How to Implement ISO 27001 Annex A 5.3: Segregation of Duties

Implementing ISO 27001 Annex A 5.3 is the operational enforcement of segregation of duties to minimize the risk of internal fraud and error. This control requires organizations to divide critical business functions between multiple individuals, ensuring that no single person has the authority to initiate, approve, and execute high-risk transactions. By establishing these checks and balances, companies protect assets and ensure accountability.

ISO 27001 Annex A 5.3 Implementation Checklist

Use this implementation checklist to achieve compliance with ISO 27001 Annex A 5.3. This control ensures that conflicting duties are identified and managed to reduce the risk of unauthorised or unintentional modification of organisational assets.

Create a Segregation of Duties (SoD) Conflict Matrix

Control Requirement: Conflicting duties and areas of responsibility must be identified and segregated.

Required Implementation Step: Open a spreadsheet and list all high-risk business processes (e.g., procurement, payroll, system administration). Map these against job roles to identify “conflicts” where one person could perform and conceal a malicious act.

Minimum Requirement: A documented table identifying at least three key areas (Finance, IT, and HR) where duties are split between two different people.

Audit Active Directory Domain Administrator Privileges

Control Requirement: Access to high-level administrative functions must be restricted to prevent a single point of failure or misuse.

Required Implementation Step: Go to your Active Directory or Azure AD management console and export the ‘Domain Admins’ or ‘Global Admins’ group. Remove any users who do not require these rights for their primary daily tasks.

Minimum Requirement: A screenshot of the admin group showing that no more than two named individuals have full system-wide administrative authority.

Separate Financial Approval and Payment Execution

Control Requirement: Responsibility for initiating a transaction must be separate from the responsibility for approving it.

Required Implementation Step: Open your online banking portal or accounting software settings. Verify that the “Maker/Checker” or “Dual Authorisation” feature is active for all outgoing payments and payroll runs.

Minimum Requirement: A redacted bank statement or portal screenshot showing two different user IDs required for a single transaction approval.

Mandate Peer Review for Source Code Commits

Control Requirement: Technical changes must be reviewed by someone other than the person who developed the change.

Required Implementation Step: Navigate to your Git repository settings (GitHub, GitLab, or Bitbucket). Enable “Branch Protection” on your ‘main’ or ‘production’ branches to require a pull request and at least one independent approval before merging.

Minimum Requirement: A sample Pull Request (PR) log showing the developer’s name and a different colleague’s approval name.

Restrict Developer Access to Production Environments

Control Requirement: Development, testing, and operational environments must be separated to reduce the risk of unauthorised changes.

Required Implementation Step: Audit your cloud environment (AWS, GCP, or Azure) IAM roles. Ensure that users with the ‘Developer’ role do not have ‘Owner’ or ‘Contributor’ permissions on production resources or databases.

Minimum Requirement: A policy document or system export proving that the production database password is not known by the development team.

Implement Multi-Stage Change Management Approvals

Control Requirement: Changes to systems must be approved by an authorised party who is independent of the person making the change.

Required Implementation Step: Look at your last three system changes. Ensure the ‘Request for Change’ (RFC) was signed off by a manager or Change Advisory Board (CAB) rather than the engineer who performed the update.

Minimum Requirement: An email trail or change log entry where a supervisor approves a change before it is executed on live systems.

Isolate Physical Key Management from Access Authorisation

Control Requirement: Physical access controls must be segregated to prevent unauthorised entry through collusion or administrative error.

Required Implementation Step: Go to your office security records. Ensure that the person responsible for authorising a new staff member’s building access is not the same person who physically programmes the RFID fob or issues the physical key.

Minimum Requirement: A simple sign-off sheet where one manager authorises access and a separate ‘Security Officer’ confirms the fob was issued.

Review High-Privilege Third-Party Service Accounts

Control Requirement: Third-party access to organisational assets must be monitored and segregated from internal administrative roles.

Required Implementation Step: Examine your external vendor list. Ensure that any MSP or consultant has an individual, auditable account rather than using shared ‘Admin’ credentials, and that their access is restricted only to the systems they support.

Minimum Requirement: A contract clause or system log showing that third-party access is ‘Just-in-Time’ or requires internal sponsor approval for each session.

Formalise the Employee Onboarding Access Request Process

Control Requirement: Access rights must be provisioned based on role requirements, ensuring no single role accumulates conflicting permissions.

Required Implementation Step: Open your HR onboarding checklist. Ensure that IT only grants access once an ‘Access Request Form’ is received, specifying the role-based permissions needed rather than “copying” the access of another employee.

Minimum Requirement: A completed Access Request Form for the most recent hire, signed by their line manager.

Perform Quarterly Governance Access Re-certifications

Control Requirement: Access rights and assigned duties must be reviewed at planned intervals to identify role-creep or conflicts.

Required Implementation Step: Set a recurring calendar invite for every 90 days. Manually review all users with administrative or financial authority and document that they still require those rights and that no new SoD conflicts have been created.

Minimum Requirement: A signed and dated memo or spreadsheet from the Information Security Officer confirming the quarterly access review was completed.

ISO 27001 Annex A 5.3 SaaS / GRC Platform Implementation Failure Checklist

Control Requirement	The ‘Checkbox Compliance’ Trap	The Reality Check
Identify Conflicting Duties	Uploading a generic “Segregation of Duties Policy” to the GRC dashboard and marking it “Done”.	The auditor will ask to see your actual SoD Matrix and how it applies to your specific staff names.
Technical Segregation	The GRC tool shows a green tick because you linked it to an IAM policy.	An auditor will look at the live AWS/Azure console to see if developers *actually* have write-access to Prod.
Dual Authorisation	Setting a “Review Task” in the SaaS platform that any user can mark as complete.	Showing an immutable bank log or code-merge history where the approver is a different human than the submitter.
Role Re-certification	Automated emails from the tool that managers “Accept All” without looking.	Interviewing a manager to ask *why* a specific person has a specific privilege and seeing if they know the answer.
Physical Segregation	Relying on a SaaS tool that only monitors digital logs but ignores physical keys/fobs.	Checking the physical sign-out sheet for the office server room keys.
Change Independence	Linking a Jira ticket to a GRC control without verifying who the reporter and assignee were.	Verifying that the person who typed the code is not the person who clicked “Deploy to Production”.
Access Provisioning	Using “Role Based Access” in the GRC tool that doesn’t actually sync with your real IT systems.	Comparing the GRC “Owner List” to the actual HR payroll list to find “Ghost” accounts or role-creep.

About the author