← Zurück zum Blog

DSGVO & Datenschutz in eigenen Softwareprojekten - die Checkliste

Was du bei Auftragsentwicklung zum Thema Datenschutz vertraglich und technisch absichern musst, bevor personenbezogene Daten verarbeitet werden.

DSGVODatenschutzAuftragsverarbeitungCompliance

Sobald deine neue Software personenbezogene Daten verarbeitet - Kundendaten, Mitarbeiterdaten, schon eine simple E-Mail-Adresse -, bist du datenschutzrechtlich in der Pflicht. Das gilt unabhängig davon, ob du die Software selbst entwickelst oder entwickeln lässt. Und die Verantwortung bleibt bei dir: Als Auftraggeber bist du in aller Regel der datenschutzrechtlich Verantwortliche, nicht dein Entwicklungspartner. Diese Checkliste geht nicht noch einmal durch, was die DSGVO grundsätzlich verlangt, sondern zeigt konkret, was du bei der Beauftragung einer Individualsoftware prüfen und vertraglich absichern musst.

Auftragsverarbeitungsvertrag (AVV) nicht vergessen

Wenn dein Entwicklungspartner im Rahmen des Projekts Zugriff auf personenbezogene Daten hat - etwa bei Tests mit echten Kundendaten oder beim späteren Hosting -, benötigst du einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Ohne AVV haftest du im Ernstfall für Verstöße des Auftragnehmers mit, die du vertraglich hättest ausschließen können.

Achte dabei auf drei Punkte, die in der Praxis am häufigsten übersehen werden:

  • Weisungsgebundenheit: Der AVV muss festhalten, dass der Auftragnehmer Daten ausschließlich nach deiner dokumentierten Weisung verarbeitet - nicht nach eigenem Ermessen.
  • Löschung nach Projektende: Was passiert mit Testdaten, Backups und Staging-Umgebungen, sobald das Projekt abgeschlossen ist? Ohne klare Regelung bleiben Kopien deiner Daten oft monatelang auf Entwicklerrechnern oder in vergessenen Cloud-Buckets liegen.
  • Kontrollrechte: Der Vertrag sollte dir das Recht einräumen, die Einhaltung der Vereinbarung zu prüfen - etwa durch Nachweise oder ein Audit.

Subunternehmer und Subprozessoren offenlegen lassen

Kaum ein Entwicklungspartner arbeitet vollständig allein. Hosting-Provider, E-Mail-Versanddienste, Monitoring-Tools, KI-APIs - jeder dieser Drittanbieter, der mit euren personenbezogenen Daten in Berührung kommt, ist ein Subprozessor im Sinne der DSGVO. Verlange vor Projektstart eine vollständige Liste aller eingesetzten Subunternehmer inklusive ihres Verarbeitungszwecks und Standorts. Kläre außerdem, ob und wie du informiert wirst, wenn sich diese Liste im Projektverlauf ändert - eine Klausel, die im Eifer der Vertragsverhandlung gern vergessen wird, aber später zu bösen Überraschungen führt, wenn plötzlich ein neuer Analytics-Dienst Daten mitliest.

Datenschutz durch Technikgestaltung von Anfang an

"Privacy by Design" ist keine freiwillige Zusatzleistung, sondern gesetzliche Pflicht nach Art. 25 DSGVO. Konkret bedeutet das für dein Pflichtenheft:

  • Welche Daten werden wirklich benötigt (Datenminimierung)? Jedes Feld, das "vielleicht später mal nützlich sein könnte", ist ein zusätzliches Risiko und gehört nicht in die erste Version.
  • Wie werden Daten verschlüsselt - bei Übertragung und bei Speicherung?
  • Gibt es eine Löschfunktion, die tatsächlich alle Kopien der Daten erfasst, inklusive Backups, Log-Dateien und Suchindizes?
  • Sind Zugriffsrechte so granular, dass nur berechtigte Rollen bestimmte Daten sehen?
  • Werden Testumgebungen mit anonymisierten oder synthetischen Daten befüllt, statt mit echten Kundendaten zu arbeiten?

Wenn ein Entwicklungspartner diese Fragen im Angebot nicht beantworten kann oder will, ist das ein Warnsignal - nicht erst nach Vertragsschluss.

Serverstandort und Drittlandtransfer

Kläre vor Projektstart, wo die Daten gehostet werden. Server außerhalb der EU/des EWR können einen Drittlandtransfer auslösen, der zusätzliche rechtliche Absicherung erfordert (z.B. Standardvertragsklauseln). Viele Mittelständler übersehen das, weil der Hosting-Anbieter vom Entwicklungspartner ausgewählt wird, ohne dass der Serverstandort explizit vertraglich festgelegt ist.

Das gilt auch für Nebendienste, die leicht vergessen werden: Wenn Fehler-Tracking, E-Mail-Versand oder eine KI-API in den USA gehostet sind und dabei personenbezogene Daten verarbeiten, brauchst du dieselbe rechtliche Absicherung wie beim Hauptsystem. Lass dir schriftlich bestätigen, in welchem Land jede Komponente der Architektur läuft - nicht nur die Hauptdatenbank.

Betroffenenrechte technisch abbilden

Die DSGVO gibt Nutzern Rechte auf Auskunft, Berichtigung, Löschung und Datenübertragbarkeit. Diese Rechte müssen sich technisch umsetzen lassen - nicht nur auf dem Papier. Frage konkret:

  • Kann ein Nutzer seine Daten in einem gängigen, maschinenlesbaren Format exportieren?
  • Kann ein Admin eine vollständige Löschung auf Anfrage durchführen, ohne manuell durch die Datenbank zu suchen?
  • Wie lange dauert eine Löschanfrage in der Praxis, und wird sie protokolliert? Die DSGVO verlangt eine Reaktion in der Regel innerhalb eines Monats - ohne ein technisches Werkzeug dafür wird das schnell zum manuellen Notfall.
  • Was passiert mit Daten in Backups, wenn ein Löschantrag eingeht? Eine Löschfunktion, die nur die Live-Datenbank bereinigt, ist unvollständig.

Meldepflichten bei Datenpannen vertraglich regeln

Kommt es später zu einer Datenpanne - etwa einem unbefugten Zugriff auf die Datenbank -, hast du als Verantwortlicher in der Regel nur 72 Stunden Zeit, um die Aufsichtsbehörde zu informieren (Art. 33 DSGVO). Diese Frist läuft ab dem Zeitpunkt, an dem der Vorfall bekannt wird - nicht ab dem Zeitpunkt, an dem er passiert ist. Genau hier entsteht das Problem: Wenn dein Entwicklungspartner einen Vorfall bemerkt, aber vertraglich nicht verpflichtet ist, dich unverzüglich zu informieren, tickt deine Frist möglicherweise schon, ohne dass du es weißt. Lege deshalb im Vertrag eine kurze, konkrete Meldefrist fest - etwa 24 Stunden ab Kenntnis des Vorfalls - und verlange, dass die Meldung mindestens Art, Umfang und betroffene Datenkategorien benennt, damit du deiner eigenen Meldepflicht fristgerecht nachkommen kannst.

Dokumentation der Verarbeitungstätigkeiten

Als Verantwortlicher musst du ein Verzeichnis von Verarbeitungstätigkeiten führen (Art. 30 DSGVO). Die technische Dokumentation deines neuen Systems - welche Daten wo gespeichert werden, wer Zugriff hat - ist die Grundlage dafür. Verlange diese Dokumentation als festen Projektbestandteil, nicht als nachträgliche Recherche. Am einfachsten ist es, sie direkt als Abnahmekriterium im Vertrag zu verankern: Ohne aktuelle Verarbeitungsübersicht keine finale Abnahme.

Checkliste zum Abhaken vor Vertragsunterschrift

  • AVV mit Weisungsgebundenheit, Löschregelung und Kontrollrechten liegt vor
  • Liste aller Subprozessoren inklusive Standort ist bekannt
  • Datenminimierung, Verschlüsselung und Löschfunktion sind im Pflichtenheft verankert
  • Serverstandort für Haupt- und Nebendienste ist vertraglich fixiert
  • Export- und Löschfunktion für Betroffenenrechte sind als Feature eingeplant, nicht als Nice-to-have
  • Technische Dokumentation für das Verarbeitungsverzeichnis ist als Liefergegenstand vereinbart
  • Meldefrist des Entwicklungspartners bei Datenpannen ist vertraglich fixiert (z.B. 24 Stunden ab Kenntnis)

Fazit

Datenschutz in Softwareprojekten lässt sich nicht nachträglich draufsetzen. AVV, Subprozessoren, Datenminimierung, Serverstandort und technisch umgesetzte Betroffenenrechte gehören ins Pflichtenheft und in den Vertrag, bevor die erste Zeile Code geschrieben wird. Je klarer diese Punkte im Angebot stehen, desto einfacher lässt sich später auch die vertraglich zugesicherte Festpreis-Leistung gegen Nachforderungen abgrenzen.

Häufig gestellte Fragen

Brauche ich einen Auftragsverarbeitungsvertrag mit meinem Entwicklungspartner?

Ja, wenn der Entwicklungspartner im Rahmen des Projekts Zugriff auf personenbezogene Daten hat, etwa beim Testen mit echten Kundendaten oder beim Hosting. Ohne AVV nach Art. 28 DSGVO haftest du für Verstöße des Auftragnehmers mit.

Was bedeutet "Privacy by Design" konkret für mein Pflichtenheft?

Es bedeutet, Datenminimierung, Verschlüsselung, vollständige Löschfunktionen (inklusive Backups) und granulare Zugriffsrechte von Anfang an als Anforderungen zu definieren, statt sie nachträglich zu ergänzen.

Warum ist der Serverstandort datenschutzrechtlich relevant?

Server außerhalb der EU/des EWR können einen Drittlandtransfer auslösen, der zusätzliche rechtliche Absicherung wie Standardvertragsklauseln erfordert. Das gilt nicht nur für die Hauptdatenbank, sondern auch für Nebendienste wie E-Mail-Versand oder Fehler-Tracking. Der Serverstandort sollte deshalb vor Projektstart vertraglich festgelegt werden.

Muss ich als Auftraggeber die Betroffenenrechte technisch umsetzen lassen?

Ja. Auskunft, Berichtigung, Löschung und Datenübertragbarkeit müssen sich technisch abbilden lassen, zum Beispiel durch einen Datenexport für Nutzer und eine vollständige Löschfunktion für Admins, die auch Backups erfasst - statt nur auf dem Papier zu existieren.

Muss ich auch Subunternehmer meines Entwicklungspartners kennen?

Ja. Jeder Dienstleister, der mit personenbezogenen Daten in Berührung kommt - etwa Hosting-Provider, E-Mail-Versanddienste oder KI-APIs - gilt als Subprozessor. Lass dir vor Projektstart eine vollständige Liste geben und vereinbare, dass du über spätere Änderungen informiert wirst.

Wie schnell muss mich mein Entwicklungspartner bei einer Datenpanne informieren?

Das solltest du vertraglich festlegen, zum Beispiel innerhalb von 24 Stunden ab Kenntnis des Vorfalls. Als Verantwortlicher hast du nur 72 Stunden Zeit, eine Datenpanne bei der Aufsichtsbehörde zu melden (Art. 33 DSGVO) - diese Frist läuft ab dem Zeitpunkt, an dem der Vorfall bekannt wird, nicht ab dem eigentlichen Vorfall.

Verwandte Themen

Dieser Artikel bietet allgemeine Informationen und ersetzt keine rechtliche Beratung im Einzelfall. Lass vertragliche und datenschutzrechtliche Fragen von einer Anwältin oder einem Anwalt prüfen.


Datenschutzanforderungen gehören ins Pflichtenheft, bevor du ein Angebot einholst. Pairlios KI prüft dein Dokument kostenlos auf Lücken. Jetzt kostenlos prüfen →