Autor: Marcel Peter

„Wird über die Verfügbarkeit von RZ gesprochen, werden häufig Prozentwerte von 99 % und mehr angeführt […].“ So beginnt das BSI ein Kapitel seiner Handlungsempfehlungen für Rechenzentren und fügt hinzu, dass mitunter auch die vier Tier-Klassen des Uptime Institute herangezogen werden. Für den Kunden seien solche Angaben hilfreich, um seinen Bedarf zu beschreiben. Für den Betreiber sei es „praktisch unmöglich“, ein Rechenzentrum exakt auf eine bestimmte Prozentzahl auszulegen (BSI, RZ-Verfügbarkeitsmaßnahmen, Kap. 14.2, S. 73). Wer ein Hosting auswählt und auf „Tier III“, „EN 50600“ oder „TSI Level 3“ stößt, liest also drei verschiedene Arten von Aussagen, von drei verschiedenen Stellen.

Tier: vier Stufen, ein Herausgeber

Die Tier-Klassifizierung stammt vom Uptime Institute. Es beschreibt vier Stufen über die Technik für Strom und Kühlung. Tier I ist Grundkapazität, für Wartung muss die Anlage abgeschaltet werden. Tier II ergänzt redundante Kapazitätskomponenten. Tier III ist „concurrently maintainable“, im laufenden Betrieb wartbar: Jede Komponente und jeder Verteilungspfad kann geplant herausgenommen werden, ohne den Betrieb zu stören. Tier IV fügt Fehlertoleranz hinzu, ein einzelner Geräteausfall oder eine unterbrochene Leitung soll den IT-Betrieb nicht beeinträchtigen.

Zertifizieren darf das nach eigener Aussage nur das Uptime Institute selbst („the only licensed firm“). Und es zertifiziert in Etappen: die Planungsunterlagen (Tier Certification of Design Documents), das gebaute Rechenzentrum (Tier Certification of Constructed Facility) und den Betrieb (Tier Certification of Operational Sustainability). Für Sie heißt das: Ein Zertifikat für die Planung belegt noch nicht, dass das Gebäude so gebaut wurde.

Und die Prozentzahlen, die man im Netz oft neben den Tiers findet? Auf den Seiten des Uptime Institute, die wir am 06.11.2026 gelesen haben, stehen keine Prozentwerte. Wir drucken sie deshalb nicht ab.

EN 50600: eine Norm, keine Marke

Die Normenreihe EN 50600 beschreibt Einrichtungen und Infrastrukturen von Rechenzentren. In Deutschland erscheint sie als DIN EN 50600, der allgemeine Teil zuletzt als DIN EN 50600-1 (VDE 0801-600-1):2019-08. Weitere Teile behandeln unter anderem Stromversorgung, Klimatisierung, Verkabelung und physische Sicherung. Die Normtexte sind kostenpflichtig, für diesen Beitrag haben wir sie nicht im Volltext gelesen.

Die Norm kennt vier Verfügbarkeitsklassen. Prozentwerte nennt sie nach einer Verlautbarung des für die Norm zuständigen Gremiums DKE/GK 719 vom März 2019 bewusst nicht, weil solche Zahlen „statistischer Grundlagen entbehren“. Die Klassen beruhen auf Gestaltungsprinzipien wie Mehrpfadigkeit und Komponentenredundanz.

Eine Norm ist kein Zertifikat. Nach EN 50600 prüfen verschiedene Stellen, und wer „nach EN 50600 gebaut“ schreibt, sagt noch nicht, wer das geprüft hat und mit welchem Ergebnis.

TSI: der Prüfkatalog aus der TÜV-NORD-Gruppe

Trusted Site Infrastructure, kurz TSI, ist eine Methodik der TÜV NORD GROUP zur Bewertung und Zertifizierung der physischen Sicherheit und Verfügbarkeit von Rechenzentren, etabliert seit 2001. Aktuell ist der Kriterienkatalog TSI.STANDARD in Version 4.6 vom 1. November 2024. Seit Version 4.0 deckt er nach Angabe von TÜV NORD die Anforderungen der EN 50600 ab.

TSI kennt vier Level, von „Mittlerer Schutzbedarf / Mittlere Verfügbarkeit“ bei Level 1 bis „Sehr hoher Schutzbedarf / Höchstverfügbarkeit“ mit dediziertem Rechenzentrumsgebäude bei Level 4. Ab Level 2 sind die Anforderungen mit den Verfügbarkeitsklassen der EN 50600 harmonisiert, Level 3 entspricht dort Klasse 3. Geprüft werden neun Bereiche, vom Umfeld über Baukonstruktion, Brandschutz, Sicherheit, Verkabelung, Energieversorgung und Klimatechnik bis zu Organisation und Dokumentation. Optional lassen sich zwei gleichwertige Rechenzentren als Verbund bewerten.

Und dann noch die Klassen des BSI

Für zusätzliche Verwirrung sorgt ein vierter Begriff. Das BSI arbeitet in seinem Hochverfügbarkeits-Kompendium mit eigenen Verfügbarkeitsklassen und setzt dort Zielwerte an: „hochverfügbar“ mit 99,99 Prozent im Jahr, also einer knappen Stunde Ausfall, und „höchstverfügbar“ mit 99,999 Prozent, gut fünf Minuten (RZ-Standortkriterien, Kap. 5.1, S. 18). Das sind die Klassen VK3 und VK4 des BSI. Mit den Verfügbarkeitsklassen der EN 50600 sind sie nach unserer Lesart nicht gleichzusetzen: Das BSI setzt Prozentziele, die Norm Gestaltungsprinzipien. Die Nummern sehen trotzdem gleich aus.

Was die Siegel nebeneinander sagen

Ob Tier III, Verfügbarkeitsklasse 3 und TSI Level 3 dasselbe meinen? Eine offizielle Gleichsetzung von Tier und den beiden anderen Systemen haben wir nicht gefunden. Belegt ist nur die Harmonisierung zwischen TSI und EN 50600, und die stammt von TÜV NORD selbst.

Was keines dieser Siegel sagt

Alle drei bewerten Gebäude, Technik und Betrieb des Rechenzentrums. Über die IT-Sicherheit Ihres Hosting-Pakets, also Server, Software und Zugänge, über Ihren Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO oder darüber, welchem Recht Ihre Daten unterliegen, sagen sie nichts. Dafür gibt es andere Nachweise, etwa ein Zertifikat nach ISO/IEC 27001 mit seinem Geltungsbereich. Die physische Sicherheit des Gebäudes prüft TSI dagegen mit.

Gesetzlich vorgeschrieben ist keine der Stufen; verlangen kann sie ein Vertrag oder eine Ausschreibung. Das BSI-Gesetz verlangt von Einrichtungen unter NIS2, dass ihre Maßnahmen den Stand der Technik einhalten und die einschlägigen europäischen und internationalen Normen berücksichtigen sollen (§ 30 Abs. 2 BSIG). Welche Normen, sagt das Gesetz nicht. Weder das BSIG noch die NIS2-Richtlinie noch DORA nennen die Tier-Klassifizierung des Uptime Institute oder die Normenreihe EN 50600.

Fünf Fragen an Ihren Hoster

Steht auf der Website Ihres Anbieters eines dieser Siegel, lohnt die Nachfrage. Für welchen Standort gilt das Zertifikat, und läuft Ihre Website genau dort? Wer hat es ausgestellt? Welche Stufe: Planung, gebautes Rechenzentrum oder Betrieb? Bis wann ist es gültig? Und gilt es für das Rechenzentrum des Hosters selbst oder für ein angemietetes Rechenzentrum eines Dritten?

Wenn die Antwort ein PDF mit Datum, Aussteller und Standort ist, haben Sie etwas in der Hand. Wenn sie „nach Tier-III-Standard“ lautet, eher nicht. Für Ihre Website selbst gibt es den Website-Compliance-Check von Experto Mundi; das Rechenzentrum dahinter prüft er nicht.

Quellen (Abrufdatum: 06.11.2026)

• BSI, Handlungsempfehlungen zu baulich-technischen Maßnahmen für Rechenzentren mit erhöhtem Verfügbarkeitsbedarf (RZ-Verfügbarkeitsmaßnahmen), Version 1.0 vom 21.06.2023, Kap. 14.2, S. 73 (PDF): bsi.bund.de
• BSI, Kriterien für die Standortwahl von Rechenzentren, Version 2.1, Dezember 2024, Kap. 5.1, S. 18 (PDF): bsi.bund.de
• Uptime Institute, Tier Classification System: uptimeinstitute.com/tiers
• Uptime Institute, Tier Certification: uptimeinstitute.com/tier-certification
• DKE/GK 719, Normauslegung zum BSI-Dokument „Kriterien für die Standortwahl höchstverfügbarer und georedundanter Rechenzentren“, 20.03.2019: dke.de
• VDE Verlag, DIN EN 50600-1 (VDE 0801-600-1):2019-08, Produktseite: vde-verlag.de
• TÜV NORD, TSI.STANDARD Trusted Site Infrastructure: tuev-nord.de
• TÜV NORD, TSI-Zertifizierungsmethodik: tuev-nord.de
• BSI-Gesetz (BSIG) vom 02.12.2025, BGBl. 2025 I Nr. 301, § 30 Abs. 2: gesetze-im-internet.de

Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Fach- und Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er bewertet keinen Anbieter und kein einzelnes Rechenzentrum und ersetzt keine Beratung im Einzelfall. Maßgeblich sind die Dokumente der jeweiligen Herausgeber in ihrer geltenden Fassung; Stand: 06.11.2026.

Ca. 200 Kilometer. So weit sollen zwei Rechenzentren nach dem Bundesamt für Sicherheit in der Informationstechnik (BSI) mindestens auseinander liegen, wenn das eine den Betrieb übernehmen soll, falls das andere ausfällt. Weniger als 100 Kilometer sollen es keinesfalls sein. Die Zahl steht in den „Kriterien für die Standortwahl von Rechenzentren“, Version 2.1 vom Dezember 2024, und ist eine Empfehlung, kein Gesetz. DORA, die EU-Verordnung für die Finanzbranche, nennt gar keine Kilometerzahl. Und für Angriffe mit Kriegswaffen, zu denen auch Atomwaffen zählen, verlangt das BSI eigene Sicherheitsbetrachtungen, die über den Rahmen des Dokuments hinausgehen.

Was das BSI wörtlich empfiehlt

Das BSI unterscheidet zwei Arten von Standortredundanz. Liegen zwei Rechenzentren nah beieinander, geben sie einander nur Betriebsredundanz. Liegen sie so weit auseinander, dass „selbst ein Großschadensereignis nicht gleichzeitig oder zeitnah mehrere RZ“ trifft, sprechen die Standortkriterien von Georedundanz (Kap. 4, S. 15). Als Beispiele für solche Ereignisse nennt das Dokument die Schneekatastrophe im Münsterland 2005 und die Jahrhunderthochwasser an Elbe und Donau 2013.

Für Georedundanz „sollten“ die Rechenzentren einen Mindestabstand von ca. 200 km haben (Kap. 4.1, S. 15). Das BSI begründet den Wert mit Erfahrungen zur flächigen Ausdehnung von Großschadensereignissen, mit der Überlegung, dass die Wahrscheinlichkeit eines gleichzeitigen Treffers mit wachsendem Abstand sinkt, und mit der begrenzten Fläche Deutschlands. Weniger ist erlaubt, wenn es im Einzelfall „unabweisbar“ ist. Dann muss der Betreiber das schriftlich begründen und einer Risikoanalyse unterziehen, und auch dann nie unter 100 km. Was „unabweisbar“ heißt, steht in Kap. 1.4 (S. 6 und 7): zwingende technische oder betriebliche Gründe. Dass ein geringerer Abstand billiger ist, zählt ausdrücklich nicht.

Für nahe Standorte gibt es eigene Werte. Ein Bombenfund aus dem Zweiten Weltkrieg kann eine Sperrung im Radius von bis zu 1.500 m auslösen, deshalb sollen betriebsredundante Rechenzentren rund 5 km auseinander liegen, wegen der Folgen für den Verkehr in der Umgebung besser 10 bis 15 km (Kap. 3, S. 14).

Zur Einordnung, eigene Rechnung als Luftlinie zwischen den Stadtzentren: Köln und Frankfurt am Main liegen ca. 150 km auseinander, Frankfurt und München ca. 300 km. Ob das BSI in Kap. 4.1 Luftlinie oder Leitungslänge meint, sagt es nicht ausdrücklich; da es um die Fläche eines Großschadensereignisses geht, liegt die Luftlinie nahe. Ein Paar Köln/Frankfurt läge also über der Untergrenze von 100 km, aber unter der Empfehlung von 200 km.

Kurzer Exkurs, weil er zeigt, wie weit das BSI denkt: Werden georedundante Rechenzentren vom selben Caterer versorgt, soll das Essen für mehr als ein Rechenzentrum nicht in derselben Küche zubereitet werden (Kap. 4.4, S. 17). Zur Begründung verweist der Anhang auf den Brechdurchfall-Ausbruch 2012 mit über 10.000 Betroffenen in fünf Bundesländern (Kap. 5.4.13, S. 25).

Und die Bombe?

Haben die 200 Kilometer etwas mit Bombenangriffen zu tun? Nach dem Dokument nicht. Kap. 1.5 (S. 7) klammert solche Szenarien ausdrücklich aus. Wer Ereignisse wie die Anschläge vom 11. September 2001 berücksichtigen will, braucht „spezielle Sicherheitsbetrachtungen“, die über die Standortkriterien hinausgehen. „Entsprechendes gilt“, so das BSI, wenn Angriffe mit Waffen als realistisch angenommen werden, die dem Gesetz über die Kontrolle von Kriegswaffen unterliegen. Atomwaffen stehen dort in Teil A der Kriegswaffenliste.

Kerntechnik kommt in den Standortkriterien trotzdem vor, nur an anderer Stelle. Ein einzelnes Rechenzentrum soll 40 km Abstand zu Anlagen halten, bei denen Ereignisse ab Stufe 5 der Internationalen Bewertungsskala für nukleare Ereignisse (INES) möglich sind, und 5 km zu Anlagen bis Stufe 4 (Kap. 2.1.1, S. 8 und 9). Begründet wird das mit den Evakuierungsradien von Tschernobyl (37 km) und Fukushima (20 km Sperrzone), nicht mit Waffenwirkung (Kap. 5.4.1, S. 21).

Und noch ein Satz, der in Diskussionen über die Zahl selten fällt: „Zu keinem der in diesem Dokument genannten Abstandswerte gibt es zwingende physikalische Gründe“ (Kap. 5.4, S. 21). Das BSI nennt seine Werte selbst „vernünftige plausible Vorgaben“.

Umstritten ist die Zahl trotzdem

Das BSI räumt ein, dass die Literatur zum Abstand weit auseinandergeht (Kap. 5.4.12, S. 25). Zitiert werden Angaben von „mehrere Kilometer“ bis „≥ 5.000 km“ für einen katastrophentoleranten Verbund. Das für die Normenreihe DIN EN 50600 zuständige Gremium DKE/GK 719 hat die erste Fassung der Standortkriterien im März 2019 kritisiert: Die 200 km seien nicht hergeleitet. Statt eines festen Abstands solle eine qualifizierte Risikoanalyse zeigen, ob zwei Standorte gemeinsame Risiken haben. Das BSI ist in der Fassung von 2024 bei den 200 km geblieben.

Dazu kommt ein technischer Zielkonflikt, den das BSI offen benennt. Ab mehr als 100 km Leitungslänge können nach dem BSI Probleme bei der synchronen Datenhaltung auftreten, und die Leitung ist immer länger als die Luftlinie (Kap. 2.2, S. 10). Großer Abstand schützt besser, macht aber eine verlustfreie Spiegelung schwerer. Beides zugleich optimal zu haben, hält das BSI für kaum möglich, der Betreiber muss im Sicherheitskonzept begründen, was zurücksteht (Kap. 1.3, S. 6). Als Ausweg nennt das Dokument, Datenbestände betriebsredundanter Rechenzentren zusätzlich in einem tatsächlich georedundanten Rechenzentrum zu sichern (Kap. 3, S. 14).

Wer hat also recht, das BSI mit der festen Zahl oder die Normungsleute mit der Risikoanalyse? Das lässt sich nicht pauschal entscheiden. Die Zahl ist leicht prüfbar, die Risikoanalyse genauer, aber nur so gut wie ihr Verfasser.

Was DORA verlangt

Für Banken, Versicherer und andere Finanzunternehmen gilt seit dem 17. Januar 2025 die Verordnung (EU) 2022/2554, kurz DORA (Art. 64). Art. 12 Abs. 4 verlangt von Finanzunternehmen, die keine Kleinstunternehmen sind, redundante IKT-Kapazitäten, die für den Geschäftsbedarf ausreichen. Eine Entfernung steht dort nicht.

Konkreter wird DORA nur für Zentralverwahrer. Sie brauchen nach Art. 12 Abs. 5 einen sekundären Verarbeitungsstandort „in geografischer Entfernung“, damit er „ein eigenes Risikoprofil“ hat und vom Ereignis am Hauptstandort nicht betroffen ist. Für zentrale Gegenparteien verlangt die Delegierte Verordnung (EU) 2024/1774 in Art. 24 Abs. 2 Buchst. c Ziff. ii einen sekundären Verarbeitungsstandort, der „ein anderes geografisches Risikoprofil“ aufweisen muss als der Primärstandort. Eine Kilometerzahl nennt keine der beiden Vorschriften. Auch das deutsche BSI-Gesetz verlangt von Einrichtungen unter NIS2 in § 30 Abs. 2 Nr. 3 Backup-Management und Wiederherstellung nach einem Notfall, ohne Abstandsangabe.

Und Ihre Website?

Die Standortkriterien richten sich vor allem an Rechenzentren mit hohem oder sehr hohem Schutzbedarf bei der Verfügbarkeit (Kap. 1, S. 5). Das BSI schreibt aber auch, dass ein Kunde anhand des Dokuments prüfen kann, ob ein Dienstleistungs-Rechenzentrum zu seinen Anforderungen passt (Kap. 1.1, S. 5). Genau dafür taugt es.

Unsere Einschätzung als Experto Mundi: Für die Website eines kleinen Betriebs ist die Frage nach zwei Rechenzentren im Abstand von 200 km selten die wichtigste. Wichtiger ist, wo die Datensicherung liegt und ob sie im selben Gebäude steht wie die Website. Fragen Sie Ihren Hoster, an welchen Standorten Website und Sicherung liegen, wie weit diese voneinander entfernt sind und ob das im Vertrag steht. Ein Prospekt mit dem Wort „georedundant“ ersetzt diese Angaben nicht.

Wie Ihre Website technisch dasteht, zeigt der Website-Compliance-Check von Experto Mundi. Die Frage nach den Rechenzentren beantwortet Ihr Hoster.

Quellen (Abrufdatum: 06.11.2026)

• BSI, Kriterien für die Standortwahl von Rechenzentren (RZ-Standortkriterien), Version 2.1, Dezember 2024, Kap. 1, 1.1, 1.3, 1.4, 1.5, 2.1.1, 2.2, 3, 4, 4.1, 4.4, 5.4, 5.4.1, 5.4.12, 5.4.13 (PDF): bsi.bund.de
• DKE/GK 719, Normauslegung zum BSI-Dokument „Kriterien für die Standortwahl höchstverfügbarer und georedundanter Rechenzentren“, veröffentlicht 20.03.2019: dke.de
• Verordnung (EU) 2022/2554 (DORA), Art. 12 Abs. 4 und 5, Art. 64, CELEX 32022R2554: EUR-Lex
• Delegierte Verordnung (EU) 2024/1774, Art. 24 Abs. 2 Buchst. c Ziff. ii, CELEX 32024R1774: EUR-Lex
• BSI-Gesetz (BSIG) vom 02.12.2025, BGBl. 2025 I Nr. 301, § 30 Abs. 2 Nr. 3: gesetze-im-internet.de
• Gesetz über die Kontrolle von Kriegswaffen, Anlage (Kriegswaffenliste), Teil A, Abschnitt I: gesetze-im-internet.de

Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechts- und Fachfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche oder technische Beratung. Maßgeblich sind allein die Rechtstexte und Dokumente in ihrer geltenden Fassung; Stand: 06.11.2026.

NIS2 trifft das Rechenzentrum selbst. DORA trifft seine Kunden aus der Finanzbranche und erreicht das Rechenzentrum über deren Verträge. Wer ein Rechenzentrum betreibt, muss beide Wege auseinanderhalten, weil Pflichten, Fristen und Aufsicht verschieden sind. Wer nur eine Website hostet, sollte wissen, welcher Weg seinen Anbieter betrifft. Stand der Rechtslage ist der 06.11.2026.

Wen NIS2 erfasst

Die EU-Richtlinie (EU) 2022/2555, kurz NIS2, gilt in Deutschland über das BSI-Gesetz in der Fassung des NIS2-Umsetzungsgesetzes. Das neue BSIG ist am 6. Dezember 2025 in Kraft getreten. In seiner Anlage 1 stehen unter „Digitale Infrastruktur“ ausdrücklich die Anbieter von Rechenzentrumsdiensten (Nr. 6.1.5), daneben Anbieter von Cloud-Computing-Diensten (Nr. 6.1.4) und Managed Services Provider (Nr. 6.1.10). Ob ein Webhoster unter die eine oder die andere Nummer fällt, hängt von seinem Angebot ab. Die Anlage nennt alle drei.

Ein Rechenzentrumsdienst ist nach § 2 Nr. 35 BSIG ein Dienst, dessen Strukturen vorrangig der zentralen Unterbringung, Zusammenschaltung und dem Betrieb von IT- oder Netzwerkausrüstungen dienen, samt Stromverteilung und Umgebungskontrolle. Das eigene Rechenzentrum eines Unternehmens, das nur der eigenen IT dient, soll nach Erwägungsgrund 35 der NIS2-Richtlinie nicht darunter fallen. Erwägungsgründe erläutern die Richtlinie, sie sind selbst kein verbindlicher Gesetzestext.

Dann entscheidet die Größe. Besonders wichtige Einrichtung ist nach § 28 Abs. 1 Nr. 4 BSIG, wer mindestens 250 Mitarbeiter hat oder über 50 Millionen Euro Jahresumsatz und zugleich über 43 Millionen Euro Jahresbilanzsumme. Wichtige Einrichtung ist nach § 28 Abs. 2 Nr. 3 BSIG, wer mindestens 50 Mitarbeiter hat oder jeweils über 10 Millionen Euro Umsatz und Bilanzsumme. Ein kleines Rechenzentrum mit 20 Leuten und 3 Millionen Euro Umsatz liegt unter beiden Schwellen, solange es keine kritische Anlage betreibt und nicht zu einer größeren Unternehmensgruppe gehört; Partner- und verbundene Unternehmen werden grundsätzlich mitgezählt (§ 28 Abs. 4 BSIG).

Unabhängig von der Größe besonders wichtig sind Betreiber kritischer Anlagen (§ 28 Abs. 1 Nr. 1 BSIG). Die Schwellen für Rechenzentren stehen in der BSI-Kritisverordnung, Anhang 4 Teil 3: Housing ab 3,5 MW vertraglich vereinbarter Leistung, Hosting ab 10.000 physischen oder 15.000 virtuellen Instanzen für Nutzer im Jahresdurchschnitt (abgerufen am 06.11.2026). Für den Begriff der kritischen Anlage gilt nach § 66 BSIG eine Übergangsregel, bis eine Rechtsverordnung nach dem KRITIS-Dachgesetz in Kraft ist. Bis dahin gilt die alte Begriffsbestimmung weiter, nach der die Rechtsverordnung nach § 56 Abs. 4 BSIG die kritischen Anlagen bestimmt, und das ist die BSI-Kritisverordnung. Ob sich die Werte dann ändern, ist offen.

Was NIS2 vom Betreiber verlangt

Die Kernpflicht steht in § 30 BSIG. Der Betreiber muss geeignete, verhältnismäßige und wirksame Maßnahmen ergreifen und das dokumentieren. Abs. 2 zählt die Mindestinhalte auf: Risikoanalyse und Sicherheitskonzepte, Bewältigung von Sicherheitsvorfällen, Aufrechterhaltung des Betriebs mit Backup-Management, Wiederherstellung und Krisenmanagement, Sicherheit der Lieferkette, Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen, Prüfung der Wirksamkeit, Schulungen, Kryptografie, Zugriffskontrolle und Personalsicherheit sowie Multi-Faktor-Authentifizierung. Für Rechenzentrumsdienste hat ein Durchführungsrechtsakt der EU-Kommission nach Art. 21 Abs. 5 NIS2 Vorrang (§ 30 Abs. 3 BSIG). Dessen Inhalt behandelt dieser Beitrag nicht.

Bei einem erheblichen Sicherheitsvorfall laufen nach § 32 Abs. 1 BSIG drei Uhren: unverzüglich, spätestens 24 Stunden nach Kenntnis eine frühe Erstmeldung, unverzüglich, spätestens 72 Stunden nach Kenntnis die eigentliche Meldung, spätestens einen Monat danach die Abschlussmeldung. Eine Zwischenmeldung gibt es nur, wenn das BSI darum bittet. Gemeldet wird an die gemeinsame Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe.

Registrieren müssen sich betroffene Einrichtungen spätestens drei Monate, nachdem sie erstmals als solche gelten (§ 33 Abs. 1 BSIG). Wer schon seit dem Inkrafttreten erfasst ist, war rechnerisch Anfang März 2026 dran. Wer die Frist verpasst hat, sollte das nicht liegen lassen: Eine fehlende oder falsche Registrierung kann mit bis zu 500.000 Euro geahndet werden (§ 65 Abs. 2 Nr. 6, Abs. 5 Satz 1 Nr. 5 BSIG).

Und die Geschäftsleitung? Sie muss die Maßnahmen umsetzen und überwachen, haftet bei schuldhafter Pflichtverletzung nach Gesellschaftsrecht und muss regelmäßig an Schulungen teilnehmen (§ 38 BSIG). Die Pflicht liegt damit bei der Leitung selbst.

Die Bußgelder, nüchtern gelesen

Für Verstöße gegen Risikomanagement, Dokumentation und Meldepflichten nennt § 65 Abs. 5 BSIG bis zu 10 Millionen Euro bei besonders wichtigen und bis zu 7 Millionen Euro bei wichtigen Einrichtungen. Die prozentualen Obergrenzen von 2 und 1,4 Prozent des weltweiten Gesamtumsatzes greifen nach § 65 Abs. 6 und 7 erst bei mehr als 500 Millionen Euro Gesamtumsatz.

Woher kommt diese Schwelle? Die Richtlinie selbst verlangt in Art. 34 Abs. 4 und 5 einen „Höchstbetrag von mindestens 10 000 000 EUR“ oder von „mindestens 2 %“ des Umsatzes, „je nachdem, welcher Betrag höher ist“. Gemeint ist die Obergrenze, die das nationale Gesetz mindestens vorsehen muss, kein Mindestbußgeld. 2 Prozent von 500 Millionen sind genau 10 Millionen. Unterhalb dieser Umsatzgrenze ist der feste Betrag ohnehin der höhere, das deutsche Gesetz bildet das also nur ab.

Wie DORA ins Rechenzentrum kommt

DORA, die Verordnung (EU) 2022/2554, gilt seit dem 17. Januar 2025 unmittelbar (Art. 64). Sie richtet sich an 20 Arten von Finanzunternehmen, von Kreditinstituten über Versicherer bis zu Krypto-Dienstleistern (Art. 2 Abs. 1 Buchst. a bis t). Ausgenommen sind unter anderem Versicherungsvermittler, die Kleinst-, kleine oder mittlere Unternehmen sind (Art. 2 Abs. 3 Buchst. e). Die BaFin hat ihre IT-Rundschreiben für Versicherer (VAIT), Kapitalverwaltungsgesellschaften (KAIT) sowie Zahlungs- und E-Geld-Institute (ZAIT) mit Ablauf des 16. Januar 2025 aufgehoben, die BAIT der Banken laufen mit Ablauf des 31. Dezember 2026 vollständig aus.

Das Rechenzentrum taucht in DORA als IKT-Drittdienstleister auf, also als „Unternehmen, das IKT-Dienstleistungen bereitstellt“ (Art. 3 Nr. 19). DORA nennt IKT-Drittdienstleister in Art. 2 Abs. 1 Buchst. u zwar selbst als Adressaten; eigene Pflichten gegenüber der Aufsicht entstehen aber vor allem, wenn sie als kritisch eingestuft werden (Art. 31). IKT-Dienstleistungen schließen ausdrücklich „Hardware als Dienstleistung“ ein (Art. 3 Nr. 21). Ob reine Flächen- und Stromvermietung ohne IT-Betrieb darunter fällt, beantwortet der Wortlaut nicht eindeutig. Eine Aussage der Aufsicht dazu haben wir nicht gefunden.

Die Pflichten treffen zuerst den Kunden. Er bleibt nach Art. 28 Abs. 1 Buchst. a voll verantwortlich, führt ein Informationsregister über alle IKT-Verträge (Art. 28 Abs. 3) und braucht für kritische oder wichtige Funktionen eine Ausstiegsstrategie (Art. 28 Abs. 8). Beim Rechenzentrum kommt das als Vertragstext an. Art. 30 Abs. 2 schreibt für jeden IKT-Vertrag unter anderem vor: eine vollständige Leistungsbeschreibung mit Regeln zur Unterauftragsvergabe, die Standorte der Leistung und der Datenspeicherung samt Vorabinformation bei Änderungen, Zugang zu den Daten bei Insolvenz oder Vertragsende, Unterstützung bei IKT-Vorfällen ohne zusätzliche oder zu vorab festgelegten Kosten, Zusammenarbeit mit den Behörden und Kündigungsrechte. Eine Pflicht, die Daten in der EU zu halten, enthält Art. 30 nicht. Geht es um kritische oder wichtige Funktionen, kommen nach Abs. 3 präzise Leistungsziele, getestete Notfallpläne, die Mitwirkung an bedrohungsgeleiteten Penetrationstests (TLPT), uneingeschränkte Zugangs-, Inspektions- und Auditrechte sowie Ausstiegsregeln mit Übergangszeit dazu.

Die europäischen Aufsichtsbehörden können einen IKT-Drittdienstleister als kritisch einstufen und dann direkt überwachen (Art. 31 Abs. 1). Maßgeblich sind unter anderem die systemischen Auswirkungen einer Störung, gemessen auch an der Zahl der betroffenen Finanzunternehmen und deren Aktiva (Art. 31 Abs. 2 Buchst. a).

Gilt dann beides?

Für den Finanzkunden nicht. Nach § 28 Abs. 6 Nr. 1 BSIG gelten die §§ 30, 31, 32, 35, 36, 38 und 39 BSIG nicht für Finanzunternehmen im Sinne von DORA. Das Rechenzentrum selbst ist kein Finanzunternehmen, für es gilt diese Ausnahme nicht. Ein Betreiber mit Bankkunden erfüllt also, wenn er die Schwellen erreicht, die NIS2-Pflichten für sich selbst und die DORA-Vertragspflichten gegenüber seinen Kunden. Eine Ausnahme gibt es bei der Meldepflicht: Betreibt ein Betreiber kritischer Anlagen eine Anlage für ein Finanzunternehmen, gilt § 32 BSIG insoweit nicht (§ 28 Abs. 7 BSIG). Dann meldet der Finanzkunde nach DORA an seine Aufsicht, und das Rechenzentrum unterstützt ihn nach Art. 30 Abs. 2 Buchst. f DORA. In den übrigen Fällen meldet das Rechenzentrum erhebliche Sicherheitsvorfälle selbst nach § 32 BSIG.

Was das für Hosting-Kunden heißt

Wenn Sie einen kleinen Betrieb führen und kein Finanzunternehmen im Sinne von DORA sind, also keine Bank, kein Versicherer, kein Zahlungs-, E-Geld- oder Krypto-Dienstleister, treffen Sie die DORA-Pflichten der Finanzunternehmen nicht. Ob NIS2 für Sie gilt, hängt von Ihrer eigenen Branche nach den Anlagen 1 und 2 des BSIG und Ihrer Größe ab, nicht davon, bei wem Ihre Website liegt.

Für Ihren Hoster kann das anders aussehen. Sie dürfen ihn fragen, ob er nach dem BSIG als wichtige oder besonders wichtige Einrichtung gilt und registriert ist, wie er Sie bei einem Vorfall informiert und wo Ihre Daten gespeichert werden. Die Antworten gehören in den Vertrag zur Auftragsverarbeitung oder in die Leistungsbeschreibung. Eine Antwort, die nur „wir sind sicher“ lautet, ist keine.

Den technischen Stand Ihrer eigenen Website können Sie mit dem Website-Compliance-Check von Experto Mundi prüfen lassen. Was NIS2 und DORA technisch für Websites bedeuten, steht im Beitrag NIS2 und DORA technisch.

Quellen (Abrufdatum: 06.11.2026)

• BSI-Gesetz (BSIG) vom 02.12.2025, BGBl. 2025 I Nr. 301, Stand der Textfassung zuletzt geändert durch Art. 8 G v. 22.10.2026, §§ 2 Nr. 35, 28 Abs. 4, 6 und 7, 30, 32, 33, 38, 65, 66 und Anlage 1 Nr. 6: gesetze-im-internet.de
• Richtlinie (EU) 2022/2555 (NIS2), Art. 21, Art. 34 Abs. 4 und 5, Erwägungsgrund 35, CELEX 32022L2555: EUR-Lex
• Verordnung (EU) 2022/2554 (DORA), Art. 2, 3 Nr. 19 und 21, 28, 30, 31, 64, CELEX 32022R2554: EUR-Lex
• Verordnung zur Bestimmung Kritischer Infrastrukturen nach dem BSI-Gesetz (BSI-Kritisverordnung), Anhang 4 Teil 3: gesetze-im-internet.de
• BaFin, Meldung „DORA kommt: Änderungen bei den aufsichtlichen Anforderungen an die IT“, 10.01.2025: bafin.de

Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Ob Ihr Unternehmen erfasst ist, hängt von Umständen ab, die nur eine Einzelfallprüfung klären kann. Maßgeblich sind allein die Rechtstexte in ihrer geltenden Fassung; Stand: 06.11.2026.

Am 7. Oktober 2026, abends um 21:47 Uhr UTC, sah der Sicherheitsanbieter Patchstack nach eigenen Angaben den ersten Angriff auf ein WordPress-Plugin namens Bricksforge. Insgesamt zählte der Anbieter 63 verschiedene IP-Adressen. Drei Meldungen sollten Sie als Betreiber einer Website kennen: diese Plugin-Lücke, einen Fehler im Webserver nginx und ein Urteil des Bundesgerichtshofs zur SCHUFA.

1. Bricksforge: Dateien hochladen ohne Anmeldung (CVE-2026-85097)

Was ist passiert?

Bricksforge ist ein Zusatz für den WordPress-Seitenbaukasten Bricks. In älteren Versionen kann ein Angreifer ohne Anmeldung beliebige Dateien auf den Server laden. Lädt er eine PHP-Datei hoch und ruft sie auf, läuft sein Code auf Ihrem Server. Die Fehlernummer lautet CVE-2026-85097. Streng genommen ist das keine „Codeausführung per Fernzugriff“ in einem Schritt, sondern ein Upload, der danach die Ausführung möglich macht. Für Sie macht das praktisch keinen Unterschied.

Die Schwachstelle liegt im Parameter temporaryFileUploads, genauer in dessen Feld url. Laut Patchstack holt sich der Angreifer zuerst einen Sicherheitsschlüssel von einem Endpunkt, der ohne Anmeldung antwortet, und schickt dann eine Datei hoch.

Die Bewertung: Wordfence, das die Nummer vergeben hat, bewertet mit CVSS 3.1 und 9,8 von 10. Die US-Datenbank NVD hat den Eintrag am 8. Oktober 2026 veröffentlicht und führt die Wertung von Wordfence mit 9,8 von 10 auf (eine eigene Analyse der NVD steht noch aus). Patchstack kommt auf 10,0. Die Anbieter bewerten unterschiedlich, beide Werte liegen in der Stufe „kritisch“.

Wer ist betroffen?

Alle Seiten, auf denen Bricksforge in der Version 3.1.8.9 oder älter installiert ist. Wer das Plugin nicht nutzt, ist nicht betroffen. Seiten mit 4.0.0 oder 3.1.8.10 sind von dieser Nummer nicht mehr erfasst. Laut Changelog schließt 4.0.1 aber eine Lücke im Datei-Upload der Pro Forms, die jede Seite mit aktivem Pro Forms betrifft, deshalb empfehlen wir mindestens 4.0.1. Ist es installiert, gehört es aktualisiert oder entfernt.

Wie ist der Stand der Updates?

Laut Patchstack ist die Lücke in Version 3.1.8.10 behoben. Der Changelog des Herstellers nennt 3.1.8.10 nur im Eintrag zu Version 4.0.1, ohne eigenen Eintrag und ohne Datum, und führt dort aus, dass die Lücke bereits in 3.1.8.10 und im 4er-Zweig mit Version 4.0.0 vom 17. September 2026 behoben wurde. Version 4.0.1 vom 8. Oktober 2026 schließt nach Angabe des Herstellers eine Sicherheitslücke im Datei-Upload der Pro Forms. Betroffen ist jede Seite mit aktivem Pro Forms, auch wenn die Formulare keine Upload-Felder haben, ein Update wird ausdrücklich empfohlen. Am 13. Oktober 2026 erschien 4.0.2, die unter anderem Bilder wieder annimmt, die die Prüfung aus 4.0.1 fälschlich abgelehnt hatte, und gespeicherte Zugangsdaten stärker filtert. Aktualisieren Sie deshalb auf 4.0.2 oder neuer, mindestens auf 4.0.1.

Dass die Lücke tatsächlich ausgenutzt wird, stammt aus einer einzigen Quelle: Patchstack selbst. Danach gingen die Angriffe an die Adressen /wp-json/bricksforge/v1/form_submit und admin-ajax.php. Eine unabhängige Bestätigung haben wir nicht gefunden. Der SSVC-Eintrag der US-Behörde CISA in der NVD führt die Ausnutzung (Stand 8. Oktober, bei unserer Prüfung am 25. Oktober 2026 unverändert) mit „none“. Das widerspricht der Patchstack-Meldung nicht zwingend, die Einstufungen stammen aus unterschiedlichen Quellen und Zeitpunkten.

Was Sie tun

1. Prüfen Sie im WordPress-Backend unter „Plugins“, ob Bricksforge installiert ist und in welcher Version.

1. Aktualisieren Sie auf Version 4.0.2 oder neuer, mindestens auf 4.0.1. Vorher eine Sicherung ziehen, nachher die Seite testen, denn der Sprung von 3.x auf 4.x ist ein Hauptversionswechsel. (Sicherung und Test: eigene Einschätzung.)
2. Lassen Sie Anfragen an /wp-json/bricksforge/v1/form_submit und admin-ajax.php im Zugriffsprotokoll prüfen, möglichst weiter zurück als bis zum 7. Oktober. Ob der Parameter temporaryFileUploads im Anfragekörper stand, zeigt ein übliches Zugriffsprotokoll meist nicht. Das klären Sie mit dem Hoster oder einer Firewall, die auch den Körper protokolliert. Kein Treffer im Protokoll ist keine Entwarnung. (Eigene Einschätzung, nicht Inhalt der Quellen.)
3. Lassen Sie mindestens das Verzeichnis /wp-content/uploads/bricksforge/tmp/ auf PHP-Dateien durchsehen, besser den ganzen Ordner wp-content/uploads (auch auf Endungen wie .php5 oder .phtml). Unerwartete PHP-Dateien sind ein Warnzeichen. Ein Fund wird nicht selbst gelöscht, sondern erst gesichert und dokumentiert. Können dadurch personenbezogene Daten betroffen sein, läuft die Meldefrist von 72 Stunden nach Art. 33 DSGVO. (Eigene Einschätzung.)
4. Laut Changelog zu 4.0.2 werden im Plugin gespeicherte Zugangsdaten nun stärker gefiltert. Wer dort API-Schlüssel hinterlegt hat, soll sie vorsorglich bei den Anbietern erneuern. Das gilt erst recht, wenn Sie nicht ausschließen können, dass die Lücke vor dem Update ausgenutzt wurde. Erst Seite bereinigen und aktualisieren, dann die Schlüssel erneuern, sonst landet der neue Schlüssel wieder in einer möglicherweise kompromittierten Umgebung. (Reihenfolge: eigene Einschätzung.)

2. nginx: Speicherfehler bei alias und rewrite (CVE-2026-15176)

Kurzer Einschub: Die Einstufung dieser Lücke fällt je nach Quelle sehr unterschiedlich aus. Am 14. Oktober 2026 hat das nginx-Projekt die Versionen 1.31.7 (Mainline) und 1.30.6 (Stable) veröffentlicht. 1.31.7 schließt insgesamt fünf Sicherheitsfehler. Einer davon ist CVE-2026-15176, ein Überlauf im Speicher eines Arbeitsprozesses.

Was ist passiert?

Der Fehler tritt auf, wenn die Konfiguration mehrere Dinge zugleich enthält: einen location-Block mit alias, ein rewrite, das die Adresse ändert, und die Variable $request_filename in einer der Anweisungen set oder return oder im Log-Format. Dann reicht eine präparierte Anfrage ohne Anmeldung. Die Folge ist in der Regel, dass der Arbeitsprozess abstürzt und neu startet (Dienst kurz gestört). Fremden Code auszuführen ist laut NVD nur möglich, wenn der Speicherschutz ASLR deaktiviert oder umgangen ist. Das ist nach unserer Einschätzung auf gängigen Servern eher die Ausnahme.

Die Einstufung ist uneinheitlich. Im NVD-Eintrag (Wertung durch den Hersteller F5) stehen CVSS 3.1 mit 8,1 und CVSS 4.0 mit 9,2. Das nginx-Projekt selbst stuft den Fehler als „Medium“ ein. Eine mögliche Erklärung sind unterschiedliche Maßstäbe.

Wer ist betroffen?

Betroffen sind laut nginx.org die Versionen 0.1.29 bis 1.31.6. Gefixt sind 1.31.7 und 1.30.6, in der Stable-Reihe sind also die Versionen bis 1.30.5 betroffen. Das gilt nur bei der Kombination aus der Konfiguration oben. Auch NGINX Plus ist laut NVD betroffen, die Fixstände dazu haben wir nicht geprüft, sie erfragen Sie beim Hersteller. Wir gehen davon aus, dass viele Installationen die Kombination nie enthalten. Wer nur Webspace mietet, kann die Konfiguration meist nicht selbst ändern, dann ist der Hoster am Zug. Wer einen eigenen Server oder einen Docker-Container mit nginx betreibt, sollte nachsehen.

Hinweis: Linux-Distributionen übernehmen Sicherheitskorrekturen oft in ältere Versionen, ohne die Nummer zu ändern. Dass bei Ihnen „1.24“ steht, heißt deshalb nicht automatisch „nicht gefixt“. Ob Ihr Paket den Fix enthält, steht im Sicherheitsverzeichnis der Distribution. Das haben wir nicht für einzelne Distributionen geprüft.

Was Sie tun

• Eigener Server: auf 1.31.7 oder 1.30.6 oder neuer aktualisieren. Wer nicht sofort kann, sucht in der Konfiguration nach der Kombination aus alias, rewrite und $request_filename, auch in eingebundenen Dateien (nginx -T zeigt die gesamte wirksame Konfiguration). Das ist eine Prüfung, kein Schutz: Workarounds nennt nginx.org nicht.
• Webspace beim Hoster: nachfragen, ob nginx dort eingesetzt wird und ob der Fix eingespielt ist.

3. BGH zur SCHUFA: Revisionen erfolgreich, Beweiserleichterung für Betroffene

Am 21. Oktober 2026 hat der Bundesgerichtshof in vier Verfahren (I ZR 227/25 bis I ZR 230/25) über Klagen von Privatpersonen gegen die SCHUFA entschieden. Es ging um Auskunft über die Berechnung der Scorewerte und um die Erstattung außergerichtlicher Rechtsanwaltskosten. Das betrifft Sie als Website-Betreiber, wenn Ihr Shop Bonitätsauskünfte einholt, etwa für den Kauf auf Rechnung. Die Landgerichte Chemnitz, Leipzig und Görlitz hatten die Auskunftsanträge abgewiesen. Das Oberlandesgericht Dresden hatte am 7. Oktober 2025 teilweise Auskunft und die Erstattung außergerichtlicher Kosten zugesprochen.

Der BGH hat den Revisionen der SCHUFA stattgegeben, die Berufungsurteile in diesem Punkt aufgehoben und die Sachen an das OLG Dresden zurückverwiesen. Einen Auskunftsanspruch aus Art. 15 Abs. 1 Buchst. h DSGVO (Information über die Logik hinter automatisierten Entscheidungen) gibt es danach nur, wenn alle Voraussetzungen von Art. 22 Abs. 1 DSGVO erfüllt sind. Das folgt der Linie des Europäischen Gerichtshofs, der in der Rechtssache C-634/21 (Urteil vom 7. Dezember 2023) die Berechnung eines Scorewerts unter Umständen als automatisierte Entscheidung ansieht.

Zwei Punkte aus der Pressemitteilung (Nr. 198/2026) sind für die Praxis wichtig:

• Ein Scorewert kann eine automatisierte Entscheidung sein, wenn die Entscheidung eines Dritten (unsere Beispiele: ein Vermieter, eine Bank oder ein Händler) maßgeblich davon abhängt. Ob die Betroffenen dadurch erheblich beeinträchtigt wurden, hat der BGH mangels Feststellungen nicht beurteilt.
• Die Betroffenen müssen darlegen und beweisen, dass die Entscheidung des Dritten maßgeblich auf dem Score beruht. Dafür gibt es nach der Pressemitteilung erhebliche Erleichterungen. Es genügt vorzutragen, dass der Score übermittelt wurde und danach eine nachteilige Entscheidung folgte. Dann besteht eine tatsächliche Vermutung dafür, dass sie auf dem Score beruhte.

Wie sich das für Betroffene auswirkt, entscheidet nun das OLG Dresden. Zu den vier Entscheidungen liegen inzwischen Volltexte als PDF vor (verlinkt auf der Seite der Pressemitteilung). Die Pressemitteilung nennt keine Leitsätze. Wir haben die Volltexte bisher nicht ausgewertet und stützen uns auf die Pressemitteilung.

Was das für Betreiber heißt

Der BGH hat über den Auskunftsanspruch gegen die SCHUFA entschieden, nicht über Pflichten von Unternehmen, die Scorewerte einholen. Folgendes ist unsere Einschätzung und nicht Inhalt der Entscheidung: Für solche Unternehmen kann die Frage wichtig sein, ob eine Entscheidung ausschließlich automatisiert und maßgeblich auf dem Score beruht, denn nur dann greift Art. 22 Abs. 1 DSGVO. Entscheidet bei Ihnen am Ende ein Mensch, ist das möglicherweise anders zu beurteilen. Das ist keine Rechtsberatung. Lassen Sie Ihre Praxis von einer Fachperson für Datenschutzrecht prüfen.

Wen Sie fragen

• Bricksforge und andere WordPress-Plugins: Ihr Webdesigner oder die Agentur, die die Seite pflegt.
• nginx: Ihr Hoster oder die Person, die den Server betreut.
• Scoring und DSGVO: Ihre Datenschutzbeauftragte oder Ihr Anwalt.

Quellen

• NVD, CVE-2026-85097
• NVD, CVE-2026-15176
• nginx.org, Security Advisories
• Bricksforge, Versions-Changelog
• Patchstack, Beitrag zu Bricksforge
• Bundesgerichtshof, Pressemitteilung Nr. 198/2026 vom 21.10.2026