An SoD policy without a matrix is just a good intention. The matrix is what makes it enforceable.
Every Segregation of Duties program eventually comes down to one document: a matrix that maps roles or entitlements against each other and flags which combinations create risk. Without it, "we take SoD seriously" is a sentence, not a control.
In this guide, we'll cover what an SoD matrix should include, how to structure one by department, the two mistakes that make most matrices useless within a year, and how to keep it current once it's built.
What is a Segregation of Duties matrix?
A Segregation of Duties matrix is a structured mapping of job functions, roles, or specific entitlements against each other. Each cell represents a combination, and the matrix marks which combinations are acceptable and which are conflicts. For the fundamentals of what SoD is and the risk it addresses, see our Segregation of Duties guide.
At its simplest, think of it as a grid. Down one side: roles or tasks like "create purchase order," "approve purchase order," "process payment," "reconcile bank statement." Across the top, the same list. Where a row and column intersect, you mark whether that pairing is safe for one person to hold, or a violation if they do.
Mature SoD matrices go deeper than job titles, though. They map specific entitlements, permissions, and system roles, because two people with the same job title can still hold very different actual access. A matrix built at the job-title level catches the obvious conflicts. A matrix built at the entitlement level catches the ones that accumulate quietly through role changes and one-off access requests, the same access creep pattern that lets conflicting permissions build up unnoticed.
Why the matrix matters more than the policy
A lot of organizations write an SoD policy statement, something like "no employee shall both create and approve financial transactions," and consider the job done. That statement is true and reasonable. It's also unenforceable on its own, because nobody can check every employee's access against a sentence.
The matrix is what turns the policy into something checkable. It gives you a finite list of combinations to test for, instead of a general principle everyone interprets slightly differently. Without it, the specific risks that follow from unchecked conflicts tend to accumulate silently; see our breakdown of Segregation of Duties risks for what's actually at stake.
When an auditor asks how you know nobody holds a conflicting set of permissions, "we have a policy" isn't an answer. "Here's the matrix we test access against, and here's the last quarter's results" is.
For the fuller picture of how the matrix fits into a documented policy and the operational procedure around it, see our guide to Segregation of Duties policy and procedure.
Core components of an SoD matrix
A working matrix needs a few consistent elements, regardless of department or industry.
Function or task list. The individual actions that make up a process, broken down enough to identify where conflicts live. "Manage vendors" is too broad; "create vendor record" and "approve vendor payment" are specific enough to actually test.
Risk rating per conflict. Not every conflict carries the same weight. Rating conflicts High, Medium, or Low lets you prioritize remediation instead of treating every finding as equally urgent.
Compensating controls. For conflicts that can't be fully eliminated, usually on smaller teams, the matrix should document what compensating control offsets the risk: a second reviewer, a monthly reconciliation, an automated alert on transactions above a threshold. This is exactly the kind of evidence auditors expect when testing SoD as one control activity within a broader internal controls framework; see Separation of Duties and internal controls for how the two connect.
Ownership. Who's responsible for reviewing this row when roles change. Without a named owner, matrix rows go stale the moment the org chart shifts.
Review cadence. How often the matrix itself gets re-validated against actual current access. Quarterly is common for high-risk processes; annually is often the floor for lower-risk ones.
Building the matrix by department
The specific conflicts worth mapping differ significantly by function, and a generic, one-size-fits-all matrix tends to either miss department-specific risks or bury them under irrelevant rows.
Finance and accounting. This is where SoD originated, and where the conflicts are most well understood: vendor creation vs. payment approval, journal entry creation vs. approval, bank reconciliation performed by someone who also has payment initiation rights. These carry direct financial exposure, and they're almost always the first section auditors check.
Procurement. Vendor selection and contract approval held by the same person. Purchase requisition and purchase order approval. Receiving goods and approving the invoice for those same goods.
HR and payroll. Processing a new hire and approving their own compensation changes. Managing timesheets and approving payroll runs. Access to employee personal data combined with the ability to modify direct deposit details, a combination that shows up in real payroll diversion schemes more often than most HR teams expect.
IT. This deserves its own treatment beyond a single matrix row, because IT conflicts tend to be system-level rather than transactional. We go deep on this category in IT Segregation of Duties.
For a broader set of worked examples across these departments and more, see Segregation of Duties policy examples.
The two mistakes that make most matrices fail
Too coarse to catch real conflicts. A matrix built at the department level, "Finance shouldn't both create and approve," sounds reasonable but doesn't map to how access actually gets granted. Real conflicts live at the entitlement level. A matrix that stops at job titles will miss the analyst who was granted approval rights temporarily during someone's leave and never had them revoked.
Too granular to maintain. The opposite failure mode is a matrix that tries to map every single permission in every single application, becoming so large that nobody actually reviews it on any regular cadence.
The right level of granularity is usually somewhere in the middle: specific enough to catch real toxic combinations, coarse enough that a human owner can review it quarterly without it becoming a full-time job. Most organizations resolve this by starting granular only in the highest-risk processes and staying coarser everywhere else, tightening it as the program matures.
What a matrix row actually looks like
Abstract descriptions only get you so far. Here's a simplified example of three rows in a finance-focused SoD matrix.
Not every conflict resolves the same way. The first is a hard rule with no exceptions. The second allows for a compensating control when full separation isn't possible. The third isn't even a conflict below a certain dollar threshold. That's the kind of nuance a matrix needs to capture if it's going to reflect how the business actually operates, rather than an idealized version nobody can live with.
Building this out across every process worth mapping is what turns the matrix from a concept into a working document. The format matters less than the discipline behind it, but the format still carries real tradeoffs.
Spreadsheet matrix vs. software-enforced matrix
Most SoD matrices start life as a spreadsheet, and for a first pass, that's fine. It's fast to build, easy to share with an auditor, and doesn't require buying anything.
The limitations show up once the matrix needs to do more than exist as a reference document. A spreadsheet can't check itself against live access data, so someone has to manually pull a list of who has what access and cross-reference it against the matrix rows. That's manageable quarterly for a 50-person company. It becomes close to impossible monthly for a 500-person company running 150 SaaS applications, because access data changes constantly while the spreadsheet stays frozen at the last update.
A software-enforced matrix flips this. The conflict logic gets defined once, as a rule rather than a static row, and the system continuously checks every identity's actual entitlements against it. New hires, role changes, and offboarded employees all get evaluated automatically. The tradeoff is setup cost against ongoing manual effort, and for most organizations past a certain headcount, that tradeoff favors software fairly quickly.
Keeping the matrix current
A matrix is only as good as its last update. Three triggers should force a review outside the normal quarterly or annual cadence:
- A role or job function is created, merged, or restructured
- A new application is added with entitlements that map to an existing conflict category
- An SoD violation is found during an audit that the matrix didn't already account for
Without these triggers built into a broader change-management process, the matrix drifts from reality within a year, sometimes within a quarter, regardless of how well it was built initially.
From matrix to automated detection
Everything above describes what the matrix should contain. How you actually test real employee access against it, on an ongoing basis rather than during an annual audit scramble, is a separate operational question.
Manually cross-referencing a matrix against every employee's actual access doesn't scale much past a few dozen employees before it becomes a spreadsheet nobody trusts. This is the specific gap automated SoD detection tools close: the matrix logic gets encoded as a rule, and the system checks every identity against it continuously.
Zluri, an identity security platform, implements this through its IGA product's Segregation of Duties capability. You define your matrix conflicts as policies, two conflicting entitlement sets per policy, and Zluri checks every identity in scope on a schedule, flagging violations and routing them for remediation through configurable Playbooks.
If you're comparing tools that can do this kind of automated matrix enforcement, our guide to SoD software covers the evaluation criteria and compares the leading platforms.
Want to see how the matrix logic in this guide translates into automated policies? Book a demo with Zluri.
Frequently Asked Questions
What should be included in a Segregation of Duties matrix? At minimum: the function or task list broken down to a testable level, a risk rating per conflict, documented compensating controls, a named owner per row, and a defined review cadence.
How granular should an SoD matrix be? Granular enough to catch real toxic combinations at the entitlement level, not just job titles, but not so granular that it becomes unmaintainable. Most organizations start granularly in high-risk areas and stay coarser elsewhere.
How often should an SoD matrix be reviewed? Quarterly for high-risk processes is common practice; annually is typically the floor for lower-risk areas. Any role restructuring, new application rollout, or newly discovered violation should trigger an off-cycle review.
Is a Segregation of Duties matrix the same as an SoD policy? No. The matrix maps which combinations are conflicts. The policy defines rules, ownership, exception handling, and review requirements around those conflicts. You need both.
Can a small company use a simplified SoD matrix? Yes. Smaller organizations often can't fully separate every duty due to headcount, so the matrix should document compensating controls alongside the conflicts that can't be immediately resolved through role separation.
How do you test employee access against an SoD matrix? Manually, by cross-referencing each employee's actual entitlements against the matrix, which works at small scale but breaks down quickly. At scale, most organizations encode the matrix logic into an automated SoD detection tool instead.
What's the difference between a spreadsheet matrix and a software-enforced one? A spreadsheet matrix requires manual cross-referencing against actual access. A software-enforced matrix encodes the same conflict logic as rules that get checked continuously, catching violations as they happen.
Should every SoD conflict be treated as equally urgent? No. Risk-rating each conflict lets teams prioritize remediation on the conflicts with real financial or security exposure.
.svg)
