A formal acceptance of a known security risk instead of immediate remediation. It records the owner, justification, scope, and expiry so the exception remains visible, reviewable, and time bound. In identity programs, waivers help teams document deliberate decisions without turning unresolved risk into an unmanaged permanent exception.
What a risk waiver actually is
A risk waiver is a documented exception, not a decision to ignore risk. It formalises why the issue is being accepted now, who accepted it, and how long that acceptance remains valid.
That distinction matters because waivers create accountability. They convert an informal “we will deal with it later” posture into a visible governance decision that can be challenged, reviewed, and revoked.
Why waivers are used in security programmes
Teams use waivers when remediation is temporarily impractical, disproportionately disruptive, or dependent on a later change window. The waiver acknowledges residual risk while the organisation keeps moving.
In well-run programmes, a waiver is paired with scope, justification, compensating controls, and an expiry date. Those details prevent the exception from becoming a permanent gap in the control environment.
NHIMG’s Security Exceptions and Risk Acceptance Guide is the most direct reference for the workflows, authority and expiry discipline that make a waiver defensible.
What makes a waiver defensible
A defensible waiver is specific about what is being accepted and what is not. Good waivers separate the underlying weakness from any compensating control, so reviewers can judge whether the residual exposure is acceptable for the stated period.
They also make ownership explicit. If no accountable owner exists, or if the justification is vague, the waiver is really just deferred remediation without governance. That is where exception registers, approval records, and periodic review become essential.
For practitioners, the key test is whether the waiver still makes sense if the original approver leaves, the system changes, or the business context shifts. If it does not, the waiver should expire or be re-approved.
How risk waivers differ from permanent exceptions
A waiver should be time bound and reviewable. A permanent exception usually signals that the control design, architecture, or business process itself needs rework, because the organisation has decided the exception is effectively part of the steady state.
That difference is operationally important. Short-lived waivers help preserve pressure to remediate, while open-ended exceptions tend to accumulate and hide control debt. Over time, exception sprawl can become its own security and compliance problem.
In identity and access programmes, the same principle applies when teams accept delayed remediation for privilege, authentication, or lifecycle issues: the waiver must not outlive the risk it was created to manage.
Risk and Threat Considerations
Risk waivers can conceal exposure if they are used too broadly, reviewed too slowly, or written so generically that no one can tell what risk was actually accepted. The main danger is not the waiver itself, but the false sense of closure it can create.
Failure mechanism: A waived issue remains exploitable, but the exception record no longer receives the same operational attention as an active finding, so the exposure persists past its intended review point.
Impact: Uncontrolled exceptions can lead to weak enforcement, audit gaps, and prolonged exposure to the original security weakness, especially when ownership or expiry tracking is poor.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Risk waivers commonly track intentional deviations from secure baselines. |
| Recommendation — Record approved deviations from secure baselines and review them until they are removed. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Waivers document and approve controlled deviations from required configurations. |
| RA-5 — Vulnerability Monitoring and Scanning | Waivers are often used to accept unresolved vulnerabilities with known scope and expiry. | |
| Recommendation — Require formal approval and review for configuration deviations that are accepted as temporary exceptions. Track accepted vulnerabilities separately so they remain visible to monitoring and review. | ||
| ISO/IEC 27001:2022 | A.8.32 — Change management | Risk waivers support controlled approval of deviations from standard security requirements. |
| Recommendation — Approve temporary security deviations through controlled change and exception records. | ||
| NIST CSF 2.0 | GV.OV-01 — Oversight of the cybersecurity risk management strategy | Waivers are governance decisions that require oversight, accountability and periodic review. |
| Recommendation — Maintain oversight of accepted risks and revisit them on a defined schedule. | ||
Practitioner Guidance
Governance implication: Treat each waiver as a temporary risk decision with a named owner, stated scope, and expiry. If those elements are missing, the record is incomplete and should not be treated as an approved acceptance.
What to watch for: Repeated renewals, vague justifications, and waivers that outlive the system or process they were created for are strong signs that the organisation has moved from managed exception to unmanaged debt.