This is an often-argued topic within CMMC discussions, so pour a cup of coffee and enjoy! Spoiler: Scoping does not mean all controls apply everywhere!
One of the biggest misconceptions with scoping is that if something is “in scope” then every control will be applicable across the entire boundary of the assessment. This is an incorrect assumption and the key takeaway from this article is that common sense must prevail, since it is technically infeasible to apply all controls uniformly as the examples in this article will demonstrate.
To answer the “why?” question, as to why this is important to keep reading, the failure to adequately perform due diligence in scoping activities may lead to every system, application and service in your organization to be considered in scope and require applicable statutory, regulatory and/or contractual controls. The old adage of “if you fail to plan, you plan to fail” is very applicable in this scenario, so taking the time to document assets and data flows is of the utmost importance to ensure an accurate understanding of the people, processes and technology involved exists.
What Is Your Scope?
Depending on what compliance obligations you face, defining the scope can take on different names, but for the most part the nomenclature is interchangeable in terms of defining where controls must be appropriately applied:
Card Data Holder Environment (CDE)
Statement of Applicability (SoA);
And so on.
Scoping generally is a defined as a process of identifying all the applicable systems, applications and processes that store, transmit and/or process the data that is associated with the compliance obligations. Think of it as an inventory of all things that require administrative, physical and/or technical security controls to be applied.
This inventory helps define the boundary that is your “security perimeter” to establish what is in-scope or out-of-scope for systems, applications, services, etc. This boundary defines not just the “Sensitive Data Environment (SDE)”, but the people, process and technologies that influence the security of the SDE, which would also require applicable security controls.
What Is Your Applicability?
When you look at the breath of cybersecurity and privacy controls that an organization is obligated to comply with, the controls are administrative, technical and/or physical. This means that there may be controls that are not applicable to certain systems, applications and/or processes.
Example 1: Network firewall
A network firewall is a technical control, where certain other controls would be applicable, such as Multi-Factor Authentication (MFA), access control, secure baseline configurations and patch management.
Since a network firewall is a device, it not capable of having end user training, completing a Non-Disclosure Agreement (NDA) or conducting incident response exercises.
Example 2: User awareness training
User awareness training is an administrative control that is focused on personnel, such as employees and applicable third-parties who will be interacting with the organization’s systems and data. NDAs, threat intelligence awareness, acceptable use notifications are all applicable to individuals.
Since an individual is not a device, an individual is not capable of having a secure baseline configuration applied, be scanned by a vulnerability assessment tool, or have missing patches installed.
Example 3: Incident Response Plan (IRP)
An IRP is an administrative control that is used to documented a process and is used as a tool to guide incident response operations.
Since an IRP is a not an individual or technology, it cannot sign a NDA, have MFA or be patched.
How Should I Define Applicability?
The best solution is to create a matrix that can apply the appropriate controls to the correct people, processes and technologies (specific to your organization) to help identify the correct scope for the implementation of controls. If you take a look at Annex E in the Unified Scoping Guide there is an example of a control applicability matrix for CMMC.