Access requests as an audit-ready control for IAM governance

At a glance

What this is: This is a blog post arguing that access requests should function as an audit-ready IAM control, not a help-desk workflow, because decision lineage and traceability are what auditors and security teams need.

Why it matters: It matters to IAM, IGA and PAM practitioners because access-request evidence increasingly has to prove who approved what, why it was approved, and whether the resulting access still fits policy and risk.

By the numbers:

• 73.9% of organisations say employees still hold access they do not need.

Context

Access requests are the point where entitlement, justification and approval should be tied together. In many organisations, that process still behaves like a ticketing exercise rather than a governed identity control, which leaves auditors with incomplete evidence and security teams with little assurance that access was approved for the right reason.

The governance problem is not the absence of approvals. It is the lack of decision lineage, SoD checks, risk context and post-approval validation. For IAM programmes that cover human users, the same weakness also affects offboarding, recertification and least-privilege enforcement because the request trail does not reliably prove why access existed in the first place.

The article frames access requests as a compliance and assurance issue rather than a workflow convenience issue. That is a typical challenge in organisations that grew access governance around manual review, email approvals and disconnected provisioning systems.

Key questions

Q: Where does an access-request workflow fail when it is used only as a ticketing process?

A: It fails when the organisation cannot reconstruct who requested access, who approved it, what rationale was used and whether the resulting entitlement matched policy. At that point, the workflow produces administration but not evidence, which leaves auditors with a closed ticket and no defensible control story.

Q: Why do access approvals need more than a manager’s sign-off?

A: A manager’s sign-off is only useful when it is tied to policy context, risk scoring and segregation-of-duties checks. Without those elements, the approval may be operationally convenient but still leave the organisation unable to prove that access was justified, traceable and consistent with least privilege.

Q: How do security teams know whether approved access is still justified?

A: They need to compare the approved entitlement with actual usage, then review access that is unused, excessive or inconsistent with the original business case. If the organisation cannot connect the request to subsequent activity, the approval trail is incomplete and stale access can persist unnoticed.

Q: What should auditors look for in an access-request control?

A: They should look for a record that shows the requester, the approver, the business reason, the policy decision and the provisioning outcome in one place. If any of those elements are missing, the organisation is relying on evidence fragments rather than a control that can be independently reconstructed.

Technical breakdown

Why access-request lineage matters for IAM governance

An access request is only useful as evidence if the organisation can reconstruct the full decision path: requester, approver, justification, policy check, provisioning outcome and later use. Without that lineage, the request is just a message or ticket, not a control. Traditional IGA workflows often store approval records but do not preserve the context needed to explain why access was granted or whether the request aligned with policy. That gap matters because auditors examine the decision, not just the checkbox.

Practical implication: preserve request, approval and entitlement context as one governed record, not as disconnected system logs.

How explainability changes access approvals

Explainability in this context means the organisation can show why the system recommended approval, what risk signals were considered and how the final decision aligned with policy. It is not the same as generic logging. The article describes AI-driven context, risk scoring and rationale capture as the mechanism that turns an approval into reviewable evidence. That matters because compliance teams cannot assess a decision they cannot interpret, even if the ticket is closed and the account is provisioned.

Practical implication: require every approval to carry a rationale that can be reviewed later by auditors and control owners.

Why continuous validation belongs after approval

Access governance does not end when access is granted. Continuous validation checks whether the entitlement is actually used, whether usage matches the original justification and whether the access has become stale or excessive. This is especially important in SaaS-heavy environments where entitlements drift quickly and manual recertification lags behind real activity. The article’s core point is that an auditable control includes the full lifecycle from initiation to revocation, not just the initial yes or no.

Practical implication: connect approval records to usage and revocation signals so unused access can be challenged in the same control loop.

Threat narrative

Attacker objective: The objective is to obtain access that appears approved while avoiding a traceable governance record that would expose the approval as unjustified.

1. Entry occurs through a routine access request, where the primary weakness is not attack sophistication but weak governance around justification, policy checks and approver accountability.
2. Escalation follows when manual approvals, email threads or static forms fail to surface SoD conflicts or excessive entitlements before provisioning.
3. Impact appears as audit failure, persistent over-entitlement and inability to prove why access was granted or whether it remained justified.

Breaches seen in the wild

• Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.
• Caesars Entertainment breach 2023: Social engineering of an IT support vendor let attackers copy Caesars loyalty database; about $15 million was reportedly paid.

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

NHI Mgmt Group analysis

Access requests have become a control surface, not an admin task: The article reflects a broader shift in IAM governance, where the approval path itself must stand up as evidence. When access requests are treated as workflow noise, organisations lose the ability to prove entitlement rationale, SoD review and offboarding integrity. The practitioner conclusion is that the request record must be designed for audit from the start.

Decision lineage is the missing control in many IGA programmes: Storage of approval artefacts is not enough if the organisation cannot explain how the decision was made. That gap is especially visible in email-based or form-based approvals, where the record exists but the control logic does not. The practitioner conclusion is that IAM teams need traceable reasoning, not just a completed ticket.

Continuous validation closes the gap between approval and reality: Access that is never used, or is used in ways that diverge from the original justification, signals that governance ended too early. This is not merely a reporting problem; it is an evidence problem. The practitioner conclusion is that approval controls and usage controls have to operate as one lifecycle.

Explainable access is becoming a compliance baseline: Regulators and auditors increasingly care about why access was granted, not only whether it was approved. That pushes IAM programmes toward controls that can show context, risk and policy alignment in a single trail. The practitioner conclusion is that explainability is now part of access governance design, not a nice-to-have feature.

Access-request evidence should be built, not reconstructed: Retrospective spreadsheet assembly is a symptom of poor control design. When evidence has to be recreated after the fact, the governance model is already too fragile for modern SaaS and hybrid environments. The practitioner conclusion is that access-request workflows should emit audit artefacts as they operate.

What this signals

Access-request governance is moving from process convenience to evidence discipline. IAM teams should expect auditors to ask not only whether a request was approved, but whether the approval can be reconstructed as a defensible control decision across the full lifecycle.

Decision lineage: The useful unit of control is no longer the ticket, it is the traceable path from justification to approval to provisioning to usage. When that path is missing, organisations cannot distinguish an access request from an audit liability.

For practitioners

• Formalise request-to-revocation evidence chains Ensure every access request captures requester identity, business justification, approver rationale, entitlement granted and eventual revocation in one traceable record.
• Add risk scoring to approval workflows Use entitlement context, peer access patterns and SoD checks to flag risky requests before provisioning, rather than after audit findings appear.
• Tie approvals to usage validation Compare granted access with real activity so unused or stale entitlements can be reviewed before they become permanent exceptions.
• Replace email approvals with explainable controls Move away from informal approval channels that cannot preserve policy context, because auditors need to reconstruct the decision path, not just confirm a name on a ticket.
• Build offboarding into the access-request lifecycle Treat revocation as part of the original control, so access cannot remain in place simply because the request was once approved.

Key takeaways

• Access requests become weak controls when approvals are detached from policy context, risk scoring and later usage.
• The article points to 73.9% unnecessary access and more than half of organisations with overly permissive accounts as evidence of the governance gap.
• IAM teams should design request workflows to emit audit evidence continuously, not reconstruct it after the fact.

Key terms

• Decision Lineage: Decision lineage is the traceable record of how an access decision was made, including the inputs, policy checks, risk signals, and approver rationale. It goes beyond an approval log by showing why access was granted and how the organisation can defend the choice later in audit or review.
• 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.
• Explainable Access Administration: Explainable access administration means access decisions can be traced to a policy, a reason, and an accountable owner. This matters because AI-assisted or delegated administration can become opaque unless the programme preserves decision provenance and challengeability.
• Audit-Ready Compliance: Audit-ready compliance means maintaining evidence, controls, and decision records in a form that can be reviewed without last-minute reconstruction. For third-party risk, this includes clear due diligence, remediation tracking, and governance documentation that shows how vendor risks were assessed, approved, and monitored over time.

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.