03.01.04 Separation of duties: requirements and evidence

What 03.01.04 separation of duties asks for and why it is hard

A CISO or compliance lead who must show that no single person can misuse CUI systems unchecked needs to answer one question: which duties, if held by the same person, would let that person change, approve and hide a misuse of CUI? Requirement 03.01.04 asks the organization to identify the duties of individuals that must be separated and to define system access authorizations that support that separation. The requirement has two parts. The first is an analysis: listing the duties, such as requesting an account, approving it, provisioning it, and reviewing its audit trail. The second is a technical and administrative design: giving each role only the access that lets it perform its own duty, so that carrying out a misuse would require two or more people to cooperate. NIST traces the requirement to control AC-5 (Separation of Duties) in SP 800-53 Rev. 5, and Rev. 3 cross-references 03.01.02 (Access enforcement) because the split only holds if the system actually enforces the authorizations.

The difficulty is rarely the wording of the requirement. It is that the duties are usually never written down. In many organizations, the person who approves payments in an application is also its administrator, and nobody recorded that as a decision. Role sprawl makes it worse: roles accumulate over years, a single role carries permissions from several duties, and users keep access they picked up on a previous project. A useful first step is to write a short duty matrix for each CUI system, listing the sensitive functions and the roles that currently hold them, then marking every pair of functions that one person should not hold. Confirm with your assessor how they expect that matrix to be documented and linked to the system security plan, because the evidence they examine will depend on it.

Scoping is the second hard part. Separation has to be checked across the systems that store, process or transmit CUI and the administrative tools that control them, including identity platforms, cloud consoles, ticketing and logging. Rev. 3 is written so that assessors examine policy, procedures, configuration settings and audit records, interview the people who define the split, and test whether the mechanisms enforce it. The organization owns the duty analysis and the decisions about who holds which role. An implementation partner can help build the role model, configure the systems and assemble the evidence, but only the independent assessor determines whether the requirement is met.

Which duties, systems and teams fall under separation of duties

Separation of duties under 03.01.04 starts with scoping: which systems touch CUI, which people hold conflicting duties, and which third parties can act with administrative rights. Each decision below changes how many roles need splitting and how much evidence the assessor will ask for.

Systems that hold or administer CUI

Start with the system boundary described in the system security plan, then list every system that stores, processes, transmits or administers CUI, including identity providers, backup consoles and logging platforms. For each one, record who can change configuration and who can approve that change. A system left out of the separation model is usually where an assessor finds collusion risk that no one documented. Confirm the inventory matches the boundary you have described to the assessor.

Request and approval paths

Map every workflow where one person requests an action and another must approve it, such as granting access, releasing payments or changing firewall rules. Then check whether the same role can both request and approve, directly or through group membership. The single role that spans both paths is the most common finding, so resolve it in the access model before the assessment rather than in the evidence file.

Development and deployment roles

Decide who may write code, who may review it and who may promote it to production. Where one engineer can commit, approve and deploy a change to a CUI system, the split is missing even if a review tool exists. Check repository permissions, pipeline approval rules and production deployment rights together, because a group that inherits all three defeats the separation.

Administration and audit of logs

Identify who administers the audit system and who reviews its records. An administrator who can edit, delete or disable logging for their own actions can hide misuse, so the review function needs access the administrators do not hold. Confirm which accounts can change log retention, forwarding rules or alert thresholds, and document who reviews those changes. This link ties 03.01.04 to the audit and accountability family.

Third parties with administrative access

List every managed service provider, vendor support engineer and remote maintenance account that holds administrative rights to a CUI system. Each one may combine request, approval and execution in a single session, which is hard to split inside your own organization. Ask whether the contract limits their rights, whether your staff approve each session and whether their activity is logged to an account you control. Confirm these arrangements with the system owner and the contracting officer where the contract requires it.

How an assessor tests separation of duties under SP 800-171A

This table maps the two SP 800-171A Rev. 3 determination statements for 03.01.04 to the examine, interview and test methods and their objects, then lists findings assessors commonly raise. Use it to prepare evidence before an assessment, since each row names what the assessor will ask to see and who they will ask.

Assessment method	Assessment objects for 03.01.04	Evidence to have ready	Common findings
Examine	Access control policy and procedures; procedures for the separation of duties and the division of responsibilities; system configuration settings; system audit records	A written list of conflicting duties, the procedure that defines the split, and configuration exports showing role and permission assignments	Duty splits exist only in people's heads, with no documented list of conflicting functions
Interview	Personnel with responsibilities for defining the separation of duties and the division of responsibilities; personnel with information security responsibilities	Named owners for the duty matrix, and a walkthrough of how new roles are checked against it	Staff who define access cannot explain which combinations are prohibited or who approves exceptions
Test	Mechanisms implementing the separation of duties policy	Attempted combinations of roles or approvals that the system should block, with the results recorded	Administrators can approve their own changes or hold both request and approval rights in the same workflow
Determination statement 1	Duties of individuals that need separating are identified	Duty matrix mapping functions such as request, approve, deploy, and audit to the roles that may hold them	Matrix covers finance or change workflows but omits security administration or log review
Determination statement 2	System access authorizations that support separation of duties are defined	Role definitions that show which permissions are granted, and which combinations are blocked or flagged	Roles are broad enough that one account can both create and release a change
Audit record review	Logs showing role changes, approvals and privileged actions by the same identity	Sample records showing approvals made by a different identity than the requester	No logs exist to show whether a split was followed in practice
Periodic access review	Reviewer decisions to keep, change or revoke role assignments within a set timeframe	Dated review records with reviewer names and outcomes for conflicting roles	Reviews rubber-stamp assignments, or never revisit roles after an employee changes duties

Sequence to implement separation of duties in a CUI environment

This sequence turns 03.01.04 from a policy sentence into working controls: it names the duties that must be split, documents the split, builds role authorizations that enforce it, and leaves dated evidence that an assessor can examine, interview against and test.

Inventory functions that touch CUI
List every system, application and business process that stores, processes or transmits CUI, then record the functions people perform in each one, such as requesting access, approving access, configuring systems, posting payments, releasing CUI or reviewing logs. Include functions performed by administrators, developers, contractors and automated service accounts. The step closes when the owner of each system signs off on a function inventory that covers the whole CUI boundary described in the system security plan.
Identify conflicting duty pairs
Review the function inventory and mark each pair of functions that one person should not hold together, because holding both would let that person create, hide or approve a misuse of CUI alone. Typical pairs include requesting and approving access, developing code and promoting it to production, and administering a system and auditing its logs. Record the reason for each pair and the people or roles affected. The step closes when a conflict matrix has been reviewed and approved by the data owner and the information security lead.
Document the split in policy and procedure
Write the separation of duties rule into the access control policy and the procedures that support it. The procedure should state which duty pairs are split, who may hold each duty, how exceptions are requested, approved and time-limited, and who checks compliance. Keep the document tied to the roles named in the system security plan so that the rule and the implementation describe the same environment. The step closes when the policy is approved, version-controlled and distributed to the people who administer the affected systems.
Define role-based access authorizations
Translate each split duty into a role with the narrowest set of permissions that performs it, and define which roles can never be granted together. Document the authorization for each role, including the approver. Where one person must hold two related roles for operational reasons, record the compensating control, such as an independent review of that person's actions. The step closes when a role catalog exists that maps each role to its permitted functions, its excluded role combinations and its authorizing owner.
Configure the platform to enforce the split
Implement the role catalog in the platform's identity and access management, directory groups, application roles and privileged access tooling so that conflicting roles cannot be assigned to the same account without a recorded exception. Prefer enforcement at the point of assignment, not only a manual check afterward. Confirm each setting against the platform's own documentation, because capabilities differ between products. The step closes when a test account that attempts a prohibited role combination is refused, and the configuration export is stored with the change record.
Set reviews and monitoring of role assignments
Schedule periodic reviews in which designated reviewers confirm, change or revoke each role assignment, and alert on new assignments that create a conflicting combination. Access certification campaigns, such as those in the midPoint identity platform, can structure this by requiring reviewers to decide within a set timeframe whether to keep, change or revoke each item. Log the review decisions and the reviewer identity. The step closes when the first review campaign has run to completion and its decisions are recorded against the access items.
Retain outputs as assessment evidence
Keep the artifacts that show the requirement operating over time: the approved function inventory, the conflict matrix, the policy and procedures, the role catalog, configuration exports and test results, exception records, review campaign results and the audit logs of role changes. Map each artifact to the determination statements in SP 800-171A Rev. 3 for 03.01.04 so an assessor can find it quickly. Set a retention schedule and confirm it against contract and assessment requirements. The step closes when an evidence index exists and an internal reviewer has walked through it without finding gaps.

How access authorizations make misuse require collusion

The core idea behind 03.01.04 is that no single identity should be able to complete a sensitive transaction from start to finish. Separation of duties is achieved in the access design, not in a policy document alone. Start by listing the sensitive transactions in your CUI environment, such as approving a payment to a supplier, changing a system's security configuration, or releasing CUI to an external recipient. For each one, identify the steps that must be split, for example request, approval and execution. Then decide which roles hold each step, and make sure no user holds conflicting roles at the same time. Conflicting roles should live in separate groups, so that an administrator who can create accounts is not also the person who approves their privileges.

The access authorizations that support the split are the enforcement layer. Under 03.01.01 (account management), you define the account types, roles and approvers, and you disable accounts that accumulate conflicting roles when people move between jobs. Under 03.01.02 (access enforcement), the system must actually refuse actions outside those authorizations, which the Rev. 3 discussion for 03.01.04 links to directly. Under 03.01.05 (least privilege), periodic role reviews catch privilege creep before it becomes a collusion risk. Requirements 03.01.06 and 03.01.07 limit administrator accounts and privileged functions, which matters because administrators are often the people best placed to bypass a split. NIST's change analysis notes that withdrawn Rev. 2 requirement 3.13.3 is addressed by 03.01.04 together with 03.01.01 to 03.01.03 and 03.01.05 to 03.01.07, so an assessor will expect to see these controls working as a set.

To test the design, ask an independent reviewer to pick one sensitive transaction and try to complete it with a single account. Confirm which approvals come from a different identity and whether the system records both identities in its audit trail. Check group membership for conflicts, and document any exception with an owner and an end date. Confirm with your assessor which evidence they expect for the examine, interview and test methods in SP 800-171A Rev. 3, since the procedures name policy, configuration settings, audit records and personnel who define the split. The NIST SP 800-171 Rev. 3 publication is the natural starting point for that conversation.

Evidence that passes a separation of duties review

An assessor testing 03.01.04 wants to see that the split of duties was decided on paper, built into system access, enforced in practice and kept current. The six artifacts below map to those steps, and each one needs a named owner and a refresh routine so the evidence still matches the system when the assessment happens.

Written duty matrix

A matrix listing each business or security function that must be split, such as request, approve, post and reconcile, and the roles that hold each side. It records which pairs of duties must never sit with one person and why. Check that every high-impact function on the CUI system appears, that the matrix names the owner who signed it, and that it is re-signed after organizational or system changes. Because the matrix is the decision record, an assessor will compare it against the configuration exports line by line.

Procedures for dividing responsibilities

Written procedures that explain how responsibilities are divided, who decides when a split cannot be made because of staffing, and what compensating controls apply in that case, such as added review or logging. They should also cover how new roles are assessed for conflicts before access is granted. Ask whether the procedures match what staff actually do, since assessors interview the people who define and follow the split.

Role and group configuration exports

Dated exports of role, group and permission assignments from the identity provider and each application that holds CUI. The export should show which accounts hold which combinations of conflicting roles, so reviewers can find any person who can both create and approve a transaction. Run the export on a schedule and keep the prior versions, so you can show the access state at any point in the assessment window and demonstrate changes over time.

Approval workflow records

Records from ticketing, change or approval tools showing that the requester, approver and executor were different people for each sensitive action. Pull a sample across the period and confirm that no record shows the same identity in two roles. Where a workflow allows self-approval, record the exception, its justification and the reviewer who accepted it. These records are often the most direct proof that the split operates in daily use.

Audit logs of blocked or flagged conflicts

Log entries showing that the system denied or flagged an action that would combine conflicting duties, along with the alerts raised and how they were handled. Confirm that the logging covers both the attempt and the outcome, that logs are protected from change, and that someone reviews the flags. An empty log is not automatically a pass, so test a conflicting action in a non-production environment and keep the result as evidence that the control works.

Periodic access review records

Completed review campaigns in which designated reviewers confirm, change or revoke role assignments within a set timeframe, with the decisions and revocations recorded. Open-source identity governance tools such as midPoint support access certification campaigns of this kind, though the organization should confirm the features it needs against current documentation. Reviews should specifically test for accumulated conflicting roles, not only for stale accounts, and should be run before each assessment and on a fixed cycle between assessments.

Who owns separation of duties, who can help, and where the auditor stops

Your organization owns the control. Requirement 03.01.04 asks you to identify the duties of individuals that must be separated and to define the system access authorizations that support that separation. Those decisions are business and risk decisions, so they belong to people accountable for the system, not to the people configuring it. NIST's FAQ is clear that the organization remains responsible for implementing SP 800-171 and for compliance, whatever help it brings in.

Duty decisions: Name the conflicting duties, such as requesting a payment and approving it, or developing a change and deploying it to production.
Access authorizations: Approve which roles may hold each side of a split, and record who signs off.
Recurring reviews: Schedule reviews of role assignments and resolve conflicts when people change jobs.
Policy and procedures: Maintain the access control policy and the separation of duties procedures that assessors will examine.
Interviews: Make sure the people who define and enforce the split can explain it when assessors ask.

Check that each conflicting duty has a named owner and a dated approval record before any assessor asks for it.

What meeting 03.01.04 costs in money and effort

This table breaks down the cost components of meeting 03.01.04 Separation of duties, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to separate internal effort from outside help. No dollar figures or durations are supplied for this requirement, so the table names what to confirm rather than estimating them.

Cost component	One-time or recurring	Who is paid or who spends effort	What drives it up or down
Duty analysis and split mapping	One-time, then revisited on role changes	Internal process owners and security staff, sometimes an outside consultant	Number of business processes touching CUI, number of distinct roles, and how well existing role catalogs are documented
Engineering time to configure roles and approvals	One-time, plus change work	Internal platform engineers or an implementation partner under a fixed-scope agreement	Number of systems in the CUI boundary, whether approvals are built into the platform or added manually, and integration with identity sources
Access control policy and procedures	One-time drafting, recurring review	Internal compliance lead, with legal or HR input where needed	Whether a separation of duties procedure already exists under 03.01.01 and 03.01.02, and how many exceptions must be documented
Licenses and tooling	Recurring where commercial, often one-time for setup	Software vendors for commercial access governance products	Self-hosted open-source platforms can remove license spend, but hosting, patching and support still need budget. Confirm the license terms of each component
Periodic access review and certification	Recurring	Designated reviewers in each business unit, plus the team that runs the campaign	Number of reviewers, frequency set in the organization's own policy, and whether campaigns are automated with a timeframe for decisions
Evidence upkeep	Recurring	Internal security or compliance staff, and system owners who export and retain records	How much evidence is generated automatically, retention periods the organization sets, and how often roles change
External review and readiness check	Optional, one-time per cycle	Independent assessors or consultants, billed under a written scope	Size of the environment, number of separated duty pairs to test, and whether preparation is done before the assessment starts
Assessor sampling during assessment	Recurring per assessment cycle	Independent assessor or DoD assessment team, not the organization	Number of roles, approval workflows and access reviews the assessor selects, and how quickly the organization produces records

How midPoint access certification supports the split

Access certification campaigns in midPoint give the organization recurring, documented evidence that people still hold only the access their duties allow, which is the kind of record an assessor will ask to see for 03.01.04. In midPoint (EUPL-1.2+), a certification campaign collects access items, such as role assignments, and routes them to designated reviewers. Each reviewer decides within a set timeframe whether to keep, change or revoke each item. That cycle is the mechanism that counters access accumulation, where someone changes roles over time and quietly keeps the permissions of every role they once held, eventually combining duties that should stay apart.

The campaign does not decide what must be separated. The organization still has to identify the duties that need splitting, record which role combinations conflict, and define the system access authorizations that support the split. Those decisions belong in the duty matrix and the access control policy, owned by the business and security owners. midPoint can make the review of those decisions repeatable and traceable, but a reviewer who has not been told that two roles conflict will approve them. Before relying on campaigns as evidence, write down the conflicting role pairs and confirm that the campaign scope and reviewer assignments reflect that list.

Confirm which midPoint capabilities fit your environment before designing around them. Check the access certification documentation at midPoint certification documentation for the campaign types, reviewer options, timeframe handling and reporting your version supports, and check whether conflicting-role detection or policy rules are available for your deployment. Test one campaign against a known conflicting pair, keep the decision records, and ask your assessor which artifacts they expect to examine. Where the vendor documentation does not cover a need, plan it as a separate control rather than assuming the tool provides it.

Where separation of duties usually fails in assessments

Assessors testing 03.01.04 look for two things: a written record of which duties must be split, and system access that actually enforces the split. The gaps below are where organizations most often fall short, and each one has a closing action that gives the assessor something concrete to examine.

Duties never written down

Many organizations separate duties in practice but have no document that names the conflicting duties. Under 03.01.04, the organization must identify the duties of individuals that need separating. Without that list, an assessor cannot tell whether a gap is a design flaw or an oversight. Start with a short matrix of conflicting functions, such as requesting a payment and approving it, or writing code and promoting it to production. Have the system owner and the security lead sign off on it, and keep it in the access control procedures so the interview answers match the document.

Role accumulation over time

Staff who change teams often keep the access from every previous role. A user who once approved purchases and later moved to accounts payable can end up holding both sides of a transaction. This is access accumulation, and it quietly defeats a split that looked correct on paper. Check each user's effective permissions against the duties matrix, not just their current job title. Remove access from prior roles at the time of transfer, and record who approved the change.

Shared administrator accounts

When several administrators log in with one shared account, the system cannot show which person made a change. An assessor testing separation will ask who could both create a privileged change and approve it, and a shared login makes that question impossible to answer. Give each administrator a named account, and confirm that the same person cannot both hold an administrative role and approve the work that role performs. Audit logs should record the individual, not the team.

Approvals reviewed by the requester's team

A change request is often approved by the manager of the person who asked for it, which keeps the split within one reporting line. Collusion risk is highest here, because the two people who would need to conspire already work together. Route approvals to a function that is independent of the requester, such as a separate security or finance group, for the duties identified in the matrix. Test the workflow by submitting a request as a user and confirming that the approver is outside that user's team.

No evidence of periodic review

Access that was correct at setup can drift without anyone noticing. Assessors look for records showing that someone reviewed role assignments against the duties matrix at a defined frequency, and that they kept, changed or removed each item. Without those records, the split cannot be shown to hold. Access certification campaigns, such as those in midPoint, assign reviewers who must decide within a set timeframe whether to keep, change or revoke each access item. Keep the signed review results as evidence.

Separation of duties questions buyers ask before hiring help

How much effort does separation of duties take to implement under 03.01.04?

The effort depends on how many duties in your environment need splitting and how many systems hold CUI. 03.01.04 asks you to identify the duties of individuals that must be separated and to define the system access authorizations that support that split. The work is mostly analysis and documentation at the start, then configuration of roles and approval paths. Drivers include the number of business processes that touch CUI, how many applications issue or approve access, whether roles are already defined, and how many people hold overlapping authority today. Ask a partner to state the systems in scope, the number of duty pairs to review, and whether the quote covers configuration changes or only the design and evidence.

Can our own team meet 03.01.04 without an outside partner?

Often yes, if your team has access administrators who understand the business processes and can document them. The requirement is not technically exotic, but it needs people who can map who requests, approves, records and reviews sensitive actions. Organizations commonly outsource the mapping of duties across several systems, the role design that keeps authorizations consistent, and the evidence package an assessor will examine. Your team still owns the control. An independent assessor, not the implementation partner, decides whether the evidence supports a finding. Decide early which parts your staff will own and which you will buy as fixed-scope work.

What does 03.01.04 need from our staff during the work?

The work needs input from people who know the duties, not only from system administrators. Plan time from process owners who can describe approvals, from security staff who understand the policy, and from the people who will review access. Assessors interview personnel with responsibilities for defining separation of duties and personnel with information security responsibilities, and they examine the procedures for dividing responsibilities. Staff should be ready to explain why a given pair of duties is split, how exceptions are approved, and what happens when someone changes role. Confirm with your assessor which interview roles they expect to speak with before you schedule the work.

Is 03.01.04 scored in CMMC Level 2?

Yes. CMMC Level 2 uses the Rev. 2 requirement set, and its practice AC.L2-3.1.4 corresponds to Rev. 2 requirement 3.1.4, which NIST traces to 03.01.04. Under the scoring methodology in 32 CFR 170.24, that practice is worth 1 point. Because the score is a count of assessed practices with weights, a single practice of this weight is small on its own, but a failed or unevidenced practice still affects the outcome of a Level 2 assessment. Confirm the current status of CMMC phase requirements and the applicable contract clauses with your contracting officer, since those rules are changing.

How does 03.01.04 relate to Rev. 2 requirement 3.1.4?

NIST's change analysis maps Rev. 2 requirement 3.1.4 to 03.01.04 and classifies the change as not significant, meaning the change is editorial. Rev. 2 included 3.1.4 in its access control family, and Rev. 3 keeps the separation of duties intent in 03.01.04. The Rev. 3 discussion refers to 03.01.02 access enforcement, so the two requirements work together. Rev. 3 also renumbered requirements and removed the basic and derived split, so a Rev. 2 evidence set can usually be reused with a new mapping. Check the change analysis spreadsheet yourself and confirm which version your contract names before you rebuild your evidence.

What should we ask a partner to include in a quote for 03.01.04?

Ask for a written scope that names the systems, the duty pairs to be reviewed, and the authorization changes to be made. A useful quote separates one-time work, such as duty analysis and role design, from recurring work, such as periodic access review. Ask who produces each artifact: the duty matrix, the authorization definitions, the configuration evidence and the review records. Ask what happens if the review finds that a duty cannot be split, and whether that triggers a separate change. DeployOpen prepares systems and evidence under a fixed-scope written agreement, but it does not issue assessment reports or certifications. Ask any partner to confirm the same boundary in writing.

Why 03.01.04 is unchanged from Rev. 2 3.1.4 but still matters for DoD work

NIST's Rev. 2 to Rev. 3 change analysis traces 03.01.04 back to Rev. 2 requirement 3.1.4 and classifies the change as editorial only. The obligation to identify the duties that must be separated and to define access authorizations that support that separation carries over without substantive change. For a DoD contractor, though, the wording of the requirement is not what decides which version gets assessed. The version named in the contract and the CMMC scoring rules decide that. Under 32 CFR 170.14(c)(3), CMMC Level 2 uses the Rev. 2 requirements, so 3.1.4 is assessed as AC.L2-3.1.4 and carries one point in the scoring methodology. Your separation of duties design has to satisfy the Rev. 2 wording today, and the Rev. 3 wording will read almost the same.

The version question is moving. DoW Class Deviation 2026-O0025, Revision 3, signed on 3 September 2026, has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly, and it cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. Separately, a FAR overhaul proposed rule published on 23 June 2026 would require contractors handling CUI to comply with Rev. 3 using organization-defined parameter values published by the DoW CIO. Comments closed on 23 July 2026, and the rule was not final as of October 2026. Under Rev. 3, 03.01.04 is assessed with two determination statements and the examine, interview and test methods, so the evidence you prepare for separation of duties should be reusable under either version.

How DeployOpen prepares separation of duties evidence

DeployOpen works on 03.01.04 by mapping which duties must be split between people and then configuring system access authorizations that support that split. The organization owns the policy and the decisions, and an independent assessor reaches the conclusion; DeployOpen prepares the systems and records that let the organization show the split is in place.

How we scope

Engagements are fixed-scope, with the duties to be separated and the systems covered agreed in writing before work starts.
The written scope lists which roles, approval steps and administrative functions are in the separation review.
Scope also states who in the organization owns the duty map, the access authorizations and the sign-off.

How we build

We help define the duties that must be split, such as request, approval, provisioning and audit review, and document each pairing.
We configure role and access authorizations so no single account can complete a full sensitive transaction alone.
We test the configuration against the split and record results, including attempts that should fail.

How we hand over

Deliverables include the duty-separation matrix, role definitions, access authorization settings and test records.
Documentation maps each element to the 03.01.04 determination statements so an assessor can follow the evidence.
The organization receives the material with named owners for keeping the matrix current after handover.

How we support

Ongoing support is available as a retainer for role changes, new systems and periodic re-testing of the split.
Retainer work can include reviewing access certification results to confirm that role assignments still match the duty map.
Questions about which assessment body or auditor will review the evidence should be directed to that independent party, not to DeployOpen.