Governance Debt: Technical Debt’s Forgotten Cousin

Technical debt is a familiar concept.

A shortcut is taken because the project needs to move forward. Documentation is left for later. A temporary solution becomes permanent. Nobody worries too much about it at the time. Governance debt often starts the same way.

“We need to get the product out. We can sort out governance later.” It sounds reasonable. Governance should not become a six-month approval process that stops people from building things.

But governance is an unavoidable fact of development. Someone is deciding who gets access, which identities can do what, who owns the application, and where changes should be made.

When those decisions are made without thinking about how they will be managed later, the problems simply show up somewhere else.

Now, nobody knows who owns the old service principal. An application has powerful permissions but no clear reason for them. Two systems are both updating the same group. Someone changes something manually in Entra, only to have it overwritten by the next deployment.

Suddenly, a simple question like “Can we remove this?” becomes a small investigation project. That is governance debt.

You might be asking “How do we avoid this?” The answer is not to build a huge governance machine that slows everything down. It is to put the right controls in the right places from the beginning, automate what can be automated, and be clear about the decisions that truly matter.

Find what you actually have

So how do you start paying down the debt without creating another delivery bottleneck?

The first problem is usually knowing where to start. Governance debt is usually spread across the environment, and once you start looking, you will find more problems than first expected. There are applications without owners, groups nobody remembers creating, service principals with permissions that have outlived the project that needed them, and objects where nobody is quite sure which system is supposed to manage them.

The temptation is to start fixing the first things you find. I would resist that.

Pick one area that matters to the organization and build a picture of what you have. Applications, groups, service principals or managed identities are good places to start.

For each object, collect enough information to answer some basic questions:

• What is it?
• Why does it exist?
• Who is accountable for it?
• What does it have access to?
• Where is it managed?
• Is it still needed?

The first inventory does not need to be complete. You are looking for patterns, not perfection.

In my experience, the patterns are often more interesting than the individual objects. One missing owner is a cleanup task. Hundreds of missing owners usually point to a governance problem. If large parts of the application estate have no owner, descriptions provide little value, or nobody knows which system manages a group, those are patterns worth investigating.

Understand what is actually wrong

It is easy to reach for a quick fix and correct the missing data right there and then. But what you are looking at is often just a symptom. The real problem is what caused the gap in the first place. Fixing the data does not fix the problem. You need to fix what caused it if you want an environment that is easy to manage.
When Bob from a consulting firm doing a security assessment asks who has access to HR data, you want to be able to answer quickly and with confidence. You do not want to start an investigation to find out.

The goal is not to make the inventory look complete. It is to understand why the gap exists.

Prioritize based on risk

Look at what the object can access, what could happen if it were misused or removed, and whether someone is accountable for it. A group with a poor name but a clear owner and lifecycle is often less urgent than an application with powerful permissions that nobody is willing to take responsibility for.

If you do not prioritize correctly, you can easily spend three months fixing naming conventions while a much higher-risk problem sits quietly in production.

Find where the problem should be fixed

Finding a problem in Entra does not necessarily mean that Entra is where it should be fixed. Changing the object manually in Entra might fix the problem for now, but the next deployment or synchronization can simply put it back the way it was.

A group might be defined through Infrastructure as Code. Access might be provisioned through an IGA platform. Application information might come from another system. Entra may simply be where the result happens to be visible.

Before changing anything, find out where the object is managed. Fix it at the source, and you are much less likely to have the same problem come back again.

Decide who owns the decision

Knowing where something is managed is only part of the problem. You also need to know who gets to decide. Those are not necessarily the same thing.

One platform might handle access requests and approvals. Another might create the underlying groups. Entra might enforce the resulting access. That is perfectly reasonable if the boundaries are clear.

The problem starts when several systems can approve the same access, several automations can change the same object, or nobody knows which system gets the final say.

For important governance activities, I want two questions to have clear answers:

If you cannot answer both, you probably have some governance debt to pay.

Learn from the first fixes

You will probably have a long list of things that could be fixed. Resist the urge to fix them.

Pick a small number of high-value problems and follow them all the way through. Not just until the object is fixed, but until you understand what the fix tells you about the way governance works.

Following issues back to where they originate often reveals bigger governance problems. The missing owner may actually be an organizational problem. The source of truth may not be authoritative. Two governance platforms may have overlapping responsibilities.

At that point, you are no longer cleaning up objects. You are learning how governance actually works in your environment. Doing this with twenty objects is often more useful than creating a remediation plan for twenty thousand.

Make the fix stick

Fixing the existing problems is only half the job. If new objects are created with the same gaps, you will be having the same conversation again in a few years.

By now, you should know which information actually matters, and which does not. Use that when new objects are created. An owner, a meaningful purpose, a clear management source and an expected lifecycle are a good starting point. The exact requirements should depend on the type and risk of the object.

These requirements need to be part of the process rather than something someone has to remember. If objects are created through code, put the requirements and validation there. If they are requested through a workflow, collect the information before approval. If administrators can create them directly, use policy, templates, automation or monitoring to catch the gaps.

The goal is not to make creation harder. It is to make the right thing the easiest thing to do.

Measure whether it is actually improving

What matters is measuring whether governance is improving, not just whether more fields have been filled in.

A dashboard showing that 98% of objects have an owner might look fantastic. It is less impressive if the owner is a generic team account assigned to thousands of unrelated objects. You have not improved governance. You have just made the spreadsheet happier.

More useful measures are whether high-risk objects have accountable owners, whether management sources are known, whether privileged access has been reviewed, and whether people can answer ordinary governance questions without starting an investigation every time.

Governance debt is not a cleanup project

Governance debt is rarely the result of one terrible decision. In assessments, I usually find the accumulation of hundreds of reasonable decisions, changing responsibilities, abandoned projects and undocumented assumptions that nobody revisited later.

Governance does not have to slow delivery down. But treating it as something that can be added later does not make it disappear. It just moves the cost further down the road, where even simple changes become harder to understand and harder to make safely.

A perfectly clean environment is not realistic. I am not sure such a thing exists outside diagrams and sales presentations anyway.

At the end of the day, what matters is that people understand the systems they are handling, know who gets to make the decisions, and know where changes should be made.

All you need to do is stop accumulating debt faster than you can pay it down.