ISO 27001 A.5.3 - Segregation of Duties

Requirement

Conflicting duties and conflicting areas of responsibility must be segregated.

Plain-language meaning

No single person should be able to perform a sensitive activity from beginning to end without independent oversight, approval, review, or control.

Segregation of duties reduces the risk of:

• fraud;
• abuse of privilege;
• unauthorized changes;
• human error;
• concealment of mistakes;
• conflicts of interest;
• loss of confidentiality, integrity, or availability.

Core idea

A person should not be able to both perform and independently approve, review, or hide the results of their own sensitive activity.

Memory phrase:

Separate request, approval, execution, and review.

Why segregation matters

Segregation is a traditional business control. It assumes:

• most people are honest, but controls still matter;
• honest people can make mistakes;
• honest people can act differently under pressure or duress;
• unchecked privileges create temptation and opportunity;
• negligent behavior can increase when nobody reviews activity.

The Barings Bank case is a classic example of serious control and management failures where one person had too much unchecked authority. The lesson for ISMS work is that critical processes need checks and balances.

How segregation works

Segregation divides a sensitive process across roles.

Example: access management.

This prevents one person from requesting, approving, implementing, and reviewing their own access.

Common segregation patterns

1. Maker-checker control

One person performs an action and another reviews or approves it.

Example:

• Admin prepares a firewall rule change.
• Network manager or security reviewer approves it.
• Change is implemented.
• Logs or change records are reviewed afterward.

2. Dual authorization

Two people must approve or perform an action.

Examples:

• two authorized people approve emergency privileged access;
• two people approve deletion of critical backups;
• two signatures required for high-value transactions.

3. Independent review

One person performs work and another independent person reviews records afterward.

Example:

• Administrator performs privileged activity.
• Security team reviews privileged activity logs weekly.

4. Role separation

Different responsibilities are assigned to different roles.

Example:

• Developers write code.
• DevOps deploys code.
• CAB or change owner approves high-risk changes.
• Security reviews critical security changes.

5. Technical enforcement

Systems prevent incompatible access combinations.

Examples:

• identity governance tool blocks incompatible roles;
• CI/CD pipeline requires peer approval;
• privileged activity is sent to immutable logs;
• system administrators cannot modify SIEM audit logs.

Information security examples

Small organizations

Small organizations may not have enough staff to fully segregate duties.

That does not mean they can ignore the control.

The practical approach:

1. identify where segregation is needed;
2. assess the risk of not segregating;
3. segregate where practical;
4. implement compensating controls where segregation is not possible;
5. document the decision and evidence;
6. review the exception periodically.

Compensating controls

Key exam point:

Lack of resources is not an excuse to do nothing. It requires risk-based compensating controls.

Audit guidance

Auditors should check whether the organization has identified conflicting duties and whether critical processes have checks and balances.

For small organizations, auditors should expect at least compensating controls for critical roles.

Audit tests

Audit focus areas

Security administration and audit are particularly critical. If the same person administers controls and audits the controls, independence is weak.

Auditors should also examine:

• access provisioning;
• privileged access;
• production change;
• log administration;
• backup deletion;
• incident evidence handling;
• supplier approval and payment;
• risk acceptance and control validation.

Strong evidence

• Documented SoD matrix.
• Incompatible roles identified in access governance.
• Workflow separates request, approval, implementation, and review.
• Admin activities are logged to a system admins cannot alter.
• Independent log reviews are performed and recorded.
• High-risk transactions require dual approval.
• Exceptions are risk-assessed, approved, time-bound, and monitored.
• Internal audit tests missing log entries or unauthorized activity.
• Holiday coverage does not remove independence.

Weak evidence

• “We trust our staff.”
• One person can create, approve, and review their own access.
• Admins can delete logs of their own activity.
• Developers can push directly to production without review.
• No SoD conflict analysis exists.
• Small organization uses lack of staff as a reason for no controls.
• Logs exist but are never reviewed.
• Reviews are performed by the same person whose activity is reviewed.
• Temporary holiday cover bypasses independence.

Common failures

Exam traps

• SoD applies only to finance — wrong.
• Small organizations can ignore SoD — wrong.
• Logging alone is enough — wrong unless logs are tamper-resistant and reviewed.
• Two people automatically means segregation exists — wrong if independence is weak.
• SoD eliminates collusion — wrong; it reduces risk but does not eliminate it.
• One person can have conflicting duties if they are senior — wrong unless risk-assessed and compensated.

KB-ready summary

A.5.3 reduces the risk of fraud, misuse, error, and concealment by separating conflicting duties. Sensitive processes should separate request, approval, execution, review, and monitoring. Where full segregation is not possible, the organization should use documented compensating controls such as immutable logging, independent review, dual authorization, and periodic management oversight.

Templates and checklists

• Segregation of Duties Matrix
• SoD Exception Record
• A.5.3 Audit Checklist