The Cybersecurity Maturity Model Certification (CMMC) Level 1 is the foundational level of cybersecurity certification required for all Department of War (DoW) contractors and subcontractors. Level 1 focuses on the protection of Federal Contract Information (FCI).
As defined in the Code of Federal Regulations (CFR), FCI is “. . . information, not intended for public release, that is provided by or generated for the Government under a contract to develop or deliver a product or service to the Government, but not including information provided by the Government to the public (such as on public Web sites) or simple transactional information, such as necessary to process payments.”
To be compliant at CMMC Level 1, your organization must
Before implementing CMMC domains/controls/objectives, your organization must define which assets are “in-scope.” Defining the in- and out-of-scope assets is the single most important step at any CMMC level because scoping determines where your organization has to comply with CMMC and where it does not. Defining what is “in-scope” more narrowly than is actually true creates the conditions for CMMC compliance failure from the beginning; defining “in-scope” too broadly will cause more time and money to be spent achieving compliance than is needed.
Although CMMC Level 1 is represented in a hierarchy of domains, controls, and objectives, implementation is performed and compliance achieved at the objective level. Many information sources discuss implementing the CMMC controls, but compliance for every control is actually achieved by fulfilling the objectives.
Each control is labeled as follows:
Note that the requirement number is the 48 CFR 52.204-21 paragraph number, NIST SP 800-171 R2 requirement number, or NIST SP 800-172 Feb2021 requirement number.
For reference purposes, CMMC Level 1 has 6 domains and a total of 15 controls which are:
| Domain | Control |
|---|---|
| Access Control (AC) | AC.L1-3.1.1 Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems). |
| AC.L1-3.1.2 Limit information system access to the types of transactions and functions that authorized users are permitted to execute. | |
| AC.L1-3.1.20 Verify and control/limit connections to and use of external information systems. | |
| AC.L1-3.1.22 Control information posted or processed on publicly accessible information systems. | |
| Identification and Authentication (IA) | IA.L1-3.5.1 Identify information system users, processes acting on behalf of users, or devices. |
| IA.L1-3.5.2 Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems. | |
| Media Protection (MP) | MP.L1-3.8.3 Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse. |
| Physical Protection (PE) | PE.L1-3.10.1 Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals. |
| PE.L1-3.10.3 Escort visitors and monitor visitor activity; maintain audit logs of physical access; and control and manage physical access devices. | |
| System and Communications Protection (SC) | SC.L1-3.13.1 Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems. |
| SC.L1-3.13.5 Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. | |
| System and Information Integrity (SI) | SI.L1-3.14.1 Identify, report, and correct information and information system flaws in a timely manner. |
| SI.L1-3.14.2 Provide protection from malicious code at appropriate locations within organizational information systems. | |
| SI.L1-3.14.4 Update malicious code protection mechanisms when new releases are available. | |
| SI.L1-3.14.5 Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed. |
CMMC Level 1 implementation is achieved at the level of the objectives under each control. A control is graded as “MET” when all of the objectives under that control are correctly and fully implemented or determined to be not applicable or out-of-scope.
The following table lists each CMMC Level 1 control, the corresponding objective, and implementation guidance on achieving the objective.
| Control | Objective | Implementation Guidance |
|---|---|---|
| AC.L1-3.1.1 | [a] authorized users are identified | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Create a list of users who are allowed to access. The list should contain sufficient details, such as the person’s full name or employee id number, to uniquely identify each user.Additional implementationMaintain the list by adding and removing people promptly when their access needs change.Create a computer security policy that states (1) who is allowed to add/remove users from the list, (2) the time frame for updating the list when there is a change, (3) where the access list is kept, (4) actions to be taken, user agreements signed, and/or training taken when a user is granted access. Assessment consideration: (1) be able to produce the list of users when asked and (2) make sure the personnel who grant users access know where to find the list. |
| [b] processes acting on behalf of authorized users are identified | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:There are many processes that could be running on a system, which makes identifying “processes acting on behalf of” challenging.Write a Computer Security Policy that states that processes are permitted access only if acting in association with an authorized user. Processes are associated with a user only if they are (1) triggered by the user’s login to their account or (2) configured by an authorized privileged user, such as a system administrator, to execute in support of system maintenance, monitoring, or security purposes.Assessment consideration: be able to (1) describe how processes acting on behalf of users are identified and (2) demonstrate identifying these processes. | |
| [c] devices (and other systems) authorized to connect to the system are identified; | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Create a list of devices and other systems that are allowed to connect. The list should contain sufficient details, such as an IP address and MAC number, to uniquely identify each device or system.Additional implementationMaintain the list by adding and removing devices or other systems promptly when connection needs change.Create a computer security policy that states (1) who is allowed to add/remove devices or systems from the list, (2) the time frame for updating the list when there is a change, (3) where the access list is kept, and (4) actions to be taken when a device or system is granted access.Assessment consideration: (1) be able to produce the list of authorized devices and systems when asked and (2) make sure the personnel control access know where to find the list. | |
| [d] system access is limited to authorized users | Nature of the objective: this objective is primarily implemented through IT controls.Minimum implementation:Implement the Additional implementationEnhance the computer security policy by describing password complexity and length requirements, the duration before passwords must be changed, and how long users are locked out when repeatedly entering wrong passwords.Assessment consideration: show the list of users who have accessed the systems within a selected time period, such as a month, and show everyone who is on that list is also on the list of authorized users. | |
| [e] system access is limited to processes acting on behalf of authorized users | Nature of the objective: this objective is primarily implemented through IT controls.Minimum implementation:Implement the computer security policy described in [b] using IT controls that prohibit or kill any process that is not traceable to a user or a system maintenance, monitoring, or security function.Additional implementation: NoneAssessment consideration: be able to (1) describe how processes acting on behalf of users are identified and (2) demonstrate identifying these processes. | |
| [f] system access is limited to authorized devices (including other systems) | Nature of the objective: this objective is primarily implemented through IT controls.Minimum implementation:Implement the computer security policy described in [c] using IT controls that block access by unauthorized devices or systems.Additional implementation: NoneAssessment consideration: be able to (1) describe how authorized devices and systems are identified and (2) show the IT control that identifies devices and blocks unauthorized access. | |
| AC.L1-3.1.2 | [a] the types of transactions and functions that authorized users are permitted to execute are defined | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Create a list of the types of transactions and functions that users are permitted to execute. This information could be represented as a table that cross-indexes transactions/functions (read, write, delete, move, change settings [owner, who can access]) against different user classes (privileged user, information owner, authorized user). Additional implementation: The list of allowed transactions/functions is usually incorporated in a computer security plan or system security plan. Some sophisticated IT control implementations allow function/transaction permissions to be set at individual file and user levels.Assessment consideration: be able to (1) show the list that cross-indexes user types versus information types versus permitted transactions/functions allowed and (2) demonstrate how IT controls are configured to block unauthorized transactions/functions. |
| [b] system access is limited to the defined types of transactions and functions for authorized users | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:Configure IT controls to blacklist all transactions/functions and allow only those permitted from AC.L1-3.1.2 [a].Additional implementation: noneAssessment consideration: be able to (1) show the list that cross-indexes user types versus information types versus permitted transactions/functions allowed and (2) demonstrate how IT controls are configured to block unauthorized transactions/functions. | |
| AC.L1-3.1.20 | [a] connections to external systems are identified | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Create a list of the external systems that are authorized to conduct to the system containing FCI.The external systems may alternately be identified on the FCI data flow diagram and system boundary diagram.Any list of external connecting systems, the data flow diagram, and the system boundary diagram must all match with respect to the external system identities.Additional implementation: External systems could include an employee’s personally owned device or systems controlled by another part of the organization with FCI.Assessment consideration: (1) Produce one or more of the list of external systems, the FCI data flow diagram, and the system boundary diagram and (2) make sure the personnel who manage external system connectivity are aware of what systems are authorized to connect and that all unauthorized systems must not connect. |
| [b] the use of external systems is identified [authorized] | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:For each identified authorized external system, document the types of transactions and information exchanges that are authorized for that system. This information is typically documented in a computer security policy or system security plan.The types of transactions and information exchanges may also be documented in the FCI data flow diagram, which may be incorporated into the computer security policy or system security plan.Additional implementation: IT controls may be configured to permit only the authorized types of transactions and/or data exchanges with external systems. A firewall is a typical IT-based implementation. If the IT controls are configured in this way, make sure to capture the baseline configuration information for the controls and that this baseline matches documents such as the computer security policy and system security plan.Assessment consideration: (1) Provide the computer security policy, system security plan, or baselined IT controls and (2) make sure the personnel who manage external system connectivity are aware of what transactions or exchanges are permitted. | |
| [c] connections to external systems are verified | Nature of the objective: this objective is implemented through a combination of documentation and IT controls. Minimum implementation:At an organization level, the organization that has the FCI must verify that (1) the external organization has a valid reason to need access to the FCI and (2) the external system itself is capable of safeguarding FCI before any information is provided. This may be accomplished by requesting proof of the external system’s owner that the required CMMC Level 1 controls are fully implemented.At an IT controls level, the organization with the FCI must verify that any particular external connection is (1) being made by an authorized organization and (2) exhibiting the technical characteristics expected. For example, external connections should be verified to (1) prevent identity spoofing and (2) confirm that the communications security protocols, such as encryption, are functioning.Additional implementation: For non-government organizations, such as external connections between a prime and subcontractor or between two partner organizations, confirming proof of CMMC Level 1 conformance may be challenging since CMMC Level 1 only requires self-certification. (The government itself includes language in its SPRS system that provides civil and criminal penalties for false claims.) This may mean that an organization allowing an external connection may need binding contractual affirmation that CMMC Level 1 controls are fully implemented.Assessment consideration: Provide evidence of how the external system was determined to (1) have fully implemented CMMC Level 1 controls and (2) have a valid reason to need access to FCI.Demonstrate how external connections are verified at a technical level to make sure that (1) the external system is who it claims to be and (2) communications security protocols are operating. | |
| [d] Connections to external systems are verified [controlled] | Nature of the objective: this objective is primarily implemented through IT controls.Minimum implementation:Controlling the use of external systems means that the organization permitting the external connection must confirm that transactions and information exchanges conform with those identified in AC.L1-3.1.20 [b]. Since systems are not usually able to monitor activities inside another system, this means that the transactions and information exchanges are monitored (controlled) at the system boundary. The typical implementation is to use a firewall configured to blacklist any external transaction type except those that are explicitly allowed for the specific external system in conformance with the authorized uses in AC.L1-3.1.20 [b].Additional implementation: sophisticated firewall implementations will monitor not only blacklist particular transaction types, but will also monitor external traffic for trends and unusual patterns such as unusually heavy traffic, disconnects/reconnects, cycling of encryption protocols, etc.Assessment consideration: (1) provide the list of authorized transaction types for each external system and (2) show how monitoring devices, such as a firewall, are configured to block all other transaction types. | |
| [e] connections to external systems are controlled/limited | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:IT controls are configured to block all connections and only permit those that are identified in [a]. Data transfers may be limited in connection frequency or volume of data being transferredAdditional implementation: noneAssessment consideration: be able to (1) provide the list of authorized external connections from [a] and (2) be able to show that the IT controls are configured in accordance with [a]. | |
| [f] the use of external systems is controlled/limited | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:IT controls are configured to block all transactions not listed in [b], in accordance with the authorized systems listed in AC.L1-3.1.20 [a].Additional implementation: noneAssessment consideration: be able to (1) provide the list of authorized external connections from AC.L1-3.1.20 [a], the list of permitted transactions from AC.L1-3.1.20 [b], and (2) be able to show that the IT controls are configured in accordance with AC.L1-3.1.20 [a] and AC.L1-3.1.20 [b]. | |
| AC.L1-3.1.22 | [a] individuals authorized to post or process information on publicly accessible systems are identified | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Create a list of users who are allowed to post any information, not just FCI, to publicly accessible systems, just as company public-facing web sites, press releases, social media, account management applications, etc.Additional implementationCreate a “release of information” policy that states (1) who is allowed to post potentially sensitive information either from the government or the company, (2) the internal review process involving authoritative company personnel before information is released, (3) where the information may be posted, for example to the company website but not to a social media account, (4) the records to be kept with respect to the review and posting decision, (5) how often and by whom previously-posted information should be checked to make sure it does not include FCI, and (6) how to remove information that should not have been posted, including the personnel involved and actions to be taken (possibly including government personnel who should be informed).Assessment consideration: (1) be able to produce the list when asked, (2) make sure the personnel who control the publicly accessible system(s) know where to find the list. |
| [b] procedures to ensure FCI is not posted or processed on publicly accessible systems are identified | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Create a step-by-step procedure that must be followed for information to be posted to publicly accessible systems. The procedure should have a step for determining if information is FCI through a review by authoritative company personnel and prohibiting publication if so.Additional implementationCreate a “release of information” policy that states (1) who is allowed to post potentially sensitive information either from the government or the company, (2) the internal review process involving authoritative company personnel before information is released, (3) where the information may be posted, for example to the company website but not to a social media account, (4) the records to be kept with respect to the review and posting decision, (5) how often and by whom previously-posted information should be checked to make sure it does not include FCI, and (6) how to remove information that should not have been posted, including the personnel involved and actions to be taken (possibly including government personnel who should be informed).Implement data labeling to mark every piece of information with respect to “FCI” or “not FCI”. (Many additional data labels could also be implemented.) Implement IT controls that block any data labelled as FCI from being posted.Assessment consideration: (1) be able to produce the procedure when asked, (2) make sure the personnel who control the publicly accessible system(s) know where to find the procedure and can attest to following it. | |
| [c] a review process is in place prior to posting of any content to publicly accessible systems | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Create a step-by-step procedure that must be followed for information to be posted to publicly accessible systems. The procedure should have a step for determining if information is FCI through a review by authoritative company personnel and prohibiting publication if so.Additional implementationCreate a “release of information” policy that states (1) who is allowed to post potentially sensitive information either from the government or the company, (2) the internal review process involving authoritative company personnel before information is released, (3) where the information may be posted, for example to the company website but not to a social media account, (4) the records to be kept with respect to the review and posting decision, (5) how often and by whom previously-posted information should be checked to make sure it does not include FCI, and (6) how to remove information that should not have been posted, including the personnel involved and actions to be taken (possibly including government personnel who should be informed).Assessment consideration: (1) be able to produce the procedure when asked, (2) identify the personnel who are considered authoritative in conducting the reviews, (3) make sure the personnel who control the publicly accessible system(s) and conduct reviews know where to find the procedure and can attest to following it. | |
| [d] content on publicly accessible systems is reviewed to ensure that it does not include FCI; | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:On a periodic basis, an authoritative company person should check publicly accessible systems to make sure there is no FCI. The period for checking can be anything—once a week, once a month, once a quarter—as long as the review is done consistently.Additional implementationCreate a “release of information” policy that states (1) who is allowed to post potentially sensitive information either from the government or the company, (2) the internal review process involving authoritative company personnel before information is released, (3) where the information may be posted, for example to the company website but not to a social media account, (4) the records to be kept with respect to the review and posting decision, (5) how often and by whom previously-posted information should be checked to make sure it does not include FCI, and (6) how to remove information that should not have been posted, including the personnel involved and actions to be taken (possibly including government personnel who should be informed).Implement data labeling to mark every piece of information with respect to “FCI” or “not FCI”. Automatically scan the system periodically to make sure no (1) prohibited or (2) unlabeled data is posted.Assessment consideration: (1) be able to show evidence that reviews have been conducted at the period defined and (2) make sure the personnel who conduct the reviews can attest to doing so and know the period at which they conduct reviews. Note: this objective does not require that the time period for reviews be written down, although having a written definition may be useful for addressing assessment questions. | |
| [e] mechanisms are in place to remove and address improper posting of FCI | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:Define a process, which would typically be documented and incorporated into or referenced by a computer security policy, release of information policy, or system security plan, that defines the steps to be followed and the personnel responsible to (1) remove postings of unauthorized FCI and (2) informing the owner(s) of the FCI that is was improperly posted.Additional implementationExpand the removal process to include root cause analysis and corrective action steps to determine how unauthorized FCI was posted and how to update the processes for posting information to prevent future mistakes.In the process, define who is responsible for implementing it, how quickly the FCI must be removed, who should be informed (including government organizations), and how the steps in removing it are documented.Assessment consideration: (1) be able to show the process and (2) make sure the personnel responsible for the process (2) make sure the personnel who conduct the reviews can attest to doing so and know the period at which they conduct reviews. Note: this objective does not require that the time period for reviews be written down, although having a written definition may be useful for addressing assessment questions. | |
| IA.L1-3.5.1 | [a] system users are identified | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Provide a unique, documented identity for each authorized user (reference AC.L1-3.1.1[a]) that is traceable to them.Additional implementationCreate a procedure for (1) confirming who is an authorized user, (2) creating an unique identifier to be assigned to that user, and (3) setting up user accounts on systems containing FCI that only that user may access during “business as usual”. Identify who is responsible for implementing the procedure.Assessment consideration: (1) be able to provide a list of unique identifiers that is bi-directionally traceable with the list of authorized users and (2) make sure the personnel responsible for assigning identifiers can attest to how authorized personnel are assigned the identifier. |
| [b] processes acting on behalf of users are identified | Nature of the objective: this objective is primarily implemented using documentation. There are many processes that acting on behalf of users, which makes identifying “processes acting on behalf of” challenging.Write a computer security policy or system security plan that states that processes acting on behalf of a user only if acting in association with an authorized user. Processes are associated with a user only if they are (1) triggered by the user’s login to their account or (2) configured by an authorized privileged user, such as a system administrator, to execute in support of system maintenance, monitoring, or security purposes. Associate the processes with the user by including some identifier in the process’s name (for example, a process id list) that is traceable back to the user.Assessment consideration: be able to (1) describe how processes acting on behalf of users are identified and (2) demonstrate identifying these processes. | |
| [c] devices accessing the system are identified | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Create a system boundary diagram that lists all of the devices allowed to access the system along with a unique identifier. All devices accessing the system should be traceable to this list. Create a computer security policy that states that all devices not on this list are automatically blocked.Additional implementation: NoneAssessment consideration: be able to (1) describe how authorized devices are identified and (2) show the IT control that identifies devices and blocks unauthorized access. | |
| IA.L1-3.5.2 | [a] the identity of each user is authenticated or verified as a prerequisite to system access | Nature of the objective: this objective is primarily implemented through IT controls.Minimum implementation:The system checks the user’s login credentials, typically the assigned username, password, and possibly multi-factor authentication criteria, to confirm the user’s identity. Users whose claimed identity does not match the system’s information about them should be denied access.Additional implementationKeep a log of successful and failed authentication attempts. If a particular user has many failed logins or demonstrates a pattern of failures, investigate why this is occurring (for example, stolen credentials).Assessment consideration: (1) provide a demo of user authentication at login and (2) provide a record of successful and unsuccessful login attempts. |
| [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:The system should block all processes and permit only those processes that match those that are authorized in accordance with IA.L1-3.5.1[b]Additional implementation: Keep a log of successful and failed authentication attempts. If a particular process or type of process fails, then investigate why this is occurring. Of great urgency for further investigation are processes that are not authorized that are also not traceable to a known user.Assessment consideration: (1) provide a demo of how processes are authenticated and traceable to users and (2) demonstrate forensic tools for identifying and investigating unauthenticated processes. | |
| [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:The system should block all devices and permit only those devices that match those that are authorized in accordance with IA.L1-3.5.1[c]Additional implementationKeep a log of successful and failed authentication attempts. If a particular device fails, then investigate why this is occurring. Of great urgency for further investigation are devices that are not authorized that are also not traceable to a known user.Assessment consideration: (1) provide a demo of how devices are authenticated and traceable to users and (2) demonstrate forensic tools for identifying and investigating unauthenticated devices. | |
| MP.L1-3.8.3 | [a] system media containing FCI is sanitized or destroyed before disposal | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:Examples of system media include USB drives, computer hard drives, or DVDs.The simplest method for satisfying this control is to prohibit anyone from putting FCI on media. Document this prohibition as part of a computer security policy and/or make it part of an agreement that users sign when granted access to the system. If possible, configure any system containing FCI from writing to removable media.If FCI must be placed on media, create a step-by-step procedure for erasing or destroying the media prior to it being re-used, transferred, sold, etc. The concept is to make sure that no FCI can go from the possession of an authorized person to an unauthorized one without the information being removed.Additional implementationProcedures for “sanitization” (removal) of FCI from a device or destruction of the device can be elaborate depending on the nature of the device, see NSA/CSS Policy Manual 9-12 Storage Device Sanitization and Destruction Manual. The procedure may involve not just deleting the information from the media but overwriting the device with some pattern (such as all zeros). Some media, such as writable DVDs cannot be sanitized and must be destroyed.Assessment consideration: (1) be able to produce the procedure when asked, (2) make sure the personnel who are responsible for sanitizing or destroying media containing FCI are aware of the procedure. |
| [b] system media containing FCI is sanitized before it is released for reuse | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Keep a log that identifies media containing FCI and the disposition of that media that describes when it was sanitized or destroyed and who performed the action. Additional implementationTo avoid mistakes, identify media on the log at the time FCI is placed on the media. Include an entry stating where the media is currently located or who it is possessed by.Periodically audit to confirm that media identified in the log that has not yet been sanitized or destroyed is located or possessed as recorded.Assessment consideration: (1) be able to produce the log when asked, (2) make sure the personnel who are responsible for sanitizing or destroying media are aware of the log. | |
| PE.L1-3.10.1 | [a] authorized individuals allowed physical access are identified | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:If FCI is contained in a virtual cloud environment only, this control is not applicable. The data flow diagram and system boundary diagram should reflect that there are no physical systems (servers, computers, network attached storage, file cabinets, etc.) that process, transmit, or store FCI.Create a list of authorized users (reference AC.L1-3.1.1[a]) who have physical access to systems, equipment, operating environments. Note that having logical access (for example, a login identity) and physical access (being physically present where FCI is actually stored) may be different—many organizations allow personnel logical access to FCI but restrict who is allowed to physically enter a room containing the servers that store FCI.Additional implementation:Define a process for granting authorized users physical access to systems, equipment, or operating environments. The process should describe who is responsible for granting physical access, the means of physical access provided (for example, key, id badge, device, biometrics), the rules for physical access (for example, access is permitted only during certain times, two people must be present when physically accessing systems), how to report the loss of the means of physical access, and how and when the need for physical access is periodically reconfirmed. Assessment consideration: (1) be able to produce the list when asked and (2) make sure the people responsible for granting physical access are aware of the list. |
| [b] physical access to organizational systems is limited to authorized individuals | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Create a policy that states that only individuals specifically granted physical access to systems are permitted to have that access. Maintain a log that records everyone who enters into physical access with the system(s).Additional implementation:Have locked room(s) where only personnel who are granted physical access to the system may enter using a key, badge, device, biometrics, etc. Monitor locked room(s) using cameras or motion sensors.Assessment consideration: (1) be able to produce the log of who has physically accessed systems and (2) make sure personnel who need physical system access are aware of the log. | |
| [c] physical access to equipment is limited to authorized individuals | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Create a policy that states that only individuals specifically granted physical access to equipment are permitted to have that access. Maintain a log that records everyone who physically accesses equipment.Additional implementation:When there is specific equipment that requires controlled access, organizations typically put in the equipment in a locked room(s) where only personnel who are granted physical access to the equipment may enter using a key, badge, device, biometrics, etc. Monitor locked room(s) using cameras or motion sensors.Assessment consideration: (1) be able to produce the log of who has physically accessed equipment and (2) make sure personnel who need physical equipment access are aware of the log. | |
| [d] physical access to operating environments is limited to authorized individuals | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Create a policy that states that only individuals specifically granted physical access to operating environments are permitted to have that access. Maintain a log that records everyone who physically accesses the operating environment.Additional implementation:When there is a specific operating environment that requires controlled access, organizations typically house the operating environments in a locked room(s) where only personnel who are granted physical access to the operating environments may enter using a key, badge, device, biometrics, etc. Monitor locked room(s) using cameras or motion sensors.Assessment consideration: (1) be able to produce the log of who has physically accessed the operating environment and (2) make sure personnel who need operating environment access are aware of the log. | |
| PE.L1-3.10.3 | [a] visitors are escorted | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:If FCI is contained in a virtual cloud environment only, this control is not applicable. If IA.L1-3.5.2 is implemented, then there is no need to escort visitors because there is no means for the visitor to access FCI. The data flow diagram and system boundary diagram should reflect that there are no physical systems (servers, computers, network attached storage, file cabinets, etc.) that process, transmit, or store FCI. Create a process for (1) identifying and recording the presence visitors (that is, anyone who is not on the list for AC.L1-3.1.1[a]), (2) assigning as an escort someone who is on the list for AC.L1-3.1.1[a], and (3) the actions to be taken when escorting the visitor. Additional implementation:When identifying visitors, consider recording their name, citizenship, what external organization they represent, who sponsored or authorized their visit, when the visit began and ended, who is responsible for escorting them, and where they will be going inside of the facilities. Visitors may have to provide a photo ID to verify their identity.Base the escort actions on the organization’s risk from unescorted visitors. How closely a visitor must be escorted depends on the damage the visitor could cause if not escorted. Assessment consideration: (1) be able to produce the visitor escort process and (2) make sure that personnel who permit access to the facility are aware of the process. |
| [b] visitor activity is monitored | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:Provide a means for monitoring visitor activities, including through escorts and, if the user has system access, generating activity logs.Additional implementation:Create a work aid, such as a checklist, to be used in monitoring visitor activity.Provide training for personnel who escort visitors in how to monitor visitor activity.If visitors have system access, implement a specific login for visitors that provides more logging to assist in monitoring their activities.Assessment consideration: (1) personnel who monitor visitor activities should be able to describe the actions they take in monitoring and (2) provide any records generated by visitor monitoring, such as logs or notifications of visitor activities. | |
| [c] audit logs of physical access are maintained | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:Create a process that all personnel must follow to physically access systems. The process should generate a log of when facilities, secured areas, and physical devices (for example, network devices, computers) are accessed. For example, if FCI is stored on local disk drives on a machine, the log might be a list of (1) users who accessed the machine and (2) when the access began and ended. Network equipment might be placed in a secured room with a sign-in/sign-out list.Additional implementation: noneAssessment consideration: (1) provide a copy of the log and (2) be able to describe the process users must go through to physically access equip. | |
| [d] physical access devices are identified | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Provide a list of the physical access devices, such as keys, locks, safe combinations, and card readers, that are used to physically protect FCI information. Generally, physical access devices are for protecting non-IT FCI that might be printed on paper. However, physical access devices should also be used to protect easily portable electronic devices, such as DVDs and USB storage devices. Physical access devices may also limit entrance/exit from controlled areas, such as a secure room, where sensitive equipment is stored.Additional implementation:Create a process that describes (1) who oversees control of physical access devices and grants access through the devices (for example, issues a key), (2) tracking of physical access devices, typically through a log of who they have been issued to, (3) how physical access devices are secured when not issued to anyone, and (4) how physical access devices are returned once no longer needed.Assessment consideration: (1) provide a list of the physical access devices and (2) provide a record of who has physical access through the devices. | |
| [e] physical access devices are controlled | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:Create a process that describes (1) who oversees control of physical access devices and grants access through the devices (for example, issues a key), (2) tracking of physical access devices, typically through a log of who they have been issued to, (3) how physical access devices are secured when not issued to anyone, and (4) how physical access devices are returned once no longer needed.Additional implementation: noneAssessment consideration: (1) provide the process and (2) provide a record of who has physical access through the devices. | |
| [f] physical access devices are managed | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:Create a process that describes (1) who oversees control of physical access devices and grants access through the devices (for example, issues a key), (2) tracking of physical access devices, typically through a log of who they have been issued to, (3) how physical access devices are secured when not issued to anyone, and (4) how physical access devices are returned once no longer needed.Additional implementation: noneAssessment consideration: (1) provide the process and (2) provide a record of who has physical access through the devices. | |
| SC.L1-3.13.1 | [a] the external system boundary is defined | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Create a system boundary diagram. A boundary diagram is often included in a system security plan.Additional implementation: noneAssessment consideration: (1) provide the system boundary diagram and (2) ensure that the system owner, or whomever is responsible for system security, is able to discuss the system boundaries in the context of the boundary diagram. |
| [b] key internal system boundaries are defined | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Create a system boundary diagram that shows boundaries with external systems but also internal boundaries to (1) segment one set of users and components from others and (2) limit propagation of data loss or malware if one segment of the system is breached.Internal boundaries may be protected using the same mechanisms, such as firewalls and separate authorized user lists and authentication requirements, as external boundaries. The existence and description of these internal boundaries can be documented on the same boundary diagram used for external systems or in a separate diagram.Additional implementation: Implementation of segmentation and separation of internal systems that may share some information but not all information, with different users and different system components being able to possibly process, store, or transmit some but not other information, is complex. See the requirements in NIST SP 800-53 rev. 5, SC-4 and SC-31.Assessment consideration: (1) provide the system boundary diagram that includes internal boundaries and (2) ensure that the system owner, or whomever is responsible for system security, is able to discuss the system boundaries in the context of the boundary diagram. | |
| [c] communications are monitored at the external system boundary | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:Implement IT controls at the system boundary defined in SC.L1-3.13.1[a] to capture logs of communications crossing system boundaries. The IT controls are typically implemented using a firewall.Additional implementation:The firewall used to monitor communications is typically also used to block unauthorized communications entering or exiting the system at the boundaries. Firewalls may be configured to block whole ranges of IP addresses, types of communication to/from particular systems, particular users, etc. The most secure implementation is to block all traffic (blacklist) and permit only specific systems, users, and information types.Assessment consideration: (1) provide the logs of communications crossing the external system boundary and (2) ensure that the person responsible for security at the system boundary can discuss how traffic is monitored. | |
| [d] communications are monitored at key internal boundaries | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:Implement IT controls at the internal system boundary defined in SC.L1-3.13.1[b] to capture logs of communications crossing internal boundaries. The IT controls are typically implemented using an internal firewall.Additional implementation:The firewall used to monitor communications is typically also used to block unauthorized communications entering or exiting the system at the boundaries. Firewalls may be configured to block IP addresses, types of communication to/from particular systems, particular users, etc. The most secure implementation is to block all internal traffic (blacklist) and permit only specific systems, users, and information types. However, for internal traffic, configuring the firewall may be more difficult since a greater variety of communications may occur versus external traffic.Assessment consideration: (1) provide the logs of communications crossing the internal system boundary and (2) ensure that the person responsible for security at the internal system boundary can discuss how traffic is monitored. | |
| [e] communications are controlled at the external system boundary | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:Implement IT controls, typically using an external firewall, to block or filter communications entering or exiting the system at the boundaries. Firewalls may be configured to block or filter whole ranges of IP addresses, types of communication to/from particular systems, particular users, etc. The most secure implementation is to block all traffic (blacklist) and permit only specific systems, users, and information types.Additional implementation: noneAssessment consideration: (1) provide the logs of communications crossing the external system boundary and identify traffic in the logs that was blocked or filtered (2) be prepared to show how the firewall is configured to block or filter traffic. | |
| [f] communications are controlled at key internal boundaries | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:Implement IT controls, typically using an internal firewall, to block or filter communications entering or exiting the system at internal boundaries. Firewalls may be configured to block or filter traffic from particular internal system segments, types of communication to/from particular systems, particular users, etc. The most secure implementation is to block all traffic (blacklist) and permit only specific systems, users, and information types. However, for internal traffic, configuring the firewall may be more difficult since a greater variety of communications may occur versus external traffic.Additional implementation: noneAssessment consideration: (1) provide the logs of communications crossing the internal system boundary and identify traffic in the logs that was blocked or filtered (2) be prepared to show how the firewall is configured to block or filter traffic. | |
| [g] communications are protected at the external system boundary | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:Implement protection for data entering or leaving the system boundary. Usually the protection implemented is encrypting traffic and establishing system-to-system virtual private networks.Additional implementation: Implementation of communications security (COMSEC) mechanisms can be highly sophisticated. No COMSEC mechanism is entirely secure, especially when using external links that are not directly under the control of the parties engaged in exchanging information. COMSEC depends on the resources that an attacker is willing to spend in penetrating the mechanism. Conducting a risk assessment to determine the level of threat to the communications will guide the selection of COMSEC mechanisms.Assessment consideration: (1) show how the IT controls are configured to protect traffic and (2) be prepared to discuss how the level of protection was chosen. | |
| [h] communications are protected at key internal boundaries | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:Implement protection for data entering or leaving internal system segment boundaries. Usually the protection implemented is encrypting traffic and establishing segment-to-segment virtual private networks.Additional implementation: Implementation of communications security (COMSEC) mechanisms can be highly sophisticated. For internal systems, COMSEC mechanisms may be simplified since (1) the users and devices involved in a communication channel are known and authorized and (2) the entire communications path is under control of people accountable to the organization. No COMSEC mechanism is entirely secure but depends on the resources that an attacker is willing to spend in penetrating the mechanism. Conducting a risk assessment to determine the level of threat to the communications will guide the selection of COMSEC mechanisms.Assessment consideration: (1) show how the IT controls are configured to protect traffic and (2) be prepared to discuss how the level of protection was chosen. | |
| SC.L1-3.13.5 | [a] publicly accessible system components are identified | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Develop a list of the system components that may be publicly accessible. Publicly accessible components are ones that can be accessed by an external user who is not fully identified and where limited or not authorization mechanisms are in place.Additional implementation: the list of publicly accessible components is usually documented as part of the system boundary diagram.Assessment consideration: (1) provide the list of publicly accessible components and (2) be prepared to discuss how publicly accessible components are protected from malicious activity. |
| [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks | Nature of the objective: if implemented logically, this objective is primarily implemented through IT controls; if implemented physically, this objective is primarily implemented using a (documented) process.Minimum implementation:For logical implementation, publicly accessible system components grouped together in a subnetwork and treated as if the subnet is external to the system boundary. Safeguarding mechanisms such as firewall transaction blocking/filtering and limited access from the subnet then protect the rest of the system from public access. Create a log for audit review of transfers that occur. Logical separation is faster and scales to larger information transfer levels than physical separation but carries greater risk from technical attacks.For physical implementation, publicly accessible system components may not be physically connected (“air-gapped”) to internal components. Any information to be transmitted to/from the publicly accessible component and the internal component must be transferred by an authorized user and typically inspected before the transfer is made. Write a process that describes how the process is done, who can do it, and what inspections are done prior to data transfers. Create a log for tracking transfers of information. Physical separation is slower and scales poorly with larger information transfer levels than logical separation but carries less risk of technical attack. The system is still vulnerable to insider threats, though.Additional implementation: Even for publicly accessible components, firewall protections may block known high-threat IO addresses (for example, IP addresses associated with the People’s Republic of Korea)) and filter packets for malware or unauthorized information transfers.Reference AC.L1-3.1.22.Assessment consideration: (1) provide a list of publicly accessible system components, (2) explain how these publicly accessible components are separated from other internal components and the internal components are protected from the publicly accessible components, and (3) provide a log of information transfers that occurred. | |
| SI.L1-3.14.1 | [a] the time within which to identify system flaws is specified | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Create a computer security policy or system security plan that describes how often a check for system flaws, such as bugs and vulnerabilities, should be performed. There is no minimum time duration, although vendors often release patches at a specific cadence (for example, Microsoft “Patch Tuesday”).Additional implementation:The organization may have different cadences for checking for system flaws that depend on the importance of an application to the organization and the seriousness of the flaw. For example, an organization that depends on an email application for its business operations may want to check for updates with greater frequency than the organization would check for updates to an application that produces network diagrams. Likewise, checking for “zero-day” security vulnerability patches might be done more frequently than checking for routine application upgrades.The organization may be entirely dependent on how often application vendors release updates on system flaws. Adopting a cadence that happens more frequently than the vendor releases patch notices provides no benefit; checking less frequently risks a critical update being unnoticed until a vulnerability is already being exploited.Many systems, such as those using Windows operating system, can be set to check for system flaw notices based on a signal issued by the vendor. The system security plan or computer security policy can adopt this automatic notification to satisfy this objective. At CMMC Level 1, using the vendor’s automatic notification does not generate any side-effects but automatic patching requires more care at CMMC Level 2 with respect to the configuration management requirements.Assessment consideration: (1) be able to produce the document that defines the time for checking on system vulnerabilities and (2) make sure the personnel responsible for system security, which may include the system administrator(s), know the frequency for checks. |
| [b] system flaws are identified within the specified time frame | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:Define a process, which would typically be documented and incorporated into or referenced by a computer security policy or system security plan, that defines the steps to be followed and the personnel (or automated component) responsible for checking for notices on system flaws. The process should produce a log of dates when a check was performed. Additional implementation: noneAssessment consideration: (1) be able to show the process and the log of checks and (2) make sure the personnel who check for system flaw notifications can attest to doing so. | |
| [c] the time within which to report system flaws is specified | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Create a computer security policy or system security plan that defines the maximum allowed time between a system flaw being identified in the organization’s systems and a report being issued to other internal or external organizations or personnelAdditional implementation:Define a process for reporting to other personnel or organizations. The process could include (1) who performs the notification, (2) the information to be contained in the notification, (3) any reviews or approvals needed prior to sending the notification, (4) which organization(s) and personnel to send the notification to and the deadline for sending it, and (5) a log for recording transmission of the notification. Organizations that handle classified information in addition to FCI must follow rules for what to report, when to report, and to whom to report. The process for reporting system flaws and these reporting processes can be integrated to create more efficient process.Assessment consideration: (1) Provide the policy or process that describes the deadline for reporting a system flaw and (2) make sure personnel responsible for system security can identify the reporting deadline. | |
| [d] system flaws are reported within the specified time frame | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:Create a log that records any reports that are issued. Additional implementation:Define a process that is designed to comply with the deadline for reporting to other personnel or organizations. The process could include (1) who performs the notification, (2) the information to be contained in the notification, including any impact analysis, (3) any reviews or approvals needed prior to sending the notification, (4) which organization(s) and personnel to send the notification to and the deadline for sending it, and (5) a log for recording transmission of the notification. Organizations that handle classified information in addition to FCI must follow rules for what to report, when to report, and to whom to report. The process for reporting system flaws and these reporting processes can be integrated to create a more efficient process.Assessment consideration: Since application and equipment vendors are usually much faster in identifying flaws than organizations using an application or equipment, an organization with FCI may never have an opportunity to report a system flaw before a vendor has supplied a patch. If the organization does make a report, provide the reporting log. If the organization has never had an opportunity to make a report, provide the reporting process and make sure that the personnel identified in the process are aware of it. | |
| [e] the time within which to correct system flaws is specified | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Create a computer security policy or system security plan that defines the time allowed from identification/notification of a system flaw until that flaw is corrected.Additional implementation:Define a process that is designed to comply with the deadline for correcting system flaws. The process could include (1) who performs the corrective action(s), (2) any reviews or approvals needed prior to implementing the action(s), (3) requirements for testing to be performed before correcting any flaws, (4) which organization(s) and personnel to notify before make changes, and (5) a log for corrections made. Although not required at CMMC Level 1, the timing of system flaws corrective actions must take into consideration CMMC Level 2 configuration management requirements.Assessment consideration: (1) provide the policy or process that specifies the deadlines for corrective action and (2) make sure that personnel who would implement the corrective action are aware of the deadlines. | |
| [f] system flaws are corrected within the specified time frame | Nature of the objective: this objective is primarily implemented using a (documented) process.Minimum implementation:Define a process that is designed to comply with the deadline for correcting system flaws. The process should include a log with beginning and completion dates/time to track corrective actions.Additional implementation:Expand the process to include (1) who performs the corrective action(s), (2) any reviews or approvals needed prior to implementing the action(s), (3) requirements for testing to be performed before correcting any flaws, (4) which organization(s) and personnel to notify before make changes, and (5) a log for corrections made. Although not required at CMMC Level 1, the timing of system flaws corrective actions must take into consideration CMMC Level 2 configuration management requirements.Assessment consideration: (1) Provide the log of corrective actions taken and (2) make sure the personnel responsible for corrective actions are aware of the deadlines. If no corrective actions have been taken, then (1) provide the process and (2) make sure the personnel responsible for the process are aware of it. | |
| SI.L1-3.14.2 | [a] designated locations for malicious code protection are identified | Nature of the objective: this objective is primarily implemented using documentation.Minimum implementation:Create a computer security policy or system security plan that documents where in the system or network malicious code protections will exist. These locations may also be documented in the system and network data flow diagram. Some common locations are at firewalls, network storage devices, and end-user computers.Additional implementation:NoneAssessment consideration: (1) be able to produce the document that defines the location(s) where malicious code protection is implemented and (2) make sure the personnel responsible for system security, which may include the system administrator(s), can identify the location. |
| [b] protection from malicious code at designated locations is provided | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:Configure the operating system, firewall settings, etc. to run anti-malware protection applications or services whenever an object (for example, file, email) transitions through or is saved at the designated locations. Additional implementation:Some systems are configured to protect against malicious code both internally, such as at internal network routing, and externally, such as at firewalls.Assessment consideration: (1) be able to show that the operating system, firewall settings, etc. are configured to provide malware protection and (2) be prepared to demonstrate that malware protections are active. | |
| SI.L1-3.14.4 | [a] malicious code protection mechanisms are updated when new releases are available | Nature of the objective: if implemented logically, this objective is primarily implemented through IT controls; if implemented manually, this objective is primarily implemented using a (documented) process.Minimum implementation:If implemented logically, configure the malicious code protection applications or services to check regularly for new releases and to update when the new release is available. There is no mandatory period for how often checks are performed, but most anti-malware applications or services check at least daily. If implemented manually, maintain a log of when a check was made for updates and when the update was installed.Additional implementation:Since automatic updates from an external source—even a generally trusted one such as an anti-malware application vendor—represent a risk to a system, sometimes updates are made to an isolated system for verification before the update is propagated in general. (People or organizations that distribute malware will often try to surreptitiously corrupt an anti-malware vendor’s product, since these products are widely distributed and generally trusted Assessment consideration: (1) be able to produce a log that is generated automatically or manually generated of anti-malware updates and (2) make sure the personnel responsible for system security, which may include the system administrator(s), can explain how updates are performed. |
| SI.L1-3.14.5 | [a] the frequency for malicious code scans is defined | Nature of the objective: this objective is primarily implemented using documentation. Minimum implementation:Create a computer security policy or system security plan that documents how often malicious code scans—typically “malware” scans—are performed. There is no minimum frequency, although at least daily is a typical frequency. Scanning more frequently than described is acceptable.Additional implementation:Many anti-malware applications enable scans every time a file is accessed.Assessment consideration: (1) be able to produce the document that defines the frequency of malicious code scans and (2) make sure the personnel responsible for system security, which may include the system administrator(s), is aware of the scanning frequency. |
| [b] malicious code scans are performed with the defined frequency | Nature of the objective: if implemented logically, this objective is primarily implemented through IT controls; if implemented manually—typically using a malware scanning application—this objective is primarily implemented using a (documented) process.Minimum implementation:If this objective is implemented logically, then capture a record of when scans are being performed. Most scanning software will automatically track how often scans are performed. If this objective is implemented manually, then keep a manual log that records when scans are performed.Additional implementation: noneAssessment consideration: (1) be able to produce the manually or automatically generated log of scans being performed and (2) be prepared to provide a demonstration of performing a scan. | |
| [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed | Nature of the objective: this objective is primarily implemented through IT controls. Minimum implementation:Configure the malware scanning application to automatically scan any file from an external source when the file is downloaded, opened, or executed. The operating system may also need to be configured to invoke the malware scanning application.Additional implementation:Since scanning only files from external sources is cumbersome, configure the malware scanning application and operating system to scan all files when the files are moved or transmitted, opened, or executed.Assessment consideration: (1) be able to produce a log of files being scanned and (2) be prepared to provide a demonstration of performing a scan when a file is downloaded, opened, or executed. |
Under CMMC, every organization is obligated to perform an annual self-assessment to ensure current and continued compliance. Here’s a list of what needs to be done:
