NIS2 vs DORA Geltungsbereich-Überschneidung für WordPress-Agenturen 2026
Richtlinie 2022/2555 (NIS2) und Verordnung 2022/2554 (DORA) decken ähnliches Terrain ab, aber mit unterschiedlicher Mechanik. NIS2 ist eine Richtlinie, die jeder Mitgliedstaat in nationales Recht umsetzt. DORA ist eine Verordnung mit direkter Geltung. NIS2 deckt eine breite Palette wesentlicher und wichtiger Sektoren ab. DORA ist finanzspezifisch. Wo sie sich überschneiden (Großteil von Risikomanagement, Vorfallsbehandlung, Lieferkette), kann ein gut gebauter Nachweispfad beide bedienen. Wo DORA weiter geht (Informationsregister, TLPT), muss die WordPress-Agentur die Deltas hinzufügen.
Dies ist ein vertiefender Artikel innerhalb der NIS2 und DORA WordPress Säule, mit Querverweisen zur Anhang II Nachweispfad-Anleitung, zur DORA Artikel 28 Drittparteienrisiko-Erklärung, zur Informationsregister-Feldanleitung und zur 24/72/30 Vorfallszeitleiste.
TL;DR
- DORA ist Lex specialis für Finanzunternehmen; NIS2 gilt anderswo.
- Überschneidung: Risikomanagement, Vorfälle, Geschäftskontinuität, Lieferkette, Berichterstattung.
- Nur DORA: Informationsregister-Schema, TLPT für kritische Unternehmen, präskriptive Drittparteienklauseln.
- Nur NIS2: breitere sektorale Reichweite (Energie, Verkehr, Gesundheit, öffentliche Verwaltung), nationale Umsetzungsvarianten.
- Praxisregel: hat ein Kunde DORA-Pflichten, baue den Nachweispfad auf DORA-Niveau und skaliere für NIS2 herunter.
Wie NIS2 selbst DORA benennt
Artikel 1(2) NIS2 sagt: wo sektorspezifische Unionsrechtsakte wesentliche oder wichtige Unternehmen verpflichten, Cybersicherheitsrisiken zu verwalten oder erhebliche Vorfälle zu melden, gelten diese sektorspezifischen Bestimmungen. DORA ist einer dieser Akte. Ein Finanzunternehmen im Geltungsbereich von DORA erfüllt also nicht doppelt: es erfüllt DORA, und die entsprechenden NIS2-Bestimmungen gelten als erfüllt.
Was DORA nicht ausdrücklich behandelt (z.B. Teile der NIS2-Verantwortung des Leitungsorgans, Schulung, sektorgemeinsame CSIRT-Kooperation), deckt die NIS2-Baseline weiterhin ab.
Für eine WordPress-Agentur heißt das: ist Ihr Kunde eine Bank, eine Wertpapierfirma, ein Zahlungsinstitut, ein Versicherer, ein Vermögensverwalter, ein TPP unter PSD2 - DORA dominiert. Bauen Sie auf DORA. Ist Ihr Kunde ein Krankenhaus, ein TLD-Register, ein Energieverteiler, ein Postbetreiber - NIS2 dominiert. Bauen Sie auf NIS2.
Entscheidungsbaum: NIS2, DORA, oder beides?
Die Regel oben (“DORA für Finanzen, NIS2 für alles andere”) gilt für die offensichtlichen Fälle. Sie versagt bei den Fällen, die tatsächlich einen Nachmittag Scoping beanspruchen: ein Fintech unterhalb des Schwellenwerts für bedeutende Unternehmen, eine Krankenhausgruppe mit einer Zahlungstochtergesellschaft, oder eine Agentur, die nie etwas mit dem Wort “NIS2” unterschrieben hat, aber eine Lieferkettenklausel in einem Anhang entdeckt. Das Flussdiagramm unten ist der Ablauf, den wir bei einem Erstgespräch mit einem neuen Kunden verwenden, bevor eine Vertragsprüfung beginnt.
flowchart TD
A["Ist Ihr Kunde ein Finanzunternehmen gemäß DORA Artikel 2?"] -->|"Ja"| B["Ist es eine Bank, Wertpapierfirma, Zahlungsinstitut, Versicherer, Vermögensverwalter oder PSD2-TPP?"]
A -->|"Nein"| C["Ist der Kunde in einem NIS2-Anhang-I- oder -II-Sektor: Energie, Verkehr, Gesundheit, Wasser, digitale Infrastruktur, öffentliche Verwaltung, Post, Abfall oder Fertigung?"]
B -->|"Ja"| D["DORA primär: Informationsregister, TLPT-Bereitschaft, Konzentrationsrisikoanalyse aufbauen"]
B -->|"Nein - unterhalb des Schwellenwerts oder ausgenommen"| C
C -->|"Ja"| E["NIS2 primär: Artikel-21-Risikoregister, Anhang-II-Nachweispfad, nationale Umsetzungsdelta aufbauen"]
C -->|"Nein"| F["Wird Ihre Agentur von einem Unternehmen beauftragt, das selbst im Geltungsbereich ist, d.h. sind Sie ein IKT-Drittanbieter?"]
F -->|"Ja - Kunde ist DORA-Geltungsbereich"| G["Lieferketten-Einbeziehung nach DORA Artikel 28: Kundenvertragsklauseln reichen DORA-Niveau-Pflichten durch"]
F -->|"Ja - Kunde ist NIS2-Geltungsbereich"| H["Lieferketten-Einbeziehung nach NIS2 Artikel 21(2)(d): Kundenvertragsklauseln reichen NIS2-Niveau-Pflichten durch"]
F -->|"Nein"| I["Weder direkt noch indirekt anwendbar: Kundenwachstum und sektorale Neueinstufung jährlich beobachten"]
D --> J["Hat die Gruppe Nicht-Finanz-Tochtergesellschaften, die die Agentur ebenfalls nutzen?"]
E --> J
J -->|"Ja"| K["Mischregime-Holding: DORA-Niveau als Obergrenze halten und Tochtergesellschaften einzeln zuordnen"]
J -->|"Nein"| L["Ein Nachweispfad auf einem Niveau reicht aus"]Zwei Verzweigungen sind es, bei denen Agenturen die Antwort am häufigsten falsch einschätzen. Erstens die Verzweigung “Nein - unterhalb des Schwellenwerts oder ausgenommen” aus B: ein Kunde kann ein Finanzunternehmen gemäß DORA Artikel 2 sein und trotzdem keine Bank oder Versicherung im alltäglichen Sinne - Crowdfunding-Dienstleister und einige Zahlungsinstitute landen hier und hören nicht auf, DORA-Unternehmen zu sein, nur weil sie klein sind. Zweitens die Verzweigung F: eine Agentur ohne einen einzigen regulierten Kunden auf dem Papier kann trotzdem in DORA-Pflichten hineingezogen werden, wenn einer ihrer Hosting- oder Wartungs-Unterauftragnehmer mehrere Stufen tiefer unter der Lieferkette eines regulierten Unternehmens sitzt.
Anwendbarkeitsmatrix
Sechs Kundenarchetypen, denen eine Agentur wahrscheinlich begegnet, zugeordnet zum primären Regime, dazu wie die Pflicht die Agentur erreicht, und dem Nachweispfad-Niveau, mit dem dieses Scoping-Gespräch enden sollte.
| Kundentyp | Primäres Regime | Lieferketten-Einbeziehung | Nachweispfad-Niveau |
|---|---|---|---|
| Bank | DORA (direkter Geltungsbereich) | Nicht zutreffend - die Bank selbst ist das regulierte Unternehmen | Volles DORA: Informationsregister, TLPT-Bereitschaft, Konzentrationsrisikoanalyse |
| Zahlungsinstitut | DORA (direkter Geltungsbereich) | Nicht zutreffend - das Institut selbst ist das regulierte Unternehmen | Volles DORA: Informationsregister, proportionales TLPT je nach Größe |
| Krankenhaus | NIS2 (direkter Geltungsbereich, Gesundheitssektor, Anhang I) | Nicht zutreffend - das Krankenhaus selbst ist das regulierte Unternehmen | NIS2-Baseline: Artikel-21-Risikoregister, Anhang-II-Nachweispfad |
| Energieverteiler | NIS2 (direkter Geltungsbereich, Energiesektor, Anhang I) | Nicht zutreffend - der Verteiler selbst ist das regulierte Unternehmen | NIS2-Baseline, oft auf Niveau eines wesentlichen Unternehmens angehoben angesichts der Kritikalität |
| WordPress-Agentur als IKT-Anbieter | Keines direkt | DORA Artikel 28 oder NIS2 Artikel 21(2)(d), je nachdem, welcher Kunde die Agentur beauftragt | Spiegelt das Regime des Kunden; DORA-Niveau wird zum Boden, sobald ein Kunde DORA-Geltungsbereich hat |
| Holding mit gemischten Tochtergesellschaften | Aufteilung pro Tochtergesellschaft (teils DORA, teils NIS2) | Direkt für regulierte Tochtergesellschaften, vertragliche Einbeziehung für den Rest über die gemeinsame Lieferantenliste der Gruppe | DORA-Niveau-Obergrenze gruppenweit angewendet, pro Tochtergesellschaft herabgestuft, sobald deren eigenes Regime bestätigt ist |
Das Muster, das neue Scoping-Gespräche am häufigsten überrascht: sobald eine einzige Kundenbeziehung irgendwo im Buch einer Agentur DORA-Geltungsbereich hat, ist es operativ günstiger, jeden Nachweispfad auf DORA-Niveau zu bauen und für reine NIS2-Kunden herabzustufen, als zwei parallele Dokumentationssysteme zu pflegen.
Zwei anonymisierte Scoping-Fälle
Die folgenden Details sind zusammengesetzt und von identifizierenden Angaben befreit; in diesem Abschnitt erscheinen keine Kundennamen.
Fall A: regionale Genossenschaftsbank. Eine Genossenschaftsbank mit rund 40 Filialen in einer einzelnen Region hat ihre Unternehmenswebsite und ein internes Mitarbeiter-Intranet, beide auf WordPress-Basis, an eine externe Agentur ausgelagert. Die Bank ist ein Finanzunternehmen gemäß DORA Artikel 2 ohne Einschränkung - die “genossenschaftliche” Struktur ändert daran nichts. Das Scoping-Gespräch bestätigte, dass die Agentur im Informationsregister der Bank als IKT-Drittanbieter erscheinen musste, konkret in den Tabellen B.02.01 (Vertragsvereinbarungen) und B.05.01 (unterstützte Funktionen), obwohl die Größe der Bank sie unter dem Schwellenwert für fortgeschrittene Threat-Led-Penetrationstests hielt. Die Agentur musste trotzdem die Konzentrationsrisikofrage nach Artikel 29 beantworten - “wer sonst könnte Hosting und Wartung innerhalb von acht Wochen übernehmen” - weil die Compliance-Verantwortliche der Bank diese Antwort unabhängig vom TLPT-Status schriftlich benötigte. Die entstandene Ordnerstruktur des Nachweispfads spiegelte den später in diesem Artikel beschriebenen Aufbau 05_dora_register/ wider, ab dem ersten Tag des Engagements befüllt statt vor einem Audit nachträglich aufgeholt.
Fall B: kommunale Krankenhausgruppe. Eine Gruppe kommunaler Krankenhäuser, die ein gemeinsames Patienteninformationsportal und ein Mitarbeiter-Intranet betreibt, beide auf WordPress-Basis, beauftragte denselben Nachweispfad-Ansatz, landete aber auf der entgegengesetzten Seite des Entscheidungsbaums. Krankenhäuser fallen unter NIS2 Anhang I (Gesundheitssektor), und die Gruppe hatte in ihrer Struktur nirgendwo einen Finanzunternehmensstatus, sodass DORA nie ins Spiel kam. Es wurde kein Informationsregister-Schema aufgebaut - das wäre verschwendete Mühe gewesen, da das fünfzehntabellige RoI-Format eine DORA-spezifische Anforderung ohne NIS2-Äquivalent ist. Stattdessen baute die Agentur ein einfacheres Lieferantenregister plus einen Due-Diligence-Fragebogen und eine Vorfallsmeldungs-SLA-Klausel, gebunden an die nationale NIS2-Umsetzung des Krankenhauses (die eigene Meldefristen und eine zuständige Behörde festlegte, getrennt vom 24h/72h/1-Monats-Rhythmus, der anderswo in dieser Säule verwendet wird). Die praktische Lehre aus dem Vergleich beider Fälle: der DORA-Kunde kostete etwa doppelt so viel initialen Dokumentationsaufwand wie der NIS2-Kunde, fast ausschließlich wegen des Informationsregister-Schemas, und diese Kostenlücke ist der beste Prädiktor dafür, welches Nachweispfad-Niveau für ein neues Engagement anzubieten ist.
Was sich überschneidet
Fünf große Überschneidungsbereiche, in denen ein einziges Artefakt beiden Regimen dient:
Risikomanagement. NIS2 Artikel 21 listet zehn Maßnahmen; DORA Artikel 5-15 deckt denselben konzeptionellen Boden detaillierter ab. Ein Risikoregister, das Assets, Bedrohungen, Wahrscheinlichkeit, Auswirkung und Behandlung benennt, erfüllt beide. Detailgrad unterscheidet sich: DORA verlangt mehr Granularität für kritische oder wichtige Funktionen; NIS2 erwartet Verhältnismäßigkeit.
Vorfallsbehandlung. NIS2 Artikel 22-23 und DORA Artikel 17-23 verlangen beide Klassifikation, Reaktion, Wiederherstellung, Post-Mortem und Berichterstattung. Die Meldefristen unterscheiden sich leicht (NIS2: 24h Frühwarnung, 72h Meldung, 1-Monats-Abschlussbericht; DORA: ähnlich, mit sektorspezifischen Vorlagen). Der interne Incident-Response-Runbook lässt sich teilen.
Geschäftskontinuität. NIS2 Artikel 21(2)(c) und DORA Artikel 11 verlangen beide Backup, getestetes Restore, Off-Site, mit dokumentierten RPO und RTO. Ein BCDR-Plan mit einem jährlichen Restore-Drill-Log erfüllt beides.
Lieferkettenkontrollen. NIS2 Artikel 21(2)(d) und DORA Artikel 28 verlangen beide Lieferantenregister, Due Diligence, Vertragsklauseln, Exit-Plan. Das DORA-Informationsregister ist ein strengeres Schema; auf DORA gebaut bekommen Sie NIS2-Lieferketten-Konformität kostenlos.
Berichterstattung. Beide verlangen Berichterstattung an die zuständige Behörde. NIS2 benennt nationales CSIRT und zuständige Behörde; DORA berichtet an den Finanzregulator (national plus ESAs). Die interne Evidenz-Vorbereitung ist gleich; der Adressat ist unterschiedlich.
Was DORA obendrauf legt
Drei Deltas, in denen DORA über NIS2 hinausgeht und die WordPress-Agentur spezifische Evidenz hinzufügen muss:
Informationsregister-Schema. Durchführungsverordnung 2024/2956 spezifiziert fünfzehn Tabellen mit benannten Spalten. Detailliert in der Informationsregister-Feldanleitung. NIS2 hat kein Pendant; die Agentur unter reinen NIS2-Pflichten braucht dieses Schema nicht.
Threat-Led Penetration Testing. DORA Artikel 26 verlangt fortgeschrittene TLPT für als bedeutend eingestufte Finanzunternehmen. Die Agentur, die kritische Infrastruktur für ein solches Unternehmen betreibt, kann als getestetes System im Geltungsbereich sein. NIS2 erwähnt Schwachstellenbehandlung breit, aber kein TLPT.
Konzentrationsrisiko und Substituierbarkeit. DORA Artikel 29 verlangt explizite Konzentrationsanalyse: wie viele kritische Funktionen trägt diese Drittpartei, und wie leicht kann sie ersetzt werden. Die Agentur muss “wer kann diese Arbeit in acht Wochen erledigen, wenn wir verschwinden” beantworten können. NIS2 hat keine vergleichbare präskriptive Forderung.
Was NIS2 obendrauf legt
Zwei Deltas, in denen NIS2 weiter reicht als DORA in Nicht-Finanz-Kontexten:
Sektorale Breite. Krankenhäuser, ISPs, Telekom-Carrier, Postdienste, Lebensmittelproduktion, öffentliche Verwaltung, Forschungsorganisationen sind in NIS2. Die meisten nicht in DORA. Die Agentur über mehrere Klientensektoren hält einen NIS2-konformen Pfad pro Sektor.
Nationale Umsetzungsvarianten. Weil NIS2 Richtlinie ist, setzt jeder Mitgliedstaat Details mit lokalem Geschmack um. Die deutsche Umsetzung (KRITIS-DachG / NIS2UmsuCG) unterscheidet sich von der polnischen (KSC) und der norwegischen. Die grenzüberschreitend tätige Agentur hält ein kleines Pro-Jurisdiktion-Delta-Dokument.
Ein Nachweispfad, beide Regimes
Entscheidungsmatrix für ein WordPress-Mandat
Ausgangspunkt sind Rechtsträger, regulierter Dienst und Jurisdiktion. Erst danach wird das WordPress-System der unterstützten Funktion zugeordnet. Die Matrix hält fest, ob NIS2, DORA, beide oder keines der Regime voraussichtlich greift, wer die Einordnung vorgenommen und welches nationale Recht geprüft hat. Die Agentur liefert technische Fakten; Kunde und Rechtsberatung verantworten die rechtliche Einordnung.
Berühren beide Regime denselben Finanzdienst, entstehen nicht zwei getrennte Kontrollprogramme. DORA wird dort als sektorspezifischer Maßstab behandelt, wo seine Vorschriften greifen; relevante NIS2- und nationale Deltas bleiben erhalten. Das ist eine Einzelfallanalyse und keine pauschale Aussage, dass ein Rechtsakt den anderen immer verdrängt.
Nachweise werden nur wiederverwendet, wenn Umfang, Eigentümer, Zeitraum und Abnahme übereinstimmen. Derselbe Restore-Test kann beide Mappings stützen; DORA-Informationsregister und behördliche Meldevorlagen bleiben getrennt. Jede Kontrolle erhält Kundenverantwortlichen, Agenturverantwortlichen, Reviewer, Ablageort und Aktualisierungsauslöser. Das Gap-Register unterscheidet fehlende Umsetzung, fehlenden Nachweis und offene Rechtsfrage.
Die Abnahme erfolgt, wenn jede Kontrolle belegt oder als Lücke dokumentiert ist, gemeinsame Artefakte verlinkt statt kopiert sind und das Restrisiko einen Eigentümer hat. Änderungen an Architektur, Anbieter, Dienst oder Rechtslage lösen einen Review aus. Die Matrix ist weder Zertifizierung noch Garantie gegen Vorfälle.
Durchgespieltes Szenario: Finanzgruppe mit öffentlichem Portal
Eine Finanzgruppe betreibt über WordPress ein öffentliches Produktportal, Formulare und einen geschützten Partnerbereich. Die Gruppe fällt in den DORA-Kontext; eine weitere Konzerngesellschaft kann zugleich einen NIS2-relevanten Dienst erbringen. Das macht nicht automatisch jede Seite zu einem kritischen System. Die Matrix verbindet deshalb jede Route und Integration mit Geschäftsprozess, Rechtsträger und Datenfluss.
Der Kunde verantwortet die Regime-Einordnung, Kritikalität und Behördenkommunikation. Die Agentur verantwortet die vereinbarten Anwendungs-, Change- und Betriebsnachweise. Hosting, Identität und Formulardienst können eigene Eigentümer haben. Ein ungeklärter Übergang wird als Governance-Lücke erfasst, nicht stillschweigend der Agentur zugewiesen.
Ein gemeinsamer Patch-Bericht kann beide Kontrollmappings stützen, wenn dieselbe Produktionsversion, derselbe Zeitraum und derselbe Prüfgegenstand betroffen sind. Dagegen darf ein Restore-Test des öffentlichen Portals nicht ohne Weiteres als Nachweis für den Partnerbereich gelten, wenn dessen Identität, Datenbank oder RTO abweichen. Die Abnahme prüft somit nicht nur, ob eine Datei vorhanden ist, sondern ob sie die konkrete Behauptung trägt.
Lücken nach Ursache statt nach Rechtsakt führen
Ein gemeinsames Gap-Register verhindert doppelte Tickets. Es kennzeichnet die Ursache als fehlende Kontrolle, unwirksame Kontrolle, fehlenden Nachweis, veralteten Nachweis, unklare Zuständigkeit oder offene Einordnung. Danach werden die betroffenen NIS2- und DORA-Mappings referenziert. Die Behebung erfolgt einmal, die regimebezogene Bewertung bleibt nachvollziehbar getrennt.
Bei der Schließung prüft der Kontrollverantwortliche Implementierung und Evidenz; der jeweilige Compliance-Verantwortliche bestätigt nur die Verwendung im eigenen Mapping. So kann ein technischer Fix abgeschlossen sein, während eine juristische oder vertragliche Frage bewusst offen bleibt. Diese Trennung verhindert, dass ein grünes Engineering-Ticket fälschlich als vollständige regulatorische Abnahme gelesen wird.
Senden Sie Rechtsträger, Länder, Dienst, Architektur, Anbieter, vorhandenes Kontrollmapping und Termin schriftlich. Unser NIS2- und DORA-Readiness-Service erstellt Überschneidungsmatrix und Nachweislückenplan, ersetzt aber keine Rechtsberatung.
Praktischer Nachweispfad-Aufbau, der beide abdeckt:
00_governance/- Risikoregister, Freigabe Leitungsorgan, Review-Kadenz.01_risikomanagement/- Artikel 21 / Artikel 5 Mapping, Kontrollen, Evidenzen.02_incident_response/- Runbook, Tabletop-Drills, Post-Mortems, 24/72/30-Vorlagen.03_geschaeftskontinuitaet/- Backup-Policy, Restore-Test-Logs, BCDR-Plan.04_lieferkette/- Lieferantenregister, Subprocessor-Liste, Due-Diligence-Akten.05_dora_register/- Informationsregister-Inputs (15 Tabellen) für DORA-Kunden.06_berichterstattung/- alte Meldungen, Adressatenlog, Fristenlog.07_jurisdiktionen/- Pro-Mitgliedstaat-NIS2-Umsetzungsdeltas.08_tlpt/- für DORA-bedeutende Unternehmen, TLPT-Berichte und Mitigation.
Einmal gebaut, quartalsweise iteriert, dauert das nächste Lieferanten-Review Stunden statt Wochen.
