NIST 800-53 REV 5 • ACCESS CONTROL
AC-5 — Separation of Duties
Identify and document {{ insert: param, ac-05_odp }} ; and Define system access authorizations to support separation of duties.
Supplemental Guidance
Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission or business functions and support functions among different individuals or roles, conducting system support functions with different individuals, and ensuring that security personnel who administer access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of systems and system components when developing policy on separation of duties. Separation of duties is enforced through the account management activities in [AC-2](#ac-2) , access control mechanisms in [AC-3](#ac-3) , and identity management activities in [IA-2](#ia-2), [IA-4](#ia-4) , and [IA-12](#ia-12).
Practitioner Notes
Separation of duties means no single person can control all aspects of a critical process. The person who requests access should not be the same person who approves it. The person who writes code should not deploy it to production.
Example 1: In Active Directory, ensure that no single account is a member of both Domain Admins and Account Operators. Your system admin who manages servers should not also be the person who manages user accounts. Document these role separations in your security plan.
Example 2: In your change management process, require that the developer who writes a code change cannot be the same person who approves the pull request or deploys it to production. In Azure DevOps, enforce this with branch policies that prohibit self-approval under Repos → Branches → Policies → Require a minimum number of reviewers.