For example, the proposed rule provides that it is intended to protect CUI wherever it resides.¹ As the proposed rule states, the new proposed contract clause, 48 CFR 3052.204-7x, must be included in solicitations where:

(1) Contractor and/or subcontractor employees will have access to CUI;

(2) CUI will be collected or maintained on behalf of the agency; or

(3) Federal information systems, which include contractor information systems operated on behalf of the agency, are used to collect, process, store, or transmit CUI.

Therefore, the new proposed contract clause requiring safeguarding of CUI would arguably apply to federal contractors that maintain CUI on their own information systems incidental to the performance of a DHS contract, in addition to those federal contractors that operate an information system on behalf of DHS that is used to collect, process, store or transmit CUI. The confusion arguably arises, in part, from the statement in the proposed rule that the proposed regulation applies to “any situation where a contractor and/or subcontractor employees may have access to CUI.” Clearly many contractors have access to CUI and maintain CUI on their own systems in order to perform a federal government contract.

Neither does the definition of a Federal Information System clearly segregate contractor responsibilities under the proposed contract clause. Federal Information System is defined as “an information system used or operated by an agency or by a contractor of an agency or by another organization on behalf of an agency.” This definition is broad enough to encompass a contractor’s information system. However, the clearest statement of what DHS intends may be footnote 5 in the proposed rule. This footnote acknowledges that NIST Special Publication (SP) 800-171 recommends safeguarding requirements to protect CUI on “nonfederal information systems”. The footnote continues to contrast the purpose of the current rulemaking: “the information system security requirements in this proposed rulemaking are focused on Federal information systems, which include contractor information systems operating on behalf of an agency.” However, the proposed rulemaking does not define “nonfederal information system”, nor clearly define a “federal information system.” In sum, the proposed rule and contract clause do not establish clear boundaries for the scope or application of the proposed safeguarding requirements.

Significantly, clarity was in reach. While the proposed rule uses the same definition of Federal Information System that is used in the National Archives and Records Administration (NARA) agency-wide CUI regulation, 32 CFR 2002, one clarifying definition was omitted by DHS. The NARA CUI regulation provides that an information system operated “on behalf of an agency occurs when a non-executive branch entity uses or operates an information system or maintains or collects information for the purpose of processing, storing, or transmitting Federal information, and those activities are not incidental to providing a service or product to the Government.” (emphasis supplied). An even clearer boundary could have been established by defining a non-federal information system that maintains CUI in the same clear manner as the NARA CUI regulation. The NARA CUI regulation provides that “when a non-executive branch entity receives Federal information only incidental to providing a service or product to the Government other than processing services, its information systems are not considered Federal information systems. NIST SP 800-171 … defines the requirements necessary to protect CUI” on such non-federal systems.² In sum, this type of clarifying language in the proposed rule, and within the proposed DHS contract clause, would have removed much of the lack of clarity in the proposed rule.

The flaws in the proposed rule are exacerbated by the incorporation of DHS policies included on its website. These policies are most suitable for contractors operating a system on behalf of DHS, rather than a nonfederal system that maintains CUI incidental to the performance of a contract for goods or services. Such policies, to the extent applicable to a particular procurement, may more reasonably be included in the solicitation. Additional flaws in the proposed rule relate to the fact that the proposed rule lists CUI categories not included in the CUI Registry. The CUI Registry is the exclusive list of the types of information that qualify as CUI: “Agencies may use only those categories or subcategories … published in the CUI Registry to designate information as CUI.” 32 CFR 2002.12(b). DHS must submit additional categories of CUI to NARA for approval and publishing. Id.

Significantly, the comment period for the proposed rule has been extended to April 19, 2017. Comments are easy to submit online. (Search for DHS-2017-0006 for the proposed rule and the submission of comments.) Some have asked DHS to delay or suspend the rulemaking. One of the best reasons for delay is the anticipated rulemaking by NARA, which is expected to propose a uniform procurement regulation for safeguarding CUI agency wide.

Turning to the substance of the proposed rule, federal contractor covered by the proposed rule must hold an agency issued “authority to operate” (ATO) at the required security level, which will be at least at the medium risk impact level. The proposed rule is reasonably clear concerning the threshold requirements and steps required to obtain an ATO. The contractor must submit a substantial Security Authorization Package, in conformity with NIST SP 800-53, that has been validated by an independent third party. Federal contractors that have been through the FedRAMP process, required to provide cloud services to the Federal government, using an independent assessment by an accredited third party assessment organization will have an advantage, as safeguarding requirements overlap, depending upon the security impact achieved through a FedRAMP provisional ATO or an agency ATO. Likewise, contractors with an ATO from an agency other than DHS will also have an advantage. Those who have neither and wish to compete for a covered DHS contract should consider becoming FedRAMP compliant, especially as it typically takes several weeks to assemble a Security Authorization Package.

Additional requirements under the proposed rule include:

• Government Security Reviews. Security Reviews may be randomly conducted by DHS, the Office of Inspector General, or their designees. The federal contractor must provide access to all facilities, systems, and data used or collected in the performance of a covered contract.
• Continuous System Monitoring. Although all ATOs will require continuous system monitoring, the proposed rule expressly requires such monitoring as well as the storing of all continuous monitoring data for a period of at least one year from the date such data was created. The Government may also elect to conduct continuous monitoring with its tools and facilities.
• Incident Reporting. All “known or suspected incidents” must be reported in accordance with 4300A Sensitive Systems Handbook, Attachment F, Incident Reporting, and the contracting officer and contracting officer representative must be notified. A known or suspected incident is not defined. However, the Security Authorization Package will require an incident reporting protocol and procedure, as well as details on the procedures to be used for incident response, including identifying incidents, isolating and mitigating the impact of incidents, and reporting incidents.
• Timing of Incident Reporting. A known or suspected incident involving personally identifiable information (PII) or sensitive personally identifiable information (SPII), as such terms are defined in the proposed regulation must be reported “within one hour of discovery”. All other incidents must be reported within eight hours of discovery.
• Investigation of Incidents. While the contractor must investigate incidents, so too will the government, including law enforcement. The contractor must preserve all relevant data, including images, log data, and event information, and must preserve and protect images of known affected information and all relevant monitoring/packet capture data must be retained for 90 days from the date an incident is reported and be provided to the Government upon request.
• Notice to Individuals. A contractor must have notice procedures and must notify individuals whose PII or SPII is involved in an incident, only if requested by the contracting officer. The notice must be coordinated with the contracting officer, although the proposed rule includes specific content that must be included in the notice. If the contracting officer directs notice to individuals, the contractor has five days to comply.
• Credit Monitoring Services. A contracting officer may direct a contractor to provide credit monitoring services to individuals if an incident involves PII or SPII.
• Sanitization of Systems with CUI. Contractors must comply with NIST SP 800-88 on sanitizing CUI on its systems and return CUI to the Government upon termination of a contract. The contractor must certify that sanitization has been accomplished, following the NIST SP 800-88 template.
• Subcontractors. The proposed contract clause, 48 CFR 3052.204-7x, must be flowed down to all subcontractors and lower tier subcontractors.

In conclusion, while the overall scope and application of the proposed CUI is flawed, the substantive provisions related to the ATO process and the other specific requirements related to incident reporting and response will likely be incorporated into a final rule at some point in time. The timing of a final DHS CUI rule may be deferred not only to correct the flaws in the proposed rule, but also because DHS has not yet issued its anticipated cybersecurity policy, and President Trump has not yet issued a cybersecurity policy or executive order on CUI. Nor has NARA yet issued its promised proposed Federal Acquisition Regulations and contract clause on protecting CUI on both federal and non-federal information systems. While the fate of the proposed DHS rule is uncertain, contractors now have additional insight into DHS’ goals in safeguarding CUI. There is little doubt that a final rule will rely on the NIST frameworks for CUI, as set forth in NIST SP 800-171.1 for non-federal information systems, and NIST SP 800-53, due to be released in rev 5 this year, for contractor operated federal information systems.

1. Fed Reg. Vol 82, No 12 at 6438-6439 (January 19, 2017) (the “Rule”). 

2. The NARA CUI regulation provides that “Agencies must use NIST SP 800-171 when establishing security requirements to protect CUI’s confidentiality on non-Federal information systems (unless the authorizing law, regulation, or Government-wide policy listed in the CUI Registry for the CUI category or subcategory of the information involved prescribes specific safeguarding requirements for protecting the information’s confidentiality, or unless an agreement establishes requirements to protect CUI Basic at higher than moderate confidentiality). While NARA’s CUI regulation differentiates between “CUI Basic” and CUI Specified”, the proposed DHS rule uses the general definition of CUI. The proposed rule notes that the solicitation will specify the specific security requirements required for a proposed contract. Rule at 6437.