ISO/IEC 27001:2022 Annex A · Control 5.3

Segregation of Duties: A Practical Implementation Guide

Separate incompatible responsibilities so that one person cannot make, approve and conceal a sensitive action without independent oversight.

Control 5.3 addresses conflicting duties and areas of responsibility. Its purpose is to reduce the opportunity for unauthorized, fraudulent or accidental activity to occur without detection.

Practical interpretation: Segregation of duties is not simply “two people for every task.” It is a risk-based design decision: identify dangerous combinations of access or authority, separate them where practical and apply strong compensating controls where full separation is impossible.

Where conflicts commonly arise

A person can request, approve and provision their own access.
A developer can change production code and erase the related logs.
An employee can create a supplier, approve an invoice and release payment.
An administrator can modify security settings and independently review compliance.
An incident responder can alter evidence and approve the incident closure.
A backup operator can change backup jobs and report their own restore test as successful.

Step-by-step implementation

Identify critical transactions and assets

Focus on activities that could create significant financial, operational, legal or security harm. Use risk assessments, process maps, fraud scenarios, privileged access inventories and incident history to locate high-impact actions.

Break processes into stages

For each sensitive process, identify initiation, authorization, execution, recording and review. Conflicts become visible when one role controls several stages without independent checks.

Define incompatible combinations

Create a concise conflict matrix. Examples include “access requester + access approver,” “code developer + production deployer,” and “payment creator + payment approver.” Link each conflict to the risk it addresses.

Design preventive separation

Use workflow approvals, separate privileged accounts, role-based access, branch protection, dual authorization and system-enforced limits. Preventive controls are usually stronger than relying only on later review.

Use compensating controls for small teams

When full separation is impractical, document the reason and risk. Possible compensating controls include independent retrospective review, immutable logging, alerts to a manager, transaction limits, time-limited privilege, session recording or external review.

Test the actual access configuration

Policy statements alone do not prevent conflicts. Compare the conflict matrix with real permissions in applications, cloud platforms, source repositories and financial systems. Include service accounts and emergency access.

Review changes and exceptions

Reassess conflicts when people change roles, systems are replaced, teams reorganize or temporary access is granted. Set expiry dates for approved exceptions and verify that compensating controls actually operate.

Practical examples

Process	Risky combination	Preferred separation	Possible fallback
User access	Request and approval	Manager requests; asset owner approves; IT provisions	Independent weekly review of all grants
Software release	Develop and deploy	Peer-approved code; automated deployment by controlled pipeline	Immutable logs and post-deployment review
Payments	Create vendor and release payment	Procurement creates; Finance approves; authorized signer releases	Low transaction limits plus monthly independent review
Cloud administration	Change controls and review own activity	Administrators operate; Security monitors logs	Logs sent to a separate tenant with manager alerts
Incident response	Collect evidence and approve closure	Responder collects; Incident Manager approves closure	External or management review for high-severity cases

Example for a small software company

A 20-person company has only two infrastructure engineers, so complete separation is unrealistic. Either engineer may make an emergency production change. However, emergency access is time-limited, all commands are centrally logged, the other engineer reviews the change within one business day, and the CTO receives an alert. The exception and compensating controls are documented in the risk register.

Routine releases follow a stricter path: a pull request needs peer approval, protected branches prevent self-approval, and the deployment pipeline—not the developer's personal account—releases to production. Production logging is administered separately from application administration.

Evidence checklist

Segregation-of-duties policy or standard
Critical process maps
Incompatible-role matrix
Role and permission design
Workflow approval configurations
Privileged access inventory
Access review results
Conflict scan reports
Exception and risk approvals
Compensating-control evidence
Change and deployment logs
Emergency-access reviews

Useful metrics

Number of unresolved incompatible-access conflicts
Percentage of sensitive workflows with enforced independent approval
Number of expired exceptions still active
Percentage of emergency actions independently reviewed on time
Average time to remove a conflict after a role change

Common mistakes

Documenting separation that systems do not enforce. Real permissions contradict the process diagram.
Ignoring administrators and service accounts. Technical privilege may bypass business workflows.
Adding approval without independence. The approver reports to or shares credentials with the requester.
Applying the same rigor everywhere. Low-risk activities become inefficient while high-risk conflicts receive insufficient attention.
Permanent “temporary” exceptions. Access remains after the business need ends.
No monitoring of compensating controls. A promised review is not evidence that reviews occur.

Questions an auditor may ask

How did you identify incompatible duties?
Show a sensitive process from request through approval, execution and review.
How do systems prevent users from approving their own actions?
Which conflicts are accepted because of team size, and what compensating controls exist?
Show a recent review of emergency or privileged activity.

Implementation test: Ask what a malicious or careless insider could do alone. If one account can initiate a high-impact action, approve it, modify the evidence and close the review, the process needs stronger separation or compensating oversight.

Continue through Annex A

Explore the complete set of practical Annex A implementation guides.

Open the ISO 27001 Annex A Control Library

This independent educational guide paraphrases the practical intent of the control and does not replace the official ISO standards, professional advice or an organization-specific risk assessment. It is not affiliated with or endorsed by ISO.

ISO 27001 Annex A 5.3: Segregation of Duties – Practical Implementation Guide