What AC.L2-3.1.2 transaction and function control requires
A defense contractor preparing for a CMMC assessment has to show that a user with an ordinary account cannot do more on the system than their job requires. AC.L2-3.1.2 is the Level 2 requirement that puts this into practice. It asks the organization to limit access to the types of transactions and functions that each authorized user is permitted to execute. In practical terms, a payroll clerk who can view salary records should not be able to approve a payment, change the record, or delete it, and an engineer who can read a CUI drawing repository should not be able to alter its access settings. The requirement is the Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.1.2, and the assessment is run against the NIST SP 800-171A objectives for that requirement.
NIST SP 800-171A breaks the requirement into two objectives. The first is that the organization defines the types of transactions and functions each authorized user may execute. The second is that system access is limited to those defined transactions and functions. An assessor therefore expects a written definition of permitted actions per role, then technical proof that the system enforces it. Under the CMMC Scoring Methodology, AC.L2-3.1.2 is a 5-point requirement, and because it carries more than 1 point, it cannot be placed on a plan of action and milestones. It must be MET to reach Conditional or Final Level 2 status. A gap here cannot be deferred, so the decision on how roles are built has to be made before the assessment, not during it.
Role design is usually the hard part. Most systems ship with broad default roles, and organizations often inherit accounts that have accumulated permissions over years. The reader should confirm which applications hold CUI, list the transactions each one supports, and map those transactions to the people who truly need them. Evidence that assessors accept includes approved authorizations, documented access enforcement procedures, configuration settings, and audit records, and assessors may interview staff who administer access and test the mechanisms that enforce the policy. Identity platforms such as authentik can centralize role-based application access, and access certification reviews in midPoint can catch permissions that have built up over time. Confirm the exact capabilities of any product against its own documentation before relying on it for evidence.
Which systems, roles and accounts fall under AC.L2-3.1.2
AC.L2-3.1.2 applies wherever a role can create, read, update or delete CUI, so the scope starts with the systems and accounts that grant those rights, not only the network boundary. The cards below list the components an assessor will expect you to inventory, and the scoping decisions that change how much work each one creates.
CUI applications and their data stores
Start with the line-of-business applications, ticketing tools, document repositories and databases that store or process CUI. For each one, record which functions exist (create, read, update, delete, approve, export) and which roles can use them. Assessors will test whether the application enforces those limits, so a role matrix that exists only in a spreadsheet will not show enforcement. Confirm whether database-level grants and application-level roles match each other.
Identity providers that issue role claims
When an identity provider such as authentik or FreeIPA supplies group membership or role claims that applications use to grant rights, that provider is part of the scope. Document which groups map to which application roles and who can change those mappings. A change to a group in the directory can silently widen what a user may do, so the mapping logic is part of the evidence.
Cloud tenants and administrative consoles
Cloud tenants that hold CUI, along with their administrative portals, fall within scope when users hold roles there. Include tenant-level roles, resource-level permissions and any service roles that can read or change CUI data. Ask your cloud provider and your own team which built-in roles grant broad rights, and whether custom roles are documented with the functions they permit.
Shared and generic roles
Shared roles such as a common finance login or a generic administrator account make it hard to show that each person is limited to permitted transactions. Decide whether each shared role is retired, split into named roles, or documented with a compensating control. Assessors will ask who used a shared role at a given time, so this decision changes both the access design and the audit trail.
Application permissions versus operating system permissions
Operating system file permissions and application permissions are different controls. A user who can open a file share may still lack a transaction right inside the application, and the reverse is also true. Scope both layers, and state which one enforces each function. Overlooking the application layer is a common gap, because the operating system may appear to restrict access while the application still allows broader actions.
Third-party and managed service accounts
Vendor support accounts, managed service provider logins and integration service accounts can hold create, update or delete rights on CUI systems. List each one with its granted functions, the contract or ticket that authorizes it, and how it is reviewed. Confirm with each provider which functions their accounts can perform, since their internal roles may be broader than the access you have approved.
How an assessor tests transaction and function control
This table walks through what an assessor does for each part of AC.L2-3.1.2 under the SP 800-171A objectives, from interviews to test accounts. Read it as a checklist of what to prepare, and note the common findings that cause a requirement to be scored NOT MET.
| Assessment step | What the assessor does | What the organization should have ready |
|---|---|---|
| Objective 1: define permitted transactions and functions | Asks which transactions and functions each authorized user type may execute, then compares the answer with written role definitions | Role catalog listing each role, its permitted create, read, update, delete and administrative functions, and its owner |
| Objective 2: limit access to defined transactions and functions | Tests whether the system actually enforces those limits for each role, not just whether the policy exists | Access enforcement configuration for applications, directories and databases showing role-to-permission bindings |
| Interviews with access administrators | Asks staff who grant and change access how they decide which functions a role receives and who approves changes | Staff who can explain the role model, the approval path and how exceptions are handled |
| Examination of approved authorizations | Checks that each role assignment traces to an approval, including remote access authorizations where relevant | Signed or recorded approvals for role assignments, dated and linked to the user or group |
| Examination of configuration settings | Reviews permission settings, group memberships and default roles for drift from the documented design | Exported permission matrices or configuration baselines with the date of the last review |
| Testing with test accounts | Signs in with test accounts for each role and attempts permitted and prohibited actions to confirm the enforcement works | Test accounts for each role, a test script with expected results, and recorded outcomes |
| Common finding: broad write rights | Flags roles that hold create, update or delete rights beyond their documented purpose, often inherited through default groups | Periodic review records showing that write rights were checked against the role definition |
| Common finding: undocumented or draft role definitions | Treats roles that exist only in administrator memory or in unapproved drafts as not defined, so the objective is not met | Final, approved role definitions with version control and an owner, not working drafts |
How to implement transaction and function control step by step
This sequence turns the requirement that users may only perform the transactions and functions their role permits into a documented role model, enforced permissions and test records that an assessor can check against the 3.1.2 objectives.
Inventory CUI systems and their functions
Start by listing every system that stores, processes or transmits CUI, then list the functions each one offers, such as creating records, viewing files, changing configuration, approving payments or exporting data. The system owner and the security lead should sign off on the inventory. The output is a function register that ties each function to a system and to the CUI it touches. You know this step is done when every function in the register has a named system owner and no system in the CUI boundary is missing.
Define permitted transactions for each role
For each job role that needs access, decide which functions it may execute and at what level, for example read only, create and update, or full administration. Record these decisions in a role matrix that lists roles in rows, functions in columns and the permitted action in each cell. Business owners and security staff should both approve the matrix, because the SP 800-171A objective asks the organization to define these types of transactions explicitly. The matrix is complete when each function has an explicit entry for every role, including a deny entry where access is not intended.
Map roles to accounts and groups
Connect each role in the matrix to the groups, directory roles or application roles that already exist in the identity provider and in each system. Remove roles that do not match a defined job, and flag accounts that hold more permissions than their role requires. The output is a mapping table with columns for role, group or role name, system and account type. Your check is a report from the identity source showing which accounts belong to each role, reviewed against the matrix.
Enforce permissions in each system
Configure each application, database, file share and cloud service so that its built-in roles or access policies match the matrix. Use the platform's native role or policy mechanism where it exists, and disable default or shared roles that grant broader rights. Keep configuration exports, such as role definitions, policy files or permission reports, in version control or a controlled repository so that changes are traceable. Confirm the platform's exact capabilities for fine-grained function control with its documentation before you design around them.
Test denied actions with non-admin accounts
For each role, sign in with a test account that holds only that role and attempt both permitted and forbidden actions. Record the account used, the action attempted, the expected result from the matrix, the actual result and a screenshot or log entry. Testing with administrator accounts proves nothing about restriction, so every denial must come from a role-restricted account. Repeat the tests after any configuration change. The test record is complete when every forbidden action in the matrix has a logged denial and every permitted action has a logged success.
Review and document approvals
Store the approved role matrix, the mapping table, the configuration exports and the test records together as a single evidence set, and link it from the system security plan. Assign a review cadence and a named owner for each role, and record who approved each change to the matrix. Assessors look for evidence in final form rather than drafts, so mark each document with an approval date and version. The step closes when an outside reader can trace one function from the register to the role, the configured permission and the test result that proves it.
Designing roles and permissions that an assessor can follow
Start by deciding how access will be defined, because 3.1.2 is only testable when each authorized user has a documented set of permitted transactions and functions. NIST SP 800-171 Rev. 2 allows you to define access privileges by account, by type of account, or both. In practice, most organizations use account types (for example, requester, approver, records administrator, auditor) as the primary unit, then add individual account exceptions only where a named person needs something outside their type. Each account type should map to a list of functions such as create, read, update, delete, approve and export, written against the specific applications and data stores that hold CUI. The assessment objective for defining permitted transactions and functions cannot be satisfied by a general statement that staff have 'appropriate access'.
Coarse roles are easier to document, review and explain to an assessor, but they tend to accumulate permissions over time. Fine-grained permissions match duties more closely, yet they multiply the number of entitlements to test and can make the role model impossible to explain at assessment. A workable middle ground is a small set of roles with a clear boundary, plus narrowly scoped functions for sensitive actions such as exporting CUI or changing another user's rights. Every role needs a documented owner who approves its permissions and is accountable for changes, along with a recorded approval date. Confirm with your assessor which level of role granularity they expect for your environment before you finalize the model.
NIST also notes that access can be restricted by attributes such as time of day, day of week and point of origin. Treat these as supporting restrictions layered on top of role definitions, not as a substitute for them. For example, an identity provider or application policy might allow a records role to export CUI only from managed devices on the corporate network during business hours. Whether you use these conditions depends on what your platforms can enforce and log, so verify that capability in each product before you commit to it in the system security plan. Document each condition, the reason for it, and the test that shows it works, because an unexplained restriction is as hard to defend as no restriction at all.
Evidence that satisfies AC.L2-3.1.2
An assessor testing AC.L2-3.1.2 wants to see two things: that the organization defined what each authorized user may do, and that the system actually enforces those definitions. The cards below cover the documents, configuration exports and logs that show both, and the routine that keeps them current between assessments.
Approved authorizations and remote access records
Keep signed authorizations that name each user role, the transactions and functions it may perform, and the approver and date. Include separate authorizations for remote access, since SP 800-171A lists remote access authorizations as potential evidence for this requirement. Check that every role on the system appears in these records and that no account is active without one.
Role and permission matrix
A role and permission matrix maps each role to the create, read, update and delete rights it holds on each application, database and administrative console. It is the document that defines the permitted transactions, so it should be approved by the system owner and version controlled. Confirm that the matrix matches what the systems actually grant, because a matrix that differs from live permissions will fail the first assessor interview.
Access enforcement procedures
Write procedures that explain how access is granted, changed and removed, who performs each step, and which system enforces the decision. Assessors interview the staff who carry out access enforcement duties, so the procedure should match what those staff do. Record the review cycle and the trigger for an out-of-cycle change, such as a role change or termination.
Configuration exports showing enforced permissions
Export the configuration of the identity provider, directory and application authorization settings to show that permissions are enforced in the system, not only documented. For example, an illustrative export might show that a read-only group cannot reach an update endpoint. Date each export, store it with the matrix it supports, and re-export after every permission change so the two never drift apart.
Audit records of granted and denied actions
Retain logs that show both successful transactions and denied attempts, with user identity, action, object and timestamp. Denied records prove that the limit works, while granted records show that actions stayed within the defined role. Confirm that these logs are protected from edit and that someone reviews them, because assessors look for evidence that the records are used.
Dated test results in final form
Record test cases that attempt actions outside each role and capture the result, with the tester, date and system version. Under the CMMC rule, a requirement counts as MET only when evidence is in final form, so mark drafts as drafts and replace them with signed final versions before the assessment. Ask your assessor which sample of roles and transactions they will select so your tests cover the same ground.
How authentik, FreeIPA and midPoint support role enforcement
authentik is an identity provider that applications can delegate sign-in to, so user identity, group membership and attributes are managed in one place rather than inside each application. It supports several protocols, including OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, which lets it front web applications, directory-based services and network access. For AC.L2-3.1.2, the useful part is that group and attribute data flowing from authentik can drive what an application permits, but the transaction rules themselves usually live in the application.
- Central sign-in: Applications send users to authentik for authentication instead of keeping separate credential stores.
- Group and attribute claims: Group membership or attributes passed in tokens or assertions can be mapped to application roles.
- Proxy providers: Applications without native role support can still be gated at the front door, though this limits access to the application rather than its individual functions.
- Authorization evidence: Export of provider configuration, group definitions and application bindings gives assessors a record of who can reach each application.
- Change tracking: Changes to providers and bindings should be logged and reviewed as part of configuration management.
Confirm, for each application, whether it reads roles or groups from the identity provider, which claims it accepts, and whether transaction permissions (create, read, update, delete) are defined in the application or in authentik.
FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos key distribution center, so users and hosts authenticate against one directory and receive Kerberos tickets for services. It is most relevant where CUI systems are Linux servers, shared hosts or internal services that need consistent identity and group control. For AC.L2-3.1.2, it helps define which accounts and groups can reach which hosts and services, while the functions a user may perform on each service still depend on that service's own permissions.
- Kerberos single sign-on: Users authenticate once and access permitted services without separate passwords for each host.
- Host-based groups: Host-based access control rules and sudo rules can restrict which groups may log in to a host or run specific commands.
- Directory-backed identity: User, group and host objects are maintained in one directory that can be reviewed and exported.
- Service principals: Each service has its own identity, which limits what a compromised service can do with its credentials.
- Audit of group changes: Group membership and rule changes should be recorded and tied to an approved change.
Confirm which hosts and services in your boundary authenticate through FreeIPA, which of them enforce roles locally, and how sudo or command-level rules are documented for assessors.
midPoint is an identity governance tool. Its access certification campaigns ask designated reviewers to decide within a set timeframe whether each access item should be kept, changed or revoked. Items can include role assignments, which is the point where transaction and function rights are granted. The campaign record shows that someone with defined authority reviewed the assignments and removed those no longer justified, which addresses access accumulation and supports segregation of duties.
- Defined reviewers: Each campaign names the people responsible for reviewing specific roles or resources.
- Set timeframes: Campaigns close within a defined period, and unreviewed items follow a stated default.
- Keep, change or revoke: Each decision is recorded, and revocations flow back to the connected systems.
- Role assignment visibility: Reviewers see which roles a user holds, supporting checks that rights match the defined transactions for each role.
- Campaign evidence: Scope, reviewers, decisions and completion dates form the record assessors can examine.
Confirm how often campaigns run, how revocations are provisioned to each target system, and whether the target systems actually remove the rights when a role is revoked.
What meeting AC.L2-3.1.2 costs in money and effort
This table breaks down the cost components of meeting AC.L2-3.1.2, who is paid for each one, and whether it is one-time or recurring. Use it to shape a written scope and to compare quotes on like-for-like terms. No prices are stated because none are supplied; ask for each line item in a quote.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Role and permission design | Internal architects or an implementation partner | One-time, then revised on change | Number of job functions, data classes and transactions to define |
| Identity tooling or licenses | Software vendor or support provider; open-source tools carry their own license terms | Recurring if licensed or supported; open-source code itself is free to use under its license | User count, applications integrated, and whether support is bought |
| Application configuration | Internal administrators or an implementation partner | One-time per application, plus changes | Number of applications that enforce their own roles and whether each supports role-based access |
| Testing of enforcement | Internal staff or an independent tester | One-time, then repeated after changes | Number of roles tested and negative tests needed to show users cannot exceed their permitted transactions |
| Evidence upkeep | Internal compliance staff | Recurring | Frequency of role changes, log retention and how evidence is stored and versioned |
| Periodic access reviews | Internal reviewers and system owners | Recurring on the review cycle the organization sets | Number of roles, reviewer count and whether reviews are tool-supported |
| External review or assessor fees | Independent assessor or certification body, not DeployOpen | Recurring per assessment cycle | Assessment scope, number of systems in boundary and assessor's own fee schedule |
| Ongoing support or retainer | Implementation partner, if purchased | Recurring if chosen | Support hours, upgrade cadence and whether testing is continuous |
Where organizations fall short on transaction and function control
Most failures on AC.L2-3.1.2 are not missing technology. They are roles that exist on paper but not in systems, shared accounts that step around those roles, and evidence that was never finalized. The cards below pair each gap with the action that closes it before an assessor arrives.
Shared administrator accounts
A shared administrator login lets several people perform any transaction the system allows, so the role limits never apply to them. An assessor testing AC.L2-3.1.2 will look for the account in directory exports and ask who holds its password. Close it by issuing named privileged accounts to each person, disabling the shared login, and recording the change in the account management records.
Roles defined only in tickets
When the permitted transactions for a job function live in change tickets or chat threads, the system does not enforce them and no one can show the definition as a controlled document. Assessors expect the defined types of transactions and functions to be written down and traceable to the access mechanisms. Close it by writing a role matrix that lists each role, its permitted create, read, update and delete actions, and the group or policy that enforces it.
Unreviewed role accumulation
Users who change jobs often keep the roles from earlier positions, so their effective permissions grow beyond what the current role permits. Nobody notices because no one compares granted rights with the role definition. Close it by running a periodic access review that compares each user's assigned roles with the role matrix and removes any transaction the current job does not require.
Built-in admin roles left open
Many applications ship with default administrator roles, sample accounts or permissive guest profiles that bypass the organization's own role design. These defaults often remain active after installation. Close it by inventorying every built-in role in each application, disabling or renaming defaults, and restricting the remaining administrative functions to the roles named in the matrix.
Draft evidence at assessment time
Role matrices, access review records and configuration exports that are still marked as drafts do not satisfy the assessment objectives. A requirement is met only when the evidence is in final form. Close it by approving each artifact with a named owner and date, version-controlling it, and keeping the final copy with the system security plan.
Who owns transaction and function control, and what to outsource
Your organization owns the requirement itself. Only you can decide which transactions and functions each role may perform, which business owner approves those rights, and how exceptions are granted and ended. NIST SP 800-171A treats the defined set of transactions and functions per authorized user as the first assessment objective, so a definition that exists only in a consultant's workbook will not satisfy it.
- Role definitions: Name each role, the transactions it may run (create, read, update, delete, approve) and the systems it touches.
- Approvals: Record who signs off on each role and each change, with dates.
- Exception handling: Document temporary grants, their reason, their owner and their end date.
- Periodic review: Assign an owner to confirm that rights still match job duties.
- Staff accountability: Name the people who run access enforcement and can be interviewed.
Before engaging anyone, confirm that a named internal owner can answer an assessor's questions about every role in scope.
An implementation partner can prepare the systems and the evidence that show the requirement is met. Under a fixed-scope engagement, work typically covers configuring role-based permissions in the identity and application layer, documenting the design, and assembling the records an assessor will request. The partner does not approve roles, decide whether a control is met, or issue any finding.
- Configuration: Set up role-based permissions, group mappings and application roles in self-hosted platforms.
- Documentation: Draft the role matrix and access enforcement procedures for your review and approval.
- Evidence collection: Export configuration settings, role assignments and audit records in a form assessors can read.
- Testing support: Run internal checks that a role cannot perform transactions outside its definition.
- Knowledge transfer: Train your staff to maintain roles after the engagement ends.
Ask the partner for a written scope that lists which artifacts will be delivered and which decisions remain with your organization.
Only an independent assessor can issue findings. For Level 2 certification, assessments are performed by a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. Self-assessments are performed by the organization itself. Assessors interview staff with access enforcement duties, examine approved authorizations, enforcement procedures, configuration settings and audit records, and test the mechanisms that implement the policy.
- Independence: A consultant who designed the roles should not also act as the assessor for the same scope.
- Evidence in final form: Assessors accept finished artifacts, not drafts.
- Interviews: Staff must explain their own roles in their own words.
- Testing: Assessors may attempt transactions outside a role to confirm enforcement.
- Findings: Only the assessor records MET or NOT MET for the requirement.
Before engaging a C3PAO, confirm its current authorization status with The Cyber AB and check how it handles consulting conflicts.
Most organizations outsource implementation work and keep decision rights. Outsourcing makes sense where skills are scarce, such as directory integration, application permission mapping or evidence exports. Decisions about business need, risk acceptance and final sign-off should stay internal, because they are the substance an assessor will question.
- Outsource: Technical configuration, role mapping across platforms, and evidence packaging.
- Keep internal: Role approvals, risk acceptance, exception decisions and staff interviews.
- Shared work: Reviewing the role matrix against actual job functions.
- Recurring work: Quarterly access reviews and role changes after reorganizations.
- Cost drivers: The number of applications, the complexity of existing permissions and the amount of documentation required.
Request a quote that separates one-time design and configuration from any recurring review support, and ask who will answer assessor questions after handover.
Common questions about AC.L2-3.1.2 transaction and function control
Can AC.L2-3.1.2 be placed on a POA&M?
No. AC.L2-3.1.2 is a 5-point requirement under the CMMC Scoring Methodology in 32 CFR 170.24, and 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point on a plan of action and milestones. It must be MET before the organization can reach Conditional or Final Level 2 status. If it is NOT MET, its 5 points are subtracted from the maximum score of 110. Because deferral is not an option, the role model and enforcement work should be scheduled early. Confirm with your sponsor or assessment body how the current implementation schedule affects your status.
What drives the effort needed to meet AC.L2-3.1.2?
Effort rises with the number of roles, the number of transactions each role may perform, and the number of applications that hold CUI. The assessment objectives require you to define those transaction and function types for each authorized user, then show that system access is limited to them. Effort also rises when applications lack native role permissions, when accounts were granted ad hoc over years, or when shared accounts are in use. Effort falls when identity is centralized, roles are already documented and applications enforce permissions consistently.
Can our internal IT team meet AC.L2-3.1.2 without outside help?
Many internal teams can, because the work is design, configuration and record keeping inside systems they already run. The team needs a complete inventory of CUI systems, a role and permission matrix that defines allowed transactions and functions, enforcement in each application, and evidence in final form. Outside help is often used to prepare the role model, configure identity tooling or assemble the evidence package. The organization still owns the control, and an independent assessor, not the implementation partner, evaluates it.
What does meeting AC.L2-3.1.2 require from our staff?
It requires several roles to take part. Data owners must state which transactions each role needs, such as create, read, update and delete rights. Application owners must confirm how permissions are enforced in their systems. Identity administrators apply and document the changes, and managers approve role assignments. Assessors may interview people with access enforcement duties and test the mechanisms that implement the policy, so those staff must be able to explain how access is limited in practice. Plan time for these people during design and evidence collection.
How long does preparing for AC.L2-3.1.2 usually take?
No reliable duration can be given without knowing your environment, so the honest answer is that preparation time depends mainly on scope. It grows with the number of roles, applications and user populations, and with how far existing access practices are from documented, enforced roles. Teams with centralized identity and written role definitions generally need less time than teams managing accounts application by application. Ask any provider for a written schedule with milestones tied to deliverables, and ask which steps depend on your own staff being available.
How does the Level 1 counterpart for FCI differ from Level 2?
The Level 1 counterpart is AC.L1-b.1.ii, which comes from FAR 52.204-21(b)(1)(ii) and covers Federal contract information rather than CUI. A Level 1 self-assessment uses the SP 800-171A objectives for requirement 3.1.2, with FCI substituted for CUI, as described in 32 CFR 170.15, Table 2. The underlying idea is the same: limit users to the transactions and functions they are permitted to execute. The Level 2 version applies to a larger set of systems and carries a higher scoring weight, so the evidence standard is more demanding.
What should we ask a partner for in a quote?
Ask for a written scope that names the systems, applications and user populations included. The deliverables should list the role and transaction matrix, the enforcement changes for each application, the evidence package and its format, and who signs off on each item. Request exclusions in writing, retest arrangements and a schedule with milestones. Confirm that the partner prepares systems and evidence but does not issue assessment reports or certifications, since only an independent assessor does. DeployOpen works from fixed scope agreed in writing, and a quote follows from that scope.
Which open-source tools help enforce role-based access?
Identity and access tooling can enforce and document role-based limits. authentik acts as an identity provider for applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to a single place. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. midPoint access certification campaigns let designated reviewers decide within a set timeframe whether to keep, change or revoke role assignments, which helps counter access accumulation. Confirm that each tool meets your application's permission needs before relying on it for evidence.
How DeployOpen prepares evidence for this requirement
DeployOpen's work on AC.L2-3.1.2 starts with scoping, not tooling. Before anything is configured, the organization and DeployOpen agree in writing which systems store, process or transmit CUI, which user roles touch them, and which transactions each role must perform (for example, create, read, update or delete a CUI record). That scope is the boundary the assessor will test against. DeployOpen does not decide what a role may do. The organization owns that decision, and DeployOpen records it, implements it and checks that the implementation matches it.
Once the role matrix is approved, DeployOpen configures or hardens the identity and access tooling inside the client's own environment. Depending on the stack, that can mean using authentik as the identity provider so applications delegate sign-in and group-based authorization to one place, or using FreeIPA for single sign-on across Linux and UNIX hosts. Where roles accumulate over time, midPoint access certification campaigns can route role assignments to designated reviewers, who decide whether to keep, change or revoke them. Each platform's role and permission features should be confirmed against the version the client runs, since capabilities differ by product and release.
For the assessor, DeployOpen prepares the artifacts that SP 800-171A names as potential evidence for 3.1.2: the approved role matrix, the access enforcement configuration exported from each system, sample account-to-role assignments, and audit records showing that out-of-role transactions were denied. Documents must be in final form, because a drafted matrix does not count toward MET. DeployOpen can also prepare staff for interviews, since assessors may ask personnel with access enforcement duties how permissions are granted and removed. Be aware that DeployOpen does not issue assessment reports or certifications. Level 2 certification assessments are performed by an authorized or accredited C3PAO, and the organization should confirm the current Phase status with its contracting officer before planning that work.
