ISO 27001 Control 5.3: Segregation of Duties

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

The Purpose of Segregation of Duties

The primary goal of Segregation of Duties (SoD) is to prevent any single individual from performing tasks that could result in conflicting responsibilities.

This separation of duties mitigates the following risks:

• Fraudulent Activities: Prevents opportunities for financial or operational misconduct.
• Unintentional Errors: Reduces the likelihood of mistakes going unnoticed.
• Control Bypass: Strengthens the effectiveness of implemented security measures by ensuring oversight and accountability.

You can think of it as trying to ensure that, where possible, someone isn’t, for example, requesting and approving their own access rights to systems, or undertaking an audit of their own work. Objectivity and independence are important aspects of security and review that ISO 27001 requires you to implement.

It’s the exact same concept as why, at school, you had to swap your answer paper with the kid next to you when marking in class.

Key Areas Requiring Segregation

It doesn’t normally jump out to people as to where and how to go about this, so here are some thoughts on areas where I would normally guide a review, but the principle applies anywhere a single person could both act and conceal that action.

Examples include:

Change Management

Any IT team I’ve ever worked in has segregated roles for initiating, approving, and executing changes to prevent unapproved modifications. The person requesting a change should never be the same person who authorises it, and ideally, a third party deploys it into the live environment. This creates a clear audit trail and ensures changes have been properly considered before they reach production.

If you’ve ever been on a team with a rogue engineer who doesn’t believe in change management or a Request for Change process, then you’ll know what I mean. Poorly executed changes are among the highest causes of outages and disruptions to services. Well-intentioned but poorly considered changes can and do bring organisations to their knees, which directly impacts the ‘availability’ aspect of security.

Not to mention that getting extra eyes on changes brings other considerations to the table and can help avert major security oversights and other issues.

Access Control

This is the key one that auditors will look at, and something I always focus on with my clients when implementing the controls.

It’s important to assign separate responsibilities for requesting, approving, and implementing access rights to minimise the risk of unauthorised access.

A line manager might request access for a new starter, an information owner approves it based on business need, and IT then provisions the account. Without this separation, individuals could grant themselves elevated privileges with no independent check. Without this, you could find accounts with much greater levels of access than strictly necessary to undertake their jobs.

Code Development and Review

I’ve worked with enough software development teams now to know the crucial value of distinct roles for designing, implementing, and reviewing code to maintain software integrity and prevent vulnerabilities. The larger the team, the more I would value it.

Peer review or formal code review by someone other than the original developer is the standard control here, and most modern version control platforms make this straightforward to enforce. This catches both honest mistakes and deliberate insertion of malicious or unauthorised functionality.

Software Development vs. Production Administration

It follows from the above that it is often necessary to separate development roles from those managing production systems to reduce risks of unauthorised or accidental changes.

Developers should not have standing administrative access to live environments, and production administrators should not be modifying application code. More mature teams I’ve worked with have a DevOps team that owns deployments to the production environment, and the development team cannot touch it unless directly supervised and for a good reason.

Where small teams make full separation impractical (and we’ll come back to this), compensating controls such as logged break-glass accounts and independent monitoring become essential.

Security Control Design and Auditing

Divide responsibilities for designing, auditing, and validating security controls to maintain impartiality and effectiveness.

The person who designs and implements a control is rarely the right person to assess whether it works as intended; objectivity is hard to maintain when reviewing your own work.

ISO 27001 understands this, and in the main standard, where it refers to the internal audit process under clause 9.2.2, it mandates that auditors “conduct audits that ensure objectivity and the impartiality of the audit process”. Again, in a smaller organisation, this can be difficult, but not impossible to address and you can use an external resource, or train someone up in auditing to conduct it internally.

What If You’re Too Small to Fully Segregate Duties?

This is the question I tend to preempt with my SME clients. If you’re a team of ten or fewer, you simply cannot replicate the separation that a bank or government department maintains. The same person often has to wear several hats, and pretending otherwise on paper will fail you faster at audit than admitting it honestly. Remember, ISO 27001 requires you to evaluate risk and right-size your response for your unique business.

The good news is that auditors and certification bodies know the problems smaller organisations face. What they’re looking for is evidence that you’ve recognised where ideal segregation isn’t possible, assessed the risk, and put compensating controls in place deliberately.

Here’s how I’d approach it.

Start with an honest analysis

Before you reach for controls, document the conflicts. A short segregation-of-duties analysis listing the roles in which one person handles activities that should ideally be separated, the resulting risk, and how you manage it is genuinely useful evidence. It might take an hour to produce, but it tells an auditor exactly what they need to know.

Use the tools you already pay for

Modern platforms have built-in segregation if you switch it on. For example, GitHub branch protection requiring pull request approval, finance systems with dual authorisation for payments over a certain threshold, identity providers with access request workflows, and ticketing systems that enforce that the approver and implementer are different people.

Sometimes it’s possible to make the platform become the second pair of hands. This is the cheapest segregation you’ll ever get, so start here.

Get logging and monitoring right

If the same person can do everything, the next best thing is making sure they cannot do it invisibly.

Privileged action logging forwards activity to locations the privileged user cannot tamper with, and automated alerts for high-risk actions such as permission changes, mass data exports, or out-of-hours admin activity.

The principle is simple: visibility is itself a control. Microsoft logs, for example, under 365, are tamper-proof and great for logging who did what and when. So, if you can log these activities (which, let’s be honest, you should do anyway), then you should use them to help record what’s going on – just make sure the risk is identified and addressed in your log or at least your SoA.

Build management review into the rhythm of the business

Where one person has to request, approve, and implement, a second pair of eyes after the fact still adds real value.

Perhaps a weekly access review, monthly change logs, and quarterly privileged-user activity reports, all reviewed and signed off by a director or senior manager. The key is that the review is documented.

Bring in external resources selectively

I don’t want to assume all small businesses don’t have the cash or willingness to look at external resources to bolster certain aspects, but some lend themselves nicely to this, such as Internal Auditing, Penetration testing, vulnerability scanning, and code review, all of which can be outsourced as needed rather than wholesale.

Yes, it costs, but compared to hiring a second full-time person to handle internal segregation, it’s likely a bargain.

Use peer review within the team

For technical teams where everyone has the competence to review each other’s work, peer review of code, changes, and risk assessments is one of the most effective controls available.

Two people looking at the same thing catch most of what one person misses, and it costs nothing beyond the time it takes.

A practical order of priority

If you’re starting from scratch, I’d suggest tackling these in order:

1. Get logging and monitoring right; this is the foundation everything else builds on.
2. Switch on segregation features in the tools you already use.
3. Establish documented management review for the conflicts you can’t resolve.
4. Bring in external assurance for your highest-risk areas annually.
5. Use peer review and rotation for the rest.

The one thing to avoid…

Don’t write a policy that claims full segregation across the board if you cannot deliver it. Auditors spot this immediately, and it’s worse than honestly documenting the reality.

“In our organisation, the IT Manager both approves and implements access changes; this is reviewed monthly by the Managing Director against the access request log” is a perfectly defensible position. Pretending the conflict doesn’t exist is not.

Segregation of duties for an SME is about being deliberate, not being perfect. Recognise the conflicts, manage them with compensating controls, and document your actions. That’s what passes certification, and more importantly, that’s what actually keeps your business safe.

Below is a template you can download to help you through your rationalisation process, should it help.

Role-Based Access Control and Automation

Role-based access control (RBAC) systems are one of the most effective ways to enforce segregation of duties at scale.

Rather than managing permissions person-by-person, you define what each role can do and assign people to roles. This turns segregation from a manual policing exercise into something the system enforces automatically.

That said, RBAC only works if it’s set up thoughtfully. So here are a few principles I’d recommend:

Avoid conflicting roles. Identify combinations of roles that should never be assigned to the same person, and configure your identity platform to prevent them. The classic example is one person holding both “raise purchase order” and “approve purchase order”; the same logic applies in IT, where “request access” and “approve access” should be mutually exclusive. Most enterprise identity platforms support this directly through segregation-of-duties policies or toxic-combination rules.

Use automated tools to spot conflicts. In any organisation beyond a handful of people, manually checking who has what becomes unworkable. Tooling that continuously monitors role assignments and flags conflicts, whether built into your identity provider, finance system, or a dedicated governance tool, will catch problems your annual access review will miss. This is particularly important when roles change, when someone moves between teams, or when temporary access is granted and never revoked.

Define roles clearly and keep them documented. Each role should have a written definition covering what it grants, why it exists, and who owns it. Without this, roles tend to accumulate permissions over time as exceptions get baked in, and you end up with a handful of “super roles” that quietly undermine the whole model. Clear documentation also makes onboarding, offboarding, and role changes far smoother, particularly when the original role designer has left the organisation.

Review roles, not just users. Most organisations review who has access to what. Fewer review whether the roles themselves still make sense. A periodic review of the role catalogue, ideally annually, catches drift that user-level reviews never will.

Here are tighter versions of both sections.

Common Issues I Find During Internal Audits

Segregation of duties is a control where the gap between what’s documented and what actually happens tends to be wider than people think. Here’s what I commonly find:

• Policies that overstate the reality. A policy stating “all access requests are approved by a separate authoriser” when the IT Manager approves their own requests. Auditors trace three recent requests, and the policy collapses. Document the actual control with compensating monitoring; don’t write fiction, as it’ll undermine you when a good auditor asks the right questions.
  
• No documented analysis of unavoidable conflicts. Most SMEs have conflicts they can’t fully resolve – it’s life! What we want to see during an audit is evidence that you’ve identified them, assessed the risk, and implemented compensating controls as best you can.
  
• Role assignments accumulate when people change jobs. Someone moves from development to operations, gets the new permissions, and keeps the old ones. Three years later, they have everything. Caused by relying on annual access reviews instead of triggered reviews when roles change, which is easy to fix with a good Joiners / Leavers / Movers process.
  
• Self-audit dressed up as audit. The IT Manager designs the access control process and conducts an internal audit of it. Unsurprisingly finds it works! Either rotate auditors across control areas, train someone outside IT, or use external resources for high-risk audits. Reviewing your own work is not an audit.

How does ISO 27001 Control 5.3 link to other clauses and controls

Segregation of duties pulls several other controls together. Understanding the relationships helps you avoid documenting the same thing in multiple places.

• Control 5.2: Information Security Roles and Responsibilities: 5.3 enforces what 5.2 allocates. You can’t segregate duties you haven’t first defined.
• Annex A 5.15 – Access control: The “request, approve, implement” three-way split is a 5.15 implementation of 5.3 principles.
• Annex A 5.18 – Access rights: The day-to-day provisioning side. 5.3 ensures these activities are separated between roles.
• Annex A 8.2 – Privileged access rights: Highest-risk area for segregation failures, because privileged users can usually do enough damage to matter.
• Annex A 8.32 – Change management: Change processes are an 8.32 control with 5.3 principles applied. Requester, approver, and implementer should be different people.
• Clause 9.2 – Internal audit: Clause 9.2.2 requires auditors to “ensure objectivity and the impartiality of the audit process”. 5.3 is how you demonstrate you meet that requirement, particularly in small organisations.
• Clause 7.2 – Competence: Segregated roles only work if the people in them are competent. A second approver who doesn’t understand what they’re approving is a rubber stamp, not a control.

FAQs

Conclusion

Segregation of duties under ISO 27001 control 5.3 is a critical element of any organisation’s security framework. By distributing responsibilities and ensuring oversight, organisations can mitigate risks, maintain operational integrity, and comply with regulatory standards.

Even when resources are limited, alternative measures, such as enhanced monitoring and supervision, can uphold the principles of SoD and safeguard the organisation against evolving threats.

If you’d like a structured way to document your own segregation-of-duties analysis, the SoD Analysis Template above will get you started, and the Iseo Blue ISO 27001 Toolkit includes the full set of supporting documents alongside it. Or if you’d rather talk through how to right-size your segregation controls for a small team, the free 30-minute consultation is genuinely free and genuinely 30 minutes.

Author Background

This article was written by Alan Parker, an ISO 27001 consultant and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less, often without a dedicated security team or a large budget.

With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally.

Qualifications: Certified ISO 27001 Lead Auditor (ANAB-accredited certification),
ITIL v3 Expert, ITIL v4 Bridge, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done.

Connect on LinkedIn or Bluesky, or explore his free ISO 27001 tools and templates at iseoblue.com. B.Sc (Hons) Information Systems, CISMP certified.

Alan Parker