ISO/IEC 27002 is the international code of practice for information security controls: a guidance standard that describes a reference set of controls, states the purpose of each one and explains how to implement it. Among cybersecurity security standards, it is the companion of ISO 27001, which defines the certifiable management system, while ISO 27002 supplies the detailed implementation guidance behind each control listed in Annex A of ISO 27001.
The current edition, ISO/IEC 27002:2022, is titled “Information security, cybersecurity and privacy protection: Information security controls”. It is often shortened to ISO 27002. Organizations use it to select controls, justify them in a risk treatment plan and write internal policies, but nobody can be certified against ISO 27002 itself.
How ISO/IEC 27002 relates to ISO 27001
ISO/IEC 27002 is the guidance half of a two-document pair. ISO 27001 contains the requirements, written with “shall”, for an information security management system (ISMS), and its Annex A lists the controls only as one-sentence statements. ISO 27002 repeats the same controls with the same numbering and adds the purpose, the guidance and further notes, written with “should”.
The two documents are revised together, so the control numbers stay aligned: control 5.7 Threat intelligence in Annex A corresponds to section 5.7 in ISO 27002. An auditor checks the ISO 27001 requirements, while an implementer reads ISO 27002 to understand what a reasonable control looks like in practice. The table below separates their roles.
| Aspect | ISO 27001 | ISO/IEC 27002 |
|---|---|---|
| Nature | Requirements standard | Guidance standard |
| Wording | Shall (mandatory) | Should (recommended) |
| Certification | Possible through accredited bodies | Not possible |
| Control content | One-line control statements in Annex A | Purpose, guidance and other information |
| Main reader | Auditors and ISMS owners | Implementers and control owners |
Structure of the 2022 control set
The 2022 edition contains 93 controls grouped into four themes, replacing the 114 controls in 14 clauses of the 2013 edition. The reduction came mostly from merging overlapping controls, while 11 controls were added to cover risks that had grown since 2013. Each control has a fixed layout: a control statement, a purpose, guidance and other information.
| Clause and theme | Number of controls | Typical examples |
|---|---|---|
| 5 Organizational controls | 37 | Policies, roles, supplier relationships, incident management |
| 6 People controls | 8 | Screening, awareness training, remote working |
| 7 Physical controls | 14 | Secure areas, equipment siting, clear desk |
| 8 Technological controls | 34 | Access rights, logging, malware protection, backup |
The new controls reflect modern threats and practices. They include threat intelligence, information security for the use of cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering and secure coding.
Control attributes and how they are used
The 2022 edition introduced five control attributes, hashtag-style labels that let an organization sort and filter the same controls from different viewpoints. Attributes do not change what a control requires; they make it easier to map controls to other frameworks, build dashboards and explain coverage to management.
| Attribute | Possible values | Practical use |
|---|---|---|
| Control type | Preventive, detective, corrective | Checking the balance of prevention and detection |
| Information security properties | Confidentiality, integrity, availability | Linking controls to risk impact |
| Cybersecurity concepts | Identify, protect, detect, respond, recover | Mapping to the NIST CSF functions |
| Operational capabilities | Fifteen values, such as asset management and identity and access management | Assigning control owners |
| Security domains | Governance and ecosystem, protection, defense, resilience | Reporting to executives |
Organizations may also define their own attributes, for example a regulation tag or a business unit. This flexibility makes the catalog usable as a single control library for several compliance obligations.
ISO/IEC 27002 compared with other control frameworks
ISO/IEC 27002 is one of several control catalogs used in security governance, and the differences lie in depth, prescriptiveness and audience. It is deliberately technology-neutral and risk-based: it does not prescribe password lengths or encryption algorithms but asks the organization to decide them through its risk assessment.
| Framework | Scope and style | Key difference from ISO/IEC 27002 |
|---|---|---|
| NIST SP 800-53 | Over 1,000 controls and enhancements with baselines | Far more granular, built for US federal systems |
| CIS Controls | 18 prioritized technical safeguards | Prescriptive and ordered by implementation group |
| NIST CSF | Outcome-oriented functions and categories | Describes outcomes, not control guidance |
| SOC 2 | Attestation report on trust services criteria | An audit report, not a control catalog |
| ISO/IEC 27701 | Privacy extension of the ISMS | Adds privacy controls on top of ISO 27002 |
Sector standards extend the core catalog. ISO/IEC 27017 adds cloud-specific guidance, ISO/IEC 27018 covers personal data in public clouds, and ISO/IEC 27019 addresses the energy sector. Each of them refers back to ISO 27002 controls and adds or modifies guidance instead of starting from zero.
Applying the code of practice in an organization
ISO/IEC 27002 is applied through risk-based selection, not by implementing every control. The organization identifies its risks, chooses controls to treat them and records the decision in a Statement of Applicability, which lists each control as included or excluded with a justification. The guidance text then shapes the actual policies and procedures.
- Define the ISMS scope and perform a risk assessment.
- Select controls from the catalog and add any custom controls the risks require.
- Use the ISO 27002 guidance to write policies, standards and procedures.
- Assign control owners and measure effectiveness with defined metrics.
- Review controls after incidents, audits and major changes.
Organizations moving from the 2013 edition had to map old controls to new ones. The transition period for ISO 27001 certificates based on the old Annex A ended in October 2025, so current certifications refer to the 2022 control set.
Common misunderstandings and pitfalls
The most frequent errors come from treating the code of practice as a compliance checklist rather than as guidance for risk treatment. The table summarizes typical problems and their remedies.
| Mistake | Consequence | Better approach |
|---|---|---|
| Claiming ISO 27002 certification | Misleading statements to customers | Certify the ISMS against ISO 27001 |
| Implementing all 93 controls blindly | Wasted effort on irrelevant risks | Select controls from the risk assessment |
| Copying guidance text into policies | Generic documents nobody follows | Adapt guidance to real processes |
| Treating the catalog as complete | Gaps for sector-specific threats | Add controls from sector extensions |
| Ignoring control effectiveness | Controls exist only on paper | Define metrics and test regularly |
Another pitfall is assuming that guidance equals minimum requirements. Some guidance points will not fit a small company, and the standard explicitly allows them to be adapted, provided the decision is documented and risk-justified.
The short version
ISO/IEC 27002 is like a detailed cookbook for protecting information. Its sister standard, ISO 27001, says that a company must run a proper security kitchen and lists the dishes it may choose to cook. ISO 27002 gives the recipe for each dish: why it matters and how to prepare it well.
A company does not have to cook every recipe. It picks the ones that fit its own risks. The key point is simple: ISO 27002 explains how to do security well, but certificates are issued only for ISO 27001.
Where it makes a difference
A mid-sized software company with about 200 employees wants ISO 27001 certification because enterprise customers demand it. Its risk assessment shows that the biggest risks are leaked customer data in test environments and insecure code reaching production.
The security team selects controls 8.11 data masking and 8.28 secure coding, among others, and uses the ISO 27002 guidance to write a rule that production data must be masked before it is copied to test systems, plus a secure coding standard with mandatory code review. It tags each control with attributes so that the same library also produces a NIST CSF coverage view for a US customer.
During the certification audit, the auditor sees controls traced from risk to procedure to evidence. The company passes without major nonconformities, and the attribute tags let it answer customer security questionnaires much faster than before.