Segregation of Duties as a SOX Control Objective

Segregation of duties is one of the oldest ideas in internal controls, and under SOX it is also one of the most enforced. Auditors do not treat it as a best practice. They treat it as a control objective that has to be designed, documented, and operating, or the control around it fails. We walk through SoD as a SOX control objective below, why it matters in a 404 audit, the toxic combinations that sink findings, and how to remediate without freezing the business. It is not a NetSuite tooling guide. It is the control-objective layer that sits above any system you run.

Why SOX Auditors Care About Segregation of Duties

A SOX auditor’s job is to find a material misstatement risk and then confirm a control mitigates it. Segregation of duties is the control that prevents the same person from authorizing a transaction, recording it, and having custody of the related assets. When one person holds two of those, the risk of fraud or error that is also concealed goes up, and that is exactly the risk SOX 404 is designed to address.

Auditors test for SoD because it is observable and binary. A control is either segregated or it is not, and the access records in your ERP prove which one. That makes it a high-yield test area, which is why almost every 404 walkthrough touches it. Our SOX 404 overview shows where SoD sits in the full control framework.

The Toxic Combinations That Sink a 404 Audit

Toxic combinations are the specific access pairs that create a concealed-error or fraud risk. The classic ones are the same person who can approve a vendor and create a vendor, the same person who can enter a journal entry and post it, and the same person who can set up a user and grant themselves access. Auditors have a standing list, and they will run your access extract against it.

A finding here is expensive because the fix is not a policy change. It is an access change, and access changes ripple through how work gets done. The entity-level controls part of our 404 series covers where SoD lives among the entity-level controls an auditor tests first.

How We Identify SoD Conflicts Across In-Scope Processes

We start from scope, not from a system. SOX scope is the set of processes that feed material accounts, and SoD only has to be clean inside that scope. We pull the access extract for the in-scope systems, map roles to the authorize-record-custody functions, and run the conflict matrix against the toxic-combination list. The output is a conflict register, each one flagged with the process, the role pair, and the compensating control if one already exists.

This is the part that gets skipped when teams treat SoD as a checkbox. Running the matrix once at scoping, then again before testing, catches the conflicts that role changes introduce mid-year. Our walk-through overview shows how the conflict register feeds the walkthroughs an auditor will run.

Remediate or Compensate, the Two Paths

When a conflict shows up, you have two paths. Remediate by removing one of the access rights so the conflict no longer exists, which is clean but can break how work moves. Or compensate by keeping the access and adding a mitigating control, typically a detailed review by someone independent, which lets the work keep moving but adds a control the auditor will test.

Remediation is preferred because it removes the risk. Compensation is the reality for most growing companies because the person wearing three hats is also the only person who knows the system. The decision is a scoping decision, and the wire-fraud prevention entity-level controls post walks through when compensation is defensible.

How Often a SOX SoD Review Should Run

SoD is not a one-time exercise. Roles change, people join, and scope moves as the business grows. We recommend running the conflict matrix at scoping and again before testing, and rerunning it whenever a material role change lands. The ITGC shared-folder access review is an example of the access-review cadence that keeps SoD from drifting between audits.

When you are ready to run the assessment, we do NetSuite SoD work with our SOD Check tool on a fixed-fee basis. The segregation of duties analysis service page lays out what the engagement covers, and that is the money-page engagement this post feeds. Start with a free consultation call before you commit.

FAQ

What is the SOX segregation of duties requirement?

SOX does not name a single SoD requirement by number. It requires effective internal control over financial reporting, and segregation of duties is one of the controls auditors expect to see designed and operating to meet that standard. The requirement is that conflicts which allow concealed error or fraud are remediated or compensated.

What is the segregation of duties rule?

The rule is that no single person should control all phases of a transaction, authorization, recording, and custody of the related assets. In practice it means splitting those duties across roles so that one person cannot both initiate and conceal an error.

What is SOX 302 and 404?

SOX 302 is the management certification of the financial report, signed by the CEO and CFO. SOX 404 is the management assessment of internal control over financial reporting, with 404(b) adding the external auditor attestation for accelerated filers.

What are the 5 components of the COSO Internal Controls Framework?

The five components auditors look for are the COSO components, control environment, risk assessment, control activities, information and communication, and monitoring. SOX 404 is assessed against this framework, which is why COSO and SOX show up together.