Separate the duties of individuals to reduce the risk of malevolent activity
📖 What This Means
This practice requires organizations to assign different responsibilities to different people to prevent any single individual from having too much control over critical systems or data. By separating duties, the organization reduces the risk of insider threats, fraud, or accidental misuse. For example, the person who approves access requests should not be the same person who grants access. Similarly, the person who develops software should not be the same person who deploys it to production. This ensures checks and balances are in place, making it harder for malicious or negligent actions to go unnoticed.
🎯 Why It Matters
Without separation of duties, a single individual could exploit their access to compromise sensitive data or systems. For instance, in the 2017 Equifax breach, a lack of proper role separation allowed attackers to exploit weak access controls, leading to the exposure of 147 million records. Such breaches can cost millions in fines, legal fees, and reputational damage. The DoD emphasizes this control to protect Controlled Unclassified Information (CUI) from insider threats and ensure accountability in defense contractor environments.
✅ How to Implement
- 1. Use role-based access control (RBAC) in AWS/Azure/GCP to define distinct roles for administrators, developers, and auditors.
- 2. Assign permissions based on job responsibilities (e.g., AWS IAM roles for 'Read-Only Access' vs. 'Full Access').
- 3. Enable multi-factor authentication (MFA) for privileged accounts.
- 4. Implement logging and monitoring (e.g., AWS CloudTrail, Azure Monitor) to track changes made by different roles.
- 5. Regularly review and update role assignments to ensure separation of duties is maintained.
📋 Evidence Examples
Role Definitions
Access Logs
Policy Document
Training Records
Audit Report
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For AC.L2-3.1.4 ("Separate the duties of individuals to reduce the risk of malevolent activity"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how access to CUI systems is controlled, including the specific IAM tools, policies, and processes used. Reference your Access Control Policy and identify the systems in scope. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"AC.L2-3.1.4 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to separate the duties of individuals to reduce the risk of malevolent activity. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"AC.L2-3.1.4 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to separate the duties of individuals to reduce the risk of malevolent activity. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"AC.L2-3.1.4 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all access points to CUI systems (VPN, direct network, cloud portals)
- • Document which IAM system manages access (Azure AD, AWS IAM, on-prem AD)
- • Map user roles to system access levels
- • Ensure this control covers all systems within your defined CUI boundary where separate the duties of individuals to reduce the risk of malevolent activity applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Access Control Policy
- 📄 IAM configuration documentation
- 📄 Access request and approval records
- 📄 Evidence artifacts specific to AC.L2-3.1.4
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will verify that access controls are implemented as described, test whether unauthorized users are blocked, and review access logs for evidence of enforcement.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Have you defined distinct roles for administrators, developers, and auditors?
Question 2: Do you have logging enabled to track role-based activities?
Question 3: Do you conduct periodic access reviews?
Question 4: Is there a written policy outlining separation of duties?
Question 5: Have employees been trained on separation of duties?
⚠️ Common Mistakes (What Auditors Flag)
1. Overlapping roles
2. Insufficient logging
3. Lack of policy documentation
4. Inadequate training
5. Failure to conduct access reviews
📚 Parent Policy
This practice is governed by the Access Control Policy