The draft amendment to the Code itself is just 10 pages long (pp. 123-133), pp. 1-123 are the analysis, a total of 133 pages [1].
§ 226.2 Applicability (12) on p. 125 covers most IT/SaaS companies (any SW that has an OAuth2 client lib dependency seems to hit sub-clauses (ii)(C) and (ii)(D)) (emphasis mine):
(12) Information technology entities.
The entity meets one or more of the
following criteria:
(i) Knowingly provides or supports
information technology hardware,
software, systems, or services to the
Federal government;
(ii) Has developed and continues to
sell, license, or maintain any software
that has, or has direct software
dependencies upon, one or more
components with at least one of these
attributes:
(A) Is designed to run with elevated
privilege or manage privileges;
(B) Has direct or privileged access to
networking or computing resources;
(C) Is designed to control access to
data or operational technology;
(D) Performs a function critical to
trust; or
(E) Operates outside of normal trust
boundaries with privileged access;
(iii) Is an original equipment
manufacturer, vendor, or integrator of
operational technology hardware or
software components;
(iv) Performs functions related to
domain name operations;
Also, would not hurt if the draft was written in the BLUF fashion [2], with the 10 pages of the proposed law followed by 123 pages of the analysis.
226.2 Applicability.
This part applies to an entity in a critical infrastructure sector.
So as long as you aren't a "Submarine cable licensee
required to report outages to the Federal Communications Commission under 47 CFR 4.15" or a "A systems compliance and integrity entity, security-based swap dealer, or security-based swap data repository regulated by the Securities and Exchange Commission under Regulation Systems Compliance and Integrity or Regulation Security-Based Swap Regulatory Regime, 17 CFR part 242"
You quoted (2)(iv) and (7)(v) quite selectively. There are 16 items in that list and the text above the list clearly says that the specific sector (i.e. the criticality of the sector) of your company is irrelevant as long as you meet at least one criteria:
(b) Meets a sector-based criterion.
Meets one or more of the sector-based
criteria provided below, regardless of
the specific critical infrastructure sector
of which the entity considers itself to be
part:
From what I can tell its actually 133, the rule not the law.
The first five pages are the table of contents, definitions of acronyms, and then about a 10 page explanation of background and what CISA is required to do by the law. Starting on 98 there is also an analysis, as required by law, of who is affected, what the cost of implementation is, and a wide variety of other details to inform the public on why this on rule and this way. That cost includes what it will cost CISA to implement the rule (e.g., CISA estimates that a covered entity would spend six hours per submission to collect, store, and maintain records ... hourly compensation rate of $35.19). It analyzes this rule for people who might want to critique it from a variety of perspectives and an enormous amount of potential impacts as required by law (e.g., its compliance with technical standards, energy usage, tribal implications).
Its easy to jump on these things for being long, but I would imagine the goal is to be thorough and precise. That matters to making this useful - as it does any law or regulation.
Doing government well is hard...just like writing good code or designing any complex system is hard. Documentation is often, and more often should be extensive. The headline is a cheap shot meant to undermine the actual rule itself.
Tbh I feel like something like this would greatly benefit from being compiled in a documentation repo, like as a wiki or structured like obsidian or logseq docs.
The information is all important but compiled as one big document it's obviously going to tough to crack into and digest. But structuring it into a bunch of smaller sections that you can easily jump between relevant/interconnected bits would make this kind of thing so much more transparent for people.
U.S. law requires that agencies perform this public disclosure of their analysis so that interested parties in the general public have an opportunity to meaningfully weigh in before the proposed regulation becomes an actual regulation. It's an incredibly valuable aspect of accountability if you are someone affected by the regulation.
A more recent law also required that CISA create a regulation on this particular subject. (It's explained in the regulation itself.)
If you want simpler regulations, the issue isn't that we're missing a law to ensure regulations are simpler. The law requires that exactly this happen all the time: Your(?) legislators in Congress are constantly writing laws that direct agencies to do exactly this.
Of course, if they didn't and regulations were simpler, all of the ambiguity would be decided by courts instead. The world is complicated with or without complicated regulations. So we can either have less-ambiguous but more wordy laws, or we can have more ambiguity, more court cases, and judges unpredictably deciding how to resolve the ambiguity.
I made a comment elsewhere in this thread on it but it's a proposal. That's how these go. There's a lot of information and analysis in it that's only relevant to some people but those people are going to care if it's not present.
The actual changes are 10 pages long. The rest is all discussions, alternatives, potential impacts to different sectors, etc.
If you look at it, the 447 pages are because it's a report & proposal. It includes a lot of background information, discussion on potential impacts, how it'll influence different industries and agencies, potential alternatives to the current proposal, and details as to what specific aspects of the request for comments they are interested in from SMEs and the public.
The actual proposed changes are only 10 pages long.
§ 226.2 Applicability (12) on p. 125 covers most IT/SaaS companies (any SW that has an OAuth2 client lib dependency seems to hit sub-clauses (ii)(C) and (ii)(D)) (emphasis mine):
(12) Information technology entities. The entity meets one or more of the following criteria: (i) Knowingly provides or supports information technology hardware, software, systems, or services to the Federal government; (ii) Has developed and continues to sell, license, or maintain any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes: (A) Is designed to run with elevated privilege or manage privileges; (B) Has direct or privileged access to networking or computing resources; (C) Is designed to control access to data or operational technology; (D) Performs a function critical to trust; or (E) Operates outside of normal trust boundaries with privileged access; (iii) Is an original equipment manufacturer, vendor, or integrator of operational technology hardware or software components; (iv) Performs functions related to domain name operations;
Also, would not hurt if the draft was written in the BLUF fashion [2], with the 10 pages of the proposed law followed by 123 pages of the analysis.
[1]: https://www.govinfo.gov/content/pkg/FR-2024-04-04/pdf/2024-0...
[2]: https://en.wikipedia.org/wiki/BLUF_(communication)