Temporary risks shouldn’t become permanent.

I’m comfortable with a business accepting risk. We cannot fix everything at once, and there are times when delaying a service creates more harm than proceeding with a known limitation. I’m much less comfortable when we make the risk sound smaller so the decision becomes easier.

A security exception usually starts with a reasonable explanation. A dependency needs to change. The fix will take longer than the project allows. A control cannot be implemented without interrupting something people depend on. We agree to proceed, record the exception, and promise to come back to it.

Then other work arrives. The people involved move on. The promised replacement slips. Eventually, someone asks why the exception still exists, and nobody has a convincing answer beyond “it’s been accepted.”

I think the problem often starts well before the expiry date.

The rating can decide whether anything gets done

A low or moderate rating can be entirely appropriate. But it needs an explanation that holds up when somebody asks how the system actually works.

A reviewer may understand the risk process without understanding the technical exposure. The delivery team may understand the technology but be under pressure to get it approved. Put those people in a rushed conversation and it is easy for “we think this is manageable” to become a rating nobody has properly tested.

That does not require bad intentions. People want to deliver. They may have operated the system for years without a visible incident. They may believe another control covers the gap. But familiarity with a system, confidence in the team, and pressure on the schedule are different things from evidence that the risk is low.

If the rating understates the exposure, the work to address it can struggle to compete for funding or attention. The exception gets renewed because higher-rated work comes first. The original assessment has helped create the conditions for the risk to stay.

I want the technical team’s input. I also want the reviewer to be able to disagree with it, ask for evidence, or bring in someone with deeper expertise. A healthy review allows the rating to change in either direction as we learn more.

Work through the consequence before choosing the label

Consider a hypothetical service with an unsupported component. “It’s internal” may be offered as a reason to rate the risk low. That is useful context, but it leaves several questions unanswered.

Who can reach it? What privileges does it have? What data does it handle? Could a compromised user or another system provide a path to it? What would stop an attacker, and have we checked that protection? If the service became unavailable, which business activities would stop?

The answer could support a low rating. It could also reveal a much wider exposure than the original description suggested. We need enough detail to distinguish those situations.

NIST’s risk-assessment guidance explicitly addresses uncertainty, including incomplete knowledge of threats, controls and dependencies. I would rather see an assessment explain what we do not yet know than conceal that uncertainty behind a confident label.

That does not mean every unknown should become a high risk. It means recording the assumptions, deciding whether the uncertainty is acceptable, and assigning any investigation needed to support the decision. The depth of that work should fit the potential consequence.

A business deadline is a reason to decide, not a reason to lower the rating

There is a fair conversation to have about the cost of delaying a release, interrupting a service, or replacing a difficult dependency. Security should help the business understand those choices.

But if the evidence supports a significant risk, and the business still needs to proceed, say that plainly. Let the person with the right authority accept it under defined conditions. Changing the assessment to make the approval easier deprives that person of information they need.

I would ask two separate questions: “What exposure remains with the protections we actually have?” and “Are we willing to operate with that exposure for this period?” The deadline belongs in the second conversation. It should not quietly answer the first.

That approach also treats the delivery team fairly. They can explain the real constraints without having to argue that the risk is smaller than it is.

Put names against the decision and the work

“The team owns it” is often too vague. I want to know who is authorized to accept the remaining risk, who will deliver the corrective work, and who will bring the decision back for review. One person may hold more than one responsibility, but none should be implied.

The person doing the work also needs capacity and a realistic plan. Assigning a name without time, funding or the ability to resolve a dependency gives us someone to chase. It does not give us a way to finish.

For a temporary exception, I would expect a concrete description of what will end it: the unsupported component is replaced, the required control is implemented and tested, or the affected service is retired. “Review in six months” tells me when we will talk again. It does not tell me what we intend to accomplish.

NIST CSF 2.0 includes defined responsibilities and tracking of risk responses and exceptions. My practical expectation is that another leader can read the record and understand who has agreed to do what.

Make renewal worth having

When an exception returns for renewal, I want to understand what happened since the last decision. What was completed? What slipped, and why? Are the interim protections still working? Has the service, its exposure or our understanding of the risk changed?

If the work keeps slipping, the next conversation may need to be about funding, priorities or a dependency the team cannot resolve. Repeatedly extending the date without addressing that constraint is not helping them.

Sometimes the honest conclusion is that the organization intends to live with the risk for the foreseeable future. That should be an explicit decision through the appropriate authority and within applicable obligations, with ongoing monitoring and reconsideration when conditions change. Calling it temporary for another year does not make it temporary.

I want exceptions to give teams room to deliver while the business understands the consequences. That requires an assessment people can defend, ownership that survives staff changes, and a plan the organization is prepared to support.

If we have decided to keep a risk, let’s be honest about that. If we have decided to remove it, let’s give someone the means to finish the job.