Notifications
Clear all
Topic starter
15/08/2026 8:29 pm
TL;DR: For IAM, compliance and audit leaders, the hard part is not defining an access policy but proving it survives role changes, application sprawl and NHI activity across the estate, according to SafePaaS. The core issue is policy assurance: if a platform cannot translate intent into effective privileges, SoD checks and defensible evidence, it is managing intent, not governing access.
NHIMG editorial — based on content published by SafePaaS: policy assurance for access governance and identity governance
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should security teams prove that access policy is actually enforced?
A: They should require evidence that each request was checked against policy rules, reviewed with the right context and either approved, denied or remediated in a traceable workflow.
Q: Why do role-based models break down in complex enterprises?
A: Role-based models break down when role names no longer describe the actual access underneath them.
Q: What should organisations do when access spans multiple systems and business units?
A: They should govern access at the entitlement and process level, then apply the same policy across systems, entities and approval paths.
Practitioner guidance
- Map policy to effective privileges Build access views that show the entitlements and cross-system combinations behind each role so reviewers can see actual exposure, not just labels.
- Move SoD checks into the request path Check conflicts before provisioning, then re-evaluate them when roles, applications or legal entities change so toxic combinations cannot drift into production.
- Treat evidence as a workflow output Capture the request, policy result, approver rationale, mitigation and remediation in the same trace so audit evidence is produced automatically.
What's in the full article
SafePaaS's full article covers the operational detail this post intentionally leaves for the source:
- Platform-specific guidance on turning policy rules into access decisions across ERP and SaaS environments.
- Examples of how federated governance layers coexist with existing IAM, IGA and ITSM tooling.
- Customer case details showing how coverage, fulfilment time and audit findings changed in practice.
- Decision criteria for choosing between centralised IGA, ERP-native GRC and federated policy-based governance.
👉 Read SafePaaS's analysis of policy assurance for identity governance →
Access policy versus policy assurance: where IGA programs fail?
Explore further
15/08/2026 8:29 pm
Policy assurance is the real control objective, not policy administration. Recording what the organisation intends to permit is necessary, but it is not governance. If the platform cannot prove effective privileges, conflict checks, approvals and remediations across the applications that matter, it is managing intent rather than access. Practitioners should judge IGA by the quality of its assurance trail, not by how many identities it can register.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 92% of organisations expose NHIs to third parties, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How do IGA teams know whether their programme is producing real control value?
A: They know it is working when fewer risky combinations reach production, access reviews show effective privileges, exceptions are closed or accepted with a mitigation, and audit evidence is generated automatically from the workflow. If the programme only counts certifications completed, it is measuring activity rather than control.
👉 Read our full editorial: Policy assurance for access governance: why roles are not enough
