TL;DR: SOX compliance depends on disciplined control design, access restriction, change tracking, and audit evidence, according to Zluri’s guidance on 13 best practices for financial reporting operations. The practical issue for identity teams is that user access, segregation of duties, and history trails now sit at the centre of audit readiness, not beside it.
At a glance
What this is: This is a SOX compliance best-practices article arguing that audit readiness depends on access control, change management, segregation of duties, and traceable evidence.
Why it matters: It matters to IAM and IGA teams because financial reporting controls increasingly fail or succeed based on identity governance, not just finance process design.
Context
SOX control design only works when identity governance is embedded in the financial reporting process. The article treats access, approvals, and change evidence as part of the control environment, not as separate admin tasks.
That matters because SOX issues often surface where role assignment, privileged changes, and audit trails are weakly governed. For IAM and IGA teams, the question is whether access controls can prove who changed what, who approved it, and whether segregation of duties held throughout the process.
Key questions
Q: What breaks in SOX compliance when access governance is not tied to control design?
A: The control environment becomes hard to defend because access, approval, and change evidence no longer line up with the reporting process. Auditors may still see policies and logs, but the organisation cannot reliably prove who had authority, who changed what, and whether the right person approved it.
Q: When does segregation of duties stop being meaningful in financial reporting controls?
A: It stops being meaningful when one identity can still influence both sides of the same control, even indirectly through exceptions or shared admin paths. In SOX terms, separation must exist in practice, not just in documentation. If approval and execution overlap, the control can no longer provide independent assurance.
Q: How do teams know whether SOX audit evidence is strong enough?
A: Evidence is strong enough when a reviewer can reconstruct the full change path without gaps: who requested it, who approved it, when it happened, and what control or report it affected. If that chain cannot be replayed from identity-linked records, the evidence is incomplete for audit purposes.
A: Both. Access reviews are an IAM activity, but in a SOX context they are also a control validation step that protects reporting integrity. Treating them as separate creates blind spots, because the same entitlement decisions can determine whether a key control is operating as intended.
Technical breakdown
How access governance underpins SOX control design
SOX control design depends on knowing who can see, change, and approve financial reporting data. In practice, that means access scope, role assignment, and approval boundaries must be explicit enough to withstand audit scrutiny. When access is too broad or poorly mapped to job duties, control assertions become hard to defend because the underlying identity model does not match the process being audited.
Practical implication: tie financial reporting access to documented roles and review it as part of the control framework, not as a separate IAM exercise.
Why change management and audit trails are part of identity governance
The article's emphasis on documenting every change reflects a core governance truth: control evidence is only as strong as the trail behind it. Change management in SOX is not limited to code or configuration. It also includes who approved the change, when it was made, and whether the change altered a control relied on for reporting accuracy. Without that chain, auditors cannot reliably reconstruct control operation.
Practical implication: require every access or control change to produce an attributable, time-stamped record that can be traced back to an approver.
How segregation of duties prevents control collapse
Segregation of duties works by separating the people who request, implement, and approve material changes. The point is not bureaucracy, but the prevention of self-approval and unchecked privilege. In SOX environments, the same identity that deploys a control change should not be the identity that signs off on its validity. Where those functions overlap, the control structure can still exist on paper while failing in operation.
Practical implication: enforce approval boundaries that prevent one identity from both changing and certifying the same financial control.
Breaches seen in the wild
- Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SOX control design fails when identity governance is treated as an adjacent process instead of the control itself. The article shows that access, approval, and traceability are not support functions for financial reporting, they are the mechanism by which reporting integrity is established. That makes IAM and IGA part of the audit control plane, not a separate operations layer. Practitioners should treat access governance as a SOX control dependency, not a downstream hygiene task.
Segregation of duties is the control most likely to collapse first when identity governance is weak. The article correctly ties SOX risk to the same person being able to implement and approve a change, which is a classic control failure mode. When role design is loose, exception handling becomes routine and the control loses its independence. Practitioners should assume SoD has failed until the approval path, execution path, and review path are demonstrably distinct.
Audit evidence is only persuasive when identity events are traceable end to end. The article's focus on documented changes, field history tracking, and internal audits points to the same governance requirement: an auditor must be able to reconstruct who did what, when, and under which authority. That is a lifecycle problem as much as a compliance one. Practitioners should design evidence capture around identity-linked events, not after-the-fact document collection.
Access restriction for financial reporting belongs under identity lifecycle governance, not just entitlement cleanup. The article makes clear that limiting access to sensitive systems reduces the chance of manipulation and misstatement, but that only works if access is granted, reviewed, and revoked through disciplined governance. In NHI terms, the same principle applies wherever privileged execution paths exist. Practitioners should align SOX access design with lifecycle controls that keep privilege tightly bounded over time.
Named concept: audit-reconstructable control chain. SOX readiness depends on a control chain that can be reconstructed from identity assignment through approval, implementation, and review. That chain is fragile when access changes are undocumented or when approval is detached from the identity that executed the change. The practical conclusion is that identity governance must produce evidence the audit can replay, not just controls the organisation assumes are in place.
What this signals
Audit-reconstructable control chain: SOX programmes are only as strong as the identity-linked evidence behind them. When access change, approval, and history tracking are unified, audit preparation becomes a control validation exercise instead of a document hunt.
For IAM and IGA teams, the practical shift is clear: financial reporting controls should be reviewed as living identity policies, with segregation of duties and field history tracking measured against the same evidence standard. That is where SOX readiness becomes durable rather than reactive.
For practitioners
- Tighten SOX-related role mapping Map financial reporting tasks to explicit roles so access approvals, control ownership, and review responsibilities are unambiguous during audit testing.
- Separate approval from execution Prevent the same identity from implementing and approving control changes, especially where reporting logic, configuration, or access scope can affect SOX evidence.
- Record every control change Capture the reason, approver, timestamp, and affected control for each change so auditors can reconstruct the full decision trail.
- Review access before audit season Re-certify access to financial systems and sensitive reporting data before testing begins, with focus on users who can alter controls or approve exceptions.
Key takeaways
- SOX control design depends on identity governance because access, approval, and traceability are what make financial reporting controls auditable.
- The article places segregation of duties, user access restrictions, and change history at the centre of control reliability, not at the edges of compliance work.
- Teams that cannot reconstruct who changed a control, who approved it, and when it happened will struggle to defend SOX evidence under audit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Access restriction and review are central to the article's SOX control argument. |
| Recommendation — Review privileged and sensitive account access against CIS-5 to confirm only required users can affect financial reporting. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on who can access and change financial reporting controls. |
| Recommendation — Apply PR.AA-05 to map entitlements for financial systems and evidence every approval boundary. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article recommends limiting access to those who need it for job duties. |
| Recommendation — Use AC-6 to remove unnecessary access to reporting systems and reduce control manipulation risk. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SOX best practices here depend on controlling access and proving it through evidence. |
| Recommendation — Implement A.5.15 controls to keep financial reporting access restricted and reviewable. | ||
Key terms
- 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.
- Audit Trail: An audit trail is a record of who accessed a system, what they did, and when they did it. For PHI environments, it provides the evidence needed to investigate incidents, support breach determinations, and demonstrate that access was attributable to a specific identity or workflow.
- Control Matrix: A control matrix is a structured map that links risks, processes, and specific control activities. For IAM and compliance teams, it is only useful when the matrix points to real identities, permissions, and evidence sources, not abstract policy statements that cannot be tested.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org