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

In this ultimate how to implement guide to ISO 27001 Annex A 5.3 Segregation of Duties, you will learn directly from an ISO 27001 Lead Auditor:

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.

About the author