The Logical Impossibility of Control-First Regulation

The Premise Every Regulator Claims

Open any cybersecurity regulation—NIS2, DORA, GDPR Article 32, PCI-DSS, HIPAA Security Rule, or sector-specific frameworks from financial services to critical infrastructure—and you will find the same foundational claim: "These requirements are based on internationally recognized standards."

The standards they reference—ISO/IEC 27001, NIST Cybersecurity Framework, and their derivatives—share a core principle so fundamental it appears in their opening chapters:

This is not merely a recommendation. It is the logical structure that makes control selection defensible. A control exists to address a threat. Without knowing what threat you're addressing, control selection becomes arbitrary.

The Regulatory Reality

Now examine what those same regulations actually require. They mandate specific controls: "Implement encryption." "Establish access controls." "Maintain audit logs." "Conduct penetration testing." "Implement multi-factor authentication."

Notice what is missing. The regulation never states: "Encryption is required because it mitigates Threat X." It never identifies which threat each control addresses. It simply mandates the control and moves on.

The Two Missing Dimensions

This creates not one, but two logical impossibilities. When a regulator mandates Control X as obligatory, they implicitly claim:

1. There exists a Threat Y that Control X addresses
2. Threat Y is relevant to the regulated entities
3. The risk from Threat Y justifies the cost of Control X
4. Control X operates at the right point in the attack chain

Yet regulations never state what Threat Y is, nor do they clarify where in the causal chain the control operates. This reveals two missing dimensions:

Without these two dimensions, regulated entities face impossible questions:

• They cannot verify the logic. They cannot confirm whether Control X actually addresses a threat relevant to their environment.
• Proportionality becomes impossible. Risk-based thinking requires knowing what risk you're addressing.
• Control architecture is incoherent. Preventive and mitigating controls are mixed without acknowledging they serve fundamentally different purposes.
• Compliance replaces security. When you cannot trace a control to a threat, you implement the control to satisfy the auditor and regulator and your compliance risk, not to reduce your cyber risk.

Universal Validation: 30 Regulations, Zero Exceptions

To test whether this was a selective observation or a universal pattern, I examined 30 cybersecurity regulations and standards across four jurisdictions (US, UK, EU, Switzerland) and multiple sectors. The result: every single regulation fails both dimensions.

The pattern is universal. Not a single regulation examined provides a threat taxonomy that would allow controls to be traced to specific threats, and not a single regulation distinguishes between controls that prevent compromise versus controls that limit damage after compromise.

Why Both Dimensions Matter: The MFA vs. Encryption Example

Consider two controls that regulations frequently mandate together: Multi-Factor Authentication (MFA) and Encryption at Rest. Most regulations list them side by side as if they were equivalent security measures. They are not.

Without the horizontal dimension, you cannot answer: "Which threat does this control address?" Without the vertical dimension, you cannot answer: "Does this control prevent compromise or limit damage after compromise?" Regulations that conflate these produce incoherent security architectures.

The TLCTC Solution: A Two-Dimensional Framework

The Top Level Cyber Threat Clusters (TLCTC) framework provides exactly the two-dimensional structure that regulations lack, through its Bow-Tie model:

The 10 Threat Clusters (Horizontal Dimension)

TLCTC classifies threats by the generic vulnerability they exploit, not by outcomes:

The Causal Chain (Vertical Dimension)

The Bow-Tie model separates controls by their position in the attack chain:

What Coherent Regulation Would Look Like

With this two-dimensional structure, a regulatory requirement could finally be stated coherently:

"Organizations shall implement controls addressing #4 Identity Theft, specifically multi-factor authentication for privileged access, because weak credential management enables unauthorized system access. This is a cause-side preventive control."

This statement identifies the threat (#4), names the generic vulnerability (weak credential management), specifies the control (MFA for privileged access), explains the causal relationship, and positions the control in the attack chain. It can be verified, challenged, and proportionally assessed.

Conclusion

The logical flaw in cybersecurity regulation is not subtle. It is a structural contradiction between what the referenced standards require (identification-first, chain-aware) and what the regulations themselves do (control-first without identification or chain positioning).

This contradiction cannot be resolved by writing more detailed control requirements. It can only be resolved by doing what the standards have always demanded: identifying threats first across both dimensions—which threat and where in the chain—then deriving control requirements from that identification.

The TLCTC framework provides the missing structure. It's available under CC BY 4.0 at tlctc.net.