You got it. Your tenant works. You just need a consultant to tinker with it from time to time.
But behind closed doors, another request comes in for yet another exception.
And at this point, you have lost track of half of them.
Why it became unmanageable in the first place
Most environments do not become unmanageable because of one terrible decision.
They get there through a long series of reasonable shortcuts.
Speed is the priority. Quality and maintainability can wait because their cost belongs to tomorrow.
Documentation is an afterthought. Another cost.
Meanwhile, requests pile up in your ticketing system. Multiple people touch Intune, changing things, testing things and fixing yesterday's fixes. The dust never settles.
Bugs appear. Technical debt accumulates.
Eventually, your environment starts looking like a hoarder's house. There is probably something useful underneath, but the mountain has become too large to move, and nobody really knows what can safely be thrown away.
What happened?
You vaguely remember Jacqueline from accounting. You will hear a lot about Jacqueline from me.
She asked for a very specific exception, you implemented it and never checked whether she still needed it.
Then there was Martin from marketing... He has local administrator rights on his workstation because of some software neither you nor he is even sure he still uses in 2026.
Finally, your boss asked you to implement a temporary fix for some recent issue. Then another emergency appeared, followed by another one, and the temporary fix disappeared into the pile of fires you had to extinguish.
It is probably still there.
The same thing happens inside the tenant. A user is excluded from a Conditional Access policy. A group receives a special Intune assignment. An application gets deployed for a project nobody has mentioned in two years.
None of these decisions necessarily looked bad when they were made.
The problem is what happened afterwards. There was no owner, no review date and no clear definition of what "temporary" meant.
And exceptions have a tendency to reproduce.
Martin has local admin rights, so someone else asks why they cannot have them too. A special configuration created for one team gets copied for another. An exclusion becomes a group, the group grows, and eventually the exception starts looking like a second standard.
Managed debt and unmanaged debt
Not all technical debt is equal.
Managed debt is debt you know about and deliberately keep because you still need it to operate.
Think of your old car. If it ain't broke, don't change it. But that does not stop you from taking it to the garage once in a while to check that the brakes still work.
You know the car is old. You know why you keep it. You understand the risks and the maintenance cost. And you know that, eventually, something will have to be done about it.
Unmanaged debt is different.
It is the debt you do not even know you still have.
An exception created for a legitimate reason becomes dangerous when nobody remembers why it exists, who still needs it, or what would happen if you removed it.
An exception is a deliberate deviation from your normal configuration or supported service. It may be necessary, but it should remain a conscious decision.
Simply knowing about an exception does not automatically make it acceptable either. A documented security risk can still be a bad decision. The difference is that you now have enough information to assess it and decide what to do.
That is where ownership matters.
An exception needs an owner
Exceptions are not inherently bad. Businesses have legitimate requirements that do not always fit neatly inside a standard configuration, otherwise I would have no job!
The most common mistake is letting IT become the permanent owner of every exception simply because IT implemented it.
IT does not know every job in the company, and it should not be expected to. Accounting knows what it needs to close the books. Marketing knows which tools it needs to do its work. HR, sales and operations all have their own requirements.
Their responsibility is to explain those requirements to IT. If the business cannot explain what it actually needs, IT cannot be expected to design the right solution.
IT's responsibility is different. It needs to understand the technical consequences, find an appropriate solution and push back when the proposed solution creates unnecessary security or operational risk.
There is an important difference between a business requirement and a technical solution.
"I need to run application X to perform this accounting process" is a requirement.
"Give me local administrator rights" is a proposed solution.
Those two things should not be treated as equivalent.
Maybe local administrator rights are actually necessary. Maybe there is another way. Determining that is part of IT's job.
But knowing whether the accounting process still exists three years later is not something IT can decide alone.
Technical data can tell you that an application is still installed or occasionally used. It cannot always tell you whether the original business requirement still exists.
The business owner needs to confirm that the requirement remains valid. IT needs to understand the technical implementation and its consequences. And when an exception creates significant risk, someone with the appropriate authority needs to accept that risk.
Those responsibilities may belong to different people.
The person who submitted the request is not necessarily the long-term owner either. Jacqueline may create the ticket, but the owner might be the person responsible for the accounting process. If Jacqueline leaves the company, the exception should not become ownerless with her.
Without that ownership, Martin keeps local administrator rights for years because nobody is confident enough to remove them.
Where the IT policy fits
This is where an IT policy becomes useful.
The policy sets the rules. Your standards define what normal looks like. And your exception process manages the deviations.
And no, you do not need four 40-page documents to achieve that. You can start with my IT Service Policy Starter Pack.
What matters is having a normal configuration people can refer to and a place to record why you decided to deviate from it.
People also need a clear way to ask IT for something. Not every decision should live inside a Teams message, an email to someone in IT, or a conversation next to the coffee machine.
Requesting something also does not automatically mean receiving the exact technical solution that was requested. The business explains the need. IT evaluates how that need can be supported without unnecessarily compromising security or maintainability.
When an exception is approved, you should at least know:
Why it exists and what it affects.
Who owns the business requirement.
Who owns the technical implementation.
What risk it introduces and who approved it.
When it needs to be reviewed.
That may sound like paperwork, but it is still less work than three years of archaeology.
Give every request a lifecycle
A simple lifecycle can prevent a lot of future debt:
Request: The business explains what it needs and who owns the requirement.
Understand: IT makes sure it understands the actual business requirement, not just the proposed technical solution.
Decide: IT accepts the request, proposes another solution or rejects it when the risk or maintenance cost is not justified. When significant risk remains, the appropriate person needs to approve it.
Implement: The approved solution is implemented with a defined scope, and the important decisions are documented.
Review: Someone confirms that the original requirement still exists and that the exception remains appropriate. A review can also be triggered when something changes, such as the owner leaving or the application being replaced.
Remove or Renew: If the requirement is gone, remove the exception carefully. If it is still needed, renew it deliberately instead of letting it survive by default.
Silence should never mean automatic renewal. Otherwise, your review process becomes a collection of ignored reminders while the exception remains forever.
The important part is simple: an exception needs a beginning, a reason, an owner and an end.
Governance stops the bleeding, but it does not clean the wound
A good request process helps prevent new unmanaged exceptions.
It does not tell you what is already hiding inside the environment.
You therefore have two jobs:
Stop creating new exceptions without ownership or review.
Find the undocumented exceptions that already exist.
That might mean looking through old Conditional Access exclusions, Intune assignments, local administrator grants and app registrations.
Some will still be needed. Some will be obsolete. Some will be impossible to classify without speaking to the business.
Technical data can help you understand what is still active. It cannot always tell you why something exists.
And before removing anything, you may still need to understand the dependencies, test the impact and have a way back if something breaks.
Especially once leaving something in place feels safer than touching it.
How bad is it?
So, where are you today?
| Level | What your environment looks like | Typical signs |
|---|---|---|
| DEFCON 5: Clean | You know what is configured and why. | Exceptions are documented, have owners and are reviewed. Changes follow a reasonably consistent process. |
| DEFCON 4: Dusty | A few things are starting to escape your control. | Old policies, forgotten groups, temporary settings that became permanent and documentation that is slightly behind reality. |
| DEFCON 3: Messy | You can still explain most of the environment, but you need time to investigate before touching anything. | Exceptions are accumulating, ownership is unclear and nobody is completely sure whether some configurations are still required. |
| DEFCON 2: Hoarder's house | Removing something feels more dangerous than leaving it there. | Nobody wants to disable old policies or groups because nobody knows what depends on them. Local admin exceptions and legacy configurations have become normal. |
| DEFCON 1: Don't touch anything | The tenant works, but nobody really knows why. | Documentation cannot be trusted, exceptions have exceptions, changes cause unexpected side effects and troubleshooting means archaeology. |
If you are at DEFCON 2 or DEFCON 1, you probably need a consultant like me.
Not because the tenant is necessarily broken, but because nobody can change it with confidence anymore. At that point, getting things back under control requires understanding what exists, why it exists, what depends on it and what can safely be removed. And sometimes, what you need is an external pair of eyes and someone to push the cleanup forward.
And once you start cleaning things up, there is another question: how do you avoid ending up in the same situation again?
That is what I will cover in a future article.
Finally
A maintainable environment is not one without exceptions. It is one where you can still explain why they exist.
In the meantime, if you don't have an IT policy, use the IT Policy Starter Pack.
It will give you a good place to start.
Define your responsibilities, find the right owners, and give the business its responsibilities back as well.
0 Comments