This is one of the most misunderstood practices for small defense contractors. When a company has 15 people and the owner wears six hats, “separation of duties” sounds like something written for a 5,000-person agency. It wasn’t. The assessor knows your team is small. They’re not expecting you to have separate departments for every function. They’re checking whether you’ve thought about where a single person could cause real damage and put at least one check in place. This practice works hand-in-hand with AC.L2-3.1.5 (least privilege) and AC.L2-3.1.1 (authorized access), since who has access and how much directly shapes whether duties are actually separated. Strong role-based access control from AC.L2-3.1.2 also enables enforcement of this practice.
What the assessor is actually evaluating
The NIST language says “separate the duties of individuals to reduce the risk of malevolent activity without collusion.” In the room, this comes down to two questions:
Have you identified where separation matters? The assessor wants to see that you’ve looked at your critical functions and identified the ones where a single person acting alone could cause serious harm. For most small contractors, the high-risk areas are: creating and approving user accounts, managing and auditing financial transactions, administering and reviewing security logs, and handling CUI access decisions. The assessor isn’t going to hand you a checklist of duties to separate. They want to see that you identified the ones that matter in your environment.
Do you have a check in place for each one? True separation means two different people handle two halves of a critical process. In a 15-person shop, that’s not always possible. The assessor accepts compensating controls: the same person might do both halves, but someone else reviews the work on a defined schedule. The key is that the review actually happens and is documented.
What the assessor is really looking for is evidence that you haven’t just handed one person the keys to everything with no oversight. If your IT admin can create accounts, assign permissions, and review their own audit logs with nobody else ever looking at any of it, that’s the kind of gap this practice exists to catch.
What a realistic SSP definition looks like
[Organization Name] separates duties for critical security functions to prevent any single individual from completing a high-risk action without oversight. The organization has identified the following critical functions requiring separation or compensating controls:
1. User account management: Access requests are submitted by the employee's manager. The IT Director provisions the access. The Operations Manager reviews the user access list quarterly to verify appropriateness.
2. Audit log review: The IT Director configures and maintains logging systems. Log review is performed by [MSSP / a designated security reviewer] who does not have administrative access to modify log configurations.
3. System changes: Configuration changes are requested through the change management process and require approval from the IT Director or designee before implementation. Changes are reviewed for security impact post-implementation.
Where full separation of duties is not feasible due to organizational size, compensating controls are documented and include periodic review by a second party at least quarterly. Compensating controls are noted in the duty separation matrix maintained by the IT Director.
Notice what this SSP does. It doesn’t pretend to be a large organization with separate teams for everything. It names the specific critical functions, explains how they’re separated (or compensated), and identifies who does what. The assessor reads this and immediately understands how your organization handles the control. No ambiguity.
The phrase “where full separation is not feasible due to organizational size” is important. It tells the assessor you know full separation is the ideal and you’ve made a deliberate decision about where compensating controls are necessary. That framing is far better than just not mentioning the areas where you can’t fully separate duties.
How to present your evidence
- Duty separation matrix identifying critical functions and responsible individuals
- Documented compensating controls where full separation isn't feasible
- Evidence of review activities (access reviews, log reviews, change approvals)
- Organizational chart or role descriptions showing reporting relationships
- Tickets or records showing approval workflows (access requests, change requests)
The single strongest piece of evidence for this practice is a duty separation matrix. It doesn’t need to be complicated. A table that lists each critical function, who performs it, who reviews or approves it, and how often the review happens. If the same person performs and reviews, note the compensating control.
Have your access request tickets ready to show the approval workflow in action. The assessor may ask to see a recent example of someone requesting access and a different person approving it. If you can pull up a ticket that shows the request, the approval, and the provisioning as distinct steps by distinct people, you’ve demonstrated separation in practice.
For audit log review, be ready to show that the person reviewing logs is not the same person who configures the logging infrastructure. If your MSSP handles log review, this separation happens naturally. Have a sample log review report ready.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
"We're too small for separation of duties." This is the most common response I hear, and it's the wrong one. You're never too small to have one person review another person's work on critical functions. Even two people can establish a basic check. The assessor isn't expecting separate departments. They're expecting oversight.
The IT admin reviews their own work. If the same person creates accounts, assigns permissions, configures security settings, and reviews the logs that record all of those actions, you have zero separation. This is a finding. The fix is straightforward: have someone else review the access list periodically, and have someone else (or an MSSP) review the security logs.
No documentation of compensating controls. You might actually have decent separation in practice, but if your SSP doesn't call out where you use compensating controls and what those controls are, the assessor has to take your word for it. Write it down.
Confusing separation of duties with least privilege. They're related but different. Least privilege (AC.L2-3.1.5) limits what a person CAN do. Separation of duties ensures that no one person DOES everything in a critical process. You need both.
A duty separation matrix that shows you've thought about where the risks are. Compensating controls documented for areas where full separation isn't practical. Evidence that reviews actually happen. An honest acknowledgment of your size constraints paired with deliberate controls to address them. When the assessor sees that level of self-awareness, they're satisfied.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
An MSP or MSSP naturally creates separation of duties in several areas, and this is one of the practices where having one is a real advantage.
When the MSSP manages your security tools and reviews your logs, and a different person inside your organization manages user access decisions, you have genuine separation. The MSSP performs technical security functions. Your internal team handles business access decisions. Neither side can complete the entire chain alone.
The assessor will want to understand the split clearly. Who on the MSSP side does what? Who on your side approves what? The responsibility matrix you should have from AC.L2-3.1.1 can serve double duty here. If it shows that account provisioning, log review, and security configuration are handled by different parties with defined handoffs, you’ve demonstrated separation.
The MSSP should be ready to explain their internal separation as well. If one person on the MSSP team both configures your security tools and reviews the alerts those tools generate, the assessor may ask about that. A mature MSSP has separation built into their own operations: the engineer who configures doesn’t review their own work.
Assessors expect you to have a thoughtful answer about where separation matters in your organization. A simple matrix is enough. You don't have to have perfectly separated departments, but you do need to show you've identified the critical functions and put checks in place. If you can't explain how someone's work gets reviewed, expect pushback. The word "compensating control" is your friend. Use it when full separation isn't practical, and document it in your SSP.
Ask your MSSP how they handle separation of duties internally for your account. The best ones I've worked with can explain it in thirty seconds: "Engineer A configures, Analyst B reviews, and the SOC manager audits both." If your MSP can't articulate that, it's worth a conversation before you're sitting in front of an assessor.
This page covers AC.L2-3.1.4 from NIST SP 800-171 Rev 2 (3.1.4). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.