Cybersecurity leaders are dealing with a threat landscape where disruption spreads quickly across systems, vendors, and business operations. AI is accelerating how quickly attackers identify and exploit weaknesses, while identity-based attacks and growing third-party dependencies are making incidents harder to contain. At the same time, operating across cloud environments means it is increasingly difficult to fully understand and manage.
Many organizations still focus their preparedness efforts on isolated incidents and predictable scenarios. In reality, cyber events are rarely isolated. It’s entirely possible for a ransomware event to overlap with a cloud outage, limiting access to recovery tools while compromised credentials create uncertainty around which systems can still be trusted.
For CISOs, CIOs, and technology leaders, the challenge extends beyond preventing attacks to ensuring that critical business functions can continue operating when multiple systems, vendors, or processes fail simultaneously.
Why Traditional Tabletop Exercises are Not Enough
Traditional tabletop exercises and scenarios often fail to capture how cyber incidents unfold inside a complex business environment.
Most organizations test for success rather than failure. They simulate a ransomware attack, follow communication procedures, validate escalation paths, and end the exercise. The plan seems effective because the scenario is familiar, controlled, and has known failure points. While the approach builds confidence, it does not prove or challenge true readiness.
During a real disruption, teams make decisions as the situation unfolds in real time. They may not know the extent of an incident, which business functions need to recover first, or how long a vendor outage will last. Exercises that follow a predictable script do not prepare teams for that kind of environment.
Many organizations fail to discover the limits of their plans until a real disruption occurs. Recovery procedures may depend on systems or vendors that were never treated as critical, and timelines may depend on assumptions that were never validated. Systems may come back online while business processes remain impaired because the people, data, third parties, or workflows needed to operate them are still unavailable. This is the difference between restoring systems and restoring the business.
Cyber Risk is Becoming Harder to Assess
Cyber risk is complex. Attackers no longer need to rely solely on malware or a perimeter compromise to cause material disruption. Increasingly, they gain access through compromised credentials, session hijacking, and identity exploitation. If an organization is still assessing risk primarily through the lens of endpoints and perimeter controls, it may be missing where serious exposure now begins.
Security teams used to have more breathing room between a vulnerability becoming public and attackers exploiting it. That window is shrinking, forcing organizations to make critical decisions under tighter timelines.
Deepening reliance on third parties adds another layer of complexity. Cloud platforms, SaaS applications, managed services, and third-party integrations are deeply embedded in day-to-day operations. When one of those providers goes down, the impact rarely stays isolated to a single system or team.
A cyber event quickly becomes an operational event when an organization cannot see what is impacted, which dependencies are most critical, and which decisions must be prioritized.
Rethinking Cyber Scenario Testing and Planning
Scenario testing and planning should reflect how disruption actually happens: moving beyond expected scenarios and testing severe but plausible combinations of events.
For example, rather than testing a standalone ransomware incident, an organization tests a scenario in which ransomware encrypts a core platform while a critical SaaS provider is unavailable. During the same exercise, identity services may be partially impaired, forcing teams to validate which systems can still be trusted. Customer support may be operating with reduced capacity, while legal and executive teams evaluate notification requirements and customer communications.
This scenario demonstrates how operational strain builds. Individually, each issue may be manageable. Together, they reveal whether an organization understands its dependencies, whether teams can coordinate across functions, and whether recovery priorities are aligned with business impact.
What to Pressure Test Before a Real Disruption
The most valuable exercises are usually the ones that highlight where the response starts to break down. Teams should be forced to work through situations where multiple services are affected at the same time, where a vendor is unavailable, or where restored systems cannot immediately be trusted.
They also bring IT, operations, legal, communications, customer support, compliance, and executive leadership to the table. If these groups are not practicing together, the organization is not testing how the response will actually work.
This becomes especially important because any major incident comes with trade-offs. A technical team may be focused on restoration, while the legal team focuses on notification requirements. Customer teams focus on service disruption while executives need to decide what level of risk the organization is willing to accept. Those decisions should not be made for the first time during a live crisis.
Turning Testing into Measurable Readiness
A good exercise should leave teams with more than a checklist and a few observations.
Organizations should come out of exercises with a clear view of what failed, why it failed, who owns the fix, and how the issue connects to business impact. A gap affecting a low-priority internal process should not be treated the same as a gap affecting a revenue-generating service, customer obligation, or regulated function.
Understanding which dependencies matter most and which services carry the greatest exposure are critical. Without that context, every gap can look equally important, and teams may spend time fixing what is visible rather than what is material.
Testing cannot stay static in a business that is constantly changing. Infrastructure, vendors, business priorities, and threat patterns are always evolving. A scenario that was useful 12 months ago may no longer reflect how the organization operates today.
Continuous testing does not mean every exercise needs to become larger or more complex. It means organizations regularly validate the assumptions that matter most to business performance.
Cyber Resilience Is About Performance Under Pressure
Real incidents are unpredictable and complex. Organizations that manage disruption effectively have practiced navigating uncertainty before a crisis occurs.
For CISOs, CIOs, and enterprise technology leaders, one of the greatest risks is preparing for a predictable crisis that never arrives while ignoring the severe but plausible events that become more possible each day.
About the Author
Michael Campbell is the CEO of Fusion Risk Management. He brings more than 35 years of software development and technology experience. His exceptional executive management background includes multiple executive leadership roles and board membership positions, as he spent the beginning of his professional career co-founding and developing several successful start-ups. With a unique global perspective and strategic insights, Mike’s vision is to lead, grow, and scale the company.
Fusion Risk Management can be reached at www.fusionrm.com.
