Annex A of ISO 27001:2022 is one of the most referenced documents in the information security profession — and one of the most misunderstood. Organizations that approach it as a checklist to be ticked produce SMEs that can claim conformance without genuine security. Organizations that approach it as a framework of interconnected controls, each addressing specific risks, producing specific evidence, and requiring specific governance — those are the organizations that build ISMSs that actually work.
The 2022 revision restructured Annex A substantially — from 14 domains and 114 controls to 4 domains and 93 controls, with 11 new controls addressing the security challenges that emerged in the decade since the 2013 version was published. The restructuring was not cosmetic. The 2022 control architecture reflects a more coherent and actionable view of information security: organizational governance, people security, physical security, and technology security — four distinct areas, each with its own ownership model and evidence requirements.
This article provides the foundation for Section 5's deeper dives into each control domain. It covers the structural changes from 2013 to 2022, the control attribute system that makes the 2022 version far more navigable than its predecessor, the ISO 27002 companion standard, how to read control entries efficiently, and the roadmap for the remaining articles in this section.
The 2013 to 2022 Structural Transformation
The transition from ISO 27001:2013 to ISO 27001:2022 was the first major revision in nine years. For Annex A, the changes were significant — not just cosmetic reordering but a genuine rethinking of how security controls should be organized, described, and used. Understanding the differences helps organizations that started their ISMS journey under the 2013 version understand what changed and why:
| Dimension | ISO 27001:2013 / Annex A 2013 | ISO 27001:2022 / Annex A 2022 |
| Structure | 14 domains (A.5 through A.18) | 4 domains (5 Organizational, 6 People, 7 Physical, 8 Technological) |
| Total controls | 114 controls | 93 controls |
| New controls | N/A — base version | 11 new controls introduced (see Article 3.5 for full list) |
| Merged controls | N/A | Several 2013 controls merged for clarity and conciseness |
| Renamed controls | N/A | Many controls renamed to better reflect current security practice |
| Control attributes | Not present — controls listed without metadata | Each control has 5 attributes: Control type, Information security properties, Cybersecurity concepts, Operational capabilities, Security domains |
| ISO 27002 companion | ISO 27002:2013 — implementation guidance | ISO 27002:2022 — substantially revised with expanded guidance, attribute tables, and purpose statements per control |
| Transition deadline | All 2013 certificates expired October 2025 | Only valid version as of November 2025. All active certifications are on 2022. |
The reduction from 114 to 93 controls does not mean security requirements have been relaxed — many 2013 controls were merged or consolidated. The 11 genuinely new controls address areas that the 2013 version did not explicitly cover: threat intelligence, cloud services security, information deletion, data masking, secure coding, and several technological controls that have become essential in the decade since 2013.
| THE 2013 TRANSITION IS COMPLETE | As of October 2025, all ISO 27001:2013 certificates have expired. Any organization claiming ISO 27001 certification as of 2026 holds an ISO 27001:2022 certificate. SoAs built against the 2013 control list (114 controls in 14 domains) are not valid for current certification. If your organization has a 2013-era SoA, it must be updated to address all 93 controls in the 2022 structure — including explicit applicability decisions for the 11 new controls. |
The Five Control Attributes — A New Navigation Tool
The most significant structural improvement in ISO 27001:2022 Annex A — and one that many practitioners have not fully exploited — is the introduction of five attributes for each control. These attributes transform Annex A from a flat list of controls into a multidimensional catalogue that can be filtered, grouped, and prioritized in ways the 2013 version did not support.
Each of the 93 controls in Annex A now carries five attributes. Understanding these attributes unlocks more efficient control selection, better ownership assignment, and cleaner mapping to other frameworks:
| Attribute | Values | How to use it | Example |
| Control type |
| Tells you whether the control acts before, during, or after a security event. A layered security program needs controls of all three types — prevention alone is insufficient. | A.8.7 Protection against malware: Preventive (stops malware from running) and Detective (identifies malware when it attempts to execute) |
| Information security properties |
| Helps trace controls back to the CIA risks in the risk register. If your highest risk involves confidentiality of customer data, prioritize controls with a 'C' attribute. | A.8.10 Information deletion: C only — addresses confidentiality of personal data by ensuring it is removed when no longer needed. |
| Cybersecurity concepts |
| Maps to the NIST Cybersecurity Framework (CSF) concepts. Useful for organizations that want to align their ISMS with NIST CSF or for regulators that reference NIST. | A.8.8 Vulnerability management: Identify (assess vulnerabilities) and Protect (remediate before exploitation). |
| Operational capabilities |
| Groups controls by the organizational function that typically implements them. Useful for assigning control ownership — 'all controls with operational capability X belong to team Y'. | A.6.3 Information security awareness, education and training: Operational capability = Human resource security → owned by HR + ISMS Manager. |
| Security domains |
| High-level grouping that maps to strategic security program domains. Governance and ecosystem = policies, governance, supplier management. Protection = access control, cryptography. Defence = monitoring, incident response. Resilience = business continuity. | A.9.3 Management review: Governance and ecosystem — it is a governance activity, not a technical control. |
| Practical use of attributes in the SoA: The SoA can be enriched with the attribute data to create a much more useful management tool. A SoA filtered by 'Preventive' control type shows all controls that reduce risk before incidents occur — useful for a management presentation on the ISMS's protective posture. A SoA filtered by 'Confidentiality' IS property shows all controls relevant to UU PDP personal data protection. A SoA filtered by 'Detect' and 'Respond' shows all monitoring and incident response controls — relevant for a CISO's analysis of detection capability gaps. |
The Complete Annex A Control List
The table below provides the complete list of all 93 Annex A controls organized by domain. Controls marked with ★ are new in the 2022 revision. This reference table is cross-linked with the detailed articles in this section — each domain receives a dedicated deep-dive article.
| 5 — Organizational Controls (39 controls · New in 2022: 5.7, 5.23, 5.30) | ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| 6 — People Controls (8 controls · No new controls in 2022) | ||
| ||
| ||
| ||
| ||
| 7 — Physical Controls (14 controls · New in 2022: 7.4) | ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| 8 — Technological Controls (34 controls · New in 2022: 8.9, 8.10, 8.11, 8.12, 8.16, 8.23, 8.28) | ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
|
The distribution of controls across domains reflects the current reality of information security: organizational governance (39 controls) is the largest domain because policy, risk management, supplier security, and incident management are the foundation that all technical controls rest on. Technological controls (34) reflects the density of specific security mechanisms required in modern digital operations. People controls (8) is small but high-impact — the human layer is where most attacks succeed, and these 8 controls address the full human security lifecycle from hiring to departure. Physical controls (14) covers the physical environment that underlies all digital operations.
ISO 27002:2022 — The Implementation Companion
ISO 27001 tells you what controls to address. ISO 27002 tells you how to implement them. Understanding the relationship between the two standards — and knowing when to consult ISO 27002 — is essential for ISMS implementation teams:
| Aspect | Detail |
| What ISO 27002 is | ISO/IEC 27002:2022 is the implementation guidance standard that accompanies ISO 27001:2022. While ISO 27001 Annex A lists controls and requires each one to be addressed in the SoA, ISO 27002 explains each control in depth — what it is for, how to implement it, and what good practice looks like. |
| Relationship to ISO 27001 | ISO 27001 specifies what controls must be addressed. ISO 27002 explains how to implement them. ISO 27001 is the auditable standard — your ISMS is certified against ISO 27001. ISO 27002 is not directly auditable — it is implementation guidance that informs how you implement each of the 93 controls. |
| Structure in the 2022 version | ISO 27002:2022 follows the same 4-domain, 93-control structure as Annex A. Each control entry in ISO 27002 contains: the control statement (identical to Annex A), an attribute table showing the 5 attributes for that control, a 'Purpose' statement explaining what the control achieves, 'Guidance' providing detailed implementation instructions, and 'Other information' with supplementary context. |
| How to use it in ISMS implementation | Use ISO 27002 as the implementation reference when writing procedures and setting technical control standards. When the SoA says 'A.8.5 Secure authentication is applicable and implemented', the procedure that operationalizes it should reflect the implementation guidance in ISO 27002 8.5. Many organizations reference ISO 27002 in their procedure documents to show that their approach is based on internationally recognized guidance. |
| Is ISO 27002 required? | ISO 27002 is not required for ISO 27001 certification — you are certified against ISO 27001 only. ISO 27002 is a best practice implementation guide that organizations choose to use (or not). That said, auditors who see procedures that align with ISO 27002 guidance recognize that the organization has approached control implementation with appropriate depth. It is a quality signal. |
| Cost and access | ISO 27002:2022 is a commercially published standard available from ISO, national standards bodies (BSN in Indonesia), and their authorized distributors. It is not freely available. Organizations implementing ISO 27001 seriously should invest in a copy for their ISMS team. Alternatively, accredited ISMS consultants and implementation platforms provide implementation guidance derived from ISO 27002. |
| ISO 27002 vs. implementation shortcuts: Many online resources provide 'ISO 27001 control guidance' that is derived from ISO 27002 but simplified, summarized, or adapted for specific contexts. These resources are useful as starting points — but they are not a substitute for the authoritative guidance in ISO 27002 itself, particularly for complex controls. When auditors ask how implementation decisions were made, citing ISO 27002 guidance is a stronger defense than citing a blog post or a template. Invest in the standard. |
How to Read a Control Entry
Annex A control entries are concise — typically two to three sentences. Understanding the components of a control entry, and how to use them in ISMS work, extracts maximum value from the source material:
| Control entry element | Where to find it | What it means and how to use it |
| Control reference number | Before the control name. Format: [Domain].[Number] e.g. 8.5, 5.23 | Identifies the domain (5=Org, 6=People, 7=Physical, 8=Tech) and the position within it. Use this reference in the SoA, risk register, and all ISMS documentation. |
| Control name | In bold at the start of each Annex A entry | The short descriptor. Used in SoA column headers, policy cross-references, and internal communication. Memorizing the key control names by domain saves time in implementation and audit conversations. |
| Control statement | The one-to-two sentence statement beginning 'An information security policy...' or 'User endpoint devices...' | This is the requirement. It states the security standard the control is intended to achieve. The SoA applicability and implementation status decision should directly reference this statement. |
| Attribute table | A small table showing: Control type, IS properties, Cybersecurity concepts, Operational capabilities, Security domains | The attribute table tells you what the control does (type), what it protects (CIA), how it maps to NIST CSF (concepts), who implements it (capabilities), and what strategic domain it belongs to. Use attributes to group controls by owner, filter by CIA property, or map to other frameworks. |
| Purpose (ISO 27002) | In ISO 27002 — the 'Purpose' subsection after the control statement | Explains why this control exists — what risk it mitigates. Useful for justifying control applicability in the SoA and for explaining control value to non-technical stakeholders. |
| Guidance (ISO 27002) | In ISO 27002 — the 'Guidance' subsection | Implementation instructions. This is the most valuable part of ISO 27002 for practitioners — it describes what good implementation looks like. Use as the basis for writing procedures and setting technical standards. |
A worked example: Annex A control 8.5 — Secure authentication. Control statement: 'Secure authentication technologies and procedures shall be implemented based on information access restrictions and the policy on access control.' Attribute table shows it is Preventive, addresses Confidentiality and Integrity, maps to the Protect cybersecurity concept, and belongs to the Identity and access management operational capability. In ISO 27002, the Guidance section covers MFA requirements, password management, session timeout, and authentication for privileged accounts — all of which feed directly into the technical procedure for implementing 8.5.
Section 5 Article Roadmap
Section 5 is structured to provide both reference and implementation guidance for every one of the 93 Annex A controls. The articles cover each domain in depth, then address implementation methodology and Indonesian regulatory mapping:
| § | Article title | Coverage focus |
| 5.1 | Overview of Annex A and ISO 27002 | You are here — structure of the 2022 revision, the 5 control attributes, ISO 27002 relationship, and how to navigate the control set. |
| 5.2 | Organizational Controls (Domain 5) | 39 controls — policies, asset management, access management, supplier security, incident management, business continuity, compliance. Deepest domain with the most coverage. |
| 5.3 | People Controls (Domain 6) | 8 controls — screening, employment terms, awareness training, disciplinary process, departure security, NDA, remote working, incident reporting. Small domain, high human impact. |
| 5.4 | Physical Controls (Domain 7) | 14 controls — physical security perimeters, entry controls, equipment security, clean desk, secure disposal. One new control in 2022 (7.4 physical security monitoring). |
| 5.5 | Technological Controls (Domain 8) | 34 controls — the largest domain. Access control, endpoint security, vulnerability management, logging, monitoring, network security, secure development. Seven new controls in 2022. |
| 5.6 | Implementing Controls: From SoA to Evidence | How to operationalize selected controls — translating SoA decisions into procedures, technical configurations, and the evidence portfolio that satisfies auditors. |
| 5.7 | Control Mapping: ISO 27001 ↔ UU PDP ↔ POJK ↔ BSSN | How the 93 Annex A controls map to Indonesian regulatory requirements — identifying which controls satisfy which regulatory obligations and where the gaps are between ISO 27001 and Indonesian law. |
Each domain article (5.2 through 5.5) covers the controls in that domain with the same practitioner depth applied throughout this knowledge base — specific implementation guidance, Indonesian regulatory context, common implementation gaps, evidence requirements for auditors, and Bitlion GRC platform integration. Article 5.6 and 5.7 bring the domain knowledge together for implementation execution and regulatory mapping.
Approaching Annex A as a Security Architecture
The most productive way to approach Annex A is not as a compliance checklist but as a security architecture — a structured set of controls that, when implemented cohesively, create multiple layers of defense against the threats identified in the risk assessment.
The 93 controls are not independent — they reinforce each other. Access control (5.15, 5.18, 8.2, 8.3) creates the foundation that logging and monitoring (8.15, 8.16) observes. Vulnerability management (8.8) reduces the attack surface that network security (8.20, 8.21, 8.22) defends. Awareness training (6.3) reduces the human errors that incident management (5.24–5.28) responds to. Supplier security (5.19–5.22) extends the organization's security posture into the third-party relationships that create the most significant supply chain risks.
When control selection and implementation follows this architectural logic — rather than treating each control as a standalone checkbox — the ISMS produces genuine security improvement rather than compliance documentation. That architectural orientation is the spirit of ISO 27001, and Annex A is its implementation catalogue.