Cybersecurity Engineering Handbook / Chapter 63
Security Exception Template
Record security exceptions with ownership, risk analysis, compensating controls, detection, remediation, approval, expiration, and revalidation.
Preparing audio…
Audio edition
Security Exception Template
The export design in the preceding appendix requires signed job envelopes and safe signing-key rotation. Suppose the envelope is implemented and tested, but automated rotation will miss the release date. The team can rotate the key manually with dual-key verification; the platform integration that makes rotation routine needs three more weeks.
That gap creates a decision. The release can wait, or an authorized risk owner can accept a narrower, temporary operating condition. Schedule pressure alone does not decide between them. The team must show the exact requirement it cannot meet, the attacker opportunity created by the gap, what will constrain that opportunity now, how misuse or control failure will be detected, and what event ends the exception.
A security exception records that argument. It does not amend the requirement or turn missing work into compliance.
What an exception can contain
Use an exception only for a known requirement gap whose scope and duration can be bounded. A vendor limitation, staged migration, legacy dependency, or control rollout may qualify when the residual risk remains within the named acceptor’s authority. The record must travel with the release decision and the operating risk register; it should not live only in a delivery ticket.
Some gaps should stop the work. Do not approve an exception when the affected assets are unknown, the attacker path is not understood, the proposed controls exist only on a roadmap, no one can detect the relevant failure, or the worst credible outcome exceeds the acceptor’s authority. An expiry date does not make an unacceptable risk temporary.
The working record
The form is sequential because the decision depends on the reasoning above it. Keep links to test results, alerts, change records, and approvals with the record rather than replacing them with “verified.”
# Security Exception: <requirement gap in plain language>
## Identity and authority
- Exception ID and status:
- System, environment, and assurance level:
- Accountable remediation owner:
- Authorized risk acceptor:
- Security and operations reviewers:
- Date opened and expiration date:
- Review cadence:
- Related requirement, decision, threat, release, and incident records:
## Requirement gap
- Exact requirement or control ID:
- Required state and current state:
- Constraint preventing compliance now:
- Systems, interfaces, data, users, and tenants in scope:
- Explicitly out of scope:
## Risk created by the gap
- Attacker or failure path:
- Preconditions and exposure window:
- Worst credible outcome:
- Existing controls that still apply:
- Residual risk after the temporary controls below:
- Evidence or change that would make this analysis invalid:
## Temporary controls required before approval
### <control>
- Owner and effective date:
- Mechanism and boundary protected:
- Evidence that the control is active:
- Limitation or attacker step left open:
## Detection, containment, and communication
- Signals and telemetry-health check:
- Alert threshold, route, and triage owner:
- First containment action and decision authority:
- Evidence to preserve:
- Customer, regulator, or stakeholder communication trigger:
## Remediation and closure
### <step>
- Owner and due date:
- Completion evidence:
- Dependency or blocker:
- Closure test that proves the original requirement is met:
- Records from which the exception must be removed:
## Decision
- Decision: approved | rejected
- Acceptable residual risk and conditions of approval:
- Decision maker and date:
- Release or operating decision that depends on this approval:
## Revalidation
### <review date>
- Reviewer and decision: continue | narrow | revoke | close
- New evidence, incidents, scope changes, or missed conditions:
- Remaining remediation and next review:
Proposed means the record is open and grants no permission to release or continue operating. Approved means the named authority accepted the stated residual risk until the earliest of expiration, a revocation trigger, or closure. Expired means the authority has ended: the affected release or operation must stop unless a new review produces a new bounded decision. Closed means evidence shows that the original requirement is satisfied or the affected capability no longer exists.
Follow one gap to its end
This worked record continues the Customer Export Service decision. The dates and identifiers are illustrative; the controls and evidence show the level of specificity the review needs.
# Security Exception: Automated rotation for export job-envelope signing key
## Identity and authority
- Exception ID and status: EXC-KEY-EXPORT-004; approved
- System, environment, and assurance level: Customer Export Service;
production; Level 2
- Accountable remediation owner: Customer Data Platform service owner
- Authorized risk acceptor: Customer Data Platform director
- Security and operations reviewers: Security Architecture and SRE
- Date opened and expiration date: 2026-07-10; 2026-08-07 17:00 UTC
- Review cadence: every seven days and after every rotation
- Related records: SADR-AUTHZ-EXPORT-003; KEY-ROT-006;
TS-AUTHZ-EXPORT-002; release EXPORT-2026-07
## Requirement gap
- Exact requirement: KEY-ROT-006 requires automated rotation of the
job-envelope signing key every seven days, with overlap for verification and a
tested rollback path.
- Required and current state: the worker verifies a versioned signed envelope
and accepts the active and immediately previous public key. Rotation currently
requires a reviewed production change instead of the platform rotation job.
- Constraint: the managed signing integration cannot publish the new public-key
version to workers until the worker configuration migration is complete.
- In scope: export API, queue envelopes, workers, signing key, and production
exports. Out of scope: archive-download authorization, which has its own key
and must meet its approved requirement without exception.
## Risk created by the gap
- Attacker path: a compromised break-glass custodian could preserve an old
signing version or alter the public-key publication step so that a worker
accepts envelopes outside the approved signing path. An ordinary execution
error could leave the active and previous versions inconsistent across workers.
- Exposure window: production export creation until automated rotation is
validated or this exception expires, whichever comes first.
- Worst credible outcome: forged export work runs with valid-looking envelope
integrity, or legitimate exports fail unevenly across workers during rotation.
Worker tenant consistency checks still constrain a forged job to the signed
tenant and export record, but the signature no longer proves that the approved
API created it.
- Existing controls: signing custody is separate from worker credentials;
workers reject unknown versions, expired envelopes, tenant mismatches, and
replayed job IDs; download reauthorizes the subject against the archive.
- Residual risk: misuse or error by the temporary human custodian may preserve
an unauthorized version, publish an incorrect verification key, or interrupt
export processing before review detects it. The exception does not cover
failure of tenant checks, replay protection, download authorization, or audit
events.
- Invalidation triggers: missed rotation, failed overlap or rollback test,
signing-policy change, unexplained envelope rejection, signing access outside
the approved identity, scope expansion, or an event suggesting forgery.
## Temporary controls required before approval
### Seven-day manual rotation
- Owner and effective date: SRE signing-key custodian; before release
- Mechanism: a two-person reviewed change creates a new key version, publishes
its public key, verifies dual-key operation, switches signing, and disables
the old private key after the maximum envelope lifetime.
- Evidence: change record, custody log, versioned worker configuration, overlap
test, rollback test, and old-version disable event linked here.
- Limitation: privileged custody remains and a manual step can be delayed or
performed incorrectly.
### Narrow signing authority
- Owner and effective date: IAM owner; before release
- Mechanism: only the export API identity and the break-glass custodian can use
the key; human access requires a time-bound approved elevation.
- Evidence: policy export, denied-use test, elevation expiry test, and daily
review of signing principals.
- Limitation: an approved but compromised identity can still request signatures.
## Detection, containment, and communication
- Signals: signing principal, key version, envelope issuer, job ID, tenant,
issued-at time, verification result, replay result, and rotation age. A daily
canary proves that the signing and worker telemetry path is reporting.
- Alerts: human signing, unexpected principal, envelopes using a disabled
version, duplicate job ID, signature rejection, or key age above eight days
pages Product Security and the export on-call owner.
- First containment: pause export creation and worker consumption, disable the
suspect version, preserve API, signing, queue, worker, policy, and object-access
events, then decide whether existing archives must be quarantined.
- Communication: the incident commander invokes customer or regulatory review
when evidence shows or cannot exclude unauthorized tenant-data processing.
## Remediation and closure
### Publish key versions automatically
- Owner and due date: Platform Identity owner; 2026-07-31
- Completion evidence: reviewed integration change, staging rotation, and
production configuration showing current and previous public-key versions
### Exercise the complete rotation
- Owner and due date: Customer Data Platform service owner; 2026-08-02
- Completion evidence: production rotation and rollback exercise with signing,
verification, rejection, alert, and old-version disable events
- Closure test: two scheduled rotations complete without human key handling;
stale, unknown, and replayed envelopes fail closed and route an alert.
- Remove from: release record, operating risk register, and on-call handoff.
## Decision
- Decision: approved through 2026-08-07 17:00 UTC, subject to every temporary
control and weekly review above
- Accepted residual risk: short-term privileged misuse or manual-rotation error
within the stated export boundary
- Decision maker and date: Customer Data Platform director; 2026-07-10
- Dependent decision: release EXPORT-2026-07 may proceed only after Release
Security Review confirms the pre-release evidence in this record.
## Revalidation
### 2026-07-17
- Reviewer and decision: Security Architecture; continue
- Evidence: first manual rotation, overlap test, alert canary, and access review
completed; no invalidation trigger observed
- Remaining work: automated public-key publication; next review 2026-07-24
The worked record does not call manual rotation equivalent to automated rotation. It names the remaining privilege and execution risk, then gives the release reviewer concrete evidence and a revocation boundary. If any required temporary control is absent, the record remains proposed and the release remains blocked.
Revalidate against change, not optimism
At each review, ask what has changed in scope, exposure, evidence, and remediation. Confirm that the temporary controls are still active, their telemetry still reports, and the owner is meeting the plan. An incident, missed condition, new tenant or data class, expanded environment, or evidence that contradicts the analysis can revoke approval before the date on the record.
Do not silently move the expiry date. If the gap persists, the acceptor must confront the new facts: why remediation slipped, whether exposure accumulated, whether the controls failed, and whether continued operation remains inside their authority. Record that as a new decision or a clearly preserved reapproval, not an edited date that erases history.
Closure requires evidence that the original requirement now holds. A completed ticket, merged change, or vendor promise is not enough. Run the named closure test, remove the exception from release and operating records, and preserve the decision history. The next appendix can then treat the exception honestly: as an approved, bounded input to release review—or as a blocker.