Annex A is a catalogue of information security controls, not a checklist you must implement in full. That distinction is the one most misunderstood: the clauses of the standard are mandatory, Annex A is a reference set you compare your risk treatment against so nothing obvious is missed.
The 2022 restructure
The previous revision had 114 controls across 14 domains. The current one has 93 controls across 4 themes. Very little was removed - the reduction comes mostly from merging closely related controls rather than dropping requirements.
| Theme | Controls | Covers |
|---|---|---|
| A.5 Organisational | 37 | Policies, roles, supplier relationships, incident management, continuity, legal and compliance obligations |
| A.6 People | 8 | Screening, terms of employment, awareness, disciplinary process, remote working |
| A.7 Physical | 14 | Perimeters, entry, equipment siting, secure disposal, clear desk |
| A.8 Technological | 34 | Access, cryptography, logging, secure development, network security, malware, backups |
Each control also carries attributes - control type (preventive, detective, corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts aligned to identify/protect/detect/respond/recover, operational capabilities, and security domains. These are filtering aids, not requirements. Nobody has to use them, and no auditor will ask for them - but they are genuinely useful for producing a view of your control set by type or by NIST CSF function.
The eleven new controls
These are where existing certified organisations found gaps at transition:
- A.5.7 Threat intelligence - collecting and acting on information about threats. Frequently a genuine gap: many organisations consume feeds without any process for acting on them.
- A.5.23 Information security for use of cloud services - acquisition, use and exit. The exit part is the one usually missing.
- A.5.30 ICT readiness for business continuity - explicitly connecting continuity requirements to technology recovery.
- A.7.4 Physical security monitoring - detecting unauthorised physical access, not merely preventing it.
- A.8.9 Configuration management - baselines and control of configuration change.
- A.8.10 Information deletion - deleting data no longer required.
- A.8.11 Data masking - typically for non-production environments.
- A.8.12 Data leakage prevention.
- A.8.16 Monitoring activities - watching for anomalous behaviour, distinct from simply retaining logs.
- A.8.23 Web filtering.
- A.8.28 Secure coding.
The pattern is clear: the new controls reflect cloud adoption, detection rather than pure prevention, and software development practices. If you certified under the previous revision, these eleven are where your transition gap analysis should start.
See your position against all 93 controls
GRC Copilot scores you against Annex A control by control, holds the evidence for each, and generates the Statement of Applicability with justifications.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
How Annex A actually gets used
The sequence matters, and doing it backwards is the most common programme error:
- Assess risks against your scope.
- Decide the treatment for each risk, choosing controls that address it - from anywhere, not only from Annex A.
- Compare your chosen set against Annex A to confirm nothing necessary was overlooked. This comparison is the standard's actual requirement.
- Record the outcome in the Statement of Applicability: which controls apply, why, whether they are implemented, and a justification for each exclusion.
Starting from Annex A and working backwards produces a control set disconnected from your risks - which auditors detect quickly, because the SoA justifications read as generic rather than specific to the organisation.
Exclusions
You may exclude controls that are genuinely not applicable, with a documented reason. Common legitimate exclusions: no in-house software development, no physical data centre, no operational technology. What is not legitimate is excluding a control because it would be difficult or expensive - that is a risk acceptance, recorded as such, not an exclusion.
Expect exclusions to be tested. An organisation excluding secure development while running a public web application will be asked about it directly.
ISO 27002's role
Annex A gives you control titles and short statements. ISO 27002 is the companion guidance explaining purpose and implementation for each one, at considerably greater length. You do not have to buy it, but implementing from Annex A titles alone leaves a lot to interpretation - and where a control's intent is ambiguous, ISO 27002 is what your auditor is reading.
Frequently asked questions
Do we have to implement all 93 controls?
No. You implement what your risk assessment justifies, then compare against Annex A and document any exclusions with reasons in the Statement of Applicability.
How many controls do organisations typically apply?
Most apply the large majority. Genuine exclusions usually number in the single digits and cluster around development, physical infrastructure and operational technology.
Are the control attributes mandatory?
No - they are an optional aid for filtering and reporting. No auditor will require them, though they help produce management views of the control set.
Is Annex A the same as ISO 27002?
Annex A lists the controls; ISO 27002 explains how to implement each one. Same control set, very different depth.
Key takeaways
- 93 controls in 4 themes; the clauses are mandatory, Annex A is a completeness check.
- The 11 new controls target cloud, detection and secure development - start transition work there.
- Derive controls from risk, then compare to Annex A - not the reverse.
- Exclusions need genuine justification; "too expensive" is a risk acceptance instead.