Zwei EU-Verordnungen, zwei verschiedene Aufgaben
Es ist leicht, DSGVO und den EU Cyber Resilience Act (CRA) in einen Topf zu werfen — beide sind EU-Verordnungen, beide bringen ernsthafte Bußgelder mit sich, und beide werden in denselben "Compliance-Checklisten"-Gesprächen erwähnt. Aber sie regulieren tatsächlich unterschiedliche Dinge, und sie als austauschbar zu behandeln lässt echte Lücken offen.
Bei der DSGVO geht es um Daten: welche personenbezogenen Informationen du sammelst, warum, wie lange du sie aufbewahrst, und welche Rechte die Menschen hinter diesen Daten haben. Beim CRA geht es um Softwaresicherheit: wie sicher ein digitales Produkt gebaut ist, wie Schwachstellen offengelegt werden, und wie Sicherheitsupdates über die Lebensdauer des Produkts geliefert werden.
Eine WordPress-Seite kann vollständig DSGVO-konform sein — ordentliche Cookie-Einwilligung, eine klare Datenschutzerklärung, Verarbeitungsverträge — und trotzdem nichts haben, was der CRA erwartet. Umgekehrt gilt das Gleiche. Es sind keine sich überlappenden Kästchen auf derselben Liste; es sind zwei getrennte Listen.
Was die DSGVO tatsächlich abdeckt
Die Datenschutz-Grundverordnung, in Kraft seit 2018, regelt, wie personenbezogene Daten gesammelt, gespeichert, verarbeitet und weitergegeben werden. Für eine typische WordPress-Seite betrifft das:
- Cookie-Einwilligung — Analyse-, Werbe- und Tracking-Cookies erfordern eine ausdrückliche Opt-in-Einwilligung, bevor sie geladen werden, nicht nur einen Hinweisbanner.
- Datenschutzerklärung — eine klare, zugängliche Erklärung, welche Daten du sammelst (Kontaktformulare, Kommentare, Analysen, E-Commerce-Bestellungen) und was du damit machst.
- Rechte der betroffenen Person — Mechanismen für Besucher, ihre Daten anzufordern, eine Korrektur zu verlangen, oder eine Löschung zu beantragen.
- Verarbeitungsverträge — Verträge mit jedem Drittanbieter-Dienst, der Daten im Auftrag verarbeitet (E-Mail-Anbieter, Analysetools, Hosting).
- Meldung von Verstößen — ein Prozess, um Datenschutzverletzungen innerhalb von 72 Stunden an die zuständige Behörde zu melden, falls personenbezogene Daten offengelegt werden.
Nichts davon betrifft die Sicherheit deines Codes, deiner Plugins, oder wie Schwachstellen gemeldet werden. Der DSGVO ist es egal, ob dein Kontaktformular-Plugin einen ungepatchten SQL-Injection-Fehler hat — sie kümmert sich darum, was mit den Daten passiert, die hindurchfließen, sobald sie gesammelt wurden.
Was der CRA tatsächlich abdeckt
Der Cyber Resilience Act, dessen Durchsetzung bis 2027 schrittweise eingeführt wird, regelt die Sicherheit von Produkten mit digitalen Elementen, die auf dem EU-Markt verkauft werden. Er richtet sich primär an Hersteller — einschließlich Softwareanbieter, was WordPress-Plugin- und Theme-Entwickler einschließt — und nicht an jeden Website-Betreiber. Für einen Entwickler oder Anbieter bedeutet das:
- Secure-by-Design-Entwicklung — Software bauen, bei der Sicherheit von Anfang an berücksichtigt wird, nicht nachträglich angeflanscht.
- Richtlinie zur Offenlegung von Schwachstellen — ein dokumentierter, öffentlicher Prozess für Sicherheitsforscher, um Schwachstellen zu melden (hier kommt security.txt ins Spiel).
- Sicherheitsupdates — eine Verpflichtung, bekannte Schwachstellen für einen definierten Supportzeitraum zu patchen und Nutzer zu benachrichtigen, wenn ein Sicherheitsupdate verfügbar ist.
- Software-Stückliste (SBOM) — für viele Produkte eine dokumentierte Liste der verwendeten Softwarekomponenten und Abhängigkeiten, damit Nutzer und Regulierer die Gefährdung einschätzen können, wenn eine Komponente eine bekannte Schwachstelle hat.
- Vorfallsmeldung — Benachrichtigung der zuständigen Behörden (ENISA) über aktiv ausgenutzte Schwachstellen innerhalb enger Zeitrahmen.
Wenn du nur Plugins von WordPress.org installierst, statt Software zu bauen und zu vertreiben, treffen die direkten Pflichten des CRA eher die Plugin-Entwickler als dich — aber wenn dein Unternehmen ein Plugin, ein Theme oder ein digitales Produkt mit EU-Kunden baut und verkauft, gilt das direkt für dich.
Ein Vergleich nebeneinander
| DSGVO | EU Cyber Resilience Act | |
|---|---|---|
| Was reguliert wird | Umgang mit personenbezogenen Daten | Sicherheit des Softwareprodukts |
| An wen sich es richtet | Jeden, der Daten von EU-Bürgern verarbeitet | Hersteller von Produkten mit digitalen Elementen |
| Schlüsseldokumente | Datenschutzerklärung, Verarbeitungsverträge | Richtlinie zur Offenlegung von Schwachstellen, SBOM |
| Kernanforderung | Rechtsgrundlage für Datenverarbeitung | Secure-by-Design, laufende Sicherheitsupdates |
| Durchsetzung | Bis zu 20 Mio. € oder 4 % des weltweiten Umsatzes | Bis zu 15 Mio. € oder 2,5 % des weltweiten Umsatzes |
| In Kraft seit | 2018 | Schrittweise bis 2027 |
Warum beide für ein WordPress-Geschäft wichtig sind
Wenn du eine WordPress-Agentur betreibst, Plugins oder Themes entwickelst, oder eine Seite betreibst, die Daten von EU-Besuchern verarbeitet, sind beide Verordnungen realistisch relevant — nur für unterschiedliche Teile deines Betriebs:
- Die Datenerfassung deiner Website (Kontaktformulare, Analysen, E-Commerce) fällt unter die DSGVO.
- Jede Software, die du baust und vertreibst — ein Plugin, ein Theme, ein SaaS-Produkt — fällt unter den CRA.
Viele WordPress-Geschäfte haben die DSGVO-Seite bereits im Griff, da sie seit 2018 durchgesetzt wird und die meisten Agenturen das vor Jahren in ihren Prozess eingebaut haben. Der CRA ist neuer und wird weit seltener adressiert — genau dort liegt meist die Lücke.
Die CRA-Lücke schließen
Wenn du ein WordPress-Plugin oder -Theme entwickelst und vertreibst, ist der praktische Ausgangspunkt für CRA-Bereitschaft die Dokumentation: eine Richtlinie zur Offenlegung von Schwachstellen, eine security.txt-Datei, und idealerweise ein SBOM, das deine Abhängigkeiten auflistet. Erdo CRA Compliance scannt eine WordPress-Seite gegen CRA-, DSGVO- und NIS2-Anforderungen und erzeugt die vom CRA erwartete Dokumentation — Richtlinie zur Offenlegung von Schwachstellen, SBOM, security.txt — in einem Durchgang, statt jedes Teil manuell zu erstellen.
Fazit
DSGVO und CRA sind keine konkurrierenden Verordnungen oder zwei Versionen derselben Anforderung — sie decken völlig unterschiedliche Risiken ab. "Wir sind DSGVO-konform" als Beweis für umfassendere Compliance zu behandeln, lässt die Softwaresicherheitsseite völlig unbehandelt. Wenn dein WordPress-Geschäft Software baut oder vertreibt, verdienen beide separate Aufmerksamkeit, separate Dokumentation, und das Adressieren separater Risiken.