ISO/IECĀ 27002 is the commentary on Annex A of ISO/IECĀ 27001. Where Annex A names a control in a single sentence, ISO/IECĀ 27002 explains across several paragraphs what is meant, what purpose the control serves and what to watch out for when implementing it. For day-to-day ISMS work, ISO/IECĀ 27002 is therefore usually the document lying open on the desk.
Edition, the German version, and a common mix-up
The current edition is ISO/IECĀ 27002:2022, published 15 February 2022 as the third edition. In German it appeared with some delay, as DIN EN ISO/IECĀ 27002:2024-01, the German-language version of the European adoption EN ISO/IECĀ 27002:2022; it replaces DIN EN ISO/IECĀ 27002:2017-06.
Two things stand out. The length: 209 pages in the German edition of 27002 against roughly 31 for 27001; that is the difference between a list of controls and its explanation. And the amendment that is not here: "Amendment 1: Climate action changes", published in 2024, belongs to ISO/IECĀ 27001, not ISO/IECĀ 27002. At European level, 27002 has only a 2024 corrigendum. A substantively new "ISOĀ 27002:2024" does not exist.
No management system, no certification
ISO/IECĀ 27002 contains no requirements for a management system: no scope, no internal audits, no management review. An organisation therefore cannot be certified to ISO/IECĀ 27002. Offers claiming otherwise mean either certification to ISO/IECĀ 27001 or a personal certification.
The four themes
The 2022 edition consolidated the 114 controls of the previous edition into 93 controls and reorganised the structure from 14 sections into four themes.
| Clause | Theme | Count | Examples |
|---|---|---|---|
| 5 | Organisational controls | 37 | policies, roles, classification, supplier relationships |
| 6 | People controls | 8 | screening before employment, awareness, disciplinary process |
| 7 | Physical controls | 14 | secure areas, physical entry control, cabling, secure disposal |
| 8 | Technological controls | 34 | access rights, cryptography, logging, secure development |
Attributes as a second ordering principle
New is a system of attributes that allows the same 93 controls to be sorted in different ways: by control type (preventive, detective, corrective), by information security property (confidentiality, integrity, availability), by cybersecurity concept (identify, protect, detect, respond, recover), by operational capability and by security domain. This is practically useful above all for cutting responsibilities: assigning all technological and detective controls to security operations, for instance.
The eleven new controls in the 2022 edition
Eleven controls were added to catch up with the state of the art:
- 5.7: source and assess information on current attack techniques and actors, and let it shape the defences rather than sit in a feed.
- 5.23: rules for choosing, using and leaving cloud services, including where the provider's responsibility ends and yours begins.
- 5.30: make the IT side capable of meeting the recovery targets the business has set, not merely of restoring a backup.
- 7.4: watch premises continuously for unauthorised entry instead of relying on granted access rights alone.
- 8.9: define secure configurations for hardware, software, services and networks, record them, and check for drift.
- 8.10: delete information once it is no longer needed, in systems, in backups and on media.
- 8.11: obscure personal or otherwise sensitive data wherever the real values are not required, typically in test and analysis environments.
- 8.12: detect and stop the unauthorised extraction of information.
- 8.16: monitor networks, systems and applications for anomalous behaviour, and settle in advance what happens on a hit.
- 8.23: control access to external web content to limit exposure to malicious material.
- 8.28: build secure coding principles into the development process rather than into a review at the end.
Experience shows these are the most frequent gaps when moving up from the 2013 edition, simply because they did not appear in older frameworks at all.
How to use the standard in practice
ISO/IECĀ 27002 is a reference, not an implementation plan. The sensible order is: assess risks, derive controls, then look up in ISO/IECĀ 27002 how the control in question is meant, and write your own rule from that. The text of the standard is deliberately generic and has to be translated to your own organisation: wording copied verbatim is worthless in an audit if it does not describe actual operations.
The standard is also useful outside a certification. Anyone looking simply for a structured catalogue of controls will find in ISO/IECĀ 27002 a complete, internationally agreed reference, without having to build a management system.
How the guidance becomes executable work
ISO/IECĀ 27002 describes controls and how to implement them. The step to executable work is missing from every guidance document, and it is where the real effort sits. In Rizzqo the standard is held as a requirement catalogue. A requirement is deliberately not the same as one of the 93 controls but the executable unit derived from a control, carrying implementation guidance and a note on how to evidence it, and one control can produce several.
Requirements are dispatched by the object's classification. A site picks up different ones from a SaaS application, a provider different ones again. Answering happens on the object, with a reason and evidence, and the finalisation carries a name and a timestamp. Guidance organised in four themes thereby becomes a work list per system rather than one shared spreadsheet for everything.