From Manual Sequences to Computed Recovery
How Experian 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 Experian, a 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.
Using Recovery Optimization allowed us to very quickly identify manual errors and sequencing conflicts by showing a visual recovery guide which is invaluable. In addition, the visual dynamic view ofrecovery is a perfect companion for Crisis events needing clear command and control data.
About the Organization
Experian 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 multiple 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. Experian 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 things we would be most interested in are certainly zero to four hours, and then four to twenty-four hours recovery zones, because those are the ones that have the most impact to our clients and regulatory commitments.
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 when it became visible through Recovery Optimization 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 confident with our data prior to running Recover Optimization and was genuinely shocked when we started going through the output. I don’t think you can underestimate that. It’s not a use case for Recovery Optimization we even considered, but it’s definitely been a big win.
Results
The engagement ran from February to May 2026. Throughout the process, the Experian 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.
I want a view of this for everyone (Crisis Management, Major Incident, Resiliency, CTOs). Because it gives the latest recovery position, regardless of whatever happened yesterday. I’ve got it in my inbox, and I know exactly what the recovery looks like for ‘today’. That’s really powerful because on a global level this data is dynamic and goes out of date really, really quickly.
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.
When I saw what Recovery Optimization produced from our data, my immediate reaction was that our regional recovery teams need to see this. It changes how you think about whether your recovery approach is actually optimized for the events you are planning for.
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.
