Segregation of Duties in the Database: From Policy to Behaviour

Segregation of duties means one person cannot complete an operation end to end on their own. It sounds bureaucratic and usually stays inside a policy document. Its purpose is not bureaucracy but cutting off the damage a single point of failure or abuse can cause. This article is about moving the rule out of the document and into the behaviour of the system.

What Segregation of Duties Actually Prevents

It prevents two different risks and both matter equally. The first is abuse: if one person can approve their own action, there is no control. The second, and in practice the more frequent one, is error: a second pair of eyes sees what the first missed. Organizations usually talk about the first risk while most of the daily benefit comes from the second.

Four Conflicts on the Database Side

The fourth row is rarely considered. The process is built, the controls are defined, and then the same person can switch a control off from a settings screen. Applying four eyes to the request flow while leaving the settings screen open is locking the door and leaving the key on top of it.

Does the Control Slow You Down?

The first objection to segregation of duties is not technical but about speed: if everything needs two people, work stops. The objection comes from a fair observation but builds the wrong equation. What slows things down is not the presence of control but applying the same weight of control to every change. The four rules below cost no speed.

One: nobody approves their own request. This costs no delay, because the second person is already on the team. Enforcing the rule in the system is different from writing it in a document; the document is a description, the system is a gate.

Two: separating approver from executor should be a setting. In some organisations an approver executing is acceptable, in others it is not. Making the rule configurable rather than hard coded lets each organisation decide by its own risk appetite. What matters is not the setting itself but who can change it and how.

Three: keep the non skippable list short. When certain rules fire, no fast path should apply. But if that list grows, the system jams in an emergency and the team abandons the process altogether. A short list gets obeyed; a long one gets bypassed.

Four: if a breach is not blocked, it must at least be visible. Some organisations accept the requester executing their own request. Accepting it and not seeing it are different things: an accepted exception leaves a record, an invisible one becomes an audit finding.

Once these four are in place the number to measure changes too: not how many approval steps exist, but how long a request takes from opening to execution. Setting approval depth by risk band, and why a change board jams, are covered separately in when the change board becomes a bottleneck.

How to Do It in a Small Team

The most common objection is fair: with three people, how do you separate duties? The answer is not to block every conflict at once. The priority order is:

• Always block: approving your own request. This is achievable even in a team of three and gives the highest return.
• Decide per organization: the approver executing the change. It can be allowed in a small team; what matters is that the decision is deliberate and recorded.
• Compensate with automation: a single reviewer. When people are scarce, the rule engine becomes the second pair of eyes.

There is also an arithmetic reality: forbidding self approval requires at least two users holding each permission in scope. This is about how permissions are distributed rather than team size. Even in a team of three, two people can hold the same screen permission.

The Emergency Exception

What happens at 2 AM when the system is down and there is nobody to approve? There are two wrong answers. The first is to allow no exception, after which the team bypasses the process entirely and nothing is recorded. The second is to allow the exception silently, after which the exception becomes the rule.

The right answer is to make the exception visible: record it as a distinct event when used, require a justification and report how often it happens. An exception used three times a month says something in the process needs fixing. The exception count is a quality metric.

What the Auditor Checks

The auditor reads the policy but looks for three things in the system. First, whether the rule is really enforced: what happens when a user tries to approve their own request? Second, the historical state of the rule: was it on six months ago as well? Third, the trace of exceptions: how often was the rule bypassed and by whom?

The second item defeats most organizations. Showing today's configuration is easy; proving the past configuration requires freezing the rule set at the time of the action. Without that, the answer to the auditor becomes "I believe it was on", and that is not evidence.

Frequently Asked Questions

Can segregation of duties work in a team of three?

It can, but the definition changes. In a small team the goal is not to give every role to a different person, but to stop one person holding two critical roles on the same item. Someone can be the approver on one request and the executor on another. What matters is that nobody approves their own request.

Can segregation of duties be suspended in an emergency?

It should not be suspended, it should be shortened. The emergency path can reduce the number of approval steps, but at least one step should remain and be tied to an on call role. An emergency path where the rule is fully switched off eventually becomes the normal path.

How does an auditor verify that segregation of duties works?

They look at two things. First, that the rule is defined in the system; a document is not enough. Second and more important, evidence that the rule works: a record of blocked attempts. For a rule that has never blocked anything, the auditor cannot tell whether it really works or was simply never tested.