Two a16z pieces put numbers on the threat. RAND’s 2017 study: 22 days for a professional to turn a vulnerability into a working exploit. The August 2026 PaperCut campaign: under four hours, on a cheap open-weight model. Patching has not moved: a 30 day half-life in 2003, a 43 day median fix in 2026.
JPMorganChase’s technology leadership explained the gap. You can decide in hours and still need weeks to execute.
Both end in the same place: when the patch won’t arrive in time, prove you can recover.
Here is the part I think is missing
Code is becoming provable. Memory-safe languages remove whole bug classes by construction. In September 2026 an AI wrote a 13 million line, machine-checked proof of Fermat’s Last Theorem in 11 days.
No human can realistically read 13 million lines. The execs I talk to are uneasy about that, and they will give ground on human interpretability grudgingly. That feels right on risk.
What we will end up relying on is the spec: a short statement of the behavior we want, across the conditions that matter, that people have read and accepted. That is where the effort will go. Some teams are already there.
Tech ops and resilience are different
A recovery spans applications, infrastructure and people. There is no short spec to check it against. And a real event rarely follows the happy path: a step fails, a dependency is missing, and people have to adapt in the moment. You cannot easily prove that end to end. You can only run it.
Most firms can only run it in production, once a year, in a staged window, on the happy path. Then the estate changes and the evidence goes stale.
The ladder for how you know something works
So there is a ladder for how you know something works:
- Proven
- Tested continuously
- Tested rarely
- Believed
Code sits at 2 and is edging toward 1. Most recovery sits at 3. Some sits at 4. And it is the layer we fall back on when everything above it fails.
The job is to move recovery up a rung: exercised often, against the live estate, using the same thing you invoke when it is real.
Full disclosure: that is the work we do at Cutover, so weight my view accordingly.
Frequently asked questions
Why is it so hard to prove you can recover?
A recovery spans applications, infrastructure and people, and there is no short spec to check it against. A real event rarely follows the happy path, so you cannot easily prove it end to end. You can only run it.
What is the ladder for how you know something works?
It has four rungs: proven, tested continuously, tested rarely, and believed. Code sits at tested continuously and is edging toward proven. Most recovery sits at tested rarely, and some sits at believed.
Why does disaster recovery testing once a year fall short?
Most firms can only run a recovery in production, once a year, in a staged window, on the happy path. Then the estate changes and the evidence goes stale.
What does moving recovery up a rung look like?
Recovery that is exercised often, against the live estate, using the same thing you invoke when it is real.
Where does your recovery sit on that ladder?
The pieces referenced above
- The Exploit Was the Bottleneck (a16z, Nov 5, 2026)
- Defense in Depth, Rebuilt for Machine Speed (a16z, Nov 6, 2026)
- 200 days into the frontier: What we know and what to do now (JPMorganChase Global Technology Leadership Team, Nov 2, 2026)
- Formalizing Fermat’s Last Theorem (Anthropic, Sept 4, 2026)