Most successful attacks don't use a new technique. They use a flaw the vendor already fixed months earlier. According to the latest Verizon report on data breaches, exploiting a software vulnerability now accounts for 31% of breaches recorded worldwide — for the first time, ahead of stolen passwords as the most common way in.
The fix almost always exists before the attack happens. That's why, in the United States, the government's cybersecurity agency (CISA) now requires federal agencies to remediate flaws within a window that ranges from a few days to a few months, based on the risk of each vulnerability in the catalog of flaws already used in real attacks. The agency's latest rule, issued in June 2026, prioritizes by risk — not by the order updates arrive.
This matters to whoever decides at a company because the math always favors one side. Applying the update costs a maintenance window scheduled in advance. Not applying it costs an attack through a door that could already have been closed — and the difference is almost never technical. Nobody set a date, nobody tested it first, or nobody wanted to be the one who authorized touching a system that "is working."
The Flaw That Already Had a Cure
A software vulnerability is a gap in a program the company uses every day — a way around its security that the vendor itself didn't foresee. Once it's discovered, the vendor releases a fix. From that moment, the flaw stops being a secret: it becomes public, documented, and any attacker can read exactly what it allows.
That gap — between the fix existing and the fix being installed — is what decides the outcome. The most recent survey on data-hijacking attacks, run by security firm Sophos among 2,158 IT leaders at companies hit by this kind of attack across 17 countries, found that an exploited vulnerability was the root cause in 18% of cases in the last year — after leading that ranking for three years running, reaching 32% in the previous survey.
The drop is good news. But the most cited reason companies were hit hasn't changed in two years: 62% of respondents pointed to a known or unknown security gap as what opened the door for the attack. "Known" is the word that stings: it means someone, at some point, knew about the flaw — and it stayed open anyway.
This isn't exclusive to large companies or a specific industry. It's the effect of treating "it's working" as a synonym for "it's secure." The two have no relationship at all: a server can run without crashing for years while, at the same time, carrying an open door the vendor already warned everyone to close.
Why the Usual Approach Doesn't Work
The usual approach is to leave the security update for later. Sometimes because nobody wants to risk stopping a system that's working; sometimes because the finance, inventory, or production software's current version "isn't approved" for the new one, and switching versions feels like too big a project to treat as routine.
The problem is that "later" has no date attached. Without someone responsible for deciding when and how to apply each update, it enters a queue that never moves — and the server that has run for three years without a restart carries, along with that stability, three years of fixes that were never installed.
The other version of the same problem is applying the update straight to the live system, without testing it first, and hoping nothing breaks. When something does break once — the system freezes, a report stops closing, an integration stops working — the lesson that sticks is "updating is risky," and the next one gets postponed with even more justification. It's a cycle that feeds itself.
What Has to Be in Place
An IT setup that treats this as routine, not emergency, relies on concrete mechanisms.
An inventory of everything the company has running. Without knowing which systems, servers, and programs exist — and which version — there's no way to know which ones have a fix available and waiting to be applied.
Priority by risk, not by order of arrival. A flaw already being used in real attacks, on a system reachable from outside the company, needs a fix within days. A theoretical flaw on an isolated system can wait for the next scheduled maintenance. Treating both the same way is what keeps the queue from ever moving.
A maintenance window scheduled in advance. Instead of applying the update as a surprise, the date is set, announced, and planned for the slowest hours — which removes the fear that "it'll stop the system without warning."
Testing before applying to the live system. A separate environment, even a simple one, where the update is tested before reaching the system the company uses every day, is what separates "updating safely" from "hoping it doesn't break."
Logging the cause and the fix for every ticket. When a problem shows up after an update, the next person doesn't waste time rebuilding something that was already solved once.
This is how Skills IT works: with an inventory of what each client has running, risk-based priority for fixes, and a maintenance window scheduled before any update reaches the live system.
The Payoff for the Company
The payoff of treating updates as routine isn't abstract. It's less staff time firefighting after a system stops mid-shift, and less risk of an attack through a door that could have been closed months earlier.
The scale of the problem, when it goes wrong, shows up in industry numbers: the average cost to recover a company from a data-hijacking attack — not counting any ransom paid — reached $1.7 million per incident in Sophos's latest survey, an 11% increase from the year before. That figure isn't about one isolated case; it's the average across more than two thousand companies hit, across 17 countries.
There's also a less visible payoff: predictability. A company that already knows when and how it applies each update doesn't have to decide that on the spot, under pressure, after something has already gone wrong. The decision becomes a calendar entry, not a crisis.
And there's a people payoff: when the update is tested beforehand and announced in advance, whoever works on the system isn't caught off guard, and IT stops being synonymous with "the team that breaks things without warning."
Questions to Bring to the Next Meeting
Before asking "when are we updating" again, it's worth asking what exists so the company can decide this without relying on luck:
- Does anyone know, today, which systems have a security update available and not yet applied? If the answer requires calling someone to ask, the inventory doesn't really exist.
- Is there a criterion for deciding what gets fixed first? Without risk-based priority, the queue moves by order of arrival — and the most dangerous flaw can end up waiting behind an unimportant one.
- Is the update tested before it reaches the system the company uses every day? Without testing, every update is a gamble.
- Is there a scheduled maintenance window, or is every update a surprise? Surprise is what turns routine maintenance into a reason for resistance.
- If a critical flaw were discovered today in a company system, who decides when it gets fixed? If the answer is "nobody, we haven't thought about it," that's the first problem to solve.
