The exception was temporary. Two years later, it is still there

• Security exceptions
• Risk governance
• Security architecture
• Zero Trust

“We need an exception. Just for a few weeks.”

The request may make perfect sense. A service needs to keep running, an integration is not finished, or an application cannot support the security model we want to apply.

Fair enough. Architectures are built around real environments with real constraints. What happens next is the interesting part.

Weeks pass. The integration slips. The owner changes. Other priorities appear. And the exception that was supposed to last a month is still in place two years later.

The question is simple: is it still an exception, or has it become part of our architecture without anyone explicitly making that decision?

First, understand what it is for

Before approving or rejecting anything, we need to understand what the business is trying to achieve.

Who needs to do what, on which service, for what purpose, and for how long?

“We need an exception” describes a request. It tells us very little about the need behind it.

Imagine a supplier needs remote access to finish a migration. Do they need the whole network? Several servers? One specific application? All day, or only during intervention windows?

Above all, what prevents them from using the access method intended for that service?

Without those questions, we can end up authorising far more than necessary. Removing it later becomes harder, because someone will have started using that broader access as part of their normal way of working.

Understanding the need helps us find a proportionate solution. Sometimes an exception will be necessary. Sometimes we will find an alternative nobody had considered.

An exception needs boundaries

“Temporary access for the supplier” does not tell me enough.

I need to know which identities will use it, which resources they can reach, which actions they can perform, and when that permission ends.

I also need to know which control we are setting aside and what the consequences could be.

Allowing one specific connection between two systems is very different from maintaining permanent administrative access to an entire environment.

Working in a test environment without real information is also different from working in one containing a copy of production data. Calling it “non-production” does not remove the risk associated with the data inside it.

The more precisely we define an exception, the easier it is to control and eventually close.

If we cannot clearly explain what we are authorising, we will probably struggle to check whether it is being used as intended.

Who owns the decision?

Another interesting phrase tends to appear here: “Security approved it.”

Security can assess the risk, propose conditions, and explain the consequences. But the process must make clear who has authority to accept that risk and who is accountable for the affected service.

Technical approval does not replace that accountability.

For me, an exception should let us answer a few basic questions without reconstructing an email chain: who requested it and why; who owns the service; who accepts the risk under the organisation’s governance model; who implements and maintains the agreed conditions; and who must deliver the work needed to remove it.

Several people may be involved. What matters is that responsibilities are clear.

If everyone participates but nobody is responsible for resolving it, the exception has a good chance of staying.

While it exists, how do we reduce the risk?

Being unable to apply a control exactly as intended does not mean leaving the access without any further conditions.

Let us return to the supplier working on the migration.

If we cannot yet use the intended access mechanism, perhaps we can restrict destinations, enable access only during interventions, require additional authentication at an intermediate point, or supervise sessions.

It depends on the case. Not every measure will be available, and none should be treated as equivalent to the original control without assessing it.

We need to understand what risk remains after those measures are applied.

Keeping logs, for example, can help us investigate what happened. On its own, it does not prevent someone from reaching a resource they should not access.

A manual review can also be useful, provided someone owns it and there is a defined frequency. If it depends on somebody remembering when they have time, its effectiveness will be limited.

Compensating controls need owners and evidence that they work, too.

Setting a date does not solve the problem

An expiry date is necessary, but it is not enough.

“Expires on 30 June” sets a boundary. It does not explain what must happen before 30 June so that we can remove the exception.

Does an application need an update? Does the supplier need a different connection method? Must we migrate a service, buy a licence, or assign a team to finish an integration?

That work needs to be identified.

A temporary exception needs an exit plan: actions, owners, and realistic deadlines. If the solution depends on a project nobody has approved or funded, we should acknowledge that from the start.

Otherwise, the expiry date will simply become the day someone requests an extension.

The deadline arrives, and the business still needs it

This will happen. Projects slip and dependencies change.

But “we still need it” should trigger a review, not an automatic renewal.

First, I would check whether the need is still the same. Then whether the scope remains appropriate, whether the agreed controls have been implemented, and what happened to the exit plan.

We also need to understand the impact of removing access. Would a critical service stop? Would one specific task be blocked? Is there an operational alternative?

That information supports a decision to extend the deadline, reduce the scope, add conditions, or escalate the decision to the appropriate authority.

This is not a reason to disconnect a service without assessing the impact. It is a reason to stop using business continuity as a permanent explanation for never resolving anything.

An extension should explain what has changed and what we will do during the new period.

If every renewal contains exactly the same text, it is worth looking at what is happening.

If everyone needs the same exception, review the model

We also need to look at our own approach.

If different teams repeatedly request the same exception, we may be seeing a limitation in the service Security provides.

Perhaps the intended access is too slow. Perhaps it does not cover a legitimate need. The tool may not support certain cases, or the process may be so complicated that teams look for another way to get their work done.

That does not justify every workaround, but it gives us information we should use.

Architecture must let the business operate with a known and managed level of risk. If the model continually forces people outside it, we need to review the model.

And if a need is permanent, we should treat it accordingly: design a sustainable solution, assess its risks, and establish its controls.

Chaining temporary approvals together for years only postpones that decision.

Are we closing exceptions or accumulating them?

Keeping a register is a good start. Then we need to use it.

I want to know how many exceptions are active, how old they are, which have expired, and how often they have been extended. I also want to know which affect privileges, sensitive data, or particularly important services.

But another question matters just as much: how many have been closed because we resolved the underlying cause?

An exception can disappear from the register while still existing technically. Closing the record should therefore include checking that access was removed, the rule was deleted, or the missing control was implemented, as appropriate.

We should also review actual usage. We may be renewing access that nobody has used for months.

Measurement helps us distinguish current needs from habit.

Exceptions need architecture, too

I do not expect an environment without exceptions. I expect an environment where we can explain the ones that exist.

What they are for, what they allow, who owns them, what risk remains, and what must happen to close them.

That requires talking to the business, understanding the technology, and knowing how the service operates. Approving a request is only part of the work.

An exception can be reasonable today and stop being reasonable six months from now.

If it is still necessary two years later, we need to make a decision about how we will deliver that service.

Do we still need an exception, or do we need to resolve the architecture?

Examples are illustrative. Implementation decisions should be adapted to each organization’s requirements and dependencies.