Was sind regulierte Daten und warum sind sie wichtig?
|
7
min. Lesezeit
Regulierte Daten sind Informationen, deren Erhebung, Nutzung, Offenlegung, Aufbewahrung oder Schutz durch Gesetze oder Branchenstandards geregelt ist. Ein Kundendatensatz mit Name, Postleitzahl und Geburtsdatum überschreitet diese Grenze schnell: Sobald er eine Person identifizieren kann, ist er keine gewöhnlichen Betriebsdaten mehr, sondern bringt Compliance-Pflichten mit sich.
Das zeigt sich in den alltäglichen Tabellen, die Datenteams ständig bewegen. Ein Warehouse lädt Kundenprofile, ein anderes ergänzt die Bestellhistorie, und ein nachgelagertes Modell verknüpft diese Zeilen mit Geräte- oder Standortfeldern. Ab diesem Punkt lautet die Frage nicht mehr nur „Was steht in der Tabelle?“, sondern „Was kann diese Tabelle bei dieser Nutzung, in dieser Rechtsordnung, genau jetzt offenlegen?“
Inhaltsverzeichnis
Der Moment, in dem ein Datensatz reguliert wird
Eine Tabelle wird nicht dadurch reguliert, dass jemand sie in einer Tabellenkalkulation so kennzeichnet. Sie wird reguliert, wenn Inhalt, Kontext und Nutzung sie unter rechtliche Kontrolle stellen. Deshalb kann ein kleiner Kundenauszug zunächst harmlos wirken und in dem Moment sensibel werden, in dem er Identifikatoren enthält, mit anderen Feldern verknüpft wird oder für einen Zweck genutzt wird, der eine Rechtsvorschrift auslöst.
Die Arbeitsdefinition, die Sie im Kopf behalten sollten, ist einfach: Regulierte Daten sind Informationen, für deren Erhebung, Nutzung, Offenlegung, Aufbewahrung, Sicherheit oder Löschung gesetzliche Anforderungen gelten. Unter der DSGVO haben personenbezogene Daten diese weite Bedeutung seit dem 25. Mai 2018 (ICO-Leitfaden zu personenbezogenen Daten). Deshalb kann ein Datensatz reguliert sein, auch wenn er weder eine nationale Ausweisnummer noch einen vollständigen Namen enthält.
Warum meist der Kontext entscheidet, nicht der Tabellenname
Eine Kundentabelle mit Namen, Postleitzahlen, Geburtsdaten und Bestellhistorien kann von der Routineanalyse in regulierten Bereich wechseln, weil sie sich auf eine identifizierbare Person beziehen kann. Dieselbe Logik gilt für Mitarbeiterdaten, Lieferantendateien, Zutrittskarten-Logs, Videoüberwachung, Audioaufnahmen und Standortdaten. Wenn eine Zeile jemanden allein oder in Kombination mit anderen Daten der Organisation identifizieren kann, folgen die Pflichten der Zeile und nicht nur dem Schemanamen.
Eine hilfreiche Gewohnheit ist es, drei Fragen zu stellen, bevor Sie einem Datensatz vertrauen:
Wen können diese Daten identifizieren? Lautet die Antwort „eine Person“, befinden Sie sich in reguliertem Bereich.
Wofür werden sie genutzt? Eine rechtmäßige Analysenutzung und eine eingeschränkte operative Nutzung können unterschiedliche Pflichten mit sich bringen.
Womit können sie sonst verknüpft werden? Joins schaffen oft Identifizierbarkeit, wo vorher keine offensichtlich war.
Eine gute Datenschutz-Grundlage für Teams, die gesundheitsbezogene Kundendaten verarbeiten, wird in Datenschutzpraktiken für digitale Gesundheit erläutert, denn dieselben „kleinen“ Felder werden oft sensibel, sobald sie mit einer Person und einem Versorgungsprozess verbunden sind.
Praxisregel: Wenn ein neuer Join, Export oder ein nachgelagertes Modell es leichter macht, eine Person herauszugreifen, behandeln Sie den Datensatz als reguliert, bis Sie das Gegenteil nachgewiesen haben.
Deshalb ist auch das Denken auf Feldebene so wichtig. Eine Datenbank ist für Governance ein zu grobes Objekt. Die Kontrolleinheit ist das Feld, die Transformation und der Anwendungsfall.
Für eine breitere Einordnung der Compliance-Begriffe ist der interne Überblick darüber, was Daten-Compliance bedeutet, eine sinnvolle Ergänzung zu diesem Gedanken.
Was die DSGVO regelt
Eine Zeile kann reguliert werden, lange bevor jemand die Tabelle als sensibel kennzeichnet. Nach der DSGVO sind personenbezogene Daten alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen, einschließlich direkter Identifikatoren wie Namen und Kennnummern sowie indirekter Identifikatoren wie Standortdaten, Online-Kennungen und genetischer oder wirtschaftlicher Merkmale (DSGVO Artikel 4). Diese Breite ist entscheidend, denn eine einfache Prüfung „Name entfernt“ reicht nicht aus.
Warum Quasi-Identifikatoren alles verändern
Eine Kundenbindungstabelle kann anonym wirken, nachdem jemand die offensichtlichen Felder entfernt hat. Fügen Sie Postleitzahl, Geschlecht und Geburtsdatum wieder in dieselbe Zeile ein, kann die Kombination in der Praxis dennoch auf eine einzelne Person verweisen. Der regulierte Status folgt den Daten dann durch Joins, Exporte, Logs, Backups und Feature Stores. Der rechtliche Charakter verschwindet nicht, nur weil der Datensatz verschoben wurde.
Warehouse-Teams übersehen diese Verschiebung häufig. Sie klassifizieren eine Tabelle einmal bei der Data Ingestion und gehen dann davon aus, dass die Kennzeichnung überall gültig bleibt. Ein Feld kann seine Bedeutung ändern, wenn es mit anderen Feldern verknüpft wird, wenn eine neue Spalte hinzukommt oder wenn ein abgeleiteter Datensatz für einen neuen Zweck mit einem neuen Team geteilt wird.
Governance beginnt mit dem Kontext des Feldes, und der Tabellenname ist das unzuverlässigste Signal, das Sie haben.
Verwaltete Metadaten sollten für jeden regulierten Datensatz Rechtsordnung, Zweck, Aufbewahrungsfrist, Rechtsgrundlage und zulässige Transformationen festhalten. Das ist der Unterschied zwischen „Wir wissen, dass das sensibel ist“ und „Wir können erklären, warum, wo und wie lange.“
Was das für ein Warehouse bedeutet
Für Data Engineers lautet der praktische Test, ob die Pipeline drei Dinge zeigen kann:
Welche Felder identifizierend sind.
Welche Transformationen diese Identifizierbarkeit verändert haben.
Welche nachgelagerten Systeme die Pflicht übernommen haben.
Die Klassifizierung auf Feldebene ist ehrlicher als ein Tabellenetikett. Ein Kundenexport kann in einem Workflow gewöhnlich und in einem anderen reguliert sein. Eine pseudonyme Kennung kann weiterhin als personenbezogenes Datum gelten, wenn eine Re-Identifizierung vernünftigerweise möglich ist, und eine aggregierte Kennzahl identifiziert vielleicht keine Personen mehr, unterliegt aber dennoch branchenspezifischen Aufbewahrungsregeln.
Hier treffen auch Datenschutz und operative Verträge aufeinander. Teams, die gesundheitsbezogene Kundendaten verwalten, stützen sich oft auf eine Auftragsverarbeitungsvereinbarung für Gesundheitsdaten, um die Verantwortlichkeiten bei der Verarbeitung ausdrücklich festzulegen, vor allem wenn dieselben Felder zwischen Systemen und Nutzungen wandern.
Gesundheit, Zahlungsverkehr und Finanzen im Vergleich
Eine klinische Notiz kann in einem System gewöhnlich bleiben und in dem Moment reguliert werden, in dem sie von einer Covered Entity oder einem Business Associate in elektronischer Form erstellt, empfangen, gespeichert oder übermittelt wird. Nach der HIPAA Security Rule sind elektronische geschützte Gesundheitsinformationen individuell identifizierbare Gesundheitsinformationen in elektronischer Form, und die Regel ist in 45 CFR Part 160 und Part 164, Subparts A und C kodifiziert (HHS HIPAA Security Rule). Dieselbe Tatsache auf Papier, in einem Telefonat oder in einer elektronischen Patientenakte hat nicht dieselbe Compliance-Form.
Warum der Verarbeiter genauso wichtig ist wie die Daten
HIPAA zeigt auch, dass die Rolle zählt. Ein Leistungserbringer, eine Krankenversicherung, ein Clearinghouse oder ein Business Associate kann aufgrund der Art, wie er mit den Daten umgeht, in den Anwendungsbereich fallen, während eine andere Organisation mit ähnlichen Informationen außerhalb dieser Rollen nicht darunter fällt. Deshalb müssen Compliance-Prüfungen Medium, Workflow und Verantwortlichkeit gemeinsam betrachten.
Für Teams, die eine praktische Brücke zwischen Gesundheitsbetrieb und Datenschutzregeln brauchen, vergleichen Tipps zur HIPAA- und DSGVO-Compliance, wie sich die Pflichten zwischen den Regelwerken unterscheiden.
Regelwerke für regulierte Daten im Überblick | Was es regelt | Wen es betrifft | Meldepflichtiges Ereignis |
|---|---|---|---|
DSGVO | Personenbezogene Daten, einschließlich direkter und indirekter Identifikatoren | Verantwortliche und Auftragsverarbeiter, die Daten identifizierbarer natürlicher Personen verarbeiten | Verletzung des Schutzes personenbezogener Daten mit voraussichtlichem Risiko für Rechte und Freiheiten |
HIPAA | Individuell identifizierbare Gesundheitsinformationen in elektronischer Form sowie geschützte Gesundheitsinformationen | Covered Entities und Business Associates | Verletzung ungesicherter PHI, mit Meldepflichten, die vom Umfang abhängen |
PCI DSS | Karteninhaberdaten, einschließlich Kontodaten, die streng geschützt werden müssen | Händler, Dienstleister und andere, die mit Zahlungskartenumgebungen arbeiten | Sicherheitsvorfall oder Kontrollversagen, das Kartendaten offenlegt |
Zahlungsverkehr und Finanzen folgen demselben Grundmuster, auch wenn das Regelwerk ein anderes ist. Karteninhaberdaten sind reguliert, weil Missbrauch zu Betrug und Verlusten führen kann. Die Kontrollen konzentrieren sich daher darauf, wo die Daten gespeichert sind, wer sie sehen kann und wie sie sich durch Systeme bewegen. Zahlungspipelines sind oft so gestaltet, dass sie die Speicherung minimieren, sensible Felder isolieren und die nachgelagerte Replikation begrenzen.
Die nützliche Lehre ist enger gefasst als eine allgemeine Datenschutzerklärung. Jedes Regelwerk definiert seine eigenen regulierten Inhalte, seine eigenen verantwortlichen Akteure und seine eigene Meldeschwelle, und die Pipeline muss diese Unterschiede abbilden. Ein Feld, das in einem Workflow harmlos erscheint, kann in einem anderen reguliert werden, wenn sich die Rolle oder das Medium ändert oder derselbe Datensatz durch ein neues System fließt.
Der interne Überblick zur Compliance von Gesundheitsdaten ist eine sinnvolle Ergänzung, wenn Sie klinische Datenflüsse auf Plattformkontrollen abbilden.
Felder statt Tabellen klassifizieren
Am klarsten denken Sie über regulierte Daten nach, wenn Sie nicht mehr fragen, ob eine Tabelle reguliert ist, sondern was jedes Feld im jeweiligen Kontext wird. Ein Feld, das in einem Workflow harmlos ist, kann in einem anderen reguliert werden, wenn sich der Zweck ändert, der Datensatz Rechtsordnungen überschreitet oder ein neuer Join die Person re-identifizierbar macht.
Ein praxistaugliches Klassifizierungsmodell
Stellen Sie für jeden Datensatz und jede nachgelagerte Nutzung sechs Fragen:
Datensatz: Was ist die Quelle und wo liegt sie?
Feld: Welche Spalten enthalten Identifikatoren, Gesundheitsangaben oder andere geschützte Merkmale?
Zweck: Warum werden die Daten verarbeitet?
Rechtsordnung: Welches Regelwerk gilt?
Verantwortliche Stelle: Wer ist für den Datensatz verantwortlich?
Nachgelagerte Nutzung: Wohin fließen die Daten sonst noch?
Schema Drift kann den regulierten Status verändern. Eine bisher gewöhnliche Analysetabelle kann sensibel werden, wenn jemand ein Kundensegment, ein Haushaltsmerkmal, eine Gerätekennung oder ein Standortfeld hinzufügt. Die Tabelle hat keine neue moralische Identität bekommen. Sie hat ein neues rechtliches Risiko bekommen.
Wenn eine neue Spalte verändert, was eine Zeile offenlegen kann, klassifizieren Sie den Datensatz sofort neu.
Deshalb ist auch der Speicherort allein kein verlässlicher Indikator für Sicherheit oder Compliance. Ein zitierter Cisco-Benchmark ergab, dass der Anteil der Organisationen, die lokale Speicherung mit höherer Sicherheit verbinden, von 90 % im Jahr 2025 auf 86 % im Jahr 2026 sank, während 89 % der multinationalen Organisationen angaben, dass die Tätigkeit in mehreren Rechtsordnungen maßgeschneiderte Compliance-Strategien erfordert (Data compliance guide). Diese Zahlen weisen auf dieselbe betriebliche Realität hin: Nicht der Ort entscheidet über den rechtlichen Status, sondern der Kontext.
Warum das auch außerhalb von Kundendaten auftritt
Mitarbeiterdaten, Lieferantendateien, Betriebslogs, Trainingsdatensätze für Modelle und Plattform-Telemetrie können alle reguliert werden, ohne wie klassische Kunden-PII auszusehen. Eine Logzeile kann eine IP-Adresse enthalten. Ein Telemetriestrom kann eine Benutzerkennung enthalten. Ein Feature Store kann Spuren von Quelldaten bewahren, die eigentlich maskiert sein sollten.
Die interne Notiz zur Datenklasse passt gut zu diesem Modell, denn die nützliche Einheit ist nicht „diese Datenbank ist sensibel“, sondern „dieses Feld hat für diesen Zweck in dieser Rechtsordnung diese Pflichten.“
Wenn Aufbewahrung und Löschung in entgegengesetzte Richtungen ziehen
Ein Marketingteam verlangt die Löschung eines Kundendatensatzes. Gleichzeitig schreibt eine Finanzvorschrift vor, dass ein Teil dieses Datensatzes aufbewahrt werden muss, und die Rechtsabteilung hat gerade einen Legal Hold für eine damit zusammenhängende Untersuchung verhängt. Das ist kein Sonderfall, sondern eine normale Kollision von Pflichten in regulierten Umgebungen.
Der Grundsatz der Speicherbegrenzung der DSGVO verlangt, personenbezogene Daten nicht länger als nötig aufzubewahren, doch das Recht auf Löschung kann durch eine gesetzliche Aufbewahrungspflicht verdrängt werden. Rechtsstreitigkeiten, behördliche Untersuchungen und Audits können zudem einen Legal Hold erfordern, der die übliche Löschung für die betroffenen Datensätze aussetzt (Fortis data governance guide).
Warum das ein Zustandsproblem ist und nicht nur ein Klassifizierungsproblem
Sobald diese Pflichten kollidieren, lautet die entscheidende Frage: Was ist mit jeder Kopie, jedem Replikat und jedem abgeleiteten Datensatz passiert? Wurde eine Zeile im primären Warehouse gelöscht, existiert aber noch in einem nachgelagerten Data Lake, Backup oder Export, kann die Organisation nicht behaupten, die Löschung sei vollständig. Gilt ein Hold für eine Teilmenge und für eine andere nicht, muss das System diesen Unterschied bewahren.
Deshalb ist das Management regulierter Daten eigentlich Zustandsmanagement. Das System muss wissen, wo sich der Datensatz befindet, in welcher Lebenszyklusphase er ist und ob eine Ausnahme die normale Löschung außer Kraft setzt.
Der interne Leitfaden zur Archivierung von Daten ist hier relevant, weil Aufbewahrungs- und Löschlogik nur funktionieren, wenn der Lebenszyklus auf Datensatzebene sichtbar ist.
Die Prüfungen, auf die es ankommt
Ein Team, das dies operativ umsetzen will, sollte Folgendes beobachten:
Abschluss der Aufbewahrungsjobs, damit geplante Löschungen tatsächlich gelaufen sind.
Replikationsverzögerung, damit ein gelöschter Datensatz nicht in einer Kopie weiterlebt.
Schema- und Zuständigkeitsänderungen, weil ein neuer Owner oder eine neue Spalte die Pflichten verändern kann.
Auffällige Persistenz, weil Datensätze, die über ihr genehmigtes Zeitfenster hinaus bestehen, oft auf einen fehlerhaften Job oder einen nicht erfassten Export hinweisen.
Der nützliche gedankliche Wechsel ist einfach. Löschung ist keine einzelne Aktion. Sie ist eine Kette von Zustandsübergängen über Systeme hinweg, und die Nachweise müssen zu dieser Kette passen.
Meldefristen, die Monitoring zum Nachweis machen
Meldepflichten bei Datenschutzverletzungen machen Observability zu einem Teil der Compliance und nicht nur zu einer Frage der Betriebshygiene. Wenn nach der UK GDPR eine Verletzung des Schutzes personenbezogener Daten voraussichtlich ein Risiko für die Rechte und Freiheiten von Personen darstellt, muss die Organisation die Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden benachrichtigen und eine etwaige Verzögerung begründen (ICO-Leitfaden zu Datenschutzverletzungen).
Die Uhr ist die Kontrolle
Diese Frist verändert die Aufgabe der Technik. Erkennung, Klassifizierung und Eskalation von Vorfällen sowie Nachweise mit Zeitstempel werden Teil der rechtlichen Mechanik. Kann das Team nicht zeigen, wann es von dem Vorfall Kenntnis erlangt hat, kann es auch nicht zeigen, ob die Meldung rechtzeitig erfolgte.
HIPAA hat einen anderen Auslöser, aber dieselbe operative Wirkung. Eine Verletzung ungesicherter geschützter Gesundheitsinformationen, die 500 oder mehr Personen betrifft, erfordert in der Regel die Benachrichtigung der Betroffenen und des HHS Secretary, und der Secretary veröffentlicht eine Liste solcher Verletzungen auf der HHS-Website (CRS-Zusammenfassung der HIPAA-Meldepflichten). Sobald Sie betroffene Personen zählen und nachweisen müssen, dass die Informationen ungesichert waren, wird der Audit-Trail zum Beweismittel.
Was gutes Monitoring erfassen muss
Das System sollte Folgendes festhalten:
Zeitstempel von Vorfällen, damit Kenntnisnahme und Eskalation nachweisbar sind.
Klassifizierung der betroffenen Daten, damit das richtige Regelwerk angewendet wird.
Lineage-Spuren, damit Teams sehen, welche Kopien und abgeleiteten Objekte offengelegt wurden.
Meldemaßnahmen, damit sich die Reaktion später rekonstruieren lässt.
Wenn das Log die Zeitachse nicht beweisen kann, ist es kein Audit-Trail, sondern eine Vermutung.
Für Teams mit regulierten Daten bedeutet das: Monitoring darf nicht bei der Verfügbarkeit aufhören. Es muss der Reihe nach beantworten, was sich geändert hat, wer es gesehen hat, wann das Team davon wusste und ob die Meldefrist zu laufen begonnen hat. Deshalb gehören Nachweise zu Vorfällen in das führende System und nicht in eine separate Tabelle, die nachträglich zusammengestellt wird.
Kontrollen in Ihrer eigenen Umgebung am Laufen halten
Kontrollen funktionieren am besten dort, wo die Daten bereits liegen. So können Teams Anomalien in regulierten Feldern erkennen, Regeln auf Datensatzebene validieren, Verzögerungen verfolgen und Schemaänderungen erfassen, ohne Produktionsdaten zuerst in ein anderes System zu verschieben.
digna bietet eine Enterprise-Plattform für Datenqualität und Data Observability, die in der eigenen Umgebung des Kunden läuft und KI-gestützte Anomalieerkennung, deterministische Validierung, Überwachung der Aktualität und kontinuierliche Erkennung von Schemaänderungen über Warehouses, Data Lakes und Pipelines hinweg kombiniert, ohne Produktionsdaten zu bewegen. Für regulierte Daten ist das wichtig, weil die Nachweise nah an der Quelle bleiben und die Prüfungen weiterlaufen können, während sich Schemas, Zuständigkeiten und Liefermuster ändern.
Warum die Kombination zählt
Anomalieerkennung macht ungewöhnliches Verhalten in regulierten Tabellen sichtbar. Aktualitätsprüfungen zeigen, ob erwartete Daten rechtzeitig eingetroffen sind. Validierung setzt Geschäftsregeln durch, die oft gesetzlichen Anforderungen entsprechen. Schema-Tracking erkennt strukturelle Abweichungen, bevor sie das Risiko verändern.
Zusammen beantworten diese Kontrollen dieselbe Frage aus verschiedenen Blickwinkeln: Hat sich der regulierte Zustand seit der letzten Prüfung verändert? In Finanzwesen, Gesundheitswesen, Telekommunikation und öffentlichem Sektor stellt sich diese Frage ständig, weil die Daten nie statisch sind.
Eine starke Umsetzung behandelt Klassifizierung, Validierung und Monitoring nicht als getrennte Programme. Sie verbindet sie, sodass ein Feld, das identifizierend wird, eine Ladung, die verspätet eintrifft, oder ein Schema, das ein sensibles Attribut hinzufügt, alle in derselben Umgebung Nachweise erzeugen. Wenn das Team einen externen Beleg für diesen Ansatz braucht, finden sich die Plattformdetails bei digna.
Was Sie im nächsten Sprint umsetzen sollten
Beginnen Sie mit den Signalen, die den regulierten Status am häufigsten verändern. Instrumentieren Sie die Replikation sensibler Felder, Ausnahmen zwischen Aufbewahrung und Legal Hold, Schema- und Zuständigkeitsänderungen, Anomalie-Baselines für regulierte Tabellen und erwartete im Vergleich zu tatsächlichen Lieferzeiten. Bewahren Sie die Nachweise zu jedem Vorfall auf, einschließlich Zeitstempeln, Lineage und der Regel oder dem Hold, der die Maßnahme begründet hat.
Wenn Sie nur Platz für zwei Kontrollen haben, wählen Sie Schema-Tracking und Aufbewahrungsnachweise. Diese beiden erfassen die Änderungen, die Teams meist zuerst überraschen.
Regulierte Daten sind kein statisches Etikett auf einer Datenbank. Sie sind kontextabhängig, zustandsbehaftet und davon geprägt, was die Daten in einem bestimmten Workflow bedeuten. Teams, die sie so behandeln, haben deutlich bessere Chancen, Audits ohne Hektik zu bestehen.
Wenn Sie die Kontrollen für regulierte Daten in Warehouses, Data Lakes und Pipelines verschärfen, bietet Ihnen digna Validierung, Anomalieerkennung, Überwachung der Aktualität und Erkennung von Schemaänderungen direkt in Ihrer Umgebung, ohne Produktionsdaten zu bewegen. So bleiben Nachweise leichter nah an der Quelle, und Sie erkennen Änderungen der Risikolage, bevor daraus Audit-Feststellungen werden.
Die Rechtsordnung ist eine der sechs Klassifizierungsfragen, und beim Speicherort verwechseln Teams sie am häufigsten mit Compliance. Unser Leitfaden dazu, was Datenresidenz tatsächlich verlangt, ist deshalb eine lohnende Ergänzung zu diesem Beitrag.
Häufig gestellte Fragen
Was sind regulierte Daten?
Regulierte Daten sind Informationen, deren Erhebung, Nutzung, Offenlegung, Aufbewahrung, Sicherheit oder Löschung durch Gesetze oder Branchenstandards geregelt ist. Ein Kundendatensatz mit Name, Postleitzahl und Geburtsdatum fällt darunter, sobald er eine Person identifizieren kann, denn dann bringt er Compliance-Pflichten mit sich und ist keine gewöhnlichen Betriebsdaten mehr.
Kann ein Datensatz ohne Namen oder Ausweisnummern reguliert sein?
Ja. Nach Artikel 4 DSGVO umfassen personenbezogene Daten auch indirekte Identifikatoren wie Standortdaten, Online-Kennungen und wirtschaftliche Merkmale. Namen aus einer Kundenbindungstabelle zu entfernen reicht nicht, wenn Postleitzahl, Geschlecht und Geburtsdatum bleiben, denn diese Kombination kann weiterhin auf eine einzelne Person verweisen.
Warum sollte man Daten nach Feldern statt nach Tabellen klassifizieren?
Weil dieselbe Tabelle in einem Workflow gewöhnlich und in einem anderen reguliert sein kann. Die Pflichten hängen davon ab, welche Spalten Personen identifizieren, sowie von Zweck, Rechtsordnung und nachgelagerter Nutzung. Schema Drift, etwa eine neue Gerätekennung oder Standortspalte, kann das rechtliche Risiko einer Tabelle über Nacht verändern.
Was passiert, wenn ein Löschantrag mit einer Aufbewahrungsregel kollidiert?
Eine gesetzliche Aufbewahrungspflicht oder ein Legal Hold kann das Recht auf Löschung nach DSGVO für die betroffenen Datensätze verdrängen. Teams müssen dann den Zustand jeder Kopie, jedes Replikats und jedes abgeleiteten Datensatzes verfolgen und den Abschluss von Aufbewahrungsjobs, Replikationsverzögerungen und zu lange bestehende Datensätze überwachen.
Wie schnell muss eine Datenschutzverletzung gemeldet werden?
Nach der UK GDPR muss eine Verletzung, die voraussichtlich die Rechte von Personen gefährdet, der Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden nach Kenntnisnahme gemeldet werden. Bei HIPAA erfordern Verletzungen ungesicherter Gesundheitsdaten ab 500 Betroffenen die Benachrichtigung der Personen und des HHS Secretary.
