A warning before the checklist: walking through the 93 Annex A controls certifies nobody. Certification is granted against clauses 4 to 10 of ISO 27001 — the Annex A controls come in as a verification reference, applied according to the risk you identified. A checklist is useful as a map, not as a route.
The four-theme structure
The 2022 revision replaced the 14 sections of the 2013 version with four themes:
| Theme | Controls | What it covers |
|---|---|---|
| A.5 — Organisational | 37 | Policies, roles, suppliers, continuity, compliance, information classification |
| A.6 — People | 8 | Screening, terms of employment, awareness, disciplinary process, remote working |
| A.7 — Physical | 14 | Perimeter, entry control, equipment, media, secure disposal |
| A.8 — Technological | 34 | Access, cryptography, logging, networks, secure development, vulnerability management |
The eleven controls new in 2022
If you are migrating from an ISMS built on the 2013 version, these are the ones with no prior equivalent — and, in practice, the ones that generate the most non-conformities in transition audits:
- Threat intelligence — collect and analyse threat information and turn it into action.
- Information security for use of cloud services — criteria for selecting, using and exiting providers.
- ICT readiness for business continuity — continuity stops being a plan on paper.
- Physical security monitoring — detection of unauthorised physical access.
- Configuration management — baseline configurations defined, applied and verified.
- Information deletion — delete what no longer needs to exist, with proof.
- Data masking — limit exposure of sensitive data in non-production environments.
- Data leakage prevention — controls over information leaving the organisation.
- Monitoring activities — monitor networks and systems for anomalous behaviour.
- Web filtering — restrict access to malicious external websites.
- Secure coding — secure development principles applied across the lifecycle.
The Statement of Applicability is the central document
The SoA is where the checklist becomes a commitment. For each of the 93 controls it must record four things:
- Whether the control applies to the scope
- The justification for including it — or excluding it
- Whether it is implemented, and to what degree
- A reference to the evidence proving it
Excluding controls is allowed and, in many scopes, correct. What is not accepted is excluding without justification tied to the risk assessment. "Not applicable because we don't have it" is usually rejected; "not applicable because the scope does not cover software development, per scope item 2" is accepted.
What counts as evidence
This is where most projects discover they are behind. Auditors work with three kinds of proof, in ascending order of weight:
- Document — the policy exists, is approved and is dated.
- Record — the activity happened: minutes, logs, tickets, signed reports.
- Demonstration — the control works now, verified in front of the auditor.
A policy with no record of application is worth little. An access management control with an immaculate procedure and no access review recorded in the last twelve months is a non-conformity, not an observation.
How to use this checklist without fooling yourself
The sequence that works is the opposite of the intuitive one. Do not start with the controls: start with the scope, run the risk assessment, and only then use Annex A to check whether the treatment you chose is covered. Walking through the 93 controls before knowing what you protect produces an ISMS that is expensive to maintain and does not reduce the risk that matters.