SoD Risk Detection & Remediation in NetSuite

The Two Types of SoD Conflicts

When people talk about Segregation of Duties (SoD), they often forget there are two flavors of risk:

• Intra-Role SoD: conflicts that live inside a single role. Example: one NetSuite role has access to both “Enter Journal” and “Approve Journal” permissions.
• Cross-Role / Inter-Role SoD: conflicts that arise when a user holds multiple roles that, when combined, create toxic access through conflicting permissions. For example, one role may allow a user to “Enter Purchase Orders,” while another grants the ability to “Maintain Vendor Master Data.” Individually, these roles may be appropriate—but together, they enable a user to both set up suppliers and approve purchases against them, creating opportunities for fraud or the onboarding of disadvantageous suppliers in order to receive kickbacks.

Compliance Context

Auditors care about this because regulators care. SOX 404 requires management to prevent incompatible duties in financial systems, AKA SoD risks, while frameworks like COSO and COBIT shape how auditors test SoD in practice. SOX requires management to establish and maintain adequate internal controls over financial reporting (ICFR). Because ERP systems often house the financial data and processes that flow into external reporting, weak or poorly designed access controls can create risks of unauthorized transactions, fraudulent activities, and material misstatements. Or, in other words, failure to identify and mitigate SoD risks where strong mitigating controls are not in place, can lead your organization to a house of trouble.

• SOX 404 requires management to design controls that prevent incompatible duties and inherently has a strong emphasis on access controls.
• COSO and COBIT frameworks underpin external audit expectations for access risk testing.

Why Third-Party Tools Help

Here’s the catch: native ERP reports won’t give you the full picture. They can show what permissions a role has, or what roles a user holds, but they don’t automatically connect the dots across both layers. That’s where specialized GRC software tools and assessment services like ERP Armor: Assessments come in handy—they bring pre-built SoD rulesets, map them to your ERP’s object structure (e.g., permissions and access levels for NetSuite), and highlight the real conflicts management should look for.

Examples of SoD Conflicts

A few NetSuite specific examples:

• Intra-role conflict: A role with both Make Journal Entry and Journal Approval permissions.
• Intra-role conflict: A role with both Workflows and Vendor Payment Approval permissions.
• Cross-role conflict: Role A has access to the Purchase Orders permission and Role B has access to the Vendors permission.
• Cross-role conflict: Role A allows a user to create Bills (i.e., AP Invoices) and Role B allows a user to maintain vendor master data via the Vendors permission.

Each of these opens the door to fraud or material misstatement if left unchecked.

1. Inter-role conflict: Make Journal Entry vs Journal Approval → If one role contains both permissions, the same user could create and approve their own journal entries. This bypasses independent review and could allow fraudulent postings (e.g., hiding misappropriated funds) or material misstatements in financial reporting.
2. Inter-role conflict: Workflow Maintenance vs Vendor Payment Approval → A user with workflow design/maintenance rights and the ability to approve vendor payments could alter or disable payment approval workflows, then process unauthorized payments above their authority limit without detection. This effectively neutralizes preventive controls designed to stop fraud.
3. Cross-role conflict: Purchase Orders vs Vendors → If a user has access to create purchase orders (Role A) and also maintain vendor master data (Role B), they could set up fictitious or unapproved vendors and issue purchase orders to them. This creates a path for fraudulent supplier onboarding and payments for illegitimate goods/services.
4. Cross-role conflict: Create Bills (AP Invoices) vs Vendors → With access to create AP invoices (Role A) and maintain vendor records (Role B), a user could both create a fraudulent vendor and process invoices to that vendor. This is one of the most classic fraud pathways that can lead to severe financial loss.

Scoping & Prioritization

Not every conflict is worth chasing initially. It is best to start by mapping ERP security objects, like permissions in NetSuite, to your Risk & Controls Matrix so you can focus on financially significant conflicts from the jump. Think items like supplier maintenance, payments, journals, revenue recognition, workflow configurations, payroll, etc. From there, prioritize conflicts based on fraud potential and residual risk. A conflict covered by dual approval workflow, for example, may be acceptable, while one without mitigating controls may not be.

Remediation Steps

Cleaning this up requires structure:

1. Run a SoD assessment at the security object level (e.g., permissions for NetSuite)
2. Separate true conflicts from false positives.
3. Remediate by redesigning roles, removing permissions, or layering in mitigating controls like application workflows or detective monitoring controls.
4. Track everything in a ticketing or GRC tool for closure and audit evidence.

Closing

SoD risk isn’t something you check once a year—it evolves with every patch, every new role, and every integration update. Continuous monitoring, supported by automated tools and robust sensitive access and SoD rulesets, is the only way to stay ahead of both auditors and real-world threats.