Make every security exception expire—or escalate

Source facts: risk decisions require continuing accountability

NIST SP 800-37 Rev. 2 describes a Risk Management Framework that integrates security and privacy risk management into the system development lifecycle. The framework includes preparation, control selection and implementation, assessment, authorization, and continuous monitoring. Risk acceptance is therefore connected to accountable decision-making and current evidence, not a permanent label applied once.

NIST SP 800-53 Rev. 5 provides security and privacy control outcomes and enhancements covering assessment, plans of action, configuration, access, vulnerability remediation, monitoring, and many other areas where exceptions arise. Organizations tailor controls based on mission, environment, requirements, and risk.

Neither publication mandates one universal approval level, maximum duration, form, or compensating control for every exception. The organization must define those parameters. The common requirement is an explainable decision that remains valid only while its facts, scope, and risk treatment remain current.

DSE recommendation: make renewal more demanding than initial approval

An exception process should enable necessary work while making drift visible. Repeated renewal is evidence that the underlying design, ownership, funding, or requirement needs a higher-level decision.

1. Define what qualifies. Distinguish a temporary exception from a standard change, false positive, accepted product limitation, permanent architecture decision, or incident containment measure. Route each through the correct authority rather than using one generic risk-acceptance field.
2. Require a complete request. Record the requirement being departed from, exact assets and users, environment, business reason, technical constraint, start date, requested end date, data and service impact, threat scenario, evidence, alternatives considered, and requested control change. Reject vague scopes such as all servers or until fixed.
3. Evaluate residual risk. Identify the control objective that is weakened, likelihood and consequence under current exposure, dependencies, detection capability, legal or contractual limits, and whether the exception combines with others. Use qualified technical, business, privacy, safety, and compliance reviewers where relevant.
4. Assign treatment and authority. Specify compensating controls, implementation owner, evidence, monitoring, incident triggers, remediation owner, milestones, budget or dependency, and approval level proportionate to residual risk. The person who benefits from the exception should not be the only person accepting it.
5. Set expiry and automatic escalation. Choose the shortest practical duration and notify owners before expiry. Automatically disable the exception where safe or escalate it for decision. High-impact, repeatedly renewed, expanded, or overdue exceptions should require a more senior risk owner and an explicit remediation plan.
6. Monitor changed conditions. Reassess after exploitation activity, incidents, vendor updates, new exposure, asset transfer, architecture change, compensating-control failure, or regulatory change. Define conditions that end approval immediately rather than waiting for the calendar date.
7. Verify closure. Confirm the original requirement is restored, the workaround is removed from every management path, compensating measures are retired appropriately, services remain healthy, and evidence is retained. Closing a ticket without technical verification does not close the exception.

Review the portfolio, not only individual requests. Several narrow exceptions affecting the same identity, application, network segment, supplier, or recovery path can combine into a larger exposure that no single approver sees. Periodic aggregation should identify concentration, recurring root causes, remediation dependencies, and standards that may need redesign.

Factual boundary: NIST supplies risk-management and control frameworks; it does not set DSE or customer approval authority, exception lifespan, risk appetite, or legal sufficiency. Those decisions depend on the organization, system, contract, jurisdiction, and impact.

Measure open and expired exceptions, average age, renewals, scope growth, missing compensating-control evidence, overdue remediation, concentration by system and supplier, and failed closure checks. The useful trend is not merely fewer records; it is less time spent outside the approved state and faster escalation of structural problems.

Official references

• NIST, SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations.
• NIST, SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations.