In the early hours of July 19, 2024, millions of screens across airports, hospitals, banks and data centers turned blue. A single faulty update was enough to halt flights, scheduled surgeries and stock exchange operations within minutes. The question that day left behind was not "who do we blame?" but a far more uncomfortable one for any board of directors: if a single supplier fails tomorrow, how long does your organization survive before the customer notices?
The bottom line: July's global outage proved that fragility no longer comes from sophisticated attacks, but from invisible dependencies and uncontrolled rollouts. Operational resilience is not an IT project: it is a governance discipline that is designed, tested and measured. Those who treat it as a technical expense will keep fighting fires; those who turn it into an institutional capability will turn the next outage into a competitive advantage.
For years, operational continuity lived buried in an appendix of the IT plan that almost no one read. July changed that conversation. When a single dependency can paralyze billing, customer service and the supply chain at the same time, the risk stops being technical and becomes strategic.
The difference between the companies that lost hours and those that lost days was not in the technology, but in the decisions made long before the incident: how suppliers were concentrated, how changes were rolled out and whether anyone had tested the recovery plan with a stopwatch in hand. Resilience, in other words, is what you build on the calm days.
Efficiency led many organizations to consolidate around a single provider of cloud, security or critical software. That concentration lowers costs, but it creates a single point of failure that no service-level agreement compensates for when the entire system goes down at once.
Building diversity does not mean duplicating everything, but identifying where a dependency is existential and creating real alternatives:
July's incident spread so quickly precisely because the update reached all machines simultaneously. The resilient organization assumes that any change, its own or a third party's, may be faulty, and designs its entry so the damage is containable.
A staged rollout does not eliminate errors; it turns them into a local scare instead of a global catastrophe.
Most organizations have a continuity plan. Few have tested it under real pressure. A plan that lives in a PDF signed three years ago is, in practice, documented fiction: no one knows whether the emergency phone lines are still active, whether the backups actually restore, or whether key staff know what to do without access to their usual systems.
Testing is the only way to know the plan works. At SUMāTO we help our clients transform the continuity plan from a compliance formality into a living capability. Learn about our business continuity approach at https://sumatogroup.com/bcp.
When the incident occurs, value is measured in speed. Two metrics must be known and accepted by leadership, not only by the technical team: RTO (recovery time objective, how long a process can be down) and RPO (how much data can be lost without irreversible harm).
Fast recovery depends on three ingredients prepared in advance:
Here is the deepest change July left behind. As long as resilience is fully delegated to the technical team, it will keep competing for budget against more visible initiatives and lose. The resilient organization elevates the topic to the board and treats it as what it is: strategic risk management.
A short list your team can review this very week:
Business continuity covers how to keep essential processes running during a disruption, including manual procedures and crisis roles. Disaster recovery is the more technical component: how to restore systems, data and infrastructure. A resilient organization needs both, aligned and tested together.
At a minimum, once a year for a comprehensive exercise, and quarterly for critical components such as backup restoration. Any major change in systems or suppliers should trigger an additional test. A plan that hasn't been tested in the last year should be considered unvalidated.
It isn't about duplicating everything, but about investing in redundancy only where the dependency is existential. The right calculation compares the cost of that selective redundancy against the real cost of a prolonged outage: lost revenue, reputational damage and contractual penalties. Properly sized, diversity is cheaper than a single serious outage.
With the critical dependency map and verification that your backups actually restore. Those two exercises reveal most of the hidden risks and require no large upfront investment, only discipline.
The July outage was a free warning: next time, the cost will be paid by whoever failed to build resilience before the incident. The best time to test your continuity plan is not during the crisis, but today, calmly and methodically. At SUMāTO we help boards and leadership teams across Latin America turn resilience into a measurable, tested capability. Let's talk about where your organization stands and what your first concrete step is: https://sumatogroup.com/contacto.