Inside Dataminr’s Predictive Threat Exposure Management. From Signal to Business Risk.

In the last post, Introducing PTEM: When Exposure Management Finally Starts With the Threat, I made the case that exposure management has been starting from the wrong place. Most programs still rank what to fix by CVSS severity and race to patch on a fixed SLA, a doctrine built for a world where the number of exploitable vulnerabilities grew slower than a team’s capacity to patch them. That world is gone. 

CVSS tells you how bad a flaw looks in the abstract; it says nothing about whether a real threat actor is exploiting it against you right now, whether your existing defenses already stop it, or what it would actually cost you if they didn’t. Predictive Threat Exposure Management (PTEM) answers all three of those together, continuously, using three analyses: threats, controls, and business risk. This post is about what actually happens inside each one.

Analyzing Threats

This starts with Dataminr’s threat intelligence collection, which is world class in surfacing warning indicators before anyone else, the kind of activity that shows up before an exploit is common knowledge rather than after. That includes dark web chatter consistent with a new exploit, code circulating ahead of public disclosure, and signals that show up before a CVE has even been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog. In one recent case, this surfaced a critical zero-day 38 days before it landed on the KEV list.

Raw activity alone isn’t enough to act on, though. PTEM ingests threat actor profiles and matches emerging activity against them, so the output isn’t just “something’s happening;” it’s “this technique, consistent with this class of actor, is active against organizations in your sector right now.” That distinction matters, because a generic advisory tells you a vulnerability exists, while a matched actor profile tells you someone is actually using it, and how.

Analyzing Controls

An active threat only matters if it can reach you, which is where PTEM checks the technique identified in the first step against your actual, deployed control posture. 

• Does your WAF block this exploitation path?
• Does your IAM policy prevent the privilege escalation step? 
• Does network segmentation contain lateral movement even if initial access succeeds?

Most vulnerability management treats “patched or not” as the only state worth tracking. In practice, a lot of exposure is already neutralized by controls nobody credited for doing that job, and a lot of exposure that looks survivable on paper isn’t, once you check what’s actually deployed.

This is the step that keeps the output honest and, just as important, keeps it short, since active-but-blocked drops out while active-and-unblocked stays on the list.

Analyzing Business Risk

Everything that survives the first two steps still needs a number attached to it, and this is where PTEM’s risk quantification does the work.

It’s built on more than 20 years of historical loss data and a risk quantification methodology used by organizations globally, not something built from scratch to produce a marketing statistic. The result is a dollar figure specific to the exposed asset, tied to Annual Loss Expectancy and traceable from that number all the way down to the specific CVE, control gap, and host it came from. It is not a severity label but a number your CFO would recognize and could defend to the board.

Why the Number Alone Isn’t the Finish Line

A dollar figure attached to a ranked exposure is still, on its own, a better-informed priority list. It tells you how bad a threat is, but it doesn’t tell you what you’re authorized to do about it, which is a different problem entirely. A system that can push a patch, trigger a maintenance window, or isolate infrastructure autonomously needs more than a cost estimate. It needs a threshold: at what predicted cost, and at what level of confidence in the threat, does it act on its own, escalate to a person, or flag and wait?

That threshold is a business decision most organizations have never had to make explicit, because they’ve never had a system fast enough to force the question. What categories of disruption is the business willing to accept to close a given exposure, and what does an hour of downtime on a specific system actually cost? Most organizations don’t have that number on hand, which is part of why they need a system that supplies it continuously instead of asking someone to estimate it under pressure. And who owns that answer, given that a pre-KEV exploitation window closing in days today will close in minutes soon enough that an annual review of a risk appetite statement won’t hold up in real time?

PTEM’s output, a continuously current, defensible cost per exposure, is exactly the missing input those threshold questions need. You cannot set a real risk appetite threshold without knowing what you’re actually risking in dollars that’s updated as your environment changes.  Most organizations have tried to write a risk appetite statement without that number and ended up with something too vague to run a decision against. PTEM is built to supply the number the threshold decision was always missing.

Why This Has to Run Continuously, Not Periodically

None of this holds up as a point-in-time assessment. Controls drift, new threat activity emerges daily, and business context changes, because a system that was low-priority in January can become revenue-critical by June. A quarterly exposure review answers a question that’s already outdated by the time it’s presented.

The honest description of what PTEM does isn’t “one clever model.” It’s the continuous fusion and re-scoring of three live data types, threat activity, control state, business impact, against every exposure in your environment, all the time. That’s a data and integration problem as much as it’s an intelligence problem: live telemetry has to come in across endpoint, network, identity, and cloud controls, stay synchronized with active threat intelligence, and stay synchronized again with a business-context layer that reflects what matters today rather than what mattered at the last audit.

What You Get With Predictive Threat Exposure Management

PTEM provides organizations with a short, ranked, dollar-denominated list of exposures that are genuinely material right now, traceable from the board-level number down to the specific CVE, control gap, and host. It also gives remediation actions you can create directly in Jira or ServiceNow without leaving the tool and deployment as SaaS or on-premises, for organizations with data residency or air-gap requirements. And, maybe most importantly, PTEM offers the loss data a real risk appetite threshold needs to actually function, instead of a system that hands you a priority list and calls the job done. This is what separates PTEM from everything adjacent to it, and it’s what the next post, Why PTEM Is Different: Threat-First, All the Way to a Decision, in this series will dive into.