Your governance model is probably built around the wrong thing

We spend too much time looking at the object

When people talk about identity governance, the conversation often revolves around controls, reviews, policies, and approval processes. Yet some of the most time-consuming governance problems I encounter have nothing to do with any of those things.

They’re caused by a lack of context.

Most of us have encountered it at some point. A group created years ago with no meaningful name, no description, no obvious owner, and no documentation explaining why it exists. An application nobody remembers implementing. A service principal that suddenly appears in an audit report with permissions nobody feels comfortable approving, but nobody feels comfortable removing either.

Before you can decide whether something should be changed, reviewed, or removed, you first need to figure out what it is. Who created it? Why was it created? Does anyone still use it? Is there automation behind it? Is there another system that considers itself the source of truth?

In many cases, understanding the object takes longer than fixing the problem.

When the fix doesn’t stick

I’ve lost count of how many times I’ve seen someone finally gather enough information to make a change, only to discover a few days later that their carefully applied fix has been overwritten by a provisioning process, a synchronization engine, Terraform, or some automation nobody knew existed.

The change itself wasn’t wrong.

It was made in the wrong place.

What’s interesting is that we already understand this concept in other parts of IT. If an employee’s name is incorrect in Microsoft 365, most organizations wouldn’t update it directly in Microsoft 365. They would update the HR system. If a distribution list is synchronized from another source, nobody expects Exchange to be the right place for managing membership. If a firewall rule is deployed through Infrastructure as Code, changing it directly in the management console is usually little more than a temporary workaround until the next deployment overwrites it.

In all of these situations, we instinctively understand that the right place to make a change is the place that owns the data.

Yet when it comes to identity governance, we often seem to forget that principle.

The problem isn’t the object

Instead, we tend to organize governance around object types. Group governance. Application governance. Service principal governance. Agent governance.

At first glance, that feels logical. Different object types have different risks, different lifecycle requirements, and different control models.

But after spending years working with identity governance, I’m no longer convinced that’s where governance should begin.

Take a group as an example. One group may be managed through Terraform, another through an IGA platform, and a third directly in Entra. From a directory perspective they’re all groups. From a governance perspective they’re entirely different.

A missing owner on a Terraform-managed group should result in a change to code. The exact same finding on a manually managed group may require a completely different process.

The object type hasn’t changed. The system that has authority over it has.

Maybe We’re Governing the Wrong Thing

I think many governance programs are very good at classifying objects, but far less effective at defining where authority actually lives.

As environments grow, more platforms are introduced. Governance products, provisioning systems, automation platforms, Infrastructure as Code, application-specific workflows, identity governance tools, and now increasingly AI-related services. Each one solves a problem and adds value. But each one also introduces another place where ownership needs to be understood.

Before long, a single object may be touched by multiple systems. Access is approved in one platform, provisioned through another, reviewed somewhere else, and reported on by a fourth tool.

Everybody interacts with the object, but responsibility becomes increasingly difficult to understand.

Ironically, the response is often to introduce even more governance. Another process. Another review. Another platform. Another workflow.

I’m not convinced that’s always the answer.

The more environments I work with, the more I find myself believing that good governance starts with something much simpler: understanding where authority lives.

Who can create the object? Who can change it? Which system is the source of truth? And what happens if someone changes it somewhere else?

Those questions tell us much more about how an object should be governed than its object type ever can.

Governance starts with authority

Maybe that’s why the objects that cause the most frustration are rarely the ones with the highest risk. They’re the ones where nobody knows who is actually in control.

Once authority becomes unclear, every governance task becomes harder than it needs to be. Reviews become investigations. Remediation becomes guesswork. Even simple changes become risky. And that has a business cost. People spend time figuring out what they are allowed to change, remediation takes longer, and organizations end up adding controls to compensate for a lack of clarity.

What an object is certainly matters.

But knowing who has authority over it, where the source of truth lives, and where changes should be made is often what determines whether governance works in practice.