How often should you pentest? A model of the exposure window

#The question

Every testing program implicitly trades money for a shorter exposure window: the time between an exploitable weakness appearing in your environment and that weakness being closed. Attackers are racing the same clock from the other side. If they find and use the weakness before you close it, the test schedule did not matter.

That framing gives a clean quantity to compute: the probability that an exposure is exploited before it is closed, as a function of how often you test, how reliably each test finds the exposure, how long fixes take, and how fast attackers are. The point of the model is not the absolute numbers — your parameters will differ — but the shape: which lever moves risk, and by how much.

#The model

We model a single exploitable exposure. Four random times matter, all measured in days from the moment it appears:

• $W$: time until a test detects it.
• $R$: time from detection to a verified fix. We take $R\sim \mathrm{Exp}(\text{mean }r)$.
• $A$: time until an attacker finds and exploits it, $A\sim \mathrm{Exp}(\text{mean }\tau )$, independent of the defender.
• The exposure is closed at $W+R$. It is exploited first if $A<W+R$.

Because $A$ is exponential, the probability of exploitation before closure has a convenient form in terms of Laplace transforms:

For an exponential fix time the second factor is ${\mathcal{L}}_R(1/\tau )=\frac{1}{1+r/\tau }$.

Periodic testing

Tests run every $T$ days. The exposure appears at a uniformly random point in the cycle, so the wait for the next test is $U\sim \mathrm{Uniform}(0,T)$. Each test independently finds a live exposure with probability $q$ — coverage is never perfect, because scope is sampled and testers run out of hours. If the first test misses, the next chance is $T$ days later, so $W=U+(K-1)T$ with $K\sim \mathrm{Geometric}(q)$. Taking the transform:

and the mean exposure window is

The middle term is the one people forget: a test that misses a weakness doesn't just delay detection by a few days, it pushes it out by a full cycle.

Continuous testing

Continuous testing replaces the schedule with a detection delay $W\sim \mathrm{Exp}(\text{mean }d)$, giving ${\mathcal{L}}_W(1/\tau )=1/(1+d/\tau )$ and therefore

#Parameters and why we chose them

We use $q=0.8$ per test, a fix time of $r=14$ days, and $d=1$ day for continuous detection. For attacker speed we bracket $\tau$ with three values taken from Mandiant's time-to-exploit analysis: an average of 63 days in 2018–2019, 32 days in 2021–2022 and 5 days in 2023 (the 2023 figure excludes outliers; with them the average is 47 days) [1]. Those are times from public disclosure to exploitation in the wild, not times for an attacker to find a weakness in your estate, so read $\tau$ as a scale for "how fast is the adversary you worry about", not as a measured constant.

We computed every value in closed form and checked it with a 400,000-trial Monte Carlo simulation per cell. The largest absolute difference between the two across all cells was 0.0007. Code and outputs are in the project's research/ directory.

#Results

Three things stand out.

Annual testing is close to irrelevant against a fast adversary. With a 365-day cycle and 80% detection, the mean exposure window is 288 days. Against $\tau =32$ days, 95% of exposures are exploited before closure. The annual test is still useful for compliance and for finding long-lived structural problems, but as a control on time-sensitive exposure it does very little.

Moving from annual to monthly roughly halves risk at $\tau =63$ and cuts it by a third at $\tau =32$. That's real, and it is why PTaaS and quarterly programs exist. But at $\tau =5$ even weekly testing leaves 88% of exposures exploited.

Once detection is continuous, the fix time is the whole game. Continuous detection at $d=1$ day with a 14-day fix still leaves 78% exploited at $\tau =5$. The detection term has shrunk to almost nothing; what remains is $r$.

#Sensitivity: fix time under continuous testing

Under annual testing, fix time barely matters: the exposure window is dominated by waiting for the test. Under continuous testing, cutting mean fix time from 14 to 3 days at $\tau =32$ drops risk from 32.5% to 11.3%. This is the quantitative version of a familiar complaint: buying detection without buying remediation capacity moves the bottleneck, it doesn't remove it.

A useful rule of thumb falls out of the formula. When $d\ll \tau$ and $r\ll \tau$, a first-order expansion gives

Risk is roughly linear in the total exposure time over the attacker's time scale. Halving fix time is worth exactly as much as halving detection delay — and fix time is usually the bigger number.

#What this means in practice

• Measure your $q$. Seed known weaknesses (or use last year's findings that were reintroduced) and see how often your tests find them. A program with $q=0.5$ on a quarterly cycle has the same mean detection wait as one with $q=1$ on a half-yearly cycle.
• Track $r$ as a first-class metric. Time from proven finding to verified fix — not to ticket closure, to verified fix — is the number this model says you should obsess over once testing is continuous.
• Retest automatically. Without a retest, $R$ silently includes every fix that didn't actually work. The model treats a failed fix as an exposure that never closed.
• Use continuous testing to buy back fix time, not just detection. Proof of exploit and a minimal fix recommendation shorten $r$ directly; a list of scanner output does not.

#Run it on your own numbers

The model is four parameters and two lines of code. Plug in your own estimates — even rough ones — before arguing about test frequency:

from math import exp

def p_exploit_periodic(T, q, r, tau):
    a = exp(-T / tau)
    lap_w = (tau / T) * (1 - a) * q / (1 - (1 - q) * a)
    return 1 - lap_w / (1 + r / tau)

def p_exploit_continuous(d, r, tau):
    return 1 - 1 / ((1 + d / tau) * (1 + r / tau))

# quarterly tests that find 60% of issues, 21-day fixes, a 30-day adversary
print(p_exploit_periodic(91, 0.6, 21, 30))   # 0.887
print(p_exploit_continuous(1, 21, 30))       # 0.43

Three estimates do most of the work. $q$: the share of known-bad conditions your tests actually find — measure it by checking how many of last cycle's findings the next test re-discovered after they regressed. $r$: median days from a proven finding to a verified fix, by severity. $\tau$: pick the adversary you're defending against; for internet-facing systems the public time-to-exploit data argues for days, not months.

The output is a probability per exposure. Multiply by the number of exploitable exposures you expect per year — your historical findings rate is a reasonable proxy — and you have an expected count of exposures that were open long enough to be used. That is the number to put next to the testing budget.

#Limitations

This is a single-exposure model. It ignores dependence between exposures (one exposure often enables another; see our attack-path study), assumes attackers are memoryless (exponential $A$), and treats detection probability per test as constant. Real fix times are heavier-tailed than exponential; a lognormal $R$ with the same mean raises risk further because the long tail of slow fixes dominates. The attacker-speed values are anchors from public exploitation data, not measurements of attackers targeting any particular organization. None of these change the qualitative conclusions, but all of them change the numbers.

#Frequently asked questions

#Sources

1. [1] Mandiant (Google Cloud), “How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends,” 2024
2. [2] PCI Security Standards Council, FAQ on penetration and segmentation testing frequency for service providers