FutureFeed CMMC Education Series · Access Control
Access Control (AC): 3.1.4
One person should never be able to quietly approve their own access, pay their own invoice, or hide their own actions. That’s exactly what separation of duties is designed to prevent.
The short version
If you’re responsible for CMMC compliance, here’s what this requirement comes down to. You need to:
- Find the sensitive tasks where one person doing everything would be risky
- Split those tasks so it takes more than one person (for example, request versus approve, create versus review)
- Bring managers and process owners in to decide who does what, not just IT
- Write down the split duties and keep records showing they’re followed
If you already have those things and can prove them, you’re well on your way. Now let’s talk about what each one actually looks like.
In plain English
Separation of duties means no single person controls a sensitive process from start to finish. You split the steps so it takes more than one person, which means a mistake, or a bad actor, can’t go unchecked.
It exists because organizations don’t fail only from outside attackers. They also fail when one trusted person has enough authority to make a change, approve it, and hide their actions. Splitting responsibilities makes fraud, mistakes, and malicious activity much harder to pull off without someone noticing.
This is the part IT can’t do for you. IT can give two people different accounts, but only the business can decide which duties need to be kept apart. That’s what makes this one of the most important, and most overlooked, controls in the whole standard. It’s less about technology and more about how you organize the work.
A few classic splits:
- The person who requests access isn’t the one who approves it.
- The person who enters a payment isn’t the one who releases it.
- The person who manages your security settings isn’t the same person who reviews the logs.
No one person should control a sensitive process from start to finish. That’s the whole idea.
Who owns what
The decisions belong to the business. The enforcement belongs to IT. It helps to see the split side by side:
| The business decides | IT implements |
|---|---|
| Which duties must be separated | Configures technical controls to enforce the separation |
| Who can approve requests | Configures approval workflows |
| Which processes are sensitive | Implements and enforces technical controls |
| Who reviews exceptions | Maintains the technical controls |
| How oversight is documented | Produces the audit evidence |
Swipe sideways to see the full table.
Take granting access. One person requests it, a different person approves it, and IT actually turns it on. No single person can quietly give themselves the keys. Payments work the same way: whoever enters an invoice can’t also approve and release the payment. Those splits didn’t come from IT. A manager or process owner decided these steps were risky enough to require a second set of hands.
What you need to have in place
To be compliant, each of those boxes needs to be real and repeatable:
- A list of the sensitive processes where one person doing everything is risky, such as granting access, releasing payments, making admin changes, and administering security versus reviewing the logs.
- Those duties divided across different people, with the split decided by the business, not assumed by IT.
- Management and process owners involved in deciding who is responsible for each step.
- A documented second check where full separation isn’t practical. On a small team, that’s often a management review, so no one acts entirely unchecked.
- Records of who owns each step, and evidence the split is actually followed.
The objective is to reduce the likelihood that one person, acting alone, can intentionally or accidentally cause significant harm without independent oversight.
A new stop every Tuesday and Thursday.
Our twice-weekly series breaking CMMC down one step at a time. Opt in and we’ll send each one to your inbox.
What you need to prove it
Think in three buckets. An assessor will want all three, so it helps to build them at the same time.
People
- Leadership and process owners who decide which duties must be separated (this is the part that isn’t IT’s to decide)
- Managers who carry out the approval or review steps
- IT, who implements the technical side with separate accounts and permissions
Tools
- Your identity system, to keep request, approve, and perform in different hands
- Workflow or ticketing that records who did each step
- Somewhere the duty definitions are kept
Documents
- A written description of the separated duties: who requests, who approves, who performs
- For small teams, the documented second check or management review
- Records showing the separation happened, like an approval made by a different person, with dates
- A note in your System Security Plan (SSP) describing the separated duties
Many organizations document these responsibilities in a Governance, Risk, and Compliance (GRC) platform, which lets them assign duty ownership, keep approval records, and show an assessor that separation of duties is consistently enforced.
When should I work on this
Start this early, and bring the business in from the beginning, because IT can’t define it alone. This discussion should happen before technical implementation begins, so the business decisions drive how the control is enforced. Separation of duties shapes the rest of your Access Control work: who approves access, who holds admin rights, who reviews the logs. It’s easy to skip because no single tool “does” it, and that’s exactly why it slips through the cracks. The sooner leadership decides which duties have to be split, the cleaner every later control becomes.
Common challenges
It’s treated as an IT problem.
Why it happens: Teams assume a tool will handle it, but separation is about how the business divides its work.
Recommendation: Get managers and process owners to define who does which step; IT enforces the split afterward.
One person controls an entire sensitive process.
Why it happens: Convenience, or a small team where the same person requests, approves, and performs the work.
Recommendation: Split the steps. Where the team is too small, document a management review so no one acts fully unchecked.
The separation happens but isn’t written down.
Why it happens: “Everyone knows” who approves what, but there’s no record an assessor can look at.
Recommendation: Document the split duties and keep evidence, like approvals made by a different person, with dates.
What good looks like
A compliant contractor can usually answer yes to all of these:
- Have you identified the sensitive processes where one person shouldn’t do everything?
- Are those duties split so no single person completes a sensitive process alone?
- Did the business, not just IT, decide which duties to separate?
- Can you show records that the separation is actually followed?
In a mature organization, managers, not IT, identify which business processes require separation. IT implements technical controls that enforce those decisions, approvals are documented, and evidence shows different people performed each step. That’s exactly what an assessor wants to see.
If any answer is no, that’s your next place to start.
The biggest mistake organizations make is assuming IT owns this control. They don’t. Separation of duties is a business decision about how work is divided, and it needs managers and process owners at the table. The requirement is to separate duties so one person can’t cause harm acting alone; it doesn’t hand you a fixed list of duties to split. You decide which processes are sensitive enough, and if your team is too small for a clean split, document how a second person still reviews the work.
How this connects to other controls
This control doesn’t stand alone. A few close relationships:
- Least privilege (3.1.2, 3.1.5): least privilege limits how much any one person can do; separation of duties splits who does what. Together they keep power from concentrating in a single person.
- Audit & Accountability: your logs are where you show different people performed the separated steps, and separation keeps whoever administers security from also controlling the audit trail.
- Personnel Security: separation depends on clearly defined roles and knowing who is responsible for each step.
Separation of duties begins with a business decision. Technology simply enforces it.
The requirement, word for word
For your reference, here’s the exact language so you’re working from the source and not a paraphrase:
Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
Every organization implements these controls a little differently. If you’re not sure whether your approach would satisfy an assessor, join one of our upcoming webinars or schedule a 15 Minutes with FutureFeed session. We’d rather answer your questions now than have you discover them during an assessment.
CMMC: Everything You Need to Know to Get Started (6th Edition)
Want the full compliance framework and the funding resources available to defense contractors? Our guide has it.
Sources
- NIST SP 800-171 Rev 2, Access Control (3.1)
- Related requirements: see also 3.1.2 (limit transactions and functions), 3.1.5 (least privilege), and 3.3.1 (audit logging) within NIST SP 800-171 Rev 2.
