Segregation of Duties

“Segregation of duties requirement” is one of those controls auditors expect you to have, but many programs implement it as a vague principle rather than an enforceable operating model. That gap shows up quickly in access reviews, change management, finance operations, and incident response: one user has broad privileges, approvals are rubber-stamped, and the organization can’t prove independent oversight.

HITRUST CSF v11 09.c is explicit: separate duties and areas of responsibility to reduce opportunities for unauthorized or unintentional modification or misuse of organizational assets, and ensure no single individual controls all aspects of a critical business process or transaction ¹. For a CCO or GRC lead, the operational question is straightforward: which processes are “critical,” what combinations of actions are incompatible, and what technical and procedural gates prevent one person from doing everything end-to-end?

This page gives you a requirement-level implementation approach: scoping, role engineering, control design patterns, evidence to retain, exam questions to prep for, common mistakes, and an execution plan you can hand to IAM, Security, IT Ops, Finance, and Engineering without rewriting it.

Regulatory text

HITRUST CSF v11 09.c: “Duties and areas of responsibility shall be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization's assets. No single individual shall control all aspects of a critical business process or transaction.” ¹

Operator interpretation (what you must do):

• Identify the organization’s critical business processes and transactions (the ones where misuse, fraud, or error would materially impact confidentiality, integrity, availability, financial reporting, patient safety, or regulatory obligations).
• Define incompatible duties for each critical process (for example: request vs approve; develop vs deploy; create vendor vs approve payment).
• Implement preventive controls (access restrictions, workflow approvals, technical separation) so one person cannot perform incompatible duties in the same process.
• Where separation is not feasible due to size, staffing, or tooling, implement compensating controls that create independent detection and accountability (for example: immutable logs plus independent review by a different function).

Plain-English requirement: what “segregation of duties” means in practice

Segregation of duties (SoD) is the idea that power should be split across people and systems so that a single insider (or a compromised account) cannot single-handedly cause harm without being blocked or quickly detected.

For most regulated environments, SoD is not satisfied by a policy statement. Auditors look for enforced separation in:

• Identity and access management (IAM): users have only the roles they need; admin privileges are limited and time-bound where possible.
• Workflows: approvals require an independent approver; the approver cannot be the requestor.
• Operations: changes are reviewed, deployed, and reconciled by different individuals or teams.
• Monitoring: logs exist, are protected from tampering, and are reviewed by someone not performing the activity.

Who it applies to

Entity scope: HITRUST CSF v11 states applicability to all organizations ¹.

Operational scope (where it actually bites):

• IT administration: system administrators, cloud admins, database admins, EHR admins.
• Security operations: those who create rules vs those who approve exceptions; those who administer logging platforms.
• Engineering/DevOps: code authorship, code review, CI/CD approvals, production deployments, emergency changes.
• Finance and procurement: vendor creation, PO approval, invoice approval, payment release, reconciliation.
• Data governance: granting access to sensitive datasets, approving data sharing, exporting data.
• Third party access: onboarding third party users, granting privileged access, approving remote sessions, reviewing activity.

If you have a lean team, SoD still applies. The control objective remains: prevent a single person from controlling the full lifecycle of critical activity ¹.

What you actually need to do (step-by-step)

1) Define “critical processes” and “critical assets”

Create a short list that you can defend in an audit. Typical critical items include:

• Production environment changes (applications, infrastructure, configuration).
• Access provisioning for privileged roles and sensitive data.
• Payment and disbursement processes.
• Security logging configuration and retention.
• Backup/restore and key management operations.

Deliverable: a one-page inventory of critical processes and assets, with process owners.

2) Build an SoD matrix (incompatible duties map)

For each critical process, document roles and mark combinations that must not be held by the same person. Keep it readable.

Example (change management):

• Request change
• Approve change
• Implement/deploy change
• Validate/testing sign-off
• Post-change review / reconcile

Rule: the same individual cannot hold all roles, and specific pairs should be incompatible based on risk. The HITRUST requirement sets the standard that no single individual controls all aspects of the process ¹.

Deliverable: SoD matrix by process, approved by process owner + Security/GRC.

3) Translate the matrix into access roles and workflow gates

This is where programs fail: they stop at documentation.

Do the translation in three layers:

• IAM roles and groups: define roles that correspond to duties (Requester, Approver, Deployer, Reconciler).
• Workflow enforcement: configure systems so the requestor cannot approve their own request; require at least one independent approval for risky actions.
• Privileged access controls: restrict standing admin access; use a separate admin account; add step-up authentication where available.

Deliverables: role definitions, group mappings, workflow configuration screenshots/exports, and an access control standard.

4) Address privileged access and “break glass” paths

Privileged access is the fastest way to bypass SoD. Treat it as its own process:

• Separate admin identity from day-to-day identity.
• Limit who can grant admin rights vs who can use them.
• For emergency access (“break glass”), require documented justification and independent post-event review.

Deliverables: privileged access procedure, emergency access log, post-event reviews.

5) Define compensating controls (only when needed)

In small organizations, strict SoD may be impractical for every process. Compensating controls must create independent oversight.

Common compensating controls:

• Independent log review by someone outside the function (for example, Security reviews admin actions performed by IT).
• Exception-based alerts to a distribution list that includes a manager or compliance.
• Periodic reconciliation performed by Finance or internal audit rather than the operator who executed the transaction.
• Immutable logging with restricted admin rights to logging configuration.

Deliverables: exception register, compensating control descriptions, review records, and management sign-off.

6) Implement an SoD exception process

Auditors expect exceptions. They dislike undocumented exceptions.

Minimum exception process:

• Business justification and scope (system/process, role, duration).
• Risk acceptance by an authorized approver (often the system owner plus Security/GRC).
• Compensating controls selected and assigned to a reviewer.
• End date and confirmation of removal.

Deliverables: SoD exception form/ticket template, exception log, approvals, closure evidence.

7) Test SoD continuously (access reviews + transaction sampling)

SoD “works” only if it stays true after org changes, acquisitions, and tool migrations.

Testing patterns:

• User access reviews for privileged roles and sensitive systems.
• Workflow sampling: pick recent change tickets or approvals and confirm requestor ≠ approver and deployer ≠ approver (or documented exception).
• Admin activity sampling: confirm independent review of high-risk actions.

Deliverables: access review attestations, sampling worksheets, findings log, remediation tickets.

Required evidence and artifacts to retain

Keep these artifacts organized by process and system:

• SoD policy/standard describing principles and enforcement expectations.
• Inventory of critical processes and assets.
• SoD matrix (incompatible duties map) with approval history.
• Role definitions and IAM group mappings.
• System configuration evidence (approval workflows, role permissions, privileged access settings).
• Access review records and sign-offs.
• Change management records demonstrating separation (tickets, approvals, deployments, validations).
• Privileged access logs and “break glass” reviews.
• SoD exceptions register with approvals, compensating controls, and closure evidence.

If you use Daydream to manage compliance workflows, the fastest win is centralizing the SoD matrix, exception approvals, and review evidence in one system of record so audits don’t become a scavenger hunt.

Common exam/audit questions and hangups

Expect these:

• “Show me your SoD matrix for critical processes. Who approved it?”
• “Pick three recent production changes. Prove the requestor didn’t approve and deploy the change.”
• “Who can modify logging configurations? Who reviews those modifications?”
• “List all users with admin rights. Who reviews this list, and where is the evidence?”
• “How do you manage SoD for small teams where one person wears multiple hats?”
• “Show your SoD exceptions and how you ensured independent oversight.”

Hangups that slow audits:

• Roles exist on paper but are not mapped cleanly to IAM groups.
• Approvals happen in chat/email without a durable record.
• Break-glass access exists but has no after-action review.

Frequent implementation mistakes (and how to avoid them)

1. Declaring SoD without scoping critical processes.
   Fix: publish the critical process list first, then apply SoD rigorously there.

2. Relying only on “manager approval” while keeping broad admin access.
   Fix: enforce technical separation where possible; treat privileged access as a controlled process.

3. Overloading one “Admin” role with everything.
   Fix: split roles (for example, User Admin vs System Admin vs Security Admin) aligned to duties.

4. No exception mechanism, so exceptions go underground.
   Fix: create a lightweight exception workflow and require compensating controls.

5. Ignoring third party access.
   Fix: include third party accounts in the same role model, approvals, logging, and reviews.

Risk implications (why this control matters operationally)

SoD reduces two classes of risk described in the HITRUST text: unauthorized modification/misuse and unintentional errors ¹. Practically, it limits the blast radius of a compromised credential, reduces fraud opportunities, and improves the odds that mistakes are caught before they become incidents or reporting failures.

A practical 30/60/90-day execution plan

Days 0–30: Establish scope and design

• Confirm your list of critical processes/assets and name owners.
• Draft the SoD matrix for each critical process.
• Identify the top SoD gaps by interviewing process owners and reviewing current access lists.
• Decide where you can enforce SoD technically vs where you need compensating controls.
• Stand up an SoD exception workflow (ticket template + approval routing).

Days 31–60: Implement controls and start collecting proof

• Update IAM roles/groups to match the SoD matrix.
• Configure workflow tools to block self-approval and require independent approval.
• Separate admin identities from daily identities; tighten privileged access assignments.
• Start recurring access reviews for privileged roles and sensitive systems.
• Begin sampling transactions/changes to prove separation and log results.

Days 61–90: Operationalize and harden

• Close the highest-risk access conflicts; document exceptions where you can’t.
• Add independent log review for privileged actions and exceptions.
• Run an internal “mini-audit”: pick recent changes/payments/access grants and prove SoD end-to-end.
• Finalize the evidence pack: SoD matrices, reviews, exception log, and sample testing results.

Frequently Asked Questions

What counts as a “critical business process or transaction” for segregation of duties?

Treat a process as critical when one person controlling it could materially impact systems, sensitive data, money movement, or security monitoring. Document your rationale and get process-owner approval so you can defend the scope in an assessment.

We’re a small team. How can we meet the segregation of duties requirement?

Use compensating controls where strict separation is not feasible: independent review of logs and transactions, documented exceptions with time bounds, and management sign-off. The key is proving independent oversight so one person does not control the full lifecycle of critical activity.

Does segregation of duties only apply to Finance and SOX-style controls?

No. HITRUST CSF v11 09.c applies broadly to organizational assets and critical processes, which often includes IT admin, security tooling, production changes, and access provisioning ¹.

What evidence is strongest for auditors?

System-enforced workflow records (tickets/approvals), IAM role mappings, and access review sign-offs tend to be the fastest to validate. Pair these with an SoD matrix and a clean exception register.

How do we handle “break glass” admin access without failing SoD?

Allow emergency access only with strong logging, a documented justification, and an independent after-action review. Treat break-glass as an exception path with its own evidence trail.

Should third party administrators be included in SoD?

Yes. Third party accounts can create the same risk as employees, and often more if monitoring is weaker. Put third party admins into the same role model, approvals, logging, and periodic reviews.

Footnotes

1. HITRUST CSF v11 Control Reference