IAM compliance exposes the access transfer gap in governance

At a glance

What this is: This is an IAM compliance analysis showing that organizations struggle less with policy ideas than with proving complete access governance across onboarding, transfer, offboarding, and reviews.

Why it matters: It matters because compliance evidence now has to cover the full identity lifecycle, which affects human users, NHI access, and any automated access workflow that auditors may question.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Zluri's analysis of IAM compliance, access control, and audit obligations

Context

IAM compliance is the discipline of proving that access is granted, changed, and revoked under documented control, with evidence that stands up to audit. In practice, most organisations still think about it as a reporting exercise, but the article shows the harder problem is lifecycle completeness, especially when access changes hands rather than simply starts or ends.

That matters for human IAM and for non-human identities alike. If a programme cannot demonstrate how access transfers are governed, it will struggle to show that rights were assigned and removed consistently across roles, applications, service accounts, and automation-led workflows.

Key questions

Q: What breaks when access transfer is not tracked separately in IAM compliance programmes?

A: Organisations lose the ability to prove that entitlement changes were approved, justified, and limited to the new business context. That creates audit gaps because joiner and leaver records do not explain what happened in between. In regulated environments, transfer must be treated as its own lifecycle control, especially where access scope changes without a full identity replacement.

Q: Why does IAM compliance get harder when service accounts and human accounts are governed differently?

A: Because auditors need a consistent story about who or what had access, why it had it, and when that access changed. If human access has documented review and transfer logic but service accounts do not, the programme cannot show lifecycle consistency. That inconsistency is especially risky when credentials persist across ownership or workload changes.

Q: How do organisations know whether access reviews are actually supporting compliance?

A: They know it is working only when reviews produce complete evidence, identify real entitlements that no longer fit the role, and trigger remediations that are recorded for audit. If the process generates reports but does not explain approvals, exceptions, or follow-up actions, it is producing paperwork rather than assurance.

Q: Who is accountable when automated IAM workflows make access changes that fail audit review?

A: The organisation remains accountable because automation executes the workflow, but governance defines the control objective, approval model, and retention requirements. If the workflow is misconfigured, the audit failure belongs to the programme design, not to the tool. Compliance teams should therefore treat automated output as evidence that still needs oversight.

Technical breakdown

Why access transfer is the compliance blind spot

Access transfer is the point where an identity keeps its business role but changes its permissions, owner, or application scope. Compliance programmes often document joiner and leaver events well, yet miss this middle state because the identity is still active. That creates an evidence gap: auditors need to see how access was reassigned, approved, and retained only where justified. In IAM terms, transfer is where entitlement drift often starts, because the old access is easiest to leave in place while the new access is added.

Practical implication: Map transfer events as a distinct lifecycle control and require evidence of who approved the old and new access.

Access control policies do not satisfy compliance on their own

RBAC, ABAC, least privilege, segregation of duties, and JIT are control patterns, not compliance outcomes. The article correctly points out that organisations often struggle to choose the right one because regulations ask for demonstrable governance, not just a policy label. The mechanism is simple: a policy defines entitlement logic, but compliance also needs context, review cadence, exception handling, and evidence retention. In other words, a control only helps if the organisation can show when it applied, to whom, and why.

Practical implication: Tie each control pattern to a documented use case and capture review evidence for every high-risk entitlement decision.

Automation changes evidence production, not accountability

Automating provisioning, modification, deprovisioning, and access review reduces manual effort, but it does not remove the need for governance. The system can generate reports, trigger remediation, and apply policy rules, yet the organisation still owns the approval model, the policy scope, and the audit narrative. This is especially important in compliance settings because automated actions can hide bad design if no one checks whether the workflow matches the control objective. Automation is therefore an evidence engine, not a substitute for control intent.

Practical implication: Validate automated workflows against control objectives before relying on their reports as compliance evidence.

NHI Mgmt Group analysis

Access transfer is the missing control state in many IAM programmes. The article shows that organisations often evidence joiner and leaver handling but cannot demonstrate what happened when access was moved from one role, owner, or context to another. That is not a minor reporting defect. It is a lifecycle governance gap that leaves auditors unable to verify whether entitlement changes stayed within policy, which is exactly where compliance drift accumulates.

Compliance language often hides NHI exposure. The same reporting weakness applies to service accounts, API keys, and other non-human identities when ownership changes or workloads move. If a programme cannot explain transfer for human access, it usually cannot explain delegation, reassignment, or persistence for NHI credentials either. That is why identity governance must treat transfer as a first-class lifecycle event across all identity types.

Automation only works when the control model is already explicit. Zluri describes automated provisioning and access reviews as ways to speed compliance, but the deeper issue is whether the underlying approval logic is sound. If role rules, exception handling, and evidence retention are vague, automation will simply make the gap faster and more repeatable. Practitioners should treat automation as a force multiplier for governance design, not as a replacement for it.

Access transfer governance: This article sharpens the case for a named control gap that many programmes still ignore. Access transfer is not onboarding and not offboarding, yet it changes entitlements in ways that can directly affect SOX, HIPAA, PCI DSS, GDPR, and ISO 27001 evidence. Practitioners should build audit logic around that middle state rather than assume lifecycle reports are complete once start and end states are covered.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• For a broader lifecycle view, see NHI Lifecycle Management Guide, which breaks down provisioning, rotation, and offboarding controls for machine identities.

What this signals

Access transfer governance: IAM programmes that only model onboarding and offboarding are leaving a gap exactly where audit evidence tends to fail. The next maturity step is to make transfer, reassignment, and exception handling visible in the same control plane as standard lifecycle events, with clear ownership for both human and non-human identities.

The practical signal for teams is that compliance automation will not fix ambiguous governance. If access rules are not explicit, review output will remain inconsistent, and audit narratives will keep relying on manual interpretation rather than system evidence. That is a structural issue, not a tooling issue.

Teams should also expect lifecycle governance to converge across IAM, NHI, and privilege controls. A programme that can explain why a human entitlement changed but cannot explain why a service account stayed active has not built a coherent governance model, only parallel ones.

For practitioners

• Separate access transfer from onboarding and offboarding Define transfer as its own lifecycle event in JML workflows, with explicit approval, entitlement comparison, and evidence capture before and after the move.
• Document policy choice by use case Map RBAC, ABAC, least privilege, segregation of duties, and JIT to the compliance scenario they serve, then record why each control was selected.
• Require audit-ready evidence for every access change Store who approved the change, what entitlements were added or removed, when the review happened, and which exceptions were accepted.
• Treat automation outputs as control evidence, not control design Review whether automated provisioning and access review workflows actually enforce the intended policy before using their reports for audit submission.

Key takeaways

• IAM compliance fails most often at the access transfer stage, where organisations cannot prove how rights changed or why they remained.
• Automation can accelerate provisioning and reviews, but it does not compensate for incomplete lifecycle design or weak evidence capture.
• The most useful compliance programmes treat transfer, offboarding, and exception handling as auditable controls across both human and non-human identities.

Key terms

• Access Transfer: Access transfer is the lifecycle moment when an identity keeps operating but its permissions, owner, or business context changes. It is distinct from onboarding and offboarding because the identity remains active while entitlement scope shifts, creating a governance point that must be approved, recorded, and reviewed.
• Access Review: An access review is a periodic or event-driven check that compares current entitlements with what an identity should have. In IAM compliance, the review must produce evidence, identify exceptions, and show remediation. Without that trail, the process is inspection theatre rather than control assurance.
• Segregation Of Duties: Segregation of duties is a control that prevents one identity from holding combinations of access that create fraud or error risk. In practice, it is enforced through role design, approval flows, and periodic review. Compliance teams use it to limit high-risk privilege combinations and preserve accountability.
• Just-in-Time Access: Just-in-time access is an ephemeral access pattern where elevated privileges are granted only when needed and removed after the task. It reduces standing privilege exposure, but only when the approval, expiry, and logging model are reliable enough to prove that access was temporary and task-scoped.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Access Management IAM Compliance and Regulatory Obligations. Read the original.