Rewrite: segregation-of-duties-for-cmmc-practical-reality-for-small-contractors

Word count: ~1,800

Specificity markers hit (4/5):

1. ✅ NIST/CMMC control references — AC.L2-3.1.5, AC.L2-3.1.6, AC.L2-3.1.7, AU.L2-3.3.3, CM.L2-3.4.5, PS.L2-3.9.1
2. ✅ Cost/time estimate — RBAC implementation 20–40 hours; external assessor review $5K–$15K
3. ✅ Tool/product name — Active Directory, Azure AD, CyberArk, Microsoft Privileged Identity Management
4. ✅ Common mistake — Giving IT admins access to audit logs they generate; same person doing security and audit
5. ✅ Decision point with guidance — Compensating controls when full SoD isn't feasible

---

Segregation of duties is a standard audit concept: no single person should control all phases of a critical process. In defense contracting, it's the principle behind requirements like "the person who authorizes changes shouldn't also be the person who implements them" and "the person who has admin access to a system shouldn't also be the only one who reviews that system's logs."

CMMC Level 2 doesn't use the phrase "segregation of duties" as a standalone control, but the concept is embedded throughout the framework — in access control requirements, audit log protection, change management, and personnel security. For larger organizations with mature IT departments, implementing SoD is standard practice. For small contractors with IT teams of two or three people, it requires deliberate design and sometimes compensating controls.

Here's what the standard requires and how to implement it when you don't have the headcount for perfect role separation.

Where SoD Lives in NIST 800-171

The clearest SoD requirements in CMMC Level 2 appear in these controls:

AC.L2-3.1.5 — Employ the principle of least privilege, including for specific security functions and privileged accounts. People have access only to what they need for their job function.

AC.L2-3.1.6 — Use non-privileged accounts when accessing non-security functions. Your IT administrator has a regular user account for day-to-day work and a separate admin account for administrative functions. They don't surf the web, check personal email, or do general work while logged in as admin.

AC.L2-3.1.7 — Prevent non-privileged users from executing privileged functions. Standard users can't install software, modify security configurations, or change firewall rules.

AU.L2-3.3.3 — Review and update logged events. The requirement to review logs implies someone other than the person generating the logs should be reviewing them — or at minimum, that log reviews are supervised.

CM.L2-3.4.5 — Define, document, approve, and implement changes to organizational systems. The change management process should separate the person requesting a change from the person approving it. The person implementing the change shouldn't also be the person verifying it.

PS.L2-3.9.1 — Screen individuals prior to authorizing access to organizational systems. Personnel security is the organizational layer that prevents insider threats — it works alongside SoD by ensuring the people in sensitive roles are vetted appropriately.

Together, these controls create a picture of role separation: people should have defined, limited functions; technical controls should enforce those limits; and oversight functions should be independent of the functions they're overseeing.

The Small Contractor Reality

A 50-person defense contractor might have one IT administrator and a part-time IT consultant. The IT administrator deploys systems, manages user accounts, configures firewalls, maintains backups, and troubleshoots daily problems. They also manage access controls and generate the audit logs that are supposed to monitor their own activity.

That's an SoD gap. The same person who can modify access controls can also remove evidence of having done so. The same person who manages the backup system could theoretically tamper with backups containing evidence of a security incident.

CMMC assessors understand this reality. The goal isn't to manufacture headcount you don't have — it's to put compensating controls in place that reduce the risk the SoD gap creates.

The Four Role Separations That Matter Most

Not all SoD gaps are equally risky. Focus on these four:

1. Audit log management vs. system administration

Your IT admin manages systems that generate audit logs. They should not also be the sole person who controls where logs are stored and who can access them. The risk: an admin who wants to cover their tracks can modify or delete logs they control.

The fix: route logs to a centralized SIEM or log management server that the IT admin cannot modify unilaterally. Microsoft Sentinel, Splunk, or even a dedicated log aggregation server where access is controlled by leadership or a secondary person. Implement log integrity controls (AU.L2-3.3.9) so any modification is detectable. Have someone outside IT — a manager, security officer, or external party — receive a weekly summary of log alerts.

2. Security configuration vs. security review

The person who configures firewall rules and access policies shouldn't also be the only person who reviews whether those configurations are correct. This is where even a small organization can get into trouble: if the IT admin sets a policy and the IT admin reviews it, there's no independent check.

The fix: involve a second person in periodic configuration reviews. This doesn't require a dedicated security staff member — a manager who reviews a monthly configuration summary, or an external consultant who does a quarterly review ($5,000–$15,000 annually for most small organizations), provides enough independent oversight to address the control intent.

3. Change authorization vs. change implementation

Someone should approve changes to CUI systems before they're implemented — and that someone shouldn't be the same person implementing the change for anything other than routine, pre-approved maintenance.

The fix: define a change management process with a documented approval step. For a small team, this can be as simple as an email approval from a manager before significant changes (new software installs, firewall rule changes, access grants) are implemented. Document the request, the approval, and the implementation. Keep these records as evidence for CM.L2-3.4.5.

4. Account creation vs. account approval

Your IT admin creates user accounts. But someone outside IT should be authorizing who gets access and at what privilege level. The risk: an admin can create unauthorized accounts or escalate privileges without detection.

The fix: implement a documented access request and approval process. Access requests go to a manager or supervisor for approval before the IT admin creates the account. Keep access request tickets or emails as evidence. Conduct access reviews quarterly — a manager reviews a list of who has access to CUI systems and confirms they still need it.

Technical Controls That Substitute for Headcount

When you can't separate duties with personnel, separate them with technology:

Privileged Identity Management: Microsoft Privileged Identity Management (PIM) in Azure AD provides just-in-time admin access — your IT admin requests elevated privileges for a specific task, the elevation is time-limited, and all privileged actions are logged separately from normal activity. This doesn't eliminate the SoD gap, but it creates visibility into privileged action that compensating control reviewers can see.

Role-Based Access Control (RBAC): In Active Directory or Azure AD, define distinct roles with the minimum permissions needed for each function. Your IT admin's day-to-day account shouldn't have Domain Admin rights — those should be in a separate admin account used only for admin tasks (AC.L2-3.1.6).

Privileged Access Workstations (PAWs): Admin activities are performed only from designated, hardened workstations — not from general-use machines. This limits the exposure when an admin account is active and reduces the risk of credential theft from a compromised general-use endpoint.

CyberArk or similar PAM tools: Privileged Access Management (PAM) platforms manage admin credentials, record admin sessions, and alert on anomalous privileged activity. Overkill for very small organizations, but appropriate if you have more than two or three IT administrators.

Common Mistake: Treating SoD as Paperwork

The most common error small contractors make with SoD is treating it as a documentation exercise. They write policies that describe role separation, but the technical access controls don't enforce it. The IT admin account still has rights to modify audit logs. The change management policy exists in a document nobody uses.

Your assessor won't just read your policies. Under AC.L2-3.1.5, they'll look at actual account configurations and verify that least privilege is enforced technically, not just stated in policy. They'll ask your IT admin to show them their own account permissions. They'll test whether a standard user can install software or modify security settings. Policies that describe controls that don't exist are worse than no policies — they indicate either deception or negligence.

Document what you actually do, then make what you actually do good enough. That's a better strategy than documenting aspirational practices.

What Your Assessor Expects

Assessors evaluating SoD-related controls at a small contractor will look for:

• Documented roles with defined privileges — not just job titles, but actual access levels
• Separate admin and user accounts for IT personnel (AC.L2-3.1.6)
• Evidence that account creation requires documented approval from someone outside IT
• Log management configuration that prevents the IT admin from unilaterally modifying log retention
• A change management process with approval records, even if minimal
• Evidence of periodic access reviews — a quarterly sign-off from managers confirming current access lists are appropriate

They understand that a 10-person IT function can't achieve the same separation as a 500-person organization. What they're looking for is evidence that you've thought about the risk, put controls in place that reduce it, and can demonstrate those controls work.

If you have an SoD gap you can't close with current staffing, document it as a risk in your POA&M, describe the compensating controls in place, and show your timeline for improvement. Acknowledging and managing risk honestly is more credible than pretending the gap doesn't exist.

---

Starting your SoD implementation? Map your IT admin's current access first — list every system they have elevated rights to, then identify which of those need oversight from a second person.