As Cyber Regulators Rush Toward New Rules, Shifting Foundations May Complicate Compliance

April 1, 2024

These days, cyber regulators are in a hurry. Commentators have observed, the “federal government is quietly directing a seismic shift in the economy” with new mandates.[1] Ann Neuberger, Deputy National Security Advisor for cyber, recently said in an interview[2] that despite dozens of new cyber regulations and Executive Orders, “I want it to go faster.” Developing effective cyber regulations requires careful consideration, but with the pace and scope of new proposals it can be hard for regulators or their targets to do that. Haste and ambitious goals can lead to truncated analysis and cut corners that affect everything from who may be covered by a rule, to dismissing unintended consequences, to overly optimistic cost-benefit analyses. It also can lead to heavy reliance on third-party frameworks and other agencies’ definitions, which may not be a good fit for the regulatory purpose at hand.

New cybersecurity incident reporting rules proposed by the Cybersecurity and Infrastructure Security Agency (CISA) illustrate this trend.[3] This analysis focuses on one aspect of those proposed rules to show how an agency’s use of definitions, standards, and approaches from other agencies and sources can create a complex patchwork of regulations and obligations.

What is “Incorporation by Reference”?

In its most formal use, agencies can (and are encouraged by federal law to) use third-party standards when they need what Notre Dame Law Professor Emily Bremer describes as a “technical standard to flesh out a regulatory requirement.”[4] Agencies do this by getting approval from the Office of the Federal Register (OFR) to use an appropriate third-party standard in a proposed regulation. As Professor Bremer has pointed out, this is commonly done in various settings, like state environmental regulations that the U.S. Environmental Protection Agency must rely on, or the Federal Aviation Administration’s incorporation by reference of aircraft service information or maps.

Professor Bremer has observed that “sometimes the incorporated materials are what are commonly known as private or voluntary ‘standards.’ These types of standards are “developed by industry groups or nongovernmental organizations and are relied upon widely by many companies in the design of their products and processes.”[5] There are many of these, like Occupational Safety and Health Administration rules that incorporate safety codes for industrial lighting, elevators, welding, signage, ventilation, and other standards created by organizations like the American National Standards Institute (ANSI).[6]

There is also the concept of dynamic incorporation, which is disfavored in the law but attractive to regulators: “dynamic incorporation is not keyed to a particular version of the referenced material, but rather incorporates whatever happens to be the most recent version of the material. Dynamic incorporation is attractive because the agency need not take any action to update the regulation when the incorporated material is revised; the most recent version is always and necessarily the one incorporated by reference.”[7] But, Professor Bremer observes, “dynamic incorporations are prohibited. That is, agencies are required to identify the specific version of any material incorporated by reference.”[8]

Why Does This Matter for Cyber?

In the cyber arena, we are seeing incorporation by reference accelerate and move well beyond using technical information or formal “standards” like those from ANSI. We see agencies reach for and lean on definitions and approaches developed by the National Institute of Standards and Technology (NIST), as well as other agencies and third-party frameworks. NIST is particularly interesting because its information technology and cyber materials have traditionally been developed for federal agencies under specific federal laws, but its work has in recent years expanded to offer more guidance to the private sector, as in its seminal Framework for Improving Critical Infrastructure Cybersecurity, now in its third iteration.[9] And we see regulators use approaches that were designed to be “voluntary” and flexible guidance, such as new and evolving Cross-Sector Cybersecurity Performance Goals from DHS.

CISA Cyber Mandates Provide a Case Study

The newly proposed CISA cyber mandates rely a great deal on other definitions and approaches. A key question facing the private sector is who will be covered by the regulations. There are dozens of definitions and approaches that companies will have to analyze.

One example of the challenges of incorporation by reference is CISA’s proposed definition for Cloud Service Providers (CSP), in proposed new 6 C.F.R. 226.1.[10]

CISA’s NPRM proposes to define a CSP as “an entity offering products or services related to cloud computing, as defined by the National Institute of Standards and Technology in Nat’l Inst. of Standards & Tech., NIST Special Publication 800-145, and any amendatory or superseding document relating thereto.”[11] Putting aside what it might mean for a product or service to “relate to” cloud computing, and the complexities of the dynamic incorporation of future unspecified “superseding documents” from NIST, the core underlying NIST definition presents its own challenges. A company wondering if it will be a treated as a CSP will have to look up NIST SP 800-145.[12] That company and its lawyers (and those of its customers) may make some surprising observations.

First, 800-145 was written in 2011, in advance of modern cloud service offerings. NIST says that an “essential” element of a cloud service is “metering,” which NIST says is typically on a “pay-per-use or charge-per-use basis.” It is not clear that this, or other identified characteristics, remain salient.
Second, 800-145 expressly notes its limitations: “Cloud computing is an evolving paradigm. The NIST definition characterizes important aspects of cloud computing and is intended to serve as a means for broad comparisons of cloud services and deployment strategies, and to provide a baseline for discussion from what is cloud computing to how to best use cloud computing.“
Third, the definition was “prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis.” Federal agencies have to comply with FISMA, and have different compliance needs than the private sector, so this may not make it a good basis for a new mandate.
Fourth, it may be confusing as a basis for regulatory triggers. NIST 800-145 explains that “[t]his cloud model is composed of five essential characteristics, three service models, and four deployment models.” Each of these have a description, but it is not clear how the characteristics, service models, and deployment models may be elements of a regulatory definition or how they should be used by a company assessing its regulatory status.

Other regulated entities and sectors will face similar challenges. In addition to the references to NIST, CISA’s NPRM bases many definitional triggers on other regulatory regimes’ treatment. The treatment of the Communications Sector relies on a few broad definitions in the Communications Act,[13] and expands covered entities to those providing “one-way” and “two-way” services and other classifications. Given that regulatory classifications are sometimes disputed or left to private entities’ determination, this may create uncertainty. As for the Financial Services Sector, CISA proposes to determine application of the rules, proposed 6 C.F.R. 226.2(7),[14] by reference to an array of (more than 20) regulatory regimes, including the broad definition of money services business in 31 C.F.R. 1010.100(ff) which is broad, serves other regulatory purposes, and whose application has been litigated.[15]

CISA’s approach may create confusion about application of the new rules. Notably, the NPRM states that “CISA anticipates that the process for an entity to determine if it is within a critical infrastructure sector will usually be a relatively straightforward exercise.”[16] But the NPRM spends a great deal of time explaining its varied use of size-based and sector-based criteria, as well as why it is relying on other documents, profiles, and partnerships beyond the Presidential Policy Directive-21 that Congress specified it should use, to make rules about what entities will be covered.

For example, the agency says that it has relied on Sector Specific Profiles (SSPs) that were created in various venues under the National Infrastructure Protection Plan (NIPP) program. The NPRM notes that the SSPs were often managed by “self organized and self-governed councils”[17] – though these councils may be underinclusive in representation and were not created by Congress. The profiles may have been helpful to core players in those sectors, but they do not appear to be the sort of technical standard or clear regulation that is a solid foundation for regulation. Further, many of the SSPs are approximately 10 years old and may not reflect the evolution of the sector or changes in technology. The NPRM itself notes that the SSPs were to be updated every four years, but “to date, none of these plans have been updated.”[18] Use of SSPs also illustrates the “mismatch” effect already alluded to. SSPs often focused on the identification of core functions and operational issues, and not on providing a framework for reliably predicting or scoping what entities would be considered to be “critical infrastructure.” For example, the “IT Sector-Specific Plan (ITSSP)”[19] in 2016 identified its purpose “to guide and align the Sector’s efforts to secure and strengthen the resilience of critical infrastructure and describe how the IT Sector contributes to national critical infrastructure security and resilience, as set forth in Presidential Policy Directive 21 (PPD-21). This SSP tailors the strategic guidance provided in the 2013 National Infrastructure Protection Plan (NIPP 2013) to the unique operating conditions and risk landscape of the IT Sector.” It did not purport to identify entities in the sector or provide a reliable basis for doing so.

CISA’s incorporation of frameworks, profiles, and third-party documents to guide the application of binding new rules that carry penalties for noncompliance may raise challenges. This approach may not offer the certainty and predictability that CISA predicts and that regulated entities seek.

Is This a Problem?

There is an understandable desire for regulators to build on things someone else has already done. This can be a good thing if it results in expanded use of good ideas and frameworks. It can be harmful if the regulator takes an idea or concept created for one use and imports into a different context for which it is ill-suited or – worse – fails to consider the similarities and differences. Use of unclear or shifting definitions and approaches can be unfair to regulated entities who lack predictability. Commenters have advised the Federal Acquisition Regulation Council, for example, that their recent proposed cyber rule, FAR Case No. 2021-0017, would require contractors “to comply with future versions of guidance documents, such as ‘The Minimum Elements for a Software Bill of Materials’ guidance document published by the U.S. Department of Commerce, even when those versions are not in effect at the time of contract award and are not incorporated into the contract by a modification issued by the contracting office.”[20] Likewise, the FCC has heard from commenters that it should not incorporate DHS Cross-Sector Cybersecurity Performance Goals[21] into new cyber mandates because the document itself will be revised regularly, and DHS has said it will be developing additional sector-specific performance goals over time.

Cyber regulators should consider the wisdom of building new regulatory mandates on definitions and approaches that were not designed for use as mandates. Federal law is supposed to exert discipline over “incorporation by reference,” but in practice agencies appear to overlook the supposedly limited use of this regulatory tool and base major new regulatory structures on frameworks, definitions, and standards that may in fact be poor foundations. This may be because the document being incorporated is not static and will change, or because the definition or standard was created for a different purpose and may not make sense to use in the new regulatory context. Or, the underlying document, definition, or approach is outdated or of unclear application in the new setting.

As cyber regulators call for more consequences and enforcement, it is also a matter of fundamental fairness. As Neuberger has said, the government has made a “shift in our entire approach, and we got it done using existing regulators. We’re not treating cyber as a stand-alone thing, but we're leveraging systems expertise and matching it with the enforcement action.”[22] The government is threatening enforcement actions (such as costly regulatory investigations, referrals of contractors for suspension and debarment, and False Claims Act liability) based on compliance with unclear and non-static expectations.

What Should Come Next?

The foregoing caution is not to suggest that cyber regulators should avoid NIST documents, SSPs, cyber frameworks, best practices or third-party standards and frameworks. To the contrary, those materials and related prior work are essential to develop intelligent regulation. The government should rely on decades of cyber policy and standards that have been borne of consensus and technical expertise, and that have vital flexibility. But the challenges of dynamic incorporation, regulatory mismatch, and lack of clarity should be explicitly recognized. The private sector deserves a degree of regulatory humility and recognition of compliance challenges from the government’s approach, and the government should work to create stable legal regimes that do not undermine decades of operational collaboration on cyber.

This is even more vital where the regulatory paradigm is being changed deliberately to be more punitive and seek robust enforcement. If the government threatens companies for noncompliance with expectations, then it is essential that agencies be clear about expectations and not create unnecessary confusion for regulated entities that must attempt to understand and apply a rapidly shifting and overlapping set of regulations. Better still, the government should create safe harbors and liability protections that shield companies from punishment for good faith mistakes and misunderstandings. In the meantime, regulators and OMB should carefully consider their use of standards, definitions, and frameworks in new mandates, including the new CIRCIA rules.

[1] https://fortune.com/2023/12/20/quiet-cybersecurity-revolution-economy-us-allies-new-threats-regulation-politics-tech-eric-noonan/.

[2] https://www.wired.com/story/anne-neuberger-cybersecurity-q-and-a/

[3] https://www.wiley.law/alert-CISAs-Proposed-Cyber-Incident-Reporting-Requirements-Would-Hit-a-Range-of-Industries-and-Sectors.

[4] https://pennreg.org/codes-standards/wp-content/uploads/sites/4/2022/08/Bremer-IBR-Teaching-Guide.pdf.

[5] Id.

[6] https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.6.

[7] Incorporation by Reference in an Open-Government Age, 36 HARV. J.L. & PUB. POL’Y 131-210 (2013), available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2127288

[8] Id.

[9] https://www.nist.gov/cyberframework.

[10] CISA NPRM, March 27, 2024, available at https://www.cisa.gov/news-events/news/cisa-marks-important-milestone-addressing-cyber-incidents-seeks-input-circia-notice-proposed

[11] Id.

[12] NIST SP 800-145, available at https://doi.org/10.6028/NIST.SP.800-145.

[13] See proposed 6 C.F.R. 226.2(b)(2) in CISA NPRM

[14] See proposed 6 C.F.R. 226.2(7) in CISA NPRM

[15] CISA NPRM p. 415

[16] CISA NPRM p. 120

[17] CISA NPRM footnote 168

[18] See NPRM footnote 167; see also notes 172, 173, 174.

[19] https://www.cisa.gov/sites/default/files/2023-01/nipp-ssp-information-technology-2016-508 %281%29.pdf