For an ISO 27001 stage 2 audit, the core documentation required includes your Statement of Applicability, information security policies, risk assessment and treatment records, internal audit results, management review minutes, and evidence of operational controls in practice. Together, these documents demonstrate that your Information Security Management System is not only designed correctly but is actively functioning within your organisation. The sections below unpack each of these requirements in detail, including the common pitfalls that lead to nonconformities and how to keep your documentation in good shape after certification. If you have questions about your specific situation, feel free to get in touch with us and we will be happy to help.

Which documents do auditors actually review in a stage 2 audit?

In a stage 2 audit, auditors review a defined set of mandatory documents alongside any additional records your organisation has committed to maintaining. The mandatory items include your information security policy, scope statement, risk assessment methodology, risk treatment plan, Statement of Applicability, internal audit programme and results, management review records, and documented evidence of nonconformity and corrective action. These are the non-negotiables under ISO 27001:2022.

Beyond the mandatory list, auditors will also examine the documented information you have chosen to maintain to demonstrate control effectiveness. This includes operational procedures, supplier agreements, access control records, incident logs, and training records. The standard does not prescribe the exact format for most of these, but it does require that they exist, are controlled, and reflect what your organisation actually does rather than an idealised version of it.

A common misunderstanding is that a thick policy binder constitutes sufficient documentation. Auditors are looking for coherence across documents, not volume. Your scope statement must align with your risk register, which must align with your Statement of Applicability, which must align with the controls you can demonstrate in practice. Gaps between these layers are exactly what a stage 2 audit is designed to surface.

What is the Statement of Applicability and why do auditors prioritise it?

The Statement of Applicability, commonly called the SoA, is a document that lists all 93 controls from Annex A of ISO 27001:2022 and records whether each control is applicable to your organisation, whether it has been implemented, and the justification for any exclusions. Auditors treat it as the central reference point for the entire audit because it connects your risk treatment decisions to your actual control environment.

Auditors prioritise the SoA because it is the document most likely to reveal misalignment. If a control is marked as implemented in the SoA but no evidence of implementation exists, that is a nonconformity. If a control has been excluded without a documented justification, that is another finding. The SoA effectively acts as a promise your organisation has made to itself and to the certification body, and the stage 2 audit tests whether that promise has been kept.

A well-constructed SoA goes beyond a simple checklist. It references the specific risks or requirements that led to each inclusion decision, links controls to the relevant policies or procedures that govern them, and is reviewed and updated as your risk environment changes. Organisations that treat the SoA as a living document rather than a one-time deliverable consistently perform better in stage 2 audits and in subsequent surveillance audits.

What evidence of operational controls is required beyond written policies?

Written policies alone are not sufficient for a stage 2 audit. Auditors require objective evidence that controls are operating as described. This means records, logs, configurations, completed forms, and other artefacts that demonstrate the control has been applied in practice, not just documented in theory.

The specific evidence varies by control type, but common examples include:

  • Access control: user provisioning and de-provisioning logs, access review records, privileged account inventories
  • Asset management: an up-to-date asset register with ownership assigned
  • Supplier management: signed information security clauses in contracts, records of supplier assessments
  • Incident management: a log of security events and incidents, including how each was handled and closed
  • Training and awareness: attendance records, completion certificates, or assessment results
  • Change management: change request records with approvals and post-implementation reviews
  • Vulnerability management: scan results, remediation tracking, and evidence of timely action

Auditors often conduct interviews alongside document review to verify that staff actually understand and follow the controls described in your policies. A disconnect between what the policy says and what an employee describes during interview is a reliable indicator of a documentation-versus-reality gap, which is one of the most frequent sources of nonconformities at stage 2.

How complete does the risk register need to be for stage 2?

Your risk register needs to be sufficiently complete to demonstrate that you have systematically identified, assessed, and treated information security risks relevant to your scope. It does not need to be exhaustive to the point of listing every conceivable threat, but it must reflect a credible and methodical process applied across your organisation’s assets, processes, and context.

At a minimum, each entry in the risk register should include the risk description, the affected asset or process, the likelihood and impact assessment using your defined methodology, the risk owner, the treatment decision (accept, mitigate, transfer, or avoid), and a reference to the controls or actions selected to address it. The treatment decisions must be traceable back to your Statement of Applicability.

Auditors will look for evidence that the risk assessment has been reviewed and updated, not just completed once during the implementation phase. A risk register that has not been updated since initial certification preparation is a red flag. It suggests that risk management is being treated as a documentation exercise rather than an ongoing governance process. Dates of review, records of who conducted the review, and evidence that new or changed risks have been incorporated are all important signals of a functioning risk management programme.

What causes documentation nonconformities in ISO 27001 stage 2 audits?

The most common causes of documentation nonconformities in ISO 27001 stage 2 audits are inconsistencies between documents, evidence that does not match stated controls, outdated records, and missing mandatory documented information. These failures typically do not reflect a lack of effort but rather a lack of ongoing governance discipline in maintaining the ISMS after the initial implementation push.

Inconsistency across the documentation set

When the scope statement, risk register, SoA, and operational procedures do not tell a consistent story, auditors raise findings. A common example is a control listed as implemented in the SoA with no corresponding procedure, or a risk identified in the register with no treatment action visible anywhere in the documentation. Cross-document coherence is a discipline that requires deliberate review, not just good intentions at the time of writing.

Evidence gaps for operational controls

Organisations frequently document controls thoroughly but fail to generate or retain the records that prove those controls are operating. If your patch management policy says critical vulnerabilities must be remediated within 30 days but you have no records showing that this has happened, the policy provides no audit value. The evidence gap is the nonconformity, not the absence of a policy.

Stale or unreviewed documentation

Documents that carry a review date from two or three years ago, or that reference systems, roles, or processes that no longer exist, signal to auditors that governance has drifted. Version control, review schedules, and document ownership are basic hygiene requirements that many organisations underinvest in after the initial certification sprint.

How should governance documentation be maintained after certification?

After ISO 27001 certification, governance documentation must be maintained as a continuous operational activity, not revisited only when a surveillance audit approaches. Certification bodies conduct annual surveillance audits and a full recertification audit at the end of the three-year cycle, and each of these assessments expects to see documented evidence of ongoing management, not a documentation refresh completed in the weeks before the audit date.

Effective post-certification maintenance involves several interconnected practices. Document owners should be assigned for every key policy and procedure, with defined review frequencies. The risk register should be reviewed at least annually and whenever significant changes occur to the organisation, its technology, or its threat environment. Management reviews must be conducted at planned intervals and properly minuted, covering ISMS performance, audit results, and any changes that affect the system.

Internal audits are another critical maintenance mechanism. An internal audit programme that runs throughout the year, rather than as a single annual event, provides the continuous assurance that surveillance auditors expect to see. Findings from internal audits should flow into a corrective action process with tracked closure, creating a documented improvement loop that demonstrates the ISMS is genuinely active.

This is where continuous governance makes a measurable difference. Organisations that embed governance into their operational rhythm rather than treating it as a periodic project consistently find that stage 2 audits and subsequent surveillance assessments are far less stressful and far more successful. Our governance services are designed around exactly this model, providing the ongoing expert support that keeps documentation accurate, coherent, and audit-ready across the full 36-month certification cycle.

Maintaining ISO 27001 documentation after certification is not a documentation problem. It is a governance discipline problem. Organisations that solve it structurally, by assigning ownership, scheduling reviews, and integrating governance into day-to-day operations, are the ones that pass stage 2 audits with confidence and sustain certification without crisis. If you would like to discuss how to build that discipline into your organisation, contact us and we will help you find the right approach.

Frequently Asked Questions

How far in advance should we have our documentation ready before a stage 2 audit?

Ideally, your full documentation set should be in its final, reviewed state at least four to six weeks before the stage 2 audit date. This buffer gives you time to conduct a pre-audit internal review, identify any gaps or inconsistencies, and close them before the certification body arrives. Rushing documentation into shape in the final days before an audit is one of the most reliable predictors of nonconformities, because last-minute changes rarely have the supporting evidence trail that auditors expect to see.

Can we exclude controls from our Statement of Applicability, and how do we justify exclusions?

Yes, controls can be excluded from your SoA, but every exclusion must be supported by a documented justification that demonstrates the control is genuinely not applicable to your organisation's context and risk profile. Acceptable justifications typically include the absence of the relevant asset, process, or risk that the control is designed to address. Exclusions that appear to be motivated by implementation difficulty rather than genuine inapplicability are a common source of auditor scrutiny, so your justifications need to be grounded in your risk assessment, not in convenience.

What happens if a nonconformity is raised during the stage 2 audit — does it mean we fail certification?

Not necessarily. Minor nonconformities typically allow the certification process to continue, provided your organisation submits an acceptable corrective action plan within an agreed timeframe, usually 30 to 90 days depending on the certification body. Major nonconformities, which indicate a significant failure of the ISMS to meet a clause requirement, will delay certification until the issue is resolved and evidence of correction has been reviewed. The key is to treat any finding as a genuine improvement opportunity and respond with a root cause analysis and a concrete remediation plan, not just a quick document fix.

How detailed do management review minutes need to be to satisfy an auditor?

Management review minutes need to demonstrate that the review was substantive, not ceremonial. Auditors expect to see that the meeting covered the mandatory inputs defined in ISO 27001 Clause 9.3, including ISMS performance data, audit results, risk treatment status, and any relevant changes to the organisation or its context. Minutes that simply record attendance and state that 'the ISMS is performing well' without supporting data or decisions are unlikely to satisfy an auditor. Effective minutes document what was reviewed, what conclusions were reached, and what actions or resource decisions resulted from the discussion.

Do we need a dedicated ISMS document management system, or can we use general tools like SharePoint or Google Drive?

ISO 27001 does not mandate a specific document management platform, so general tools such as SharePoint, Google Drive, or Confluence are entirely acceptable provided they meet the standard's requirements for document control. This means documents must be identifiable, version-controlled, protected from unintended alteration, and accessible to those who need them. What matters to an auditor is not the tool itself but whether you can demonstrate that documents are reviewed, approved, and updated in a controlled and traceable manner.

How should we handle documentation when our organisation undergoes significant changes, such as a merger, system migration, or major restructure?

Significant organisational changes should trigger a formal ISMS review rather than waiting for the next scheduled review cycle. At a minimum, you should reassess your scope statement, update the risk register to reflect new assets, processes, or threat exposures introduced by the change, and review the SoA to confirm that all applicable controls remain relevant and implemented. Changes that are not reflected in your documentation create exactly the kind of documentation-versus-reality gap that stage 2 and surveillance auditors are trained to identify, so timely updates are essential to maintaining a credible ISMS.

What is the most practical way to build an internal audit programme that satisfies surveillance audit expectations?

The most effective approach is to distribute internal audits across the year rather than conducting a single large audit event immediately before a surveillance visit. A rolling programme that covers different areas of the ISMS at different points in the year provides continuous assurance and generates a richer evidence trail of ongoing governance activity. Each audit should produce a formal report, any findings should be logged and tracked through to closure, and the overall programme should be reviewed annually to ensure full ISMS coverage is maintained across the three-year certification cycle.

Related Articles

Share

  • June 19, 2026