Security Exceptions and Risk Acceptance Guide: Waivers

Every security programme has exceptions, and most of them outlive their reason, their owner and the controls that were meant to compensate for them. An unpatchable server, a service account that cannot rotate its password, an MFA exclusion for a legacy integration: each starts as a reasonable, temporary decision and becomes permanent exposure when nobody tracks it. This guide covers the operating model behind security exceptions and risk acceptance: the request workflow, who may accept which risk, what the register must hold, how expiry and renewal work, how to prove a compensating control actually works, and how US federal agencies handle risk acceptance under FISMA. It is for GRC teams, security architects and risk owners. For where exceptions sit in the policy hierarchy, see the Security Policy Framework Guide.

Key takeaways

• Acceptance is a decision, not a default. NIST IR 8286B notes that accepting a risk "does not indicate that the risk is negligible or unimportant"; accepted risks still need reporting and monitoring.
• Authority follows the size of the risk. A delegation table decides who may accept which rating; the requester never approves their own exception, and high risks go to an executive who owns the budget to fix them.
• Every exception expires. Time-bound approvals with alerts before expiry, and renewal treated as a new decision, are the main defence against exception sprawl.
• Compensating controls must be tested, not described. Validate them at approval and retest on a schedule; a compensating control nobody checks is an assumption.
• Delay is implicit acceptance. When a remediation date slips without a decision, the organisation has accepted the risk anyway, without anyone signing for it.

Exceptions, waivers and risk acceptance defined

Organisations use these terms differently. Define them once in the policy framework and use them consistently in tooling and reports.

An exception is risk acceptance applied to one policy statement and one set of assets. NIST IR 8286B lists four risk responses: accept "within risk tolerance levels", transfer, mitigate "to an acceptable level" and avoid. An exception usually combines acceptance with partial mitigation through compensating controls.

When an exception is legitimate

• Legitimate: a legacy system with a funded replacement date; a supplier product that does not support the required control yet; an operational technology asset that cannot be patched without a plant outage; a regulatory or contractual constraint; a short business-critical window such as a product launch.
• Not legitimate: convenience, avoiding the cost of a fix without anyone deciding to carry the risk, or a control that "slows the team down" with no assessment of what it protects.
• Not an exception at all: a requirement that most teams cannot meet. If many teams request the same exception, the policy or the platform is wrong. Change the standard or fund the fix.
• Never excepted: some requirements should be outside the process entirely, for example legal obligations, or controls the board has ruled non-negotiable such as MFA on administrative access. List them in the policy.

The security exception workflow

1. Request: the asset owner submits a security exception request citing the policy statement ID, affected assets, business justification, requested duration and the remediation plan. Free-text requests by email are the start of unmanaged exceptions; use a form in the ticketing or GRC tool.
2. Triage: security checks the request is complete, the statement is eligible for exception, and no existing exception covers it.
3. Assess: rate likelihood and impact using the organisation's standard method (NIST SP 800-30 Rev. 1 or ISO/IEC 27005:2022 style). Consider exposure (internet-facing or not), data handled, exploitability and whether the asset is a path to critical systems.
4. Design compensating controls: security proposes controls that reduce the specific risk, with how each will be tested.
5. Approve: route by residual rating to the authority in the delegation table. Security recommends; the business risk owner accepts.
6. Record: create the register entry with an expiry date and link it to the POA&M or remediation ticket.
7. Validate: test the compensating controls before the exception becomes active, and attach evidence.
8. Monitor: tag affected assets in scanners and posture tools so findings show as "excepted" with an expiry, not as noise or as silently suppressed.
9. Close or renew: close when the fix ships; renewal needs a fresh assessment and approval.

Rolling out the process

1. Inventory existing exceptions from email, tickets, scanner suppressions, conditional access exclusions and firewall rules. Expect to find more than anyone thinks.
2. Pilot the form and delegation table with one or two teams for a quarter and adjust ratings and durations.
3. Migrate known exceptions into the register with a short amnesty: anything not re-requested within 60 to 90 days is withdrawn and the control enforced, after notice.
4. Connect the register to tooling so suppressions need an exception ID and lapse with it.
5. If enforcement breaks a critical service, restore it under an emergency exception with a short expiry (days), then run the normal process.

Risk acceptance authority

Authority should rise with the risk. NIST IR 8286B observes that "the level of coordination and oversight usually increases" with potential impact. A simple delegation table makes this enforceable.

• Separation of duties: the requester, the assessor and the approver are different people. The CISO advises but should not accept business risk on the business's behalf. See the Segregation of Duties Guide.
• Budget link: the person who accepts a risk should be able to fund its removal. Accepting risk you cannot fix is signing for someone else's decision.
• Aggregation: many low-rated exceptions on the same system or control can add up to a high risk. Review exceptions by asset and by control, not only one by one.
• Small and large organisations: a small organisation may have only two levels (IT lead and managing director); a large one maps the table to its enterprise risk framework and risk appetite statements (NIST CSF 2.0 GV.RM-02).

The risk acceptance form and exception register

A risk acceptance form becomes evidence once signed. Each field below exists to answer a question an auditor, regulator or incident investigator will ask.

Evidence based risk acceptance means the approver saw current, specific evidence: scan results, exposure, data classification and test results for compensating controls. A form signed from a one-line summary is formal risk acceptance on paper only. Record what the approver was shown. NIST IR 8286B adds that remediation deadlines "should be recorded", including in the cybersecurity risk register, so the register shows when acceptance is meant to end.

Keep exceptions and risks in linked registers, or one register with an exception type, so a single report shows every accepted risk. See the Risk Register Template.

Expiry, renewal and exception sprawl

• Time-bound exceptions: every exception and every risk acceptance has an expiry no longer than the delegation table allows. Open-ended exceptions are not permitted, including for waivers.
• Alerts: notify the owner 30 and 7 days before expiry. On expiry the exception lapses and the asset is reported non-compliant, or the control is enforced if that is safe.
• Renewal: a renewal is a new request with updated evidence and approval at the current rating. Track how many times each exception has been renewed; a third renewal should go one level higher.
• Implicit acceptance: NIST IR 8286B describes risk being "implicitly accepted" when treatment is delayed. A POA&M milestone that slips without a recorded decision is an unmanaged security exception.
• Exception sprawl signals: rising count of active exceptions, many renewals, exceptions without linked remediation, suppressions in scanners with no exception ID, and the same statement excepted across many teams.

Compensating controls: design, validation and retesting

PCI DSS sets the best-known test for compensating controls in its Appendix B, with a worksheet in Appendix C. A compensating control must meet the intent and rigour of the original requirement, provide a similar level of defence, be above and beyond other PCI DSS requirements, and be commensurate with the additional risk of not meeting the original requirement; it is only available where there is a legitimate technical or documented business constraint. The worksheet records constraints, objective, identified risk, the control definition, how it was validated and how it is maintained. Those criteria work well outside payments too. See the PCI DSS 4.0 Guide.

• Runtime compensating controls: controls that act on live traffic or behaviour (virtual patching, isolation, behavioural alerts) need monitoring of their own health. A disabled rule or a silent alert pipeline removes the compensation without anyone noticing.
• Compensating control effectiveness: measure whether the control reduces the specific risk, not whether it exists. For detective controls, run a test event end to end and time the response.
• Compensating control retesting: retest on a schedule and after any change to the asset, network path or tool. Attach evidence to the register entry; stale evidence should block renewal.

Where identity fits

Identity exceptions are among the most common and the least visible, because they live in configuration rather than in a register.

• MFA and conditional access exclusions: excluded users and groups are standing exceptions. Give each exclusion an exception ID and expiry and review membership monthly. See the Conditional Access Guide.
• Service accounts and non-human identities: non-expiring passwords, interactive logon rights and broad privileges are often excepted at build time and forgotten. See the Service Account Security Guide.
• Break-glass accounts: these are designed exceptions to MFA or conditional access. Document them as such, monitor every use and test them. See the Break-Glass Account Guide.

FISMA and federal risk acceptance

US federal agencies operate the most formal model, and its vocabulary appears in many commercial frameworks.

• Authorising official: OMB Circular A-130 defines the authorising official as "a senior Federal official or executive with the authority to authorize (i.e., assume responsibility for)" operating a system, and an authorisation to operate (ATO) as a decision to "explicitly accept the risk to agency operations". NIST SP 800-53 CA-6 requires a senior official to be assigned as authorising official and notes authorising officials are "both responsible and accountable for security and privacy risks".
• Explicit acceptance before operation: NIST SP 800-37 Rev. 2 states that "the final action before a system is placed into operation is the explicit acceptance of risk by the authorizing official." The authorising official may have a designated representative, but the authorisation decision itself remains with the authorising official.
• Mission risk acceptance: the authorising official weighs risk against mission and business need, so a system can be authorised with known weaknesses if the mission requires it, provided they are documented.
• POA&M: CA-5 requires a plan of action and milestones documenting remediation of weaknesses, updated from assessments, audits and continuous monitoring; POA&Ms are required in authorisation packages and subject to OMB reporting.
• Ongoing authorisation: A-130 describes ongoing authorisation as "time-driven or event-driven", and CA-6 notes continuous monitoring evidence can support it. Risk acceptance in the federal model is therefore revisited, not granted once.

See the NIST SP 800-53 Guide and the FedRAMP Guide.

Monitoring, metrics and framework mapping

What to monitor: expired exceptions where the gap still exists; scanner, CSPM or EDR suppressions without an exception ID; conditional access exclusion membership changes; firewall rules tagged temporary past their date; compensating control health (rule enabled, alerts flowing).

• Active exceptions by rating and age: trend should be flat or falling.
• Overdue exceptions: past expiry with no closure or renewal; target zero.
• Renewal rate: share of exceptions renewed more than once.
• Compensating control test pass rate: and percentage with evidence older than the retest interval.
• Median time to closure: from approval to remediation shipped.
• Untracked suppressions: tool suppressions with no register entry.

Common failure patterns

• Permanent temporary exceptions: no expiry, or automatic renewal, so the register becomes a list of forgotten decisions.
• Exceptions outside the register: scanner suppressions, MFA exclusions and "temporary" firewall rules created directly in tools.
• Wrong approver: the requester's line manager or the security team accepting business risk, so nobody with budget or authority owns it.
• Paper compensating controls: described at approval, never tested, and quietly disabled during a later change.
• Remediation drift: POA&M dates slip repeatedly, turning a decision into implicit acceptance.
• No feedback loop: the same exception granted to many teams without anyone changing the standard or funding a platform fix.

Practitioner checklist

• Define exception, waiver, risk acceptance and compensating control once in the policy framework.
• Publish a delegation table linking residual rating to approver and maximum duration.
• Use a structured request form; reject requests without a policy statement ID, assets and remediation plan.
• Keep one exception register linked to the risk register and to POA&M or remediation tickets.
• Require an exception ID for every tool suppression, conditional access exclusion and temporary firewall rule.
• Validate compensating controls before activation and retest them on a schedule.
• Alert owners before expiry and treat every renewal as a new decision.
• Report active, overdue and renewed exceptions to the risk committee quarterly.
• Review exceptions by asset and by control to catch aggregated risk.

Standards and references

• NIST: SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations
• NIST: SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
• NIST: IR 8286B, Prioritizing Cybersecurity Risk for Enterprise Risk Management
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• OMB: Circular A-130, Managing Information as a Strategic Resource
• ISO: ISO/IEC 27005:2022, Guidance on managing information security risks
• NIST: The NIST Cybersecurity Framework (CSF) 2.0

Related NHI Mgmt Group resources: Security Policy Framework Guide · Segregation of Duties Guide · Risk Register Template · GRC Maturity Model