Why IAM programmes fail before the tool is even installed
Across information systems built over decades, the missing piece is almost never the platform. It is the operating rules nobody has bothered to write down.
A programme that starts with the right questions
A large organisation recently approached us to launch an IGA programme. Around 20,000 employees, several hundred applications, multiple Active Directory forests, multiple HR systems, several IT teams and several business teams. The sponsor was convinced that the main challenge was to stand up Netwrix Identity Manager quickly and regain control of entitlements.
In the first workshops we did not open the tool. We asked a different kind of question, deliberately more basic.
What actually counts as an identity? What is a manager? When does an identity begin to exist? When does it stop existing? Who decides on entitlements? Who is accountable for them? Which system is the authoritative source?
The answers diverged within minutes. HR did not answer like IT. Security did not answer like the business. Every application had its own entitlement logic. Every Active Directory had its own naming conventions and its own groups. Every team used its own vocabulary to describe the same objects.
The problem was not technology. The problem was that nobody in the organisation had ever been asked to spell out the rules.
The product is not the starting point
Many organisations look for the answer inside the product. They ask us which modules to switch on, which connectors to build first, which workflows to configure. These are fair questions, but they come too early.
We approach it the other way round. The platform becomes a way to explore the information system. The data pulled into it is used to surface the operating rules that already exist in the company — usually held in a few people's heads and rarely written down.
Our job is to turn these implicit practices into explicit rules. An identity governance platform does not create governance. It reveals it, and only then can it automate it.
Four observations from the field
A few situations from recent engagements, chosen because they show up in one form or another across most large organisations.
- 01
Two profiles, one role
Two applications covering the same business domain assign two different profiles to users who, in their own minds, hold the same role. The underlying entitlements do not overlap cleanly. Nobody had noticed, because nobody had ever put the two models side by side.
- 02
Three directories, three logics
Three Active Directory forests grant administrative rights in three different ways. One relies on team-based groups, another on application-based groups, the third mixes both. These are historical patterns that no one can justify anymore.
- 03
Approvals without reading
Managers approve access requests without knowing exactly what the profile they sign off actually contains. The profile label speaks the language of the business; the entitlements behind it speak the language of the systems.
- 04
Two org charts running in parallel
The HR system points to a line manager who is not the one used inside several applications. Approval workflows grew organically, each team built its own functional org chart, and none of them was ever reconciled with the authoritative source.
None of these situations is solved by switching on a feature. Every one of them is solved by putting the facts on the table.
What Netwrix Identity Manager delivers, in the right order
Netwrix Identity Manager is a platform we use regularly, particularly with clients whose roadmap calls for it. We know its components well. Here is how we use them — not as a product demo, but to show the order in which each part earns its place.
- Identity Warehouse
- We do not treat it as a provisioning engine first. We treat it as a mirror. By reconciling several HR sources, several Active Directory forests and a handful of critical applications, it brings the discrepancies to the surface. It is those discrepancies that drive our workshops, not slides.
- Role Management
- We do not create roles inside the tool. We discover them in the data. Once a consistent entitlement pattern appears across a coherent group of identities, it becomes a candidate for formalisation and turns into a business role that can be reviewed and challenged.
- Workflow Engine
- Access workflows already exist, in the form of emails, tickets and informal conversations. The engine does not invent them, it makes them traceable and repeatable. We refuse to encode inside the tool what has never been described outside of it.
- Policy Engine
- A business policy — a segregation-of-duties rule, an eligibility constraint, an attribute-based condition — has to be articulated, debated and owned by the people accountable for it. We only encode into the engine what the business has explicitly accepted.
- Access Requests
- An access request only makes sense once roles, ownership and approval paths have been understood. Without that, the portal simply industrialises ambiguity.
- Recertification
- A recertification campaign validates governance that has already been built. It is not a discovery mechanism. Launched too early, it exhausts managers and produces the appearance of compliance without improving the actual quality of access.
- Reporting
- Once governance is in place, dashboards measure its quality: coverage rate, orphan accounts, drift between the HR source and target systems, campaign completeness. It is not the first step; it is the step that gives meaning to everything that came before.
What the reader should take away
The software matters. At the scale we work at — tens of thousands of identities, hundreds of applications, multiple directories, multiple HR sources — no serious governance holds together without a platform.
But the tool is never the starting point. Our first task is to understand how the organisation actually operates. Once that work has been done, the platform becomes a genuine accelerator. Without it, even the best product only delivers the appearance of governance.
Model first, automate later
Before we connect applications, automate workflows or run the first recertification campaigns, we want to understand the rules that already shape the organisation. Those rules always exist. They are simply scattered across several teams, several systems and several generations of decisions.
This modelling work — patient, rarely spectacular — is what later gives Netwrix Identity Manager and the rest of the IAM ecosystem their leverage. An IAM programme does not begin the day the tool is installed. It begins the moment an organisation agrees to look honestly at the way it works.