IGA fails when the question is not who had access but whether the underlying business control actually operated. Access certifications can confirm entitlement state, yet they do not prove that approval thresholds, segregation of duties, or manual checks executed correctly. Identity GRC closes that gap by tying access to process controls, evidence, and remediation records.
Why auditors keep asking past entitlement and into control performance
Audit evidence fails when it proves that access existed, but not that the business control actually worked. A clean access review can show that someone approved an entitlement, yet an auditor still has no proof that a two-person check, approval threshold, or exception workflow was executed consistently on the transactions that mattered. IAM and IGA Basics is useful here because it separates entitlement management from control operation.
The practical gap is that IGA often reports on identities, roles, and certifications, while the audit question is about a control objective such as preventing misuse, enforcing segregation, or requiring review before release. That means the evidence set must move beyond “who has access” into “what decision was made, by whom, under what rule, and with what recorded outcome.” Access governance matters, but the evidence has to be tied to the control event, not only the entitlement state.
When the control lives in a manual or semi-manual workflow, the strongest evidence usually comes from timestamps, approver identity, exception records, workflow state, and any downstream reconciliation artifact. Without those fields, a reviewer may be able to confirm that the right account existed, but not that the control was actually operating when the transaction occurred.
What good control evidence looks like in an IGA program
Auditors usually want evidence that is specific enough to reconstruct the control path. For segregation of duties, that means showing the conflict rule, the detected violation or mitigation, the approval of any exception, and the remediation record if the issue was corrected later. For approval controls, it means showing the request, the approver, the approval threshold, the effective date, and the object that was actually released or blocked. Segregation of Duties (SoD) Guide and Access Reviews and Certification Guide both reinforce that the evidence has to prove the control outcome, not just the review activity.
That distinction matters because access recertification can be necessary evidence, but it is rarely sufficient on its own. A certification campaign may confirm that access is still assigned, yet the auditor may still ask whether the underlying business check was performed for each relevant event. If the control is preventive, evidence should show the check before execution; if it is detective, evidence should show the review, escalation, and follow-up within the required window.
Identity governance becomes more credible when it closes the loop from decision to remediation. The most defensible record set usually includes the original entitlement, the operating rule, the exception or approval, and proof that any excess access or failed control condition was removed or escalated. IGA Buyer’s Guide is relevant because platform selection and implementation should support that end-to-end traceability, not just periodic attestation.
Where the evidence gap opens, and how to close it before audit day
The biggest failure mode is treating IGA as a reporting layer instead of a control evidence system. If workflows do not preserve approver context, rule evaluation results, exceptions, and post-decision remediation, the organisation ends up with access data but no defensible control narrative. That is especially weak when access is approved once and then used many times across finance, operations, or privileged workflows. Joiner-Mover-Leaver (JML) Guide helps here because lifecycle events often supply the strongest audit trail for access changes and removals.
Another common gap is role or rule drift. A control that looked sound during design can fail in operation when role definitions, SoD rules, or manual compensating checks stop matching the real process. Auditors will often focus on this mismatch because the existence of a policy is not the same as the policy working at runtime. If the evidence cannot show current enforcement, current exception handling, and current remediation, the control story is incomplete.
Teams that manage high-risk access should expect auditors to ask for more than screenshots. They should be ready to produce raw workflow records, approval logs, SoD violation reports, remediation tickets, and a sample that traces one decision from request through closure. Role Mining and Role Design Guide supports this because a clean role model makes control evidence easier to interpret and less likely to be undermined by role explosion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Auditors need records that show control operation and follow-up, not only access state. |
| AC-6 — Least Privilege | IGA evidence often must show that assigned access stayed constrained to required duties. | |
| AC-5 — Separation of Duties | The question centers on proving SoD and similar business controls actually operated. | |
| Recommendation — Retain workflow, approval, and remediation logs that prove the control executed and was reviewed. Validate that granted access remains minimal and justified for the business role. Document SoD rules, violations, compensating approvals, and remediation outcomes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access governance evidence must demonstrate controlled access decisions and enforcement. |
| A.5.18 — Access rights | Auditors often ask whether access rights were reviewed, changed, or revoked as required. | |
| Recommendation — Maintain evidence that access decisions are defined, approved, and enforced. Keep traceable records of access grants, reviews, changes, and removals. | ||
Practitioner Guidance
What to verify: Verify that every high-risk control has an auditable transaction trail, not just an entitlement snapshot. If the control is manual, make sure the system records who acted, when they acted, what rule they used, and whether the exception or remediation was closed.
Decision rule: If an auditor could ask “did the control operate?” and your current evidence only answers “did the user have access?”, treat the control as under-evidenced and supplement it with workflow records, exception logs, and remediation proof.
What practitioners underestimate: The hardest part is usually not proving access removal or review completion, it is proving that the business control remained consistently enforced after the first clean audit cycle. That is where control drift, exception fatigue, and missing remediation records create the most exposure.
Practitioner takeaway: Build IGA evidence around control execution and closure, not around entitlement state alone, because auditors are testing whether the safeguard operated, not merely whether access was assigned.
Related resources from NHI Mgmt Group
- Why do SOC 2 programmes often fail at evidence rather than control design?
- What should teams do when auditors ask for proof of control effectiveness?
- How should financial institutions implement access reviews that auditors will accept as evidence of control?
- Why do legacy IGA tools fail to control over-entitlement and access drift in complex environments?