A separation of duties matrix template for a team of five
Who performs and who approves each sensitive activity, and what covers the gaps.
A separation of duties matrix lists the sensitive activities in a company, such as merging code, deploying, granting access and paying invoices, and shows who performs each one and who approves or checks it.
The workbook is below with nine starter rows. At a small company the same person often appears in both columns, so each of those rows names a compensating control instead.
The template in full
Below is the whole workbook as it downloads. Every bracketed field, such as [Company name], is a detail to fill in before you adopt it. There is no form and no email address to hand over, and the file is yours to edit.
Separation of Duties Matrix
Duties
One row per sensitive activity at [Company name]. Where one person both performs and approves an activity, mark it as a conflict and name the compensating control. Review the sheet yearly and whenever roles change.
| Activity | Performed by (role) | Approved or reviewed by (role) | Conflict? | Compensating control |
|---|---|---|---|---|
| Merge code to the main branch | Engineer who wrote the change | A second engineer (required pull request review) | No | Branch protection on the main branch blocks a merge without one approving review from someone other than the author. |
| Deploy to production | [Engineering owner role] (through the deployment pipeline) | [Security owner role] | No | Only reviewed code on the main branch can deploy. [Security owner role] reviews the deployment history monthly. |
| Grant or change user access | [IT owner role] | [Security owner role] | No | Every grant has a recorded approval, and the quarterly access review checks each account against it. |
| Approve a new vendor | [Security owner role] (security assessment) | [Policy approver role] | No | Vendor register records the assessment and the approval date for every vendor that handles company or customer data. |
| Pay invoices | [Policy approver role] | External bookkeeper or accountant (monthly review) | No | Bank and card statements are reconciled monthly by someone other than the person who made the payments. |
| Change firewall or security group rules | [Engineering owner role] | [Security owner role] | No | Network changes are made as code through a reviewed pull request where possible. [Security owner role] reviews changes in the cloud provider audit log monthly. |
| Restore data from backup | [Engineering owner role] | [Security owner role] | No | Restores are requested in a ticket with the reason, approved before they run and recorded in the backup restore log. |
| Rotate secrets and keys | [Engineering owner role] | [Security owner role] | No | Secrets live in a secrets manager with access logging. Rotations are recorded with the date and reviewed quarterly. |
| Approve a policy | [Security owner role] (drafts) | [Policy approver role] | No | Every policy shows its owner, approver and approval date, and the approver is never the only author. |
How to use
- Read each row and replace the role with the actual person or role that does the work today.
- Mark "Conflict?" Yes whenever the same person appears in both the "Performed by" and "Approved or reviewed by" columns. In a small team this is normal and expected; the auditor looks for the compensating control, not a large headcount.
- Every Yes row needs a compensating control that someone else, or a system, carries out. Common ones for small teams: (a) Peer review: a second engineer approves every pull request before merge, enforced by branch protection. (b) Log review by the executive: [Policy approver role] reviews admin activity, deployment history or cloud audit logs monthly and records the date. (c) Automation: changes can only happen through a pipeline that enforces review, so no one can skip the check. (d) Outside review: an external bookkeeper, accountant or advisor reconciles payments and bank statements monthly. (e) After-the-fact detection: alerts on admin sign-ins, permission changes and security group edits go to a second person.
- Add any activity missing for your business, such as issuing refunds, changing payroll, or exporting customer data.
- Keep the evidence each control produces: pull request approvals, the monthly review record, reconciliation reports.
- [Policy approver role] approves the matrix once a year and whenever someone joins, leaves or changes role.
What an auditor checks
An auditor reads the rows marked as a conflict and asks for the compensating control's evidence: the pull request approvals, the monthly log review, the bookkeeper's reconciliation. A conflict with no compensating control is the finding.
They also check the matrix matches reality. If the deploy history shows someone deploying who is not named here, expect a question. The security roles document names the people behind each role.
Which criteria it maps to
It supports CC5.1 and CC6.1.1 A template is evidence of intent. The examination tests whether the control operated over the period, so keep the dated records the workbook produces. Every criterion, explained one by one, is on the Trust Services Criteria page.
Questions
What is separation of duties in SOC 2?
How does a small startup handle separation of duties?
Is a conflict in the matrix a SOC 2 failure?
Sources
Get audit-ready without a compliance team.
The readiness assessment is free, with no payment and no card. Star is $2,000 one time to get on the platform and close your gaps. Orbit is $7,800 a year, and your SOC 2 Type 2 audit is included in every contract year. You can be audit-ready starting at about a week.
Take the free assessmentPolara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.