These documents show whether the ISMS is actually designed and operating as claimed. If the internal audit is missing, the risk assessment is incomplete, or the Statement of Applicability does not tie back to risk, the auditor cannot verify control coverage. That creates a certification blocker because the organisation has not demonstrated a coherent, auditable security management system.
Why those artefacts matter to the stage two decision
Stage two is not a checkbox review of forms. It is the point where the auditor asks whether the ISMS can be traced from risk, to control selection, to operation, to evidence. If the internal audit programme is absent or weak, the risk assessment is incomplete, or the statement of applicability does not justify control inclusion or exclusion, the audit trail breaks and the ISMS looks theoretical rather than operational.
That is why these artefacts are treated as proof of design intent and operating reality. They let the auditor test whether the organisation has selected controls for the risks it actually faces, and whether those controls are being reviewed on a repeatable cycle. Without that linkage, the reviewer cannot determine whether the management system is coherent enough to support certification.
For organisations building or remediating the ISMS, the practical standard is consistency: the risk register, control choices, internal audit scope, and management review outputs should all tell the same story. If they do not, the problem is not merely documentation quality, it is that the ISMS has not been evidenced as a working system.
How audit, risk, and the Statement of Applicability work together
The internal audit shows whether the organisation is checking itself against its own requirements. The risk assessment shows why particular risks exist and why certain controls are needed. The Statement of Applicability shows which Annex A controls are in or out, and the rationale for that decision. Stage two relies on the three together because each one answers a different question about the ISMS.
A coherent package should allow an auditor to follow the path from risk to control without guesswork. If a control is included in the Statement of Applicability, the related risk should be visible. If a control is excluded, the rationale should still be defensible. If an internal audit has identified a gap, there should be evidence that the organisation understood the gap and acted on it. When one of these links is missing, the whole chain becomes harder to trust.
This is also why late-stage fixes are often only partially effective. You can rewrite a Statement of Applicability, but if the underlying risk treatment logic is not sound, the change will still feel retrofitted. Stage two auditors are looking for an ISMS that was built with evidence and discipline, not one assembled after the fact to satisfy the checklist.
What a stage-two auditor is actually testing
The real test is whether the organisation can demonstrate control governance, not just control names. The auditor is checking for a defensible method, timely review, and evidence that the method is being used. If the internal audit is missing, the audit function cannot show independent verification. If the risk assessment is stale or incomplete, control selection lacks a current basis. If the Statement of Applicability is not tied back to risk, the control set looks arbitrary.
That is why these gaps become certification blockers. They do not simply leave a paperwork omission, they undermine confidence that the ISMS is operating as a managed system. In practice, an auditor may not be able to confirm scope completeness, treatment decisions, or whether exclusions are justified. When that happens, the audit finding is usually about system coherence, not a single absent document.
For organisations using supporting guidance, ISO’s own framework materials on ISO/IEC 27001:2022 Information Security Management and ISO/IEC 27002:2022 Information Security Controls are the clearest reference points for how that traceability is expected to work.
Risk and Threat Considerations
These gaps create more than certification friction. A weak risk assessment or a disconnected Statement of Applicability can hide missing controls, weak ownership, or unmanaged exceptions, which means the organisation may believe it has security coverage that does not actually exist. That increases the chance of control failure and makes the ISMS harder to trust during incident response or external assurance.
Failure mechanism: The ISMS loses traceability between risk, treatment, and evidence, so the auditor cannot verify that selected controls are both justified and operating as intended.
Impact: The organisation may fail stage two, or be forced into remediation because the management system cannot demonstrate coherent control coverage, review, and accountability.
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 NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Asset and scope traceability underpins a defensible ISMS scope and SoA coverage. |
| A.5.35 — Independent review of information security | Internal audit evidence is needed to show the ISMS is independently checked. | |
| A.5.8 — Information security in project management | Controls and risk treatment must be embedded early so the ISMS is not assembled after the fact. | |
| Recommendation — Keep the ISMS scope and asset inventory aligned before certification evidence is reviewed. Run and retain independent ISMS reviews before stage two audit. Build ISMS evidence into delivery and remediation workstreams from the start. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | A coherent risk strategy is required for risk assessments to justify control choices. |
| Recommendation — Tie control selection to a documented risk management strategy. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Audit evidence and review findings must be actionable to demonstrate operating controls. |
| Recommendation — Review audit outputs and track remediation to closure. | ||
Practitioner Guidance
What to verify: Check that each in-scope risk has a treatment decision, each material control decision is reflected in the Statement of Applicability, and each internal audit finding has an owner and closure path. If any one of those links is missing, stage two risk rises quickly because the auditor will see a system narrative gap, not just a document gap.
Common mistake: Teams often try to “fix” certification by polishing templates instead of reconciling the underlying logic. That usually fails because the issue is not wording, it is whether the ISMS can be followed end to end from risk through control selection and operational evidence.
Practitioner takeaway: Stage two is blocked when the organisation cannot prove that its ISMS decisions are connected, current, and independently checked, because certification depends on evidence of governance, not evidence of intent.
Related resources from NHI Mgmt Group
- How should security teams write an ISO 27001 Statement of Applicability so it stands up in audit and internal review?
- Why do non-human identities create more audit risk than human accounts?
- How should security teams govern non-human identities for ISO 27001?
- Why do non-human identities create audit risk in modern environments?