Blog
ISO 27001 Annex A controls explained: the 93 controls in 4 themes.
Annex A of ISO/IEC 27001:2022 is a reference list of information security controls. It is not a checklist you must implement in full. You use it to check that your risk treatment has not missed a control you need, and you record the result in your Statement of Applicability.
This article covers how the 2022 Annex A is organized, what changed from the 2013 edition, where the control attributes come from, and how exclusions work.
93 controls in 4 themes
The 2022 edition groups its 93 controls into four themes, numbered as sections 5 to 8 of Annex A. The 2013 edition had 114 controls in 14 domains. Most of the old controls were merged or renamed rather than removed, and 11 are new.
| Theme | Controls | Count |
|---|---|---|
| Organizational | 5.1 to 5.37 | 37 |
| People | 6.1 to 6.8 | 8 |
| Physical | 7.1 to 7.14 | 14 |
| Technological | 8.1 to 8.34 | 34 |
- Organizational. Examples: Policies for information security (5.1), access control (5.15), supplier relationships (5.19 to 5.22), incident management (5.24 to 5.28), legal and contractual requirements (5.31).
- People. Examples: Screening (6.1), terms and conditions of employment (6.2), awareness, education and training (6.3), remote working (6.7).
- Physical. Examples: Physical security perimeters (7.1), physical entry (7.2), clear desk and clear screen (7.7), storage media (7.10).
- Technological. Examples: User endpoint devices (8.1), privileged access rights (8.2), backup (8.13), logging (8.15), use of cryptography (8.24).
The themes say who usually owns a control, not how important it is. Organizational controls are the policies and processes; people controls are about staff before, during and after employment; physical controls cover premises and equipment; technological controls are the ones IT and engineering implement.
The 11 new controls in 2022
If you are moving an ISMS from the 2013 edition, these are the controls with no 2013 equivalent. Each one needs an applicability decision and, where it applies, an owner and evidence.
| Control | Title |
|---|---|
| 5.7 | Threat intelligence |
| 5.23 | Information security for use of cloud services |
| 5.30 | ICT readiness for business continuity |
| 7.4 | Physical security monitoring |
| 8.9 | Configuration management |
| 8.10 | Information deletion |
| 8.11 | Data masking |
| 8.12 | Data leakage prevention |
| 8.16 | Monitoring activities |
| 8.23 | Web filtering |
| 8.28 | Secure coding |
Several of them reflect how most organizations now run: cloud services (5.23), configuration as something to manage rather than assume (8.9), and secure coding for anyone who writes software (8.28). Others, such as data masking (8.11), may genuinely not apply to you, which is fine as long as the reason is written down.
Attributes come from ISO/IEC 27002, not 27001
ISO/IEC 27002:2022 is the guidance standard that explains each Annex A control in detail. It also tags every control with five attributes, so you can sort and filter the list in ways other than the four themes:
- Control type: preventive, detective or corrective.
- Information security properties: confidentiality, integrity, availability.
- Cybersecurity concepts: identify, protect, detect, respond, recover.
- Operational capabilities: for example governance, asset management, identity and access management, supplier relationships security.
- Security domains: governance and ecosystem, protection, defence, resilience.
The attributes are optional. ISO 27001 does not require you to use them, and an auditor will not raise a nonconformity because your SoA leaves them out. They are useful when someone asks, for example, which of your controls are detective, or how your controls line up with the identify-protect-detect-respond-recover model.
How Annex A and the Statement of Applicability fit together
Clause 6.1.3 sets the order. First you decide how to treat your risks and determine the controls that treatment needs, from any source. Then you compare those controls with Annex A to check you have not left out something necessary. Then you produce the Statement of Applicability (6.1.3 d), which contains:
- the necessary controls, including any you added that are not in Annex A;
- the justification for including them;
- whether each one is implemented;
- the justification for excluding any Annex A control.
The SoA is the document a certification auditor uses to plan which controls to sample, so it needs to agree with your risk register. A control marked applicable that treats no risk, or a high risk with no control against it, is the kind of gap that turns into a finding.
Exclusions need a justification
You can exclude an Annex A control, but you have to say why, and the reason has to hold up against your risk assessment and your scope. “We have no office” can justify excluding some physical controls; it does not justify excluding remote working (6.7) or the security of assets off-premises (7.9). If your data sits with a cloud provider, physical security of the data center is usually handled through your supplier controls (5.19 to 5.23) rather than excluded outright.
Exclusions apply to Annex A only. The requirements in clauses 4 to 10 (context, leadership, planning, support, operation, performance evaluation and improvement) are mandatory for every ISMS.
What GapLedger does with Annex A
GapLedger loads all 93 Annex A controls plus the 18 clause 4 to 10 requirements, each with plain-English guidance. For every control you record whether it applies, the justification and its status, and you link the risks it treats. Applicable controls with no linked risk, and controls with no written justification, are flagged. The SoA is a PDF you can download at any time, built from those decisions. See the Statement of Applicability page for a sample, or the ISO 27001 software page for the rest of the ISMS.