They’re asking if your controls are operating effectively
Auditors test whether controls operated effectively across the full population and period — not whether you own an identity governance platform. IGA evidence often covers only a subset of what auditors require, which is why findings persist after implementation.
“Do you have SailPoint?” isn’t the audit question. “Can you show this control operated effectively, for this population, during this period?” is.
Most teams answer the first question well. They’ve deployed an identity governance platform, they run certifications, and they can point to it during an audit kickoff. Then they’re surprised when that isn’t enough to satisfy the second question, and findings show up anyway.
What auditors are actually testing
Auditors evaluate the effectiveness of controls, not whether an organization owns an identity governance platform. That distinction matters more than it sounds like it should, because it’s easy to conflate “we have a tool for this” with “we can prove this control worked.”
Control effectiveness testing comes down to three things: population completeness (did you test everyone and everything the control was supposed to cover, not a sample that happened to be convenient), evidence retention (can you retrieve proof the control operated, not just describe it), and consistency across the period (did the control operate the whole time, not just when someone checked). None of those three depend on which platform sits behind the scenes.
What the regulators are already flagging
This isn’t a hypothetical gap. It’s a documented, recurring pattern in regulatory inspection findings.
The PCAOB’s 2024 Inspections Spotlight reviewed portions of more than 800 audits across 171 inspected firms and found an aggregate Part I.A deficiency rate of 39% in 2024, down from 46% in 2023. The two most frequent deficiency categories — testing controls with a review element and identifying and selecting the right controls to test — have been the top ICFR deficiency areas for three straight years.
Access controls specifically have shown up in PCAOB inspection findings before. In one documented case covered by Going Concern’s reporting on PCAOB inspection results, inspectors found that an audit firm failed to sufficiently test IT general controls over user access, including failing to evaluate whether administrator-level access to critical applications and supporting databases was appropriate, even after the firm had identified that access during testing. The finding wasn’t about whether a governance tool existed. It was about whether the testing was thorough enough to catch a real risk sitting in plain sight.
Put those two data points together and the pattern is clear: testing controls and testing access are where audits keep coming up short, year after year, independent of what platform an organization runs.
Where does IGA evidence typically run out?
IGA-only evidence tends to run out in the same four places, every time:
- Partial application coverage. IGA platforms report on the applications onboarded into them, not the full population an auditor tests against.
- Missing entitlement-level detail. A role name isn’t the same as a list of what a user can actually do inside a system.
- Segregation of duties conflicts outside the IGA scope. A conflict in an unmanaged application is just as real as one the platform would catch, but it’s invisible if the application was never onboarded.
- Lack of organizational context. Auditors need to know who has access to what, why they have it, and who approved it. A certification record without that context doesn’t answer the question.
The limitation isn’t necessarily any single product. It’s identity governance as a category. IGA was built to manage identities and access requests, not to serve as the evidence system an audit relies on.
[Diagram placeholder: A Venn diagram or coverage-gap visualization showing IGA-managed applications (inner circle) vs. full audit-scope population (outer circle), with the gap labeled “evidence missing for audit.”]
Why this creates more work, not less
When IGA evidence isn’t enough, the work doesn’t disappear. It moves. Audit and IT teams fall back to manual evidence collection, screenshots, and spreadsheets for exactly the systems and questions the platform was supposed to resolve. That’s the opposite of what most teams expected when they invested in an identity governance platform in the first place: fewer manual reviews, not a parallel manual process running alongside it.
If your evidence trail runs out in any of those four places, the question becomes: what would close that gap without replacing what you already have?
What to look for in a solution
Compliance requires more than identity. Closing the four gaps above means adding a layer built specifically for what auditors test, not another identity administration tool. Specifically, look for:
- Full population coverage, not partial application coverage. A solution needs to connect to your IGA platform and every other provisioning source and application in scope, so the population an auditor tests against matches the population the evidence actually covers.
- Entitlement-level detail, not role names. A certifier or auditor needs to see what a role can actually do inside a system, not just what it’s called, to make or verify a defensible decision.
- Segregation of duties analysis across every in-scope system, with business context. Conflicts evaluated against business unit, legal entity, and location catch what matters financially instead of burying reviewers in technical noise.
- A single evidence trail instead of a patchwork. One record connecting access, approvals, SoD checks, exceptions, and remediation, covering privileged access, configuration changes, ERP controls, and transaction monitoring — not separate platform reports, spreadsheets, and screenshots stitched together at audit time.
- Continuous monitoring, not evidence built right before the audit. A running trail across the full period gives auditors what they’re actually testing for: proof a control operated the whole time, not just when someone looked.
How to close the evidence gap without replacing SailPoint
SafePaaS extends SailPoint deployments — not replaces them. Its federated architecture connects to SailPoint and the systems and applications around it, then produces auditor-verifiable evidence that ties access, approvals, SoD checks, exceptions, and changes together, across SailPoint and non-SailPoint systems alike.
For example, when a SOX audit requires evidence of segregation of duties across Oracle EBS and three non-SailPoint-managed applications, SafePaaS produces a single evidence trail covering all in-scope systems — entitlement-level detail, approval history, exception remediation, and continuous monitoring across the full audit period — without a second identity platform or a re-implementation project.
Instead of a patchwork of platform reports, spreadsheets, and screenshots, audit teams get one evidence trail that covers the full population the auditor actually tests.
Frequently asked questions
What are auditors actually testing when they review access controls?
Whether the control operated effectively for the full population, across the full period, with evidence that’s retrievable and consistent. They’re not testing whether a governance platform exists.
Why do audit findings continue after implementing SailPoint?
Because SailPoint’s coverage typically extends to a subset of onboarded applications. Findings continue in the applications, entitlement details, and evidence gaps that sit outside that scope.
What evidence do auditors expect for user access and privileged access controls?
Evidence that shows who has access to what, why they have it, who approved it, whether it was reviewed on a consistent schedule, and whether any exceptions were remediated, across the full population in scope for the audit.
What causes PCAOB deficiencies related to IT general controls?
Insufficient testing of controls, including inadequate evaluation of user access and administrator-level access appropriateness, and failure to select the right controls to test in the first place. These remain among the most frequently cited deficiency categories in PCAOB inspections.
What does a governance coverage assessment check?
A governance coverage assessment maps your in-scope applications, entitlements, and control populations against what your current IGA platform covers, then identifies the specific gaps where auditors will find missing or insufficient evidence. It covers four areas: application coverage completeness, entitlement-level visibility, SoD conflict detection across all in-scope systems, and evidence trail continuity across the audit period.
The takeaway
The fix isn’t proving you own SailPoint. It’s closing the evidence and coverage gaps auditors are already testing for, year after year, in inspection findings that predate any single platform.
Download the SailPoint Value Gap Report to see where your evidence trail runs out — or request a Governance Coverage Assessment to get a mapped breakdown of your coverage gaps.
