Cyber Resilience Act + NIS2 + DORA: der Compliance-Stack 2026 für headless WordPress

#Cyber Resilience Act + NIS2 + DORA: der Compliance-Stack 2026 für headless WordPress

Zwischen 2024 und 2026 sind drei EU-Rechtsakte inhaltlich auf dieselbe operative Substanz zugelaufen. Der Cyber Resilience Act (Verordnung (EU) 2024/2847) regelt Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Die NIS2-Richtlinie (2022/2555) regelt Einrichtungen, die wesentliche oder wichtige Dienste erbringen. Die DORA-Verordnung (2022/2554) regelt Finanzunternehmen und die IKT-Drittdienstleister, auf die sie sich stützen. Ein headless WordPress-Projekt, das einem regulierten Kunden eine kommerzielle Komponente mitliefert, fällt auf der Produktseite unter den CRA und auf der Seite der Einrichtung unter NIS2 oder DORA. Für ein Finanzunternehmen ersetzt DORA die Risikomanagement- und Meldevorschriften der NIS2, statt sie zu ergänzen. Die gute Nachricht: Ein einziges Nachweispaket kann das alles abdecken, wenn es nach Kontrollen statt nach Rechtsakten aufgebaut ist.

Dieser Artikel schließt die Säule zu NIS2 und DORA in WordPress ab und verbindet den Nachweispfad nach Anhang II, das Lieferantenaudit nach DORA Artikel 28, das 24-Stunden-Playbook für Vorfälle und den Beitrag zu BFSG und EAA.

#Compliance-Stack aus CRA, NIS2 und DORA in Kürze

• CRA ist Produktregulierung. NIS2 ist Regulierung von Einrichtungen. DORA ist Regulierung von Finanzunternehmen.
• Ein headless WordPress-Projekt kann über seine kommerziellen Komponenten unter den CRA fallen und über den Kunden, der es betreibt, unter NIS2 oder DORA.
• Für Finanzunternehmen gilt DORA anstelle der Artikel 21 und 23 NIS2 (Artikel 4 und Erwägungsgrund 28 NIS2).
• Ein nach Kontrollen gegliedertes Nachweispaket schlägt drei getrennte Papierspuren.
• Meldepflichten aus dem CRA ab dem 11. September 2026, volle Geltung ab dem 11. Dezember 2027.
• NIS2 ab der Umsetzungsfrist 2024-10-17; DORA seit 2025-01-17 unmittelbar anwendbar.

#Was headless WordPress für CRA, NIS2 und DORA bedeutet

Ein headless WordPress-Projekt trennt zwei Schichten. Die Inhaltsschicht betreibt WordPress als Editor und maßgebliche Quelle und stellt Inhalte über die REST API oder GraphQL bereit. Die Präsentationsschicht betreibt ein Frontend-Framework (Next.js, Astro, Nuxt, SvelteKit), das diese Inhalte abruft und für die Nutzer rendert.

Für die Compliance verändert diese Trennung die Risikofläche auf drei Arten.

Das Frontend kann ein Produkt sein. Eine Next.js-Anwendung mit kommerziellen Bibliotheken, von einer Agentur ausgerollt, kann ein “Produkt mit digitalen Elementen” im Sinne des CRA sein, wenn sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird. WordPress selbst liegt als freie Open-Source-Software einer Community, die von ihren Entwicklern nicht monetarisiert wird, nicht im Geltungsbereich des CRA (Erwägungsgründe 15 und 18 der Verordnung (EU) 2024/2847); kommerzielle Bündel darauf können es sein.

Die Lieferkette ist breiter. Headless-Projekte bringen npm-Abhängigkeiten (oft Hunderte), CDN-Edge-Functions, Dienste zur Bildoptimierung, Suchanbieter und Kommentarsysteme mit. Artikel 21(2)(d) NIS2 verlangt von erfassten Einrichtungen, die Beziehungen zu unmittelbaren Anbietern abzusichern, und Artikel 28(3) DORA verlangt von Finanzunternehmen ein Informationsregister über alle vertraglichen Vereinbarungen zu IKT-Dienstleistungen. Beides läuft auf ein Inventar dieser Kette mit vertraglichen Kontrollen hinaus.

Die Vorfallfläche ist aufgeteilt. Eine Schwachstelle kann im WordPress-Backend, im Frontend-Bundle, in einer Edge-Function oder in einer Drittanbieter-API liegen. Die 24-Stunden-Frist aus NIS2 und die Meldefristen aus DORA gelten für die Einrichtung, egal wo der Fehler sitzt. Das Runbook der Agentur muss über alle vier Schichten hinweg erkennen und triagieren.

#Was CRA, NIS2 und DORA jeweils verlangen

#CRA (Verordnung (EU) 2024/2847)

Erfasst Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Artikel 13 legt die Herstellerpflichten fest: eine dokumentierte Bewertung der Cybersicherheitsrisiken (Artikel 13 Absätze 2 und 3), die grundlegenden Anforderungen aus Anhang I Teil I wie eine sichere Standardkonfiguration, die Schwachstellenbehandlung über den Supportzeitraum nach Anhang I Teil II, Sicherheitsupdates und eine Software-Stückliste (SBOM, Anhang I Teil II Nummer 1). Artikel 14 ergänzt die Meldepflichten: Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gehen gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA, über die einheitliche Meldeplattform nach Artikel 16, mit einer Frühwarnung binnen 24 Stunden nach Kenntnis.

Geltungszeitplan nach Artikel 71:

• Meldepflichten nach Artikel 14 ab dem 11. September 2026.
• Kapitel IV zu notifizierten Stellen (Artikel 35 bis 51) ab dem 11. Juni 2026.
• Alles Übrige, einschließlich der vollständigen Herstellerpflichten, ab dem 11. Dezember 2027.
• Für die Konformitätsbewertung “wichtiger” und “kritischer” Produkte mit digitalen Elementen gelten eigene Verfahren (Artikel 32).

Open-Source-Software, die ohne Geschäftstätigkeit entwickelt und bereitgestellt wird, liegt außerhalb des CRA. Die Erwägungsgründe unterscheiden zwischen nichtkommerziellem Open-Source-Beitrag und kommerzieller Bündelung. Der WordPress-Core ist nichtkommerzielles Open Source; ein Managed-WordPress-Angebot als Produkt mit gebündelten Premium-Plugins unter einer einzigen Lizenz kann in den Geltungsbereich des CRA rutschen.

#NIS2 (Richtlinie 2022/2555)

Erfasst Einrichtungen (wesentliche und wichtige), die in Anhang I und Anhang II aufgeführt sind. Artikel 21(2) nennt zehn Risikomanagementmaßnahmen, Buchstaben a bis j (ausführlich im Artikel zum Nachweispfad nach Anhang II). Artikel 23 Absatz 4 legt die Frühwarnung nach 24 Stunden, die Meldung nach 72 Stunden und den Abschlussbericht nach einem Monat fest (ausführlich im 24-Stunden-Playbook zur Vorfallsreaktion). Artikel 21(2)(d) zieht Lieferanten mittelbar hinein: Die Einrichtung muss die Sicherheit der Lieferkette einschließlich der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern abdecken, und Artikel 21(3) verlangt, die sicheren Entwicklungsverfahren jedes Anbieters zu berücksichtigen.

Die Umsetzungsfrist endete am 2024-10-17 (Artikel 41). Mehrere Mitgliedstaaten waren verspätet; prüfen Sie den nationalen Stand vor jedem abschließenden Audit.

#DORA (Verordnung 2022/2554)

Erfasst die in Artikel 2 aufgeführten Finanzunternehmen sowie die von den Europäischen Aufsichtsbehörden nach Artikel 31 benannten kritischen IKT-Drittdienstleister (CTPPs). Die Artikel 28 bis 30 regeln das IKT-Drittparteienrisiko: Allgemeine Grundsätze, Informationsregister und Ausstiegsstrategien stehen in Artikel 28 (ausführlich im Artikel zum Lieferantenaudit nach DORA Artikel 28), die Pflichtklauseln der Verträge in Artikel 30. Die Artikel 17 bis 19 behandeln den Prozess für das Management IKT-bezogener Vorfälle, ihre Klassifizierung und die Meldung schwerwiegender Vorfälle. Die Artikel 24 bis 27 behandeln das Testen der digitalen operationalen Resilienz einschließlich TLPT.

Gilt seit 2025-01-17 unmittelbar in der gesamten EU (Artikel 64).

#Gilt NIS2 noch, wenn DORA ein Finanzunternehmen erfasst

Für die hier relevanten Teile nicht. Artikel 4 Absatz 1 NIS2 schaltet die eigenen Vorschriften zu Risikomanagement, Meldung und Aufsicht ab, sobald ein sektorspezifischer Rechtsakt der Union Anforderungen stellt, die in ihrer Wirkung mindestens gleichwertig sind. Erwägungsgrund 28 NIS2 benennt DORA als diesen Rechtsakt für Finanzunternehmen: Die DORA-Regeln zu IKT-Risikomanagement, Vorfallmeldung, Resilienztests, Informationsaustausch und IKT-Drittparteienrisiko gelten anstelle der NIS2-Regeln.

Für einen headless WordPress-Auftrag teilt das die Kundschaft in zwei Gruppen:

• Eine Bank, ein Versicherer, ein Zahlungsinstitut oder eine Wertpapierfirma arbeitet unter DORA. Das Nachweispaket verweist auf DORA-Artikel, und Vorfallmeldungen gehen nach Artikel 19 DORA an die zuständige Finanzaufsicht.
• Ein Krankenhaus, ein Energieversorger, eine öffentliche Verwaltung oder eine andere Einrichtung aus Anhang I oder II arbeitet unter dem nationalen NIS2-Umsetzungsgesetz. Das Nachweispaket verweist auf Artikel 21(2), und Vorfallmeldungen gehen nach Artikel 23 an das CSIRT oder die zuständige Behörde.

Der CRA liegt quer über beiden: Liefert die Agentur ein kommerzielles Produkt, gelten ihre Herstellerpflichten unabhängig davon, unter welchem Regime der Kunde steht. Die Überschneidungstabelle weiter unten hat deshalb eine NIS2-Spalte und eine DORA-Spalte, aber ein einzelner Auftrag füllt nur eine davon.

#Wann die Agentur selbst unter NIS2 fällt

NIS2 erreicht nicht nur den Kunden. Anhang I Nummer 9 nennt “Verwaltung von IKT-Diensten (Business-to-Business)” und erfasst damit Anbieter verwalteter Dienste und Anbieter verwalteter Sicherheitsdienste. Artikel 6 Nummer 39 definiert den Anbieter verwalteter Dienste als Einrichtung, die Dienste im Zusammenhang mit der Installation, der Verwaltung, dem Betrieb oder der Wartung von IKT-Produkten, -Netzen, -Infrastruktur oder -Anwendungen erbringt, sei es durch Unterstützung oder aktive Verwaltung in den Räumlichkeiten der Kunden oder aus der Ferne.

Eine Agentur, die im Rahmen eines Wartungsvertrags Hosting, Updates und Monitoring für WordPress-Installationen ihrer Kunden übernimmt, passt auf diese Beschreibung. Ob sie erfasst ist, entscheidet der Größentest in Artikel 2 Absatz 1: Die Richtlinie gilt für Einrichtungen, die als mittlere Unternehmen im Sinne der Empfehlung 2003/361/EG der Kommission gelten oder deren Schwellenwerte überschreiten. Nach Artikel 2 dieser Empfehlung hat ein kleines Unternehmen weniger als 50 Beschäftigte und höchstens 10 Millionen EUR Umsatz oder Bilanzsumme, also ist eine Agentur mit 50 oder mehr Beschäftigten und einer Managed-Hosting-Sparte der Fall, den man prüfen muss. Ist sie erfasst, braucht sie eigene Maßnahmen nach Artikel 21 und einen eigenen Meldeweg nach Artikel 23, getrennt von denen der Kunden.

#Ist eine headless WordPress-Website ein Produkt im Sinne des CRA

Meistens nicht, und die Verordnung sagt das ausdrücklich. Nach Erwägungsgrund 12 CRA fallen Websites, die die Funktionalität eines Produkts mit digitalen Elementen nicht unterstützen, nicht in den Geltungsbereich, und Cloud-Dienste wie SaaS, PaaS und IaaS unterliegen stattdessen der NIS2. Eine Marketing-Website oder ein Online-Banking-Frontend auf headless WordPress ist eine als Dienst betriebene Website, kein in Verkehr gebrachtes Produkt.

Der CRA kommt über drei engere Wege ins Spiel:

• Ein kommerzielles Produkt für viele Kunden. Ein Premium-Theme, ein kostenpflichtiges Plugin oder ein lizenziertes Frontend-Starterkit, das im Rahmen einer Geschäftstätigkeit bereitgestellt wird, ist ein Produkt mit digitalen Elementen (Artikel 3 Nummer 1).
• Eine App mit eigenem Backend. Artikel 3 Nummer 2 und Erwägungsgrund 11 behandeln eine “Datenfernverarbeitung”, die vom Hersteller oder in seinem Auftrag entwickelt wurde und ohne die das Produkt eine seiner Funktionen nicht erfüllen kann, als Teil des Produkts. Liefert eine mobile App einen eigenen WordPress-REST-Endpunkt mit, von dem sie abhängt, liegt dieser Endpunkt im CRA-Geltungsbereich der App.
• Open-Source-Komponenten in einem kommerziellen Produkt. Artikel 13 Absatz 5 verlangt von Herstellern Sorgfalt bei der Integration von Komponenten Dritter, auch freier und quelloffener, und Artikel 13 Absatz 6 verlangt, eine in einer Komponente gefundene Schwachstelle an denjenigen zu melden, der sie pflegt.

Keiner der Produkttypen in Anhang III (wichtige Produkte) oder Anhang IV (kritische Produkte) ist ein CMS, ein Theme oder ein Web-Frontend. Ein typisches WordPress-Produkt nutzt daher das Verfahren der internen Kontrolle (Modul A in Anhang VIII), keine notifizierte Stelle.

#Wie sich die Meldefristen von CRA, NIS2 und DORA unterscheiden

Jeder Rechtsakt hat seine eigene Uhr, die zu einem anderen Zeitpunkt startet:

Die DORA-Fristen stammen aus der Delegierten Verordnung (EU) 2025/301 der Kommission, nicht aus DORA selbst. Eine praktische Folge für einen headless Stack: Die Frontend-Agentur, die zugleich CRA-Herstellerin ist, kann eine eigene 24-Stunden-Meldung an die ENISA zu derselben Schwachstelle schulden, die die Bank ihrer Aufsicht meldet. Beide Meldungen sollten aufeinander verweisen, und das Runbook sollte festlegen, wer was einreicht.

#Wo sich CRA, NIS2 und DORA überschneiden

Ein headless WordPress-Auftrag, der ein kommerzielles Frontend-Bundle mitliefert, trifft auf folgende Überschneidungen. Die NIS2-Spalte gilt für Kunden außerhalb des Finanzsektors, die DORA-Spalte für Finanzunternehmen:

Acht sich überschneidende Kontrollen. Ein Nachweispaket mit acht Ordnern, jeder mit Querverweisen auf den CRA und auf das Regime des Kunden, deckt sie alle ab.

#Wie man ein gemeinsames Nachweispaket für CRA, NIS2 und DORA strukturiert

Ich gliedere das Paket nach Kontrollbereichen, nicht nach Rechtsakten. Jeder Kontrollordner enthält:

1. Richtlinie. Vom Leitungsorgan der Einrichtung genehmigt. Mit Querverweisen auf die relevanten Artikel aus CRA / NIS2 / DORA.
2. Prozessverantwortliche. Benannte Rolle in der Einrichtung, dazu die benannte Ansprechperson der Agentur.
3. Umsetzungsnachweise. Logs, Auditberichte, Scan-Ergebnisse, Testergebnisse, Vertragsklauseln.
4. Zuordnungstabelle. Drei Spalten: CRA-Artikel, NIS2-Artikel, DORA-Artikel. Wo die Richtlinie jeweils verankert ist.
5. Prüfprotokoll. Jährliche oder häufigere Überprüfung, datiert und unterschrieben.
6. Audithistorie. Externe Audits, Penetrationstests, Anfragen der Aufsicht, alles datiert und verschlagwortet.

Das gemeinsame Paket vermeidet die häufigste Verschwendung bei Compliance über mehrere Rechtsakte: dasselbe Risikoregister dreimal für drei Aufsichtsbehörden zu schreiben. Ein Register, drei Artikelverweise in den Metadaten.

#Welche Nachweise ein Headless-Projekt für CRA, NIS2 und DORA braucht

Ein headless-Projekt bringt Artefakte mit, die ein monolithischer WordPress-Auftrag nicht braucht:

• SBOM für das Frontend-Bundle. Eine CycloneDX- oder SPDX-Datei mit jeder npm-Abhängigkeit samt Version und Lizenz. Die npm-CLI erzeugt sie mit npm sbom --sbom-format cyclonedx (oder spdx); npm audit signatures ist eine getrennte Prüfung, die Registry-Signaturen verifiziert. Die SBOM ist ein Liefergegenstand nach Anhang I Teil II CRA; unter NIS2 und DORA dient sie der Schwachstellenbehandlung und dem Asset-Inventar.
• SBOM für das WordPress-Backend. Inventar der Plugins und Themes mit Version und Lizenz. WP-CLI exportiert es mit wp plugin list --fields=name,version,update_version,wporg_status,wporg_last_updated --format=json und wp theme list --format=json; die Lizenz steht im Header jedes Plugins, dazu kommen interne Versions-Lockdateien.
• Inventar der Edge-Functions. Cloudflare Workers, Netlify Functions, Vercel Edge. Jede Funktion ist Teil der Lieferkette und Teil der Vorfallfläche.
• Dokumentation des API-Vertrags. OpenAPI- oder GraphQL-Schema für die headless API, mit Sicherheitsdefinitionen, Rate Limits und Authentifizierung.
• Nachweise aus der Frontend-Deployment-Pipeline. CI/CD-Logs, Ergebnisse von Container-Scans, Nachweise des Secret-Scannings, Abhängigkeitsprüfung bei jedem PR.
• Schichtübergreifendes Monitoring. Ein Dashboard oder Runbook, das Ereignisse aus WordPress-Backend, Frontend-Anwendung, Edge-Schicht und Drittanbieter-APIs korreliert.

Für eine regulierte Einrichtung ist dieses Artefakt-Set Pflicht. Für eine nicht regulierte Einrichtung ist es gute Praxis, aber das Budgetgespräch wird enger.

#Was ein gemeinsames Paket für CRA, NIS2 und DORA nicht abdeckt

Drei Bereiche deckt ein einziges Paket nicht ab.

Konformitätsbewertung nach dem CRA. Nach Artikel 32 brauchen wichtige Produkte der Klasse I, die keine harmonisierten Normen anwenden, alle wichtigen Produkte der Klasse II und kritische Produkte die EU-Baumusterprüfung oder die umfassende Qualitätssicherung nach Anhang VIII, an denen eine notifizierte Stelle beteiligt ist, oder ein europäisches Schema für die Cybersicherheitszertifizierung, wo eines verfügbar ist. NIS2 und DORA haben keine vergleichbare Basis für eine Drittzertifizierung (am nächsten kommt der TLPT aus DORA). Planen Sie die Konformitätsbewertung als eigenen Arbeitsstrang ein, wenn das Produkt unter Anhang III oder IV fällt.

TLPT nach Artikel 26 DORA. Bedrohungsorientierte Penetrationstests für benannte Finanzunternehmen finden mindestens alle drei Jahre an Produktivsystemen statt, und die technischen Standards dahinter folgen dem TIBER-EU-Rahmenwerk. NIS2 und CRA verlangen keine Tests in dieser Tiefe.

Sektorspezifische Aufsicht. NIS2 hat sektorale zuständige Behörden. DORA hat die zuständigen Finanzaufsichtsbehörden nach Artikel 46 und für jeden kritischen IKT-Drittdienstleister eine federführende Überwachungsbehörde mit einem gemeinsamen Untersuchungsteam (Artikel 40). Der CRA hat Marktüberwachungsbehörden nach Artikel 52. Drei verschiedene Aufsichtskanäle brauchen weiterhin getrennte Kommunikationsprozesse.

#Welche Geldbußen CRA, NIS2 und DORA vorsehen

Die Obergrenzen unterscheiden sich, weil die Rechtsakte unterschiedliche Beteiligte regeln:

• CRA Artikel 64. Verstöße gegen die grundlegenden Anforderungen aus Anhang I oder gegen die Artikel 13 und 14: bis zu 15 Millionen EUR oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Andere Pflichten der Wirtschaftsakteure: bis zu 10 Millionen EUR oder 2 %. Falsche oder irreführende Angaben gegenüber notifizierten Stellen oder Marktüberwachungsbehörden: bis zu 5 Millionen EUR oder 1 %.
• NIS2 Artikel 34. Verstöße gegen Artikel 21 oder 23: ein Höchstbetrag von mindestens 10 Millionen EUR oder 2 % für wesentliche Einrichtungen und von mindestens 7 Millionen EUR oder 1,4 % für wichtige Einrichtungen. Die Mitgliedstaaten dürfen höher gehen.
• DORA Artikel 50. Die Beträge legen die Mitgliedstaaten fest, die den zuständigen Behörden Sanktionsbefugnisse geben müssen. Gegen kritische IKT-Drittdienstleister kann die federführende Überwachungsbehörde nach Artikel 35 ein tägliches Zwangsgeld von bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes verhängen, für höchstens sechs Monate.

Für die Agentur ist die CRA-Zeile diejenige, die in der eigenen Bilanz landet, weil die Agentur die Herstellerin ist. Die Bußgelder aus NIS2 und DORA treffen den Kunden, und deshalb reichen Kunden sie über Vertragsklauseln die Kette hinunter.

#Was CRA, NIS2 und DORA von WordPress-Agenturen verlangen

Eine WordPress-Agentur, die 2026 headless-Projekte an regulierte Einrichtungen liefern will, muss:

1. Die Vorlage für das gemeinsame Nachweispaket einmal bauen und in allen Aufträgen wiederverwenden.
2. SBOMs als Teil der Deployment-Pipeline erzeugen, nicht nachträglich.
3. Das Lieferantenregister als lebendes Dokument aktuell halten.
4. Die Bereitschaft zur Vorfallsreaktion über beide Schichten aufrechterhalten (WordPress und Frontend).
5. Die Durchführungsrechtsakte und delegierten Rechtsakte verfolgen, die die Kommission zum CRA erlässt, und sich vor dem Geltungsbeginn von Artikel 14 am 11. September 2026 mit der einheitlichen Meldeplattform der ENISA vertraut machen.

Die Preise sind individuell; der Compliance-Umfang bestimmt die Dauer des Auftrags, nicht ein fester monatlicher Retainer.

#Verwandte Leitfäden zu CRA, NIS2 und DORA

• Säule: NIS2 und DORA in WordPress: der Compliance-Stack 2026
• NIS2 Anhang II für WordPress-Agenturen: Geltungsbereich, Fristen, Nachweispfad
• DORA Artikel 28, IKT-Drittparteienrisiko: Audit von Hosting- und WAF-Lieferanten für WordPress
• Vorfallsreaktion in WordPress nach NIS2: Playbook für die 24-Stunden-Frühwarnung
• BFSG vs. EAA: die Frist 2025 des Barrierefreiheitsstärkungsgesetzes für WordPress-Shops