Policy assurance for access governance: why roles are not enough

At a glance

What this is: This is an analysis of why access policy alone does not govern access unless it can survive role changes, SoD checks, application sprawl and NHI activity.

Why it matters: It matters because IAM, IGA and audit teams need evidence that policy is enforced in the real estate, not just recorded in a workflow or role catalogue.

Context

Access policy in identity governance is the written intent that says who or what may do what, under which conditions, and with what evidence. In practice, that intent has to survive role changes, business reorganisations, application sprawl and the growing use of non-human identities across business processes.

The problem is not defining the rule. The problem is translating it into effective privileges, segregation of duties, approvals, exceptions and audit-ready evidence across the applications that matter. If that translation fails, an organisation may have policy on paper without policy assurance in operations.

Key questions

Q: What breaks when access policy stops at role names?

A: Roles can hide the privileges that matter most, so a clean-looking catalogue may still contain toxic combinations, duplicate entitlements and hidden SoD conflicts. Once reviewers cannot see effective access, the programme loses the ability to prove that policy was actually enforced. The failure is not policy design alone, but the gap between policy intent and the access the system really grants.

Q: Why do SoD conflicts still appear in well-run IAM programs?

A: Because SoD conflicts are created by privilege combinations, not by role names alone. Two harmless-looking roles can become risky when assigned together, especially after role copying, organisational change or application sprawl. The practical answer is to test access at the entitlement level and re-evaluate it whenever the business or systems change.

Q: How should teams measure whether policy assurance is working?

A: Look for operating-effectiveness evidence, not just policy definitions. A working programme can show who approved access, what was checked, which exception was accepted, what mitigation was assigned and whether remediation actually happened. If those traces are missing or inconsistent, the governance model is recording intent rather than proving control.

Q: Why do non-human identities complicate privileged access governance?

A: Non-human identities complicate privileged access because they often act faster, more frequently, and at greater scale than humans. They may also rely on long-lived secrets, broad scopes, or automation paths that are hard to trace after the fact. Governance must therefore cover lifecycle, scope, and evidence, not just authentication.

Technical breakdown

Policy administration versus policy assurance

Policy administration records the intended access model: roles, rules, exceptions and approvals. Policy assurance goes further by proving that those rules were translated into effective privileges, evaluated for risk, enforced consistently and backed by evidence. The difference matters because a role name rarely exposes the underlying entitlements, SoD conflicts or business context that determine whether access is actually safe. In modern IAM and IGA programmes, assurance is the control objective and administration is only the record of intent.

Practical implication: measure governance by enforced decisions and evidence quality, not by how many policies or roles have been defined.

Why role names hide real access risk

Roles are useful packaging, but they often accumulate privileges, get copied across users and bundle access that should never coexist. That produces role proliferation, where the catalogue looks orderly while effective access becomes harder to interpret. Once that happens, reviewers who see only the role label cannot reliably assess what the identity can actually do, especially when the same named role differs across applications, entities or regions. Governance has to look beneath the role to the entitlements it carries.

Practical implication: review effective privileges and entitlement combinations, not just the role catalogue.

How segregation of duties becomes a policy test

Segregation of duties is the clearest proof that access policy is being translated into control. The article’s model places SoD at the privilege level, before access is granted and again when roles or systems change, because toxic combinations can emerge even when individual roles look harmless. This is why continuous compliance matters: SoD is not a one-time design exercise but a live test of whether the governance model still matches the business process and the application landscape.

Practical implication: check SoD at request time and after material changes, not only during periodic certification cycles.

Threat narrative

Attacker objective: The objective is to exploit weak governance visibility so harmful access combinations survive long enough to affect financial and compliance-sensitive processes.

1. Entry occurs when users, entities or NHI activity are granted access through roles that look acceptable on paper but hide incompatible privileges underneath.
2. Escalation happens when copied roles, privilege accumulation or inconsistent naming bury SoD conflicts inside broad access packages.
3. Impact follows when the organisation cannot prove which effective privileges existed, which exceptions were accepted and whether inappropriate access was prevented or remediated.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy assurance is the real control objective, not policy documentation. An identity programme can define every rule correctly and still fail if those rules do not survive role changes, application differences and business exceptions. The discipline has to prove translation into effective privileges, SoD outcomes and defensible evidence. That is why governance maturity should be measured by operating effectiveness, not catalogue completeness.

Role proliferation is a governance debt, not just an administration nuisance. When roles are copied, expanded and renamed over time, reviewers lose visibility into what the identity can actually do. That debt hides toxic combinations inside otherwise familiar access packages and makes audit defence harder. The implication is that role design alone cannot carry a governance programme across a complex enterprise.

Policy assurance has to extend across human and non-human identities. The article explicitly notes that business activity now includes NHI behaviour, which means the same policy logic must govern service accounts, integration users, bots and human users where they touch material processes. Once NHI activity enters the business workflow, identity governance is no longer only workforce control. It becomes cross-actor control over effective access and evidence.

Effective governance is a coverage problem before it is a feature problem. A platform that works in one ERP or one region but leaves legacy, SaaS or acquired systems outside the model produces a partial control story. The key concept here is governance coverage: the proportion of material applications and identity types under consistent policy, review and evidence. Practitioners should judge IGA on where it reaches, not how many identity records it processes.

Policy assurance is the boundary between compliance theatre and continuous compliance. When exceptions, approvals and remediation are traceable end to end, the organisation can defend access decisions under SOX, ITGC and internal audit scrutiny. When they are not, the programme records intent without proving control. The practical conclusion is that governance platforms must be assessed on their ability to produce evidence as a by-product of work.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
• Read next: NHI Lifecycle Management Guide

What this signals

Governance coverage is the first reality check for any IGA program. The question is not whether policy exists, but how much of the material estate is actually governed with effective privileges, SoD checks and evidence. When legacy, SaaS or acquired systems sit outside that model, the programme can look mature while leaving the highest-risk access paths partially unmanaged.

Access reviews are only as strong as the access model behind them. If reviewers can see only role names, they are being asked to certify a story rather than a control. The practical shift is to treat entitlement-level visibility as a prerequisite for certification, especially where NHI activity and cross-system access blur the boundary between business process and identity control.

For practitioners

• Define policy at the entitlement level Map role names to the privileges they actually carry, then express access rules in terms of effective access rather than broad role labels. This is the only way to see hidden SoD conflicts and duplicate privilege paths across applications.
• Push SoD checks to request time Evaluate proposed access before provisioning and re-check it when roles, business units, entities or systems change. That timing matters because toxic combinations often appear after a move, merger or application update, not during the original grant.
• Track exceptions to closure Require every exception to carry an owner, a mitigation and a removal path, so risk acceptance does not become permanent access drift. Exceptions should not disappear into a ticket queue without a recorded end state.
• Measure governance coverage Inventory which material ERP, SaaS, legacy and locally administered applications are actually under consistent policy, review and evidence. A strong model is only strong where it reaches, including NHI-driven workflows that touch financial processes.
• Build evidence into the workflow Capture request, approval, SoD result, justification, mitigation and remediation in one traceable record so audit evidence emerges from the control itself. That removes the need for separate evidence projects every audit cycle.

Key takeaways

• Access policy becomes useful only when it is translated into effective privileges, approvals and evidence across the real application estate.
• Role proliferation and hidden entitlements make role-based review insufficient on its own, especially when SoD risk sits below the role label.
• The control that changes outcomes is governance coverage, meaning the programme reaches the systems, processes and identity types that actually move risk.

Key terms

• Policy Assurance: Policy assurance is the proof that an access rule was enforced as intended across real systems, not just written down. It includes effective privilege views, approval outcomes, exception handling and remediation evidence that can survive audit scrutiny.
• Effective Privilege: Effective privilege is the real access an entity can exercise after inheritance, delegation, token scope, and connected-system trust are applied. It is often broader than the permissions shown in an identity repository, which is why runtime validation matters.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Time To Governance Coverage: Time to governance coverage is the interval between a new system, entitlement or identity type appearing and that access being brought under policy and review. In mature programmes, the interval is short enough that business change does not create a prolonged blind spot.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.