DORA-Compliance und NIS2-Richtlinie: Status Page als rechtsverbindlicher Audit-Nachweis

Am 15. Januar 2026 veröffentlichte die ACPR ihre Bilanz nach acht Monaten DORA-Anwendung mit der Schlussfolgerung, dass die Meldefristen von vier Stunden von französischen Finanzunternehmen "noch selten eingehalten" werden. In Frankfurt und Luxemburg stellen BaFin und CSSF einen gleichwertigen Befund fest. Bei der NIS2-Richtlinie haben 22 der 27 Mitgliedstaaten die Vorgaben zum 1. April 2026 umgesetzt: Deutschland hat das NIS2UmsuCG am 6. Dezember 2025 in Kraft gesetzt, Italien wendet das Gesetzesdekret 138/2024 seit dem 16. Oktober 2024 an, und Frankreich erwartet die Verkündung des am 26. Februar 2025 verabschiedeten Resilienzgesetzes.

In dieser Landschaft taucht bei jedem Audit eine operative Frage auf: Wie weisen Sie nach, dass eine Vorfallmeldung tatsächlich fristgerecht abgegeben wurde? Interne E-Mails gehen verloren, ServiceNow-Tickets werden geschlossen, Screenshots können angefochten werden. Was bleibt, ist ein öffentliches, zeitgestempeltes Artefakt, das jederzeit von außen zugänglich ist: die Status Page. Für die meisten europäischen B2B-SaaS-Anbieter bleibt diese Seite jedoch ein Marketing-Kommunikationsinstrument, kein Audit-Liefergegenstand. Die regulatorische Wende, die sich zwischen 2024 und 2026 vollzogen hat, ändert diesen Status radikal.

Dieser Artikel richtet sich an CTOs, CISOs, Heads of SRE und Datenschutzbeauftragte, die die DORA-Compliance und NIS2-Compliance eines europäischen B2B-SaaS steuern müssen. Er gliedert sich in drei Teile: ein pädagogischer Teil zu den Regulierungen, ein operativer Teil zur Anatomie einer konformen Status Page und ein Checklisten-Teil zur Vorbereitung auf eine Kontrolle. Sie gehen mit einer einheitlichen Fristenübersicht, einer JSON-Exportvorlage gemäß den DORA-RTS/ITS-Templates, einem Sieben-Schritte-Framework und einer Checkliste mit 25 Punkten weg.

Die Ausgangsfeststellung ist einfach: Die öffentliche Status Page vereint ohne zusätzlichen technischen Aufwand die drei Eigenschaften eines rechtsverbindlichen Nachweises. Sie muss nur mit dieser Absicht konzipiert sein. Die folgenden Abschnitte zeigen, wie sich ein operatives Werkzeug in einen Audit-Liefergegenstand verwandelt, gestützt auf offizielle Texte (EUR-Lex, RTS/ITS der ESAs, ANSSI, ACPR, BaFin, CSSF, Banca d'Italia) und die jüngsten öffentlichen Erfahrungsberichte.

Warum die Status Page 2026 in den EU-Auditbereich fällt

Die öffentliche Status Page wurde lange als Schaufenster wahrgenommen. Sie diente dazu, Kunden während eines Vorfalls zu beruhigen, eine Überlastung des Supports zu vermeiden, ein Wartungsfenster anzukündigen. 2026 ändert sich ihre Funktion. Die europäischen Regulierungsbehörden, allen voran die ACPR, betrachten eine zeitgestempelte öffentliche Vorfallkommunikation nun als integralen Bestandteil der ICT-Compliance-Akte, ohne sie in den Texten formal als "Nachweis" zu bezeichnen, aber sie wird bei dokumentarischen Kontrollen systematisch eingefordert.

Der regulatorische Wandel von der Höflichkeitsseite zum Audit-Artefakt

Drei Elemente erklären diese Verschiebung. Erstens das Ende der DORA-Übergangsphase. Die EU-Verordnung 2022/2554 wurde am 17. Januar 2025 anwendbar. Die ersten acht Monate dienten als Beobachtungszeitraum, in dem die Aufsichtsbehörden keine massiven Sanktionen verhängt haben. Ab dem ersten Quartal 2026 haben die ACPR, die BaFin, die luxemburgische Zentralbank und die Banca d'Italia bestätigt, in den Modus der aktiven Durchsetzung übergegangen zu sein. Zweitens wird die NIS2-Umsetzung allgemein. Zum 1. April 2026 haben 22 Mitgliedstaaten von 27 einen nationalen Text angenommen, was die Mehrheit der europäischen Wirtschaftsakteure abdeckt. Schließlich hat die ENISA im Oktober 2025 ihre Threat Landscape veröffentlicht, die eine Intensivierung der ICT-Vorfälle dokumentiert, was die Regulierungsbehörden dazu drängt, ihre Transparenzanforderungen zu verschärfen.

Drei zusammenlaufende Kräfte: Finanzregulierung, Netzsicherheit und Lieferkette

DORA gilt für Finanzunternehmen und ihre kritischen ICT-Dienstleister. NIS2 deckt 18 Sektoren ab (Energie, Gesundheit, Verkehr, Digital, Ernährung, öffentliche Infrastruktur usw.). Für einen europäischen B2B-SaaS-Anbieter koexistieren zwei Szenarien. Erstes Szenario: Der Anbieter ist selbst wesentlicher oder wichtiger Betreiber im Sinne von NIS2 (zum Beispiel ein Cloud-Hoster, ein Managed-Service-Provider, ein Anbieter qualifizierter elektronischer Signaturen). Er unterliegt dann direkt NIS2. Zweites Szenario: Der Anbieter beliefert eine Bank, einen Versicherer, eine Fintech, die DORA unterliegt. Er wird dann ICT-Dienstleister im Sinne von DORA Artikel 28, und sein Kunde muss vertraglich Pflichten zu Resilienz, Auditfähigkeit und Reporting festlegen. In beiden Fällen verlässt die Status Page den Marketingbereich und tritt in den vertraglichen und regulatorischen Bereich ein.

Auch die Lieferkette kommt ins Spiel. NIS2 Artikel 21 Absatz 2 fordert ein ausdrückliches Management der Risiken im Zusammenhang mit Lieferanten und der Lieferkette. Ein nicht gemeldeter Ausfall eines Unterauftragnehmers kann dem Hauptbetreiber zugerechnet werden. Die Status Page dient dann als vertraglicher Benachrichtigungsmechanismus zwischen den Gliedern der Kette.

Was die Aufseher in der Praxis sagen

Die öffentlichen Positionen laufen zusammen. Die ACPR betont über ihr OneGate-Portal und ihre DORA-FAQ die Nachvollziehbarkeit der Meldungen. Die deutsche BaFin verlangt in ihrem offiziellen Fachartikel zum DORA-Reporting die Übereinstimmung zwischen öffentlicher Kommunikation und regulatorischem Bericht. Die luxemburgische CSSF hat im Mai 2025 die Rundschreiben 25/892 und 25/893 veröffentlicht, die Klassifizierung und Reporting im Detail regeln. Die ANSSI in Frankreich betreibt das Portal MonEspaceNIS2, das die NIS2-Meldungen für wesentliche und wichtige Betreiber bündelt. Die Botschaft ist einheitlich: Eine öffentliche zeitgestempelte Spur ist erforderlich, und sie ist nicht optional. Sie ist eine strukturelle Ergänzung zum vertraulichen regulatorischen Bericht.

Für die operativen Teams bedeutet dies, die Konzeption der Status Page ab der Architekturphase als Audit-Liefergegenstand zu denken und nicht als reaktiven Kommunikationskanal. Genau das ermöglicht das Status-Page-Tool von CaptainDNS, das nativ ein rechtsverbindliches Artefakt produziert.

Zum Mitnehmen: 2026 kann Ihre Status Page von Ihrer Regulierungsbehörde als rechtsverbindlicher Nachweis herangezogen werden. Sie von Anfang an so zu konzipieren, vermeidet eine teure Neugestaltung im Audit-Moment.

DORA Artikel 19 im Detail: 4 Stunden, 72 Stunden, 1 Monat

Die EU-Verordnung 2022/2554, kurz DORA-Verordnung, gilt für europäische Finanzunternehmen und ihre kritischen ICT-Dienstleister. Ihr Kapitel III, insbesondere Artikel 19, regelt die Meldung schwerwiegender ICT-Vorfälle. Für einen B2B-SaaS-Anbieter, der eine Bank oder einen Versicherer beliefert, ist das Verständnis dieses Artikels keine juristische Übung: Er bestimmt die operative Orchestrierung eines Vorfalls und damit die DORA-Compliance des Unternehmens.

Anwendungsbereich: Finanzunternehmen und kritische ICT-Dienstleister

Artikel 2 der DORA listet 20 Kategorien von Finanzunternehmen auf: Kreditinstitute, Zahlungsinstitute, Kontoinformationsdienstleister, Schwarmfinanzierungsdienstleister, Wertpapierfirmen, Handelsplätze, Zentralverwahrer, zentrale Gegenparteien, Verwalter von Organismen für gemeinsame Anlagen, Versicherungs- und Rückversicherungsunternehmen, Versicherungsvermittler, Einrichtungen der betrieblichen Altersversorgung, Ratingagenturen, Administratoren von Referenzwerten, Anbieter von Krypto-Dienstleistungen, Verbriefungsregister, Fonds usw. Alle diese Unternehmen unterliegen direkt DORA.

Kapitel V (Artikel 28 bis 44) erstreckt die DORA-Pflichten vertraglich auf ICT-Dienstleister. Wenn ein Dienstleister eine kritische oder wichtige Funktion stützt (CIFA, Critical or Important Function Arrangement), sind die Vertragsklauseln verpflichtend. Wenn ein Dienstleister die von den ESAs (European Supervisory Authorities: EBA, EIOPA, ESMA) festgelegten Schwellen überschreitet, kann er als "kritischer Drittdienstleister" (CTPP, Critical Third-Party Provider) eingestuft und unter direkte Aufsicht gestellt werden.

Der zeitliche Dreiklang: 4 Stunden, 72 Stunden, 1 Monat

Artikel 19 schreibt drei Fristen für die Vorfallmeldung eines als schwerwiegend eingestuften ICT-Vorfalls vor:

• Erstmeldung: 4 Stunden nach der Klassifizierung des Vorfalls als schwerwiegend, mit einer Höchstgrenze von 24 Stunden nach Entdeckung.
• Zwischenbericht: 72 Stunden nach Entdeckung.
• Abschlussbericht: 1 Monat nach Entdeckung.

Die genauen Fristen und Pflichtfelder finden sich im Abschlussdokument der technischen Standards JC 2024-33, veröffentlicht am 17. Juli 2024 durch die drei europäischen Behörden EBA, EIOPA und ESMA. Es handelt sich um Regulatory Technical Standards (RTS) und Implementing Technical Standards (ITS), die den erwarteten Inhalt jedes Berichts präzisieren. Die Erstmeldung muss neun Felder enthalten: Identität des Unternehmens, Zeitstempel der Entdeckung, Zeitstempel der Klassifizierung, vorläufige Beschreibung, aktivierte Klassifizierungskriterien (Artikel 17 und 18 DORA), geschätzte Auswirkung, sofort ergriffene Maßnahmen, geplante nächste Schritte, zuständiger Ansprechpartner.

Die Klassifizierung stützt sich auf die Kriterien von Artikel 18 DORA: Wesentlichkeit der Auswirkung (Anzahl betroffener Kunden, Dauer, Geografie, Datenverlust, Kritikalität des unterbrochenen Dienstes, wirtschaftliche Schwere). Die Frist von 4 Stunden beginnt in dem Moment, in dem das Unternehmen formell feststellt, dass der Vorfall "schwerwiegend" ist, nicht bei der Entdeckung. Diese Nuance verändert alles in der Praxis: Die Entscheidungskette muss dokumentiert werden (wer klassifiziert hat, nach welchen Kriterien, zu welcher Uhrzeit UTC). Andernfalls kann die Regulierungsbehörde die Frist umqualifizieren und auf eine Überschreitung schließen.

Wem in der Praxis je nach Gerichtsbarkeit melden

Die Unternehmen melden ihre nationale zuständige Behörde:

• Frankreich: ACPR über das OneGate-Portal (JSON-Format, keine elektronische Signatur erforderlich). Bei Nichtverfügbarkeit von OneGate (Mitternacht bis 4 Uhr, Sonntage) Versand per E-Mail an 2760-INCIDENTS-DORA-UT@acpr.banque-france.fr.
• Deutschland: BaFin über das MVP-Portal (Meldungs- und Veröffentlichungsplattform), im XBRL-Format.
• Luxemburg: CSSF über das eDesk-Portal (Rundschreiben 25/893), begleitet von einer standardisierten Klassifizierungsmatrix.
• Italien: Banca d'Italia über ihr eigenes Portal für DORA-Vorfälle, im Format CSV oder XML.

Bei eingestuften CTPP erfolgt die Aufsicht gemeinsam durch ESA und nationale Regulierungsbehörde, mit einem Joint Examination Team (JET), das vor Ort prüfen kann. Ein B2B-SaaS-Anbieter, der mehrere europäische Banken bedient, muss möglicherweise mehrere Behörden parallel für denselben Vorfall benachrichtigen, daher das kritische Interesse an einem Pivotformat wie JSON, das aus seiner Status Page abgeleitet wird, was an die Logik des zuvor dokumentierten resilienten DNS-Monitorings anknüpft.

Sanktionen Artikel 50 bis 58

DORA sieht schwere administrative Sanktionen vor. Für Finanzunternehmen: bis zu 2 % des jährlichen weltweiten Umsatzes oder 10 Millionen Euro (der höhere Betrag), mit Einzelstrafen bis zu 1 Million Euro für die Verantwortlichen. Für CTPP: bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes, höchstens sechs Monate. Über die Bußgelder hinaus werden die Sanktionen veröffentlicht (Artikel 54), was einen erheblichen Reputationsschaden hinzufügt. Die ACPR-Bilanz vom Januar 2026 stellt klar, dass die aktive Durchsetzungsphase im ersten Quartal 2026 begonnen hat, jedoch noch ohne öffentlich genannten Sanktionsfall, ein Zeichen dafür, dass die Regulierungsbehörden ihre Akten im Stillen vorbereiten.

Zum Mitnehmen: 4 Stunden nach der Klassifizierung müssen Sie 9 Pflichtfelder zur Übermittlung bereit haben. Wenn Ihre Status Page diese Felder bereits exportiert, haben Sie den Großteil des Rennens gewonnen.

NIS2 Artikel 23 und die Kaskade 24h, 72h, 1 Monat

Die EU-Richtlinie 2022/2555, kurz NIS2-Richtlinie, ergänzt die DORA-Verordnung, indem sie alle wesentlichen und wichtigen Sektoren außerhalb des reinen Finanzwesens abdeckt. Ihr Artikel 23 legt eine eigene Meldekaskade fest, mit breiterem Anwendungsbereich und einem anderen Ausgangspunkt. Für ein europäisches B2B-SaaS gilt die NIS2-Richtlinie oft parallel zu DORA, und beide zu orchestrieren ist die zentrale operative Herausforderung von 2026.

Erweiterter Anwendungsbereich: 18 Sektoren und Lieferkette

Die Anhänge I und II von NIS2 listen 18 Sektoren auf. Anhang I unterscheidet hochkritische Sektoren (Energie, Verkehr, Bankwesen, Finanzmarktinfrastruktur, Gesundheit, Trinkwasser, Abwasser, digitale Infrastruktur, Verwaltung von B2B-IT-Diensten, öffentliche Verwaltung, Raumfahrt), Anhang II die weiteren kritischen Sektoren (Post- und Kurierdienste, Abfallwirtschaft, Fertigung, Herstellung und Vertrieb chemischer Erzeugnisse, Herstellung und Verarbeitung von Lebensmitteln, Anbieter digitaler Dienste, Forschung). Die Größe der Einrichtung (≥ 50 Mitarbeitende und Umsatz ≥ 10 Millionen Euro für den Status "wichtig", höhere Schwellen für "wesentlich") bestimmt, ob sie unter NIS2 fällt.

NIS2 Artikel 21 Absatz 2 Buchstabe d schreibt das Management der Sicherheit der Lieferkette vor, einschließlich der Sicherheitsaspekte der direkten Beziehungen zwischen Lieferanten und Dienstleistern. Eine von einem Lieferanten schlecht betriebene Status Page kann die Verantwortung des wesentlichen oder wichtigen Betreibers als Kunde nach sich ziehen.

Frühwarnung 24h, Meldung 72h, Abschlussbericht 1 Monat

Artikel 23 organisiert die Vorfallmeldung in drei Phasen:

• Frühwarnung innerhalb von 24 Stunden nach Kenntnis eines erheblichen Vorfalls.
• Vorfallmeldung innerhalb von 72 Stunden nach Kenntnis, einschließlich einer ersten Bewertung, Kompromittierungsindikatoren und einer Schweregradbeschreibung.
• Abschlussbericht innerhalb eines Monats nach der Meldung, mit detaillierter Ursachenanalyse.

Der kritische Ausgangspunkt: "Kenntnis" (awareness), nicht technische "Entdeckung" noch formale "Klassifizierung". Sobald ein internes Team Kenntnis von einem erheblichen Vorfall hat, läuft der Zähler. Ein Vorfall ist "erheblich", wenn er eine schwerwiegende Störung der Dienste, erhebliche finanzielle Verluste verursacht hat oder voraussichtlich verursachen wird, oder wenn er Dritte durch erhebliche materielle oder immaterielle Schäden betroffen hat oder voraussichtlich betreffen wird.

Nationale Umsetzungen im Frühjahr 2026

Der Stand am 1. April 2026:

• Frankreich: Resilienzgesetz am 26. Februar 2025 von der Nationalversammlung verabschiedet, Verkündung im ersten Halbjahr 2026 erwartet. Die ANSSI betreibt das Portal MonEspaceNIS2 und koordiniert das CERT-FR als nationales CSIRT. Compliance-Zeitraum: 3 Jahre nach Verkündung. Für die Entwicklung der Historisierung von Beobachtungen siehe die DNS-Rückverfolgbarkeit, die CaptainDNS im November 2025 veröffentlicht hat.
• Deutschland: NIS2UmsuCG am 5. Dezember 2025 verkündet, am 6. Dezember 2025 in Kraft getreten. Das BSI hat die operativen Details veröffentlicht: rund 30 000 betroffene Einrichtungen, Registrierungspflicht innerhalb von 3 Monaten, Sanktionen auf "Board-Accountability"-Niveau.
• Italien: Gesetzesdekret 138/2024 veröffentlicht am 4. September 2024, in Kraft seit dem 16. Oktober 2024. Die ACN (Agenzia per la Cybersicurezza Nazionale) betreibt das Meldeportal, ergänzt durch das DPCM 221 vom 9. Dezember 2024.
• Luxemburg, Niederlande, Belgien, Spanien, Portugal, Polen, nordische Länder, baltische Staaten: effektive oder unmittelbar bevorstehende Umsetzung (parlamentarisches Verfahren läuft).
• Fünf Staaten in Verzug zum 1. April 2026: Risiko von Vertragsverletzungsverfahren nach Artikel 258 AEUV.

Unterschied zwischen der Richtlinie und der Datenschutzverordnung

NIS2 und DSGVO überschneiden sich teilweise. Ein Vorfall kann sowohl ein "erheblicher Vorfall" nach NIS2 als auch eine "Verletzung des Schutzes personenbezogener Daten" nach DSGVO sein. Die Meldungen erfolgen dann parallel: nationales CSIRT für NIS2, Datenschutzbehörde (CNIL in Frankreich) für DSGVO. Die Frist nach DSGVO Artikel 33 beträgt 72 Stunden "nachdem ihm die Verletzung bekannt wurde". NIS2 fügt eine Frühwarnung nach 24 Stunden hinzu, was eine zusätzliche Pflicht schafft. Für einen Anbieter, der einen SaaS-Speicherdienst betreibt, der von einem Eindringen mit personenbezogenen Daten betroffen ist, können drei Meldekanäle ausgelöst werden (NIS2 + DSGVO + DORA, wenn der Kunde im Finanzbereich tätig ist), daher die Bedeutung einer einzigen zeitgestempelten Quelle, die genau die öffentliche Status Page ist.

Zum Mitnehmen: Unter NIS2 startet der 24h-Zähler ab interner Kenntnis, nicht nach formaler Klassifizierung. Bereiten Sie Ihre Teams darauf vor, in den ersten 4 Stunden eine öffentliche Nachricht zu veröffentlichen, damit Sie nicht alles in der 23. Stunde erledigen müssen.

Einheitliche Karte der drei europäischen Regulierungen

Die operative Komplexität entsteht aus der Überschneidung der drei Regulierungen. Für einen Anbieter, der gleichzeitig Finanzunternehmen und wesentliche NIS2-Betreiber bedient, kann ein und derselbe Vorfall drei Meldekanäle auslösen, mit unterschiedlichen Fristen und Adressaten. Die Status Page spielt dann die Rolle des zeitgestempelten gemeinsamen Nenners.

Kreuztabelle der Fristen

Auslöser: Wer beginnt wann

Drei verschiedene Ausgangspunkte existieren nebeneinander. DORA geht von der Klassifizierung als schwerwiegender Vorfall aus (formell, dokumentiert, datiert). NIS2 geht von der internen Kenntnis eines erheblichen Vorfalls aus. DSGVO geht von der Kenntnisnahme einer Verletzung aus. Die kürzeste operative Frist beträgt 4 Stunden (DORA), startet aber spät (nach Klassifizierung). Die früheste ist die NIS2-Frühwarnung nach 24 Stunden, die mehrere Stunden vor der DORA-Klassifizierung beginnen kann.

Für die Ops-Teams bedeutet das, dass ein und derselbe Vorfall gleichzeitig im NIS2-Vorlauf und in DORA-Verzug sein kann, woraus sich die Notwendigkeit eines gemeinsamen Protokolls und eines schnellen Klassifizierungsmechanismus ergibt. Auf Aufsichtsseite liefert das Multi-Region-HTTP-Uptime-Monitoring den objektiven technischen Zeitstempel, auf den sich die Klassifizierung stützt.

Wem melden: das vollständige Mapping nach Gerichtsbarkeit

Für B2B-SaaS-Anbieter, die in mehreren europäischen Ländern tätig sind, hier die Empfängermatrix:

• Frankreich: ACPR (DORA), CERT-FR über MonEspaceNIS2 (NIS2), CNIL (DSGVO).
• Deutschland: BaFin (DORA), BSI (NIS2), BfDI oder Landesbehörde (DSGVO).
• Italien: Banca d'Italia (DORA, über eigenes Portal), ACN (NIS2), Garante (DSGVO).
• Luxemburg: CSSF (DORA über eDesk), GovCERT-LU (NIS2), CNPD (DSGVO).
• Spanien: Banco de España und CNMV (DORA), INCIBE-CERT (NIS2), AEPD (DSGVO).
• Niederlande: DNB und AFM (DORA), NCSC-NL (NIS2), AP (DSGVO).

Die Idee eines einheitlichen europäischen Eintrittspunkts schreitet voran: Das Digital-Omnibus-Paket, vorgestellt von Bird & Bird sieht eine Harmonisierung 18 Monate nach Annahme vor. 2026 ist diese Harmonisierung noch nicht wirksam: Die Mehrfachmeldungen müssen daher manuell gesteuert werden, und die Status Page bleibt der einzige kohärente Liefergegenstand für alle Gerichtsbarkeiten.

Erstellen Sie ab heute eine DORA- und NIS2-konforme Status Page

Zum Mitnehmen: Wenn 3 Regulierungen greifen, gewinnt das kürzeste Zeitfenster, oft die 4 Stunden DORA. Die öffentliche zeitgestempelte Status Page bedient alle drei parallel.

Die Status Page als rechtsverbindlicher Nachweis und warum Prüfer sie verlangen

Ein rechtsverbindlicher Nachweis kombiniert juristisch drei Eigenschaften: zuverlässiger Zeitstempel, Unveränderlichkeit, überprüfbare öffentliche Zugänglichkeit. Kein anderes technisches Artefakt eines B2B-SaaS hakt alle drei Kästchen gleichzeitig ab. Interne Logs sind nicht öffentlich zugänglich. Post-Mortem-PDFs können nachträglich bearbeitet werden. Kunden-E-Mails sind nicht kryptografisch zeitgestempelt. Die öffentliche Status Page erfüllt die drei Bedingungen, sofern sie in diesem Geist konzipiert wurde.

Drei nachweiskräftige Eigenschaften: signierter Zeitstempel, unveränderliche Archivierung, öffentliches Publikum

Der Zeitstempel muss RFC 3339 im UTC-Format folgen. Dies ist der von allen europäischen Gerichtsbarkeiten für elektronische Vorgänge anerkannte Standard (eIDAS, eIDAS 2). Lokale Zeitstempel (CET, CEST, BST) sind nicht akzeptabel, da sie um die Zeitumstellung herum mehrdeutig sind. Ein qualifizierter Zeitstempel im Sinne von RFC 3161, signiert durch einen qualifizierten Trust Service Provider, ist juristisch noch stärker, bleibt aber in der Praxis optional, solange der UTC-Zeitstempel kohärent und überprüfbar ist.

Die Unveränderlichkeit beruht auf dem Audit Trail: Jede Aktualisierung eines Vorfalls muss versioniert werden, niemals überschrieben. Wenn Sie eine Nachricht um 14:17 UTC nach einer Veröffentlichung um 14:02 UTC korrigieren, müssen beide Versionen zugänglich bleiben, mit dem Hinweis "bearbeitet um 14:17". Diese redaktionelle Disziplin ähnelt der Praxis der Online-Medien bei sachlichen Korrekturen.

Die öffentliche Zugänglichkeit unterscheidet die Status Page von einem internen Log. Die Seite muss ohne Authentifizierung von jedem Punkt des Internets aus konsultierbar sein. Das erfordert eine Hosting-Infrastruktur, die von der Hauptanwendung getrennt ist: Wenn Ihre Anwendung ausfällt, muss Ihre Status Page weiterhin laufen. Es ist eine Architekturanforderung, die sich mit aktivem DNSSEC auf der Status-Domain und striktem HTTPS verstärkt.

Der Cloudflare-R2-Fall vom 21. März 2025 als Referenzmodell

Cloudflare hat einen Vorfall an seinem R2-Dienst am 21. März 2025 öffentlich dokumentiert. Das Unternehmen veröffentlichte drei Tage nach dem Vorfall ein detailliertes Post-Mortem. Der Ablauf ist beispielhaft: Ankündigung auf der Status Page um 14:04 UTC (kurz nach Beginn der Beeinträchtigung), Aktualisierungen alle 15 bis 30 Minuten, Identifizierung der Ursache (Storage-Konfigurationsproblem), Behebung um 15:11 UTC bekanntgegeben, vollständiges Post-Mortem am 24. März mit detaillierter Timeline, Root Cause, nächste Korrekturmaßnahmen. Die Status Page dient hier als zeitlicher Pivot: Sie zeitstempelt die operativen Verpflichtungen, und das spätere Post-Mortem bezieht sich ausdrücklich auf sie.

Für einen europäischen B2B-SaaS-Anbieter ist dieses Modell unmittelbar übertragbar. Es erfordert kein exotisches Tooling: Es erfordert redaktionelle Disziplin und ein strukturiertes Exportformat.

Wenn der Status-Page-Anbieter selbst ausfällt

OneUptime hat einen aufschlussreichen Fall dokumentiert: Zwischen dem 2. und 23. Februar 2026 blieb das System-Metrics-Modul von Atlassian Statuspage 21 aufeinanderfolgende Tage lang nicht verfügbar. Die von OneUptime am 25. Februar 2026 veröffentlichte Analyse unterstreicht das Paradoxon: Ein Status-Page-Anbieter, der die SLA seiner eigenen Komponenten nicht halten kann, kann nicht als Audit-Artefakt für seine Kunden dienen. Das auf einen einzigen Anbieter konzentrierte Risiko wird zu einer direkten vertraglichen Schwachstelle.

Acht-Monats-Bilanz der ACPR und regulatorische Spannung gegenüber operativer Realität

Die ACPR-Bilanz vom 15. Januar 2026 weist darauf hin, dass die Fristen von 4 Stunden "noch selten eingehalten" werden. Diese Feststellung ist kein Freibrief: Sie geht mit der Ankündigung des Übergangs in den aktiven Durchsetzungsmodus einher. Die implizite Botschaft: 2026 markiert den Übergang zwischen Toleranz und Sanktion. Für Unternehmen, die noch keine konforme Status Page haben, ist das Sanktionsrisiko konkret. Was die Grundsätze der TLS-Sicherheit und Vertrauenskette betrifft, so deckt sich die Strenge der Zeitstempel und Signaturen mit denselben kryptografischen Anforderungen.

Zum Mitnehmen: Nur eine öffentliche zeitgestempelte Status Page vereint die drei Eigenschaften eines rechtsverbindlichen Nachweises. Sie als solche zu konzipieren, ist heute eine Investition mit sehr hoher regulatorischer Rendite.

Anatomie einer DORA-konformen Status Page: zehn Pflicht-Attribute für die DORA-Compliance

Eine als Audit-Liefergegenstand konzipierte Status Page muss zehn technische Kästchen abhaken. Die untenstehende Liste fasst die gekreuzten Erwartungen der europäischen Aufseher (ACPR, BaFin, CSSF, Banca d'Italia, ACN) und die operativen Best Practices der reifsten Anbieter zusammen.

Attribut 1, klare Identifikation der Komponenten und Dienste. Die Granularität muss bis auf die Ebene Produkt/Region heruntergehen. Ein Label "API" reicht nicht aus; es braucht "API REST v3, Region EU-West", "API REST v3, Region US-East", "SFTP B2B", "Webhooks". Das erlaubt, einen Teil-Vorfall zu deklarieren, ohne ungerechtfertigte Panik im gesamten Dienst auszulösen.

Attribut 2, Zeitstempel nach RFC 3339 UTC überall. Keine Datumsangaben in Lokalzeit. Keine Datumsangaben ohne Zeitzone. Die Umwandlung in Lokalzeit erfolgt browserseitig. Die UTC-Konsistenz gewährleistet die juristische Verbindlichkeit.

Attribut 3, kodierter und stabiler Schweregrad. Mindestens vier Stufen: operational, degraded performance, partial outage, major outage. Die Bezeichnungen müssen über die Zeit stabil bleiben (keine Umbenennung durch das Marketing). Der zugrundeliegende Zahlencode (zum Beispiel 0/1/2/3) muss im JSON-Strom übertragen werden, um die Automatisierung zu ermöglichen.

Attribut 4, expliziter Link zum laufenden Vorfall und stabile Kennung. Jeder Vorfall muss eine eindeutige Kennung haben, die nach Behebung bestehen bleibt und über eine kanonische URL zugänglich ist. Regulierungsbehörden fragen oft: "Geben Sie uns die genaue URL der öffentlichen Kommunikation zu Vorfall XYZ."

Attribut 5, sichtbarer Audit Trail. Jede Aktualisierung muss versioniert und datiert sein und den Autor (mindestens nach Rolle oder Kennung) identifizieren. Spätere Bearbeitungen müssen mit dem Hinweis "bearbeitet am …" sichtbar bleiben.

Attribut 6, strukturierter Export in JSON, RSS, Atom, ICS. JSON dient der automatisierten Extraktion in Regulierungsberichte. RSS und Atom dienen dem Kundenabonnement (und der Erfassung durch Tools wie StatusGator oder IsDown). ICS dient der geplanten Wartung für die Kundenteams.

Attribut 7, Infrastruktur-Unabhängigkeit. Die Status Page muss außerhalb des überwachten Anwendungsperimeters gehostet werden. Wenn Ihre Anwendung auf AWS Frankfurt läuft, darf Ihre Status Page nicht dort sein. Diese Unabhängigkeit ist nicht verhandelbar: Sie unterscheidet ein bei einem großen Ausfall nützliches Lieferprodukt von einem Placebo.

Attribut 8, Versionierung der Aktualisierungen. Direkte Folge von Attribut 5: Ein unveränderliches Speichersystem vom Typ Write-Once-Read-Many (WORM) oder ein signiertes Register garantiert, dass keine rückwirkende Umschreibung technisch möglich ist.

Attribut 9, kanalübergreifende Benachrichtigungen. E-Mail, Webhook, RSS und optional SMS. Regulierungsbehörden bitten oft darum, während Kontrollen abonniert zu werden: Einen Abonnementkanal abzulehnen ist nicht denkbar.

Attribut 10, langfristige Aufbewahrung. Die Archivierung der Snapshots (JSON und HTML) muss mindestens 6 Jahre abdecken, um sich an DORA Artikel 5 bis 14 (ICT-Risikorahmen, Vorfallregister) und die nationalen NIS2-Umsetzungen anzulehnen. Frankreich schreibt 6 Jahre im verabschiedeten Resilienzgesetz vor. Die italienische und deutsche Umsetzung sehen mindestens 5 Jahre vor.

Exkurs zum ICT-Drittpartei-Risiko und den Vertragsklauseln nach DORA Artikel 28 und 30

Kapitel V der DORA regelt die Beziehungen zwischen Finanzunternehmen und ICT-Dienstleistern. Artikel 28 schreibt das Führen eines Registers der ICT-Vertragsvereinbarungen, die Klassifizierung der kritischen oder wichtigen Funktionen (CIFA) und die Konzentration des Drittpartei-Risikos vor. Artikel 30 listet die vertraglichen Mindestklauseln auf: klare Beschreibung des Dienstes, messbare Service Level, Datenlokalisierung, Informationssicherheit, Zugänglichkeit und Rückgabe der Daten, Auditrecht, Exit-Strategie.

Für einen europäischen B2B-SaaS-Anbieter oder -Kunden diktieren diese beiden Artikel eine objektive Fragestellung bei der Auswahl eines Status-Page-Anbieters:

• Datenlokalisierung. Ist das Hosting der Status-Page-Daten (Vorfälle, Kommentare, Metadaten) vertraglich in Europa garantiert? Sind die Unterauftragnehmer (CDN, Backups, internes Monitoring) alle in Europa angesiedelt?
• Gerichtsbarkeit des Anbieters. Ein Anbieter, dessen Muttergesellschaft in den Vereinigten Staaten ansässig ist, aktiviert das CLOUD-Act-Risiko (Clarifying Lawful Overseas Use of Data Act, 2018), der es US-Behörden erlaubt, Daten zu fordern, die von einem Unternehmen unter US-Gerichtsbarkeit gespeichert werden, unabhängig vom Land der physischen Speicherung. Das disqualifiziert die betroffenen Anbieter nicht automatisch (Atlassian Statuspage zum Beispiel), erfordert aber verstärkte SCC (Standardvertragsklauseln) der DSGVO und einen expliziten DPA.
• Zertifizierungen. SOC 2 Type II und ISO 27001 sind nützlich, aber für DORA nicht ausreichend, da DORA eine sektorspezifische Auditfähigkeit für den Finanzsektor erfordert. Verlangen Sie ausdrücklich ein Statement of Applicability, das die Klausel zu DORA Artikel 28 einschließt.
• Register der Unterauftragnehmer. Ein DORA-konformer Anbieter muss die aktuelle Liste seiner Unterauftragsverarbeiter mit ihrem Standort und ihrer Rolle liefern können. Verweigerung = Warnsignal.
• Getestete Exit-Strategie. Die Fähigkeit, Ihre gesamte Status-Page-Historie in einem offenen Format (JSON, CSV) in weniger als 72 Stunden wiederzugewinnen, muss vertraglich festgelegt und jährlich getestet werden. Ein im Notfall improvisierter Export hält einem Prüfer nicht stand.

US-Anbieter (Atlassian Statuspage, StatusGator, bestimmte BetterStack je nach Vertragsgerichtsbarkeit) koexistieren mit europäischen Alternativen (Instatus EU, CaptainDNS, OpenStatus im Self-hosting-Modus). Die Wahl erfolgt nicht über Features oder Pricing, sondern über die Ausrichtung an DORA Artikel 28 und 30. Für die detaillierten Vertragsklauseln konsultieren Sie die Zusammenfassung von Bird & Bird zu den DORA-Vertragsklauseln. Zur gleichen Logik des vertraglich europäischen Hostings siehe auch den vollständigen MTA-STS-Leitfaden.

Zum Mitnehmen: 10 technische Attribute plus 1 juristische Frage zur Gerichtsbarkeit bilden die Anatomie-Checkliste. Jeder Verstoß gegen ein Attribut ist ein Auditrisiko, kein Produktdetail.

Vorlage für Vorfallberichte vom Status-Page-JSON zum DORA-Bericht

Das Ziel einer DORA-konformen Status Page besteht nicht nur in der öffentlichen Kommunikation. Es geht auch darum, den vertraulichen regulatorischen Bericht direkt zu nähren, ohne wiederholte manuelle Erfassung. Der Pivot zwischen beiden ist eine strukturierte JSON-Datei, die aus der Status Page abgeleitet und auf die Vorlagen RTS/ITS JC 2024-33 übertragen wird.

Feld-zu-Feld-Entsprechung zwischen Status-Page-Export und Regulatorenvorlage

Der DORA-Erstbericht erfordert mindestens neun Felder. Die untenstehende Tabelle zeigt die Entsprechung mit einem Status-Page-JSON-Export:

• entity_id (Status Page) -> Feld "LEI" oder nationale Kennung des DORA-Berichts.
• incident.uuid (Status Page) -> Feld "Reference number" des Berichts.
• incident.detected_at (Zeitstempel RFC 3339 UTC) -> Feld "Date and time of detection".
• incident.classified_at -> Feld "Date and time of classification".
• incident.preliminary_description -> Feld "Description of the incident".
• incident.classification_criteria (kodierte Liste Art. 18) -> Feld "Classification criteria activated".
• incident.impact_estimate (Kunden, Dauer, Geografie, Daten) -> Block "Estimated impact".
• incident.immediate_actions (Tabelle der Maßnahmen) -> Feld "Immediate measures taken".
• incident.contact (E-Mail + Telefon des DORA-Ansprechpartners) -> Feld "Reporting contact".

JSON-Beispiel für einen als schwerwiegend eingestuften DDoS-Vorfall

{
  "entity": {
    "lei": "5493000F4ZO33MV32P92",
    "name": "captaindns.com",
    "ncas": ["ACPR-FR", "BaFin-DE"]
  },
  "incident": {
    "uuid": "INC-2026-05-15-001",
    "url_public": "https://status.captaindns.com/incidents/INC-2026-05-15-001",
    "detected_at": "2026-05-15T14:02:11Z",
    "classified_at": "2026-05-15T14:48:32Z",
    "classification_criteria": [
      "geographical_spread:multi_region",
      "data_loss:none",
      "duration_estimate:over_2h",
      "clients_affected:over_10000"
    ],
    "severity": "major_outage",
    "preliminary_description": "Volumetric DDoS attack (1.2 Tbps) on EU-West API ingress, mitigation engaged at T+8min, traffic partially restored T+15min, full mitigation T+47min.",
    "impact_estimate": {
      "clients_affected_estimate": 12400,
      "geography": ["EU-West", "EU-North"],
      "data_loss": false,
      "downstream_dependencies": ["bank-X", "insurer-Y"]
    },
    "immediate_actions": [
      "Activation BGP blackhole upstream",
      "Failover to APAC fallback (read-only mode)",
      "Public status page update T+11min"
    ],
    "next_steps": [
      "Continuous monitoring 24h",
      "Forensic capture preserved",
      "Intermediate report scheduled T+72h"
    ],
    "contact": {
      "name": "DORA Incident Notifier (role dedicated)",
      "email": "dora-incidents@captaindns.com",
      "phone": "+33 1 00 00 00 00"
    },
    "timestamps_audit_trail": [
      {"at": "2026-05-15T14:08:00Z", "action": "public_announce", "version": 1},
      {"at": "2026-05-15T14:23:00Z", "action": "update_severity", "version": 2},
      {"at": "2026-05-15T14:55:00Z", "action": "resolution_announced", "version": 3}
    ]
  }
}

Workflow für Extraktion und Übermittlung

Die Industrialisierung des Flusses stützt sich auf drei Bausteine. Eine Cron-Aufgabe liest die Status Page alle 5 Minuten, serialisiert die Vorfälle im JSON-Format, signiert die Datei mit einer abgesetzten Signatur (PGP oder cosign). Eine zweite Aufgabe, ausgelöst durch einen Webhook bei der Klassifizierung, bereitet die Regulator-Version vor, indem sie die Felder auf die offiziellen XSDs (XBRL für BaFin, XML für Banca d'Italia, JSON für ACPR OneGate) abbildet. Ein dritter Baustein steuert die Übermittlung über die dedizierten APIs oder Portale (OneGate API, eDesk CSSF, MVP BaFin), mit Retry bei Nichtverfügbarkeit des Portals.

Zur Absicherung des E-Mail-Transports ergänzender Benachrichtigungen folgt die Strenge der gehosteten MTA-STS-Policies derselben Logik kryptografischer, im Audit verwertbarer Beweise.

Zum Mitnehmen: Wenn Ihre Status Page dieses JSON exportiert, füllen Sie den DORA-Bericht in 4 Stunden ohne Neuerfassung. Das ist der Unterschied zwischen Fristenwahrung und Verfehlung.

Praktisches Framework in sieben Schritten (HowTo)

Um vom Konzept zur operativen Umsetzung zu kommen, hier ein Framework in sieben Schritten, anwendbar in 90 Tagen für ein europäisches B2B-SaaS mit einem Basis-SRE-Team.

Die Abfolge der Schritte 1 bis 4 bereitet die Infrastruktur vor; die Schritte 5 und 6 verriegeln den Nachweis und die Resilienz; Schritt 7 institutionalisiert den Ansatz. Für Teams, die nie eine Simulation gesteuert haben, erscheint die Anfangsinvestition hoch. Sie ist in Wirklichkeit minimal gegenüber dem Sanktionsrisiko. Zur Strenge der mit der Status-Domain verbundenen HTTPS- und HSTS-Kontrollen siehe den HSTS-Preload-Leitfaden.

Zum Mitnehmen: Ohne vierteljährlichen 4-Stunden-Drill werden Sie in Produktion feststellen, dass Ihr Meldeprozess nicht hält. Der Drill kostet einen halben Tag. Eine misslungene Meldung kostet 10 Millionen Euro.

Häufige Fragen

Abschluss-Checkliste 25 Punkte vor dem Audit zu validieren

Diese Checkliste fasst die DORA-, NIS2- und DSGVO-Anforderungen zusammen, die für die Status Page eines europäischen B2B-SaaS gelten. Sie ist in drei Blöcke gegliedert: dokumentarisch (7 Punkte), technisch (10 Punkte), organisatorisch (8 Punkte). 25 von 25 Punkten abzuhaken garantiert nicht das Ausbleiben einer Sanktion, versetzt das Unternehmen aber in eine starke Verteidigungsposition vor einer Kontrolle durch ACPR, BaFin, ACN, CSSF oder Banca d'Italia.

Dokumentarischer Block (sieben Punkte)

1. Schriftliche Klassifizierungspolitik für Vorfälle, von der Geschäftsleitung unterzeichnet (Schweregradmatrix in Bezug auf DORA- und NIS2-Reporting).
2. Dokumentiertes Verfahren der DORA-Meldung nach 4 Stunden, von der Rechtsabteilung validiert, jährlich aktualisiert.
3. Dokumentiertes Verfahren der NIS2-Meldung nach 24 Stunden, ausgerichtet am nationalen Portal (MonEspaceNIS2, BSI, ACN).
4. Mit dem Status-Page-Anbieter unterzeichnetes DSGVO-DPA einschließlich Liste der Unterauftragnehmer.
5. Aktuelles Register der ICT-Dienstleister, konform zu DORA Artikel 28 Absatz 3.
6. Jährlich getestete und dokumentierte Exit-Strategie des Status-Page-Anbieters.
7. Vom Vorstand validierter Krisenkommunikationsplan (Rollen, Standardnachrichten, Kanäle).

Technischer Block (zehn Punkte)

1. Status Page außerhalb der Anwendungs-Infrastruktur gehostet, mit Nachweis der getesteten Unabhängigkeit.
2. Zeitstempel RFC 3339 UTC überall, ohne Ausnahme (Interface, API, Exporte).
3. Schweregrad in mindestens 4 Stufen codiert (operational, degraded, partial outage, major outage).
4. Strukturierter Export verfügbar in JSON, RSS und Atom, ergänzt durch ICS für die Wartung.
5. Sichtbarer Audit Trail bei jeder Aktualisierung, der den Autor identifiziert (mindestens nach Rolle).
6. Versionierung der Vorfallaktualisierungen, niemals rückwirkende Überschreibung.
7. Multi-Region-Monitoring in mindestens 4 Zonen (EU, US, APAC, UK).
8. Funktionierende kanalübergreifende Benachrichtigungen: E-Mail, Webhook, RSS, optional SMS.
9. Unveränderliche WORM-Archivierung oder signiertes Register über mindestens 6 Jahre.
10. Sicherheit der Status-Domain: aktives DNSSEC, striktes HTTPS, HSTS, CAA, validierter HSTS-Test.

Organisatorischer Block (acht Punkte)

1. Rolle "DORA Incident Notifier" schriftlich benannt, mit Backup (entspricht der CSSF-eDesk-Rolle).
2. 24/7-Bereitschaft auf dem Status-Page-Kanal, mit dokumentierter Rotation und Jahreskalender.
3. Vierteljährlicher 4-Stunden-Drill als Tabletop Exercise, gefolgt von einem Drill-Post-Mortem.
4. Dokumentiertes Mapping der nationalen Behörden nach Gerichtsbarkeit (ACPR / BaFin / ACN / CSSF / Banca d'Italia + NIS2-CSIRT + CNIL und DSGVO-Äquivalente).
5. KPI "delay-to-publish" kontinuierlich verfolgt, mit Zielwert unter 15 Minuten.
6. Vor-redigierte Kundenkommunikation je Szenario, vom DPO und der Rechtsabteilung validiert.
7. Jährliche Schulung der SRE- und Kommunikationsteams zu den DORA- und NIS2-Pflichten.
8. Jährliche Überprüfung durch Vorstand und Aufsichtsrat zu den schwerwiegenden Vorfällen (DORA Artikel 17).

Um diese Checkliste direkt in Ihr Audit-Backlog zu integrieren, stehen zwei operative Exporte zur Verfügung: Checkliste im CSV-Format herunterladen (für Import in Excel oder Google Sheets) oder im JSON-Format (zur Einspeisung in ein GRC-System, Jira oder Notion). Jede Zeile enthält die Kategorie, die Nummer, den Punkt, die Priorität und das erforderliche Beweisstück für die dokumentarische Verteidigung.

Glossar

• CIFA: Critical or Important Function Arrangement, kritische oder wichtige Funktion im Sinne von DORA Artikel 28.
• CTPP: Critical Third-Party Provider, von den ESAs benannter kritischer Drittdienstleister, der direkter Aufsicht unterliegt.
• DORA: Digital Operational Resilience Act, EU-Verordnung 2022/2554, anwendbar ab 17. Januar 2025.
• NIS2: Network and Information Security Directive 2, EU-Richtlinie 2022/2555, in nationales Recht umzusetzen.
• ESA: European Supervisory Authorities, bestehend aus EBA (Banken), EIOPA (Versicherungen) und ESMA (Finanzmärkte).
• CSIRT: Computer Security Incident Response Team, von jedem Mitgliedstaat für NIS2 benanntes nationales Team (CERT-FR, BSI, ACN usw.).
• RTS / ITS: Regulatory Technical Standards und Implementing Technical Standards, von den ESAs zur Präzisierung der DORA veröffentlicht.
• WORM: Write Once Read Many, unveränderlicher Speichermodus, der das Fehlen von Umschreibungen garantiert.

Fazit

Das Jahr 2026 bedeutet den Übergang zwischen der Übergangsphase und der aktiven Durchsetzung der beiden strukturierenden europäischen Regulierungen zur digitalen operativen Resilienz. Für ein europäisches B2B-SaaS ist die öffentliche Status Page kein Marketing-Kommunikationsinstrument mehr, sondern ein Audit-Liefergegenstand, der gegenüber einem nationalen Aufseher rechtsverbindlich ist. Die DORA-Compliance und die NIS2-Richtlinie machen aus diesem Artefakt einen vertraglichen und regulatorischen Hebel. Drei Prioritäten zeichnen sich im Compliance-Rahmen ab: die Status Page auf einer unabhängigen Infrastruktur hosten, ein an JC 2024-33 ausgerichtetes JSON-Pivotformat exportieren, einen vierteljährlichen 4-Stunden-Drill zur Validierung der gesamten Kette organisieren. Anbieter, die diese Transformation zwischen 2026 und 2027 vorwegnehmen, verwandeln eine regulatorische Pflicht in einen kommerziellen Vorteil: Ein Finanzkunde oder ein wesentlicher Betreiber wird stets einen Anbieter bevorzugen, dessen Status Page direkt seinem eigenen Regulator-Bericht zugutekommt, gegenüber einem Anbieter, bei dem jeder Vorfall eine manuelle Rekonstruktion des Nachweises erfordert. Um diesen Ansatz zu industrialisieren, bietet das Hosting einer konformen Status Page den schnellsten Einstieg.