- On 19 July a faulty update to CrowdStrike security software crashed millions of Windows computers worldwide.
- Airports, banks and hospitals suffered disruptions, Spain included: it was not a cyberattack but an error.
- It is worth having backups, manual procedures and a clear way of communicating with clients if systems fail.
On 19 July 2024, a faulty update to CrowdStrike security software crashed millions of Windows computers worldwide. Airports, banks and hospitals suffered disruptions, Spain included. Within hours, companies of all sizes found themselves with frozen screens, systems that would not start and services that stopped working without anyone having suffered any attack. For many of them, it was the first time they saw how far their activity depends on each workstation’s computer working.
The episode was especially instructive because it had no malicious origin. What paralysed so many organisations was an error in a piece of software designed precisely to protect them. That paradox explains why specialists have long insisted that IT security is not only about preventing attacks but also about being able to keep working when something fails. The incident shifted the conversation from defence towards resilience.
What failed
A faulty update to a security program crashed millions of Windows computers. It was not a cyberattack but an error, yet its effects resembled one: the disruption reached very different critical sectors. The affected machines could not start normally and had to be dealt with one by one to be recovered. In the meantime, activity depended on what each organisation had planned for operating without systems.
That circumstance explains why recovery was slow in many organisations. When the fault lies in the system itself and not in a central server, switching off and on is not enough: technical staff, time and procedures are needed. Companies with many workstations, or with equipment spread across different sites, were the slowest to return to normal. For customers, the result was queues, delays and limited services, often without a clear explanation in the first hours.
A shared dependency
The incident showed the dependence on a handful of technology providers. When many organisations use the same software, a single fault can hit them all at once, including those that had nothing to do with the error. The efficiency of using common tools has as its counterpart a shared risk that is rarely calculated. It is the price of convenience: what simplifies day-to-day management also concentrates the points of failure.
For a small business, this does not mean ceasing to use trusted suppliers but knowing which ones it really depends on and what would happen if one of them failed. Sometimes the dependence is hidden: a booking system, a payment gateway or an invoicing program that uses someone else’s tool in the background. Knowing that chain is the first step towards managing it. Asking suppliers how they handle updates and what guarantees they offer is part of that review.
A contingency plan
An IT contingency plan is as necessary as insurance. It is worth having up-to-date backups and checking that they can be restored, having manual procedures to keep serving clients and a clear way of communicating with them if systems stop working. All of this should be written down and within reach of those who have to apply it.
A good plan answers a few simple questions: which processes are critical, how long the business can last without them, who decides what is done and how clients and employees are informed. Rehearsing it once a year, even in a simple way, makes it possible to discover flaws before they become costly. And it is worth checking what insurance covers in the event of a technology interruption. Insurance does not replace a plan, but it helps absorb the cost when the plan is overwhelmed.
Technology fails, and what matters is how work carries on.
This article is general information. It is not legal, tax or investment advice, and it does not take anyone’s particular circumstances into account.
