ISO 27002: The 93 Security Controls, Attributes and How to Use Them
ISO/IEC 27002 is the international reference set of information security controls with implementation guidance. Its 2022 edition reorganised the controls into 93 controls across four themes (organisational, people, physical and technological), added 11 new controls such as threat intelligence, secure coding and data masking, and introduced attributes for filtering controls by type, property and capability. It is not certifiable, but it is the guidance behind the Annex A controls of ISO/IEC 27001.
ISO 27002 (formally ISO/IEC 27002) is the companion to ISO/IEC 27001. Where ISO/IEC 27001 says what an information security management system must do and lists 93 controls in its Annex A in one or two lines each, ISO/IEC 27002 explains each of those controls: its purpose, how to implement it, and other information to consider. Auditors use it to judge whether a control is implemented sensibly; engineers use it to understand what "secure coding" or "monitoring activities" should mean in practice.
The 2022 edition was a major restructure: 114 controls in 14 clauses became 93 controls in four themes, 11 new controls were added, and attributes were introduced so that controls can be filtered by type, security property, cybersecurity concept, operational capability and security domain. This guide explains the structure, the controls that matter most for software and SaaS companies, how to use attributes, and how ISO/IEC 27002 relates to certification and other frameworks.
What is ISO/IEC 27002?
ISO/IEC 27002 provides a reference set of generic information security controls, including implementation guidance. It is designed to be used within an ISMS based on ISO/IEC 27001, for implementing controls based on recognised best practices, or for developing organisation-specific security guidelines. It applies to all types and sizes of organisations.
Each control has the same structure:
- Control title and a short control statement.
- Attributes table: values for each of the five attribute types.
- Purpose: why the control exists.
- Guidance: how the control can be implemented.
- Other information: related standards, legal considerations and further notes.
Because it uses "should" rather than "shall", it gives options rather than requirements. Your risk assessment decides how far to go.
History and why it exists
ISO/IEC 27002 descends from British Standard BS 7799 Part 1, a code of practice published in the 1990s. It was adopted internationally as ISO/IEC 17799 in 2000, renumbered ISO/IEC 27002 in 2007, and revised in 2013 alongside ISO/IEC 27001:2013. The third edition, published in February 2022, restructured the controls to reflect cloud computing, remote work, modern threats and the need to map controls to other frameworks. ISO/IEC 27001:2022 then replaced its Annex A with the 93 controls of ISO/IEC 27002:2022.
It exists because a management system needs concrete controls, and organisations, auditors and regulators benefit from a shared, detailed description of what good practice looks like for each.
Who uses ISO/IEC 27002?
- Organisations implementing or certified to ISO/IEC 27001, to design and justify Annex A controls.
- Security architects and engineers selecting and implementing controls.
- Internal and external auditors assessing controls.
- Organisations writing security policies, supplier requirements or contract schedules.
- Sector schemes that build on it, such as ISO/IEC 27017 for cloud services, ISO/IEC 27018 for PII in public clouds, and TISAX in the automotive industry.
It is global and voluntary. Some regulations and contracts refer to it as a benchmark for reasonable security.
The four themes and 93 controls
| Clause | Theme | Controls | Examples |
|---|---|---|---|
| 5 | Organisational controls | 37 | Policies for information security (5.1), roles and responsibilities (5.2), segregation of duties (5.3), threat intelligence (5.7), information security in project management (5.8), inventory of assets (5.9), acceptable use (5.10), classification (5.12), access control (5.15), identity management (5.16), authentication information (5.17), access rights (5.18), supplier relationships (5.19 to 5.22), use of cloud services (5.23), incident management (5.24 to 5.28), continuity and ICT readiness (5.29, 5.30), legal requirements (5.31), intellectual property (5.32), records (5.33), privacy and PII (5.34), independent review (5.35), compliance (5.36), documented operating procedures (5.37) |
| 6 | People controls | 8 | Screening (6.1), terms of employment (6.2), awareness and training (6.3), disciplinary process (6.4), responsibilities after termination (6.5), confidentiality agreements (6.6), remote working (6.7), event reporting (6.8) |
| 7 | Physical controls | 14 | Perimeters and entry (7.1, 7.2), offices and facilities (7.3), physical security monitoring (7.4), clear desk and screen (7.7), equipment siting and protection (7.8), off-premises assets (7.9), storage media (7.10), utilities (7.11), cabling (7.12), maintenance (7.13), secure disposal (7.14) |
| 8 | Technological controls | 34 | User endpoints (8.1), privileged access (8.2), information access restriction (8.3), source code access (8.4), secure authentication (8.5), capacity (8.6), malware (8.7), technical vulnerabilities (8.8), configuration management (8.9), information deletion (8.10), data masking (8.11), data leakage prevention (8.12), backup (8.13), redundancy (8.14), logging (8.15), monitoring (8.16), clock synchronisation (8.17), privileged utilities (8.18), software installation (8.19), network security (8.20 to 8.22), web filtering (8.23), cryptography (8.24), secure development life cycle (8.25), application security requirements (8.26), secure architecture (8.27), secure coding (8.28), security testing (8.29), outsourced development (8.30), separation of environments (8.31), change management (8.32), test information (8.33), audit testing protection (8.34) |
The 11 new controls in 2022
- 5.7 Threat intelligence: collect and analyse information about threats to produce intelligence that informs protection.
- 5.23 Information security for use of cloud services: processes for acquiring, using, managing and exiting cloud services.
- 5.30 ICT readiness for business continuity: plan, implement, maintain and test ICT readiness based on continuity objectives.
- 7.4 Physical security monitoring: continuously monitor premises for unauthorised access.
- 8.9 Configuration management: establish, document, implement, monitor and review configurations, including security configurations.
- 8.10 Information deletion: delete information when no longer required.
- 8.11 Data masking: mask data in line with access policies and business requirements, considering legislation.
- 8.12 Data leakage prevention: apply measures to systems, networks and devices that process sensitive information.
- 8.16 Monitoring activities: monitor networks, systems and applications for anomalous behaviour.
- 8.23 Web filtering: manage access to external websites to reduce exposure to malicious content.
- 8.28 Secure coding: apply secure coding principles to software development.
Many 2013 controls were merged rather than removed. For example, several separate access control, cryptography and supplier controls became single, broader controls.
Control attributes
The 2022 edition tags every control with values for five attribute types, which make it easier to filter, map and report on controls:
| Attribute | Values | Use |
|---|---|---|
| Control type | Preventive, detective, corrective | Check balance between preventing, detecting and correcting |
| Information security properties | Confidentiality, integrity, availability | Link controls to the properties your risks threaten |
| Cybersecurity concepts | Identify, protect, detect, respond, recover | Map to the NIST Cybersecurity Framework functions |
| Operational capabilities | Governance, asset management, information protection, human resource security, physical security, system and network security, application security, secure configuration, identity and access management, threat and vulnerability management, continuity, supplier relationships security, legal and compliance, information security event management, information security assurance | Assign controls to teams and capabilities |
| Security domains | Governance and ecosystem, protection, defence, resilience | Report at a strategic level |
Organisations can add their own attributes, such as owner, product or regulation, which is useful when one control set must serve ISO/IEC 27001, SOC 2 and a privacy law at once.
The controls that matter most for software and SaaS companies
Secure development (8.25 to 8.34)
These ten controls cover the secure development life cycle, security requirements, secure architecture and engineering principles, secure coding, security testing, outsourced development, separation of development, test and production environments, change management, protection of test information and protection of systems during audit testing. In practice: threat modelling for significant features, coding standards aligned with the OWASP Top 10, peer review, static and dynamic analysis, dependency scanning, masked or synthetic test data, and changes deployed through controlled pipelines.
Access and identity (5.15 to 5.18, 8.2 to 8.5)
Role-based access, unique identities, MFA, privileged access management, restricted source code access and regular access reviews, applied both to staff and to customers using your product.
Logging and monitoring (8.15, 8.16, 8.17)
Logs of user activities, exceptions, faults and security events, protected from tampering and reviewed; monitoring for anomalies; and synchronised clocks so events can be correlated.
Data protection (5.12, 5.34, 8.10 to 8.12, 8.24)
Classification, privacy and PII protection, deletion when no longer needed, masking in non-production and support tools, data leakage prevention and cryptography with managed keys.
Cloud and suppliers (5.19 to 5.23)
Security requirements in supplier agreements, monitoring of supplier services, and a defined process for selecting, using and exiting cloud services, including understanding the shared responsibility model.
Moving from the 2013 control set
Organisations that built their policies and risk registers on the 2013 edition need to re-map them. A few examples show how the restructuring works:
| 2013 controls | 2022 control | What changed |
|---|---|---|
| 5.1.1 and 5.1.2 (policies and their review) | 5.1 Policies for information security | Merged into one control covering the policy set and its review |
| 9.2.1 to 9.2.6 (user registration, provisioning, privileged rights, secret information, review, removal) | 5.16, 5.17, 5.18 and 8.2 | Regrouped into identity management, authentication information, access rights and privileged access |
| 12.4.1 to 12.4.4 (event logging, protection of logs, admin logs, clock sync) | 8.15 Logging and 8.17 Clock synchronisation | Logging controls merged; monitoring split out into the new 8.16 |
| 14.2.1, 14.2.5 and related development controls | 8.25 to 8.29 | Secure development reorganised, with secure coding added as its own control |
| 15.1.1 to 15.2.2 (supplier relationships) | 5.19 to 5.22 | Kept, with cloud services moved to the new 5.23 |
The standard includes correspondence tables in an annex that list each 2013 control and its 2022 equivalent. Use them to update policy references, risk register links and contract schedules, and then focus attention on the controls that are genuinely new.
Writing topic-specific policies
Control 5.1 expects an overall information security policy supported by topic-specific policies where needed. Keep each one short, owned and tied to controls. A typical set for a software company includes access control, asset management and acceptable use, cryptography and key management, secure development, backup and recovery, logging and monitoring, supplier and cloud security, incident management, remote working and data classification and handling. Each should say what is required, who is responsible and how compliance is checked, and should be reviewed at planned intervals or when something significant changes.
How to use ISO/IEC 27002 step by step
- Start from risk. Use your risk assessment (see ISO/IEC 27005) to decide which controls you need.
- Compare with all 93 controls and record decisions in the ISO/IEC 27001 Statement of Applicability.
- Read the purpose and guidance for each applicable control and decide how you will implement it in your context.
- Assign owners using operational capability attributes.
- Implement with evidence in mind: what record will show the control works?
- Map to other frameworks using attributes and published mappings, so one control serves several requirements.
- Review controls after incidents, audits and changes.
Documentation you will need
ISO/IEC 27002 itself mandates no documents, but implementing its controls normally produces:
- An information security policy and topic-specific policies (5.1), such as access control, cryptography, secure development, backup, supplier security and acceptable use.
- Documented operating procedures (5.37).
- Asset and information inventories (5.9) and classification scheme (5.12).
- Supplier agreements with security clauses (5.20).
- Incident management procedures and records (5.24 to 5.28).
- Records of access reviews, vulnerability management, backups, logging and changes.
Certification and audits
You cannot be certified to ISO/IEC 27002. Certification is to ISO/IEC 27001, whose Annex A lists the same 93 controls. Certification auditors often refer to ISO/IEC 27002 guidance when judging whether your implementation of a control is adequate, so aligning with it reduces audit friction. Organisations that are not seeking certification can still be assessed against ISO/IEC 27002 by internal audit or consultants.
Timeline and cost considerations
As a guidance document, ISO/IEC 27002 adds no fees beyond buying the standard. The cost lies in implementing the controls you select, which depends on your risk, size and starting point. Using attributes and mappings to reuse controls across frameworks is one of the most effective ways to keep cost down.
Benefits and the risk of ignoring it
ISO/IEC 27002 gives a well-tested, detailed description of good security practice that auditors, customers and partners recognise. It helps avoid two common failures: controls that exist in name only, and controls that are far heavier than the risk requires. Ignoring it rarely causes direct penalties, but it makes ISO/IEC 27001 audits harder and leaves gaps in areas such as secure development and supplier security that guidance would have flagged.
Common mistakes and challenges for IT companies
- Treating it as a checklist to implement in full rather than a menu chosen by risk.
- Still mapping to 2013 control numbers. Update policies, risk registers and contracts to the 2022 numbering.
- Thin implementation of new controls such as threat intelligence, configuration management and data masking.
- Applying controls to corporate IT only and not to the product customers use.
- No evidence plan for how each control will be shown to work.
Best practices, tools and technologies
- Use a GRC tool or structured spreadsheet with all 93 controls, attributes, owners, implementation notes and evidence links.
- Tag controls with the frameworks they satisfy, such as SOC 2 criteria and NIST CSF functions.
- Automate evidence for technological controls: identity provider reports, scan results, pipeline settings and log retention configuration.
- Use CIS Benchmarks for 8.9 configuration baselines and OWASP resources for 8.25 to 8.29.
- Review threat intelligence monthly and feed it into vulnerability management.
Our web application work covers many theme 8 controls directly, including secure coding, logging, access control and data masking.
How ISO/IEC 27002 relates to other frameworks
| Framework | Relationship |
|---|---|
| ISO/IEC 27001 | Annex A lists the same 93 controls; ISO/IEC 27002 explains them. |
| ISO/IEC 27017 | Cloud-specific guidance and additional controls built on ISO/IEC 27002. |
| ISO/IEC 27018 | Guidance for public cloud PII processors built on ISO/IEC 27002. |
| NIST SP 800-53 | A larger US control catalogue; mappings exist between the two. |
| CIS Controls | Prioritised technical safeguards that implement many ISO/IEC 27002 controls. |
| NIST CSF | The cybersecurity concepts attribute aligns controls with CSF functions. |
Real-world implementation examples
Organisations transitioning from the 2013 to the 2022 edition of ISO/IEC 27001 used ISO/IEC 27002's correspondence tables to map old controls to new ones, then focused effort on the 11 new controls. Many found existing practices already covered most of them, with gaps in formal threat intelligence, data masking in test environments and documented configuration management.
An illustrative case for a SaaS company: it tags each control with an operational capability and an owner. Engineering owns the 8.25 to 8.34 secure development controls and evidences them through repository settings, pipeline checks and test data policies; IT owns endpoint and identity controls; the compliance lead owns supplier and legal controls. A monthly report by capability shows leadership where controls are weak, and the same tags drive its SOC 2 mapping.
Next steps
- Get the 2022 edition and map your current controls to it using the correspondence tables in its annex.
- Prioritise the new controls and the secure development set if you build software.
- Add attributes and owners to your control register.
- Plan evidence for each control, preferring records produced automatically by your systems over screenshots.
- Use it with ISO/IEC 27001 if certification is your goal, and with ISO/IEC 27017 and 27018 if you provide cloud services.
Frequently asked questions
Can a company be certified to ISO 27002?
No. ISO/IEC 27002 is guidance. Certification is to ISO/IEC 27001, whose Annex A lists the same controls.
How many controls are in ISO 27002:2022?
Ninety-three, grouped into four themes: 37 organisational, 8 people, 14 physical and 34 technological.
What is the difference between ISO 27001 and ISO 27002?
ISO/IEC 27001 contains requirements for a management system and a short list of controls. ISO/IEC 27002 contains detailed guidance on implementing those controls.
What are the new controls in ISO 27002:2022?
Eleven: threat intelligence, information security for 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.
What are control attributes in ISO 27002?
Tags on each control for control type, security properties, cybersecurity concepts, operational capabilities and security domains, used to filter and map controls.
Do we have to implement all 93 controls?
No. You select controls based on risk and justify inclusions and exclusions in the ISO/IEC 27001 Statement of Applicability.
Is ISO 27002 useful without ISO 27001?
Yes. Organisations use it as a reference to design security programmes, write policies and set supplier requirements, even without seeking certification.
Which ISO 27002 controls cover secure software development?
Controls 8.25 to 8.34, covering the secure development life cycle, requirements, architecture, secure coding, testing, outsourced development, environment separation, change management and test data.
How does ISO 27002 map to NIST CSF?
Each control carries a cybersecurity concepts attribute (identify, protect, detect, respond, recover) that aligns it with CSF functions, and detailed mappings are available.
Is the 2013 edition still valid?
It has been withdrawn and replaced by the 2022 edition. Certifications to ISO/IEC 27001:2013 had to transition by 31 October 2025.
Where does privacy fit in ISO 27002?
Control 5.34 covers privacy and protection of PII. For a full privacy management system, use ISO/IEC 27701.
Official sources
- ISO/IEC 27002:2022 Information security controls (ISO)
- ISO/IEC 27001:2022 Information security management systems: Requirements (ISO)
- ISO/IEC JTC 1/SC 27 Information security, cybersecurity and privacy protection (ISO)
- NIST mappings between SP 800-53 and ISO/IEC 27001 (NIST)
- CIS Controls v8.1 (Center for Internet Security)
Review history
Last reviewed Oct 30, 2026. Next scheduled review Oct 30, 2027, or sooner if ISO publishes an amendment or new edition of ISO/IEC 27002.
- : First published, covering the 2022 edition.
This guide explains the official requirements in plain language. It is not legal advice and does not tell you whether your organisation is compliant. Confirm with qualified counsel, your auditor or an accredited certification body.