Building resilient IT infrastructure for DACH companies

Resilience is a set of tested capabilities, not a platform: recovery objectives that come from the business, real disaster recovery, and compliance by design.

2 June 2025 7 min read Updated 28 September 2026

Building resilient IT infrastructure for DACH companies

Resilience is usually bought as a product and is actually a set of capabilities, each of which has to be tested to exist at all.

The distinction matters because almost every organisation believes it has a recovery capability, and a much smaller number has executed one. This is what the difference looks like in practice, and where DACH expectations raise the bar.

Why the bar is higher here

Two forces, and they are not the same force.

Customers. Swiss and German procurement applies the same availability and recovery expectations to a fifty-person supplier as to a five-hundred-person one, and asks during purchasing. A slow or vague answer costs time in an already long sales cycle.

Regulation. For finance-adjacent businesses, FINMA expects documented risk assessment, audit rights and a demonstrable exit for outsourced services. Under revDSG/nDSG and GDPR, availability and integrity of personal data are part of the obligation, not an operational nicety.

The practical consequence: resilience spend usually has to precede the revenue that justifies it. That is uncomfortable and it is the market you are in.

Recovery objectives come from the business, not from IT

The foundation of everything below is two numbers per application:

How much data can we afford to lose? (recovery point)
How long can it be unavailable? (recovery time)

These are business decisions. IT can tell you what each level costs; only the business can say what an hour of unavailability costs in orders, penalties or reputation.

The common failure is a single availability target applied to the whole estate. It over-spends on the systems nobody would notice and under-protects the two that carry the revenue. Differentiating by application is where the money is.

Disaster recovery that has been executed

A recovery plan that has never been run is a hypothesis. The first time you find out whether it works is the worst possible time to find out.

What a real capability includes:

Backups verified by restoring, not by checking a green tick in a console
A documented runbook someone other than its author can follow
A rehearsal on a schedule — at least annually, with the result written down
A tested failure of a whole availability zone, not just a single instance
A rollback that has been executed, ideally during a low-stakes migration wave

The rehearsal is the item that gets cut under time pressure and the only one that converts a plan into a capability.

Managed services: what to hand over and what to keep

Handing operations to a managed provider is reasonable and it does not transfer accountability. Under FINMA outsourcing expectations and under GDPR processor obligations, the responsibility remains yours.

What that means in the contract:

Named service levels with consequences, not aspirations
Audit rights you can actually exercise
Sub-processor disclosure — your provider has suppliers, and that chain is in your documentation
Access control, not just data location. Where data sits is the easy half; who can reach it, from which jurisdiction, is the half that gets audited
A documented exit — data export, credential handover, a notice period long enough to transition

Keep internally: knowing what your own recovery objectives are, and the ability to verify that the provider is meeting them. A capability you cannot verify is a claim.

Multi-cloud: justified by a requirement, not a preference

Multi-cloud is frequently proposed as resilience and is more often operational burden. Two platforms mean two sets of skills, two security models and two cost models, usually with half the depth in each.

Justified when: a regulator or a customer contract requires demonstrable independence from a single provider, or a specific workload genuinely runs better elsewhere.

Not justified by: a general preference for optionality. For most DACH mid-market companies, one platform with a documented exit path delivers more real resilience than two platforms operated thinly.

The honest middle ground for most estates is hybrid rather than multi-cloud — regulated data in Switzerland, variable load in the cloud, decided per workload rather than by philosophy. The reasoning is in why the DACH market prefers evolution over revolution.

Cost, without cutting the wrong things

Resilience and cost control are usually presented as opposed. Mostly they are not — the same discipline serves both:

Right-sizing removes spend without touching resilience
Scheduling non-production environments off likewise
Retiring unused systems improves both, since every system is also an attack surface and a recovery obligation

Two things not to cut, because they cost more than they save:

Logging and monitoring. It removes the evidence you need during an incident and, for regulated workloads, part of what you are obliged to retain.

The recovery rehearsal. Cutting it saves a day a year and converts your capability back into a hypothesis.

What “resilient” looks like on paper

Six things. If you have them, you can answer a procurement questionnaire in days rather than weeks:

Recovery point and time objectives per application class, agreed with the business
Backups verified by restore, on a schedule
A recovery runbook, rehearsed, with the last result recorded
Written answers on data residency, access, sub-processors and exit
Monitoring with defined alert thresholds and a named responder
A named owner for the platform, after any migration programme ends