Annex A is the part of ISO/IECĀ 27001 that gets quoted most often and misread most often. It is not a mandatory list of controls to work through but a reference set against which your own, self-determined controls are compared. That role follows directly from the way clause 6 is built.
Four themes, 93 controls
| Clause | Theme | Count | Subject matter |
|---|---|---|---|
| 5 | Organisational | 37 | policies, roles, classification, supplier relationships, incident handling, compliance |
| 6 | People | 8 | screening, terms of employment, awareness, disciplinary process, termination |
| 7 | Physical | 14 | secure areas, entry control, equipment, cabling, disposal, the working environment |
| 8 | Technological | 34 | access rights, cryptography, logging, network security, development, data leakage |
The structure comes from the 2022 edition. Previously there were 114 controls in 14 sections; after merging and reordering, 93 remain, eleven of them newly added. One point deserves stressing: the count is not a metric. A single 2022 control can bundle several earlier ones, and the implementation effort has not fallen as a result.
In substance, the eleven new controls close gaps that opened up between 2013 and 2022: threat intelligence, the use of cloud services, information security continuity during a disruption, monitoring of physical premises, configuration management and secure deletion, data masking, protection against data leakage, monitoring and logging activity, web content filtering, and secure development. Coming from the 2013 edition, this is typically where the actual work sits; the rest of the transition is mostly remapping.
What Annex A actually says
Annex A is deliberately terse: for each control, essentially a number, a title and a short statement of what the control requires. Purpose, implementation guidance and the attributes are not there; they are in ISO/IECĀ 27002. Work from Annex A alone and you have the catalogue but not the interpretation. Conversely, ISO/IECĀ 27002 does not replace the annex, because certification is against ISO/IECĀ 27001.
A cross-check, not a starting point
The order the standard prescribes is unambiguous. First, the necessary controls are determined from the risk treatment. Only then are they compared with Annex A to establish whether a necessary control has been overlooked. The comparison may show that nothing is missing. If it shows that something is, the risk treatment plan is extended and the control implemented.
The comparison has three outcomes, not two
In practice the Statement of Applicability gets run as a yes/no list: applicable or excluded. But the comparison the standard describes has three outcomes, and the middle one is the one that decides the quality of the system.
| Outcome of the comparison | What follows | What the SoA states |
|---|---|---|
| The control is already covered by a control you derived yourself | nothing further; your own control stays the operative one | applicable, referencing your own control, not the catalogue text |
| The control is necessary but was not derived | the risk treatment plan is extended and the control implemented | applicable, with implementation open or closed |
| The control has no use case in your scope | no implementation | excluded, with a justification that carries |
The middle case is the actual point of the annex. A system in which it never occurs either has an exceptionally complete risk treatment, or the cross-check never happened and was written up afterwards as confirmation.
The widespread alternative, working down the 93 controls from top to bottom, produces a system that cannot be justified in an audit. Asked why a control is designed one way rather than another, you have no answer beyond pointing at the catalogue.
Exclusions and how to justify them
Not every control applies to every organisation. An exclusion is permitted, but it has to be justified in the Statement of Applicability, and the justification has to carry the exclusion. The difference comes down to one question: does the justification rest on a fact about the scope, or on a decision the organisation made?
| Justification | Does it hold up? | Why |
|---|---|---|
| No in-house software development; applications are exclusively bought in | yes | a fact about the scope, checkable in an audit against contracts and the org chart |
| No data centre space of your own; operation sits entirely with a provider | yes | a fact; make sure the corresponding requirements on the provider sit elsewhere |
| The category of data in question is not processed | yes | a fact, evidenced through the record of processing activities and data classification |
| The control is disproportionate for our size | no | proportionality shapes how a control is designed, not whether it applies |
| Implementation is planned for next financial year | no | that is an open implementation, not an exclusion, and an audit will read it as a contradiction between the SoA and the plan |
| Resources and budget are not available | no | a decision by the organisation, not a feature of the scope |
The bottom three rows routinely produce a finding in an audit, because the Statement of Applicability then says something different from the risk treatment plan. Check both documents against each other before the audit; this is the contradiction most easily found.
Numbering and mapping
Controls are labelled theme.number, so 5.19 in the organisational theme and 8.16 in the technological one. The 2022 numbers do not match those of the previous edition. Anyone still using older material (customer questionnaires, audit reports, internal policies with references) needs a mapping table between the old and the new numbering. It is drudgery, but it prevents the most common follow-on error: two numbering schemes sitting side by side in one document with nobody able to say which edition is meant.
Your own controls are expressly allowed
The standard does not require every control to come from Annex A. Sector-specific requirements, contractually promised measures or controls of your own belong in the Statement of Applicability too. Annex A does not cap the control set from above; it secures it from below.
How Annex A gets misused
- The catalogue is used as a project plan, and the risk assessment is written afterwards to justify it.
- All 93 controls are declared applicable to avoid discussion. That creates evidence obligations nobody can service.
- Implementation status is maintained in the Statement of Applicability, but the link back to the risk is not.
- Annex A and ISO/IECĀ 27002 are conflated, and implementation guidance from the guidance standard is treated as a normative requirement.
Why there is no usable full-text list
The most searched-for form of this topic is the list: all 93 controls as a table, ideally downloadable. That expectation cannot be served responsibly. Annex A is part of a standard you have to pay for; the control texts are copyrighted, and reproducing them in full is not a permissible source, and it is a risk for whoever publishes it, and for whoever works from it, because such copies routinely carry translation errors and the 2013 numbering.
The workable route instead: obtain the standard itself from a standards body and build your own Statement of Applicability around it, stating, for each control, your own wording rather than the standard's text. That is the better working basis anyway, because an audit does not examine the catalogue text; it examines what the organisation made of it. For interpretation, ISO/IECĀ 27002 is the authoritative source. For the move from 2013 to 2022, take the mapping between old and new numbering from the edition of the standard you purchased rather than trusting a copy in circulation.
How controls, risks and evidence can be linked together with tool support is described on our ISOĀ 27001 page.
How the catalogue becomes work in Rizzqo
A reference catalogue describes controls, not tasks. The step in between decides whether 93 entries turn into a programme or a spreadsheet. In Rizzqo, ISO/IECĀ 27002 is held as a requirement catalogue, and a requirement is deliberately not the same as a control but the executable unit derived from a control, carrying implementation guidance and a note on how to evidence it. One control can produce several.
Dispatch happens through classification. An object picks up the requirements held for its category and subcategory, and if the classification changes the list adjusts. The applicability question is therefore not answered once centrally but per object, with a reason and evidence in the same place.