A preemptive program acts on exposure before an alert exists, not after. Two numbers tell you whether yours does: the time between an asset becoming exposed and the team knowing, and the fraction of what was detected that went through some proof it was exploitable. A periodic program answers the first in days or weeks, and does not answer the second.
Every security manufacturer pasted the word preemptive onto some page in the last twelve months. When an adjective gets adopted by everyone at once, it stops separating anything.
What still separates is measurement. And here is the part that tends to surprise people: two numbers are enough, both come out of an afternoon's work, and neither requires buying anything. Together they produce a sharper diagnosis than any maturity assessment you could commission.
Why the question got urgent
The 2026 Verizon DBIR carries three findings that only make sense read together.
Three measurements from the report carry the point. Exploitation of a vulnerability became the most common way in, passing stolen credentials, and at the same time the speed of whoever closes the door went backwards, with median remediation stretching from 32 to 43 days. The third one stings most, because it is about execution rather than discovery. Of CISA's catalog of vulnerabilities known to be under exploitation, 26% showed as remediated.
The main door is now the exposed flaw, and the queue that should close it is moving slower than before. Patching faster became a promise the numbers do not support.
What is left is reducing what is exposed. Reducing it requires knowing what is exposed before the adversary does, and that is where the two tests come in.
Test 1: how long until you know
Take the last ten assets that appeared on your external surface. A new subdomain, a staging environment published by mistake, an admin panel that came up with an integration, a bucket somebody opened to solve a Friday problem.
For each, write down two dates. When it became reachable from the internet, and when somebody on the security team knew it existed.
The gap between them is your time to discovery.
If the median lands in hours, the program is preemptive on this dimension. If it lands in days, it is periodic with a new name. And if you cannot establish the first date at all, that is the finding, bigger than the number you set out to calculate.
One caveat about what this test does not measure. It says nothing about whether the asset was dangerous. A staging environment with no real data and working authentication can sit exposed for months with no consequence. What it measures is the speed of your knowledge.
And watch for the inventory trap. Many companies measure this against their own asset list, which guarantees a good and false result. The asset that matters for this test is precisely the one that was not on the list.
Test 2: how much of what you know means anything
Take everything your tool reported last quarter. Add it up. Then count how many of those items went through any check that the flaw was actually reachable and exploitable on that specific asset.
Divide the second by the first.
In most programs I see, that number sits below 5%. The rest of the queue is raw findings, ordered by CVSS, waiting for somebody with time to check them one by one.
This is where most of a security budget evaporates. CVSS measures potential damage under ideal conditions for the attacker and says nothing about the probability that anyone will try. There are 9.8 flaws published years ago with no known exploit. And there are medium-scored flaws in active campaigns right now, sitting at position 400 in a queue ordered by theoretical severity.
A program that validates little is not lazy. It is a program that received more findings than it can process, and its natural response is to work top-down through a list that is in the wrong order.
The two numbers multiply, they do not add
This is the part that changes how you read the result.
Fast discovery without validation does not improve the program. It delivers a bigger pile, faster, and the pile is still in the wrong order. The team finds more and freezes harder.
High validation on an incomplete inventory is worse in a subtler way: it produces confidence. You handle everything you know about beautifully, close the quarter with good metrics, and the asset that will take you down never entered the count.
That is why the two numbers only mean something together. Combined, they give four diagnoses.
Fast discovery, high validation. The program is preemptive. What remains is mobilization: turning validated findings into tickets with an owner and a deadline, which is where most teams stall after solving the first two parts.
Fast discovery, low validation. You know what you have and not what matters. This is the most common situation in a company that bought a good discovery tool. The next step is exploitability validation, not more discovery.
Slow discovery, high validation. The classic profile of mature vulnerability management without surface management. Internal metrics look excellent and the real surface is not in the report.
Slow discovery, low validation. Where almost every program starts. Order matters: fix discovery first, because validating an incomplete list well only anchors you to the wrong part of the problem.
The same two questions, turned on a vendor
Both tests work better than any feature question in a sales meeting.
Ask how long passes between an asset becoming exposed and the platform telling you. Watch whether the answer talks about scan frequency or about time to notification. Daily scanning with weekly processing produces weekly notification.
Ask how much of what they report comes with proof of exploitability. An honest answer usually draws a distinction between a finding and a validated finding. If the manufacturer treats both as the same thing, their finding count is inflated by construction.
There is a third question that reveals more than the other two, and almost nobody asks it: what do you not do? An over-permissioned cloud account and a valid credential used by the wrong hands stay invisible from outside, because neither of them answers on a port. Anyone promising both halves in one product is selling the name of the category.
One afternoon, no purchase
You get the first number from the DNS history and change log you already have. The second from the report your current tool already emits.
That matters more than it sounds. It means you can find out where your program is broken before sitting down with any vendor, and walk into the meeting knowing which of the four quadrants is yours. Anyone who arrives without those two numbers buys on the word printed on the proposal cover, and that word, now that the whole industry adopted it at once, no longer means anything.
Preemptive is a claim. These two numbers are its receipt.
Frequently asked questions
What counts as a good time to discovery?
It depends on the size and rate of change of the surface. As a practical reference: hours is good, one day is acceptable in most contexts, a week means the adversary had a six-day head start on every new asset. Automated internet-wide scanning runs in cycles of hours, so that is the real yardstick.
Why does validation rate matter more than total findings?
Because a total measures the volume the tool produces, not the risk you carry. A queue of 3,000 unvalidated items and a queue of 40 validated ones can describe the same company. The second one can actually be worked.
Doesn't my vulnerability management program already cover this?
It partly covers the second test, and almost never the first. Vulnerability management works on assets already in the inventory, so it is born blind to the asset nobody registered. That is the difference between vulnerability management and threat exposure management.
Can both numbers improve without growing the team?
The first can, because discovery is machine work and does not scale with headcount. The second depends on automating validation, since manually checking a queue of thousands is not viable at any team size.
What if I cannot establish the first date in test 1?
That is the result of the test. Not knowing when an asset became exposed means nobody is watching the surface from outside, and that is the gap to close before anything else.
Do these tests work for evaluating a vendor in a POC?
They do, and they beat counting findings. Ask the manufacturer to show you an asset you did not know about, with the date it appeared, and proof of exploitability for at least one finding. Those two together separate a product from a report.