By NHI Mgmt Group Editorial TeamBased on Zluri: “ISO 27001 vs 27002: 5 Key Differences” (June 26, 2025)

TL;DR: ISO 27001 defines the requirements for an information security management system, while ISO 27002 provides implementation guidance for the controls, including access control and periodic review, according to Zluri. For IAM and governance teams, the practical distinction is between proving the system exists and showing the controls work consistently.


At a glance

What this is: This is an analysis of how ISO 27001 and ISO 27002 differ, with access reviews used as the practical example for IAM teams deciding how to evidence control effectiveness.

Why it matters: It matters because identity teams often confuse management-system requirements with control guidance, and that confusion weakens audit evidence, review cadence, and the governance of access rights across human and non-human accounts.

By the numbers:

  • ISO 27001 Annex A contains 114 controls divided into 14 categories.

Context

ISO 27001 and ISO 27002 are often treated as interchangeable, but they solve different governance problems. ISO 27001 defines the requirements for an information security management system, while ISO 27002 provides the implementation guidance for the controls that sit underneath it, including access control and periodic review.

For IAM teams, the distinction matters because access reviews are not just a control activity. They are evidence that governance is operating, that permissions are being assessed against risk, and that the organisation can show how access decisions are made and recorded within a broader ISMS.

The article frames access review as the bridge between standards and execution. That makes it useful for teams responsible for identity governance, certification workflows, and audit readiness across employees, service accounts, and other non-human identities.


Key questions

Q: How should IAM teams use ISO 27001 and ISO 27002 together?

A: Use ISO 27001 to define the management system, risk scope, and accountability model, then use ISO 27002 to implement the controls that support those decisions. IAM teams should treat the first as governance architecture and the second as the operating guide for access control, review, and evidence collection.

Q: When do access reviews satisfy ISO expectations instead of just creating paperwork?

A: They satisfy the standard when they are linked to risk, target the right access populations, and produce evidence that access changed where it should have. A review that cannot show what was challenged, approved, or revoked is governance theatre, not control assurance.

Q: Why do periodic access reviews leave organisations exposed?

A: Periodic reviews are snapshots, not continuous control. They assume access state remains stable long enough to be certified later, which is often untrue in SaaS-heavy and hybrid environments. By the time a review identifies stale access, the entitlement may already have created risk, lateral movement opportunity, or compliance exposure. The delay is the problem.

Q: What should teams do when ISO 27002 guidance and business risk seem to point in different directions?

A: Use ISO 27001’s risk-based management requirement to decide how much of the guidance is appropriate for the environment. ISO 27002 informs the implementation pattern, but it does not override the organisation’s risk assessment or the need to scope controls sensibly.


Technical breakdown

ISO 27001 versus ISO 27002 in access governance

ISO 27001 is the management standard. It specifies what an organisation must establish, operate, maintain, and improve in an information security management system, including risk assessment and control selection. ISO 27002 is the guidance standard. It explains how controls from Annex A are typically implemented in practice, but it does not replace the requirement to decide which controls are relevant. For access reviews, that means 27001 is about governance obligation and 27002 is about implementation detail.

Practical implication: use ISO 27001 to justify the governance model and ISO 27002 to design the control workflow.

Why access reviews need risk-based scope

Access reviews only work when the review population is tied to risk. ISO 27001 requires organisations to determine which controls are necessary and how far they should be applied, based on assessed information security risks. ISO 27002 gives guidance on the control, but not the scoping decision. In practice, that means a meaningful certification process must focus on privileged access, sensitive applications, and accounts that can materially affect confidentiality, integrity, or availability.

Practical implication: scope review cycles by risk tier, not by every application on the same cadence.

How documentation turns reviews into audit evidence

Periodic review is not just an operational habit. It becomes auditable only when the organisation can show who reviewed what, what was challenged, what was removed, and when the decision was recorded. The article emphasises documentation because certification depends on proof, not intent. For identity governance teams, the control value is in traceable review artefacts that demonstrate the review happened and led to an actual access decision.

Practical implication: retain review logs, approval trails, and revocation records as evidence of control operation.


NHI Mgmt Group analysis

Access reviews are evidence controls, not just administrative tasks: The article correctly separates the standard that defines the management system from the standard that explains how to operate controls. For identity teams, that distinction matters because an access review only becomes governance evidence when it is repeatable, scoped, and recorded. The practitioner conclusion is simple: treat certification as proof of control operation, not a checkbox exercise.

Risk-based scoping is the real dividing line between policy and practice: ISO 27001 requires organisations to decide which controls are necessary in context, while ISO 27002 describes how to apply them. That means access reviews must be tied to business risk, privilege level, and data sensitivity rather than run as a uniform calendar event. The practitioner conclusion is to align review depth with exposure.

Review traceability is the named control gap this article exposes: The article makes clear that access control only satisfies the standard when the organisation can show what was reviewed and what changed. Without documented outcomes, periodic review becomes an assertion instead of evidence. The practitioner conclusion is to make traceability the core output of every certification cycle.

ISO 27001 and ISO 27002 together define the governance stack for access rights: One standard establishes the management requirements, the other explains the operational control. That structure is still the right model for IAM programmes, but only if teams resist the temptation to treat implementation guidance as a substitute for governance. The practitioner conclusion is to keep control design and management accountability distinct.

Access review programmes should be judged by control effect, not review volume: The article implies that periodic review is valuable because it identifies unnecessary access and triggers changes. A high-volume review process that leaves permissions untouched does not strengthen the ISMS. The practitioner conclusion is to measure how often reviews actually remove or reduce access, not how many rows were processed.

From our research library:

What this signals

Access review programmes fail when they are treated as evidence production rather than governance decisions: The standards distinction in this article is the useful one for practitioners. ISO 27001 answers what must exist in the management system, while ISO 27002 helps define how the review control is carried out. Teams that blur the two often end up with process volume instead of risk reduction.

Certification quality should be measured by access change, not completion rate: The control only matters if the review cycle removes unnecessary privilege, especially for high-risk accounts and sensitive applications. If nothing changes after the review, the programme is probably confirming access rather than governing it.


For practitioners

  • Define the ISMS scope before building review workflows Map which business units, applications, and identity types fall inside the information security management system before choosing review cadence or reviewer groups.
  • Separate control selection from control guidance Use ISO 27001 to decide which controls are required and ISO 27002 to define how those controls should be operated in practice.
  • Risk-rank access reviews by sensitivity and privilege Prioritise privileged accounts, high-impact SaaS applications, and access that can affect sensitive data or production workflows.
  • Capture review outcomes as audit evidence Record who reviewed the access, what was approved or revoked, and when the decision was completed so the review can be evidenced later.
  • Test whether review cycles change access decisions Track how many certifications result in revocation, reduction, or escalation rather than only counting completed review tasks.

Key takeaways

  • ISO 27001 and ISO 27002 play different roles, and IAM teams need both the management-system view and the control-implementation view to make access reviews meaningful.
  • The article’s central operational point is that periodic access review only matters when it is risk-based, documented, and able to produce real access changes.
  • For governance teams, the useful test is whether review evidence can stand up in audit and whether the process actually reduces unnecessary access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
ISO/IEC 27001:2022A.5.15 — Access ControlThe article centres on access review governance inside an ISMS.
A.8.2 — Privileged Access RightsAccess reviews are most sensitive where privileged rights must be justified and reviewed.
Recommendation — Use A.5.15 to align access review scope, approval, and evidence with ISMS requirements. Apply A.8.2 to prioritise review of privileged access and revoke rights that are no longer justified.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article’s access review focus maps directly to entitlement governance.
Recommendation — Apply PR.AA-05 to review entitlements regularly and remove access that no longer fits the role or risk.
CIS Controls v8CIS-5 — Account ManagementPeriodic access review is a core account management discipline.
Recommendation — Use CIS-5 to verify account ownership, review access, and remove stale or excessive permissions.

Key terms

  • Information Security Management System: An information security management system is the operating structure an organisation uses to manage security policies, controls, responsibilities, and evidence. Under ISO 27001, it is the framework auditors assess, but its real strength depends on whether access, logging, and remediation work consistently in practice.
  • Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
  • 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.
  • Certification Evidence: Certification evidence is the documentation used to prove that required controls are actually operating. For cybersecurity regulations, that usually includes access reviews, exception approvals, inventory records, incident logs, and configuration proof retained long enough to support executive sign-off.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org