Global Credit Data and Analytics Company
From Manual Sequences to Computed Recovery
How a global credit data and analytics company used Recovery Optimization to surface what years of plan maintenance could not
The Disruption No One Plans For
In July 2024, a faulty software update crashed 8.5 million Windows systems worldwide. Fifteen months later, an AWS outage again demonstrated how quickly dependency failures can cascade across modern technology environments.
For resilience leaders, the takeaway wasn’t that disruption is inevitable. It was that successful recovery depends on understanding how thousands of interconnected systems behave under pressure.
For one global credit data and analytics company operating across 32 countries, that raised a difficult question: how much confidence could they place in recovery sequences built over years of manual planning?
Their recovery plans were maintained rigorously. Their recovery teams were highly experienced. But when they ran their primary data center recovery sequence through Recovery Optimization, the results surfaced assumptions that traditional planning and testing methods had not exposed.
About the Organization
The organization is a global provider of data intelligence, fraud prevention, and identity management services. Its UK operations support critical financial services infrastructure and are subject to stringent operational resilience requirements.
The UK IT disaster recovery program covers hundreds of applications across primary and secondary data centers. Recovery activities are governed by defined recovery time objectives, regulatory expectations, and contractual commitments. The most critical services must be restored within defined recovery time windows.
The program had a dedicated plan owner, deep architectural knowledge, mature governance, and well-maintained recovery documentation. The challenge was understanding whether hundreds of documented dependencies would behave as expected when recovery execution moved from planning to reality.
The Challenge: A Well-Maintained Plan That Could Not See Itself
The ITDR program had done what mature programs are designed to do. Recovery plans were documented, dependencies were mapped, and recovery sequences were reviewed and updated monthly in Microsoft Project.
What the program could not do was validate those relationships at scale. Static planning tools can document dependencies, but they cannot follow each dependency across the full plan to identify hidden conflicts, sequencing issues, or assumptions embedded within the recovery plan itself.
The manual process was disciplined, but inherently limited:
- Infrastructure changes required manual plan updates
- New applications required new dependency relationships
- Recovery timelines were based on periodically updated estimates
- Recovery sequencing could not be continuously validated as dependencies changed
At the same time, FCA and PRA operational resilience requirements increased the need to demonstrate that critical services could be recovered within defined recovery objectives. The organization needed more than a well-maintained plan. It needed confidence that the documented recovery sequence would produce the intended recovery outcome under real-world conditions.
The Discovery: What Traditional Plan Review Cannot Surface
The first Recovery Optimization engagement began in February 2026. The team loaded in their ITDR data and analyzed a primary UK data center recovery scenario.
What emerged was not a poorly maintained program. The findings reflected something more fundamental: the reality of managing hundreds of applications, thousands of dependencies, and years of incremental change across a complex technology environment.
The analysis surfaced issues that traditional plan maintenance processes were not designed to detect, including:
- Recovery sequencing conflicts that only became visible when dependencies were analyzed as a complete system
- Data quality issues that materially impacted projected recovery timelines
- Legacy or unnecessary relationships included in site-specific recovery scenarios
- Opportunities to improve recovery scope and recovery planning assumptions
One finding stood out. A critical application had a recovery duration entered as 523 hours rather than its actual recovery time of approximately 2.3 hours. A simple data-entry error, but one that significantly distorted the projected recovery timeline for everything downstream. It was a clear illustration of why recovery-time visibility cannot depend solely on manually maintained plan data.
Treating the recovery plan as a complete system, rather than a collection of individual records, gave the organization greater visibility into both its recovery sequence and the timelines used to support planning, testing, and operational resilience objectives.
I was genuinely shocked how much stuff came out of the woodwork when we started going through this. I don’t think you can underestimate that. It’s not a use case I even considered, but it’s definitely been a big win.
Results
The engagement ran from February to May 2026. Throughout the process, the team investigated anomalies, resolved issues in the source data, and continuously validated Recovery Optimization outputs against its existing Microsoft Project recovery sequence.
By the end of the engagement, the conversation had shifted from diagnosis to deployment. The team’s assessment was that Recovery Optimization was producing credible outputs, and the remaining work centered on data refinement rather than system logic validation.
Key Outcomes
- Validated recovery sequencing against current dependency data
- Identified and resolved data anomalies affecting recovery planning
- Confirmed recovery outputs aligned with real-world dependencies
- Surfaced opportunities to strengthen recovery assumptions
- Established a continuously updated view of recovery timelines
That last point mattered most to the team. For the first time, they had a live view of recovery timelines based on current dependency data rather than a monthly manually maintained estimate.
As the Global Head of Resilience explained:
Looking Ahead: A Stronger Foundation for Recovery Planning
Following the analysis, the organization began moving Recovery Optimization toward production deployment, starting with the recovery sequence analyzed during the engagement. With the dependency model validated and key issues addressed, the focus shifted from discovery to operationalization.
The team plans to expand Recovery Optimization across additional recovery environments and integrate optimized recovery sequences into its broader disaster recovery processes.
One reality became clear: maintaining a recovery plan and validating a recovery plan are different activities. By analyzing recovery execution as a complete system, the organization gained greater confidence in its recovery sequence, its recovery timelines, and its ability to meet critical resilience objectives during a real disruption.
Key Takeaways
- Continuous recovery visibility
With recovery timelines generated from current dependency data, the team gained an always-current view of recovery readiness instead of relying on monthly estimates.
- Improved recovery data quality
System-wide analysis uncovered inaccurate recovery times, outdated dependencies, and other hidden data issues that could have affected recovery execution.
- Stronger recovery readiness
By validating recovery logic against real dependency relationships, the organization established greater confidence that its recovery plans would perform as expected.
