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.

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.