Annex A is a reference list of 93 information security controls appended to ISO/IEC 27001:2022 [1]. It is not a checklist you tick from top to bottom. It is a catalogue you compare against your risk assessment results so you can justify which controls you apply, which you do not, and why. That justification lives in a document called the Statement of Applicability (SoA), and it is one of the first things we look at when we open a Stage 1 audit.
Annex A and the standard
The mandatory part of ISO 27001 is Clauses 4 through 10. Those clauses tell you to run an information security management system (ISMS): define a scope, identify risks, treat them, monitor performance, and improve. Annex A does not add requirements in the way the clauses do. Clause 6.1.3 says you must "determine all controls that are necessary" to treat your risks, then compare them against Annex A to make sure you have not overlooked anything [1]. The standard's own footnote calls Annex A "a possible list of information security controls." It is a safety net, not a mandate.
The companion standard ISO/IEC 27002:2022 takes the same 93 controls and adds implementation guidance, examples, and attribute tables [2]. If Annex A is the menu, 27002 is the recipe book. You do not need to buy 27002 to get certified, but most implementers keep a copy open because the Annex A descriptions are deliberately terse (one or two sentences each).
The four themes and 93 controls
The 2022 revision reorganised Annex A from 14 domains into four themes. Here is what each one covers:
| Theme | Control count | Scope |
|---|---|---|
| Organisational (A.5) | 37 | Policies, roles, asset management, access control, supplier relationships, incident management, business continuity, compliance |
| People (A.6) | 8 | Screening, terms of employment, awareness, disciplinary process, responsibilities after termination |
| Physical (A.7) | 14 | Perimeters, entry controls, securing offices, clear desk, equipment siting, cabling, maintenance, disposal |
| Technological (A.8) | 34 | User devices, privileged access, authentication, source code, malware, backups, logging, network security, secure development, data masking, DLP |
The total is 93. We once opened a Stage 2 with a client whose SoA listed 114 controls against the 2022 standard, which only has 93. That is a bad start to a Tuesday. They had copied a 2013-era template and never updated it.
2013 to 2022 changes
The previous version of the standard, ISO/IEC 27001:2013 (amended 2017), had 114 controls in 14 domains [3]. The 2022 revision did not delete any control outright. Instead, 24 were merged, 58 were updated, and 11 entirely new controls were added [2]. The result is a shorter, better-organised list.
The restructuring also introduced attribute values from ISO 27002:2022: each control can be tagged by control type (preventive, detective, corrective), security properties (confidentiality, integrity, availability), cybersecurity concepts (identify, protect, detect, respond, recover), operational capabilities, and security domains [2]. These attributes are not mandatory for certification, but they make it easier to map your controls to other frameworks like NIST CSF or the UK Cyber Essentials scheme.
The transition deadline from the 2013 to the 2022 version was 31 October 2025 [4]. Any certificate still referencing the 2013 standard is now void. If your organisation missed the deadline, you need a full Stage 1 and Stage 2 audit, not a transition audit.
The eleven new controls
These are controls that did not exist in the 2013 edition. Most of them reflect how organisations actually work now, with cloud infrastructure, remote teams, and threat intelligence feeds that did not feature in a standard written when on-premise servers were the default.
- 5.7 Threat intelligence - gathering and analysing information about threats to inform decisions
- 5.23 Information security for use of cloud services - managing security when you use third-party cloud
- 5.30 ICT readiness for business continuity - making sure your technology can actually recover, not just your paper plan
- 7.4 Physical security monitoring - CCTV, alarms, intrusion detection for physical premises
- 8.9 Configuration management - baselines for systems, documented and enforced
- 8.10 Information deletion - deleting data when you no longer need it (a GDPR overlap, and auditors notice when you do not have it)
- 8.11 Data masking - anonymisation and pseudonymisation in non-production environments
- 8.12 Data leakage prevention - DLP tools and processes
- 8.16 Monitoring activities - logging, alerting, anomaly detection across systems
- 8.23 Web filtering - blocking access to malicious or inappropriate websites
- 8.28 Secure coding - secure development practices baked into the software lifecycle
If you are a SaaS company, controls 5.23, 8.9, 8.16, and 8.28 are likely already part of how you operate. The standard caught up with you. For a company with no cloud presence and no software development, some of these may not apply, and your SoA should say so with a clear reason.
The Statement of Applicability
The Statement of Applicability (SoA) is where Annex A meets your risk assessment. Clause 6.1.3 d) requires you to produce a document that lists all necessary controls, justifies their inclusion, states whether they are implemented, and explains why any Annex A control was excluded [1].
In practice, the SoA is usually a spreadsheet or a table with one row per Annex A control, columns for applicability (yes/no), justification, implementation status, and a reference to the risk or policy that drives it. We have reviewed SoAs that ran to 30 pages with paragraph-long justifications. That is unnecessary. A one-sentence reason per control is fine. "Excluded: we have no physical premises (fully remote)" is a perfectly acceptable justification for excluding physical controls.
The SoA is also where you record controls you have added beyond Annex A. The standard explicitly allows this. If your risk assessment identifies a need for something Annex A does not cover (application-level rate limiting, say), you add it to the SoA and treat it like any other control.
Common Annex A mistakes
The biggest one is treating Annex A as a compliance checklist. Organisations mark every control as applicable, write a policy sentence for each one, and call it done. An auditor will ask "what risk drove this control?" and the answer cannot be "it was in Annex A". The logic runs from risk assessment to control selection, not the other way around.
The second mistake is confusing control titles with implementation requirements. Control A.8.7 is titled "Protection against malware." That does not mean you need an enterprise antivirus product. It means you need a proportionate measure against malware. For a three-person startup running macOS with no local admin rights and a managed endpoint tool, that might be a paragraph in your acceptable use policy and a configuration baseline. For a hospital network with 4,000 Windows endpoints, it is a different conversation.
The third is ignoring the new controls. If your SoA still lists 114 controls in 14 domains, your ISMS is built on a version of the standard that expired in October 2025 [4]. Even if your certificate is current, your next surveillance audit will check that your SoA reflects the 2022 structure.
Working through Annex A
Start with your completed risk assessment. For each risk treatment, identify which Annex A controls are relevant. Then go through the remaining Annex A controls and ask: "Is there a reason this applies to us that our risk assessment missed?" If yes, add the risk and the control. If no, document why in the SoA.
At Calibre, we see most small tech companies marking 70 to 80 of the 93 controls as applicable. The exclusions are typically physical controls (if fully remote), a handful of people controls (if there is no HR function beyond the founders), and occasionally web filtering or physical security monitoring. Every exclusion needs a justification, but the justification does not need to be long.
The whole exercise, for a 20-person SaaS company with a clear scope, usually takes a day or two. If it is taking a month, you are probably over-engineering the SoA or trying to write implementation procedures at the same time. Separate the two. Decide what applies first. Write the procedures second.
FAQ
There are 93 controls in the 2022 version, down from 114 in the 2013 version. The reduction came from merging overlapping controls, not from removing requirements [2].
No. You implement the controls your risk assessment identifies as necessary, then check against Annex A for anything you might have missed. Controls that do not apply to your scope can be excluded with a documented justification in your Statement of Applicability.
Annex A lists the 93 controls with a title and a brief description. ISO 27002 takes the same controls and adds detailed implementation guidance, examples, and attribute tags [2]. Annex A is normative (referenced by the standard); ISO 27002 is guidance.
Yes. The IAF set 31 October 2025 as the transition deadline [4]. Certificates issued against the 2013 standard are no longer valid. Organisations still on the old structure need a fresh certification audit, not a transition audit.
The four themes are organisational (37 controls), people (8), physical (14), and technological (34). They replaced the 14 domains used in the 2013 version.
Sources
- 1.ISO/IEC. (2022). "ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection - Information security management systems - Requirements". https://www.iso.org/standard/27001
- 2.ISO/IEC. (2022). "ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection - Information security controls". https://www.iso.org/standard/75652.html
- 3.ISO/IEC. (2013). "ISO/IEC 27001:2013 Information technology - Security techniques - Information security management systems - Requirements". https://www.iso.org/standard/54534.html
- 4.International Accreditation Forum. (2023). "IAF Resolution 2022/21 - Transition to ISO/IEC 27001:2022". https://iaf.nu/en/iaf-documents/
- 5.ISO. (2025). "The ISO Survey of Management System Standard Certifications 2024". https://www.iso.org/the-iso-survey.html
- 6.Department for Science, Innovation and Technology. (2026). "Cyber Security Breaches Survey 2025/2026". GOV.UK. https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026
