Every regulated quality system rests on a simple assumption: no single person should be able to approve their own work.
The principle is called separation of duties. In the context of document workflows, it takes a specific and enforceable form: the author, reviewer, and approver for any given document must be three different people.
This is not optional. It is the foundation of credible quality records — and one of the first things an auditor checks.
This guide explains why separation of duties matters, how it plays out in regulated environments, and how to enforce it without turning every release into a bottleneck.
What separation of duties actually means
Separation of duties (sometimes called segregation of duties) is the principle that critical tasks should be divided among multiple people so that no single individual can complete a process end-to-end without oversight.
In a document workflow, that means:
- The author drafts the document and submits it for review.
- The reviewer independently reviews the document and either passes it forward or returns it.
- The approver — typically a QA approver — signs the document as final.
None of these three people may be the same person as another. Not for the same document. Not for the same release.
If one person writes a document, "reviews" it, and approves it, the review step is theatre. The document has passed through the motions of oversight without any actual oversight occurring.
Why it matters in regulated environments
Separation of duties appears directly in most regulatory frameworks:
- 21 CFR Part 11 requires that electronic signatures be attributable to specific individuals, and that systems ensure "the series of steps necessary to complete a process" cannot be performed by one person alone where oversight is required.
- EU GMP Annex 11 requires that the system be designed to ensure that only authorised persons can make changes — implicitly requiring separation between those who author and those who approve.
- ICH Q10 frames oversight as part of the pharmaceutical quality system, with clear roles and responsibilities separated across functions.
- ISO 13485 requires that personnel performing verification and validation are not the same as those who developed the item.
Different regulators use different language. They mean the same thing: no self-approval.
The reason is not legalistic. It is empirical. Self-approved documents correlate with errors, and errors in regulated environments correlate with quality failures.
What separated workflows look like in practice
Consider a System Design Specification (SDS) for a product release. In a well-designed workflow, the SDS passes through three distinct people.
| Step | Role | Action | Who |
|---|---|---|---|
| 1 | Author | Draft the SDS, upload it, and sign Submit | Named engineer |
| 2 | Reviewer | Sign Review (to pass forward) or Reject (with reason) | Senior engineer, different person |
| 3 | QA Approver | Sign Approve (to finalise) or Reject (with reason) | QA approver, third person |
Three signatures. Three humans. No shortcuts.
If the reviewer rejects, the SDS returns to the author. The author corrects the document, uploads a revision, and re-submits. The reviewer reviews the revision. If the reviewer passes it forward, the QA approver signs.
At no point does a person's action grant them another person's authority.
The three signatures
Each signature records:
- The user who signed
- The time of the signature
- The action (Submit, Review, Approve, Reject)
- The meaning (re-entered password, in the case of approval-type actions)
- The file fingerprint of the document being signed (SHA-256)
The fingerprint matters. If the file changes after submission — even by one byte — the reviewer or approver's action is refused. The author must re-submit the corrected revision through the workflow.
Without fingerprinting, "separation of duties" is just role theatre. A reviewer signs off on version A; the author quietly uploads version B; the approved document is not the one that was reviewed.
With fingerprinting, the workflow enforces what it says: the document you approved is the document that was reviewed.
Common anti-patterns
Teams adopt separation of duties in principle but break it in practice. Five recurring anti-patterns.
1. The "small team" exception
"We only have four people on this team. Sometimes one person has to wear multiple hats."
The exception defeats the principle. If your team is genuinely too small to separate author, reviewer, and approver, either bring in someone from a different function (a colleague from engineering, a QA representative) or accept that your release process cannot be compliant. Do not write a policy that says separation of duties is required and then quietly allow one person to sign three times.
2. The "trusted individual" exception
"We've worked with this engineer for fifteen years. She doesn't need a reviewer."
Trust is not the variable. Review is. The reviewer is there to catch errors, not to catch dishonesty. The most experienced engineer on the team produces the same volume of typos and misread requirements as anyone else.
3. The "email thread" exception
"The reviewer replied 'looks good' in the email thread. That's the review."
An email reply is not a signature. It is not attributable to a specific document version. It is not timestamped against a file fingerprint. It is not audit-trailed. If the reviewer meant to sign off, they must sign off — in the system.
4. The "approval by proxy" exception
"The QA approver is out this week, so the Release Manager approved it on their behalf."
If the QA approver cannot sign, either the release waits or a delegated approver signs. The Release Manager does not have the authority to sign on someone else's behalf. Ever.
5. The "matrix change" exception
"We changed the matrix. The new version says only two signatures are required."
The matrix can be changed — but as a formal version. The change is submitted, signed, and QA-approved. If the change reduces the number of signatures required for a document, that reduction is itself auditable. There is no undocumented shortcut.
Enforcing separation of duties without slowing releases
The natural objection to separation of duties is speed. If every document requires three signatures from three different people, releases will slow down.
This is true for organisations that enforce separation of duties badly — through email chains, shared drives, and follow-up phone calls. It is false for organisations that enforce it structurally.
Three things make separated workflows fast:
1. Role-aware dashboards
Each person sees what is waiting on them — nothing more. An author sees drafts to submit. A reviewer sees documents to sign. A QA approver sees gates awaiting authorisation. There is no "did you see my email?" step.
2. Clear assignment rules
Every document has an author, a reviewer, and a QA approver assigned at release creation. Product defaults fill these in automatically. Overrides are explicit. There is no ambiguity about who signs what.
3. Stage gates that enforce, not just check
Rather than a Release Manager chasing signatures before a gate, the gate itself refuses to open until the signatures exist. The gate is the enforcement point. This converts a management problem into a workflow property.
In practice, teams that implement these three things reduce DEV-gate preparation from days to hours — while increasing, not decreasing, their audit-readiness.
Special cases and edge cases
Multiple roles on the same person
A user can hold more than one role. An engineer might be both an Author and a Reviewer. A senior manager might be both a Reviewer and a Manager.
Holding multiple roles is fine. Using them on the same document is not. The same person cannot sign as both the author and the reviewer for a single document, even if they hold both roles.
Delegation
When a person is unavailable, their responsibilities must be delegated explicitly. Delegation is not the same as acting on someone's behalf. The delegate signs as themselves, using their own credentials, in their own role.
Matrix change approvals
The same principle extends to matrix changes. A product matrix change requires separate approvals from a Manager, a QualityManager, and a ProductOwner. The requester cannot approve their own request. One person cannot provide multiple approvals for the same request.
Release-stage gate signatures
Gate signatures follow the same pattern. The person who records a deployment cannot sign the corresponding gate approval. The QA approver signing the gate must differ from the Release Manager who recorded the deployment.
Document reopening
If an approved document is reopened (say, to fix an error discovered later), the release returns to In Progress. The document goes back to Draft. When it is resubmitted, the same separation rules apply: author, reviewer, and approver must be three different people.
What auditors look for
An auditor reviewing your documentation process will typically check:
- Were the author, reviewer, and approver for each document three different people? Cross-referenced against the user table.
- Was the review performed on the same version that was approved? Checked via file fingerprint.
- Was the review completed before the approval? Checked via timestamps.
- Was the approval completed before the gate signature? Checked via timestamps.
- If a signature was rejected and the document re-submitted, was the rejection recorded with a reason? Checked via audit trail.
Every one of these questions has a binary answer in a properly designed workflow. In a spreadsheet-and-email process, the same questions often have no answer at all.
The bottom line
Separation of duties is the foundation of credible quality records. It is enforced by three rules: three different people, one document, no exceptions.
If your current process relies on email threads and verbal sign-offs, the separation exists on paper but not in practice. If your process enforces separation through a workflow system with electronic signatures, the separation is real — and auditable.