Understanding the Incidents
In July 2024, a routine software update from Crowdstrike caused a global cascade failure. A faulty patch locked systems worldwide, grounding airline fleets, shutting health care providers out of electronic health records, and blocking consumers from financial accounts. No breach occurred. No attacker exploited a vulnerability. A configuration error in a widely deployed endpoint protection platform brought operations to a standstill across industries.
Months later, a Domain Name System error at Amazon Web Services (AWS) caused a similar ripple effect, taking down thousands of messaging, media, and banking services. Again, no malicious actor was involved. The failure originated in the infrastructure layer that thousands of organizations depend on to deliver their services.
Both incidents were resolved quickly. Had they persisted for days instead of hours, the financial damage could have escalated from inconvenience to existential threat for many businesses.
Incident Timelines
Crowdstrike Incident (July 2024)
- Vendor releases faulty patch update.
- Systems running the update experience immediate failures.
- Airlines begin canceling and delaying flights.
- Health care providers lose access to patient records.
- Financial services become inaccessible to customers.
- Crowdstrike identifies the issue and deploys corrective measures.
- Systems gradually restore over several hours.
AWS Incident (October 2025)
- DNS configuration error occurs within AWS infrastructure.
- Thousands of customer-facing applications go offline simultaneously.
- Organizations lose ability to serve customers through digital channels.
- AWS engineering teams diagnose and resolve the DNS issue.
- Services return to normal operation.
Identifying Coverage Gaps
These incidents highlight a critical vulnerability: reliance on external systems that internal security measures can't mitigate.
Missing Coverage Layer
Most affected organizations held Cyber Liability Insurance policies, but few had explicit dependent system failure coverage. Standard cyber policies focus on breaches and liability from your own security failures. They don't cover losses when a vendor's operational failure shuts down your business.
Inadequate Vendor Risk Assessment
Organizations often assess vendor security for data protection and breach prevention but rarely evaluate insurance response when a vendor's failure stops revenue generation. The gap is in financial protection, not security controls.
Undefined Critical Vendor Designation
Many businesses couldn't answer a basic question after these outages: Does our policy define Crowdstrike or AWS as a "critical vendor" for Contingent Business Interruption coverage? If your policy requires a direct contractual relationship with the failed vendor, and you access AWS through a SaaS provider, you may have no coverage despite complete operational dependency.
Standards and Their Limitations
NIST CSF addresses supply chain risk management, requiring organizations to identify and prioritize critical suppliers. However, it doesn't specify financial risk transfer mechanisms for dependency failures.
The Insurance Data Security Model Law requires insurers to manage third-party service provider risks but doesn't mandate dependent system failure coverage.
NIS2 requires critical entities to implement supply chain security measures and business continuity management. Yet, compliance doesn't guarantee insurance coverage for third-party operational failures.
These standards establish operational resilience requirements but don't ensure your policy will pay when a vendor's infrastructure fails. That's a procurement gap, not a compliance gap.
Action Items for Your Team
Review Your Policy for Specific Clauses
Check your Cyber Liability Insurance policy for "Contingent Business Interruption" and "System Failure" language. If your coverage is an endorsement to a Business Owners Policy rather than a Stand-Alone Cyber Policy, you likely lack dependent system failure coverage.
Clarify Critical Vendor Definitions
Ask your broker or insurer how the policy defines "critical vendor" and what documentation establishes that relationship. If your operations depend on AWS but you access it through Salesforce, ensure the policy recognizes that dependency chain. Get these answers in writing.
Understand What Constitutes a Covered Event
Determine whether your policy requires a minimum disruption duration, covers DNS errors and patch failures, and applies when the vendor resolves the issue before you can quantify lost revenue. These details determine whether coverage exists in practice.
Document Your Operational Dependencies
Create a dependency map identifying every external system required for revenue generation. Note whether you have a direct contract, whether the vendor qualifies as "critical" under your policy, and what documentation you'd need to substantiate a claim.
Calculate Your Exposure
Estimate your hourly revenue loss if your three most critical vendors went offline for 24 hours. Compare that figure to any sublimits in your Contingent Business Interruption coverage. If the sublimit is $100,000 and your daily revenue is $500,000, you're self-insuring most of your risk.
Engage a Cyber Insurance Specialist
Dependent system failure coverage is complex and inconsistently offered. A broker specializing in cyber insurance can identify which carriers offer robust System Failure clauses and which definitions create coverage gaps.
The Crowdstrike and AWS incidents were resolved quickly. Your exposure wasn't tested. Next time, you may not be that fortunate. The question isn't whether another major vendor will experience an operational failure. The question is whether your policy will respond when it happens.
