policiesException Register

Governance Exception Register

Purpose: Record all approved deviations from the security and engineering baseline defined in governance.md. Each exception must be time-bounded, risk-accepted by a named decision-maker, and linked to a remediation ticket.

Review cadence: Quarterly. Expired exceptions without renewal are automatically escalated to Platform Engineering lead.


Active Exceptions

IDControl Deviated FromJustificationRisk LevelExpiresOwnerTicket
EX-001SQLite in unit test conftest bypasses Alembic migration pathEnables zero-infra unit tests; SQLite schema is created from ORM metadata. Integration tests use full Alembic + Postgres path. See ADR-003.Low2027-05-23 (annual renewal)Platform Engineering
EX-002Redis fail-open policy on denylist check under outageFail-closed (blocking all auth) during Redis outage is operationally unacceptable for an incident response tool. Fail-open is documented in ADR-002 as an explicit risk.Medium2027-01-01SecurityINFRA-TBD

Closed / Resolved Exceptions

IDControlResolved DateResolution

Exception Request Process

  1. Engineer raises exception request using templates/governance-exception-request.md.
  2. Security reviews within 5 business days.
  3. Platform Engineering lead approves or rejects.
  4. Approved exception is added to this register with an expiry date ≤ 12 months.
  5. Ticket created in issue tracker for remediation tracking.
  6. Register reviewed quarterly; expired exceptions trigger escalation.

Risk Level Definitions

LevelCriteria
LowNo direct data exposure; compensating controls in place; limited blast radius
MediumPotential indirect exposure; time-bounded; monitored via alerts
HighDirect security control deviation; requires CISO sign-off; max 90-day duration
CriticalNot permissible via exception register; requires architectural remediation