ISO/IEC 27002.

What ISO/IEC 27002 actually is

ISO/IEC 27002 is the implementation guidance that sits beside ISO 27001. Where ISO 27001 is the certifiable management system standard that lists the Annex A controls and requires you to justify which ones apply, ISO 27002 explains each of those controls in depth: its purpose, what good looks like, and the practical considerations of putting it into operation. It is a code of practice, not a checklist of requirements. You do not certify against ISO 27002 and an auditor cannot issue a non-conformity against it directly. They use it to interpret the spirit of an Annex A control and to challenge whether your implementation is genuinely fit for purpose.

That distinction matters in real audits. A surface review asks whether a control is "in place". An auditor reaching for ISO 27002 asks how you operate it: whether the access review actually happens on the cadence you claim, whether your logging captures the events that would let you detect an incident, whether your supplier clauses survive contact with a real breach. The standard gives both sides a shared vocabulary for that conversation, which is why practitioners treat it as the operational playbook rather than supporting reading.

How it relates to ISO 27001, the SoA and the ISMS

The three documents form a chain. Your ISMS is the management system that runs the whole programme. ISO 27001 defines what that system must do and supplies the control set. The Statement of Applicability (SoA) records, control by control, which you have included, which you have excluded and why. ISO 27002 is where you turn for the substance of each control once the SoA tells you it applies. In practice, teams write the SoA with ISO 27001 open for the requirement and ISO 27002 open for the implementation guidance, then design the actual control against the guidance.

Modern editions of ISO 27002 organise the controls into four themes, organisational, people, physical and technological, and tag each one with attributes such as control type, the security property it protects and the relevant cybersecurity concept. Those attributes let you slice the control set in different ways, for example pulling every preventive control or every control that supports detection, which helps when you are mapping to other frameworks or building a risk treatment plan.

What practitioners actually do with it

In a working programme ISO 27002 shows up in a few recurring tasks:

1. Designing controls: when the SoA marks a control as applicable, the implementation guidance shapes the policy, procedure or technical configuration you build.
2. Justifying decisions: when you tailor or scope a control, the guidance gives you the rationale to record so an auditor can follow your reasoning.
3. Preparing for audit: teams use the guidance to pressure-test their own controls before the assessor does, closing the gap between "documented" and "operating effectively".
4. Mapping frameworks: the control structure and attributes make ISO 27002 a useful spine for cross-walking to control sets like the CIS Controls or NIST guidance.

Because ISO 27002 is guidance rather than a strict requirement, the judgement sits with you. The standard describes intent and good practice; you decide how far to go based on your risk assessment. That freedom is the point. It lets a small consultancy and a multinational both claim conformity to the same control while implementing it at very different depths, each appropriate to its risk.