Dies ist keine Rechtsberatung, sondern die praktische Checkliste, die wir uns in der Arbeit mit Kunden in Deutschland, Italien und Großbritannien gebaut haben und bei jedem neuen Projekt wiederholen. Sie ersetzt keine Anwältin, verkürzt das Gespräch mit ihr aber erheblich.
Der Grundrahmen: Ihr Kunde ist Verantwortlicher, Sie sind mit hoher Wahrscheinlichkeit Auftragsverarbeiter, und jeder genutzte Clouddienst ist Unterauftragsverarbeiter. Sitzen diese drei Begriffe richtig, ordnet sich der Rest der Liste von selbst.
DSGVO ist keine Papierarbeit, sondern eine Architekturentscheidung. Dokumente beschreiben die Architektur, ersetzen sie aber nicht.
01Die Vertragsebene: AVV und Standardvertragsklauseln
Mit jedem EU-Kunden braucht es einen unterzeichneten Auftragsverarbeitungsvertrag. Da für die Türkei kein Angemessenheitsbeschluss vorliegt, kommen bei Verarbeitung in der Türkei Standardvertragsklauseln und eine kurze Transfer-Folgenabschätzung hinzu. In der Praxis reisen diese drei Dokumente gemeinsam und lassen sich, einmal gut erstellt, in jedem Projekt wiederverwenden.
Schritt zwei ist die Liste der Unterauftragsverarbeiter. Jeder genutzte Dienst — Hosting, Transaktionsmails, Fehlertracking, Analytics, Backups — wird mit Name, Zweck und Region aufgeführt und dem Kunden bereitgestellt. Eine neue Zeile ist vertraglich meldepflichtig; deshalb ist es am praktischsten, die Liste als Seite zu pflegen und im Vertrag zu verlinken.
02Die Architekturebene: Region, Aufbewahrung, Löschung
Für EU-Kunden ist unsere Voreinstellung eindeutig: Datenbank und Objektspeicher in einer EU-Region (Wien oder Irland), Backups in derselben Region. Diese eine Entscheidung vereinfacht die Antworten auf hundert Folgefragen. Greift das Entwicklungsteam aus der Türkei zu, ist das Fernzugriff und wird im AVV so beschrieben.
Aufbewahrungsfristen werden je Datenart festgelegt: Vertrags- und Rechnungsdaten für die gesetzlich geforderten Jahre, Marketingeinwilligungen bis zum Widerruf, Server-Zugriffslogs neunzig Tage, Bewerbungsunterlagen sechs Monate. Diese Fristen in der Software abzubilden — ein Löschfälligkeitsfeld und ein nächtlicher Job — ist verlässlicher als ein Dokument.
Behandeln Sie Lösch- und Auskunftsanfragen ab Tag eins als Feature. Wer die Daten einer Person in einem Vorgang exportieren und löschen kann, für den verliert die gesetzliche Dreißigtagefrist ihren Schrecken. Nachträglich ist es stets mühsam, weil die Daten bis dahin auf fünf Tabellen verteilt sind.
03Alltagspraxis: Cookies, Formulare, Notfallplan
Das Cookie-Banner ist kein Gestaltungselement, sondern ein technisches Versprechen: Analyse- und Marketingskripte dürfen vor der Einwilligung nicht laden, und „Ablehnen“ muss so sichtbar sein wie „Akzeptieren“. Wer das beherrscht, hat die ersten beiden Punkte jeder Prüfliste bereits abgehakt.
Trennen Sie in Formularen die Zwecke: Projektanfrage und Newsletter sind zwei getrennte Einwilligungen, und kein Kästchen ist vorangekreuzt. Jedes Formular verlinkt eine Datenschutzinformation, die tatsächlich die Felder dieses Formulars beschreibt.
Der letzte Punkt ist der, den niemand vorbereiten will: der Notfallplan bei Datenpannen. Eine Seite mit: wer informiert wird, wo die Logs gelesen werden, was dem Kunden geschrieben wird und wer die Zweiundsiebzig-Stunden-Frist im Blick hat. Diese Seite an einem ruhigen Tag zu schreiben ist weit günstiger als an einem schlechten.
Geschrieben von
Das Paradigma7-Team
Produkt, Entwicklung und Betrieb
Wir sind ein Team aus Ankara und entwickeln Software für Europa. Nichts davon ist Theorie: Es sind die Prozesse, die wir in Kundenprojekten tatsächlich fahren.
Über uns