Scenario: documenting a risk acceptance
A low-severity flaw won't be fixed before release. Record a defensible, time-boxed acceptance with sign-off.
A low-severity flaw in a deprecated component won't be fixed before release — document a defensible, time-boxed risk acceptance with sign-off instead of a silent shrug. Related: Scenario: answering a security questionnaire · Scenario: choosing your conformity route.
Two jours before release, a low-severity issue surfaces in a component you're already deprecating. Fixing it now means slipping the date; ignoring it silently means a gap in your evidence. There's a third, honest option: accept the risk on the record.
The finding
Value
Componentlibqux@1.4.2 (deprecated)
SeverityLow (CVSS 3.1)
Reachable?Yes, but low impact
Fix availableNot upstream
What a defensible acceptance needs
- The rationale. Why the residual risk is tolerable — low severity, limited impact, compensating controls in place.
- A time box. Acceptance expires; it isn't permission to forget. This one is tied to the component's planned removal.
- Named sign-off. A person with the authority accepts it, so it's a decision, not a drift.
The recorded acceptance
FieldEntry
DecisionAccept, time-boxed
ExpiresÀ suivre release (v4.3)
Compensating controlInput validation upstream
Signed offHead of Security
Risk acceptance isn't the opposite of compliance — undocumented risk is. A time-boxed acceptance with a name on it turns "we didn't fix it" into "we decided, and here's why."
Proofwright records the acceptance, its expiry, and its owner, so it resurfaces before it lapses.