Software-Sicherheit bekommt in der EU einen engeren Takt. Der Cyber Resilience Act (CRA) ist zwar schon in Kraft, die nächste praktische Schwelle kommt aber deutlich früher als viele Website- und Produktteams erwarten: Ab 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle bei Produkten mit digitalen Elementen. Die vollständigen Produktanforderungen folgen erst später, am 11. Dezember 2027. Genau deshalb ist jetzt der richtige Zeitpunkt, den eigenen WordPress-, Plugin-, SaaS- und Website-Stack als Produktlandschaft zu betrachten und nicht nur als technische Hintergrundarbeit.

Für österreichische KMU bedeutet das nicht automatisch, dass jede Website sofort selbst zum CRA-Produkt wird. Die neue Verordnung richtet sich vor allem an Hersteller, Importeure und Händler von Software- und Hardwareprodukten mit digitalen Elementen. Trotzdem trifft der CRA viele Website-Projekte indirekt: über gekaufte Plugins, selbst entwickelte Erweiterungen, White-Label-Tools, Kundensysteme, SaaS-Funktionen und Wartungsverträge. Wer Software bereitstellt, verteilt oder für Kunden betreibt, braucht künftig eine belastbare Antwort auf eine einfache Frage: Wer erkennt eine Schwachstelle, wer bewertet sie, wer informiert Nutzerinnen und Nutzer und wer kann fristgerecht melden?

Warum der CRA nicht erst 2027 relevant wird

Die EU-Kommission erklärt die Meldepflichten auf ihrer CRA-Reporting-Seite sehr konkret. Hersteller müssen ab 11. September 2026 aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden, wenn sie davon Kenntnis erlangen. Der Ablauf ist gestuft: eine frühe Warnung innerhalb von 24 Stunden, eine ausführlichere Meldung innerhalb von 72 Stunden und danach ein Abschlussbericht. Bei aktiv ausgenutzten Schwachstellen ist dieser spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme fällig, bei schweren Sicherheitsvorfällen innerhalb eines Monats nach der 72-Stunden-Meldung.

Das klingt nach Konzern-Compliance, ist aber in der Praxis ein Prozessproblem. Eine 24-Stunden-Frist hilft wenig, wenn niemand weiß, welche Produktversion betroffen ist, welche Kundinnen und Kunden diese Version nutzen, welche Open-Source-Komponente eingebaut wurde oder ob ein Plugin überhaupt noch gepflegt wird. Der CRA verschiebt Sicherheit damit vom reinen Technikthema in Produktplanung, Support, Dokumentation und Vertragsmanagement.

Website-Betreiber, Agenturen und SaaS-Anbieter: drei unterschiedliche Rollen

Normale Website-Betreiber werden häufig nicht selbst Hersteller eines digitalen Produkts sein. Sie bleiben aber abhängig von Herstellern, Plugin-Anbietern, Hosting-Partnern, Analytics-Diensten und Sicherheits-Tools. Für sie ist der CRA ein guter Anlass, die eigene Lieferkette sauberer zu dokumentieren. Wer bereits den Beitrag zum NISG 2026 und Website-Stack gelesen hat, kennt den Grundgedanken: Sicherheitsrisiken entstehen selten nur im sichtbaren Frontend, sondern in Accounts, Abhängigkeiten, Updates, Schnittstellen und Zuständigkeiten.

Agenturen und Entwicklerteams stehen näher an der CRA-Zone, wenn sie eigene Plugins, Themes, Konfiguratoren, Mitgliederbereiche, Shopschnittstellen oder SaaS-Funktionen an Kundinnen und Kunden ausliefern. Besonders relevant wird es, wenn Software nicht nur intern genutzt, sondern als Produkt oder Produktbestandteil am Markt bereitgestellt wird. Dann reicht ein Ticket im Backlog nicht mehr aus. Es braucht eine nachvollziehbare Produktakte: betroffene Versionen, Wartungsstatus, Sicherheitskontakt, Updateweg, Nutzerinformation und Nachweis, wann welche Maßnahme gesetzt wurde.

SaaS-Anbieter und Tool-Betreiber sollten den CRA noch breiter lesen. Remote-Datenverarbeitung, Cloudfunktionen und Produktdienste können Teil des digitalen Produkts sein. Wer Kundendaten verarbeitet, Monitoring einsetzt oder Sicherheitsereignisse protokolliert, muss außerdem Datenschutz und Sicherheit zusammen denken. Der AdSimple Datenschutz Generator hilft dabei, eingesetzte Dienste und Datenverarbeitungen nachvollziehbar zu beschreiben. Das ersetzt keine technische Sicherheitsbewertung, sorgt aber dafür, dass die Website-Dokumentation nicht von der tatsächlichen Tool-Landschaft abweicht.

Der wichtigste erste Schritt ist ein Software-Inventar

Viele CRA-Vorbereitungen beginnen nicht mit Juristensprache, sondern mit einer nüchternen Liste. Welche Plugins laufen auf der Website? Welche Themes, Libraries, Zahlungsdienste, Formulartools, Consent-Komponenten, Security-Plugins, Newsletter-Schnittstellen, CDN- oder WAF-Dienste sind beteiligt? Wer ist Hersteller, wer ist Dienstleister, wer hat Zugriff, wer liefert Updates und wer informiert im Sicherheitsfall?

Dieser Inventar-Gedanke passt auch zum Beitrag über die EU Open Source Strategy und WordPress-Websites. Open Source bleibt wertvoll und oft sicherheitsfördernd, aber nur, wenn Abhängigkeiten sichtbar bleiben. Für Website-Teams heißt das: nicht jedes Plugin blind als technische Kleinigkeit behandeln, sondern kritische Bausteine markieren. Kritisch sind etwa Login-, Zahlungs-, Formular-, Tracking-, Consent-, Shop-, Mitglieder- und Automatisierungsfunktionen. Dort können Schwachstellen schnell Datenschutz, Verfügbarkeit oder Integrität berühren.

Was in einen CRA-tauglichen Schwachstellenprozess gehört

Ein schlanker Prozess genügt am Anfang, wenn er wirklich genutzt wird. Hilfreich ist ein fester Eingang für Sicherheitsmeldungen, etwa eine Security-Adresse oder ein definiertes Support-Formular. Dazu kommen klare interne Verantwortliche, eine Schweregradbewertung, ein Ablauf für betroffene Versionen, eine Entscheidung über Nutzerinformation und eine Vorlage für Maßnahmen: deaktivieren, patchen, konfigurieren, Workaround kommunizieren, Dienstleister eskalieren.

Für WordPress-Projekte kann ein praktikabler Ablauf so aussehen: Plugin- und Theme-Liste regelmäßig exportieren, kritische Komponenten markieren, Update- und Backup-Prozess testen, Staging-Umgebung für Sicherheitsupdates bereithalten, externe Dienstleister im Wartungsvertrag benennen und nach jedem relevanten Update kurz dokumentieren, warum es durchgeführt wurde. Das klingt unspektakulär, ist aber genau die Art von Nachweis, die im Ernstfall Zeit spart.

Das AdSimple Business Paket kann hier als organisatorischer Rahmen dienen, wenn Website-Dokumentation, Datenschutztexte, Consent-Setup und laufende Prüfungen zusammengeführt werden sollen. Denn ein Sicherheitsupdate kann mehrere Bereiche berühren: Ein neues Formular-Plugin verändert personenbezogene Datenflüsse, ein Tracking-Skript braucht eine neue Einwilligungslogik im Consent Manager, oder ein neuer Dienst muss in der Datenschutzerklärung sauber beschrieben werden.

CRA-Meldung ist nicht automatisch DSGVO-Datenpanne

Wichtig ist die Abgrenzung: Eine aktiv ausgenutzte Schwachstelle nach CRA und eine meldepflichtige Datenschutzverletzung nach DSGVO sind nicht dasselbe. Eine Schwachstelle kann produktbezogen sein, ohne dass personenbezogene Daten abgeflossen sind. Umgekehrt kann ein Sicherheitsvorfall auch datenschutzrechtlich relevant werden, wenn Vertraulichkeit, Integrität oder Verfügbarkeit personenbezogener Daten betroffen sind. Dann läuft neben dem CRA-Prozess unter Umständen auch die bekannte DSGVO-72-Stunden-Prüfung.

Für Website-Verantwortliche ist diese Trennung praktisch wichtig. Wer jeden Security-Hinweis sofort als Datenpanne behandelt, erzeugt unnötige Unruhe. Wer aber Security- und Datenschutzteam gar nicht zusammenbringt, verliert im Ernstfall wertvolle Stunden. Der Beitrag zum EDPB-Template für Datenpannen zeigt, warum vorbereitete Entscheidungswege helfen. Der CRA ergänzt diesen Blick um Produkt- und Softwareverantwortung.

Auch Impressum, Kontaktwege und Nutzerinformation prüfen

Der CRA verlangt keine Marketing-Kosmetik, aber Kommunikation wird wichtiger. Wenn Nutzerinnen und Nutzer über Risiken, Updates oder Korrekturmaßnahmen informiert werden müssen, sollten Kontaktwege funktionieren. Bei Websites lohnt sich deshalb ein kurzer Blick auf Support-Adresse, Verantwortliche, Anbieterangaben und rechtliche Pflichtinformationen. Der Impressum Generator deckt nicht den CRA-Prozess selbst ab, kann aber helfen, die öffentlich sichtbaren Basisangaben aktuell zu halten.

Für Agenturen ist zusätzlich wichtig, Rollen nicht zu verwischen. Wer nur eine Website wartet, ist nicht automatisch Hersteller jedes eingesetzten Plugins. Wer aber eigene Softwaremodule wiederholt an Kundinnen und Kunden ausliefert, braucht klarere Produktverantwortung. Empfehlenswert sind einfache Vertragsbausteine: Wer beobachtet Sicherheitsmeldungen? Wer entscheidet über Updates? Wie schnell darf bei kritischen Schwachstellen eingegriffen werden? Wer informiert Endkunden oder Nutzer? Und welche Systeme gelten als produktiv, kritisch oder nur intern?

Ein realistischer 90-Tage-Plan für den Website-Stack

Bis zur CRA-Meldepflicht im September 2026 bleibt genug Zeit für einen pragmatischen Start, aber nicht für Aufschub bis kurz davor. In den ersten 30 Tagen sollte das Inventar stehen: WordPress, Theme, Plugins, wichtige externe Dienste, Eigenentwicklungen, SaaS-Funktionen und Verantwortliche. In den nächsten 30 Tagen folgt die Bewertung: Welche Bausteine sind kritisch, ungepflegt, nicht dokumentiert oder ohne klaren Updateweg? Danach sollten die wichtigsten Prozesse getestet werden: Sicherheitsmeldung annehmen, betroffene Version prüfen, Patch einspielen, Nutzerinformation vorbereiten und Nachweis ablegen.

Der Anspruch muss nicht Perfektion sein. Für KMU ist entscheidend, dass der Ablauf wiederholbar ist und nicht nur im Kopf einzelner Personen existiert. Ein einfacher Ordner mit Inventar, Update-Log, Sicherheitskontakten, Risikoentscheidungen und Kommunikationsvorlagen ist besser als ein theoretisches Compliance-Handbuch, das niemand öffnet. Später kann daraus ein automatisierter Scanner, ein Plugin-Risikoregister oder ein regelmäßiger Website-Audit werden.

Fazit: Der CRA macht Sicherheitsarbeit sichtbarer

Der Cyber Resilience Act ist für Website-Teams vor allem ein Weckruf: Schwachstellen, Updates und Software-Abhängigkeiten werden messbarer und dokumentationspflichtiger. Wer WordPress nur als Sammlung einzelner Plugins betrachtet, übersieht die Lieferkette. Wer die eigene Website dagegen als lebenden Software-Stack führt, ist deutlich besser vorbereitet: für CRA-Meldungen, für DSGVO-Prüfungen, für NISG-nahe Anforderungen und für Kundinnen und Kunden, die Sicherheit nachvollziehbar erwarten.

AdSimple kann dabei nicht die technische Produktsicherheit garantieren und ersetzt keine individuelle Rechtsberatung. Aber die Kombination aus sauberer Website-Dokumentation, aktuellen Datenschutztexten, Consent-Prüfung und einem strukturierten Business-Setup hilft, Sicherheit nicht erst im Notfall zu organisieren. Der beste Zeitpunkt für den CRA-Start ist deshalb nicht der Tag der ersten Schwachstelle, sondern der nächste reguläre Website-Check.

Quellen