DSGVO-Audit 2026: wie Konformität geprüft wird und nicht nur Dokumentation

Rechenschaftspflicht als Grundprinzip des Audits

Art. 5 Abs. 2 DSGVO begründet die Rechenschaftspflicht: Der Verantwortliche ist für die Einhaltung der Grundsätze verantwortlich und muss sie nachweisen können. Art. 24 verlangt geeignete technische und organisatorische Maßnahmen sowie deren Überprüfung und Aktualisierung, soweit erforderlich.^[1] Ein Audit ist eine Methode zur Gewinnung von Nachweisen, ein positiver Bericht erzeugt aber keine Konformität von selbst.

Es gibt kein allgemeines "DSGVO-Konformitätszertifikat". Zertifizierungsmechanismen nach Art. 42 sind freiwillig und mindern die Verantwortung von Verantwortlichem oder Auftragsverarbeiter nicht. Auch ein Audit muss seinen Scope klar benennen: Eine Schlussfolgerung zum Recruiting sagt nichts über Videoüberwachung, Marketing oder ein medizinisches System, wenn diese Bereiche nicht untersucht wurden.

Ein guter Bericht sollte mindestens vier Arten von Findings unterscheiden:

• Verstoß gegen eine konkrete Rechtspflicht, etwa fehlende Rechtsgrundlage oder nicht erfüllte Informationspflicht;
• Risiko für Rechte und Freiheiten, etwa zu weitreichender Zugriff auf sensible Daten;
• Sicherheitsmangel, etwa ein unzureichend geschütztes Administratorkonto;
• fehlender Wirksamkeitsnachweis, wenn eine Maßnahme behauptet wird, aber Test, Aufzeichnung, Verantwortlicher oder Ergebnis fehlen.

Zuerst die tatsächliche Verarbeitung abbilden

Das Audit sollte mit einer realen Karte von Prozessen, Systemen, Datensätzen, Datenflüssen und Empfängern beginnen. Das Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 ist eine wichtige Quelle, darf aber nicht automatisch als wahrer Ist-Zustand gelten. Es ist mit Anwendungskonfiguration, Verträgen, Logs, Formularen, Konten, Integrationen, Arbeitskopien und tatsächlicher Praxis abzugleichen.

Auch Rollen müssen korrekt zugeordnet werden. Der Verantwortliche bestimmt Zwecke und Mittel. Ein Auftragsverarbeiter verarbeitet im Auftrag des Verantwortlichen. Gemeinsam Verantwortliche bestimmen Zwecke und Mittel für den gemeinsamen Verarbeitungsteil gemeinsam. Die Bezeichnung im Vertrag entscheidet nicht, wenn die tatsächlichen Verhältnisse etwas anderes zeigen.^[3]

Die Ausnahme des Art. 30 für Organisationen mit weniger als 250 Beschäftigten ist eng. Sie greift nicht, wenn die Verarbeitung ein Risiko verursachen kann, nicht nur gelegentlich erfolgt oder besondere Kategorien beziehungsweise Daten zu strafrechtlichen Verurteilungen und Straftaten umfasst. Dauerhafte Personal-, Kunden- oder Nutzerprozesse verlangen daher häufig mehr als einen bloßen Verweis auf die Mitarbeiterzahl.

Zwecke, Rechtsgrundlagen und die Grundsätze des Art. 5

Jeder Verarbeitungszweck sollte eine geeignete Rechtsgrundlage aus Art. 6 haben. Einwilligung ist nur eine mögliche Grundlage und darf nicht automatisch gewählt werden. Bei besonderen Kategorien personenbezogener Daten ist zusätzlich eine Voraussetzung aus Art. 9 erforderlich. Das Audit prüft dies je Zweck und Verarbeitungsvorgang und nicht pauschal für ein gesamtes System.^[1]

Auch die Grundsätze aus Art. 5 sind zu prüfen: Rechtmäßigkeit, Verarbeitung nach Treu und Glauben und Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung sowie Integrität und Vertraulichkeit. Ein Geburtsdatum kann in einem Prozess erforderlich und in einem einfachen Kontaktformular überflüssig sein.

Aufbewahrung darf ebenfalls nicht durch eine einzige Frist für die gesamte Organisation geregelt werden. Zweck, Sondervorschriften, Verjährung und das auslösende Ereignis müssen berücksichtigt werden. Der Satz "Wir speichern Daten fünf Jahre" ohne Angabe, ab wann die Frist läuft, ist keine Aufbewahrungsregel, sondern nur ihr Anschein.

Privacy by Design und Privacy by Default

Art. 25 verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen.^[1] Ein Audit sollte deshalb Beschaffungs- und Änderungsprozesse prüfen: Werden vor Inbetriebnahme eines neuen Systems Zweck, Datenumfang, Berechtigungen, Aufbewahrung, Schnittstellen, Logging, Dienstleister, Übermittlungen und Risiken bewertet?

Voreinstellungen sollen Verarbeitung auf das für den jeweiligen Zweck Erforderliche beschränken. Daraus folgt keine einzige technische Standardkonfiguration für alle Systeme. Gemeint ist ein bewusster Entwurf, bei dem Nutzer nicht erst übermäßige Erhebung oder Veröffentlichung selbst abschalten müssen. Gibt es in der Organisation keinen Moment, in dem jemand diese Fragen vor der Einführung stellt, bleibt Art. 25 eine Aussage in einer Richtlinie.

Betroffenenrechte: Verfahren müssen systemübergreifend funktionieren

Die Prüfung von Betroffenenrechten endet nicht beim Lesen einer Prozedur. Aussagekräftiger ist die Nachverfolgung eines realen oder kontrollierten Antrags von der Identitätsprüfung über die Datensuche in eigenen und Auftragsverarbeiter-Systemen bis zu Entscheidung, Antwort und Fristnachweis.

Grundsätzlich antwortet der Verantwortliche unverzüglich, spätestens innerhalb eines Monats. Die Frist kann wegen Komplexität oder Zahl der Anträge um zwei weitere Monate verlängert werden. Die betroffene Person ist aber innerhalb des ersten Monats über Verlängerung und Gründe zu informieren.^[1]

Das Auskunftsrecht bedeutet nicht automatisch die Herausgabe jedes Originaldokuments. Der Verantwortliche muss eine Kopie der verarbeiteten personenbezogenen Daten bereitstellen, die eine wirksame Ausübung der Rechte ermöglicht und Rechte und Freiheiten anderer berücksichtigt. Die Rechtsprechung des EuGH verlangt eine originalgetreue und verständliche Wiedergabe der Daten.^[4]

Dienstleister, Auftragsverarbeiter und Shadow IT

Ein Vertrag nach Art. 28 ist erforderlich, wenn ein Dienstleister personenbezogene Daten im Auftrag verarbeitet. Das Audit prüft nicht nur das Vorhandensein von Klauseln, sondern deren Übereinstimmung mit der realen Leistung: Gegenstand und Dauer, Zweck, Daten- und Betroffenenkategorien, Vertraulichkeit, Sicherheit, Unterauftragsverarbeiter, Unterstützung bei Rechten und Verletzungen, Rückgabe oder Löschung sowie Auditrechte.^[1]

Das Lieferanteninventar sollte auch Werkzeuge enthalten, die Fachbereiche oder Beschäftigte selbst einführen: kostenlose Apps, Testkonten, OAuth-Integrationen, Analysewerkzeuge, Ticketsysteme, Repositories, Transkriptionsdienste und generative KI. Die Aussage eines Anbieters "GDPR compliant" beweist nicht, dass die konkrete Nutzung durch die Organisation konform ist.

Die Europäische Kommission hat Standardklauseln zwischen Verantwortlichen und Auftragsverarbeitern für Art. 28 veröffentlicht.^[5] Sie sind nicht mit den Standardvertragsklauseln zu verwechseln, die als Instrument für Drittlandübermittlungen nach Kapitel V verwendet werden.^[6] Es handelt sich um zwei verschiedene Instrumente mit unterschiedlichem Zweck, die in der Dokumentation regelmäßig vertauscht werden.

Art. 32: risikoadäquate Sicherheit

Die DSGVO gibt keine allgemeine Produktliste vor. Verantwortliche und Auftragsverarbeiter berücksichtigen Stand der Technik, Implementierungskosten, Art, Umfang, Umstände und Zwecke der Verarbeitung sowie Risiken für Personen. Pseudonymisierung, Verschlüsselung, Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit, Wiederherstellbarkeit sowie regelmäßige Überprüfung und Bewertung der Wirksamkeit werden in Art. 32 genannt; ihre Auswahl muss risikobasiert erfolgen.^[1]

Ein technisches Audit kann umfassen:

• Identitätsmanagement und Kontenlebenszyklus;
• privilegierten Zugriff und MFA, soweit begründet;
• Verschlüsselung und Schlüsselmanagement;
• Backups, Restore-Fähigkeit und Resilienz;
• Updates, Schwachstellenmanagement und Hardening;
• Segmentierung und Verkehrsbegrenzung;
• Logging und Incident Detection;
• Endgeräte-, Mobilgeräte- und E-Mail-Sicherheit;
• Lieferantensicherheit und Fernzugriffe;
• sichere Löschung von Daten und Datenträgern.

Verschlüsselung korrigiert weder übermäßige Datenerhebung noch Missbrauch durch berechtigte Benutzer. Ein Backup beweist keine Resilienz, wenn niemand es wiederherstellen kann. Der Funktionsnachweis ist im Audit deshalb wichtiger als der Produktname.

Art. 32 schreibt weder einen universellen jährlichen Penetrationstest noch ein bestimmtes Scanintervall vor. Verlangt werden regelmäßige Tests und Bewertungen der Wirksamkeit entsprechend dem Risiko. Die Frequenz sollte sich an Systemmerkmalen, Änderungen, Vorfällen, Exposition und weiteren anwendbaren Vorschriften orientieren.

Verletzungen des Schutzes personenbezogener Daten

Nicht jeder Cybersecurity-Vorfall ist eine Datenschutzverletzung, und nicht jede Datenschutzverletzung muss der Aufsichtsbehörde gemeldet werden. Zuerst ist festzustellen, ob eine Sicherheitsverletzung zur unbeabsichtigten oder unrechtmäßigen Vernichtung, zum Verlust, zur Veränderung, unbefugten Offenlegung oder zum unbefugten Zugang zu personenbezogenen Daten geführt hat. Danach bewertet der Verantwortliche das Risiko für Personen.^[1]

Ist ein Risiko wahrscheinlich, erfolgt die Meldung unverzüglich und möglichst innerhalb von 72 Stunden nach Bekanntwerden. Bei hohem Risiko kann zusätzlich eine Benachrichtigung der betroffenen Personen erforderlich sein. Ein Auftragsverarbeiter informiert den Verantwortlichen unverzüglich nach Bekanntwerden.

Ein Audit sollte eine Stichprobe von Vorfällen untersuchen, einschließlich nicht gemeldeter Fälle. Zentraler Nachweis ist die dokumentierte Begründung: Was geschah, welche Daten und Personen waren betroffen, welche Maßnahmen wirkten, wie wurden Wahrscheinlichkeit und Schwere bewertet und wer genehmigte die Entscheidung? Eine unterlassene Meldung ist zulässig, wenn sie begründbar ist; problematisch ist das Fehlen jeder Entscheidungsspur.

DPIA: wann hohes Risiko zu bewerten ist

Eine Datenschutz-Folgenabschätzung ist erforderlich, wenn eine Art der Verarbeitung, insbesondere unter Einsatz neuer Technologien, voraussichtlich ein hohes Risiko für Rechte und Freiheiten zur Folge hat. Art. 35 nennt Beispiele, und die Aufsichtsbehörde veröffentlicht eine Liste von Verarbeitungsvorgängen, für die eine DPIA erforderlich ist.^[1][7]

Das Audit sollte nicht nur fragen "Gibt es eine DPIA?". Zu prüfen sind Mechanismen zur Erkennung relevanter Projekte, Durchführung vor Beginn risikoreicher Verarbeitung, Maßnahmen zur Risikominderung und Aktualisierung bei Risikoänderungen.

Beschäftigtenüberwachung, Profiling, biometrische Daten, neue Analytik oder KI können die Wahrscheinlichkeit hohen Risikos erhöhen, führen aber nicht automatisch bei jeder Implementierung zur DPIA. Entscheidend sind die konkrete Verarbeitung und die Kriterien des Art. 35.

Übermittlungen außerhalb des EWR

Ein häufiger Auditfehler besteht darin, Serverstandort mit fehlender Drittlandübermittlung gleichzusetzen. Daten können in Frankfurt gespeichert werden, während Fernadministration, Support, Telemetrie, Backups oder Unterauftragsverarbeiter außerhalb des EWR liegen. Die gesamte Verarbeitungskette ist zu prüfen.

Eine Übermittlung kann sich unter anderem auf einen Angemessenheitsbeschluss oder geeignete Garantien wie Standardvertragsklauseln stützen.^[6] Nach Schrems II beendet die Unterzeichnung der Klauseln die Prüfung nicht: Der Datenexporteur muss beurteilen, ob im konkreten Kontext ein im Wesentlichen gleichwertiges Schutzniveau erreicht wird, und nötigenfalls ergänzende Maßnahmen einsetzen. Der EDSA hat hierzu detaillierte Empfehlungen veröffentlicht.^[8][9]

Das EU-US Data Privacy Framework ist am 29. August 2026 weiterhin ein Mechanismus für US-Organisationen, die tatsächlich daran teilnehmen und soweit die konkrete Zertifizierung reicht. Der Kommissionsbeschluss von 2023 erfasst nicht automatisch jedes US-Unternehmen.^[10]

2025 wies das Gericht der EU die Klage T-553/23 Latombe gegen Kommission ab. Gegen dieses Urteil wurde das Rechtsmittel C-703/25 P eingelegt, das am 29. August 2026 weiterhin anhängig ist.^[11] Ein Audit sollte den Mechanismus daher als aktuell gültig beschreiben und nicht als für alle Zukunft endgültig bestätigt.

DSGVO und künstliche Intelligenz

Generative KI erzeugt mehrere parallele Fragen: Gibt es eine Rechtsgrundlage für die Übermittlung an das Modell? Werden Daten minimiert? Wer ist Verantwortlicher oder Auftragsverarbeiter? Wohin gelangen die Daten? Werden sie für weiteres Training genutzt? Wie lange werden sie aufbewahrt? Wer sieht den Verlauf und wie werden Betroffenenrechte umgesetzt?

Die EDSA-Stellungnahme 28/2024 zu KI-Modellen erläutert unter anderem, dass die Anonymität eines Modells im Einzelfall zu bewerten ist und ein berechtigtes Interesse einen vollständigen Erforderlichkeits- und Abwägungstest voraussetzt. Sie behandelt auch Folgen rechtswidriger Verarbeitung bei der Modellentwicklung für spätere Vorgänge.^[12]

Der AI Act ersetzt die DSGVO nicht. Beide können auf dasselbe System anwendbar sein. 2026 wurde der Zeitplan teilweise geändert: Kapitel III Abschnitte 1-3 gelten für Hochrisiko-Systeme nach Art. 6 Abs. 2 und Anhang III ab 2. Dezember 2027, für Systeme nach Art. 6 Abs. 1 und Anhang I ab 2. August 2028. Die Pflicht zur KI-Kompetenz aus Art. 4 gehört zu Kapitel I und gilt seit 2. Februar 2025.^[13][14]

Datenschutzbeauftragter: Unabhängigkeit und Interessenkonflikte

Ein Datenschutzbeauftragter darf andere Aufgaben wahrnehmen, sofern kein Interessenkonflikt entsteht. Das Audit sollte seine tatsächliche Stellung prüfen: Zugang zur höchsten Leitung, frühzeitige Einbindung, Ressourcen, Weisungsfreiheit bei seinen Aufgaben und die Frage, ob andere Funktionen ihn Zwecke und Mittel bestimmen lassen, die er später unabhängig überwachen soll.^[1][15]

Ein Interessenkonflikt ergibt sich nicht allein aus der Stellenbezeichnung. Wer selbst über Architektur und Verarbeitungszwecke eines Systems entscheidet, kann in Konflikt geraten, wenn dieselbe Person dieses System unabhängig kontrollieren soll.

ISO/IEC 27701:2025

ISO/IEC 27701:2025 ist die aktuelle Ausgabe der Norm für Privacy Information Management Systems und ersetzte die Ausgabe 2019. Sie kann Rollen, Risiken, Prozesse und Nachweise strukturieren, ist aber kein polnisches Recht, und eine Zertifizierung ersetzt keine DSGVO-Konformitätsanalyse.^[16]

Praktisch am nützlichsten ist sie als Dokumentationsgerüst für ein um Datenschutz erweitertes ISMS und nicht als Ersatz für die rechtliche Bewertung konkreter Verarbeitungsvorgänge.

Wie ein nachweisbasiertes Audit durchgeführt wird

Für jeden Bereich eignet sich eine einfache Triangulation:

1. Was erklärt die Organisation in Richtlinie, Verzeichnis oder Vertrag?
2. Was zeigen Konfiguration, Log, Formular, Datensatz oder Stichprobe?
3. Was tun Prozessverantwortliche, Beschäftigte und Dienstleister tatsächlich?

Weichen diese drei Bilder voneinander ab, hat das Audit wahrscheinlich ein wichtigeres Problem gefunden als ein weiteres fehlendes Dokument.

Beispielhafte Stichproben umfassen neue und ausgeschiedene Beschäftigte einschließlich Erteilung und Entzug von Zugängen; Betroffenenanträge und Bearbeitungsfristen; Löschung nach Ablauf von Aufbewahrungsfristen; Einwilligungsnachweise und Widerruf; Auftragsverarbeitungsverträge und Unterauftragsverarbeiter; Remote-Support außerhalb des EWR; Vorfälle und Entscheidungen über Meldung oder Nichtmeldung; Restore-Tests von Backups; neue IT-Projekte und DPIA-Entscheidungen sowie die Nutzung generativer KI durch Beschäftigte.

Bei 4crypto kann die rechtliche Prüfung mit technischer Verifikation von Konfiguration, E-Mail-Sicherheit, Hardening, Schwachstellen und Logging verbunden werden. Die Kriterien müssen getrennt bleiben: Keine technische Schwachstelle beweist keine Datenminimierung, und eine perfekte Datenschutzerklärung beweist keine wirksame Authentisierung.

Häufige Fehler

1. Nur Dokumente auditieren. Die DSGVO betrifft reale Verarbeitung und keinen Ordner.
2. Einwilligung als Standardrechtsgrundlage verwenden. Je nach Prozess können Vertrag, Rechtspflicht, öffentliche Aufgabe oder berechtigtes Interesse einschlägig sein.
3. Daten vorsichtshalber speichern, ohne Aufbewahrungsregeln und Löschmechanismus.
4. Herstellererklärungen zur Compliance an die Stelle einer Prüfung von Rollen, Vertrag, Sicherheit und Übermittlungen setzen.
5. Ein Rechenzentrum in der EU mit fehlender Drittlandübermittlung gleichsetzen.
6. DPIA erst nach Produktivsetzung durchführen, nur um die Projektakte zu vervollständigen.
7. Annehmen, dass eine Enterprise-KI-Version Rechtsgrundlage, Minimierung, Aufbewahrung und Transparenz automatisch löst. Sie kann Sicherheits- und Vertragsbedingungen verbessern, beseitigt aber die Pflichten des Verantwortlichen nicht.

Was der Bericht enthalten sollte

Der Bericht sollte angeben:

• organisatorischen, prozessualen und technischen Scope;
• Kriterien und Rechtsstand;
• Nachweisarten und Stichprobenverfahren;
• Findings mit konkreter Rechtsgrundlage;
• getrennte Bewertung von Risiken für Personen und Sicherheitsmängeln;
• umsetzbare Empfehlungen und Verantwortliche;
• Frist und Nachweis zum Schließen eines Findings;
• Einschränkungen, einschließlich nicht zugänglicher Systeme oder unzureichender Daten.

Der Bericht sollte keine "100% Compliance" unabhängig von Umfang und Zeitpunkt versprechen. Verarbeitung verändert sich mit Systemen, Dienstleistern, Personal und Zwecken. Ein Audit ist Zustandsaufnahme und Prüfung des Governance-Mechanismus, keine dauerhafte Garantie.