ISO 27002,
the control catalogue explained

ISO/IEC 27002 is the international reference for information security controls. Where ISO/IEC 27001 tells you that an information security management system must select and operate controls, 27002 is the book those controls come from: for each one it gives a short control statement, the purpose it serves, and several paragraphs of guidance on how to implement it in practice. The current edition is ISO/IEC 27002:2022.

It is a code of practice, not a requirements standard. That is the single fact that shapes everything else. Nobody is certified against ISO 27002, no accredited body audits against it, and a customer who asks whether you are 27002 certified is really asking about your ISO/IEC 27001 scope. What 27002 gives you is depth: the difference between knowing you need a control for information deletion and knowing what a defensible deletion practice looks like.

In daily use it is the layer engineers and security leads actually open. The management clauses of ISO/IEC 27001 are read once and written into a manual; the control guidance in 27002 is read again every time a control is designed, reviewed, questioned by an auditor or explained to a new hire. If Annex A is the table of contents, 27002 is the book.

The 2022 edition was the first full rewrite in almost a decade, and the change is structural rather than cosmetic. The 2013 edition listed 114 controls across 14 domains, organized by topic such as access control or supplier relationships. The 2022 edition consolidates those into 93 controls in four themes, and adds an attribute table to every control so the same list can be viewed from several angles.

Fewer controls does not mean less coverage. Most of the reduction comes from merging controls that had drifted into near duplicates, and from renaming others to say what they actually mean. A team that mapped its practice to the 2013 set will find nearly everything still present, just filed differently, which is why the transition mostly meant re-mapping rather than re-implementing.

The more interesting change is what was added. Eleven controls are genuinely new, and together they read like a list of what security practice learned in the intervening years: cloud services, threat intelligence, data leakage and secure coding were barely visible in 2013 and are unavoidable now.

Every control in the 2022 edition sits in one of four themes. Organizational controls are the largest group at 37: policies, roles, supplier relationships, incident management, compliance and the other things that are decided rather than configured. People controls, eight in total, cover screening, terms of employment, awareness and training, disciplinary process and remote working. Physical controls, fourteen of them, cover perimeters, entry, equipment, cabling and clear desks. Technological controls, 34 in all, are where access, cryptography, logging, backups, network security and secure development live.

The themes replace the 2013 domains and are deliberately coarser. A domain like access control used to hold everything from policy to password management; in 2022 the policy piece sits under organizational controls and the technical enforcement under technological ones. It takes a little getting used to, but it maps more honestly onto who owns what: the organizational theme is usually the CISO and management, the technological theme is engineering and IT.

For a small team the practical value of the themes is prioritization. The technological theme is closest to the systems engineers already work in and tends to have the most evidence available automatically; the organizational theme is where policies and reviews have to be written and run. Knowing which theme a gap belongs to tells you who has to close it.

The quiet innovation of the 2022 edition is the attribute table on every control. Each control is tagged along five dimensions: control type (preventive, detective or corrective), the information security properties it protects (confidentiality, integrity, availability), the cybersecurity concept it serves (identify, protect, detect, respond, recover), the operational capability it belongs to (governance, asset management, identity and access management and so on), and the security domain (governance and ecosystem, protection, defence, resilience).

Attributes turn a flat list into something you can query. Want every detective control you run? Filter by control type. Need to show a board what covers availability? Filter by security property. The cybersecurity concepts are lifted directly from the NIST CSF functions, which is not an accident: it lets a team present the same control set to a US customer who thinks in NIST terms and to a European auditor who thinks in ISO terms without maintaining two lists.

Most teams ignore the attributes on first reading and come back to them later, when a second framework arrives or an auditor asks a cross-cutting question. Recording them from the start costs almost nothing, because the standard has already assigned them; it is a matter of keeping them next to the control in whatever system holds your control set.

The most common use is as the how-to layer behind an ISO/IEC 27001 Statement of Applicability. Annex A lists the controls; 27002 explains them. When you decide a control applies, the 27002 guidance is what you turn into a policy, a procedure or a technical configuration, and it is what you compare your implementation against when you ask whether it is good enough.

The second use is as a control catalogue in its own right. Teams that are not yet pursuing certification, or that need a structured baseline before deciding which framework to adopt, often take 27002 as the starting control set: it is comprehensive, vendor-neutral, and every control comes with enough guidance to implement without a consultant. Because Annex A is derived from it, that work carries straight into certification later.

The third use is translation. Because 27002 controls are well defined and widely referenced, other frameworks map onto them: SOC 2 criteria, NIST CSF subcategories, the NIS2 risk-management measures and the cloud extensions in ISO/IEC 27017 and 27018 all cross-reference the 27002 set. A team that maintains its controls at 27002 granularity can answer most of those frameworks from one place.

ISO/IEC 27001 is the obvious neighbour: its Annex A is the 27002 control list with the guidance removed, and the two editions are published together. ISO/IEC 27017 and 27018 are the cloud extensions, taking the 27002 controls and adding cloud-specific guidance and a few cloud-only controls; you cannot read either without 27002 underneath.

Beyond the ISO family the overlaps are looser but real. SOC 2 Trust Services Criteria cover most of the same ground from an attestation angle. NIST CSF organizes outcomes rather than controls, but the 2022 cybersecurity concepts were chosen to line up with its five original functions. The NIS2 Directive names ten risk-management measures that each correspond to a cluster of 27002 controls.

The practical consequence is that 27002 makes a good spine. Maintain one control set at that level of detail, record which control satisfies which requirement in each framework you adopt, and the evidence you keep for one serves the others. That is the difference between running four frameworks and running one control set with four views.

Organizations certified against ISO/IEC 27001:2013 had until the end of October 2025 to transition to the 2022 edition, which means moving their Statement of Applicability and control implementation onto the 93-control set. Most of that work is a mapping exercise: the standard itself includes a correspondence between old and new controls, and the merges are documented.

The eleven new controls are where the real effort sits. Each needs a decision on applicability, and where it applies, an implementation and evidence. Teams that had already adopted cloud security, threat intelligence or data loss prevention in practice mostly needed to write down what they were doing; teams that had not found the new controls to be genuine gaps.

A control catalogue is only useful while it matches reality. Controls get implemented, changed, partly retired or quietly replaced by a new tool, and the description in the policy drifts away from what actually runs. The 27002 guidance does not stop that drift; a review cadence does. Each control needs an owner, a review date and a place where the current evidence lives.

The teams that find 27002 easy are the ones that treat it as a living index rather than a document they read once. Keep the control set, the policies that implement it, the risks that justify it and the evidence that proves it in one place, and the catalogue becomes the map of your security programme instead of a standard on a shelf.