Geschäftssysteme so gestalten, dass sie Datenschutzanforderungen erfüllen

Der Personal Data Protection Act B.E. 2562 (2019) gilt für Organisationen, die personenbezogene Daten von Personen in Thailand erheben, nutzen oder offenlegen. Er unterscheidet den Verantwortlichen, der über Zweck und Mittel der Verarbeitung entscheidet, vom Auftragsverarbeiter, der im Auftrag des Verantwortlichen verarbeitet; die Aufsicht liegt beim Personal Data Protection Committee (PDPC). Das Gesetz regelt Rechtsgrundlagen der Verarbeitung, Rechte betroffener Personen, Sicherheitspflichten, Dokumentationspflichten und eine Meldepflicht bei Datenschutzverletzungen.

Dieser Leitfaden dient der Information und ist keine Rechtsberatung. Das Gesetz, seine Durchführungsbestimmungen und die Leitlinien des PDPC ändern sich im Laufe der Zeit; Ihr Datenschutzbeauftragter oder Ihre Rechtsberatung sollte bestätigen, wie sie auf Ihr Unternehmen anzuwenden sind. Im Folgenden geht es um die technische Sicht: Wo das Gesetz verlangt, dass das Unternehmen etwas leisten kann, beschreibt dieser Leitfaden, was das System dafür benötigt.

Ist die Einwilligung die Grundlage, muss das System nachweisen können, dass eine bestimmte Person einer bestimmten Nutzung in einem bestimmten Wortlaut zu einem bestimmten Zeitpunkt zugestimmt hat, und auf welchem Weg. Speichern Sie einen Einwilligungsnachweis mit der Kennung der betroffenen Person, dem Zweck, der Version des Hinweis- oder Einwilligungstexts, den sie gesehen hat, dem Zeitstempel, dem Kanal (Webformular, App, eingescanntes Papier, Anruf) und etwaigen Belegen wie der Formular-ID. Bewahren Sie jede Version des Einwilligungstexts auf; ein Nachweis, der auf einen inzwischen umformulierten Text verweist, beweist nichts.

Der Widerruf muss so einfach sein wie die Erteilung der Einwilligung und in jedem System wirksam werden, das darauf aufgebaut hat. Gestalten Sie die Einwilligung als zentralen Status, den nachgelagerte Systeme (eine Marketingplattform, ein Newsletter-Versand, eine Analyse-Pipeline) im Moment der Nutzung abfragen, statt als einmal kopiertes und dann vergessenes Kennzeichen. Unser eigener Website-Newsletter ist ein kleines Beispiel für dieses Muster: Double-Opt-in per E-Mail, ein Abmeldelink in jeder Nachricht und eine Sperrliste, die vor dem Versand angewendet wird.

Die Einwilligung ist nicht für alles die passende Grundlage. Die Verarbeitung von Mitarbeiterdaten für die Lohnabrechnung oder von Kundendaten zur Lieferung eines Kaufs beruht auf Vertrag oder rechtlicher Verpflichtung; wer in diesen Fällen um Einwilligung bittet, schafft ein Widerrufsrecht, das das Unternehmen nicht einlösen kann. Wird die Grundlage korrekt gewählt, gibt es weniger Einwilligungsnachweise, und diese sind aussagekräftiger.

Das Gesetz verlangt angemessene Sicherheitsmaßnahmen. Systemseitig beginnt das mit dem Prinzip der minimalen Rechte: rollenbasierter Zugriff, bei dem jede Rolle die Felder sieht, die ihre Arbeit erfordert, und nicht mehr. Ein Modell aus Inhaber/Administrator/Mitglied/Betrachter ist eine solide Grundlage für einen Workspace; Geschäftsanwendungen benötigen meist feinere Rollen, damit etwa ein Lagermitarbeiter Lieferadressen sieht, aber keine Ausweisnummern, und ein Support-Mitarbeiter die letzten vier Ziffern einer Karte, aber nie die vollständige Nummer. Maskierung auf Feldebene, angewendet in der API-Schicht, damit kein Client sie umgehen kann, lohnt den Aufwand für personenbezogene und sensible Felder.

Datenminimierung gilt bei der Erhebung und für jede Kopie. Erheben Sie nur die Felder, die ein Zweck erfordert; kopieren Sie keine personenbezogenen Produktionsdaten in Test- und Entwicklungsumgebungen, sondern erzeugen oder anonymisieren Sie Testdaten; beschränken Sie Exporte und Massen-Downloads auf die Rollen, die sie benötigen, und protokollieren Sie jeden einzelnen. Eine starke Authentifizierung schützt all das: Single Sign-On mit dem Identitätsanbieter des Unternehmens, Zwei-Faktor-Authentifizierung, Passkeys, wo unterstützt, und Sitzungszeitlimits, die der Sensibilität der Daten entsprechen.

Auftragsverarbeiter, auf die das Unternehmen angewiesen ist (Hosting, E-Mail, Analyse, KI-Dienste), benötigen Verträge, die sie an dieselben Standards binden, und aus der Architektur sollte klar hervorgehen, welche personenbezogenen Daten an welchen von ihnen fließen.

Personenbezogene Daten dürfen nur so lange aufbewahrt werden, wie es der Zweck erfordert oder ein Gesetz verlangt. Leiten Sie daraus einen Aufbewahrungsplan je Datenkategorie mit Frist und rechtlicher oder geschäftlicher Begründung ab: Buchhaltungsunterlagen für die steuerrechtlich vorgeschriebene Dauer, Bewerberdaten für einen festgelegten Zeitraum nach der Entscheidung, inaktive Kundenkonten nach einer festgelegten Zeit der Inaktivität, Support-Chatverläufe nach einer festgelegten Frist. Automatisieren Sie diesen Plan anschließend. Eine Aufbewahrungsrichtlinie, die davon abhängt, dass jemand einmal im Jahr ein Skript ausführt, ist keine Kontrolle.

Legen Sie fest, wie die Löschung technisch funktioniert. Beim Soft Delete sind Daten unsichtbar, aber weiterhin vorhanden; das ist nur als kurze Übergangsfrist vor der endgültigen Löschung oder Anonymisierung vertretbar. Die Anonymisierung, die Identifikatoren entfernt oder unumkehrbar verändert und dabei Statistiken erhält, ermöglicht es, die Geschäftshistorie zu bewahren, ohne Personenbezug zu behalten. Backups müssen ebenso behandelt werden: Legen Sie fest, wie lange sie bestehen, stellen Sie sicher, dass sie verschlüsselt sind, und sorgen Sie dafür, dass für wiederhergestellte Daten die Löschungen gelten, die nach Erstellung des Backups erfolgt sind.

Betroffene Personen können erfragen, welche Daten das Unternehmen über sie speichert, Kopien und Berichtigungen verlangen, die Löschung beantragen, der Verarbeitung widersprechen oder sie einschränken lassen und ihre Einwilligung widerrufen; der Verantwortliche muss innerhalb der vom Gesetz und den Verordnungen gesetzten Frist handeln. Das System muss es geschulten Mitarbeitern ermöglichen, diese Anfragen ohne Hilfe der Entwicklung zu erfüllen: alle Datensätze einer Person modulübergreifend finden, einen lesbaren Export ihrer personenbezogenen Daten erstellen, ein Feld mit Audit-Eintrag berichtigen und Löschung oder Anonymisierung unter Beachtung verbindlicher Aufbewahrungsregeln ausführen (eine Rechnung kann nicht gelöscht werden, nur weil der Kunde die Löschung verlangt; sie kann mit dokumentierter Rechtsgrundlage aufbewahrt werden).

Führen Sie ein Anfrageprotokoll: wer angefragt hat, wann, wie die Identität geprüft wurde, was unternommen wurde und wann die Anfrage abgeschlossen war. Das Protokoll belegt die Einhaltung der Vorschriften und zeigt zugleich, wo Abläufe zu langsam sind.

Ein Audit-Log hält fest, wer wann was mit welchen Daten getan hat: Anmeldungen, Berechtigungsänderungen, Ansichten und Exporte personenbezogener Daten, Bearbeitungen und Löschungen, Konfigurationsänderungen. Es sollte von der Anwendung im Moment der Aktion geschrieben, getrennt von den Geschäftsdaten mit eingeschränktem Schreibzugriff gespeichert und für einen bewusst festgelegten Zeitraum aufbewahrt werden. Protokolle in derselben Datenbank mit denselben Administratoren bieten keinen Schutz vor Innentätern.

Sorgen Sie dafür, dass die Protokolle nicht nur vorhanden, sondern auch nützlich sind: durchsuchbar nach Person und Datensatz, regelmäßig geprüft und mit Alarmen bei ungewöhnlichen Mustern wie Massenexporten oder Zugriffen außerhalb der Arbeitszeiten. Audit-Logs enthalten selbst personenbezogene Daten und gehören in den Aufbewahrungsplan.

Das Gesetz verpflichtet Verantwortliche, dem PDPC eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden zu melden, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für Rechte und Freiheiten; bei hohem Risiko sind auch die betroffenen Personen zu informieren. 72 Stunden vergehen schnell. Auf Systemseite bedeutet Bereitschaft vor allem Erkennung, also Protokollierung und Monitoring, die unbefugte Zugriffe sichtbar machen, sowie die Fähigkeit, rasch festzustellen, welche Daten über wen in welchem Zeitraum betroffen waren.

Auf organisatorischer Seite braucht es einen schriftlich festgelegten Incident-Prozess: wer zuerst informiert wird, wer das Risiko bewertet, wer die Meldung entwirft, wer mit Kunden spricht, sowie im Voraus vorbereitete Vorlagen in jeder Arbeitssprache des Unternehmens. Führen Sie jährlich eine Planspielübung mit einem realistischen Szenario durch, damit das Runbook nicht erst während einer echten Datenschutzverletzung zum ersten Mal zum Einsatz kommt.