In the last posts, I wrote about audit, compliance, and trust, and how all three tend to break down for the same underlying reason: systems forget the business story. When decisions can no longer be explained in context — when time, responsibility, and intent are flattened into “current state” — organisations compensate by adding controls. More reviews. More approvals. More process.

Trust, in that sense, turns out not to be a cultural problem at all, but an architectural one.

Separation of duties sits squarely in the same space. It is usually framed as a security concern, enforced through role-based access control and permission matrices. And yet, despite all that machinery, it remains one of the most fragile compliance requirements in practice.

What’s striking is that the problem is rarely a lack of rules. It is that the system never made decisions explicit in the first place.

Separation of duties is usually introduced late in a system’s life.

Once functionality is in place, once workflows exist, once data is flowing, someone asks the inevitable compliance question: Who is allowed to do what? Roles are defined, permissions are assigned, access matrices are created. Sometimes entire governance layers are added on top of an already complex system.

And still, separation of duties remains fragile.

What’s interesting is that this fragility rarely comes from missing permissions. It comes from something much more fundamental: the system never made decisions explicit in the first place.

Most security models are built around access to data and functionality. Who can read this record? Who can update that field? Who can execute this action?

These questions are useful, but they are not the questions compliance is asking.

Compliance cares about authority, responsibility, and independence. It asks: Who may initiate a decision? Who must approve it? Who must be excluded from doing both? Who can review it afterward?

Those are not data questions. They are decision questions.

This is why separation of duties so often feels bolted on.

When systems are modelled around state and access, authority is inferred indirectly. “Write access” becomes a proxy for decision-making power. “Admin rights” quietly collapse multiple responsibilities into one role. Over time, the same person can initiate, approve, and correct a change — not because anyone intended this, but because the model never distinguished those acts.

The result is predictable: compliance rules that look strict on paper, but are hard to reason about in practice.

Let’s look at two examples, from two different domains, that reveal the same underlying issue.

Example 1: Claims in Life & Health insurance

In a claims process, separation of duties is usually very clear at a business level.

One role assesses the claim: verifies facts, checks coverage, evaluates eligibility. Another role approves the pay-out. A third role may execute the payment. Yet another role reviews claims after the fact.

Everyone agrees this separation is necessary.

And yet, in many systems, claims are modelled as a mutable record. Whoever can update the claim can often do all of the above — assess, approve, and trigger payment — simply by moving the claim through states.

From a compliance perspective, this is deeply uncomfortable. Not because the people are untrustworthy, but because the system cannot clearly show who made which decision.

If, instead, the model treats “assess claim”, “approve claim”, and “release payment” as distinct business decisions — each with its own moment in time — separation of duties becomes almost trivial. Roles attach to decisions, not to records. Violations are no longer subtle; they are structurally impossible.

Example 2: Payments in finance

The same pattern appears in payment systems.

Most organisations require that the person who initiates a payment is not the one who approves it. Often, a third role is required to release funds or reconcile payments afterward. This is one of the oldest separation-of-duties rules there is.

And yet, many systems still model payments as a single object that moves from “created” to “approved” to “paid”. Access rights are layered on top to prevent abuse.

The trouble starts when exceptions appear. Urgent payments. Overrides. Corrections. Suddenly, permissions expand. Roles blur. Controls multiply.

Again, the issue is not enforcement. It is modelling.

When initiation, approval, and execution are treated as explicit decisions — each recorded, each attributable, each irreversible — separation of duties stops being a fragile rule and becomes part of the structure of the system.

No one needs to remember not to do two things. The system simply does not allow the same person to do both.

What both examples have in common is this: compliance requirements are being forced onto models that were never designed to express authority.

Role-based access control then becomes a compensating mechanism. It tries to infer intent from access, responsibility from permissions, and separation from configuration.

That’s a losing battle.

When decisions are first-class concepts, security changes character. Roles are no longer about who can “edit” something. They are about who may participate in a specific decision. Separation of duties is no longer a rule that must be checked everywhere; it is a property of the model.

Audit trails become natural. Reviews become simpler. Exceptions become explicit instead of dangerous.

Most importantly, compliance stops fighting the system.

This is why separation of duties is not primarily a security problem.

It is a modelling problem.

If a system cannot clearly express what decisions exist, who may make them, and when they were made, no amount of RBAC configuration will make it safe in a way that compliance can trust.

When it can, much of the defensive machinery quietly becomes unnecessary.

In regulated environments, this distinction matters.

Security that protects data may prevent accidents. Security that protects decisions prevents abuse.

And the latter only works when decisions are modelled explicitly — not inferred from state, not hidden behind permissions, but visible as part of the business story the system preserves.

If you’ve been following the previous posts in this series, this should feel familiar by now.

Trust emerged when systems remembered business history. Audit became easier when the story was preserved. Governance became quieter when decisions were explainable.

Separation of duties follows the same path.

Not as a configuration exercise. But as a consequence of taking business decisions seriously.

Prior posts in the series:

• Post 1: We lack a shared language and blueprint
• Post 2: We can work with a small set of repeatable building blocks
• Post 3: We need a living map for the enterprise
• Post 4: When “change state” quietly reshapens our boundaries
• Post 5: Where does a domain get the facts it needs to make a decision?
• Post 6: Boundaries Follow Decisions, Not Data
• Post 7: When software makes simple business decisions hard
• Post 8: Why Systems Forget What the Business Never Did
• Post 9: Why EventModeling Still Struggles in the Enterprise
• Post 10: Why “Current State” Is a Dangerous Lie in Decision-Heavy Systems
• Post 11: Audit, Compliance, and Governance Don’t Need More Controls — They Need the Story
• Post 12: Trust Is Not a Cultural Problem — It’s an Architectural Outcome

Originally published on LinkedIn (2026-01-14): https://www.linkedin.com/pulse/separation-duties-modelling-problem-gabriel-n-schenker-op9qe