ISO 27001, 27002 and 27003: what each standard does

At a glance

What this is: This is a comparison of ISO 27001, ISO 27002, and ISO 27003, with the key finding that only ISO 27001 is certifiable while the other two support control selection and ISMS implementation.

Why it matters: It matters because IAM and security teams often treat standards as interchangeable, when in practice certification, control design, and implementation planning are separate governance jobs that affect access control, auditability, and compliance scope.

By the numbers:

• 114 security controls divided into 14 control sets
• Cyber incidents are among the top risks for businesses in 2022

👉 Read StrongDM's guide to ISO 27001, 27002, and 27003 differences

Context

ISO 27001, ISO 27002, and ISO 27003 are often discussed together, but they do different governance work. ISO 27001 defines the certifiable information security management system, ISO 27002 expands the control guidance behind it, and ISO 27003 helps teams plan how to implement the system in practice.

For IAM, PAM, and NHI programmes, that distinction matters because policy, control design, and implementation planning are not the same thing. A team can have access controls, audit logs, and secrets handling in place and still lack a coherent ISMS that ties those controls to risk treatment and certification scope.

Key questions

Q: How should organisations decide when to use ISO 27001 versus ISO 27002?

A: 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.

Q: Why do access control and audit logging matter so much in ISO compliance programmes?

A: Because they are among the clearest ways to show that security policy is operating as a managed system rather than a paper exercise. Access control proves who can do what, and audit logging proves whether those decisions are visible, reviewable, and tied back to risk treatment. Without both, certification evidence becomes thin and hard to defend.

Q: What breaks when teams treat ISO 27002 as a certification standard?

A: Teams misread guidance as proof of compliance and confuse implementation detail with certification evidence. ISO 27002 explains how controls can work, but it does not replace the requirements of ISO 27001. The result is often a control-heavy programme that still lacks the structure needed for an auditable ISMS.

Q: How do ISO 27001, 27002, and 27003 fit together in an ISMS rollout?

A: ISO 27001 defines the requirements, ISO 27002 expands the control guidance, and ISO 27003 helps plan the implementation effort. A practical rollout uses 27003 to organise the project, 27001 to define the target state, and 27002 to shape control selection and execution. That separation keeps the programme from becoming a documentation-only exercise.

Technical breakdown

ISO 27001 certification and the ISMS baseline

ISO 27001 is the foundation standard in the ISO 27000 family because it defines the requirements for an information security management system, or ISMS. An ISMS is not a tool or checklist. It is the documented management system that ties risk assessment, risk treatment, controls, monitoring, and continual improvement together. In practice, ISO 27001 tells organisations what they must be able to demonstrate for certification, not just what security controls they should own.

Practical implication: map your IAM, PAM, and NHI controls to ISO 27001 requirements before treating them as compliance evidence.

ISO 27002 control guidance for access control and operations security

ISO 27002 supports ISO 27001 by explaining how to select and implement controls from Annex A in more detail. That makes it the working guide for control design, especially in areas like access control, cryptography, operations security, supplier relationships, and incident management. For identity teams, the value is in translating broad control intent into practical control behaviour, such as how access is approved, monitored, and reviewed.

Practical implication: use ISO 27002 when turning policy into control implementation details, especially for access governance and audit logging.

ISO 27003 implementation planning for an ISMS

ISO 27003 focuses on how to plan and design an ISMS from the ground up. It covers the implementation project itself, including management approval, scope definition, and planning activities. It does not add new requirements. Instead, it helps teams sequence the work needed to operationalise ISO 27001, which is why it is most useful early in a programme rather than after certification work is already underway.

Practical implication: use ISO 27003 to structure the ISMS rollout plan before control ownership and evidence collection begin.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ISO 27001, 27002, and 27003 are often confused because teams collapse certification, control guidance, and implementation planning into one governance problem. That collapse creates weak programme design. ISO 27001 is the certifiable baseline, ISO 27002 is the control guidance layer, and ISO 27003 is the implementation planning layer. The implication is that security leaders must separate evidence of compliance from the mechanics of control operation.

Access control is only one part of ISO compliance, but it is the part most likely to expose gaps in IAM and NHI governance. StrongDM's article correctly points to segregation of duties, JIT, secrets storage, and audit logs as supporting capabilities. The deeper point is that ISO-style governance depends on whether those controls can be shown to operate consistently across users, workloads, and infrastructure access paths. Practitioner conclusion: do not certify a policy model that cannot be demonstrated in operations.

Control selection under ISO 27002 should be driven by risk treatment, not by the convenience of the control catalogue. That matters because 114 controls across 14 groups can create false completeness if teams treat the standard as a menu. The stronger governance model is to identify which access, logging, supplier, and incident controls actually reduce the organisation's stated risks. Practitioner conclusion: use the standard to narrow decisions, not to justify broad but shallow coverage.

Control evidence debt: organisations accumulate compliance risk when access decisions exist in tooling but cannot be linked back to the ISMS requirement they are meant to satisfy. This is where identity programmes often drift from governance into isolated operational practice. The practical conclusion is to connect control evidence, review cadence, and ownership into the ISMS itself so audits are proving a managed system rather than a collection of controls.

ISO 27003 matters because implementation plans fail when teams assume policy writing equals programme design. The standard exists to help teams sequence scope, sponsorship, and project structure before controls are deployed. That makes it a useful bridge between executive approval and operational execution. Practitioner conclusion: treat ISO 27003 as the design phase for governance, not as documentation after the fact.

From our research:

• ISO 27001 Annex A includes 114 security controls divided into 14 control sets, according to 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• For broader control mapping, see Top 10 NHI Issues for the access and governance patterns that most often break down in practice.

What this signals

ISO 27001 programmes increasingly have to prove that identity controls are not only documented but operationally traceable across users, workloads, and infrastructure. Control evidence debt: teams that cannot connect access decisions, review records, and audit logs to the ISMS will struggle to turn policy into defensible assurance.

The compliance conversation is shifting from control ownership to control demonstrability. For IAM and PAM teams, that means evidence design, review cadence, and access logging need to be treated as programme artefacts, not audit afterthoughts. The wider the infrastructure footprint, the more important it becomes to anchor the programme in a shared lifecycle model such as the NHI Lifecycle Management Guide.

Where organisations are already mapping identity controls to governance frameworks, the next step is to align those controls with formal risk treatment and review processes. The NIST Cybersecurity Framework 2.0 remains a useful external reference for tying protect, detect, and respond activities back to assurance goals.

For practitioners

• Separate certification scope from control guidance Document which activities sit under ISO 27001 certification, which are supported by ISO 27002 guidance, and which belong in the ISO 27003 implementation plan. This prevents teams from using control detail as a substitute for a managed ISMS scope.
• Map access governance to Annex A controls Link identity approvals, privileged access workflows, secrets handling, and audit logging to the relevant Annex A controls so evidence can be traced from policy to operation.
• Use the implementation plan to sequence ownership Assign explicit owners for risk assessment, control design, evidence collection, and review cadence before the programme reaches audit readiness.
• Test whether controls are demonstrable, not just documented Verify that access decisions, review records, and incident logs can be produced on demand and tied to the ISMS requirements they support.

Key takeaways

• ISO 27001 is the certifiable ISMS standard, while ISO 27002 and ISO 27003 provide supporting guidance for controls and implementation planning.
• Identity teams should treat access control, audit logging, and evidence traceability as part of the ISMS, not as disconnected security chores.
• A compliant programme depends on separating what the standard requires, what the controls do, and how the implementation is sequenced.

Key terms

• Information Security Management System: An ISMS is the documented management system an organisation uses to govern information security risk. It brings policy, control selection, operating procedures, monitoring, and continual improvement into one structure so security can be managed and evidenced rather than handled as isolated tasks.
• Annex A Controls: Annex A is the control catalogue associated with ISO 27001. It gives organisations a structured list of security controls that can be selected and adapted according to risk, helping teams turn broad governance requirements into concrete technical and administrative safeguards.
• Control Evidence: Control evidence is the artefact that shows a control is not just documented but actually operating. In identity programmes this can include approval records, access logs, review outcomes, and configuration history, all of which must be traceable back to the ISMS requirement they support.

Deepen your knowledge

ISO 27001 certification planning, access governance, and audit evidence are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning identity controls to an ISMS for the first time, it is worth exploring.

This post draws on content published by StrongDM: ISO 27001 vs. 27002 vs. 27003: What’s the Difference? Read the original.