GUIDE

Separation of duties
without the headcount.

The control assumes an organisation large enough to split responsibilities across different people. Most engineering teams are not that organisation, and pretending otherwise produces documentation rather than security.

The control, and the assumption underneath it

Separation of duties requires that no single individual controls every stage of a sensitive process. The person who requests a change should not be the person who approves it; the person who approves should not be the person who reviews the log afterwards. Break the chain into stages held by different people and no one person can complete a harmful sequence undetected.

This works in an organisation with distinct teams. It assumes there is someone else to hand the next stage to. At a company where six engineers share on-call and everyone has production access because they must, that assumption fails immediately.

The failure mode: writing it down and moving on

The common response to an audit question about separation of duties is a policy document describing roles that map loosely onto reality, plus a note that the CTO reviews access quarterly. This satisfies the auditor and changes nothing operationally. The same engineer still holds every credential needed to delete the company's data, and the control exists only on paper.

It is worth being clear that this is a real gap, not a paperwork problem. The reason separation of duties is required is that concentrated capability is dangerous, and a small team concentrates it more, not less.

What actually works at small scale

You cannot separate roles you do not have. You can still separate the moment of action, which captures most of the value.

Separate acting from authorising, not role from role. Everyone may hold the same permissions; the control is that using them on a high-risk operation requires someone else to agree at that moment.
Put the gate in the system, not the process. A rule people are expected to follow is not a control. A webhook that only fires at threshold is.
Make the evidence external. If your approval record lives in the same system your admins control, it proves little. Signatures made on personal devices, verifiable without trusting the server, hold up much better.
Include the founders. A control that exempts whoever holds the root credentials is not a control. This is the step small teams skip most often.
Keep the list short. Five operations that genuinely require agreement, enforced without exception, beat thirty that people work around.

How this maps to what auditors ask

Frameworks are generally less prescriptive than people expect. They ask whether privileged actions are controlled and evidenced, not whether you have a particular org chart. A small team that can show a specific list of high-risk operations, each requiring approval from two named people, each with a cryptographic record of who approved and why, is answering the question well — arguably better than a larger organisation with separated roles and no verifiable record of individual decisions. The related detail on change management specifically is in the SOC 2 guide.

Common questions

We are three people. Is separation of duties even achievable?

Full role separation is not, but threshold approval on your highest-risk operations is, and that is the part that provides actual protection. Two of three is a workable threshold for a team of that size.

Does this replace least privilege?

No. They address different problems and work together. Least privilege limits what each person can reach; separation of duties limits what any one person can complete alone.