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 für eine regulierte Einrichtung, das eine kommerzielle Komponente mitliefert, fällt unter alle drei zugleich. Die gute Nachricht: Ein einziges Nachweispaket kann alle drei 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.

#Was ist der Compliance-Stack aus CRA, NIS2 und DORA in Kürze?

• CRA ist Produktregulierung. NIS2 ist Regulierung von Einrichtungen. DORA ist Regulierung von Finanzunternehmen.
• Headless WordPress für regulierte Einrichtungen kann unter alle drei fallen.
• Ein nach Kontrollen gegliedertes Nachweispaket schlägt drei getrennte Papierspuren.
• Meldepflichten aus dem CRA ab 2026, vollständige Herstellerpflichten ab 2027.
• NIS2 ab der Umsetzungsfrist 2024-10-17; DORA seit 2025-01-17 unmittelbar anwendbar.

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

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 ist ein Produkt. Eine Next.js-Anwendung mit kommerziellen Bibliotheken, von einer Agentur ausgerollt, kann ein “Produkt mit digitalen Elementen” im Sinne des CRA sein, wenn sie an ein Finanzunternehmen verkauft oder lizenziert wird. WordPress selbst liegt als freie Open-Source-Software einer Community laut Erwägungsgrund 15 der Verordnung (EU) 2024/2847 nicht im Geltungsbereich des CRA; 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. Sowohl Artikel 21(2)(d) NIS2 als auch Artikel 28(2) DORA verlangen, dass diese Kette inventarisiert, klassifiziert und vertraglich kontrolliert wird.

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 verlangen CRA, NIS2 und DORA jeweils?

#CRA (Verordnung (EU) 2024/2847)

Erfasst Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Artikel 13 legt die Herstellerpflichten fest: Cybersicherheit durch Technikgestaltung und Voreinstellungen, Schwachstellenbehandlung über den Supportzeitraum, Sicherheitsupdates, Software-Stückliste (SBOM), Meldung aktiv ausgenutzter Schwachstellen an die ENISA binnen 24 Stunden nach Kenntnis, Meldung schwerwiegender Vorfälle binnen 24 Stunden nach Kenntnis.

Geltungszeitplan nach Artikel 71:

• Meldepflichten zu Schwachstellen und Vorfällen ab 2026.
• Vollständige Herstellerpflichten ab 2027 (36 Monate nach Inkrafttreten).
• Für die Konformitätsbewertung “wichtiger” und “kritischer” Produkte mit digitalen Elementen gelten eigene Verfahren.

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 (ausführlich im Artikel zum Nachweispfad nach Anhang II). Artikel 23 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 über vertragliche Pflichten in den Geltungsbereich.

Die Umsetzungsfrist endete am 2024-10-17. 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 benannten kritischen IKT-Drittdienstleister (CTPPs). Artikel 28 regelt das Management des IKT-Drittparteienrisikos (ausführlich im Artikel zum Lieferantenaudit nach DORA Artikel 28). Die Artikel 16 bis 19 behandeln den Lebenszyklus des Managements IKT-bezogener 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.

#Wo überschneiden sich CRA, NIS2 und DORA?

Ein headless WordPress-Auftrag für ein Finanzunternehmen, der ein kommerzielles Frontend-Bundle mitliefert, trifft auf folgende Überschneidungen:

Acht sich überschneidende Kontrollen. Ein Nachweispaket mit acht Ordnern, jeder mit Querverweisen auf alle drei Rechtsakte, deckt sie alle ab.

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

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 braucht ein Headless-Projekt für CRA, NIS2 und DORA?

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. Erzeugt mit npm audit signatures plus einem CycloneDX-Generator. Die SBOM ist ein Liefergegenstand nach Artikel 13 CRA; unter NIS2 und DORA dient sie der Schwachstellenbehandlung.
• SBOM für das WordPress-Backend. Inventar der Plugins und Themes mit Version und Lizenz. Plugin Checker von WordPress.org plus 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 deckt ein gemeinsames Paket für CRA, NIS2 und DORA nicht ab?

Drei Bereiche deckt ein einziges Paket nicht ab.

Konformitätsbewertung nach dem CRA. “Wichtige” und “kritische” Produkte mit digitalen Elementen brauchen eine Konformitätsbewertung durch Dritte nach Anhang VII CRA. 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.

TLPT nach Artikel 26 DORA. Bedrohungsorientierte Penetrationstests für benannte bedeutende Finanzunternehmen 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 gemeinsamen Untersuchungsteams nach Artikel 31. Der CRA hat Marktüberwachungsbehörden nach Anhang VIII. Drei verschiedene Aufsichtskanäle brauchen weiterhin getrennte Kommunikationsprozesse.

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

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 zum CRA verfolgen, die die ENISA im Laufe von 2026 veröffentlicht.

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