The CrowdStrike outage in July 2024 was one of the largest IT disruptions in recent history, and it taught every business a hard lesson about operational resilience. A faulty update to CrowdStrike’s Falcon endpoint detection and response (EDR) tool caused Windows computers worldwide to crash before fully loading, grounding flights, shutting down TV stations, disrupting payment systems, and canceling surgeries. Microsoft confirmed the outage affected 8.5 million devices, roughly 1% of all Windows computers globally. The U.S. Cybersecurity and Infrastructure Security Agency issued a public alert on the incident the same day.
What made the incident especially painful was the lack of a quick fix. Each affected endpoint required manual rebooting, a time-consuming process that stretched recovery timelines from hours into days for many organizations. The incident exposed fundamental gaps in how businesses prepare for, respond to, and recover from large-scale IT failures.
Whether you run a small firm or manage enterprise infrastructure, the lessons from this disruption apply directly to your operations. Below are three critical takeaways every organization should act on now. Pairing these technology safeguards with strong financial controls is exactly the kind of work covered by risk advisory services.
Test Updates Before Rolling Them Across Your Organization
Patch management best practices exist for a reason, and the July 2024 incident is a textbook example of what happens when a software update bypasses adequate testing. A single faulty update to CrowdStrike’s Falcon sensor cascaded into a global crisis because the patch was deployed broadly without staged validation.
A well-designed patch management process includes two non-negotiable steps: testing and rollback planning. Testing means deploying updates to a controlled subset of systems first, such as a staging environment or a small group of endpoints, and monitoring for conflicts with existing configurations before wider rollout. This approach limits the blast radius if something goes wrong.
Why rollback procedures matter
Equally important is having a documented rollback plan. When an update causes problems, your team needs a clear, pre-tested process to revert affected systems to their previous state. During the Falcon outage, organizations without rollback procedures were left manually rebooting individual machines one by one. Those with automated rollback capabilities recovered significantly faster.
The broader lesson here extends beyond endpoint security tools. Any software update, whether an operating system patch, application upgrade, or firmware change, should go through a structured testing and approval workflow before reaching production systems. Patch management best practices are not just a compliance checkbox; they are a direct line of defense against exactly the kind of cascading failure this incident demonstrated. The NIST Cybersecurity Framework treats this kind of change control as a core safeguard.
Organizations that take testing seriously build what security professionals call “defense in depth.” They use canary deployments, phased rollouts, and automated monitoring to catch problems early. This discipline does not eliminate risk entirely, but it dramatically reduces the chance that a single bad update takes down your entire operation.
Have a Business Continuity and Disaster Recovery Plan
A business continuity and disaster recovery plan is no longer optional. It is a baseline requirement for any organization that depends on technology, which today means every organization. The July 2024 event proved that even companies using industry-leading security tools can face sudden, widespread downtime through no fault of their own. Federal guidance at Ready.gov outlines how to structure such a plan.
Many businesses affected by the outage did not have a tested disaster recovery plan IT teams could activate quickly. Without one, they scrambled to improvise analog workarounds: handwriting boarding passes at airports, processing payments manually, and reverting to paper-based record systems. The organizations that recovered fastest were those that had already documented and rehearsed their response to exactly this type of scenario.
What a strong disaster recovery plan includes
A disaster recovery plan for IT should cover several key areas. First, it should define recovery time objectives (RTOs) and recovery point objectives (RPOs) for every critical system. These metrics set clear targets for how quickly systems must be restored and how much data loss is acceptable. Second, the plan should identify alternative operating procedures, meaning what your team does when primary systems are unavailable. Third, it needs to be tested regularly, not just written and filed away.
The incident also highlighted the importance of employee training. A disaster recovery plan is only useful if the people who need to execute it know it exists and understand their roles. When a major outage hits, there is no time to read through a binder for the first time. Regular tabletop exercises and simulation drills help teams respond quickly and confidently when real incidents occur.
Consider the impact on CrowdStrike itself: the company’s shares closed down about 11% on July 19, 2024, the day of the outage, and continued sliding in the weeks that followed as customer-trust and liability concerns mounted. For the businesses that depended on Falcon, the costs included lost revenue, damaged customer trust, and operational chaos. A documented, tested business continuity plan cannot prevent every outage, but it can dramatically shorten recovery time and protect your organization’s reputation.
Know Your Third Parties and Review Their Security Annually
Third-party risk management is one of the most overlooked areas of cybersecurity, and the Falcon incident brought it into sharp focus. Before July 2024, many business leaders outside the information security world had never heard of CrowdStrike. They knew Microsoft and Windows, but the critical security tool running on their endpoints was invisible to them until it caused a global outage.
This lack of visibility is the core problem that third-party risk management addresses. Every organization relies on a chain of vendors, software providers, and service partners. Each one represents a potential point of failure. If you do not know who your upstream and downstream service providers are, you cannot assess the risk they introduce or plan for their failure.
How to build a third-party risk review process
Effective third-party risk management starts with maintaining a complete inventory of your vendor relationships, including the software and services each vendor provides. From there, you should conduct security reviews on a regular cycle, at minimum annually, and more frequently for vendors with access to sensitive data or critical infrastructure.
These reviews should evaluate each vendor’s security posture, incident response capabilities, business continuity plans, and compliance certifications. Ask your vendors how they test their own updates before deployment. Ask what their recovery process looks like when something goes wrong. The July 2024 event demonstrated that even well-respected vendors can ship flawed updates, so “trust but verify” is the right approach. For finance and accounting functions, our accounting services team can help you weigh the operational and financial exposure each vendor introduces.
The consequences of ignoring third-party risk are real and growing. Just weeks before the Falcon incident, a hacking event at Synnovis, a third-party pathology provider, forced multiple London hospitals to cancel non-emergency appointments. These are not isolated events. They are part of a trend that makes third-party risk management a board-level priority for every organization.
Building strong vendor relationships also means establishing clear contractual expectations around security standards, incident notification timelines, and liability. When your vendors know you take security seriously, they are more likely to prioritize it themselves.
Taking Action After the Outage
The CrowdStrike outage was a wake-up call for organizations of every size and industry. The three lessons it reinforced, namely rigorous patch management, tested disaster recovery planning, and proactive third-party risk management, are not new concepts. But for many businesses, the event was the catalyst that moved these priorities from “someday” to “now.”
Start by auditing your current patch management process. If updates go straight to production without staged testing, fix that immediately. Next, review your business continuity and disaster recovery plan. If it has not been tested in the past year, schedule a tabletop exercise. Finally, build or update your third-party vendor inventory and commit to annual security reviews.
The next major IT outage is not a question of if, but when. The organizations that survive it with minimal disruption will be the ones that learned from this incident and took action before the next incident arrived.
Frequently Asked Questions
What caused the CrowdStrike outage in July 2024?
A faulty update to CrowdStrike’s Falcon EDR tool that ran on Microsoft Windows systems. The defective update caused Windows computers with Falcon installed to crash before fully loading, affecting approximately 8.5 million devices worldwide. The fix required manually rebooting each affected endpoint, making recovery slow and labor-intensive.
How can businesses prevent major IT outages?
Businesses can reduce their exposure to IT outages by implementing patch management best practices, including staged testing of all software updates before broad deployment. Using canary deployments, maintaining rollback procedures, and monitoring systems after each update cycle are all proven ways to catch faulty updates before they cause widespread disruption.
What should a disaster recovery plan include for IT systems?
A disaster recovery plan for IT should define recovery time objectives and recovery point objectives for every critical system. It should document alternative operating procedures for when primary systems fail, identify the team members responsible for executing each step, and be tested through regular simulation exercises to ensure readiness.
Why is third-party risk management important after a major IT outage?
Third-party risk management is critical because the CrowdStrike outage showed that even trusted vendors can introduce catastrophic failures. Organizations that did not know Falcon was running on their systems had no way to anticipate or plan for the disruption. Maintaining a vendor inventory and conducting annual security reviews helps identify and mitigate these risks proactively.
How often should businesses test their business continuity plans?
Businesses should test their business continuity and disaster recovery plans at least once per year through tabletop exercises or full simulation drills. Organizations in highly regulated industries or those with complex IT environments should test more frequently. Regular testing ensures employees know their roles and that the plan reflects current systems and processes.
What is the difference between business continuity and disaster recovery?
Business continuity planning focuses on maintaining essential operations during and after a disruption, including non-IT functions like customer communication and manual workarounds. Disaster recovery is a subset that specifically addresses restoring IT systems, data, and infrastructure. Both are necessary, and the July 2024 incident demonstrated that organizations need plans covering technology recovery and operational continuity simultaneously.
