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.
Why financial reporting access reviews belong to both control planes
Access reviews are an IAM activity because they test whether the right people, roles, and system accounts still have the right access. They are also a control validation activity in a financial reporting context because the review outcome can affect whether a key control is operating as intended. If the same entitlement drives both access and reporting integrity, splitting the work creates gaps.
The practical issue is that a reviewer is not only asking whether access is still needed, but whether the access is appropriate for a control-sensitive process. That is why the review needs to be understood as both an access governance task and a reporting assurance task, with the same evidence serving both purposes when designed correctly.
A useful way to think about it is that IAM owns the identity decision, while SOX cares whether that decision preserves the integrity of the control environment. When a user, privileged account, or application entitlement can influence financial data, the review becomes part of the control chain, not just an administrative cleanup exercise.
What changes when the access review is tied to financial reporting
Financial reporting access reviews need a tighter scope than generic quarterly recertifications. The review should focus on accounts and entitlements that can create unauthorized posting, adjustment, approval, extraction, or override in systems that feed financial statements. That includes direct application access, admin access, emergency access, and any delegated access that can bypass normal workflow.
In practice, the review should ask three separate questions: does the access still match the job or business function, can the access affect a SOX-relevant process, and is the control evidence strong enough to support audit reliance. A review that answers only the first question may still leave a reporting control gap.
This is also where role design matters. If roles are too broad, the review becomes a rubber-stamping exercise. If roles are well structured, the same review can detect entitlement drift, dormant privileged access, and stale exceptions before they distort the control design.
How to organise the work without duplicating it
The cleanest operating model is to run one review process with two outputs: remove or reduce access where it is no longer justified, and retain audit evidence showing how the control was validated. That avoids running two separate campaigns against the same population and then trying to reconcile contradictory results after the fact.
For teams that already use identity governance, the review owner should be the business or system owner for access approval, with IAM or GRC providing control design, evidence retention, and remediation tracking. The review should include escalation paths for unresolved exceptions, because a lingering exception is itself a control outcome that auditors may test.
One practical anchor is the Access Reviews and Certification Guide, which is useful for designing reviews that remove access rather than just collecting approvals. For broader control design, the IAM and IGA Basics guide helps separate identity governance from pure administration. Where segregation of duties is a material issue, the Segregation of Duties (SoD) Guide shows how to keep financial reporting controls from being undermined by toxic combinations of access.
Risk and Threat Considerations
When financial reporting access reviews are treated as either IAM-only or SOX-only, organisations create two kinds of exposure: stale access may survive longer than it should, and control evidence may become too weak for assurance purposes. In a reporting environment, that means an entitlement can remain in place even after the business need has disappeared, or a reviewer can approve access without understanding its effect on the control boundary.
Failure mechanism: Broad roles, delayed recertification, and weak exception handling let inappropriate access persist in systems that influence financial reporting, while the review record fails to demonstrate that the control was tested at the right level of precision.
Impact: The organisation can end up with unauthorized changes, ineffective SoD enforcement, audit findings, remediation churn, or a weakened basis for relying on the control during SOX testing.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access reviews validate whether reporting-related account access remains justified. |
| AC-6 — Least Privilege | SOX-sensitive access should be limited to the minimum needed for reporting duties. | |
| AU-6 — Audit Review, Analysis, and Reporting | Access review evidence supports control monitoring and auditability for reporting processes. | |
| Recommendation — Review and remove unnecessary account access to systems that affect financial reporting. Enforce least privilege for accounts that can affect financial reporting. Retain review evidence that shows who approved, challenged, or removed access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Financial reporting access reviews are an access-control governance activity. |
| A.5.18 — Access rights | The question is about validating and maintaining appropriate access rights over time. | |
| A.8.2 — Privileged access rights | Reporting systems often hinge on privileged access that needs tighter review. | |
| Recommendation — Define and operate access reviews for reporting systems as a governed control. Recertify access rights for reporting systems at a defined cadence. Tighten review and approval of privileged access tied to financial reporting. | ||
| CIS Controls v8 | CIS-5 — Account Management | Access review and recertification are core account-management controls. |
| CIS-6 — Access Control Management | SOX-relevant access must be controlled, reviewed, and remediated when inappropriate. | |
| Recommendation — Continuously validate and remove unnecessary access rights. Restrict access to reporting systems and remediate exceptions promptly. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | Access reviews support control operation over systems that affect reporting integrity. |
| Recommendation — Demonstrate that logical access is approved, reviewed, and removed when no longer needed. | ||
Practitioner Guidance
What to prioritise: Review the accounts and entitlements that can change, approve, or feed financial data before you spend time on low-impact access. If an entitlement cannot influence reporting, it should not be consuming SOX review effort.
What to verify: Make sure every review item has a clear process owner, an explainable business purpose, and a defined remediation path when access is no longer justified. If reviewers cannot explain the control impact of the access, the review design is too loose.
Practitioner takeaway: Treat the review as one control with two accountability lenses, not two separate exercises. That is the best way to keep access decisions accurate, evidence usable, and reporting controls defensible.
Related resources from NHI Mgmt Group
- Should organisations treat MFA as part of compliance, access governance or user experience?
- When should organisations treat agent output integrations as part of access governance?
- How should organisations manage third-party access as part of IAM governance?
- Should organisations treat data discovery as part of IAM governance?