Identity governance and SOX compliance are different programs because they are bought by different teams with different success metrics. IT and Security purchase IGA platforms for provisioning efficiency and access automation; SOX and Internal Audit need financially relevant access-risk evidence capable of independent auditor reperformance. When audit isn’t in the room during scoping, coverage follows IT’s priorities — not the SOX-in-scope application list.
The team that bought SailPoint and the team whose job depends on what it produces are often not the same people, and they usually weren’t in the same room when the platform was scoped.
That’s not a criticism of either team. IT and Security typically evaluate, purchase, and scope identity governance platforms. SOX and Internal Audit typically get consulted late, or not at all. Both groups measure success differently, and that difference is a root cause of the value gap organizations run into later.
IT measures identity lifecycle efficiency and governance automation. SOX and Internal Audit measure whether access-risk controls operated effectively, financial risk was evaluated correctly, and evidence can withstand external audit. Those are different outcomes.
If you’re the IAM Director or CISO who selected and scoped SailPoint, none of this is a criticism of that decision. The goals that drove the purchase were legitimate. The gap isn’t in what you bought — it’s in who was in the room when it was scoped.
What IT and Security are optimizing for
The goals that usually drive an IGA purchase are legitimate: faster provisioning, automated access requests, identity lifecycle management, and less helpdesk load. Those are real problems worth solving, and SailPoint solves them well.
Those capabilities are essential to modern identity governance. They are not, by themselves, evidence that financially relevant controls are operating effectively.
None of those goals are wrong. They’re just not the same goals SOX compliance requires, and nothing in that buying process was built to check whether they were.
What does SOX audit need from identity governance?
SOX and Internal Audit require complete population coverage, entitlement-level detail, segregation of duties analysis, and an evidence trail capable of independent auditor reperformance. Specifically:
- Complete population coverage of financially relevant applications. Not just the applications already onboarded into the IGA platform, but every in-scope system the external audit will test.
- Entitlement-level detail instead of role labels. Audit doesn’t need to know a user has the “Controller” role. It needs to know that role can post journals, access payables, reverse entries, and create liabilities. That’s the detail a certifier needs to make a defensible decision, and the detail an auditor expects to see evidenced.
- Segregation of duties analysis across every in-scope system. Not just the systems already connected to the IGA platform, but every financially relevant application in the SOX scope.
- Evidence that ties access, approval, and review together for every period under test. A trail connecting access, approvals, SoD checks, exceptions, and remediation — not IGA reports reconciled against spreadsheets by hand.
For the CFO and Director of Financial Controls, the risk is that access-related control deficiencies become material weaknesses in the audit report — because the applications and entitlements that create financial risk were never in scope.
For the ITGC Control Owner, the requirement is evidence that each control operated effectively for every period under test, not just that a certification was completed on schedule.
A completed certification does not necessarily prove financial risk was evaluated. In many ERP environments, the access object shown during review sits several layers above the privileges, responsibilities, functions, and inherited access paths that actually create financial risk.
If audit wasn’t in the room during scoping, there was no mechanism for those requirements to shape which applications got onboarded first, or at all. Onboarding priorities followed IT risk, not the SOX-in-scope application list, because nobody was asking about the SOX-in-scope application list.
Audit requires complete entitlement populations to be evaluated against financially relevant risk, reviewed by the appropriate control owner, remediated where required, and evidenced in a manner capable of independent auditor reperformance.
Why this produces the same value gap, from a different angle
This is the “why” behind the coverage and evidence gaps identity governance keeps running into: partial application onboarding and manual evidence collection persist because the platform was scoped around IT and Security’s priorities, not audit’s. The applications that matter most for a SOX audit were never guaranteed a seat at the onboarding table.
It isn’t a failure of the platform. It’s a mismatch between who bought it and who has to prove compliance with what it covers.
How do you align an existing IGA deployment with SOX requirements?
It’s not too late to align an existing SailPoint deployment to SOX requirements, and it doesn’t require re-scoping or replacing the platform. It starts with a straightforward comparison: map the applications currently onboarded into SailPoint against the actual SOX-in-scope application list, and see where the two lists diverge.
That gap: the SOX-in-scope applications that never made it into the original IT and Security scoping, is where the work is. Closing it means extending governance to those applications, not starting over.
Frequently asked questions
Why do audit findings continue after buying an identity governance platform?
Because the platform’s onboarding priorities were typically set by IT and Security, based on their own goals, not by audit’s requirements for population coverage and evidence. Applications audit needs covered may never have been part of the original scope.
Who should be involved in evaluating an IGA solution for SOX compliance?
SOX Program Leads and Internal Audit, alongside IT and Security. Without audit at the table, onboarding priorities reflect IT risk rather than the SOX-in-scope application list, which is what an audit actually tests against.
What’s the difference between what IT needs from IGA and what audit needs?
IT typically needs faster provisioning, automated access requests, and reduced helpdesk load. Audit needs complete population coverage, entitlement-level detail, segregation of duties analysis, and an evidence trail across every in-scope application and period. Those are different requirements, and satisfying one doesn’t satisfy the other.
How does the buying process affect whether an IGA platform supports SOX compliance?
If audit wasn’t part of scoping, the applications it depends on for evidence may never have been prioritized for onboarding. The buying process determines coverage, and coverage determines whether audit’s requirements get met later.
Why isn’t identity governance the SOX control of record?
Identity governance platforms manage identity workflows and certifications. SOX requires organizations to demonstrate that financially relevant access risks were evaluated correctly, remediated where necessary, and supported by evidence capable of independent auditor reperformance. Those are related objectives, but they are not the same.
What’s the financial risk if our identity governance platform doesn’t cover SOX-in-scope applications?
If IGA coverage doesn’t extend to financially relevant applications and entitlements, access-related control deficiencies may not be detected before the external audit. The risk is a control gap finding, a remediation deadline imposed by auditors, or in the most serious case, a material weakness in the SOX audit report — which can trigger remediation costs, management time, and in some cases, required public disclosure.
How do you align an existing SailPoint deployment with SOX requirements?
Start by mapping the applications currently onboarded into SailPoint against your actual SOX-in-scope application list. The applications that appear on the SOX list but not in your IGA deployment are the coverage gap. Closing it means extending governance to those applications — not re-scoping or replacing the platform.
The takeaway
SOX teams typically don’t buy identity governance platforms because the purchase was never scoped as a compliance decision, but compliance outcomes depend on it anyway. Closing that gap means aligning coverage to what audit actually needs, not asking IT to buy a second tool.
Download the Governance Coverage Assessment to map your SOX-in-scope applications against your current IGA coverage.
