Ausbildung zum zertifizierten Datenschutzbeauftragten
Abo

Aufsatz : Datenschutzrechtliche Verkehrssicherungspflicht: Data Protection by Design : aus der RDV 3/2025, Seite 125 bis 132

Der Beitrag beleuchtet, wie Data Protection by Design als präventive Pflicht im Sinne des Art. 25 Abs. 1 DS-GVO verstanden und praktisch umgesetzt werden kann.

Lesezeit 27 Min.

Die Pflicht zum Schutz Dritter vor Gefahrenquellen ist als sog. Verkehrssicherungspflicht ein im deutschen Zivilrecht stark ausgeprägter, aber allgemeiner Grundsatz. Die Datenschutz-Grundverordnung (DS-GVO) sieht in ihren einzelnen Regelungen Pflichten zur Beherrschung der von einer Verarbeitung personenbezogener Daten ausgehenden Risiken für die betroffenen Personen vor. Das lässt sich als datenschutzrechtliche Verkehrssicherungspflicht verstehen. Der Beitrag betrachtet das Prinzip des „Data Protection by Design“ aus Art. 25 DS-GVO[1] in diesem Verständniskonzept.

I. Datenschutzrechtliche Verkehrssicherungspflicht der DS‑GVO

Die im (deutschen) Zivilrecht geprägte Verkehrssicherungspflicht bildet eine grundlegende Verantwortlichkeit ab. Jeder, der eine Gefahrenlage – gleich welcher Art – schafft, ist grundsätzlich verpflichtet, die notwendigen und zumutbaren Vorkehrungen zu treffen, um eine Schädigung anderer möglichst zu verhindern.[2] Diese Pflicht geht mit der Zulässigkeit des entsprechenden Tuns einher. Nach der Rechtsprechung des BGH sind die Maßnahmen zur Erfüllung der Verkehrssicherungspflicht zu treffen, die ein umsichtiger und verständiger, in vernünftigen Grenzen vorsichtiger Mensch für notwendig und ausreichend hält, um andere vor Schäden zu bewahren.[3] Mit der Erfüllung dieser Verkehrssicherungspflicht geht konsequenterweise die Begrenzung der Verantwortlichkeit und der Haftung einher.[4] Die Verkehrssicherungspflicht beschreibt damit die Grundlage der Haftung und deren Grenzen.

Die Herausforderung in der Praxis besteht in dieser Grenzziehung. Haftungsbegründend ist eine Gefahr, wenn aufgrund einer sachkundigen Bewertung die naheliegende Möglichkeit besteht, dass Rechtsgüter anderer verletzt werden.[5] 

Eine Gefahrenquelle ist nicht per se haftungsbegründend, sondern erst dann, wenn sich aus der konkreten Situation für einen sachkundig Bewertenden die naheliegende Gefahr der Verletzung von Rechtsgütern Dritter ergibt.[6] Haftungsbegrenzend ist nach der Rechtsprechung, dass nicht Vorsorge gegen alle denkbaren Möglichkeiten eines Schadenseintritts getroffen werden muss, womit solche Vorkehrungen ausreichend sind, die geeignet sind, die Schädigung anderer tunlichst abzuwenden.[7]Nicht jeder abstrakten Gefahr muss entgegengewirkt werden.[8] Der BGH hat anerkannt, dass eine Verkehrssicherung, die jede Schädigung ausschließen müsste, im praktischen Leben nicht erreichbar wäre.[9] Eine solche Forderung würde faktisch auf das Verbot des Tuns hinauslaufen. Die Verkehrssicherungspflicht ist erfüllt, wenn im Ergebnis derjenige Sicherheitsgrad erreicht ist, den die in dem entsprechenden Bereich herrschende Verkehrsauffassung für erforderlich hält.[10]Der konkrete Inhalt und Umfang der Verkehrssicherungspflicht lassen sich daher nicht abstrakt, sondern nur im jeweiligen konkreten Einzelfall bestimmen.[11]

Die DS-GVO bildet von Art.  24 DS-GVO ausgehend eine spezialgesetzliche Verkehrssicherungspflicht ab. Nach Art. 24 DS-GVO ist durch technische und organisatorische Maßnahmen die Einhaltung des Datenschutzrechts zu gewährleisten. Mit anderen Worten: Durch geeignete Maßnahme ist der aus der Verarbeitung personenbezogener Daten entstehenden Gefahr für die davon betroffenen natürlichen Personen zu begegnen.

Die Ausführung dieser Verkehrssicherungspflicht erfolgt durch die weiteren Regelungen der DS-GVO. Diese lassen sich insbesondere in vorsorgliche Maßnahmen wie Rechenschaftspflicht (Art. 5 Abs. 2 DS-GVO), proaktive Hinweispflichten (Art. 12, 13, 14 DS-GVO), Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (Art.  25 DS-GVO), Verzeichnis von Verarbeitungstätigkeiten (Art. 30 DS-GVO), Sicherheit der Verarbeitung (Art. 32 DS-GVO), Datenschutz-Folgenabschätzung mit Konsultationsverfahren (Art. 35, 36 DS-GVO), Benennung eines Datenschutzbeauftragten (Art. 37, 38, 39, 35 Abs. 2 DS-GVO, §§ 6, 38 BDSG) und reaktive Maßnahmen Betroffenenrechte (Art. 15 ff. DS-GVO) und Meldung bzw. Benachrichtigung im Falle einer Verletzung des Schutzes personenbezogener Daten (Art. 33, 34 DS-GVO) einteilen.

Diese durch die DS-GVO ausgeprägte Verkehrssicherungspflicht wird durch die Autoren – und durch diese insgesamt erstmals – als „Datenschutzrechtliche Verkehrssicherungspflicht“ (DS-VSP) bezeichnet.[12] Die Datenschutzrechtliche Verkehrssicherungspflicht ist allerdings keine eigenständig oder zusätzlich haftungsbegründende Rechtsfigur. Sie kennzeichnet den der DS-GVO zugrunde liegenden Ansatz und bietet eine weitere Perspektive auf die risikobasierten Pflichten der DS-GVO. Die Datenschutzrechtliche Verkehrssicherungspflicht lässt sich wie folgt definieren – so die Autoren bereits ausdrücklich zuvor: Wer durch seine Verarbeitung personenbezogener Daten eine Gefahrenquelle schafft, muss die erforderlichen Maßnahmen ergreifen, um die von seiner (jeweiligen) konkreten Gefahr ausgehenden Risiken für die betroffenen Personen zu beherrschen.[13]Das durch die Autoren vertretene Verständnis der Datenschutzrechtlichen Verkehrssicherungspflicht ist als die gesamtheitliche Betrachtung und Einhaltung dieser Regelungen zu verstehen, auch wenn die Ausprägungen jeweils in den einzelnen Normen konkretisiert werden.

Ausgehend vom Wortlaut ist der Datenschutzrechtlichen Verkehrssicherungspflicht das Absichern gegen Risiken und Schäden. Aus diesem Grund liegt es nahe, die Datenschutzrechtliche Verkehrssicherungspflicht entlang den Vorgaben der spezifischen Sicherheits-Vorschrift der DS-GVO, nämlich Art.  32 DS-GVO, zu interpretieren.[14] Doch in diesem Beitrag soll der Blick auf eine ebenfalls vorsorgliche, aber aufgrund ihrer Ausprägung besondere Vorschrift geweitet werden: Die Pflicht zu Data Protection by Design & by Default (Art. 25 DS-GVO) besteht bereits „bei der Festlegung der Mittel“ und damit vorbeugend. Sie ist aber insoweit besonders, weil in der heutigen digitalen Welt der datenschutzrechtlich Verantwortliche (Art. 4 Nr. 7 DS-GVO) – anders, als die DS-GVO nahelegt – nicht stets frei die Mittel der Verarbeitung selbst festlegen kann, sondern auf durch die Anbieter der Datenverarbeitung vordefinierte Mittel angewiesen ist, die jedoch selbst nicht durch die DS-GVO und insbesondere nicht durch Art.  25 DS-GVO verpflichtet sind. Denn die Anbieter selbst nehmen die Verarbeitung nicht als Verantwortliche im Sinne der DS-GVO vor.

Der AI Act (KI-Verordnung, KI-VO) ist ebenfalls ein durch die Verkehrssicherungspflicht geprägter Rechtsakt. Er erlaubt das durch den Einsatz von KI-Systeme und KI-Modellen mit allgemeinem Verwendungszweck ausgehende Risiko, sofern die durch den AI Act festgelegten und als ausreichend betrachteten Maßnahmen zur Risikobeherrschung umgesetzt sind.[15] Als – im Gegensatz zur DS-GVO – Produktsicherheitsrecht trägt der AI Act dem Umstand, dass die Betreiber von KI-Systemen (siehe Art. 26, 27, 50 Abs.  3 und 4 AI Act) nicht alles selbst entwickeln, dadurch Rechnung, dass auch die Anbieter (neben den übrigen Akteuren der gesamten Wertschöpfungskette) eigenständig in die Pflicht genommen werden (Art. 16 ff., Art. 50 Abs. 1 und 2 AI Act). Hier wird deutlich, dass das Produktsicherheitsrecht die Fortentwicklung der Verkehrssicherungspflicht ist. Der Cyber Resilience Act hat als Produktsicherheitsrecht ebenfalls eine grundsätzliche vergleichbare Ausprägung.

Die DS-GVO darf gleichwohl nicht als Produktsicherheitsrecht missinterpretiert werden. Sie schützt die Grundfreiheiten der jeweiligen betroffenen Person individuell.

II. Data Protection by Design und die DS-VSP

Die datenschutzrechtliche Verkehrssicherungspflicht wird häufig nur als reaktive Pflicht verstanden, die dann entsteht, wenn aufgrund eines Zustands oder einer Handlung eine Gefahr für diejenigen entsteht, die mit der Gefahrenquelle in Berührung kommen. Würde die Datenschutzrechtliche Verkehrssicherungspflicht nur in diesem Sinn verstanden, erschiene die Pflicht zu Data Protection by Design als Fremdkörper, weil hierdurch die Pflichten auf den Zeitpunkt der Entstehung der Gefahrenquelle verlegt werden.

1. Data Protection by Design (Art. 25 Abs. 1 DS-GVO) als vorsorgende Pflicht?

Vorsorge ist dem risikobasierten Prinzip, nach dem die DS-GVO ebenso wie andere europäische Digitalrechtsakte geformt sind, immanent. Das Risiko, das mit der Verarbeitung personenbezogener Daten einhergeht, muss ausreichend eingedämmt sein. Die Rechte und Freiheiten natürlicher Personen sollen stets gewahrt sein. Nach Möglichkeit sollen sich von vornherein vermeidbare Risiken gar nicht erst realisieren und damit auch kein Schaden für die betroffenen Personen eintreten. Zu diesem Zweck muss der Verantwortliche technische und organisatorische Maßnahmen (TOMs) treffen, wie sie in Art. 24, 25, 32, 35 DS-GVO aufgeführt sind, sozusagen „Ex-ante-Maßnahmen“. [16]„Ex-post-Maßnahmen“ hingegen spielen dann eine Rolle, wenn etwas schiefgegangen ist: Im Fall einer Verletzung des Schutzes personenbezogener Daten, die in Art. 33, 34 DS-GVO geregelt ist, muss der Verantwortliche berichten, welche Abhilfemaßnahmen (Art. 33 Abs. 3 Buchst. d sowie Abs. 5) zur Behebung der Verletzung der Datenpanne und zur Abmilderung ihrer möglichen Auswirkungen vorgeschlagen werden oder ergriffen worden sind[17]. In solchen Fällen bewähren sich im Voraus erstellte Notfallpläne oder andere Maßnahmen zum sog. Business Continuity Management.[18] Das bedeutet: Auch die Ex-anteBeschäftigung mit einer möglichen Verletzung des Schutzes personenbezogener Daten kann und sollte sich in TOMs niederschlagen.

Im Ergebnis mag nur formal eine Unterscheidung in „exante“- und „ex-post“-Maßnahmen möglich erscheinen, der der DS-GVO immanente Ansatz führt jedoch dazu, dass auch für die „ex-post“-Maßnahmen im Voraus Vorkehrungen getroffen werden müssen.

Zwei Regelungen der DS-GVO machen besonders deutlich, dass die Beschäftigung mit dem der Verarbeitung innewohnenden Risiko schon notwendig ist, bevor überhaupt ein personenbezogenes Datum verarbeitet wurde:

  • Art. 35 DS-GVO regelt die Datenschutz-Folgenabschätzung. Bei einer Form der Verarbeitung, die voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat, „führt der Verantwortliche vorab eine Abschätzung der Folgen der vorgesehenen Verarbeitungsvorgänge für den Schutz personenbezogener Daten durch“ – so formuliert es Art. 35 Abs. 1 DS-GVO. Das bedeutet, dass für den Fall eines mutmaßlich hohen Risikos eine DatenschutzFolgenabschätzung vor Beginn der Verarbeitung zu erfolgen hat – mit dem möglichen Ergebnis, dass die Verarbeitung nicht wie geplant stattfinden darf, sondern es anderer technischer oder organisatorischer Maßnahmen bedarf oder von der Verarbeitung ganz abgesehen werden muss. Die Feststellung, ob der Fall des voraussichtlich hohen Risikos vorliegt, ist ebenfalls der Verarbeitung vorgelagert. Hierzu muss der Verantwortliche für jede Verarbeitung in einer SchwellwertAnalyse prüfen, ob anzunehmen ist, dass das mit der Verarbeitung verbundene Risiko eine Datenschutz-Folgenabschätzung erforderlich macht.
  • In ähnlicher Weise zeigt die Formulierung des Art.  25 DS-GVO als zentrale Norm mit den Anforderungen an die datenschutzgerechte Gestaltung der Verarbeitung, dass den Verantwortlichen vor Beginn der Verarbeitung bestimmte Pflichten treffen. Data Protection by Design soll durch geeignete technische und organisatorische Maßnahmen umgesetzt werden. Diese Pflicht obliegt dem Verantwortlichen „sowohl zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung als auch zum Zeitpunkt der eigentlichen Verarbeitung“, Art. 25 Abs. 1 DS-GVO. Der Zeitpunkt der Festlegung der Mittel der Verarbeitung ist offensichtlich der tatsächlichen Verarbeitung vorgelagert. Das ist auch sachgerecht, denn bereits die Auswahl der Mittel der Verarbeitung ist entscheidend dafür, ob und wie sich die personenbezogenen Daten im Einklang mit den datenschutzrechtlichen Anforderungen verarbeiten lassen. Auch Art. 25 Abs. 2 DS-GVO ist im Vorfeld der Verarbeitung verankert: Denn die dort geregelten Anforderungen an die datenschutzfreundlichen Voreinstellungen[19] müssen von Anfang an umgesetzt sein – sonst wären es ja auch keine „Vor“-Einstellungen.

Das Vorsorgeprinzip, das die gesamte DS-GVO durchzieht, wird also in den Regelungen zur Datenschutz-Folgenabschätzung (Art. 35 DS-GVO) und zu „Data Protection by Design and by Default“ (Art. 25 DS-GVO) expliziert. Ein Verantwortlicher, der personenbezogene Daten „einfach drauflos verarbeitet“, ohne sich jemals um das Risiko – zumindest im Rahmen der Schwellwert-Analyse – und um dementsprechende Gestaltungsanforderungen gekümmert zu haben, kann damit bereits gegen die DS-GVO verstoßen, selbst wenn quasi zufällig das mit der Verarbeitung einhergehende Risiko durch vorhandene technische und organisatorische Maßnahmen ausreichend eingedämmt wird. Andersherum werden all diejenigen Verantwortlichen, die ein funktionierendes Datenschutz-Managementsystem betreiben, sich von Anfang an und über den vorhersehbaren gesamten Lebenszyklus der Verarbeitung personenbezogener Daten mit der Einhaltung der datenschutzrechtlichen Anforderungen wie der Umsetzung der Datenschutz-Grundsätze aus Art. 5 DS-GVO sowie der effektiven und dauerhaften Eindämmung des Risikos durch technische und organisatorische Maßnahmen beschäftigen und dies auch dokumentieren. Damit erfüllen sie automatisch Art. 25 und 35 DS-GVO sowie die Rechenschaftspflicht in Art. 5 Abs. 2 und Art. 24 DS-GVO.

2. VSP als proaktive Pflicht?

Data Protection by Design fügt sich insoweit in die Datenschutzrechtliche Verkehrssicherungspflicht ein, als auch die Verkehrssicherungspflicht nicht auf rein reaktive Pflichten beschränkt ist.[20] Entstehen Gefährdungslagen hingegen nicht spontan, sondern vorhersehbar durch ein Tun – also wie bei der Aufnahme eine Verarbeitung personenbezogener Daten – sind bereits mit der Eröffnung der Gefahrenquellen die erforderlichen Maßnahmen zum Schutz vor den hiervon ausgehenden Risiken zu treffen.[21]Eine Parallelität besteht dementsprechend auch insoweit, wie die erforderlichen Maßnahmen zu bestimmen sind, und dass sich auch hieraus Grenzen der Pflichtenstellung ergeben.[22]

Deutlicher wird dies in der im Deliktsrecht des BGB als spezielle Ausprägung der Verkehrssicherungspflicht entwickelten Produzentenhaftung des Herstellers. Der Anknüpfungspunkt für die deliktsrechtliche Produzentenhaftung ist Verletzung der herstellerseitigen Verkehrssicherungspflicht, deren Auswirkung als Produktfehler bezeichnet wird.[23]Diese werden unterschieden in Konstruktionsfehler, Fabrikationsfehler, Instruktionsfehler und Produktbeobachtungspflichten.[24]

Diese Ausprägung macht deutlich, dass die Verkehrssicherungspflicht bereits Pflichten vor der eigentlichen Eröffnung der Gefahrenquelle zur Vermeidung und Minimierung der dadurch entstehenden Gefahren schafft.

Diese Produzentenhaftung ist von der sog. Produkthaftung nach dem Produkthaftungsgesetz, das zeitlich erst nach der Entwicklung der Grundsätze der Produzentenhaftung entstanden ist, zu unterscheiden. Die Produkthaftung ist im Gegensatz zur Produzentenhaftung eine verschuldensunabhängige Gefährdungshaftung[25] der Hersteller im Sinne des § 4 ProdHaftG für die in § 2 ProdHaftG genannten Produkte in den Grenzen des ProdHaftG (§ 1 Abs. 2 ProdHaftG). Aufgrund der enge des Anwendungsbereichs – so ist insbesondere die Anwendung auf Software[26]und insbesondere auf KI-Software[27] als Produkt im Sinne des ProdHaftG umstritten – spielt die Produzentenhaftung im IT-Sicherheitsrecht gleichwohl eine wesentliche Rolle.[28]

3. Haftung des Herstellers nach Art. 25 Abs. 1 DS-GVO

Die Pflichten zur zivilrechtlichen Mängelfreiheit und die deliktische Haftung für die Verletzung von Verkehrssicherungspflichten lassen sich dahingehend – wenngleich umstritten – auslegen, dass die Pflicht des Herstellers besteht, nur datenschutzkonform nutzbare Produkte – also Mittel im Sinne der DS-GVO – bereitzustellen. Unabhängig davon, wie diese umstrittenen Einzelheiten letztlich auszulegen sind, hängen diese wesentlich vom Verständnis der DS-GVO und damit auch des Art. 25 Abs. 1 DS-GVO ab. Während die Voraussetzungen der Haftung[29]vorliegend nicht vertieft untersucht werden können, werden die Anforderungen an die Gestaltung nach Art. 25 Abs. 1 DS-GVO weitergehend zu untersuchen.

III. DS-VSP in Form des Data Protection by Design

Data Protection by Design lässt sich als besondere Ausprägung der Datenschutzrechtlichen Verkehrssicherungspflicht verstehen. Data Protection by Design geht insbesondere über den Grundsatz der Datenminimierung hinaus und prägt damit stärker die der DS-GVO auch damit immanente Datenschutzrechtliche Verkehrssicherungspflicht.

1. Zielrichtung des Prinzips von „Datenschutz durch (Technik-)Gestaltung)“

 Art.  25 DS-GVO ist betitelt als „Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen“. Vergleicht man die verschiedenen Sprachfassungen der DS-GVO, erkennt man schnell, dass der Begriff „Technik“ in den meisten Sprachen gar nicht vorkommt.[30] Tatsächlich geht es im Art. 25 DS-GVO auch nicht um Technikgestaltung, sondern ganz generell um die Gestaltung der Verarbeitung personenbezogener Daten mit technischen und organisatorischen Maßnahmen.

Viele Verantwortliche denken bei Art.  32 DS-GVO (richtigerweise) an Sicherheit und bei Art.  25 DS-GVO (verkürzt) an Datenminimierung. Es ist zwar zutreffend, dass in Art. 25 Abs.  1 DS-GVO die Datenminimierung als Beispiel besonders hervorgehoben ist und auch Art.  25 Abs.  2 DS-GVO mit den datenschutzfreundlichen Voreinstellungen eine besondere Verwandtschaft zur Datenminimierung (und Speicherbegrenzung) aufweist. Art.  25 DS-GVO dennoch universeller formuliert: Es geht um sämtliche Datenschutzgrundsätze; Art. 25 Abs. 1 DS-GVO ruft insoweit den gesamten Art. 5 DS-GVO auf. So heißt es in Art. 25 Abs. 1 DS-GVO:

„geeignete technische und organisatorische Maßnahmen, die dafür ausgelegt sind, die Datenschutzgrundsätze wie etwa Datenminimierung wirksam umzusetzen und die notwendigen Garantien in die Verarbeitung aufzunehmen, um den Anforderungen dieser Verordnung zu genügen und die Rechte der betroffenen Personen zu schützen.“ Die Maßnahmen, die der Verantwortliche treffen muss, müssen einerseits für die wirksame Umsetzung der Datenschutzgrundsätze ausgelegt sein und andererseits für die notwendigen Garantien sorgen, um – vollständig – die DS-GVO zu erfüllen und – erneut betont – die Rechte der betroffenen Personen, nämlich Kapitel III der DS-GVO mit den Art. 12 bis 23, zu schützen.

Damit wird deutlich: Art. 25 Abs. 1 DS-GVO formuliert umfassende Gestaltungsanforderungen an die Verarbeitung – und zwar mit der Zielrichtung, das Risiko für die Rechte und Freiheiten natürlicher Personen, die in Art.  8 der Europäischen Grundrechte-Charta niedergelegt sind, ausreichend einzudämmen. Insoweit ist Art. 32 DS-GVO, der sich aus dem Datenschutzgrundsatz aus Art. 5 Abs. 1 lit. f) DS-GVO „Integrität und Vertraulichkeit“[31] ableitet, „nur“ eine Konkretisierung des Gestaltungsauftrags aus Art. 25 DS-GVO, der wiederum eine Konkretisierung des Art. 24 DS-GVO darstellt.

Abb. 1: Veranschaulichung der Einbettung des Art. 25 in der DS‑GVO[32]

In jedem Fall muss das Eindämmen des Risikos von Anfang an und über den gesamten vorhersehbaren Lebenszyklus erfolgen. Das regeln sowohl Art. 25 Abs. 1 DS-GVO („zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung als auch zum Zeitpunkt der eigentlichen Verarbeitung“) als auch Art.  32 Abs.  1 DS-GVO mit den Anforderungen „die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung auf Dauer sicherzustellen“ (Art. 32 Abs. 1 lit. b) DS-GVO) sowie eines Verfahrens „zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung“ (Art. 32 Abs. 1 lit. d) DS-GVO).

2. Maßnahmen des Art. 25 DS-GVO i.S.d. DS-VSP

Art. 25 DS-GVO enthält – wie zuvor dargestellt – die Pflicht zur datenschutzkonformen Gestaltung der Verarbeitung insgesamt. Das bedeutet, dass das Risiko für die Rechte und Freiheiten natürlicher Personen, das mit der Verarbeitung personenbezogener Daten einhergeht, ausreichend eingedämmt werden muss. Im Bereich der Sicherheit – also zum Schutz vorhandener personenbezogener Daten gegen Missbrauch oder Verlust, wie dies der Datenschutzgrundsatz „Integrität und Vertraulichkeit“ formuliert – ist dies unmittelbar einleuchtend. Doch dasselbe gilt auch für die anderen Datenschutzgrundsätze aus Art.  5 DS-GVO: Der EU-Gesetzgeber beschreibt nämlich mit diesen Datenschutzgrundsätzen, was zu tun ist, um die den Datenschutz charakterisierenden Risiken einzudämmen: So steht neben dem Risiko von zu wenig Sicherheit (Art. 5 Abs. 1 lit. f) DS-GVO) beispielsweise das Risiko von zu wenig Transparenz für die betroffenen Personen (Art. 5 Abs. 1 lit. a) DS-GVO), das Risiko von zu wenig Richtigkeit der personenbezogenen Daten (Art. 5 Abs. 1 lit. d DS-GVO) oder das Risiko von zu wenig Speicherbegrenzung (Art.  5 Abs.  1 lit.  e) DS-GVO). Dies lässt sich für alle Datenschutzgrundsätze ausführen: Betrachtet man die Umkehrung (also: „Abwesenheit von/Mangel bei ausreichender Umsetzung dieses Datenschutzgrundsatzes“), ergeben sich die zu behandelnden Risiken. Darunter fallen alle Arten von Gefährdungen (d.h. auch fahrlässiges und vorsätzliches Verhalten, das die Rechte und Freiheiten natürlicher Personen bedroht) und sowohl externe (=außerhalb des Verantwortlichen) als auch interne Risikoquellen – wie man es für den Bereich der Datensicherheit kennt.

Mit dieser Lesart handelt es sich bei den Datenschutzgrundsätzen in Art. 5 DS-GVO um eine zwischengeschobene Ebene zur Konkretisierung oder Operationalisierung des in der Europäischen Grundrechte-Charta formulierten Schutzes der Rechte und Freiheiten. Doch auch diese Datenschutzgrundsätze sind abstrakt formuliert und in ihrem genauen Umfang nicht ganz klar konturiert.[33] So lässt sich diskutieren, ob die – ja wohl doch grundlegenden[34] – Betroffenenrechte aus Kapitel III der DS-GVO tatsächlich unmittelbar und vollständig im Datenschutzgrundsatz von „Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz“ nach Art. 5 Abs. 1 lit. a) DS-GVO zum Ausdruck kommen sollen. Für die Anwendung des Art. 25 DS-GVO spielt dieser Punkt jedoch keine Rolle, da diese Norm sowohl die Datenschutzgrundsätze als auch explizit die Rechte der betroffenen Personen aufgreift. Im Ergebnis dient also die Umsetzung des Art. 25 DS-GVO – mit Rückgriff auf die Datenschutzgrundsätze aus Art.  5 DS-GVO sowie die Rechte der betroffenen Personen aus Kapitel III DS-GVO – in Konkretisierung der Rechte und Freiheiten aus der Europäischen Grundrechte-Charta der Risikobeherrschung. Damit ist nicht nur Art. 32 DS-GVO, wie bereits an anderer Stelle verdeutlicht,[35] sondern auch Art. 25 DS-GVO zentral für die Datenschutzrechtliche Verkehrssicherungspflicht.

Einen Überblick über technische und organisatorische Maßnahmen, die sich zur Umsetzung des Art.  25 DS-GVO eignen, geben beispielsweise die Leitlinien des Europäischen Datenschutzausschusses zu Art. 25 DS-GVO[36] und die Übersichten im Standard-Datenschutzmodel (SDM)[37] einschließlich der zugehörigen Bausteine[38]. Zu den Maßnahmen des Art. 25 Abs. 1 DS-GVO, die sich nicht zugleich unmittelbar aus Art.  32 DS-GVO ableiten lassen, gehören beispielsweise das Vorsehen von Löschmöglichkeiten nach der Speicherfrist in einer Verarbeitung, Maßnahmen zur Transparenz über die Verarbeitung oder Trennungen oder Entkopplungen von personenbezogenen Anteilen der Verarbeitung[39].

3. Cyber Resilience Act: Lücke geschlossen?

Der Cyber Resilience Act (CRA, Cyberresilienz-Verordnung) adressiert Produkte mit digitalem Inhalt und deren Anbieter. Auf den ersten Blick scheint der CRA damit eine spiegelbildliche Flankierung der Pflicht zu Art.  25 DS-GVO zu sein. Um es vorweg zu nehmen: Obgleich der CRA den Schutz personenbezogener Daten fördert, schließt die durch die Nichtadressierung von Anbietern in Art.  25 DS-GVO geschaffene Lücke gleichwohl nicht. Denn zum einen erfasst der CRA nur „Produkt mit digitalen Elementen“ was in Art.  3 Nr.  1 CRA legaldefiniert ist als „ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden“. Zum anderen ist der CRA als Produktsicherheitsrecht allgemein am Schutz vor den von Produkten mit digitalen Elementen Gefahren und nicht am Schutz der betroffenen Person durch Verarbeitung deren personenbezogener Daten ausgerichtet.[40]

Mit Art.  25 DS-GVO haben Verantwortliche zwar die Pflicht zur datenschutzgerechten Gestaltung ihrer Verarbeitung. Ihre Gestaltungsoptionen hängen jedoch von den eingesetzten Hard- und Software-Produkten ab. Nicht alle Hersteller haben ihre Produkte nicht so entwickelt, dass es für diejenigen, die diese Produkte verwenden, leicht ist, die Anforderungen der DS-GVO zu erfüllen bzw. deren Erfüllung nachzuweisen. Die DS-GVO enthält auch gar keine Pflichten für Hersteller. Diese werden lediglich im ErwG 78 DS-GVO erwähnt, wonach Hersteller „ermutigt“ werden sollten, das Recht auf Datenschutz bei der Entwicklung und Gestaltung der Produkte, Dienste und Anwendungen zu berücksichtigen.[41] Auswirkungen kann dies beispielsweise in Bezug auf Ausschreibungen zur Beschaffung von Produkten haben, jedoch ist der Status quo noch unbefriedigend.

Änderungen könnte der Cyber Resilience Act (CRA) bringen, der am 11.12.2024 in Kraft getreten ist und die Erhöhung der Cybersicherheit zum Ziel hat. So verlangt der CRA vom Hersteller von Produkten mit digitalen Elementen – das sind insbesondere Hard- und Software-Produkte, die sich vernetzen lassen –, dass diese gemäß dem Prinzip von „Security by Design“ entwickelt wurden. Vor dem Inverkehrbringen des Produkts muss der Hersteller dies mit einer Konformitätserklärung belegen. Weiterhin werden Hersteller zu einem funktionierenden Schwachstellenmanagement über einen definierten Zeitraum verpflichtet.

„Security by Design“ ist allerdings nicht dasselbe wie „Data Protection by Design“. Die Verantwortlichen können daher nicht erwarten, dass ab vollständiger Geltung des CRA am 11.12.2027 jeder Einsatz von vernetzten Produkten automatisch datenschutzfreundlich voreingestellt ist oder sich jedenfalls ohne großen Aufwand datenschutzgerecht realisieren lässt. Der genaue Blick in den CRA und insbesondere die Anhänge mit den Anforderungen an Hersteller zeigt jedoch, dass durchaus Positives für die Erfüllung der Datenschutzpflichten abfällt:[42]

Hersteller müssen zum Durchführen des künftig notwendigen Konformitätsbewertungsverfahrens eine technische Dokumentation nach Art. 31 CRA erstellen. Die Inhalte dieser technischen Dokumentation sind vor allem im Anhang VII („Inhalt der technischen Dokumentation“) mit Verweis auf Anhang II („Informationen und Anleitungen für den Nutzer“) des CRA festgelegt.

Während die Informationen für Nutzende zielgruppengerecht – d.h. zumeist für technische Laien – verständlich sein sollen und mit dem Produkt zusammen als Anleitung zum Einsatz bereitgestellt werden, beinhaltet die technische Dokumentation insgesamt die notwendigen Aussagen zur Bewertung der Konformität mit den Cybersicherheitsanforderungen. So muss die technische Dokumentation verständlich für die Marktüberwachungsbehörden nach dem CRA sein, Art. 53 i.V.m. Art. 31 Abs. 4 CRA. In der technischen Dokumentation werden also vertiefte Darstellungen enthalten sein, die von Fachexpertinnen und -experten geprüft werden können.

So müssen die praktischen Informationen für die Nutzenden beispielsweise umfassen, welche Maßnahmen bei der ersten Inbetriebnahme des Produkts und während seiner gesamten Lebensdauer getroffen werden müssen, um dessen sichere Verwendung sicherzustellen (Anhang II Nr. 8 lit. a) CRA) und wie eine sichere Außerbetriebnahme des Produkts erfolgt und wie Nutzerdaten sicher entfernt[43]werden können (Anhang II Nr. 8 lit. d) CRA). Ebenso müssen die Nutzenden auf typische Fehlanwendungen hingewiesen werden, die zu erheblichen Cybersicherheitsrisiken führen können, informiert werden (Anhang II Nr. 5 CRA).

Die technische Dokumentation enthält Aussagen darüber, wie das Produkt die grundlegenden Cybersicherheitsanforderungen aus Anhang I erfüllt (Anhang VII Nrn. 1, 3 CRA). Dazu gehören sowohl Erläuterungen zur Konzeption, Entwicklung und Herstellung des Produkts (Anhang VII Nr. 2 CRA) als auch die Berichte über Tests und Prüfungen zur Konformitätsbewertung und Behandlung von Schwachstellen (Anhang VII Nr. 6 CRA). Auch die Software-Stückliste (Software Bill of Materials, SBOM) kann Teil der technischen Dokumentation sein und Risiken sichtbar machen, die aufgrund der Software-Lieferkette entstehen.[44]

Da der CRA auf „Sicherheit by Design“ zielt, profitiert der Verantwortliche in der Regel von mit den Cybersicherheitsanforderungen konformen Produkten (und ihrer technischen Dokumentation) bei der Umsetzung der Art. 25, 32 DS-GVO.[45]Dies gilt insbesondere, weil nicht nur die klassischen Schutzziele der Cybersicherheit wie Vertraulichkeit, Integrität und Verfügbarkeit zu den Anforderungen gehören, sondern auch die Datenminimierung:

„Auf der Grundlage der Bewertung der Cybersicherheitsrisiken gemäß Art. 13 Abs. 2 müssen Produkte mit digitalen Elementen, soweit zutreffend,

g) die Verarbeitung personenbezogener oder sonstiger Daten auf solche, die angemessen und von Bedeutung sind, und auf das für die Zweckbestimmung des Produkts mit digitalen Elementen erforderliche Maß beschränken („Datenminimierung“), (Art. 31 Abs. 1 i.V.m. Anhang I, Teil I Abs. 2 lit. g) CRA).

Achtung: Datenminimierung i.S.d. CRA ist nicht identisch mit der Datenminimierung i.S.d. DS-GVO, aber doch verwandt. Die dahinterliegende Grundüberlegung ist jedoch sowohl bei der Cybersicherheit als auch im Datenschutz, dass eine Verarbeitung von für den Zweck überflüssigen Daten ein Risiko bedeutet.

Im Datenschutzrecht entscheidet grundsätzlich der Verantwortliche über die Zwecke und Mittel der Verarbeitung personenbezogener Daten, Art. 4 Nr. 7 DS-GVO. Ein Hersteller, der mit seinem Produkt ein Verarbeitungsmittel bereitstellt, kann in der Regel nicht oder nicht sicher wissen, welche konkreten Zwecke der Verantwortliche verfolgen wird. Dies gilt insbesondere für Produkte, die zweckübergreifend einsetzbar sind oder als Teil einer Infrastruktur betrachtet werden können, wie beispielsweise eine Office-Suite, eine Datenbank-Software oder eine Programmierumgebung. Doch auch in diesen Fällen würde es dem Verantwortlichen bei der Auswahl der eingesetzten Mittel und bei der Erfüllung der Rechenschaftspflicht helfen, wenn ihm die Informationen aus der technischen Dokumentation zu der Umsetzung der Cybersicherheitsanforderungen einschließlich der Datenminimierung i.S.d. CRA zur Verfügung gestellt würden, da dies eine Basis darstellt, auf der er seine datenschutzrechtlichen Pflichten regelmäßig effektiver und effizienter umsetzen kann.

Der CRA verpflichtet zwar den Hersteller, die technische Dokumentation zu erstellen (Art. 13 Abs. 12 S. 1 CRA) und auf Anfrage den zuständigen Behörden zur Marktüberwachung vorzulegen (Art.  53 CRA). Eine Pflicht zur Veröffentlichung oder zur Bereitstellung gegenüber Kunden besteht allerdings nicht. Es obliegt also (weiterhin) dem datenschutzrechtlich Verantwortlichen, der ein Produkt auswählen und einsetzen will, sich die für die Erfüllung der datenschutzrechtlichen Rechenschaftspflicht nötigen Informationen zu verschaffen. Immerhin wird es mit Geltung des CRA einen Fortschritt geben: Sofern es sich um Pflichtangaben für die technische Dokumentation handelt, müssen diese Informationen beim Hersteller stets aktuell (Art. 31 Abs. 2 CRA) vorliegen.

IV. Fazit

Der Beitrag zeigt auf, dass Data Protection by Design so verstanden werden kann, dass in der Gestaltung der Verarbeitung bereits vorausschauend die in der DS-GVO angelegten Grundsätze und Anforderungen berücksichtigt werden. Der Beitrag soll damit die Diskussion um das Verständnis des Art. 25 Abs. 1 DS-GVO und seine inhaltliche Ausgestaltung voranbringen und beleuchtet hierzu seine Bedeutung im Kontext der Datenschutzrechtlichen Verkehrssicherungspflicht.

Dr. Jens Eckhardt ist Rechtsanwalt und Fachanwalt für ITRecht
sowie Datenschutz-Auditor (TÜV) und IT-Compliance Manager (TÜV), pitc
legal Eckhardt Rechtsanwälte Partnerschaft mbB

Dr. h.c. Marit Hansen ist Diplom-Informatikerin und Landesbeauftragte
für Datenschutz Schleswig-Holstein.

[1] Der Einfachheit halber wird die Bezeichnung des Art. 25 DS-GVO in der englischen Sprachfassung ( „Data Protection by Design and by Default“) verwendet. In der deutschen Sprachfassung lautet die Überschrift des Art. 25 DS-GVO „Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen“. Im Übrigen ist dies nicht identisch mit dem insbesondere von Cavoukian geprägten Konzept des „Privacy by Design“, 2009/2011, https://www.ipc.on.ca/en/media/1826/download?attachment.

[2] BGH, NJW 2007, 1683, 1684; VersR 1990, 498, 499; VersR 2002, 247, 248; VersR 2005, 279, 280; VersR 2006, 233.

[3] BGH, NJW 2007, 1683, 1684 m.w.N.; vgl. Hornung/Schallbruch, IT-Sicherheitsrecht, 2. Aufl., 2024, § 9 Rn. 107; vgl. Leupold/Wiebe/Glossner, IT-Recht, 4. Aufl. 2021, Teil 7.1 Rn. 127.

[4] BGH, NJW 2007, 1683, 1684, vgl. VersR 1975, 812; VersR 2003, 1319; VersR 2006, 233; VersR 2006, 1083.

[5] BGH, NJW 2007, 1683, 1684; NJW 2006, 610 m.w.N. Die Verkehrssicherungspflicht ist nicht die alleinige haftungsbegründende Voraussetzung. Jedenfalls außerhalb der Haftung nach ProdHaftG ist stets auch das Verschulden des Verpflichteten eine zentrale Voraussetzung der Haftung. Dementsprechend begründet weder der objektive Verstoß gegen eine Verkehrssicherungspflicht noch der objektive Verstoß gegen Art.  25 DS-GVO eine Haftung auf Schadensersatz.

[6] Grüneberg, Bürgerliches Gesetzbuch, § 823 BGB Rn. 46.

[7] BGH, NJW 2007, 1683, 1684, vgl. VersR 1978, 1163, 1165, NJW 2006, 610.

[8] BeckOK IT-Recht, 17. Edition; Stand: 01.04.2023, § 823 BGB Rn. 44.

[9] BGH, NJW 2007, 1683, 1684, vgl. VersR 1972, 559, 560, VersR 2006, 233.

[10] BGH, NJW 2007, 1683, 1684, vgl. VersR 1972, 559, 560, VersR 2006, 233; Hornung/Schallbruch, IT-Sicherheitsrecht, 2. Aufl., 2024; § 12 Rn. 29, die in erster Linie auf die berechtigten Sicherheitserwartungen der betroffenen Verkehrskreise abstellen

[11] BeckOK IT-Recht, 17. Edition; Stand: 01.04.2023, § 823 BGB Rn. 44.

[12] Die bis dahin – soweit ersichtlich – nicht verwendete Bezeichnung wurde erstmals durch die Autoren verwendet (Eckhardt/Hansen, BvD-News 2023, Heft 2, 20-27); siehe auch Eckhardt/Hansen, DuD, 2024, 561–565.

[13] So bereits wörtlich: Eckhardt/Hansen, DuD 2024, 562; Eckhardt/Hansen, BvDNews 2023, Heft 2, 21

[14] Ausführlich, in: Eckhardt/Hansen, BvD-News 2023, Heft 2, 20-27 sowie Eckhardt/Hansen, DuD 2024, 561–565.

[15] Die nach Art. 5 AI Act sog. verbotenen Praktiken werden hier nicht betrachtet, weil sie gerade durch die AI Act verboten sind.

[16] Unter Geltung der DS-GVO ist es anders als nach dem BDSG a.F. auch nicht (mehr) zutreffend „TOMs“ als Synonym für Maßnahmen der Sicherheit der Verarbeitung (Art. 32 DS-GVO, § 9 BDSG a.F.) zu verstehen, weil solche durch die DS-GVO in weiterem Umfang gefordert werden.

[17] Bspw. weist der EDSA insoweit zutreffend darauf hin, dass Vorkehrungen für den Fall der Verletzung des Schutzes personenbezogener Daten Bestandteil der Pflichten nach Art. 32 DS-GVO sein können (EDSA, Leitlinien 9/2022 für die Meldung von Verletzungen des Schutzes personenbezogener Daten gemäß der DS-GVO, Version 2.0, Datum der Annahme: 28.03.2023, Rn. 41).

[18] BSI, Business Continuity Management, BSI-Standard 200-4, 2023.

[19] Europäischer Datenschutzausschuss, Leitlinien 4/2019 zu Art. 25 – Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen, Version 2.0, angenommen am 20.10.2020, S. 12 ff., https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines42019-article-25-data-protection-design-and_de.

[20] Vgl. Grüneberg, Bürgerliches Gesetzbuch, § 823 BGB Rn. 45 ff.

[21] Vgl. Hornung/Schallbruch, IT-Sicherheitsrecht, 2. Aufl., 2024, § 12 Rn. 29; vgl. BeckOK IT-Recht, 17. Edition; Stand: 01.04.2023, § 823 BGB Rn. 44.

[22] Siehe oben Ziffer 1.

[23] Statt vieler: Sassenberg/Faber, Rechtshandbuch Industrie 4.0 und Internet of Things, 2. Aufl., 2020, § 4 Ziffer 1 b).

[24] Statt vieler: Sassenberg/Faber, Rechtshandbuch Industrie 4.0 und Internet of Things, 2. Aufl., 2020, § 4 Ziffer 1 b).

[25] Marly, Praxishandbuch Softwarerecht, 8. Aufl. 2024, § 11 Rn. 321

[26] Marly, Praxishandbuch Softwarerecht, 8. Aufl. 2024, § 11 Rn. 318.

[27] Hoeren/Sieber/Holznagel, Handbuch Multimedia-Recht, Werkstand: 62. EL Juni 2024, Teil 29.2 Rn. 17.

[28] Hoeren/Sieber/Holznagel, Handbuch Multimedia-Recht, Werkstand: 62. EL Juni 2024, Teil 29.2 Rn. 18; Marly, Praxishandbuch Softwarerecht, 8. Aufl. 2024, § 11 Rn. 326 ff. Nach § 15 Abs. 2 ProdHaftG bleibt eine Haftung aufgrund anderer Vorschriften als des ProdHaftG unberührt.

[29] Statt vieler: Specht-Riemenschneider, MMR 2020, 73 ff.

[30] Simitis/Hornung/Spiecker gen. Döhmann/Hansen, Datenschutzrecht DS-GVO/BDSG, 2. Aufl., 2024, Art. 25 Rn. 16.

[31] Die Bezeichnung des Datenschutzgrundsatzes als „Integrität und Vertraulichkeit“ greift zu kurz; aus der Beschreibung des Datenschutzgrundsatzes „… in einer Weise verarbeitet werden, die eine angemessene Sicherheit der personenbezogenen Daten gewährleistet, einschließlich Schutz vor unbefugter oder unrechtmäßiger Verarbeitung und vor unbeabsichtigtem Verlust, unbeabsichtigter Zerstörung oder unbeabsichtigter Schädigung durch geeignete technische und organisatorische Maßnahmen“ gehen beispielsweise auch explizit Verfügbarkeitsanforderungen hervor; Simitis/Hornung/ Spiecker gen. Döhmann/Hansen, Datenschutzrecht DS-GVO/BDSG, 2. Aufl., 2024, Art. 32 Rn. 12.

[32] Siehe auch Tinnefeld/Buchner/Petri/Hansen, Einführung in das Datenschutzrecht – Datenschutz und Informationsfreiheit in europäischer Sicht, 8. Aufl., 2024, S. 393.

[33] Auch bei den (im Übrigen mit den Datenschutzgrundsätzen aus Art. 5 DS-GVO kompatiblen) Gewährleistungszielen des Standard-Datenschutzmodells handelt es sich um eine Ebene zur Konkretisierung der Anforderungen bzw. zur ausreichenden Eindämmung der Risiken; DSK, Das Standard-Datenschutzmodell – Eine Methode zur Datenschutzberatung und -prüfung auf der Basis einheitlicher Gewährleistungsziele, Version 3.1a, 2025, https://www.datenschutzmv.de/static/DS/Dateien/Datenschutzmodell/SDM-Methode-V31a.pdf, S. 28 f.

[34] So regelmäßig verdeutlicht in Entscheidungen des EuGH, beispielsweise im Urt. v. 12.01.2023, C-154/21, Rn. 37: „… entschieden, dass es der betroffenen Person durch die Ausübung dieses Auskunftsrechts nicht nur ermöglicht werden muss, zu überprüfen, ob sie betreffende Daten richtig sind, sondern auch, ob sie in zulässiger Weise verarbeitet werden … insbesondere ob sie gegenüber Empfängern offengelegt wurden, die zu ihrer Verarbeitung befugt sind“.

[35] Eckhardt/Hansen, BvD-News 2023, Heft 2, 20-27 sowie Eckhardt/Hansen, DuD, 2024, 561–565.

[36] EDSA, Leitlinien 4/2019 zu Art. 25 – Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen, Version 2.0, angenommen am 20.10.2020.

[37] DSK, Das Standard-Datenschutzmodell – Eine Methode zur Datenschutzberatung und –prüfung auf der Basis einheitlicher Gewährleistungsziele, Version 3.1a, 2025.

[38] Zurzeit wird an den Bausteinen des SDM gearbeitet; neue Versionen werden hier zur Verfügung gestellt: https://www.datenschutz-mv.de/datenschutz/datenschutzmodell/.

[39] Beispielsweise im Cloud Computing, siehe EDSA, Empfehlungen 01/2020 zu Maßnahmen zur Ergänzung von Übermittlungstools zur Gewährleistung des unionsrechtlichen Schutzniveaus für personenbezogene Daten, Version 2.0, angenommen am 18.06.2021, https://www.edpb.europa.eu/our-work-tools/our-documents/recommendations/recommendations-012020-measuressupplement-transfer_de. Neben Pseudonymisierungsmaßnahmen können auch andere Formen der Trennung bei der Umsetzung helfen. So arbeitet auch das vor vielen Jahren eingeführte Lettershop-Verfahren mit einer Trennung von Rollen und Datenbeständen, indem einem Auftraggeber eine Nutzung von Postadressen ermöglicht wird, ohne dass er diese personenbezogenen Daten selbst erhält. Neuere Entwicklungen mit Bezug zum Forschungsfeld der Privacy-Enhancing Technologies wie Attribute-based Credentials, Multiparty Computation oder Confidential Computing tragen ebenfalls dazu bei, durch Aufteilung und Trennung von Funktionen, Daten und Verarbeitungen bestimmten Datenschutzrisiken entgegenzuwirken.

[40] Siehe oben einleitend.

[41] „In Bezug auf Entwicklung, Gestaltung, Auswahl und Nutzung von Anwendungen, Diensten und Produkten, die entweder auf der Verarbeitung von personenbezogenen Daten beruhen oder zur Erfüllung ihrer Aufgaben personenbezogene Daten verarbeiten, sollten die Hersteller der Produkte, Dienste und Anwendungen ermutigt werden, das Recht auf Datenschutz bei der Entwicklung und Gestaltung der Produkte, Dienste und Anwendungen zu berücksichtigen und unter gebührender Berücksichtigung des Stands der Technik sicherzustellen, dass die Verantwortlichen und die Verarbeiter in der Lage sind, ihren Datenschutzpflichten nachzukommen.“, ErwGr. 78 S. 4.

[42] Hansen, Dokumentation als Normalfall? – Cyberresilienz-Verordnung und KIVerordnung helfen bei der Rechenschaftspflicht, DuD, 2025 (im Erscheinen).

[43] Auch wenn die Konstellation bei einer Produktverwendung durch Nutzende eine andere ist, vgl. die datenschutzrechtlichen Anforderungen zum Löschen, Art. 5 Abs. 1 lit. e), Art. 17 DS-GVO

[44] Beispielsweise bei einem Drittstaatentransfer bestimmter personenbezogener Daten.

[45] Es soll nicht verschwiegen werden, dass die Erfüllung der Anforderungen der Cybersicherheit nicht in jedem Fall auch schon die Umsetzung von Datenschutzanforderungen gewährleistet, sondern sogar gegenteilige Effekte möglich sind. So können Sicherheitsmaßnahmen selbst Datenschutzrisiken verursachen, z. B. wenn für die Erkennung von Angriffen Mittel gewählt werden, die zu einer überbordenden Überwachung des legitimen Verhaltens von Kunden oder Mitarbeitenden führen, s. Hansen/Probst, Souveräne Sicherheit, Zero Trust und das Datenschutzrecht, DuD, 2023, S. 625.