The 30-Day Gap Where Most Breaches Actually Happen

A vulnerability gets disclosed on a Tuesday. Proof-of-concept exploit code appears online by Thursday. Your patch, scheduled for the next maintenance window, is still three weeks away. That gap is not a technicality. It is where most real-world breaches actually happen, quietly, long before anyone notices anything is wrong.

The race that most businesses are quietly losing

Software vendors disclose vulnerabilities constantly, and most disclosures come with a patch already available on the day the flaw is announced. The trouble is what happens after disclosure. Security researchers, criminal groups, and automated scanning tools all move within hours or days, not weeks, often weaponising a disclosure before most IT teams have even read the advisory properly. Businesses, by contrast, tend to patch on a monthly cycle built around change management processes, testing windows, and staff availability, all sensible on their own terms but collectively slow compared with the pace on the other side. That mismatch in speed is the single biggest reason so many breaches trace back to vulnerabilities that already had a fix sitting unused somewhere in a ticketing system.

This is not a criticism of careful patch management. Testing updates before deployment is sensible practice, and rushing a patch into a production environment without checking for compatibility issues carries its own risk of outages. The answer is not to patch recklessly fast. It is to know, with confidence, exactly where your exposure sits at any given moment, rather than guessing based on last quarter’s picture. Regular vulnerability scan services gives you that visibility, flagging exactly which systems remain vulnerable to a disclosed flaw while your patching cycle catches up.

The 30-Day Gap Where Most Breaches Actually Happen — Aardwolf Security

Why the gap feels smaller than it is

Most IT teams genuinely believe their patch cadence is adequate, because a thirty-day cycle sounds reasonable on paper and matches what most vendors recommend as a baseline. The problem is that attackers do not wait thirty days out of courtesy. Automated tools scan the entire internet for specific vulnerable software versions within days of a disclosure, often faster than most businesses can even schedule a change request, let alone test and deploy one across every affected system, wherever it happens to sit in the environment.

William Fieldhouse has seen this exact timeline play out with uncomfortable regularity.

“We tested a client eleven days after a critical vulnerability was published for software they were running, and their internet-facing server was still exposed, sitting exactly where automated scanners would have found it days earlier”

— William Fieldhouse, Director of Aardwolf Security Ltd

Eleven days felt fast to that client’s IT team, and by the standards of a typical patch cycle, it was. It was also more than enough time for an opportunistic scan to locate the flaw and for an automated exploit to do the rest without any human attacker needing to get involved at all, or even choose that business specifically as a target.

Shrink the window, not just the patch cycle

Closing this gap does not mean patching everything instantly. It means knowing your real exposure at any given point, prioritising fixes for internet-facing and high-value systems first, and using independent testing to confirm what is actually reachable rather than trusting an assumption inherited from last year’s audit. Aardwolf Security’s ongoing internal network pen testing is built to keep that picture current, so the thirty-day gap stops being where your breach happens.

Share: