ISO 27001 Annex A 5.3 – Segregation of Duties is designed to reduce the risk of fraud, unauthorized activity, errors and misuse of information or technology resources by ensuring that conflicting responsibilities are appropriately separated.
In simple terms:
The person who requests an important action should not, wherever practical, be the only person who can approve and execute that action.
Segregation of duties does not mean that every task must be performed by a different employee.
The organization should identify conflicting duties and establish appropriate separation based on its size, risk, business model and available resources.
What Does ISO 27001 Annex A 5.3 Require?
The objective of A.5.3 is to ensure that conflicting duties and areas of responsibility are segregated.
The organization should identify activities where excessive control by one person could create a security risk.
Examples include:
- Requesting and approving access
- Developing and deploying software
- Creating and approving payments
- Creating and approving user accounts
- Making a change and independently approving that change
- Performing an activity and reviewing its own work
- Creating and approving supplier records
- Administering systems and independently reviewing privileged activity
The exact segregation required depends on the organization’s risk assessment.
Why Is Segregation of Duties Important?
Consider this example:
One employee can:
- Create a supplier
- Approve the supplier
- Create the payment
- Approve the payment
There is very little independent control.
If that account is compromised or the employee acts improperly, the organization may have difficulty detecting or preventing the activity.
A segregation-of-duties model could instead require:
Employee A → Creates supplier
↓
Manager → Approves supplier
↓
Finance → Processes payment
↓
Authorized Manager → Approves payment
This creates multiple points of control.
What Activities Should Be Segregated?
There is no universal list that applies to every organization.
Start by identifying activities where one person having complete control could create significant risk.
Typical areas include:
1. User Access
Request → Approval → Provisioning
Example:
- Employee/manager requests access
- System owner approves
- IT provisions access
2. Software Development
Development → Code Review → Production Deployment
Example:
- Developer writes code
- Another developer reviews the code
- Authorized person approves deployment
3. Financial Transactions
Creation → Approval → Payment
4. Security Administration
Privileged Change → Approval → Review
5. Supplier Management
Supplier Creation → Approval → Payment
6. Change Management
Change Request → Approval → Implementation → Verification
7. Audit
Control Owner → Auditor
The person responsible for operating a control should not normally be the person providing independent assurance over that same control.
How to Implement ISO 27001 A.5.3
Activity 1: Identify Critical Processes
Start by listing processes that could create significant security, financial or operational risk.
For example:
- Access management
- Change management
- Software deployment
- Incident management
- Financial processing
- Supplier management
- Backup administration
- Privileged access
- Security monitoring
Activity 2: Identify Conflicting Responsibilities
Ask:
Could one person perform this activity from beginning to end without independent review or approval?
For example:
High-risk combination
Developer + Production Deployment Approver
A developer could write and deploy code without independent review.
Better arrangement
Developer → Code Review → Deployment Approval → Production Deployment
Activity 3: Create a Segregation-of-Duties Matrix
A simple matrix can help identify conflicts.
| Activity | Request | Approve | Execute | Review |
|---|---|---|---|---|
| User access | Manager | System Owner | IT | ISMS/Security |
| Production change | Developer | Change Owner | IT/DevOps | Independent reviewer |
| Supplier payment | Procurement | Finance Manager | Finance | Finance reviewer |
| Code deployment | Developer | Technical Lead | DevOps | Security/QA |
| Security policy | ISMS Manager | Management | ISMS Manager | Management/Internal Audit |
The exact assignments should reflect the organization’s actual structure.
Activity 4: Implement Preventive Controls
Where practical, configure systems so that conflicting responsibilities cannot be performed by the same person.
Examples:
- Approval workflows
- Role-based access control
- Git branch protection
- Pull-request approval
- Production access restrictions
- ERP approval workflows
- Dual authorization
- Privileged access management
Example
A developer may be able to merge code only after another authorized developer approves the pull request.
This creates a technical segregation-of-duties control.
Activity 5: Implement Detective Controls
Perfect segregation is not always possible.
In a small organization, one person may have multiple responsibilities.
In such cases, compensating detective controls can help.
Examples:
- Independent review
- Log monitoring
- Periodic access review
- Management review
- Transaction review
- Audit trail monitoring
- Privileged activity review
Can a Startup Have the Same Person Perform Multiple Roles?
Yes, depending on the circumstances and risk.
This is particularly important for small organizations.
A 10-person startup may not have enough employees to completely separate every responsibility.
For example:
CTO
may be responsible for:
- IT administration
- Cloud infrastructure
- Security administration
Complete segregation may not be practical.
Instead, the organization could implement compensating controls such as:
- Management approval
- Monthly privileged-access review
- Cloud activity logging
- Independent review of major changes
- Periodic internal audit
The objective is to manage the risk created by conflicting responsibilities.
Example: Small SaaS Startup
Consider a SaaS startup with:
- 25 employees
- 5 developers
- 1 CTO
- 1 IT administrator
- 1 finance manager
- 1 CEO
The startup identifies software deployment as a critical activity.
Poor arrangement
Developer
→ Writes code
→ Approves code
→ Deploys directly to production
Improved arrangement
Developer
→ Writes code
↓
Another Developer
→ Reviews pull request
↓
CTO
→ Approves production release
↓
DevOps / Authorized Administrator
→ Deploys to production
↓
Monitoring
→ Confirms successful deployment
This reduces the risk associated with a single individual controlling the entire process.
Example: User Access
Suppose an employee requires access to the production database.
Step 1 – Request
Employee’s manager submits the access request.
Step 2 – Approval
The system owner reviews and approves the request.
Step 3 – Provisioning
IT/security provisions the access.
Step 4 – Review
Access is periodically reviewed by the system owner.
The same person does not control the entire process.
Example: Emergency Access
Sometimes segregation cannot be followed because of an emergency.
For example:
A critical production incident occurs at 2:00 AM and only one administrator is available.
The administrator may need emergency privileged access.
The organization can address this through an emergency access / break-glass process.
For example:
- Emergency access is granted.
- The activity is logged.
- The incident is documented.
- Management or another authorized person reviews the activity afterward.
- Unnecessary temporary access is removed.
This provides a compensating control when normal segregation is temporarily impractical.
What Events Should Trigger an A.5.3 Review?
Segregation of duties should be reviewed when important organizational or technology changes occur.
| Event | Example Action |
|---|---|
| New employee | Review assigned permissions |
| Employee leaves | Remove/reassign conflicting responsibilities |
| Promotion | Review role permissions |
| New application | Review application roles |
| New cloud environment | Review administrative access |
| Organizational restructuring | Review SoD matrix |
| New supplier | Review procurement/payment responsibilities |
| New financial system | Review approval workflows |
| Major security incident | Review whether conflicting access contributed |
| New business process | Identify new SoD conflicts |
| New regulatory requirement | Review applicable segregation |
| Annual access review | Reassess conflicting roles |
What Evidence Will an ISO 27001 Auditor Look For?
An auditor may look for evidence that the organization has actually identified and managed conflicting responsibilities.
Governance evidence
- Segregation of Duties Policy
- Access Control Policy
- Roles and Responsibilities Matrix
- RACI matrix
- SoD matrix
Technical evidence
- Access control configurations
- Role definitions
- Git permissions
- Pull-request approvals
- Production access controls
- ERP approval workflows
Operational evidence
- Access requests
- Approval records
- Change tickets
- Code reviews
- Deployment approvals
- Transaction approvals
- Periodic access reviews
Detective evidence
- Privileged activity logs
- Management reviews
- Security monitoring
- Exception reviews
- Audit reports
Exception evidence
Where segregation is not practical:
- Risk assessment
- Exception approval
- Compensating control
- Periodic review
Common A.5.3 Mistakes
1. Assuming SoD means every task needs two people
That is not the objective.
The focus is on conflicting duties and responsibilities.
2. Creating a theoretical matrix nobody follows
A segregation-of-duties matrix is useful only if it reflects actual system permissions and business processes.
3. Ignoring privileged IT access
Organizations often focus on financial approvals but overlook:
- Cloud administrators
- Database administrators
- Domain administrators
- Production administrators
These roles can have significant security impact.
4. Developers having unrestricted production access
Where practical, development and production responsibilities should be appropriately separated.
5. No compensating controls
Small companies may not be able to completely segregate every responsibility.
If one person must perform multiple conflicting duties, identify the risk and implement appropriate compensating controls.
6. No periodic review
Employee roles and permissions change.
The organization should periodically review whether segregation remains appropriate.
ISO 27001 A.5.3 Audit Checklist
| Question | Yes/No |
|---|---|
| Have conflicting duties been identified? | ☐ |
| Has the organization assessed SoD risks? | ☐ |
| Is a SoD matrix maintained where appropriate? | ☐ |
| Are access request and approval responsibilities separated? | ☐ |
| Are development and production activities appropriately separated? | ☐ |
| Are privileged activities appropriately controlled? | ☐ |
| Are critical changes independently approved? | ☐ |
| Are financial or high-risk transactions appropriately segregated? | ☐ |
| Are system owners identified? | ☐ |
| Are privileged permissions periodically reviewed? | ☐ |
| Are exceptions documented? | ☐ |
| Are compensating controls implemented where needed? | ☐ |
| Are emergency activities reviewed afterward? | ☐ |
| Are SoD responsibilities reviewed after organizational changes? | ☐ |
| Is evidence available to demonstrate implementation? | ☐ |
Practical Implementation Model
A simple A.5.3 implementation process is:
Identify Critical Activities
↓
Identify Conflicting Duties
↓
Assess Risk
↓
Define Segregation Requirements
↓
Configure Roles & Permissions
↓
Implement Approval Workflows
↓
Implement Monitoring / Review
↓
Document Exceptions
↓
Apply Compensating Controls
↓
Periodically Review
Policy vs Control vs Evidence
A useful way to understand A.5.3 is:
Policy
What does the organization require?
Conflicting information security duties shall be appropriately segregated based on risk.
Control
How is the requirement implemented?
Production deployments require approval from an authorized person other than the developer who performed the development activity.
Evidence
Show that the control operated.
For example:
- Pull request
- Reviewer approval
- Change ticket
- Deployment record
- Production log
Therefore:
Policy = Requirement
Control = Implementation
Evidence = Proof
What Does Good A.5.3 Implementation Look Like?
A mature organization should be able to answer:
Which activities require segregation?
The organization should have identified important conflicting duties.
Why are they segregated?
The segregation should be based on risk.
Who approves?
Approval responsibilities should be clearly assigned.
Who performs the activity?
Execution responsibilities should be clear.
What happens when segregation is not practical?
The organization should have documented exceptions and compensating controls.
Can you prove that the control operates?
The organization should retain appropriate evidence.
Useful Resources & Draft Documents
To help organizations implement ISO 27001 Annex A 5.3 – Segregation of Duties, we have prepared practical resources and draft documents.
📄 Draft Segregation of Duties Policy / Matrix
Please find the draft document here:
https://iso27001.makeauditeasy.in/docs/iso-27001/other-doc/segregation-of-duties-policy/
You can customize the document based on your organization’s:
- Organizational structure
- Business processes
- IT environment
- Critical applications
- Privileged accounts
- Financial processes
- Information security risks
📋 Other Useful Resources
You may also find these resources helpful:
- ISO 27001 Access Control Policy
- SO 27001 Roles & Responsibilities Template
- ISO 27001 RACI Matrix
- ISO 27001 Statement of Applicability (SoA) Guide – Understand how applicable controls are documented and justified.
- How to Prepare an ISO 27001 Statement of Applicability – Example
- ISO 27001 Risk Assessment Guide
- ISO 27001 Internal Audit Checklist
- ISO 27001 Implementation Guide for Startups
Important: Segregation of duties should be based on your organization’s actual risks. Smaller organizations may need to use compensating controls where complete separation is not practical.
Final Takeaway
ISO 27001 Annex A 5.3 is about preventing excessive control from being concentrated in a single person or role.
The organization should identify conflicting duties, separate them where practical, and introduce appropriate approval, monitoring or compensating controls where complete segregation is not possible.
A simple principle is:
Request → Approve → Execute → Review
These activities should be separated appropriately for higher-risk processes.
For a startup, this does not mean hiring four different people for every process.
Instead:
Identify the conflict → Assess the risk → Separate where practical → Add compensating controls where necessary → Keep evidence.
That is the practical approach to implementing ISO 27001 Annex A 5.3 – Segregation of Duties.