What makes a documented risk acceptance still defensible six months later?

## Why this is asked Every threat model produces findings that will not be fixed. The interesting question is never whether you accept risk — you always do — but whether the acceptance survives contact with an incident review. A do-not-fix you cannot defend six months later retroactively invalidates the whole modeling exercise, because it shows the model produced a list, not decisions. ## The worked example A nightly build runner holds a long-lived cloud role that can deploy to production. The threat: an attacker who compromises the build system — through a dependency, a malicious change to the build definition, or the host itself — inherits a standing production deploy capability. The asset at stake is deploy credentials, and through them the integrity of what runs in production. The fix is short-lived, per-run federated credentials, and it is a quarter of work. The team accepts the risk for one quarter. Here is what makes that acceptance hold up. ## 1. A named owner with the authority to accept The person who signs must be accountable for the system and its outcomes — the service or product owner who carries the budget and wears the incident. The security engineer who found the threat is exactly the wrong signatory: they can advise, rate and object, but they do not own the consequence, and an acceptance signed by the finder lets the accountable party say later that they were never told. Seniority should scale with the residual risk; a threat that can reach production integrity is not an acceptance a single engineer takes alone. ## 2. Residual risk stated as an outcome, not a score "Accepted: high" is worthless in six months. Write what actually happens if it lands, in the language the owner used when they agreed: an attacker with a foothold in the build system can push arbitrary code to production without a further credential, and the deploy would look routine. That sentence is what the owner is signing, and it is what a reviewer checks the acceptance against later. ## 3. The reason, including what was traded Record why: the cost of the fix, the delivery it would displace, the dependency it waits on. "Accepted while per-run federated credentials are built; the alternative was delaying the release train by a sprint" is a decision. "Accepted, low priority" is not. The reason is also the thing that stops being true first, which is what makes it worth writing. ## 4. Evidence and compensating controls, verified An acceptance is much stronger when it is not bare. What narrows the window — restricting which branches can trigger the deploy job, pinning the build definition, alerting on a deploy that does not correspond to a merge? Say which of these exist, and say that someone checked they work rather than that they are configured. The trap is a compensating detection that has never fired, has no owner, and routes to a channel nobody reads: the acceptance is then resting on a control that exists only on paper. If the detection is the entire justification, verify it, name who acts on it, and say what the response is. ## 5. A hard expiry The expiry is the single element that most acceptances are missing, and the one that turns a decision into a permanent state. A date forces the decision to be made again against the facts of that day — did the federated-credential work actually land, did the system grow more blast radius, did the threat's likelihood change? Two rules keep it honest. First, lapse should return the risk to the queue as un-accepted, not silently extend it. Second, renewal is a fresh decision with fresh evidence, not a rubber stamp; an acceptance renewed three times without anyone re-reading the residual risk has quietly become an unmanaged risk. It is also worth naming **trigger conditions** that force early re-review regardless of the date: the system starts handling a new class of data, the compensating control is removed, the blast radius grows, or the threat is observed being exploited elsewhere. ## What an acceptance is not It is not a closure. The risk still exists, still belongs in whatever view the organisation uses to see its exposure, and still shows up in the next model of the same system. It is not a transfer — nobody else is paying. And it is not a silence: an acceptance nobody outside the team can find is functionally the same as never having decided. ## How this is probed in interviews Expect a scenario: "you accepted this last quarter, the fix slipped, the owner has changed teams — what now?" The strong answer re-derives the decision rather than extending it: confirm who owns the system today, re-check whether the residual-risk sentence is still accurate, verify the compensating control still fires, and put a shorter expiry on the renewal because the original assumption — that the fix was one quarter away — has already been falsified once.