Sarbanes-Oxley internal controls now demand always-on monitoring

At a glance

What this is: This is an analysis of how Sarbanes-Oxley internal controls, ITGCs, and segregation of duties fit together across financial reporting environments.

Why it matters: It matters because IAM, IGA, and PAM teams increasingly underpin SOX assurance, and control design now has to work continuously across human, NHI, and application access.

👉 Read SafePaaS's analysis of Sarbanes-Oxley internal controls and ITGCs

Context

Sarbanes-Oxley internal controls are the control fabric that protects financial reporting from error, fraud, and unreviewed system change. In practice, that means preventive controls block risky actions, detective controls surface exceptions, and corrective controls close the loop when something slips through. For identity teams, the important point is that these controls only hold when access, approval, and monitoring are aligned across people and systems.

The governance gap is rarely the absence of one control. It is the mismatch between access lifecycle, segregation of duties, and the pace at which ERP and other financial systems change. That is why SOX programmes increasingly depend on IAM, IGA, and PAM discipline, plus continuous evidence collection rather than end-of-year sampling.

Key questions

Q: How should teams design SOX controls across IAM, PAM, and ERP systems?

A: Start with the business process, then assign one preventive, one detective, and one corrective control to each high-risk step. IAM should govern who can act, PAM should constrain elevated actions, and the ERP should enforce workflow rules. The control set must be testable end to end, not just defensible in documentation.

Q: Why do segregation of duties failures still happen in mature finance programmes?

A: They happen because SoD is often enforced in one layer while access exceptions, temporary elevation, and application logic live in others. A mature programme can still fail if the same person can influence multiple steps through different systems. The issue is usually integration failure, not lack of policy.

Q: How do organisations know whether detective controls are actually working?

A: Detective controls are working when they find exceptions early, route them to accountable owners, and produce consistent remediation evidence. If reports are generated but never acted on, or if access reviews cannot explain why a violation is acceptable, the control is producing paperwork rather than assurance.

Q: Who is accountable when SOX control deficiencies are found?

A: Accountability sits with the business owner of the process, the control owner, and the leaders responsible for access governance and remediation. Auditors can identify the deficiency, but the organisation must own the fix, the retest, and the evidence that the control now works as designed.

Technical breakdown

Preventive controls in SOX and ITGC environments

Preventive controls are designed to stop misstatement or fraud before it reaches a financial system or report. In SOX environments, that usually means segregation of duties, role-based access control, approval workflows, and change controls that prevent one person or process from both creating and approving high-risk activity. In ITGC terms, secure provisioning and configuration standards do the same job at the platform layer. The architectural point is that preventive control strength depends on how well identity policy, application logic, and approval routing stay aligned.

Practical implication: Map each high-risk financial workflow to an explicit preventive control and verify that provisioning and approvals enforce it consistently.

Detective controls, access reviews, and monitoring

Detective controls do not stop the event, but they make the event visible quickly enough to act. In SOX and ITGC programs, that usually includes log review, exception reporting, privilege monitoring, and periodic access recertification. These controls are only effective when the evidence is complete, the review scope matches the actual access model, and exceptions are routed to people who can interpret the business risk. A control that is reviewed but not acted on is an audit artefact, not a detective control.

Practical implication: Use monitoring and access reviews to identify SoD violations, privileged drift, and unapproved changes in the same reporting cycle.

Corrective controls and retesting after deficiencies

Corrective controls close the loop after a control failure, whether the issue is a provisioning defect, a broken approval path, or an audit finding in a key ERP process. In SOX practice, that means remediation plans, control redesign, documentation updates, and retesting until the deficiency is resolved and evidenced. The technical challenge is not writing the fix, but proving that the control now behaves consistently under the same operating conditions that produced the gap. Without retesting, correction is only intention.

Practical implication: Tie every remediation to a named control owner, a retest date, and evidence that the revised control actually prevents recurrence.

Threat narrative

Attacker objective: The objective is to bypass financial control boundaries and create untrusted reporting or unauthorised transaction capability.

1. Entry occurs when an identity, access, or change path allows an incompatible financial action to proceed through an ERP or ITGC-controlled environment.
2. Escalation follows when weak segregation of duties, privileged access, or poor approval design lets the same party influence multiple steps in the financial workflow.
3. Impact is a weakened SOX control environment, unreliable financial reporting evidence, and audit findings that expose the organisation to restatement and remediation risk.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SOX control design fails when identity governance is treated as audit support instead of operational control. Sarbanes-Oxley programmes often collapse into evidence collection after the fact, but the actual risk sits in how access, approval, and monitoring are configured day to day. That means the real discipline is not documentation volume, it is whether identity controls actively prevent incompatible actions before financial impact occurs. Practitioners should treat SOX control design as an access governance problem first and an audit problem second.

Segregation of duties becomes fragile when ERP access is distributed across roles, exceptions, and temporary overrides. A single SoD policy is not enough if access provisioning, emergency elevation, and change approvals are managed in separate silos. The failure mode is control fragmentation, where no one system can prove that an individual cannot both initiate and approve a high-risk transaction. Practitioners should assume SoD breaks at the seams between IAM, PAM, and application controls.

Continuous controls monitoring is the named concept that matters here because SOX evidence now has to match system tempo. If access can change daily and financial workflows are automated, annual or quarterly testing cannot reliably describe control state at the moment of risk. This is where detective controls become operationally valuable, because they reveal privilege drift, process exceptions, and control failures while there is still time to remediate. Practitioners should align monitoring cadence with the speed of the underlying ERP and identity changes.

Manual control dependency increases both audit effort and operational blind spots. Manual reviews still have a place, but they are weak where volume is high, access churn is frequent, and transaction paths are tightly coupled to production systems. The more an SOX programme depends on human review of repetitive access or change evidence, the more likely it is to miss inconsistency and exception fatigue. Practitioners should prioritise controls that are enforceable in-system rather than only reviewable on paper.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• For programme design, use the NHI Lifecycle Management Guide to align provisioning, rotation, and offboarding with control evidence.

What this signals

Control evidence will increasingly need to be continuous, not periodic. SOX programmes that still depend on quarterly snapshots will struggle to keep pace with role churn, exception approvals, and ERP automation. The practical signal for teams is simple: if a control cannot produce current evidence on demand, it is already out of step with the operating model.

Identity governance is becoming the control plane for financial assurance. As access reviews, SoD enforcement, and privileged oversight converge, finance and security teams will have to share a single view of who can do what, where, and under which approval path. That is where IAM becomes an assurance function, not just an access function.

Continuous controls monitoring should be paired with lifecycle discipline. The programme signal is that access reviews alone will not close the gap if role assignment, elevation, and offboarding are still manually handled. Teams should expect audit pressure to shift toward evidence that identity lifecycle controls are operating in real time.

For practitioners

• Map SOX workflows to control owners Assign every high-risk financial workflow to a named preventive, detective, and corrective control owner so responsibility is clear before audit season starts.
• Test segregation of duties at the application layer Validate that ERP roles, approval thresholds, and emergency access cannot be combined to create and approve the same transaction path.
• Centralise access evidence across systems Pull access data from IAM, PAM, and ERP platforms into one review cycle so recertification reflects the real entitlement picture, not one system at a time.
• Automate exception reporting for high-risk changes Trigger alerts for privileged changes, unusual journal activity, and policy overrides so detective controls operate close to transaction time.
• Retest remediated controls after every deficiency Require post-remediation evidence that the revised control prevents the same failure mode under normal operating conditions.

Key takeaways

• Sarbanes-Oxley internal controls only hold when preventive, detective, and corrective controls work together across identity and ERP layers.
• The main operational weakness is not a missing policy, but fragmented enforcement across provisioning, approvals, monitoring, and remediation.
• Teams that want stronger SOX assurance need continuous evidence, clear control ownership, and retesting after every material deficiency.

Key terms

• Segregation Of Duties: Segregation of duties is the practice of splitting high-risk actions so one person or system cannot complete a sensitive transaction end to end. In SOX environments, it reduces fraud and error risk by separating initiation, approval, posting, and reconciliation across distinct identities or controls.
• IT General Controls: IT general controls are the baseline controls that make underlying systems trustworthy for financial reporting. They typically cover access management, change management, IT operations, backup, recovery, and security configuration, and they are the foundation that supports application controls and audit confidence.
• Continuous Controls Monitoring: Continuous controls monitoring is the ongoing observation of control signals rather than periodic sampling. It uses automation, logs, access data, and exceptions to show whether a control is operating as designed at the time risk occurs, which is especially important in fast-changing ERP and identity environments.
• Entity-Level Control: An entity-level control is a broad governance control that applies across the organisation rather than inside one process. Examples include risk oversight, ethics programmes, audit committee supervision, and whistleblower mechanisms, all of which shape the reliability of lower-level controls.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by SafePaaS: Sarbanes-Oxley internal controls, ITGCs, and segregation of duties. Read the original.