ISO 27001 Control A.5.3: Segregation of Duties

Some mistakes are honest and some are not, and the surest way to prevent both is to make sure no single person can do everything. The person who raises a supplier invoice should not also approve and pay it. The developer who writes a change should not be the only one who reviews it and pushes it to production. A.5.3 is the control that puts this old idea, familiar from finance and audit, into your information security management system. It is the third of 37 organizational controls in Annex A.

For small teams this control can sound unrealistic. When you have eight people and one of them is the entire IT department, strict separation is not always possible. The standard knows that, and so do we. The goal is to understand where conflicts exist, separate them wherever you reasonably can, and put visible safeguards in place where you cannot.

What the control requires

Annex A control 5.3 of ISO 27001:2022 states that conflicting duties and conflicting areas of responsibility shall be segregated.

The key elements:

Conflicting duties - tasks which, when combined in one person, create an opportunity for fraud, error or abuse that nobody else would notice
Conflicting areas of responsibility - not just single tasks, but whole domains, such as owning a system and also being the one who audits it
Segregated - split between different people or roles, or, where that is impossible, covered by compensating measures

A.5.3 is a preventive control in ISO/IEC 27002:2022. It reduces the risk of unauthorized or unintentional modification or misuse of assets by making sure that one person acting alone cannot complete a sensitive process end to end. Annex A states the control in a single sentence; ISO 27002 gives the guidance, including the point that if segregation is hard to achieve, other controls such as monitoring of activities, audit trails and management supervision should be considered.

How to implement segregation of duties

Find the conflicts that matter

You do not need to segregate everything. Start with the processes where a single person could cause serious harm or hide a mistake. Typical examples include:

Requesting, approving and implementing access rights
Writing, reviewing and deploying code or infrastructure changes
Creating a supplier, approving invoices and releasing payments
Administering a system and administering the logs that record what administrators do
Running a security control and independently testing that control

Look at your information security risk assessment and at your list of critical processes, and ask of each: if one person did every step here, what could go wrong, and who would notice? Write the answers down as a short conflict matrix, with roles on one axis and duties on the other, marking the combinations that must not sit together. A one-page table is enough, and it is very persuasive in an audit.

Design roles around the matrix

Once you know the toxic combinations, build your roles to avoid them. Roles defined in your information security roles and responsibilities should state not only what a person does but what they must not do. In practice this means using separate accounts or permission sets for requesting and approving, requiring a second person to approve high-risk changes, and making sure the owner of a system is not the sole reviewer of its security.

Technical enforcement works better than a promise. If your ticketing tool, code platform or finance system can block the requester from approving their own request, switch that setting on. Branch protection that requires a second reviewer is a cheap and effective example. We often find these features available and simply unused.

Consider also the timing of access. Someone who moves from one team to another can quietly accumulate conflicting permissions over the years. Our post on responsibilities after termination or change of employment covers the people side of that problem, and later controls on access rights deal with periodic review.

Compensate when you cannot separate

In a small business the same person may have to hold two conflicting duties. That is acceptable if you show you thought about it. Good compensating measures include:

Independent review after the fact - a director or external party reviews a sample of changes, payments or admin actions every month
Logging that the actor cannot edit - audit trails sent to a place the administrator cannot alter
Management supervision - a named manager who is accountable for noticing unusual activity
Rotation or time limits - privileged access that is granted for a task and then removed

Document the exception, the reasoning and the compensating control in your risk treatment. Auditors tend to respond well to a candid note saying “we are too small to separate this, so the managing director reviews the monthly admin log” and badly to silence.

Keep it alive

Organizations change. New tools get adopted, teams merge, and a role designed with care two years ago now holds three extra duties. Review the conflict matrix whenever you reorganize, introduce a major system or change suppliers, and at least once a year in your regular ISMS review. Segregation also applies to people outside the payroll: contractors and suppliers who administer your systems should be covered by the same thinking.

A.5.1 connection. Policies for information security is where the principle of segregation is usually stated, with detail left to topic-specific policies and procedures.

A.5.2 connection. Information security roles and responsibilities defines the roles that this control then keeps apart.

A.6.1 connection. Screening matters most for the people who must hold sensitive, hard-to-separate duties.

A.6.5 connection. Responsibilities after termination or change of employment is the moment when old permissions should be removed so conflicts do not build up.

Clause 5.3 connection. Clause 5.3, Organizational roles, responsibilities and authorities, requires top management to assign and communicate security roles, which is the foundation for separating them.

Clause 8.2 connection. Information security risk assessment is where the processes that need separation are identified.

Forward reference. Access control, access rights, privileged access rights and change management are covered later in the series; they supply many of the technical mechanisms behind segregation.

What auditors check

Awareness of conflicts. Auditors ask whether you have identified which duties conflict and how you decided. A conflict matrix or a paragraph in your risk assessment is usually enough to answer.

Role definitions. They compare job descriptions and system roles with the stated conflicts, looking for someone who holds both halves of a sensitive process.

System configuration. Expect a live demonstration, for example showing that a person cannot approve their own access request or merge their own code change.

Samples of real activity. Auditors pick a few recent changes, payments or access grants and trace who requested, approved and executed each one.

Treatment of exceptions. Where one person does hold conflicting duties, they look for a recorded decision and a working compensating control.

Privileged users. They check that people who administer systems are not the only ones who can see or alter the logs of their own activity.

Common mistakes to avoid

Treating it as a finance-only idea. Segregation matters just as much in IT, development and security operations, where a single administrator can often do everything.

Ignoring the small-team reality. Pretending you have segregation when you do not is worse than admitting the gap and compensating for it.

Relying on trust. “We trust Anna” is a fine management attitude and a poor control. Controls protect Anna as well, because they show she could not have done anything wrong unnoticed.

Letting permissions accumulate. People change roles and keep old access. Without periodic review the conflict matrix quietly stops reflecting reality.

Forgetting third parties. An outsourced administrator with full rights and no review is a conflict like any other.

Paper-only separation. A procedure that says two people must approve, in a tool that lets one person click both buttons, will not survive a sample test.

How 27kay can help

We help organizations find the conflicts that actually matter and design separation that fits their size, so you are not inventing bureaucracy for a five-person team or leaving a dangerous combination unnoticed. As part of ISO 27001 implementation, we build the conflict matrix with you, choose sensible compensating controls, and prepare the evidence for your audit. For the full picture, see our ISO 27001 knowledge hub.

If one person in your organization could change, approve and hide something important, would you know? Get in touch - we will help you find out and fix it in a way that suits your team.