"Relevant to Your Industry" Is a Threat Intel Myth

Open any threat intelligence product and you will be told it delivers intelligence relevant to you. Ask how it decides what is relevant, and the answer is almost always the same: it matches the intel's industry-sector and geography tags against your organization's profile. A finance company in Germany gets the finance-and-Europe feed. It is intuitive, it demos well, and it is the default across nearly the entire market.

It is also, as far as the published evidence goes, an assumption that no one has validated. When you go looking for studies testing whether sector or geography independently predict that a given organization gets hit, after controlling for what technology it actually runs and what it exposes to the internet, you do not find them. The frameworks and products that lean on those attributes assume they matter. They do not show it.

This is not an argument that sector and geography are meaningless. It is an argument that they are doing far less work than the industry pretends, and that the signal practitioners should be spending their attention on is somewhere else entirely. The evidence points to a clear hierarchy, and most relevance scoring is built on the wrong tier of it.

The strongest signal is the least glamorous: do you even run it

Before any actor profile or regional trend, the single best-supported relevance filter is whether the affected technology exists in your environment at all. The base rates make this filter enormously powerful.

In the foundational EPSS dataset, only about 44% of CVEs published between 2016 and 2018 were ever detected open in any corporate environment across hundreds of enterprises. More than half of all published vulnerabilities were never observed in a single scanned estate. And of the full population, only about 3.7% (921 of 25,159) were observed exploited in the wild within twelve months of disclosure. Later work nudges that exploitation figure to roughly 5 to 6%, but the shape of the conclusion is durable: the overwhelming majority of vulnerability-flavored intel describes something that either is not in your environment or will never be used against anyone.

An asset-presence filter, applied rigorously, discards most of that with high confidence before any scoring even begins. This is unglamorous work. It is version-range matching, CPE and package normalization, resolving a vendor advisory to the specific deployed assets it touches. It is also the highest-leverage filter you have, because it shrinks the denominator for every downstream judgment. A live inventory of what you run beats a sector tag every time, because a sector tag is a guess about what you might run and an inventory is a fact about what you do.

The most predictive attributes are not about your organization at all

When researchers actually measure what predicts exploitation, the winners are vulnerability-intrinsic and ecosystem attributes, not organizational ones. Whether working exploit code has been published and weaponized, the vendor, whether the flaw allows remote code execution, how many references a CVE accumulates: these carry the predictive weight.

The clearest number here is the effect of weaponized proof-of-concept code. Its presence raises observed exploitation from that 3.7% base rate to 37.1%, an order-of-magnitude lift, corroborated across multiple independent studies and baked into EPSS. Nothing about your industry moves the needle like that. An exploit existing in the wild is a fact about the vulnerability's ecosystem, and it tells you more about your real exposure than knowing you are a hospital or a bank.

The practitioner implication is direct. Ingest exploitation-ecosystem signals, EPSS, CISA KEV membership, proof-of-concept weaponization, observed-exploitation data, as inputs to your own prioritization. Just do not inherit any single one as the ranking, for reasons the next section makes uncomfortable.

Sector and geography: assumed, not validated

Here is where the common model runs out of support.

No empirical study I could find, after adversarial review, tests whether sector or geography independently predict firm-level victimization once tech stack and attack surface are controlled for. That is a striking gap given how universally those attributes are used. The strongest signals in the literature all concern vulnerability-level exploitation with population-level ground truth, which is a proxy for org-specific risk, not a measurement of it. On the specific question of whether being in a given sector makes your firm more likely to be compromised, the honest answer is that the industry has assumed it rather than shown it.

Two authoritative systems are worth watching on this point because of what they choose to leave out. CISA's operational SSVC decision tree uses exactly five attributes, exploitation status, technical impact, automatability, mission prevalence, and public well-being, and it deliberately excludes sector, geography, and company size. IBM's patented affectedness engine does use sector and geography, but only to scope which sightings it queries; its core mechanism is empirical sighting frequency, and first-party observation in the customer's own telemetry receives the single largest default weight, above sightings from industry-similar or geography-similar peers. Even a design that keeps sector in the model ranks direct observation of your own environment ahead of profile similarity.

There is one contrary result worth citing honestly. A 2024 study joined sector, country, and a normalized software inventory to actor-targeting data and reported a 71.5 to 91.3% improvement in vulnerability ranking over a CVSS-only baseline. That sounds like vindication for org-context scoring, and it may yet prove to be. But it does not survive scrutiny cleanly: the baseline it beats is weak, the ground truth partly overlaps with the scoring features (a circularity trap), some inventories were synthetic, and it has not been replicated. Treat it as a promising research direction, not a settled case for sector-based relevance.

While we are here: stop inheriting a single score

The relevance problem sits next to a scoring problem, and the scoring problem is worse than most teams admit.

Remediating everything at CVSS 7 and above yields about 6.2% precision. EPSS reaches equivalent coverage with somewhere between 28.8 and 85.9% less remediation effort. A CVSS base score contains no element that enumerates a specific threat to a specific organization, and that remains true in CVSS v4.0, where exploit maturity lives in a separate, often-unpopulated threat metric group.

The deeper problem is that the major scoring systems do not agree with each other. On the same 600 Patch Tuesday CVEs, CVSS, EPSS, SSVC, and Microsoft's Exploitability Index showed pairwise agreement at chance level, Cohen's Kappa between −0.01 and 0.03. Some of that is by design, since they measure different constructs, but the operational consequence is blunt: which vulnerabilities look urgent to you depends mostly on which scoring system your program happened to adopt. Inheriting any one of them as your ranking is therefore indefensible. The defensible move is to treat them as features feeding your own model, and to condition them on something the flat scores cannot see: topology. A KEV-listed remote code execution flaw on an internet-facing asset and the same flaw on an internal, segmented host are not the same risk, and only your own environment model knows the difference.

Even KEV, the most operationally trusted list, is coarser than its reputation. As of a January 2026 snapshot, only about 32% of KEV entries were immediately exploitable for initial access, meaning unauthenticated remote code execution with no user interaction. The lowest-scoring entries carried EPSS values below 0.001. KEV membership is a useful prior, not a verdict.

Relevance is a decision, and it goes stale

The framework doctrine converges on a stance that most attribute-matching implementations quietly violate. FIRST's Priority Intelligence Requirements curriculum and SSVC both anchor relevance to a bounded set of stakeholder decisions and deployment context, rather than to static attribute tags. And they insist it is perishable. In the words of the PIR guidance, priority intelligence requirements are fluid and not static; when the operational environment changes, everything the requirements support must be re-evaluated.

That has a concrete engineering consequence. Relevance should be re-scored on environment-change events, a new asset class appearing, a system decommissioned, a merger reshaping the topology, not on a fixed weekly or monthly cadence. A relevance judgment made against last quarter's environment is describing an organization that no longer exists. Wiring re-evaluation to drift, rather than to a timer, is how you implement that doctrine instead of just quoting it.

What to actually do

Strip the theory down to a working prioritization stance and it looks like this:

• Gate on asset presence first. Whether you run the affected technology is your strongest, cheapest filter, and it discards most vulnerability intel before any scoring. Invest in the entity resolution that makes it rigorous.
• Fuse exploitation-ecosystem signals as features, never as an inherited ranking. EPSS, KEV, and proof-of-concept weaponization belong in your model. No single external score belongs as your model.
• Condition on topology. Internet-facing versus internal changes the risk of an identical vulnerability. A flat score cannot express that; your environment graph can.
• Use sector and geography only as a coarse prior for actor targeting, with no independent weight in the score, until someone actually validates them.
• Re-score on change, not on a schedule. Relevance is perishable. Tie it to environment drift.

None of this says threat actor context is useless. Knowing that a group targets your sector can sharpen which actors you model. It says that letting sector and geography tags decide what intelligence reaches your analysts is optimizing on the weakest tier of the evidence while the strongest tier, what you run and what is being exploited against it, sits right there unused.

The uncomfortable summary is that a lot of what the market sells as relevance is a well-designed guess dressed as a measurement. The parts that are actually measured point somewhere less flattering and more useful: your own inventory, the exploitation ecosystem, and your own topology. Optimize there.

This post is the practitioner-facing version of a longer, fully-cited research brief I wrote for AEGIS Labs, Organizational Context as Signal for Threat Intelligence Relevance, which carries the full source list and the adversarial-verification methodology behind each claim. Statistics reflect the sources current at the time of writing; date-stamp any single-vendor snapshot before you quote it.