Risk Acceptance
PASS_WITH_KNOWN_RISK requires an owner, a reason, an approval time, and an expiry. A model may summarize an accepted risk; it may not approve one.
What acceptance means
PASS_WITH_KNOWN_RISK is a release outcome that says: a real weakness exists, it is documented, somebody named owns it, and the release proceeds anyway. It is not a softer PASS.
The default policy sets allow_accepted_risk to false. A team that wants the outcome has to enable it deliberately in its own policy pack, which is the point at which the approval fields become mandatory.
Required fields
{
"allow_accepted_risk": false,
"accepted_risk_required_fields": [
"reason",
"approver",
"approved_at",
"expires_at"
]
}- reason
- Why the risk is being carried rather than fixed, in terms a later reader can evaluate.
- approver
- A named human with the authority to accept it.
- approved_at
- When the decision was made, so its age is visible.
- expires_at
- When it must be revisited. An acceptance without an expiry is a permanent defect with paperwork.
The private-policy guidance adds two more in practice: a compensating control and a ticket reference, so the acceptance connects to whatever work is meant to eventually retire it.
Who may approve
- Security ownership covers policy semantics. Application ownership covers business invariants.
- Risk acceptance and signing should require protected-environment approval in CI.
- The owner and release authority are a distinct role from the mapper, the specialists, and the verifiers.
The audit trail
Accepted-risk creation, approval, expiration, and revocation are all listed as append-only audit events, alongside policy-pack version changes and gate decisions.
| Event field | Purpose |
|---|---|
| Event ID and UTC timestamp | Ordering and identity. |
| Actor or workload identity | Who or what performed the action. |
| Object type and ID | Which accepted risk or finding it concerns. |
| Repository, commit, scope ID | What the decision applied to. |
| Policy digest | Which policy version was in force. |
| Previous-event hash | Chaining, where the organization uses it. |
| Redacted metadata | Context without raw tokens, keys, cookies, seed phrases, or production payloads. |
Retention
Accepted risk is its own retention class: keep the approval, rationale, and compensating controls through expiration and review history. That is longer than ephemeral working data and different from release evidence.
Retention is not keep forever. Document deletion jobs, backup expiry, storage and geographic restrictions, and how a repository or customer is purged.