Software assurance guide

How to record an informed risk acceptance

Risk acceptance is an authorized decision to tolerate a stated failure mode under defined conditions. It should preserve the evidence, affected promises, containment and next review date so the decision can be revisited when its basis changes.

Start with the decision

Separate four questions before recording acceptance: what is known to fail, who is exposed, what reduces that exposure, and who has authority to accept the remaining consequence. A test result answers a behavioral question. A risk decision answers whether the organization will proceed despite that result. Neither replaces the other. A risk can be acceptable for one release or use while remaining unacceptable for another.

An illustrative case

Illustrative case: a reporting dashboard omits a rare error category while the authoritative ledger remains correct. The owner may consider a temporary release decision if operators use the ledger and affected customers receive a clear limitation. The record should identify the missing behavior, affected requirement, impact evidence, workaround, release scope and date for reassessment. If the ledger itself is incomplete, the same rationale no longer supports that decision.

Build the record

Keep the observed failure and reproducer in a KnownIssue. Connect it to the approved requirement and identify unresolved facts.
Prepare the exposure, mitigation, alternatives and residual consequence for the person authorized to accept the risk. Do not infer acceptance from silence or a passing audit.
After authorization, record the person, scope and review date. Verify the mitigation separately and keep the issue visible.
Reassess when the review date arrives or a material assumption changes. Withdraw acceptance when the basis no longer applies; record fresh authorization if it continues.

How Proof retains the decision

Proof stores AcceptedRisk records under proof/risks. Creation requires accepted_by and review_date; the CLI stamps acceptance time and history. The default release disposition is ship_with_known_issue. Referenced requirements and enumerated values are validated before writing. A review appends history without replacing the original accepting identity.

The review audit surfaces stale or blocking risk records. Do not assume that a passed date automatically rewrites the stored status to expired: the recorded review date remains relevant even when status still says active. A waiver suppressing an audit check is a different object and does not constitute acceptance of the product failure.

proof risk list
proof audit --check accepted_risks_reviewed

Keep the conclusion bounded

An AcceptedRisk records supplied identity and decision fields; those strings do not authenticate a person or prove authorization. A current record also does not establish that mitigation was deployed. Delivery still depends on the applicable release policy, current evidence and the authority of the decision maker.

Continue with one real issue

Known issues reviewed · Waivers reviewed

Bring one finding, its requirement and the current evidence to scope a walkthrough of what your reviewer can establish and what still needs work.