Segregation of Duties Matrix: A Guide for Auditors

Featured image for Segregation of Duties Matrix: A Guide for Auditors

A segregation of duties matrix is the control blueprint that converts SoD policy into enforceable rules — it maps every sensitive task to the roles and entitlements that can perform it, flags toxic combinations, and documents who owns the remediation. Download the template below, then run a pilot on accounts payable or vendor payments before expanding further.

Three frameworks anchor this work in U.S. regulated environments:

  • COSO Internal Control — Integrated Framework defines the control objectives the matrix must satisfy for financial reporting integrity.
  • SOX Section 404 requires management and external auditors to assess the design and operating effectiveness of internal controls, and a documented SoD matrix is primary evidence.
  • ISO/IEC 27001 extends the requirement to IT entitlements, tying the matrix to the principle of least privilege — no identity should hold more access than the minimum needed to complete its assigned function.

The matrix is also your audit trail anchor. Every flagged conflict, every compensating control, and every review date feeds the evidence chain auditors expect to see.

Table of Contents

What is a segregation of duties matrix and how does it fit your control stack?

An SoD matrix is a structured document — typically a spreadsheet or a rules table inside an identity governance tool — that maps processes and tasks to the roles or entitlements authorized to perform them, then evaluates every combination for conflict. It sits one layer below the SoD policy (which states the principle) and one layer above operational enforcement (which blocks or flags access in a system). The policy says “no one person should approve their own vendor payments.” The matrix says exactly which roles create vendors, which roles approve payments, and what happens when one identity holds both.

The distinction from a policy document matters for auditors. Mature matrices include risk ratings, compensating controls, owners, and review cadence — not just a list of prohibited combinations. A policy without that structure is an aspiration; the matrix is the evidence.

Segregation of duties examines four primary functions: authorization, custody, record-keeping, and reconciliation. Any combination that allows one identity to control two or more of these functions within a single process is a candidate conflict. That four-function model is the conceptual backbone of every matrix row, whether you are mapping finance workflows or IT privileged access.

Infographic showing Segregation of Duties matrix key steps

Within the control stack, the matrix connects upward to COSO’s Control Activities component and downward to system-level role exports. COSO and COBIT provide the baseline for control prioritization, and the matrix operationalizes those baselines into testable rows. ISO/IEC 27001 Annex A.9 (access control) adds the IT dimension: entitlement-level mapping, not just job-title mapping, is required when a single application role bundles multiple sensitive functions.

Hands pointing at control matrix documents on table

Job-title level vs. entitlement level. Mapping at job-title level is faster to build but misses conflicts that live inside application roles. A “Finance Analyst” title tells you nothing about whether that person holds both the “Create Vendor” and “Approve Payment” entitlements in your ERP. Entitlement-level mapping catches those combinations and scales better as your application portfolio grows.

What goes in each column of an effective SoD matrix?

The schema below represents the minimum fields an audit-ready matrix should carry. Every column has a job; removing one creates a gap auditors will flag.

Column What to Capture Acceptable Values / Format Why It Matters
Process The business process being controlled “Accounts Payable,” “Payroll,” “Vendor Master” Groups rows for scoping and reporting
Task / Action The specific action within that process “Create vendor record,” “Approve payment run” Must be granular enough to test independently
System / Application The system where the action occurs “NetSuite,” “SAP S/4HANA,” “Workday” Ties the row to an actual entitlement export
Role / Entitlement The role or permission that grants the action Role name or permission string from the system The unit of enforcement
Conflict Flag Whether this task conflicts with another in the matrix — Drives the review workflow
Risk Rating Severity of the conflict High / Medium / Low Prioritizes remediation effort
Compensating Control The mitigating control when separation is not feasible “Monthly supervisory review of payment log” Required for audit acceptance of residual risk
Owner The person accountable for the control Name + title Auditors need a human to interview
Last Review Date When the row was last validated ISO date (YYYY-MM-DD) Demonstrates operating effectiveness
Evidence Link Where to find supporting documentation Document repository URL or file path Closes the audit evidence loop

Granularity is the hardest call. “Manage vendors” is too broad — it bundles creation, editing, and approval into one row, which means you cannot test them separately. “Create vendor record” is testable: pull the system log, confirm which identities executed that transaction, and cross-reference against the matrix. The right breakdown is the one where each task maps to a discrete system action you can query.

A few additional notes on populating the schema:

  • Risk ratings should follow a consistent rubric, not gut feel. High = direct financial exposure or fraud enablement with no compensating control. Medium = conflict exists but a compensating control is documented and operating. Low = theoretical conflict with negligible financial impact.
  • The compensating control column must describe the control, its frequency, and who performs it. “Management review” is not sufficient. “CFO reviews the weekly vendor payment exception report every Friday and signs off in the document management system” is.
  • Assign one owner per row. Shared ownership is no ownership.

How do you build a segregation of duties matrix from scratch?

The process below is repeatable and produces an audit-ready evidence chain from day one. Follow the steps in order; skipping buy-in or scoping almost always forces a restart.

  1. Secure executive sponsorship. The matrix touches every department and requires access to system role exports, process documentation, and HR data. Without a named sponsor at the CFO or CRO level, you will hit walls at step three.

  2. Identify stakeholders and assign process owners. Map each in-scope process to a business owner (Finance, Procurement, HR, IT) and a technical owner (system administrator or IT security). Both must participate in the role-discovery step.

  3. Select and prioritize processes. Start with “money in / money out” processes: accounts payable, payroll, procurement, and vendor master management. These carry the highest fraud and financial-reporting risk and are the first processes external auditors will test.

  4. Collect source data. Export role and entitlement lists from each in-scope system. Supplement with process flow diagrams, prior access review results, and interviews with process owners. The goal is a complete inventory of who can do what in each system.

  5. Map tasks to roles and entitlements. For each task in the process, identify every role or entitlement that grants the ability to perform it. This is where entitlement-level mapping pays off — one role often bundles multiple sensitive functions.

  6. Evaluate conflicts and assign risk ratings. Cross-reference task pairs using the four-function model (authorization, custody, record-keeping, reconciliation). Any combination where one identity controls two functions is a candidate conflict. Rate each High, Medium, or Low using the rubric from the components section.

  7. Define remediation paths. For each conflict, choose one: (a) separate the functions by revoking one entitlement, (b) implement a compensating control if separation is not operationally feasible, or © accept residual risk with documented rationale and senior sign-off.

  8. Build the matrix in a controlled repository. Use the template schema above. Store the file in a version-controlled document repository — not a shared drive folder where anyone can overwrite it. Practical creation steps include storing the matrix in a controlled repository and scheduling continuous updates.

  9. Run a pilot. Select one high-risk process (accounts payable is the standard starting point), run the matrix against current access, document findings, and remediate within a defined window (30 days is a reasonable target). Measure the number of conflicts found, time to remediate, and whether compensating controls are operating.

  10. Roll out to remaining processes. Use the pilot findings to refine the schema and rubric before expanding. Rollout order should follow risk rating: highest-risk processes first.

Pro Tip: Scope granularity before you start mapping. Decide at the outset whether you are mapping at the job-title level or the entitlement level, and document that decision. Changing granularity mid-project forces a rebuild. For any process subject to SOX or HIPAA, entitlement-level mapping is the only defensible choice.

What do SoD conflicts look like across finance, procurement, HR, and IT?

Concrete examples are what turn a schema into a working control. The rows below are representative conflicts auditors test in every engagement — adapt them to your specific systems and role names.

Finance / Accounts Payable

  • Create vendor record + Approve vendor record: One identity can add a fictitious vendor and approve it for payment. Risk: High. Compensating control: Independent supervisor reviews all new vendor additions weekly against the approved vendor list.
  • Create journal entry + Approve journal entry: Allows manipulation of financial records without a second reviewer. Risk: High. Compensating control: Automated workflow requiring a different approver role before posting.
  • Perform bank reconciliation + Approve disbursements: The person reconciling can conceal unauthorized payments. Risk: Medium. Compensating control: Monthly CFO sign-off on reconciliation output.

Procurement

  • Create purchase requisition + Approve purchase order: Bypasses the authorization step entirely. Risk: High. Separation is almost always feasible — this conflict should be resolved structurally, not with a compensating control.
  • Receive goods + Approve vendor invoice: Allows a single person to confirm receipt and authorize payment, enabling fictitious invoicing. Risk: High.

HR / Payroll

  • Onboard new employee + Authorize payroll run: A person who can add employees to the system and run payroll can create ghost employees. Risk: High.
  • Change direct deposit information + Approve payroll: Allows redirection of payroll funds. Risk: High. This combination should never exist without a mandatory second-approver workflow.

IT / Privileged Access

  • System administrator access + Deploy to production: Allows code changes without a peer review gate. Risk: High. Compensating control: Change Advisory Board approval log required before any production deployment.
  • Create user accounts + Assign privileged roles: Allows privilege escalation without oversight. Risk: High.

The 4-eyes principle — requiring a second reviewer for every critical action — is the operational expression of SoD for high-risk tasks. It applies wherever structural separation is not feasible: a small team where one person must hold two functions can still enforce a mandatory second-reviewer step before any transaction completes. The 4-eyes principle requires a second reviewer for critical actions to prevent both error and fraud, and it is the most common compensating control auditors accept for small-team conflicts.

What mistakes make SoD matrices ineffective — and how do you fix them?

Two failure modes account for most matrix problems in practice.

Compliance officer reviewing SoD mistakes report

Too coarse. A matrix that maps at the job-title level misses the conflicts that live inside application roles. If your matrix says “Finance Analyst conflicts with Accounts Payable Manager,” that tells an auditor nothing about which specific entitlements are in conflict or how to test them. The fix: rebuild the conflicting rows at the entitlement level, starting with your highest-risk process. It takes more time upfront but produces testable, defensible rows.

Too granular. A matrix with 2,000 rows covering every possible permission combination in every system becomes unmaintainable within six months. No one updates it, owners stop responding, and it fails the operating-effectiveness test. The fix: apply the “money in / money out” prioritization principle. Map the 20–30 task pairs that carry real financial or compliance risk in detail; use broader role-level mapping for lower-risk processes.

Beyond those two, the most common pitfalls are:

  • Missing owners. A row with no named owner has no accountability. Auditors will ask who is responsible for the compensating control and expect a name, not a department.
  • No review cadence. A matrix dated 18 months ago is evidence of a control that has lapsed, not one that is operating. Set calendar reminders and treat missed reviews as audit findings.
  • Vague compensating controls. “Management review” fails the specificity test. Document the control, its frequency, the reviewer’s name or role, and where the evidence is stored.
  • Wrong storage location. A matrix saved in a personal OneDrive folder or an unversioned SharePoint library cannot demonstrate version control or access restriction. Use a document management system with audit logging.

Measuring improvement is straightforward: track the number of rows with named owners, the percentage of high-risk conflicts with documented compensating controls, and the age of the last review date across all rows. Those three metrics tell you whether the matrix is alive or decorative.

When should you move from a spreadsheet to automated SoD enforcement?

The spreadsheet works well when you have fewer than a dozen in-scope applications and a manageable number of roles. Past that threshold, manual maintenance becomes the bottleneck. Once you manage dozens of apps or hundreds of roles, encoding policies into tooling saves far more time than manual reviews.

The scale triggers that typically justify automation investment: more than 15 in-scope applications, more than 200 distinct roles, quarterly or more frequent access certifications, or a SOX or HIPAA audit scope that requires continuous evidence.

Integration checklist for automated SoD enforcement:

  • Authoritative identity source (Active Directory, Okta, or equivalent) connected to the SoD tool
  • System role exports from every in-scope application feeding the rule engine
  • Provisioning workflow hooks that evaluate SoD rules before granting access (preventative enforcement)
  • Certification cycle configuration: who certifies, at what frequency, and what happens to uncertified access
  • Exception workflow: a documented path for business-justified exceptions with time limits and senior approval
Dimension Manual Spreadsheet Rules-as-Code Automation
Conflict detection Point-in-time, during reviews Continuous, at provisioning and on schedule
Evidence generation Manual screenshots, email threads Automated logs, certification records
Scalability Degrades past ~15 apps Scales with application portfolio
Setup cost Low Moderate to high
Maintenance burden High (human-driven updates) Lower after initial configuration
Audit readiness Requires manual assembly Evidence available on demand
Preventative enforcement None Blocks risky assignments before they occur

A software-enforced SoD rule set converts matrix cells into continuous checks and prevents privilege creep by evaluating actual entitlements across ERP and SaaS systems during provisioning and on an ongoing basis. Application-based SoD processes are essential where application permissions drive financial reporting impacts — which is nearly every SOX-scoped environment today.

One documented outcome from an oil and gas operator’s SAP access governance implementation: a 50% reduction in access review time and an 80% increase in automation of access assignments after implementing continuous SoD controls. That is the kind of operational shift that makes the investment case for tooling.

How do you govern and maintain the matrix so auditors trust it?

A matrix that is not actively maintained is worse than no matrix — it creates a false impression of control. Governance is what separates a living control from a document artifact.

Review cadence. High-risk rows (rated High) should be reviewed quarterly. The full matrix warrants at least an annual review. Off-cycle reviews are mandatory when: a new application is deployed, a significant role change occurs (merger, reorganization), or an audit finding touches the matrix.

Ownership model. Each row has a business owner (accountable for the control) and a technical owner (accountable for the entitlement configuration). The business owner signs off on compensating controls; the technical owner confirms the entitlement mapping is still accurate. Both names appear in the matrix.

KPIs to track:

  • Number of active High-risk conflicts with no compensating control (target: zero)
  • Percentage of High-risk conflicts with a documented, operating compensating control (target: 100%)
  • Time-to-remediate for newly identified conflicts (target: 30 days for High, 90 days for Medium)
  • Percentage of rows reviewed within the scheduled cadence (target: 100%)
  • Number of exceptions granted and their average age (exceptions older than 90 days without renewal are a red flag)

Evidence storage. Version every matrix release with a date stamp and a change log entry. Store access certification records alongside the matrix. When an auditor asks for evidence that a compensating control operated in Q3, you should be able to produce the reviewer’s sign-off, the date, and the transaction log reviewed — not a verbal assurance.

How do you use the SoD matrix template effectively?

The template has three tabs: Role/Entitlement Inventory, Conflict Matrix, and Compensating Controls Register. Populate them in that order.

  1. Role/Entitlement Inventory tab. Export role lists from each in-scope system and paste them here. Add columns for the system name, the tasks each role can perform, and the business process it belongs to. This tab is your source of truth for the mapping step.

  2. Conflict Matrix tab. For each task pair identified as a potential conflict, create a row using the schema from the components section. Populate every column — leave nothing blank. A blank “Owner” cell is an immediate audit finding.

  3. Compensating Controls Register tab. For every conflict rated Medium or High where separation is not feasible, document the compensating control in full: control description, frequency, reviewer name/role, evidence location, and last execution date.

Sample filled rows (generic):

Process Task A Task B System Risk Compensating Control Owner Last Review
Accounts Payable Create vendor Approve vendor ERP High Weekly supervisor review of new vendor log AP Manager 2026-03-01
Payroll Add employee Run payroll HCM High Dual-approval workflow enforced in system Payroll Director 2026-03-15
IT Access Create user Assign admin role IAM High CAB approval required before role assignment IT Security Lead 2026-02-28
Procurement Create PO Approve PO ERP Medium Manager countersignature on POs over $10,000 Procurement Lead 2026-03-10

First manual cross-check checklist:

  1. Pull a current user access report from each in-scope system.
  2. For each user, identify all roles/entitlements they hold.
  3. Cross-reference each user’s entitlement set against the Conflict Matrix tab.
  4. Flag every user who holds both sides of a High-risk conflict.
  5. For flagged users, confirm whether a compensating control is documented and operating.
  6. Document findings in a findings log with the user ID, conflict ID, and remediation status.
  7. Assign remediation owners and target dates.

Archive the canonical matrix in your document management system with version control enabled. Every release should carry a version number, a change summary, and the approver’s name.

Applying an SoD matrix in upstream oil and gas operations

Upstream oil and gas operations present SoD challenges that differ from standard enterprise environments. The combination of field-based roles, per-well cost accounting, and vendor-heavy operations creates conflict patterns that generic matrix templates do not anticipate.

Role mapping for upstream operations:

  • Field engineer / lease operator: Can record production volumes, log field maintenance activities, and submit field-level expense tickets. Conflicts arise when this role also has access to approve vendor invoices for the same well.
  • Production accountant: Manages per-well revenue and expense allocations. A conflict exists if this role can also modify the underlying production data that drives those allocations.
  • Vendor management / AP: Creates and edits vendor records, processes invoices. The standard vendor-creation / payment-approval conflict applies here with added complexity: in oilfield operations, vendors are often approved on short notice in the field, creating pressure to bypass controls.

High-risk combinations specific to oil and gas:

  • Access to production volume data + ability to adjust expense allocations: allows manipulation of per-well P&L without a second reviewer.
  • Vendor invoice approval + field activity log entry: a single person can create a fictitious service record and approve the corresponding invoice.
  • Lease operating statement (LOS) preparation + LOS approval: standard journal-entry conflict applied to the LOS workflow.

In operationally complex industries like oil and gas, linking per-asset transaction histories to access reviews gives stronger evidence of control effectiveness than role lists alone. An audit trail that shows who approved each per-well expense, when, and from which system is more defensible than a static entitlement report reviewed once a year.

Pilot narrative. An independent operator with 40 active wells might pilot the matrix on its top 10 wells by revenue. The process: export entitlements from the ERP and field operations platform, map them against the conflict matrix, and run the first cross-check. Expected findings typically include at least one instance of a field-level role holding both expense entry and invoice approval access — a High-risk conflict that is straightforward to remediate by splitting the approval step to a separate finance role. After 30 days of remediation and one cycle of compensating-control evidence, the operator has a defensible audit package for those 10 wells. Consistent, documented internal controls with role-based access are critical for financial reporting in oil and gas application systems.

Your 30/90/180-day action plan after downloading the template

  1. Days 1–30: Secure executive sponsorship. Select one pilot process (accounts payable or vendor master). Export role and entitlement lists from the relevant system. Run the first manual cross-check using the template. Document all High-risk conflicts found.
  2. Days 31–90: Remediate pilot findings. Assign named owners to every matrix row. Define and document compensating controls for conflicts that cannot be structurally separated. Begin the first access certification cycle for the pilot process. Establish the review cadence calendar.
  3. Days 91–180: Expand the matrix to the next two highest-risk processes. Evaluate automation ROI against the scale triggers (number of apps, roles, and audit frequency). If the threshold is met, begin vendor evaluation for IGA tooling. Implement preventative SoD checks in your provisioning workflow for the pilot process.

What success looks like: Internal audit can pull a current matrix, identify every High-risk conflict, confirm a named owner and a documented compensating control for each, and trace evidence of the control operating within the last 90 days. External auditors see version history, change logs, and certification records. That is a control that is designed and operating effectively — the SOX Section 404 standard.

How to build organizational support for SoD compliance

A matrix no one follows is a document, not a control. Getting people to actually use it requires deliberate communication and training, not a policy email.

Start with the business case, not the compliance mandate. Process owners respond to risk in plain language: “If one person can create a vendor and approve their own payment, we have no way to detect a fictitious vendor scheme until the damage is done.” That framing lands differently than “SOX requires segregation of duties.”

Stakeholder communication by audience:

  • Executive sponsors: Quarterly dashboard showing number of active High-risk conflicts, time-to-remediate trends, and percentage of rows with operating compensating controls. Keep it to one page.
  • Process owners: Role-specific training on which conflicts affect their team, what the compensating controls require of them, and how to escalate exceptions. Annual refresher with updates when the matrix changes.
  • IT and system administrators: Technical briefing on entitlement exports, provisioning workflow hooks, and how to read a conflict flag. They are the ones who implement structural separations.
  • Internal audit: Full matrix access, change log visibility, and a defined escalation path when a conflict is found during testing.

Training should be practical, not theoretical. Walk process owners through a real example from their own department — show them the conflict row, the compensating control, and what evidence they need to produce. Abstract training on SoD principles rarely changes behavior; a 20-minute walkthrough of their own access report does.

Document training completion. Auditors will ask whether affected personnel were trained on the controls they are responsible for operating.

Compensating controls: detailed examples and how to document them

A compensating control is the evidence-backed alternative when structural separation is not feasible. It does not eliminate the risk; it reduces it to an acceptable level and creates a detection mechanism. Auditors evaluate compensating controls on three criteria: specificity, frequency, and evidence.

Documented examples by conflict type:

Vendor creation + vendor approval (same person): Control: The controller reviews a system-generated report of all new vendor additions weekly. The report is exported from the ERP, reviewed against the approved vendor list, and signed off in the document management system. Evidence: signed report, stored with date and reviewer name, retained for three years.

Journal entry creation + journal entry approval (small accounting team): Control: All journal entries above $5,000 require a second approver in the ERP workflow before posting. Entries below $5,000 are subject to a monthly supervisory review of the complete journal entry log. Evidence: ERP workflow approval records (automated) and monthly sign-off document.

Payroll processing + payroll approval (single payroll administrator): Control: The CFO reviews and approves the payroll register before each pay run. Direct deposit changes require a separate authorization form signed by HR and the employee. Evidence: signed payroll register, authorization forms retained in HR system.

How to document a compensating control in the matrix:

Every compensating control entry must answer five questions: (1) What is the control? (2) Who performs it? (3) How often? (4) Where is the evidence stored? (5) When was it last performed? A control description that cannot answer all five is incomplete and will not satisfy an auditor. Auditors look for evidence of a consistent control framework, not an aspirational policy — and that means the compensating control column in your matrix must be specific enough to test.

Risk assessment methods for identifying SoD conflicts

Not all conflicts carry equal weight, and a flat list of prohibited combinations is not a risk assessment. Effective SoD risk assessment uses a structured methodology to prioritize which conflicts to address first and how aggressively.

The four-function model as a starting filter. The four primary functions — authorization, custody, record-keeping, and reconciliation — form the canonical basis for identifying toxic combinations. Any task pair where one identity controls two of these functions in the same process is a candidate conflict. This filter narrows the universe of combinations to a manageable set before you apply risk ratings.

Inherent risk factors to evaluate for each conflict:

  • Financial exposure: What is the maximum dollar amount that could be misappropriated or misstated if this conflict were exploited? Higher exposure = higher inherent risk.
  • Detectability: How quickly would the conflict be detected through existing controls or reporting? Low detectability increases risk.
  • Frequency of the transaction: A conflict in a process that runs daily carries more risk than one in a quarterly process.
  • Regulatory scope: Is the process in scope for SOX, HIPAA, or another regulation? Regulatory scope elevates the rating regardless of dollar exposure.

Residual risk after compensating controls. Once a compensating control is documented and operating, reassess the residual risk. A High-inherent-risk conflict with a well-designed, frequently executed compensating control may carry Medium residual risk — which is an acceptable outcome for audit purposes, provided the evidence is current.

Apply this methodology consistently across every row. Inconsistent rating criteria are one of the first things an experienced auditor will challenge.

How to integrate SoD matrices with audit and risk management functions

The matrix is most valuable when it is not a standalone document but a live input to your audit and risk management cycle. Integration means the matrix informs audit planning, feeds risk assessments, and generates evidence automatically rather than being assembled manually before each audit.

Connecting the matrix to internal audit planning. High-risk conflict rows should map directly to audit program steps. When internal audit plans its annual risk assessment, the matrix provides a pre-scored inventory of control risks — which processes have unmitigated High conflicts, which compensating controls have not been tested recently, and where the evidence gaps are. That connection eliminates duplicated effort and ensures audit coverage aligns with actual control risk.

Feeding the enterprise risk register. Each High-risk conflict without a compensating control is a control gap that belongs in the enterprise risk register with an owner and a remediation target date. The matrix and the risk register should reference each other: the risk register entry cites the matrix row ID, and the matrix row links to the risk register item.

Continuous monitoring integration. When the matrix is encoded in an IGA or GRC tool, conflict detection becomes continuous rather than periodic. Alerts fire when a provisioning request would create a conflict, and certification campaigns pull directly from the matrix rule set. The audit team receives real-time dashboards instead of point-in-time snapshots. Automation can deliver continuous SoD detection, automate certification, and prevent risky assignments during provisioning — which shifts the audit team’s role from evidence collector to exception reviewer.

Presenting the matrix to external auditors. Provide the current matrix version, the change log showing all updates since the last audit, access certification records for the period under review, and evidence of compensating controls operating (signed reports, workflow approval logs, exception approvals). Organize by process, then by risk rating. Auditors will sample High-risk rows first — make those rows complete and easy to navigate.

Key Takeaways

An effective segregation of duties matrix maps every sensitive task to its entitlements, flags toxic combinations, assigns named owners, and carries documented compensating controls — without all four elements, it will not survive audit scrutiny.

Point Details
Entitlement-level mapping is required Job-title mapping misses conflicts inside application roles; map at the entitlement level for any SOX or HIPAA-scoped process.
Start with “money in / money out” Prioritize accounts payable, payroll, procurement, and vendor master before expanding to lower-risk processes.
Compensating controls must be specific Document the control, frequency, reviewer, and evidence location; “management review” alone will not satisfy an auditor.
Automate when scale demands it Past 15 applications or 200 roles, manual spreadsheet maintenance degrades faster than it can be corrected.
Wellsmanager supports oil and gas SoD Per-well audit trails and approval history tracking in Wellsmanager reduce the evidence burden during SoD reviews for upstream operators.

What mature SoD programs do that most teams miss

Most SoD programs fail at the same point: they build a solid matrix, run a successful pilot, and then let the document go stale. The matrix passes its first audit and fails the second because no one updated it after a system upgrade changed the role structure.

Mature programs treat the matrix as infrastructure, not a project deliverable. That means three things in practice. First, the matrix is connected to the change management process — any new application deployment or role restructuring triggers an automatic off-cycle review. Second, ownership is cross-functional from day one: the business owner, the IT security team, and internal audit all have defined roles in maintaining and testing the matrix, and no single team can let it lapse without the others noticing. Third, evidence capture is automated wherever possible, so the audit package assembles itself rather than requiring a two-week scramble before each engagement.

The granularity question is where I see the most wasted effort. Teams spend months building exhaustive matrices covering every permission in every system, then discover they cannot maintain them. The better approach is a tiered model: entitlement-level precision for your top 20–30 highest-risk task pairs, role-level mapping for everything else. That ratio keeps the matrix maintainable without sacrificing coverage where it matters.

For small teams — a compliance function of two or three people covering a mid-size operator — the realistic starting point is a well-maintained spreadsheet covering the five highest-risk processes, with named owners and quarterly reviews. Automation is a second-year investment, not a prerequisite. What auditors actually want to see in year one is evidence that someone is actively managing the conflicts, not a sophisticated tool with stale data.

Wellsmanager gives upstream operators a built-in SoD evidence layer

For oil and gas operators running SoD programs, the hardest part of the evidence cycle is not building the matrix — it is producing transaction-level proof that controls operated between audits. That is where an operations platform purpose-built for upstream work changes the equation.

Wellsmanager

Wellsmanager captures per-well expense entries, vendor invoice approvals, and field activity logs in a single platform with a timestamped audit trail. Every approval is recorded with the approver’s identity, the date, and the transaction detail — exactly the approval history tracking that SoD reviews require. When your external auditor asks for evidence that the compensating control on your vendor invoice approval conflict operated in Q2, you pull the approval log from Wellsmanager rather than assembling it from email threads and spreadsheet exports.

The platform’s compliance notifications flag exceptions in real time, and the per-well P&L view makes it straightforward to spot anomalies that warrant a deeper access review. For operators managing dozens of wells across multiple fields, that operational visibility is the complement to a well-built SoD matrix — not a replacement for it, but the evidence layer that makes the matrix defensible.

Request access to see how Wellsmanager’s audit trail and approval history features support your SoD program, or visit wellsmanager.com to learn more about the platform.

This section describes an optional complementary approach. Wellsmanager is an operations management platform, not a dedicated IGA or GRC tool. Consult a qualified compliance professional to determine the right control architecture for your organization.

Authoritative sources and further reading

The sources below were used to build this guide. Each is worth reading directly for the depth it adds to specific topics.

Recommended