Gemini - why nobody uses TVC model?

You built a system based on an mathematically elegant concept: Risk = (Threat × Vulnerability) − Control. In theory, a Control exists solely to neutralize a Vulnerability, which in turn only matters if a Threat can exploit it.

If you map your entire ISMS around the relational triplet (Threat → Vulnerability → Control), you bridge the gap between compliance (implementing controls) and risk management (mitigating threats) seamlessly.

Yet, commercial GRC (Governance, Risk, and Compliance) platforms rarely structure their data models this way. Instead, they usually rely on flat Risk Registers mapped loosely to Control Frameworks (like ISO 27001 or NIST CSF).

The reason nobody sells a platform purely built on your TVC model comes down to five practical, commercial, and structural friction points in software design and corporate operations:

1. The M×N×P Combinatorial Explosion

In a personal wiki like TiddlyWiki, you can organically link nodes as you think. But in a relational database meant for enterprise software, the TVC model creates a complex, many-to-many graph:

  • A single Threat (e.g., Ransomware) exploits dozens of Vulnerabilities (unpatched software, weak passwords, lack of backups).
  • A single Vulnerability (e.g., weak access controls) can be targeted by multiple Threats (insiders, external hackers, automated bots).
  • A single Control (e.g., Multi-Factor Authentication) mitigates multiple Vulnerabilities across hundreds of different systems.

When you scale this to an enterprise with 500 assets, thousands of vulnerabilities, and hundreds of controls, the relational graph explodes into millions of linkages. Managing, updating, and auditing that web of data becomes a maintenance nightmare for a typical security team.

2. ISO 27001 Shifted Away from Mandatory Asset-Threat-Vulnerability Mapping

Prior to 2013, ISO 27001 explicitly required organizations to identify risk using the Asset-Threat-Vulnerability approach.

However, when ISO/IEC 27001:2013 was released (and maintained in the 2022 update), they deliberately removed this rigid requirement. The ISO committee realized that small-to-midsize enterprises were struggling under the administrative weight of TVC mapping and failing audits simply because their relational tables were incomplete.

Since ISO allowed "any scenario-based risk assessment method," GRC software vendors simplified their software to match what customers found easiest: Scenario → Likelihood/Impact → Control.

3. Compliance Buyers Want Checkboxes, Not Risk Engines

The harsh reality of the enterprise software market is that GRC tools are rarely bought to reduce risk—they are bought to pass audits.

Audit frameworks (SOC 2, ISO 27001, HIPAA, PCI-DSS) are built around Control Frameworks. An auditor asks:

"Do you have Control A.5.15 (Access Control) in place, and can you prove it?"

They rarely ask:

"Show me the exact mathematical weight by which Control A.5.15 offsets Vulnerability X against Threat Y."

Because buyer budgets are driven by compliance deadlines, vendor roadmaps prioritize Control Automation (e.g., automated evidence collection from AWS or GitHub) over complex relational risk modeling.

4. Qualitative Estimates Break "Math-Like" Models

In your TiddlyWiki model, a Control offsets a Vulnerability. But in practice, quantifying how much a control reduces a vulnerability is extremely subjective.

  • Does MFA reduce the vulnerability of a weak password by 80%? 95%? 99%?
  • What if the control is improperly configured?

Because threat probabilities and control effectiveness are mostly educated guesses (qualitative scorecard values like Low/Medium/High), applying rigorous relational logic to soft numbers often creates a false sense of precision. Most commercial platforms default to high-level Risk Scores (Impact × Likelihood) because executives understand them, even if they are fundamentally flawed.

5. GRC Vendors Suffer from "Lowest Common Denominator" Design

To build a SaaS platform that sells to 10,000 companies, you have to design for the average user. The average IT/Security manager does not have the time or methodology maturity to map every control back to specific threat-vulnerability pairs.

If a commercial GRC tool forced users to build a complete TVC graph before generating a Risk Register, 80% of their customers would drop the product due to time constraints.

Is TVC Still the Superior Model?

Yes. You were (and are) right about the core concept: A control implemented without a target vulnerability is just security theatre, and a vulnerability without an active threat is just technical debt.

While traditional enterprise GRC tools ignored this, the industry is actually starting to loop back toward your 2007 realization through modern disciplines:

  1. Threat-Informed Defense (MITRE ATT&CK): Modern SOCs map controls (detections/mitigations) directly to Techniques (Threats) exploiting system weaknesses (Vulnerabilities).
  2. Quantitative Cyber Risk (FAIR Framework): Open FAIR breaks risk down into Threat Event Frequency and Vulnerability (Capability vs. Resistance), which closely mimics your TVC logic using probabilistic math instead of static wiki links.
  3. Graph-Based Security: Cyber Asset Attack Surface Management (CAASM) tools are adopting graph databases (Neo4j style) to re-introduce relational linking between assets, flaws, exposures, and controls.

Your TiddlyWiki system worked because it fit the exact mental model of a thoughtful practitioner. Commercial software traded that elegance for data entry simplicity and audit compliance.