IT-Notfallplan fuer kleine Unternehmen in Berlin: Erstellen Sie ihn, bevor Sie ihn brauchen

Die meisten Berliner Kleinunternehmen haben keinen schriftlichen IT-Notfallplan. Diejenigen, die einen haben, besitzen meist ein Dokument, das einmal erstellt, irgendwo abgelegt und seitdem nicht getestet wurde. Keine dieser Situationen ist im Jahr 2025 akzeptabel, wenn die Kosten ungeplanter Ausfallzeiten fuer ein Unternehmen mit 10–50 Mitarbeitern typischerweise innerhalb von 48 Stunden das Jahres-IT-Budget uebersteigen und die durchschnittliche Ransomware-Wiederherstellungszeit fuer ungeschuetzte KMU 21 Tage betraegt.

Dieser Leitfaden bietet Ihnen ein praxistaugliches Disaster-Recovery-Framework — keine theoretische Vorlage, sondern einen operativ umsetzbaren Ansatz, der auf die Groesse und Microsoft-365-zentrierte Infrastruktur von Berliner KMU zugeschnitten ist.

Grundbegriffe: RTO, RPO und MTTR

RTO (Recovery Time Objective) — wie lange Ihr Unternehmen ohne ein bestimmtes System auskommen kann, bevor die finanziellen oder betrieblichen Auswirkungen unannehmbar werden. Fuer die meisten Berliner KMU sind das 4–8 Stunden fuer Kernsysteme (E-Mail, Dateien, Buchhaltung) und 24–72 Stunden fuer sekundaere Systeme.

RPO (Recovery Point Objective) — wie viel Datenverlust akzeptabel ist. Ein RPO von 24 Stunden bedeutet, dass Sie bereit sind, bis zu einen Tag Daten zu verlieren. Ein RPO von 1 Stunde erfordert mindestens stuendliche Backups. Dies bestimmt direkt Ihre Backup-Frequenz und Technologiewahl.

MTTR (Mean Time to Recovery) — wie lange die Wiederherstellung in der Praxis tatsaechlich dauert. Ihr RTO ist das Ziel; Ihr MTTR ist die Realitaet. Die Luecke zwischen beiden ist Ihr operatives Defizit. Den MTTR koennen Sie nur durch Tests ermitteln — nicht durch Annahmen.

System	Typischer KMU-RTO	Typischer KMU-RPO	Wiederherstellungsmechanismus
E-Mail (Microsoft 365)	1–2 Stunden	Nahezu null (Cloud)	M365 Geloeschte Elemente / Litigation Hold
Dateien (SharePoint/OneDrive)	1–4 Stunden	Nahezu null (Versionierung)	SharePoint-Versionsverlauf / Papierkorb
On-Premise-Dateiserver	4–24 Stunden	max. 4 Stunden	Azure Backup oder dediziertes BDR-Geraet
Einzelner Arbeitsplatz	2–8 Stunden	max. 24 Stunden	Intune Autopilot + OneDrive-Backup

Die vier Katastrophenszenarien, fuer die Berliner KMU planen muessen

Szenario 1: Ransomware-Verschluesselungsereignis. Ransomware verschluesselt Dateien auf gemappten Netzlaufwerken, SharePoint-Sync-Clients und manchmal Backups. Die Wiederherstellung erfordert: sofortige Isolierung betroffener Systeme (vor jeder anderen Massnahme vom Netzwerk trennen), Umfangsbestimmung der Verschluesselung, Wiederherstellung aus Offline- oder unveraenderlichen Backups und Neuaufbau ueber Autopilot bei kompromittierten Endpunkten. Zeitleiste: mindestens 24–72 Stunden fuer eine gut vorbereitete Umgebung. Ohne saubere Offline-Backups: Wochen bis Monate, oder Loesegeld zahlen.

Szenario 2: Einzelne Hardware-Fehlfunktion. Eine Festplatte eines Dateiservers faellt aus oder ein kritischer Arbeitsplatz stirbt. Die Wiederherstellung erfordert: Failover auf ein Ersatzgeraet oder eine Cloud-Ersatzloesung, Datenwiederherstellung aus dem Backup und Neueinrichtung der Benutzerumgebung. Fuer Microsoft-365-zentrierte Organisationen mit OneDrive-gesicherten Dokumenten und Intune-verwalteten Geraeten dauert ein Arbeitsplatz-Neuaufbau ueber Autopilot 2–4 Stunden. Ohne Autopilot: 4–8 Stunden pro Geraet.

Szenario 3: Versehentliche Loeschung oder Datenbeschraedigung. Ein Nutzer loescht einen kritischen SharePoint-Ordner oder ueberschreibt eine Schluesseldatei. Die Wiederherstellung erfordert: Zugriff auf den Versionsverlauf (SharePoint behaelt standardmaessig 500 Versionen) oder den Papierkorb (93 Tage Aufbewahrung). Fuer mandantenweite versehentliche Loeschungen nutzen Sie eDiscovery oder eine Drittanbieter-Backup-Loesung (Veeam, Acronis oder Backupify). Beachten Sie: Die native M365-Aufbewahrung ist kein Backup — sie schuetzt nicht vor administrativer Loeschung oder mandantenweiten Vorfaellen.

Szenario 4: Buero nicht zugaenglich. Das physische Buero wird unzugaenglich. Fuer M365-zentrierte Organisationen ist dies das am wenigsten beeintraechtigende Szenario — die Mitarbeiter arbeiten remote mit bestehenden Cloud-Tools. Die kritischen Abhaengigkeiten sind: Mitarbeiter haben funktionierende Geraete zu Hause, VoIP-Telefone leiten auf Mobilgeraete um, und kritische physische Dokumente haben digitale Entsprechungen.

Die fuenf Komponenten eines funktionierenden IT-Notfallplans

1. System- und Dateninventar. Sie koennen nicht schuetzen, was Sie nicht katalogisiert haben. Dokumentieren Sie jedes System, seine Funktion, wer davon abhaengt, wo seine Daten liegen und welche Geschaeftsauswirkungen sein Ausfall hat. Fuer die meisten Berliner KMU ist das eine Tabelle mit 10–30 Zeilen.

2. Backup-Architektur mit getesteter Wiederherstellung. Die drei Schluesselfragen: Sind Backups von der Produktion isoliert (damit Ransomware sie nicht verschluesseln kann)? Werden Backups durch tatsaechliche Dateiwiederherstellungen mindestens vierteljaeaerlich getestet? Decken Backups alle kritischen Daten einschliesslich M365-Inhalte (Exchange, SharePoint, Teams) ab? Ein Backup, das nie getestet wurde, ist kein Backup — es ist eine Haftung, die falsches Vertrauen erzeugt.

3. Schriftliche Wiederherstellungsverfahren. Schreiben Sie fuer jedes kritische System die genauen Schritte zur Wiederherstellung auf, einschliesslich Befehle, Konsolenpfade, benoetigte Anmeldedaten und erwartete Zeit. Diese Verfahren muessen fuer jemanden geschrieben sein, der das System nicht zuvor bedient hat — denn Ihre erfahrenste Person koennte diejenige sein, die waehrend des Vorfalls nicht verfuegbar ist.

4. Kommunikationsplan. Wer ruft wen an, wenn ein Vorfall beginnt? Wer kommuniziert mit Mitarbeitern, Kunden, Ihrem MSP? Wer hat die Befugnis, ein Loesegeld zu zahlen? Wer verhandelt mit der Cyberversicherung? Diese Entscheidungen sollten nicht zum ersten Mal unter Vorfallsdruck getroffen werden.

5. Jaehrliche Testübung. Ein DR-Plan, der nie getestet wird, ist keine DR-Plan — er ist eine Hypothese. Fuehren Sie mindestens einmal pro Jahr eine Tischübung durch, bei der Sie ein Szenario durchgehen und die Luecken identifizieren. Fuehren Sie idealerweise jaehrlich einen tatsaechlichen Wiederherstellungstest aus dem Backup fuer mindestens ein kritisches System durch.

Microsoft 365 Backup: Was Sie haben und was Sie brauchen

Ein haeufiges Missverstaendnis unter Berliner KMU: „Wir nutzen Microsoft 365, also sind unsere Daten gesichert.“ Das ist teilweise wahr und teilweise gefaehrlich.

Was Microsoft 365 nativ bietet: Wiederherstellung geloeschter Elemente fuer 30–93 Tage, SharePoint-Versionsverlauf (500 Versionen), Papierkorb-Aufbewahrung und grundlegendes eDiscovery. Was es nicht bietet: unabhaengige Point-in-Time-Wiederherstellung fuer mandantenweite Ereignisse, Schutz vor administrativer Loeschung und Langzeitarchivierung fuer compliance-relevante Dokumente (deutschen GoBD-Anforderungen: 10 Jahre).

Der empfohlene Ansatz: Aktivieren Sie Litigation Hold oder Aufbewahrungsrichtlinien in Microsoft Purview fuer compliance-relevante Dokumente, und setzen Sie eine Drittanbieter-M365-Backup-Loesung fuer unabhaengige Point-in-Time-Wiederherstellung ein.

Azure Backup fuer On-Premise-Workloads

Fuer Berliner KMU mit On-Premise-Servern bietet Azure Backup eine kostenguenstige und operativ einfache Offsite-Backup-Loesung, die direkt in Azure integriert ist. Wesentliche Vorteile: keine separate Backup-Infrastruktur, Aufbewahrung bis zu 99 Jahre, georedundanter Speicher standardmaessig in der EU und Integration mit Azure Recovery Services Vault fuer zentralisiertes Management.

NIS2 und Backup-Verpflichtungen fuer deutsche KMU

Gemaess NIS2 (in Deutschland umgesetzt durch das NIS2UmsuCG) muessen in den Anwendungsbereich fallende Organisationen angemessene technische Massnahmen zur Sicherstellung der Geschaeftskontinuitaet implementieren — ausdruecklich einschliesslich Backup- und Disaster-Recovery-Faehigkeiten. Wenn Ihr Unternehmen unter den NIS2-Anwendungsbereich faellt, ist das Fehlen eines getesteten DR-Plans eine Compliance-Luecke, nicht nur ein operatives Risiko.