Segregation of Duties (SoD)

What segregation of duties is

Segregation of Duties (SoD) is the control principle that critical activities affecting GxP records should be divided among different individuals so no single person can both perform the activity and approve it. The principle reduces fraud risk, error risk, and the bias of conflict-of-interest. In regulated electronic systems, SoD is the policy layer that role-based access control enforces operationally.

The classic regulated cases: an analyst running a test shouldn't approve their own result; a document author shouldn't approve their document for release; a change requester shouldn't approve the change; an investigator shouldn't approve closure of their own investigation; a system administrator shouldn't have routine GxP user privileges; an audit lead shouldn't both run the audit and close the findings.

SoD is sometimes called "separation of duties" or "the four-eyes principle." The terminology varies; the substance is the same. Regulators expect documented SoD analysis, role definitions that enforce it, compensating controls for unavoidable exceptions, and periodic review that catches drift.

Why SoD has become an explicit inspection topic

SoD weaknesses turn up in nearly every data integrity inspection finding. The pattern: an analyst creates a test result, the same analyst electronically signs the approval, no one independent reviews the underlying data, and an OOS result later surfaces a data integrity issue the approval should have caught. The system permitted what the policy should have blocked.

Modern data integrity guidance from MHRA (March 2018, updated September 2021), PIC/S PI 041-1 (July 2021), and FDA's December 2018 DI Q&A all treat SoD as a baseline control. PIC/S PI 041-1 specifically references the four-eyes principle and the need for role separation. Inspectors look for SoD analysis documented in role definitions and access control SOPs, not just stated as policy intent.

Inspector perspective: a typical inspector technique is to pick one critical workflow — a batch release, a CAPA closure, a deviation disposition — and trace it back. Who initiated it? Who reviewed it? Who approved it? If the same name appears in two of those three positions, the inspector will want to see the SoD analysis that accepted that combination and the compensating controls that mitigate it. If the analysis doesn't exist, the conversation about whether the record can be trusted starts there.

Where SoD obligations come from

SoD isn't named in a single section of any predicate rule; the obligation comes from several intersecting expectations:

• 21 CFR §11.10(d): limiting access to authorised individuals — presupposes that authorisation is granted by role, with conflicts considered.
• 21 CFR §11.10(g): authority checks. The system checks the user has the authority for the specific action; the authority structure is what enforces SoD.
• 21 CFR §11.100: unique signature attribution. SoD applies because a single user's signature shouldn't be acceptable for both sides of a separated activity.
• 21 CFR §11.50: signature meaning. The meaning captured (review, approve, responsibility) is the layer SoD analysis operates on.
• 21 CFR §211.22(a): quality control unit responsibility for approval or rejection — the predicate for QA independence from production.
• 21 CFR §211.68(b): control over computerised systems including the people authorised to make changes.
• EU GMP Annex 11 §2 — Personnel: clear definition of responsibilities.
• EU GMP Annex 11 §12 — Security: authority to enter, change, or delete data should be defined; access should reflect role; expects SoD-aware role design.
• EU GMP Chapter 2 §2.5: roles and responsibilities clearly defined to prevent overlap.
• MHRA "GxP" Data Integrity Definitions and Guidance for Industry (March 2018, updated September 2021): addresses segregation of duties as a data integrity control.
• PIC/S PI 041-1 (July 2021): explicitly references the four-eyes principle and role separation; sets the most detailed regulator expectation on the topic.
• FDA Data Integrity and Compliance With Drug CGMP Q&A (December 2018): addresses SoD in the context of supervisor review and independent review of data.
• ICH Q10 §2: management responsibility for resources and structure; SoD-aware role definition sits inside this.
• ISO 13485 §5.5: responsibility, authority, communication — the device-side framework for documented role separation.
• ISO 27001 A.6.1.2: segregation of duties as an information-security control; often referenced in regulated firms' broader access policy.

What a working SoD program contains

A defensible SoD program contains these elements operating together:

• Documented SoD matrix. A controlled document identifying the activity pairs that must be separated, the roles that enforce the separation, and the rationale. Updated when roles change or new systems come online.
• SoD analysis at role design. When a role is defined or revised, the SoD matrix is checked: does this role grant rights that conflict with another role? Can a single user hold both? If yes, what's the mitigation?
• SoD enforcement at assignment. When a user is assigned to a role, the assignment workflow checks against other roles the user holds. Conflicting assignments trigger an approval gate.
• Documented and approved exceptions. Where business need requires a conflict (small team, specialist function), the exception is documented with justification, compensating controls, senior management approval, and periodic re-confirmation.
• Compensating controls actually performed. Independent secondary review, elevated audit trail review frequency, expanded periodic access review — defined for each exception and operationally executed.
• Periodic SoD review. The SoD matrix and current role assignments reviewed periodically (typically annually) to catch drift. Role definitions that have expanded since the matrix was approved get flagged.
• Periodic access review includes SoD check. When access is reviewed quarterly, the review explicitly checks for conflicting role combinations on individual users, not just whether each role is still warranted.
• Audit trail review surfaces SoD violations. Patterns like the same user signing both review and approval of the same record are flagged for investigation.
• Training on SoD principles. Users with multiple roles understand which combinations are constrained and why. Role owners understand their role's SoD implications.
• Management Review input. SoD exception count, exception aging, compensating-control closure rate are standing inputs to Management Review.

What strong SoD programs do

The patterns that hold up at inspection:

• SoD matrix is current. Versioned, approved, periodically reviewed; not a static spreadsheet from initial system go-live.
• Role definitions designed against the matrix. Not retrofitted to the matrix after the fact.
• System enforces, doesn't just suggest. The system blocks conflicting role assignment, not just warns. Override requires documented approval.
• Exceptions are governed. Documented, justified, senior-management-approved, and time-bound or periodic-reviewed.
• Compensating controls operate. Defined for each exception, performed on schedule, evidence retained.
• Periodic SoD review separate from access review. Both happen; both produce records. The SoD matrix itself gets reviewed, not just the assignments against it.
• Audit trail review surfaces SoD violations. Same-user-on-both-sides patterns get flagged in the review program.
• Training reinforces SoD culture. Users with multiple roles know which combinations matter and why.
• Management Review tracks SoD metrics. Exception count, exception aging, compensating-control effectiveness — all reviewed.
• External and contractor access included. SoD constraints apply equally to vendors, consultants, and auditors.

How Complere supports SoD enforcement

SoD analysis is your work — Complere can't decide for you which activity pairs need separation in your firm's context. What the platform does give you is the role and authority infrastructure that turns your SoD policy from intent into enforcement, so the system blocks what your policy says shouldn't happen.

You configure roles per regulated workflow. Inside each workflow, roles map to specific actions — draft, review, approve, sign, close — and to the signature meanings each role is allowed to apply. That mapping is how you enforce, for example, that the person who reviewed a CAPA can't also approve it: you define "reviewer" and "approver" as distinct roles with distinct signing authority, and your assignment process keeps one user from holding both unless you've documented an exception.

When one of your users tries to act on a record, the system checks at that moment whether they have the action permission and the signature authority. Rights you revoked yesterday don't carry over today. Every signing event is recorded with the user, the meaning, the timestamp, and the binding to the record — so when your team or your auditor reviews the trail, any same-user-on-both-sides pattern shows up plainly.

What stays your work: the SoD analysis itself (which pairs of activities your firm separates, which conflict combinations need senior justification), the role design that operationalises that analysis, the documented exceptions and the compensating controls that govern them, your periodic SoD review cadence, and the training that keeps your team aware of which combinations matter and why. Complere supports the program; you run it.

Related access control and governance terms

SoD sits inside the broader access-control discipline:

• Role-Based Access Control (RBAC) — the operational mechanism SoD policy depends on
• User Access Review — the periodic process that catches SoD drift
• Electronic Signature — SoD constrains who can apply which signature meaning
• Audit Trail — captures the signing events SoD governance examines
• Audit Trail Review — the discipline that surfaces SoD violations
• 21 CFR Part 11 — §11.10(d), §11.10(g), §11.100, and §11.50 together expect SoD-aware controls
• Data Governance — SoD is one of the controls a DG program operationalises
• Data Integrity — SoD supports the Attributable principle of ALCOA+