72 minutes: the new speed of an attack, and what it changes

The fastest attacks now move from break-in to data theft in about the time it takes to run a status meeting. Here's what that means if you don't have an enterprise security budget.

Palo Alto Networks' incident-response team published its annual report this month, and one number is doing the rounds: in the fastest cases they investigated, attackers went from initial access to stealing data in 72 minutes. That's four times faster than the year before.1

Every security vendor will quote that number at you this quarter. Almost none of them will translate it for a company that doesn't have an enterprise security budget. So let's do that.

Most mid-market security postures are built — often without anyone saying it out loud — on a "detect and respond" assumption: something bad gets in, tools raise an alarm, people investigate, damage gets contained. That model has a hidden variable: it assumes the response happens faster than the attack.

At 72 minutes, it usually doesn't. Not because your people are slow, but because the arithmetic is unforgiving. An alert fires at 2 a.m. Someone has to see it, judge it against the hundred false alarms that fired that week, escalate it, and act. In a company without a 24-hour security operation — which is nearly every company we work with — that loop takes hours on a good day.

The uncomfortable conclusion: for the fastest class of attacks, the response will arrive after the data is gone. Planning as if it won't is the actual risk.

If response can't reliably outrun the attack, three other things have to carry more of the load:

Prevention gets more valuable, not less. The unglamorous basics — multi-factor authentication everywhere, patched systems, no forgotten internet-facing servers — matter more when there's no second chance behind them. It's fashionable to say "assume breach"; it's more accurate to say "assume breach, and make the breach hard anyway."

Blast radius becomes the design goal. The 72-minute attacker takes what they can reach. The design question for your environment is: from any single compromised laptop or account, how much is reachable? Segmentation, least-privilege access, and separated backup infrastructure aren't enterprise luxuries — they're what makes a bad hour survivable.

Recovery must be assumed, not hoped against. Tested restores, offline copies, and a rehearsed decision chain. If the last recovery test was a checkbox in an audit, it isn't a capability; it's a hope.

None of this requires buying what the enterprise next door buys. In the mid-market, architecture and governance have to do the work that a security operations center does elsewhere — and done well, they do it surprisingly well.

The predictable response to a scary number is a procurement cycle: a new detection platform, a managed monitoring contract, another agent on every endpoint. Sometimes justified. But tooling bought to soothe a headline, without the architecture underneath, mostly produces more alerts for the same overwhelmed people.

Spend on the structure first. Then let the structure tell you what tooling it's missing.

If the answers are fuzzy, that's normal — and fixable. Our Resiliency Report turns exactly these questions into a scored, NIST CSF 2.0-based self-assessment you can take in about ten minutes. For the fuller argument on continuity in the cloud and AI era, the Resilient Business in the Age of AI report goes deeper.

Seventy-two minutes is a sobering number. It's also, handled correctly, just a design constraint — and design is a leadership decision, not a product category.