1. Purpose
The purpose of this Segregation of Duties Policy is to reduce the risk of unauthorized activities, errors, fraud, misuse of privileges, and conflicts of interest by separating incompatible responsibilities wherever practical.
The organization shall identify activities where having excessive control with one individual could create an unacceptable information security or business risk and shall establish appropriate separation, approval, review, or compensating controls.
Segregation of duties is particularly important for activities involving:
- Privileged access
- Financial transactions
- Production systems
- Security administration
- Access approvals
- Software deployment
- Vendor management
- Risk acceptance
- Audit activities
2. Scope
This policy applies to:
- Employees
- Contractors
- Consultants
- Temporary workers
- System administrators
- Developers
- Managers
- Finance personnel
- Security and compliance personnel
- Third-party service providers
It applies to business processes, information systems, cloud environments, applications, and other activities within the scope of the organization’s ISMS.
3. What Is Segregation of Duties?
Segregation of Duties (SoD) means dividing sensitive or conflicting responsibilities among different individuals or roles so that one person cannot independently perform an entire high-risk transaction or process without appropriate oversight.
A simple principle is:
No individual should have more control over a critical process than is appropriate for their role and risk.
For example:
Request Access → Approve Access → Provision Access
Where practical, these responsibilities should not all be controlled by the same person.
4. Objectives
The organization shall use segregation of duties to:
- Reduce unauthorized activity
- Prevent misuse of privileged access
- Reduce fraud risk
- Reduce accidental errors
- Prevent inappropriate self-approval
- Improve accountability
- Strengthen internal controls
- Protect sensitive information
- Support independent review
- Improve auditability
5. Segregation of Duties Principles
5.1 Separation of Request and Approval
Where practical, the person requesting access, expenditure, or a sensitive activity should not be the sole person approving it.
Example
Employee requests AWS production access → Manager/System Owner approves → IT provisions access
5.2 Separation of Approval and Execution
Where practical, the person approving a sensitive activity should not also be the person executing it without appropriate oversight.
Example
Change requested → Change approved → Change implemented
5.3 Separation of Development and Production
For critical systems, developers should not have unrestricted ability to independently develop, approve, and deploy changes to production.
A typical process may be:
Developer → Code Review → Approval → CI/CD → Production
The exact separation should be based on the organization’s risk and technology architecture.
5.4 Separation of Administration and Review
Where practical, individuals responsible for administering critical security controls should not be the sole person responsible for reviewing their own activities.
For example:
An administrator may manage privileged access, while a security or management role performs periodic review of privileged access.
5.5 Separation of Risk Ownership and Audit
Individuals should not independently audit activities for which they are directly responsible when doing so would compromise the objectivity of the audit.
For example:
A person responsible for implementing a control should not be the sole internal auditor assessing the effectiveness of that same control.
6. Identification of Conflicting Duties
The organization shall identify activities where combining responsibilities could create significant risk.
Examples include:
| Responsibility 1 | Responsibility 2 | Potential Risk |
|---|---|---|
| Request access | Approve own access | Unauthorized privilege |
| Approve access | Provision own access | Bypass of approval |
| Develop software | Approve own production change | Unauthorized code deployment |
| Create vendor | Approve vendor payment | Fraud/error |
| Create user | Approve own privileged access | Privilege misuse |
| Administer security system | Independently audit own work | Lack of objectivity |
| Create financial transaction | Approve transaction | Unauthorized payment |
| Identify risk | Solely approve risk acceptance | Inadequate challenge |
| Configure controls | Solely verify controls | Self-review |
Not every combination is automatically prohibited. The organization should evaluate the risk and apply appropriate controls.
7. Access Management and Segregation of Duties
Access permissions shall be designed to prevent inappropriate combinations of privileges.
Examples include:
- A user should not receive unnecessary administrator privileges.
- A developer should not automatically receive unrestricted production administration.
- An employee should not approve their own access request.
- A user should not have conflicting financial permissions without appropriate justification and oversight.
Where systems support role-based access control, predefined roles should be used to reduce conflicting permissions.
8. Privileged Access
Privileged access shall receive additional segregation and oversight based on risk.
Examples include:
- Cloud administrators
- Database administrators
- Domain administrators
- Security administrators
- Identity administrators
- Production administrators
Where practical:
Request → Approval → Privilege Assignment → Monitoring → Review
Privileged access should be periodically reviewed to identify:
- Excessive privileges
- Conflicting permissions
- Unused privileges
- Former employees
- Temporary access that was not removed
- Privileges no longer required
9. Software Development and Deployment
For systems where unauthorized changes could create significant risk, the organization shall implement appropriate separation between development, review, approval, and production deployment.
A startup may implement:
Developer
↓
Pull Request
↓
Peer Review
↓
Automated Testing
↓
Approved Merge
↓
CI/CD Deployment
↓
Production
For higher-risk production changes, additional approval may be required.
The level of segregation should be proportional to:
- System criticality
- Customer impact
- Security risk
- Regulatory requirements
- Team size
- Technical architecture
10. Change Management
Changes to critical systems should follow an appropriate approval and implementation process.
Where practical:
- Change requester ≠ change approver
- Change approver ≠ sole change verifier
- Production implementation should be controlled
- Emergency changes should be documented and reviewed afterward
Automated CI/CD controls may provide segregation where manual separation is impractical.
11. Access Request and Provisioning
Access should follow:
Request → Approval → Provisioning
The requester should not be able to grant themselves the requested permissions.
For example:
An employee requests access to AWS production → Manager approves business need → System owner approves where required → IT/Cloud administrator provisions access.
The access request and approval should be retained as evidence.
12. Financial and Procurement Activities
Where relevant to the ISMS and business operations, financial and procurement activities should incorporate appropriate segregation.
For example:
Vendor Selection → Vendor Approval → Purchase → Payment
Where organizational size makes complete separation impractical, compensating controls may include:
- Management review
- Transaction limits
- Periodic independent review
- Automated approval workflows
- Audit logs
13. Supplier and Third-Party Activities
Third-party personnel with access to organizational systems should not receive unnecessary combinations of privileges.
Where practical:
- Access should be individually assigned.
- Responsibilities should be defined.
- Privileged access should require approval.
- Access should be time-limited where appropriate.
- Activity should be logged.
- Access should be periodically reviewed.
14. Small Startup Considerations
Complete segregation of duties can be difficult for a startup with a small team.
For example, a 10-person company may not have separate:
- IT administrator
- Security manager
- Compliance manager
- Internal auditor
- Change manager
In such cases, the organization should not simply ignore segregation of duties.
Instead, it should use risk-based compensating controls.
Examples:
Option 1 — Management Review
If the CTO performs a technical change, another authorized manager reviews the change afterward.
Option 2 — Automated Controls
Use GitHub branch protection and pull-request approvals to prevent direct production changes.
Option 3 — External Review
An independent consultant or auditor performs periodic review.
Option 4 — System-Enforced Permissions
Use AWS IAM, SSO, CI/CD controls, and role-based permissions to enforce separation technically.
Option 5 — Periodic Independent Review
Where the same person must perform multiple responsibilities, an independent review can provide additional oversight.
The objective is not to create unnecessary bureaucracy.
The objective is to ensure that critical actions cannot be performed without appropriate control or oversight.
15. Compensating Controls
When full segregation is not practical, management shall identify and implement appropriate compensating controls.
Possible compensating controls include:
- Management approval
- Independent review
- Automated workflow approvals
- System-enforced access restrictions
- Transaction limits
- Activity logging
- Periodic access reviews
- Exception monitoring
- External review
- Increased monitoring
The compensating control should address the specific risk created by the lack of segregation.
16. Emergency Access
Emergency access may be required to restore services or respond to security incidents.
Emergency access should:
- Be limited to authorized personnel
- Be granted only when necessary
- Be logged
- Be appropriately monitored
- Be reviewed after use
- Be removed when no longer required
Emergency access should not become a permanent workaround for normal access-control procedures.
17. Internal Audit Independence
Internal audit activities should maintain appropriate objectivity.
Where possible, auditors should not audit activities for which they have direct operational responsibility.
For a small startup where complete independence is difficult, management should consider:
- Using a different employee
- Cross-functional review
- External auditor/consultant
- Independent periodic assessment
The organization should document how audit objectivity is maintained.
18. Responsibilities
| Role | Responsibility |
|---|---|
| Top Management | Approve segregation principles and accept significant exceptions |
| ISMS/Security Manager | Identify and monitor SoD risks |
| System Owner | Define appropriate access and role separation |
| IT/Cloud Team | Implement technical access restrictions |
| Engineering Lead | Ensure appropriate separation in development and deployment |
| HR | Communicate role changes and employee departures |
| Managers | Approve business access requirements |
| Internal Auditor | Independently evaluate relevant controls |
| Employees | Follow assigned responsibilities and approval processes |
19. Segregation of Duties Matrix
The organization may maintain a simple SoD matrix.
| Activity | Request | Approve | Execute | Review |
|---|---|---|---|---|
| User access | Employee | Manager/System Owner | IT | Security |
| Privileged access | User/Manager | System Owner | IT/Security | Security/Management |
| Production change | Developer | Change Approver | DevOps | System Owner |
| Vendor onboarding | Procurement | Management | Procurement | Finance/Management |
| Payment | Requester | Authorized Approver | Finance | Management |
| Risk acceptance | Risk Owner | Management | N/A | ISMS |
| Internal audit | N/A | Management | Auditor | Management |
For smaller organizations, one individual may perform more than one role. Such combinations should be evaluated based on risk.
20. Evidence of Segregation of Duties
Possible evidence includes:
- Role and responsibility matrix
- RACI matrix
- Access-control matrix
- IAM role definitions
- User-access reports
- Access approval records
- Pull requests
- Code-review records
- Change tickets
- CI/CD configuration
- Production deployment logs
- Privileged-access reviews
- Management approvals
- Exception records
- Internal audit records
The evidence should demonstrate that segregation is actually operating, rather than existing only in the policy.
21. Example: AWS SaaS Startup
Consider a 25-person SaaS company using AWS and GitHub.
The organization could implement the following model:
Developer
- Development access
- GitHub repository access
- No unrestricted AWS production administrator access
Engineering Lead
- Code-review authority
- Production-change approval where required
Cloud Administrator
- AWS infrastructure administration
- Cannot independently approve their own privileged-access request
CTO
- Approves high-risk production access
- Reviews significant changes
Security/Compliance Lead
- Performs periodic privileged-access reviews
- Monitors security controls
- Coordinates internal audit
CI/CD Platform
- Enforces branch protection
- Requires approved pull requests
- Controls production deployment
This provides practical segregation without requiring a large organizational structure.
22. Segregation of Duties and Evidence
A policy alone does not demonstrate effective segregation.
Consider this requirement:
Privileged access must be appropriately controlled.
Policy
Privileged access requires authorization.
Implementation
AWS IAM roles restrict administrative permissions.
Evidence
- Access request
- Approval
- IAM role assignment
- MFA configuration
- Privileged-access list
- Periodic access review
- CloudTrail logs
This demonstrates the complete chain:
Requirement → Risk → Control → Implementation → Evidence → Review
23. Exceptions
Where segregation of duties cannot be implemented because of:
- Small team size
- Technical limitations
- Emergency circumstances
- Business requirements
- Legacy systems
the exception shall be:
- Documented
- Risk assessed
- Approved by an authorized person
- Supported by compensating controls where appropriate
- Periodically reviewed
- Removed when the underlying reason no longer exists
Exceptions should have an owner and, where practical, an expiry or review date.
24. Policy Review
This policy shall be reviewed periodically and when significant changes occur, including:
- Organizational restructuring
- New systems
- New cloud platforms
- Major changes to access architecture
- Security incidents
- Significant audit findings
- Changes to legal or contractual requirements
- Changes to ISMS scope
25. Quick Startup Checklist
Before considering Segregation of Duties operational, ask:
- Are critical responsibilities identified?
- Are conflicting responsibilities documented?
- Can users approve their own access?
- Can administrators approve their own privileges?
- Is production access appropriately separated?
- Are code changes independently reviewed?
- Are production deployments controlled?
- Are privileged accounts periodically reviewed?
- Are financial/procurement conflicts addressed where relevant?
- Are third-party privileges controlled?
- Are emergency privileges reviewed?
- Are exceptions documented?
- Are compensating controls used where separation is impractical?
- Is internal audit sufficiently objective?
- Can the organization demonstrate evidence of SoD controls?
26. Final Principle
Segregation of Duties does not mean that every task must be performed by a different employee.
For a startup, that approach may be impractical.
The objective is to identify high-risk combinations of responsibilities and ensure that they are appropriately separated, restricted, approved, monitored, or independently reviewed.
A practical model is:
Request → Approve → Execute → Review
Where complete separation is not possible:
Combine Roles → Assess Risk → Apply Compensating Control → Monitor → Review
The goal is simple:
No individual should have unchecked control over a critical activity when that creates an unacceptable security or business risk.