Join our Newsletter — 33% off our NHI Course

What is the difference between Stage 1 and Stage 2 in an ISO 27001 audit?

Stage 1 is primarily a documentation review. Auditors check whether the organisation has the required policies, risk assessment, Statement of Applicability, and implementation plan. Stage 2 is an operational test. Auditors then examine whether the controls actually function, whether staff know their responsibilities, and whether incidents produce the expected response across the ISMS.

How Stage 1 and Stage 2 differ in an ISO 27001 audit

Stage 1 is the readiness check, Stage 2 is the effectiveness check. In practice, that means the first stage verifies whether the ISMS is defined, documented, and internally coherent, while the second stage tests whether people, processes, and controls operate as written under real conditions. The distinction matters because a strong document set does not prove operational security.

Stage 1 typically focuses on the scope statement, risk treatment logic, Statement of Applicability, internal audit records, management review, and the implementation plan. Auditors are looking for evidence that the organisation has built a defensible management system and that the core control choices are traceable to risk. The audit standard itself is set out in ISO/IEC 27001:2022 Information Security Management, with implementation detail commonly cross-checked against ISO/IEC 27002:2022 Information Security Controls.

Stage 2 moves from documented intent to observed execution. Auditors sample how controls actually work, whether responsibilities are understood, whether incidents are handled consistently, and whether logs, approvals, exceptions, and follow-up actions show a living ISMS rather than a static binder. If Stage 1 answers “Is the system designed properly?”, Stage 2 answers “Does the system behave properly when pressure, exceptions, and normal business activity occur?”

What auditors are really testing at each stage

Stage 1 is less about proving every control and more about checking that the organisation has a credible management framework in place. Auditors will usually look for missing or inconsistent documents, weak scope decisions, unclear risk methodology, or a Statement of Applicability that does not match the business model. A common failure mode is treating Stage 1 as a paperwork exercise and discovering too late that the documented control set does not reflect actual operations.

Stage 2 is evidence-led and sample-based. Auditors ask for operating records, not just policies, and they expect the organisation to demonstrate that monitoring, access decisions, incident response, and corrective actions are happening in practice. This is where teams often uncover that an approved control exists on paper but is not followed consistently, or that evidence cannot be produced quickly enough to prove routine operation.

  • Stage 1 evidence is usually documentary: policies, procedures, risk treatment decisions, and governance records.
  • Stage 2 evidence is usually operational: tickets, logs, approvals, interview responses, incident records, and control outputs.
  • Stage 1 can identify gaps before certification, but Stage 2 is where those gaps become audit findings if the control is not demonstrably working.

For organisations that already manage access governance, the logic is similar to a broader compliance review such as Ultimate Guide to NHIs, Regulatory and Audit Perspectives: documentation establishes accountability, but operational proof establishes trust.

Risk and Threat Considerations

The main risk in this audit split is false confidence. Teams can pass Stage 1 with strong documentation and still fail Stage 2 because the controls are not actually embedded, not consistently performed, or not evidenced well enough to satisfy the auditor. In audit terms, the threat is not only nonconformance, but also the control gap between declared process and real behaviour.

Failure mechanism: Policies, risk assessments, and control descriptions are approved, but control owners cannot show repeatable execution, timely incident handling, or consistent responsibility awareness during sampling and interviews.

Impact: The organisation may receive nonconformities, delayed certification, remediation work, or a finding that the ISMS is designed but not operating effectively, which undermines assurance to customers, regulators, and internal stakeholders.

Standards & Framework Alignment

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

ISO/IEC 27001:2022 provides the primary governance reference for this topic.

Framework Control / Reference Relevance
ISO/IEC 27001:2022 4-10 — Improvement Stage 1 and Stage 2 both assess whether the ISMS is established and improved over time.
5-12 — Information Security Risk Management Stage 1 checks whether risk treatment and SoA choices are grounded in risk decisions.
9-2 — Internal Audit The audit stages depend on whether internal audit evidence demonstrates operational readiness.
Recommendation — Show evidence that ISMS issues are tracked to corrective action and ongoing improvement. Document risk treatment decisions and keep them traceable to the selected controls. Maintain internal audit results that demonstrate the ISMS is being tested before certification.

Practitioner Guidance

What to verify: Before Stage 1, make sure the scope, risk treatment plan, and Statement of Applicability all point to the same operating reality. Before Stage 2, verify that you can produce evidence for a representative sample of controls without reconstructing records after the fact.

Common mistake: Treating Stage 1 as a design review and Stage 2 as a formality. In practice, the fastest way to fail Stage 2 is to rely on manual explanations for controls that should have routine, dated evidence such as approvals, monitoring outputs, and incident records.

What good looks like: An auditor can trace a risk to a selected control, see that the control is owned, observe that staff understand their responsibilities, and confirm that incidents or exceptions trigger the expected workflow consistently.

Practitioner takeaway: Use Stage 1 to prove that your ISMS is coherent, and use Stage 2 to prove that it is real; the organisations that succeed usually close evidence gaps before the audit, not during it.