This post gives a practical, step-by-step approach to implementing NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control AC.L2-3.1.4 within your Compliance Framework — focusing on separation of duties, least privilege, and enforceable access controls that a small business can implement with existing identity and access management tools.
Understanding AC.L2-3.1.4 in the Compliance Framework context
AC.L2-3.1.4 requires separating duties of individuals to reduce the risk of malevolent activity without collusion and to ensure that critical operations cannot be completed by a single person. Within a Compliance Framework this means documenting roles, mapping who can perform sensitive actions (create/approve/deploy/transact), and applying technical controls (RBAC, PAM, workflow enforcement) so the policy is operationalized and auditable.
Step-by-step implementation
Step 1 — Scope systems, CUI locations, and role inventory
Start by scoping: identify systems that process or store CUI (file shares, cloud storage, SaaS apps, CI/CD systems, HR/finance). Create a role inventory that maps job titles to access needs; for small businesses this can be a spreadsheet with columns: role name, systems, tasks (read/write/delete/approve), and whether tasks are "sensitive" (e.g., create vendor + approve payment). Use this to feed your Compliance Framework's control implementation plan.
Step 2 — Define roles, privileges, and Separation-of-Duties (SoD) rules
For each role, define exactly what permissions are needed and what must be prevented. Build a simple SoD matrix (roles vs. sensitive tasks). Example: "Accounts Payable Clerk" can create a vendor record but cannot approve payments; "Finance Manager" can approve payments but cannot create vendor entries for themselves. Keep roles coarse enough to manage but fine-grained enough to prevent conflicts — typically 8–15 roles for a small firm instead of per-user ACLs.
Step 3 — Implement RBAC and technical enforcement
Map roles to groups in your IAM: Active Directory/Azure AD groups, Okta groups, or Google Workspace groups. Implement least privilege using group membership and deny/allow rules rather than per-user exceptions. For infrastructure, use AWS IAM roles with least privilege policies (example: use AssumeRole for admin tasks), create Azure RBAC custom roles if built-ins are too broad, and use database roles (Postgres roles or SQL Server schemas) rather than granting broad user accounts. Configure provisioning tooling (SCIM or automated scripts) so group membership is the single source of truth for access.
Step 4 — Control privileged access and enforce dual control
For privileged operations, implement Privileged Access Management (PAM) or manual dual-control workflows. Options for small business: require approvals in ServiceNow/Jira/Trello before executing production changes; use GitHub/GitLab protected branches and required code reviews for deploys; use an approval step in CI/CD (e.g., GitHub Actions manual approval) so the developer cannot both write and deploy the same change. For admin accounts, use just-in-time (JIT) elevation (Azure AD PIM or AWS IAM Access Analyzer + STS) or break up capabilities across accounts (separate admin account for daily email vs. cloud admin). Enforce MFA for all privileged accounts and make passwords non-shared.
Step 5 — Provisioning/deprovisioning, attestations, and periodic review
Integrate role assignments into HR/onboarding and offboarding processes. Automate provisioning with SCIM or PowerShell/Cloud formation templates where possible; ensure termination triggers immediate removal of group membership and federated access. Schedule quarterly access reviews where managers attest to each user's role and access; store attestations in the Compliance Framework evidence repository. Log changes to group membership (Azure AD audit logs, AD replication logs, CloudTrail) for audit and investigation.
Real-world examples and scenarios for a small business
Example 1 — Small defense subcontractor with 25 employees: create roles (Engineer, QA, DevOps, Program Manager, Finance). Use Azure AD groups to enforce file share permissions: Engineers can read/write in secure project file share but cannot approve release packages; DevOps can deploy from CI/CD but requires a Program Manager approval in the pipeline for production deploys. Example 2 — SaaS startup processing CUI: set GitHub teams so developers can open PRs but only "Release Engineers" (a separate team) can merge to main; use HashiCorp Vault with approver workflows for handing out production database credentials.
Technical configuration examples and tips
Practical technical details: name groups with a convention (e.g., project-role-env: projX-dev-prod), use least-privilege IAM policy snippets (AWS: deny iam:* to non-admin roles; allow s3:GetObject only to specified bucket ARNs), and set up logging: enable CloudTrail, Azure AD Activity Logs, and SFTP/file-server audit. For Linux servers, use sudoers to restrict root commands (e.g., Cmnd_Alias DEPLOY = /usr/bin/deploy_script; %deployers ALL=(ALL) NOPASSWD: DEPLOY). For databases, create roles like db_developer (CREATE TEMP, SELECT) vs db_admin (CREATE, DROP) and never use shared "admin" credentials.
Risks of non-implementation and compliance tips
If you fail to separate duties, a single compromised or malicious user can alter, exfiltrate, or delete CUI, sign fraudulent contracts, or approve payments — risks include data breach notifications, loss of DoD contracts, financial loss, and reputational damage. Compliance tips: keep SoD matrices current, automate what you can, treat evidence collection as part of daily ops (not an audit scramble), and prioritize controls that reduce blast radius (segmentation, JIT admin, MFA).
Best practices and closing summary
Best practices: start small, enforce policy with technical controls, remove standing privileges, and require explicit approvals for critical actions. Use role-based groups as the single source of truth, instrument logging and alerting, and run quarterly SoD reviews. For small businesses, pragmatic choices (GitHub protected branches, Azure AD groups, simple PAM tools, and documented approval workflows) achieve AC.L2-3.1.4 without expensive enterprise suites.
Summary: AC.L2-3.1.4 is about preventing concentration of privilege and ensuring critical tasks require separation or dual control; by scoping CUI, defining roles and SoD, implementing RBAC and PAM, integrating provisioning with HR, and maintaining logs and attestations, small organizations can meet the requirement within a practical Compliance Framework while reducing insider and operational risk.
