design-a-policy-exception-program

# design-a-policy-exception-program ## When to use - Use when a policy permits bounded risk acceptance or temporary alternate control. - Do not use an exception to bypass a legal prohibition, conceal noncompliance, or normalize chronic underinvestment. ## Procedure 1. Define policies in scope, prohibited exceptions, decision authority, independence, materiality, and record retention. 2. Require a stable request ID, policy clause, asset or population, business need, root cause, alternatives, and requested duration. 3. Assess affected people, obligations, threat, likelihood, impact, concentration, precedent, and cumulative exception exposure. 4. Define compensating controls, owners, evidence, monitoring, incident triggers, residual risk, and remediation milestones. 5. Route approval by risk tier with conflict checks, legal review where needed, explicit risk ownership, and reasoned dissent. 6. Publish the approved scope, start, expiry, restrictions, alerts, renewal lead time, and automatic control restoration. 7. Monitor usage, breaches, overdue remediation, repeated requests, portfolio patterns, and policy-design feedback. ## Failure plan - Deny, narrow, or expire the exception when authority, evidence, compensating control, monitoring, or remediation is inadequate. ## Worked example A legacy production system receives a 60-day encryption exception with network isolation, access logging, daily review, and a funded replacement milestone. ## Done - A policy exception program records scope, evidence, risk, alternatives, controls, authority, duration, monitoring, remediation, and expiry - Approval, conflict, control, alert, expiry, renewal, portfolio, and remediation evidence verifies the program