Business Continuity: ein IT-Notfallplan, der am schlechtesten Tag trägt

Business Continuity heißt: Ihre zeitkritischen Abläufe laufen nach einem Ausfall weiter oder schnell wieder an. Der IT-Notfallplan ist der Teil davon, der Server, Daten und Zugänge betrifft. Er legt fest, was zuerst wieder laufen muss, wie viel Datenverlust tragbar ist und wer entscheidet. Und er liegt auf Papier vor, falls die IT selbst ausfällt.

1. Was Business Continuity bedeutet — und wo der IT-Notfallplan hingehört

Das BSI übersetzt Business Continuity mit „Geschäftsfortführung“. Zeitkritische Abläufe sollen nach einem Schaden weiterlaufen oder wieder anlaufen, damit Ihr Betrieb arbeitsfähig bleibt. Die Steuerung dafür heißt BCM. Früher sprach das BSI von Notfallmanagement; mit dem Standard 200-4 hat es den Begriff durch Business Continuity Management ersetzt. Gemeint ist dasselbe.

Der IT-Notfallplan ist ein Ausschnitt davon. Das BSI nennt diesen Teil IT-Notfallmanagement, englisch IT-Service Continuity Management. Es sorgt dafür, dass Server, Anwendungen und Daten die Anforderungen an den Wiederanlauf erfüllen und der Datenverlust im Notfall klein bleibt. Das volle BCM schaut weiter: Es fragt auch, was passiert, wenn Personal, Gebäude oder ein Dienstleister ausfallen.

Für die Praxis wichtig ist eine Abstufung, die das BSI in seinem Glossar trifft. Nicht jeder Ausfall ist ein Notfall:

Ein Notfallplan soll genau den mittleren Fall abdecken — und verhindern, dass aus ihm eine Krise wird. Zur Abgrenzung: Die Schutzmaßnahmen von Passwort bis Firewall behandelt unser Überblick zur IT-Sicherheit im Mittelstand. Dort ist der Notfallplan einer von zehn Punkten, hier ist er das Thema.

2. Die Kennzahlen: BIA, RTO, RPO — und warum es jeweils zwei Werte gibt

Am Anfang steht die Business Impact Analyse, kurz BIA. Sie klärt, welche Abläufe und Ressourcen zeitkritisch sind und welche Folgen ein Ausfall hätte. Aus ihr leiten sich die Anforderungen an den Wiederanlauf ab. Vier Größen tragen den Plan:

Das BSI ist bei der RTO streng: Sie muss zwingend kürzer sein als die tolerierbare Ausfallzeit, weil auch das Erkennen und Alarmieren Zeit kostet. Der Kern steckt aber in einem Detail. Das BSI stellt jedem Sollwert einen Istwert gegenüber. Der RTO steht die RTA gegenüber, die tatsächlich erreichbare Wiederanlaufzeit. Der RPO steht die RPA gegenüber, der tatsächlich zu erwartende Datenverlust — in der Regel Ihr echter Sicherungstakt. Belastbar ist ein Plan erst, wenn der Istwert unter dem Sollwert liegt.

Für den Datenverlust stellt JTL im eigenen Handbuch eine Leitfrage, die für jede Warenwirtschaft passt: „Wie viele Daten müssten Sie rekonstruieren, wenn Sie ein Backup einspielen?“ Wer abends sichert und mittags ausfällt, trägt einen halben Tag Aufträge von Hand nach.

3. Szenario: Der Wawi-Server startet am Montag im Dezember nicht

Szenario: Das folgende Beispiel ist konstruiert, kein Kundenfall. Es nennt bewusst keine Schadenssummen, weil diese von Umsatz, Sortiment und Saison abhängen.

Ein Händler mit zwölf Beschäftigten verkauft über einen JTL-Shop und einen Marktplatz. JTL-Wawi läuft auf einem Server im Büro, der Shop bei einem externen Hoster, die E-Mail über Microsoft 365. Montag, zweite Dezemberwoche, 7:40 Uhr: Der Server startet nicht mehr.

Was dann geschieht, folgt aus der Technik. Der Shop verkauft weiter, denn er läuft woanders, und die Bestellungen liegen in seiner eigenen Datenbank. In die Wawi gelangen sie aber erst mit dem nächsten Abgleich, und auch die Bestände im Shop werden nicht mehr aktualisiert (Quelle: JTL-Guide zum Onlineshop-Abgleich). Knappe Artikel können so doppelt verkauft werden. Wer Lieferscheine und Etiketten aus der Wawi druckt, druckt nichts. Die E-Mail läuft — Sie können Kunden also schreiben, wenn jemand weiß, was drinstehen soll.

Der Unterschied zwischen beiden Spalten ist keine Technik, sondern Vorarbeit. Keine Zeile rechts setzt neue Software voraus. Jede setzt voraus, dass vorher jemand darüber nachgedacht und es aufgeschrieben hat.

4. Business Impact Analyse im Kleinformat

Eine BIA muss kein Beraterprojekt sein. Die BSI-Broschüre für kleine und mittlere Unternehmen stellt für den Einstieg vier Fragen: Wie lange dürfen Ihre kritischen Abläufe höchstens ausfallen? Wie lange soll der Notbetrieb durchhalten? Wie weit liegt das heute Mögliche davon entfernt? Und welche Mittel braucht der Notbetrieb?

Für einen Onlinehändler lässt sich das auf ein Arbeitsblatt bringen. Die rechte Spalte enthält bewusst keine Zahlen, denn die tolerierbare Ausfallzeit ergibt sich aus Ihrem Umsatz, Ihren Fristen und Ihrer Saison.

Aus dem Blatt ergeben sich zwei Dinge. Erstens die Ausfallzeit, die Sie sich je Ablauf leisten können. Zweitens die Abläufe, die ohne Wawi gar nicht laufen — sie bestimmen, was zuerst zurückkommen muss. Für die Auswertung stellt das BSI einen kostenlosen BIA-Auswertungsbogen als Excel-Datei bereit, derzeit als Testversion. Das Ergebnis ist bei dieser Methode kein Gutachten, sondern eine Liste, die in eine Schublade passt.

5. Die Reihenfolge beim Wiederanlauf: Abhängigkeiten statt Bauchgefühl

Welches System zuerst zurückkommt, entscheidet nicht seine Wichtigkeit, sondern seine Abhängigkeit. Das BSI leitet die Reihenfolge ausdrücklich aus den Beziehungen zwischen den Abläufen ab: Wer braucht was, um selbst zu laufen? Im Wiederanlaufplan sollen zudem die nötigen Rechte, die beteiligten Dienstleister und ein abschließender Funktionstest stehen. Für eine typische JTL-Umgebung ergibt das diese Folge:

1. Zugänge. Ohne Rechte als Administrator läuft nichts an. Für Microsoft 365 empfiehlt Microsoft zwei oder mehr Konten für den Notfallzugriff, falls die normale Anmeldung ausfällt. Wie diese Konten mit der Pflicht zur Mehr-Faktor-Anmeldung zusammenpassen, steht in unserem Beitrag zur MFA im Unternehmen.
2. Server und Datenbank. Ein Ersatzsystem mit SQL Server steht bereit, im Büro oder in der Cloud.
3. Backup einspielen — mit abgeschalteten Abgleichen. JTL weist ausdrücklich darauf hin, dass kein Abgleich unbeabsichtigt anlaufen darf, „weder manuell noch durch einen Hintergrunddienst wie JTL-Worker“. Für das Einspielen in eine andere Umgebung, etwa ein Ersatzsystem, warnt JTL sonst vor schweren Störungen im laufenden Betrieb.
4. Funktionstest in der Wawi. Stimmen Bestände, die letzten Aufträge und die Einstellungen?
5. Abgleiche einzeln einschalten. Zuerst den Shop, damit aufgelaufene Bestellungen und Bestände wieder fließen, dann Marktplätze und Kasse.
6. Versand und Druck. Etiketten, Lieferscheine, Rechnungen.
7. Datenlücke schließen. Alles zwischen letzter Sicherung und Ausfall mit Shop, Marktplatz und Zahlungsanbieter abgleichen.

Eine naheliegende Faustregel wäre „Wawi vor Shop vor Mail“. Sie greift zu kurz. Liegen Shop und E-Mail bei externen Anbietern, laufen beide weiter; der Engpass ist dann nicht der Shop, sondern der Abgleich dazwischen. Die Reihenfolge ergibt sich aus Ihrer Umgebung — und genau deshalb gehört sie aufgeschrieben.

Für den Detailgrad setzt das BSI die Latte hoch: Eine fachkundige dritte Person soll den Wiederanlauf allein anhand des Plans umsetzen können. Das ist der Test für den schlechtesten Tag, nämlich den, an dem Ihr Administrator im Urlaub ist.

6. Backups, die im Ernstfall tragen: getrennt, gleichzeitig, getestet

Ein Notfallplan ist nur so gut wie die Sicherung, auf die er zeigt. Drei Eigenschaften entscheiden.

Getrennt. JTL rät, Sicherungen nie auf derselben Festplatte wie die Datenbank abzulegen, sondern am besten auf einem anderen Server an einem anderen Ort. Gegen Ransomware reicht auch das nicht immer: Das BSI weist darauf hin, dass Snapshots und Sicherungen auf Festplatten selbst mit verschlüsselt werden können, und hebt Offline-Backups besonders hervor. Der Bitkom rät in seiner Studie 2026 ebenso, Sicherungen getrennt vom Firmennetz aufzubewahren.

Gleichzeitig. Eine vernetzte Umgebung gilt laut JTL erst dann als vollständig gesichert, wenn für jedes System mit eigenen Daten eine Sicherung aus etwa derselben Zeit vorliegt. Beim JTL-Shop sind das drei Orte: die Datenbank der Wawi, die Datenbank des Shops mit Kunden und Bestellungen und die Dateien auf dem Webspace. Wawi und Shop gehören also in denselben Takt.

Getestet. JTL empfiehlt, Sicherungen regelmäßig testweise einzuspielen, etwa in eine SQL-Server-Testinstanz auf einem separaten Rechner. Das BSI zählt den Restore-Test von Datenbank-Servern und den Lesbarkeitstest von Backups ausdrücklich zu den Funktionstests. Zur Aufbewahrung nennt JTL als Beispiel die Sicherungen der letzten zwei Wochen plus ein Archiv pro Monat — hilfreich, wenn ein Fehler erst spät auffällt.

Liegt die Wawi in der Cloud, übernimmt der Anbieter einen Teil davon, etwa mit täglichen Snapshots. Zwei Fragen bleiben trotzdem bei Ihnen. Erstens: Was steht im Vertrag zur Wiederherstellungszeit? Das BSI empfiehlt, Verträge und Service-Level-Vereinbarungen genau darauf zu prüfen. Zweitens: Gibt es eine Kopie außerhalb dieses Anbieters? Die Unterschiede zwischen Cloud und eigenem Server beschreibt unser Ratgeber zum Cloud-Hosting für JTL-Wawi; welche Fragen Sie dem Hoster vor der Unterschrift stellen, zeigt unser Webhosting-Vergleich, dort auch mit Blick auf Artikel 32 DSGVO.

Für Microsoft 365 gilt dieselbe Frage. Microsoft bietet mit Microsoft 365-Backup ein eigenes Produkt für SharePoint, OneDrive und Exchange an, abgerechnet nach Verbrauch. Ob Sie das oder eine andere Lösung brauchen, entscheidet Ihre BIA: Wie schwer wöge ein gelöschtes Postfach im Dezember?

Ein ehrlicher Hinweis zum Schluss: Das BSI schreibt selbst, dass sich RTO und RPO bei einem Cyberangriff meist nicht einhalten lassen. Vor dem Einspielen stehen dann die Sicherung von Beweisen und die Frage, ob der Angreifer noch im Netz ist. Planen Sie für diesen Fall mehr Zeit ein. Für Angriffe auf den Shop selbst gibt es unseren eigenen Notfallplan für DDoS-Angriffe.

Wie viele Kopien ein Notfallplan voraussetzt, beantwortet die 3-2-1-Regel: drei Kopien Ihrer Daten, das Original mitgezählt, auf zwei Speichermedien, eine davon außer Haus. Gegen Ransomware kommen eine Kopie hinzu, die offline oder unveränderbar liegt, und ein Restore-Test ohne Fehler. Wie das für Wawi-Datenbank, Shop-Dateien und Microsoft 365 aussieht, zeigt unser Beitrag zur 3-2-1-Backup-Regel für Händler.

7. Was in den IT-Notfallplan auf Papier gehört

Ein Plan, der auf dem ausgefallenen Server liegt, existiert im Notfall nicht. Der Bitkom schreibt in seiner Studie 2026, Notfallpläne sollten auch bei einem Ausfall der IT verfügbar sein. Die BSI-Broschüre für KMU nennt „Zettel und Stift“ sogar ausdrücklich als Beispiel für die Ausstattung im Notfall. In den gedruckten Plan gehören:

• Wer den Notfall ausruft, wer vertritt und nach welcher Frist aus einer Störung ein Notfall wird.
• Alle Notfallkontakte mit Vorabsprachen: IT-Dienstleister, Hoster, Internetanbieter, Versanddienstleister — mit Erreichbarkeit und vereinbarter Reaktionszeit.
• Der Erstkontakt für alle Mitarbeitenden, etwa über die IT-Notfallkarte des BSI mit eigenem Feld für die Rufnummer.
• Wo die Sicherungen liegen, wie alt sie sein dürfen und wer sie einspielen darf.
• Die Reihenfolge beim Wiederanlauf mit Abhängigkeiten und nötigen Rechten.
• Wo die Notfallzugänge verwahrt sind — der Ort, nicht die Passwörter selbst.
• Der Notbetrieb je Ablauf: Wie nehmen Sie Aufträge an, wie versenden Sie, wer schreibt Kunden?
• Meldewege, etwa an die Datenschutzaufsicht und bei Angriffen an die Zentrale Ansprechstelle Cybercrime (ZAC) beim Landeskriminalamt.
• Stand-Datum und Verteiler: Wer hat welche Ausgabe?

Unser Rat aus Projekten: Bewahren Sie mindestens zwei Ausdrucke an verschiedenen Orten auf, einen davon außerhalb des Büros. Und sichern Sie Beweise vor dem Aufräumen. Das BSI rät, Protokolle, Log-Dateien und Fotos von Bildschirmen zu sichern, bevor die Analyse auf den Systemen beginnt.

Eine Vorlage müssen Sie nicht selbst erfinden. Das BSI stellt zum Standard 200-4 kostenlose Dokumentvorlagen bereit, darunter Geschäftsfortführungsplan, Wiederanlauf- und Wiederherstellungsplan sowie ein Notfallhandbuch. Die IT-Notfallkarte für Flure und Arbeitsplätze gibt es als ausfüllbares PDF. Die IHK München bietet ein Muster für einen IT-Notfallplan zum Download. Keine Vorlage ersetzt aber den Inhalt: die Nummern, Fristen und Reihenfolgen Ihres Betriebs.

8. Testen: wo Soll auf Ist trifft

Ein ungetesteter Plan beruht auf Annahmen. Das BSI sagt das deutlich: Solange keine Tests vorliegen, soll die tatsächliche Wiederanlaufzeit realistisch geschätzt werden und keinen gewünschten Zielzustand zeigen. Lässt sie sich nicht schätzen, ist sie als „unbekannt“ zu kennzeichnen. Wer noch nie zurückgespielt hat, kann diese Zeit nur raten. Der Standard 200-4 kennt dafür mehrere Übungsarten, vier davon lassen sich direkt auf einen Händler übertragen:

Für die Einstiegsstufe verlangt der Standard Stabs- und Alarmierungsübung regelmäßig und empfiehlt Planbesprechung und Funktionstest. Für einen Händler bringt der Funktionstest am meisten: Die gestoppte Zeit ist Ihre RTA. Liegt sie über Ihrer RTO, wissen Sie es jetzt und nicht im Dezember. Nach jeder Übung und jedem echten Vorfall passen Sie den Plan an, so rät es die BSI-Broschüre. Den passenden Zeitraum vor der Saison ordnet unsere Checkliste zum Weihnachtsgeschäft ein.

9. Pflicht oder Kür? NIS2, BSI-Standard 200-4 und ISO 22301

Für Unternehmen unter dem BSI-Gesetz ist Business Continuity Pflicht. § 30 Absatz 2 Nummer 3 BSIG verlangt die „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“. Nach Absatz 1 ist die Umsetzung zudem zu dokumentieren. Ob Ihr Betrieb darunter fällt, klärt unser Beitrag zu den NIS2-Pflichten für Unternehmen; ein klassischer Onlineshop ist meist nicht direkt betroffen.

Den Weg beschreibt der BSI-Standard 200-4 in der Version 1.0 vom Mai 2023. Er löst den Standard 100-4 ab und kennt drei Stufen: Reaktiv-, Aufbau- und Standard-BCMS. Das Reaktiv-BCMS nennt das BSI den idealen Einstieg für KMU: schnell umsetzbar, mit einem Geschäftsfortführungsplan als Kern. Es ist aber ausdrücklich nur eine Einstiegsstufe, die nach dem ersten Durchlauf zu einer höheren Stufe weiterentwickelt werden muss. Gelten gesetzliche Vorgaben, empfiehlt das BSI eher den Start mit Aufbau- oder Standard-BCMS.

International maßgeblich ist ISO 22301. Laut BSI ist sie die erste internationale Norm zum BCM, nach der sich ein Unternehmen zertifizieren lassen kann; sie erschien 2012 und wurde 2019 überarbeitet. Der Standard 200-4 ist mit dieser Fassung kompatibel. Eine eigene Zertifizierung nach 200-4 plant das BSI derzeit nicht, ein voll umgesetztes Standard-BCMS kann aber die Reife für ISO 22301 erreichen.

Für alle anderen gilt: Eine Pflicht aus dem BSIG besteht nicht, das Risiko schon. Laut der Bitkom-Studie Wirtschaftsschutz 2026 waren 45 Prozent der befragten Unternehmen in den zwölf Monaten davor von einem Ransomware-Angriff betroffen. Befragt wurden 1.003 Unternehmen ab zehn Beschäftigten. Als sehr gut vorbereitet sehen sich 43 Prozent, im Vorjahr waren es 50 Prozent.

10. Fazit: kurz, auf Papier, einmal durchgespielt

Business Continuity klingt nach Konzern, beginnt im Mittelstand aber klein: ein Arbeitsblatt mit Ihren Abläufen, zwei Kennzahlen je System, eine begründete Reihenfolge, ein getestetes Backup und ein Ausdruck, der nicht auf dem Server liegt. Das BSI nennt diesen Einstieg Reaktiv-BCMS. Er ersetzt kein vollständiges BCM, bringt Sie aber vom Hoffen zum Messen.

Läuft Ihre Warenwirtschaft in der Cloud oder soll sie dorthin, prüfen wir mit Ihnen im Rahmen unseres JTL Cloud Hostings, wie Sicherung und Wiederanlauf dort geregelt sind. Für Notfallzugänge und die Anmeldung in Microsoft 365 ist unsere Beratung zu Office 365 und Lizenzen der passende Rahmen.

Hinweis: Dieser Beitrag gibt den Stand vom 25. September 2026 wieder. Er ersetzt keine Rechtsberatung und keine auf Ihren Betrieb bezogene Sicherheitsberatung. Die Angaben zum BSI-Gesetz ordnen die Rechtslage allgemein ein; ob und wie sie für Sie gelten, klären Sie im Einzelfall.

11. Häufige Fragen zu Business Continuity und IT-Notfallplan

Was bedeutet Business Continuity?

Business Continuity heißt auf Deutsch Geschäftsfortführung. Gemeint ist, dass zeitkritische Abläufe nach einem Schaden weiterlaufen oder schnell wieder anlaufen, damit der Betrieb arbeitsfähig bleibt. Die Steuerung dafür heißt Business Continuity Management, kurz BCM, auf Deutsch Notfallmanagement. Laut BSI umfasst sie zwei Bereiche: Vorsorge gegen Unterbrechungen und die Reaktion danach.

Was ist der Unterschied zwischen BCM und Notfallmanagement?

Inhaltlich keiner. Das BSI hat mit dem Standard 200-4 den früheren Begriff Notfallmanagement durch Business Continuity Management ersetzt. Abzugrenzen ist dagegen das IT-Notfallmanagement: Es kümmert sich nur um Server, Anwendungen und Daten. Das volle BCM betrachtet zusätzlich Personal, Gebäude und Dienstleister, die zeitkritische Abläufe brauchen.

Wie läuft eine Business Impact Analyse ab?

Sie listen Ihre Abläufe auf und fragen je Ablauf: Welcher Schaden entsteht, wenn er ausfällt, und ab wann ist er nicht mehr tragbar? Daraus folgen die maximal tolerierbare Ausfallzeit, die geforderte Wiederanlaufzeit und der zulässige Datenverlust. Zuletzt ordnen Sie jedem Ablauf die Systeme, Menschen und Dienstleister zu, die er braucht.

Was ist der Unterschied zwischen RTO und RPO?

Die RTO legt fest, wie schnell ein System nach dem Ausrufen des Notfalls wieder laufen muss. Die RPO legt fest, wie alt die Daten danach höchstens sein dürfen, und bestimmt damit Ihren Sicherungstakt. Beide sind Sollwerte. Das BSI stellt ihnen die tatsächlich erreichbaren Werte gegenüber, genannt RTA und RPA.

Was gehört in einen IT-Notfallplan?

Wer den Notfall ausruft, alle Notfallkontakte mit Vorabsprachen, der Erstkontakt für Mitarbeitende, Ort und Alter der Backups, die Reihenfolge beim Wiederanlauf mit den nötigen Rechten, der Notbetrieb je Ablauf, Kommunikation und Meldewege. Dazu kommt ein Stand-Datum. Der Plan muss auch ohne IT greifbar sein, also gedruckt an mindestens zwei Orten.

Gibt es eine Vorlage für einen IT-Notfallplan?

Ja. Das BSI stellt zum Standard 200-4 kostenlose Dokumentvorlagen bereit, darunter Geschäftsfortführungsplan, Wiederanlaufplan und Notfallhandbuch, dazu eine ausfüllbare IT-Notfallkarte für Mitarbeitende. Auch die IHK München bietet ein Muster an. Eine Vorlage liefert die Struktur; Telefonnummern, Fristen und die Reihenfolge Ihrer Systeme tragen Sie selbst ein.

Ist ein IT-Notfallplan Pflicht?

Für Einrichtungen unter dem BSI-Gesetz ja: § 30 Absatz 2 Nummer 3 BSIG verlangt die Aufrechterhaltung des Betriebs mit Backup-Management, Wiederherstellung und Krisenmanagement, und die Umsetzung ist zu dokumentieren. Ein klassischer Onlineshop fällt meist nicht darunter. Für ihn ist der Plan keine Pflicht aus diesem Gesetz, aber Vorsorge für den Tag, an dem die Systeme stehen.

Wie oft sollte man einen Notfallplan testen?

Einen festen Takt nennt die BSI-Broschüre für kleine und mittlere Unternehmen nicht. Sie empfiehlt, regelmäßig zu testen und den Plan nach jeder Übung und jedem echten Notfall anzupassen. Wir raten Händlern zu einem Funktionstest vor der Hauptsaison und nach jeder größeren Änderung, etwa einem Serverwechsel oder einem neuen Verkaufskanal.

Quellen & offizielle Informationen

Alle Quellen wurden am 25. September 2026 abgerufen und inhaltlich gegengelesen. Externe Quellen öffnen in einem neuen Tab.

• BSI: BSI-Standard 200-4 Business Continuity Management — Standard (Version 1.0, Mai 2023) zum Download: Stufenmodell, Kennzahlen, Soll-Ist-Vergleich, Wiederanlaufplan, Übungsarten, Einordnung von ISO 22301; Hinweis, dass keine Zertifizierung nach 200-4 geplant ist.
• BSI: Glossar und Abkürzungsverzeichnis zum BSI-Standard 200-4 (PDF) — Definitionen von Business Continuity, BCM, BIA, MTA, RTO, RTA, RPO, RPA, Störung, Notfall und Krise.
• BSI: Business Continuity Management (BCM) für KMU — Broschüre „Einstieg in das BCM für KMU“ (Stand August 2025) mit Stufen, den drei Plänen und einer Checkliste für den Geschäftsfortführungsplan.
• BSI: Hilfsmittel zum BSI-Standard 200-4 — kostenlose Dokumentvorlagen und BIA-Auswertungsbogen.
• BSI: Maßnahmenkatalog zum Notfallmanagement – Fokus IT-Notfälle — Vorbereitung, Bereitschaft, Bewältigung und Nachbereitung für kleine und mittlere Unternehmen.
• BSI: IT-Notfallkarte „Verhalten bei IT-Notfällen“ — ausfüllbares PDF mit Feld für die eigene Notfallnummer.
• BSI: Ransomware – Bedrohungslage (PDF) — Offline-Backups als Vorsorge, Risiko mitverschlüsselter Snapshots.
• Gesetze im Internet: § 30 BSIG — Risikomanagementmaßnahmen, darunter Absatz 2 Nummer 3 zur Aufrechterhaltung des Betriebs.
• JTL-Guide: Datensicherung für JTL-Wawi einrichten — Backup-Strategie, getrennte Ablage, Test auf einer Testinstanz, Aufbewahrung.
• JTL-Guide: Datenbank-Backup wieder einspielen — Abgleiche vor dem Einspielen deaktivieren, Datenverlust seit der letzten Sicherung.
• JTL-Guide: Einfachen Onlineshop-Abgleich durchführen — welche Daten der Abgleich zwischen Shop und Wawi überträgt.
• JTL-Guide: Datenbank-Backups von JTL-Shop erstellen — die drei Datenorte eines JTL-Shops.
• Microsoft Learn: Verwalten von Konten für den Notfallzugriff in Microsoft Entra ID — Empfehlung von zwei oder mehr Notfallkonten.
• Microsoft Learn: Übersicht über Microsoft 365-Backup — Umfang und nutzungsbasierte Abrechnung.
• Bitkom: Studienbericht Wirtschaftsschutz 2026 (PDF) — Befragung von 1.003 Unternehmen, Kennzahlen zu Ransomware und Vorbereitung, fünf Maßnahmen gegen Ransomware.
• IHK München: Muster IT-Notfallplan — Vorlage zum Download.