ISO 27001 Segregation of Duties | Annex A 5.3 | The Lead Auditor’s Implementation and Audit Guide

ISO 27001 Annex A 5.3 Segregation of Duties is an organizational control requiring the separation of conflicting roles to reduce the risk of fraud and error. By implementing a “Four Eyes” principle, organizations achieve the primary business benefit of operational integrity and resilient internal security governance.

In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.3 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.

Key Takeaways: ISO 27001 Annex A 5.3 Segregation of Duties

• Segregating duties is a simple way to protect your business from mistakes and fraud. It means no single person has too much control over important tasks.
• This ISO 27001 rule helps make sure your company’s information is secure. It’s about splitting up jobs so that everything is double-checked.
• You can implement this by writing down who does what and making sure tasks are shared. Regularly checking on these duties keeps your security strong and helps during an audit.

ISO 27001 Annex A 5.3 requires organizations to separate conflicting duties and areas of responsibility to reduce the risk of fraud, error, and the bypassing of security controls. The core principle is that no single person should have enough authority to execute a sensitive process from start to finish without a second person’s involvement. This “Four Eyes” principle creates a system of checks and balances that protects both the organization and its employees.

Core requirements for compliance include:

• Identification of Conflict: You must analyze your business processes to find where a single person has too much control. Common conflict areas include change management, financial payments, and user access provisioning.
• Role-Based Access Control (RBAC): Implementing RBAC is the most practical way to enforce segregation. By defining roles with specific, non-overlapping permissions, you ensure that “the person who requests” is technically different from “the person who approves.”
• Audit Independence: The person responsible for a security control should never be the one to audit it. This is a common failure point for Information Security Managers who try to perform their own internal audits.
• Regular Access Reviews: You must conduct periodic reviews (ideally monthly) to ensure that roles haven’t drifted and that employees haven’t accumulated “conflicting” permissions over time.
• Small Business Adaptability: If your team is too small to separate duties physically, you must implement compensating controls like enhanced logging, management oversight, and mandatory risk acceptance in your risk register.

Audit Focus: Auditors will look for “The Self-Approval Trap”:

1. Change Control: “Show me a recent system change. Who requested it, and who approved it? If they are the same person, you have a non-conformity.”
2. Access Provisioning: “Can your IT Administrator grant themselves ‘Global Admin’ rights without any secondary notification or approval?”
3. Independence of Audit: “Who performed the internal audit of the HR process? If it was the HR Manager, that is a conflict of duty.”

Segregation of Duties Matrix (Audit Cheat Sheet):

Role A (The Maker)	Role B (The Checker)	Conflict?	ISO 27001 Rule	ISO 27001:2022 Control
Request Purchase	Approve Purchase	❌ YES	One person cannot do both.	Annex A 5.3
Write Code	Deploy to Prod	❌ YES	Developers should not have Prod access.	Annex A 5.3 / 8.32
Create User	Audit Logs	❌ YES	Admins cannot audit their own actions.	Annex A 5.3 / 8.15
Request Access	Grant Access	❌ YES	Self-approval is strictly forbidden.	Annex A 5.3 / 5.18

What is Segregation of Duty?

Segregation of duty is the act of dividing up critical tasks and responsibilities so that no one person has complete control over a process.

What is ISO 27001 Annex A 5.3?

ISO 27001 Annex A 5.3 Segregation of Duties is an ISO 27001 control that requires an organisation to separate and segregate conflicting information security roles and responsibilities.

ISO 27001 Annex A 5.3 requires you to separate key duties. By splitting up tasks, you prevent any single person from having total control over a process. This creates checks and balances for better security.

ISO 27001 Annex A 5.3 Purpose

The purpose of Annex A 5.3 Segregation of Duties is to reduce the risk of fraud, error and bypassing of information security controls.

ISO 27001 Annex A 5.3 Definition

ISO 27001 defines ISO 27001 Segregation of Duty as:

Conflicting duties and conflicting areas of responsibility should be segregated.

ISO 27001:2022 Annex A 5.3 Segregation of Duties

Watch the ISO 27001 Annex A 5.3 Tutorial

In the video ISO 27001 Annex A 5.3 Segregation of Duty Explained show you how to implement it and how to pass the audit.

ISO 27001 Annex A 5.3 Podcast

In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.3 Segregation of Duties. The podcast explores what it is, why it is important and the path to compliance.

A 5.3 Implementation Guidance

You are going to have to

• define your roles and responsibilities as covered in ISO 27001 Annex A 5.2 Information Security Roles And Responsibilities
• identify where there are conflicts and remove them
• implement role based access controls
• regularly review the access

Implement Role Based Access Control

Role based access is one of the most common and practical approaches to implementing segregation of duty. By taking the time to identify the roles that you require and removing conflicts in those roles and then assigning individuals to roles rather that allocating access on a case by case basis will significantly help you to remove conflicts in a consistent way.

Divide Responsibilities

Understanding and documenting your processes and systems will allow you to identify the key roles and responsibilities which can then be allocated to more than one individual and ensure no one person has complete control for a process or system. This is part of role based access control.

Prevent Collusion

The way that teams are structured and where they are located and how they interact can have an impact on introducing the opportunity for collusion. Collusion is the working together to commit fraud or circumvent controls.

Monitor and Review

It may be the case that segregation of duty does not work as intended or requires continual improvement. By implementing logging, monitoring and review on a regular basis allows for the identification and management of when it goes wrong and the ongoing and continual improvements to ensure that it remains effective.

How to Implement Annex A 5.3

Approaches to Segregation of Duty

There are many standard approaches with the most common being:

• Sequential separation: the two signature principle
• Individual separation: the four eyes principle
• Spatial separation: the principle of separate actions in separate locations
• Factorial separation: process completion requires several factors to be true

Segregation of duty in a small organisation

When you work at a new tech company or an early-stage business, your main goals are speed, efficiency, and making a profit. Because of this, you often don’t think about things like segregation of duty.

For example, a small development team might have access to the development, testing, and production environments, and also act as the tech support. This situation presents a clear conflict of interest. A way to fix this is by having different user accounts for different roles. The other way is to accept the risk and manage it via risk management.

How to identify conflict of interest

You can learn how to find conflicts of interest for ISO 27001 by starting with the idea of segregation of duties. This means you should make sure to separate tasks so that no one person has too much control. You need to identify where these conflicts might exist in your own environment.

You can begin by reviewing the roles and responsibilities you have already defined. You should look for potential conflicts, which may be inherent in the standard definitions of certain roles. Once you have identified what those conflicts could be, you can then figure out how to address them.

How to remove conflict of interest

When you want to remove conflicts or separate duties in a company, it’s simple to do if you have many workers. However, it’s much harder in a small business with only a few people.

If you have a small business, you can choose not to follow this rule. The rule might not be a big risk for you, so you don’t have to put it into place. If you decide to do this, you should write it down as a risk and then manage it. This shows you have accepted the risk and are handling it.

How to remove conflict of interest in internal audit

You should know that if you are assuming everything is okay with how duties are separated, there’s a big area where problems can pop up: internal audits. When companies use their own staff to do these audits, it often leads to a conflict of duty.

Imagine if you pick someone to audit an area, but they are also responsible for running that very area. That creates a conflict. This is something you need to fix to make sure your audits are fair and accurate.

Why the information security manager should not do internal audits

You should not do your own internal audits for ISO 27001 if you are also the information security manager. This is because you need to separate your duties. Consultants often have a coworker perform this task for them. You should keep this in mind as it’s something auditors often notice.

Segregation of duties examples

The following are some common real world examples of Segregation of Duty:

Change Control: the change control process usually has several key steps that include the request for change, the approval of the change and the implementation of the change. There would clearly be a conflict of interest if the person requesting was the same person that approved and then actioned the change. In fact it would make the purpose of having a change control process redundant.

Human Resources: there are many processes in HR that require fairness and objectivity. Take the key processes of hiring, performance management and financial rewards such as pay rise reviews and bonus allocation. If the same individual is responsible for all of these key processes then there is a conflict of interest and a lack of impartiality.

Information Technology (IT): as most processes and business operations rely on the use of information technology this presents the biggest risk to information security and the confidentiality, integrity and availability of data. Most fraud occurs via a compromise of IT. Having one individual with total control can lead to changes being made that cannot be caught with tracks being covered via the manipulation or removal of monitoring and logging.

Remove conflict in duties

You are looking to work out where there may be a conflict in duties and to remove that conflict so that one individual cannot exploit it for their own gain.

Let us consider an example.

If a person could request a pay rise, then approve that pay rise and make the payment – would that be a conflict of interest?

The answer if you are struggling, is yes.

A person should not be able to request something, authorise it and then execute it.

Think about it.

In basic terms what would be point in the process?

The person may as well just go to the last step and pay themselves what they want.

Role Based Access

Role based access is a great way to implement segregation of duties. You spend a little time up front to work out what the various roles are that people have on systems. You define the role, paying particular attention to remove any conflicts. It is then just a matter of allocating people to roles. It isn’t just people that can be included in role based access though. You can also use it for service and technical accounts. By considering a role based access approach there is consistency in the way access is implemented rather than doing it per individual and it makes both the management and the review of access rights a lot more straightforward. The management of a change in access rights when a person moves job or role or leaves becomes a breeze.

Access reviews

One of the checks and balances and good governance is to implement access reviews. Access reviews should be conducted regularly. You will define what this means but best practice is every month. The access review will be conducted by the asset owner, be that a system owner or a data owner. They will review the accounts that have access, the level of access and if that is still required and appropriate. Where it isn’t they will address it through continual improvement. In this process you will be looking to ensure that segregation of duties is still in place and effective.

Segregation of Duties Matrix Example

Role A (Maker)	Role B (Checker)	Conflict?	Allowed?
Request Purchase	Approve Purchase	❌ YES	NO (Same person cannot do both).
Write Code	Deploy to Production	❌ YES	NO (Devs shouldn’t touch Prod).
Create User	Audit User Logs	❌ YES	NO (Admins shouldn’t audit themselves).
Request Access	Grant Access	❌ YES	NO (Self-approval forbidden).

How to Audit ISO 27001 Annex A 5.3

How to pass the ISO 27001 Annex A 5.3 audit

To comply with ISO 27001 Annex A 5.3 Segregation of Duties you are going to implement the ‘how’ to the ‘what’ the control is expecting. You are going to

• Write your roles and responsibilities to satisfy ISO 20001 Annex A 5.2
• List out the systems that people use and have a systems inventory
• For each system define the roles people have within those systems
• For the roles you define you are going to document what levels of access those roles have
• Then you are going to allocate those roles to people
• The allocation, change and removal of roles is going to be documented in your access control process
• Plan to review access to your systems at least monthly or if significant change occurs
• Keep records of your review and audit trails of the access control process

Comparison of manual vs. automated technical enforcement for Segregation of Duties.

Enforcement Layer	Manual (Trust-Based)	Automated (Policy-as-Code)	Audit Reliability
Access Control	Manager checks a spreadsheet monthly.	Entra ID PIM / JIT: Roles are inactive by default and require MFA request.	10/10: Logs are immutable and generated in real-time.
Code Quality	Team lead “promises” to check all code.	Branch Protection Rules: Git blocks “Merge” until two independent reviews are logged.	10/10: Direct forensic link between code and approver.
System Admin	Admin has permanent “Root” access.	Privileged Access Management (PAM): Credentials are “checked out” for single tasks.	9/10: Prevents “Privilege Creep” and permanent toxic access.
Data Governance	Staff told not to download databases.	DLP Triggers: Automated block if an Admin attempts to export PII to a local drive.	10/10: Proves “Policy in Practice” rather than just “Policy on Paper.”

What an auditor looks for

The audit is going to check a number of areas. Lets go through them

1. They will check the processes that Annex A 5.3 has defined as needing segregation

The standard has already pre defined processes that it thinks you should have segregation in so either make sure you do or have a compelling reason why you do not that you can justify to the auditor.

• a) initiating, approving and executing a change;
• b) requesting, approving and implementing access rights;
• c) designing, implementing and reviewing code;
• d) developing software and administering production systems;
• e) using and administering applications;
• f) using applications and administering databases;
• g) designing, auditing and assuring information security controls.

2. They will check conflicting roles

This is obvious but they are going to look for conflicts and they are coming at this with fresh eyes.

3. Documentation

They are going to look at audit trails and all your documentation. They are looking that the roles and responsibilities are defined, that the role based access is defined, that you have a process for access control and they are going to look for evidence of operation ( that you have done it ). They want to see documentation of regular reviews.

Auditor evidence requirements for mandatory segregated ISO 27001 security roles.

Segregated Role Pair	Primary Audit Evidence (Artifacts)	Verification Method
Developer vs. Deployer	CI/CD Pipeline Peer Review Logs	Verification that the “Approved By” ID is different from the “Committed By” ID in GitHub/GitLab.
SysAdmin vs. Log Auditor	SIEM Access Logs / WORM Storage	Evidence that logs are shipped to a central repository where the SysAdmin has “Read-Only” rights.
Access Requestor vs. Authoriser	ITSM Ticketing History (Jira/ServiceNow)	Verification of timestamps showing an independent manager approved the privilege escalation request.
Payment Creator vs. Approver	Bank Portal Audit Trail / Mandate	Sighting of dual-factor authorisation logs for a sample of high-value external transfers.
Risk Owner vs. Internal Auditor	Management Review Minutes / Audit Report	Verification that the Internal Auditor does not report to the individual owning the risks being audited.

Top 3 ISO 27001 Annex A 5.3 Mistakes and How to Fix Them

Based on experience, the top 3 mistakes people make for ISO 27001 annex a 5.3 are

1. You don’t have enough staff to segregate duties: You get stressed because you do not have enough staff to implementation segregation of duty but you do nothing to compensate. It is ok to have conflicts if you cannot avoid it but you should have additional controls in place such as logging and monitoring of activity that IS handled and managed by someone else.
2. One or more members of your team haven’t done what they should have done: Prior to the audit check that all members of the team have done what they should have. Have access reviews taken place? Do people actually have the level of access that is documented in your role based access document or has someone gone and changed the actual access on the systems.
3. Your document and version control is wrong: Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.

Applicability of ISO 27001 Annex A 5.3 across different business models.

Business Type	Applicability & Interpretation	Examples of Control
Small Businesses	Compensating Controls. You likely don’t have enough staff to separate every duty. Compliance allows for “Management Oversight” instead. If one person does everything, the owner must check the logs.	• The “Owner Review”: A monthly check where the Director reviews the bank transfer logs or payroll adjustments, acting as the “Second Pair of Eyes.” • External Bookkeeper: Using an external accountant to reconcile the books, separating the “Doer” (internal staff) from the “Checker” (external).
Tech Startups	The “Dev vs. Ops” Divide. The biggest risk is developers pushing malicious code to production. Segregation means the person who writes the code cannot be the only one who approves its deployment.	• Pull Request (PR) Rules: Configuring GitHub so that the main branch is protected and requires at least one peer review before merging. • CI/CD Pipelines: Using automated pipelines to deploy code, removing the need for developers to have direct SSH access to production servers.
AI Companies	Data vs. Model Integrity. To prevent “Data Poisoning” or bias, the person selecting the training data should ideally be different from the person evaluating the model’s safety.	• Red Teaming Separation: Ensuring the “Red Team” (who attack the model) are organizationally distinct from the “Model Builders,” preventing conflicts of interest. • Access Segmentation: Granting “Read-Only” access to raw datasets for most researchers, reserving “Write/Delete” access for data engineers.

Fast Track ISO 27001 Annex A 5.3 Compliance with the ISO 27001 Toolkit

For ISO 27001 Annex A 5.3 (Segregation of duties), the requirement is to divide critical tasks and responsibilities among different people to reduce the risk of fraud, error, and bypassing security controls. This is a fundamental organisational control that creates essential “checks and balances.”

Compliance Factor	SaaS Compliance Platforms	High Table ISO 27001 Toolkit	Audit Evidence Example
Policy Ownership	Rents access to your SoD rules; if you cancel the subscription, your documented “Maker-Checker” standards and history vanish.	Permanent Assets: Fully editable Word/Excel Access Control Policies and SoD Matrix templates you own forever.	A localized “Segregation of Duties Matrix” stored on your secure drive defining conflicting roles (e.g., Developer vs. Deployer).
Operational Utility	Attempts to “automate” conflicts via dashboards that cannot determine the physical “four-eyes” checks needed for your team.	Governance-First: Provides a “Duties Procedures” framework to formalize your existing workflows into an auditor-ready system.	A “Role Description” proving that the individual who creates a supplier in the system cannot also approve payments to them.
Cost Efficiency	Charges a “Headcount Tax” or “Role Fee” based on the number of users tracked, creating perpetual overhead as you grow.	One-Off Fee: A single payment covers your SoD governance for 10 roles or 1,000, with zero recurring costs.	Allocating budget to hiring additional security personnel rather than monthly “governance dashboard” subscription fees.
Structural Freedom	Mandates rigid reporting formats that often fail to align with lean startup environments or specialized department structures.	100% Agnostic: Procedures adapt to any operating style—from “Maker-Checker” digital workflows to physical “four-eyes” principles.	The ability to evolve your organizational chart and departmental responsibilities without reconfiguring a rigid SaaS module.

Summary: For Annex A 5.3, the auditor wants to see that you have identified conflicting roles and documented how they are separated. The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.

Mandatory SoD Metadata Checklist

Mandatory document metadata requirements for ISO 27001 Annex A 5.3 compliance.

Metadata Field	Required Value / Format	Technical Purpose
Conflict ID / Code	Unique Alphanumeric (e.g., SOD-FIN-01)	Ensures unambiguous referencing in the Risk Register and Access Control Lists (ACLs).
Role Pairing	Role A vs. Role B (e.g., Dev vs. Prod)	Defines the specific “Toxic Combination” that the technical control must prevent.
Enforcement Type	Technical, Administrative, or Compensatory	Identifies if the control is a hard block (technical) or a review-based check (administrative).
Approver ID	Role-based (e.g., CISO, Finance Director)	Assigns accountability for the authorisation of the segregated workflow.
Last Review Date	YYYY-MM-DD (Max 6 months from last)	Proves the organisation is adhering to the “planned intervals” mandate for access recertification.

Governing AI and Agentic Permissions (ISO 42001 Alignment)

Mandatory AI governance roles and SoD requirements for 2026 compliance.

AI Governance Area	Segregation Requirement	Compliance Logic (ISO 42001)
Agentic Permissions	The “AI Architect” cannot also be the “AI Permissions Grantor.”	Ensures autonomous bots do not inherit excessive administrative rights without human oversight.
Model Validation	Individuals who train the LLM must be independent of those who “Red Team” or validate output safety.	Prevents “confirmation bias” and ensures safety-critical decisions remain objective and segregated.
Human-in-the-Loop (HITL)	AI-driven security remediation (e.g., automated blocking) must require a human “Executor” for P1 changes.	Satisfies the EU AI Act mandate for human oversight in high-risk automated decision-making.
Data Egress Review	The person configuring AI data ingestion must be separate from the person auditing the “Data Egress” logs.	Prevents the intentional or accidental leaking of PII/Sensitive data into public model training sets.

SoD-as-Code: Technical Enforcement Triggers

Technical triggers for automated Segregation of Duties enforcement in Cloud/DevOps environments.

SoD Mandate	Technical Trigger (The “Enforcer”)	Auditor Verification Artifact
Production Isolation	Terraform/OpenTofu: Infrastructure code linter that blocks merges if a Developer ID attempts to provision Prod resources.	Git history showing “Build-Fail” logs for unauthorised resource modifications.
Just-in-Time Access	Entra ID PIM: High-privilege roles are set to “Eligible” but remain inactive until requested and approved.	Azure Activity Logs showing a timestamped approval from a different User Principal Name (UPN).
Secrets Management	HashiCorp Vault: Dynamic credentials that require “Quorum” (multiple keys) to unseal sensitive production secrets.	Audit logs proving that no single person possesses the full key fragment set.
CI/CD Guardrails	GitHub/GitLab Protected Branches: Hard block on “Push to Main” without a signed peer-review from a designated “Checker.”	Forensic link between the “Committer” and the “Reviewer” in the pipeline metadata.

The Quantified Impact of SoD Failure

• HR & Employment Tribunals: 85% of HR disciplinary actions for internal fraud or data misuse fail in UK tribunals if the organisation cannot produce a signed “Segregation of Duties” acknowledgement record for the specific role.
• Cyber Insurance Voidance: 60% of ransomware claims involve “Privilege Creep.” Carriers now routinely exclude coverage if the “Root” account used in the breach was assigned to an individual with conflicting duties (e.g., a Developer with permanent Prod access).
• Regulatory Fines (GDPR/NIS2): Under the “Accountability Principle,” failure to implement SoD is viewed as “Gross Negligence” in the event of an insider threat. Fines are typically 35% higher for organisations with undefined role boundaries.
• Operational Loss: On average, internal fraud committed by a single individual with “Maker-Checker” control lasts 18 months longer and costs $250,000 more than fraud committed under a segregated governance model.

Forensic & Resilience Layers

Legal Defensibility & Forensic Readiness

Forensic requirements for legally defensible SoD evidence and non-repudiation.

Forensic Requirement	Technical Implementation	Tribunal / Audit Value
Non-Repudiation	Cryptographically sealed digital signatures for all Access Recertifications.	High: Prevents managers from denying they approved “Toxic Access” pairings.
Version Integrity	SHA-256 hashing of monthly SoD violation reports stored in WORM storage.	High: Proves logs were not altered post-incident to hide control failures.
Timestamp Accuracy	Network Time Protocol (NTP) synchronisation across all IAM and SIEM logs.	Critical: Establishes a verifiable timeline for “Maker-Checker” actions.
Chain of Custody	Automated log shipping to a segregated security account with restricted access.	High: Ensures administrators cannot delete logs of their own unauthorised actions.

Crisis Governance: SoD Under Stress (Break-Glass)

• The “Red” Folder: Maintain a secure, physical or immutable offline repository containing emergency “Emergency Admin” credentials.
• Pre-Authorised Bypasses: Define specific SoD rules that can be temporarily suspended during a “P1 Crisis” (e.g., allowing a single engineer to both patch and deploy), provided a “Scribe” role records every action manually.
• Post-Incident Reconciliation: Mandate a technical “Clean Up” audit within 24 hours of the crisis resolving to revoke all emergency privileges and verify the integrity of changes made.
• Hardware Tokens: Assign emergency access keys to different executive roles (e.g., CEO holds the safe key, CISO holds the vault password) to maintain physical segregation even when digital systems fail.

SoD Drift Mitigation: The Silent Compliance Killer

Automated triggers to mitigate privilege creep and SoD drift.

Drift Type	Automated Mitigation (The “Dormancy Trigger”)	Compliance Outcome
Mover Risk	HRIS-to-IAM Sync: Automates the “Clean Slate” policy upon department change.	Prevents individuals from keeping “Finance” rights while working in “IT”.
Admin Dormancy	Automated stripping of administrative roles if unused for 30 consecutive days.	Reduces the attack surface and ensures SoD applies only to active duties.
Shadow IT Drift	CASB alerts for any user attempting to provision unvetted SaaS applications.	Maintains the integrity of the “Procurement Gatekeeper” segregation role.
JIT Expiry	Just-in-Time (JIT) access that auto-revokes after a 4-hour technical window.	Ensures that “Checker” roles do not linger as permanent “Maker” permissions.

Performance & Maturity Metrics

ISO 27001 SoD Governance KPIs

Key Performance Indicators (KPIs) for monitoring ISO 27001 Annex A 5.3 effectiveness.

Metric Name	Target Threshold	Audit Utility
Conflict Remediation Latency	< 24 Hours	Measures the speed at which “Toxic Access” is revoked following a staff member’s role change or departure.
Self-Approval Attempt Rate	0% (Hard Block)	Tracks the number of times users attempt to approve their own changes or access requests in the ITSM tool.
Access Recertification Completion	100% On-Time	Demonstrates that Asset Owners are actively reviewing and validating segregated roles at planned intervals.
Exception Volume Trend	< 5% of Total Roles	Indicates whether the organisation is relying too heavily on manual workarounds rather than technical segregation.

The Governance Maturity Evolution Path

Maturity levels for Segregation of Duties management and enforcement.

Maturity Level	Characteristic Behaviour	Auditor Perception
Level 1: Reactive	Roles are ad-hoc; segregation is only addressed when an error or fraud occurs.	High Risk / Major Non-Conformity likely.
Level 2: Defined	SoD Matrix exists in a document, but enforcement is manual and review dates are often missed.	Medium Risk / Minor Non-Conformity likely.
Level 3: Managed	RBAC is implemented in primary systems; Access Reviews are scheduled and evidenced.	Low Risk / Certification Ready.
Level 4: Optimised	SoD is “Code-Enforced” via PIM/CI-CD; Real-time dashboards monitor self-approval attempts.	Platinum Standard / Best-in-Class.

The SoD Audit Readiness Scorecard

Scoring model for ISO 27001 Annex A 5.3 Audit Readiness.

Assessment Area	Weighting	Success Criteria
Org Chart & Matrix Accuracy	25%	The current organisational chart matches the names and roles listed in the SoD Matrix exactly.
Executive Evidence	25%	Signed Management Review minutes from the last 12 months show Board approval of the SoD Policy.
Artifact Samples	25%	forensic logs from GitHub/Jira prove that “Maker” and “Checker” IDs are always different.
AI & Agentic Governance	25%	A specific SoD sub-policy exists defining human oversight for high-risk AI decision-making.

ISO 27001 Annex A 5.3 FAQ

ISO 27001 Annex A 5.3 Mapped to other Standards and Laws

Exhaustive regulatory and standard mapping for ISO 27001 Annex A 5.3 Segregation of Duties.

Standard / Law	Mapping Reference	Compliance Logic (The “How”)
GDPR / UK Data Protection Act	Articles 24, 25 & 32	Mandates “technical and organisational measures.” SoD is the primary organisational control to prevent unauthorised access to PII by ensuring no single admin can both access and delete audit trails of their own data processing.
UK Data (Use and Access) Act 2025	Governance Provisions	Aligns with reduced administrative burdens by encouraging risk-based controls. SoD satisfies the “Appropriate Measure” threshold by providing high-integrity data handling without requiring excessive manual paperwork.
Cyber Security and Resilience Bill (UK)	MSP Governance Rules	Requires Managed Service Providers (MSPs) to demonstrate robust internal governance. SoD prevents a single rogue engineer at a provider from compromising multiple client environments simultaneously.
NIST CSF 2.0 / SP 800-53	PR.AC-01 / AC-5	NIST explicitly mandates “Separation of Duties.” Annex A 5.3 is the direct implementation of this, requiring that “conflicting duties and areas of responsibility” are assigned to different individuals.
NIS2 Directive (EU)	Article 21 (Human Resources)	Identifies human error and insider threats as major risks. SoD is the mandated control for “essential entities” to reduce the risk of a single person causing a systemic infrastructure failure.
DORA (Financial Services)	Articles 6 & 9	Requires strict segregation between those who develop ICT systems and those who administer them. SoD prevents “Toxic Access” in banking systems, such as an individual creating and then approving a payment.
SOC 2 (Trust Services Criteria)	CC6.1 & CC5.2	Under the “Logical and Physical Access” criteria, SOC 2 auditors require proof that segregation is enforced to prevent fraud and ensure that the “maker-checker” principle is applied to system changes.
EU AI Act	Article 14 (Human Oversight)	Mandates that high-risk AI systems have human oversight. SoD ensures that the individuals monitoring the AI’s output are independent of those who trained or deployed the model, preventing bias and data poisoning.
ISO/IEC 42001 (AI Management)	Control A.5.3	Specifically requires that AI-related roles and responsibilities are segregated to ensure that safety-critical decisions are not consolidated within a single automated or human function.
HIPAA (US Healthcare)	§ 164.308(a)(4)	The “Information Access Management” standard requires organisations to implement procedures for authorising access. SoD prevents clinical staff from also having the administrative rights to modify medical records.
California Data Laws (CCPA/CPRA)	Accountability Principle	Requires “reasonable security.” SoD provides the “Governance Proof” that an organisation has taken steps to prevent internal data theft by distributing authority across multiple roles.
CIRCIA (USA)	Reporting Governance	While focused on 72-hour reporting, CIRCIA implies a need for valid data. SoD ensures the “Scribe” or “Reporting Officer” is independent of the IT team managing the incident, ensuring the report’s accuracy.
EU Product Liability Directive (PLD)	Defect Standard	Treats cybersecurity flaws as product defects. Failure to implement SoD in a software product (e.g., allowing a developer to push code without review) creates strict liability for the provider if a breach occurs.
ECCF (European Framework)	High Assurance Level	Mandates a documented and segregated chain of custody for certified products. SoD ensures that the security testing of a product is performed by a party separate from the development team.
PCI DSS v4.0	Requirement 7.1.2	Specifically mandates the “restricting of access” to least privilege and the “separation of duties” to prevent individuals from having enough access to steal cardholder data.

Further Reading

Essential ISO 27001 Annex A 5.3 Resources and Guidance

Resource Title	Compliance Context
How to Implement ISO 27001:2022 Annex A 5.3: Segregation of Duties	A step-by-step technical implementation guide for establishing conflicting role separation.
The complete guide to ISO/IEC 27002:2022	Detailed breakdown of the 2022 control updates and best practice implementation guidance.
ISO 27001 Segregation of Duty Beginner’s Guide	Plain-English introduction to the core concepts of duties segregation for non-technical stakeholders.
ISO 27001 Annex A 8.22 Segregation of Networks	Technical control guidance for separating network environments to prevent lateral movement.

ISO 27001 Annex A 5.3 Attribute Table

Control type	Information security properties	Cybersecurity concepts	Operational capabilities	Security domains
Preventive	Confidentiality	Protect	Governance	Governance and Ecosystem
	Integrity		Identity and access management
	Availability

About the author