← All articles

Governance · · 2 min read

Accepting risk responsibly: how to defer a fix without ignoring it

Deferring a low-risk finding is good practice. Forgetting about it is not. The difference is a documented, reviewed, time-bound decision.

Context-aware prioritisation means some findings will wait. That is the point — but it raises a fair concern: how do you make sure "later" does not quietly become "never"?

Defer is a decision, not a default

A responsible deferral has four parts:

  1. Reasoning. Why the risk is lower here: not reachable, function not called, compensating control in place.
  2. Owner. A named person accountable for the decision.
  3. Review. Approval by someone with the authority to accept that level of risk.
  4. Trigger to revisit. A date, a change cycle, or a change in context that re-opens the decision.

Context can change

A deferred finding should be re-evaluated automatically when the facts behind the deferral change — a new network route, a new exploit, a service moving into production. Static risk-acceptance registers rarely do this well.

The audit view

To an auditor, a documented, reviewed deferral is evidence of a working risk process. An undocumented one looks like a missed SLA. Every finding is recorded and assessed; context decides the order, and the record shows why.

Book a demo