Forty-Eight-Hour Cadence Beats Annual Pentest: The Economics of Continuous Validation

1. The quarterly pentest is a 2008 procurement artifact

Most enterprise security programmes still schedule penetration testing on an annual or quarterly cycle. The cadence is not derived from threat tempo. It is derived from procurement tempo, quarterly budget cycles, annual compliance attestation windows, and the historical reality that a high-quality pentest required a specialist consultancy to fly two people in for a week. The cadence made sense in 2008 when application change frequency was monthly and CVE publication rate was on the order of a dozen high-severity issues per week.

The cadence has not survived contact with the modern operational tempo. The CVE programme published 28,902 CVEs in 2023, 40,003 in 2024, and is on pace for over 50,000 in 2025. CISA KEV, the lower bound on observed exploitation, adds 5-15 entries per week. Mandiant's M-Trends 2025 measures median time-to-exploitation for high-severity CVEs at under five days. A pentest scheduled quarterly samples the customer's surface once every twelve weeks against a threat environment that turns over every five days. The sampling rate is roughly twenty times slower than the underlying signal. The aliasing is not a bug in the pentest, it is a bug in the cadence.

The right cadence is the one that catches a newly-emerged exposure before the attack window closes. For CVEs in CISA KEV, that window is days. For application-class bugs introduced by ongoing engineering change, the window is the next deploy. The cadence that satisfies both is sub-weekly. Our default is forty-eight hours.

2. The forty-eight-hour math

A forty-eight-hour re-scan cadence means every customer asset is re-evaluated against the catalogue within two days. The catalogue itself is refreshed nightly by the research chain, so a newly-published CVE that projects against a customer asset gets tested within forty-eight hours of catalogue inclusion plus one nightly chain interval, typically twelve to forty-eight hours from CVE publication.

The probability calculation is straightforward. Suppose a newly-published high-CVSS CVE that affects a customer asset has a daily probability p of being exploited if unpatched (the EPSS score on a daily basis). Suppose the customer's mean patch time after disclosure is t days. The probability of exploitation before patch under a scan cadence of s days is approximately 1 - (1 - p)^(s + 0.5 * t), the scan cadence delays disclosure to the customer by up to s days, then the patch takes a further t days on average.

For a moderately exploited CVE (p = 0.05/day) and a typical seven-day patch time, the difference between a quarterly cadence (s = 90) and a forty-eight-hour cadence (s = 2) is dramatic. At s = 90, the cumulative exploitation probability before patch lands at roughly 99.0 percent: meaning a customer running quarterly scans is, in expectation, exploited before they patch. At s = 2, the cumulative probability drops to roughly 26.6 percent. The compounded reduction across the customer's full active-CVE backlog is the entire business case for continuous testing.

The forty-eight-hour cadence does not eliminate exposure. It bounds it. The customer who patches in seven days under a forty-eight-hour cadence is exposed for a maximum of nine days per finding. The customer who patches in seven days under a quarterly cadence is exposed for a maximum of ninety-seven days per finding. The difference is the area under the curve where attackers operate without defender visibility.

3. The dispatch architecture

Continuous scanning at this cadence requires architecture the traditional pentest model does not. Three components are non-negotiable.

Per-customer scan schedules. Each customer has at least one scheduled scan registered in our Temporal scheduler, staggered across the 24-hour clock so the load on our scanner pool is smooth and the load on the customer's edge is bounded. The schedules survive worker restarts (they are persisted in the scheduler's catalogue, not in process memory). The schedules are deterministic, {engagement}-{daily} workflow IDs prevent duplicate dispatch on re-runs.

Bounded-budget execution. A scan that takes too long blocks the next scheduled scan. Every test in the catalogue declares an expected duration and a hard ceiling; the scheduler enforces the ceiling. Tests that exceed the ceiling produce partial results, never PASS-by-omission. The partial result is itself a finding, surfaced to the engagement team as "test could not complete within budget" with the relevant evidence captured up to the cutoff.

Per-test capsule persistence. Every test execution produces a signed Test Capsule. The capsule records inputs, outputs, decision rule, and verdict. Three months later, when the customer asks "did you run this against this asset on this date?", the answer is queryable. The cadence is only meaningful if the evidence survives.

4. The objection that customers raise first

The most common objection from a customer evaluating the forty-eight-hour cadence is alert fatigue. The objection has three parts:

> "If you run this twice a week, the SOC will be drowning in your scan traffic." > > "The development team will reject every new finding because the previous one is still in the queue." > > "Our quarterly compliance report works fine."

The first part is operational and solvable. We onboard with the SOC: we publish the source IP ranges, we share the scan windows in advance, we acknowledge alerts from the SOC about our traffic and confirm whether the scan is in-policy. The SOC reaction to a known continuous scanner is structurally different from the reaction to a one-off pentest, they tune their detection logic once and the traffic becomes background.

The second part is a triage-queue problem, not a scan-frequency problem. A development team drowning in new findings is one whose existing backlog is too large; the right remediation is not less testing but better triage. We rank findings by EPSS-weighted triage score so the top of the queue is always the most actionable item, and we promote findings into the customer's ticketing system at a rate the engineering team controls. The forty-eight-hour cadence does not create twenty-four findings per week per asset, it creates one or two, because the surface does not change that fast.

The third part is the only one where the customer is right in the narrow sense and wrong in the broad sense. A quarterly compliance attestation does work as a compliance artifact. It does not work as a security control. The compliance artifact verifies that you tested. The security control verifies that you are still defended. Continuous testing produces both.

5. What forty-eight hours catches that quarterly does not

Three concrete classes of finding that we routinely catch within forty-eight hours of introduction, and that a quarterly cadence would miss for weeks or months:

Regression on a previously-fixed finding. A development team patches a SQL injection in the order-history endpoint. Eight weeks later, a refactor reintroduces the vulnerable code path. A quarterly scan catches this 0-13 weeks after introduction. A forty-eight-hour scan catches it within two days. The patched finding is a Test Capsule in our store; the regression detection is automatic.

New asset that drifts out of policy. A platform team spins up a new public-facing service. The service was supposed to be behind the auth proxy; a load-balancer rule mistake exposed it directly. A quarterly scan catches this 0-13 weeks after spin-up. A forty-eight-hour scan catches it the night the asset shows up in our recon pipeline, typically within twenty-four hours of DNS publication.

Freshly-public CVE that projects against the customer's stack. A high-EPSS CVE drops at 18:00 UTC. The catalogue update lands at 03:00 UTC the next morning. The customer's scheduled scan runs by 03:00 UTC the following morning. Total elapsed time: under forty-eight hours. A quarterly customer learns about the same CVE when the next pentest reads our blog.

6. What we ask every customer

The continuous-cadence question is rarely whether the cadence is right. It is whether the customer's organisation can absorb continuous findings. Our default contract starts at the forty-eight-hour cadence and lets the customer dial back to weekly or daily based on operational readiness. Customers who start at weekly typically move to forty-eight hours within two months; customers who start at forty-eight hours typically stay there. We have one customer running on a twelve-hour cadence and the catalogue is the bottleneck rather than their team.

There is no premium tier for the forty-eight-hour cadence. There is no upgrade path. The cadence is the product. The quarterly pentest is the legacy of a slower decade, and the customers who have stopped paying for it tell us they sleep better.

Verifiable security.