CyphrQ
Menu

ISO/IEC 27002:2022 Explained: The Security Controls Guide

ISO/IEC 27002:2022 is guidance on security controls, not a certificate. How it relates to 27001 Annex A, its themes and attributes, and how to use it.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

9 min read

ISO/IEC 27002:2022 is a guidance standard, not a certificate. It describes a reference set of information security controls and how to implement them. You use it inside an information security management system built on ISO/IEC 27001, which is the standard an auditor can certify. Think of 27001 as the rulebook for running the programme and 27002 as the handbook for the controls.

What is ISO/IEC 27002:2022?

ISO/IEC 27002:2022 is titled "Information security, cybersecurity and privacy protection - Information security controls". ISO and the IEC publish it jointly, and the official page is the ISO catalogue entry for the standard. The edition details below come from the listing on the Bahrain national standards portal. It shows the standard as current, approved on 15 February 2022, 152 pages long. Its abstract says the standard gives a reference set of generic information security controls with implementation guidance. It names three uses: within an ISMS based on ISO/IEC 27001, to implement controls based on recognised good practice, and to write an organisation's own security guidelines.

An ISMS, or information security management system, is the set of policies, roles, risk checks and routines an organisation uses to manage security consistently. The standard text is paid and copyrighted, so everything below is in my own words.

What does ISO/IEC 27002 cover?

It covers the controls an organisation might use to manage information security risk, across the whole organisation rather than one technology. A control here means any measure that reduces risk: a policy, a process, a technical setting or a physical safeguard.

For each control the standard explains the purpose and how to put it into practice. It deliberately stays generic, so it fits a ten-person firm and a bank. It tells you what good looks like, not which product to buy.

The 2022 edition arranges the controls under four themes, which are also its main clauses 5 to 8:

Theme Clause What it deals with
Organizational 5 Policies, roles, supplier relationships, incident management, legal and contractual duties
People 6 Screening, awareness, responsibilities when people join, move or leave
Physical 7 Premises, equipment, secure areas
Technological 8 Access, cryptography, logging, network and application security

The clause numbers and theme names are as Schellman, an audit firm, lists them. The "what it deals with" column is my summary.

How are ISO/IEC 27002 controls tagged with attributes?

Each control also carries attributes. These are labels that let you sort the same controls in different ways, such as "show me every detective control" or "show me everything that protects availability".

Schellman lists five attribute types and their values:

  • Control type: preventive, detective or corrective, meaning whether a control acts before, during or after an event.
  • Information security properties: confidentiality, integrity, availability.
  • Cybersecurity concepts: identify, protect, detect, respond, recover. Schellman says this draws on the framework in ISO/IEC TS 27110.
  • Operational capabilities: practitioner-oriented groupings such as governance and asset management. The list is not exhaustive.
  • Security domains: governance and ecosystem, protection, defence, resilience.

Attributes are not requirements. Schellman's author describes them as tools to consider during risk assessment and risk treatment, and notes you can create your own values. That matches how I would use them: as filters for reporting, not a checklist to satisfy.

Who uses ISO/IEC 27002, and can you be certified against it?

Anyone building or reviewing a security programme can use it: IT managers choosing controls, consultants writing policies, auditors checking that a control is implemented sensibly, and buyers who want a common vocabulary with suppliers.

You cannot rely on it for a certificate. The Bahrain listing describes it as guidance used within a 27001 ISMS, and I found no certification scheme for 27002 itself. What an accredited body certifies is the management system under ISO/IEC 27001. ISO's own 27001 committee page says certification is optional, and that an accredited certification body adds confidence because an accreditation body has confirmed its competence.

A practical consequence: if a supplier says it is "ISO 27002 certified", ask what it actually holds. The accurate claim is "certified to ISO/IEC 27001:2022", with the scope and the certification body named. A supplier may legitimately say it follows 27002 guidance, but that is a self-statement, not an independent result.

How does ISO/IEC 27002 relate to ISO/IEC 27001 Annex A?

ISO/IEC 27001 requires you to assess your risks, decide which controls treat them, and compare your choices against a reference list of controls in its Annex A. In the 2022 edition, Kiwa, a certification body, reports that Annex A was reduced from 114 controls in 14 sections to 93 controls, grouped as:

Annex A section (2022) Controls
A.5 Organizational 37
A.6 People (Kiwa: "Personnel") 8
A.7 Physical 14
A.8 Technological (Kiwa: "Technical") 34

Kiwa adds that the implementation guide was revised alongside it, naming ISO 27002:2022. The four-theme structure matches 27002's clauses 5 to 8, which is the link between the two documents: Annex A is the short list your ISMS refers to, and 27002 is where each item is explained.

In short: 27001 says that you must choose and justify controls. 27002 helps you decide what a given control means and how to implement it. For how the certification itself works, read the ISO/IEC 27001 explainer rather than repeating it here.

Two other relationships are worth one line each. SOC 2 is an auditor's report against AICPA criteria, and 27002 is a common source of control ideas for either. ISO/IEC 42001 is the management-system standard for AI, and it sits beside this one, not under it.

How do you adopt ISO/IEC 27002 in practice?

There is no audit of 27002 on its own, so adoption means using it as a reference while you build or refine an ISMS. A sensible sequence:

  1. Define scope. Which systems, teams, sites and suppliers are covered.
  2. Assess your risks. List what could go wrong for the information in scope.
  3. Select controls. Read the relevant themes and decide which controls treat each risk.
  4. Use the guidance to implement. Turn each selected control into a written rule, a setting or a routine with an owner.
  5. Record your decisions. Say which Annex A controls you apply, which you do not, and why.
  6. Test and keep evidence. Collect proof the control works, then review it on a schedule.

Work through the themes against your risks rather than reading every control in order. Some will not apply, and a documented reason for leaving one out is acceptable.

Going deeper: for security and IT teams

Statement of Applicability (SoA). In a 27001 programme, the SoA lists the Annex A controls you apply, whether each is implemented, and the reasoning for any exclusion. Use 27002 as the source of the wording you check against. Auditors expect the SoA to trace back to your risk treatment, so each line should point to a risk, an owner and a piece of evidence. A control that appears in the SoA with no owner is a common finding.

Attributes as a reporting layer. Build your control register with extra columns for the five attribute types. Filtering by control type shows how balanced you are: a register that is almost all preventive controls with little detective capability will struggle to spot a breach already under way. Filtering by the cybersecurity concepts (identify, protect, detect, respond, recover) gives you a quick check against ISO/IEC TS 27110's categories. The attribute values are as Schellman lists them. Because attributes are optional, you can add your own columns, for instance a column for regulation or customer commitment.

Evidence an auditor asks for. For each selected control, expect to be asked for the policy or procedure, who owns it, how it is communicated, and proof it operated. Typical proof is a configuration export, a ticket, a log extract, a training record or a review sign-off. Keep it dated. For technological controls, evidence is usually a screenshot or export of a setting plus an example of it working. For people controls it is records of screening and awareness, and for physical controls, access lists and visit records.

Common nonconformities, described generally.

  • Controls selected in the SoA but never implemented in practice.
  • Risk assessment and control selection that do not connect, so exclusions have no reasoning.
  • Policies that exist but are not owned, reviewed or communicated.
  • Evidence gathered once before the audit instead of continuously.
  • Supplier controls assumed, not checked.

Mapping to other frameworks. Keep one control register and map each entry to its Annex A reference, to any SOC 2 criteria you also need, and to legal duties such as the NIS2 Directive. The control is written and tested once, and each framework is a view of it. That is cheaper than running separate programmes. Mappings between standards are never exact, so treat each as "supports" rather than "satisfies".

Edition and transition. Kiwa reports that ISO/IEC 27001:2022 was published on 25 October 2022, with a three-year transition, and that certificates against the 2013 edition expired on 31 October 2025. That date has passed, so a certificate that cites 27001:2013 is out of date. If you inherit a control set built on the 2013 edition (Kiwa says the old Annex A had 114 controls in 14 sections), re-map it to the four themes instead of editing the old numbering. Confirm audit timings with your certification body.

Questions to ask.

  • Which edition of 27001 and 27002 is the SoA based on?
  • Are the control owners named and aware of them?
  • How do we know each control worked this quarter, not only that it exists?
  • Which controls did we exclude, and who approved the reason?
  • What changes in our systems or suppliers would trigger a review of the control set?

What this post does not cover: the standard text is paid and was not checked here, so individual control numbers and titles are not listed. Check those in your licensed copy.

Learn more

  • SGS ISO/IEC 27002:2022 training course: a one-day classroom or virtual course on the 2022 revision, from a certification body, aimed at people who already know the 2013 edition. Its certificate is one of attendance, not a professional qualification.

Key takeaways

  • ISO/IEC 27002:2022 is guidance on information security controls. You use it within a 27001 ISMS, and you cannot be certified to it on its own.
  • Its controls sit under four themes (organizational, people, physical, technological) and carry five optional attribute types for sorting them.
  • ISO/IEC 27001:2022 Annex A lists 93 controls across the same four themes, according to Kiwa. 27002 explains how to implement them.
  • If a supplier claims "ISO 27002 certification", ask for the ISO/IEC 27001:2022 certificate, its scope and the certification body.
  • Use attributes and one control register to report on your controls and map them to other frameworks, and keep dated evidence that each control works.
  • For more standards, see the ISO Standards subtopic.

Sources