DSGVO-Compliance: Der massgebliche Leitfaden für IT-Verantwortliche und Leiter der digitalen Transformation

DSGVO-Compliance bezeichnet den Zustand, die Pflichten der Verordnung (EU) 2016/679 – der Datenschutz-Grundverordnung – nachweisbar zu erfüllen, wann immer ein Unternehmen personenbezogene Daten von Personen in der Europäischen Union erhebt, speichert, verwendet, weitergibt oder löscht. In der Praxis bedeutet das: für jede Verarbeitungstätigkeit eine Rechtsgrundlage zu besitzen, darüber transparent zu informieren, die Rechte der Betroffenen zu erfüllen, die Daten mit geeigneten technischen und organisatorischen Massnahmen zu schützen, bestimmte Datenschutzverletzungen innerhalb von 72 Stunden zu melden und all dies gegenüber einer Aufsichtsbehörde nachweisen zu können.

Genau dieser letzte Punkt unterscheidet DSGVO-Compliance von den meisten Regelungsprojekten, die eine IT-Organisation je durchgeführt hat. Die DSGVO verbietet nicht nur bestimmte Verhaltensweisen; sie legt die Beweislast auf den Verantwortlichen. Artikel 24 verlangt, die Einhaltung nachweisen zu können, wodurch Dokumentation, Protokollierung, Design-Entscheidungen und Testergebnisse zu gleichrangigen Arbeitsergebnissen werden. Für einen CTO oder IT-Leiter ist DSGVO-Compliance deshalb kein Rechtsdokument, das abgelegt und vergessen wird. Sie ist eine operative Disziplin, die bis in Architektur, Softwareentwicklungslebenszyklus, Testdatenmanagement, Lieferantenverträge und Incident Response hineinreicht.

Dieser Leitfaden ist für die Menschen geschrieben, die sie aufbauen müssen: IT-Verantwortliche, CTOs, Leiter der digitalen Transformation und Datenschutzbeauftragte, die mit Entwicklungsteams zusammenarbeiten. Er behandelt die Entstehungsgeschichte der Verordnung, die sieben Grundsätze und ihre Bedeutung in technischer Hinsicht, die Rechtsgrundlagen der Verarbeitung, die Betroffenenrechte und ihre Erfüllung im Massstab, die zentralen operativen Pflichten, die Unterschiede zu verwandten Regelwerken wie CCPA und UK GDPR, einen Zwölf-Monats-Fahrplan zur Umsetzung, die konkreten Auswirkungen auf Softwareentwicklung und Testing, die Fehlannahmen, die Programme scheitern lassen, die tatsächlichen Kosten der Nichteinhaltung und die Richtung, in die sich die Verordnung mit Inkrafttreten des EU AI Act entwickelt.

Was ist DSGVO-Compliance und warum ist sie weiterhin relevant?

Woher kommt die DSGVO-Compliance?

Die DSGVO ist nicht aus dem Nichts entstanden. Ihre Wurzeln reichen zurück in ein Jahrzehnt europäischen Datenschutzrechts, das die meisten IT-Teams nie lesen mussten.

Der Ausgangspunkt ist die Richtlinie 95/46/EG aus dem Jahr 1995. Eine Richtlinie gibt ein Ziel vor, das jeder Mitgliedstaat durch eigenes nationales Recht umsetzen muss. Achtundzwanzig Länder erliessen folglich achtundzwanzig unterschiedliche Datenschutzgesetze – mit unterschiedlichen Definitionen, Registrierungspflichten, Meldegrenzen und Sanktionen. Ein paneuropäisches Lohnsystem musste im Jahr 2010 gleichzeitig einen deutschen Betriebsrat, ein französisches Registrierungsregime und ein britisches Melderegime zufriedenstellen. Diese Zersplitterung war teuer – und sie war genau dort am teuersten, wo Daten am schnellsten fliessen: über Grenzen hinweg und innerhalb multinationaler Konzerne.

Im Januar 2012 schlug die Europäische Kommission eine einzige, unmittelbar geltende Verordnung statt einer Richtlinie vor. Der Unterschied ist wesentlich. Eine Verordnung gilt in allen Mitgliedstaaten ohne nationale Umsetzung, das heisst: ein Text, ein Begriffsapparat, ein Sanktionsrahmen. Die Verordnung (EU) 2016/679 wurde am 27. April 2016 angenommen, am 4. Mai 2016 im Amtsblatt veröffentlicht und wurde nach einer zweijährigen Übergangsfrist am 25. Mai 2018 verbindlich – eine Frist, die viele Organisationen deutlich zu langsam genutzt haben.

Zwei Gestaltungsentscheidungen im finalen Text haben alles Weitere geprägt. Erstens erhielt die Verordnung durch Artikel 3 extraterritoriale Wirkung: Sie folgt der betroffenen Person und nicht dem Unternehmen. Zweitens wählte sie ein Ergebnis- und Rechenschaftsmodell statt eines Checklistenmodells. Die Verordnung schreibt nur selten vor, welche Technologie einzusetzen ist. Sie schreibt vor, welches Ergebnis erreicht werden muss, und verlangt anschliessend den Nachweis. Deshalb sieht DSGVO-Compliance in einem Krankenhaus, einer Bank und einem SaaS-Scale-up unterschiedlich aus – und deshalb kann dieselbe Klausel in Artikel 32 in einem Unternehmen Verschlüsselung verlangen und in einem anderen rollenbasierte Zugriffskontrolle plus eine automatisierte Löschroutine.

Das Wort „Compliance” trägt die richtige Betonung. Es stammt vom lateinischen complere – ausfüllen, vervollständigen. DSGVO-Compliance ist ein fortlaufender Zyklus des Vervollständigens von Pflichten, kein Zertifikat an der Wand. Aufsichtsbehörden, Gerichte und Datenschutzaufsichten betonen immer dasselbe: Compliance ist ein Zustand, den man aufrechterhält, und sie verfällt in dem Moment, in dem ein neues System, ein neuer Dienstleister oder ein neuer Datenfluss ohne Prüfung entsteht.

Was verlangt DSGVO-Compliance konkret?

DSGVO-Compliance: die nachweisbare Übereinstimmung sämtlicher Verarbeitungen personenbezogener Daten mit der Verordnung (EU) 2016/679 – einschliesslich Rechtsgrundlage, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit, Rechenschaftspflicht, Betroffenenrechte, Sicherheit der Verarbeitung, Umgang mit Datenschutzverletzungen und rechtmässige internationale Übermittlungen – belegt durch Dokumentation, die eine Aufsichtsbehörde prüfen kann.

Aufgeschlüsselt ergeben sich daraus acht konkrete Pflichten, die eine IT-Organisation jederzeit auf Anfrage erfüllen können muss:

1. Eine dokumentierte Rechtsgrundlage für jede Verarbeitungstätigkeit, zugeordnet zu Artikel 6 und, wo relevant, Artikel 9.
2. Ein Datenverzeichnis, das zeigt, welche personenbezogenen Daten existieren, wo sie liegen, warum sie existieren, wer darauf zugreifen darf, wie lange sie gespeichert werden und wohin sie übermittelt werden.
3. Transparente Information der Betroffenen in klarer und einfacher Sprache, in der Regel über mehrschichtige Datenschutzhinweise und Just-in-time-Einwilligungsoberflächen.
4. Funktionierende Prozesse für Betroffenenrechte – Auskunft, Berichtigung, Löschung, Einschränkung, Übertragbarkeit, Widerspruch und Rechte im Zusammenhang mit automatisierter Entscheidungsfindung – mit überwachten Fristen.
5. Risikogerechte Sicherheitsmassnahmen nach Artikel 32, einschliesslich Verschlüsselung, Belastbarkeit, Wiederherstellungsfähigkeit und regelmässiger Tests.
6. Eine Fähigkeit zur Reaktion auf Datenschutzverletzungen, die klassifizieren, eindämmen, bewerten und – soweit erforderlich – innerhalb von 72 Stunden melden kann.
7. Lieferanten- und Übermittlungs-Governance mit Auftragsverarbeitungsverträgen nach Artikel 28 und Übermittlungsmechanismen nach Kapitel V.
8. Eine Rechenschaftsschicht – Verzeichnis von Verarbeitungstätigkeiten, DPIAs, Richtlinien, Schulungsnachweise und Entscheidungsprotokolle –, die die sieben Punkte oben von Behauptungen in Nachweise verwandelt.

Bemerkenswert ist, was fehlt: Es gibt keine vorgeschriebene Technologie, keine Pflichtzertifizierung und keine feste Dokumentenvorlage. Die DSGVO definiert Ergebnisse und überlässt die Umsetzung der Organisation. Diese Freiheit ist zugleich die Falle. Sie bedeutet, dass es keinen Abkürzungsweg gibt ausser der eigentlichen Arbeit: erfassen, entscheiden, dokumentieren, testen.

Warum ist DSGVO-Compliance ein Geschäftsthema und nicht nur ein rechtliches?

DSGVO-Compliance als reine Rechtsaufgabe zu behandeln, ist der häufigste Grund, warum Programme ins Stocken geraten. Die Pflichten sind rechtlichen Ursprungs, aber die Kontrollen, die sie erfüllen, leben in Systemen, Code und Betrieb. Drei kommerzielle Dynamiken machen das konkret.

Beschaffung ist datenschutzgesteuert geworden. Unternehmenskunden in regulierten Branchen versenden Sicherheits- und Datenschutzfragebögen mit DSGVO-spezifischen Nachweisanforderungen: aktuelle Verarbeitungsverzeichnisse, DPIA-Zusammenfassungen, Listen von Unterauftragsverarbeitern, Transfer Impact Assessments, Historie von Datenschutzverletzungen und Auditrechte. Organisationen, die diese Dokumente nicht liefern können, verlieren Aufträge oder absorbieren monatelange Prüfungen. Compliance-Artefakte sind zu Vertriebsmaterial geworden.

Vertrauen hat einen Preis. Kunden, Mitarbeitende und Partner entscheiden darüber, wo sie personenbezogene Daten platzieren, anhand der wahrgenommenen Qualität des Umgangs mit ihnen. Eine öffentlich gemeldete Datenschutzverletzung beschädigt diese Wahrnehmung schneller, als jedes Marketingprogramm sie wieder aufbauen kann – und die Wirkung hält weit über das Meldefenster hinaus an.

Datenprogramme werden durch Datenrechtmässigkeit begrenzt. Analytics, Personalisierung, maschinelles Lernen, Cloud-Migration und generative KI verbrauchen alle personenbezogene Daten. Jedes davon braucht eine Rechtsgrundlage, einen Zweck, eine Löschregel und häufig eine DPIA. Organisationen mit ausgereifter DSGVO-Compliance liefern Dateninitiativen schneller, weil die rechtliche Grundlage bereits steht. Organisationen ohne sie entdecken das Problem mitten im Projekt, wenn die Architektur eingefroren und Nacharbeit teuer ist.

Bei den Kunden von Greyson in der CEE-Region ist das Muster konsistent: Die Organisationen, die DSGVO-Compliance als Engineering-Fähigkeit und nicht als jährliche Papierübung behandeln, sind diejenigen, die neue Technologie ohne Compliance-Krise in jedem zweiten Quartal einführen können.

Wer muss die DSGVO einhalten?

Die DSGVO beantwortet diese Frage in zwei Stufen. Der sachliche Anwendungsbereich definiert, was reguliert wird – personenbezogene Daten und deren Verarbeitung. Der räumliche Anwendungsbereich definiert, wer gebunden ist, und er ist weiter gefasst, als die meisten Nicht-EU-Organisationen annehmen.

Was ist der sachliche Anwendungsbereich – was gilt als personenbezogene Daten?

Artikel 4 Absatz 1 definiert personenbezogene Daten als alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Entscheidend ist das Wort identifizierbar. Daten sind personenbezogen, wenn sie mit einer Person verknüpft werden können – direkt oder indirekt, unter Verwendung von Mitteln, deren Einsatz wahrscheinlich ist. Dazu gehören offensichtliche Identifikatoren wie Name, E-Mail-Adresse, nationale Identifikationsnummer und Kontonummer, aber auch weniger offensichtliche:

• Online-Kennungen – IP-Adressen, Cookie-IDs, Geräte-Fingerprints, Werbe-IDs und mobile Advertising IDs. Die DSGVO nennt diese ausdrücklich.
• Standortdaten – GPS-Spuren, Mobilfunkzellendaten, Check-in-Datensätze.
• Pseudonymisierte Daten – Daten, bei denen direkte Identifikatoren ersetzt wurden, eine Re-Identifizierung aber weiterhin möglich ist. Pseudonymisierte Daten bleiben personenbezogene Daten und im Anwendungsbereich. Dies ist eines der folgenreichsten technischen Missverständnisse des Feldes.
• Besondere Kategorien nach Artikel 9 – rassische oder ethnische Herkunft, politische Meinungen, religiöse oder weltanschauliche Überzeugungen, Gewerkschaftszugehörigkeit, genetische Daten, biometrische Daten zur eindeutigen Identifizierung, Gesundheitsdaten sowie Daten zum Sexualleben oder zur sexuellen Orientierung.
• Daten über Straftaten nach Artikel 10, deren Verarbeitung eine amtliche Stelle oder eine ausdrückliche rechtliche Ermächtigung erfordert.
• B2B-Kontaktdaten – eine geschäftliche E-Mail-Adresse samt Funktion einer namentlich bekannten Person ist personenbezogen. Der Unternehmenskontext nimmt sie nicht aus dem Anwendungsbereich heraus.

Zwei Klarstellungen ersparen viele Diskussionen. Erstens: Anonymisierte Daten fallen nicht unter die DSGVO – aber nur, wenn die Anonymisierung tatsächlich irreversibel ist. Der Europäische Datenschutzausschuss hat klargestellt, dass Anonymisierung Singling-out, Verkettbarkeit und Inferenzangriffe widerstehen muss, wobei alle wahrscheinlich eingesetzten Mittel zu berücksichtigen sind. Die meisten „anonymisierten” Exporte, die in Unternehmen kursieren, bestehen diesen Test nicht. Zweitens: Aggregierte Statistiken, die aus personenbezogenen Daten abgeleitet wurden, sind nicht automatisch aus dem Anwendungsbereich heraus – entscheidend ist, ob Einzelpersonen identifizierbar bleiben.

Was ist der räumliche Anwendungsbereich – gilt die DSGVO auch ausserhalb der EU?

Artikel 3 setzt zwei voneinander unabhängige Auslöser; jeder einzelne genügt.

Artikel 3 Absatz 1 – Niederlassungsprinzip. Die DSGVO gilt für Verarbeitungen im Rahmen der Tätigkeiten einer Niederlassung in der Union, unabhängig davon, ob die Verarbeitung selbst in der Union stattfindet. Eine slowakische Gesellschaft, die Daten auf Servern in Asien verarbeitet, ist erfasst. Ebenso eine Zweigstelle, ein Vertreter oder eine dauerhafte Einrichtung, über die Tätigkeit in der Union ausgeübt wird.

Artikel 3 Absatz 2 – Marktortprinzip. Die DSGVO gilt für Organisationen ohne Niederlassung in der Union, wenn sie betroffenen Personen in der Union Waren oder Dienstleistungen anbieten oder deren Verhalten beobachten. Erwägungsgrund 23 stellt klar, dass eine lediglich aus der EU abrufbare Website nicht genügt; es muss ein Hinweis auf die Absicht bestehen, Waren oder Dienstleistungen für Personen in der EU anzubieten – etwa Preisangaben in Euro, EU-sprachige Website-Versionen, Lieferoptionen in Mitgliedstaaten oder auf EU-Märkte gerichtete Werbung. Erwägungsgrund 24 erfasst die Beobachtung, einschliesslich Verhaltenswerbung, Analyse-Profiling, Tracking-Technologien und Wearables.

Deshalb liegt ein US-amerikanisches, indisches oder brasilianisches Unternehmen mit europäischen Kunden, mit durch Analytics verfolgten europäischen Website-Besuchern oder mit europäischen Beschäftigten in der Lohnbuchhaltung in der Regel im Anwendungsbereich. Wo Artikel 3 Absatz 2 greift, verlangt Artikel 27 die Benennung eines Vertreters in der Union, sofern keine Ausnahme vorliegt. Die Durchsetzung gegenüber Nicht-EU-Organisationen stützt sich auf Kooperationsmechanismen nach Artikel 50, Rechtshilfe und zunehmend auf den praktischen Druck des Marktzugangs.

Wer ist wer im DSGVO-Ökosystem?

Rollen richtig zu bestimmen ist keine Semantik. Die Rolle bestimmt Ihre Pflichten, Ihr Haftungsrisiko und die Verträge, die Sie abschliessen müssen. Ein überraschender Anteil der Compliance-Fehler geht auf Organisationen zurück, die sich als Auftragsverarbeiter eingestuft haben, obwohl sie tatsächlich Verantwortliche waren.

Wer ist Verantwortlicher und wer Auftragsverarbeiter?

Der Verantwortliche ist die Organisation, die entscheidet, warum und wie personenbezogene Daten verarbeitet werden. Der Auftragsverarbeiter führt diese Entscheidungen aus. Der Abgrenzungstest ist faktisch, nicht vertraglich: Sie können sich nicht von Verantwortlichkeiten befreien, indem Sie sich im Vertrag als Auftragsverarbeiter bezeichnen, wenn Sie tatsächlich über Zwecke und Mittel entscheiden.

Mehrere Konstellationen bringen Organisationen zu Fall. Ein SaaS-Anbieter, der Kundendaten streng nach dokumentierter Weisung verarbeitet, ist Auftragsverarbeiter – nutzt er diese Daten jedoch für eigene Produktanalysen, Benchmarks oder KI-Modelltrainings, wird er für diese Tätigkeit Verantwortlicher und braucht eine eigene Rechtsgrundlage. Eine Marketingagentur, die entscheidet, welche Zielgruppensegmente angesprochen werden, ist Verantwortlicher, auch wenn ihr Kunde die Kundenbeziehung hält. Werden Zwecke gemeinsam festgelegt, greift die gemeinsame Verantwortlichkeit nach Artikel 26 und eine Vereinbarung muss dokumentiert werden.

Die praktische Konsequenz: Ein Unternehmen kann für verschiedene Verarbeitungstätigkeiten mehrere Rollen gleichzeitig innehaben. Ausgereifte DSGVO-Programme pflegen deshalb eine Rollenzuordnung pro Datenfluss und nicht ein unternehmensweites Etikett.

Was sind die sieben Grundsätze der DSGVO-Compliance?

Artikel 5 enthält die sieben Grundsätze, die alles Weitere in der Verordnung bestimmen. Jedes Recht, jede Pflicht, jede DPIA und jedes Bussgeld lässt sich auf einen von ihnen zurückführen. Als Liste gelesen wirken sie abstrakt; als technische Anforderungen gelesen sind sie sehr konkret.

Die sieben Grundsätze im Einzelnen

1. Rechtmässigkeit, Fairness und Transparenz – Artikel 5 Absatz 1 Buchstabe a. Die Verarbeitung muss auf einer der sechs Rechtsgrundlagen des Artikels 6 beruhen, darf für die betroffene Person nicht unangemessen nachteilig, unerwartet oder irreführend sein und muss klar kommuniziert werden. Technisch bedeutet das: ein Feld im Verarbeitungsverzeichnis, ein Zweck-Tag an jedem Datenfluss und ein Datenschutzhinweis, den ein Nichtjurist versteht.

2. Zweckbindung – Artikel 5 Absatz 1 Buchstabe b. Für einen festgelegten, eindeutigen und legitimen Zweck erhobene Daten dürfen nicht für einen damit unvereinbaren Zweck weiterverarbeitet werden. Die Vereinbarkeit wird anhand der Verbindung zwischen den Zwecken, des Erhebungskontexts, der Art der Daten, der Folgen für die Betroffenen und des Bestehens von Schutzvorkehrungen beurteilt. Die Rechnungsadresse eines Kunden für Betrugsprüfung wiederzuverwenden ist in der Regel vereinbar; sie zum Training eines Allzweck-KI-Modells zu nutzen in der Regel nicht.

3. Datenminimierung – Artikel 5 Absatz 1 Buchstabe c. Erheben Sie nur, was angemessen, relevant und auf das notwendige Mass beschränkt ist. Dieser Grundsatz wird am häufigsten durch Analytics-Implementierungen, CRM-Lead-Formulare und Log-Pipelines verletzt, die mehr erfassen, als irgendwer rechtfertigen kann. Jedes zusätzliche Feld erhöht das Verletzungsrisiko, den Aufwand für Auskunftsersuchen und die Speicherkosten.

4. Richtigkeit – Artikel 5 Absatz 1 Buchstabe d. Personenbezogene Daten müssen richtig und, soweit erforderlich, auf dem neuesten Stand sein; unrichtige Daten sind unverzüglich zu löschen oder zu berichtigen. Praktisch bedeutet das Datenqualitätskontrollen, Dublettenmanagement und Berichtigungsworkflows, die bis in nachgelagerte Systeme einschliesslich Analytics und Backups durchgreifen.

5. Speicherbegrenzung – Artikel 5 Absatz 1 Buchstabe e. Daten dürfen nicht länger in identifizierbarer Form gespeichert werden als notwendig. Das Wort „notwendig” verlangt einen tatsächlichen Löschplan je Datenkategorie und Zweck sowie dessen automatisierte Durchsetzung. Löschpläne, die nur in einem Richtliniendokument, aber nicht im Code existieren, sind der häufigste Prüfungsbefund der gesamten Verordnung.

6. Integrität und Vertraulichkeit – Artikel 5 Absatz 1 Buchstabe f. Geeignete technische und organisatorische Sicherheitsmassnahmen, einschliesslich Schutz gegen unbefugte oder unrechtmässige Verarbeitung sowie gegen versehentlichen Verlust, Zerstörung oder Beschädigung. Artikel 32 konkretisiert: Pseudonymisierung und Verschlüsselung, dauerhafte Gewährleistung von Vertraulichkeit und Integrität, Belastbarkeit, Wiederherstellungsfähigkeit und regelmässige Tests.

7. Rechenschaftspflicht – Artikel 5 Absatz 2. Der Verantwortliche ist dafür verantwortlich, die Einhaltung der anderen sechs Grundsätze nachzuweisen. Die Rechenschaftspflicht ist der Metagrundsatz, der Absicht in Nachweis verwandelt – und der Grund, warum Verarbeitungsverzeichnisse, DPIAs, Schulungsnachweise und Designdokumentation existieren.

Wie verändert die Rechenschaftspflicht, was Sie bauen müssen?

Die Rechenschaftspflicht hat eine unbequeme Implikation, die IT-Verantwortliche früh verinnerlichen sollten: Die Abwesenheit von Nachweisen gilt als Nachweis der Abwesenheit. Eine Aufsichtsbehörde muss nicht beweisen, dass Sie unrechtmässig verarbeitet haben. Sie kann Sie auffordern, die Einhaltung nachzuweisen, und wenn Sie das nicht können, ist bereits der Rechenschaftsgrundsatz verletzt.

Das verschiebt mehrere technische Entscheidungen. Eine Consent-Management-Plattform, die den genauen Wortlaut, Zeitstempel, die Oberflächenversion und den Umfang jeder Einwilligung aufzeichnet, ist keine Bürokratie, sondern der Nachweis, der den Grundsatz der Rechtmässigkeit verteidigbar macht. Eine DPIA, die erwogene Risiken und verworfene Alternativen dokumentiert, ist kein Overhead, sondern das Artefakt, das Rechenschaft zeigt. Eine CI/CD-Pipeline, die datenschutzrelevante Tests ausführt und die Ergebnisse archiviert, ist eine Compliance-Kontrolle, nicht nur eine Qualitätskontrolle.

Rechenschaft verlangt zudem, dass Compliance überwacht und nicht angenommen wird. Artikel 32 Absatz 1 Buchstabe d fordert ausdrücklich einen Prozess zur regelmässigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der Sicherheitsmassnahmen. Hier wird Testdisziplin zu einer DSGVO-Anforderung statt zu einem Nice-to-have.

Die sieben Grundsätze und ihre konkreten Kontrollen

Was sind die Rechtsgrundlagen für die Verarbeitung personenbezogener Daten?

Die Verarbeitung personenbezogener Daten ist verboten, sofern keine Rechtsgrundlage greift. Artikel 6 nennt sechs. Die richtige Wahl ist entscheidend, weil die Grundlage bestimmt, was Sie tun dürfen, worüber Sie informieren müssen und ob Betroffene widersprechen oder widerrufen können.

Die sechs Rechtsgrundlagen nach Artikel 6

Einwilligung – Artikel 6 Absatz 1 Buchstabe a. Jede freiwillig gegebene, spezifische, informierte und unmissverständliche Willensbekundung der betroffenen Person. Die Einwilligung muss so einfach widerrufbar sein wie erteilbar, darf nicht an sachfremde Bedingungen gekoppelt werden und muss für ausdrückliche Einwilligung nach Artikel 9 Absatz 2 Buchstabe a einen höheren Standard erfüllen. Die Einwilligung ist die am häufigsten überdehnte und die fragilste Grundlage, weil sie jederzeit widerrufen werden kann und einen vollständigen Audit-Trail verlangt.

Vertrag – Artikel 6 Absatz 1 Buchstabe b. Verarbeitung, die zur Erfüllung eines Vertrags mit der betroffenen Person oder zur Durchführung vorvertraglicher Massnahmen auf deren Anfrage erforderlich ist. Das umfasst Auftragsabwicklung, Lieferung, Kontoverwaltung und Zahlungsverarbeitung – nicht aber Marketing, Analytics oder Produktverbesserung, die eigene Zwecke und eigene Grundlagen darstellen.

Rechtliche Verpflichtung – Artikel 6 Absatz 1 Buchstabe c. Verarbeitung, die zur Erfüllung einer rechtlichen Verpflichtung erforderlich ist, der der Verantwortliche unterliegt; die Verpflichtung muss sich aus Unionsrecht oder mitgliedstaatlichem Recht ergeben. Steuerunterlagen, Geldwäscheprüfungen, arbeitsrechtliche Pflichten und gesetzliche Berichtspflichten fallen hierunter. Die Verpflichtung muss konkret sein; der allgemeine Wunsch, Daten vorsorglich zu behalten, genügt nicht.

Lebenswichtige Interessen – Artikel 6 Absatz 1 Buchstabe d. Verarbeitung, die zum Schutz des Lebens einer Person erforderlich ist. Diese Grundlage ist eng und für Notfälle gedacht – medizinische Behandlung, Katastrophenhilfe, Schutz gefährdeter Personen – und kein Allzweck-Fallback für gesundheitsbezogene Daten.

Öffentliche Aufgabe – Artikel 6 Absatz 1 Buchstabe e. Verarbeitung, die für die Wahrnehmung einer Aufgabe im öffentlichen Interesse oder in Ausübung öffentlicher Gewalt erforderlich ist. Relevant für öffentliche Stellen und für Organisationen, die Aufgaben öffentlicher Natur wahrnehmen.

Berechtigte Interessen – Artikel 6 Absatz 1 Buchstabe f. Verarbeitung, die zur Wahrung berechtigter Interessen des Verantwortlichen oder eines Dritten erforderlich ist, sofern nicht die Interessen oder Grundrechte und Grundfreiheiten der betroffenen Person überwiegen. Dies ist die flexibelste und die disziplinbedürftigste Grundlage: Eine Interessenabwägung muss das Interesse, die Erforderlichkeit der Verarbeitung, die Abwägung gegen die Rechte der betroffenen Person und die angewandten Schutzvorkehrungen dokumentieren. Öffentlichen Stellen ist sie für ihre öffentlichen Aufgaben verwehrt.

Zwei Regeln bestimmen die Auswahl. Erstens: Sie müssen vor Beginn der Verarbeitung wählen, nicht nachträglich nach einer Beschwerde eine Grundlage konstruieren. Zweitens: Die Grundlage muss in Ihrem Datenschutzhinweis genannt werden, nach Artikel 13 Absatz 1 Buchstabe c und Artikel 14 Absatz 1 Buchstabe d, und Sie können die Grundlage nicht beliebig wechseln – ein Wechsel von berechtigtem Interesse zu Einwilligung mitten in der Verarbeitung ist in der Regel unzulässig, weil eine unter dem Druck „Einwilligung oder wir stellen den Dienst ein” erteilte Einwilligung nicht freiwillig ist.

Was ändert sich bei besonderen Kategorien personenbezogener Daten?

Artikel 9 Absatz 1 verbietet die Verarbeitung besonderer Kategorien – rassische oder ethnische Herkunft, politische Meinungen, religiöse oder weltanschauliche Überzeugungen, Gewerkschaftszugehörigkeit, genetische Daten, biometrische Daten zur eindeutigen Identifizierung, Gesundheitsdaten sowie Daten zum Sexualleben oder zur sexuellen Orientierung –, sofern keine der Voraussetzungen des Artikels 9 Absatz 2 vorliegt. Dazu gehören ausdrückliche Einwilligung, arbeits- und sozialrechtliche Pflichten, lebenswichtige Interessen bei fehlender Einwilligungsfähigkeit, Daten, die die betroffene Person offensichtlich öffentlich gemacht hat, Rechtsansprüche, erhebliches öffentliches Interesse, präventiv- und arbeitsmedizinische Zwecke, öffentliche Gesundheit sowie Archiv- und Forschungszwecke.

Die meisten Voraussetzungen des Artikels 9 Absatz 2 verlangen eine Grundlage im Unions- oder mitgliedstaatlichen Recht, weshalb die praktische Prüfung jurisdiktionsabhängig ist. Artikel 10 fügt eine weitere Ebene hinzu: Die Verarbeitung von Daten über Straftaten und Strafurteile erfordert eine Ermächtigung durch Unions- oder mitgliedstaatliches Recht oder die Kontrolle einer amtlichen Stelle.

Für IT-Teams sind die operativen Folgen unmittelbar. Besondere Kategorien verlangen stärkere Kontrollen – typischerweise Verschlüsselung mit separatem Schlüsselmanagement, strikt zweckgebundenen Zugriff, erweitertes Audit-Logging und häufig eine DPIA, weil die Risikoschwelle des Artikels 35 Absatz 3 Buchstabe b bei umfangreicher Verarbeitung solcher Daten erreicht ist. Biometrische Authentifizierung verdient besondere Vorsicht: Wird die biometrische Vorlage zur eindeutigen Identifizierung genutzt, handelt es sich um besondere Kategorien, selbst wenn die Vorlage eine mathematische Repräsentation und kein Bild ist.

Rechtsgrundlagen in der Praxis

Welche Rechte haben Betroffene und wie erfüllen Sie diese?

Betroffenenrechte sind der Punkt, an dem DSGVO-Compliance zu einer operativen Dienstleistung mit Fristen wird. Jedes Recht hat einen Auslöser, ein Antwortfenster und einen Nachweispfad – und jedes berührt mehrere Systeme.

Die acht Betroffenenrechte im Einzelnen

Recht auf Information – Artikel 13–14. Betroffene müssen zum Zeitpunkt der Erhebung bestimmte Informationen erhalten: Identität des Verantwortlichen, Zwecke, Rechtsgrundlage, Empfänger, Übermittlungen, Speicherdauer, Rechte und Beschwerderecht. Werden Daten nicht direkt bei der betroffenen Person erhoben, muss die Information innerhalb eines Monats (oder bei erster Kommunikation, je nachdem was früher eintritt) erfolgen.

Auskunftsrecht – Artikel 15. Betroffene können eine Bestätigung verlangen, ob ihre Daten verarbeitet werden, eine Kopie dieser Daten sowie Angaben zu Zwecken, Kategorien, Empfängern, Speicherdauer und zur Existenz automatisierter Entscheidungsfindung. Dies ist in der Praxis das Recht mit dem höchsten Volumen und dasjenige, das unzureichendes Datenmapping am häufigsten offenlegt, weil eine Antwort jedes System abdecken muss, das Daten der Person hält – einschliesslich Logs, Backups, Support-Tickets, Tabellenkalkulationen und Schatten-IT.

Recht auf Berichtigung – Artikel 16. Unrichtige Daten sind unverzüglich zu berichtigen, unvollständige zu vervollständigen. Die Berichtigung muss bis in nachgelagerte Systeme, abgeleitete Datensätze und Analytics durchgreifen.

Recht auf Löschung – Artikel 17. Auch als „Recht auf Vergessenwerden” bekannt. Es greift, wenn Daten nicht mehr erforderlich sind, die Einwilligung widerrufen wird, die betroffene Person widerspricht und keine überwiegenden berechtigten Gründe bestehen, die Verarbeitung unrechtmässig war oder eine rechtliche Pflicht die Löschung verlangt. Es ist nicht absolut: Es gilt nicht, soweit die Verarbeitung zur Erfüllung rechtlicher Pflichten, zur Geltendmachung von Rechtsansprüchen, für öffentliche Gesundheit oder für Archiv- und Forschungszwecke im öffentlichen Interesse erforderlich ist. Die Löschung muss auch Dritte erfassen, an die Daten offengelegt wurden.

Recht auf Einschränkung der Verarbeitung – Artikel 18. Die Verarbeitung kann pausiert werden, solange Richtigkeit oder Rechtmässigkeit bestritten wird. Technisch ist dies ein Status-Flag, das jede Verarbeitung unterdrücken muss, während der Datensatz erhalten bleibt.

Recht auf Datenübertragbarkeit – Artikel 20. Beruht die Verarbeitung auf Einwilligung oder Vertrag und erfolgt sie automatisiert, kann die betroffene Person ihre Daten in einem strukturierten, gängigen, maschinenlesbaren Format erhalten und – soweit technisch machbar – an einen anderen Verantwortlichen übermitteln lassen.

Widerspruchsrecht – Artikel 21. Betroffene können der Verarbeitung auf Grundlage berechtigter Interessen oder öffentlicher Aufgabe widersprechen; der Verantwortliche muss die Verarbeitung einstellen, sofern er nicht zwingende berechtigte Gründe nachweist. Bei Direktwerbung ist das Widerspruchsrecht absolut und bedingungslos: Die Verarbeitung muss mit Eingang des Widerspruchs enden.

Rechte bei automatisierter Entscheidungsfindung – Artikel 22. Betroffene haben das Recht, nicht einer ausschliesslich auf automatisierter Verarbeitung einschliesslich Profiling beruhenden Entscheidung unterworfen zu werden, die rechtliche Wirkung entfaltet oder sie erheblich beeinträchtigt – es sei denn, die Entscheidung ist für einen Vertrag erforderlich, gesetzlich zugelassen oder beruht auf ausdrücklicher Einwilligung. Wo solche Entscheidungen zulässig sind, müssen Schutzvorkehrungen menschliches Eingreifen, eine Erklärung der Logik und die Möglichkeit der Anfechtung umfassen. Dieser Artikel wird für Bonitätsbewertung, Bewerber-Screening, Versicherungstarifierung und KI-gestützte Betrugserkennung zunehmend relevant.

Wie setzen Sie ein Auskunftsersuchen operativ um?

Ein Auskunftsersuchen nach Artikel 15 muss innerhalb eines Monats nach Eingang beantwortet werden. Diese Frist kann bei komplexen oder zahlreichen Anträgen um zwei weitere Monate verlängert werden, wobei die Verlängerung innerhalb des ersten Monats mit Begründung mitgeteilt werden muss. Die Frist beginnt, wenn der Antrag bei irgendeinem Teil der Organisation eingeht – nicht, wenn er das Datenschutzteam erreicht.

Die Identitätsprüfung ist zulässig und erwartet. Ein Verantwortlicher darf Informationen anfordern, die zur Bestätigung der Identität erforderlich sind, aber nicht mehr als dafür nötig erheben. Ist der Antrag offensichtlich unbegründet oder exzessiv, kann ein angemessenes Entgelt verlangt oder der Antrag abgelehnt werden – die Beweislast dafür trägt jedoch der Verantwortliche.

Ein funktionierender Auskunftsprozess braucht sechs Komponenten:

1. Einen einzigen Eingangskanal, der im Datenschutzhinweis veröffentlicht und überwacht wird, mit Protokollierung jedes Antrags bei Eingang.
2. Einen dokumentierten Suchumfang, der jedes System, jede Datenbank, jeden Log-Speicher, jedes Backup, jedes Postfach und jeden Auftragsverarbeiter auflistet, der personenbezogene Daten dieser Person halten könnte.
3. Einen Abrufworkflow einschliesslich Unterstützung durch Auftragsverarbeiter, die nach Artikel 28 Absatz 3 Buchstabe e antworten müssen.
4. Einen Redaktionsschritt zum Entfernen von Daten Dritter und rechtlich geschütztem oder ausgenommenem Material, mit dokumentierter Ausnahmegrundlage.
5. Einen sicheren Übermittlungsweg – verschlüsselte Übertragung oder authentifiziertes Portal –, niemals ein unverschlüsselter E-Mail-Anhang.
6. Ein Abschlussprotokoll mit Datumsangaben, Entscheidungen, angewandten Ausnahmen und aufbewahrten Nachweisen für die Rechenschaftspflicht.

Organisationen, die Auskunftsersuchen gut bearbeiten, haben fast immer zuerst in Datenmapping investiert. Man kann nicht abrufen, was nie inventarisiert wurde, und die 30-Tage-Frist verzeiht keine Sucharbeit.

Betroffenenrechte im Überblick

Was sind die zentralen operativen Pflichten der DSGVO-Compliance?

Über Grundsätze und Rechte hinaus enthält die DSGVO benannte operative Pflichten. Jede hat einen Auslöser, ein erforderliches Ergebnis und einen natürlichen Verantwortlichen. Sie als Dokumentencheckliste zu behandeln ist der schnellste Weg zu einem Prüfungsbefund; sie als Kontrollen mit Verantwortlichen zu behandeln der schnellste Weg zu dauerhafter Compliance.

Verzeichnis von Verarbeitungstätigkeiten und Datenmapping – Artikel 30

Artikel 30 verlangt von Verantwortlichen und Auftragsverarbeitern ein Verzeichnis der Verarbeitungstätigkeiten. Für Verantwortliche muss das Verzeichnis Zwecke, Kategorien betroffener Personen und personenbezogener Daten, Empfänger, Drittlandübermittlungen und Garantien, Löschfristen und, soweit möglich, Sicherheitsmassnahmen enthalten. Organisationen mit weniger als 250 Beschäftigten profitieren von einer eingeschränkten Ausnahme, doch diese ist enger als sie scheint: Sie gilt nicht, wenn die Verarbeitung nicht nur gelegentlich erfolgt, wenn sie wahrscheinlich ein Risiko für Rechte und Freiheiten mit sich bringt oder wenn besondere Kategorien betroffen sind – Bedingungen, die auf die meisten kommerziellen Verarbeitungen zutreffen.

Das Verzeichnis ist nur so gut wie das Datenmapping dahinter. Eine brauchbare Landkarte entsteht aus systembasierter Erhebung, nicht aus Interviews. Sie sollte für jedes Feld personenbezogener Daten beantworten: welches System es hält, wer Eigentümer ist, welcher Zweck gilt, welche Rechtsgrundlage greift, wer Zugriff hat, wohin übermittelt wird, wie lange gespeichert und wie gelöscht wird. In den meisten Organisationen ist dies der grösste Arbeitsblock des gesamten Programms – und die Grundlage für alles andere.

Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen – Artikel 25

Artikel 25 verlangt, Datenschutz von Anfang an in die Verarbeitung einzubauen und standardmässig die datenschutzfreundlichsten Einstellungen anzuwenden, ohne dass die betroffene Person tätig werden muss. Die Voreinstellungsklausel überrascht Organisationen regelmässig: Eine Anwendung, die Profildaten öffentlich teilt, solange der Nutzer keine Einstellung findet, hat den Test nicht bestanden – unabhängig davon, wie gut die Einstellung dokumentiert ist.

Die Umsetzung von Artikel 25 bedeutet, dass Datenschutzanforderungen als testbare Kriterien in den Entwicklungslebenszyklus eintreten, nicht als rechtlicher Anhang. Typische Designmuster sind Datenminimierung auf Schemaebene, Pseudonymisierung als Standard für analytische Nutzung, zweckgebundene Zugriffstoken, automatisierte Durchsetzung von Löschfristen, Einwilligungsstatus als erstklassiges Attribut im Datenmodell und datenschutzfreundliche Standardeinstellungen in Benutzeroberflächen.

Datenschutz-Folgenabschätzung – Artikel 35

Eine DPIA ist erforderlich, wenn eine Verarbeitungsart voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat. Artikel 35 Absatz 3 nennt drei Fälle, die fast immer eine DPIA auslösen: systematische und umfassende Bewertung persönlicher Aspekte auf Basis automatisierter Verarbeitung einschliesslich Profiling, auf die Entscheidungen mit rechtlicher Wirkung oder ähnlich erheblicher Beeinträchtigung gestützt werden; umfangreiche Verarbeitung besonderer Kategorien oder von Daten über Straftaten; und systematische umfangreiche Überwachung öffentlich zugänglicher Bereiche.

Aufsichtsbehörden veröffentlichen Listen von Verarbeitungen, die eine DPIA erfordern, und die Kriterien des EDSA – Bewertung oder Scoring, automatisierte Entscheidungsfindung mit rechtlicher oder ähnlicher Wirkung, systematische Überwachung, sensible Daten, Verarbeitung in grossem Umfang, Zusammenführung oder Verknüpfung von Datensätzen, Daten über schutzbedürftige Personen, innovative Technologienutzung und Verarbeitung, die Betroffene an der Ausübung eines Rechts hindert – dienen der Bestimmung, ob die Schwelle überschritten ist. Zwei oder mehr Kriterien weisen in der Regel auf eine DPIA hin.

Eine belastbare DPIA ist eine strukturierte Risikobewertung, kein Formular. Sie sollte die Verarbeitung systematisch beschreiben, Notwendigkeit und Verhältnismässigkeit am Zweck messen, Risiken für Betroffene identifizieren, Abhilfemassnahmen definieren, die Stellungnahme des DSB – falls vorhanden – festhalten und die getroffene Entscheidung dokumentieren, einschliesslich der Entscheidung, mit Restrisiko fortzufahren, was zu dokumentieren ist und bei weiterhin hohem Restrisiko eine Konsultation der Aufsichtsbehörde nach Artikel 36 erfordert.

Brauchen Sie einen Datenschutzbeauftragten? – Artikel 37–39

Ein DSB ist nach Artikel 37 Absatz 1 in drei Fällen verpflichtend: wenn die Verarbeitung von einer öffentlichen Stelle oder Einrichtung durchgeführt wird, ausgenommen Gerichte in ihrer justiziellen Tätigkeit; wenn die Kerntätigkeiten des Verantwortlichen oder Auftragsverarbeiters in Verarbeitungen bestehen, die aufgrund ihrer Art, ihres Umfangs oder ihrer Zwecke eine regelmässige und systematische umfangreiche Überwachung betroffener Personen erfordern; und wenn die Kerntätigkeiten in der umfangreichen Verarbeitung besonderer Kategorien oder von Daten über Straftaten bestehen.

Der DSB muss angemessen eingebunden sein, der höchsten Managementebene berichten, keine Weisungen zur Aufgabenerfüllung erhalten, wegen der Wahrnehmung seiner Aufgaben nicht abberufen oder benachteiligt werden und über angemessene Ressourcen verfügen. Ein DSB kann extern auf Dienstleistungsbasis bestellt werden, was in mittelgrossen Organisationen üblich ist, die Unabhängigkeit ohne Vollzeitstelle brauchen. Die Aufgaben sind in Artikel 39 geregelt: Unterrichtung und Beratung, Überwachung der Einhaltung einschliesslich Schulungen und Audits, Beratung zu DPIAs, Zusammenarbeit mit der Aufsichtsbehörde und Funktion als Anlaufstelle. Ein DSB, der zugleich IT-Leiter, CISO oder Marketingleiter ist, schafft einen strukturellen Interessenkonflikt, den Aufsichtsbehörden wiederholt kritisiert haben.

Verträge mit Auftragsverarbeitern und Due Diligence – Artikel 28

Wird Verarbeitung im Auftrag eines Verantwortlichen durchgeführt, verlangt Artikel 28 einen schriftlichen Vertrag, der den Auftragsverarbeiter an bestimmte Bedingungen bindet: Verarbeitung nur auf dokumentierte Weisung, Vertraulichkeit, Sicherheitsmassnahmen nach Artikel 32, Genehmigung vor Einschaltung von Unterauftragsverarbeitern, Unterstützung bei Betroffenenrechten und DPIAs, Meldung von Verletzungen an den Verantwortlichen, Löschung oder Rückgabe der Daten am Ende der Beauftragung sowie Audit- und Prüfrechte. Der Vertrag muss zudem Gegenstand, Dauer, Art und Zweck der Verarbeitung, die Art der personenbezogenen Daten und die Kategorien betroffener Personen festlegen.

Verträge allein sind keine Due Diligence. Artikel 28 Absatz 1 verlangt, nur Auftragsverarbeiter einzusetzen, die hinreichende Garantien bieten, was eine Bewertung der Sicherheitslage vor dem Onboarding bedeutet – Zertifizierungen, Zusammenfassungen von Penetrationstests, Transparenz bei Unterauftragsverarbeitern, Verletzungshistorie, Optionen zur Datenresidenz und Zusagen zum Incident Response. Diese Bewertung muss regelmässig wiederholt werden, weil sich die Lage eines Auftragsverarbeiters ändert, wenn er wächst, übernommen wird oder neue KI-Funktionen einführt, die Kundendaten wiederverwenden.

Sicherheit der Verarbeitung und Meldung von Verletzungen – Artikel 32–34

Artikel 32 verlangt risikogerechte technische und organisatorische Massnahmen und nennt ausdrücklich Pseudonymisierung und Verschlüsselung, die Fähigkeit, dauerhaft Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit sicherzustellen, die Fähigkeit, Verfügbarkeit und Zugang nach einem Vorfall wiederherzustellen, sowie einen Prozess zur regelmässigen Überprüfung und Bewertung der Wirksamkeit der Massnahmen. Er erlaubt zudem, die Einhaltung eines genehmigten Zertifizierungsmechanismus als Element des Nachweises heranzuziehen.

Artikel 33 verlangt die Meldung einer Datenschutzverletzung an die zuständige Aufsichtsbehörde unverzüglich und, soweit möglich, spätestens 72 Stunden nach Bekanntwerden. Die Meldung muss die Art der Verletzung, Kategorien und ungefähre Zahl betroffener Personen und Datensätze, den DSB oder eine Kontaktstelle, wahrscheinliche Folgen sowie ergriffene oder vorgeschlagene Massnahmen beschreiben. Erfolgt die Meldung nicht innerhalb von 72 Stunden, sind die Gründe für die Verzögerung anzugeben. Ist die Verletzung voraussichtlich nicht mit einem Risiko für Rechte und Freiheiten verbunden, ist keine Meldung erforderlich – die Entscheidung muss aber intern dokumentiert werden, und Auftragsverarbeiter müssen Verantwortliche unverzüglich nach Artikel 33 Absatz 2 benachrichtigen.

Artikel 34 verlangt die Benachrichtigung der Betroffenen unverzüglich, wenn die Verletzung voraussichtlich ein hohes Risiko für ihre Rechte und Freiheiten zur Folge hat – es sei denn, die Daten wurden durch Verschlüsselung unverständlich gemacht, nachträgliche Massnahmen haben das hohe Risiko beseitigt oder die Benachrichtigung wäre mit unverhältnismässigem Aufwand verbunden. Im letzten Fall ist stattdessen eine öffentliche Bekanntmachung erforderlich.

Die 72-Stunden-Frist ist eine Fähigkeitsanforderung, keine Papieranforderung. Sie einzuhalten bedeutet, Erkennung, Triage-Kriterien, Schweregradklassifizierung, Eskalationswege, rechtliche Prüfung und Meldungsvorlagen im Voraus vorbereitet und geübt zu haben. Organisationen, die ihre Reaktion mit Tabletop-Übungen und simulierten Vorfällen testen, halten die Frist routinemässig ein. Organisationen, die eine Richtlinie schreiben und nie proben, nicht.

Internationale Datenübermittlungen nach Schrems II

Kapitel V beschränkt die Übermittlung personenbezogener Daten ausserhalb des EWR. Übermittlungen sind zulässig, wenn die Kommission einen Angemessenheitsbeschluss erlassen hat oder – ohne Angemessenheit – geeignete Garantien bestehen. Die wichtigsten Garantien sind Standardvertragsklauseln (SCC), verbindliche interne Datenschutzvorschriften, genehmigte Verhaltenskodizes und Zertifizierungsmechanismen. Die SCC von 2021 verlangen ein Transfer Impact Assessment, das Rechtslage und Praxis des Ziellandes analysiert und, wo nötig, ergänzende Massnahmen vorsieht.

Die Angemessenheitslandschaft ist komplexer geworden. Das EU-US Data Privacy Framework bietet einen Angemessenheitsweg für Organisationen, die sich zertifizieren lassen, während das frühere Privacy Shield 2020 vom Gerichtshof im Urteil Schrems II für ungültig erklärt wurde. Da Angemessenheitsbeschlüsse angefochten werden können, vermeiden ausgereifte Programme, einen einzelnen Übermittlungsmechanismus als dauerhaft gesichert zu behandeln. Praktische Schritte: ein Übermittlungsregister führen, Datenresidenz und Unterauftragsketten von Anbietern prüfen, Verschlüsselung und Schlüsselverwahrung anwenden, die Schlüssel im EWR halten, wo das Risiko es verlangt, und Transfer Impact Assessments je Ziel und Datenart dokumentieren.

Zentrale operative Pflichten im Überblick

Wie unterscheidet sich die DSGVO-Compliance von anderen Datenschutzgesetzen?

Multinationale Organisationen sehen sich selten nur einem Datenschutzregime gegenüber. Zu verstehen, wo die DSGVO im Verhältnis zu ihren Nachbarn steht, verhindert den häufigen Fehler, ein Kontrollset zu bauen und anzunehmen, es reise mit.

DSGVO vs. CCPA/CPRA

Der California Consumer Privacy Act in der durch den California Privacy Rights Act geänderten Fassung ist ein Verbraucherdatenschutzgesetz mit anderer Architektur. Er gilt für gewinnorientierte Unternehmen, die Umsatz- oder Datenmengenschwellen erreichen und mit Einwohnern Kaliforniens zu tun haben, und ist um Rechte an „personal information” und „sensitive personal information” aufgebaut. Er verlangt Information bei Erhebung, Rechte auf Wissen, Löschen, Berichtigen, Widerspruch gegen Verkauf oder Weitergabe und Einschränkung der Nutzung sensibler Daten und wird primär von der California Privacy Protection Agency und dem Attorney General mit zivilrechtlichen Bussgeldern durchgesetzt, nicht mit am globalen Umsatz bemessenen Verwaltungsbussgeldern.

Die praktisch relevanten Unterschiede für Entwicklungsteams sind das Opt-out-Modell (CCPA/CPRA erlaubt Verkauf und Weitergabe, solange der Verbraucher nicht widerspricht, während die DSGVO vor Beginn der Verarbeitung eine Rechtsgrundlage verlangt), das Fehlen eines allgemeinen Rechtsgrundlagenrahmens in Kalifornien, die engere Definition sensibler Daten und die unterschiedliche Behandlung von Beschäftigten- und B2B-Daten, die die DSGVO vollständig erfasst. Ein gut gebautes DSGVO-Programm erfüllt vieles von CCPA/CPRA, aber die Einwilligungsarchitektur ist tatsächlich anders und nicht einfach wiederverwendbar.

DSGVO vs. UK GDPR

Nach dem Austritt des Vereinigten Königreichs aus der EU hat das Land die DSGVO als UK GDPR in innerstaatliches Recht übernommen, ergänzt durch den Data Protection Act 2018. Die beiden Texte waren zum Zeitpunkt der Divergenz weitgehend identisch, weshalb ein einziges Compliance-Programm beide abdecken kann. Die Divergenz ist dennoch kumulativ: Das Vereinigte Königreich verfolgt eine eigene Reformagenda, einen eigenen internationalen Übermittlungsrahmen mit eigenen Angemessenheitsregelungen, eigene Ansätze zu bestimmten Einwilligungs- und Cookie-Fragen und eine eigene Aufsicht im Information Commissioner’s Office. Für Organisationen, die in beiden Märkten tätig sind, ist der praktische Ansatz ein gemeinsames Kernkontrollset mit einem dokumentierten Register jurisdiktionsspezifischer Abweichungen.

DSGVO vs. LGPD, PIPL und andere Regime

Brasiliens LGPD orientiert sich stark an der Struktur der DSGVO – Rechtsgrundlagen, Betroffenenrechte, eine nationale Behörde (ANPD) und Verwaltungssanktionen –, enthält aber eine eigene Rechtsgrundlage des Kreditschutzes und abweichende Regeln zum berechtigten Interesse. Chinas PIPL verbindet DSGVO-ähnliche Konzepte mit einer staatssicherheitsbezogenen Rahmung, verlangt in mehr Situationen separate Einwilligung, erlegt für bestimmte Übermittlungen Datenlokalisierung und Sicherheitsbewertungen auf und kennt keine unabhängige Aufsichtsbehörde im europäischen Sinne. Indiens DPDP Act wählt einen anderen Weg mit einem Consent-Manager-Modell und staatlich benannten „significant data fiduciaries”. Das revidierte schweizerische DSG ist der DSGVO nahe genug, um im selben Programm geführt zu werden, mit eigenen Nuancen bei Registrierung und Meldung.

Die strategische Schlussfolgerung für einen CTO lautet: Globale Datenschutzarchitektur sollte modular sein – ein gemeinsames Datenverzeichnis, eine gemeinsame Rechte-Engine und eine gemeinsame Sicherheitsbasis, mit jurisdiktionsspezifischen Entscheidungsschichten für Rechtsgrundlage, Einwilligung, Übermittlung und Löschung. Der Versuch einer einzigen globalen Richtlinie führt entweder zu teurer Übererfüllung oder zu teurer Untererfüllung.

Vergleich über Jurisdiktionen

Wie setzen Sie ein DSGVO-Compliance-Programm Schritt für Schritt um?

DSGVO-Programme scheitern aus vorhersehbaren Gründen: Sie beginnen mit dem Schreiben von Richtlinien statt mit Bestandsaufnahme, sie haben keine benannten Verantwortlichen, sie behandeln die Arbeit als einmaliges Projekt und sie erzeugen nie Nachweise. Ein phasiertes Programm, das die Bestandsaufnahme nach vorne zieht und mit Betriebsroutinen endet, vermeidet alle vier.

Phase 1 – Erfassen und bewerten (Tage 0–90)

Die erste Phase beantwortet drei Fragen: welche personenbezogenen Daten existieren, wohin sie fliessen und welche Risiken am höchsten sind. Ohne diese Antworten lässt sich nichts anderes verlässlich sequenzieren.

• Anwendungsbereich bestimmen. Klären Sie, ob Artikel 3 Absatz 1, Artikel 3 Absatz 2 oder beide greifen, und identifizieren Sie die federführende Aufsichtsbehörde bei grenzüberschreitender Verarbeitung.
• Rollen zuordnen. Bestimmen Sie Status als Verantwortlicher, gemeinsam Verantwortlicher und Auftragsverarbeiter je Datenfluss – nicht je Rechtsträger.
• Datenerhebung und Inventar. Kombinieren Sie automatisierte Discovery-Tools mit strukturierten Interviews der Systemeigentümer. Erfassen Sie Produktivsysteme, Data Warehouses, Logs, Backups, SaaS-Anwendungen, Tabellenkalkulationen, Support-Tools und Schatten-IT. Erfassen Sie Datenkategorie, Zweck, Rechtsgrundlage, Löschfrist, Empfänger und Übermittlungen.
• Gap-Analyse. Vergleichen Sie den Ist-Zustand mit den sieben Grundsätzen und den zentralen Pflichten und bewerten Sie jede Lücke nach Wahrscheinlichkeit und Auswirkung auf Betroffene.
• Inventar hoher Risiken. Identifizieren Sie Verarbeitungen, die voraussichtlich eine DPIA erfordern, und solche, die eine vorherige Konsultation verlangen.
• Governance aufsetzen. Benennen Sie einen Executive Sponsor, eine Programmleitung, Systemeigentümer und eine DSB-Entscheidung mit dokumentierter Begründung.

Phase 2 – Beheben und dokumentieren (Tage 90–180)

Die zweite Phase verwandelt Befunde in Kontrollen und erzeugt die Rechenschaftsnachweise, deren Fehlen Phase 1 aufgedeckt hat.

• Verzeichnis nach Artikel 30 vervollständigen und unter Change Control stellen, damit neue Verarbeitungen vor dem Go-live eingetragen werden.
• Risikoreiche Lücken zuerst schliessen. Priorisieren Sie besondere Kategorien, umfangreiche Überwachung, grenzüberschreitende Übermittlungen und jede Verarbeitung mit offener DPIA.
• Löschfristen durchsetzen. Überführen Sie den Löschplan in automatisierte Lösch-, Archivierungs- und Backup-Ablaufjobs und verifizieren Sie deren Funktion.
• Rechteprozess neu aufbauen. Veröffentlichen Sie einen Eingangskanal, definieren Sie den Suchumfang je System, bauen Sie Abrufworkflows und beginnen Sie, Anträge und Abschlusszeiten zu protokollieren.
• Verträge korrigieren. Bringen Sie Auftragsverarbeitungsverträge auf den Stand von Artikel 28, identifizieren Sie Unterauftragsverarbeiter und schliessen Sie Lücken bei Übermittlungsgarantien.
• Sicherheit härten. Setzen Sie die in der Gap-Analyse identifizierten Massnahmen nach Artikel 32 um, einschliesslich Verschlüsselung, Zugriffskontrolle, Logging, Monitoring und Schwachstellenmanagement.
• Melde-Runbook erstellen. Definieren Sie Erkennung, Triage, Schweregradklassifizierung, Eskalation, rechtliche Prüfung, Meldungsvorlagen und einen Übungsplan.
• Schulen. Rollenbasierte Schulungen für Engineering, Marketing, HR, Vertrieb und Support mit aufbewahrten Abschlussnachweisen.

Phase 3 – Betreiben und nachweisen (Tage 180–365, danach Regelbetrieb)

Die letzte Phase macht aus Compliance Routine. Sie entscheidet, ob das Programm den ersten Führungswechsel oder den ersten grossen Produktlaunch übersteht.

• Datenschutz in der Lieferung verankern. Datenschutzanforderungen in die Definition of Done aufnehmen und DPIA-Screening in Intake- und Change-Advisory-Prozesse integrieren.
• Monitoring-Zyklus fahren. Monatliche Kennzahlen zu Auskunftsvolumen und Abschlusszeiten, Verletzungsereignissen, Einwilligungsraten, Erfolg von Löschjobs, Schulungsabschlüssen und Anbieterprüfungen.
• Testen. Jährliche Penetrationstests, periodische Restore-Tests und mindestens jährliche Tabletop-Übungen zur Verletzungsreaktion mit dokumentierten Erkenntnissen.
• Auditieren. Interne Revision oder externe Bewertung gegen die sieben Grundsätze und die zentralen Pflichten, mit Nachverfolgung der Befunde bis zum Abschluss.
• Anbieter überprüfen. Neubewertung der Sicherheitslage von Auftragsverarbeitern, der Unterauftragsketten und Übermittlungsarrangements in definierten Zyklen und immer, wenn ein Anbieter sein Leistungsbild wesentlich ändert.
• Nach oben berichten. Ein kurzer Bericht an die Geschäftsleitung zu Compliance-Stand, Restrisiken und erforderlichen Entscheidungen.

Wenn Ihr Unternehmen dieses Programm parallel zur Produktlieferung betreiben muss – und das müssen die meisten –, arbeitet das Consulting-Team von Greyson mit der IT-Leitung daran, Bestandsaufnahme, Behebung und Betriebsroutinen zu sequenzieren, ohne die Roadmap zu blockieren.

Zwölf-Monats-Fahrplan für DSGVO-Compliance

Wie verändert DSGVO-Compliance Softwareentwicklung und Testing?

Dies ist der Bereich, in dem DSGVO-Compliance am häufigsten als Rechtsfrage missverstanden und am häufigsten als Engineering-Aufgabe nicht erfüllt wird. Die Pflichten aus Artikel 25 und 32 sind Design- und Testpflichten. Sie lassen sich nicht durch ein nach dem Release geschriebenes Richtliniendokument erfüllen.

Datenschutz durch Technikgestaltung über den Softwareentwicklungslebenszyklus

Datenschutz durch Technikgestaltung funktioniert nur, wenn Datenschutzanforderungen sich wie jede andere nichtfunktionale Anforderung verhalten: früh erfasst, testbar gemacht, bis zur Erfüllung verfolgt und vor dem Release verifiziert.

Anforderungsphase. Jedes Feature, das personenbezogene Daten berührt, sollte Zweck, Rechtsgrundlage, Datenkategorien, Löschfrist, Empfänger und anwendbare Betroffenenrechte deklarieren. Eine Screening-Frage im Intake – verarbeitet dieses Vorhaben personenbezogene Daten, und erfüllt es ein DPIA-Kriterium? – erfasst die Fälle, die vor der Architekturfestlegung bewertet werden müssen.

Designphase. Datenminimierung wird auf Schema- und API-Ebene angewendet, nicht nur im Formular. Pseudonymisierung, zweckgebundener Zugriff, Verschlüsselung und Schlüsselmanagement werden eingeplant. Standardeinstellungen sind datenschutzfreundlich und erfüllen die Voreinstellungsklausel des Artikels 25.

Build-Phase. Einwilligungsstatus, Zweck-Tags und Löschmetadaten werden als erstklassige Datenattribute modelliert statt nachträglich angeflanscht. Logging wird standardmässig so konfiguriert, dass personenbezogene Daten ausgeschlossen oder redigiert werden, denn Log-Speicher gehören zu den am häufigsten übersehenen Datensammlungen personenbezogener Daten.

Testphase. Datenschutzanforderungen werden wie funktionale Anforderungen getestet: dass Löschen tatsächlich über alle Speicher einschliesslich abgeleiteter Datensätze und Suchindizes löscht, dass Löschjobs auslösen, dass ein Widerruf der Einwilligung die Verarbeitung downstream unterbindet, dass Zugriffskontrollen nach Zweck einschränken, dass ein Export einen vollständigen und maschinenlesbaren Datensatz erzeugt und dass automatisierte Entscheidungen eine Erklärung liefern und an menschliche Prüfung weiterleiten.

Release-Phase. Datenschutzprüfungen werden Teil der Definition of Done. Ein Release, das die Verarbeitung personenbezogener Daten ändert, ohne den Registereintrag zu aktualisieren oder das DPIA-Screening abzuschliessen, sollte das Gate nicht passieren.

Betriebsphase. Durchsetzung von Löschfristen, Zugriffsprüfungen, Monitoring und periodische Neubewertung von DPIAs, wenn sich die Verarbeitung weiterentwickelt. Artikel 32 Absatz 1 Buchstabe d verlangt ausdrücklich die regelmässige Prüfung der Wirksamkeit von Sicherheitsmassnahmen, was kontinuierliches Testen zu einer rechtlichen Erwartung macht – nicht zu einer Engineering-Präferenz.

Testdatenmanagement – Pseudonymisierung versus Anonymisierung

Testing ist der Bereich, in dem DSGVO-Compliance und Engineering-Praxis am sichtbarsten kollidieren. Entwicklungs- und Testumgebungen brauchen realistische Daten, um realistische Defekte zu finden, aber personenbezogene Produktivdaten dürfen nicht in Umgebungen mit schwächeren Kontrollen kopiert werden. Die DSGVO bietet zwei Wege, und sie sind nicht austauschbar.

Anonymisierung entfernt die Identifizierbarkeit so weit, dass die Daten vollständig aus dem Anwendungsbereich der DSGVO fallen. Dafür müssen die Daten Singling-out (Isolierung einer Person), Verkettbarkeit (Verbindung von Datensätzen über dieselbe Person) und Inferenz (Ableitung von Merkmalen aus anderen Daten) widerstehen, wobei alle wahrscheinlich eingesetzten Mittel zu berücksichtigen sind. Echte Anonymisierung ist schwierig und bei vielen Unternehmensdatensätzen – besonders solchen mit reichhaltigen Quasi-Identifikatoren wie Postleitzahl, Geburtsdatum und Transaktionsmustern – nicht erreichbar, ohne den analytischen Nutzen zu zerstören.

Pseudonymisierung ersetzt direkte Identifikatoren durch künstliche, während eine Re-Identifizierung über separat gehaltenes Schlüsselmaterial möglich bleibt. Pseudonymisierte Daten bleiben personenbezogene Daten und im Anwendungsbereich, aber Artikel 32 erkennt Pseudonymisierung ausdrücklich als Sicherheitsmassnahme an und Artikel 25 als Designtechnik. Für die meisten Testumgebungen ist Pseudonymisierung mit strikter Schlüsseltrennung die praktikable und verteidigbare Wahl: Sie erhält referenzielle Integrität und Datenrealismus, entfernt direkte Identifizierbarkeit und erfüllt eine technische Massnahme nach Artikel 32.

Unabhängig vom Weg sind mehrere Kontrollen nicht verhandelbar. Testumgebungen dürfen nicht mit Produktivzugangsdaten erreichbar sein. Daten müssen am Punkt der Extraktion maskiert werden, nicht in der Zielumgebung. Referenzielle Integrität muss erhalten bleiben, damit Tests aussagekräftig sind – derselbe synthetische Identifikator muss über verbundene Tabellen konsistent abbilden. Freitextfelder, Anhänge, Notizen und Dokumentmetadaten müssen abgedeckt sein, denn dort überleben personenbezogene Daten die Maskierung am häufigsten. Und der Maskierungsprozess selbst muss getestet werden: die Stichprobenprüfung maskierter Datensätze auf Restidentifikatoren ist eine legitime und erwartete Kontrolle.

Cloud, Anbieter und Assurance bei Auftragsverarbeitern

Der Wechsel in die Cloud überträgt keine Verantwortung. Nach Artikel 28 bleibt der Verantwortliche dafür zuständig, einen Auftragsverarbeiter mit hinreichenden Garantien zu wählen und sicherzustellen, dass der Vertrag die erforderlichen Bedingungen abdeckt. Speziell für Cloud verdienen vier Bereiche Aufmerksamkeit.

Datenresidenz und Übermittlungsketten. Ein Cloud-Dienst kann Daten über Regionen replizieren und Unterauftragsverarbeiter in mehreren Jurisdiktionen einsetzen. Das Übermittlungsmapping muss dem tatsächlichen Datenpfad folgen, einschliesslich Support-Zugriffen aus Drittländern, die selbst eine Übermittlung darstellen.

Transparenz bei Unterauftragsverarbeitern. Artikel 28 Absatz 2 verlangt eine Genehmigung für Unterauftragsverarbeiter. In der Praxis bedeutet das, veröffentlichte Listen zu überwachen, einen Mechanismus zum Widerspruch gegen Änderungen zu haben und einen dokumentierten Prozess für den Fall, dass Sie tatsächlich widersprechen.

Löschung und Exit. Artikel 28 Absatz 3 Buchstabe g verlangt Löschung oder Rückgabe der Daten am Ende der Beauftragung. Prüfen Sie in Multi-Tenant- und backup-lastigen Architekturen, was „Löschung” konkret bedeutet, welche Fristen gelten und ob Restkopien in Backups oder Analytics-Speichern verbleiben.

Feature-Creep und Sekundärnutzung. Viele Cloud-Plattformen bieten heute KI-gestützte Funktionen, die Kundendaten verarbeiten können. Jede solche Funktion muss bewertet werden: Werden Daten für Modelltraining wiederverwendet, und wenn ja, auf welcher Rechtsgrundlage und mit welchem vertraglichen Schutz?

Datenschutzkontrollen im Entwicklungslebenszyklus

Was sind die häufigsten DSGVO-Fehlannahmen?

Die meisten ins Stocken geratenen Programme werden nicht durch Komplexität blockiert. Sie werden durch eine kleine Gruppe hartnäckiger Überzeugungen blockiert, die Teams dazu bringen, Aufwand an der falschen Stelle zu investieren.

Neun Mythen, die Compliance-Programme ausbremsen

„Wir sind nicht in der EU, also gilt die DSGVO für uns nicht.” Artikel 3 Absatz 2 wendet die Verordnung auf Organisationen an, die Personen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten beobachten – ohne Erfordernis einer Niederlassung.

„Unsere Daten sind anonymisiert, also fallen sie nicht darunter.” Nur irreversibel anonymisierte Daten sind aus dem Anwendungsbereich heraus. Pseudonymisierte Daten und Daten, die durch Kombination mit anderen Datensätzen re-identifizierbar sind, bleiben personenbezogen.

„Einwilligung ist die einzige Rechtsgrundlage, die wir brauchen.” Es gibt fünf weitere Grundlagen. Einwilligung dort zu nutzen, wo Vertrag oder rechtliche Verpflichtung greift, schafft vermeidbares Risiko, weil Einwilligung jederzeit widerrufbar ist.

„Wir haben den Datensatz gelöscht, also sind wir compliant.” Löschung muss Backups, abgeleitete Datensätze, Analytics-Speicher, Suchindizes, Caches und Auftragsverarbeiter erreichen. Löschung, die an der Primärdatenbank endet, ist unvollständig.

„Die DPIA ist eine Formalität für die Rechtsabteilung.” Eine DPIA ist eine Risikobewertung, die Designentscheidungen informiert, vor Beginn der Verarbeitung erstellt werden muss, die Stellungnahme des DSB festhält und Restrisiken auf der richtigen Ebene akzeptiert.

„Unser Cloud-Anbieter übernimmt die DSGVO für uns.” Auftragsverarbeiter liefern Garantien und vertragliche Zusagen; die Rechenschaftspflicht nach Artikel 5 Absatz 2 und Artikel 24 bleibt beim Verantwortlichen, einschliesslich für Übermittlungen und Unterauftragsverarbeiter.

„Wir haben eine Datenschutzerklärung auf der Website, also sind wir abgedeckt.” Ein Datenschutzhinweis erfüllt eine Transparenzpflicht. Für Durchsetzung von Löschfristen, Erfüllung von Rechten, Sicherheitstests oder Meldungsbereitschaft leistet er nichts.

„Compliance ist ein einmaliges Projekt.” Jedes neue System, jeder Anbieter, jede Integration, jeder Marketingkanal und jedes KI-Feature verändert die Verarbeitungslandschaft. Compliance ohne Change-Control-Intake verfällt innerhalb eines Quartals.

„DSGVO und AI Act sind getrennte Probleme.” KI-Systeme, die personenbezogene Daten verarbeiten, müssen beide erfüllen. Datenminimierung, Zweckbindung und Rechtsgrundlagenprüfung gelten für Trainingsdaten, und Artikel 22 beschränkt automatisierte Entscheidungen mit erheblicher Wirkung auf Personen.

Mythos versus Realität

Was kostet die Nichteinhaltung?

Bussgelder dominieren die Diskussion, sind aber selten die grössten Kosten. Sowohl die gesetzliche Struktur als auch die operativen Folgen zu verstehen hilft, eine Wirtschaftlichkeitsrechnung zu bauen, die die Budgetprüfung übersteht.

Die zweistufige Bussgeldstruktur nach Artikel 83

Artikel 83 sieht zwei Stufen von Verwaltungsbussgeldern vor. Die niedrigere Stufe erfasst Pflichten einschliesslich der allgemeinen Grundsätze, der Pflichten von Verantwortlichen und Auftragsverarbeitern, der Zertifizierungsstellen und der Pflichten von Überwachungsstellen. Sie erlaubt Bussgelder bis zu 10 Millionen Euro oder 2 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem welcher Betrag höher ist.

Die höhere Stufe erfasst Verstösse gegen die Grundsätze, Betroffenenrechte, internationale Übermittlungsregeln und die Nichtbefolgung einer Anordnung einer Aufsichtsbehörde. Sie erlaubt Bussgelder bis zu 20 Millionen Euro oder 4 % des gesamten weltweiten Jahresumsatzes, je nachdem welcher Betrag höher ist.

Der tatsächliche Betrag hängt von mehreren Faktoren ab: Art, Schwere und Dauer des Verstosses, Fahrlässigkeit oder Absicht, Abhilfemassnahmen, Grad der Verantwortung, frühere Verstösse, Zusammenarbeit mit der Behörde und Kategorien der betroffenen Daten. Bussgelder müssen in jedem Fall wirksam, verhältnismässig und abschreckend sein. Aufsichtsbehörden können zudem korrigierende Massnahmen verhängen – Verwarnungen, Rügen, Anordnungen, vorübergehende oder endgültige Verarbeitungsverbote und die Aussetzung von Datenflüssen –, die kommerziell schädlicher sein können als ein Bussgeld.

Was die Durchsetzungsdaten tatsächlich zeigen

Aggregierte Durchsetzungsdaten zeigen, wie aktiv das Regime angewendet wird. Über alle erfassten Durchsetzungsfälle in EU und EWR hinweg geht die Gesamtzahl der Fälle in die Tausende und die kumulierten Bussgelder übersteigen 7,5 Milliarden Euro, mit dem höchsten Einzelbussgeld von 1,2 Milliarden Euro, verhängt in Irland. Spanien liegt bei der Fallzahl konstant unter den aktivsten Behörden, was den hohen Anteil kleinerer Fälle mit Verbraucherbeschwerden und Cookie-Einwilligungen widerspiegelt.

Die Verteilung ist wichtiger als die Schlagzeile. Eine kleine Zahl sehr grosser Bussgelder dominiert den Gesamtwert, während die Mehrheit der Fälle mittlere und kleinere Organisationen mit deutlich kleineren Beträgen betrifft. Dieses Muster hat eine klare strategische Implikation: Das Risiko einer Untersuchung konzentriert sich nicht auf multinationale Konzerne. Es folgt der Sichtbarkeit – Verbraucherbeschwerden, schlecht bearbeitete Betroffenenanfragen, Verletzungsmeldungen und Beschwerden von Wettbewerbern oder Beschäftigten. Organisationen, die auf ein einzelnes Auskunftsersuchen oder eine Verletzungsmeldung schlecht reagieren, landen weit wahrscheinlicher in einer Durchsetzungsakte als solche mit einem reibungslosen, dokumentierten Prozess.

Zwei Durchsetzungsmuster sind für die IT-Leitung besonders relevant. Erstens bleiben Cookie-Einwilligung und Tracking europaweit eine anhaltende Bussgeldquelle, was den Marketing-Technologie-Stack mitten in den Anwendungsbereich rückt. Zweitens sind Fälle unzureichender technischer und organisatorischer Massnahmen nach Artikel 32 häufig und entstehen oft aus Fehlern, die Engineering-Teams als grundlegend betrachten würden: ungepatchte Systeme, übermässige Zugriffsrechte, unverschlüsselte Backups, exponierte Datenbanken und Zugangsdaten im Code.

Die Kosten, die nie im Bussgeld auftauchen

Für die meisten Organisationen ist das Bussgeld die kleinere Zahl. Die wesentlichen Kosten sind operativ:

• Behebungskosten. Notfall-Sicherheitsarbeit, forensische Untersuchung, Systemneubau und externe Berater, typischerweise unter Zeitdruck und zu Premiumsätzen.
• Betriebsunterbrechung. Ausgesetzte Verarbeitung, eingefrorene Datenflüsse, deaktivierte Marketingfähigkeit und blockierte Produktlaunches.
• Kunden- und Vertragsverlust. Ausschluss in Beschaffungsprozessen, Kündigungsrechte, gescheiterte Due Diligence und verzögerte Enterprise-Deals.
• Rechtliches Risiko. Schadenersatzansprüche nach Artikel 82 für materielle und immaterielle Schäden, einschliesslich Sammelklagen.
• Aufmerksamkeit des Managements. Zeit von Geschäftsleitung und Vorstand, gebunden durch Untersuchung, Behördenkorrespondenz und Behebungs-Governance.
• Anhaltender Reputationsschaden. Durchsetzungsentscheidungen sind öffentlich und dauerhaft und tauchen in jeder späteren Beschaffungsprüfung auf.

Verwaltungsbussgelder im Überblick

Wie sieht die Zukunft der DSGVO-Compliance aus?

Die DSGVO ist lange genug in Kraft, damit sich die Durchsetzungspraxis gefestigt hat – und damit sich die technologische Landschaft erheblich verändert hat. Drei Entwicklungen werden die nächste Phase prägen.

Konvergenz mit dem EU AI Act

Der EU AI Act führt ein risikobasiertes Regime für KI-Systeme ein, mit Pflichten, die sich für Systeme, die personenbezogene Daten verarbeiten, stark mit der DSGVO überschneiden. Anbieter und Betreiber von Hochrisiko-Systemen müssen Daten-Governance einschliesslich Trainingsdatenqualität und Bias-Monitoring adressieren, technische Dokumentation und Protokollierung führen, menschliche Aufsicht sicherstellen und Transparenz gegenüber betroffenen Personen bieten. Viele dieser Pflichten verstärken DSGVO-Anforderungen, sind aber nicht identisch und betreffen Organisationen in unterschiedlichen Rollen.

Für IT-Verantwortliche folgt daraus, dass KI-Governance und Datenschutz-Governance zusammenlaufen sollten statt parallel zu laufen. Ein einziger Intake-Prozess sollte KI-Initiativen sowohl durch ein DPIA-Screening als auch durch eine AI-Act-Klassifizierung leiten. Ein einziges Datenverzeichnis sollte Herkunft, Rechtsgrundlage und Löschung von Trainingsdaten erfassen. Ein einziges Set an Modelldokumentation sollte beiden Regimen dienen. Organisationen, die das getrennt aufbauen, duplizieren Aufwand und erzeugen Inkonsistenzen, die Aufsichtsbehörden bemerken werden.

Cookie-Einwilligung, ePrivacy und Einwilligungsmüdigkeit

Einwilligungsoberflächen bleiben der sichtbarste Teil der DSGVO-Compliance und einer der meistprozessierten. Aufsichtsbehörden in ganz Europa prüfen weiterhin Consent-Banner, Ablehnungssymmetrie, Dark Patterns, vorausgewählte Kästchen und das Zusammenspiel von Einwilligung mit den Regeln der ePrivacy-Richtlinie zur Speicherung von Informationen auf Endeinrichtungen. Die Richtung geht zu strengerer Durchsetzung von „so einfach ablehnbar wie zustimmbar” und klareren Abgrenzungen zwischen notwendigen und nicht notwendigen Technologien.

Gleichzeitig sind Nutzer zunehmend ablehnend gegenüber Einwilligungsanfragen, was den Druck erzeugt, wo angemessen auf alternative Rechtsgrundlagen zu setzen und Tracking auf das wirklich Notwendige zu reduzieren. Serverseitige und datenschutzfreundliche Messansätze werden gerade deshalb Mainstream, weil sie sowohl rechtliche Exposition als auch Einwilligungsreibung reduzieren. Hier dient Datenminimierung gleichzeitig rechtlicher Compliance und kommerziellen Ergebnissen.

Unsicherheit im Übermittlungsregime und der Weg nach vorn

Internationale Übermittlungen bleiben der volatilste Bereich des Regimes. Angemessenheitsbeschlüsse können angefochten werden, und die Geschichte von Safe Harbour und Privacy Shield zeigt, dass ein heute geltender Mechanismus morgen ungültig sein kann. Das EU-US Data Privacy Framework bietet einen Weg für zertifizierte Organisationen, wurde aber bereits gerichtlich angefochten, und seine langfristige Stabilität ist nicht garantiert.

Ausgereifte Organisationen reagieren mit reduzierter Abhängigkeit von einem einzelnen Übermittlungsmechanismus: Sie minimieren das Volumen personenbezogener Daten, das Grenzen überschreitet, halten Verschlüsselungsschlüssel unter EU-Verwahrung, wo das Risiko es verlangt, strukturieren die Verarbeitung so, dass sensible Vorgänge im EWR bleiben, und pflegen Transfer Impact Assessments, die bei Wegfall eines Mechanismus schnell aktualisiert werden können. Am stärksten exponiert sind Organisationen, deren Architektur davon ausgeht, dass ein rechtlicher Mechanismus dauerhaft gültig bleibt.

Häufig gestellte Fragen zur DSGVO-Compliance

Was ist DSGVO-Compliance einfach erklärt?

DSGVO-Compliance bedeutet, die Anforderungen der Verordnung (EU) 2016/679 zu erfüllen, wann immer Sie personenbezogene Daten von Personen in der EU verarbeiten. In der Praxis heisst das: eine Rechtsgrundlage für jede Verarbeitungstätigkeit, klare Information der Betroffenen, Erfüllung ihrer Rechte innerhalb der Fristen, angemessene Absicherung der Daten, Meldung bestimmter Verletzungen innerhalb von 72 Stunden und die Fähigkeit, all dies einer Aufsichtsbehörde nachzuweisen.

Gilt die DSGVO auch für Unternehmen ausserhalb der EU?

Ja. Nach Artikel 3 Absatz 2 gilt die DSGVO für Organisationen ohne Niederlassung in der EU, die Personen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten beobachten, einschliesslich Website-Analytics oder gezielter Werbung. Eine lediglich erreichbare Website genügt nicht – es muss ein Hinweis auf die Absicht bestehen, den EU-Markt zu adressieren, etwa EU-sprachige Versionen, Euro-Preise oder EU-Lieferoptionen. Artikel 27 verlangt in der Regel die Benennung eines Vertreters in der Union.

Was sind die sieben Grundsätze der DSGVO-Compliance?

Artikel 5 nennt sieben Grundsätze: Rechtmässigkeit, Fairness und Transparenz; Zweckbindung; Datenminimierung; Richtigkeit; Speicherbegrenzung; Integrität und Vertraulichkeit; und Rechenschaftspflicht. Die Rechenschaftspflicht ist der Metagrundsatz – der Verantwortliche muss die Einhaltung der anderen sechs nachweisen können, weshalb Dokumentation, Verzeichnisse und Testnachweise in jedem glaubwürdigen Programm zentral sind.

Was ist der Unterschied zwischen Verantwortlichem und Auftragsverarbeiter?

Ein Verantwortlicher entscheidet über Zwecke und Mittel der Verarbeitung; ein Auftragsverarbeiter verarbeitet personenbezogene Daten im Auftrag des Verantwortlichen nach dokumentierter Weisung. Die Abgrenzung ist faktisch und nicht vertraglich, und dieselbe Organisation kann für verschiedene Tätigkeiten beide Rollen innehaben. Ein Auftragsverarbeiter, der Kundendaten für eigene Zwecke nutzt, etwa zum Training eigener KI-Modelle, wird für diese Tätigkeit Verantwortlicher und braucht eine eigene Rechtsgrundlage.

Wann ist ein Datenschutzbeauftragter erforderlich?

Artikel 37 Absatz 1 macht einen DSB in drei Situationen verpflichtend: wenn die Verarbeitung von einer öffentlichen Stelle oder Einrichtung durchgeführt wird (ausser Gerichten in justizieller Tätigkeit); wenn die Kerntätigkeiten eine regelmässige und systematische umfangreiche Überwachung betroffener Personen umfassen; und wenn die Kerntätigkeiten die umfangreiche Verarbeitung besonderer Kategorien oder von Daten über Straftaten umfassen. Der DSB muss unabhängig sein, der höchsten Managementebene berichten, angemessene Ressourcen erhalten und vor Abberufung oder Benachteiligung wegen seiner Aufgabenerfüllung geschützt sein.

Wann ist eine Datenschutz-Folgenabschätzung verpflichtend?

Eine DPIA ist erforderlich bei Verarbeitungen, die voraussichtlich ein hohes Risiko für die Rechte und Freiheiten von Personen zur Folge haben. Artikel 35 Absatz 3 nennt drei Fälle: systematische und umfassende automatisierte Bewertung einschliesslich Profiling, auf die Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung gestützt werden; umfangreiche Verarbeitung besonderer Kategorien oder von Daten über Straftaten; und systematische umfangreiche Überwachung öffentlich zugänglicher Bereiche. Nach den EDSA-Kriterien weisen zwei oder mehr Risikoindikatoren in der Regel auf eine erforderliche DPIA hin.

Wie lange haben Sie Zeit, eine Datenschutzverletzung zu melden?

Sie müssen die zuständige Aufsichtsbehörde unverzüglich und, soweit möglich, innerhalb von 72 Stunden nach Bekanntwerden einer Datenschutzverletzung benachrichtigen, gemäss Artikel 33. Bei späterer Meldung ist die Verzögerung zu begründen. Ist die Verletzung voraussichtlich mit einem hohen Risiko für die Rechte und Freiheiten der Betroffenen verbunden, verlangt Artikel 34 zusätzlich die unverzügliche Benachrichtigung dieser Personen. Auftragsverarbeiter müssen Verantwortliche unverzüglich benachrichtigen.

Wie hoch können DSGVO-Bussgelder sein?

Artikel 83 sieht zwei Stufen vor. Verstösse der niedrigeren Stufe können bis zu 10 Millionen Euro oder 2 % des gesamten weltweiten Jahresumsatzes kosten, je nachdem welcher Betrag höher ist. Verstösse der höheren Stufe – einschliesslich gegen die Grundsätze, Betroffenenrechte und internationale Übermittlungsregeln – bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes, je nachdem welcher Betrag höher ist. Aufsichtsbehörden können zudem nicht monetäre korrigierende Massnahmen wie Verarbeitungsverbote verhängen, und Betroffene können nach Artikel 82 Schadenersatz verlangen.

Wie unterscheidet sich die DSGVO von der CCPA?

Die DSGVO ist ein rechtebasiertes Regime, das vor der Verarbeitung eine Rechtsgrundlage verlangt und für jede Organisation gilt, die Daten von EU-Betroffenen verarbeitet. Die CCPA in der Fassung des CPRA ist ein Verbraucherdatenschutzgesetz Kaliforniens, das für qualifizierende gewinnorientierte Unternehmen gilt und einem Opt-out-Modell für Verkauf und Weitergabe personenbezogener Informationen folgt, ohne allgemeinen Rechtsgrundlagenrahmen. Beide gewähren Rechte an personenbezogenen Daten, aber Einwilligungsarchitektur und Durchsetzungsmodelle unterscheiden sich grundlegend.

Wie wird man DSGVO-konform?

Compliance folgt einer Abfolge, nicht einem Dokument. Bestimmen Sie zuerst Anwendungsbereich und Ihre Rolle je Datenfluss und bauen Sie dann ein Dateninventar und eine Flusslandkarte. Bewerten Sie Lücken gegenüber den sieben Grundsätzen und den zentralen Pflichten und identifizieren Sie risikoreiche Verarbeitungen, die eine DPIA brauchen. Beheben Sie dann: Verzeichnis nach Artikel 30 vervollständigen, Löschfristen durchsetzen, einen funktionierenden Rechteprozess aufbauen, Auftragsverarbeitungsverträge korrigieren, Sicherheit härten und ein getestetes Melde-Runbook erstellen. Betreiben und belegen Sie schliesslich – verankern Sie Datenschutz in der Definition of Done, überwachen Sie Kennzahlen, testen Sie regelmässig und berichten Sie an die Geschäftsleitung. Compliance ist ein aufrechtzuerhaltender Zustand, kein Meilenstein.