It often starts with a small request. A colleague calling in sick, a looming deadline, or an understaffed team during the summer holidays. "Can we make an exception to the separation of duties just this once?" As an IT manager or CISO, you almost always say yes, because the business must keep moving. But did you know that single "yes" is often the beginning of the erosion of your Separation of Duties (SoD) policy? The policy remains intact on paper, but in practice, it is being undermined.
In this article, we dive into the world of SoD: why it is a cornerstone of frameworks like ISO 27001 and the BIO, and why it tends to go wrong in daily practice.
Proposition: The day your organization approved its first SoD exception was the day the principle began to lose its value.
That sounds harsh. But take a look at the reality within your own organization. An employee falls ill. A colleague resigns. It’s summer, and three people are on vacation at the same time. And then the question reaches you: can we make a temporary exception to that strict separation of duties? The answer is almost always "yes." The pressure on daily operations is simply too great to allow processes to stagnate.
And so, something creeps into what began as a fundamental security measure: the habit of the exception.
But is that really so bad? Or is SoD inherently too rigid a concept for the dynamic reality of your modern organization? And where does the four-eyes principle fit into this story—is it an alternative, a supplement, or something else entirely?
Separation of Duties (SoD) means that no single employee can complete a critical process entirely on their own. In the world of risk management and IT security, this principle is also known by the synonymous term Segregation of Duties. Whether you refer to it as separation or segregation, the core remains the same: the division of functions.
The logic is simple: if you can create, approve, and process a payment all by yourself, you alone have the means to commit fraud and subsequently hide it. By distributing these steps across different individuals or roles, you make abuse structurally more difficult and ensure that errors are detected more quickly.
For your organization, SoD is a fundamental measure within identity governance and a strict requirement for ISO 27001, SOX, and the BIO (Baseline Information Security Government). However, the crucial question is not whether the policy exists on paper, but whether it actually holds up within the daily operations of the organization.
Separation of Duties is not a modern IT invention. The principle is centuries old and originates from the world of accounting. In the past, people already knew: you never let one person receive the money, count it, and audit the cashbook at the same time. If one person holds all those roles, it becomes far too easy to pocket money unnoticed.
This logic—separating custody, recording, and authorization—was officially established in international standards (such as COSO) in 1992. However, the real shift toward IT only occurred after 2002. Following massive accounting scandals at companies like Enron, the American Sarbanes-Oxley Act (SOX) forced companies to tighten their control systems. From that moment on, separation of duties in IT systems became the standard.
Nowadays, you can no longer bypass SoD. It is a permanent fixture in nearly every security framework your organization encounters, such as:
Does your organization deal with privacy legislation, government audits, or financial inspections? Then SoD is no longer just friendly advice—it is a strict obligation.
The core of SoD is simple: you break a critical process into pieces. No single employee is allowed to perform all steps alone.
Consider these examples from your daily operations:
In practice, there are usually two ways to organize this:
This is the most common form. You determine in advance that certain roles may not belong to the same person. If you hold Role A, you simply cannot be granted Role B.
This is a smarter approach. Someone may technically possess both permissions but is not allowed to use them within the same transaction or action.
Finally, we distinguish between how you intervene:
A mature organization chooses a combination: blocking where necessary, and providing a safety net of monitoring where a total block is unworkable.
This is where things often get tricky. The reality within your organization is much more chaotic than an auditor’s beautiful diagrams. Vacations, illness, or a sudden project: there is always a reason why the standard rules are momentarily inconvenient.
The solution? An exception. "Just this once," you say. It’s done with the best of intentions and neatly documented.
Making an exception isn't the issue. Things go wrong during what happens (or doesn't happen) afterward. A secure exception requires three things:
In practice, someone is granted temporary extra permissions, but everyone loses track of time. Six months later, those permissions are still active. At that point, your security policy is merely a "paper reality"—a checkbox for the accountant.
This is dangerous. Treating SoD as a simple checkbox gives you a false sense of security. You believe you are managing risks, while in reality, the back door is standing wide open.
Because SoD can be difficult in practice, many organizations wonder: isn't the four-eyes principle simply a better alternative?
The four-eyes principle (also known as dual control) is simple: an important action always requires two people. One person initiates the action, and the other approves it. Think of a system administrator requesting a change, which a second administrator then executes only after an additional check.
There is often confusion, but it is actually quite logical:
The four-eyes principle does not replace SoD; it supplements it. It can be an excellent temporary solution if you cannot perfectly close the loop on separation of duties.
Beware! This only works if the second person is actually paying attention. If approving becomes a routine task where someone blindly clicks "agree," you still lose all security.
The best approach for your organization? Use SoD as the foundational structure and implement the four-eyes principle as an extra lock on the door for the most high-risk tasks.
Here is the final part of the translation, maintaining the professional and authoritative tone:
The old-fashioned way of handling separation of duties—a list of forbidden combinations reviewed by an auditor once a year—no longer works. Today’s IT landscape has simply become too fast and too complex.
There are three major shifts your organization must take into account:
Nowadays, you likely have more "digital identities" than human employees. Think of automated integrations (APIs), software robots, and AI systems. The old rules were designed for people with fixed job titles, but how do you handle a computer program that creates and approves an account all by itself?
More and more modern organizations are moving away from permanent permissions. Instead of an employee always having certain authorities, they are granted them only at the moment they truly need them—and only for the duration of the task. This ensures that dangerous combinations of permissions simply never exist simultaneously.
With traditional methods, you only discover errors during the annual audit. But if someone performed a forbidden action yesterday and quickly relinquished their rights afterward, the auditor will never see it. Modern systems provide continuous monitoring and send an immediate alert if something unauthorized occurs.
This requires a smart platform—Identity Governance & Administration (IGA)—that brings all these layers together. It is no longer about isolated lists, but about a system that constantly keeps its finger on the pulse: who has what access, why, for how long, and exactly what are they doing with it?
Back to the question: is the first exception the beginning of the end?
Not necessarily. Making an exception is human and sometimes simply necessary to keep the business running. The real problem is the "uncontrolled" exception: one without an expiration date, without extra monitoring, and without anyone watching.
SoD remains indispensable for your organization. Not just because the auditor demands it, but because it is the only way to truly prevent fraud and major errors. However, this principle only works with a "living" system. This means no annual retrospective audits, but smart software that monitors the situation every single day.
In this setup, the four-eyes principle serves as your extra lock on the door during high-stakes moments.
Organizations that don't just have these rules on paper, but actually make them work in practice, are more secure and breeze through every audit. That is exactly the peace of mind and control that a modern IGA platform provides.