Imagine a security review that ends with a reasonable decision.

There is an access-control finding in a customer-facing application. Engineering understands the issue, but fixing it properly means changing a shared component. A major release is two weeks away. The team agrees to put a temporary restriction in place, accept the remaining risk and revisit the fix next quarter.

Someone records the decision. Everyone moves on.

By the next review, the release has slipped. The engineer who understood the finding has moved to another team. The temporary restriction may still be there, but nobody has checked whether the application has changed around it.

The finding has not been fixed. It has simply become harder to remember.

A security finding marked Risk accepted connected to a next-quarter calendar, asking who checks the review date.

The decision made sense at the time

Security teams have to make these calls. There are more findings than available engineering hours, and some fixes carry their own operational risk.

A documented exception can be a sensible way to handle that. It gives the organisation a way to say: we understand this issue, we know what remains exposed, and an authorised person has agreed to carry that risk for a defined period.

What deserves more attention is what happens after the approval.

A decision made before a product launch may look different after the application gains more customers. An internal service may become externally accessible. A compensating control may depend on a configuration that another team later changes.

The approval remains in the record. The circumstances behind it may no longer exist.

“Next quarter” needs an owner

An expiry date helps, but a date by itself cannot organise a retest, confirm a control or find space in an engineering sprint.

Someone needs to own the return conversation.

Before approving an exception, it should be possible to answer a few ordinary questions:

  • Who is responsible for getting the finding reviewed again?
  • What is being done to limit exposure while the fix waits?
  • What evidence would show that protection is still in place?
  • What happens if the fix is still unavailable when the exception expires?

That last question often gets left until the reminder arrives.

By then, the same delivery pressure may still exist. The easiest response is another extension, sometimes with the original justification copied into a new request.

An extension may be justified. It deserves a fresh decision based on the application as it exists today.

What the dashboard stops showing

Suppose a dashboard counts overdue remediation work but excludes approved exceptions. That can be a legitimate way to define the metric. Yet the headline number can improve even though some of the underlying weaknesses remain.

Anyone reading it needs enough context to tell what changed.

Were findings independently verified? Were exceptions approved? Did scope change? Are accepted risks approaching review?

Those are different outcomes, and they lead to different conversations.

A security head reviewing accepted risk should be able to open a record and see the original finding, the approval rationale, the interim controls, the responsible people and the next review date. Reconstructing that story from a ticket, a spreadsheet and someone’s inbox makes every review more expensive than it needs to be.

The useful conversation happens before expiry

Waiting until the final day leaves very little room to act.

A review held early enough can establish whether Engineering has started, whether the temporary protection remains appropriate and whether the original assumptions still hold. If another extension is needed, the approver has time to examine it.

The useful question is more specific than “Can we renew this?”

It is: “Given what has changed, are we still comfortable carrying this risk?”

Sometimes the answer will be yes. Sometimes the finding needs to move back into active remediation. Sometimes leadership needs to resolve a capacity or ownership problem that the team cannot settle alone.

The record should make that decision easier.

At your next security review, pick one finding accepted last quarter. Try to establish who owns it now, whether its interim controls still hold and what will happen at expiry.

If those answers take several people and a search through old messages, that is a useful place to start.