AC-5: Separation of Duties

What this control requires

AC-05 requires organizations to separate conflicting duties across roles and enforce those separations through system access controls. Most organizations think of access control as managing who can log in. Separation of duties goes further by addressing what combinations of access create risk when held by the same person.

In practice, this control has two parts. First, you document which job functions and system privileges must be divided across different roles. Second, you enforce those divisions through technical access controls so that one individual can’t both initiate and approve a sensitive transaction.

Specifically, the requirement spans mission functions, system administration, and security operations. Under NIST SP 800-53, this control is foundational to the integrity of financial processes, audit functions, and privileged system operations because no single person should be able to commit fraud, cause serious errors, or abuse privileges without someone else being in a position to detect it.

Why it matters

When a single employee holds enough access to execute a sensitive workflow from start to finish, the organization is one bad decision away from fraud, sabotage, or an undetected error that compounds over time. Separation of duties exists specifically to prevent this scenario, and failures are not hypothetical.

Specifically, the risk is highest in financial systems, privileged IT operations, and audit functions where one person controlling both sides of a transaction eliminates the checks that would catch abuse. Where organizations fail to divide duties, insider threats move from possibility to near-certainty. The VA benefit payment fraud case below is one documented example of what happens when this control is absent.

U.S. Department of Veterans Affairs benefit payment fraud

Terrence Starks was a U.S. Department of Veterans Affairs employee with legitimate access to the VA’s benefits payment system as part of his regular job. Using that access, he modified routing numbers and bank account information to redirect veterans’ benefit payments to an account he controlled with an accomplice.

Starks wasn’t an external attacker who had breached the system. He was an authorized user whose role gave him the ability to both view beneficiary payment details and change the destination of payments, with no independent review required.

The consequence was severe. A federal court convicted Starks of wire fraud and aggravated identity theft, sentencing him to 30 months in federal prison and ordering him to pay $19,260.26 in restitution. The VA Office of Inspector General investigated the case after receiving an external tip.

But the deeper failure was structural, not procedural. Internal controls did not catch the fraud because no separation existed between read and write access on payment routing, a textbook AC-05 gap.

In practice, this means a single structural control could have prevented the entire scheme. Had the VA’s system required a second approver for changes to payment routing, or separated the ability to view beneficiary details from the ability to modify them, the fraud would have been blocked immediately. Properly provisioned credentials don’t prevent abuse when one role holds unchecked authority over a sensitive end-to-end process.

What attackers exploit

• Roles with both read and write access to financial or payment routing data, allowing unilateral changes
• Absence of dual-approval workflows for sensitive transactions like payment modifications
• Security personnel who administer both access control and audit functions, enabling cover-up of unauthorized actions
• System administration and security roles consolidated in a single individual, removing independent oversight
• Lack of automated monitoring to flag when a single user completes both halves of a segregated process

How to implement

Most implementations fail not because organizations don’t understand the concept, but because they don’t map duties to specific system privileges early enough. A duty matrix that exists only in policy, without enforcement in access controls, is a gap auditors will flag and attackers will exploit.

For your organization

Step 1: Identify and document conflicting duties. Start by listing every critical business process that involves sensitive data, financial transactions, system administration, or audit and compliance functions. For each process, identify the discrete steps and determine which steps create risk if performed by the same individual.

Common conflict pairs include initiating and approving financial transactions, writing and deploying code to production, administering user accounts and reviewing audit logs, and creating vendor records and approving vendor payments.

Step 2: Build a duty separation matrix. Create a formal matrix mapping conflicting duties to roles. This matrix becomes a primary evidence artifact for auditors.

Each row should specify the two conflicting duties, the roles they’re assigned to, and the technical enforcement mechanism. Update the matrix whenever roles or processes change.

Step 3: Enforce through access controls. Configure your identity and access management (IAM) systems to prevent users from holding conflicting privileges. Use role-based access control (RBAC) or attribute-based access control (ABAC) to enforce mutual exclusivity. Where full technical enforcement isn’t feasible, implement compensating controls such as dual-approval workflows or real-time alerts when a user performs both sides of a segregated process.

Step 4: Address privileged and administrative accounts. Ensure that personnel who administer access controls don’t also administer audit functions. System backup operators shouldn’t hold restore privileges without oversight. Privileged access management tools can enforce session recording and approval gates for sensitive administrative actions.

Step 5: Monitor and audit. Configure audit logging to flag violations or attempts to circumvent duty separation. Review access patterns quarterly against the duty matrix. Automated tools in the security information and event management (SIEM) category can detect when a single identity performs conflicting actions within a defined window.

Common mistakes:

• Defining separation of duties in policy but never enforcing it technically
• Failing to update the duty matrix after organizational restructuring
• Over-relying on detective controls when preventive controls are feasible
• Granting “break glass” emergency access without post-incident review

For your vendors

When evaluating whether a vendor enforces separation of duties, you need evidence that goes beyond policy statements. Vendors operating at the MODERATE or HIGH baseline should demonstrate both documentation and technical enforcement.

Questionnaire questions to ask:

• How do you identify and document conflicting duties within your organization?
• What technical controls enforce separation of duties in your systems (for example, RBAC, dual-approval workflows, or mutual exclusivity constraints)?
• Who administers access controls, and are those individuals separate from personnel who manage audit logs?
• How frequently do you review your duty separation matrix, and what triggers an update?
• Can a single administrator both provision user accounts and approve their own access changes?

Evidence to request:

• A current duty separation matrix or conflict-of-interest policy with role-to-duty mappings
• Screenshots or configuration exports from IAM or access enforcement systems showing mutual exclusivity rules
• Audit logs demonstrating that dual-approval workflows are active for sensitive transactions
• Most recent internal or external audit report referencing separation of duties findings

Red flags:

• The vendor can’t produce a duty separation matrix or says “we handle it informally”
• A single administrator holds both user provisioning and audit log management roles
• No dual-approval workflow exists for financial transactions or change management processes
• The vendor’s last audit had findings related to segregation of duties that remain unresolved

To verify, cross-reference the vendor’s duty matrix against their access control configuration evidence. Look for alignment between documented separations and actual system enforcement. Ask for the most recent SOC 2 Type II report and check whether the auditor tested separation of duties controls and whether any exceptions were noted.

Evidence examples

Cross-framework mapping

Related controls

• AC-02 — Account Management: governs the lifecycle of user accounts, which provides the foundation that separation of duties builds on by restricting how those accounts combine privileges.
• AC-03 — Access Enforcement: implements the technical mechanisms that enforce the duty separations documented under AC-05.
• AC-06 — Least Privilege: limits users to the minimum access needed for their role, complementing duty separation by reducing the scope of any single account.
• AU-09 — Protection of Audit Information: ensures audit records can’t be tampered with by the personnel whose actions they track, a direct application of separation of duties to the audit function.
• CM-05 — Access Restrictions for Change: restricts who can make changes to system configurations, supporting duty separation in change management processes.
• CM-11 — User-installed Software: controls which users can install software, preventing a single individual from both deploying and approving unauthorized applications.
• CP-09 — System Backup: separates backup and restore functions so that no single individual can both create and manipulate backup data without oversight.
• IA-02 — Identification and Authentication (Organizational Users): verifies user identity before granting access, which is a prerequisite for enforcing role-based duty separations.
• IA-04 — Identifier Management: manages unique user identifiers that map to separated roles, preventing shared accounts from undermining duty controls.
• IA-05 — Authenticator Management: governs credentials and authentication tokens, ensuring that separated duties can’t be bypassed through shared or compromised authenticators.

Frequently asked questions

What is NIST SP 800-53 AC-05?

AC-05 is the NIST SP 800-53 control that requires organizations to identify duties that must be performed by separate individuals and enforce those separations through system access authorizations. It addresses scenarios where a single person holding too many privileges could commit fraud, introduce errors, or abuse their access without detection. The control specifically targets the documentation of conflicting duty pairs and the configuration of access controls to prevent any one user from completing both sides of a sensitive process.

What happens if AC-05 is not implemented?

Without AC-05, a single employee can hold enough system access to execute a sensitive workflow from initiation to completion with no independent check. In the VA benefit payment fraud case, one employee redirected veterans’ payments by modifying routing numbers because no separation existed between viewing payment details and changing payment destinations. The consequences extend beyond fraud to include undetected configuration errors, manipulation of audit logs by the same personnel responsible for the actions being audited, and regulatory findings that can jeopardize certifications at the MODERATE and HIGH baselines.

How do you audit AC-05?

Auditing AC-05 starts with reviewing the organization’s documented list of divided responsibilities and verifying that each conflicting duty pair maps to distinct roles with technical enforcement. Examiners check system access authorizations and configuration settings to confirm that mutual exclusivity constraints or dual-approval workflows are active, not just documented. They also review system audit records for violations, looking for instances where a single user performed both sides of a segregated process. The duty separation matrix, access control policy, and procedures addressing divisions of responsibility are the primary evidence artifacts.

What are examples of separation of duties in practice?

In financial operations, one person initiates a payment and a different person approves it, so no single individual can redirect funds unilaterally. In IT operations, the administrator who provisions user accounts shouldn’t be the same person who reviews audit logs for those accounts. Security personnel who manage access control lists should not also manage the audit functions that monitor those access decisions. In software development, the engineer who writes code shouldn’t be the same person who deploys it to production, ensuring that changes pass through an independent review before reaching live systems.