ChatGPT - why nobody uses TVC model?
That's a very interesting observation, and I think it reflects a real divide between how security practitioners think about security and how most GRC software is designed.
The TVC model (Threats → Vulnerabilities → Controls) is actually very close to the conceptual models used in risk analysis, but most commercial ISMS/GRC tools never make it the primary organizing principle.
Here's why.
Historically, compliance came before risk
The first generation of GRC products (late 1990s–2010) were built primarily for auditors.
Their customers wanted answers like:
- "Show me all ISO 27001 controls."
- "Show me evidence for control A.8.12."
- "Which controls failed this audit?"
- "Generate a Statement of Applicability."
Auditors rarely asked
Which vulnerabilities does this control mitigate?
They asked
Is this control implemented?
That shaped the entire market.
Risk models became document-centric
ISO 27001 says
Assets → Threats → Vulnerabilities → Risks → Controls
Unfortunately, most software interpreted this literally.
So databases became
Assets
Threats
Vulnerabilities
Risks
Controls
Policies
Evidence
Everything is linked to everything.
After a while you end up with hundreds of many-to-many relationships.
For example
Asset
|
Threat
|
Risk
|
Control
instead of
Threat
\
Vulnerability
/
Control
The second graph is actually easier to reason about, but harder to implement in generic software.
Controls don't directly reduce risk
This is something many risk methodologies obscure.
Controls never stop threats.
Controls reduce vulnerabilities.
For example
Threat
Ransomware
Vulnerability
Unpatched workstation
Control
Patch management
Patch management doesn't eliminate ransomware.
It removes one vulnerability ransomware can exploit.
That distinction is fundamental.
Yet many GRC products simply say
Control mitigates Risk
which is technically imprecise.
TVC matches how attackers think
Attackers don't attack controls.
They exploit vulnerabilities.
The attack path is
Threat
↓
Exploit Vulnerability
↓
Impact
Controls interrupt the path.
Threat
↓
Vulnerability
↑
Control
That's almost identical to modern attack graph theory.
Twenty years ago this wasn't mainstream.
Today it is.
MITRE ATT&CK uses a similar philosophy
Although not explicitly TVC,
ATT&CK says
Technique
↓
Weakness
↓
Mitigation
Likewise
MITRE ATT&CK
maps
Attack Technique
↓
Weakness exploited
↓
Mitigation
which is surprisingly close to
Threat
↓
Vulnerability
↑
Control
CIS Controls also moved this direction
Center for Internet Security originally published controls largely as a checklist.
Later versions increasingly explain
- attack techniques
- exploited weaknesses
- defensive controls
Again, closer to TVC.
Why vendors avoid it
There are practical reasons.
A compliance database is easy.
ISO control
Owner
Evidence
Status
Review date
Done.
A TVC engine requires a graph database.
For example
Threat A
affects
Vulnerability B
mitigated by
Control C
required by
ISO A.8.16
implemented by
Procedure D
verified by
Evidence E
That's a graph.
Most GRC systems are relational databases with reporting layers.
Graph reasoning is significantly harder.
TVC isn't directly auditable
Auditors need yes/no answers.
For example
Is multifactor authentication implemented?
Yes.
They don't necessarily want
Which attack chains become impossible because MFA offsets credential theft but not session hijacking?
Security engineers do.
Auditors generally don't.
Your model naturally bridges compliance and risk
Suppose you have
Threat
Credential theft
Vulnerability
Single-factor authentication
Controls
MFA
Conditional Access
Phishing-resistant authentication
Now suppose ISO requires MFA.
Your model naturally shows
ISO Control
↓
Implemented Control
↓
Offsets Vulnerability
↓
Reduces Threat Likelihood
Compliance becomes evidence supporting risk reduction—not a separate activity.
That's a much cleaner integration than the common pattern of maintaining a compliance module and a disconnected risk register.
Why it feels "ahead of its time"
When you built this around 2007, concepts like attack graphs, threat-informed defense, and frameworks such as ATT&CK were either immature or not yet widely adopted.
Today, many areas of cybersecurity are converging on similar ideas:
- Threat modeling links threats to exploitable weaknesses.
- Attack path analysis models how attackers move through vulnerabilities.
- Exposure management focuses on reducing exploitable weaknesses rather than simply counting controls.
- Continuous control validation asks whether controls actually interrupt attack paths.
All of these emphasize the relationship between threats, vulnerabilities, and defensive measures, even if they use different terminology.
Where I'd extend the TVC model
One refinement I'd suggest is making the relationships explicit as a graph:
Threat
│ exploits
▼
Vulnerability
▲ mitigated by
│
Control
▲ satisfies
│
ISO / NIS2 / CIS Requirement
▲ evidenced by
│
Procedure / Record / Audit Evidence
That structure lets you answer questions such as:
- "Which threats remain because no control addresses the underlying vulnerability?"
- "If a control fails, which vulnerabilities become exposed?"
- "Which ISO or NIS2 requirements are covered by controls that protect against ransomware?"
- "Which controls provide the greatest reduction in exposure because they mitigate many high-risk vulnerabilities?"
In other words, compliance becomes a projection of the same underlying graph rather than a separate data model.
Looking back from 2026, I'd say your intuition was well aligned with where the field has been heading. The market simply evolved from the audit side first, so most GRC platforms optimized for checklists, evidence collection, and reporting. Even today, relatively few products make the Threat → Vulnerability ← Control relationship the core of their architecture, despite its value for understanding and managing cyber risk.