Regulation of technology risk works by reference. A law requires risk management and points to standards; it defines its key terms by pointing to another act; the standards in turn require the organisation to “identify threats”. Each reference is legitimate on its own. Followed to the end, the chain shows a pattern that holds on both sides of the Atlantic: every link defines the threat by the harm it may cause, and the last link hands the definition to the regulated entity itself. This post traces five chains link by link in the verbatim text (NIS2, DORA and the Cyber Resilience Act in the EU, the SEC disclosure rule and FISMA in the US), names the pattern definition by delegation, states the problem it creates, and describes what the end of the chain would need: a closed vocabulary of causes.
The Problem in One Sentence
Technology-risk regulation in the EU and the US delegates the meaning of “cyber threat” from act to act and from law to standard, every link defines it by the harm it may cause rather than by what makes the harm possible, and the chain ends with the regulated entity identifying threats in a vocabulary of its own — so the obligations cannot be verified, the reports cannot be aggregated, and no control can be traced to the cause it is meant to address.
None of this is a drafting mistake in a single law. Definition by reference is a normal legal technique: it keeps terms consistent and avoids repeating text. It only becomes a problem when the reference never arrives anywhere. To see that, one has to follow the references instead of reading each law on its own. That is what the rest of this post does.
How to Read the Chains
Each chain below starts with the obligation a regulated entity actually faces and follows every reference it contains: to a definition, to another act, to a standard. The quoted text is verbatim from the official sources listed at the end. Words that define something by its harm — loss, disruption, compromise, adverse effect — are marked. The question at every link is the same: does this text say what makes the harm possible?
Chain 1: NIS2 (EU, essential and important entities)
“Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems […]”
“Taking into account the state-of-the-art and, where applicable, relevant European and international standards […]”
“‘risk’ means the potential for loss or disruption caused by an incident […]”
“‘incident’ means an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services […]”
“‘cyber threat’ means a cyber threat as defined in Article 2, point (8), of Regulation (EU) 2019/881”
→ “any potential circumstance, event or action that could damage, disrupt or otherwise adversely impact network and information systems, the users of such systems and other persons”
“the type of threat or root cause that is likely to have triggered the incident”
Chain 2: DORA (EU, financial entities — technology risk in general)
DORA is the clearest case that the problem is not limited to “cyber”: it regulates ICT risk as a whole, and its central definition is a circumstance defined by what it may compromise.
“Financial entities shall, on a continuous basis, identify all sources of ICT risk […] and assess cyber threats and ICT vulnerabilities relevant to their ICT supported business functions, information assets and ICT assets.”
“‘ICT risk’ means any reasonably identifiable circumstance in relation to the use of network and information systems which, if materialised, may compromise the security of the network and information systems […] by producing adverse effects in the digital or physical environment”
“‘cyber threat’ means ‘cyber threat’ as defined in Article 2, point (8), of Regulation (EU) 2019/881”
Chain 3: Cyber Resilience Act (EU, products with digital elements)
“manufacturers shall undertake an assessment of the cybersecurity risks associated with a product with digital elements and take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases […]”
“‘cybersecurity risk’ means the potential for loss or disruption caused by an incident […]”
“Products with digital elements and processes put in place by the manufacturer which are in conformity with harmonised standards […] shall be presumed to be in conformity with the essential cybersecurity requirements […]”
Chain 4: SEC cybersecurity disclosure (US, listed companies)
“Describe the registrant’s processes, if any, for assessing, identifying, and managing material risks from cybersecurity threats […]”
“Cybersecurity threat means any potential unauthorized occurrence on or conducted through a registrant’s information systems that may result in adverse effects on the confidentiality, integrity, or availability […]”
Chain 5: FISMA → NIST (US, federal agencies)
“(A) assessing the risk and magnitude of the harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of such information or information systems; (B) […] in accordance with standards promulgated under section 11331 of title 40 […]”
“Any circumstance or event with the potential to adversely impact organizational operations […] through a system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.”
“Internal and external threats to the organization are identified and recorded”
Where Every Chain Lands: the Standards
The EU laws point to “European and international standards”; in practice that means the ISO/IEC 27000 family and NIST. Both continue the pattern rather than end it.
- ISO/IEC 27001 (clause 6.1.2 c) asks the organisation to identify risks “associated with the loss of confidentiality, integrity and availability” — risk identified by the outcome. The clause does not ask for threats to be identified at all; the asset–threat–vulnerability method is one option described in ISO/IEC 27005.
- ISO/IEC 27000 (3.74) defines a threat as a “potential cause of an unwanted incident” — the only definition in any chain that uses the word cause, and it is circular: the cause is defined by the incident it may lead to, and the incident by the harm.
- NIST CSF 2.0 requires threats to be identified and recorded (ID.RA-03) without defining what a threat is, and points to informative references; the references lead back to SP 800-30 and its “any circumstance or event”.
So the last link of every chain is the same instruction to the regulated entity: identify the threats. What counts as a threat, at what level of detail, in what categories, is left to each entity. Five laws, two continents, three standard families — and the vocabulary for the most basic input of risk management is decided anew in every organisation.
Three Patterns
A definition that says “as defined in”. Legitimate on its own. NIS2, DORA, the CRA and the Cyber Solidarity Act all point to the same sentence of the Cybersecurity Act; the US information-sharing statute points to 6 U.S.C. § 650.
Every substantive definition names what the threat may do — loss, disruption, adverse effects on confidentiality, integrity, availability — never what makes it possible. Risk is defined by incidents, incidents by outcomes, threats by outcomes.
The last link tells the regulated entity to identify threats or “all sources of ICT risk”. The definition that the chain never supplied becomes each entity’s private decision.
What It Costs
- Obligations that cannot be verified. “Identify all sources of ICT risk” has no object an auditor can check for completeness, because “any reasonably identifiable circumstance” has no boundary. Audits fall back on checking that a process exists (see The Audit Trap).
- Reports that cannot be aggregated. NIS2 asks every final report for “the type of threat or root cause”. Without a shared vocabulary, one entity writes “ransomware”, the next “phishing”, the next “a named group”. The national situation report can only count outcomes.
- Controls that cannot be traced. A control acts on a cause. If the threat is defined by its harm, no control can be shown to address it; frameworks map controls to assets, functions or outcomes instead (see The Logical Impossibility of Control-First Regulation).
- No equivalence across borders. The EU and the US both define the threat by its harm, in different words, and both delegate the rest. Two regimes that never name a cause cannot be compared on causes — mutual recognition has to be argued case by case.
Not Only Cyber: Technology Risk
DORA regulates ICT risk as a whole, and NIS2 requires an “all-hazards approach” (Art. 21(2)). Both are right to include failures, mistakes and misuse next to attacks. But a definition by harm cannot tell them apart: an outage after a failed update, an administrator’s error and a ransomware attack produce the same “adverse effects”. They are answered by different controls and owned by different functions. The chain does not only fail to name the cause of an attack; it fails to separate an attack from a failure.
What the End of the Chain Needs
The fix is not another definition by harm, and not a longer catalogue of threats. The chain needs to end in a closed vocabulary of causes that every link can point to: closed, so completeness can be checked; cause-based, so controls can be traced; independent of actors and outcomes, so reports can be added up. TLCTC was built to be that end point:
- The cause side first. Three questions sort every technology risk event into four rows — failure, error in use, abuse of rights, attack (R-SCOPE). That separates what DORA’s “any circumstance” mixes.
- Ten clusters for the attack row. Each defined by the generic vulnerability it exploits; one cluster per attack step. “Type of threat or root cause” becomes an attack path such as
#9 → #7 → #4 → #1. - The harm keeps its place. The law’s definitions by harm are not wrong; they describe the consequence side. Loss of confidentiality, integrity or availability is a Data Risk Event; disruption of services and reporting duties are Business Risk Events. Every regime can keep its trigger point on the same chain SRE → DRE → BRE.
| Regulatory term | Defined by | Where it belongs |
|---|---|---|
| “cyber threat” (CSA 2(8), SEC, 6 U.S.C. 650) | potential harm | the cause: one of ten clusters |
| “ICT risk” (DORA 3(5)) | any circumstance with adverse effects | the cause side: four rows, then clusters for attacks |
| “incident” (NIS2 6(6)), “ICT-related incident” (DORA) | compromise of C, I, A | System and Data Risk Events |
| “risk” / “cybersecurity risk” (NIS2 6(9), CRA 3(37)) | loss or disruption × likelihood | the number on the chain: likelihood of the cause, impact on the consequence side |
| “type of threat or root cause” (NIS2 23(4)(d)(ii)) | — | the attack path, cluster by cluster, with Δt |
The laws do not need to change what they protect. They need a shared word for why it failed — and a reference that finally arrives somewhere.
Further Reading
- Cyber in the Name — six answers to “what is a cyber threat?” across 25 rulebooks, and the film As Defined In …
- The Logical Impossibility of Control-First Regulation
- Definition Entries for “Threat” on One NIST Page
- NIS2 · DORA · CRA · Cybersecurity Act
- The Logical Foundations of TLCTC — why the ten clusters can serve as the end of the chain
Sources
All quotations are verbatim from the official texts, checked on 24 October 2026. Square brackets mark omissions.
- Directive (EU) 2022/2555 (NIS2), Arts. 6(6), 6(9), 6(10), 21(1)–(2), 23(4)(d)(ii) — EUR-Lex
- Regulation (EU) 2022/2554 (DORA), Arts. 3(5), 3(12), 8(2), Recital 56 — EUR-Lex
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Arts. 3(37), 13, 27(1) — EUR-Lex
- Regulation (EU) 2019/881 (Cybersecurity Act), Art. 2(8) — EUR-Lex
- 17 CFR § 229.106 (Regulation S-K Item 106) — LII
- 6 U.S.C. § 650(8) — LII
- 44 U.S.C. § 3554 (FISMA) — LII
- NIST Cybersecurity Framework 2.0, CSWP 29 (2024), ID.RA-03 and Appendix C — NIST
- NIST CSRC glossary, “cyber threat” (21 entries) — NIST CSRC; NIST SP 800-30r1, Appendix B
- ISO/IEC 27001:2022, 6.1.2 c); ISO/IEC 27000:2018, 3.74 (short quotations)