The number 93 stops a lot of people in their tracks. Ninety-three security controls. That is what ISO 27001:2022’s revised Annex A presents to any organisation pursuing certification. If you have spent any time staring at that list and wondering how on earth your team is supposed to implement all of it, this post is written specifically for you.
The short answer: you are not required to implement all 93 controls. The longer answer — and the one that actually matters — is more nuanced, and getting it wrong is one of the most common reasons ISO 27001 projects fail or stall.
How Annex A Actually Works
Annex A is a reference set. It provides a catalogue of controls that organisations should consider during their risk treatment process. The key word is “consider.” ISO 27001 does not mandate that every control is implemented — it mandates that every control is reviewed, and that any control you choose not to implement is explicitly justified in your Statement of Applicability (SoA).
This distinction is critical. An auditor is not checking a box next to each of 93 items. They are looking at your SoA, cross-referencing it with your risk register, and assessing whether your decisions are logical, documented, and defensible. An organisation that implements 60 controls with clear justifications will pass an audit. An organisation that implements all 93 controls but cannot explain why they chose them will not.
The Four Themes: A Map for the Overwhelmed
One of the genuine improvements in the 2022 version is how the controls are structured. The 2013 standard organised 114 controls across 14 domain categories that often felt arbitrary. The 2022 version reorganises everything into four clear themes:
Organisational Controls (37 controls)
These cover governance-level items: policies, roles and responsibilities, information security in project management, threat intelligence, supplier relationships, and incident management. If your ISMS has a documentation or governance gap, this is usually where it shows up.
People Controls (8 controls)
Screening, terms and conditions, information security awareness, training, disciplinary processes, and offboarding. Eight controls. This is the shortest category, but it is consistently under-evidenced. Having a training policy is not evidence of training. Completion records are.
Physical Controls (14 controls)
Physical security perimeters, access controls, securing offices, clear desk and clear screen policies, equipment maintenance, and secure disposal. Cloud-native organisations sometimes assume most of these don’t apply. That assumption needs to be documented in your SoA — not just assumed.
Technological Controls (34 controls)
This is where the 2022 update has the most new content. User endpoint devices, privileged access rights, information access restriction, secure coding, web filtering, data masking, data leakage prevention, monitoring activities, and more. If your organisation builds or maintains software, controls like A.8.25 (Secure development life cycle) and A.8.28 (Secure coding) are now explicitly in scope.
The 11 New Controls You Cannot Ignore
ISO 27001:2022 introduced 11 controls that did not exist in the 2013 standard. These are not retrofitted names for old concepts — they address specific modern risk areas:
- A.5.7 – Threat intelligence: Organisations should gather and analyse information about threats to stay ahead of them. This is a formal process, not just “keeping an eye on the news.”
- A.5.23 – Information security for use of cloud services: As cloud adoption has accelerated, so has the need to manage the associated risks explicitly.
- A.5.30 – ICT readiness for business continuity: Ensuring your technology infrastructure can support operations during disruptions.
- A.8.9 – Configuration management: Secure, documented baseline configurations for systems.
- A.8.10 – Information deletion: Ensuring data is securely deleted when no longer needed.
- A.8.11 – Data masking: Protecting sensitive data through masking techniques.
- A.8.12 – Data leakage prevention: Controlling how sensitive data moves across systems and networks.
- A.8.16 – Monitoring activities: Detecting anomalous behaviour across networks, systems, and applications.
- A.8.23 – Web filtering: Restricting access to external websites that pose security risks.
- A.8.28 – Secure coding: Applying secure coding principles throughout the development process.
- A.8.29 – Security testing in development and acceptance: Building security testing into the development pipeline.
Several of these have direct overlap with requirements emerging from the EU Cyber Resilience Act (CRA), which mandates security-by-design for products with digital elements. If your organisation manufactures or supplies software or connected hardware, ISO 27001:2022 now offers a framework that is genuinely useful as foundational evidence when demonstrating CRA readiness — particularly around A.8.25, A.8.28, and A.8.29.
The Statement of Applicability: Your Most Important Document
The SoA is where all of this comes together. It is a document that lists every Annex A control, states whether it is applicable or not applicable, provides a justification for that decision, and — for applicable controls — states whether it has been implemented.
A well-constructed SoA does three things at once: it demonstrates that your team has genuinely thought through every control, it creates a defensible audit trail for exclusion decisions, and it serves as a roadmap for your implementation team. A poorly constructed SoA — one that marks everything as applicable without justification, or excludes controls without explanation — is one of the first things a lead auditor will challenge.
Common Mistakes Organisations Make With Annex A
After working through ISO 27001 implementations across multiple sectors, certain patterns repeat:
Copy-pasting a generic SoA. Templates exist for a reason, but a template SoA that has not been tailored to your actual risk assessment is worse than useless — it creates an internal document that contradicts your actual control environment.
Confusing “we have a policy” with “we have a control.” A written policy is the start of a control, not the end. The control is evidenced by the policy, the training records, the implementation artefacts, and the monitoring data.
Treating the new controls as optional. The 11 new controls are not optional additions. If they are relevant to your context — and for most organisations, most of them are — they need to appear in your SoA with a reasoned applicability decision.
The Right Way to Approach This
Work from your risk assessment outward. Identify your assets, identify the threats and vulnerabilities that affect them, assess the likelihood and impact of those risks materialising, and then use Annex A as a checklist of controls that might address those risks. That sequence — risk first, controls second — is how ISO 27001 is designed to work.
If you are working backwards from Annex A (picking controls and hoping they map to risks), you have inverted the process. The result will be an ISMS that is difficult to audit and difficult to maintain.
At Bitsecura, we build your SoA from your risk assessment — not from a template. Every control decision is justified against your actual organisational context. Our certified Lead Implementers have built SoAs across a range of industries, and we know what auditors look for.
If you would like a straight conversation about where your Annex A currently stands — or where to start — get in touch with us here. No obligation, no pitch deck.
Bitsecura provides ISO 27001 implementation, internal audit, and ISMS maintenance services. Learn more about our ISO 27001 services.