Separation of Duties

Separation of duties limits the ability of one actor to misuse a sensitive process alone. NIST’s definition uses the example of separating preparation of a paycheck from its authorization. Identify the conflicting powers and the action they could enable before assigning roles.

DORA describes independent change approval as a common separation requirement and recommends peer review as an implementation. The requirements applicable to an organization must still be established from its obligations and policies. A reviewer needs authority, relevant information, and a protected way to refuse; a second name in a workflow is not enough.

Static and dynamic enforcement

NIST distinguishes static constraints on conflicting roles from dynamic checks at access time. Its two-person example requires different authorized users for the two parts of an operation. Dynamic enforcement can also depend on the history of who acted on the same object or transaction.

Static separation makes the forbidden combination visible in role assignments; it requires staffing and access arrangements that preserve the split. Dynamic separation can allow people to hold roles while preventing a prohibited combination for a particular operation. It must cover alternate paths and relevant history, not merely test each action in isolation. Neither model automatically authorizes emergency bypass. Role-based and attribute-based access control explains how grants are expressed, while least privilege addresses their scope.

Conflicting powers to examine

PairWhat it preventsAn implementation failure
Requesting and approvingSelf-granted access and self-approved exceptionsThe requester is the only person who understands the request, so the approval is nominal
Producing artifacts and authorizing their deploymentA producer bypassing the required verification or approvalThe producer can alter checks, impersonate the approver, or use deployment credentials outside the protected path
Administering keys and reading dataA key administrator quietly decrypting what the keys protectThe same actor can administer keys and obtain protected data without the required independent authorization
Acting and controlling the retained evidenceAn actor rewriting evidence of their actionsThe acting identity can modify or delete retained logs. See audit log

DORA recommends preserving peer reviews and approvals in the development platform. Bind that approval to the change and artifact actually deployed, and protect the reviewer requirements, evidence, verifier, and bypass permissions. A shared orchestrator can enforce a check outside the producer’s control; separate identities fail to provide independence if one can alter or impersonate the other.

When the team is too small

Staffing depends on conflicts between roles, availability, and required expertise. Four independent pairs can be split between two people: one holds each first role and the other each second role. Additional cross-role conflicts or coverage requirements may need more people. When the actual assignments cannot meet the required split, consider the following options under the applicable policy.

  1. Borrow the second person. Review by someone outside the team, limited to the classes where it matters, rather than for everything.
  2. Automate an authorized policy where permitted. A machine can enforce well-specified constraints within a previously approved scope. Protect its rules, evidence, credentials, and bypass paths from the actor being checked. It cannot replace a separate person where independent human approval is required.
  3. Use an approved compensating control where allowed. Protected logs, alerts, and independent retrospective review can detect misuse when prevention is infeasible. The appropriate authority must accept the residual risk and define coverage and review conditions. Detection alone does not satisfy an unchanged requirement for preventive separation.

How apparent separation fails

  • An approver who cannot evaluate. A signature from someone without the context converts a control into latency, which is the substance of the argument against distant approval bodies.
  • The emergency path. A bypass needs explicit authority, bounded permissions, and an examination of each use. Preserve evidence outside the actor’s alteration rights. Urgency alone does not authorize suspending the split.
  • Automation with unchecked authority. Inspect whether a service identity can change both the output and the controls that authorize it, including impersonation and bypass. Identity count alone does not establish independence. Standing privilege addresses how long those grants remain available.
  • Evidence that cannot be verified. A retained chat approval can be useful if it identifies the approver, time, scope, and approved change and is protected and retrievable. A disappearing message or unlinked signature may fail those conditions. Assess the evidence’s properties rather than rejecting a medium by name.

Trace an actual production change and ask who can produce it, authorize it, change the check, or bypass deployment restrictions. For data, examine the power to grant access and use it; for evidence, examine alteration rights and retention. Confirm that the independent reviewer has enough information and authority to refuse. Governance body explains where a standing review body fits into those assignments.

How this principle sits inside a governance design, alongside decision rights and automated controls, is worked through in Forty Approvals and Two Rejections.

References


Discover more from Insightful Data Lab

Subscribe to get the latest posts sent to your email.

Similar Posts

Questions, corrections, or additional insights?

This site uses Akismet to reduce spam. Learn how your comment data is processed.