Let me ask you a question.
Suppose you're the CEO of a Fortune 500 company. You've just spent $50 million building two geographically separated data centers. You've installed redundant power, redundant telecommunications carriers, redundant network equipment, and redundant everything else you could reasonably think of.
Your CIO tells you the infrastructure is resilient.
Congratulations.
Now let me ask you something else.
When was your last Business Impact Analysis?
If the answer is three years ago, my next question is whether your business has changed in those three years.
Have you acquired another company? Expanded into new markets? Introduced new applications? Changed how customers purchase your products? Outsourced critical business processes?
Because the infrastructure you built three years ago may still be perfectly functional.
The problem is that it may no longer support the business you operate today.
And that's where our conversation about resilience really begins.
You cannot audit your own assumptions
The first thing I'd recommend is an independent Business Impact Analysis, or BIA.
Not an internal review where everyone agrees that the existing priorities still make sense.
An independent assessment of what your business actually needs to survive.
Then I'd recommend a separate technical resilience assessment, preferably conducted by a different independent auditor.
Why two assessments?
Because they're answering two different questions.
The BIA establishes which business processes matter, what happens when they fail, and how long the organization can tolerate their disruption.
The technical assessment determines whether the infrastructure, dependencies, and recovery capabilities can actually support those requirements.
You need both.
And when the auditors disagree with your engineers, don't immediately assume either side is correct.
Get them in the same room.
Let everyone explain their position.
Then, wherever practical and safe, test the competing claims.
Engineers can be wrong. Auditors can be wrong. Executives can certainly be wrong.
The infrastructure doesn't particularly care whose business card has the most impressive title.
It either performs under the conditions being tested or it doesn't.
The disaster doesn't end when the fire goes out
In March 2021, a fire struck OVHcloud's Strasbourg data center campus in France.
One data center was destroyed, another was damaged, and the other two were physically intact. Nevertheless, the incident and associated power shutdown disrupted operations across the campus.
It's a powerful reminder that having multiple buildings doesn't necessarily mean having independent failure domains.
But the fire itself isn't the most important part of the lesson I want to teach.
It's what happens afterward.
Imagine I'm standing in front of a room full of executives.
I ask everyone to stand.
Then I describe the Strasbourg fire and tell them to imagine their businesses depend on the affected infrastructure.
I point to four people.
"You, you, you, and you. Sit down."
They represent businesses that couldn't survive the initial disruption.
Then I turn to the remaining executives.
"Congratulations. You survived the initial carnage."
Now let's fast-forward one year.
I point to another executive.
"Congratulations. You got back online. Unfortunately, rebuilding drained your cash reserves, and you can't make payroll next month."
Sit down.
I point to another.
"You rebuilt the servers, but the data and intellectual property your business depended on are gone. You can't fulfill your customer contracts."
Sit down.
Welcome to a place I like to call being sued for breach of contract.
Now let's fast-forward to the two-year mark.
"Congratulations. You're back to full capacity. Unfortunately, while you were recovering, your biggest customer signed a three-year contract with your competitor."
Sit down.
You became their backup plan.
"You managed to rebuild, but the employees who knew how to deliver your services left. Your largest remaining contract is approaching renewal, and you can't staff the work."
Sit down.
I hope the kids' college fund is up to date.
And finally:
"You borrowed enough to rebuild. Your lender gave you two years to restore revenue. That extension ends today, and you can't make the payment."
You, sit down.
Considering you put up your house as collateral, I hope you know a good divorce attorney.
Then I look at the people still standing.
"Congratulations. You'll probably live to see another day."
Any questions?
Now, to be clear, those business outcomes are hypothetical scenarios. I'm not claiming they happened to specific OVHcloud customers.
The Strasbourg fire is the real event. The exercise illustrates the possible consequences of a prolonged business disruption.
And that's the point.
A disaster can destroy a business long after its infrastructure has been rebuilt.
Three gates of recovery
I believe organizations should approach disaster recovery through three distinct gates.
And I don't believe a gate should be considered achieved until its results are sustainable and independently validated.
Gate 1: Infrastructure restoration
The necessary infrastructure has been restored, its critical dependencies are functioning, and the organization can demonstrate that the technical environment is stable.
Not merely powered on.
Not simply responding to a ping.
Operational, validated, and sustainable.
Gate 2: Customer service restoration
The organization can once again deliver the services its customers depend on.
Applications may be running, but can customers actually use them?
Can orders be processed? Can contractual obligations be fulfilled? Can essential business processes operate?
And can the organization sustain that delivery rather than relying on a temporary arrangement that's about to collapse?
Gate 3: Business stabilization
This is the gate I suspect many organizations don't spend nearly enough time considering.
Has the company regained sufficient financial, operational, and contractual stability to sustain itself?
Can it make payroll?
Can it service its debt?
Does it have the employees necessary to fulfill its obligations?
Has it retained enough customers and revenue to remain viable?
Because you can pass Gate 1 and still fail Gate 2.
You can pass Gate 2 and still fail Gate 3.
And if you haven't passed all three, I don't believe you should declare the business fully recovered.
Each gate should be validated by an independent outside auditor against established criteria. That process needs to be arranged in advance so independent validation doesn't become another obstacle during an emergency.
And once you've achieved all three gates, congratulations.
Now keep doing the work.
A successful recovery isn't a lifetime warranty.
Stop rehearsing the same comfortable disaster
Here's the exercise schedule I'd recommend.
Quarterly tabletop exercises.
Semiannual failover exercises.
One prolonged disaster exercise annually, lasting three to seven days.
And outside the continuity team and authorized exercise controllers, I wouldn't announce the timing or scenario.
Why?
Because real disasters don't send calendar invitations.
Your primary engineer might be on vacation. Your telecommunications provider might be unavailable. Your staff might be exhausted. Your suppliers might be dealing with the same disaster you are.
I want to know how the organization responds when things don't happen according to the script.
That doesn't mean recklessly endangering people or infrastructure.
A designated Safety Officer needs the authority to stop an exercise when serious physical safety or infrastructure risks arise. Exercises also need appropriate safeguards against unacceptable real-world consequences.
But I don't want controllers rescuing participants every time someone makes a bad decision.
Those mistakes are precisely what we're trying to discover.
And if an exercise exposes a significant failure, we should evaluate whether continuing will produce useful information.
Sometimes it will.
Sometimes the responsible decision is to document the failure, investigate its cause, correct it, and test again.
Otherwise, we risk confusing a series of cascading consequences with several unrelated problems.
The objective isn't to make the exercise look successful.
The objective is to discover weaknesses before a real disaster finds them for us.
A repair isn't proof of recovery
Suppose an exercise identifies a serious authentication dependency.
Your engineering team corrects the configuration and demonstrates that authentication works again.
Wonderful.
But has the affected business process been tested under the conditions that exposed the problem?
If not, the finding remains open.
Technical remediation and restored business resilience are not necessarily the same thing.
Depending on the severity, we might use the next semiannual exercise to validate the corrective action. Or we might decide that another full-scale exercise is warranted.
That's a judgment call.
What isn't negotiable is the requirement to demonstrate that the correction actually works.
Resilience requires ownership
Ideally, a sufficiently large organization should have a Chief Continuity and Resilience Officer, or CCRO.
If the organization isn't large enough to justify that position, responsibility may sit with the CEO or CIO.
But someone needs clear executive accountability.
And that person needs meaningful authority.
I favor allowing the CCRO to initiate a temporary operational suspension when a serious resilience risk warrants it, followed immediately by review from the appropriate C-suite officers.
Ultimately, the CEO makes the business decision, subject to applicable legal and safety obligations.
Because the buck stops there.
Sometimes that means choosing between two potentially catastrophic outcomes.
Remaining offline might destroy the company's finances.
Restoring operations prematurely might expose the organization to an even greater disaster.
There may not be a perfect answer.
But the decision should be informed, documented, and made by someone accountable for its consequences.
Which brings me to something I believe every executive needs to understand.
Just because you abdicate control doesn't mean you abdicate responsibility.
Outsource your infrastructure.
Hire a managed service provider.
Engage consultants.
Use independent auditors.
That's fine.
But when your business fails to fulfill its obligations, you cannot simply point at the vendor and declare that it wasn't your problem.
You may have delegated the work.
You haven't delegated away your responsibility.
Don't mistake good fortune for resilience
There's an unwritten warning among continuity professionals that I've always found worth remembering.
The more facilities you operate, and the longer you go without experiencing a disaster, the more concerned you should become about the possibility of a major one.
That's not a statistical law.
Disasters don't accumulate somewhere waiting for their turn.
But as organizations expand, their dependencies and operational complexity can increase. And as the years pass without a serious incident, people can begin mistaking good fortune for proof of preparedness.
That's dangerous.
If your business hasn't materially changed, I favor a fresh independent BIA at least every three years.
If significant changes occur, don't wait for the calendar.
And keep performing the quarterly, semiannual, and annual exercises.
If your auditors have spent years examining the same organization and everyone has become comfortable with consistently clean results, consider bringing in a new auditor.
A fresh set of eyes can discover assumptions that everyone else has stopped questioning.
Resilience isn't a sales slogan
I don't believe organizations should turn resilience into a marketing competition.
For one thing, claiming to be more resilient than your competitors can be difficult to substantiate.
For another, advertising your defenses can attract attention you don't particularly want.
And ultimately, building resilience should be about meeting your obligations, not winning a marketing contest.
That doesn't mean customers shouldn't receive legitimate evidence of your continuity capabilities.
If a hospital, government agency, or major enterprise needs independently verified assurance, provide appropriate documentation under suitable confidentiality protections.
But sanitize it.
Protect sensitive business operations, infrastructure dependencies, security information, and anything else that could compromise the organization.
Demonstrate what was actually tested and validated.
Don't pretend you've proven what you haven't.
Ego and complacency will get you dead. Period.
I can build redundant networks.
I can design geographically distributed infrastructure.
I can establish independent control planes, alternate operating environments, and multiple recovery paths.
But none of those things will save an organization whose leadership refuses to acknowledge its own weaknesses.
An engineer who cannot accept being wrong.
An executive who refuses to listen to an auditor.
A board that believes a $50 million investment guarantees survival.
A continuity team that keeps repeating the same comfortable exercise because everyone likes the results.
Those are vulnerabilities too.
And unlike a failed switch, you can't always replace them with a spare part.
At Atlas Global Technologies, we're designing our proposed infrastructure and continuity systems around the principle that resilience must be tested, challenged, and demonstrated. Those are design objectives, not claims that our planned global infrastructure has already proved itself under live disaster conditions.
Because I don't believe anyone can guarantee that a business will survive every disaster.
And if someone offers you that guarantee, come see me.
I have a bridge in Brooklyn I'd like to show you.
Redundancy is what you build. Resilience is what you prove. Responsibility is what you never get to walk away from.
And if you remember nothing else from this article, remember this:
Ego and complacency will get you dead. Period.
Sources and further reading
- OVHcloud, information about the Strasbourg data center fire
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
- ISO 22301, Business Continuity Management Systems
The boardroom discussion, financial scenarios, and three-gate recovery framework reflect the author's perspective and illustrative examples. They are not claims about specific businesses affected by the Strasbourg fire.