\n| Europ\u00e4ischer Datenschutzausschuss<\/td>\n | Gremium aller Aufsichtsbeh\u00f6rden (Art. 68)<\/td>\n | Erl\u00e4sst Leitlinien, Stellungnahmen und verbindliche Beschl\u00fcsse bei grenz\u00fcberschreitenden Streitigkeiten<\/td>\n | EDSA-Leitlinien zu Einwilligung, \u00dcbermittlungen und Anonymisierung<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWer ist Verantwortlicher und wer Auftragsverarbeiter?<\/h3>\nDer Verantwortliche ist die Organisation, die entscheidet, warum<\/em> und wie<\/em> personenbezogene Daten verarbeitet werden. Der Auftragsverarbeiter f\u00fchrt diese Entscheidungen aus. Der Abgrenzungstest ist faktisch, nicht vertraglich: Sie k\u00f6nnen sich nicht von Verantwortlichkeiten befreien, indem Sie sich im Vertrag als Auftragsverarbeiter bezeichnen, wenn Sie tats\u00e4chlich \u00fcber Zwecke und Mittel entscheiden.<\/p>\nMehrere Konstellationen bringen Organisationen zu Fall. Ein SaaS-Anbieter, der Kundendaten streng nach dokumentierter Weisung verarbeitet, ist Auftragsverarbeiter \u2013 nutzt er diese Daten jedoch f\u00fcr eigene Produktanalysen, Benchmarks oder KI-Modelltrainings, wird er f\u00fcr diese T\u00e4tigkeit Verantwortlicher und braucht eine eigene Rechtsgrundlage. Eine Marketingagentur, die entscheidet, welche Zielgruppensegmente angesprochen werden, ist Verantwortlicher, auch wenn ihr Kunde die Kundenbeziehung h\u00e4lt. Werden Zwecke gemeinsam festgelegt, greift die gemeinsame Verantwortlichkeit nach Artikel 26 und eine Vereinbarung muss dokumentiert werden.<\/p>\n Die praktische Konsequenz: Ein Unternehmen kann f\u00fcr verschiedene Verarbeitungst\u00e4tigkeiten mehrere Rollen gleichzeitig innehaben. Ausgereifte DSGVO-Programme pflegen deshalb eine Rollenzuordnung pro Datenfluss und nicht ein unternehmensweites Etikett.<\/p>\n Was sind die sieben Grunds\u00e4tze der DSGVO-Compliance?<\/h2>\nArtikel 5 enth\u00e4lt die sieben Grunds\u00e4tze, die alles Weitere in der Verordnung bestimmen. Jedes Recht, jede Pflicht, jede DPIA und jedes Bussgeld l\u00e4sst sich auf einen von ihnen zur\u00fcckf\u00fchren. Als Liste gelesen wirken sie abstrakt; als technische Anforderungen gelesen sind sie sehr konkret.<\/p>\n Die sieben Grunds\u00e4tze im Einzelnen<\/h3>\n1. Rechtm\u00e4ssigkeit, Fairness und Transparenz \u2013 Artikel 5 Absatz 1 Buchstabe a.<\/strong> Die Verarbeitung muss auf einer der sechs Rechtsgrundlagen des Artikels 6 beruhen, darf f\u00fcr die betroffene Person nicht unangemessen nachteilig, unerwartet oder irref\u00fchrend 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.<\/p>\n2. Zweckbindung \u2013 Artikel 5 Absatz 1 Buchstabe b.<\/strong> F\u00fcr einen festgelegten, eindeutigen und legitimen Zweck erhobene Daten d\u00fcrfen nicht f\u00fcr einen damit unvereinbaren Zweck weiterverarbeitet werden. Die Vereinbarkeit wird anhand der Verbindung zwischen den Zwecken, des Erhebungskontexts, der Art der Daten, der Folgen f\u00fcr die Betroffenen und des Bestehens von Schutzvorkehrungen beurteilt. Die Rechnungsadresse eines Kunden f\u00fcr Betrugspr\u00fcfung wiederzuverwenden ist in der Regel vereinbar; sie zum Training eines Allzweck-KI-Modells zu nutzen in der Regel nicht.<\/p>\n3. Datenminimierung \u2013 Artikel 5 Absatz 1 Buchstabe c.<\/strong> Erheben Sie nur, was angemessen, relevant und auf das notwendige Mass beschr\u00e4nkt ist. Dieser Grundsatz wird am h\u00e4ufigsten durch Analytics-Implementierungen, CRM-Lead-Formulare und Log-Pipelines verletzt, die mehr erfassen, als irgendwer rechtfertigen kann. Jedes zus\u00e4tzliche Feld erh\u00f6ht das Verletzungsrisiko, den Aufwand f\u00fcr Auskunftsersuchen und die Speicherkosten.<\/p>\n4. Richtigkeit \u2013 Artikel 5 Absatz 1 Buchstabe d.<\/strong> Personenbezogene Daten m\u00fcssen richtig und, soweit erforderlich, auf dem neuesten Stand sein; unrichtige Daten sind unverz\u00fcglich zu l\u00f6schen oder zu berichtigen. Praktisch bedeutet das Datenqualit\u00e4tskontrollen, Dublettenmanagement und Berichtigungsworkflows, die bis in nachgelagerte Systeme einschliesslich Analytics und Backups durchgreifen.<\/p>\n5. Speicherbegrenzung \u2013 Artikel 5 Absatz 1 Buchstabe e.<\/strong> Daten d\u00fcrfen nicht l\u00e4nger in identifizierbarer Form gespeichert werden als notwendig. Das Wort \u201enotwendig” verlangt einen tats\u00e4chlichen L\u00f6schplan je Datenkategorie und Zweck sowie dessen automatisierte Durchsetzung. L\u00f6schpl\u00e4ne, die nur in einem Richtliniendokument, aber nicht im Code existieren, sind der h\u00e4ufigste Pr\u00fcfungsbefund der gesamten Verordnung.<\/p>\n6. Integrit\u00e4t und Vertraulichkeit \u2013 Artikel 5 Absatz 1 Buchstabe f.<\/strong> Geeignete technische und organisatorische Sicherheitsmassnahmen, einschliesslich Schutz gegen unbefugte oder unrechtm\u00e4ssige Verarbeitung sowie gegen versehentlichen Verlust, Zerst\u00f6rung oder Besch\u00e4digung. Artikel 32 konkretisiert: Pseudonymisierung und Verschl\u00fcsselung, dauerhafte Gew\u00e4hrleistung von Vertraulichkeit und Integrit\u00e4t, Belastbarkeit, Wiederherstellungsf\u00e4higkeit und regelm\u00e4ssige Tests.<\/p>\n7. Rechenschaftspflicht \u2013 Artikel 5 Absatz 2.<\/strong> Der Verantwortliche ist daf\u00fcr verantwortlich, die Einhaltung der anderen sechs Grunds\u00e4tze nachzuweisen. Die Rechenschaftspflicht ist der Metagrundsatz, der Absicht in Nachweis verwandelt \u2013 und der Grund, warum Verarbeitungsverzeichnisse, DPIAs, Schulungsnachweise und Designdokumentation existieren.<\/p>\nWie ver\u00e4ndert die Rechenschaftspflicht, was Sie bauen m\u00fcssen?<\/h3>\nDie Rechenschaftspflicht hat eine unbequeme Implikation, die IT-Verantwortliche fr\u00fch verinnerlichen sollten: Die Abwesenheit von Nachweisen gilt als Nachweis der Abwesenheit.<\/strong> Eine Aufsichtsbeh\u00f6rde muss nicht beweisen, dass Sie unrechtm\u00e4ssig verarbeitet haben. Sie kann Sie auffordern, die Einhaltung nachzuweisen, und wenn Sie das nicht k\u00f6nnen, ist bereits der Rechenschaftsgrundsatz verletzt.<\/p>\nDas verschiebt mehrere technische Entscheidungen. Eine Consent-Management-Plattform, die den genauen Wortlaut, Zeitstempel, die Oberfl\u00e4chenversion und den Umfang jeder Einwilligung aufzeichnet, ist keine B\u00fcrokratie, sondern der Nachweis, der den Grundsatz der Rechtm\u00e4ssigkeit 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\u00fchrt und die Ergebnisse archiviert, ist eine Compliance-Kontrolle, nicht nur eine Qualit\u00e4tskontrolle.<\/p>\n Rechenschaft verlangt zudem, dass Compliance \u00fcberwacht und nicht angenommen wird. Artikel 32 Absatz 1 Buchstabe d fordert ausdr\u00fccklich einen Prozess zur regelm\u00e4ssigen \u00dcberpr\u00fcfung, Bewertung und Evaluierung der Wirksamkeit der Sicherheitsmassnahmen. Hier wird Testdisziplin zu einer DSGVO-Anforderung statt zu einem Nice-to-have.<\/p>\n Die sieben Grunds\u00e4tze und ihre konkreten Kontrollen<\/h3>\n\n\n\n| Grundsatz<\/th>\n | Artikel<\/th>\n | Was er vom Unternehmen verlangt<\/th>\n | Konkrete IT- und Engineering-Kontrollen<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Rechtm\u00e4ssigkeit, Fairness und Transparenz<\/td>\n | 5 Abs. 1 lit. a<\/td>\n | Eine g\u00fcltige Rechtsgrundlage und ehrliche, klare Kommunikation<\/td>\n | Verarbeitungsverzeichnis mit Feld f\u00fcr die Rechtsgrundlage je T\u00e4tigkeit; Consent-Management-Plattform; mehrschichtige Datenschutzhinweise; Zweck-Tagging in Datenpipelines<\/td>\n<\/tr>\n | \n| Zweckbindung<\/td>\n | 5 Abs. 1 lit. b<\/td>\n | Keine Zweck\u00e4nderung ohne Vereinbarkeitspr\u00fcfung oder neue Grundlage<\/td>\n | Datenkatalog mit Zweckmetadaten; zweckgebundene Zugriffskontrolle; Change Control, die neue Nutzungen kennzeichnet; Trennung von Produktions- und Analytics-Datens\u00e4tzen<\/td>\n<\/tr>\n | \n| Datenminimierung<\/td>\n | 5 Abs. 1 lit. c<\/td>\n | Nur Notwendiges erheben<\/td>\n | Schema-Review-Gates; Pflichtfeldbegr\u00fcndung in Design-Reviews; Feld-Audits in Formularen und APIs; Log-Redaktionsrichtlinien; Abschalten standardm\u00e4ssiger Telemetrie<\/td>\n<\/tr>\n | \n| Richtigkeit<\/td>\n | 5 Abs. 1 lit. d<\/td>\n | Daten m\u00fcssen richtig und korrigierbar sein<\/td>\n | Master Data Management; Dublettenerkennung; Weitergabe von Korrekturen an nachgelagerte Systeme, Caches und abgeleitete Datens\u00e4tze; dokumentierte Berichtigungs-SLA<\/td>\n<\/tr>\n | \n| Speicherbegrenzung<\/td>\n | 5 Abs. 1 lit. e<\/td>\n | Definierte und durchgesetzte L\u00f6schfristen<\/td>\n | L\u00f6schplan je Datenkategorie; automatisierte L\u00f6sch- und Archivierungsjobs; abgestimmter Ablauf von Backups; Berichte zur L\u00f6schnachpr\u00fcfung<\/td>\n<\/tr>\n | \n| Integrit\u00e4t und Vertraulichkeit<\/td>\n | 5 Abs. 1 lit. f, 32<\/td>\n | Risikogerechte Sicherheit<\/td>\n | Verschl\u00fcsselung bei \u00dcbertragung und im Ruhezustand; Schl\u00fcsselmanagement; Pseudonymisierung; Least-Privilege-RBAC; MFA; Logging und Monitoring; Backup- und Restore-Tests; Schwachstellenmanagement; Penetrationstests<\/td>\n<\/tr>\n | \n| Rechenschaftspflicht<\/td>\n | 5 Abs. 2, 24<\/td>\n | Einhaltung auf Anfrage nachweisen<\/td>\n | Verzeichnis von Verarbeitungst\u00e4tigkeiten (Art. 30); DPIA-Repository; Schulungsnachweise; Audit-Trails; Datenschutzanforderungen in der Definition of Done; Aufbewahrung von Testnachweisen<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWas sind die Rechtsgrundlagen f\u00fcr die Verarbeitung personenbezogener Daten?<\/h2>\nDie 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\u00fcrfen, wor\u00fcber Sie informieren m\u00fcssen und ob Betroffene widersprechen oder widerrufen k\u00f6nnen.<\/p>\n Die sechs Rechtsgrundlagen nach Artikel 6<\/h3>\nEinwilligung \u2013 Artikel 6 Absatz 1 Buchstabe a.<\/strong> Jede freiwillig gegebene, spezifische, informierte und unmissverst\u00e4ndliche Willensbekundung der betroffenen Person. Die Einwilligung muss so einfach widerrufbar sein wie erteilbar, darf nicht an sachfremde Bedingungen gekoppelt werden und muss f\u00fcr ausdr\u00fcckliche Einwilligung nach Artikel 9 Absatz 2 Buchstabe a einen h\u00f6heren Standard erf\u00fcllen. Die Einwilligung ist die am h\u00e4ufigsten \u00fcberdehnte und die fragilste Grundlage, weil sie jederzeit widerrufen werden kann und einen vollst\u00e4ndigen Audit-Trail verlangt.<\/p>\nVertrag \u2013 Artikel 6 Absatz 1 Buchstabe b.<\/strong> Verarbeitung, die zur Erf\u00fcllung eines Vertrags mit der betroffenen Person oder zur Durchf\u00fchrung vorvertraglicher Massnahmen auf deren Anfrage erforderlich ist. Das umfasst Auftragsabwicklung, Lieferung, Kontoverwaltung und Zahlungsverarbeitung \u2013 nicht aber Marketing, Analytics oder Produktverbesserung, die eigene Zwecke und eigene Grundlagen darstellen.<\/p>\nRechtliche Verpflichtung \u2013 Artikel 6 Absatz 1 Buchstabe c.<\/strong> Verarbeitung, die zur Erf\u00fcllung einer rechtlichen Verpflichtung erforderlich ist, der der Verantwortliche unterliegt; die Verpflichtung muss sich aus Unionsrecht oder mitgliedstaatlichem Recht ergeben. Steuerunterlagen, Geldw\u00e4schepr\u00fcfungen, arbeitsrechtliche Pflichten und gesetzliche Berichtspflichten fallen hierunter. Die Verpflichtung muss konkret sein; der allgemeine Wunsch, Daten vorsorglich zu behalten, gen\u00fcgt nicht.<\/p>\nLebenswichtige Interessen \u2013 Artikel 6 Absatz 1 Buchstabe d.<\/strong> Verarbeitung, die zum Schutz des Lebens einer Person erforderlich ist. Diese Grundlage ist eng und f\u00fcr Notf\u00e4lle gedacht \u2013 medizinische Behandlung, Katastrophenhilfe, Schutz gef\u00e4hrdeter Personen \u2013 und kein Allzweck-Fallback f\u00fcr gesundheitsbezogene Daten.<\/p>\n\u00d6ffentliche Aufgabe \u2013 Artikel 6 Absatz 1 Buchstabe e.<\/strong> Verarbeitung, die f\u00fcr die Wahrnehmung einer Aufgabe im \u00f6ffentlichen Interesse oder in Aus\u00fcbung \u00f6ffentlicher Gewalt erforderlich ist. Relevant f\u00fcr \u00f6ffentliche Stellen und f\u00fcr Organisationen, die Aufgaben \u00f6ffentlicher Natur wahrnehmen.<\/p>\nBerechtigte Interessen \u2013 Artikel 6 Absatz 1 Buchstabe f.<\/strong> Verarbeitung, die zur Wahrung berechtigter Interessen des Verantwortlichen oder eines Dritten erforderlich ist, sofern nicht die Interessen oder Grundrechte und Grundfreiheiten der betroffenen Person \u00fcberwiegen. Dies ist die flexibelste und die disziplinbed\u00fcrftigste Grundlage: Eine Interessenabw\u00e4gung muss das Interesse, die Erforderlichkeit der Verarbeitung, die Abw\u00e4gung gegen die Rechte der betroffenen Person und die angewandten Schutzvorkehrungen dokumentieren. \u00d6ffentlichen Stellen ist sie f\u00fcr ihre \u00f6ffentlichen Aufgaben verwehrt.<\/p>\nZwei Regeln bestimmen die Auswahl. Erstens: Sie m\u00fcssen vor Beginn der Verarbeitung w\u00e4hlen<\/strong>, nicht nachtr\u00e4glich nach einer Beschwerde eine Grundlage konstruieren. Zweitens: Die Grundlage muss in Ihrem Datenschutzhinweis genannt werden<\/strong>, nach Artikel 13 Absatz 1 Buchstabe c und Artikel 14 Absatz 1 Buchstabe d, und Sie k\u00f6nnen die Grundlage nicht beliebig wechseln \u2013 ein Wechsel von berechtigtem Interesse zu Einwilligung mitten in der Verarbeitung ist in der Regel unzul\u00e4ssig, weil eine unter dem Druck \u201eEinwilligung oder wir stellen den Dienst ein” erteilte Einwilligung nicht freiwillig ist.<\/p>\nWas \u00e4ndert sich bei besonderen Kategorien personenbezogener Daten?<\/h3>\nArtikel 9 Absatz 1 verbietet die Verarbeitung besonderer Kategorien \u2013 rassische oder ethnische Herkunft, politische Meinungen, religi\u00f6se oder weltanschauliche \u00dcberzeugungen, Gewerkschaftszugeh\u00f6rigkeit, genetische Daten, biometrische Daten zur eindeutigen Identifizierung, Gesundheitsdaten sowie Daten zum Sexualleben oder zur sexuellen Orientierung \u2013, sofern keine der Voraussetzungen des Artikels 9 Absatz 2 vorliegt. Dazu geh\u00f6ren ausdr\u00fcckliche Einwilligung, arbeits- und sozialrechtliche Pflichten, lebenswichtige Interessen bei fehlender Einwilligungsf\u00e4higkeit, Daten, die die betroffene Person offensichtlich \u00f6ffentlich gemacht hat, Rechtsanspr\u00fcche, erhebliches \u00f6ffentliches Interesse, pr\u00e4ventiv- und arbeitsmedizinische Zwecke, \u00f6ffentliche Gesundheit sowie Archiv- und Forschungszwecke.<\/p>\n Die meisten Voraussetzungen des Artikels 9 Absatz 2 verlangen eine Grundlage im Unions- oder mitgliedstaatlichen Recht, weshalb die praktische Pr\u00fcfung jurisdiktionsabh\u00e4ngig ist. Artikel 10 f\u00fcgt eine weitere Ebene hinzu: Die Verarbeitung von Daten \u00fcber Straftaten und Strafurteile erfordert eine Erm\u00e4chtigung durch Unions- oder mitgliedstaatliches Recht oder die Kontrolle einer amtlichen Stelle.<\/p>\n F\u00fcr IT-Teams sind die operativen Folgen unmittelbar. Besondere Kategorien verlangen st\u00e4rkere Kontrollen \u2013 typischerweise Verschl\u00fcsselung mit separatem Schl\u00fcsselmanagement, strikt zweckgebundenen Zugriff, erweitertes Audit-Logging und h\u00e4ufig 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\u00e4sentation und kein Bild ist.<\/p>\n Rechtsgrundlagen in der Praxis<\/h3>\n\n\n\n| Rechtsgrundlage<\/th>\n | Definition<\/th>\n | Typischer Unternehmensfall<\/th>\n | H\u00e4ufiges Fehlermuster<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Einwilligung \u2013 Art. 6 Abs. 1 lit. a<\/td>\n | Freiwillige, spezifische, informierte und unmissverst\u00e4ndliche Willensbekundung<\/td>\n | Marketing-E-Mails an Interessenten; nicht notwendige Cookies; optionales Profiling<\/td>\n | Vorausgew\u00e4hlte K\u00e4stchen, geb\u00fcndelte Einwilligung, fehlender Widerrufsmechanismus, Consent Walls, die den Dienst von sachfremder Einwilligung abh\u00e4ngig machen<\/td>\n<\/tr>\n | \n| Vertrag \u2013 Art. 6 Abs. 1 lit. b<\/td>\n | Erforderlich zur Erf\u00fcllung eines Vertrags mit der betroffenen Person<\/td>\n | Auftragsabwicklung, Lieferung, Kontobereitstellung, Support<\/td>\n | Vertrag als Grundlage f\u00fcr Analytics, Personalisierung oder Marketing nutzen, die zur Leistungserbringung nicht erforderlich sind<\/td>\n<\/tr>\n | \n| Rechtliche Verpflichtung \u2013 Art. 6 Abs. 1 lit. c<\/td>\n | Erforderlich zur Erf\u00fcllung einer konkreten rechtlichen Pflicht<\/td>\n | Steuer- und Buchhaltungsunterlagen; AML-\/KYC-Pr\u00fcfungen; gesetzliche Personalunterlagen<\/td>\n | Rechtliche Verpflichtung nennen, ohne die konkrete Norm zu benennen; sie zur Rechtfertigung offener Aufbewahrung nutzen<\/td>\n<\/tr>\n | \n| Lebenswichtige Interessen \u2013 Art. 6 Abs. 1 lit. d<\/td>\n | Erforderlich zum Schutz des Lebens<\/td>\n | Notfallm\u00e4ssige Weitergabe medizinischer Daten; Katastrophenhilfe<\/td>\n | Als allgemeine Grundlage f\u00fcr gesundheitsbezogene Verarbeitung behandeln<\/td>\n<\/tr>\n | \n| \u00d6ffentliche Aufgabe \u2013 Art. 6 Abs. 1 lit. e<\/td>\n | Erforderlich f\u00fcr eine Aufgabe im \u00f6ffentlichen Interesse oder in Aus\u00fcbung \u00f6ffentlicher Gewalt<\/td>\n | Kommunale Leistungen; gesetzliche Register; \u00f6ffentlich finanzierte Forschung<\/td>\n | Private Organisationen berufen sich auf \u00f6ffentliche Aufgabe ohne Rechtsmandat<\/td>\n<\/tr>\n | \n| Berechtigte Interessen \u2013 Art. 6 Abs. 1 lit. f<\/td>\n | Erforderlich f\u00fcr berechtigte Interessen, sofern Betroffenenrechte nicht \u00fcberwiegen<\/td>\n | Netz- und Informationssicherheit; Betrugspr\u00e4vention; konzerninterne Verwaltung; Direktwerbung an Bestandskunden in bestimmtem Umfang<\/td>\n | Keine dokumentierte Interessenabw\u00e4gung; Nutzung dort, wo Einwilligung erforderlich ist; Missachtung des absoluten Widerspruchsrechts gegen Direktwerbung<\/td>\n<\/tr>\n | \n| Ausdr\u00fcckliche Einwilligung f\u00fcr besondere Kategorien \u2013 Art. 9 Abs. 2 lit. a<\/td>\n | Ausdr\u00fcckliche, spezifische Einwilligung zur Verarbeitung nach Art. 9<\/td>\n | Daten von Gesundheits-Apps; freiwilliges Diversit\u00e4tsmonitoring; Barrierefreiheits-Anpassungen<\/td>\n | Gew\u00f6hnliche Einwilligung als ausdr\u00fcckliche Einwilligung behandeln; keine separate granular Einwilligung je Datenart<\/td>\n<\/tr>\n | \n| Erhebliches \u00f6ffentliches Interesse \u2013 Art. 9 Abs. 2 lit. g<\/td>\n | Verarbeitung auf Grundlage von Unions- oder mitgliedstaatlichem Recht wegen erheblichen \u00f6ffentlichen Interesses<\/td>\n | Betrugsregister; Schutz gef\u00e4hrdeter Personen; Hinweisgebersysteme<\/td>\n | Annahme, ein allgemeines kommerzielles Interesse gen\u00fcge<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWelche Rechte haben Betroffene und wie erf\u00fcllen Sie diese?<\/h2>\nBetroffenenrechte sind der Punkt, an dem DSGVO-Compliance zu einer operativen Dienstleistung mit Fristen wird. Jedes Recht hat einen Ausl\u00f6ser, ein Antwortfenster und einen Nachweispfad \u2013 und jedes ber\u00fchrt mehrere Systeme.<\/p>\n Die acht Betroffenenrechte im Einzelnen<\/h3>\nRecht auf Information \u2013 Artikel 13\u201314.<\/strong> Betroffene m\u00fcssen zum Zeitpunkt der Erhebung bestimmte Informationen erhalten: Identit\u00e4t des Verantwortlichen, Zwecke, Rechtsgrundlage, Empf\u00e4nger, \u00dcbermittlungen, 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\u00fcher eintritt) erfolgen.<\/p>\nAuskunftsrecht \u2013 Artikel 15.<\/strong> Betroffene k\u00f6nnen eine Best\u00e4tigung verlangen, ob ihre Daten verarbeitet werden, eine Kopie dieser Daten sowie Angaben zu Zwecken, Kategorien, Empf\u00e4ngern, Speicherdauer und zur Existenz automatisierter Entscheidungsfindung. Dies ist in der Praxis das Recht mit dem h\u00f6chsten Volumen und dasjenige, das unzureichendes Datenmapping am h\u00e4ufigsten offenlegt, weil eine Antwort jedes System abdecken muss, das Daten der Person h\u00e4lt \u2013 einschliesslich Logs, Backups, Support-Tickets, Tabellenkalkulationen und Schatten-IT.<\/p>\nRecht auf Berichtigung \u2013 Artikel 16.<\/strong> Unrichtige Daten sind unverz\u00fcglich zu berichtigen, unvollst\u00e4ndige zu vervollst\u00e4ndigen. Die Berichtigung muss bis in nachgelagerte Systeme, abgeleitete Datens\u00e4tze und Analytics durchgreifen.<\/p>\nRecht auf L\u00f6schung \u2013 Artikel 17.<\/strong> Auch als \u201eRecht auf Vergessenwerden” bekannt. Es greift, wenn Daten nicht mehr erforderlich sind, die Einwilligung widerrufen wird, die betroffene Person widerspricht und keine \u00fcberwiegenden berechtigten Gr\u00fcnde bestehen, die Verarbeitung unrechtm\u00e4ssig war oder eine rechtliche Pflicht die L\u00f6schung verlangt. Es ist nicht absolut: Es gilt nicht, soweit die Verarbeitung zur Erf\u00fcllung rechtlicher Pflichten, zur Geltendmachung von Rechtsanspr\u00fcchen, f\u00fcr \u00f6ffentliche Gesundheit oder f\u00fcr Archiv- und Forschungszwecke im \u00f6ffentlichen Interesse erforderlich ist. Die L\u00f6schung muss auch Dritte erfassen, an die Daten offengelegt wurden.<\/p>\nRecht auf Einschr\u00e4nkung der Verarbeitung \u2013 Artikel 18.<\/strong> Die Verarbeitung kann pausiert werden, solange Richtigkeit oder Rechtm\u00e4ssigkeit bestritten wird. Technisch ist dies ein Status-Flag, das jede Verarbeitung unterdr\u00fccken muss, w\u00e4hrend der Datensatz erhalten bleibt.<\/p>\nRecht auf Daten\u00fcbertragbarkeit \u2013 Artikel 20.<\/strong> Beruht die Verarbeitung auf Einwilligung oder Vertrag und erfolgt sie automatisiert, kann die betroffene Person ihre Daten in einem strukturierten, g\u00e4ngigen, maschinenlesbaren Format erhalten und \u2013 soweit technisch machbar \u2013 an einen anderen Verantwortlichen \u00fcbermitteln lassen.<\/p>\nWiderspruchsrecht \u2013 Artikel 21.<\/strong> Betroffene k\u00f6nnen der Verarbeitung auf Grundlage berechtigter Interessen oder \u00f6ffentlicher Aufgabe widersprechen; der Verantwortliche muss die Verarbeitung einstellen, sofern er nicht zwingende berechtigte Gr\u00fcnde nachweist. Bei Direktwerbung ist das Widerspruchsrecht absolut und bedingungslos: Die Verarbeitung muss mit Eingang des Widerspruchs enden.<\/p>\nRechte bei automatisierter Entscheidungsfindung \u2013 Artikel 22.<\/strong> 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\u00e4chtigt \u2013 es sei denn, die Entscheidung ist f\u00fcr einen Vertrag erforderlich, gesetzlich zugelassen oder beruht auf ausdr\u00fccklicher Einwilligung. Wo solche Entscheidungen zul\u00e4ssig sind, m\u00fcssen Schutzvorkehrungen menschliches Eingreifen, eine Erkl\u00e4rung der Logik und die M\u00f6glichkeit der Anfechtung umfassen. Dieser Artikel wird f\u00fcr Bonit\u00e4tsbewertung, Bewerber-Screening, Versicherungstarifierung und KI-gest\u00fctzte Betrugserkennung zunehmend relevant.<\/p>\nWie setzen Sie ein Auskunftsersuchen operativ um?<\/h3>\nEin Auskunftsersuchen nach Artikel 15 muss innerhalb eines Monats<\/strong> nach Eingang beantwortet werden. Diese Frist kann bei komplexen oder zahlreichen Antr\u00e4gen um zwei weitere Monate verl\u00e4ngert werden, wobei die Verl\u00e4ngerung innerhalb des ersten Monats mit Begr\u00fcndung mitgeteilt werden muss. Die Frist beginnt, wenn der Antrag bei irgendeinem Teil der Organisation eingeht \u2013 nicht, wenn er das Datenschutzteam erreicht.<\/p>\nDie Identit\u00e4tspr\u00fcfung ist zul\u00e4ssig und erwartet. Ein Verantwortlicher darf Informationen anfordern, die zur Best\u00e4tigung der Identit\u00e4t erforderlich sind, aber nicht mehr als daf\u00fcr n\u00f6tig erheben. Ist der Antrag offensichtlich unbegr\u00fcndet oder exzessiv, kann ein angemessenes Entgelt verlangt oder der Antrag abgelehnt werden \u2013 die Beweislast daf\u00fcr tr\u00e4gt jedoch der Verantwortliche.<\/p>\n Ein funktionierender Auskunftsprozess braucht sechs Komponenten:<\/p>\n \n- Einen einzigen Eingangskanal<\/strong>, der im Datenschutzhinweis ver\u00f6ffentlicht und \u00fcberwacht wird, mit Protokollierung jedes Antrags bei Eingang.<\/li>\n
- Einen dokumentierten Suchumfang<\/strong>, der jedes System, jede Datenbank, jeden Log-Speicher, jedes Backup, jedes Postfach und jeden Auftragsverarbeiter auflistet, der personenbezogene Daten dieser Person halten k\u00f6nnte.<\/li>\n
- Einen Abrufworkflow<\/strong> einschliesslich Unterst\u00fctzung durch Auftragsverarbeiter, die nach Artikel 28 Absatz 3 Buchstabe e antworten m\u00fcssen.<\/li>\n
- Einen Redaktionsschritt<\/strong> zum Entfernen von Daten Dritter und rechtlich gesch\u00fctztem oder ausgenommenem Material, mit dokumentierter Ausnahmegrundlage.<\/li>\n
- Einen sicheren \u00dcbermittlungsweg<\/strong> \u2013 verschl\u00fcsselte \u00dcbertragung oder authentifiziertes Portal \u2013, niemals ein unverschl\u00fcsselter E-Mail-Anhang.<\/li>\n
- Ein Abschlussprotokoll<\/strong> mit Datumsangaben, Entscheidungen, angewandten Ausnahmen und aufbewahrten Nachweisen f\u00fcr die Rechenschaftspflicht.<\/li>\n<\/ol>\n
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.<\/p>\n Betroffenenrechte im \u00dcberblick<\/h3>\n\n\n\n| Recht<\/th>\n | Artikel<\/th>\n | Ausl\u00f6ser<\/th>\n | Antwortfrist<\/th>\n | Typische Systember\u00fchrungspunkte<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Auf Information<\/td>\n | 13\u201314<\/td>\n | Erhebung personenbezogener Daten<\/td>\n | Bei Erhebung; innerhalb 1 Monat bei indirekter Erhebung<\/td>\n | Website, App-Onboarding, Datenschutzhinweis-CMS, CRM<\/td>\n<\/tr>\n | \n| Auf Auskunft<\/td>\n | 15<\/td>\n | Antrag der betroffenen Person<\/td>\n | 1 Monat (verl\u00e4ngerbar um 2 Monate mit Mitteilung)<\/td>\n | CRM, ERP, Data Warehouse, Logs, Postf\u00e4cher, Support-Tickets, Systeme von Auftragsverarbeitern<\/td>\n<\/tr>\n | \n| Auf Berichtigung<\/td>\n | 16<\/td>\n | Unrichtige oder unvollst\u00e4ndige Daten<\/td>\n | 1 Monat<\/td>\n | Master-Data-Systeme, nachgelagerte Caches, Analytics, bereits geteilte Exporte<\/td>\n<\/tr>\n | \n| Auf L\u00f6schung<\/td>\n | 17<\/td>\n | Antrag oder rechtlicher Ausl\u00f6ser; kein \u00fcberwiegender Grund<\/td>\n | 1 Monat<\/td>\n | Alle Produktivspeicher, Backups, abgeleitete Datens\u00e4tze, Auftragsverarbeiter, Suchindizes<\/td>\n<\/tr>\n | \n| Auf Einschr\u00e4nkung<\/td>\n | 18<\/td>\n | Bestrittene Richtigkeit oder Rechtm\u00e4ssigkeit<\/td>\n | 1 Monat<\/td>\n | Verarbeitungs-Flags, Workflow-Engines, API-Gateways, Marketing-Suppression-Listen<\/td>\n<\/tr>\n | \n| Auf Daten\u00fcbertragbarkeit<\/td>\n | 20<\/td>\n | Einwilligungs- oder vertragsbasierte automatisierte Verarbeitung<\/td>\n | 1 Monat<\/td>\n | Export-Dienste, Schema-Dokumentation, Formatkonverter<\/td>\n<\/tr>\n | \n| Auf Widerspruch<\/td>\n | 21<\/td>\n | Widerspruch gegen berechtigte Interessen oder \u00f6ffentliche Aufgabe<\/td>\n | 1 Monat; sofort bei Direktwerbung<\/td>\n | Marketing-Automation, Consent-Plattform, Suppression-Listen, Werbeplattformen<\/td>\n<\/tr>\n | \n| Automatisierte Entscheidungsfindung<\/td>\n | 22<\/td>\n | Ausschliesslich automatisierte Entscheidung<\/td>\n | 1 Monat<\/td>\n | Scoring-Engines, ML-Modelle, Entscheidungsprotokolle, menschliche Pr\u00fcfwarteschlangen<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWas sind die zentralen operativen Pflichten der DSGVO-Compliance?<\/h2>\n\u00dcber Grunds\u00e4tze und Rechte hinaus enth\u00e4lt die DSGVO benannte operative Pflichten. Jede hat einen Ausl\u00f6ser, ein erforderliches Ergebnis und einen nat\u00fcrlichen Verantwortlichen. Sie als Dokumentencheckliste zu behandeln ist der schnellste Weg zu einem Pr\u00fcfungsbefund; sie als Kontrollen mit Verantwortlichen zu behandeln der schnellste Weg zu dauerhafter Compliance.<\/p>\n Verzeichnis von Verarbeitungst\u00e4tigkeiten und Datenmapping \u2013 Artikel 30<\/h3>\nArtikel 30 verlangt von Verantwortlichen und Auftragsverarbeitern ein Verzeichnis der Verarbeitungst\u00e4tigkeiten. F\u00fcr Verantwortliche muss das Verzeichnis Zwecke, Kategorien betroffener Personen und personenbezogener Daten, Empf\u00e4nger, Drittland\u00fcbermittlungen und Garantien, L\u00f6schfristen und, soweit m\u00f6glich, Sicherheitsmassnahmen enthalten. Organisationen mit weniger als 250 Besch\u00e4ftigten profitieren von einer eingeschr\u00e4nkten Ausnahme, doch diese ist enger als sie scheint: Sie gilt nicht, wenn die Verarbeitung nicht nur gelegentlich erfolgt, wenn sie wahrscheinlich ein Risiko f\u00fcr Rechte und Freiheiten mit sich bringt oder wenn besondere Kategorien betroffen sind \u2013 Bedingungen, die auf die meisten kommerziellen Verarbeitungen zutreffen.<\/p>\n Das Verzeichnis ist nur so gut wie das Datenmapping dahinter. Eine brauchbare Landkarte entsteht aus systembasierter Erhebung, nicht aus Interviews. Sie sollte f\u00fcr jedes Feld personenbezogener Daten beantworten: welches System es h\u00e4lt, wer Eigent\u00fcmer ist, welcher Zweck gilt, welche Rechtsgrundlage greift, wer Zugriff hat, wohin \u00fcbermittelt wird, wie lange gespeichert und wie gel\u00f6scht wird. In den meisten Organisationen ist dies der gr\u00f6sste Arbeitsblock des gesamten Programms \u2013 und die Grundlage f\u00fcr alles andere.<\/p>\n Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen \u2013 Artikel 25<\/h3>\nArtikel 25 verlangt, Datenschutz von Anfang an in die Verarbeitung einzubauen und standardm\u00e4ssig die datenschutzfreundlichsten Einstellungen anzuwenden, ohne dass die betroffene Person t\u00e4tig werden muss. Die Voreinstellungsklausel \u00fcberrascht Organisationen regelm\u00e4ssig: Eine Anwendung, die Profildaten \u00f6ffentlich teilt, solange der Nutzer keine Einstellung findet, hat den Test nicht bestanden \u2013 unabh\u00e4ngig davon, wie gut die Einstellung dokumentiert ist.<\/p>\n 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\u00fcr analytische Nutzung, zweckgebundene Zugriffstoken, automatisierte Durchsetzung von L\u00f6schfristen, Einwilligungsstatus als erstklassiges Attribut im Datenmodell und datenschutzfreundliche Standardeinstellungen in Benutzeroberfl\u00e4chen.<\/p>\n Datenschutz-Folgenabsch\u00e4tzung \u2013 Artikel 35<\/h3>\nEine DPIA ist erforderlich, wenn eine Verarbeitungsart voraussichtlich ein hohes Risiko f\u00fcr die Rechte und Freiheiten nat\u00fcrlicher Personen zur Folge hat. Artikel 35 Absatz 3 nennt drei F\u00e4lle, die fast immer eine DPIA ausl\u00f6sen: systematische und umfassende Bewertung pers\u00f6nlicher Aspekte auf Basis automatisierter Verarbeitung einschliesslich Profiling, auf die Entscheidungen mit rechtlicher Wirkung oder \u00e4hnlich erheblicher Beeintr\u00e4chtigung gest\u00fctzt werden; umfangreiche Verarbeitung besonderer Kategorien oder von Daten \u00fcber Straftaten; und systematische umfangreiche \u00dcberwachung \u00f6ffentlich zug\u00e4nglicher Bereiche.<\/p>\n Aufsichtsbeh\u00f6rden ver\u00f6ffentlichen Listen von Verarbeitungen, die eine DPIA erfordern, und die Kriterien des EDSA \u2013 Bewertung oder Scoring, automatisierte Entscheidungsfindung mit rechtlicher oder \u00e4hnlicher Wirkung, systematische \u00dcberwachung, sensible Daten, Verarbeitung in grossem Umfang, Zusammenf\u00fchrung oder Verkn\u00fcpfung von Datens\u00e4tzen, Daten \u00fcber schutzbed\u00fcrftige Personen, innovative Technologienutzung und Verarbeitung, die Betroffene an der Aus\u00fcbung eines Rechts hindert \u2013 dienen der Bestimmung, ob die Schwelle \u00fcberschritten ist. Zwei oder mehr Kriterien weisen in der Regel auf eine DPIA hin.<\/p>\n Eine belastbare DPIA ist eine strukturierte Risikobewertung, kein Formular. Sie sollte die Verarbeitung systematisch beschreiben, Notwendigkeit und Verh\u00e4ltnism\u00e4ssigkeit am Zweck messen, Risiken f\u00fcr Betroffene identifizieren, Abhilfemassnahmen definieren, die Stellungnahme des DSB \u2013 falls vorhanden \u2013 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\u00f6rde nach Artikel 36 erfordert.<\/p>\n Brauchen Sie einen Datenschutzbeauftragten? \u2013 Artikel 37\u201339<\/h3>\nEin DSB ist nach Artikel 37 Absatz 1 in drei F\u00e4llen verpflichtend: wenn die Verarbeitung von einer \u00f6ffentlichen Stelle oder Einrichtung durchgef\u00fchrt wird, ausgenommen Gerichte in ihrer justiziellen T\u00e4tigkeit; wenn die Kernt\u00e4tigkeiten des Verantwortlichen oder Auftragsverarbeiters in Verarbeitungen bestehen, die aufgrund ihrer Art, ihres Umfangs oder ihrer Zwecke eine regelm\u00e4ssige und systematische umfangreiche \u00dcberwachung betroffener Personen erfordern; und wenn die Kernt\u00e4tigkeiten in der umfangreichen Verarbeitung besonderer Kategorien oder von Daten \u00fcber Straftaten bestehen.<\/p>\n Der DSB muss angemessen eingebunden sein, der h\u00f6chsten Managementebene berichten, keine Weisungen zur Aufgabenerf\u00fcllung erhalten, wegen der Wahrnehmung seiner Aufgaben nicht abberufen oder benachteiligt werden und \u00fcber angemessene Ressourcen verf\u00fcgen. Ein DSB kann extern auf Dienstleistungsbasis bestellt werden, was in mittelgrossen Organisationen \u00fcblich ist, die Unabh\u00e4ngigkeit ohne Vollzeitstelle brauchen. Die Aufgaben sind in Artikel 39 geregelt: Unterrichtung und Beratung, \u00dcberwachung der Einhaltung einschliesslich Schulungen und Audits, Beratung zu DPIAs, Zusammenarbeit mit der Aufsichtsbeh\u00f6rde und Funktion als Anlaufstelle. Ein DSB, der zugleich IT-Leiter, CISO oder Marketingleiter ist, schafft einen strukturellen Interessenkonflikt, den Aufsichtsbeh\u00f6rden wiederholt kritisiert haben.<\/p>\n Vertr\u00e4ge mit Auftragsverarbeitern und Due Diligence \u2013 Artikel 28<\/h3>\nWird Verarbeitung im Auftrag eines Verantwortlichen durchgef\u00fchrt, 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\u00fctzung bei Betroffenenrechten und DPIAs, Meldung von Verletzungen an den Verantwortlichen, L\u00f6schung oder R\u00fcckgabe der Daten am Ende der Beauftragung sowie Audit- und Pr\u00fcfrechte. Der Vertrag muss zudem Gegenstand, Dauer, Art und Zweck der Verarbeitung, die Art der personenbezogenen Daten und die Kategorien betroffener Personen festlegen.<\/p>\n Vertr\u00e4ge 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 \u2013 Zertifizierungen, Zusammenfassungen von Penetrationstests, Transparenz bei Unterauftragsverarbeitern, Verletzungshistorie, Optionen zur Datenresidenz und Zusagen zum Incident Response. Diese Bewertung muss regelm\u00e4ssig wiederholt werden, weil sich die Lage eines Auftragsverarbeiters \u00e4ndert, wenn er w\u00e4chst, \u00fcbernommen wird oder neue KI-Funktionen einf\u00fchrt, die Kundendaten wiederverwenden.<\/p>\n Sicherheit der Verarbeitung und Meldung von Verletzungen \u2013 Artikel 32\u201334<\/h3>\nArtikel 32 verlangt risikogerechte technische und organisatorische Massnahmen und nennt ausdr\u00fccklich Pseudonymisierung und Verschl\u00fcsselung, die F\u00e4higkeit, dauerhaft Vertraulichkeit, Integrit\u00e4t, Verf\u00fcgbarkeit und Belastbarkeit sicherzustellen, die F\u00e4higkeit, Verf\u00fcgbarkeit und Zugang nach einem Vorfall wiederherzustellen, sowie einen Prozess zur regelm\u00e4ssigen \u00dcberpr\u00fcfung und Bewertung der Wirksamkeit der Massnahmen. Er erlaubt zudem, die Einhaltung eines genehmigten Zertifizierungsmechanismus als Element des Nachweises heranzuziehen.<\/p>\n Artikel 33 verlangt die Meldung einer Datenschutzverletzung an die zust\u00e4ndige Aufsichtsbeh\u00f6rde unverz\u00fcglich und, soweit m\u00f6glich, sp\u00e4testens 72 Stunden<\/strong> nach Bekanntwerden. Die Meldung muss die Art der Verletzung, Kategorien und ungef\u00e4hre Zahl betroffener Personen und Datens\u00e4tze, den DSB oder eine Kontaktstelle, wahrscheinliche Folgen sowie ergriffene oder vorgeschlagene Massnahmen beschreiben. Erfolgt die Meldung nicht innerhalb von 72 Stunden, sind die Gr\u00fcnde f\u00fcr die Verz\u00f6gerung anzugeben. Ist die Verletzung voraussichtlich nicht mit einem Risiko f\u00fcr Rechte und Freiheiten verbunden, ist keine Meldung erforderlich \u2013 die Entscheidung muss aber intern dokumentiert werden, und Auftragsverarbeiter m\u00fcssen Verantwortliche unverz\u00fcglich nach Artikel 33 Absatz 2 benachrichtigen.<\/p>\nArtikel 34 verlangt die Benachrichtigung der Betroffenen unverz\u00fcglich, wenn die Verletzung voraussichtlich ein hohes Risiko f\u00fcr ihre Rechte und Freiheiten zur Folge hat \u2013 es sei denn, die Daten wurden durch Verschl\u00fcsselung unverst\u00e4ndlich gemacht, nachtr\u00e4gliche Massnahmen haben das hohe Risiko beseitigt oder die Benachrichtigung w\u00e4re mit unverh\u00e4ltnism\u00e4ssigem Aufwand verbunden. Im letzten Fall ist stattdessen eine \u00f6ffentliche Bekanntmachung erforderlich.<\/p>\n Die 72-Stunden-Frist ist eine F\u00e4higkeitsanforderung, keine Papieranforderung. Sie einzuhalten bedeutet, Erkennung, Triage-Kriterien, Schweregradklassifizierung, Eskalationswege, rechtliche Pr\u00fcfung und Meldungsvorlagen im Voraus vorbereitet und ge\u00fcbt zu haben. Organisationen, die ihre Reaktion mit Tabletop-\u00dcbungen und simulierten Vorf\u00e4llen testen, halten die Frist routinem\u00e4ssig ein. Organisationen, die eine Richtlinie schreiben und nie proben, nicht.<\/p>\n Internationale Daten\u00fcbermittlungen nach Schrems II<\/h3>\nKapitel V beschr\u00e4nkt die \u00dcbermittlung personenbezogener Daten ausserhalb des EWR. \u00dcbermittlungen sind zul\u00e4ssig, wenn die Kommission einen Angemessenheitsbeschluss erlassen hat oder \u2013 ohne Angemessenheit \u2013 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\u00f6tig, erg\u00e4nzende Massnahmen vorsieht.<\/p>\n Die Angemessenheitslandschaft ist komplexer geworden. Das EU-US Data Privacy Framework bietet einen Angemessenheitsweg f\u00fcr Organisationen, die sich zertifizieren lassen, w\u00e4hrend das fr\u00fchere Privacy Shield 2020 vom Gerichtshof im Urteil Schrems II f\u00fcr ung\u00fcltig erkl\u00e4rt wurde. Da Angemessenheitsbeschl\u00fcsse angefochten werden k\u00f6nnen, vermeiden ausgereifte Programme, einen einzelnen \u00dcbermittlungsmechanismus als dauerhaft gesichert zu behandeln. Praktische Schritte: ein \u00dcbermittlungsregister f\u00fchren, Datenresidenz und Unterauftragsketten von Anbietern pr\u00fcfen, Verschl\u00fcsselung und Schl\u00fcsselverwahrung anwenden, die Schl\u00fcssel im EWR halten, wo das Risiko es verlangt, und Transfer Impact Assessments je Ziel und Datenart dokumentieren.<\/p>\n Zentrale operative Pflichten im \u00dcberblick<\/h3>\n\n\n\n| Pflicht<\/th>\n | Artikel<\/th>\n | Ausl\u00f6ser<\/th>\n | Erforderliches Ergebnis<\/th>\n | Typischer Verantwortlicher<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Verzeichnis von Verarbeitungst\u00e4tigkeiten<\/td>\n | 30<\/td>\n | Jede Verarbeitung (Ausnahme ist eng)<\/td>\n | Gepflegtes und aktuelles Verarbeitungsverzeichnis<\/td>\n | Datenschutzorganisation mit Systemeigent\u00fcmern<\/td>\n<\/tr>\n | \n| Datenschutz durch Technikgestaltung und Voreinstellungen<\/td>\n | 25<\/td>\n | Jede neue oder ge\u00e4nderte Verarbeitung<\/td>\n | Datenschutzanforderungen im Design; datenschutzfreundliche Standardeinstellungen<\/td>\n | Architektur- und Engineering-Verantwortliche<\/td>\n<\/tr>\n | \n| Datenschutz-Folgenabsch\u00e4tzung<\/td>\n | 35<\/td>\n | Verarbeitung mit hohem Risiko; F\u00e4lle nach Art. 35 Abs. 3; Beh\u00f6rdenlisten<\/td>\n | Dokumentierte DPIA mit Risiken, Massnahmen und Entscheidung<\/td>\n | Fachbereich mit Beratung des DSB<\/td>\n<\/tr>\n | \n| Datenschutzbeauftragter<\/td>\n | 37\u201339<\/td>\n | \u00d6ffentliche Stelle, umfangreiche \u00dcberwachung, umfangreiche besondere Kategorien<\/td>\n | Bestellter, unabh\u00e4ngiger und ausgestatteter DSB<\/td>\n | Gesch\u00e4ftsleitung<\/td>\n<\/tr>\n | \n| Vertr\u00e4ge mit Auftragsverarbeitern<\/td>\n | 28<\/td>\n | Jede Beauftragung eines Auftragsverarbeiters<\/td>\n | Vertrag nach Art. 28 plus Due-Diligence-Nachweis<\/td>\n | Beschaffung mit Rechtsabteilung<\/td>\n<\/tr>\n | \n| Sicherheit der Verarbeitung<\/td>\n | 32<\/td>\n | Alle Verarbeitungen<\/td>\n | Risikogerechte Massnahmen plus Nachweise regelm\u00e4ssiger Tests<\/td>\n | CISO und Engineering<\/td>\n<\/tr>\n | \n| Meldung von Verletzungen<\/td>\n | 33\u201334<\/td>\n | Bekanntwerden einer Datenschutzverletzung<\/td>\n | Meldung an die Aufsichtsbeh\u00f6rde binnen 72 Stunden; Benachrichtigung Betroffener bei hohem Risiko<\/td>\n | Incident Response mit DSB<\/td>\n<\/tr>\n | \n| Internationale \u00dcbermittlungen<\/td>\n | 44\u201349<\/td>\n | \u00dcbermittlung ausserhalb des EWR<\/td>\n | Angemessenheit oder Garantien plus Transfer Impact Assessment<\/td>\n | Rechtsabteilung mit Architektur<\/td>\n<\/tr>\n | \n| Vorherige Konsultation<\/td>\n | 36<\/td>\n | Hohes Restrisiko nach DPIA<\/td>\n | Konsultation der Aufsichtsbeh\u00f6rde vor der Verarbeitung<\/td>\n | DSB mit Fachbereich<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWie unterscheidet sich die DSGVO-Compliance von anderen Datenschutzgesetzen?<\/h2>\nMultinationale Organisationen sehen sich selten nur einem Datenschutzregime gegen\u00fcber. Zu verstehen, wo die DSGVO im Verh\u00e4ltnis zu ihren Nachbarn steht, verhindert den h\u00e4ufigen Fehler, ein Kontrollset zu bauen und anzunehmen, es reise mit.<\/p>\n DSGVO vs. CCPA\/CPRA<\/h3>\nDer California Consumer Privacy Act in der durch den California Privacy Rights Act ge\u00e4nderten Fassung ist ein Verbraucherdatenschutzgesetz mit anderer Architektur. Er gilt f\u00fcr gewinnorientierte Unternehmen, die Umsatz- oder Datenmengenschwellen erreichen und mit Einwohnern Kaliforniens zu tun haben, und ist um Rechte an \u201epersonal information” und \u201esensitive personal information” aufgebaut. Er verlangt Information bei Erhebung, Rechte auf Wissen, L\u00f6schen, Berichtigen, Widerspruch gegen Verkauf oder Weitergabe und Einschr\u00e4nkung der Nutzung sensibler Daten und wird prim\u00e4r von der California Privacy Protection Agency und dem Attorney General mit zivilrechtlichen Bussgeldern durchgesetzt, nicht mit am globalen Umsatz bemessenen Verwaltungsbussgeldern.<\/p>\n Die praktisch relevanten Unterschiede f\u00fcr Entwicklungsteams sind das Opt-out-Modell (CCPA\/CPRA erlaubt Verkauf und Weitergabe, solange der Verbraucher nicht widerspricht, w\u00e4hrend 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\u00e4ftigten- und B2B-Daten, die die DSGVO vollst\u00e4ndig erfasst. Ein gut gebautes DSGVO-Programm erf\u00fcllt vieles von CCPA\/CPRA, aber die Einwilligungsarchitektur ist tats\u00e4chlich anders und nicht einfach wiederverwendbar.<\/p>\n DSGVO vs. UK GDPR<\/h3>\nNach dem Austritt des Vereinigten K\u00f6nigreichs aus der EU hat das Land die DSGVO als UK GDPR in innerstaatliches Recht \u00fcbernommen, erg\u00e4nzt 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\u00f6nigreich verfolgt eine eigene Reformagenda, einen eigenen internationalen \u00dcbermittlungsrahmen mit eigenen Angemessenheitsregelungen, eigene Ans\u00e4tze zu bestimmten Einwilligungs- und Cookie-Fragen und eine eigene Aufsicht im Information Commissioner’s Office. F\u00fcr Organisationen, die in beiden M\u00e4rkten t\u00e4tig sind, ist der praktische Ansatz ein gemeinsames Kernkontrollset mit einem dokumentierten Register jurisdiktionsspezifischer Abweichungen.<\/p>\n DSGVO vs. LGPD, PIPL und andere Regime<\/h3>\nBrasiliens LGPD orientiert sich stark an der Struktur der DSGVO \u2013 Rechtsgrundlagen, Betroffenenrechte, eine nationale Beh\u00f6rde (ANPD) und Verwaltungssanktionen \u2013, enth\u00e4lt aber eine eigene Rechtsgrundlage des Kreditschutzes und abweichende Regeln zum berechtigten Interesse. Chinas PIPL verbindet DSGVO-\u00e4hnliche Konzepte mit einer staatssicherheitsbezogenen Rahmung, verlangt in mehr Situationen separate Einwilligung, erlegt f\u00fcr bestimmte \u00dcbermittlungen Datenlokalisierung und Sicherheitsbewertungen auf und kennt keine unabh\u00e4ngige Aufsichtsbeh\u00f6rde im europ\u00e4ischen Sinne. Indiens DPDP Act w\u00e4hlt einen anderen Weg mit einem Consent-Manager-Modell und staatlich benannten \u201esignificant data fiduciaries”. Das revidierte schweizerische DSG ist der DSGVO nahe genug, um im selben Programm gef\u00fchrt zu werden, mit eigenen Nuancen bei Registrierung und Meldung.<\/p>\n Die strategische Schlussfolgerung f\u00fcr einen CTO lautet: Globale Datenschutzarchitektur sollte modular sein \u2013 ein gemeinsames Datenverzeichnis, eine gemeinsame Rechte-Engine und eine gemeinsame Sicherheitsbasis, mit jurisdiktionsspezifischen Entscheidungsschichten f\u00fcr Rechtsgrundlage, Einwilligung, \u00dcbermittlung und L\u00f6schung. Der Versuch einer einzigen globalen Richtlinie f\u00fchrt entweder zu teurer \u00dcbererf\u00fcllung oder zu teurer Untererf\u00fcllung.<\/p>\n Vergleich \u00fcber Jurisdiktionen<\/h3>\n\n\n\n| Dimension<\/th>\n | EU-DSGVO<\/th>\n | UK GDPR<\/th>\n | CCPA\/CPRA (Kalifornien)<\/th>\n | LGPD (Brasilien)<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Grundmodell<\/td>\n | Rechtebasiert, rechenschaftsgetrieben<\/td>\n | Weitgehend mit EU-DSGVO abgestimmt<\/td>\n | Verbraucherrechte und Opt-out-Modell<\/td>\n | Rechtebasiert, DSGVO-inspiriert<\/td>\n<\/tr>\n | \n| Erfasster Kreis<\/td>\n | Jede Organisation, die Daten von EU-Betroffenen verarbeitet, auch ausserhalb der EU<\/td>\n | Verarbeitung durch britische Verantwortliche und Auftragsverarbeiter<\/td>\n | Gewinnorientierte Unternehmen mit Umsatz- oder Datenschwellen<\/td>\n | Verarbeitung in Brasilien oder von in Brasilien erhobenen Daten<\/td>\n<\/tr>\n | \n| Rechtsgrundlagen<\/td>\n | Sechs Grundlagen nach Art. 6, plus Art. 9 f\u00fcr besondere Kategorien<\/td>\n | Sechs Grundlagen, eng an Art. 6 angelehnt<\/td>\n | Kein allgemeiner Rechtsgrundlagenrahmen; Information und Opt-out<\/td>\n | Zehn Rechtsgrundlagen inkl. Kreditschutz und berechtigtes Interesse<\/td>\n<\/tr>\n | \n| Einwilligungsmodell<\/td>\n | Opt-in, freiwillig, spezifisch, widerrufbar<\/td>\n | Opt-in, \u00e4hnlicher Standard<\/td>\n | Opt-out f\u00fcr Verkauf und Weitergabe; Opt-in f\u00fcr Daten Minderj\u00e4hriger<\/td>\n | Opt-in mit besonderen Anforderungen f\u00fcr sensible Daten<\/td>\n<\/tr>\n | \n| Sensible Daten<\/td>\n | Besondere Kategorien nach Art. 9 mit Verbot und Ausnahmen<\/td>\n | Gleiche Struktur wie EU-DSGVO<\/td>\n | \u201eSensitive personal information” mit Recht auf Nutzungseinschr\u00e4nkung<\/td>\n | Sensible Daten mit strengeren Grundlagen<\/td>\n<\/tr>\n | \n| DSB-Pflicht<\/td>\n | Verpflichtend in drei definierten Situationen<\/td>\n | \u00c4hnliche Ausl\u00f6ser<\/td>\n | Kein DSB; keine \u00e4quivalente Rolle<\/td>\n | Datenschutzbeauftragter in definierten F\u00e4llen erforderlich<\/td>\n<\/tr>\n | \n| Meldung von Verletzungen<\/td>\n | 72 Stunden an die Aufsichtsbeh\u00f6rde; Betroffene bei hohem Risiko<\/td>\n | 72 Stunden an das ICO; Betroffene bei hohem Risiko<\/td>\n | Keine allgemeine Meldepflicht; Landesgesetze gelten<\/td>\n | Angemessener Zeitraum an ANPD und Betroffene<\/td>\n<\/tr>\n | \n| Maximale Sanktion<\/td>\n | 20 Mio. \u20ac oder 4 % des weltweiten Jahresumsatzes, je nachdem was h\u00f6her ist<\/td>\n | 17,5 Mio. \u00a3 oder 4 % des weltweiten Umsatzes<\/td>\n | 2.500 USD je Verstoss, 7.500 USD f\u00fcr Daten Minderj\u00e4hriger<\/td>\n | 2 % des brasilianischen Umsatzes, begrenzt auf 50 Mio. R$ je Verstoss<\/td>\n<\/tr>\n | \n| Aufsichtsbeh\u00f6rde<\/td>\n | Nationale Aufsichtsbeh\u00f6rden plus EDSA<\/td>\n | Information Commissioner’s Office<\/td>\n | California Privacy Protection Agency und Attorney General<\/td>\n | ANPD<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWie setzen Sie ein DSGVO-Compliance-Programm Schritt f\u00fcr Schritt um?<\/h2>\nDSGVO-Programme scheitern aus vorhersehbaren Gr\u00fcnden: 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.<\/p>\n Phase 1 \u2013 Erfassen und bewerten (Tage 0\u201390)<\/h3>\nDie erste Phase beantwortet drei Fragen: welche personenbezogenen Daten existieren, wohin sie fliessen und welche Risiken am h\u00f6chsten sind. Ohne diese Antworten l\u00e4sst sich nichts anderes verl\u00e4sslich sequenzieren.<\/p>\n \n- Anwendungsbereich bestimmen.<\/strong> Kl\u00e4ren Sie, ob Artikel 3 Absatz 1, Artikel 3 Absatz 2 oder beide greifen, und identifizieren Sie die federf\u00fchrende Aufsichtsbeh\u00f6rde bei grenz\u00fcberschreitender Verarbeitung.<\/li>\n
- Rollen zuordnen.<\/strong> Bestimmen Sie Status als Verantwortlicher, gemeinsam Verantwortlicher und Auftragsverarbeiter je Datenfluss \u2013 nicht je Rechtstr\u00e4ger.<\/li>\n
- Datenerhebung und Inventar.<\/strong> Kombinieren Sie automatisierte Discovery-Tools mit strukturierten Interviews der Systemeigent\u00fcmer. Erfassen Sie Produktivsysteme, Data Warehouses, Logs, Backups, SaaS-Anwendungen, Tabellenkalkulationen, Support-Tools und Schatten-IT. Erfassen Sie Datenkategorie, Zweck, Rechtsgrundlage, L\u00f6schfrist, Empf\u00e4nger und \u00dcbermittlungen.<\/li>\n
- Gap-Analyse.<\/strong> Vergleichen Sie den Ist-Zustand mit den sieben Grunds\u00e4tzen und den zentralen Pflichten und bewerten Sie jede L\u00fccke nach Wahrscheinlichkeit und Auswirkung auf Betroffene.<\/li>\n
- Inventar hoher Risiken.<\/strong> Identifizieren Sie Verarbeitungen, die voraussichtlich eine DPIA erfordern, und solche, die eine vorherige Konsultation verlangen.<\/li>\n
- Governance aufsetzen.<\/strong> Benennen Sie einen Executive Sponsor, eine Programmleitung, Systemeigent\u00fcmer und eine DSB-Entscheidung mit dokumentierter Begr\u00fcndung.<\/li>\n<\/ul>\n
Phase 2 \u2013 Beheben und dokumentieren (Tage 90\u2013180)<\/h3>\nDie zweite Phase verwandelt Befunde in Kontrollen und erzeugt die Rechenschaftsnachweise, deren Fehlen Phase 1 aufgedeckt hat.<\/p>\n \n- Verzeichnis nach Artikel 30 vervollst\u00e4ndigen<\/strong> und unter Change Control stellen, damit neue Verarbeitungen vor dem Go-live eingetragen werden.<\/li>\n
- Risikoreiche L\u00fccken zuerst schliessen.<\/strong> Priorisieren Sie besondere Kategorien, umfangreiche \u00dcberwachung, grenz\u00fcberschreitende \u00dcbermittlungen und jede Verarbeitung mit offener DPIA.<\/li>\n
- L\u00f6schfristen durchsetzen.<\/strong> \u00dcberf\u00fchren Sie den L\u00f6schplan in automatisierte L\u00f6sch-, Archivierungs- und Backup-Ablaufjobs und verifizieren Sie deren Funktion.<\/li>\n
- Rechteprozess neu aufbauen.<\/strong> Ver\u00f6ffentlichen Sie einen Eingangskanal, definieren Sie den Suchumfang je System, bauen Sie Abrufworkflows und beginnen Sie, Antr\u00e4ge und Abschlusszeiten zu protokollieren.<\/li>\n
- Vertr\u00e4ge korrigieren.<\/strong> Bringen Sie Auftragsverarbeitungsvertr\u00e4ge auf den Stand von Artikel 28, identifizieren Sie Unterauftragsverarbeiter und schliessen Sie L\u00fccken bei \u00dcbermittlungsgarantien.<\/li>\n
- Sicherheit h\u00e4rten.<\/strong> Setzen Sie die in der Gap-Analyse identifizierten Massnahmen nach Artikel 32 um, einschliesslich Verschl\u00fcsselung, Zugriffskontrolle, Logging, Monitoring und Schwachstellenmanagement.<\/li>\n
- Melde-Runbook erstellen.<\/strong> Definieren Sie Erkennung, Triage, Schweregradklassifizierung, Eskalation, rechtliche Pr\u00fcfung, Meldungsvorlagen und einen \u00dcbungsplan.<\/li>\n
- Schulen.<\/strong> Rollenbasierte Schulungen f\u00fcr Engineering, Marketing, HR, Vertrieb und Support mit aufbewahrten Abschlussnachweisen.<\/li>\n<\/ul>\n
Phase 3 \u2013 Betreiben und nachweisen (Tage 180\u2013365, danach Regelbetrieb)<\/h3>\nDie letzte Phase macht aus Compliance Routine. Sie entscheidet, ob das Programm den ersten F\u00fchrungswechsel oder den ersten grossen Produktlaunch \u00fcbersteht.<\/p>\n \n- Datenschutz in der Lieferung verankern.<\/strong> Datenschutzanforderungen in die Definition of Done aufnehmen und DPIA-Screening in Intake- und Change-Advisory-Prozesse integrieren.<\/li>\n
- Monitoring-Zyklus fahren.<\/strong> Monatliche Kennzahlen zu Auskunftsvolumen und Abschlusszeiten, Verletzungsereignissen, Einwilligungsraten, Erfolg von L\u00f6schjobs, Schulungsabschl\u00fcssen und Anbieterpr\u00fcfungen.<\/li>\n
- Testen.<\/strong> J\u00e4hrliche Penetrationstests, periodische Restore-Tests und mindestens j\u00e4hrliche Tabletop-\u00dcbungen zur Verletzungsreaktion mit dokumentierten Erkenntnissen.<\/li>\n
- Auditieren.<\/strong> Interne Revision oder externe Bewertung gegen die sieben Grunds\u00e4tze und die zentralen Pflichten, mit Nachverfolgung der Befunde bis zum Abschluss.<\/li>\n
- Anbieter \u00fcberpr\u00fcfen.<\/strong> Neubewertung der Sicherheitslage von Auftragsverarbeitern, der Unterauftragsketten und \u00dcbermittlungsarrangements in definierten Zyklen und immer, wenn ein Anbieter sein Leistungsbild wesentlich \u00e4ndert.<\/li>\n
- Nach oben berichten.<\/strong> Ein kurzer Bericht an die Gesch\u00e4ftsleitung zu Compliance-Stand, Restrisiken und erforderlichen Entscheidungen.<\/li>\n<\/ul>\n
Wenn Ihr Unternehmen dieses Programm parallel zur Produktlieferung betreiben muss \u2013 und das m\u00fcssen die meisten \u2013, arbeitet das Consulting-Team von Greyson<\/a> mit der IT-Leitung daran, Bestandsaufnahme, Behebung und Betriebsroutinen zu sequenzieren, ohne die Roadmap zu blockieren.<\/p>\nZw\u00f6lf-Monats-Fahrplan f\u00fcr DSGVO-Compliance<\/h3>\n \n\n\n| Phase<\/th>\n | Zeitraum<\/th>\n | Zentrale Aktivit\u00e4ten<\/th>\n | Ergebnisse<\/th>\n | Verantwortlich<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Erfassen und bewerten<\/td>\n | Tage 0\u201390<\/td>\n | Anwendungsbereich und Rollen bestimmen; Datenerhebung; Gap-Analyse; Inventar hoher Risiken; Governance aufsetzen<\/td>\n | Dateninventar und Flussdiagramm; Rollenzuordnung; L\u00fcckenregister; DPIA-Pipeline; Programmcharta<\/td>\n | Programmleitung mit Systemeigent\u00fcmern<\/td>\n<\/tr>\n | \n| Beheben und dokumentieren<\/td>\n | Tage 90\u2013180<\/td>\n | Verzeichnis nach Art. 30; Durchsetzung von L\u00f6schfristen; Aufbau des Rechteprozesses; Vertragssanierung; Sicherheitsh\u00e4rtung; Melde-Runbook; Schulungen<\/td>\n | Verarbeitungsverzeichnis; L\u00f6schpl\u00e4ne im Code; Auskunfts-Workflow; konforme Auftragsverarbeitungsvertr\u00e4ge; Incident-Runbook; Schulungsnachweise<\/td>\n | Datenschutzorganisation mit Engineering, Beschaffung und HR<\/td>\n<\/tr>\n | \n| Betreiben und nachweisen<\/td>\n | Tage 180\u2013365<\/td>\n | Datenschutz in der Definition of Done; Monitoring-Kennzahlen; Tests; interne Revision; Anbieterneubewertung; Berichte an die Leitung<\/td>\n | Monitoring-Dashboard; Testberichte; Audit-Befundlog; Anbieterpr\u00fcfprotokolle; Leitungsberichte<\/td>\n | DSB mit CISO und Engineering-Verantwortlichen<\/td>\n<\/tr>\n | \n| Regelbetrieb<\/td>\n | Ab Jahr 2<\/td>\n | Laufende Aufnahme neuer Verarbeitungen; j\u00e4hrliche DPIA-Aktualisierung; Beobachtung regulatorischer \u00c4nderungen; Konvergenz mit dem AI Act<\/td>\n | Aktualisierte Verzeichnisse; aktualisierte DPIAs; regulatorische Kurzberichte<\/td>\n | Datenschutzorganisation mit Executive Sponsor<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWie ver\u00e4ndert DSGVO-Compliance Softwareentwicklung und Testing?<\/h2>\nDies ist der Bereich, in dem DSGVO-Compliance am h\u00e4ufigsten als Rechtsfrage missverstanden und am h\u00e4ufigsten als Engineering-Aufgabe nicht erf\u00fcllt wird. Die Pflichten aus Artikel 25 und 32 sind Design- und Testpflichten. Sie lassen sich nicht durch ein nach dem Release geschriebenes Richtliniendokument erf\u00fcllen.<\/p>\n Datenschutz durch Technikgestaltung \u00fcber den Softwareentwicklungslebenszyklus<\/h3>\nDatenschutz durch Technikgestaltung funktioniert nur, wenn Datenschutzanforderungen sich wie jede andere nichtfunktionale Anforderung verhalten: fr\u00fch erfasst, testbar gemacht, bis zur Erf\u00fcllung verfolgt und vor dem Release verifiziert.<\/p>\n Anforderungsphase.<\/strong> Jedes Feature, das personenbezogene Daten ber\u00fchrt, sollte Zweck, Rechtsgrundlage, Datenkategorien, L\u00f6schfrist, Empf\u00e4nger und anwendbare Betroffenenrechte deklarieren. Eine Screening-Frage im Intake \u2013 verarbeitet dieses Vorhaben personenbezogene Daten, und erf\u00fcllt es ein DPIA-Kriterium? \u2013 erfasst die F\u00e4lle, die vor der Architekturfestlegung bewertet werden m\u00fcssen.<\/p>\nDesignphase.<\/strong> Datenminimierung wird auf Schema- und API-Ebene angewendet, nicht nur im Formular. Pseudonymisierung, zweckgebundener Zugriff, Verschl\u00fcsselung und Schl\u00fcsselmanagement werden eingeplant. Standardeinstellungen sind datenschutzfreundlich und erf\u00fcllen die Voreinstellungsklausel des Artikels 25.<\/p>\nBuild-Phase.<\/strong> Einwilligungsstatus, Zweck-Tags und L\u00f6schmetadaten werden als erstklassige Datenattribute modelliert statt nachtr\u00e4glich angeflanscht. Logging wird standardm\u00e4ssig so konfiguriert, dass personenbezogene Daten ausgeschlossen oder redigiert werden, denn Log-Speicher geh\u00f6ren zu den am h\u00e4ufigsten \u00fcbersehenen Datensammlungen personenbezogener Daten.<\/p>\nTestphase.<\/strong> Datenschutzanforderungen werden wie funktionale Anforderungen getestet: dass L\u00f6schen tats\u00e4chlich \u00fcber alle Speicher einschliesslich abgeleiteter Datens\u00e4tze und Suchindizes l\u00f6scht, dass L\u00f6schjobs ausl\u00f6sen, dass ein Widerruf der Einwilligung die Verarbeitung downstream unterbindet, dass Zugriffskontrollen nach Zweck einschr\u00e4nken, dass ein Export einen vollst\u00e4ndigen und maschinenlesbaren Datensatz erzeugt und dass automatisierte Entscheidungen eine Erkl\u00e4rung liefern und an menschliche Pr\u00fcfung weiterleiten.<\/p>\nRelease-Phase.<\/strong> Datenschutzpr\u00fcfungen werden Teil der Definition of Done. Ein Release, das die Verarbeitung personenbezogener Daten \u00e4ndert, ohne den Registereintrag zu aktualisieren oder das DPIA-Screening abzuschliessen, sollte das Gate nicht passieren.<\/p>\nBetriebsphase.<\/strong> Durchsetzung von L\u00f6schfristen, Zugriffspr\u00fcfungen, Monitoring und periodische Neubewertung von DPIAs, wenn sich die Verarbeitung weiterentwickelt. Artikel 32 Absatz 1 Buchstabe d verlangt ausdr\u00fccklich die regelm\u00e4ssige Pr\u00fcfung der Wirksamkeit von Sicherheitsmassnahmen, was kontinuierliches Testen zu einer rechtlichen Erwartung macht \u2013 nicht zu einer Engineering-Pr\u00e4ferenz.<\/p>\nTestdatenmanagement \u2013 Pseudonymisierung versus Anonymisierung<\/h3>\nTesting 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\u00fcrfen nicht in Umgebungen mit schw\u00e4cheren Kontrollen kopiert werden. Die DSGVO bietet zwei Wege, und sie sind nicht austauschbar.<\/p>\n Anonymisierung<\/strong> entfernt die Identifizierbarkeit so weit, dass die Daten vollst\u00e4ndig aus dem Anwendungsbereich der DSGVO fallen. Daf\u00fcr m\u00fcssen die Daten Singling-out (Isolierung einer Person), Verkettbarkeit (Verbindung von Datens\u00e4tzen \u00fcber dieselbe Person) und Inferenz (Ableitung von Merkmalen aus anderen Daten) widerstehen, wobei alle wahrscheinlich eingesetzten Mittel zu ber\u00fccksichtigen sind. Echte Anonymisierung ist schwierig und bei vielen Unternehmensdatens\u00e4tzen \u2013 besonders solchen mit reichhaltigen Quasi-Identifikatoren wie Postleitzahl, Geburtsdatum und Transaktionsmustern \u2013 nicht erreichbar, ohne den analytischen Nutzen zu zerst\u00f6ren.<\/p>\nPseudonymisierung<\/strong> ersetzt direkte Identifikatoren durch k\u00fcnstliche, w\u00e4hrend eine Re-Identifizierung \u00fcber separat gehaltenes Schl\u00fcsselmaterial m\u00f6glich bleibt. Pseudonymisierte Daten bleiben personenbezogene Daten und im Anwendungsbereich, aber Artikel 32 erkennt Pseudonymisierung ausdr\u00fccklich als Sicherheitsmassnahme an und Artikel 25 als Designtechnik. F\u00fcr die meisten Testumgebungen ist Pseudonymisierung mit strikter Schl\u00fcsseltrennung die praktikable und verteidigbare Wahl: Sie erh\u00e4lt referenzielle Integrit\u00e4t und Datenrealismus, entfernt direkte Identifizierbarkeit und erf\u00fcllt eine technische Massnahme nach Artikel 32.<\/p>\nUnabh\u00e4ngig vom Weg sind mehrere Kontrollen nicht verhandelbar. Testumgebungen d\u00fcrfen nicht mit Produktivzugangsdaten erreichbar sein. Daten m\u00fcssen am Punkt der Extraktion maskiert werden, nicht in der Zielumgebung. Referenzielle Integrit\u00e4t muss erhalten bleiben, damit Tests aussagekr\u00e4ftig sind \u2013 derselbe synthetische Identifikator muss \u00fcber verbundene Tabellen konsistent abbilden. Freitextfelder, Anh\u00e4nge, Notizen und Dokumentmetadaten m\u00fcssen abgedeckt sein, denn dort \u00fcberleben personenbezogene Daten die Maskierung am h\u00e4ufigsten. Und der Maskierungsprozess selbst muss getestet werden: die Stichprobenpr\u00fcfung maskierter Datens\u00e4tze auf Restidentifikatoren ist eine legitime und erwartete Kontrolle.<\/p>\n Cloud, Anbieter und Assurance bei Auftragsverarbeitern<\/h3>\nDer Wechsel in die Cloud \u00fcbertr\u00e4gt keine Verantwortung. Nach Artikel 28 bleibt der Verantwortliche daf\u00fcr zust\u00e4ndig, einen Auftragsverarbeiter mit hinreichenden Garantien zu w\u00e4hlen und sicherzustellen, dass der Vertrag die erforderlichen Bedingungen abdeckt. Speziell f\u00fcr Cloud verdienen vier Bereiche Aufmerksamkeit.<\/p>\n Datenresidenz und \u00dcbermittlungsketten.<\/strong> Ein Cloud-Dienst kann Daten \u00fcber Regionen replizieren und Unterauftragsverarbeiter in mehreren Jurisdiktionen einsetzen. Das \u00dcbermittlungsmapping muss dem tats\u00e4chlichen Datenpfad folgen, einschliesslich Support-Zugriffen aus Drittl\u00e4ndern, die selbst eine \u00dcbermittlung darstellen.<\/p>\nTransparenz bei Unterauftragsverarbeitern.<\/strong> Artikel 28 Absatz 2 verlangt eine Genehmigung f\u00fcr Unterauftragsverarbeiter. In der Praxis bedeutet das, ver\u00f6ffentlichte Listen zu \u00fcberwachen, einen Mechanismus zum Widerspruch gegen \u00c4nderungen zu haben und einen dokumentierten Prozess f\u00fcr den Fall, dass Sie tats\u00e4chlich widersprechen.<\/p>\nL\u00f6schung und Exit.<\/strong> Artikel 28 Absatz 3 Buchstabe g verlangt L\u00f6schung oder R\u00fcckgabe der Daten am Ende der Beauftragung. Pr\u00fcfen Sie in Multi-Tenant- und backup-lastigen Architekturen, was \u201eL\u00f6schung” konkret bedeutet, welche Fristen gelten und ob Restkopien in Backups oder Analytics-Speichern verbleiben.<\/p>\nFeature-Creep und Sekund\u00e4rnutzung.<\/strong> Viele Cloud-Plattformen bieten heute KI-gest\u00fctzte Funktionen, die Kundendaten verarbeiten k\u00f6nnen. Jede solche Funktion muss bewertet werden: Werden Daten f\u00fcr Modelltraining wiederverwendet, und wenn ja, auf welcher Rechtsgrundlage und mit welchem vertraglichen Schutz?<\/p>\nDatenschutzkontrollen im Entwicklungslebenszyklus<\/h3>\n\n\n\n| SDLC-Phase<\/th>\n | Datenschutzziel<\/th>\n | Konkrete Kontrollen<\/th>\n | Erzeugter Nachweis<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Anforderungen<\/td>\n | Verarbeitung personenbezogener Daten identifizieren und begrenzen<\/td>\n | Datenschutz-Screening im Intake; Deklaration von Zweck und Rechtsgrundlage; DPIA-Ausl\u00f6serpr\u00fcfung; Klassifizierung der Datenkategorien<\/td>\n | Ausgef\u00fcllte Screening-Protokolle; DPIA-Entscheidungen<\/td>\n<\/tr>\n | \n| Design<\/td>\n | Datenschutz durch Technikgestaltung und Voreinstellungen anwenden<\/td>\n | Minimierung auf Schemaebene; Pseudonymisierungsdesign; Verschl\u00fcsselungs- und Schl\u00fcsselmanagementdesign; zweckgebundenes Zugriffsmodell; datenschutzfreundliche Standards<\/td>\n | Designdokumente mit Datenschutzabschnitt; Architektur-Review-Protokolle<\/td>\n<\/tr>\n | \n| Build<\/td>\n | Datenschutzattribute als erstklassig im Datenmodell verankern<\/td>\n | Einwilligungsstatus als modelliertes Attribut; Zweck-Tags an Datenfl\u00fcssen; L\u00f6schmetadaten; Log-Redaktion standardm\u00e4ssig; Secrets Management<\/td>\n | Code-Review-Protokolle; Datenmodell-Dokumentation<\/td>\n<\/tr>\n | \n| Test<\/td>\n | Datenschutzverhalten pr\u00fcfen, nicht nur Funktionsverhalten<\/td>\n | L\u00f6schverifikation \u00fcber alle Speicher; Tests von L\u00f6schjobs; Tests der Weitergabe von Einwilligungswiderrufen; Zugriffs- und Zwecktests; Vollst\u00e4ndigkeitstests f\u00fcr Auskunftsexporte; Stichproben auf Restidentifikatoren in maskierten Daten<\/td>\n | Als Art.-32-Nachweis aufbewahrte Testberichte; Maskierungsvalidierungsberichte<\/td>\n<\/tr>\n | \n| Release<\/td>\n | Undokumentierte Verarbeitung am Ausliefern hindern<\/td>\n | Datenschutzpr\u00fcfungen in der Definition of Done; Register-Update-Gate; DPIA-Abschluss-Gate; Release-Freigabe<\/td>\n | Release-Checklisten; aktualisierte Verarbeitungsverzeichnisse<\/td>\n<\/tr>\n | \n| Betrieb<\/td>\n | Wirksamkeit \u00fcber die Zeit erhalten<\/td>\n | Monitoring von L\u00f6schjobs; periodische Zugriffspr\u00fcfungen; DPIA-Aktualisierungsausl\u00f6ser; \u00dcbungen zur Vorfallreaktion; Schwachstellen- und Penetrationstests<\/td>\n | Monitoring-Berichte; Review-Protokolle; Test- und \u00dcbungsnachweise<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWas sind die h\u00e4ufigsten DSGVO-Fehlannahmen?<\/h2>\nDie meisten ins Stocken geratenen Programme werden nicht durch Komplexit\u00e4t blockiert. Sie werden durch eine kleine Gruppe hartn\u00e4ckiger \u00dcberzeugungen blockiert, die Teams dazu bringen, Aufwand an der falschen Stelle zu investieren.<\/p>\n Neun Mythen, die Compliance-Programme ausbremsen<\/h3>\n\u201eWir sind nicht in der EU, also gilt die DSGVO f\u00fcr uns nicht.”<\/strong> Artikel 3 Absatz 2 wendet die Verordnung auf Organisationen an, die Personen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten beobachten \u2013 ohne Erfordernis einer Niederlassung.<\/p>\n\u201eUnsere Daten sind anonymisiert, also fallen sie nicht darunter.”<\/strong> Nur irreversibel anonymisierte Daten sind aus dem Anwendungsbereich heraus. Pseudonymisierte Daten und Daten, die durch Kombination mit anderen Datens\u00e4tzen re-identifizierbar sind, bleiben personenbezogen.<\/p>\n\u201eEinwilligung ist die einzige Rechtsgrundlage, die wir brauchen.”<\/strong> Es gibt f\u00fcnf weitere Grundlagen. Einwilligung dort zu nutzen, wo Vertrag oder rechtliche Verpflichtung greift, schafft vermeidbares Risiko, weil Einwilligung jederzeit widerrufbar ist.<\/p>\n\u201eWir haben den Datensatz gel\u00f6scht, also sind wir compliant.”<\/strong> L\u00f6schung muss Backups, abgeleitete Datens\u00e4tze, Analytics-Speicher, Suchindizes, Caches und Auftragsverarbeiter erreichen. L\u00f6schung, die an der Prim\u00e4rdatenbank endet, ist unvollst\u00e4ndig.<\/p>\n\u201eDie DPIA ist eine Formalit\u00e4t f\u00fcr die Rechtsabteilung.”<\/strong> Eine DPIA ist eine Risikobewertung, die Designentscheidungen informiert, vor Beginn der Verarbeitung erstellt werden muss, die Stellungnahme des DSB festh\u00e4lt und Restrisiken auf der richtigen Ebene akzeptiert.<\/p>\n\u201eUnser Cloud-Anbieter \u00fcbernimmt die DSGVO f\u00fcr uns.”<\/strong> Auftragsverarbeiter liefern Garantien und vertragliche Zusagen; die Rechenschaftspflicht nach Artikel 5 Absatz 2 und Artikel 24 bleibt beim Verantwortlichen, einschliesslich f\u00fcr \u00dcbermittlungen und Unterauftragsverarbeiter.<\/p>\n\u201eWir haben eine Datenschutzerkl\u00e4rung auf der Website, also sind wir abgedeckt.”<\/strong> Ein Datenschutzhinweis erf\u00fcllt eine Transparenzpflicht. F\u00fcr Durchsetzung von L\u00f6schfristen, Erf\u00fcllung von Rechten, Sicherheitstests oder Meldungsbereitschaft leistet er nichts.<\/p>\n\u201eCompliance ist ein einmaliges Projekt.”<\/strong> Jedes neue System, jeder Anbieter, jede Integration, jeder Marketingkanal und jedes KI-Feature ver\u00e4ndert die Verarbeitungslandschaft. Compliance ohne Change-Control-Intake verf\u00e4llt innerhalb eines Quartals.<\/p>\n\u201eDSGVO und AI Act sind getrennte Probleme.”<\/strong> KI-Systeme, die personenbezogene Daten verarbeiten, m\u00fcssen beide erf\u00fcllen. Datenminimierung, Zweckbindung und Rechtsgrundlagenpr\u00fcfung gelten f\u00fcr Trainingsdaten, und Artikel 22 beschr\u00e4nkt automatisierte Entscheidungen mit erheblicher Wirkung auf Personen.<\/p>\nMythos versus Realit\u00e4t<\/h3>\n\n\n\n| Fehlannahme<\/th>\n | Realit\u00e4t<\/th>\n | Massgebliche Bestimmung<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Die DSGVO gilt nur f\u00fcr Organisationen mit Sitz in der EU<\/td>\n | Sie gilt f\u00fcr Nicht-EU-Organisationen, die Personen in der EU Waren oder Dienstleistungen anbieten oder sie beobachten<\/td>\n | Art. 3 Abs. 2; Erw\u00e4gungsgr\u00fcnde 23\u201324<\/td>\n<\/tr>\n | \n| Pseudonymisierte Daten fallen nicht unter die DSGVO<\/td>\n | Pseudonymisierte Daten bleiben personenbezogen; nur irreversible Anonymisierung nimmt sie heraus<\/td>\n | Art. 4 Abs. 1, Abs. 5; Erw\u00e4gungsgrund 26<\/td>\n<\/tr>\n | \n| Einwilligung ist immer die sicherste Rechtsgrundlage<\/td>\n | Einwilligung ist fragil und widerrufbar; die richtige Grundlage h\u00e4ngt vom Zweck ab<\/td>\n | Art. 6 Abs. 1; Art. 7<\/td>\n<\/tr>\n | \n| Den Prim\u00e4rdatensatz zu l\u00f6schen gen\u00fcgt<\/td>\n | L\u00f6schung muss Backups, abgeleitete Daten, Analytics, Indizes und Auftragsverarbeiter erfassen<\/td>\n | Art. 17; Art. 19<\/td>\n<\/tr>\n | \n| Eine DPIA ist ein Rechtsdokument<\/td>\n | Eine DPIA ist eine Risikobewertung, die risikoreicher Verarbeitung vorausgehen und das Design informieren muss<\/td>\n | Art. 35; Art. 36<\/td>\n<\/tr>\n | \n| Der Cloud-Anbieter ist f\u00fcr Compliance verantwortlich<\/td>\n | Die Rechenschaftspflicht bleibt beim Verantwortlichen; Auftragsverarbeiter liefern Garantien und Unterst\u00fctzung<\/td>\n | Art. 5 Abs. 2, 24, 28<\/td>\n<\/tr>\n | \n| Eine ver\u00f6ffentlichte Datenschutzerkl\u00e4rung bedeutet Compliance<\/td>\n | Transparenz ist eine von vielen Pflichten; operative Kontrollen sind ebenfalls erforderlich<\/td>\n | Art. 5, 12\u201314, 24, 30, 32<\/td>\n<\/tr>\n | \n| Compliance ist ein einmaliges Projekt<\/td>\n | Sie ist ein aufrechtzuerhaltender Zustand, der jedes neue System, jeden Anbieter und jeden Datenfluss aufnehmen muss<\/td>\n | Art. 5 Abs. 2, 24, 32 Abs. 1 lit. d<\/td>\n<\/tr>\n | \n| Eine Verletzung muss immer innerhalb von 72 Stunden gemeldet werden<\/td>\n | Meldung ist bei Risiko erforderlich; besteht kein Risiko, muss die Entscheidung dennoch dokumentiert werden<\/td>\n | Art. 33, 34<\/td>\n<\/tr>\n | \n| Jede Organisation braucht einen DSB<\/td>\n | Ein DSB ist in drei definierten Situationen Pflicht; andere k\u00f6nnen freiwillig einen bestellen<\/td>\n | Art. 37 Abs. 1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWas kostet die Nichteinhaltung?<\/h2>\nBussgelder dominieren die Diskussion, sind aber selten die gr\u00f6ssten Kosten. Sowohl die gesetzliche Struktur als auch die operativen Folgen zu verstehen hilft, eine Wirtschaftlichkeitsrechnung zu bauen, die die Budgetpr\u00fcfung \u00fcbersteht.<\/p>\n Die zweistufige Bussgeldstruktur nach Artikel 83<\/h3>\nArtikel 83 sieht zwei Stufen von Verwaltungsbussgeldern vor. Die niedrigere Stufe erfasst Pflichten einschliesslich der allgemeinen Grunds\u00e4tze, der Pflichten von Verantwortlichen und Auftragsverarbeitern, der Zertifizierungsstellen und der Pflichten von \u00dcberwachungsstellen. Sie erlaubt Bussgelder bis zu | | | | | | | | |