An ISMS fails when the organisation can describe its controls but cannot show they work under audit conditions. Stage 2 testing checks whether incidents trigger the right response from the right people, whether staff understand their roles, and whether controls are lived processes rather than static documents. Without that operational reality, certification efforts stall and major nonconformities can block approval.
When the system exists on paper but not in operation
An isms stops being credible when it cannot prove that controls work as part of normal operations. In practice, the gap is usually between documentation and evidence: people know what should happen, but incidents, approvals, reviews, and exceptions do not follow the documented path. That is why auditors test behaviour, not just policy language.
The weakness is often visible in the control chain. If a control depends on a named person, a recorded decision, or a timed response, the organisation has to show that those steps actually occur. A static policy can describe ownership, escalation, logging, or review cadence, but it cannot substitute for an operating process.
That distinction matters because an ISMS is judged on repeatability and traceability. If the same event produces different handling depending on who is present, or if records are assembled only when an audit starts, the management system is not functioning as a system. It is a document set with aspirational controls.
Where Stage 2 fails in real audits
Stage 2 testing is where certification bodies look for operational proof. They check whether an incident would trigger the right response from the right people, whether staff can explain their responsibilities, and whether control execution leaves enough evidence to verify performance. If those behaviours are inconsistent, the audit shifts from “does the organisation have controls?” to “does the organisation run them?”
Common breakpoints include weak incident handling, incomplete training evidence, unmanaged exceptions, and controls that are performed ad hoc rather than on schedule. For example, if a review is recorded only after a finding is raised, the auditor may treat it as retrospective documentation rather than a lived control.
That is also why management review, internal audit, and corrective action matter so much. They are the feedback loops that show the ISMS is being used to improve operations, not just to satisfy a template. ISO/IEC 27001:2022 Information Security Management is the clearest external reference point here, because it requires an operating management system, not a shelf-ready policy pack. For implementation detail, ISO/IEC 27002:2022 Information Security Controls helps teams translate governance intent into control behaviour.
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.4 — Information Security Management System | The question is about an ISMS that exists in documentation but not operation. |
| 9.2 — Internal Audit | Stage 2 failure often reflects the absence of auditable operational evidence. | |
| 10.1 — Nonconformity and Corrective Action | A paper-only ISMS typically breaks when findings are not corrected and closed. | |
| Recommendation — Operate the ISMS as a live management system and retain evidence that controls work in practice. Audit control performance against real evidence, not policy statements alone. Track findings to closure and verify corrective actions restore operating control. | ||
Practitioner Guidance
What to verify: Test the ISMS against evidence that would survive an audit walk-through, not against written intent. Ask whether the organisation can show a recent incident, exception, access review, or corrective action moving through the documented process end to end.
What to prioritise: Focus first on controls that depend on human action and time sensitivity, such as incident response, approvals, reviews, and escalations. These are the places where “documented” most often diverges from “operating.”
Common mistake: Teams often overvalue policy completeness and undervalue operational records. A well-written control description does not help if staff cannot explain what they did last month, what evidence was retained, or how failures are corrected.
Practitioner takeaway: The real test is whether the ISMS changes day-to-day behaviour and leaves verifiable evidence when something goes wrong; if it does not, certification is usually the first thing that fails.
Related resources from NHI Mgmt Group
- What breaks when SOC 2 controls are documented but not operating consistently?
- What breaks when mobile app testing cannot mirror the devices and operating systems users actually run?
- What breaks when identity controls are only documented and not executed consistently?
- What breaks when access control is only documented and not enforced at runtime?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
