IT Disaster Recovery Plan for Small Businesses in Berlin: Build One Before You Need It

Most Berlin small businesses do not have a written IT disaster recovery plan. The ones that do largely have a document that was written once, filed somewhere, and has not been tested since. Neither situation is acceptable in 2025, when the cost of unplanned downtime for a 10–50 person business typically exceeds the annual IT budget within 48 hours, and ransomware recovery timelines for unprotected SMBs average 21 days.

This guide gives you a working disaster recovery framework — not a theoretical template, but an operationally implementable approach calibrated to Berlin SMB scale and Microsoft 365-centric infrastructure.

Terminology That Matters: RTO, RPO, and MTTR

Before building a recovery plan, define your targets. Three metrics determine what you are actually recovering to:

RTO (Recovery Time Objective) — how long your business can tolerate being without a specific system before the financial or operational impact becomes unacceptable. For most Berlin SMBs, this is 4–8 hours for core systems (email, files, accounting) and 24–72 hours for secondary systems.

RPO (Recovery Point Objective) — how much data loss is acceptable if a system fails. An RPO of 24 hours means you are willing to lose up to one day of data. An RPO of 1 hour means you need backup or replication running at least hourly. This directly dictates your backup frequency and technology choices.

MTTR (Mean Time to Recovery) — how long recovery actually takes in practice. Your RTO is the target; your MTTR is the reality. The gap between them is your operational deficit. The only way to know your MTTR is to test recovery — not assume it.

System	Typical SMB RTO	Typical SMB RPO	Recovery mechanism
Email (Microsoft 365)	1–2 hours	Near-zero (cloud)	M365 Deleted Items / Litigation Hold
Files (SharePoint/OneDrive)	1–4 hours	Near-zero (versioning)	SharePoint Version History / Recycle Bin
On-premise file server	4–24 hours	≤4 hours	Azure Backup or dedicated BDR appliance
Line-of-business server (ERP/CRM)	4–48 hours	≤24 hours	VM snapshot + offsite backup
Individual workstation	2–8 hours	≤24 hours	Intune Autopilot + OneDrive backup

The Four Disaster Scenarios Berlin SMBs Must Plan For

Not all disasters are equal. A practical DR plan addresses four distinct scenarios with different response playbooks:

Scenario 1: Ransomware encryption event. Ransomware encrypts files across mapped network drives, SharePoint sync clients, and sometimes backups. Recovery requires: isolating affected systems immediately (disconnect from network before any other action), identifying the encryption scope, restoring from offline or immutable backups, and rebuilding from Autopilot if endpoints are compromised. Timeline: 24–72 hours minimum for a competently prepared environment. Without clean offline backups: weeks to months, or pay the ransom.

Scenario 2: Single hardware failure (server or workstation). A file server disk fails or a critical workstation dies. Recovery requires: failing over to a spare or cloud replacement, restoring data from backup, and reinstating the user’s environment. For Microsoft 365-centric organisations with OneDrive-backed documents and Intune-managed devices, a workstation rebuild via Autopilot takes 2–4 hours. Without Autopilot, expect 4–8 hours per machine.

Scenario 3: Accidental deletion or data corruption. A user deletes a critical SharePoint folder or overwrites a key file. Recovery requires: accessing version history (SharePoint retains 500 versions by default) or the Recycle Bin (93-day retention). For M365 tenant-wide accidental deletion, use eDiscovery or a third-party backup solution (Veeam, Acronis, or Backupify) with independent retention. Note: Microsoft 365’s native retention is not a backup — it does not protect against administrative deletion or tenant-level incidents.

Scenario 4: Office inaccessibility (fire, flood, forced evacuation). The physical office becomes inaccessible. For M365-centric organisations, this is the least disruptive scenario — staff work remotely using existing cloud tools. The critical dependencies are: staff have working devices at home or can access corporate resources from personal devices via compliant Conditional Access, VoIP phones redirect to mobile, and critical physical documents (contracts, signatures) have digital equivalents.

The Five Components of a Working DR Plan

1. System and data inventory. You cannot protect what you have not catalogued. Document every system, what it does, who depends on it, where its data lives, and what the business impact of its loss is. For most Berlin SMBs this is a spreadsheet with 10–30 rows. Update it whenever infrastructure changes.

2. Backup architecture with tested restore. The three key questions for your backup strategy: Are backups isolated from production (so ransomware cannot encrypt them)? Are backups tested by actually restoring files at least quarterly? Do backups cover all critical data including M365 content (Exchange, SharePoint, Teams), not just on-premise servers? A backup that has never been tested is not a backup — it is a liability that creates false confidence.

3. Written recovery procedures. For each critical system, write the exact steps required to restore it, including commands, console locations, credentials needed, and expected time. These procedures must be written for someone who has not previously worked with the system — because your most experienced person may be the one who is unavailable during the incident.

4. Communication plan. Who calls whom when an incident starts? Who communicates to staff, to clients, to your MSP? Who has authority to decide to pay a ransom? Who handles communication with your cyber insurer? These decisions should not be made for the first time under incident pressure.

5. Annual test exercise. A DR plan that is never tested is not a DR plan — it is a hypothesis. Run at least one tabletop exercise per year where you walk through a scenario (ransomware, hardware failure, office inaccessibility) and identify the gaps. Ideally, run an actual restore test from backup for at least one critical system annually.

Microsoft 365 Backup: What You Have vs. What You Need

A common misconception among Berlin SMBs: “We use Microsoft 365, so our data is backed up.” This is partially true and partially dangerous.

What Microsoft 365 provides natively: deleted item recovery for 30–93 days, SharePoint version history (500 versions), Recycle Bin retention, and basic eDiscovery. What it does not provide: independent point-in-time restore for tenant-level events, protection against administrative deletion, long-term archiving beyond the retention policy period, or granular mailbox restore to a specific date and time.

For organisations with any regulatory retention requirement (German GoBD requires 10-year retention for accounting-relevant documents), M365 native tools are insufficient without additional configuration or third-party backup. The recommended approach: enable Litigation Hold or Retention Policies in Microsoft Purview for compliance documents, and deploy a third-party M365 backup solution for independent point-in-time restore capability.

Azure Backup for On-Premise Workloads

For Berlin SMBs with on-premise servers, Azure Backup provides a cost-effective and operationally simple offsite backup solution directly integrated with Azure. Key advantages: no separate backup infrastructure to manage, retention up to 99 years, geo-redundant storage by default in the EU, and integration with Azure Recovery Services Vault for centralised management.

Azure Backup Pricing example (West Europe region): 100 GB backup storage at ~€2.40/month. The operational cost to your MSP for monitoring and restore testing is the larger variable.

NIS2 and Backup Obligations for German SMBs

Under NIS2 (implemented in Germany via the NIS2UmsuCG), organisations in scope must implement appropriate technical measures to ensure business continuity — explicitly including backup and disaster recovery capabilities. If your business falls under NIS2 scope (most IT service providers, digital service providers, and medium-sized businesses in critical sectors do), the absence of a tested DR plan is a compliance gap, not just an operational risk.