What is Separation of Duties?
Definition
This control is common across regulated industries specifically because it addresses a risk that peer review alone doesn't fully cover: a single compromised or malicious actor with both authoring and approval permissions could bypass review entirely. Requiring a different person to approve closes that gap, regardless of how trustworthy any individual is assumed to be, since the control is designed to hold even in the worst case rather than the typical one. Enforcing Separation of Duties reliably requires being able to verify who actually authored and who actually approved a given change, which depends on Identity-Aware Access Control rather than shared credentials that make individual attribution unreliable. Without that underlying identity layer, the policy exists on paper but can't actually be checked at the moment a deployment happens.
Why Separation of Duties matters
Peer review catches honest mistakes and oversights, but it doesn't fully address a scenario where the same person controls both sides of the approval process. Separation of Duties is specifically designed for that case: even a well-intentioned developer shouldn't be able to approve their own risky change, and a compromised account with both permissions represents a much larger risk than one with only one of them. Regulators and auditors in many industries treat this control as a baseline expectation rather than an optional best practice.
How Separation of Duties is enforced
Enforcing this control requires two things: reliably knowing who authored a change and who approved it, and a mechanism that blocks a change from deploying if those two identities match. The first depends on Identity-Aware Access Control tying activity to specific, verified identities rather than shared credentials. The second is typically implemented as a Governance Policy, enforced through Policy Checks that verify approver and author are different before allowing a deployment to proceed. Exceptions, such as small teams where this is genuinely impractical, usually need a documented compensating control instead.
How Liquibase helps
Liquibase Secure supports Separation of Duties as a configurable governance policy, checked automatically as part of the deployment process rather than relying on a person remembering to verify it manually. Combined with identity-aware controls, this gives organizations a control that's actually enforced every time a change deploys, rather than a written policy that depends on individual diligence to hold up in practice. Documented exceptions matter as much as the policy itself; an auditor reviewing this control usually wants to see not just that it's enforced, but that any deviation from it was itself reviewed and approved through a separate process. Smaller teams sometimes satisfy this control through a rotating approver arrangement, so the requirement holds even when headcount makes a permanent separate approval role impractical.
