Use ISO 27001 when you need the certifiable ISMS baseline, the risk treatment framework, and the management system requirements. Use ISO 27002 when you need detailed guidance on selecting and implementing the controls that support that baseline. In practice, the two should be used together, with 27001 defining the requirement and 27002 informing the control design.
Why This Matters for Security Teams
Choosing between iso 27001 and ISO 27002 is less about picking a better standard and more about deciding whether the organisation needs certifiable governance or implementation guidance. ISO 27001 defines what an information security management system must achieve, while ISO 27002 explains how to apply control guidance in practice. That distinction matters when boards, auditors, and operational teams are asking different questions at the same time.
Security teams often make the mistake of treating ISO 27002 as a substitute for ISO 27001, or assuming certification alone proves control effectiveness. In reality, 27001 gives the management-system backbone, but 27002 is what helps translate risk decisions into usable safeguards for identities, access, logging, supplier oversight, and secrets handling. That is especially relevant in environments where non-human identities are multiplying faster than manual governance can keep up, as NHI Mgmt Group notes in the Ultimate Guide to NHIs.
For a practical baseline, many organisations also align their control mapping to the NIST Cybersecurity Framework 2.0 so they can compare governance outcomes across standards rather than treating ISO as a standalone exercise. In practice, teams discover the gap only when audit scope, control evidence, and operational ownership have already drifted apart.
How It Works in Practice
The cleanest way to decide is to start with the business objective. If the goal is to establish, maintain, and possibly certify an information security management system, ISO 27001 is the primary standard. If the goal is to design or improve the control set supporting that system, ISO 27002 is the companion reference. Current guidance suggests using 27001 for the management requirements and 27002 for the control selection and implementation detail.
In operational terms, that means the organisation should first define scope, risk context, leadership accountability, and evidence expectations under 27001. Then it should use 27002 to make control decisions concrete. For example, if the risk treatment plan calls for tighter identity governance, 27002 can help teams decide how to structure access control, logging, supplier controls, and cryptographic practices. This is useful when the control area includes NHI-heavy workflows, where secrets, API keys, and service accounts need clearer lifecycle discipline.
- Use ISO 27001 when you need a certifiable ISMS and a formal risk treatment process.
- Use ISO 27002 when you need control guidance that turns policy intent into implementable safeguards.
- Use both when assurance, auditability, and practical control design all matter.
- Map the resulting control set to other governance layers only after scope and ownership are clear.
For teams trying to operationalise this across identities and access, the Ultimate Guide to NHIs is useful because it frames why control design must account for lifecycle, visibility, rotation, and revocation, not just policy language. Where implementation detail matters most, 27002 is the better day-to-day reference, while 27001 remains the benchmark for management-system completeness. These controls tend to break down when organisations try to certify before they have a stable risk register, asset inventory, and evidence owner for each control.
Common Variations and Edge Cases
Tighter ISO scope often increases documentation and evidence overhead, so organisations need to balance certifiability against the cost of maintaining the management system. That tradeoff is especially visible when different business units want different levels of assurance or when one region needs formal certification while another only needs control guidance.
One common edge case is a company that wants “ISO compliant” without pursuing certification. In that situation, ISO 27002 may be the more useful working document, but current guidance suggests anchoring it back to 27001 so that the control set still maps to a coherent risk and governance model. Another edge case is supplier assurance, where one party asks for certification and another only wants evidence of strong controls. ISO 27001 can satisfy the first need; ISO 27002 can help explain the second.
For identity-heavy environments, the same split applies to NHI controls. If the organisation is struggling with API keys, service accounts, or secrets sprawl, it may need 27002’s practical control detail, but those controls should still sit inside a 27001-driven ISMS so ownership, review cadence, and exceptions are formally managed. The JetBrains GitHub plugin token exposure is a reminder that real control failure often comes from weak operational discipline rather than missing policy text.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | ISO choice depends on whether governance and outcomes are being formalized. |
| NIST CSF 2.0 | ID.IM-01 | ISO 27001 and 27002 are often chosen during continuous improvement and gap closure. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity-heavy environments need control guidance for secrets, service accounts, and revocation. |
Use gap assessments to decide if the organisation needs management-system requirements or control detail.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
