Skip to content

Navigating ISO 27001 Annex A: Control A.5.3

Blog Series

Welcome to our ISO 27001 Annex A Blog series:

Building on our previous exploration of ISO 27001 Annex A Control A.5.2, we now delve into Control A.5.3, which focuses on the essential practice of Segregation of Duties (SoD). This control is crucial for preventing conflicts and ensuring that no single individual has unchecked control over critical processes, thereby reducing the risk of misuse, fraud, or error. Discover how to implement these requirements effectively to enhance the integrity and resilience of your Information Security Management System (ISMS).

What are the requirements from the standard

Control A.5.3Conflicting duties and conflicting areas of responsibility should be segregated and, where this cannot be achieved, other appropriate controls should be applied.

Purpose: To reduce the risk of misuse of systems, fraud, or error that could occur if one person can execute conflicting tasks.

ISO/IEC 27002:2022 explains that organisations should separate roles, responsibilities and system privileges to prevent any one person from having unchecked control over a process, asset or system.

Where segregation isn’t feasible (for example, in smaller teams), compensating controls, such as management oversight, peer review, or automated logging and alerts, must be in place.

Segregation of duties (SoD) applies across business, operational and IT processes, including financial transactions, system administration and change management.

Why this control matters

Segregation of duties is a classic internal-control principle, but it’s also one of the easiest to overlook in smaller or fast-moving organisations.

When a single person can both initiate and approve an action, or develop and deploy a change, the risk of intentional fraud or accidental error increases dramatically.

The absence of SoD doesn’t just expose systems to insider threats; it also weakens auditability and erodes stakeholder confidence.

From my experience auditing ISMSs in different industries, I often see this control taken for granted, especially in small IT teams. A single admin account with unrestricted rights can undo months of hard security work in seconds.

How to implement

Map your critical processes (user provisioning, change management, financial approvals) and note where one person performs conflicting functions.

  • No one should both request and approve access.
  • Developers shouldn’t deploy code directly to production.
  • System administrators shouldn’t audit their own activity.

  • Use role-based access control (RBAC) to limit permissions.
  • Implement multi-level approval workflows.
  • Require secondary reviews for sensitive transactions.

  • Independent review or sign-off by management.
  • Logging and periodic monitoring of activities.
  • Dual authorisation for critical changes.

  • Update your RACI matrix and procedures to reflect SoD measures.
  • Maintain evidence of reviews and approvals.

  • Include SoD checks in internal audits and access-rights reviews.
  • Adjust controls as roles, systems or organisational structures change.

How auditors assess this

Auditors will look for evidence that duties are segregated or compensated in line with risk.
According to ISO/IEC 27006-1:2024 Annex E, assessment typically includes:

  • Review of access rights, system roles, and process flows.
  • Confirmation that conflicts of interest have been identified and mitigated.
  • Evidence of dual controls or independent reviews where segregation isn’t possible.
  • Interviews with key staff to verify understanding and practice.

Personally, I like to pick one or two sensitive processes. Say, change management or privileged-access reviews and trace them end to end. If the same name appears on every step, there’s a gap to talk about.

Practical tips

  • Use automation: tools like IAM systems can flag SoD conflicts automatically.
  • Build SoD into process design rather than adding it later.
  • Document exceptions clearly: If segregation isn’t feasible, justify the risk and show compensating measures.
  • Leverage monitoring: Centralised logging or SIEM alerts provide oversight when physical separation of duties isn’t possible.
  • Include SoD in onboarding: Make sure new staff understand approval flows and access boundaries.

Common pitfalls

“Too small to segregate” mindset - relying on trust instead of controls.
Shared admin accounts - impossible to prove accountability.
No review of access conflicts - roles evolve, but rights stay the same.
Paper procedures, no practice - segregation described in policy but not enforced operationally.
Ignoring compensating controls - assuming “we can’t separate” is an acceptable excuse.

I’ve seen cases where SoD existed only in policy diagrams, but everyone still logged in as ‘Admin.’ It’s a quick way to fail both security and audit credibility.

Final thoughts

Segregation of duties isn’t about bureaucracy, it’s about trust with verification.
By dividing responsibilities and ensuring oversight, you reduce insider risks and strengthen confidence in your ISMS.

As auditors, we don’t expect perfection, but we do expect awareness. If you can clearly explain where conflicts exist and how you control them, you’re already demonstrating mature governance.

The author

Dimitar Yotov

Scheme Manager ISMS

ISO 27001


Discover our dedicated page

Contact Us


Contact us with your enquiry today!

We are looking forward to your enquiry!

TÜV UK Ltd
AMP House
Suites 27 - 29, Fifth Floor, Dingwall Road
Croydon, CR0 2LX

Tel.: +44 20 8680-7711
Enquiries.UK@tuv-nord.com