Datenschutz bei eigenentwickelter Software: Rechtliche Anforderungen an Entwicklung, Betrieb und Verantwortung

Eigenentwickelte Software ermöglicht es Unternehmen, Behörden und anderen Organisationen, digitale Verfahren auf ihre besonderen Anforderungen abzustimmen. Werden dabei personenbezogene Daten verarbeitet, müssen die einschlägigen datenschutzrechtlichen Anforderungen berücksichtigt werden. Diese Verantwortung beginnt nicht erst mit dem produktiven Einsatz. Bereits die Auswahl von Entwicklungswerkzeugen, die Verwendung von Testdaten und die Einrichtung von Fehlerprotokollen können datenschutzrechtlich relevante Verarbeitungsvorgänge auslösen.

Rechtlich entscheidend ist nicht allein, ob eine Anwendung sicher programmiert wurde. Zu klären ist ebenso, welche Daten sie zu welchen Zwecken verarbeitet, auf welcher Rechtsgrundlage dies geschieht und wie die Rechte betroffener Personen gewährleistet werden. Selbst technisch zuverlässige Software kann datenschutzwidrig eingesetzt werden, wenn sie unnötige Informationen erhebt, Daten ohne ausreichende Rechtfertigung zusammenführt oder gesetzlich vorgesehene Löschungen verhindert.

Der folgende Beitrag behandelt die Anforderungen im Anwendungsbereich der Datenschutz-Grundverordnung. Ergänzend werden deutsche Vorschriften berücksichtigt. Für bestimmte Tätigkeiten, insbesondere außerhalb des sachlichen Anwendungsbereichs der DSGVO, können andere Datenschutzregelungen maßgeblich sein. Die Entwicklung durch eine Organisation selbst begründet weder eine Ausnahme vom Datenschutzrecht noch eine eigenständige Rechtsgrundlage für die Datenverarbeitung.

Begriffsklärung und Zurechnung der Verantwortung

Was unter eigenentwickelter Software zu verstehen ist

Eigenentwickelte Software ist kein eigenständiger Rechtsbegriff der Datenschutz-Grundverordnung. Gemeint sind regelmäßig Anwendungen, die eine Organisation selbst oder nach ihren besonderen Vorgaben entwickeln lässt. Dazu gehören interne Verwaltungsprogramme, Kundenportale, mobile Anwendungen, Analysewerkzeuge und Schnittstellen zwischen bestehenden Systemen.

Ob die Entwicklung durch eigene Beschäftigte, selbstständige Programmierer oder ein beauftragtes Softwareunternehmen erfolgt, entscheidet nicht allein über die Anwendbarkeit des Datenschutzrechts. Ebenso wenig begründet die Verwendung frei verfügbarer Softwarekomponenten eine Ausnahme. Maßgeblich sind die tatsächlichen Verarbeitungsvorgänge, der gesetzliche Anwendungsbereich und die Verteilung der Entscheidungsmacht.

Die Bezeichnung „interne Anwendung“ ist keine rechtliche Privilegierung. Eine ausschließlich im Unternehmensnetz eingesetzte Software kann eingriffsintensive Verarbeitungen ermöglichen, etwa wenn sie Arbeitsverhalten oder Gesundheitsinformationen auswertet. Umgekehrt unterliegt die bloße Erstellung von Programmcode ohne Verarbeitung personenbezogener Daten nicht schon deshalb der DSGVO, weil die fertige Anwendung später solche Daten verarbeiten soll.

Personenbezug, Pseudonymisierung und Anonymisierung

Personenbezogene Daten sind nach Art. 4 Nr. 1 DSGVO Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Hierzu können neben Namen und Anschriften auch Nutzerkennungen, Standortinformationen, Gerätekennzeichen und Protokolleinträge gehören. Entscheidend ist, ob die Information unter Berücksichtigung des jeweiligen Zusammenhangs einer natürlichen Person zugeordnet werden kann.

Bei der Beurteilung der Identifizierbarkeit sind nach Erwägungsgrund 26 DSGVO die Mittel zu berücksichtigen, die vernünftigerweise zur Identifizierung eingesetzt werden könnten. Hierzu gehören insbesondere der erforderliche Aufwand, die verfügbaren Technologien und die konkreten Zugangsmöglichkeiten zu Zusatzinformationen. Eine nur theoretisch denkbare Identifizierung ist daher nicht mit einer praktisch relevanten Identifizierbarkeit gleichzusetzen.

Pseudonymisierung im Sinne des Art. 4 Nr. 5 DSGVO beseitigt den Personenbezug nicht automatisch. Für eine Organisation, die über die erforderlichen Zuordnungsinformationen verfügt, bleiben pseudonymisierte Datensätze regelmäßig personenbezogen. Ob Informationen auch für einen bestimmten Empfänger personenbezogen sind, kann dagegen von dessen rechtlichen und tatsächlichen Identifizierungsmöglichkeiten abhängen. Eine pauschale Gleichsetzung von Pseudonymisierung und Anonymisierung ist unzutreffend.

Tatsächlich anonyme Informationen fallen nicht unter die DSGVO. Der Vorgang der Anonymisierung personenbezogener Ausgangsdaten ist jedoch selbst eine Verarbeitung und bedarf einer rechtlichen Rechtfertigung. Bei umfangreichen Datensätzen können Kombinationen scheinbar unauffälliger Merkmale eine erneute Identifizierung ermöglichen.

Verantwortliche und Auftragsverarbeiter

Verantwortlicher ist nach Art. 4 Nr. 7 DSGVO, wer allein oder gemeinsam mit anderen über Zwecke und Mittel der Verarbeitung entscheidet. Bei interner Unternehmenssoftware ist dies regelmäßig das einsetzende Unternehmen, nicht die einzelne programmierende Person. Die tatsächlichen Entscheidungsbefugnisse bleiben maßgeblich.

Ein externer Entwicklungsdienstleister kann Auftragsverarbeiter nach Art. 4 Nr. 8 DSGVO sein, wenn er personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet. Dies kann beispielsweise bei Entwicklungstests mit Kundendaten, Hosting oder weisungsgebundener Fehleranalyse der Fall sein. Die bloße Erstellung von Programmcode ohne entsprechende Datenverarbeitung begründet dagegen nicht automatisch eine Auftragsverarbeitung.

Entscheiden mehrere Beteiligte gemeinsam über Zwecke und Mittel, kommt eine gemeinsame Verantwortlichkeit nach Art. 26 DSGVO in Betracht. Eine Zusammenarbeit oder ein Datenaustausch allein genügt dafür nicht. Vertragsüberschriften sind ebenso wenig ausschlaggebend wie die Selbstbezeichnung eines Anbieters. Entscheidend ist die tatsächliche Aufgabenverteilung. Ein Dienstleister kann zudem für unterschiedliche Verarbeitungsvorgänge unterschiedliche datenschutzrechtliche Rollen haben.

Rechtlicher Rahmen und einschlägige Normen

Datenschutzgrundsätze und Rechtsgrundlagen

Den zentralen Maßstab bilden die Grundsätze des Art. 5 DSGVO. Personenbezogene Daten müssen insbesondere rechtmäßig, nach Treu und Glauben, transparent, zweckgebunden, sachlich richtig und auf das notwendige Maß beschränkt verarbeitet werden. Hinzu kommen Speicherbegrenzung sowie Integrität und Vertraulichkeit.

Nach Art. 5 Abs. 2 DSGVO muss der Verantwortliche die Einhaltung dieser Grundsätze nachweisen können. Umfang und Ausgestaltung der Nachweise hängen von der Verarbeitung ab. Eine lediglich mündliche, nicht weiter belegte Zusicherung, die Anwendung sei „datenschutzkonform“, stellt regelmäßig keinen ausreichenden Nachweis dar.

Die Verarbeitung muss durch eine einschlägige Rechtsgrundlage gedeckt sein. Art. 6 Abs. 1 DSGVO nennt insbesondere Einwilligung, Vertragserfüllung, rechtliche Verpflichtung, den Schutz lebenswichtiger Interessen, öffentliche Aufgaben und berechtigte Interessen. Die Vertragsgrundlage erfasst nur Verarbeitungen, die für die Vertragserfüllung oder bestimmte vorvertragliche Maßnahmen objektiv erforderlich sind. Eine Funktion wird nicht schon dadurch erforderlich, dass sie in Allgemeinen Geschäftsbedingungen erwähnt wird.

Bei berechtigten Interessen nach Art. 6 Abs. 1 Buchst. f DSGVO sind das konkrete Interesse, die Erforderlichkeit und die entgegenstehenden Interessen oder Grundrechte der betroffenen Personen zu prüfen. Behörden können diese Rechtsgrundlage nicht für Verarbeitungen in Erfüllung ihrer Aufgaben heranziehen. Die technische Verfügbarkeit einer Auswertung ersetzt in keinem Fall die rechtliche Prüfung.

Eine Einwilligung muss insbesondere freiwillig, für bestimmte Zwecke, informiert und unmissverständlich erteilt werden. Art. 7 DSGVO enthält weitere Anforderungen, darunter Nachweisbarkeit und Widerruflichkeit. Der Widerruf berührt die Rechtmäßigkeit der bis dahin auf Grundlage der Einwilligung erfolgten Verarbeitung nicht. Ist eine Verarbeitung gesetzlich vorgeschrieben, darf nicht der irreführende Eindruck entstehen, sie könne durch Verweigerung oder Widerruf einer Einwilligung verhindert werden.

Besondere Datenkategorien und deutsche Ergänzungen

Für besondere Kategorien personenbezogener Daten gelten die zusätzlichen Voraussetzungen des Art. 9 DSGVO. Dazu zählen etwa Gesundheitsdaten sowie biometrische Daten, soweit sie zur eindeutigen Identifizierung einer natürlichen Person verarbeitet werden. Nicht jedes Foto und nicht jedes technische Körpermerkmal fällt daher allein aufgrund seiner Beschaffenheit unter das Verarbeitungsverbot.

Neben einer Rechtsgrundlage nach Art. 6 DSGVO muss für die Verarbeitung besonderer Datenkategorien grundsätzlich eine Ausnahme nach Art. 9 Abs. 2 DSGVO vorliegen. Für personenbezogene Daten über strafrechtliche Verurteilungen und Straftaten enthält Art. 10 DSGVO gesonderte Anforderungen.

Das Bundesdatenschutzgesetz ergänzt die DSGVO in bestimmten Bereichen. Für Beschäftigtendaten ist insbesondere § 26 BDSG relevant. Seine Anwendung muss den unionsrechtlichen Anforderungen entsprechen. Die Tragfähigkeit einer konkreten Verarbeitung darf deshalb nicht allein aus einem allgemeinen Verweis auf das Beschäftigungsverhältnis abgeleitet werden. Insbesondere Überwachungsmaßnahmen und weitreichende Auswertungen bedürfen einer eigenständigen Erforderlichkeits- und Verhältnismäßigkeitsprüfung.

Bei öffentlichen Stellen können besondere Fachgesetze und die Datenschutzgesetze der Länder hinzutreten. Für ärztliche, anwaltliche oder andere geheimnisgeschützte Tätigkeiten sind außerdem berufsrechtliche Vorgaben und gegebenenfalls § 203 StGB zu beachten. Eine datenschutzrechtlich zulässige Verarbeitung ist nicht automatisch auch mit sämtlichen Verschwiegenheitspflichten vereinbar.

Zugriff auf Endeinrichtungen und betriebliche Mitbestimmung

Speichert eine Anwendung Informationen in der Endeinrichtung eines Endnutzers oder greift sie auf bereits dort gespeicherte Informationen zu, kann § 25 TDDDG einschlägig sein. Die Vorschrift betrifft nicht ausschließlich personenbezogene Daten. Ihr Anwendungsbereich ist daher gesondert von demjenigen der DSGVO zu prüfen.

Grundsätzlich ist eine Einwilligung erforderlich, sofern keine gesetzliche Ausnahme greift. § 25 Abs. 2 TDDDG enthält Ausnahmen für bestimmte Vorgänge der Nachrichtenübertragung und für unbedingt erforderliche Speicherungen oder Zugriffe zur Bereitstellung eines vom Nutzer ausdrücklich gewünschten digitalen Dienstes. Eine bloße wirtschaftliche Nützlichkeit für den Anbieter genügt für die letztgenannte Ausnahme nicht.

Ob beispielsweise ein Analysewerkzeug unter eine Ausnahme fällt, hängt von seiner tatsächlichen Funktion und dem konkret gewünschten Dienst ab. Die Bezeichnung eines Werkzeugs als „technisch notwendig“ entscheidet diese Frage nicht. Für die Verarbeitung personenbezogener Daten bleibt daneben die DSGVO zu beachten; eine Ausnahme nach § 25 TDDDG ersetzt keine Rechtsgrundlage nach Art. 6 DSGVO.

Bei Beschäftigtenanwendungen ist außerdem § 87 Abs. 1 Nr. 6 BetrVG bedeutsam, soweit das Betriebsverfassungsgesetz anwendbar ist und ein Betriebsrat besteht. Nach der arbeitsgerichtlichen Auslegung kommt es grundsätzlich auf die objektive Eignung der technischen Einrichtung zur Verhaltens- oder Leistungskontrolle an, nicht allein auf eine erklärte Überwachungsabsicht. Datenschutzprüfung und Beteiligungsverfahren ersetzen einander nicht. Im öffentlichen Dienst können entsprechende personalvertretungsrechtliche Vorschriften einschlägig sein.

Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen

Anforderungen an Architektur und Standardeinstellungen

Art. 25 DSGVO verpflichtet den Verantwortlichen zu Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Die Vorschrift schreibt keine bestimmte Programmiersprache und keine einheitliche Systemarchitektur vor. Sie verlangt geeignete technische und organisatorische Maßnahmen, die unter Berücksichtigung der gesetzlichen Bewertungskriterien die Datenschutzgrundsätze wirksam umsetzen.

Bereits bei der Festlegung der Datenmodelle ist zu entscheiden, welche Informationen tatsächlich benötigt werden. Freitextfelder, umfassende Aktivitätsprotokolle und dauerhaft verknüpfte Identifikatoren können zusätzliche Risiken schaffen. Ihre Verwendung muss sich an den festgelegten Zwecken und der Erforderlichkeit orientieren.

Datenschutzfreundliche Voreinstellungen betreffen insbesondere Datenmenge, Verarbeitungsumfang, Speicherdauer und Zugänglichkeit. Standardmäßig sollen nur diejenigen personenbezogenen Daten verarbeitet werden, die für den jeweiligen bestimmten Zweck erforderlich sind. Eine Anwendung darf daher nicht allein aus Bequemlichkeit sämtliche Beschäftigtendaten für alle internen Nutzer sichtbar machen.

Die Verantwortung nach Art. 25 DSGVO trifft unmittelbar den Verantwortlichen. Ein Hersteller, der ausschließlich Software bereitstellt und selbst keine entsprechende Verarbeitung verantwortet, wird nicht allein aufgrund seiner Herstellereigenschaft zum Adressaten dieser Vorschrift. Der einsetzende Verantwortliche muss gleichwohl prüfen, ob die ausgewählte Software eine rechtmäßige Verarbeitung ermöglicht. Bei beauftragten Entwicklungen ist eine konkrete vertragliche Beschreibung der benötigten Eigenschaften regelmäßig zweckmäßig.

Sicherheit der Verarbeitung

Art. 32 DSGVO verpflichtet Verantwortliche und Auftragsverarbeiter zu einem dem Risiko angemessenen Schutzniveau. Zu berücksichtigen sind unter anderem der Stand der Technik, Implementierungskosten sowie Art, Umfang, Umstände und Zwecke der Verarbeitung. Maßgeblich sind insbesondere die Risiken für die Rechte und Freiheiten natürlicher Personen.

Je nach Verarbeitung kommen beispielsweise folgende Maßnahmen in Betracht:

• rollenbasierte Berechtigungen und Mehrfaktorauthentifizierung;
• Verschlüsselung bei Übertragung und Speicherung;
• Trennung von Entwicklungs-, Test- und Produktivsystemen;
• sichere Verwaltung von Passwörtern, Schlüsseln und Zugangstoken;
• Sicherheitsprüfungen und geregelte Aktualisierungsverfahren;
• Wiederherstellbarkeit nach Zwischenfällen;
• Verfahren zur regelmäßigen Überprüfung der Wirksamkeit der Schutzmaßnahmen.

Nicht jede Einzelmaßnahme ist in jedem System zwingend. Umgekehrt rechtfertigt ein begrenztes Entwicklungsbudget kein beliebiges Absenken des Schutzes. Die Organisation muss nachvollziehbar bewerten, welche Risiken bestehen und welche Maßnahmen hierfür angemessen sind. Eine einmalige Sicherheitsprüfung ersetzt nicht die fortlaufende Berücksichtigung neuer Schwachstellen und geänderter Einsatzbedingungen.

Löschbarkeit und Auskunftsfähigkeit als Funktionen

Betroffenenrechte lassen sich nur zuverlässig erfüllen, wenn die eingesetzten Verfahren ihre praktische Umsetzung ermöglichen. Je nach System können Suchmöglichkeiten, dokumentierte Datenherkünfte, Exportfunktionen, Löschroutinen und technische Möglichkeiten zur Einschränkung der Verarbeitung erforderlich sein. Die DSGVO verlangt dabei nicht für jedes Recht eine bestimmte Softwarefunktion; entscheidend ist die wirksame und fristgerechte Erfüllung der jeweiligen Pflicht.

Ein häufiger Konstruktionsfehler besteht darin, Daten über Tabellen, Suchindizes und Protokollsysteme zu verteilen, ohne ihre Zuordnung und Entfernung vorzusehen. Rechtliche Pflichten werden dadurch nicht ausgeschlossen. Andererseits ist nicht jeder Löschungsantrag begründet: Art. 17 DSGVO enthält Voraussetzungen und Ausnahmen, etwa für bestimmte gesetzliche Aufbewahrungspflichten.

Auch Sicherungskopien benötigen ein Lösch- und Wiederherstellungskonzept. Technische Schwierigkeiten begründen keine allgemeine Ausnahme vom Datenschutzrecht. Ob eine zeitversetzte Entfernung aus Sicherungen vertretbar ist, hängt insbesondere von Zweck, Aufbewahrungsdauer, Zugriffsbeschränkungen und Wiederherstellungsverfahren ab. Es muss verhindert werden, dass bereits zu löschende Daten nach einer Wiederherstellung unkontrolliert erneut genutzt werden.

Rechtsprechungslinien mit Bedeutung für Eigenentwicklungen

Sicherheitsvorfälle und Nachweis angemessener Maßnahmen

Der EuGH hat mit Urteil vom 14. Dezember 2023, C-340/21, klargestellt, dass eine unbefugte Offenlegung personenbezogener Daten oder ein unbefugter Zugang durch Dritte nicht allein beweist, dass die technischen und organisatorischen Maßnahmen ungeeignet waren. Deren Angemessenheit ist anhand der konkreten Umstände zu prüfen.

Der Verantwortliche trägt nach dieser Entscheidung die Beweislast dafür, dass die von ihm getroffenen Sicherheitsmaßnahmen angemessen waren. Der Hinweis auf einen externen Angriff führt daher nicht ohne Weiteres zur Entlastung. Auch bei einem Angriff durch Dritte bleiben die gesetzlichen Voraussetzungen einer Haftung und einer möglichen Befreiung davon zu untersuchen.

Für eigenentwickelte Software folgt daraus: Entwicklungsentscheidungen, Sicherheitsprüfungen und Reaktionen auf bekannte Schwachstellen sollten nachvollziehbar dokumentiert werden. Die Dokumentation ersetzt keine wirksamen Maßnahmen. Sie ermöglicht aber die Prüfung, ob Risiken erkannt, bewertet und angemessen behandelt wurden.

Schadensersatz wegen Datenschutzverletzungen

Nach dem Urteil des EuGH vom 4. Mai 2023, C-300/21, setzt ein Schadensersatzanspruch nach Art. 82 DSGVO einen Verstoß gegen die DSGVO, einen materiellen oder immateriellen Schaden und einen ursächlichen Zusammenhang voraus. Der bloße Datenschutzverstoß begründet somit nicht automatisch einen Schadensersatzanspruch.

Für immaterielle Schäden darf allerdings keine zusätzliche Erheblichkeitsschwelle verlangt werden. Der Bundesgerichtshof hat mit Urteil vom 18. November 2024, VI ZR 10/24, für einen Scraping-Fall ausgeführt, dass bereits ein kurzfristiger Verlust der Kontrolle über personenbezogene Daten einen immateriellen Schaden darstellen kann. Ein zusätzlicher nachgewiesener Missbrauch der Daten ist dafür nicht stets erforderlich.

Daraus folgt jedoch kein pauschaler Anspruch für jede fehlerhafte Softwarefunktion. Ob ein Schaden vorliegt und auf dem Datenschutzverstoß beruht, ist im konkreten Fall festzustellen. Ebenso lässt sich aus den genannten Entscheidungen kein allgemeiner, für sämtliche Datenschutzverletzungen geltender Entschädigungsbetrag ableiten.

Unternehmensverantwortung und Verschulden

Der EuGH hat im Urteil vom 5. Dezember 2023, C-807/21, zur Verhängung von Geldbußen gegen juristische Personen Stellung genommen. Für eine Geldbuße nach Art. 83 DSGVO ist ein vorsätzlicher oder fahrlässiger Verstoß erforderlich. Die Verhängung hängt jedoch nicht davon ab, dass zuvor eine bestimmte natürliche Person als Täter des Verstoßes identifiziert wird.

Eine Organisation kann sich deshalb nicht bereits dadurch entlasten, dass datenschutzwidrige Funktionen von einzelnen Beschäftigten programmiert wurden. Relevant sind auch die tatsächlichen Verantwortungsbereiche und die organisatorischen Voraussetzungen, unter denen entwickelt, geprüft und freigegeben wurde.

Die Entscheidung begründet umgekehrt keine verschuldensunabhängige Bußgeldhaftung für jeden Programmierfehler. Die gesetzlichen Voraussetzungen des jeweiligen Verstoßes und des Verschuldens müssen vorliegen.

Typische Fallkonstellationen

Produktivdaten in Entwicklung und Qualitätssicherung

Die Übernahme realer Kundendaten in eine Testumgebung ist selbst eine Verarbeitung personenbezogener Daten. Sie muss rechtlich gedeckt sein und angemessenen Schutzanforderungen genügen. Die Bezeichnung als Testbetrieb ändert daran nichts.

Dass die Daten ursprünglich rechtmäßig erhoben wurden, erlaubt nicht jede weitere Nutzung. Zu prüfen sind insbesondere der ursprüngliche Zweck, die Vereinbarkeit der Testverwendung mit diesem Zweck und die Erforderlichkeit echter Daten. Eine vereinbare Weiterverarbeitung benötigt nicht zwangsläufig eine neue, von der ursprünglichen Rechtsgrundlage unabhängige Erlaubnis. Ob die Voraussetzungen dafür vorliegen, ist jedoch gesondert zu beurteilen.

Synthetische Testdaten oder belastbar anonymisierte Datensätze können das Risiko verringern. Allerdings müssen auch vermeintlich synthetische Daten darauf geprüft werden, ob sie tatsächlich reale Personen abbilden oder aus Ausgangsdaten rekonstruierbare Informationen enthalten.

Werden reale Daten benötigt, sind Umfang, Zugriffsberechtigungen und Nutzungsdauer auf das Erforderliche zu begrenzen. Unkontrollierte Kopien auf privaten Rechnern oder öffentlich erreichbare Testsysteme können erhebliche zusätzliche Risiken begründen.

Beschäftigtenanalyse und interne Kontrollsysteme

Eine selbst entwickelte Personalsoftware kann Arbeitszeiten, Bearbeitungsstände und Kommunikationsmetadaten verknüpfen. Dadurch können Leistungsprofile entstehen, obwohl die Anwendung ursprünglich nur der Arbeitsorganisation dienen sollte.

Rechtlich müssen die einzelnen Zwecke und Auswertungsmöglichkeiten getrennt betrachtet werden. Eine erforderliche Arbeitszeiterfassung rechtfertigt beispielsweise nicht automatisch eine umfassende individuelle Produktivitätsbewertung. Auch eine Betriebsvereinbarung stellt keinen Freibrief für unverhältnismäßige Datenverarbeitungen dar.

Neben § 26 BDSG sind die DSGVO-Grundsätze und gegebenenfalls Mitbestimmungsrechte zu berücksichtigen. Bei einer ausschließlich auf automatisierter Verarbeitung beruhenden Entscheidung mit rechtlicher oder ähnlich erheblicher Wirkung kann außerdem Art. 22 DSGVO eingreifen. Die Vorschrift enthält Ausnahmen und besondere Schutzanforderungen.

Eine nur formale menschliche Bestätigung schließt die Anwendung des Art. 22 DSGVO nicht zuverlässig aus. Entscheidend ist, ob tatsächlich eine eigenständige, sachkundige Prüfung mit realer Einflussmöglichkeit auf das Ergebnis stattfindet.

Fehlerdiagnose, Protokolle und Telemetrie

Fehlerprotokolle können für Wartung und Sicherheit erforderlich sein, zugleich aber sensible Inhalte enthalten. Risiken entstehen insbesondere durch mitgeschriebene Formulareingaben, vollständige Anfragen, Sitzungsschlüssel oder Zugangsdaten.

Das Protokollierungskonzept sollte festlegen, welche Ereignisse für welchen Zweck aufgezeichnet werden, welche Inhalte ausgefiltert werden und wer auf die Aufzeichnungen zugreifen darf. Für unterschiedliche Protokollarten können unterschiedliche Aufbewahrungszeiten erforderlich sein. Eine allgemeine, für sämtliche Softwareprotokolle geltende Speicherfrist enthält die DSGVO nicht.

Sicherheitsprotokolle und Nutzungsanalysen verfolgen nicht zwingend denselben Zweck. Eine spätere Auswertung ursprünglich zur Gefahrenabwehr erhobener Protokolle für Marketing oder Beschäftigtenkontrolle bedarf deshalb einer eigenständigen Prüfung. Auch eine Auslagerung an einen Fehleranalysedienst lässt diese Anforderungen nicht entfallen.

Cloud-Dienste und internationale Entwicklungswerkzeuge

Auch eine Eigenentwicklung kann externe Dienste nutzen, etwa für Quellcodeverwaltung, Fehleranalyse, Hosting, E-Mail-Versand oder automatisierte Bereitstellung. Sobald diese Dienste personenbezogene Daten verarbeiten, sind ihre Rollen, Datenflüsse und Vertragsbedingungen zu untersuchen. Quellcodeplattformen können beispielsweise personenbezogene Angaben in Nutzerkonten, Änderungshistorien oder Fehlerberichten enthalten.

Bei Auftragsverarbeitung ist Art. 28 DSGVO zu beachten. Relevant sind insbesondere ausreichende Garantien des Dienstleisters, Weisungsbindung, Vertraulichkeit, Sicherheitsmaßnahmen und der Einsatz weiterer Auftragsverarbeiter. Der erforderliche Vertrag ersetzt nicht die Prüfung, ob die Verarbeitung als solche rechtmäßig ist.

Bei Übermittlungen in Drittländer kommen zusätzlich Art. 44 ff. DSGVO zur Anwendung. Ein europäischer Serverstandort beantwortet diese Prüfung nicht abschließend. Zugriffe durch rechtlich selbstständige Empfänger in Drittländern können ebenfalls relevant sein.

Umgekehrt führt nicht jeder Bezug zu einem ausländischen Konzern automatisch zu einer Drittlandübermittlung. Entscheidend sind die konkrete Empfängerstruktur und die tatsächlichen Übermittlungsvorgänge. Je nach Konstellation kommen ein einschlägiger Angemessenheitsbeschluss, geeignete Garantien oder eng auszulegende gesetzliche Ausnahmen in Betracht.

Einsatz generativer KI bei der Programmierung

Wer Quellcode oder Fehlermeldungen an ein KI-Werkzeug übermittelt, kann dabei personenbezogene Daten offenlegen. Dies betrifft etwa eingebettete Beispieldatensätze, Protokollauszüge oder Kommentare mit Beschäftigtennamen. Auch automatisierte Integrationen können mehr Kontext übertragen, als die unmittelbar sichtbare Eingabe erkennen lässt.

Vor einer solchen Nutzung sind Anbieterrolle, Verarbeitungszwecke, Speicherung, mögliche Weiterverwendung und internationale Übermittlungen zu prüfen. Die Rollenverteilung kann sich unterscheiden, je nachdem, ob der Anbieter ausschließlich weisungsgebunden handelt oder über eigene Verwendungszwecke entscheidet.

Zusätzlich können Geschäftsgeheimnisse und vertragliche Verschwiegenheitspflichten betroffen sein. Eine allgemeine organisatorische Freigabe des Werkzeugs ersetzt daher keine Prüfung der tatsächlich eingegebenen oder automatisiert übertragenen Inhalte.

Rechtsfolgen und wirtschaftliche Risiken

Aufsichtsbehördliche Maßnahmen und Geldbußen

Die Datenschutzaufsichtsbehörden verfügen nach Art. 58 DSGVO über Untersuchungs- und Abhilfebefugnisse. Sie können unter anderem Informationen verlangen, Verwarnungen aussprechen, Anpassungen anordnen und Verarbeitungen vorübergehend oder dauerhaft beschränken oder untersagen.

Eine Beschränkung oder Untersagung kann bei einer betrieblich zentralen Eigenentwicklung erhebliche Auswirkungen haben. Datenschutzmängel sind deshalb nicht ausschließlich ein mögliches Bußgeldproblem. Welche Maßnahme zulässig und angemessen ist, hängt vom Einzelfall ab.

Art. 83 DSGVO sieht unterschiedliche Bußgeldrahmen vor. Für die in Art. 83 Abs. 4 DSGVO genannten Verstöße reicht der Rahmen bis zu 10 Millionen Euro oder bei Unternehmen bis zu 2 Prozent des gesamten weltweit erzielten Jahresumsatzes des vorangegangenen Geschäftsjahrs, je nachdem, welcher Betrag höher ist. Für Verstöße nach Art. 83 Abs. 5 und Abs. 6 DSGVO gelten entsprechende Höchstgrenzen von 20 Millionen Euro oder 4 Prozent.

Der Unternehmensbegriff und die maßgebliche Umsatzbasis können eine wirtschaftliche Einheit erfassen und sind nicht stets auf die unmittelbar handelnde Gesellschaft beschränkt. Die tatsächliche Bemessung richtet sich nach den gesetzlichen Kriterien, insbesondere Art, Schwere, Dauer und Verschulden sowie schadensmindernden Maßnahmen. Die Höchstbeträge sind keine Regelbeträge. Für Behörden und öffentliche Stellen gelten zusätzliche nationale Besonderheiten.

Zivilrechtliche und vertragliche Folgen

Neben Ansprüchen nach Art. 82 DSGVO können vertragliche Ansprüche zwischen Auftraggebern und Entwicklungsdienstleistern entstehen. Wurde beispielsweise eine bestimmte Berechtigungsstruktur verbindlich vereinbart und nicht umgesetzt, kommen je nach Vertragstyp und Umständen Mängelrechte oder Schadensersatz nach dem BGB in Betracht.

Eine konkrete Leistungsbeschreibung erleichtert die Bestimmung der geschuldeten Funktionen. Eine pauschale Klausel zur „Datenschutzkonformität“ kann dagegen auslegungsbedürftig sein. Daraus folgt jedoch nicht, dass ohne detaillierte Einzelvereinbarung keine datenschutzbezogenen Vertragspflichten bestehen. Auch Vertragszweck, vereinbarte Verwendung und gesetzliche Anforderungen können für den geschuldeten Leistungsumfang bedeutsam sein.

Art. 82 Abs. 2 DSGVO unterscheidet zwischen der Haftung von Verantwortlichen und Auftragsverarbeitern. Ein Auftragsverarbeiter haftet danach insbesondere bei Verletzung speziell an ihn gerichteter Pflichten oder bei Verarbeitung entgegen rechtmäßigen Weisungen beziehungsweise außerhalb dieser Weisungen. Dienstleister sind deshalb weder grundsätzlich haftungsfrei noch ohne Weiteres für sämtliche Entscheidungen des Auftraggebers verantwortlich. Weitere Haftungsvoraussetzungen und Entlastungsmöglichkeiten bleiben zu prüfen.

Organisatorische Folgekosten

Ein Datenschutzvorfall kann Untersuchungen, Benachrichtigungen, Systemanpassungen und die Bearbeitung von Betroffenenanträgen erforderlich machen. Hinzu kommen mögliche Betriebsunterbrechungen und interne Aufklärungsaufwände.

Fehlende Dokumentation kann solche Situationen verschärfen. Ohne nachvollziehbare Datenflüsse und Zuständigkeiten lässt sich unter Umständen nicht zeitnah feststellen, welche Personen und Informationen betroffen sind. Diese Unsicherheit kann die Bewertung von Melde- und Benachrichtigungspflichten erschweren.

Solche Folgekosten sind nicht automatisch mit einem ersatzfähigen Schaden gegenüber einem Dienstleister gleichzusetzen. Ob und in welchem Umfang ein vertraglicher Ausgleich verlangt werden kann, hängt insbesondere von Pflichtverletzung, Verantwortlichkeit, Kausalität und den wirksamen Vertragsregelungen ab.

Verfahren, Dokumentationspflichten und Fristen

Verzeichnis und Datenschutz-Folgenabschätzung

Verarbeitungstätigkeiten sind nach Maßgabe des Art. 30 DSGVO zu dokumentieren. Das Verzeichnis des Verantwortlichen beschreibt insbesondere Zwecke, betroffene Personengruppen, Datenkategorien, Empfänger sowie, soweit möglich, vorgesehene Löschfristen und eine allgemeine Beschreibung der Sicherheitsmaßnahmen. Für Auftragsverarbeiter enthält Art. 30 Abs. 2 DSGVO eigene Vorgaben.

Die Ausnahme für Unternehmen oder Einrichtungen mit weniger als 250 Beschäftigten ist begrenzt. Sie greift insbesondere nicht für Verarbeitungen, die nicht nur gelegentlich erfolgen, bestimmte Risiken aufweisen oder besondere Datenkategorien beziehungsweise Daten im Sinne des Art. 10 DSGVO umfassen. Eine geringe Beschäftigtenzahl befreit daher nicht pauschal von der Verzeichnispflicht.

Verarbeitungen, die voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge haben, erfordern nach Art. 35 DSGVO eine Datenschutz-Folgenabschätzung. Diese ist vor Beginn der betreffenden Verarbeitung durchzuführen. Relevant können insbesondere umfangreiche Verarbeitungen besonderer Datenkategorien sowie bestimmte systematische und umfassende Bewertungen persönlicher Aspekte sein. Auch die veröffentlichten Listen der zuständigen Aufsichtsbehörden sind zu berücksichtigen.

Kann ein festgestelltes hohes Risiko nicht durch geeignete Maßnahmen ausreichend eingedämmt werden, ist nach Art. 36 DSGVO vor der Verarbeitung die Aufsichtsbehörde zu konsultieren. Eine Folgenabschätzung ist kein einmaliges Freigabeformular. Insbesondere Änderungen des Risikos können eine Überprüfung erforderlich machen.

Datenschutzbeauftragte und Freigabeprozesse

Ob ein Datenschutzbeauftragter zu benennen ist, richtet sich nach Art. 37 DSGVO und ergänzend § 38 BDSG. Nach § 38 Abs. 1 BDSG besteht die Pflicht bei nichtöffentlichen Stellen insbesondere, soweit diese in der Regel mindestens 20 Personen ständig mit der automatisierten Verarbeitung personenbezogener Daten beschäftigen. Entscheidend ist nicht allein die Größe der Entwicklungsabteilung.

Weitere gesetzliche Benennungstatbestände bleiben bestehen. Dazu gehören nach § 38 Abs. 1 BDSG insbesondere Verarbeitungen, die einer Datenschutz-Folgenabschätzung nach Art. 35 DSGVO unterliegen; insoweit kommt es nicht auf die genannte Personenzahl an.

Ein benannter Datenschutzbeauftragter ist nach Art. 38 DSGVO ordnungsgemäß und frühzeitig einzubeziehen. Er berät und überwacht, übernimmt aber nicht die Verantwortung des Verantwortlichen. Eine interne Stellungnahme ist keine behördliche Zulassung.

Für Eigenentwicklungen besteht allein aufgrund ihrer Eigenschaft als selbst entwickelte Software keine allgemeine datenschutzbehördliche Genehmigungspflicht. Besondere gesetzliche Anforderungen, insbesondere eine gegebenenfalls notwendige vorherige Konsultation, bleiben unberührt.

Betroffenenanträge und Datenschutzverletzungen

Nach Art. 12 Abs. 3 DSGVO muss der Verantwortliche über die auf einen Antrag nach Art. 15 bis Art. 22 DSGVO ergriffenen Maßnahmen unverzüglich, spätestens innerhalb eines Monats nach Eingang informieren. Eine Verlängerung um zwei weitere Monate ist möglich, soweit dies unter Berücksichtigung der Komplexität und der Anzahl der Anträge erforderlich ist. Über die Verlängerung und deren Gründe ist innerhalb des ersten Monats zu unterrichten.

Wird der Verantwortliche auf einen solchen Antrag nicht tätig, muss er nach Art. 12 Abs. 4 DSGVO grundsätzlich ebenfalls innerhalb eines Monats über die Gründe und die vorgesehenen Rechtsschutzmöglichkeiten informieren. Daneben bestehen eigenständige Informationspflichten nach Art. 13 und Art. 14 DSGVO, deren Inhalt und Zeitpunkt vom Erhebungsvorgang abhängen.

Verletzungen des Schutzes personenbezogener Daten sind nach Art. 33 DSGVO unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden an die zuständige Aufsichtsbehörde zu melden. Dies gilt nicht, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Erfolgt die Meldung später, ist die Verzögerung zu begründen. Noch fehlende Informationen können unter den gesetzlichen Voraussetzungen schrittweise nachgereicht werden.

Ein Auftragsverarbeiter muss dem Verantwortlichen eine bekannt gewordene Datenschutzverletzung nach Art. 33 Abs. 2 DSGVO unverzüglich melden. Bei voraussichtlich hohem Risiko ist nach Art. 34 DSGVO grundsätzlich auch eine unverzügliche Benachrichtigung der betroffenen Personen erforderlich. Gesetzliche Ausnahmen sind gesondert zu prüfen. Datenschutzverletzungen müssen außerdem nach Art. 33 Abs. 5 DSGVO dokumentiert werden, auch wenn keine Meldung an die Aufsichtsbehörde erforderlich ist.

Praktische Handlungsschritte für Entwicklung und Betrieb

Vor Beginn der Programmierung

Am Anfang sollte eine verständliche Beschreibung der vorgesehenen Verarbeitung stehen. Technische Anforderungen allein reichen nicht aus. Festzuhalten sind insbesondere:

• die Zwecke wesentlicher Funktionen und die einschlägigen Rechtsgrundlagen;
• erforderliche Datenkategorien und betroffene Personengruppen;
• interne Zugriffsberechtigungen und externe Empfänger;
• Aufbewahrungs-, Lösch- und gegebenenfalls Einschränkungsregeln;
• Zuständigkeiten für Betrieb, Sicherheit und Betroffenenrechte.

Anschließend sollten Datenflüsse und Schnittstellen dargestellt werden. Diese Übersicht kann sichtbar machen, ob Informationen unnötig vervielfältigt oder an bislang nicht berücksichtigte Empfänger übertragen werden. Auch die Erforderlichkeit einer Datenschutz-Folgenabschätzung lässt sich damit fundierter beurteilen.

Bereits in dieser Phase sind notwendige Datenschutzinformationen und gegebenenfalls Einwilligungsprozesse zu planen. Eine Datenschutzerklärung kann fehlende Rechtsgrundlagen oder unverhältnismäßige Funktionen nicht ersetzen.

Während Entwicklung und Freigabe

Datenschutzanforderungen sollten in überprüfbare Abnahmekriterien übersetzt werden. Statt lediglich festzulegen, dass Zugriffe „sicher“ sein müssen, sollte bestimmt werden, welche Nutzerrolle welche Datensätze lesen, verändern oder exportieren darf.

Sicherheits- und Datenschutztests ergänzen gewöhnliche Funktionstests. Je nach System sind insbesondere unberechtigte Zugriffe, fehlerhafte Mandantentrennung, unnötige Protokollierung sowie die tatsächliche Funktionsfähigkeit von Löschung und Auskunft zu prüfen. Auch automatisierte Hintergrundprozesse und Schnittstellen gehören in die Betrachtung.

Externe Komponenten benötigen einen ihrem Risiko angemessenen Auswahl- und Aktualisierungsprozess. Eine Software-Stückliste kann helfen, verwendete Bibliotheken und bekannte Schwachstellen zuzuordnen. Eine solche Liste ist jedoch nicht für jede Anwendung allein aufgrund der DSGVO ausdrücklich vorgeschrieben.

Die Freigabe sollte festgestellte Risiken, getroffene Maßnahmen und verantwortliche Entscheidungen dokumentieren. Eine interne Risikoakzeptanz macht eine rechtswidrige Verarbeitung nicht rechtmäßig. Insbesondere dürfen Veröffentlichungstermine nicht an die Stelle der Prüfung treten, ob das erforderliche Schutzniveau tatsächlich erreicht ist.

Im laufenden Betrieb

Nach der Einführung bleiben risikogerechte Kontrollen erforderlich. Berechtigungen müssen an veränderte Aufgaben angepasst, nicht mehr benötigte Zugänge entfernt und Sicherheitsaktualisierungen bewertet und erforderlichenfalls umgesetzt werden. Auch Löschroutinen sind auf ihre tatsächliche Wirkung zu prüfen.

Neue Funktionen können die rechtliche Einordnung verändern. Eine zunächst einfache Kundenverwaltung kann durch Profilbildung oder zusätzliche Datenabgleiche ein anderes Risikoprofil erhalten. Ebenso können neue Dienstleister oder veränderte Zugriffsmöglichkeiten zusätzliche vertragliche und übermittlungsbezogene Prüfungen auslösen.

Deshalb ist ein geregelter Änderungsprozess zweckmäßig: Wesentliche Erweiterungen werden auf neue Zwecke, zusätzliche Daten, veränderte Empfänger und erhöhte Risiken untersucht. Datenschutzinformationen und Dokumentation müssen mit der tatsächlichen Verarbeitung übereinstimmen. Auch die Außerbetriebnahme benötigt Regeln für Migration, Zugriffsentzug und rechtmäßige Löschung oder Aufbewahrung verbleibender Daten.

Offene Streitfragen und einzelfallabhängige Grenzen

Reichweite der Anonymisierung

Ob Informationen einer identifizierbaren Person zugeordnet werden können, lässt sich nicht allein anhand eines einzelnen technischen Verfahrens beurteilen. Verfügbare Zusatzinformationen, mögliche Verknüpfungen sowie rechtliche und tatsächliche Identifizierungsmöglichkeiten sind einzubeziehen.

Insbesondere bei komplexen Datensätzen und unterschiedlichen Empfängern bleibt die Bewertung einzelfallabhängig. Eine Datenmenge kann für eine Stelle personenbezogen sein, während einer anderen Stelle die vernünftigerweise einsetzbaren Identifizierungsmittel fehlen. Daraus darf jedoch nicht ohne nähere Prüfung auf Anonymität geschlossen werden.

Das Etikett „anonym“ in einer technischen Dokumentation ersetzt keinen belastbaren Nachweis. Außerdem kann sich die Bewertung durch neue Datenbestände oder technische Möglichkeiten verändern. Bei längerfristig verwendeten Datensätzen kann deshalb eine erneute Prüfung erforderlich sein.

Verhältnis von Entwicklungskosten und Schutzpflichten

Art. 25 und Art. 32 DSGVO berücksichtigen Implementierungskosten. Daraus folgt jedoch kein allgemeiner Kostenvorbehalt gegenüber gesetzlichen Anforderungen. Die Kosten sind Teil einer umfassenden Bewertung und nicht deren alleiniger Maßstab.

Schwierig kann die Abgrenzung sein, welche zusätzliche Schutzmaßnahme bei einem konkreten Risiko erforderlich ist. Eine dokumentierte Bewertung sollte insbesondere die möglichen Folgen für betroffene Personen, die Eintrittswahrscheinlichkeit und die Wirksamkeit verfügbarer Alternativen berücksichtigen.

Kann eine geplante Funktion nicht mit angemessenen Schutzmaßnahmen betrieben werden, ist auch ihre Einschränkung oder ein Verzicht auf die betreffende Verarbeitung zu erwägen. Besonders sensible Daten und weitreichende Auswertungen verlangen regelmäßig eine intensivere Prüfung als eng begrenzte, risikoarme Vorgänge.

Weiterentwicklung und Zweckänderung

Die Wiederverwendung vorhandener Daten zur Verbesserung einer Anwendung ist nicht automatisch vom ursprünglichen Erhebungszweck gedeckt. Entscheidend sind die konkrete Verarbeitung, die Erwartungen der betroffenen Personen und die einschlägigen Rechtsgrundlagen.

Soweit eine Weiterverarbeitung auf die Vereinbarkeit mit dem ursprünglichen Zweck gestützt werden soll, sind insbesondere die Kriterien des Art. 6 Abs. 4 DSGVO zu berücksichtigen. Dazu gehören die Verbindung zwischen den Zwecken, der Erhebungskontext, die Art der Daten, mögliche Folgen und geeignete Garantien.

Die Vereinbarkeitsprüfung ersetzt nicht die übrigen Datenschutzanforderungen. Besondere Datenkategorien, bestehende Einwilligungen, gesetzliche Zweckbindungen und Informationspflichten können zusätzliche Grenzen setzen. „Produktverbesserung“ ist deshalb keine unbegrenzte Erlaubnis für Modelltraining, neue Analysen oder umfassende Datenverknüpfungen.

Zusammenfassung

Datenschutz bei eigenentwickelter Software ist eine durchgehende rechtliche und organisatorische Aufgabe. Er beginnt bei der Zweckbestimmung und reicht über Architektur, Testverfahren und Freigabe bis zu Wartung, Löschung und Außerbetriebnahme.

Zentral sind eine tragfähige rechtliche Grundlage, nachvollziehbare Datenflüsse und die wirksame Umsetzung der Grundsätze aus Art. 5 DSGVO. Art. 25 DSGVO verlangt datenschutzgerechte Gestaltung und Voreinstellungen; Art. 32 DSGVO fordert risikogerechte Sicherheit. Ergänzend können insbesondere das BDSG, das TDDDG, das Betriebsverfassungsrecht und besondere Verschwiegenheitspflichten eingreifen.

Weder interne Entwicklung noch der Einsatz externer Fachleute beseitigen die Verantwortung der einsetzenden Organisation. Die konkrete Rollenverteilung muss dennoch für jeden relevanten Verarbeitungsvorgang geprüft werden. Ebenso wenig genügt eine einmalige Prüfung vor Veröffentlichung, wenn spätere Änderungen neue Zwecke, Empfänger oder Risiken schaffen.

Rechtlich belastbar ist ein Entwicklungs- und Betriebsprozess, der Datenschutzanforderungen frühzeitig konkretisiert, ihre technische Umsetzung überprüft und wesentliche Entscheidungen nachvollziehbar dokumentiert. Dokumentation allein heilt allerdings weder eine fehlende Rechtsgrundlage noch unzureichende Schutzmaßnahmen.