Japan-based global investment bank
Preventing the Next Technology Disaster
How a Japan-based global investment bank moved from static recovery documentation to dependency-aware sequences.
Recovery Plans Were Tested by Real-World Events
In the second half of 2025, a global investment bank experienced several significant technology disruptions that required recovery teams to adapt in real time. These events followed the global CrowdStrike software update failure in July 2024 and culminated in a major technology incident in November 2025 that affected operations across multiple regions.
The firm recovered from each event, but post-incident reviews revealed a recurring challenge: recovery plans existed as static documentation, while recovery execution relied heavily on individual expertise, institutional knowledge, and manual decision-making. The organization could describe how recovery should occur, but it had limited ability to validate how recovery would play out during a real incident.
The post-event assessment was direct: disaster recovery and crisis management capabilities had not performed to the required standard. Recovery sequences had been documented and procedures maintained, but it remained unclear whether those sequences reflected current architecture, if critical dependencies were accurate, and if recovery activities could be executed in the required order under real-world operational constraints.
This conclusion triggered a broader effort to determine whether documented recovery plans accurately reflected the dependencies, resource constraints, and recovery sequences required during a real disruption. The organization turned to Fusion Recovery Optimization to evaluate whether recovery plans could be transformed from static documentation into computed, dependency-aware recovery sequences grounded in current architecture data.
About the Organization
This Japan-based global investment bank is one of the world’s largest investment banks, with approximately 26,000 employees across the Americas, EMEA, and Asia-Pacific. The firm provides fixed income, equities, investment banking, and wealth management services in some of the world’s most highly regulated financial markets.
Because the organization supports critical financial services across multiple regulatory jurisdictions, technology disruptions can have immediate operational, client, and regulatory consequences. Recovery planning is not simply a technology function. It is a core component of the firm’s operational resilience strategy.
The Challenge
When the organization engaged with Fusion in December 2025, recovery plans existed primarily in documents. While the firm was already using Fusion, the structured dependency data required to compute and validate recovery sequences had not yet been established. The engagement created an opportunity to test whether meaningful recovery insight could be generated before a fully mature dependency model was in place.
Like many financial institutions, they had recovery plans. The challenge was determining whether those plans reflected current architecture, whether the recovery sequences hold under the operational constraints that exist during an actual event, and whether the documentation captures the real dependency chains between systems, processes, teams, and third parties.
If we were being honest about our situation, we had documented what we believed recovery looked like. What we did not have was any way to validate whether that documentation matched how recovery would actually execute when it needed to.
Key Challenges:
Recovery Sequences Could Not Be Validated
- Recovery procedures existed as documented processes.
- The organization had no reliable way to determine whether those procedures reflected actual dependency relationships.
- There was no mechanism to validate whether documented recovery sequences would execute as intended.
Operational Constraints Were Invisible
- Static plans documented recovery activities but did not account for resource constraints, competing priorities, or capacity limitations that emerge during a disruption.
Recovery Capability Could Not Be Demonstrated
- Recovery plans provided guidance but did not prove that recovery objectives could be achieved under real-world conditions.
- Increasing regulatory expectations under DORA, PRA, and FSA require firms to demonstrate recovery capability, not simply document it.
What Fusion Recovery Optimization Revealed
Fusion Recovery Optimization traversed the organization’s dependency model and generated recovery sequences based on actual architecture data. For the first time, the team could visualize the relationships between systems, processes, and resources that determine whether recovery activities execute in the intended order under real-world conditions.
The analysis provided visibility that static recovery documentation could not. Rather than viewing recovery plans as isolated procedures, the team was able to evaluate recovery execution as an interconnected system with resource constraints, sequencing requirements, and relationships that spanned multiple teams and technologies.
The output was remarkable. We could see the dependency structure, the process flows, the resource constraints across the entire recovery sequence in a way our documentation had never made visible. That is a fundamentally different way of understanding your own recovery architecture.
The reaction reflected more than enthusiasm for a new technology. It reflected a shift in how the organization understood its recovery posture. For the first time, recovery plans could be evaluated against the architecture and operational realities they were intended to support.
From Documentation to Demonstrated Capability
The value of the engagement extended beyond the proof of concept itself. It demonstrated that organizations could begin evaluating recovery execution long before a fully mature dependency model exists and that the gap between a documented recovery plan and a computed recovery sequence can be measured long before production deployment.
For organizations operating under increasing pressure to demonstrate recovery capability rather than simply document recovery processes, that distinction matters. Recovery plans remain essential. The challenge is proving they will execute as intended under real-world conditions.
The organization began the engagement with recovery plans stored in static documents and no structured dependency model available for analysis. Within five months, the organization had established a foundation for evaluating recovery execution against actual architecture data, operational constraints, and recovery requirements.
Beyond greater visibility, the engagement gave the team a concrete understanding of how recovery would perform when it mattered most.
Key Takeaways
- Validated recovery execution
Fusion transformed static recovery plans into dependency-aware recovery sequences, allowing the team to validate whether recovery activities would execute in the correct order under real-world conditions.
- Visibility into hidden dependencies
By mapping relationships across applications, infrastructure, teams, and resources, the organization uncovered operational dependencies that traditional documentation couldn’t reveal.
- Greater confidence in resilience
With recovery sequences grounded in current architecture and operational constraints, the organization established a stronger foundation for demonstrating recovery capability to stakeholders and regulators.
