| name | design-a-policy-exception-program |
| category | start |
| description | Design a policy exception program with eligibility, evidence, risk ownership, compensating controls, approval, duration, monitoring, renewal, expiry, and audit. Use when deviations must be governed without quietly weakening the policy. |
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
- Define policies in scope, prohibited exceptions, decision authority, independence, materiality, and record retention.
- Require a stable request ID, policy clause, asset or population, business need, root cause, alternatives, and requested duration.
- Assess affected people, obligations, threat, likelihood, impact, concentration, precedent, and cumulative exception exposure.
- Define compensating controls, owners, evidence, monitoring, incident triggers, residual risk, and remediation milestones.
- Route approval by risk tier with conflict checks, legal review where needed, explicit risk ownership, and reasoned dissent.
- Publish the approved scope, start, expiry, restrictions, alerts, renewal lead time, and automatic control restoration.
- 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
