DoD Contractor Considerations for CMMC Practice Guide AC.L1-3.1.2

By Christopher Moschella, CPA, CISA, Risk Advisory Services Senior Manager

DoD Contractor Considerations for CMMC Practice Guide AC.L1-3.1.2

Note: Important Change as of November 2021
The Department of Defense announced a major overhaul to the Cybersecurity Maturity Model Certification (CMMC) program. No new contracts will feature CMMC compliance requirements until the Department completes its rulemaking process for CMMC 2.0. Read our summary of the changes, Goodbye CMMC 1.0, Hello CMMC 2.0. For more detailed information, visit the CMMC website.


Keiter’s Cybersecurity team will continue to monitor the rollout of the CMMC program and update you on new information and changing requirements for DoD contractors.

CMMC Maturity Level (ML) 1 Practices:  Overview of AC.L1-3.1.2

Editor’s note: This article is one of a series of articles about the CMMC Maturity Level (ML) 1 Practices. In these articles, we dive in to the CMMC Practice Guides and provide our thoughts about the practices and what contractors should consider. The CMMC ecosystem is still developing, and as those developments occur, we will update these articles accordingly. As such, we hope that these articles represent an evergreen CMMC (ML) 1 resource.

Practice Number: AC.L1-3.1.2
Practice: Limit information system access to the types of transactions and functions that authorized users are permitted to execute.

Assessment Objectives
Determine if:
[a] the types of transactions and functions that authorized users are permitted to execute are defined; and
[b] system access is limited to the defined types of transactions and functions for authorized users.

(source: CMMC ML-1 Assessment Guide)

Overview of AC.L1-3.1.2

This practice and the related Assessment Objectives set forth requirements that restrict user access based on the users’ needs. For most systems, this simply means that users are given access to systems via roles, and those roles are aligned to access rights.

Example of how a Defense contractor might implement practice AC.L1-3.1.2

A contractor provides security services to DoD facilities. The services are managed in a Security Services Management System (SSMS). Each contract that is awarded relates to an individual campus at which the services are provided. A single contractor Security Services Manager is in charge of each campus, and the security personnel at each campus do not rotate between campuses. Overseeing all of Security Services is the Director of Security Services. Given that structure, the SSMS has the following roles and structure:

Job TitleSSMS System Role NameFunctions
IT Systems AdministratorAdministrator•Grant, Disable, and Modify Access
Director of Security ServicesServices Lead• Assign Managers and Security Staff to any Campus
• Review Billing Reports for any Campus
• Review Time Entry for any Manager or Security Staff
• Inspect security activity at any campus
• View and modify building plans and security assignments at any campus
Security Services ManagerLocation Lead•Review Billing Report for assigned campus only
•Review Time Entry for assigned campus only
•Inspect security activity for assigned campus only
•View and modify building plans and security assignments at assigned campus only
•Approve timecards for assigned campus only
Security GuardLocation Security Guard•Enter personal timecard data
•View building plans and security assignments at assigned campus only

Given the above example, it should be apparent how system permissions should be structured to comply with the practices. Ideally a system has roles for which the individual permissions are assigned and then individuals are assigned to a role based on their job responsibilities. In the above example, all the work could be performed if all service staff had the “Services Lead” role, but that would be excessive to what everyone needs, unnecessarily increasing the risk of unintended data loss.

Note: This is subtly different from AC.2.007 – an ML 3 requirement – that relates to the principle of least privilege.

Systems can be limited in a variety of ways other than role. For example, system access could be limited to certain times of day, days of the week, geographic location, etc.

Key to Success
Many organizations that have not had compliance requirements in the past enjoy loose data controls, with FCI and CUI stored in a semi-organized manner without many access restrictions within the company or department. Complying with the CMMC, however, will require changes.

Organizations with data spread throughout a network will likely need to undertake a data cleanup effort. FCI and CUI should be consolidated into as few systems and locations as possible, and access should be restricted based on role.

This effort will likely yield benefits because it will shrink the rest of your compliance efforts. For example, if you reduce the number of in-scope systems from five to three, and network folders from 25 to five, you have vastly decreased the ongoing compliance effort required to obtain and maintain your certification.

It is common for many companies to store FCI and CUI in shared drives on an Active Directory based network or cloud service, such as OneDrive or SharePoint. Companies with such requirements should leverage Active Directory Security Groups to limit access to FCI and CUI to only the employees who need access to the given data. For example, a consulting company provides Aircraft Survivability studies and Missile Defense analysis, and much of the analysis generated resides in shared network folders. The company should consider creating an Active Directory Security Group for the Aircraft Survivability Team and one for the Missile Defense Analysis Team. They should restrict access to their given work products to only the engineers on the given team.

It is also important to consider direct access to supporting databases. For example, if team members use data analysis tools to examine data in a database, those users might require user accounts to the database itself. Because they only need to read the data in the database, their database roles should be restricted to read only, rather than also having access to write, modify, or delete data.


System users should not all have rights to perform all types of transactions. All in-scope systems and networks will be required to have the ability to limit access to data and the functions of the system. Ideally, this will be accomplished with system roles that grant access to certain functions and data.

Interested in learning more about CMMC services for your defense contracts? Contact us. We are here to help.


Share this Insight:

About the Author

Christopher Moschella

Christopher Moschella, CPA, CISA, Risk Advisory Services Senior Manager

Chris is a Senior Manager in Keiter’s Risk Advisory Services. Chris has a strong combination of IT skills, which range from IT audit and internal control assessments, including general computer controls and application controls, to full stack web development. Most recently, Chris developed a Cybersecurity web application that assesses an organization’s resistance to social engineering attacks. Chris shares his cybersecurity insights on our blog.

More Insights from Christopher Moschella

The information contained within this article is provided for informational purposes only and is current as of the date published. Online readers are advised not to act upon this information without seeking the service of a professional accountant, as this article is not a substitute for obtaining accounting, tax, or financial advice from a professional accountant.


Contact Us