# Policy exception approval SOP

Version: 1.0

Owner: Support policy owner

Review cadence: Quarterly and after a material policy change

Purpose: Decide one bounded departure from a known support policy without changing the policy or granting reusable authority.

## Scope

Use only when the customer, applicable policy version, normal outcome, proposed exception and requested deadline are known. Do not use for routine policy application, emergency/security incidents, or decisions that require finance, legal, employment, safety or regulatory review outside this procedure.

## Trigger and inputs

Trigger: a support agent records that the normal policy outcome is insufficient and requests one exception.

Required inputs:

- ticket and customer identifiers;
- policy name, version, effective date and clause;
- deterministic normal outcome and its inputs;
- requested exception, scope, reason, impact and expiry;
- source-linked evidence and conflicting facts;
- authority category and threshold;
- execution destination and business idempotency key.

## Procedure

1. Confirm identity, entitlement and the governing policy version.
2. Calculate and retain the ordinary policy outcome.
3. Validate evidence links, required fields and sensitive-data handling.
4. Prepare a decision packet. Summaries must cite source records and preserve unknowns.
5. Match the exception type and magnitude to the explicit authority table.
6. Reject self-approval, expired delegation, conflicts of interest and out-of-range authority.
7. Notify the named approver and start the decision clock.
8. Record approve, reject, request-evidence or redirect with reason, scope and expiry.
9. Before execution, revalidate case, proposal version, policy version, authority and expiry.
10. Execute once using the business key; reconcile the destination state.
11. Append the verified effect to the decision record and notify the case owner.

## Exceptions and escalation

- Missing or conflicting evidence: return to the requestor with a field-level list.
- Policy changed while pending: invalidate and rebuild the packet.
- No response by expiry: fail closed; escalate or return to the queue owner.
- Ambiguous execution: stop retries and reconcile the destination.
- Repeated reason: tag for policy review; do not alter the live policy automatically.

## Output and success condition

The decision record contains the proposal and policy versions, evidence manifest, authority snapshot, approver, outcome, reason, timestamps, expiry and verified effect. Success means one valid decision led to zero or one matching effect.

## Measures

Packet return rate, complete-packet decision time, expiry rate, redirect rate, effect-reconciliation status, overturn rate and repeated reasons by policy clause.

## Revision log

- 2026-08-03: Initial public template.