Segregation of Duties in ISO 27001 (Control 5.3)

When a single employee can create a vendor account, approve a payment, and reconcile the ledger, fraud doesn’t require sophistication — it just requires opportunity. ISO 27001 control 5.3 exists because the absence of segregation of duties turns routine business processes into single points of failure, where errors go unnoticed and malicious actions go undetected.

What 5.3 Requires

ISO 27001 5.3 requires your organization to identify where one person holds enough authority to complete a sensitive process from start to finish — and then break that chain. You must separate conflicting duties and areas of responsibility so that no individual can initiate, approve, and execute a critical action without a second person’s involvement. This applies across business operations, IT processes, financial workflows, and security controls.

Where full separation isn’t feasible — common in teams under 20 people — you must implement compensating controls. These include enhanced logging of privileged actions, mandatory management review of sensitive transactions, and dual authorization requirements for high-risk changes. The key is that “we’re too small” is not an acceptable justification on its own; you need documented alternatives that achieve the same risk reduction.

The requirement exists because concentrated authority creates blind spots. When the same person who provisions user accounts also reviews access logs, there is no independent check on whether those accounts should exist. When the same developer who writes code also deploys it to production, there is no gate between a mistake — or a backdoor — and a live system. Segregation of duties forces a second pair of eyes into every critical workflow, which is the simplest and most effective way to catch both honest mistakes and deliberate abuse.

The standard does not prescribe a specific organizational structure or a minimum team size. Instead, it requires you to assess where conflicting duties exist in your environment and either separate them across different individuals or implement compensating controls that provide equivalent oversight. The focus is on outcomes — preventing unilateral control over sensitive processes — not on any particular way of achieving that separation.

Why 5.3 Matters

Organizations that fail to implement segregation of duties often discover the consequences through their most trusted employees. In a common pattern, a system administrator with unchecked access gradually escalates their own privileges, creates service accounts that bypass normal approval workflows, and accesses sensitive data without triggering any alerts — because the person responsible for monitoring is the same person performing the actions. By the time the activity surfaces, typically during an external audit or a role transition, months of unauthorized access have already occurred. The financial and reputational damage compounds with every day of undetected activity, and the forensic investigation is complicated by the fact that the actions were performed through legitimate channels rather than through an exploited vulnerability.

The risk class here is insider threat combined with operational integrity failure. Unlike external attacks that trigger perimeter defenses, segregation failures are quiet. There is no malware signature to detect and no anomalous login from an unfamiliar geography. The activity looks legitimate because it comes from a legitimate user operating within their assigned — but overly broad — authority. The Verizon 2024 Data Breach Investigations Report found that privilege misuse rose to the second most common breach pattern, with 897 incidents and 854 confirmed data disclosures in a single reporting period — underscoring how frequently unchecked internal access leads to real harm.

What attackers exploit

• Single-person approval chains: One individual can both request and approve access rights, creating accounts or elevating privileges without independent review.
• Self-deploying developers: Engineers push their own code directly to production without peer review or a separate deployment function, enabling both accidental and deliberate introduction of vulnerabilities.
• Self-auditing administrators: IT staff monitor and audit their own systems, eliminating any independent verification of their activity.
• Shared privileged accounts: Generic admin or root accounts used by multiple people destroy individual accountability and make forensic investigation nearly impossible.
• Permission drift: Roles accumulate conflicting permissions over time as employees change teams or take on additional responsibilities without losing prior access.
• Unmonitored privileged actions: No logging or alerting on sensitive operations, so even if duties aren’t separated, there is no compensating visibility.

How to Implement 5.3

Implementing segregation of duties is not a one-time project — it requires building separation into how your organization designs processes, assigns roles, and reviews access over time.

For your organization (first-party)

Start by mapping your critical processes end to end. Focus on the workflows where a single point of control creates the most risk: user provisioning, change management, financial approvals, code deployment, and security control design. For each process, document who currently performs each step — request, approval, execution, and review.

Next, identify the conflicts. Any process where the same person or role handles two or more of those steps is a segregation gap. The most common conflicts are IT administrators who approve their own access requests, developers who deploy their own code to production, and security managers who audit controls they designed.

Implement role-based access control (RBAC) to enforce separation technically. Identity providers like Okta or Microsoft Entra ID allow you to define roles with non-overlapping permissions, ensuring that “the person who requests” is technically distinct from “the person who approves.” Pair this with multi-level approval workflows in your ticketing or workflow management systems.

For small teams where full separation isn’t possible, document compensating controls explicitly. These should include enhanced logging of all privileged actions stored in a location the privileged user cannot modify, mandatory management review of sensitive transactions on a defined schedule (weekly or monthly), and dual authorization for high-risk changes such as firewall rule modifications or database schema changes. Record each exception in your risk register with a formal risk acceptance.

Build a segregation of duties matrix that maps each critical process to its constituent steps and identifies which roles are permitted to perform each step. This matrix becomes both an implementation tool and an audit artifact — it shows auditors exactly how your organization has designed separation into its workflows.

Conduct periodic access reviews — quarterly at minimum — to catch role drift. Employees who change positions, take on interim responsibilities, or work across departments frequently accumulate conflicting permissions that weren’t intended. These reviews should compare current access against the RBAC matrix and flag any conflicts for remediation.

Common mistakes:

• Treating segregation of duties as a policy statement without enforcing it technically through RBAC or workflow controls
• Using shared admin accounts that make individual accountability impossible
• Never reviewing access after initial provisioning, allowing permission drift to go unchecked for years
• Accepting “we’re too small to segregate” without implementing or documenting compensating controls
• Allowing security personnel to audit their own controls, undermining the independence that ISO 27001 clause 9.2.2 requires

For your vendors (third-party assessment)

When assessing vendors for segregation of duties compliance, include these questions in your security questionnaire:

• “How does your organization identify and separate conflicting duties?”
• “What compensating controls are in place where full separation is not feasible?”
• “Who approves privileged access requests, and is the approver independent from the requestor?”
• “How frequently do you conduct access reviews, and who performs them?”

Request supporting evidence: a segregation of duties policy, an RBAC matrix showing role-to-permission mappings, recent access review reports with findings and remediation actions, and change management records demonstrating separate requestor, approver, and implementer for system changes.

Red flags in vendor responses:

• A single administrator with unrestricted access to production systems and no oversight mechanism
• No documented access review process or inability to produce review records
• “We trust our employees” presented as the primary control rather than a verifiable process
• No compensating controls documented for teams too small to fully segregate duties

To verify beyond self-attestation, request a sample of recent access review output showing actual findings and remediations. Ask for a change management ticket that demonstrates distinct individuals in each role. Check whether the vendor’s internal audit function operates independently from the teams it audits. Where a vendor holds SOC 2 Type II certification, review the report for any exceptions related to logical access controls or segregation of duties — these often surface gaps that self-attestation conceals.

Audit Evidence for 5.3

Auditors assessing control 5.3 expect both policy-level documentation and operational evidence that segregation is actively enforced — not just described. A policy that says “we separate duties” is insufficient without evidence that the separation actually happens in practice. Auditors will select sample processes and trace them end to end, checking that different individuals performed each step.

Cross-Framework Mapping

ISO 27001 5.3 maps broadly across compliance frameworks because segregation of duties is a foundational internal control principle. If your organization complies with multiple frameworks simultaneously — common in enterprises subject to both ISO 27001 and SOC 2, or financial institutions subject to DORA or CPS 230 — this mapping helps you avoid duplicating work by identifying where a single implementation satisfies multiple requirements.

The NIST 800-53 mappings below come from the official OLIR (Online Informative References) crosswalk. Most map at the policy-development level (the “-01” family controls), while AC-05 directly addresses separation of duties.

Related ISO 27001 Controls

Segregation of duties does not operate in isolation. It connects functionally to controls governing identity, access, change management, and organizational governance. Understanding these relationships helps you implement 5.3 as part of a coherent control environment rather than as a standalone checkbox. Several of these controls provide the technical mechanisms that make segregation enforceable, while others define the organizational context in which it operates.

Frequently Asked Questions

What is ISO 27001 5.3?

ISO 27001 5.3 is an organizational control that requires organizations to separate conflicting duties and areas of responsibility to reduce the risk of fraud, error, and unauthorized activity. It mandates that no single person should have end-to-end control over a sensitive process, and where full separation isn’t feasible, compensating controls such as enhanced logging and management oversight must be implemented.

What happens if 5.3 is not implemented?

Without segregation of duties, a single employee can initiate, approve, and execute sensitive actions — such as creating user accounts, approving payments, or deploying system changes — without any independent check. This creates conditions for undetected fraud, privilege escalation, and operational errors that can persist for months before discovery, typically surfacing only during external audits or investigations.

How do you audit 5.3?

Auditors assess 5.3 by selecting sensitive processes — such as change management or user provisioning — and tracing them end to end to verify that different individuals perform each step. They review RBAC matrices, access review records, change management logs, and privileged access audit trails. Where full segregation isn’t possible, auditors expect documented compensating controls and risk register entries showing formal risk acceptance.

How UpGuard Helps

Monitor vendor segregation of duties compliance continuously

UpGuard’s platform gives you continuous visibility into your vendors’ security posture, including the access controls and governance practices that underpin segregation of duties. Instead of relying on point-in-time questionnaires, you can track compliance evidence and flag control gaps as they emerge. Explore the UpGuard platform.