Krisensicher dank Strategie: Ihre Roadmap für ein robustes Desaster-Recovery-Konzept
Denn die zentrale Frage ist nicht ob etwas passiert, sondern wann – und wie gut Sie dann vorbereitet sind.
Teil 1 - Was zählt, wenn es ernst wird
Warum jetzt handeln?
Bestandsaufnahme: Was brauche ich wirklich?
Nicht jedes System ist im Notfall gleich wichtig. Die erste Frage muss daher lauten: Welche Prozesse sind geschäftskritisch – und welche Systeme stehen dahinter?
Eine strukturierte Business Impact Analyse (BIA) liefert hier Antworten. Sie zeigt, welche Systeme sehr schnell verfügbar sein müssen (z. B. Warenwirtschaft, Produktionssteuerung, Kommunikation) – und welche und welche Systeme nachgelagert reaktiviert werden können.
Wichtige Fragen dabei:
- Welche Daten und Prozesse sind für den Fortbestand des Unternehmens unverzichtbar?
- Wie lange kann der Betrieb ohne bestimmte Systeme aufrechterhalten werden?
- Was kostet eine Stunde Stillstand – konkret?
Vertrauensgrenzen: Was ist noch sicher – was nicht mehr?
Viele Unternehmen vertrauen blind auf Systeme, die im Notfall selbst zum Problem werden können. Beispiel: Microsoft 365. Was auf den ersten Blick redundant erscheint, ist oft ein Single Point of Failure – denn auch Cloud-Dienste können ausfallen oder Ziel von Angriffen sein.
Ein eigener Exchange-Server im RZ mag altmodisch wirken – bietet aber unter Umständen mehr Kontrolle im Notfall. Entscheidend ist: Wo ziehe ich die Grenze des Vertrauens? Und welche Abhängigkeiten bin ich bereit einzugehen?
Auch hier gilt: Systeme, auf die Sie sich im Notfall verlassen wollen, müssen im Unternehmen durchdacht, getestet und notfalls isoliert lauffähig sein – sei es über eine Private Cloud, Terminalserver oder dedizierte Notfallumgebung.
Zielgrößen: RTO & RPO
Die zwei wichtigsten Kennzahlen im Desaster Recovery:
- RTO (Recovery Time Objective): Wie schnell muss ein System wieder verfügbar sein?
- RPO (Recovery Point Objective): Wie alt dürfen die Daten im Worst Case maximal sein?
Ein Beispiel: Wenn Sie Ihre Daten nur einmal täglich sichern, verlieren Sie im Ernstfall bis zu 24 Stunden an Informationen – das ist Ihr RPO. Wenn ein System erst nach 48 Stunden wieder hochgefahren werden kann, ist das Ihr RTO.
Viele Unternehmen definieren diese Werte zu optimistisch – oder gar nicht. Ein realistischer Abgleich zwischen Business-Anforderungen und technischer Machbarkeit ist daher essenziell.
Teil 2 – Kommunikation im Ernstfall: Klarheit statt Chaos
Wer kommuniziert – und wann?
In der Krise zählt jede Minute. Unklare Zuständigkeiten oder widersprüchliche Aussagen verzögern nicht nur den Wiederanlauf, sondern sorgen für Vertrauensverlust – bei Kunden, Mitarbeitenden und Partnern.
Ein guter DR-Plan definiert deshalb:
- Verantwortliche Personen für Kommunikation (z. B. Geschäftsführung, IT-Leitung, Pressesprecher)
- Klare Meldeketten intern – wer informiert wen in welcher Reihenfolge?
- Vorbereitete Textbausteine für gängige Szenarien (Cyberangriff, Systemausfall, Datenverlust)
- Kanalstrategie: Wann ist E-Mail sinnvoll, wann besser ein direkter Anruf?
Besonderheit: Kommunikation mit Externen
Spätestens wenn Kunden oder Aufsichtsbehörden betroffen sind, muss das Unternehmen reagieren – und zwar kontrolliert. Eine unüberlegte Aussage wie „Unsere IT wurde gehackt“ kann größere Schäden verursachen als der Vorfall selbst.
Typische externe Kommunikationspartner:
- Kunden & Lieferanten
- Presse & Öffentlichkeit
- Behörden (z. B. Datenschutz, Finanzaufsicht)
- Versicherungen
Je nach Branche können Meldepflichten bestehen – z. B. bei Datenschutzverletzungen (DSGVO). Auch dafür sollte ein DR-Plan vorbereitet sein.
Sonderfall: Cloud-Ausfälle und SaaS-Dienste
Ein beliebter Irrtum: „Wenn Microsoft 365 ausfällt, ist das nicht unser Problem.“ Doch genau das sehen Kunden und Mitarbeiter oft anders. Wer moderne SaaS-Plattformen nutzt, trägt auch Verantwortung für die Kommunikation im Störfall – selbst wenn die technische Ursache extern liegt.
Daher gilt:
- Auch Cloud-basierte Dienste brauchen Notfallkommunikationsszenarien
- Die Verantwortung für Kommunikation bleibt immer beim Unternehmen
- Externe SLA-Verweise reichen im Ernstfall nicht aus
Praxis-Tipp: Kommunikations-plan als Teil des DR-Konzepts
Ein praxistauglicher Kommunikationsplan besteht idealerweise aus:
- Kontaktdaten aller relevanten Personen (auch privat / mobil)
- Kurzanleitungen für häufige Krisenszenarien
- Templates für Pressemitteilungen und interne Mitteilungen
- Liste mit Kommunikationsverboten (z. B. keine technischen Details ohne Freigabe)
Ziel: Jeder weiß sofort, was zu tun ist – und niemand muss „im Moment der Krise“ improvisieren.
„Living off the Land“: Die unsichtbare Gefahr aus dem eigenen System
Angriffe, die aussehen wie normale Systemaktivitäten…
Cyberangriffe haben sich verändert. Heute arbeiten viele Angreifer subtiler – sie greifen nicht von außen mit neuen Programmen an, sondern nutzen das, was bereits im Unternehmen vorhanden ist. Dieses Prinzip wird als „Living off the Land“ (LOTL) bezeichnet. Es beschreibt eine Methode, bei der sich Angreifer gezielt jener Tools bedienen, die in jeder Windows-Umgebung zum Alltag gehören: PowerShell, Windows-Dienste, Remote Desktop oder interne Skripte.
Das Heimtückische daran: Diese Werkzeuge sind fester Bestandteil des Betriebssystems und werden regelmäßig von Administratoren oder Wartungsdiensten genutzt. Sie sehen nicht verdächtig aus. Deshalb bleiben sie in vielen Fällen völlig unbemerkt – selbst von erfahrenen IT-Teams oder modernen Sicherheitslösungen.
Wenn der Angreifer kein Fremder mehr ist
Ein LOTL-Angriff beginnt meist mit einem kleinen Türöffner: ein kompromittiertes Benutzerkonto, eine Phishing-Mail, ein ungesicherter Fernzugriff. Von dort aus bewegen sich die Angreifer systematisch weiter – von System zu System, von Dienst zu Dienst. Sie erstellen eigene Skripte, überwachen die Umgebung, sammeln Informationen. Immer mit denselben Bordmitteln, die auch Ihr IT-Team nutzt.
Besonders gefährlich wird es, wenn administrative Rechte ins Spiel kommen. Denn mit diesen Rechten können nicht nur produktive Systeme manipuliert, sondern auch Sicherungssysteme gezielt außer Kraft gesetzt werden. Backups werden gelöscht oder verschlüsselt, Protokolle bereinigt, Alarmierungen deaktiviert. Wenn das Unternehmen den Angriff schließlich entdeckt, ist der eigentliche Schaden oft längst geschehen – und die Wiederherstellung wird zum Wettlauf gegen die Zeit.
Warum klassische Sicherheit hier nicht ausreicht
Die meisten Sicherheitskonzepte setzen auf die Erkennung von fremder Software oder auffälligem Verhalten. Doch bei einem LOTL-Angriff findet beides nicht statt. Alles wirkt legitim – denn es ist legitim. Genau deshalb greifen hier viele Schutzmechanismen ins Leere. Antivirenprogramme schlagen nicht an, weil keine Malware im klassischen Sinne vorliegt. Firewall-Regeln bleiben wirkungslos, weil sich der Angreifer innerhalb des Netzes bewegt. Und Protokolle sind nur hilfreich, wenn sie detailliert genug sind – was in vielen Unternehmen nicht der Fall ist.
Hinzu kommt: Je besser der Angreifer vorbereitet ist, desto unauffälliger verhält er sich. Manche Attacken laufen über Wochen oder Monate – leise, präzise und ohne sichtbare Spuren. Gerade für Unternehmen ohne aktives Monitoring oder ohne Segmentierung im Netzwerk ist das ein enormes Risiko.
Was ein Desaster-Recovery-Plan berücksichtigen muss
Ein moderner Desaster-Recovery-Plan darf sich nicht nur auf äußere Angriffe oder Hardware-Ausfälle konzentrieren. Er muss auch interne Bedrohungsszenarien abbilden – und LOTL ist eines der relevantesten davon. Das bedeutet konkret: Unternehmen müssen wissen, welche administrativen Werkzeuge im Einsatz sind, wer sie nutzen darf, wie sie überwacht werden und wie im Ernstfall schnell und zuverlässig reagiert werden kann.
Zudem sollte geprüft werden, ob Backups wirklich außerhalb des Netzwerks erreichbar sind – oder ob sie bei einem internen Angriff ebenfalls gefährdet wären. Auch Zugriffskonzepte, Rechtevergabe, Protokollierung und Alarmierungen gehören auf den Prüfstand. Wer diese Fragen im Vorfeld klärt, kann im Ernstfall zielgerichtet handeln – statt im Dunkeln zu tappen.
„Living off the Land“ ist eine der gefährlichsten Bedrohungen unserer Zeit – gerade, weil sie schwer zu erkennen ist und auf Systemen basiert, denen wir jeden Tag vertrauen. Doch mit der richtigen Vorbereitung lässt sich das Risiko deutlich reduzieren. Ein sauber geplanter, regelmäßig getesteter Desaster-Recovery-Plan ist dabei der entscheidende Baustein.
Schritt für Schritt: Ihre Roadmap zum Desaster-Recovery-Plan
Struktur statt Aktionismus
Phase 1: Bewertung & Priorisierung
Phase 2: Zieldefinition & Strategie
Phase 3: Umsetzung & Tests
Phase 4: Dokumentation & Verankerung
Ein DR-Plan ist ein lebendiges Dokument. Er muss regelmäßig aktualisiert, zugänglich gemacht und in die Unternehmensprozesse eingebettet werden. Nur wenn Verantwortlichkeiten klar benannt und Prozesse transparent sind, kann der Plan im Ernstfall greifen.
In dieser Phase sollten auch Schulungen stattfinden – nicht nur für IT, sondern auch für die Fachabteilungen. Denn ein erfolgreicher Wiederanlauf ist keine rein technische, sondern eine unternehmerische Leistung.
Desaster Recovery ist kein Projekt, das man „mal eben“ umsetzt. Aber mit einer strukturierten Roadmap, klaren Prioritäten und realistischen Zielen wird aus einem Risiko ein beherrschbares Szenario. Unternehmen, die vorbereitet sind, gewinnen im Ernstfall nicht nur Zeit – sondern auch Vertrauen, Stabilität und Handlungsfähigkeit.
Fazit: Wer vorbereitet ist, bleibt handlungsfähig
Struktur statt Aktionismus
Ein IT-Notfall kommt selten mit Vorankündigung. Und wenn er eintritt, zählt jede Minute. Unternehmen, die dann einfach in die Schublade greifen und auf einen konkreten, durchdachten Plan zurückgreifen können, sind im Vorteil – operativ, rechtlich und kommunikativ.
Desaster Recovery ist kein rein technisches Thema. Es ist ein strategisches Element moderner Unternehmensführung. Wer seine Systeme kennt, Abhängigkeiten bewertet, Verantwortlichkeiten definiert und Wiederanlaufszenarien durchspielt, ist nicht nur besser geschützt – sondern auch schneller wieder im Geschäft.
Dabei geht es nicht darum, jedes Szenario bis ins letzte Detail zu antizipieren. Vielmehr zählt die Fähigkeit, im Krisenfall schnell, geordnet und wirksam zu handeln. Und genau dafür ist ein guter Desaster-Recovery-Plan gemacht.
Sind Sie vorbereitet? Oder hoffen Sie noch auf Glück?
Vielleicht läuft Ihre IT derzeit reibungslos. Vielleicht ist der letzte Ausfall schon vergessen. Doch genau jetzt – wenn alles stabil wirkt – ist der beste Zeitpunkt, das Fundament für den Ernstfall zu legen.
Denn die zentrale Frage ist nicht ob etwas passiert, sondern wie gut Sie darauf vorbereitet sind.
Jetzt handeln – mit einem starken Partner an Ihrer Seite
Bei KNS – Kurfer Network Support unterstützen wir Unternehmen seit Jahren dabei, ihre IT-Infrastruktur nicht nur leistungsfähig, sondern auch krisenfest aufzustellen. Wir kombinieren technische Kompetenz mit strategischem Denken – für Lösungen, die nicht nur im Normalbetrieb, sondern auch im Ausnahmezustand funktionieren.
Ob Analyse Ihrer aktuellen Systeme, Erstellung eines individuellen Desaster-Recovery-Plans oder Aufbau einer resilienten Private-Cloud-Umgebung – wir begleiten Sie persönlich, verlässlich und lösungsorientiert.
Vereinbaren Sie ein unverbindliches Erstgespräch.
Gemeinsam klären wir, wie Ihr Unternehmen im Notfall handlungsfähig bleibt – ohne blinden Aktionismus, aber mit klarer Struktur.
