Die ICO-Durchsetzungsmaßnahmen gegen UK-Organisationen stiegen 2024 und 2025 deutlich an, mit Bußgeldern von insgesamt über 12 Millionen Pfund in diesen beiden Jahren für Versäumnisse bei technischen Sicherheitsmaßnahmen. Das Muster in den ICO-Durchsetzungsmitteilungen ist konsistent: Organisationen, die einen Datenschutzverstoß erlitten und nicht nachweisen konnten, dass sie angemessene technische Kontrollen implementiert hatten, wurden am härtesten bestraft. Für Entwickler ist dies ein direktes berufliches Anliegen. Die Entscheidungen, die Sie über Verschlüsselung, Protokollierung, Zugriffskontrolle und Datenspeicherung treffen, sind die technischen Kontrollen, die darüber bestimmen, ob eine Organisation sich vor der ICO verteidigen kann.

Dieser Leitfaden richtet sich an Entwickler und Technikabteilungen, nicht an Rechts- oder Compliance-Abteilungen. Er übersetzt die Anforderungen der UK DSGVO in konkrete technische Entscheidungen: was zu implementieren ist, wie es zu implementieren ist und warum jede Maßnahme existiert.

Kurzfassung

  • UK DSGVO Artikel 32 verlangt „angemessene technische Maßnahmen" proportional zum Risiko. Für die meisten Anwendungen, die personenbezogene Daten verarbeiten, bedeutet dies Verschlüsselung im Ruhezustand und während der Übertragung, Pseudonymisierung wo möglich, Zugriffskontrollen und dokumentierte Fähigkeiten zur Breach-Erkennung.
  • Die häufigsten Entwicklerfehler, die DSGVO-Risiken erzeugen: Protokollierung personenbezogener Daten in Debug-Ausgaben, Soft-Deletion von Datensätzen, die für das Recht auf Löschung tatsächlich gelöscht werden müssten, und das Versäumnis, mit jedem Drittanbieter, der personenbezogene Daten verarbeitet, einen Datenverarbeitungsvertrag abzuschließen.
  • Datensparsamkeit ist eine Designentscheidung auf Feldebene. Wenn Sie keinen dokumentierten Grund haben, ein Feld zu erfassen und zu speichern, erfassen Sie es nicht.
  • Das Recht auf Löschung erfordert tatsächliches Löschen, kaskadierend durch alle Systeme einschließlich Backups und Drittanbieter. Soft-Deletes erfüllen die Verpflichtung nicht.

UK DSGVO vs. EU-DSGVO: Was sich für Entwickler ändert

Nach dem Brexit behielt das Vereinigte Königreich das EU-DSGVO-Rahmenwerk als „UK DSGVO" durch den European Union (Withdrawal) Act 2018 bei. Für Entwickler sind die technischen Anforderungen identisch. Die Unterschiede sind administrativer Natur: Die Aufsichtsbehörde im Vereinigten Königreich ist das Information Commissioner’s Office (ICO) und nicht eine nationale Datenschutzbehörde der EU, und grenzüberschreitende Übermittlungen zwischen dem Vereinigten Königreich und der EU unterliegen dem UK-Angemessenheitsbeschluss (derzeit von der EU aufrechterhalten, wird jedoch regelmäßig überprüft).

Die praktische Konsequenz ist: Wenn Sie Software erstellen, die den technischen Anforderungen der EU-DSGVO entspricht, erfüllt sie auch die technischen Anforderungen der UK DSGVO. Das Umgekehrte gilt ebenfalls. Abweichungen werden Sie bei Meldeverfahren, Übermittlungsmechanismen und dem spezifischen Durchsetzungsleitfaden der ICO finden, der in der Betonung manchmal von den EDPB-Leitlinien abweicht.

Artikel 32: Was er tatsächlich verlangt

Artikel 32 der UK DSGVO verpflichtet Verantwortliche und Auftragsverarbeiter, „geeignete technische und organisatorische Maßnahmen" zu ergreifen, um ein dem Risiko angemessenes Sicherheitsniveau zu gewährleisten, unter Berücksichtigung des Stands der Technik, der Implementierungskosten sowie der Art, des Umfangs, des Kontexts und der Zwecke der Verarbeitung.

Diese Formulierung ist bewusst flexibel. Was sie in der Praxis bedeutet, hängt von Ihrem Risikoprofil ab, aber Artikel 32 Absatz 1 nennt vier spezifische Beispiele:

  1. Pseudonymisierung und Verschlüsselung personenbezogener Daten
  2. Fähigkeit zur dauerhaften Sicherstellung der Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Verarbeitungssysteme
  3. Fähigkeit, die Verfügbarkeit personenbezogener Daten und den Zugang zu ihnen nach einem physischen oder technischen Zwischenfall rechtzeitig wiederherzustellen
  4. Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen

„Stand der Technik" bedeutet nicht, dass Sie die teuerste oder modernste Lösung implementieren müssen. Es bedeutet, dass Sie keinen schwachen Ansatz (wie MD5 für das Passwort-Hashing) rechtfertigen können, wenn eindeutig bessere Ansätze (wie Argon2) etabliert, weit verbreitet und nicht wesentlich teurer in der Implementierung sind.

Verschlüsselung im Ruhezustand

Passwörter. Speichern Sie niemals Passwörter im Klartext und verwenden Sie niemals MD5 oder SHA-1 für das Passwort-Hashing. Beide sind völlig ungeeignet. Verwenden Sie bcrypt mit einem Work-Faktor von mindestens 12 oder Argon2id mit Parametern, die auf mindestens 100 ms auf Ihrer Server-Hardware ausgelegt sind. Argon2id ist die aktuelle Empfehlung von OWASP und ist für neue Implementierungen vorzuziehen.

1# Argon2id mit libsodium (Node.js-Beispiel)
2const hash = await argon2.hash(password, {
3  type: argon2.argon2id,
4  memoryCost: 65536,   // 64 MB
5  timeCost: 3,
6  parallelism: 1
7});

Datenbankverschlüsselung. Aktivieren Sie die Verschlüsselung im Ruhezustand auf Datenbankebene. Alle wichtigen Datenbanken und verwalteten Dienste (PostgreSQL, MySQL, MongoDB Atlas, AWS RDS, Azure SQL) unterstützen dies. Transparente Datenverschlüsselung (TDE) schützt Daten auf dem Datenträger, schützt jedoch nicht vor einem kompromittierten Datenbankbenutzer mit Abfragezugriff. Für hochsensible Felder (Sozialversicherungsnummern, Krankenakten, Finanzkontonummern) sollten Sie eine verschlüsselung auf Anwendungsebene mit AES-256-GCM und einem Schlüsselverwaltungsdienst (AWS KMS, Azure Key Vault, HashiCorp Vault) in Betracht ziehen. Der Schlüssel muss getrennt von den zu verschlüsselnden Daten gespeichert werden.

Schlüsselverwaltung. Hardcoden Sie keine Verschlüsselungsschlüssel im Anwendungscode und speichern Sie sie nicht in derselben Datenbank wie die zu schützenden Daten. Verwenden Sie Umgebungsvariablen für die Entwicklung und einen verwalteten Schlüsselverwaltungsdienst für die Produktion. Rotieren Sie Schlüssel regelmäßig und stellen Sie sicher, dass Ihre Anwendung Schlüsselrotationen ohne Ausfallzeiten bewältigen kann.

Was zu vermeiden ist. Speichern Sie keine personenbezogenen Klartextdaten in Protokolldateien, temporären Dateien oder Anwendungscaches, bei denen möglicherweise keine Verschlüsselung gilt. Überprüfen Sie jeden Code-Pfad, der personenbezogene Daten verarbeitet, und stellen Sie sicher, dass keine unverschlüsselten Kopien versehentlich gespeichert werden.

Verschlüsselung bei der Übertragung

TLS-Konfiguration. Erzwingen Sie TLS 1.2 als Minimum, mit TLS 1.3 als Standard, wo unterstützt. Deaktivieren Sie SSLv3, TLS 1.0 und TLS 1.1 vollständig. Auf nginx:

1ssl_protocols TLSv1.2 TLSv1.3;
2ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
3ssl_prefer_server_ciphers off;

HSTS. Setzen Sie den Header Strict-Transport-Security mit einem langen max-age-Wert und includeSubDomains. Ein max-age von mindestens 31536000 (ein Jahr) ist der Standard. Melden Sie sich für die HSTS-Preload-Liste an, wenn Ihre Deployment-Umgebung dies erlaubt.

1Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Mixed Content. Das Bereitstellen von Ressourcen (Bilder, Skripte, Stylesheets, API-Aufrufe) über HTTP von einer HTTPS-Seite schafft eine Mixed-Content-Schwachstelle und untergräbt die Transportsicherheit. Konfigurieren Sie Ihre Content Security Policy so, dass Mixed Content blockiert wird, und überprüfen Sie Ihre Seite auf Ressourcen, die nicht über HTTPS geladen werden.

Interne Dienste. Die Verschlüsselung bei der Übertragung gilt auch für die interne Dienst-zu-Dienst-Kommunikation sowie für den nutzerseitigen Datenverkehr. Datenbankverbindungen, Message-Queue-Verbindungen und Microservice-Aufrufe sollten alle TLS verwenden. Viele Entwickler verschlüsseln korrekt die nutzerseitige Ebene und übersehen das interne Netzwerk.

Datensparsamkeit im Code

Datensparsamkeit ist keine rechtliche Abstraktion. Sie ist eine Designentscheidung, die Feld für Feld getroffen wird. Bevor Sie personenbezogene Daten erfassen, fragen Sie sich: Benötigt die Anwendung diese Daten tatsächlich für ihre Funktion? Wenn Sie diese Frage nicht mit einem konkreten Anwendungsfall beantworten können, erfassen Sie sie nicht.

In der Praxis bedeutet das:

  • Entfernen Sie Formularfelder, die optional sind und deren Zweck vage ist (z. B. „Geburtsdatum" bei einer Newsletter-Anmeldung, bei der keine Altersverifizierung erforderlich ist)
  • Überprüfen Sie Ihr Datenbankschema regelmäßig und löschen Sie Spalten, die personenbezogene Daten ohne aktive Nutzung enthalten
  • Setzen Sie Aufbewahrungsfristen auf Schemaebene, wo möglich, und verwenden Sie geplante Jobs, um abgelaufene Datensätze automatisch zu bereinigen
  • Vermeiden Sie die Erfassung hochsensibler personenbezogener Daten (Gesundheitsinformationen, Finanzdetails, politische Ansichten), es sei denn, Ihre Anwendung benötigt diese tatsächlich, da die Risikobewertung nach Artikel 32 mit der Sensibilität der verarbeiteten Daten skaliert

Das Rechenschaftspflichtprinzip der ICO verlangt, dass Sie nachweisen können, dass Sie die Datensparsamkeit berücksichtigt haben. Dokumentierte Designentscheidungen in Ihrer Architektur oder in Sprint-Notizen erfüllen diese Anforderung. Undokumentierte Entscheidungen tun es nicht.

Pseudonymisierung

Die Pseudonymisierung ersetzt direkt identifizierende Informationen durch ein Token oder eine Kennung, die ohne Zugang zu einem separat gespeicherten Schlüssel oder einer Zuordnungstabelle keine Person identifizieren kann. Artikel 32 listet sie ausdrücklich als empfohlene technische Maßnahme auf, und Artikel 89 sieht reduzierte Verpflichtungen für die Verarbeitung pseudonymisierter Daten zu Forschungszwecken vor.

Für Analysen und Verhaltens-Tracking ist ein gängiges Muster, Benutzeridentifikatoren mit einem site-spezifischen Salt mit SHA-256 zu hashen, bevor sie an Ihr Analysesystem weitergegeben werden:

1import hmac, hashlib
2
3def pseudonymise(user_id: str, site_secret: str) -> str:
4    return hmac.new(
5        site_secret.encode(),
6        user_id.encode(),
7        hashlib.sha256
8    ).hexdigest()

Das Salt muss getrennt von den Analysedaten gespeichert werden. Ohne es kann der Hash nicht rückgängig gemacht werden, um die Person zu identifizieren. Das bedeutet, dass Ihr Analysesystem nur pseudonymisierte Identifikatoren enthält, was das Risikoprofil eines Verstoßes gegen dieses System reduziert.

Pseudonymisierung ist keine Anonymisierung. Wenn Sie den Zuordnungsschlüssel besitzen, behandelt die ICO die pseudonymisierten Daten als personenbezogene Daten. Vollständige Anonymisierung, bei der eine Re-Identifikation auch mit zusätzlichen Informationen, die vernünftigerweise verfügbar sein könnten, nicht möglich ist, entzieht die Daten vollständig dem DSGVO-Anwendungsbereich. Echte Anonymisierung ist in der Praxis schwierig zu erreichen; die meisten Implementierungen erzeugen pseudonymisierte Daten, die immer noch unter die DSGVO fallen, aber mit reduziertem Risiko.

Recht auf Löschung: Korrekte Implementierung

Das Recht auf Löschung (Artikel 17) ist eine der technisch anspruchsvollsten DSGVO-Verpflichtungen, die korrekt umgesetzt werden muss. Die Anforderungen sind spezifisch:

Tatsächliches Löschen, kein Soft-Delete. Das Setzen eines is_deleted-Flags und das Herausfiltern aus Abfragen erfüllt das Recht auf Löschung nicht. Die Daten müssen tatsächlich aus der Datenbank entfernt werden. Implementieren Sie eine echte Löschfunktion für jede Entität, die personenbezogene Daten enthält.

Kaskadierende Löschungen. Das Löschen des Benutzerdatensatzes reicht nicht aus, wenn personenbezogene Daten auch in verwandten Tabellen gespeichert sind (Bestellungen, Adressen, Aktivitätsprotokolle, Einstellungen, hochgeladene Dateien). Kartieren Sie jede Tabelle, die personenbezogene Daten enthält, die mit einer Benutzerkennung verknüpft sind, und stellen Sie sicher, dass Löschungen korrekt kaskadieren oder implementieren Sie einen expliziten Löschjob, der alle zugehörigen Daten atomar entfernt.

Drittanbieter. Wenn Sie personenbezogene Daten an einen Drittanbieter übermittelt haben (E-Mail-Marketing-Plattform, CRM, Analysetool, Zahlungsabwickler), erstreckt sich Ihre Löschverpflichtung auch auf die Anweisung an diesen Auftragsverarbeiter, die Daten zu löschen. Dies erfordert:

  • Ein dokumentiertes Inventar jedes Drittanbieterdiensts, der personenbezogene Daten erhält
  • Einen bestätigten Löschmechanismus für jeden (API-Aufruf, Support-Ticket, automatisierte Bearbeitung von Betroffenenanfragen)
  • Nachweis, dass die Löschung abgeschlossen wurde

Backups. Backups sind das am häufigsten übersehene Löschproblem. Wenn Sie tägliche Datenbank-Backups mit einer 90-tägigen Aufbewahrungsfrist erstellen, wird eine in der Live-Datenbank erfüllte Löschanforderung in den Backups erst erfüllt, wenn diese auslaufen. Die Position der ICO lautet, dass Backups, die nach der Löschung wiederhergestellt werden, die gelöschten personenbezogenen Daten nicht wieder einführen dürfen. Praktische Ansätze umfassen: Ausschluss gelöschter Datensätze aus Backup-Exporten, wo möglich, Implementierung backup-spezifischer Bereinigungsprozesse oder Verwendung von Feldverschlüsselung und Löschen des Schlüssels (wodurch die Daten unlesbar werden, was dem Löschungsstandard nahekommt).

Ausnahmen. Das Recht auf Löschung ist nicht absolut. Sie können Daten aufbewahren, die für Rechtsansprüche, gesetzliche Compliance (z. B. Finanzunterlagen nach dem Companies Act) oder Zwecke des öffentlichen Interesses erforderlich sind. Dokumentieren Sie die Ausnahme und teilen Sie sie der betroffenen Person mit, wenn Sie eine Löschanforderung ablehnen oder nur teilweise erfüllen.

Breach-Erkennung und die 72-Stunden-Meldepflicht

UK DSGVO Artikel 33 verlangt, dass Sie die ICO innerhalb von 72 Stunden nach Bekanntwerden eines persönlichen Datenschutzvorfalls benachrichtigen, der voraussichtlich zu einem Risiko für Personen führt. Dies sind nicht 72 Stunden nach dem Eintreten des Verstoßes. Es sind 72 Stunden ab dem Zeitpunkt, zu dem Sie davon Kenntnis erlangt haben. Diese Unterscheidung schafft einen direkten Anreiz, Breach-Erkennungsfähigkeiten aufzubauen, da die Uhr zu ticken beginnt, wenn Sie ihn entdecken.

Was für die Breach-Erkennung zu protokollieren ist. Ihre Protokollarchitektur sollte erfassen:

  • Authentifizierungsereignisse: erfolgreiche und fehlgeschlagene Anmeldungen, MFA-Herausforderungen, Passwortzurücksetzungen
  • Autorisierungsfehler: Anfragen, die aufgrund von Berechtigungsprüfungen abgelehnt wurden
  • Datenzugriff: Wer auf welche personenbezogenen Daten zugegriffen hat und wann, insbesondere Massenexporte oder ungewöhnliche Abfragevolumen
  • Konfigurationsänderungen: Änderungen an Benutzerberechtigungen, Verschlüsselungsschlüsseln oder Datenspeicherungseinstellungen
  • Anomale Muster: Zugriff von ungewöhnlichen IP-Adressen oder zu ungewöhnlichen Zeiten, umfangreiche Lesevorgänge in Tabellen mit personenbezogenen Daten

Was nicht zu protokollieren ist. Protokollieren Sie keine personenbezogenen Datenwerte in Ihren Anwendungsprotokollen. Debug-Protokolle, die vollständige Anfragetexte aufzeichnen, Datenbankabfragen mit eingesetzten Parameterwerten oder vom Benutzer eingegebene Formulardaten, erstellen sekundäre personenbezogene Datenspeicher, die schwer zu verwalten sind und selbst im DSGVO-Anwendungsbereich liegen. Protokollieren Sie Identifikatoren (Benutzer-IDs, Sitzungs-IDs, Anfrage-IDs) statt Werte.

1# Falsch: protokolliert die tatsächliche E-Mail-Adresse
2logger.debug(f"Login attempt for user {request.form['email']}")
3
4# Richtig: protokolliert nur eine Kennung
5logger.debug(f"Login attempt, user_id={user.id}, request_id={request_id}")

Planung der Breach-Reaktion. Protokollierung ermöglicht Erkennung, aber Sie benötigen einen dokumentierten Prozess, der festlegt, was passiert, wenn Sie einen Verstoß erkennen. Wer wird intern benachrichtigt? Wer entscheidet über die ICO-Benachrichtigung? Welche Informationen muss die ICO-Benachrichtigung enthalten? Bauen Sie diesen Prozess auf, bevor Sie ihn benötigen.

Compliance von Drittanbieter-APIs

Controller vs. Auftragsverarbeiter. Wenn Sie einen Drittanbieterdienst verwenden, der personenbezogene Daten in Ihrem Auftrag verarbeitet (ein Transaktions-E-Mail-Anbieter, ein Cloud-Infrastrukturanbieter, ein Zahlungsabwickler), sind diese ein Auftragsverarbeiter und Sie sind der Verantwortliche. Sie sind für deren Compliance mit der UK DSGVO in diesem Kontext verantwortlich.

Datenverarbeitungsverträge. Sie müssen mit jedem Drittanbieterdienst, der personenbezogene Daten in Ihrem Auftrag verarbeitet, einen schriftlichen Datenverarbeitungsvertrag (DPA) abschließen. Die meisten großen SaaS-Anbieter (AWS, Mailchimp, Stripe, Twilio, SendGrid) bieten Standard-DPAs an. Unterzeichnen und behalten Sie diese. Wenn ein Anbieter keinen DPA vorlegen kann, dürfen Sie ihn nicht legal zur Verarbeitung personenbezogener Daten gemäß UK DSGVO verwenden.

Unterauftragsverarbeiter. Ihr DPA mit einem Auftragsverarbeiter sollte deren Unterauftragsverarbeiter auflisten (die Dienste, die sie ihrerseits zur Verarbeitung Ihrer Daten verwenden). Zum Beispiel kann Ihr Transaktions-E-Mail-Anbieter AWS-Infrastruktur nutzen. Sie sind nicht verpflichtet, einen direkten DPA mit Unterauftragsverarbeitern abzuschließen, aber Sie müssen wissen, wer diese sind und wo Daten geographisch verarbeitet werden, um die Übermittlungs-Compliance zu gewährleisten.

Übermittlungsmechanismen. Wenn ein Drittanbieterdienst Daten außerhalb des Vereinigten Königreichs oder der EU verarbeitet, benötigen Sie einen rechtlichen Übermittlungsmechanismus. Für Übermittlungen aus dem Vereinigten Königreich sind dies derzeit UK-spezifische Mechanismen (UK International Data Transfer Agreements oder Inanspruchnahme von UK-Angemessenheitsbeschlüssen, wo verfügbar). Überprüfen Sie die Datenresidenzoptionen und Übermittlungsdokumentation jedes Dienstes.

Zugriffskontrolle

Prinzip der minimalen Rechtevergabe. Datenbankbenutzer, die von Ihrer Anwendung verwendet werden, sollten die minimalen erforderlichen Berechtigungen haben: Lesen und Schreiben auf bestimmte Tabellen, kein Administratorzugriff. Erstellen Sie separate Datenbankzugangsdaten für leseintensive Dienste (Berichterstattung, Analysen) und schreibintensive Dienste (nutzerseitige Anwendung). Dies begrenzt den Schadensradius eines kompromittierten Zugangsdatensatzes.

Rollenbasierte Zugriffskontrolle. Implementieren Sie RBAC in Ihrer Anwendung und überprüfen Sie Rollenzuweisungen regelmäßig. Rollen neigen dazu, mit der Zeit Berechtigungen anzuhäufen; eine regelmäßige Überprüfung gegen den tatsächlichen Bedarf jeder Rolle erkennt Privilegienerweiterungen.

Audit-Protokolle für den Datenzugriff. Implementieren Sie für sensible Daten Audit-Protokollierung auf der Anwendungsschicht, die aufzeichnet, welcher authentifizierte Benutzer auf welchen personenbezogenen Datensatz zugegriffen hat und wann. Diese ist getrennt von Ihren Anwendungsfehlerprotokollen und sollte manipulationssicher sein (write-once oder append-only, mit vom Anwendungscode eingeschränktem Zugriff).

Entwickler-Checkliste: 10 technische Kontrollen zur Implementierung

  1. Passwort-Hashing. Verwenden Sie bcrypt (Kostenfaktor 12+) oder Argon2id. Entfernen Sie sofort jedes MD5- oder SHA-1-Passwort-Hashing.
  2. Verschlüsselung im Ruhezustand. Aktivieren Sie datenbankweite TDE und implementieren Sie Feldverschlüsselung mit AES-256-GCM für hochsensible personenbezogene Daten mit Schlüsseln in einem verwalteten KMS.
  3. TLS-Konfiguration. Erzwingen Sie TLS 1.2 als Minimum, TLS 1.3 als Standard, HSTS mit einem Jahr max-age, kein Mixed Content.
  4. Audit der Datensparsamkeit. Überprüfen Sie jedes Feld in Ihrem Datenbankschema, das personenbezogene Daten enthält. Entfernen oder stoppen Sie das Sammeln von Feldern ohne einen dokumentierten, aktiven Verwendungszweck.
  5. Implementierung des tatsächlichen Löschens. Erstellen Sie verifizierte Kaskaden-Löschungen für alle personenbezogenen Daten, die mit einem Benutzer verknüpft sind. Testen Sie, ob die Löschung tatsächlich Datensätze entfernt und sie nicht nur markiert.
  6. Inventar der Drittanbieter-DPAs. Listen Sie jeden SaaS- oder Cloud-Dienst auf, der personenbezogene Daten erhält. Bestätigen Sie das Vorhandensein eines unterzeichneten DPA für jeden. Entfernen Sie jeden Dienst, der keinen vorlegen kann.
  7. Protokollierungshygiene. Überprüfen Sie Ihre Anwendungsprotokolle auf personenbezogene Daten. Entfernen Sie personenbezogene Datenwerte aus der Protokollausgabe auf jeder Protokollierungsebene. Protokollieren Sie nur Identifikatoren.
  8. Breach-Erkennungsprotokollierung. Implementieren Sie strukturierte Protokollierung für Authentifizierungsereignisse, Autorisierungsfehler und Massendatenzugriff. Richten Sie Warnungen für anomale Muster ein.
  9. Überprüfung der Zugriffskontrolle. Überprüfen Sie Datenbankzugangsdaten und Anwendungsrollen anhand des Prinzips der minimalen Rechtevergabe. Entfernen Sie den Administratorzugriff von Anwendungsdatenbankbenutzern.
  10. Pseudonymisierung für Analysen. Ersetzen Sie direkte Benutzeridentifikatoren in Analyse- und Drittanbieter-Tracking-Aufrufen durch HMAC-gehashte Werte mit einem site-spezifischen Secret.

Wichtige Erkenntnisse

  • Die technischen Anforderungen der UK DSGVO sind identisch mit denen der EU-DSGVO. Nach dem Brexit setzt die ICO diese durch und Sie müssen dem ICO-spezifischen Leitfaden für Meldungen und Übermittlungen folgen.
  • Artikel 32 verlangt angemessene technische Maßnahmen proportional zu Ihrem Risiko. Für die meisten Anwendungen bedeutet dies starke Verschlüsselung, Zugriffskontrollen, Pseudonymisierung und dokumentierte Breach-Erkennung.
  • Datensparsamkeit ist eine auf Feldebene von Entwicklern getroffene Entscheidung, keine rechtliche Abstraktion. Wenn Sie das Sammeln eines Feldes nicht rechtfertigen können, sammeln Sie es nicht.
  • Das Recht auf Löschung erfordert tatsächliches Löschen, das kaskadierend durch alle Systeme einschließlich Backups und Drittanbieter erfolgt. Ein Soft-Delete-Flag erfüllt die Verpflichtung nicht.
  • Protokollieren Sie keine personenbezogenen Datenwerte. Protokollieren Sie Identifikatoren. Ihre Protokolldateien sind selbst ein personenbezogener Datenspeicher und einer der am häufigsten übersehenen Breach-Vektoren.
  • Haben Sie einen unterzeichneten DPA mit jedem Drittanbieterdienst, der personenbezogene Daten verarbeitet. Wenn ein Anbieter keinen vorlegen kann, dürfen Sie ihn nicht legal für diesen Zweck verwenden.

Häufig gestellte Fragen (FAQ)

Gilt die UK DSGVO, wenn alle meine Benutzer außerhalb des Vereinigten Königreichs sind? Die UK DSGVO gilt, wenn Sie im Vereinigten Königreich niedergelassen sind, unabhängig davon, wo sich Ihre Benutzer befinden. Sie gilt auch für Organisationen außerhalb des Vereinigten Königreichs, die Waren oder Dienstleistungen für Personen im Vereinigten Königreich anbieten oder das Verhalten von Personen im Vereinigten Königreich beobachten. Wenn Sie ein im Vereinigten Königreich ansässiger Entwickler sind, der für ein nicht-britisches Publikum entwickelt, gilt die UK DSGVO für Ihre Verarbeitungsaktivitäten.

Ist Verschlüsselung unter der UK DSGVO obligatorisch? Verschlüsselung ist in Artikel 32 Absatz 1 Buchstabe a ausdrücklich als empfohlene Maßnahme aufgeführt. Sie ist keine absolute Pflichtanforderung, da die Verordnung Maßnahmen „angemessen zum Risiko" verlangt. In der Praxis wäre es bei jeder Anwendung, die personenbezogene Daten über das Internet verarbeitet, sehr schwer zu rechtfertigen, Daten bei der Übertragung und im Ruhezustand nicht zu verschlüsseln. Behandeln Sie es als erforderlich.

Was gilt als persönlicher Datenschutzvorfall, der eine ICO-Benachrichtigung erfordert? Ein persönlicher Datenschutzvorfall ist jede versehentliche oder rechtswidrige Vernichtung, Verlust, Veränderung, unbefugte Offenlegung von oder Zugang zu personenbezogenen Daten. Dazu gehört ein falsch konfigurierter S3-Bucket, der Datensätze öffentlich zugänglich gemacht hat, ein Phishing-Angriff, der einem Angreifer Zugang zu Ihrem E-Mail-Konto mit Kundendaten verschafft hat, und die versehentliche Löschung von Datensätzen ohne Backup. Nicht alle Verstöße erfordern eine ICO-Benachrichtigung: nur diejenigen, die voraussichtlich zu einem Risiko für Personen führen. Bei Hochrisiko-Verstößen ist auch eine direkte Benachrichtigung der betroffenen Personen erforderlich.

Wie lange müssen wir personenbezogene Daten aufbewahren? Die UK DSGVO legt keine Aufbewahrungsfristen fest. Sie müssen Daten nur so lange aufbewahren, wie es für den Zweck, für den sie erhoben wurden, erforderlich ist. Legen Sie Aufbewahrungsfristen für jede Datenkategorie fest, die Sie halten, dokumentieren Sie diese in Ihrer Datenschutzerklärung und implementieren Sie automatisierte Bereinigung. Finanzunterlagen werden in der Regel sechs Jahre lang gemäß dem Companies Act aufbewahrt. Marketing-Einwilligungsnachweise sollten aufbewahrt werden, bis die Einwilligung widerrufen wird oder abläuft.

Benötigen wir einen Datenschutzbeauftragten? Ein Datenschutzbeauftragter (DSB) ist obligatorisch für Behörden, Organisationen, die sensible personenbezogene Daten in großem Maßstab verarbeiten, und Organisationen, die systematische Beobachtungen in großem Maßstab durchführen. Für die meisten britischen Softwareunternehmen ist ein DSB nicht obligatorisch, aber ratsam, wenn Sie erhebliche Mengen personenbezogener Daten verarbeiten. Die ICO bietet auf ihrer Website spezifische Leitlinien zu diesem Schwellenwert.

Was ist die maximale Geldstrafe für die Nichteinhaltung der UK DSGVO? Die ICO kann Bußgelder von bis zu 17,5 Millionen Pfund oder 4 % des globalen Jahresumsatzes (je nachdem, welcher Betrag höher ist) für die schwerwiegendsten Verstöße verhängen. Niedrigere Bußgelder von bis zu 8,7 Millionen Pfund oder 2 % des globalen Umsatzes gelten für weniger schwerwiegende Verstöße. In der Praxis liegen die meisten ICO-Bußgelder deutlich unter dem Maximum und werden an die Schwere des Verstoßes, die Zusammenarbeit der Organisation und die zur Behebung des Problems ergriffenen Maßnahmen angepasst.