When it comes to the US Department of Defense’s (“DoD”) new Cybersecurity Maturity Model Certification (“CMMC”) program, one of the biggest questions many government contractors wrestle with is: “Is the System Security Plan (“SSP”) they I have to create as part of that process Controlled Unclassified Information (“CUI”)?” The answer depends on who is asking the question.
We get into the details below, but the short answer is “no”, at least from the contractor’s perspective. Neither the SSP nor the artifacts collected as part of the SSP creation or CMMC assessment processes meet the definition of CUI.
The answer changes to “yes” when the government receives a copy of the SSP. Or if the contractor receives another contractor’s SSP from the government.
Definitions are Important
When it comes to determining whether any information is CUI, it all comes down to one fundamental question: does the information meet the definition of controlled unclassified information?
It is important to remember that the CUI program is administered by the National Archives and Records Administration (“NARA”). They play several critical roles in the CUI program, including setting the definition of what constitutes CUI. According to NARA’s CUI Glossary, CUI is:
“…information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls.”
CUI Definition – NARA CUI Glossary
Let’s unpack that definition and analyze whether a contractor’s SSP or assessment artifacts are CUI. There are really only two ways information can become CUI. The first way information can be CUI is if the information is created or possessed by the government. Since the SSP is in the contractor’s environment and was not created or possessed by the government, it clearly cannot meet this requirement.
The other way information can be CUI is if the information was created or possessed by an entity on behalf of the government. The SSP has never been possessed by the government, so it cannot meet that requirement. The SSP is also not created for the Government. It is created for the contractor to help the contractor maintain their systems.
Since the SSP does not meet the definition of CUI while in the contractor’s own systems (or systems operated on behalf of the contractor), the SSP cannot be CUI.
Changing Perspectives Changes the Answer
The analysis gets a little more complicated when it comes to information the contractor submits to the government. As an example of when this can arise, although the Office of the Undersecretary for Defense for Acquisition and Sustainment has repeatedly said that DoD should never ask for an SSP, we have heard of cases where contractors have been required to provide the government with copies of the contractor’s SSP. If the contractor is required to give the government the SSP, is the SSP CUI?
The short answer is yes…at least from the government’s perspective. And that’s a good thing. Given the sensitive nature of the information in the SSP, most contractors would want the government to protect their SSP as CUI.
Digging Deeper
To understand why SSP qualifies as CUI when the government receives it, let’s look at the CUI definition again. In this case, the SSP is information the government possesses since it was given to the government by the contractor. So, it meets that basic threshold requirement.
But notice that there’s another clause buried at the end of the definition’s first sentence. It requires that the information be of a type that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. How do we determine that?
We determine whether the SSP is information that the government must protect by looking at the category list in the CUI Registry. Unfortunately, this process is not for the faint of heart. We have to dig pretty deep into at least some of the regulations before we can get to an answer. For example, in some cases we have to ensure not only that the information falls into a proper category, but also that it has been submitted to a relevant agency.
Where does an SSP Fall in the CUI Registry?
Before we dig in, let’s look at one other definition: critical infrastructure. Critical infrastructure is defined in the USA Patriot Act of 2001 (42 U.S.C. 5195c(e))) as “systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters.” DoD contractors, and especially those in the Defense Industrial Base, have generally been held to be part of the nation’s critical infrastructure.
With that in mind, there are four leading candidate CUI categories under which a DoD contractor’s SSP might fall, all under the Critical Infrastructure heading: General Critical Infrastructure Information, Information Systems Vulnerability Information, Physical Security, Protected Critical Infrastructure Information. Let’s look at each of these in turn.
Protected Critical Infrastructure Information
We’ll start by looking at Protected Critical Infrastructure Information. Scrolling down to near the bottom of the description in the CUI registry, we see that this information is CUI because 6 CFR 29 (Section 29 of Part 6 of the Code of Federal Regulations) says the information must be treated in a specific manner (making it CUI Specified). Opening 6 CFR 29, we see that Section 2.1(a) reads: “This part implements sections 211 through 215 of the Homeland Security Act of 2002 (HSA) through the establishment of uniform procedures for the receipt, care, and storage of Critical Infrastructure Information (CII) voluntarily submitted to the Department of Homeland Security (DHS).” We also see that, Section 29.1(b) says “Scope. The regulations in this part apply to all persons and entities that are authorized to handle, use, or store PCII or that otherwise accept receipt of PCII.” PCII, in turn, is defined as information voluntarily submitted to the Department of Homeland Security .
This means that, to qualify as Protected Critical Infrastructure Information, information must be submitted to DHS. In the scenario we are analyzing, the contractor is submitting their SSP to DoD, not DHS. Therefore, the information will not qualify as CUI under this CUI category.
Physical Security
Next let’s look at Physical Security. All SSPs, especially those created based on NIST SP 800-171 or NIST SP 800-53, should have a physical security component to them. So there is a chance that the contractor’s SSP could qualify as CUI under this CUI category.
Scrolling to the bottom of the CUI category page, we see that there are two potential sources for a finding that the contractor’s SSP is CUI: GSA Public Building System P 3490.3, and The Risk Management Process for Federal Facilities: An Interagency Security Committee Standard. A quick review of both sources shows that they focus on protecting federal facilities. Since the contractor’s SSP focuses on protecting the contractor’s own facilities, and since those facilities are inherently not federal facilities, the contractor’s SSP cannot qualify as CUI under this category either.
General Critical Infrastructure Information
Now let’s look at General Critical Infrastructure Information. The CUI Registry refers us to Presidential Policy Directive PDD-21 for clarity on this CUI category.
PDD-21 creates “…a national unity of effort to strengthen and maintain secure, functioning, and resilient critical infrastructure, and applies to all federal agencies.” PDD-21 establishes three strategic initiatives, including enabling effective information exchange between critical infrastructure providers and the federal government. PDD-21 also notes that “Greater information sharing within the government and with the private sector can and must be done while respecting privacy and civil liberties. Federal departments and agencies shall ensure that all existing privacy principles, policies, and procedures are implemented consistent with applicable law and policy and shall include senior agency officials for privacy in their efforts to govern and oversee information sharing properly.” PDD-21 does not contain other provisions that explicitly address the protection of information provided to the government by contractors or other critical infrastructure providers.
Privacy protections generally focus on protecting personal information, such as names, phone numbers, social security numbers, etc. Since an SSP does not typically contain much privacy information, PDD-21’s focus on protecting privacy makes it less likely that a contractor’s SSP will be considered CUI under this CUI category. Contractors may be able to assert civil liberties or other arguments that could be persuasive, but that is a longer process and may not be successful.
Information Systems Vulnerability Information
Finally, let’s turn to Information Systems Vulnerability Information. All SSPs describe the architecture of the underlying systems and could disclose vulnerabilities that are inherent in the design or execution of the system. So, there is a chance that the SSP could qualify as CUI under this category.
Scrolling down, we see two sources for a CUI finding: 44 USC 3554 and 44 USC 3555(f). 44 USC 3555(f) says that “Agencies and evaluators shall take appropriate steps to ensure the protection of information which, if disclosed, may adversely affect information security. Such protections shall be commensurate
with the risk and comply with all applicable laws and regulations.” Note that this requirement is not limited to protecting only federal information. Further, 44 USC 3554(a)(1)(A)(i) makes each agency head responsible for “…providing information security protections commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of—(i) information collected or maintained by or on behalf of the agency…” (emphasis added).
An SSP received by DoD is information which is collected or maintained by or on behalf of the agency. It also contains information which, if disclosed, may adversely affect information security. Therefore, the SSP will likely be CUI and the government should mark it as CUI//ISVI when it is received.
Conclusion
A contractor’s own SSP cannot be CUI while it stays under the contractor’s control because it does not meet the definition of CUI. If the contractor gives the SSP to the government, the appropriate government agent should determine that the SSP is CUI//ISVI and should cause it to be marked as such. If the government sends the SSP back to the contractor, even though it is properly marked as CUI by the government, the contractor does not have to treat it as CUI because it is the contractor’s own information. The simple fact of receiving back one’s own information does not transform the information into CUI from the contractor’s perspective. By contrast, if a different contractor receives a copy of the original contractor’s SSP from the government, that different contractor is receiving CUI and must treat and protect it accordingly.