Separation of Duties

Separation of duties means you must design and enforce access and workflow controls so no single person can execute (and conceal) a critical action end-to-end, especially for system administration, financial transactions, and PHI access. Under HICP Practice 6.4, you operationalize this by defining “critical functions,” splitting permissions and approvals, monitoring for conflicts, and retaining auditable evidence of enforcement ¹.

Key takeaways:

• Define your critical functions first, then map who can request, approve, execute, and review each one.
• Enforce separation with technical controls (roles, approvals, privileged access) plus detective controls (logs, reviews).
• Auditors will test “effective separation,” not just a policy statement, so keep role matrices, access evidence, and review records.

Separation of duties is one of those controls that looks simple on paper and breaks quickly in real operations. The failure mode is predictable: a small set of admins, analysts, or billing staff end up with “temporary” rights that become permanent, and suddenly one individual can create an account, grant access, change logging, and view sensitive PHI without a second set of eyes. HICP Practice 6.4 calls this out directly: enforce separation of duties for critical functions to prevent any single individual from having excessive control over sensitive operations ¹.

For a Compliance Officer, CCO, or GRC lead, the fast path is to stop treating separation of duties as an HR concept and treat it as an access and workflow design problem. Your job is to (1) define which actions are “critical,” (2) assign clear roles for request/approve/perform/review, (3) implement those roles in your IAM and your key systems, and (4) prove it with evidence an auditor can test. This page gives you a requirement-level playbook you can put into motion immediately.

Regulatory text

HICP Practice 6.4 (excerpt): “Enforce separation of duties for critical functions to prevent any single individual from having excessive control over sensitive operations.” ¹

Operator interpretation (what you must do):

• Identify critical functions in your environment (HICP points to areas such as system administration, financial transactions, and PHI access) and treat them as high-risk actions requiring split control ¹.
• Implement preventive controls so one person cannot complete a critical activity end-to-end without another authorized person’s involvement.
• Add detective controls that reveal if separation fails (for example, emergency access, role stacking, or direct database access outside normal workflows).
• Maintain evidence that separation is implemented and operating, not merely documented.

Plain-English requirement (what separation of duties means in practice)

Separation of duties means you intentionally break a sensitive process into parts that are performed by different people (or different roles), so mistakes, fraud, and abuse are harder to execute and easier to detect. In a healthcare context, the “sensitive operations” include actions that affect:

• PHI confidentiality (viewing, exporting, bulk access, account provisioning for PHI systems)
• PHI integrity (changing medical records, interfaces, clinical decision support rules)
• System integrity (admin changes, disabling security tools, modifying logs)
• Financial integrity (refunds, write-offs, payment destination changes)

HICP’s purpose statement is explicit: prevent any single individual from having excessive control over sensitive operations, and reduce conflicts of interest and fraud risk in functions like system administration, financial transactions, and PHI access ¹.

Who it applies to

Entity types

• Healthcare organizations (providers, payers, clearinghouses, and their internal operations that touch PHI or supporting systems) ¹
• Health IT vendors (EHR/EMR providers, revenue cycle platforms, managed services, SaaS handling PHI, and product teams operating production systems) ¹

Operational contexts where auditors focus

• Privileged access: domain admins, cloud admins, database admins, EHR super-users.
• Security tooling: EDR/SIEM administrators, log pipeline owners, alert suppression rights.
• Identity lifecycle: user provisioning, role grants, MFA resets, break-glass access.
• Revenue cycle: refunds, adjustments, charge master updates, bank account changes.
• Third-party administration: MSPs, billing services, and consultants with elevated access.

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

1) Define “critical functions” for your environment

Create a short list of actions that could cause material harm if performed by one person without oversight. Start from HICP’s examples (system administration, financial transactions, PHI access), then tailor to your stack ¹.

Deliverable: Critical Functions Register (system + action + risk rationale).

2) Break each critical function into request / approve / execute / review

For each critical function, define:

• Requester: who initiates the need (ticket, form, change request)
• Approver: who authorizes it (manager, system owner, compliance)
• Executor: who performs the action (IT admin, billing specialist)
• Reviewer: who validates after the fact (access reviewer, security, internal audit)

Rule of thumb: if one role can approve and execute, you have a separation gap unless you implement compensating controls.

Deliverable: RACI per critical function.

3) Translate RACI into enforceable access roles

Convert “people-based separation” into “role-based separation”:

• Define mutually exclusive roles (examples: “Access Provisioner” vs “Access Approver,” “Billing Adjustment Initiator” vs “Billing Adjustment Approver”).
• Block role stacking in IAM where feasible.
• Require workflow approvals in the system of record (EHR, IAM tool, ITSM).

Deliverable: Role definitions + SoD rules (including incompatible role pairs).

4) Implement preventive controls in the systems that matter

Focus on the control points auditors test first:

• IAM / SSO: RBAC groups, admin role assignments, SCIM provisioning controls.
• Privileged access: separate admin accounts, privileged session controls, approval gates for elevation.
• EHR / PHI systems: limit “super-user” assignment, enforce break-glass with justification.
• ITSM / change management: require approvals before execution for high-risk changes.
• Finance systems: dual approval for sensitive transactions and master data changes.

Deliverable: Configuration evidence (screenshots/exports) showing enforcement.

5) Add detective controls for when reality breaks your model

Separation fails in emergencies, during outages, and in small teams. Plan for that:

• Log and alert on privilege elevation, role changes, and break-glass use.
• Run periodic reports for toxic combinations (users holding incompatible roles).
• Require targeted review of sensitive actions (bulk exports, refund overrides, logging changes).

Deliverable: Monitoring rules + review records.

6) Establish an exception process that doesn’t become the norm

You will need exceptions (on-call coverage, small clinics, mergers). Define:

• Who can approve exceptions (system owner + compliance/security)
• Required compensating controls (increased logging, independent review)
• Expiration and re-approval triggers

Deliverable: SoD exception register with start/end dates and approvals.

7) Test effectiveness and fix gaps before audit season

Validate operationally:

• Sample a set of critical changes and prove they followed request/approve/execute/review.
• Attempt to assign incompatible roles in a test environment and confirm it is blocked or detected.
• Confirm terminated users cannot complete any critical steps.

Deliverable: SoD effectiveness test results with remediation tickets.

Required evidence and artifacts to retain

Auditors typically want proof in three layers: design, implementation, and operation.

Design

• Separation of Duties policy / standard referencing critical functions ¹
• Critical Functions Register
• Role catalog with incompatible role pairs (“toxic combinations”)
• RACI matrices and process flows

Implementation

• IAM role/group membership exports
• System configuration exports (EHR admin role settings, finance workflow approvals)
• Privileged access configuration (separate admin accounts, elevation approval flows)

Operational

• Access request tickets with approvals
• Change tickets with approvals and implementation evidence
• Logs showing elevated access use and review sign-off
• Periodic access reviews that specifically check for incompatible roles
• Exception register with compensating control verification

If you use Daydream to run your access reviews and third-party access attestations, structure your evidence outputs so they map cleanly to “who had what access,” “who approved it,” and “what review occurred,” because that is the audit spine for SoD.

Common exam/audit questions and hangups

• “Show me your definition of ‘critical functions’ and who owns it.”
• “Who can add users to privileged groups, and who approves those changes?”
• “Can one person both provision access and approve access for the same system?”
• “How do you prevent or detect admin disabling of logging or security tools?”
• “Show recent examples of break-glass access and the follow-up review.”
• “How do you manage SoD for third parties with administrative access?”

Hangup auditors return to: a policy that says SoD exists, while the IAM export shows a few users with stacked privileges and no documented exceptions.

Frequent implementation mistakes (and how to avoid them)

1. Relying on titles instead of permissions. “Only managers can do X” is meaningless if the system role allows it. Fix: enforce role-based controls in IAM and the application.
2. Ignoring emergency access. Break-glass becomes a backdoor. Fix: require justification, time-bound access, and post-use review.
3. SoD only for IT, not finance or PHI operations. HICP explicitly includes financial transactions and PHI access. Fix: build a cross-functional critical functions register ¹.
4. No exception lifecycle. Exceptions never expire. Fix: require expiration and re-approval.
5. Access reviews that don’t test “toxic combinations.” A quarterly review that only checks “does the user still work here” misses the real SoD risk. Fix: include incompatible role checks and document outcomes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page avoids attributing SoD failures to specific enforcement outcomes. Practically, separation of duties is a high-signal control because it directly affects the likelihood that inappropriate PHI access, unauthorized system changes, or improper financial actions can occur without detection ¹. Treat SoD gaps as a governance and security risk with operational consequences: investigation costs rise, incident response becomes harder, and internal accountability gets murky when logs and approvals are not clean.

Practical 30/60/90-day execution plan

Use this as an execution sequence, not a promise of exact timing.

First 30 days (baseline and triage)

• Create the Critical Functions Register anchored to system administration, PHI access, and financial actions ¹.
• Pull current privileged access and “super-user” lists from IAM, EHR, finance, and cloud consoles.
• Identify obvious toxic combinations and document emergency exceptions already in place.
• Draft SoD standard: definitions, role principles, exception process, and evidence expectations.

Days 31–60 (enforce in workflows)

• Build RACI matrices for each critical function and obtain system owner sign-off.
• Implement incompatible role restrictions where supported.
• Add approval steps in ITSM/IAM workflows for privileged grants and sensitive changes.
• Stand up monitoring and a basic review cadence for break-glass and privilege changes.

Days 61–90 (prove effectiveness and operationalize)

• Run an SoD effectiveness test: sample access grants and critical changes; verify approvals and independent review.
• Clean up exceptions: add compensating controls, set expirations, remove stale elevated access.
• Embed SoD checks into onboarding/offboarding and access review routines.
• Package audit-ready evidence: role matrices, exports, review records, exception register.

Frequently Asked Questions

What counts as a “critical function” for separation of duties?

Start with HICP’s examples: system administration, financial transactions, and PHI access ¹. Add any action that can materially affect confidentiality, integrity, availability, or financial integrity if performed without oversight.

We’re a small organization. What if we don’t have enough staff to separate every duty?

Use documented exceptions with compensating controls: stronger logging, independent after-the-fact review, and time-bound elevated access. Auditors usually accept constraints if you can show you recognized the risk and added oversight.

Is a policy alone enough to meet the separation of duties requirement?

No. You need evidence that the separation is enforced in access controls and workflows, plus operating evidence like approvals, logs, and periodic reviews ¹.

How do we handle “break-glass” access for PHI systems?

Require a named user, a documented justification, and short-lived access, then perform a post-use review of what was accessed. Keep the approval and review records together with the event logs.

Do third parties need to follow our separation of duties model?

Yes for the access they hold in your environment. Contract language helps, but auditors will still expect you to control and review third-party access paths, especially for privileged or PHI-touching roles.

What evidence is most persuasive in an audit?

Role/permission exports showing enforced separation, tickets showing independent approvals, and review records showing you detect and remediate toxic combinations. Package these by critical function so the auditor can trace end-to-end.

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices