DSGVO-konforme Softwareentwicklung: was im Vertrag und im Code stehen muss

DSGVO-konforme Softwareentwicklung heißt, den Datenschutz vor der ersten Codezeile zu klären: Rollen, Auftragsverarbeitungsvertrag, technische Maßnahmen, Speicherort und Löschfristen. Nachträglich lässt sich das nur mit Umbauten korrigieren, weil Datenmodell und Berechtigungen davon abhängen. Für Auftraggeber in Deutschland ist der Datenschutz damit Teil der Leistungsbeschreibung.

Verantwortlicher und Auftragsverarbeiter

Die Verordnung verteilt Pflichten nach Rollen. Verantwortlicher ist, wer über Zweck und Mittel der Verarbeitung entscheidet – in aller Regel das auftraggebende Unternehmen. Auftragsverarbeiter ist, wer personenbezogene Daten weisungsgebunden für diesen Zweck verarbeitet, etwa ein Entwicklungsdienstleister mit Zugriff auf Echtdaten oder ein Hostinganbieter.

Diese Zuordnung ist keine Formalie: Sie bestimmt, wer Betroffenenanfragen beantwortet, wer eine Datenpanne meldet und wer das Verzeichnis der Verarbeitungstätigkeiten führt. Sie gehört deshalb ins Angebot und nicht in eine Fußnote.

Ein zweiter Punkt betrifft die Beauftragung selbst: Wer Software einkauft, sollte die Anforderungen an den Datenschutz bereits in der Anfrage nennen und nicht erst im Vertragsentwurf. Sonst kalkulieren Anbieter unterschiedliche Leistungsumfänge, und der günstigste Preis stammt regelmäßig von dem Angebot, das Löschkonzept, Rollenmodell und Protokollierung weggelassen hat. Der Vergleich wird dadurch wertlos, und die Nacharbeit landet später beim Auftraggeber.

DSGVO-konforme Softwareentwicklung beginnt beim AVV

Sobald ein Dienstleister mit personenbezogenen Daten in Berührung kommt, wird ein AVV geschlossen. Inhaltlich gehören hinein: Gegenstand und Dauer der Verarbeitung, Art der Daten und Kategorien betroffener Personen, Weisungsbindung, Vertraulichkeit der eingesetzten Personen, Unterstützung bei Betroffenenrechten, Rückgabe oder Löschung nach Projektende sowie eine Liste der weiteren Auftragsverarbeiter mit Widerspruchsrecht des Auftraggebers.

Praktischer Hinweis für Projekte: Der häufigste Verstoß entsteht nicht im Betrieb, sondern beim Testen mit einer Kopie der Echtdaten. Wer Testdaten aus dem Produktivbestand zieht, braucht dafür eine Grundlage und ein Verfahren zur Anonymisierung.

Technische und organisatorische Maßnahmen

Die TOM sind die Anlage zum AVV und beschreiben, wie geschützt wird. In Softwareprojekten sind das vor allem:

• Zugriffskontrolle. Rollen und Rechte in der Anwendung, getrennte Konten, Mehrfaktoranmeldung für Verwaltungszugänge.
• Verschlüsselung. Transportverschlüsselung durchgehend, Verschlüsselung ruhender Daten und Sicherungen.
• Trennung. Getrennte Umgebungen für Entwicklung, Test und Betrieb; bei mandantenfähigen Anwendungen eine geprüfte Datentrennung.
• Nachvollziehbarkeit. Protokollierung der Zugriffe auf sensible Datensätze, mit eigener Aufbewahrungsfrist.
• Datensparsame Fehlerberichte. Abstürze und Protokolle dürfen keine personenbezogenen Inhalte enthalten; eine Kennung statt Klartext genügt für die Fehlersuche.
• Wiederherstellbarkeit. Sicherungen, die regelmäßig zurückgespielt und geprüft werden.

Hosting und Datenstandort in der EU

Der Speicherort ist die Frage, die deutsche Auftraggeber zuerst stellen. Server in Deutschland oder der EU vermeiden die Diskussion über Drittlandtransfers vollständig. Zu prüfen ist dabei die ganze Kette: Anwendung, Datenbank, Sicherungen, Protokolldienste, Fehlerberichte, E-Mail-Versand und Webanalyse. Ein einzelner externer Dienst genügt, um Daten unbemerkt außerhalb der EU zu verarbeiten. Wir betreiben unsere Anwendungen in Deutschland und der EU und setzen zur Reichweitenmessung Matomo auf eigenen Servern ein.

DSGVO-konforme Softwareentwicklung im Code

Vier Anforderungen lassen sich nur in der Software selbst erfüllen:

• Datenminimierung. Jedes Feld braucht einen Zweck. Ein Geburtsdatum, das niemand auswertet, ist ein Risiko ohne Nutzen.
• Löschkonzept. Fristen je Datenart, technisch umgesetzt als geplanter Lauf, nicht als Handarbeit. Zu klären ist auch, was mit Verweisen und Sicherungen geschieht.
• Betroffenenrechte. Auskunft, Berichtigung, Löschung und Datenübertragbarkeit brauchen einen Export, der ohne Entwicklereingriff funktioniert.
• Einwilligungen. Wo eine Einwilligung die Grundlage ist, muss nachweisbar sein, wer wann wozu eingewilligt hat – und der Widerruf muss ebenso einfach sein.

Diese Punkte gehören in die Anforderungsbeschreibung und damit in die Abnahmekriterien, siehe Lastenheft und Pflichtenheft. Wo personenbezogene Daten in der Datenbank liegen, hilft eine saubere Struktur beim Löschen erheblich – dazu PostgreSQL für Unternehmensanwendungen.

Sprachmodelle als Auftragsverarbeiter

Sobald eine Anwendung ein Sprachmodell aufruft, verlässt der übergebene Text das eigene System. Zu klären sind vier Punkte: welcher Anbieter verarbeitet, wo er verarbeitet, ob Eingaben zum Training verwendet werden und wie lange sie gespeichert bleiben. Der Anbieter gehört in die Liste der Auftragsverarbeiter, die Datenübergabe in die TOM.

Technisch hilft ein zentraler Durchgang für alle Modellaufrufe: Wir leiten sie über ein eigenes Gateway mit Kostengrenze, sodass Protokollierung, Anbieterwahl und Filterung an einer Stelle geregelt sind statt in jedem Dienst neu. Wie das in Projekten umgesetzt wird, steht auf der Seite Softwareentwicklung.