Separation of Duties: Don’t Give One Person Complete Control

Imagine an employee who has the ability to:

  1. Create a new supplier
  2. Approve the supplier
  3. Create an invoice for that supplier
  4. Approve the invoice
  5. Authorise the payment

That employee might be completely trustworthy – But the organisation has created a serious security weakness.

There is nothing stopping that individual from creating a fictitious supplier, approving it themselves, generating a fraudulent invoice and arranging payment.

There is also nothing preventing a mistake from progressing through the entire process without anyone else checking it.

This is the problem that the principle of Separation of Duties is designed to address.

The basic idea is simple – No single person should have enough authority to complete a sensitive or high-risk process from beginning to end without another person or control being involved.

Separation of duties is a fundamental security principle that reduces the opportunity for fraud, abuse, errors and unauthorised activity.

What is Separation of Duties?

Separation of Duties (SoD) means dividing a sensitive process or responsibility between multiple people, roles or systems.

The objective is to ensure that one individual cannot exercise complete control over a critical activity.

  • No individual controls the entire process.
  • A person requesting a payment cannot approve it.
  • The person approving a payment cannot necessarily release the money.

This creates a system of checks and balances.

Why is Separation of Duties important?

There are two major reasons for separating duties:

  • Preventing deliberate abuse – If one person controls an entire process, they may be able to abuse their position without requiring anyone else’s cooperation.
  • Detecting mistakes – People make mistakes.

Separating responsibilities means that another person may identify an error before it causes harm.

This means SoD protects against both:

  • Malicious behaviour
  • Accidental behaviour

It isn’t necessary to assume that employees are untrustworthy, instead, the organisation recognises that security shouldn’t depend entirely on trusting individuals.

Separation of Duties vs Least Privilege

Separation of duties is closely related to least privilege, but they aren’t the same thing.

Least privilege asks “What permissions does this person actually need?”, whereas separation of duties asks “Should this person be able to perform all of these actions themselves?”

For example, a finance employee may legitimately need permission to create payments.

Least privilege might therefore give them permission to create payment requests, but separation of duties might prevent them from approving their own requests.

So:

Least privilege – Give the employee only the permissions required for their job.

Separation of duties – Don’t give the employee enough permissions to control the entire sensitive process.

The two principles complement each other.

The four-eyes principle

A common implementation of separation of duties is the four-eyes principle.

This means that certain sensitive actions require two people to review or approve them.

The exact implementation varies between organisations

So in one case, both people might need to approve an action, or alternatively, one person might create a request while another approves it.

The underlying principle is the same – One person should not have unilateral control over a particularly sensitive operation.

Separation of Duties in cybersecurity

SoD is particularly useful for controlling privileged access.

Consider a large organisation with several administrators.

Without appropriate separation, one administrator might be able to:

  • Create an account
  • Give that account administrator privileges
  • Disable logging
  • Modify security controls
  • Delete evidence of their activity

That’s an enormous amount of power concentrated in one individual.

A more secure environment might separate these responsibilities with multiple administrator account roles

For example:

  • Identity Administrator – Creates accounts
  • Access Administrator – Assigns permissions
  • Security Administrator – Manages security controls
  • Security Operations – Monitors activity

The exact division will depend on the organisation, but the objective is the same. It is to avoid creating a single account with unrestricted control over every aspect of the environment.

Separation of Duties and insider threats

One of the most important reasons for implementing SoD is protection against insider threats.

An insider threat doesn’t necessarily mean a malicious employee.

It can include:

  • A disgruntled employee
  • A compromised employee account
  • An employee making an accidental mistake
  • An administrator abusing their privileges
  • Someone being socially engineered

Consider an employee who has the ability to modify payroll records – If they can also approve payroll changes, they may be able to alter their own salary without independent oversight.

With separation of duties, the process is more difficult to abuse and provides additional opportunities for suspicious activity to be detected.

Separation of Duties and defence in depth

Separation of duties is also an example of defence in depth.

Imagine an attacker compromises an administrator’s account. The attacker now has the privileges associated with that account, but if the organisation has separated critical responsibilities, the compromised account may not be able to complete the attack.

The initial compromise still happened, but another security layer prevents it from becoming a much larger compromise.

This is an important point – Security controls don’t always need to prevent an attacker from gaining access. They can also prevent the attacker from turning that access into something more damaging.

Separation of Duties and auditing

SoD also works particularly well when combined with logging and auditing.

Suppose one employee creates a sensitive request and another approves it.

The organisation can record the following actions:

10:32 — User A created request #4832

10:47 — User B approved request #4832

10:49 — System applied change

This creates an audit trail.

If something suspicious happens later, investigators can determine:

  • Who requested the action
  • Who approved it
  • Who implemented it
  • When it happened
  • What was changed

The audit trail also creates accountability.

Separation of Duties and automation

Modern organisations don’t always need another human for every step. SoD can also be implemented through technical controls and automated workflows.

A software deployment system can enforce rules such as:

The person who submitted the change cannot approve their own production deployment.

This is particularly useful in large organisations where manually enforcing every separation would be impractical.

Automation can therefore enforce SoD consistently and provide an audit trail.

What happens in a small organisation?

Separation of duties can be difficult for small organisations.

Imagine a company with only five employees – There may simply not be enough people to separate every responsibility.

The finance manager for example might have to perform several parts of a process.

This doesn’t mean SoD should be abandoned – Instead, organisations can introduce compensating controls.

For example:

  • Management review
  • Periodic audits
  • Automated transaction alerts
  • Independent reconciliation
  • Detailed logging
  • Regular access reviews
  • External audits

The objective is to reduce the risk created by having multiple responsibilities concentrated in one person.

Compensating controls

A compensating control is an alternative control that provides protection when the ideal control cannot be implemented.

Ideally, two employees should approve financial transactions, but a very small organisation may have only one person capable of doing so.

The organisation might instead require:

  • Automatic transaction alerts
  • Monthly independent review
  • Bank reconciliation
  • Management oversight

This doesn’t provide exactly the same protection as two-person approval, but it can still reduce the associated risk.

This is an important lesson – Security principles need to be applied according to the organisation’s risk, size and circumstances.

The danger of excessive Separation of Duties

Like least privilege, separation of duties can be taken too far.

Imagine a process requiring six different people to approve a simple £10 purchase.

The organisation might have excellent separation of duties, but it might also have an extremely inefficient procurement process.

Excessive controls can lead to:

  • Delays
  • Increased costs
  • Administrative overhead
  • Frustrated employees
  • People looking for ways around the process

Security controls therefore need to be proportionate to the risk.

A £10 purchase doesn’t necessarily require the same controls as a £10 million transaction.

Identifying where Separation of Duties is needed

Organisations should identify activities where one person having complete control could create significant risk.

Examples include:

  • Financial transactions
  • Privileged account management
  • Production deployments
  • Security configuration changes
  • Access approvals
  • Password resets for privileged accounts
  • Data deletion
  • Backup management
  • Software releases
  • Changes to critical infrastructure

For each process, the organisation can ask – “Could one person abuse this process without another person or control detecting or preventing it?”

If the answer is yes, separation of duties may be appropriate for that process.

In summary

Separation of Duties is the practice of dividing sensitive responsibilities between multiple people, roles or systems so that no single individual has complete control over a high-risk process.

It can help organisations:

  • Reduce fraud
  • Reduce accidental errors
  • Limit insider threats
  • Reduce the impact of compromised accounts
  • Prevent unauthorised changes
  • Improve accountability
  • Create stronger audit trails
  • Provide checks and balances

Common examples include:

  • Separating payment creation from payment approval
  • Separating software development from production deployment
  • Separating access requests from access approval
  • Separating account creation from privileged access assignment
  • Separating system administration from security monitoring

The principle isn’t about assuming that people are untrustworthy – It is about recognising that no individual should have unnecessary control over a process where abuse or mistakes could have significant consequences.

The fundamental idea is simple – Don’t give one person all the keys.

If one person can request, approve, implement and conceal a sensitive action, the organisation has created a significant point of failure. By separating those responsibilities, the organisation introduces another layer of security — one that can prevent mistakes, discourage abuse and limit what happens when an individual account is compromised.