ENISA hat am 10. August 2026 eine aktualisierte Untersuchung zum Markt für Cybersecuritybewertungen veröffentlicht.

Die Marktanalyse betrachtet die Entwicklung von 2021 bis 2025 und bezieht unter anderem IT-Produkte, Cloud-Dienste, Informationssicherheitsmanagementsysteme und Managed Security Services ein. Zusätzlich werden Daten zum europäischen Zertifizierungsschema EUCC und zur Kategorie der Managed Security Services berücksichtigt. Die Veröffentlichung zeigt, dass Unternehmen bei Beschaffung und Lieferantensteuerung mit einer wachsenden Vielfalt an Zertifikaten, Prüfberichten und Bewertungsmethoden umgehen müssen.

Für die Vertragsgestaltung entsteht daraus ein doppeltes Problem. Einerseits können externe Nachweise eine Beschaffung erleichtern und Anhaltspunkte für ein angemessenes Sicherheitsniveau liefern. Andererseits besteht die Gefahr, dass ein Zertifikat als allgemeiner Beleg für vollständige Sicherheit oder umfassende Compliance verstanden wird. Ein Nachweis bezieht sich immer auf einen konkreten Prüfgegenstand, einen bestimmten Zeitraum, definierte Kriterien und einen festgelegten Geltungsbereich. Er sagt nicht automatisch etwas über alle Funktionen eines Dienstes, alle Unterauftragnehmer oder die konkrete Verarbeitung personenbezogener Daten aus.

Verträge sollten daher nicht nur die Vorlage eines Zertifikats verlangen. Zunächst ist zu definieren, welcher Nachweis für welche Leistung benötigt wird. Bei einem Cloud-Dienst kann es beispielsweise relevant sein, ob die Zertifizierung die eingesetzte Plattform, die konkrete Region, den Support, die Administration und die Unterauftragnehmer abdeckt. Bei einem Softwareprodukt ist zu prüfen, ob sich der Bericht auf die ausgelieferte Version, die Updateprozesse oder nur auf eine bestimmte Entwicklungsumgebung bezieht. Für Managed Security Services muss außerdem klar sein, welche Überwachungs- und Reaktionsleistungen tatsächlich Gegenstand der Bewertung sind.

Zu regeln sind zudem die laufenden Informationspflichten. Der Anbieter sollte Änderungen am Prüfgegenstand, wesentliche Abweichungen, kritische Feststellungen, den Ablauf der Gültigkeit und eine Aussetzung oder einen Entzug des Nachweises mitteilen. Bei relevanten Änderungen an Architektur, Standorten, Unterauftragnehmern oder Leistungsumfang sollte eine erneute Prüfung ausgelöst werden. Für besonders kritische Leistungen sind ergänzende Auskunfts-, Audit- und Nachweispflichten sinnvoll. Auch Sicherheitsvorfälle sollten nicht nur allgemein erwähnt werden. Vereinbart werden sollten erreichbare Ansprechpartner, Reaktionszeiten, die Bereitstellung technischer Informationen und die Unterstützung bei behördlichen oder betroffenenbezogenen Anfragen.

Datenschutzrechtlich bleibt die eigene Prüfung erforderlich. Ein Cybersecurityzertifikat beantwortet nicht automatisch, ob eine Verarbeitung rechtmäßig ist, ob die technischen und organisatorischen Maßnahmen für den konkreten Datenbestand ausreichen oder ob Lösch- und Rückgabepflichten umgesetzt werden. Bei Auftragsverarbeitungen müssen die Nachweise deshalb mit dem Vertrag, dem Verzeichnis der Verarbeitungstätigkeiten, der Risikoanalyse und gegebenenfalls einer Datenschutz-Folgenabschätzung abgeglichen werden. Der Zertifizierungsstatus kann ein wichtiges Beweismittel sein. Er ersetzt aber weder die Auswahlverantwortung noch die laufende Kontrolle.

Die ENISA-Marktübersicht eignet sich damit als Anlass für ein Nachweisregister. Darin sollten Prüfgegenstand, Schema, Kriterien, Geltungsbereich, Laufzeit, Ausnahmen, verantwortliche Stelle und nächste Überprüfung erfasst werden. Ein solcher Ansatz verhindert, dass Berichte nur im Vertragsordner abgelegt werden. Er macht sichtbar, welche Nachweise für welche Risiken relevant sind und wann eine Aktualisierung erforderlich ist. Rechtliche Sicherheit entsteht nicht durch die größtmögliche Anzahl von Zertifikaten, sondern durch einen überprüfbaren Zusammenhang zwischen Dienst, Risiko, Vertrag und laufender Kontrolle.

Was Unternehmen jetzt tun sollten

• Im Vertrag Prüfgegenstand, Schema, Kriterien, Geltungsbereich und Laufzeit des Nachweises konkret benennen.
• Änderungen, Abweichungen, Aussetzung und Entzug als Informations- und Prüfereignisse definieren.
• Bei kritischen Leistungen ergänzende Audit-, Auskunfts- und Nachweispflichten vorsehen.
• Zertifikate mit eigener Risikoanalyse, DS-GVO-Prüfung und tatsächlichem Leistungsumfang abgleichen.

Quelle: ENISA, Market of Cybersecurity Assessments 2021 to 2025, veröffentlicht am 10. August 2026. (https://certification.enisa.europa.eu/publications/market-cybersecurity-assessments-2021-2025_en)

Die ab dem 11. September 2026 anwendbaren CRA-Meldepflichten betreffen im Kern Hersteller von Produkten mit digitalen Elementen. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle in kurzer Frist über die vorgesehene europäische Meldeplattform melden.

Für die rechtliche Praxis ist entscheidend, dass die Meldepflicht nicht isoliert betrachtet werden kann. In der Lieferkette müssen Rollen, Informationsflüsse und Verantwortlichkeiten so organisiert sein, dass ein Hersteller die gesetzlichen Fristen tatsächlich einhalten kann.

Die erste Meldestufe ist innerhalb von 24 Stunden nach Kenntnis abzugeben. Innerhalb von 72 Stunden muss die vollständige Meldung folgen. Für aktiv ausgenutzte Schwachstellen ist ein Abschlussbericht spätestens 14 Tage nachdem eine Korrekturmaßnahme verfügbar ist vorgesehen. Bei schweren Sicherheitsvorfällen ist der Abschlussbericht spätestens innerhalb eines Monats einzureichen. Diese Fristen erhöhen den Wert vertraglicher Vorabregelungen. Eine Klausel, die lediglich eine unverzügliche Information über Sicherheitsvorfälle verlangt, beantwortet nicht, welche Informationen in den ersten Stunden benötigt werden und wer die weitere Koordination übernimmt.

In Verträgen sollten zunächst die Rollen der Beteiligten eindeutig beschrieben werden. Zu klären ist, wer Hersteller, Importeur, Händler, Betreiber, Supportdienstleister oder Unterauftragnehmer ist und welche Stelle die gesetzliche Meldung abgibt. Die Parteien können die Zusammenarbeit und interne Kostentragung regeln. Sie können dadurch jedoch nicht ohne Weiteres gesetzliche Verantwortlichkeiten gegenüber Behörden verschieben oder beseitigen. Eine Vereinbarung, nach der ein Dienstleister die Informationen liefert, ersetzt nicht die Prüfung, ob der Hersteller selbst die Meldepflicht erfüllt.

Sinnvoll sind abgestufte Informationspflichten. Der Vertrag sollte vorsehen, dass ein Sicherheitsvorfall innerhalb einer kurzen vertraglichen Frist an benannte Ansprechpartner gemeldet wird und mindestens die bereits verfügbaren Informationen zu betroffenen Produktversionen, Angriffsmustern, Auswirkungen, Abhilfemaßnahmen und Kontaktpersonen enthält. Für die vollständige Meldung und spätere Ergänzungen sollten Aktualisierungs- und Mitwirkungspflichten vereinbart werden. Ebenso sollten Regeln für die Vertraulichkeit, die technische Untersuchung, die Kommunikation mit Kunden und die Weitergabe notwendiger Informationen an CSIRT oder Behörden enthalten sein.

Haftungsrechtlich ist außerdem zwischen der Meldepflicht und der materiellen Sicherheitsverantwortung zu unterscheiden. Die rechtzeitige Meldung beseitigt nicht automatisch die Folgen einer unsicheren Produktgestaltung oder einer unzureichenden Reaktion. Umgekehrt darf ein Vertrag nicht dazu führen, dass notwendige Informationen aus Haftungs- oder Reputationsgründen zurückgehalten werden. Für kritische Produkte sind deshalb Nachweise über Schwachstellenmanagement, sichere Updates, Supportzeiten und die Behandlung von Ausnahmen sinnvoll. Auch die Folgen eines verzögerten Updates, einer unterlassenen Mitwirkung oder einer unvollständigen Information sollten geregelt werden.

Ein Vorfall kann daneben datenschutzrechtliche oder sektorspezifische Pflichten auslösen. Werden personenbezogene Daten betroffen, ist eine eigenständige Prüfung nach Art. 33 und Art. 34 DS-GVO erforderlich. Die CRA-Meldung und eine Datenschutzverletzungsmeldung haben unterschiedliche Voraussetzungen und dürfen nicht durch eine pauschale Sammelmeldung ersetzt werden. Die Vertragsgestaltung sollte deshalb die erforderlichen Informationen so strukturieren, dass sie für mehrere Prüfungen genutzt werden können, ohne die jeweiligen rechtlichen Maßstäbe zu vermischen.

Unternehmen sollten ihre CRA-Verträge vor dem Start der Meldepflichten anhand eines konkreten Szenarios prüfen. Ein kurzer Praxistest zeigt, ob Ansprechpartner erreichbar sind, ob Produkt- und Versionsinformationen vorliegen und ob der Hersteller innerhalb der ersten 24 Stunden eine belastbare Frühwarnung vorbereiten könnte. Die rechtliche Qualität der Meldekette zeigt sich nicht im Vertragstext allein, sondern in der Frage, ob die vereinbarten Pflichten im Ernstfall funktionieren.

Was Unternehmen jetzt tun sollten

• Rollen der Beteiligten und gesetzliche Meldeverantwortung für jedes Produktmodell dokumentieren.
• Vertragliche Erstinformation, Mindestinhalte, Aktualisierungen und Mitwirkungspflichten festlegen.
• Regeln zu Sicherheitsupdates, Support, Audits, Informationsrechten und Folgen fehlender Mitwirkung aufnehmen.
• CRA-Prüfung von eigenständigen DS-GVO- und gegebenenfalls NIS2-Bewertungen unterscheiden.

Quelle: Europäische Kommission, Cyber Resilience Act: Reporting obligations and implementation information. (https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)

Die Gründung des AISI Deutschland markiert einen Perspektivwechsel in der öffentlichen Diskussion über Künstliche Intelligenz. Im Mittelpunkt steht nicht nur die Frage, welche Ergebnisse ein Modell erzeugt. Bewertet werden sollen auch die Fähigkeiten und Risiken leistungsfähiger KI-Systeme, insbesondere mit Blick auf Cybersicherheit, Safety und mögliche Kontrollverluste.

BSI und Bundesnetzagentur bauen hierfür zunächst einen gemeinsamen virtuellen Nukleus auf. Das AISI soll technische Evaluierungen ermöglichen, die Bundesregierung beraten und sicherheitsrelevante Erkenntnisse in Verwaltung, Wirtschaft und Gesellschaft transferieren.

Für Unternehmen folgt daraus keine unmittelbar neue Einzelpflicht. Die Entwicklung ist aber für die Governance von KI-Systemen relevant. Sobald ein System eigenständig auf Anwendungen, Dateien, Datenbanken oder Kommunikationskanäle zugreifen kann, verändert sich die Risikoverteilung. Fehlerhafte Ausgaben sind dann nicht mehr nur ein Qualitätsproblem. Sie können zu einer Handlung mit rechtlichen, wirtschaftlichen oder sicherheitsrelevanten Folgen werden. Die Organisation muss daher nachweisen können, welche Aufgaben das System übernehmen darf, welche Kontrollen vorgesehen sind und wie ein Eingriff durch Menschen erfolgt.

Die erste Governance-Frage betrifft die Rollen. Für jeden agentischen Anwendungsfall sollte feststehen, wer fachlich verantwortlich ist, wer den Einsatz freigibt und wer bei einem Vorfall entscheidet. Die Verantwortung darf nicht unklar bleiben, weil ein System von einem externen Anbieter stammt oder seine Schritte nicht vollständig vorhersehbar sind. Auch bei einem eingekauften KI-Dienst bleibt eine Organisation für die Auswahl, Konfiguration und Einbindung in den eigenen Prozess verantwortlich. Das erfordert eine dokumentierte Prüfung der vorgesehenen Nutzung, der Datenflüsse, der Berechtigungen und der Abhängigkeit von einzelnen Anbietern.

Die zweite Frage betrifft die vertragliche Absicherung. Anbieter sollten Informationen über Modellversionen, wesentliche Änderungen, Sicherheitsmaßnahmen, Protokollierung, Unterauftragnehmer und den Umgang mit Sicherheitsvorfällen liefern. Bei agentischen Funktionen ist außerdem zu klären, welche Werkzeuge genutzt werden, in welchen Umgebungen Aktionen ausgeführt werden und ob der Anbieter Zugriffe oder Aktionen nachvollziehbar dokumentiert. Verträge sollten Änderungsanzeigen, Prüf- und Informationsrechte sowie Regeln für die Suspendierung oder Abschaltung des Dienstes vorsehen. Eine pauschale Zusicherung, der Dienst sei sicher, reicht für eine risikobasierte Steuerung nicht aus.

Die dritte Frage betrifft den Nachweis. Unternehmen sollten vor dem produktiven Einsatz Tests durchführen und die Ergebnisse archivieren. Dazu gehören Tests mit manipulierten Eingaben, Versuche zur Umgehung von Systemvorgaben, Prüfungen der Rechtebegrenzung und Szenarien mit fehlerhaften oder widersprüchlichen Daten. Nach dem Start müssen relevante Aktionen, Freigaben und Fehlermeldungen protokolliert werden. Für kritische Prozesse ist ein manueller Notbetrieb vorzusehen. Wenn ein Agent eine falsche Aktion ausführt, muss die Organisation nicht nur reagieren, sondern auch rekonstruieren können, warum es dazu gekommen ist.

Das AISI wird diese Fragen nicht für jedes Unternehmen beantworten. Seine Einrichtung macht aber deutlich, dass die technische Evaluierung leistungsfähiger KI zu einem eigenständigen Sicherheitsbereich wird. Unternehmen sollten die Einführung autonomer Funktionen deshalb nicht allein als Produktivitätsprojekt behandeln. Erforderlich ist eine Governance, die technische Begrenzungen, Verantwortlichkeiten, Vertragsgestaltung, Tests und Incident Response zusammenführt. Wer diese Grundlagen schafft, kann neue KI-Funktionen nutzen, ohne die Kontrolle über Daten, Systeme und Entscheidungen unnötig aus der Hand zu geben.

Was Unternehmen jetzt tun sollten

• Für agentische KI-Anwendungsfälle Rollen, Freigaben und Verantwortlichkeiten schriftlich festlegen.
• Modell, Werkzeuge, Datenflüsse, Berechtigungen und Unterauftragnehmer in der Beschaffungsprüfung erfassen.
• Verträge um Änderungsanzeigen, Sicherheitsinformationen, Protokollierung, Vorfallmeldungen und Abschaltrechte ergänzen.
• Vor dem produktiven Einsatz adversariale Tests durchführen und die Ergebnisse fortlaufend aktualisieren.

Quelle: BSI, AISI Deutschland; BMDS, AISI Deutschland gegründet, 31. August 2026. (https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/AISI/aisi_node.html)

Eine verpflichtende Angabe der Anrede ist regelmäßig nicht erforderlich, wenn die Leistung auch ohne Geschlechtsangabe erbracht werden kann.

Die Abfrage der Anrede gehört in vielen Formularen zum Standard und wird selten hinterfragt. Der EuGH hat nun klargestellt, dass eine verpflichtende geschlechtsspezifische Anrede regelmäßig nicht mit dem Grundsatz der Datenminimierung nach Art. 5 Abs. 1 c) DS-GVO vereinbar ist, wenn die vertragliche Leistung auch ohne diese Angabe erbracht werden kann.

Der Grundsatz der Datenminimierung verlangt, dass nur solche Daten verarbeitet werden, die für den jeweiligen Zweck tatsächlich erforderlich sind. Erforderlichkeit bedeutet dabei nicht, dass eine Angabe nützlich oder üblich ist. Maßgeblich ist, ob der Zweck ohne sie nicht erreicht werden kann. Für die Anrede lässt sich das in den meisten Konstellationen verneinen: Ein Kaufvertrag, ein Newsletter-Versand oder eine Terminbuchung funktionieren auch ohne Geschlechtsangabe.

Als Rechtfertigung wird häufig eine personalisierte Ansprache angeführt. Dieses Argument trägt jedoch nur begrenzt. Eine höfliche und professionelle Kommunikation ist ohne Weiteres auch mit einer neutralen Formulierung möglich – etwa durch die Anrede mit Vor- und Nachnamen. Ein berechtigtes Interesse an der Personalisierung kann eine Pflichtangabe daher in der Regel nicht begründen, wenn zugleich eine gleichwertige, datensparsamere Alternative zur Verfügung steht.

Für Unternehmen ergibt sich daraus ein konkreter Prüfauftrag. Zunächst sollten sämtliche Kontaktpunkte erfasst werden, an denen die Anrede erhoben wird: Bestellprozesse, Registrierungen, Newsletter-Anmeldungen, Kontaktformulare, Terminbuchungen und Papierformulare. Anschließend ist für jeden Kontaktpunkt zu bewerten, ob die Angabe wirklich benötigt wird. Ist das nicht der Fall, sollte das Feld entfallen oder zumindest optional gestaltet werden.

Zu bedenken ist außerdem die technische Seite. Viele CRM- und Shop-Systeme setzen eine Anrede voraus, um Serienbriefe, E-Mail-Vorlagen und automatisierte Kommunikation korrekt zu erzeugen. Wird das Feld optional, müssen die Vorlagen einen sinnvollen Fallback vorsehen, damit keine unvollständigen Anschreiben entstehen. Ebenso sollte geprüft werden, wie mit bereits gespeicherten Angaben umgegangen wird und ob Bestandsdaten anzupassen sind. Der Aufwand ist überschaubar – der Nutzen liegt in weniger Datenverarbeitung, geringeren Risiken und einer inklusiveren Ansprache.

Das Urteil vom 15. Mai 2026 betrifft die preisrechtliche Einordnung. Die datenschutzrechtlichen Pflichten bleiben davon unberührt.

Digitale Angebote werden häufig ohne Geldzahlung bereitgestellt, während Nutzerinnen und Nutzer im Gegenzug personenbezogene Daten zur Verfügung stellen. Ob dieses Modell verbraucherschutzrechtlich wie ein Preis zu behandeln ist, war zuletzt umstritten. Das OLG Köln hat mit Urteil vom 15. Mai 2026 entschieden, dass die Bereitstellung personenbezogener Daten nicht als „Gesamtpreis“ im Sinne der verbraucherschutzrechtlichen Preisangaben einzuordnen ist.

Für die Praxis bedeutet das zunächst eine Klarstellung bei der Angebotsdarstellung. Unternehmen müssen die Datenbereitstellung nicht wie einen Geldbetrag ausweisen, und die preisrechtlichen Vorgaben lassen sich nicht unmittelbar auf datenbasierte Gegenleistungen übertragen. Das schafft Rechtssicherheit für die Gestaltung von Landingpages, Registrierungsstrecken und kostenlosen Angeboten.

Eine datenschutzrechtliche Entwarnung ist damit jedoch ausdrücklich nicht verbunden. Die Entscheidung betrifft die preisrechtliche Einordnung, nicht die Zulässigkeit der Verarbeitung. Die Informationspflichten nach Art. 13, 14 DS-GVO gelten unverändert: Betroffene müssen transparent, verständlich und leicht zugänglich darüber informiert werden, welche Daten zu welchen Zwecken verarbeitet werden, auf welcher Rechtsgrundlage dies geschieht und wie lange die Daten gespeichert werden.

Besonderes Augenmerk verdient die Rechtsgrundlage. Wird die Verarbeitung auf eine Einwilligung gestützt, muss diese freiwillig, informiert und eindeutig erteilt sein – und sie muss jederzeit ebenso einfach widerrufbar sein, wie sie erteilt wurde. In der Praxis scheitert es hier häufig weniger an der Einholung als am Widerruf: Ist dieser nur umständlich auffindbar oder technisch erschwert, entsteht ein erhebliches Risiko. Ebenso müssen Löschkonzepte tatsächlich greifen und nicht nur auf dem Papier bestehen.

Unternehmen sollten datenbasierte Geschäftsmodelle deshalb konsequent aus zwei Perspektiven prüfen. Preisrechtlich geht es um die Transparenz und Vollständigkeit der Angebotsdarstellung. Datenschutzrechtlich geht es um Rechtsgrundlage, Zweckbindung, Information, Widerruf und Löschung. Beide Prüfungen sind unabhängig voneinander – und ein positives Ergebnis auf der einen Seite ersetzt die andere nicht.