Segregation of duties ISO 27001 Annex A 5.3 in a small team

The enterprise security questionnaire asks a blunt question: can any single person ship code or release a payment alone? In a 30-person firm the honest answer is often yes, and the deal is waiting on it.

This guide covers segregation of duties ISO 27001 Annex A 5.3 for security leads, CTOs and compliance managers at 25–250 person firms. You will see which conflicts to split, how to enforce the split in tooling, and what to document when headcount says no.

What does ISO 27001 Annex A 5.3 require?

Annex A 5.3 requires that conflicting duties are segregated, so no single person can raise, approve and execute a sensitive action alone. The purpose is to prevent fraud, accidental error and unauthorised bypass of controls without collusion. Where headcount prevents a split, the principle applies as far as possible, with compensation.

The control covers every action where one person could otherwise hold both ends, from shipping their own change to releasing their own payment. Splitting those ends makes fraud harder and catches honest mistakes before they land. It also stops one compromised account quietly bypassing everything.

NIST Special Publication 800-53 Rev. 5 control AC-5 frames the aim the same way: reducing the risk of malevolent activity without collusion. The NCSC Secure design principles on separation of duties give the engineering version. Where the impact of misuse would be significant, they suggest the most dangerous functions should need two or more people working together.

Weakness here is how the classic small-company losses happen. An invoice payment nobody countersigned. An unreviewed deploy that takes the platform down. An admin who can erase the logs that would have shown either.

"Too small to split" is not a finding. Pretending the conflict isn't there is.

Annex A 5.3 is a preventive control that protects confidentiality, integrity and availability, with integrity doing most of the work. It builds on the role allocations made under Annex A 5.2. Its independence principle is the one Clause 9.2 applies to internal audit.

Which duty pairings are toxic combinations under segregation of duties?

The recurring toxic pairings are code author and merger, access requester and approver, system administrator and log auditor, and payment initiator and releaser. Each lets one person start, approve and hide an action. A one-page conflict matrix in the access-control policy, built from your sensitive workflows, is enough; hundreds of role pairings are not.

Find the conflicts before designing anything. Walk your handful of sensitive workflows: code to production, access grants, payments and supplier setup, and security control operation versus checking. Note where one person holds both ends today. That is your real conflict list.

Each pairing fails in a recognisable way:

• Code author and merger. The author ships a faulty or malicious change with no second view.
• Access requester and approver. Someone grants themselves standing privilege.
• System administrator and log auditor. The person with power over a system also judges the record of using it. Misuse can be erased or never reported.
• Payment initiator and releaser. A fraudulent invoice or altered supplier bank detail goes out on one signature.

Two further pairings earn a row if they apply: building software versus running production, and using a system versus administering it. Start wherever money or production is touched.

Write the result as a short conflict matrix inside the access-control policy. Include a break-glass path for genuine emergencies, which the small-firm section below sets out. Skip the enterprise SoD tool.

The opposite mistake is importing an enterprise conflict framework with hundreds of role pairings into a 40-person firm. You then fail your own unworkable rules, and the auditor finds the gap between the framework and what the team actually does.

How do you enforce segregation of duties in tooling rather than on paper?

Enforce the split in tooling: protected branches stop an author merging their own change, ticketing blocks requesters approving their own access, and dual authorisation covers bank payments. Roles in the identity provider keep requester, approver and executor permissions apart. A policy that forbids self-approval while the tooling allows it fails the audit interview.

Four enforcement points carry most of the weight at a firm this size:

• Protected branches in GitHub or GitLab require an approving review from someone other than the author and block direct pushes to the production branch.
• Ticket workflow gates stop a requester approving their own access and record the approval on the ticket.
• IdP role design keeps requester, approver and executor permissions in separate roles, so nobody holds all three by default.
• Bank dual authorisation requires a second person to release transfers, with supplier bank-detail changes checked separately.

The NCSC Operational Technology guidance on functional role separation states the principle in general terms: no single system, role or individual should have complete control over all aspects of a critical function. Your deployment pipeline is a critical function in exactly that sense.

Admin bypass is the usual hole. A branch rule the repository owner can switch off, or an approval step the ticket administrator can override, satisfies the policy and fails the test. Restrict who can change the rules, and log every change to them.

Test it yourself before the auditor does. Try to get your own change into production without a second person, and try to approve your own access request. If the tooling lets you, the policy describes a control you do not have.

The table shows what each enforcement point blocks and what it leaves behind for the auditor.

What does segregation of duties ISO 27001 expect from a 30-person firm?

A 30-person firm meets segregation of duties by splitting what it can, such as two-person deploys and payments, and compensating for the rest. Compensation means logs shipped where the admin cannot edit them, scheduled second-person review, supervision, and a risk-register entry recording leadership's signed acceptance of the residual exposure. Auditors accept that documented pattern.

Proportionality is the practical test. A firm with three engineers cannot staff separate build and run teams. It can require a second engineer to approve every production merge and put an operations lead on the second payment signature. The one cloud administrator can use a separate unprivileged account for daily work.

For the conflicts you cannot split, build four compensations:

• Independent logging. Ship admin activity to a store the admin cannot edit or delete, with alerts on privileged actions.
• Scheduled second-person review. A named reviewer reads those logs on a calendar and signs off each review.
• Management supervision. A director reviews privileged activity summaries and large payments.
• External spot-check. An outside party samples activity periodically.

Record the residual exposure in the risk register: the conflict, the compensating controls, the owner and leadership's signed acceptance. That entry is the audit-proof answer. Without it, the compensations look like coincidence.

How does break-glass access fit without breaking the split?

Emergencies happen. Production is down and the usual approver is on a plane. Write the break-glass path into the conflict matrix in advance: who may invoke it, how, and for how long.

Log every use and have a second person review it afterwards. Written, logged and reviewed, the exception sits inside the design and the segregation stands. Unwritten, it becomes the route everyone uses to work around the split. Hold the credentials in a vault that alerts on checkout, and rotate them after each use.

At this scale, a short matrix, four compensations and one signed entry per residual conflict satisfy both auditors and enterprise customers.

How do you stop privilege creep rebuilding the conflicts?

Privilege creep happens when people keep permissions from old roles until someone holds both ends of a workflow without anyone deciding it. Prune access at every role change and recertify on a cadence. Review privileged access quarterly and everything else at least twice a year, looking for conflicting permissions that have built up.

Creep is quiet. A finance analyst moves to procurement and keeps payment release rights. A developer becomes team lead and gains approval rights on top of merge rights. Nobody chose the combination; the permissions simply stayed.

A workable routine has three parts:

• Prune at role change. Make removal of old-role access a step on the mover ticket, not an afterthought.
• Recertify on a calendar. Each reviewer receives their people's access list, confirms or removes each item and signs off.
• Hunt for conflicts specifically. Reviewers check pairs from the conflict matrix, not just whether each permission looks reasonable alone.

Keep the sign-offs and the conflicts they caught. The recertification trail is one of the things an auditor samples, and a campaign that records removals shows the review has teeth.

What does a separation of duties audit test under Annex A 5.3?

A separation of duties audit samples recent production deploys for author-versus-approver, traces a privileged access grant end to end, checks permissions on the log store and reviews the recertification trail. Evidence is pull-request history, access tickets, payment records and signed risk acceptances.

Expect questions like these in the room:

• Can any engineer get their own code into production without a second person? Show me.
• If you requested elevated access for yourself, who would approve it, and could you?
• Who can release a payment alone?
• Your admin's activity is logged. Can the admin edit or delete those logs?
• Where you cannot separate duties, what compensates, and who accepted the risk?

At a firm this size the auditor tests the founder because the founder is the person most likely to hold every key. The expected answer is either a split or a documented, compensated acceptance.

Keep the evidence that answers each question:

• The conflict matrix, or the segregation section of the access policy.
• Pull-request history showing different author and approver, the most-sampled artefact at a tech firm.
• Access tickets where someone other than the requester approved the grant.
• Bank mandate and payment records showing two-person release.
• Log-store permissions that are read-only to the admins the logs cover.
• Recertification records with sign-offs and the conflicts they caught.
• Risk-register entries with compensating controls and the signed acceptance.

A split nobody can evidence is a split an auditor cannot credit.

Retention matters as much as the split. Approvals, timestamps and review sign-offs must still exist when the sample is drawn, so check the retention settings on your ticketing system and repositories.

How is a segregation failure graded?

As we read certification-body grading practice, a single person able to execute a sensitive action end to end and cover the trail, with no compensation and no documented acceptance, grades major. An occasional self-approved merge, a slipped recertification or a conflict matrix that has not kept up with a reorganisation grades minor. Minor lapses aggregate to major when they form a pattern.

Does Annex A 5.3 stop a security manager auditing their own work?

Yes. Whoever designs or operates a control cannot be the one assuring it, so a security manager cannot audit the controls they run. This independence between doing and checking is part of Annex A 5.3 as well as Clause 9.2. At small scale the practical fix is an external internal-audit provider.

The usual problem looks like this. The security manager wrote the access policy, runs the quarterly recertification and then signs off the internal audit of both. That is a review of their own work, and it cannot tell leadership whether the controls hold.

An external internal-audit provider solves this without a new hire. They sample deploys, grants and the log store as a certification auditor would, and report to leadership. Your security manager is left free to fix what they find. Where a colleague exists who neither designs nor operates the control under review, they can take that scope. What counts is who is checking, not their job title.

This is ISO 27001 separation of duties in its plainest form: operating and assuring stay with different people.

How does GRC engineering automate Annex A 5.3?

GRC engineering automates Annex A 5.3 because the enforcement points are already software. Branch-protection, ticket-approval and banking dual-auth settings export as evidence. Toxic pairings are flagged at grant time. A job alerts when one identity sits on both ends of an action, and admin logs stream to a store admins cannot touch.

The automation layer works control by control:

• Config as evidence. The branch rules, ticket gates and dual-auth settings are the control. Export them on a schedule and the design evidence maintains itself.
• Conflict rules at grant time. Encode toxic pairings as policy in the IdP or access tool. A conflicting grant is then flagged when requested, not found at the annual review.
• Author and approver monitoring. A job over version-control and ticketing APIs alerts whenever the same identity appears on both ends of a sensitive action.
• Immutable log shipping. Stream admin activity to a store admins cannot touch, closing the "who watches the watchers" gap that headcount cannot.
• Automated recertification. Scheduled campaigns assemble each reviewer's list, chase sign-off and archive the result.

A practical order starts with branch protection and payment dual authorisation, the quick wins and the most sampled. Add log shipping next, because it closes the largest compensation gap. Layer on grant-time checks and recertification campaigns once the matrix is stable.

Judgment stays with people: approving risk acceptances, reviewing flagged exceptions, deciding the break-glass policy. The scripts and settings ride on access-control work you are already doing.

The commercial upside is speed. When an enterprise questionnaire asks whether one person can ship code or move money alone, you answer with exported configuration and an alert history instead of a paragraph of intent. The review that used to stall a deal becomes an attachment.

Frequently asked questions