AC.L2-3.1.4 Separation of duties: requirements and evidence

What AC.L2-3.1.4 separation of duties asks for in a CMMC assessment

If your organization is preparing for a CMMC Level 2 assessment, AC.L2-3.1.4 asks you to split critical duties across different people so that no single person can carry out a sensitive task from start to finish without someone else being involved. The requirement is the Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.1.4, and its purpose is to reduce the risk of malicious activity by insiders. The intent, as the CMMC Assessment Guide Level 2 puts it, is that no one person is in charge of an entire critical task from beginning to end. Your first job is to decide which duties in your environment are critical enough to separate, such as creating vendor payments and approving them, or writing a change and deploying it to production.

NIST SP 800-171A breaks the requirement into three assessment objectives. You must define the duties that require separation, assign those responsibilities to different individuals, and grant the access privileges for those duties to those individuals. An assessor will expect documented divisions of responsibility, system access authorizations and audit records as evidence, and will interview the people who defined the divisions and test the mechanisms that enforce them. Confirm the current version of the assessment objectives and the evidence expectations against the NIST SP 800-171A publication before you finalize your evidence list.

Separation is hard in small teams, where one administrator often holds the backup role, the approval role and the system administration role at once. In that case, document the conflicts you cannot remove, put compensating controls in place such as independent review of privileged activity logs, and record the decision in your system security plan. AC.L2-3.1.4 is worth 1 point under the scoring rules in 32 CFR 170.24, and it is not on the exclusion list in 32 CFR 170.21, so it can be placed on a plan of action and milestones if your score meets the Conditional Level 2 threshold. Treat that as a short-term allowance, not a plan, because the POA&M must be closed within the required window.

Which duties, systems and teams fall under separation of duties

Before any role is changed, the organization has to decide which critical duties exist inside the CUI environment and which systems and people carry them. The cards below cover the scoping decisions that determine how much work AC.L2-3.1.4 creates, and they follow the three assessment objectives in NIST SP 800-171A: defining the duties, assigning them to separate individuals, and granting matching access.

Paired critical duties

Start by listing the duties where one person acting alone could cause harm to CUI or to the mission. Typical pairs are request and approve, develop and deploy, provision and audit, and change a control and verify it. Each pair becomes a documented division of responsibility, and each duty in it needs a named owner. A duty left unpaired is a finding waiting to be written, so the list should be signed off by the system owner and the security lead, not assembled by one administrator.

Systems that hold the duties

Map each duty to the system where it is actually performed. This includes the CUI enclave, the identity provider, the ticketing or change system, CI/CD pipelines, logging platforms and backup consoles. A separation that exists in the ticketing tool but can be bypassed through a direct admin login on the server is not separated. Record every system where a duty can be executed, because assessors test the mechanism, not the policy.

Identity platforms and shared roles

Directory groups, role assignments and federated identities often grant more than their names suggest. Check whether one account can hold both a requester role and an approver role, whether a group nested inside another inherits both sets of rights, and whether service accounts can approve their own changes. Review these assignments in the identity platform itself, since a policy document will not show accumulated access.

Internal teams with privileged roles

Identify which internal teams hold administrative, security or audit privileges over CUI systems, and where the same people sit across more than one of them. Small teams often have one engineer who builds, deploys and reviews logs. In that case the separation may need compensating arrangements, such as a second reviewer outside the team, and the decision and its rationale should be documented before the assessment, not explained afterward.

Third-party administrators

Vendors, managed service providers and support engineers with administrative access to CUI systems are part of the duty map. Confirm which vendor staff can perform privileged actions, whether their access is time-limited and approved by an internal owner, and whether the vendor's own administrators can also approve changes. Contract terms and access records should show the same division. Ask the provider for evidence of its own internal separation rather than assuming it exists.

Managed service provider treatment

When a managed service provider runs part of the CUI environment, decide whether its personnel and tools fall inside the assessment boundary and how the division of duties is documented across both organizations. The organization remains responsible for the requirement, so responsibilities split between the two parties should be written down in the system security plan. Confirm this scope with the assessor early, because the answer changes which accounts and approval records must be produced.

How an assessor tests separation of duties

This table walks through the three assessment objectives in NIST SP 800-171A for AC.L2-3.1.4 and shows what an assessor asks, examines and interviews for each one. Read it as a checklist for preparing evidence: each row names a step, what the assessor looks for, and where organizations commonly fall short.

Assessment step	What the assessor confirms	Evidence and common findings
Define the duties	The organization has identified which duties must be separated, such as request and approve, develop and deploy, or configure and audit	Documented divisions of responsibility; finding: critical duties never written down or listed only in informal notes
Assign duties to separate individuals	No single person is assigned conflicting duties from the defined list, and assignments match the documented divisions	Role or responsibility matrix and assignment records; finding: one administrator holds both approval and execution roles
Grant access privileges	Accounts and permissions for each separated duty are granted to different individuals, with no account holding the combined rights	System access authorizations and role assignments; finding: a broad admin role grants conflicting rights not reflected in the duty matrix
Interview duty definers	Assessors ask the people who define divisions how they chose the separations and how they handle exceptions	Interview notes; finding: owners cannot explain why a separation exists or who approves exceptions
Test the mechanisms	Assessors examine the systems that enforce separation, such as workflow approvals, role configurations and ticketing controls	Configuration exports and test walkthroughs; finding: approval workflow can be bypassed by the requester
Review audit records	Logs show that separated duties were performed by different people, and conflicts are detected	Audit records of approvals and changes; finding: no record of who approved a change, or logs are not reviewed
Handle collusion risk	The organization accepts that the control reduces risk without collusion, and compensating checks exist where few people are available	Compensating review procedures; finding: small teams with no documented alternate reviewer for critical changes

How to implement separation of duties step by step

This sequence turns the intent of AC.L2-3.1.4 into a documented, enforced and reviewed set of divided duties, so an assessor can see that no single person controls a critical task from start to finish. Each step produces an artifact that the next step depends on.

Identify and document critical duties
Start by listing the business and system tasks that carry meaningful risk if one person performs them alone, such as approving payments, creating and approving user accounts, changing production configurations, or releasing CUI-handling software. Record each duty in the system security plan or a supporting procedure, with its owner and the systems it touches. The output is a duty register that names each critical duty and the reason it needs separation.
Map conflicting duty combinations
For each duty in the register, identify which other duties would give one person the ability to complete a malicious or error-prone task end to end. Document these conflicting combinations in a matrix, such as requesting and approving the same access, or developing and deploying the same change. The output is a conflict matrix that the people who define the divisions of responsibility have reviewed and approved in writing.
Assign duties to separate individuals
Assign each side of every conflicting combination to a different person, and record those assignments in role descriptions or a responsibility matrix. Where the organization is too small for full separation, document the compensating controls, such as independent review by a second person, and state who performs them. The output is a signed or approved assignment record showing that no individual holds both sides of a conflict.
Grant access privileges matched to each duty
Translate each assignment into system access. Create roles or groups that reflect a single duty, grant only the permissions that duty needs, and confirm that no account or group carries permissions from two conflicting duties. Coordinate this step with the authorized access and least privilege requirements so that the privilege design is consistent. The output is a role-to-permission map with the account lists attached.
Enforce conflicts in the identity system
Configure the identity provider or directory so that conflicting roles cannot be assigned to the same identity at the same time, and make the platform reject or flag any request that would do so. Where the platform does not enforce conflicts natively, use an approval workflow or an access governance tool and confirm its capability with the vendor before relying on it. The output is a configuration export or test record showing that a conflicting assignment is blocked or routed for review.
Test the separation with evidence
Run a test that attempts to assign conflicting duties to one account and to perform a full duty sequence with a single user, and record the results. Collect audit records showing who requested, approved and executed each step. Assessors interview the people who defined the divisions and test the mechanisms, so keep the test scripts, results and interview notes together. The output is a dated test report with logs that show the separation held.
Set a recurring review of duties and access
Schedule periodic reviews in which designated reviewers confirm, change or revoke each role assignment and each conflict exception. Reviews catch access that accumulates when people change jobs and roles are added without updating the matrix. Record the reviewer, the decision and the follow-up for each item, and feed changes back into the duty register and role map. The output is a review record that shows the separation is still in effect, and it should be kept current for the assessment.

Why access accumulates and breaks separation over time

Separation of duties rarely fails on the day access is first granted. It fails later, when role assignments pile up as people change jobs. An engineer moves to operations and keeps the approval rights from the old role. A finance analyst covers for a colleague on leave and never loses the temporary entitlement. Each change looks reasonable in isolation, but over several years one person may hold both the ability to create a payment or configuration change and the ability to approve it. Role accumulation is the most common way AC.L2-3.1.4 quietly stops being true.

Emergency access follows the same pattern. A break-glass account or an elevated role is granted for an incident, then never revoked because nobody owns the removal step. Small teams are especially exposed. When a company has three administrators, one person may end up in charge of an entire critical task from beginning to end, such as provisioning, approving and reconciling a system change. The CMMC Assessment Guide describes the intent of this requirement as making sure no one person is in charge of an entire critical task from beginning to end. Before an assessment, the practical question is which duties in your environment would look like that today, and whether you could name the compensating control if staffing makes full separation impossible. Confirm that answer with your assessor's expectations and your own risk owners, not only with an internal reading of the rule.

Periodic access certification is a common way to counter this drift. Designated reviewers decide within a set timeframe whether to keep, change or revoke each access item, such as a role assignment, so that stale or conflicting entitlements are removed on a schedule rather than when someone notices. The midPoint documentation on access certification describes this approach in an open-source identity governance platform, with campaigns that can be scoped to particular roles or resources. The reviewer decision is only useful if reviewers are chosen to be independent of the access they approve and if their decisions are recorded. Ask your identity team to show you the campaign definition, the reviewer list, the timeframe and the revocation records. Those artifacts are the evidence an assessor will want for the access drift this requirement is meant to prevent.

Evidence that passes separation of duties

Assessors test AC.L2-3.1.4 through documents, access records and configuration that show who defines the separated duties, who holds them and how the system enforces the split. Each artifact below answers one part of that test, and each must be in final form, not a draft, when the assessment happens.

Documented divisions of responsibility

This is the written list of duties that must be separated, such as requesting a payment and approving it, or writing code and promoting it to production. It should name each duty, the roles that perform it and the reason the two cannot sit with one person. Assessors use it to confirm the first objective, which is defining the duties that require separation. Check that it is approved by a named owner, dated, and reviewed when systems or staff roles change.

System access authorizations by role

Access authorizations map each role from the divisions document to the named individuals who hold it, and to the privileges granted for that role. This is the record that shows responsibilities were assigned to separate people. Export it from the identity provider or directory so the mapping reflects the live system, and confirm that no individual appears in two conflicting roles without a documented exception.

Audit records of role changes

Logs of role assignments, grants, removals and changes to privilege sets show how the separation was created and maintained over time. Assessors look for evidence that a conflicting role was not added quietly. Confirm that role-change events are captured with the actor, the target account, the time and the approver, and that these logs are retained and protected under your audit requirements.

Records of periodic access reviews

Access review records show that someone checked the role assignments on a schedule and decided whether each one should stay, change or be revoked. Access accumulates as people move between teams, so a review is what catches a single person drifting into two halves of a critical task. Keep the reviewer's name, the decision, the date and any revocations, and close each review campaign before the next one begins.

Configuration showing enforced conflicts

Some separations are enforced by the system rather than by policy alone, for example a workflow that blocks the requester from approving their own request, or a rule that refuses to assign two conflicting roles to the same account. Keep exported configuration, rule definitions and test results showing that the block works. Assessors may test the mechanism directly, so record the date you last tested it and the result.

Keeping evidence final and current

Assessors accept only evidence in final form, so every document needs an approval, a version and a date, and drafts do not count toward a MET result. Set a review cycle for the divisions document and access reviews, and refresh exports whenever roles change. Store each artifact in a controlled location with a change history, so you can show the state of the environment on the assessment date.

What meeting AC.L2-3.1.4 costs in money and effort

Most of the cost of AC.L2-3.1.4 is internal labor, not tooling. The requirement has three assessment objectives in NIST SP 800-171A: define the duties that need separation, assign them to different individuals, and grant the matching access privileges. The first of these is a design and documentation task. Someone with authority over the business process, usually a process owner working with the security lead, has to list the critical duties (for example, creating a vendor, approving that vendor's payment, and reconciling the ledger), decide which combinations must never sit with one person, and record the decision. That work is largely one-time, but it is revisited whenever a process changes, a team is reorganized or a new system holds CUI. Ask any consultant quoting the work to state whether the duty map and conflict matrix are included, how many business processes are in scope, and whether interviews with the people who own those processes are counted in the fee.

The identity and tooling work is where cost depends most on your environment. Separation has to be enforced in the systems that hold CUI, which usually means role design in the directory, separate administrator and user accounts, approval workflows and, in larger environments, an identity governance product that can detect conflicting entitlements. Open-source options such as midPoint can run access certification campaigns, in which designated reviewers decide within a set timeframe whether to keep, change or revoke role assignments, but the platform, its hosting, its integration with each application and its administration are all separate line items. Setup is largely one-time. Licensing or hosting, configuration changes after each application update and the staff who run the tool recur. Ask for the list of systems integrated, the approach for applications without an API, and who maintains the role model after handover.

The recurring cost is the access review and the evidence that proves it happened. Each review cycle requires someone to pull current entitlements, route them to reviewers, record decisions and close out revocations, and then retain the audit records that show who approved what and when. Costs rise with the number of roles, the number of CUI systems, staff turnover and how often reviews run. Assessors will look for final, dated evidence rather than drafts, so budget time for the review records and the documented division of responsibilities to stay current. Before accepting a quote, ask what is delivered as one-time work and what is a recurring service, what evidence package the consultant will prepare for the assessor, whether support during the assessment is included, and how changes to scope or new systems are priced. Confirm the current assessment timing and requirements with the Department of War and your contracting officer, since the CMMC schedule has changed.

Cost components for separation of duties

This table breaks down the costs of meeting AC.L2-3.1.4 into components, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a quote request, then compare vendor and consultant proposals line by line. The main takeaway is that role design and access certification recur every review cycle, so they deserve the same scrutiny as tooling licenses.

Cost component	One-time or recurring	What drives it and how to reduce it
Role and duty design	One-time, then revisited on change	Number of critical processes and staff roles. Reduce it by mapping only truly critical duties first and documenting the split in one reviewed matrix.
Identity platform configuration	One-time, with changes over time	Number of systems and approval workflows that must enforce separation. Reduce it by reusing existing directory groups and roles instead of building custom logic.
Licenses for identity and access tooling	Recurring	Commercial user counts and feature tiers for identity governance. Self-hosted open-source platforms can remove this license spend, but hosting and support still apply.
Engineering time	One-time build, then recurring maintenance	Integration depth with ticketing, HR and cloud accounts. Reduce it by agreeing a fixed scope and limiting integrations to systems that hold CUI.
Recurring access certification campaigns	Recurring	Number of reviewers, access items and review frequency set by the organization. Reduce it by scoping campaigns to privileged and conflicting roles and setting clear decision deadlines.
Evidence upkeep	Recurring	Volume of audit records, approvals and role change tickets retained. Reduce it by automating exports of role assignments and approvals into a single evidence location.
External review and auditor sampling	Recurring at each assessment	Assessor sample size, interview scope and whether evidence is in final form. Ask the assessor or certification body for its sampling approach before you prepare.
Independent assessment fees	Recurring at each assessment	Scope, number of systems and assessor availability. Only the authorized assessor sets this fee, so request its scope in writing and do not expect the implementation partner to issue findings.

Who does what for separation of duties

Your organization owns AC.L2-3.1.4 in full. Leadership and the people who run critical processes decide which duties must be separated, because only they know where a single person could complete a sensitive task alone. Those decisions then become signed documentation, role assignments and approval rules that your staff maintain after any outside help leaves. Assessors will interview the people who defined these divisions, so they must be able to explain the reasoning themselves.

Defining the duties: Identify critical tasks such as creating a vendor, approving a payment, changing production code and reviewing its own audit logs, then state which steps must sit with different people.
Assigning responsibilities: Name the individuals or roles for each step and record them in the system security plan or a separation of duties matrix.
Approving access: Authorize the privileges that match each role, and keep the approval records in final form.
Reviewing access: Run periodic access reviews where designated reviewers keep, change or revoke role assignments, so access does not accumulate over time.
Staying accountable: Own exceptions, such as small teams where separation is hard, and document compensating controls and their approval.

Before any assessment, confirm that each named owner can walk an assessor through the matrix and show the approval history behind it.

Where separation of duties usually fails an assessment

Assessors test AC.L2-3.1.4 by asking three things: whether critical duties are defined, whether different people hold them, and whether access matches. The gaps below break one or more of those checks, and each has a closing action you can start before an assessment window.

No written list of critical duties

Without a documented list of the duties that need separation, there is nothing for an assessor to test against. Teams often separate duties by habit, so the first objective of SP 800-171A, defining the duties that require separation, is not met. Start by listing critical tasks from request to completion, such as approving a payment, changing a production configuration or granting CUI access, and mark each pair of tasks that one person must not complete alone.

Shared administrator accounts

When several engineers sign in with one administrator account, the audit trail cannot show who did what, so separation of duties cannot be demonstrated even if the roles look right on paper. Assessors look for the link between a person, an assigned responsibility and a logged action. Replace shared accounts with named administrator accounts, and confirm that audit records identify the individual behind each privileged action.

Emergency access left permanent

Break-glass accounts created for an outage often stay enabled and hold broad rights long after the incident ends. Standing emergency access lets one person perform sensitive tasks without a second person involved, which undercuts the separation the requirement describes. Document who may use emergency access, under what conditions, and how use is approved and reviewed afterward, then disable the account between events.

Developers approving their own changes

If the person who writes a change can also approve and deploy it, one individual controls a critical task from beginning to end, which is the situation the assessment guide describes as the core concern. Check the repository and deployment settings to confirm that authors cannot approve their own merges and that production deployment requires a different identity. Record the exceptions and who granted them.

Access reviews that exist only as spreadsheets

A review spreadsheet with no date, no reviewer name and no record of changes shows that someone looked at access once, but it does not prove the decision was made by a designated reviewer within a set period. Assessors expect evidence that access was checked against the separation rules and that revocations happened. Move reviews into a system that records the reviewer, the decision, the timeframe and the change made, and keep the final version of each campaign.

Questions buyers ask about separation of duties

How much effort does separation of duties take to implement for CMMC Level 2?

The effort depends mostly on how many critical duties your business processes contain and how many people hold overlapping roles. AC.L2-3.1.4 has three assessment objectives in NIST SP 800-171A: define the duties that require separation, assign them to separate individuals, and grant the access privileges for those duties to separate individuals. Each objective produces its own evidence, so the work is more analytical than technical. Expect effort in four places:

Mapping critical workflows such as purchasing and payment approval, code change and deployment, or user account creation and approval
Reassigning roles and documenting the division of responsibilities
Adjusting access so one account cannot complete a whole sensitive task
Collecting evidence that the separation holds over time

Small organizations with few staff may find the conflicts harder to remove, because one person often covers several roles. Ask any partner to estimate effort from a written list of your critical duties.

How long does it take to get separation of duties in place?

Duration depends on the size of the system boundary, the number of workflows that need separation, and whether your identity platform already supports role-based access. Work usually moves in sequence: define duties, reassign people, change access, then gather evidence over a period long enough to show the control operating. No duration is fixed by the CMMC rule for this requirement, so treat any timeline as a planning assumption. Ask your implementation partner for a schedule that lists each deliverable and the client decisions it depends on, and confirm the window for collecting evidence before an assessment.

What does the work need from our team?

The work needs decisions from people who understand how the business actually operates, not only from IT. Expect to involve:

A business owner who can confirm which duties are critical and who should approve changes
System administrators who can explain current role assignments and grant or remove access
The people who define divisions of responsibility, since SP 800-171A assessors interview them
A compliance lead who keeps the evidence in final form

Assessors test the people who define the separation, so those people must be available and able to explain the decisions. Agree on these roles at the start of the engagement.

Can a small company handle separation of duties without outside help?

Yes, a small company can often do the design and documentation in-house, provided someone has authority to make role changes and time to collect evidence. The harder cases are organizations where one person must administer systems, approve purchases and review logs. In those cases, separation may need a second person or a compensating process, and that choice is a business decision. Outside help is most useful for mapping duties to access settings, testing whether a single account can complete a sensitive task end to end, and preparing the evidence package. Your organization still owns the control, and only an independent assessor can issue a certification result.

Can an outside partner design the separation of duties roles for us?

Yes, an implementation partner can design the duty map, the role model and the access changes, and document them for your review. DeployOpen prepares systems, controls and evidence for compliance assessments, and it works under a written, fixed scope. The organization remains responsible for the decisions: which duties are critical, who holds each role, and whether the design fits operations. Ask the partner to show how each design choice maps to the three assessment objectives and what the client must approve before implementation starts.

Can the same partner that designs our controls also be our CMMC assessor?

No. The partner that prepares your systems and evidence cannot also issue your assessment result. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and self-assessments are performed by the organization itself. Independence is the reason for this separation: the party that built a control should not be the party that judges it. Check the assessor's authorization status directly on the CMMC program rule and ask any partner to confirm in writing that it will not assess its own work.

Can AC.L2-3.1.4 be placed on a POA&M instead of fixed before assessment?

Yes, under the rules as supplied, AC.L2-3.1.4 is a 1-point requirement that is not on the exclusion list in 32 CFR 170.21, so it may be placed on a plan of action and milestones for Conditional Level 2 status. Conditional status requires a score of at least 88 out of 110, and the POA&M closeout is due within 180 days. Do not treat this as a planning shortcut. Conditional status depends on the total score and on the other requirements, and the Department of War suspended CMMC Phase II in July 2026, so confirm the current rules with your contracting officer and the official eCFR text before relying on any POA&M.

How DeployOpen scopes and prepares separation of duties evidence

DeployOpen starts every separation of duties engagement with a written, fixed scope that names the systems in the CUI boundary, the critical duties to be separated and the people who will be interviewed. The scope document should list each duty as the organization defines it, such as system administration of the identity provider, approval of privileged role grants, change approval for production, and review of audit logs, together with the named owner of each duty. Because the assessment objectives for 3.1.4 require the organization to define the duties that need separation before anything can be assigned, DeployOpen treats that definition as the first deliverable and asks the client to approve it before any configuration work begins. Pricing follows from this written scope, so the clearer the duty list and system boundary are at the start, the more predictable the quote.

Within the client's own cloud accounts, data center or air-gapped network, DeployOpen configures self-hosted open-source identity and access tooling so that the defined duties map to distinct roles. Typical work includes creating separate roles for requesting, approving and implementing a change, restricting which groups can grant the others, and recording role assignments and their history so they can be produced later. Where the client uses a platform such as midPoint, DeployOpen can set up access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke role assignments. The configuration needs to be confirmed against the specific product version and its documentation, and the client's security team should verify that the roles behave as designed in a test environment before production use.

DeployOpen then assembles a role model and an evidence pack for the assessor. The role model shows each duty, the role that performs it, the individuals assigned, and the privileges granted, with the approval record for each grant. The evidence pack gathers the documented divisions of responsibility, system access authorizations, audit records showing that conflicting actions were performed by different people, and configuration exports that demonstrate the enforced separation. DeployOpen supports the client through the assessment by preparing staff for interviews, answering technical questions and remediating gaps the client agrees to fix. DeployOpen prepares systems, controls and evidence but does not issue assessment reports or certifications. The independent assessor, a C3PAO or the appropriate assessing body, decides whether the objectives are met, and the client owns its controls and its Affirming Official's attestations.

AC.L2-3.1.4 Separation of duties