CMMC Scoping Guide: Creating an Applicability Matrix

🚀 What’s This Blog About?

This blog explains how CMMC Scoping and Applicability helps defense contractors and IT compliance teams define which components fall under CMMC Level 2 assessment. It walks through system categorization, control applicability, and how to use DISA STIGs and SRGs to streamline compliance.

Key Takeaways

  • ✅ Use the CMMC Scoping Guide to categorize assets by people, technology, and facilities
  • ✅ Apply NIST SP 800-53 guidance to determine which controls are applicable to which system components
  • ✅ Leverage DISA STIGs and SRGs to align technical control implementation with CMMC 2.0 requirements

Who Should Read This?

This guide is ideal for compliance managers, IT leaders, and CMMC consultants working with defense contractors. It’s especially useful if you’re trying to reduce the risk of audit findings by clearly scoping your environment and understanding control applicability.

Read Full Post

The Cybersecurity Maturity Model Certification (CMMC) Scoping Guide provides guidance on categorizing components within your authorization boundary. The Assessment Guides detail the requirements applicable to the system. This blog delves into the crucial intersection of system components and assessment objectives for CMMC Level 2 compliance.

We will review the process used to derive a scope of applicability from DISA STIGs and SRGs, and how it aligns with CMMC 2.0 scoping expectations. The resource enables leveraging DISA guidance to ensure control implementations provide adequate coverage. Identifying applicability reduces the risk of overstating compliance with NIST SP 800-171 requirements.

In this blog, we will discuss:

CMMC Scoping Guide - Component Categorization

The Cybersecurity Maturity Model Certification (CMMC) Scoping Guidance requires organizations to categorize components of their system. These categories revolve around where Controlled Unclassified Information (CUI) and Federal Contract Information (FCI) resides.

There are five potential categories to select from:

  • CUI Assets. Components processing, storing, or transmitting CUI.

  • Security Protection Assets. Components providing security functions or capabilities.

  • Contractor Risk Managed Assets. Components not intended to handle CUI but not  separated from CUI assets.

  • Specialized Assets. Specific types of technology eligible for enduring exceptions.

  • Out-of-Scope Assets. Separated from CUI through logical or physical means.

The CMMC Scoping Guide identifies three types of assets. These include:

  • People. Internal and external to the organization.

  • Technology. Cloud-based and on-premise. 

  • Facilities. Office buildings, data centers, and security operations centers (SOCs)

Since the scoping process depends on where CUI resides, organizations should first identify CUI Assets. Data flow diagrams show how systems receive, process, and distribute CUI. Next, identify components with logical or physical connections to CUI Assets. Categorize systems that provide security functions or capabilities as security protection assets.

Categorize any specialized assets from the list provided below:

  • Government Furnished Equipment. Equipment owned or leased by the government.

  • Internet of Things (IoT). Devices that contain hardware, software, firmware, and actuators. They connect, interact, and exchange data and information.

  • Industrial Internet of Things (IIoT). Sensors, instruments, machines, and other devices networked together. They use Internet connectivity to enhance industrial and manufacturing processes.

  • Operational Technology (OT). Programmable devices that interact with the physical environment. This includes components that manage devices that interact with the physical environment. 

  • Restricted Information Systems. Devices configured based on government security requirements used to support a contract.

  • Test Equipment. Devices used in the test of products, system components, and contract deliverables. 

Categorize components not intended to handle CUI as Contractor Risk Managed Assets. An alternative approach is to segment them into a separate security domain. This involves using logical and or physical separation techniques. Logical separation may include using boundary protection devices and information flow control mechanisms.

A segmented approach helps avoid raising the security posture beyond the required level. This ensures your organization optimizes resource allocation and eases the burden of CMMC compliance through informed scoping scenario analysis. Out-of-scope assets must have logical or physical separation from CUI Assets. In-scope assets require appropriate categorization and documentation within the CMMC boundary.

Once categorized, document each asset in an asset inventory. Create a network diagram of the CMMC Assessment Scope. If your facility protects CUI assets, document non-public areas of your facilities. These diagrams will assist the C3PAO in validating the Level 2 Assessment Scope (Step 1.3 of the CAP).

External Service Providers (ESPs)

An organization’s scope may also include external service providers (ESPs). ESPs may provision and manage IT and/or cybersecurity services. ESPs may include external people, technology or facilities. To meet the CMMC definition of an ESP, the ESP’s assets must contain either security protection data (SPD) or CUI.

ESP categories include those acting as a Cloud Service Provider (CSP) and those that are not. CMMC defines a CSP as an external company that provides cloud computing. The definition for cloud computing comes from NIST SP 800-145. Cloud computing enables on-demand network access to a shared pool of computing resources. They are often provisioned with minimal management effort or service provider interaction.

The applicability of requirements varies based on the categorization of ESPs. CSPs that handle CUI must adhere to the FedRAMP moderate standard. A memo published in January 2024 defines the standard for FedRAMP moderate equivalency.  CSPs must pass an assessment from FedRAMP-recognized Third Party Assessment Organization (3PAO). CSPs must achieve 100 percent compliance with the FedRAMP moderate security control baseline. Equivalency does not allow for operational plans of action and milestones (POA&Ms). CSPs must have corrected POA&M actions validated by the 3PAO as closed.

They must provide contractors using their services with a body of evidence (BoE) containing:

  • System Security Plan (SSP)

  • Security Assessment Plan (SAP)

  • Security Assessment Report (SAR)

CSPs that only handle security protection data are also considered within scope. CSPs that do not handle CUI or security protection data are not considered an ESP.

Some ESPs may not meet the definition of a CSP but handle CUI or SPD. In these cases, only the services provided by the ESP are within scope.

Image Source: CMMC Final Rule

Applicability and Allocation of Controls

NIST discusses control allocation in SP 800-37 and applicability in SP 800-53. The Risk Management Framework (RMF) defines a seven step risk mitigation process. Within each step, NIST prescribes tasks to provide structured actionable guidance.

Image Source: NIST SP 800-37 R2

The first step, prepare, promotes a consistent starting point for organizations. Task P-17 allocates security requirements to the system and its environment of operation. The environment of operation refers to the physical surroundings (i.e. facilities).

Systems may derive requirements from many sources, including:

  • Applicable laws

  • Executive Orders

  • Directives

  • Policies

  • Standards

  • Instructions

  • Regulations

  • Processes

  • Procedures

  • Organizational business case needs.

In the third step, select, organizations choose controls to meet requirements. Task S-3 allocates security controls to the system and its environment of operation.  NIST defines a control as a prescribed safeguard that mitigates risk. These safeguards help meet a set of defined security requirements. 

The goal of allocation is to conserve resources. System owners should identify efficient controls that deliver the required protection. The control implementation approaches shape the scope of applicability for each control.

Control Implementation Approaches

A system, the organization, or a combination of the two entities, may address a control. Appendix C defines three implementation approaches of SP 800-53 controls.

  • System (S). A control implemented by an information system through technical means.

  • Organization (O). A control implemented by an individual through non-technical means.

  • Combination (O/S). A control implemented by an organization, a system, or a combination of the two.

Organizations should consider the applicability of technical control to system components. NIST SP 800-53B provides the following guidance on applying scoping considerations to controls: 

The growing complexity of systems requires analysis in the implementation of security controls. Controls in the initial baselines may not apply to every component in the system. Components that support the security capabilities addressed by the controls are applicable. Organizations should apply controls to meet security requirements and achieve the security capability.

NIST provides an example consideration:

Organizations apply auditing controls to components of a system that provide auditing capabilities. They are not applied to every user-level component within the organization.

Applicability within CMMC

Department of Defense (DoD) guidance omits any discussion of applicability within CMMC. Instead, the CUI Scoping Guide CMMC Level 2 Scoping Guide advises full applicability to any CUI assets.

The absence of a discussion on applicability does not negate its allowance. We deduced this conclusion using the following arguments:

  1. Derived requirements from NIST 800-171 and CMMC originate from the moderate baseline of SP 800-53. The tailoring of controls into security requirements focused on protecting information confidentiality. If SP 800-53 controls have applicability, so should requirements derived from them.

  2. If CMMC permits applicability, assessors would discuss this concept. Here are three examples of assessors discussing applicability of specific requirements:

  • Nick DelRosso of DIBCAC discussing the applicability of IA.L2-3.5.3 

  • Matt Titcombe (CCA) of Peak InfoSec discussing the applicability of AC.L2-3.1.22

  • Amira Armond (CCA) of Kieri Solutions discussing the applicability of CM.L2-3.4.9. Since Amira’s discussion was at a paid event, we can’t post a link to her video.

  • Here are some snippets from her discussion:

    • You need to identify where you’re going to apply these requirements and how you’re going to meet them.

    • A policy is only effective if people know about it. So I need to make sure that my users and my IT staff know about the policy (CM.L2-3.4.9[a/b]).

    • For technical controls, I’m going to say that I need to apply this to my workstations. (CM.L2-3.4.9[c]).

CMMC Requirements for Facilities

The CAP is the official procedural guide for CMMC Third-Party Assessment Organizations (C3PAOs).  Step P.11 provides guidance on determining the assessment locations for control requirements. The CAP identifies 18 objectives that assessors should verify in-person.

This guidance gives us a good starting point to identify the facility-related Level 2 security requirements. If requirements applied to facilities, this list should contain them. This list may also include objectives applicable to other scope components. From this list, we scoped the following objectives to facilities:

  • CM.L2-3.4.5[d]: Enforce physical access restrictions associated with changes to the system.

  • MP.L2-3.8.1[c]: Safeguard paper media containing CUI.

  • MP.L2-3.8.1[d]: Safeguard digital media containing CUI.

  • PE.L1-3.10.1[b]: Limit physical access to systems to authorized individuals.

  • PE.L1-3-10.1[c]: Limit physical access to equipment to authorized individuals.

  • PE.L1-3-10.1[d]: Limit physical access to operating environments to authorized individuals.

  • PE.L2-3.10.2[a]: Protect the physical facility where the system resides.

  • PE.L2-3.10.2[b]: Protect the support infrastructure for organizational systems.

CMMC Requirements for People

Organizations may select efficient control implementations  while complying with their intent. There are many requirements that organizations may select non-technical control implementations. We identified the following control objectives as examples of those applicable to people:

  • AC.L2-3.1.6[b]. Ensure users use non-privileged accounts or roles when accessing nonsecurity functions.

  • AT.L2-3.2.1[c]. Make users of the system aware of the risks associated with their activities.

  • AT.L2-3.2.1[d]. Make users of the system aware of the applicable policies, standards, and procedures.

  • AT.L2-3.2.2[c]: Train personnel to carry out their assigned information security duties.

  • AT.L2-3.2.3[b]. Provide security awareness training on recognizing and reporting insider threats.

  • CM.L2-3.4.9[a]. Establish a policy for controlling the installation of software by users.

  • PS.L2-3.9.1[a]. Screen individuals before authorizing access to organizational systems containing CUI.

CMMC Requirements for Technology

Appendix C identifies all controls within the following domains as implemented through non-technical means:

  • Awareness and Training (AT)

  • Assessment, Authorization, and Monitoring (CA)

  • Incident Response (IR)

  • Maintenance (MA)

  • Media Protection (MP)

  • Physical and Environmental Protection (PE)

  • Personnel Security (PS)

  • Risk Assessment (RA)

While some technical aspects exist, these domains are not focused on technical controls. Available guidance from FedRAMP affirms this finding.

Combining this guidance, we looked for technical requirements within the following six domains:

  • Access Control (AC)

  • Audit and Accountability (AU)

  • Configuration Management (CM)

  • Identification and Authentication (IA)

  • System and Communications Protection (SC)

  • System and Information Integrity (SI)

Guidance from DISA STIGs/SRGs

The Defense Information Systems Agency (DISA) is part of the DoD. They publish Security Technical Implementation Guides (STIGs) for specific technology components. They also publish Security Requirement Guides (SRGs) for various types of system components.

Both STIGs and SRGs contain guidance for system owners to harden their systems. Most of this guidance maps to NIST SP 800-53 controls. We leveraged our prior work cross-walking SP 800-53 to SP 800-171A objectives. This enabled the creation of an open source CMMC applicability matrix.

A data flow diagram of CUI should help inform the CMMC authorization boundary. It serves as a foundation input to any unified scoping guide approach. The workbook allows practitioners to define and categorize components within the boundary. A dependent drop-down allows for the selection of relevant STIGs or SRGs.

Many STIGs or SRGs may apply to a single component.  The workbook enables the selection of STIGs/SRGs based on the component's capabilities. For example, a firewall may also incorporate a virtual private network (VPN) . Selections within this tab will associate other relevant STIGs/SRGs with each component.

The workbook also identifies components that may have installed applications. Practitioners may incorporate STIGs for installed application into the component that hosts them. Practitioners may also assess STIGs for applications by themselves.

The output of the workbook is a Power Query Pivot table. When refreshed, a user can identify assessment objectives that align with DISA guidance. STIG guidance provides specific instructions and testing methods. Guidance from SRGs may only cite the relevance of the requirements.

This resource should make it easier for organizations to leverage DISA guidance. There are two important limitations of this resource:

  1. Cloud Service Providers (CSPs) should provide their own shared responsibility matrix (SRM). The SRM should define requirements delegated to the organization using the cloud service.

  2. DISA guidance only addresses component configurations. Components may provide technical capabilities beyond those described in the STIG or SRG.

Integration with K2 GRC

We designed this resource to help identify the applicability of technical CMMC requirements. DISA has other tools that help automate the assessment of these technical requirements. K2 GRC APIs can ingest scans from security content automation protocol (SCAP) tools to support your CMMC program.

Many of our customers use our platform to prepare form a CMMC assessment and/or DIBCAC high. Before using K2 GRC, their SSP didn’t define the applicability of technical controls. This led to some uncomfortable discussions with DIBCAC during their assessments. Our platform addresses this critical gap by enabling objectives to have a scope. Whether they apply to Controlled Unclassified Information (CUI) or Federal Contract Information (FCI). Practitioners may write unique implementation statements for component scope to objectives.

Conclusion

Controls should mitigate risk. Failing to understand the applicability increases the risk of an assessor finding gaps during CMMC certification. STIGs help mitigate that risk but it requires translating to NIST SP 800-171. Consider downloading this resource to supplement DoD guidance for your CMMC Level 2 certification.

It's time to protect your bottom line.