Exception and risk acceptance management
Trust Architecture Playbook: Governance pillar
Canonical exception boundary
Governance owns the exception standard. Automation owns operational exception handling inside approved patterns. Keeping that split explicit prevents the exception process from being duplicated, weakened, or redefined by each automation runbook.
Aviso
Canonical register
The Governance is the authoritative source for exception criteria, approval authority, risk acceptance, evidence, and review cadence. The Automation pillar should refer back to this register when documenting operational exception handling, failure loops, and remediation.
Area | Governance owns | Automation owns |
|---|---|---|
Criteria | What qualifies as an exception, what must be remediated, and which deviations require risk acceptance. | How a specific automation pattern detects that it cannot complete normally. |
Approval authority | Who may approve exceptions by tier, trust domain, CA source, profile, and risk level. | Who may execute the operational workaround after approval exists. |
Evidence | Required risk rationale, compensating controls, expiry date, owner, review cadence, and closure proof. | Runbook evidence, failure-loop evidence, validation output, and remediation notes tied back to the governance exception ID. |
Review cadence | When exceptions are reviewed, extended, rejected, escalated, or retired. | When operational defects, failure loops, and automation pattern gaps are reviewed. |
Register of record | The governance exception register is canonical. | Automation records refer back to the canonical governance exception and must not maintain a conflicting exception register. |
Exception qualification
Every PKI program has exceptions. The question is whether exceptions remain rare, governed, and temporary, or whether they become the silent operating model. Exceptions should be used for legitimate constraints, not for missing ownership, missing inventory, missing monitoring, or lack of engineering discipline.
Legitimate exception: Third-party platform with no supported automation path, legacy device with fixed certificate handling, regulatory constraint, temporary migration state, or unsupported but business-critical platform.
Remediation required: Unknown owner, unknown install location, missing tags, broad profile created for convenience, shared service user, missing monitoring, manual deployment that could be automated with reasonable engineering work.
Pattern gap: Multiple exceptions cluster around the same platform, business unit, profile type, or CA source. Escalate to pattern catalog or platform engineering review rather than approving repeated one-offs.
Exception register
Once an exception is qualified, it must be tracked formally rather than left as an informal understanding. The following fields define what an exception register entry should capture.
Field | Required content |
|---|---|
Exception ID | Unique identifier, approval date, and approving authority. |
Affected assets | Certificates, profiles, CA sources, services, business unit, environment, and tier. |
Policy deviation | The specific standard, profile requirement, access rule, CA requirement, or evidence control not being met. |
Reason | Specific constraint. Do not accept vague phrases like legacy issue or business need without detail. |
Risk impact | Security, availability, audit, compliance, relying-party, and operational impact. |
Compensating controls | Specific, testable controls such as shorter validity, manual review, increased monitoring, restricted SAN scope, additional approval, or accelerated migration. |
Expiry / review date | Mandatory. No exception should be open-ended. Ninety days is a useful default starting point, adjusted by risk. |
Retirement plan | Platform upgrade, connector development, profile redesign, migration, decommission, or policy update. |
Owner | Business risk owner and technical remediation owner. |
Evidence link | Approval record, risk acceptance, monitoring evidence, and closure proof. |
Example exception register entry
A good exception entry is specific enough that an auditor, incident commander, or executive risk owner can understand the deviation and the path back to standard governance.
Field | Example entry |
|---|---|
Exception ID | PKI-EX-2026-001; approved June 2026 by PKI governance board. |
Affected assets | Tier 1 customer gateway certificate on legacy ADC pair; production; Digital customer platform business unit. |
Policy deviation | Cannot use the approved sensor-based deployment pattern until ADC firmware migration is complete. |
Reason | Current ADC firmware does not support the approved connector workflow for deterministic deployment and reload validation. |
Risk impact | Manual renewal and deployment increase outage risk and evidence-collection risk for a customer-facing service. |
Compensating controls | Shortened expiration alerting, two-person manual deployment review, live endpoint validation within 30 minutes, and weekly exception review. |
Expiry / review date | 90 days from approval; no automatic extension. |
Retirement plan | Complete ADC firmware migration, validate connector workflow in non-production, then move service to standard profile and close exception. |
Owner | Business risk owner: customer platform executive; technical remediation owner: ADC platform lead. |
Evidence link | Risk acceptance, deployment runbook, validation output, review notes, and closure proof in the governance evidence repository. |
Break-glass governance
Break-glass is not an exception to governance. It is a governed emergency path. It should be designed before the incident, not during one.
Use dedicated emergency profiles with narrow scope, short validity, and strong logging where possible.
Separate emergency approvers from day-to-day operators where practical.
Pre-stage emergency access for Tier 0/1 trust domains and test it through tabletop exercises.
Require a timeline: who approved, who executed, what was issued, where it was deployed, how it was validated, and when normal governance resumed.
Run post-event review within a defined window and convert break-glass output into standard profiles, corrective actions, or retired emergency artifacts.