Let's be honest... nobody likes to read 80-page BC plans.

And that's exactly the problem.

In recent 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 comes the emergency.

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 fits the current organizational structure.

(This is not an isolated case. This is the rule.)

The fundamental problem: BC as a document instead of a capability

Here's the misconception: Most companies treat Business Continuity as a documentation project. Create once, store in SharePoint, done.

It feels good. You've "done" something. The auditor is satisfied. Management can check it off.

But operational resilience doesn't work that way.

Why traditional DR plans fail

Problem 1: IT focus instead of business focus

Classic disaster recovery thinks in terms of systems: "We have backups for server X, failover for database Y, RPO of 4 hours, RTO of 8 hours."

That sounds technically solid.

But when your ERP system fails, your customers aren't interested in your RTO. They want to know: Can I order? When will my delivery arrive? Will I get support?

We experienced this with an industrial company. Perfect IT-DR plan. But when their main supplier for a critical component was hit by a cyberattack, production stopped. The DR plan was of no help – because the problem wasn't their own IT but the lack of business process redundancy.

Problem 2: The Multi-Cloud illusion

"We're using Multi-Cloud, so we're secure."

We hear this often. The reality is more complicated.

If multiple major cloud providers have problems at the same time – and this has happened multiple times – your multi-cloud strategy is of little use. Especially if your application isn't truly provider-agnostic.

(Spoiler: Most aren't.)

The major cloud providers experience dozens of service outages per year together. This is the new normal. The question is not "if" but "when" the next one will come.

Problem 3: Backups that don't work when it counts

"We have backups" is the most common response when we ask about business continuity.

But here's the catch: Modern ransomware specifically targets backup repositories. Attackers know that backups are your last line of defense. If the backups are encrypted too, recovery becomes... challenging.

The more critical problem: Many companies have been making daily backups for years. But no one ever tests a real recovery.

When the emergency actually happens? Backups are not restorable due to outdated encryption keys. Or changed infrastructures. Or incompatible software versions.

Recovery then takes weeks instead of hours.

Problem 4: Plans age faster than you update them

A BC plan from three years ago is mostly old paper today.

Your IT landscape is constantly changing: New SaaS tools, cloud migrations, remote work infrastructure, new suppliers, organizational restructurings.

But your BC plan might get brushed over once a year. If at all.

The hidden costs nobody tracks

When we talk to CFOs, most only calculate the direct IT outage costs. This massively underestimates the real damage.

What's often forgotten:

• Opportunity Costs: What deals couldn't you close because your systems were down for 3 days? Which customers bought from the competition?

• Reputational damage: How many customers permanently switch to the competition after you're unable to deliver for 2 weeks? Which deals fell through?

• Regulatory consequences: In Switzerland, mandatory reporting will be enforceable from October 2025 – not reporting can cost you up to CHF 100,000 per day. Similar regulations are coming EU-wide with NIS2.

• Recovery resources: How many man-hours flow into manual workarounds, crisis management, and recovery? What could these resources have created instead?

For a typical Swiss SME with CHF 20-100M annual turnover: A major incident without preparation quickly costs CHF 200K-2M. Directly and indirectly.

The paradigm shift: From recovery to resilience

The question must be asked differently.

Instead:

• "How long will it take to restore our servers?"

• "What is our Recovery Time Objective?"

• "Do we have enough backup capacity?"

Ask:

• "Which business processes generate our revenue and can never fail?"

• "Can we continue to operate at 70% capacity while solving issues?"

• "Where are our real dependencies – suppliers, payment service providers, critical employees?"

• "Who decides in a crisis – and is this person reachable?"

This is the difference between disaster recovery and resilience engineering.

What you can do differently tomorrow

Here are four questions you should ask this week:

1. Which 3 business processes generate 80% of our revenue? Start there. Not with IT infrastructure.

2. What happens if our most important cloud service fails for 48 hours? Not theoretically. Specifically. Who does what? Can we continue manually?

3. Have we conducted a recovery test in the last 12 months? Not a backup test. A real business recovery test with all involved.

4. Who decides in a crisis – and is this person reachable? Even on weekends? On vacation? At 3 a.m.?

The answers show you where you stand.

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 this Minimum Viable Operations (MVO). For every critical business process, you define: What is the absolute minimum to keep operating?

Here’s a real-world example:

An e-commerce company with CHF 45M annual sales (~CHF 180K daily sales). If the main shop fails on AWS:

• Option 1 (Activation: 30 Min): Emergency landing page on Azure with "Order by phone now" + hotline upscaling

• Option 2 (Activation: 2 Hr): Basic shop on Azure with reduced features

Result: Instead of CHF 180K daily loss, only CHF 15K during the switch. 92% of revenue protected.

The investment in this fallback infrastructure paid off during the first major failure.

Conclusion

• BC plans fail not because of lacking 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 "Good Enough" 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's next?

Start small. This week, take a critical business process and answer honestly:

• What happens if technical support fails for 24 hours?

• Do we have a Plan B?

• Who decides when to switch to Plan B?

If you stumble on these questions, you're not alone. But now you know where you need to start.

(And if you find that you need support to systematically tackle this – that's what we're here for.)

Further reading

• Why most risk analyses fail – A pragmatic approach

• NIS2 guidelines for Swiss companies – The ultimate implementation guide

• Is it cheaper to recover after a ransomware attack? – The real costs of unpreparedness