ISO 27001:2022 Annex A 5.3 Segregation of Duties Explained

In this guide you will learn how to implement ISO 27001 Annex A 5.3 Segregation of Duties and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.

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.

Key Takeaways

• No single person has too much control over important tasks.
• 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.

Purpose & Definition

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

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

FREE ISO 27001 Annex A 5.3 Training Video

In this free training video you will learn How to implement ISO 27001 Segregation of Duty (Annex a 5.3) and Pass Your Audit

ISO 27001 Annex A 5.3 Requirements and 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

What is Segregation of Duty?

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.

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

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.

Roles and 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.

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.

Conflict of duties example

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.

Fast track your ISO 27001 build with the ISO 27001 Templates Pack.

How to implement ISO 27001 Annex A 5.3

The effective implementation of Segregation of Duties (SoD) is a foundational pillar for preventing fraud, reducing human error, and mitigating insider threats. This process involves identifying high-risk workflows and ensuring that no single individual has the authority to initiate, approve, and execute a critical transaction or system change. By following these steps, you will establish a verifiable framework for operational integrity that meets the expectations of ISO 27001 lead auditors.

Implementing ISO 27001 Annex A 5.3 is not merely about splitting tasks: it is about engineering a technical governance structure that prevents any single individual from holding enough authority to compromise your business. As an ISO 27001 Lead Auditor, I require organisations to prove that technical and operational duties are segregated to eliminate the risk of fraud, error, and sabotage. Follow these 10 steps to establish a robust segregation of duties framework that will pass any audit.

1. Formalise the Segregation of Duties Policy and Matrix

Establish a documented policy that defines the organisational approach to role separation. This results in a governance layer that identifies which specific duties are deemed “conflicting” and must never be held by the same individual.

• Create a Segregation of Duties (SoD) matrix mapping roles against sensitive business and technical processes.
• Document the “Rules of Engagement” (ROE) for emergency access (break-glass) scenarios where SoD may be temporarily bypassed.
• Identify critical workflows such as financial payments, software deployment to production, and administrative access management.

2. Provision Role-Based Access Control (RBAC) and IAM Roles

Execute the configuration of your Identity and Access Management (IAM) systems to enforce defined role boundaries. This ensures that technical permissions are automatically aligned with the SoD matrix, preventing “privilege creep” as staff change positions.

• Define distinct IAM roles for “Requestors,” “Approvers,” and “Executors” within your cloud and on-premise infrastructure.
• Enforce Multi-Factor Authentication (MFA) for all accounts with the authority to approve high-risk changes.
• Utilise the principle of least privilege to ensure users only possess the technical permissions required for their specific segmented task.

3. Formalise Technical Approval Workflows

Provision automated workflows within your ticketing or CI/CD systems that mandate secondary sign-offs for critical actions. This ensures that the segregation of duties is technically enforced at the point of execution.

• Configure GitHub or GitLab protected branches to require at least one independent peer review before code is merged.
• Implement “Four-Eyes” approval protocols within banking and procurement software for all transactions above a defined financial threshold.
• Set up automated triggers in your ITSM tool that block administrators from approving their own change requests.

4. Provision Compensating Controls for Small Teams

Execute alternative oversight mechanisms when the size of the organisation makes full role separation physically impossible. This provides the “equivalent security” required by auditors to mitigate the risk of concentrated authority.

• Increase the frequency of independent audit log reviews for individuals holding high-privilege or conflicting roles.
• Formalise a schedule for a virtual CISO or external third party to perform quarterly spot checks on sensitive transactions.
• Deploy automated alerting for anomalous activities performed by “Super Users” to ensure rapid detection of policy violations.

5. Execute Periodic Access Reviews and Recertification

Perform a structured audit of user permissions at least twice per year to verify that role separation remains effective. This results in the identification and remediation of unauthorised access before it can be exploited.

• Generate “Access Certification” reports to be reviewed and signed off by departmental heads and the CISO.
• Revoke any legacy permissions identified during the review that create a conflict of interest or an SoD violation.
• Maintain a log of all access reviews and remediation actions as mandatory evidence for your next audit.

How to audit ISO 27001 Annex A 5.3

To conduct a forensic internal audit of ISO 27001 Annex A 5.3: you must move beyond a simple checkbox exercise. As an ISO 27001 Lead Auditor: I require evidence that your segregation of duties is technically enforced and actively monitored to prevent unauthorised modifications or fraud. Follow these 10 steps to rigorously test whether your organisational roles: responsibilities: and authorities are established: communicated: and effective in practice.

1. Review Segregation of Duties (SoD) documentation

Examine the documented information security roles and the specific SoD matrix. I am looking for clarity: completeness: and consistency across your governance framework.

• Verify that the matrix identifies all high-risk toxic combinations of access across finance: IT: and operations.
• Check that the SoD policy has been version-controlled and reviewed within the last 12 months.
• Ensure the documentation aligns with the current organisational chart and technical role definitions.

2. Assess Role and Responsibility assignments

Determine if roles are assigned to individuals based on actual competence rather than just job title. I will assess workload distribution and check for conflicting combination of access.

• Evaluate whether key personnel have the bandwidth to maintain segregation duties without bypassing controls.
• Check for conflicts of interest: such as a developer having release authority to production environments.
• Verify that individuals assigned technical security duties hold the necessary certifications or experience.

3. Audit IAM system configurations

Provision a technical export of your Identity and Access Management (IAM) roles to verify that the SoD matrix is technically enforced. This result ensures that permissions are not merely theoretical.

• Confirm that Requestor and Approver roles are assigned to distinct user IDs in your cloud console.
• Check for “Super User” accounts that might bypass defined segregation rules.
• Verify that Multi-Factor Authentication (MFA) is mandatory for all roles with approval authority.

4. Examine change management workflows

Audit the digital artifacts within your CI/CD or ticketing systems to ensure secondary sign-offs are mandatory. If it is not recorded in the workflow: the segregation does not exist.

• Review a sample of recent production deployments to ensure code was peer-reviewed by an independent party.
• Verify that the system blocks a user from approving their own change request.
• Examine timestamps to ensure approvals occur before execution.

5. Verify environment segregation

Audit network and system configurations to ensure the logical or physical separation of Development: Testing: and Production environments.

• Review firewall rules to ensure Dev environments cannot communicate directly with Production databases.
• Confirm that Production data is not used in Development or Testing without formal sanitisation.
• Check that Production administrative credentials differ from those used in lower environments.

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

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.

Top 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.

ISO 27001 Annex A 5.3 FAQ

ISO 27001 Templates

Fast track your ISO 27001 build with the ISO 27001 Templates Pack.

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