AC-5 Separation of duties: requirements and evidence

What AC-5 separation of duties requires and why assessors focus on role assignments

If you are preparing a moderate or high baseline system for assessment, AC-5 asks your organization to identify and document the duties that must be kept apart and to define system access authorizations that support that split. The control is selected in the moderate and high baselines of SP 800-53B Release 5.2.0 but not in the privacy baseline, so it will be examined in most of the systems you are preparing. Its purpose is to reduce the risk that one person can carry out a sensitive process from start to finish and misuse privileges without another person having to take part. Collusion remains possible, so the control does not promise perfect protection, but it removes the single point where one individual could approve, execute and conceal the same action alone.

AC-5 has no control enhancements in Release 5.2.0, which means the entire requirement sits in the base control and its assessment procedure. SP 800-53A Rev. 5 breaks that procedure into two determination statements, assessed through examination, interview and testing. Assessors will ask for your list of divisions of responsibility and separation of duties, the system access authorizations that implement it, and system audit records showing whether those rules are followed in practice. They will interview the people who define the splits and the system and network administrators who configure access, and they may test the mechanisms that enforce the policy. Confirm your baseline selection and the exact determination statement wording in CPRT before you build your evidence list.

The control is hard to keep true because role assignments accumulate. People change teams, temporary projects grant extra access that is never removed, and groups are nested so that a user inherits rights no one reviewed. Over time a role that was separated on paper can end up combined in one identity. For that reason assessors focus on role assignments rather than on the policy document alone. Plan a recurring review that compares current assignments against your documented separations, and decide who has the authority to revoke conflicting access. Open-source access certification tools such as midPoint's access certification campaigns can route those reviews to designated reviewers, who decide whether to keep, change or revoke each item within a set timeframe. Confirm with your own environment which identity systems hold the role data you will need.

Which systems, roles and third parties AC-5 covers in your environment

AC-5 applies where the system impact level calls for the moderate or high baseline, and it is not selected in the privacy baseline. Within those systems, the scope includes the people who can grant access as well as the people who use it, so the cards below cover both sides of each split.

Privileged administration roles

Administrators who can create accounts, change permissions and alter production settings are the most common place where one person holds conflicting duties. Map which administrative functions a single role can perform end to end, such as requesting, approving and executing a privileged change. Ask whether an operator who deploys code can also approve the deployment or edit its audit trail. Each combination you find is a candidate for a documented split.

Business approval workflows

Payment release, change approval and vendor onboarding all depend on one person initiating a request and another approving it. Identify each workflow where the requester, approver and system operator must be different people, and record which application roles carry each step. Check that the approval role cannot be self-assigned and that a user cannot approve their own request in the application, not only by policy.

Identity and directory platforms

The identity provider and directory decide who holds which group membership, so they are where access authorizations are defined. Confirm which administrators can change group membership, create users and modify directory policy, and whether those duties sit with different people. Assessors commonly examine how the directory's delegated administration is configured and who holds each delegation.

Audit log administration

The people who can alter, delete or disable audit records are positioned to hide misuse of other duties. Keep log administration separate from the administrators whose actions the logs record, and restrict who can change log retention or forwarding settings. Verify this with the actual access lists on the log store, not only the written policy.

Third-party and contractor accounts

Vendor engineers and contractors often receive broad administrative access for a project and keep it after the work ends. Include them in the same role model as employees, and confirm which contractor roles overlap with internal approval or review duties. Ask for each external account's sponsor, approved scope and end date, and whether any single external party holds both a request and an approval role.

How an assessor tests AC-5 with examine, interview and test methods

This table maps each SP 800-53A assessment method for AC-5 to the objects an assessor examines, interviews or tests, the evidence to prepare and the findings that commonly appear. Read it as a checklist of what to have ready before an assessor arrives.

Assessment method	What the assessor checks	Evidence to prepare	Common findings
Determination statement 1	Duties that must be separated are identified and documented, so the organization can show which functions must not sit with one person	Documented list of divisions of responsibility and separation of duties, approved by the people who own the duties	Duties are described in policy only, with no list of which combinations are prohibited
Determination statement 2	System access authorizations are defined so they support the documented separation	Access authorizations per role, mapped to the duty matrix	Roles grant combinations of rights the duty matrix prohibits
Examine: list of divisions of responsibility	Whether the list is complete, current and specific to system functions	Duty matrix with version history, owner and review date	Matrix is outdated after reorganizations or new system features
Examine: system access authorizations	Whether granted permissions match the defined separations	Role and group exports from the identity provider, with approval records	Duty matrix does not match actual role assignments
Examine: system audit records	Whether activity by people holding conflicting duties is logged and reviewable	Audit logs for privileged and sensitive actions, with sample reviews	No logs exist for cross-duty actions, or no one reviews them
Interview: personnel who define divisions of responsibility	How the separations were chosen, who approves exceptions and how changes are made	Named owners, approval workflow and exception register	Owners cannot explain the rationale or who may grant exceptions
Interview: system and network administrators	How administrators handle accounts that hold conflicting rights and how they apply the matrix	Admin procedures, break-glass records and sample provisioning tickets	Administrators hold both request and approval rights for the same process
Test: mechanisms implementing separation of duties policy	Whether the system actually blocks or flags conflicting assignments and actions	Test scripts, screenshots or configuration exports showing enforcement, and test results	Enforcement relies on manual checks and nothing blocks a conflicting grant

Implementing AC-5 role separation in six steps

This sequence turns the AC-5 requirement into a documented split of duties, enforced access authorizations and recorded exceptions that an assessor can trace from policy to directory to audit record.

Inventory the duties in scope
Start by listing the business and technical duties performed on the system, such as requesting access, approving access, changing configuration, deploying code, approving payments and reviewing audit logs. Include duties performed by administrators, developers, operators and business owners. The output is a duty inventory that names each duty, the system or process it belongs to and the person or team that performs it today. The step is complete when system owners have confirmed the list covers the duties in the system security plan and that nothing performed by privileged users is missing.
Identify combinations that must be split
Review the inventory and mark pairs or groups of duties that one person must not hold together, such as requesting and approving the same access, developing and promoting the same change, or administering a system and auditing its logs. Record the reason for each split against the risk it addresses. The output is a duty matrix that shows conflicting combinations, the risk each one creates and the owner who accepted the matrix. Ask the risk owner to sign off so the rules have a clear authority behind them.
Define role catalog and access authorizations
Translate the duty matrix into roles, and for each role define the system access authorizations it receives, the directory groups that carry them and the applications it can reach. Confirm that no role grants a conflicting combination of duties. The output is a role catalog listing role names, purpose, permitted duties, group memberships and application entitlements. Assessors examine this catalog against the duty matrix, so each conflict in the matrix should map to a rule that prevents the two roles from being held by the same person.
Enforce the split in directory and applications
Implement the role catalog in the identity layer and in each application. In a self-hosted environment this often means a central directory such as FreeIPA with group-based access, and an identity provider such as authentik that provisions and deprovisions application accounts over SCIM 2.0. Configure the applications so that conflicting roles cannot be assigned to one account, and test the mechanisms with an account that holds a conflicting role request. The output is a configuration record and test results showing the enforcement works, which is the evidence an assessor will test directly.
Record exceptions with approvals
Some organizations need a person to hold conflicting duties for operational reasons, such as a small team or an emergency. Record each exception in an exception register with the duties involved, the business reason, the compensating controls (for example, enhanced logging or a second reviewer), the approver, the expiry condition and the system affected. The output is an exception register that a reviewer can read without asking the owner for context. Confirm with your assessor how they expect exceptions to be documented, because the register is evidence that separation was a conscious decision and not an oversight.
Schedule recurring review and certification
Set up a recurring review in which designated reviewers confirm that each account still holds only the roles it needs and that every exception is still valid. Access certification tools such as midPoint can run campaigns in which reviewers decide within a set timeframe whether to keep, change or revoke role assignments, which counters access accumulation over time. Choose the review frequency with the risk owner and the assessor, and record it in the system security plan. The output is a review schedule, completed campaign records and a list of revocations, which together show the split still holds after staff move between teams.

Which evidence shows that duties are split and roles stay that way

An assessor testing AC-5 looks for a documented split of duties, role assignments that match it, and records showing the split held in practice. The cards below cover the artifacts that carry that story, and each one needs an owner and a refresh routine between assessments.

Documented divisions of responsibility

This is the written list of duties that must be kept apart, such as requesting, approving and executing a payment, or developing and promoting a change to production. For each pair, record the conflicting duties, the reason they are separated and the roles that hold each side. Assessors examine this list first, so it must match the system's actual workflows. Review it when a process changes and at least at each assessment cycle, and have the control owner and the process owner sign off on each revision.

Role catalog with access authorizations

The role catalog defines each role, the system access authorizations it grants and the duty pairs it must not combine. Its job is to show that the authorizations were designed to support the split, not granted ad hoc. Check that every role in the directory appears in the catalog and that no role carries both halves of a documented pair. Changes to roles should go through change control, with the system owner approving and the security function confirming the separation still holds.

Directory export of role membership

An export from the identity platform, such as the directory or identity provider, lists which accounts hold which roles and groups at a given time. It is the factual check against the catalog: an assessor can compare it line by line with the list of conflicting duties. Generate it on a schedule, store it with a timestamp and keep prior exports so changes over time can be traced. The identity administrator produces it and the system owner reviews any conflict it reveals.

Audit records of split duties

Sample audit records show what individuals actually did. For a split pair, the records should show that the person who initiated an action was not the person who approved or executed it. Pull a sample across the assessment period, including privileged actions, and check that no single account performed both halves. Confirm that audit logs are protected from the administrators whose actions they record. The security operations team reviews the sample, and the control owner confirms the result.

Exception approvals for conflicting roles

Some organizations must let one person hold conflicting roles for a short period, for example during staff shortages or an incident. Each exception should name the account, the conflicting duties, the business reason, the compensating controls such as extra review, and an end date. Keep exceptions in a register and confirm that each one expired or was closed. An exception with no expiry or no compensating control is a finding. The risk owner approves exceptions and the security function reviews the register.

Access review records

Periodic access reviews show that someone checked role assignments against the split of duties and acted on what they found. Records should list each reviewed account, the decision to keep, change or revoke, the reviewer and the date. Tools such as midPoint's access certification campaigns can route these decisions to designated reviewers within a set timeframe, which leaves a traceable record. Ask who signs off each campaign and how revoked roles are confirmed as removed.

What meeting AC-5 costs in money and effort

This table compares the cost components of meeting AC-5 separation of duties, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for a written, scope-based quote, since no DeployOpen prices or external figures are given here. The main takeaway is that role count and conflicting duty pairs drive most of the effort, and that open-source directories and review tools can reduce license spend.

Cost component	One-time or recurring	What drives it up	What keeps it down
Tooling or licenses	Recurring	Commercial identity governance or access review suites, many connected systems, and add-on modules	Self-hosted open-source directories such as FreeIPA and review tools such as midPoint remove license spend; confirm supported features and hosting needs first
Engineering time to model roles and wire enforcement	One-time, with later changes	Number of roles, number of conflicting duty pairs, and systems that each need their own role mapping	Agreeing a short duty inventory before building; reusing directory groups and delegated administration
Duty analysis and documentation of divisions of responsibility	One-time, then periodic updates	Number of business processes that touch privileged or financial actions and the number of people who must sign off	Starting from a written scope that limits which processes and systems are covered in the first pass
Evidence upkeep	Recurring	Frequency of role changes, manual approvals outside the system, and gaps in audit records of who granted what	Automated provisioning and logged approvals that produce role-assignment records without manual compilation
Access review time from reviewers	Recurring	Number of reviewers, number of role items per campaign, and how often reviews run	Campaigns scoped to high-risk roles, clear review deadlines, and default actions for items not reviewed
External testing or review of role design	Periodic, scope-dependent	Number of systems tested, depth of role-conflict testing, and whether collusion scenarios are in scope	Testing limited to the conflicting pairs identified in the duty inventory, with results tracked to closure
Auditor sampling and walkthroughs	Recurring per assessment	Number of role assignments sampled, number of systems in the assessment boundary, and missing or inconsistent records	Clean, exportable role and approval records and a current duty matrix ready before fieldwork

Which self-hosted open-source tools support AC-5 evidence

Separation of duties depends on who holds which role and whether those assignments are reviewed. The three tools below each produce a different kind of evidence: periodic review of role assignments, automated removal of access across applications, and a central directory of groups and delegated administration. Confirm with each vendor or your own testing that a tool covers your specific duty pairs before you rely on it.

midPoint access certification campaigns

midPoint (EUPL-1.2+) runs access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke each access item, such as a role assignment. For AC-5, this produces a dated record that a reviewer examined whether a person holds conflicting roles, and it counters access accumulation as people change jobs. Check that your conflicting duty pairs can be expressed as review criteria and that the campaign records are retained as evidence.

authentik SCIM provisioning

authentik (MIT) includes a SCIM provider that pushes user and group creations, changes and deletions to target applications over SCIM 2.0. It runs a full sync every hour and deprovisions users from the target when they lose access to the application. For AC-5, this helps keep the access granted in downstream systems aligned with the duty split defined in your authorizations. Confirm that each target application honors the SCIM operations you rely on and that sync logs can be exported as evidence.

FreeIPA central directory and delegation

FreeIPA (GPL-3.0-or-later) uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. It provides centralized access control and delegated administration through its web UI and command line tools. For AC-5, this lets you define which administrators can manage which groups and objects, so administrative duties can be split rather than concentrated. Confirm that your delegation model separates user creation, approval and privilege assignment, and test that the delegations behave as documented.

Who owns AC-5: your team, an implementation partner and the auditor

Your organization owns AC-5. Under the control, you must identify and document the duties of individuals that need to be separated, and define the system access authorizations that support that split. Those are management decisions tied to your mission, business processes and risk appetite, so they cannot be delegated to a vendor. Your team also decides how to handle exceptions and accepts the residual risk when a single person must hold conflicting authority, usually with compensating controls such as dual review or enhanced logging.

Duty decisions: Name the conflicting duties (for example, requesting and approving a payment, or developing and promoting a change) and record the rationale.
Risk acceptance: Sign off on each exception, its compensating control and its review date, under a named accountable owner.
Access reviews: Run periodic certification campaigns in which designated reviewers keep, change or revoke role assignments.
Policy and procedure: Maintain the separation of duties matrix and the procedures that tell administrators how to request a role.
Evidence ownership: Keep the signed matrix, exception register and review records current and available to assessors.

Check that every named reviewer has the authority and the knowledge to judge the access they approve.

Where AC-5 fails in assessments and how to close each gap

Assessors of AC-5 usually find the same few weaknesses: duty definitions that have aged, access that piles up over time, and splits that exist only on paper. Each card below names one gap, what it looks like in the evidence, and the fix that tends to close it.

Duty matrix written once and never updated

The separation of duties document is approved at audit time and then left alone while teams reorganize, systems change and new applications go live. AC-5 asks the organization to identify and document the duties that must be separated, so an outdated matrix fails the first determination statement even if the access settings look correct. Fix it by assigning a named owner to the matrix, tying review to role changes and system releases, and recording the approval date and version. Ask for the last three revisions and the change that prompted each one.

Role assignments that accumulate

People keep the access from earlier jobs after they move teams, so one individual ends up holding both sides of a split duty. The assessor will look for combinations that the matrix forbids and find them in the account lists. Fix it with periodic access certification in which designated reviewers keep, change or revoke each role assignment within a set timeframe, and with removal of old roles as part of every transfer. Ask whether the review covers conflicting combinations or only individual entitlements.

Separation enforced only by policy

The policy says that the same person may not create and release a change, but the system permits it. An assessor will test the mechanism that implements the policy, not the written rule alone, and a policy with no technical check gives no assurance that a violation would be caught. Fix it by configuring the access platform so that conflicting roles cannot be granted to the same identity, or by generating an alert when they are. Confirm which checks run automatically and which depend on a person noticing a problem.

Administrators holding request and approval rights

An administrator who can both request a privileged change and approve it has no independent check on that change. This is the most direct way that a single person can misuse privileges, and it is common in small teams where the same few people run the directory, the application and the approval queue. Fix it by moving approval to a role held by a different person, or by requiring a second approver for privileged grants, and by logging both steps. Ask for a sample of privileged changes showing two distinct identities.

Exceptions without an owner or expiry

Temporary exceptions to a split duty, such as an emergency grant during an outage, often become permanent because nobody is accountable for closing them. Assessors look for a register of exceptions and test whether each one has an approver, a reason and an end date. Fix it by recording every exception with a named owner, a documented compensating control and an expiry that the access platform or a review cycle enforces. Ask to see every open exception and when it was last reviewed.

No sample evidence that duties are split

The organization can describe its split duties but cannot show a sequence of real transactions where the duties were performed by different people. Assessors test AC-5 by examining system access authorizations and audit records, so a description without records is weak evidence. Fix it by keeping audit records that show requester, approver and implementer identities for sampled changes, and by retaining an exported role assignment list for each assessment period. Ask the team to pull five recent privileged changes and trace each one from request to implementation.

How much effort, time and outside help does AC-5 take?

What does meeting AC-5 cost, and what drives the price?

No public figure for AC-5 alone is available from NIST, which states that it does not estimate certification or compliance costs. The main cost is staff time: the people who map duties, write the separation matrix, configure role assignments and collect evidence. Costs rise with the number of systems in scope, the number of roles that must be split, how many identity tools are already in place, and whether the assessment covers moderate or high baseline systems. Ask any partner for a written scope that lists systems, roles, deliverables and the evidence set before comparing quotes. DeployOpen does not publish prices; a quote follows from that written scope.

How long does AC-5 implementation take?

The honest answer is that duration depends on scope, and no supplied figure gives a standard timeline for AC-5. A single system with a short list of conflicting duties, such as request, approve and pay, can be documented and configured far faster than a multi-system estate with dozens of roles. Timing also depends on how quickly the organization can agree on the duty matrix and on whether role assignments must be cleaned up before they can be tested. Ask for milestones tied to named deliverables in the written scope, not a single end date.

What does the work need from our own staff?

Separation of duties depends on business knowledge that only the organization holds, so its staff must do real decision work. Expect the process owners to name the duties that conflict, the department heads to approve the split, and system administrators to confirm what each role can actually do in each application. Security or compliance staff must own the resulting policy and sign off on exceptions. An implementation partner can draft the matrix, configure the tooling and gather evidence, but it cannot decide which business functions must be separated or accept the residual risk on the organization's behalf.

Can a small team implement AC-5 internally?

A small team can implement AC-5 internally if it has the time and the skills to do the work, and the control is narrow enough to manage. AC-5 has no control enhancements in SP 800-53 Release 5.2.0, so the requirement itself is compact, but the effort lies in the role analysis across applications. Small teams often struggle with three tasks: finding every role that grants conflicting rights, keeping the matrix current as people change jobs, and producing evidence that an assessor can re-test. Teams that lack directory administration experience may want outside help for the configuration work, while keeping the duty decisions in-house.

What will an assessor ask for first on AC-5?

An assessor testing AC-5 will first ask for the documented list of divisions of responsibility and separation of duties, because the control requires the organization to identify and document the duties that must be split. Next, expect requests for the system access authorizations that implement that split and for system audit records showing that the authorizations are in use. The assessor will also interview the personnel who define the divisions and the system administrators who maintain them, then test the mechanisms that enforce the policy. Prepare these artifacts before the assessment starts, because gaps in the document usually surface during the examine step. Independent assessors issue any findings; DeployOpen prepares the systems and evidence but does not issue assessment results.

What should a written scope for AC-5 include?

A written scope should state which systems and baseline (moderate or high) are covered, and it should name the roles and duties in each system that will be split. It should list the deliverables, such as the separation matrix, the configured role assignments, the review procedure and the evidence package, along with who signs off on each. Ask the partner to state what it will not do, including any decisions reserved for the organization and any work on the assessor side. The scope should also cover how changes to roles will be handled after handover and whether ongoing support is a separate retainer. Clear exclusions prevent later disputes about what the quote included.

How DeployOpen scopes, implements and prepares AC-5 evidence

DeployOpen treats AC-5 Separation of duties as a design and evidence problem: which duties must stay apart, how system access authorizations reflect that split, and how the organization can show it. We implement the supporting open-source platforms inside your own infrastructure and prepare the records an independent assessor will examine, while your organization keeps ownership of the control itself.

How we scope

Agree in writing which systems, roles and duty pairs fall within the AC-5 scope before work starts.
Confirm which divisions of responsibility your organization has already documented and which must be written.
Define the access authorization records, audit logs and approval workflows that will serve as assessment objects.

How we build

Configure role and group structures in self-hosted identity platforms so incompatible duties sit in separate roles.
Set up access certification campaigns with designated reviewers who keep, change or revoke role assignments.
Test that the mechanisms implementing the separation policy behave as documented, and record the results.

How we hand over

Deliver the configuration, role matrix and review records in a form your assessors can examine directly.
Document how each separation mechanism maps to the duty split your organization defined.
Provide a walkthrough so administrators can explain role assignments to an interviewer without relying on us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Confirm with us during scoping whether a retainer should cover periodic role reviews and role matrix updates.
Ask any assessor you engage to confirm the evidence format they accept before we prepare the final records.