Franco T.,
Too Long; Didn't Read
Most business continuity plans fail when it matters most: not because they are poorly written, but because they solve the wrong problem. Traditional DR plans focus on IT systems: backups, failover, RTO. But if your cloud provider goes down or ransomware brings your production to a standstill, a DR plan alone will not get your business back up and running. The solution? Resilience instead of recovery.
Nobody likes reading 80-page BC plans.
And that is exactly the problem.
Over the past few years, we have reviewed dozens of business continuity concepts at Swiss companies. The pattern is always the same: impressive documentation, detailed process diagrams, neatly numbered escalation chains.
And then the real situation hits.
Suddenly it turns out: the documented contact person left the company two years ago. The recovery steps refer to servers that have long since been migrated to the cloud. The escalation chain no longer matches the current org structure.
That is not an isolated case. That is the rule.
The fundamental problem: BC as a document rather than a capability
Here lies the thinking error: Most companies treat business continuity as a documentation project. Create it once, store it in SharePoint, done.
That feels good. You have “done” something. The auditor is satisfied. Management can check the box.
But operational resilience does not work that way. A plan that nobody knows and that has never been tested is not an asset. It is an illusion.
Why traditional DR plans fail
Problem 1: IT focus instead of business focus
Classic disaster recovery thinks in systems: “We have backups for server X, failover for database Y, RPO of 4 hours, RTO of 8 hours.”
That sounds technically solid.
But if your ERP system fails, your customers do not care about your RTO. They want to know: Can I place an order? When will my delivery arrive? Will I get support?
We experienced this at an industrial company. Perfect IT DR plan. But when their main supplier for a critical component was taken down by a cyberattack, production stopped. The DR plan did not help because the problem was not their own IT, but the lack of business process redundancy.
Problem 2: The multi-cloud illusion
“We run multi-cloud, so we are covered.”
We hear that often. The reality is more complicated.
If several major cloud providers have problems at the same time, your multi-cloud strategy does not help much. Especially if your application was not designed to be provider-agnostic. Most are not.
The major cloud providers together experience dozens of service outages per year. That is the new normal. The question is not “if,” but “when” the next one will happen.
Problem 3: Backups that do not work when it counts
“We have backups” is the most common answer when we ask about business continuity.
But here is the catch: Modern ransomware specifically targets backup repositories. Attackers know that backups are your last line of defense. If the backups are encrypted as well, recovery becomes difficult.
The more critical problem: Many companies run daily backups for years. But nobody ever tests a real recovery.
When the real situation comes, backups cannot be restored because of outdated encryption keys, changed infrastructures, or incompatible software versions. Recovery then takes weeks instead of hours.
Problem 4: Plans become outdated faster than you update them
A BC plan from three years ago is usually worthless today.
Your IT landscape changes constantly: new SaaS tools, cloud migrations, remote work infrastructure, new suppliers, organizational restructuring.
But your BC plan may be reviewed once a year. If at all. By the next audit, it is already obsolete.
In our experience, companies identify an average of eight to twelve critical deviations between the plan and operational reality during the first systematic review after two years. New key people are not captured. Critical third parties are missing. Recovery procedures describe systems that no longer exist.
The hidden costs nobody tracks
An outage of 48 hours feels like a manageable IT problem. The bill comes later.
When we speak with CFOs, most only calculate the direct IT outage costs. That massively underestimates the real damage.
What is often forgotten:
Opportunity costs: Which deals could you not close because your systems were down for 3 days? Which customers bought from the competition instead?
Reputational damage: How many customers permanently switch to competitors after you were unable to deliver for 2 weeks?
Regulatory consequences: In Switzerland, reporting obligations will be enforceable from October 2025. Failure to report can cost up to CHF 100,000 per day. Similar regulations are coming across the EU with NIS2.
Recovery resources: How many man-hours go into manual workarounds, crisis management, and restoration? What else could those resources have created?
For a typical Swiss SME with CHF 20-100 million in annual revenue: a major incident without preparation quickly costs CHF 200K-2M, directly and indirectly.
The paradigm shift: From recovery to resilience
The question has to be asked differently.
Instead of:
“How long does it take to restore our servers?”
“What is our recovery time objective?”
“Do we have enough backup capacity?”
Ask instead:
“Which business processes generate our revenue and must never fail?”
“Can we keep operating at 70% capacity while we solve problems?”
“Where are our real dependencies: suppliers, payment providers, critical employees?”
“Who makes decisions in a crisis, and is that person reachable?”
That is the difference between disaster recovery and resilience engineering. The first approach asks: “When will the systems be back?” The second asks: “How much damage will be done by then, and how do we minimize it?”
What you can do differently tomorrow
Here are four questions you should ask this week:
Which 3 business processes generate 80% of our revenue? Start there. Not with the IT infrastructure.
What happens if our most important cloud service goes down for 48 hours? Not theoretically. Specifically. Who does what? Can we continue manually?
Have we carried out a recovery test in the last 12 months? Not a backup test. A real business recovery test with everyone involved.
Who makes decisions in a crisis, and is that person reachable? Even on weekends? On vacation? At 3 a.m.?
The answers show you where you stand. If you hesitate on any of the questions, you have found your starting point.
In our experience, question 3 is the most critical. Companies that have not done a real recovery test in the last two years usually discover in a real incident that their backups are not as reliable as assumed. Or that responsibilities are unclear. Or both.
The 70% rule
Here is the most practical takeaway from this article:
Perfect redundancy is unaffordable. But 70% capacity within 30 minutes protects more revenue than 100% capacity after 48 hours.
We call that Minimum Viable Operations (MVO). For every critical business process, you define: What is the absolute minimum needed to keep operating?
A practical example: An e-commerce company with CHF 45 million in annual revenue, which equals CHF 180K in daily revenue. If the main shop on AWS goes down:
Option 1 (Activation: 30 min): Emergency landing page on Azure with “Order by phone now” and increased hotline capacity
Option 2 (Activation: 2 hrs): Basic shop on Azure with reduced features
Result: Instead of CHF 180K in daily losses, only CHF 15K during the switchover. 92% of revenue protected.
The investment in this fallback infrastructure paid for itself during the first major outage. That is not theory. That is a decision you can make today.
Conclusion
BC plans fail not because of missing documents, but because of the wrong focus
IT-focused DR solves the wrong problem; your customers want business continuity, not server recovery
The cost of being unprepared is higher than most CFOs calculate
The paradigm shift: From “How do we restore system X?” to “How do we keep business function Y running?”
The 70% rule: Fast degraded operations beat perfect late recovery
What next?
Start small. Take one critical business process this week and answer honestly:
What happens if technical support fails for 24 hours?
Do we have a plan B?
Who decides when we switch to plan B?
If you get stuck on these questions, you know where to start. And if you find that you need systematic support: that is what we are here for.
