Datenschutz & IT-Compliance
Das Vorhandensein einer Richtlinie, einer Kontrollbeschreibung oder eines Sicherheitskonzepts belegt noch nicht, dass die darin genannte Maßnahme im untersuchten System tatsächlich umgesetzt und technisch wirksam ist.
Kurzantwort
Eine technische Prüfung sollte Schutzmaßnahme, Soll-Anforderung, betroffenen Systembereich, konkrete Implementierung, Konfiguration, Nachweise, Prüfverfahren, Ergebnis und Aussagegrenze nachvollziehbar miteinander verbinden.
Besonders wichtig ist die Trennung: dokumentierte Maßnahme ist nicht automatisch implementierte Maßnahme; implementierte Maßnahme ist nicht automatisch wirksame Maßnahme; eine wirksame Einzelmaßnahme belegt kein vollständiges Sicherheits- oder Compliance-Niveau.
Eine praktikable Untersuchungskette lautet: Schutzobjekt → Soll-Anforderung → Maßnahme → Implementierung → Konfiguration → Nachweis → Prüfverfahren → technischer Befund → Wirksamkeitsgrenze → Aussagegrenze.
1. Zuerst muss die konkrete Schutzmaßnahme bestimmt werden
Bezeichnungen wie „Zugriffsschutz“, „Verschlüsselung“ oder „Backup“ sind für eine technische Prüfung regelmäßig zu allgemein.
Zu bestimmen ist, welche konkrete Maßnahme an welchem System, Dienst, Prozess oder Datenbestand untersucht werden soll.
2. Eine Prüfung benötigt einen nachvollziehbaren Soll-Bezug
Eine Maßnahme kann nur gegen einen bestimmten technischen oder dokumentierten Maßstab geprüft werden.
Der Soll-Bezug kann beispielsweise aus einer freigegebenen Richtlinie, einem Sicherheitskonzept, einer technischen Spezifikation, einem Kontrollkatalog oder einer konkret benannten Anforderung stammen.
3. Dokumentation beweist keine technische Implementierung
Eine Richtlinie kann vorgeben, dass Mehrfaktor-Authentifizierung, Verschlüsselung oder regelmäßige Backups eingesetzt werden sollen.
Daraus folgt nicht, dass diese Maßnahme im untersuchten Systemzustand tatsächlich aktiviert, vollständig ausgerollt oder korrekt konfiguriert war.
4. Implementierung beweist noch keine Wirksamkeit
Eine vorhandene Sicherheitsfunktion kann technisch aktiv sein und dennoch das definierte Schutzziel nicht oder nur teilweise erreichen.
Deshalb sind Implementierungsnachweis und Wirksamkeitsprüfung getrennt zu dokumentieren.
5. Wirksamkeit benötigt ein konkretes Prüfziel
Die Aussage „die Maßnahme funktioniert“ ist ohne definiertes Prüfziel regelmäßig zu unbestimmt.
Zu klären ist beispielsweise, ob ein Zugriff verhindert, eine Wiederherstellung ermöglicht, eine Änderung erkannt, ein Ereignis protokolliert oder ein Ausfall überbrückt werden soll.
6. Prüfverfahren und Erfolgskriterium sollten vor dem Ergebnis feststehen
Die Europäische Kommission nennt im Zusammenhang mit der Sicherheit personenbezogener Daten unter anderem einen Prozess zur regelmäßigen Prüfung und Bewertung der Wirksamkeit technischer und organisatorischer Maßnahmen.
Für eine technische Untersuchung sollte deshalb nachvollziehbar sein, welche Prüfung durchgeführt wird und welches Ergebnis als bestanden, teilweise bestanden oder nicht nachweisbar gilt.
7. System-, Software- und Konfigurationsstand gehören zum Untersuchungsgegenstand
Eine Schutzmaßnahme kann sich durch Softwareupdates, Konfigurationsänderungen, neue Rollen, geänderte Netzpfade oder andere Betriebsparameter verändern.
Ein technischer Befund sollte deshalb auf den tatsächlich untersuchten Zustand bezogen werden.
8. Schutzmaßnahme und geschützter Datenfluss müssen zusammenpassen
Der Beitrag zur Rekonstruktion von Datenflüssen untersucht, wo Daten zwischen Komponenten, Speichern und externen Diensten fließen.
Die hier behandelte Prüfung setzt daran an und untersucht, welche Schutzmaßnahme an einem bestimmten Verarbeitungspunkt tatsächlich wirkt.
9. Technische und organisatorische Komponenten sind zu unterscheiden
Manche Maßnahmen bestehen überwiegend aus technischen Funktionen, andere aus organisatorischen Regeln und Abläufen.
Häufig wirken beide Ebenen zusammen, etwa wenn eine Rollenregel organisatorisch definiert und technisch in einem Berechtigungssystem umgesetzt wird.
10. Zugriffskontrollen müssen am tatsächlichen System geprüft werden
Für Zugriffskontrollen können unter anderem Rollen, Gruppen, ACLs, Policies, Mandantengrenzen oder anwendungsspezifische Berechtigungsregeln relevant sein.
Eine Rollenmatrix allein beweist nicht, dass die produktive Konfiguration derselben Zuordnung folgt.
11. Authentifizierung und Mehrfaktor-Verfahren benötigen Scope und Ausnahmeprüfung
Bei Authentifizierungsmaßnahmen ist nicht nur zu prüfen, ob eine Funktion grundsätzlich existiert.
Relevant können auch betroffene Konten, privilegierte Zugänge, Ausnahmen, alternative Anmeldewege und der untersuchte Zeitraum sein.
12. Rollenprinzip und tatsächliche Berechtigungen sind getrennt zu untersuchen
Ein dokumentiertes Least-Privilege- oder Need-to-know-Prinzip ist zunächst eine Soll-Vorgabe.
Die technische Prüfung betrachtet dagegen die tatsächlich eingerichteten Rechte und deren Reichweite.
13. Transportverschlüsselung muss am relevanten Kommunikationspfad geprüft werden
Die Aussage, ein System verwende TLS, ist nur dann belastbar, wenn der tatsächlich relevante Kommunikationspfad bestimmt ist.
Dabei können Client, Proxy, Load Balancer, Backend-Verbindung und externe Schnittstellen unterschiedliche Teilstrecken bilden.
14. Verschlüsselung gespeicherter Daten und Schlüsselverwaltung sind zu trennen
Eine aktivierte Speicher- oder Datenbankverschlüsselung ist eine technische Feststellung.
Davon getrennt können Fragen zur Schlüsselablage, Schlüsselrotation, Zugriffstrennung und Wiederherstellbarkeit entstehen.
15. Protokollierung ist mehr als das Vorhandensein einer Logdatei
Für eine Logging-Maßnahme können Ereignisumfang, Zeitbezug, Vollständigkeit, Manipulationsschutz, Aufbewahrung und Auswertbarkeit relevant sein.
Ein einzelner Logeintrag belegt nicht automatisch, dass alle relevanten Ereignisse vollständig erfasst werden.
16. Monitoring benötigt einen nachweisbaren Reaktionspfad
Eine Monitoring-Komponente kann Messwerte oder Ereignisse erfassen.
Für die technische Wirksamkeit kann zusätzlich relevant sein, ob Schwellenwerte, Benachrichtigungen und Eskalationspfade tatsächlich konfiguriert sind.
17. Ein vorhandenes Backup ist noch kein Wiederherstellungsnachweis
Eine Sicherungsdatei kann vorhanden sein, ohne dass feststeht, ob sie vollständig, lesbar und für den vorgesehenen Wiederherstellungsfall geeignet ist.
Backup-Erzeugung und Wiederherstellbarkeit sind deshalb getrennte Prüfgegenstände.
18. Restore-Tests können die technische Wiederherstellbarkeit belegen
Ein dokumentierter Wiederherstellungstest kann zeigen, dass ein bestimmter Datenstand unter bestimmten Bedingungen erfolgreich wiederhergestellt wurde.
Daraus folgt jedoch nicht automatisch, dass jeder andere Datenstand, jedes System oder jeder Ausfallszenario ebenfalls beherrscht wird.
19. Verfügbarkeit und Redundanz sind nicht dasselbe
Redundante Komponenten können die Verfügbarkeit unterstützen.
Für einen technischen Befund ist jedoch zu unterscheiden, ob lediglich eine zweite Komponente existiert oder ob Umschaltung, Datenkonsistenz und Wiederanlauf tatsächlich geprüft wurden.
20. Integrität benötigt einen konkret benannten Schutzmechanismus
Integrität kann je nach System durch unterschiedliche Mechanismen unterstützt werden.
Eine technische Prüfung sollte deshalb benennen, welcher Mechanismus welche unbeabsichtigte oder unzulässige Veränderung erkennen oder verhindern soll.
21. Patch- und Schwachstellenmanagement bestehen aus mehr als einem Versionsstand
Der installierte Softwarestand ist nur ein Teil einer solchen Maßnahme.
Zusätzlich können Inventarisierung, Bewertung, Priorisierung, Freigabe, Installation und Nachkontrolle technisch beziehungsweise organisatorisch relevant sein.
22. Konfigurationsmanagement verbessert die Nachweisbarkeit von Schutzmaßnahmen
Versionierte, freigegebene und nachvollziehbar ausgerollte Konfigurationen können helfen, einen bestimmten Systemzustand technisch einzugrenzen.
Eine aktuelle Konfiguration beweist jedoch nicht automatisch, welcher Zustand zu einem früheren Zeitpunkt galt.
23. Netzsegmentierung muss gegen den tatsächlichen Kommunikationspfad geprüft werden
Netzwerkzonen, Firewall-Regeln und Routingvorgaben können auf dem Papier eine Trennung beschreiben.
Für die technische Untersuchung ist entscheidend, welche Verbindungen im relevanten Zustand tatsächlich möglich beziehungsweise unterbunden sind.
24. Physische und infrastrukturelle Maßnahmen können technische Abhängigkeiten besitzen
Stromversorgung, Kühlung, Zutritt, Standort oder andere Infrastruktur können für die Verfügbarkeit und Sicherheit eines IT-Systems relevant sein.
Ihre Prüfung benötigt andere Nachweisarten als eine reine Softwarekonfigurationsanalyse.
25. Organisatorische Maßnahmen sind nicht immer allein technisch verifizierbar
Rollenverteilungen, Freigabeprozesse, Schulungsvorgaben oder Eskalationsverfahren können sich aus Richtlinien, Prozessdokumenten, Tickets und anderen Nachweisen ergeben.
Eine technische Untersuchung kann ihre Systemabbildung prüfen, ersetzt jedoch nicht automatisch die vollständige organisatorische Prüfung.
26. Änderungen an Schutzmaßnahmen benötigen einen Zeitbezug
Eine Maßnahme kann nach einem Vorfall, Audit, Update oder Architekturwechsel verändert worden sein.
Deshalb sollte dokumentiert werden, welcher Zustand für welchen Zeitraum nachweisbar ist.
27. Unterschiedliche Nachweise besitzen unterschiedliche Aussagekraft
Richtlinien, Konfigurationsdateien, Systemexporte, Logs, Tickets, Testergebnisse und Laufzeitbeobachtungen beantworten unterschiedliche Fragen.
Ein belastbarer Befund sollte deshalb angeben, worauf eine konkrete Feststellung tatsächlich gestützt wird.
28. Screenshots sind punktuelle Nachweise
Ein Screenshot kann eine sichtbare Einstellung zu einem bestimmten Zeitpunkt dokumentieren.
Er belegt jedoch nicht automatisch die Herkunft der Ansicht, den historischen Zustand, die Vollständigkeit der Konfiguration oder die tatsächliche Laufzeitwirkung.
29. Konfigurationsexporte benötigen Herkunft und Zeitbezug
Ein maschinenlesbarer Export kann eine detaillierte technische Prüfung ermöglichen.
Dafür sollte nachvollziehbar sein, aus welchem System, aus welcher Instanz und zu welchem Zeitpunkt der Export erzeugt wurde.
30. Logs belegen Ereignisse, aber nicht automatisch die gesamte Wirksamkeit
Ein Log kann zeigen, dass ein bestimmtes Ereignis protokolliert oder eine bestimmte Aktion ausgeführt wurde.
Daraus folgt nicht automatisch, dass die Schutzmaßnahme für sämtliche relevanten Szenarien wirksam war.
31. Stichproben benötigen eine dokumentierte Abdeckung
Werden nur einzelne Konten, Systeme, Zeiträume oder Konfigurationen geprüft, ist der Befund auf diese Auswahl zu beziehen.
Eine Stichprobe darf nicht ohne weitere Begründung als vollständige Prüfung aller Systeme dargestellt werden.
32. Wiederholte Prüfungen können Zustandsänderungen sichtbar machen
Sicherheitsmaßnahmen können durch Konfigurationsänderungen, neue Systeme oder Betriebsprozesse an Wirkung verlieren.
Wiederholte beziehungsweise regelmäßige Prüfungen können deshalb einen anderen Aussagewert besitzen als ein einmaliger Snapshot.
33. NIST trennt Control-Katalog und Assessment-Verfahren
NIST SP 800-53 stellt einen Katalog von Security- und Privacy-Controls bereit.
NIST SP 800-53A ergänzt dazu eine Methodik und Assessment-Verfahren, mit denen untersucht werden kann, ob Controls implementiert sind, die vorgesehenen Kontrollziele erfüllen und die angestrebten Security- beziehungsweise Privacy-Ergebnisse erreichen.
34. NIST CSF 2.0 beschreibt Ergebnisse, ohne die technische Umsetzung vorzuschreiben
Das NIST Cybersecurity Framework 2.0 strukturiert übergeordnete Cybersecurity-Ergebnisse für das Risikomanagement.
NIST weist zugleich darauf hin, dass das Framework nicht vorschreibt, wie diese Ergebnisse technisch erreicht werden müssen.
35. BSI IT-Grundschutz verbindet Sicherheitskonzept und Risikoanalyse
Der BSI-Standard 200-2 beschreibt die IT-Grundschutz-Methodik. Der BSI-Standard 200-3 behandelt die Risikoanalyse auf Basis von IT-Grundschutz.
Für eine technische Untersuchung können solche methodischen Rahmen helfen, Schutzobjekte, Anforderungen, Maßnahmen und zusätzliche Risiken strukturiert auseinanderzuhalten.
36. Artikel 32 DSGVO ist ein normativer Bezug, aber keine technische Prüfschablone
Artikel 32 DSGVO nennt unter anderem technische und organisatorische Maßnahmen, Pseudonymisierung, Verschlüsselung, Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit, Wiederherstellbarkeit und die regelmäßige Prüfung der Wirksamkeit von Maßnahmen.
37. Technischer Befund und Compliance-Feststellung sind zu trennen
Ein technischer Befund kann beispielsweise zeigen, dass Mehrfaktor-Authentifizierung für definierte Konten aktiviert ist oder dass ein Restore-Test erfolgreich durchgeführt wurde.
Daraus folgt nicht automatisch eine vollständige Compliance-, Zertifizierungs- oder Rechtskonformitätsaussage für das gesamte System oder die gesamte Organisation.
38. Praktische Dokumentationsstruktur einer TOM-Prüfung
- konkrete technische Fragestellung,
- untersuchter System- und Zeitraumbezug,
- Schutzobjekt beziehungsweise Datenfluss,
- Soll-Anforderung,
- konkret bezeichnete Schutzmaßnahme,
- technische und organisatorische Komponenten,
- tatsächliche Implementierung,
- relevante Konfiguration,
- Versionen und Systemzustände,
- zugrunde liegende Nachweise,
- Prüfmethode,
- Prüfgegenstände und Stichprobe,
- Erfolgskriterium,
- technischer Befund,
- festgestellte Abweichungen,
- nicht geprüfte Bereiche,
- zeitliche Grenzen,
- technische Aussagegrenzen,
- Trennung von technischem Befund und rechtlicher Würdigung.
Konstruiertes Beispiel
Für eine Webanwendung ist dokumentiert, dass administrative Zugänge durch Mehrfaktor-Authentifizierung geschützt werden, die externe Kommunikation verschlüsselt erfolgt und täglich Datenbank-Backups erzeugt werden.
Eine technische Prüfung würde diese drei Aussagen getrennt untersuchen.
Für die Authentifizierung wäre etwa festzustellen, welche administrativen Konten tatsächlich erfasst werden und ob Ausnahmen bestehen.
Für die Transportverschlüsselung wäre der relevante Kommunikationspfad zu bestimmen. Für das Backup wäre zwischen Sicherungserzeugung und tatsächlicher Wiederherstellbarkeit zu unterscheiden.
Ein dokumentierter erfolgreicher Restore-Test könnte die Wiederherstellbarkeit des konkret getesteten Datenstands unter den dokumentierten Bedingungen stützen.
Er beweist jedoch nicht, dass sämtliche denkbaren Ausfallszenarien beherrscht werden.
Das Beispiel ist vollständig konstruiert und stellt kein reales Mandat, kein Audit, keine Zertifizierung und keine Rechtsberatung dar.
Quellen und fachliche Grundlage
- Normative EU-Primärquelle Europäische Union: Verordnung (EU) 2016/679 – Datenschutz-Grundverordnung, insbesondere Artikel 32 . Normativer Bezug für die Sicherheit der Verarbeitung sowie technische und organisatorische Maßnahmen. Geprüft am 21.09.2026.
- Offizielle EU-Fachinformation Europäische Kommission: Obligations – Security of personal data processing . Offizielle Erläuterung zu technischen und organisatorischen Maßnahmen, Pseudonymisierung, Verschlüsselung, Wiederherstellbarkeit und regelmäßiger Wirksamkeitsprüfung. Geprüft am 21.09.2026.
- Offizieller EU-Publikationsnachweis Amt für Veröffentlichungen der Europäischen Union: Verordnung (EU) 2016/679 – Publikations- und CELEX-Nachweis . Fundstellen- und Veröffentlichungsnachweis zur Verordnung. Geprüft am 21.09.2026.
- Amtlich-technische Primärquelle NIST: SP 800-53 Rev. 5 – Security and Privacy Controls for Information Systems and Organizations . Technischer Kontrollkatalog für Security- und Privacy-Controls. Geprüft am 21.09.2026.
- Amtlich-technische Primärquelle NIST: SP 800-53A Rev. 5 – Assessing Security and Privacy Controls . Methodik und Verfahren zur Prüfung implementierter Security- und Privacy-Controls. Geprüft am 21.09.2026.
- Amtlich-technische Primärquelle NIST: Cybersecurity Framework 2.0 . Rahmenwerk für übergeordnete Cybersecurity-Risikoergebnisse; es schreibt nicht vor, wie einzelne Ergebnisse technisch erreicht werden. Geprüft am 21.09.2026.
- Amtlich-technische Fachquelle Bundesamt für Sicherheit in der Informationstechnik: BSI-Standard 200-2 – IT-Grundschutz-Methodik . Methodische Grundlage zur strukturierten Informationssicherheitsbetrachtung. Geprüft am 21.09.2026.
- Amtlich-technische Fachquelle Bundesamt für Sicherheit in der Informationstechnik: BSI-Standard 200-3 – Risikoanalyse auf der Basis von IT-Grundschutz . Ergänzende methodische Grundlage zur strukturierten Risikoanalyse. Geprüft am 21.09.2026.
- Amtlich-technische Fachquelle Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz-Kompendium . Ergänzende Grundlage zu Anforderungen und Sicherheitsmaßnahmen in unterschiedlichen Bausteinen. Geprüft am 21.09.2026.
- Eigene fachliche Einordnung Die Kette Schutzobjekt → Soll-Anforderung → Maßnahme → Implementierung → Konfiguration → Nachweis → Prüfverfahren → technischer Befund → Wirksamkeitsgrenze → Aussagegrenze dient hier als methodische Struktur einer technischen TOM-Prüfung.
Weiterführende Beiträge
Welche Daten zwischen Systemen, Schnittstellen, Speichern und externen Diensten fließen, erläutert Datenflüsse in IT-Systemen technisch rekonstruieren: Quellen, Verarbeitungsschritte, Speicherorte und Empfänger .
Der allgemeine Quellen- und Dokumentationsstandard ist unter Quellen und Methodik beschrieben.
Zur technischen Eingrenzung einer gerichtlichen oder anwaltlichen Fragestellung siehe Welche technische Fragestellung kann ein IT-Sachverständiger tatsächlich beantworten? .
Zur Strukturierung reproduzierbarer Prüfschritte und technischer Nachweise siehe außerdem Dokumentation & Nachvollziehbarkeit .
Technische und organisatorische Maßnahmen prüfen
Wenn dokumentierte Schutzmaßnahmen auf ihre tatsächliche Implementierung, Konfiguration, technische Funktion und Nachweisbarkeit untersucht werden sollen, können zunächst Schutzobjekt, Soll-Anforderung, Prüfmethode und Aussagegrenzen fachlich eingegrenzt werden.
IT-Compliance & Datenethik ansehen