Organizational Controls (Domain 5)

Domain 5 is the largest of the four Annex A domains — 39 controls covering the full organizational governance infrastructure that information security requires. It is also the domain most directly connected to management system maturity: the controls in Domain 5 are the ones that make the ISMS a genuine management program rather than a collection of technical measures. Technical controls without Domain 5 governance are fragile — they have no policy authority, no ownership, no supplier security context, and no incident response capability.

This article provides a complete reference for all 39 organizational controls. The primary reference section covers every control with its requirement, evidence standard, and Indonesian regulatory link. Three sub-groups receive deeper implementation treatment: 5.7 (Threat Intelligence — a new 2022 control that many organizations are still operationalizing), 5.19–5.23 (Supplier Security — the most commonly failing control group in first-cycle audits), and 5.24–5.28 (Incident Management — the most regulatory-sensitive group for Indonesian organizations given UU PDP breach notification obligations).

Domain 5 Sub-Group Structure

The 39 organizational controls fall into 10 logical sub-groups, each addressing a distinct governance domain. Understanding this structure helps assign ownership and sequence implementation work:

Sub-group	Controls	Coverage
Governance (5.1–5.4)	5.1–5.4	The top of the governance hierarchy — IS policies, roles and responsibilities, segregation of duties, and management responsibilities. Everything else in Annex A is governed by these four controls.
Relationships (5.5–5.6)	5.5–5.6	Contact with authorities and special interest groups. Ensures the organization maintains current threat awareness through regulatory and peer network engagement.
Threat intelligence (5.7)	5.7	NEW in 2022 — Requires active collection, analysis, and use of threat intelligence to inform risk assessments and control improvements. The most forward-looking new control.
Project and asset management (5.8–5.11)	5.8–5.11	Security in project management, asset inventory, acceptable use, and return of assets. Foundation for knowing what you have and how it should be handled.
Information classification (5.12–5.14)	5.12–5.14	Classification levels, labelling requirements, and information transfer rules. Core to UU PDP personal data protection obligations.
Access and identity governance (5.15–5.18)	5.15–5.18	Access control policy, identity management, authentication information management, and access rights lifecycle. Sets the governance framework for the technical access controls in Domain 8.
Supplier security (5.19–5.23)	5.19–5.23	Security in supplier relationships, supplier agreements, ICT supply chain, supplier monitoring, and cloud services (NEW 5.23). One of the most critical areas for Indonesian organizations in the cloud-native era.
Incident management (5.24–5.28)	5.24–5.28	Planning, classification, response, learning, and evidence collection for security incidents. Direct mapping to UU PDP 14-day breach notification obligation.
Business continuity (5.29–5.30)	5.29–5.30	Security during disruption and ICT readiness for business continuity (NEW 5.30). Bridges information security with operational resilience.
Compliance (5.31–5.37)	5.31–5.37	Legal, statutory, regulatory and contractual compliance, IP rights, records protection, privacy, independent review, and documented operating procedures. Critical for Indonesian regulated organizations.

Complete Control Reference: Governance and Relationships (5.1–5.6)

The first six controls establish the governance foundation. 5.1 and 5.2 are the most directly audited — the IS policies and roles and responsibilities are what auditors read first at Stage 1. 5.3 and 5.4 address structural governance requirements that are frequently underdeveloped in first-cycle ISMSs. 5.5 and 5.6 ensure the organization maintains external awareness:

5.1–5.6 — Governance and Relationships

Ref. Control name What it requires Key evidence required Indonesian reg. link

5.1 IS policies A set of IS policies must be defined, approved by management, published, and communicated to staff. The top-level IS policy and supporting domain policies are both covered. IS Policy (CEO-signed, current version). Supporting policies suite (Access Control, Incident Management, etc.). Staff acknowledgment records. POJK 11/2022 IT policy requirements; UU PDP Article 53 internal data protection policies

5.2 IS roles and responsibilities Define and allocate IS responsibilities. All roles that affect information security must have documented responsibilities. No gaps in ownership — every critical ISMS activity has a named owner. Roles and responsibilities document / RACI. ISMS organizational chart. Job descriptions for ISMS roles. POJK IT governance role requirements; OJK IT risk ownership structure

5.3 Segregation of duties Conflicting duties and areas of responsibility must be segregated to reduce the risk of unauthorized or unintentional modification or misuse of assets. No single individual should control both the authorization and execution of sensitive activities. RACI showing segregation in critical processes (e.g. access request approved by different person than IT who provisions). Access control configuration showing role separation. OJK internal control requirements; Bank Indonesia payment system controls

5.4 Management responsibilities Management must actively demonstrate their commitment to IS through behavior — requiring staff to apply security per established policies and procedures, and by visibly supporting the ISMS. Management review attendance records. Executive IS communications. IS policy sign-off at executive level. Evidence of management participation in risk decisions. POJK IT governance management accountability; OJK board IT responsibility

5.5 Contact with authorities Maintain contacts with relevant authorities — regulators, law enforcement, emergency services — so that when incidents occur the organization can notify the right people quickly. Contacts register including KOMINFO, OJK, BI, BSSN, Bareskrim Polri (cybercrime) as applicable. Incident escalation procedure showing authority notification triggers. UU PDP KOMINFO notification obligation; OJK incident notification; BI payment system breach notification

5.6 Contact with special interest groups Maintain relationships with security forums, professional associations, and peer groups to access current threat intelligence and security knowledge. Membership records or participation evidence: ID-SIRTII, CSIRT Keuangan, ISACA Indonesia, BSSN advisory mailing list. Records of intelligence received through these channels. BSSN national cybersecurity coordination framework; financial sector CSIRT membership

5.7 — Threat Intelligence (NEW 2022): Deep Dive

Control 5.7 is the most significant new organizational control in the 2022 revision. It formalizes something that mature security teams already do — monitoring the threat landscape — and makes it a documented, evidenced ISMS activity rather than an informal practice. For Indonesian organizations, this control is directly relevant given the active threat environment for financial services and technology companies in 2025–2026:

Aspect	Detail
What the control requires	The organization must collect information about threats relevant to the security of information assets and analyze it to produce threat intelligence that can inform risk decisions. Intelligence must be specific, contextual, and actionable — not just generic security news.
Three types of threat intelligence	Strategic: High-level threat trends affecting the sector — e.g. BSSN annual cyberthreat report, OJK cybersecurity circulars, ENISA Threat Landscape. Tactical: Specific attack techniques, tactics and procedures (TTPs) relevant to the organization — e.g. MITRE ATT&CK techniques observed in Indonesian fintech attacks. Operational: Specific, timely intelligence about active threats — e.g. CVE disclosures in used software, active ransomware campaign targeting the sector.
Indonesian sources to monitor	BSSN (Badan Siber dan Sandi Negara) — Indonesian national cybersecurity agency, publishes advisories and annual threat reports. OJK IT security circulars — sector-specific threat information for financial institutions. ID-CERT (Indonesia Computer Emergency Response Team) — incident-specific advisories. CSIRT Keuangan (Financial Sector CSIRT) — financial sector specific. Additionally: international sources — ENISA, CISA (US), ASD/ACSC (Australia) for global context.
How to operationalize it	Assign a threat intelligence owner (typically ISMS Manager or IT Security Lead). Define a monitoring schedule — weekly for operational intelligence, quarterly for strategic/tactical. Document the process in the threat intelligence procedure. Feed intelligence into risk assessment updates — new threats discovered through intelligence should trigger risk register reviews per Clause 8.2. Record intelligence reviewed and actions taken as documented information.
Evidence required	Threat intelligence procedure. Records of intelligence reviewed (log with date, source, summary, and action taken). Evidence that intelligence has influenced risk assessments — risk register entries updated with 'trigger: threat intelligence from [source]'. Management review input showing threat intelligence summary.

Indonesian threat intelligence context: The BSSN Annual Cyberthreat Report (published annually in Q1) is the most authoritative national threat intelligence source for Indonesian organizations. The 2025 report highlighted: Business Email Compromise targeting Indonesian financial institutions (highest volume in SEA), ransomware attacks against Indonesian healthcare and government, and social engineering campaigns exploiting UU PDP awareness as a phishing pretext. These national-level findings should feed directly into risk register updates for any organization in the affected sectors.

Complete Control Reference: Asset and Information Management (5.8–5.14)

Asset and information management controls establish the foundation that risk assessment and control selection rest on: you cannot protect what you have not identified. Controls 5.12–5.14 (information classification) are particularly important for UU PDP compliance — personal data must be identified, classified, and handled appropriately:

5.8–5.14 — Asset and Information Management

Ref. Control name What it requires Key evidence required Indonesian reg. link

5.8 IS in project management Information security requirements must be addressed in project management — new systems, applications, and processes must be assessed for IS risks as part of project delivery, not as an afterthought. Project security assessment template. Security review gate in project methodology. Sample project security assessments. Security requirements in project acceptance criteria. POJK IT project management requirements; OJK new product security assessment guidance

5.9 Inventory of information and other associated assets Maintain an inventory of all information assets — information, software, hardware, services, and people — within the ISMS scope. Assets must have named owners. Asset inventory / register covering all in-scope categories. Named owners for each asset or asset class. Last updated date. UU PDP — requires inventory of personal data assets (data mapping); POJK IT asset management

5.10 Acceptable use of information and other assets Rules for acceptable use of information and assets must be documented, communicated, and applied. Staff must understand what is and is not permitted with organizational assets. Acceptable Use Policy. Staff acknowledgment records. Evidence of communication to staff. UU PDP employee obligations for personal data; HR security policy requirements

5.11 Return of assets All assets must be returned upon termination of employment or contract. Process must cover physical devices, credentials, access cards, and any data held on personal devices. Offboarding checklist showing asset return requirements. Records of completed offboarding for departed staff. Equipment return records. Supports UU PDP data minimization — returned devices must have data securely erased

5.12 Classification of information Information must be classified based on its sensitivity and criticality. Classification levels must be defined and applied consistently. Personal data under UU PDP receives special treatment. Data Classification Policy with defined levels. Classification guidance for common information types. Evidence of classification applied to key information assets. UU PDP — personal data as special classification requiring enhanced protection; POJK information classification guidance

5.13 Labelling of information Implement a labelling scheme consistent with the classification policy. Information must be labelled so users understand how to handle it. Labelling procedure. Template examples showing labelling applied. Evidence that labelling is in use (sample classified documents). UU PDP data handling requirements; document control requirements

5.14 Information transfer Rules for information transfer (to internal parties, external parties, public) must be defined and applied based on classification. Secure transfer methods required for confidential and restricted information. Information transfer policy/procedure. Evidence of secure email or file transfer for sensitive data. Supplier agreements covering data transfer requirements. UU PDP Article 55 (data transfer obligations); cross-border data transfer restrictions

Complete Control Reference: Access and Identity Governance (5.15–5.18)

Controls 5.15–5.18 set the organizational governance framework for access management — the policies and processes that the technical controls in Domain 8 (8.2–8.5) operationalize. The governance must exist before the technical implementation can be governed:

5.15–5.18 — Access and Identity Governance

Ref. Control name What it requires Key evidence required Indonesian reg. link

5.15 Access control Define and implement an access control policy covering: need-to-know and least privilege principles, access request and approval process, role-based access, and access review requirements. Access Control Policy. Access request form/workflow. Role-based access definitions for key systems. Quarterly access review records. UU PDP access controls for personal data; POJK access management requirements; Bank Indonesia payment system access controls

5.16 Identity management Manage the full lifecycle of identities — creation, maintenance, suspension, and deletion. All users must have unique identifiers. Shared accounts must be justified and controlled. Identity lifecycle procedure. IAM system configuration showing unique accounts. Process for managing service and shared accounts. POJK IT governance identity management requirements

5.17 Authentication information Management of authentication information (passwords, tokens, certificates) — including secure provisioning, storage, and change. Password policies meeting current standards. Password/authentication policy. Password management system deployment evidence. MFA enrollment records. Credential provisioning process records. POJK IT security authentication requirements; Bank Indonesia payment system authentication controls

5.18 Access rights Manage access rights throughout the user lifecycle — provisioning (with formal approval), periodic review, and revocation on departure or role change. Privileged access requires additional controls. Access provisioning records showing approval workflow. Quarterly access review reports with changes actioned. Departure access revocation records (4-hour SLA evidence). UU PDP access controls for personal data processing; POJK access rights management

Supplier Security (5.19–5.23): Deep Dive

The supplier security controls are the most commonly failing control group in first-cycle ISO 27001 audits. Organizations that have excellent internal security controls often have significant gaps in how they manage the security of the suppliers, cloud providers, and technology partners that handle their data or operate their systems. The 2022 addition of 5.23 (cloud services) makes explicit what was previously implied — cloud providers require specific governance:

Control	Name	What it requires	Evidence	Indonesian reg.
5.19	Information security in supplier relationships	Defines the baseline security requirements that apply to all supplier relationships — the framework for how the organization addresses security when working with third parties. This control establishes the policy; 5.20–5.22 operationalize it.	Supplier security policy. Supplier risk tiering methodology. Supplier register showing security tier for each supplier.	UU PDP Article 14 (third-party data processing); POJK 11/2022 IT risk management (third-party services)
5.20	Addressing information security within supplier agreements	Security requirements must be established in contracts with all in-scope suppliers — covering security obligations, incident notification, right to audit, data handling, and sub-processor disclosure. Generic service agreements without security addenda do not satisfy this control.	Supplier contracts with signed security addenda. DPAs for personal data processors. Security SLA records. Sub-processor disclosure documentation.	UU PDP Article 53 (DPA obligation for processors); UU PDP Article 14 (data transfer agreements)
5.21	Managing information security in the ICT supply chain	Goes beyond direct supplier relationships to address the broader ICT supply chain — hardware and software suppliers whose products are used in in-scope systems. Organizations must understand the security posture of their technology supply chain, not just their direct service providers.	ICT supply chain risk assessment. Hardware/software supplier security assessments for critical in-scope components. Supply chain security requirements in technology procurement criteria.	BSSN cybersecurity framework supply chain requirements; POJK IT risk management supply chain considerations
5.22	Monitoring, review and change management of supplier services	Ongoing monitoring of supplier security performance — not just due diligence at onboarding. Requires regular review of supplier security posture, SLA performance, and security incident history. Changes to supplier services must be assessed for security impact.	Annual supplier security review records. Supplier monitoring log. Records of security incidents involving suppliers and responses. Change management records for supplier service changes.	POJK 11/2022 requirements for ongoing monitoring of outsourced IT services; BI payment system supplier monitoring requirements
5.23 ★	Information security for use of cloud services (NEW 2022)	The first control explicitly addressing cloud services in ISO 27001. Requires that organizations establish information security requirements for cloud service acquisition, use, and termination — covering selection criteria, security obligations, data portability, and exit terms.	Cloud security policy or cloud-specific addendum to supplier security policy. Cloud service provider security assessments. Cloud security configuration standards. Data portability and exit documentation for critical cloud services.	UU PDP data residency implications; OJK cloud governance guidance; POJK cloud risk management requirements

UU PDP DPA urgency for Indonesian organizations: Control 5.20 requires security obligations in supplier agreements — and for any supplier that processes personal data on behalf of the organization, UU PDP Article 53 requires a formal Data Processing Agreement (DPA). As of 2026, many Indonesian organizations have not yet established DPAs with their SaaS providers, cloud infrastructure vendors, or payment processors. This creates a simultaneous Annex A 5.20 nonconformity AND a UU PDP violation. The supplier contract security addenda program should explicitly prioritize establishing DPAs for all personal data processors — this single action closes both gaps.

Incident Management (5.24–5.28): Deep Dive

The five incident management controls form the complete lifecycle of incident response — from preparation before incidents occur through to learning and evidence preservation afterward. For Indonesian regulated organizations, these controls are particularly critical because of the explicit UU PDP breach notification obligation that ties to control 5.26:

Control	Name	What it requires	Evidence	Indonesian reg.
5.24	Incident management planning & preparation	Define the ISMS roles, responsibilities, and procedures for incident management before incidents occur. Designate an incident response team. Establish communication channels and escalation paths.	Incident management policy. Incident response procedure with RACI. Escalation matrix. Contact list for response team.	POJK 11/2022 IT incident management procedures; BI payment system incident management
5.25	Assessment and decision on information security events	Not every security event is an incident. Define criteria for classifying security events (minor anomaly vs. confirmed incident vs. major breach) and the decision process for each classification. Document assessment outcomes.	Incident classification matrix (P1–P4 or equivalent). Event log showing classification decisions. Assessment records for events that did not escalate to incidents.	UU PDP — classification affects notification obligation triggering; OJK incident severity classification guidance
5.26	Response to information security incidents	Execute the response procedure when a classified incident occurs: contain, investigate, eradicate, recover, and communicate. Coordinate with affected parties. Maintain evidence chain.	Incident response records for all classified incidents. Containment evidence. Communication records to affected parties. Evidence preservation log.	UU PDP Article 46 — notification to KOMINFO within 14 calendar days of discovery; UU PDP Article 46 notification to affected data subjects; OJK incident notification requirements
5.27	Learning from information security incidents	Conduct post-incident reviews for significant incidents. Feed lessons learned into risk assessments, control improvements, and awareness training. Track improvement actions to completion.	Post-incident review reports. Risk register updates triggered by incidents. Training content updates from incident lessons. Corrective action records for incident-identified gaps.	POJK requirement for incident root cause analysis and improvement reporting; demonstrates regulatory due diligence
5.28	Collection of evidence	When incidents may result in legal proceedings or regulatory investigations, evidence must be collected in a manner that preserves its admissibility. Define evidence preservation procedures.	Evidence collection procedure. Chain of custody records for evidence collected. Legal hold procedures when relevant.	Indonesian criminal procedure law (KUHAP) requirements for digital evidence; potential regulatory investigation evidence obligations

The UU PDP 14-day notification clock: Control 5.26 (Response to information security incidents) intersects directly with UU PDP Article 46, which requires notification to KOMINFO within 14 calendar days of discovery (not confirmation) of a personal data breach. This 14-day window starts the moment the organization becomes aware that a breach may have occurred — not when it is confirmed. The incident response procedure must explicitly identify the notification trigger point, the responsible person (typically Legal Director or DPO), the KOMINFO notification portal URL, and the information required in the notification. Organizations that do not operationalize this in the incident response procedure before they experience a breach will miss the deadline.

Business Continuity (5.29–5.30)

The two business continuity controls bridge ISO 27001 with ISO 22301 (business continuity management). Control 5.30, introduced in 2022, makes ICT continuity an explicit IS requirement — not just a general business resilience matter:

5.29–5.30 — Business Continuity

Ref. Control name What it requires Key evidence required Indonesian reg. link

5.29 IS during disruption Plan how the organization will maintain appropriate levels of information security during disruption — whether natural disaster, system failure, or security incident. IS continuity requirements must be integrated with BCM planning. IS during disruption policy / procedure. BCM plan with IS continuity requirements. Evidence of IS continuity testing (tabletop or live exercise). Recovery objectives for IS systems. OJK business continuity requirements for financial institutions; BI payment system continuity standards

5.30 ★ ICT readiness for business continuity (NEW) Plan, implement, maintain, and test ICT continuity based on business continuity and disaster recovery requirements. Define RTO and RPO for in-scope systems. Test recovery procedures regularly. ICT continuity plan with defined RTO/RPO per system. DR test records showing recovery times achieved. Backup recovery test evidence. Gap analysis between current and target RTO/RPO. OJK BCM requirements specifying recovery time objectives; BI payment system disaster recovery requirements

Compliance Controls — Indonesian Context (5.31–5.37)

The compliance controls close the Domain 5 loop — ensuring that the ISMS addresses all legal, regulatory, and contractual obligations. For Indonesian organizations, the compliance context is unusually dense in 2026: UU PDP enforcement, active POJK IT governance requirements, Bank Indonesia payment system standards, and BSSN national cybersecurity framework all create overlapping obligations that controls 5.31–5.37 must address. The table below focuses on the five compliance controls most directly relevant for Indonesian regulated organizations:

Ref.	Name	Indonesian implementation context	Regulatory link
5.31	Legal, statutory, regulatory and contractual requirements	Requires identification of all applicable legal and regulatory requirements — the 'interested parties requirements' from Clause 4.2 operationalized into controls. For Indonesian organizations this means UU PDP, UU ITE, POJK, PBI, BSSN frameworks, and any sector-specific requirements. The context analysis from Clause 4.1 feeds directly into this control.	UU PDP; POJK 11/2022; PBI 23/6/2021; BSSN Presidential Regulation 82/2022; sector-specific regulations
5.34	Privacy and protection of PII	This control specifically addresses personal data protection — requiring that privacy requirements for personal information are identified and met. It is the Annex A control most directly aligned to UU PDP obligations. Requires a privacy framework, data mapping, consent management, data subject rights procedures, and personal data breach response.	UU PDP Articles 20–40 (individual rights); UU PDP Articles 41–53 (processor obligations); UU PDP Article 46 (breach notification)
5.35	Independent review of information security	Requires that the ISMS and its controls are independently reviewed — not just by internal staff. This can be satisfied by the external certification audit, but many organizations also use independent security assessments, penetration tests, or external ISMS reviews. Particularly relevant for OJK-regulated entities where independent IT audit is a regulatory expectation.	POJK 11/2022 independent audit requirements; OJK IT governance examination practices
5.36	Compliance with policies, rules and standards for information security	Managers must regularly verify that compliance with IS policies and standards within their area of responsibility is being maintained. This creates the governance loop between policy (5.1) and operational reality — ensuring that policies are not just written but actually followed.	Supports all regulatory compliance demonstrations; demonstrates governance maturity to OJK and BSSN
5.37	Documented operating procedures	Operating procedures for information processing facilities must be documented, maintained, and made available to relevant users. This control ensures that critical system administration, backup, monitoring, and operational security tasks are not dependent on individuals' memory but on documented, controlled procedures.	POJK IT governance documentation requirements; BI payment system operational procedure requirements

Control 5.34 and UU PDP: Privacy and protection of PII (5.34) is the Annex A control that most directly operationalizes UU PDP compliance within the ISMS framework. Organizations that implement 5.34 thoroughly — with data mapping, processing registers, consent management, data subject rights procedures, and breach response — will find that most UU PDP Articles are addressed as a byproduct. The reverse is also true: organizations that implement UU PDP obligations thoroughly will find that 5.34 is largely satisfied. The key insight is that ISO 27001 certification and UU PDP compliance are complementary, not competing — implementing one reinforces the other.

Common Domain 5 Gaps and How to Close Them

Threat intelligence as a nominal activity

5.7 is a new control and many first-cycle organizations operationalize it minimally — subscribing to BSSN email alerts and recording that as 'threat intelligence'. Genuine 5.7 compliance requires: a documented process, multiple intelligence sources, regular review cadence, and evidence that intelligence findings have actually influenced risk assessment updates. The evidence auditors look for is not 'we subscribed to BSSN alerts' but 'here is the BSSN alert from March 2026, here is the risk register entry we updated as a result, and here is the management review where we presented this as a significant threat development.'

Supplier register incomplete — cloud providers missing

The most common 5.19–5.22 gap: the supplier register identifies traditional IT vendors but does not include cloud SaaS providers, productivity tools, or development platforms. Every service that processes in-scope data or provides in-scope system functionality is a supplier under the organizational controls. The CFO's expense management SaaS, the development team's CI/CD platform, and the customer success team's CRM are all in scope if they access or process data within the ISMS boundary.

Incident response procedure covers detection but not notification

The most critical gap in 5.26 for Indonesian organizations: the incident response procedure describes how to detect and contain incidents but does not address regulatory notification. The UU PDP 14-day notification obligation, the OJK notification process, and the Bank Indonesia notification timeline for payment system incidents are either absent or described vaguely. A procedure that says 'notify relevant authorities as required by law' without specifying who, when, and how does not satisfy the requirement when a real incident occurs with a ticking 14-day clock.