Should IAM teams treat directory governance and IGA as one programme?

Why directory governance and IGA belong in the same operating model

directory governance is not a side process that sits next to IGA. It is the execution layer where approvals, group membership, entitlements, and removals are actually enforced in the directory and downstream applications. If the governance model and the operational directory controls diverge, the programme becomes slower to remediate and harder to evidence.

The practical test is simple: if a request is approved but not applied, or access is removed in policy but remains effective in the directory, the organisation does not have one control loop. That is why teams should treat directory governance as the place where lifecycle policy becomes measurable state, not as a separate administrative workflow.

When the two are integrated, the same process can support joiner, mover, and leaver changes, role changes, access reviews, and exception handling without duplicating ownership. That is also where concepts like role design, recertification, and access removal become operationally consistent rather than document-only.

What breaks when IAM and IGA are split

Split ownership usually creates handoffs between requesters, approvers, directory admins, and application owners. Each handoff increases latency and the chance that stale access, orphaned entitlements, or partially completed removals will persist. The result is not just more tickets, but weaker assurance that the actual access state matches the approved state.

A second failure mode is evidence fragmentation. If approvals live in one system, directory changes in another, and reviews in a third, audit and recertification become reconciliation exercises rather than straightforward control evidence. That is why lifecycle controls need a shared view of request, assignment, review, and revocation across the programme.

This is also why role governance and access reviews should not be treated as separate disciplines from directory operations. A role model that is not maintainable in the directory, or a review process that cannot drive removal, will eventually produce role explosion, privilege creep, and inconsistent exceptions.

How to run one lifecycle programme without losing control detail

One programme does not mean one team owns every task. It means one lifecycle policy, one entitlement model, and one evidence path. The operating model can still separate policy, directory administration, application ownership, and audit review, but all four should report into the same lifecycle standard and the same removal objective.

For IAM leaders, the most useful design choice is to anchor the programme around the events that change access state: join, move, leaver, access request, recertification, exception expiry, and emergency removal. Those events are where directory governance and IGA overlap in practice, and they are the moments that should trigger workflow, logging, and verification.

Good integration also means the directory is not treated as the only source of truth. It is a control point, but the programme still needs authoritative ownership, role definitions, review cadence, and escalation rules. IAM and IGA Basics is a useful reference for aligning those responsibilities into one model.

Risk and Threat Considerations

When directory governance is separated from IGA, organisations tend to accumulate stale access, excessive permissions, and unreviewed exceptions. That creates avoidable exposure because the approved entitlement and the effective entitlement drift apart, especially across leavers, role changes, and temporary access.

Failure mechanism: approvals, recertification, and revocation are handled in different flows, so a granted entitlement is never fully removed or a directory change never reaches the downstream control point. Over time, this produces lingering access that is hard to spot and easy to inherit.

Impact: stale or excessive access expands the blast radius of account compromise, weakens audit defensibility, and makes removals slower during incidents, employee exits, or access-review campaigns.

Practitioner Guidance

What to prioritise: Define one lifecycle owner for the policy, one operational owner for directory enforcement, and one evidence owner for reviews. If those three roles are not explicit, the programme will drift back into ticket handling instead of control management.

What to verify: Check that every approved access path has a corresponding removal path, every directory group or entitlement is attributable to an owner, and every recertification can trigger actual revocation rather than a record update only. Access Reviews and Certification Guide is directly relevant to making that closed loop work.

What good looks like: A joiner, mover, leaver change can be requested once, approved once, applied once, reviewed once, and removed once, with a traceable record from decision to directory state. At that point, directory governance is no longer separate from IGA, it is the way IGA is delivered.

Practitioner takeaway: Treat the directory as the control surface and IGA as the governing model, or you will get process duplication without real access reduction.

Related resources from NHI Mgmt Group

• How should security teams use IAST and RASP in NHI governance?
• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• How should security teams govern Active Directory service accounts?