DSAR, Löschung und ISO 27001-Nachweise im Jahr 2026

Die E-Mail ging um 9:03 Uhr in Sarahs Posteingang ein.

Es war nicht das erste Auskunftsersuchen einer betroffenen Person, das ihr schnell wachsendes SaaS-Unternehmen erhalten hatte. Es war aber das erste, das sich wie ein öffentliches Audit anfühlte.

Der Absender war ein ehemaliger Mitarbeiter, inzwischen Datenschutzaktivist. Die Anfrage verwies auf GDPR Artikel nach Nummer und verlangte sämtliche personenbezogenen Daten, die sofortige Einschränkung der Verarbeitung, eine Liste aller Drittdienstleister, die seine Daten speichern, sowie einen überprüfbaren Nachweis der Löschung aus Produktiv- und Backup-Systemen. Ein Journalist war in Kopie gesetzt.

Innerhalb weniger Minuten wurden die Lücken sichtbar. Engineering warnte, dass eine „echte Löschung“ aus einer mandantenfähigen Datenbank andere Kunden beeinträchtigen könnte. Marketing versuchte, Nutzerdaten über mehrere Analyseplattformen hinweg zu entflechten. Legal fand eine ungeklärte Angelegenheit aus dem Beschäftigungsverhältnis. Security befürchtete, dass Protokolle Erkennungslogik oder Daten einer anderen Person offenlegen könnten. Support hatte Datensätze unter zwei E-Mail-Adressen. Finance hatte Rechnungen unter einer dritten.

Die Frist lief bereits.

Dieses Szenario ist nicht mehr ungewöhnlich. Rechte betroffener Personen sind 2026 kein Thema für ein Datenschutz-Postfach allein. Sie sind ein gesteuerter Geschäftsprozess, der von Asset-Inventaren, Entscheidungen zur Rechtsgrundlage, Identitätsprüfung, Zugriffskontrolle, Aufbewahrungsregeln, Legal Hold, Lieferantenkoordination, sicherer Offenlegung, Löschungsnachweisen und auditfähiger Protokollierung abhängt.

GDPR gibt Organisationen vor, welche Rechte Einzelpersonen haben. ISO/IEC 27001:2022 gibt Sicherheits- und Compliance-Teams die Managementsystemdisziplin, um nachzuweisen, dass diese Rechte konsistent, sicher und wiederholbar bearbeitet werden.

Für CISOs, Compliance-Manager, Datenschutzverantwortliche und Geschäftsinhaber besteht das Ziel nicht darin, mehr Papier zu erzeugen. Ziel ist ein verlässlicher Workflow für DSAR, Löschung und Einschränkung, der die Nachweise liefert, die nach GDPR, in ISO/IEC 27001:2022-Audits und im Rahmen weitergehender Assurance-Erwartungen nach NIS2, DORA, NIST CSF 2.0 und COBIT 2019 erforderlich sind.

Warum die Ad-hoc-Bearbeitung von DSARs unter Druck scheitert

Die meisten DSAR-Fehler entstehen nicht aus böser Absicht. Sie entstehen durch Fragmentierung.

Ein Unternehmen kann eine Datenschutzerklärung, ein DPO-Postfach und eine GDPR-Klausel in Lieferantenverträgen haben und dennoch Schwierigkeiten haben, grundlegende operative Fragen zu beantworten:

• Wer prüft die Identität der anfragenden Person?
• Welche juristische Person ist Verantwortlicher oder Auftragsverarbeiter?
• Welche Systeme müssen durchsucht werden?
• Wer ist für jedes System verantwortlich?
• Welche Daten fallen in den Geltungsbereich?
• Welche Daten müssen vor der Offenlegung geschwärzt werden?
• Welche Daten dürfen wegen Steuer-, Audit-, Gerichtsverfahrens-, Betrugspräventions- oder gesetzlicher Pflichten nicht gelöscht werden?
• Wie wird die Einschränkung der Verarbeitung technisch durchgesetzt?
• Welche Lieferanten müssen Suche, Export, Löschung oder Einschränkung unterstützen?
• Welcher Nachweis belegt, dass die Anfrage fristgerecht bearbeitet wurde?
• Was passiert, wenn die DSAR eine Datenschutzverletzung offenlegt?

GDPR Artikel 5 verlangt, dass personenbezogene Daten rechtmäßig, fair und transparent verarbeitet, für festgelegte Zwecke erhoben, auf das Notwendige beschränkt, sachlich richtig gehalten, nicht länger als erforderlich aufbewahrt und durch geeignete technische und organisatorische Maßnahmen geschützt werden. Artikel 5(2) macht die Rechenschaftspflicht ausdrücklich: Der Verantwortliche muss die Einhaltung nachweisen können. Artikel 4 definiert Verarbeitung weit und umfasst Erhebung, Speicherung, Nutzung, Offenlegung, Einschränkung, Löschung und Vernichtung.

Damit ist der DSAR-Prozess selbst eine Verarbeitungstätigkeit. Er muss gesteuert werden.

GDPR Artikel 3 ist auch für Cloud-, SaaS-, Fintech- und digitale Unternehmen außerhalb der EU relevant. Wenn Waren oder Dienstleistungen Personen in der Union angeboten, deren Verhalten beobachtet oder personenbezogene Daten im Kontext einer EU-Niederlassung verarbeitet werden, kann GDPR auch dann gelten, wenn Abläufe ausgelagert sind oder die Infrastruktur global ist.

ISO/IEC 27001:2022 bringt Struktur in diese Realität. Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation ihren Kontext, interessierte Parteien, Anforderungen, den ISMS-Geltungsbereich und zusammenwirkende Prozesse versteht. Eine betroffene Person ist eine interessierte Partei. GDPR-Rechte sind Anforderungen. SaaS-Anwendungen, Identitätsanbieter, Analyseplattformen, Support-Werkzeuge, Data Warehouses und Cloud-Backups sind zusammenwirkende Prozesse. Ein DSAR-Workflow gehört in das ISMS, nicht daneben.

Die drei Rechte betroffener Personen mit dem größten Druck

Auskunft, Löschung und Einschränkung legen die größte Lücke zwischen rechtlichem Versprechen und operativer Fähigkeit offen.

GDPR Artikel 6 ist für diese Entscheidungslogik zentral. Ohne Verständnis der Rechtsgrundlage dürfen Sie nicht verarbeiten, aufbewahren, offenlegen oder eine Löschung verweigern. Artikel 9 erhöht die Anforderungen für besondere Kategorien personenbezogener Daten, etwa Gesundheitsdaten, biometrische Daten zur eindeutigen Identifizierung oder Daten, aus denen sensible Merkmale hervorgehen. In einer SaaS-Umgebung im Jahr 2026 kann dies Onboarding, Identitätsprüfung, Betrugsüberwachung, Anhänge im Kundensupport und Mitarbeiterdaten betreffen.

Clarysecs unternehmensweite Richtlinie zu Datenschutz und Privatsphäre [P17] formuliert die Verpflichtung direkt. In der Zielsetzungsklausel 3.6 verlangt sie von der Organisation:

Rechte betroffener Personen wahren, einschließlich Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerspruch und Schutz vor automatisierter Entscheidungsfindung.

Dieses Ziel wird erst auditierbar, wenn es mit Verantwortlichen, Registern, Workflows, Maßnahmen und Nachweisen verknüpft ist.

Beginnen, wo Auditoren beginnen: Geltungsbereich, interessierte Parteien und Verantwortlichkeit

In Zenith Blueprint: Eine 30-Schritte-Roadmap für Auditoren [ZB] konzentriert sich die Phase ISMS Foundation & Leadership, Schritt 2, auf Anforderungen interessierter Parteien und den ISMS-Geltungsbereich. Für GDPR identifiziert der Blueprint die Erwartungen von Aufsichtsbehörden wie folgt:

EU-Aufsichtsbehörden
(GDPR)

Rechtmäßige Verarbeitung personenbezogener
Daten, Meldung von Datenschutzverletzungen innerhalb von 72 Stunden,
Rechte betroffener Personen

Datenschutzbeauftragten benennen,
Verfahren zur Reaktion auf Datenschutzverletzungen einrichten,
Verfahren zur Bearbeitung von Datenanfragen festlegen.

Das ist der richtige Ausgangspunkt. Bevor Tickets automatisiert oder Portale konfiguriert werden, muss der Geltungsbereich der Verarbeitung von Rechten betroffener Personen definiert werden:

1. Welche juristischen Personen handeln als Verantwortlicher, gemeinsam Verantwortlicher oder Auftragsverarbeiter?
2. Welche Produkte, Dienstleistungen und Gebiete fallen in den Geltungsbereich?
3. Welche Kategorien betroffener Personen gibt es, etwa Kunden, Beschäftigte, Testnutzer, Interessenten, Lieferanten, Website-Besucher oder App-Nutzer?
4. Welche Systeme, Repositories und Lieferanten speichern personenbezogene Daten?
5. Welche Rollen genehmigen Offenlegung, Ablehnung, Löschung, Einschränkung oder Eskalation?
6. Welche Kennzahlen werden an das Management berichtet?

Die ISO/IEC 27001:2022-Klauseln 5.1 bis 5.3 verlangen Führung, Ausrichtung an Richtlinien, Ressourcen und zugewiesene Verantwortlichkeiten. Das passt unmittelbar zur Rechenschaftspflicht nach GDPR.

Die Richtlinie zu Datenschutz und Privatsphäre [P17], Anforderungen an die Umsetzung der Richtlinie, Klausel 6.4.1, legt fest:

Der Datenschutzbeauftragte muss dokumentierte Prozesse für Eingang, Validierung, Nachverfolgung und Beantwortung von Anfragen betroffener Personen unterhalten.

Für KMU nutzt Clarysecs Richtlinie zu Datenschutz und Privatsphäre - SME [P17S] angemessen dimensionierte Verantwortlichkeit. Die Governance-Anforderungen, Klausel 5.2.1, sehen vor:

Der Datenschutzkoordinator muss ein Register aller Verarbeitungstätigkeiten für personenbezogene Daten führen, einschließlich Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrungsfristen.

Dieses Verarbeitungsregister ist das operative Zentrum der DSAR-Bereitschaft. Ist es unvollständig, sucht das DSAR-Team nach Erinnerung, Slack-Nachrichten und informellem Wissen. Ist es aktuell, sucht das Team nach Verarbeitungstätigkeit, Datenkategorie, Systemverantwortlichem, Lieferant und Aufbewahrungsregel.

Der Clarysec-DSAR-Workflow: vom Eingang bis zum Abschluss

Ein auditbereiter DSAR-Workflow muss einfach genug sein, um unter Druck zu funktionieren, und zugleich kontrolliert genug, um einer Aufsichtsbehörde, einer Kunden-Assurance-Prüfung oder einem ISO/IEC 27001:2022-Audit standzuhalten.

1. Eingang und Bestätigung

Anfragen sollten über einen kontrollierten Kanal eingehen, etwa ein Datenschutzpostfach, ein Portal, ein Supportformular oder eine rechtliche Eingangswarteschlange. Mitarbeitende müssen Anfragen in Alltagssprache erkennen. Eine Person muss nicht „DSAR“ schreiben, um ein Recht auszuüben. „Welche Daten haben Sie über mich?“ oder „Löschen Sie mein Profil“ kann ausreichen, um den Workflow auszulösen.

Die Richtlinie zu Datenschutz und Privatsphäre - SME [P17S], Anforderungen an die Umsetzung der Richtlinie, Klausel 6.5.2, legt ein klares Servicelevel fest:

Der Datenschutzkoordinator muss Anfragen innerhalb von 3 Arbeitstagen bestätigen und innerhalb von 30 Tagen beantworten.

Die Eingangsbestätigung sollte die Anfragereferenz, gegebenenfalls eine Klärung des Geltungsbereichs, Anweisungen zur Identitätsprüfung und den erwarteten Antwortzeitpunkt enthalten.

2. Identitätsprüfung und Befugnisprüfung

Eine DSAR kann zu einer Datenschutzverletzung werden, wenn Informationen an die falsche Person gesendet werden. Die Prüfung muss verhältnismäßig sein und darf keine übermäßigen neuen personenbezogenen Daten erheben. Nutzen Sie, soweit möglich, authentifizierte Portale. Bei ehemaligen Nutzern ist gegen bekannte Kontodaten zu prüfen. Bei Beschäftigten ist mit HR zu koordinieren. Bei Vertretern ist ein Befugnisnachweis zu verlangen.

Bewahren Sie Nachweise zur Prüfmethode, zum Abschlussdatum, zum Genehmigenden, zu zusätzlich angeforderten Informationen und zur Entscheidung bei fehlgeschlagener Prüfung auf.

3. Anfrage klassifizieren

Eine einzelne Nachricht kann mehrere Rechte enthalten. Klassifizieren Sie jedes Recht separat, da Auskunft, Löschung, Einschränkung, Widerspruch und Datenübertragbarkeit unterschiedliche Entscheidungslogik und unterschiedliche Nachweise erfordern. Kennzeichnen Sie außerdem potenzielle Beschwerden, Beschäftigtenangelegenheiten, Daten von Kindern, besondere Kategorien personenbezogener Daten und mögliche Datenschutzverletzungen.

4. Das Inventar durchsuchen, nicht nur offensichtliche Systeme

Hier wird ISO/IEC 27001:2022 praktisch. Zenith Blueprint [ZB], Phase Controls in Action, Schritt 22, weist darauf hin, dass der Inventarumfang breiter ist, als viele Organisationen erwarten:

Der Geltungsbereich dieses Inventars ist breiter, als vielen bewusst ist. Es sollte umfassen:

✓ Physische Assets: Laptops, Server, Telefone, Backup-Bänder, Wechseldatenträger, gedruckte
Aufzeichnungen.
✓ Digitale Assets: Dokumente, Datenbestände, Repositories, E-Mails, Quellcode, in der Cloud gespeicherte
Dateien.
✓ Logische Assets: Benutzerkonten, Zugangsdaten, Schlüssel, Softwarelizenzen, Programmierschnittstellen.
✓ Servicebezogene Assets: SaaS-Plattformen, Managed Security Services, ausgelagerte
Speicherung.
✓ Menschen als Assets: nicht im Sinne einer Kommodifizierung, sondern im Hinblick auf zugewiesene Verantwortlichkeiten,
Zugriff und rollenbedingte Exposition gegenüber Informationen.

Schritt 22 erläutert außerdem die Verantwortlichkeit:

Jedes Asset sollte einen definierten Verantwortlichen haben – nicht die Person, die es nutzt, sondern die Person, die für
Nutzung, Schutz und Lebenszyklus rechenschaftspflichtig ist. Verantwortlichkeit ist wesentlich für die Ausrichtung der Maßnahmen: wer das
Asset klassifiziert (5.10), wer über seine Zugriffsstufe entscheidet (8.3), wer seine Löschung veranlasst (8.10), wer sicherstellt,
dass es zurückgegeben wird (5.9 überschneidet sich subtil mit Verfahren zur Rückgabe von Vermögenswerten).

In Zenith Controls: Der Cross-Compliance-Leitfaden [ZC] wird ISO/IEC 27002:2022-Maßnahme 5.9, Inventar von Informationen und anderen zugehörigen Assets, als präventive Maßnahme behandelt, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Das zugehörige Cybersicherheitskonzept ist Identify, die operative Fähigkeit ist Asset-Management, und die Sicherheitsdomänen umfassen Governance, Ecosystem und Protection.

Für DSARs bedeutet das: Das Inventar ist keine IT-Tabelle. Es ist die Karte, die Datenschutz, Recht und Sicherheit zeigt, wo personenbezogene Daten vorhanden sein können.

5. Offenlegung prüfen, schwärzen und genehmigen

Eine DSAR-Antwort sollte kein Roh-Export sein. Die Prüfung muss personenbezogene Daten anderer Personen, vertrauliche Geschäftsinformationen, rechtlich privilegierte Informationen, sicherheitssensitive Daten, Betrugssignale und Daten außerhalb des Anfrageumfangs schützen.

Die Genehmigung sollte risikobasiert erfolgen. Routinemäßige Auskunftsantworten können durch den Datenschutzkoordinator oder Datenschutzbeauftragten genehmigt werden. Anfragen mit Bezug zu Beschäftigten, Gerichtsverfahren, besonderen Datenkategorien, Kindern, Betrug, Sicherheitsprotokollen oder großen Exporten sollten die Rechtsabteilung, HR oder die Sicherheitsleitung einbeziehen.

6. Sicher bereitstellen

Hängen Sie keine großen unverschlüsselten Dateien an E-Mails an. Nutzen Sie authentifizierte Portale, verschlüsselte Dateien mit separater Passwortübermittlung oder sichere Übertragungslinks mit Ablaufdatum und Zugriffsprotokollierung. Erfassen Sie Bereitstellungsmethode, Datum, Empfängerkonto, Ablaufdatum und, soweit verfügbar, Bestätigung.

7. Mit Nachweisen abschließen

Die Richtlinie zu Datenschutz und Privatsphäre [P17], Klausel 6.4.3, ist eindeutig:

Alle ergriffenen Maßnahmen müssen zu Auditzwecken protokolliert werden, einschließlich Entscheidungen zur Ablehnung von Anfragen.

Die Richtlinie zu Datenschutz und Privatsphäre - SME [P17S], Klausel 6.5.4, legt fest:

Alle Antworten auf Anfragen betroffener Personen müssen in einem sicheren Register protokolliert werden, wobei der Zugriff auf den Datenschutzkoordinator und die Geschäftsführung beschränkt ist.

Eine DSAR ist nicht abgeschlossen, wenn die E-Mail versendet wurde. Sie ist abgeschlossen, wenn das Register Anfrage, Identitätsprüfung, Entscheidungen, durchsuchte Systeme, Antwort, Ausnahmen, Genehmigungen, Bereitstellung und Abschluss zeigt.

Löschung ist kontrollierte Vernichtung, kein Löschknopf

Löschanfragen zeigen, ob Datenschutz in Systeme eingebaut oder nach dem Launch nur angeflanscht wurde.

Clarysecs unternehmensweite Richtlinie zur Datenaufbewahrung und Entsorgung [P14], Rollen und Verantwortlichkeiten, Klausel 4.3.3, weist die Verantwortung der Rolle zu, die:

auf Löschanfragen reagiert und die fristgerechte, überprüfbare Löschung personenbezogener Daten sicherstellt, soweit dies erforderlich ist.

Die Formulierung „soweit dies erforderlich ist“ ist entscheidend. Löschung nach GDPR ist nicht absolut. Organisationen müssen Daten unter Umständen aufgrund gesetzlicher Pflichten, Audits, Steuern, regulatorischer Pflichten, Betrugsprävention, Sicherheit, Gerichtsverfahren oder zur Begründung, Ausübung oder Verteidigung von Rechtsansprüchen aufbewahren. Der Workflow muss eine rechtmäßige Aufbewahrungs- und Ausnahmeentscheidung enthalten.

Zenith Blueprint [ZB], Phase Controls in Action, Schritt 19, erläutert ISO/IEC 27002:2022-Maßnahme 8.10, Informationslöschung, in operativen Begriffen:

Diese Maßnahme stellt sicher, dass Daten nicht länger als erforderlich aufbewahrt werden und, wenn sie nicht mehr
benötigt werden, sicher und zuverlässig gelöscht werden müssen. Viele Organisationen sammeln im Laufe der Zeit große
Datenmengen an; ohne klaren Löschprozess können diese Daten jedoch ungenutzt
und ungeschützt verbleiben und das Risiko von Offenlegung, Datenschutzverletzung oder regulatorischem Verstoß still erhöhen.

Außerdem warnt der Blueprint:

Vergessen Sie Backups und archivierte Systeme nicht; diese enthalten häufig historische Daten deutlich länger als ihren
operativen Wert. Löschrichtlinien müssen sich erstrecken auf:

✓ Einstellungen zur Backup-Aufbewahrung,
✓ Snapshot-Lebenszyklen,
✓ archivierte E-Mail- oder Dokumenten-Repositories.

Und er schließt mit dem Nachweis:

Der Löschprozess selbst muss protokolliert und bei risikoreichen oder regulierten Daten
überprüft oder genehmigt werden. Dies stellt Nachvollziehbarkeit sicher und schützt vor versehentlicher oder
unbefugter Vernichtung wertvoller Aufzeichnungen.

In Zenith Controls [ZC] wird ISO/IEC 27002:2022-Maßnahme 8.10, Informationslöschung, als präventive Maßnahme mit Fokus auf Vertraulichkeit abgebildet, ausgerichtet am Cybersicherheitskonzept Protect und verknüpft mit den operativen Fähigkeiten Information Protection sowie Legal and Compliance.

Für komplexe Cloud-Architekturen kann kryptografische Löschung geeignet sein, wenn sie korrekt konzipiert ist. Wenn personenbezogene Daten mit einem subjekt- oder mandantenspezifischen Schlüssel verschlüsselt sind, kann die Vernichtung des Schlüssels die Daten dauerhaft unzugänglich machen, auch wenn verschlüsselte Reste bis zur planmäßigen Rotation in Backups verbleiben. Dies muss sorgfältig entworfen, dokumentiert, getestet und genehmigt werden. Es ist kein Ausweichverfahren für eine schlechte Löscharchitektur.

Anwendungsbereitschaft ist daher wesentlich. Clarysecs Richtlinie zu Anforderungen an die Anwendungssicherheit - SME [P09S], Klausel 6.5.1.3, verlangt von Anwendungen:

den sicheren Export und die Löschung personenbezogener Daten zu ermöglichen, wenn dies gesetzlich erforderlich ist (z. B. GDPR Artikel 17 – Recht auf Löschung).

Wenn Produktteams keine Export- und Löschfunktionen einbauen, werden Datenschutzteams zu Datenbankskripten, Lieferanten-Tickets und uneinheitlicher manueller Arbeit gezwungen.

Legal Hold und Aussetzung der Löschung

Ein ausgereifter Lösch-Workflow muss einen „nicht löschen“-Pfad enthalten. Das ist keine Entschuldigung, Löschung zu ignorieren. Es ist eine kontrollierte Ausnahme.

Clarysecs KMU-Datenaufbewahrungsrichtlinie und Richtlinie zur sicheren Entsorgung - SME [P14S], Governance-Anforderungen, Klausel 5.4, legt fest:

Daten, die einem Legal Hold und einer Löschsperre unterliegen (z. B. bei Gerichtsverfahren, Audit oder Untersuchung), müssen im System eindeutig gekennzeichnet und vor Löschung geschützt werden, auch wenn die geplante Aufbewahrungsfrist abgelaufen ist.

Die Richtlinie zur Datenaufbewahrung und Entsorgung [P14], Klausel 6.4.1, spiegelt denselben Grundsatz wider:

Wird ein Legal Hold und eine Löschsperre angeordnet (z. B. wegen eines anhängigen Gerichtsverfahrens, einer Untersuchung oder eines Audits), müssen Daten, die ansonsten der Vernichtung unterliegen würden, über ihre normale Aufbewahrungsfrist hinaus aufbewahrt werden.

Auditoren wollen beide Seiten sehen: Nachweise fristgerechter Löschung und Nachweise gerechtfertigter Aufbewahrung.

Einschränkung der Verarbeitung: das unterschätzte Recht

Anträge auf Einschränkung verlangen nicht immer Löschung. Sie verlangen, dass die Organisation die aktive Verarbeitung begrenzt und Daten zugleich unter kontrollierten Bedingungen aufbewahrt.

Typische Beispiele sind:

• Ein Kunde bestreitet die Richtigkeit und verlangt, dass Sie die Daten während der Prüfung nicht verwenden.
• Ein ehemaliger Mitarbeiter widerspricht der Verarbeitung, der Datensatz wird jedoch für Rechtsansprüche benötigt.
• Ein Nutzer verlangt Löschung, aber minimale Daten müssen zur Führung einer Sperrliste aufbewahrt werden.
• Eine Betrugsuntersuchung erfordert Aufbewahrung, aber keine normale operative Nutzung.

Ein praktikabler Einschränkungs-Workflow sollte eine rechtliche Entscheidung, ein Systemkennzeichen, eine Anpassung der Zugriffskontrolle, Marketing-Unterdrückung, Ausschluss aus Analysen, Lieferantenanweisung, regelmäßige Überprüfung und Ausnahmenachweise enthalten.

In Zenith Controls [ZC] wird ISO/IEC 27002:2022-Maßnahme 5.34, Datenschutz und Schutz von PII, als präventive Maßnahme behandelt, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Sie wird Identify und Protect zugeordnet, mit den operativen Fähigkeiten Information Protection und Legal and Compliance.

Zenith Blueprint [ZB], Phase Controls in Action, Schritt 23, fasst den Audit-Test zusammen:

Bestätigen Sie, dass Ihre Organisation Datenschutzmaßnahmen (5.34) umgesetzt hat, die mit
den geltenden gesetzlichen Anforderungen abgestimmt sind. Prüfen Sie die Klassifizierung von PII, geeignete Zugriffskontrollen, sichere
Handhabungspraktiken und Sensibilisierungsschulung. Validieren Sie, ob Auskunftsanfragen betroffener Personen, Datenlöschung
oder Verarbeitungsprotokolle operativ unterstützt werden – nicht nur durch Richtlinien.

Die zentrale Formulierung lautet: „operativ unterstützt werden – nicht nur durch Richtlinien“.

DSAR-Workflows auf ISO/IEC 27001:2022-Nachweise abbilden

ISO/IEC 27001:2022 ersetzt GDPR nicht. Sie ordnet Nachweise.

Die Klauseln 6.1.1 bis 6.1.3 verlangen Risikobeurteilung, Risikobehandlung, Risikoakzeptanzkriterien, Risikoverantwortliche, Maßnahmengestaltung, eine Anwendbarkeitserklärung und einen Risikobehandlungsplan. DSAR-Risiken umfassen unbefugte Offenlegung, verpasste Fristen, unvollständige Löschung, unrechtmäßige Aufbewahrung, übermäßige Identitätsprüfung, mangelnde Mitwirkung von Lieferanten und die Unfähigkeit, Verarbeitung einzuschränken.

Klausel 8.1 verlangt, dass Organisationen ISMS-Prozesse planen, umsetzen und steuern, dokumentierte Nachweise aufbewahren, Änderungen kontrollieren und sicherstellen, dass extern bereitgestellte Prozesse, Produkte und Dienstleistungen mit Relevanz für das ISMS kontrolliert werden. Das passt zu DSAR-Abläufen, weil Anfragen interne Funktionen und externe Auftragsverarbeiter durchlaufen.

Ein belastbares Nachweispaket umfasst das DSR-Verfahren, DSR-Register, Verarbeitungsregister, Asset-Inventar, Datenaufbewahrungsplan, Legal-Hold-Register, Verfahren zur Identitätsprüfung, Schwärzungsleitlinien, Methode zur sicheren Offenlegung, Löschverfahren, Verfahren zur Einschränkung, Lieferanten-Playbook, Ausnahmenregister, Schulungsnachweise, Ergebnisse interner Audits und Berichte aus der Managementbewertung.

Ein praktischer Workflow für Auskunft, Löschung und Einschränkung

Dieser Workflow verwandelt Sarahs Krise in einen auditierbaren Prozess. Jede Phase hat einen Verantwortlichen, eine Kontrollgrundlage und Nachweise.

Cross-Compliance-Wert über GDPR hinaus

Ein DSAR-Workflow hat seine Grundlage in GDPR, aber dieselben Maßnahmen unterstützen weitergehende Rahmenwerke.

NIS2 Artikel 20 macht Cybersicherheit zu einer Managementverantwortung für wesentliche und wichtige Einrichtungen. Artikel 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Vorfallmanagement, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, Wirksamkeitsbewertung, Cyberhygiene, Schulung, Zugriffskontrolle, Asset-Management, Authentifizierung und sichere Kommunikation. DSARs stützen sich auf viele dieser Fähigkeiten.

DORA gilt seit dem 17. Januar 2025 für viele Finanzunternehmen und legt einheitliche Anforderungen an das Management von IKT-Risiken, Vorfallmeldung, Resilienztests und IKT-Drittparteienrisiken fest. Artikel 5 und 6 verlangen Governance und dokumentiertes Management von IKT-Risiken. Artikel 17 bis 20 behandeln Vorfallerkennung, Klassifizierung, Eskalation, Kommunikation und Abschluss. Artikel 24 bis 30 behandeln Resilienztests, IKT-Drittparteienrisiken, Serviceregister, Auditrechte, Datenstandort, Unterstützung bei Vorfällen und Exit-Strategien. Ein Fintech, das DSARs über Cloud-Plattformen bearbeitet, sollte die Bearbeitung von Datenschutzanfragen mit seinem IKT-Serviceregister abstimmen.

NIST CSF 2.0 hilft, dieselbe Arbeit in Cybersicherheitsergebnisse zu übersetzen. GOVERN adressiert gesetzliche, regulatorische und vertragliche Anforderungen, Risikostrategie, Rollen, Richtlinien und Aufsicht. IDENTIFY und PROTECT passen stark zu Asset-Transparenz, Datenklassifizierung, Zugriffskontrolle, Löschung, Lieferanten-Governance und Datenschutz.

COBIT 2019 stellt Governance-Fragen. Wer ist Eigentümer des Prozesses? Welche Ziele sind definiert? Wie wird Leistung gemessen? Wie werden Ausnahmen genehmigt? Wie wird Assurance erreicht? DSAR-Nachweise können Ziele wie APO13 Managed Security, APO14 Managed Data und DSS06 Managed Business Process Controls unterstützen.

Die Perspektive des Auditors

Erstellen Sie nicht für jedes Rahmenwerk separate Nachweise. Erstellen Sie einen verlässlichen DSAR-Workflow und bilden Sie ihn sauber ab.

DSAR-Kennzahlen, die das Management sehen sollte

Management kann nicht überwachen, was es nicht sieht. Nützliche Kennzahlen umfassen Anfragevolumen nach Rechtetyp, durchschnittliche Bestätigungszeit, durchschnittliche Abschlusszeit, Fristeneinhaltung, Quoten für Identitätsklärungen, Lösch-Ausnahmen, Legal-Hold-Fälle, Antwortzeiten von Lieferanten, Teilablehnungen, während der Bearbeitung identifizierte Vorfälle und offene Abhilfemaßnahmen.

Diese Kennzahlen zeigen, ob Rechte betroffener Personen operativ beherrscht werden oder von Heldentaten abhängen.

Häufige Lücken in der DSAR-Bereitschaft

Clarysec sieht in SaaS-Unternehmen, Fintechs, professionellen Dienstleistungsunternehmen und cloud-first KMU regelmäßig dieselben Schwächen:

• Kein Verantwortlicher für jedes System, das personenbezogene Daten enthält
• Verarbeitungsregister nicht mit der tatsächlichen SaaS-Nutzung abgestimmt
• Marketing-, Analyse- und Data-Warehouse-Plattformen von Suchen ausgeschlossen
• Kein dokumentierter Standard zur Identitätsprüfung
• Keine Schwärzungsprüfung vor Offenlegung
• Löschung in der Produktion ohne Behandlung von Backups
• Keine Legal-Hold-Prüfung vor Löschung
• Einschränkung wird manuell ohne Systemkennzeichen bearbeitet
• Lieferantenverträge enthalten keine Bedingungen zur DSAR-Unterstützung
• Ablehnungen und Teilablehnungen sind nicht dokumentiert
• Keine Stichprobenprüfung abgeschlossener DSARs im internen Audit
• Frontline-Mitarbeitende sind nicht geschult, Anfragen zu erkennen

Ihre DSAR-Bereitschaftscheckliste für 2026

Nutzen Sie dies als Reifegradtest:

• Haben wir einen dokumentierten Prozess für DSR-Eingang, Validierung, Nachverfolgung und Antwort?
• Bestätigen wir Anfragen innerhalb eines definierten internen SLA?
• Führen wir ein sicheres DSR-Register mit eingeschränktem Zugriff?
• Haben wir ein aktuelles Verarbeitungsregister mit Kategorien, Zwecken, Rechtsgrundlagen und Aufbewahrungsfristen?
• Kennen wir jedes System, jede SaaS-Plattform, jedes Repository und jeden Lieferanten, der personenbezogene Daten enthalten kann?
• Hat jedes relevante Asset einen rechenschaftspflichtigen Verantwortlichen?
• Können wir personenbezogene Daten sicher exportieren?
• Können wir personenbezogene Daten sicher löschen, soweit dies gesetzlich erforderlich ist?
• Können wir Verarbeitung technisch oder prozessual einschränken?
• Prüfen wir Legal Hold vor der Löschung?
• Dokumentieren wir Ablehnungen, Teilablehnungen und Ausnahmeentscheidungen?
• Unterstützen Lieferantenverträge die DSAR-Bearbeitung?
• Testen wir den Workflow durch interne Audits oder Tabletop-Übungen?
• Berichten wir die DSAR-Leistung an das Management?
• Bilden wir DSAR-Maßnahmen in der ISO/IEC 27001:2022-Risikobehandlung und der Anwendbarkeitserklärung ab?

Wenn mehrere Antworten „nicht konsistent“ lauten, kann die nächste Anfrage die Lücke offenlegen.

Rechte betroffener Personen in auditbereite Nachweise überführen

Rechte betroffener Personen erfordern 2026 mehr als gute Absichten und ein Datenschutzpostfach. Sie erfordern einen Workflow, der Daten finden, Identität prüfen, rechtmäßige Entscheidungen treffen, Lieferanten koordinieren, Offenlegung schützen, Löschung ausführen, Einschränkung durchsetzen und Nachweise aufbewahren kann.

Clarysec unterstützt Organisationen dabei, diesen Workflow aufzubauen, ohne eine parallele Compliance-Bürokratie zu schaffen. Beginnen Sie mit Zenith Blueprint, um Rechte betroffener Personen in der richtigen ISMS-Phase und den passenden Schritten zu verorten. Nutzen Sie Clarysecs Richtlinie zu Datenschutz und Privatsphäre, Richtlinie zu Datenschutz und Privatsphäre - SME, Richtlinie zur Datenaufbewahrung und Entsorgung, Datenaufbewahrungsrichtlinie und Richtlinie zur sicheren Entsorgung - SME und Richtlinie zu Anforderungen an die Anwendungssicherheit - SME, um Verantwortlichkeit und operative Regeln festzulegen.

Nutzen Sie anschließend Zenith Controls, um ISO/IEC 27002:2022-Maßnahmen 5.9, 5.34 und 8.10 in Cross-Compliance-Nachweise für GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 und COBIT 2019-Assurance zu überführen.

Wenn Sie wissen möchten, ob Ihre Workflows für DSAR, Löschung und Einschränkung morgen ein Audit bestehen würden, kann Clarysec den Prozess mit Ihnen testen, Lücken schließen und das Nachweispaket aufbauen, bevor die nächste Anfrage eintrifft. Laden Sie die relevanten Clarysec-Richtlinienvorlagen herunter oder buchen Sie eine DSAR-Bereitschaftsbewertung, um von reaktiver Bearbeitung zu gesteuerten, auditbereiten Datenschutzabläufen zu wechseln.