What happens if an ISO 27001 Statement of Applicability is not kept current after certification?

When the SoA falls behind the environment, auditors and internal stakeholders lose confidence that the ISMS reflects actual practice. Controls may be marked in scope even though they are no longer implemented, or important changes may never be captured. That creates review problems, slows certification renewals, and undermines continuous improvement because the organisation is working from an outdated control picture.

Why This Matters for Security Teams

The statement of applicability is not a static certification artefact. It is the bridge between risk assessment, selected controls, exclusions, and the current operating environment. When it is allowed to drift, the ISMS can still appear certified on paper while the control set no longer matches cloud services, business processes, suppliers, or privileged access patterns. That gap weakens audit evidence, complicates governance reporting, and can leave critical changes unmanaged. ISO’s own guidance on ISO/IEC 27001:2022 Information Security Management makes the maintenance expectation clear, even if organisations sometimes treat the SoA as a one-time submission.

Security teams often underestimate how quickly a control narrative becomes stale after a restructure, platform migration, or major supplier change. Once that happens, the ISMS no longer provides a reliable view of what is actually in place, which makes gap closure and management review far less effective. In practice, many security teams encounter SoA drift only after an auditor, incident, or recertification review has already exposed the mismatch, rather than through intentional control upkeep.

How It Works in Practice

A current SoA should track three things together: the control selection decision, the reason for inclusion or exclusion, and the implementation status in the live environment. That means every significant change event should trigger a review, not just the annual audit cycle. Typical triggers include adoption of new SaaS platforms, changes to outsourced operations, merger activity, new legal requirements, or updates to identity and access architecture.

A practical maintenance process usually includes the following steps:

• Review the risk assessment to confirm whether the control set still matches current threats and business context.
• Confirm that each applicable Annex A control still has a defensible implementation owner and evidence source.
• Update exclusions or partial applications where the operating model has changed.
• Validate that policies, procedures, and technical controls align with the SoA statements.
• Record approvals so the SoA remains traceable through management review and audit.

This is where the link to control design matters. ISO/IEC 27002 provides the implementation guidance behind many Annex A controls, so it is a useful reference when the SoA needs to explain not just whether a control exists, but how it is being operationalised. The relevant control statements in ISO/IEC 27002:2022 Information Security Controls help teams keep the narrative aligned to actual practice rather than policy language alone.

For identity-heavy environments, the SoA should also reflect changes in PAM, JIT access, service accounts, and non-human identities where those are material to risk treatment. If those changes are omitted, the document may still look complete while the real control posture has already shifted. These controls tend to break down when change management is fragmented across multiple teams because no single owner updates the SoA at the same pace as the environment.

Common Variations and Edge Cases

Tighter SoA governance often increases administrative overhead, requiring organisations to balance audit readiness against the speed of operational change. That tradeoff becomes more visible in fast-moving cloud and DevSecOps environments, where control responsibility may be spread across platform, application, and security teams.

There is no universal standard for how frequently the SoA must be refreshed beyond keeping it current and demonstrably linked to the ISMS lifecycle. Current guidance suggests using event-driven updates for material changes and scheduled reviews for assurance, rather than relying on a fixed calendar alone. In lower-change environments, quarterly or biannual review may be enough; in highly dynamic environments, monthly checks or change-control integration may be more realistic.

Edge cases often arise where a control is technically implemented but no longer relevant, or where a control remains relevant but is delivered differently after outsourcing or consolidation. The strongest practice is to document the rationale clearly, preserve version history, and ensure management review sees both the control decision and the operational evidence. That discipline matters most when certification scope spans multiple business units, inherited systems, or shared service models, because inconsistency between teams can hide drift until the next external assessment.

Related resources from NHI Mgmt Group

• Who is accountable for maintaining ISO 27001 compliance after certification?
• What is the difference between passing an ISO 27001 audit and maintaining certification?
• How should security teams budget for ISO 27001 certification work?
• Why do access governance gaps increase ISO 27001 certification costs?