Nachweise zu TOMs nach GDPR Article 32 mit ISO, NIS2 und DORA

Die E-Mail landet im Posteingang des CISO mit der vertrauten Schwere eines Geschäftsabschlusses, der das Quartal des Unternehmens verändern könnte.

Ein großer Unternehmenskunde verlangt Nachweise zu „technischen und organisatorischen Maßnahmen nach GDPR Article 32, zugeordnet zu ISO 27001:2022, NIS2 und DORA, soweit anwendbar“. Gleichzeitig hat die Rechtsabteilung das Leitungsorgan über die Verantwortlichkeit der Leitung nach NIS2 und die Erwartungen an operative Resilienz nach DORA informiert. Die Anweisung des Leitungsorgans klingt einfach: Compliance nachweisen, Doppelarbeit vermeiden und daraus keine drei getrennten Projekte machen.

Das Unternehmen verfügt über Kontrollen. MFA ist aktiviert. Backups laufen. Entwickler prüfen Code. Das Datenschutzteam pflegt das Verzeichnis von Verarbeitungstätigkeiten. Das Infrastrukturteam führt Schwachstellenscans durch. Lieferanten werden im Beschaffungsprozess überprüft. Doch sobald der Interessent Nachweise anfordert, zerfällt die Antwort in Einzelteile.

Der Bericht des Identitätsanbieters liegt an einer Stelle. Backup-Protokolle liegen an einer anderen. Das Risikoregister wurde seit dem letzten Produkt-Release nicht aktualisiert. Nachweise zur Lieferantensicherheit befinden sich in Beschaffungs-E-Mails. Notizen aus Incident-Response-Tabletop-Übungen existieren, aber niemand kann nachweisen, dass gewonnene Erkenntnisse in die Risikobehandlung zurückgeführt wurden. Das Leitungsorgan hat Sicherheitsausgaben genehmigt, aber die Genehmigung ist weder mit einem IKT-Risiko noch mit einer dokumentierten Kontrollentscheidung verknüpft.

Das ist das eigentliche Problem bei technischen und organisatorischen Maßnahmen nach GDPR Article 32, häufig TOMs genannt. Die meisten Organisationen scheitern nicht daran, dass sie keine Kontrollen haben. Sie scheitern daran, dass sie nicht belegen können, dass Kontrollen risikobasiert ausgewählt, genehmigt, umgesetzt, überwacht und verbessert werden.

Die Rechenschaftspflicht nach GDPR macht diese Erwartung ausdrücklich. GDPR Article 5 verlangt, dass personenbezogene Daten durch ein angemessenes Sicherheitsniveau gegen unbefugte oder unrechtmäßige Verarbeitung sowie gegen unbeabsichtigten Verlust, unbeabsichtigte Zerstörung oder unbeabsichtigte Schädigung geschützt werden. Article 5(2) macht den Verantwortlichen für den Nachweis der Einhaltung verantwortlich. Auch die Begriffsbestimmungen der GDPR sind relevant. Personenbezogene Daten sind weit gefasst, Verarbeitung umfasst nahezu jeden Vorgang mit Daten, Pseudonymisierung ist eine anerkannte Schutzmaßnahme, und eine Verletzung des Schutzes personenbezogener Daten umfasst unbeabsichtigte oder unrechtmäßige Zerstörung, Verlust, Veränderung, unbefugte Offenlegung oder unbefugten Zugriff.

Ein Nachweisdossier zu Article 32 darf daher kein Ordner mit zufälligen Screenshots sein. Es muss ein lebendes Kontrollsystem abbilden.

Der Ansatz von Clarysec besteht darin, TOMs nach GDPR Article 32 in eine nachvollziehbare Nachweisarchitektur zu überführen, die auf ISO/IEC 27001:2022 ISO/IEC 27001:2022 basiert, durch Risikomanagement nach ISO/IEC 27005:2022 gestärkt wird und, soweit anwendbar, mit Verpflichtungen aus NIS2 und DORA querverknüpft ist. Das Ziel ist nicht Dokumentation um ihrer selbst willen. Das Ziel ist, die Organisation auditbereit zu machen, bevor ein Kunde, Auditor, eine Aufsichtsbehörde oder ein Mitglied des Leitungsorgans die schwierige Frage stellt.

Warum TOMs nach GDPR Article 32 in der Praxis scheitern

Article 32 wird häufig als Liste von Sicherheitswerkzeugen missverstanden: Verschlüsselung, Backups, Protokollierung, Zugriffskontrolle und Incident Response. Diese Maßnahmen sind wichtig, aber nur dann belastbar, wenn sie dem Risiko angemessen sind und mit dem Lebenszyklus personenbezogener Daten verbunden werden.

Für ein SaaS-Unternehmen, das Beschäftigtendaten von Kunden verarbeitet, reicht „wir nutzen Verschlüsselung“ nicht aus. Ein Auditor kann fragen, welche Daten die Verschlüsselung schützt, wo Verschlüsselung vorgeschrieben ist, wie Schlüssel verwaltet werden, ob Backups verschlüsselt sind, ob Produktionsdaten in Tests maskiert werden, wer Kontrollen umgehen kann und wie Ausnahmen genehmigt werden.

Die unternehmensweite Richtlinie zu Datenschutz und Privatsphäre von Clarysec hält das Betriebsprinzip fest:

„Technische und organisatorische Maßnahmen (TOMs) sind umzusetzen, die Vertraulichkeit, Integrität und Verfügbarkeit personenbezogener Informationen (PII) über deren gesamten Lebenszyklus schützen.“

Quelle: Richtlinie zu Datenschutz und Privatsphäre, Ziele, Richtlinienklausel 3.3. Richtlinie zu Datenschutz und Privatsphäre

Die Formulierung „über deren gesamten Lebenszyklus“ ist der Punkt, an dem viele TOM-Programme schwach werden. Personenbezogene Daten können in der Produktion geschützt sein, werden aber in Analysesysteme, Protokolle, Support-Exporte, Testumgebungen, Backups, Lieferantenplattformen und Mitarbeitergeräte kopiert. Jeder Speicherort erzeugt Sicherheits- und Datenschutzrisiken.

GDPR Article 6 verlangt eine Rechtsgrundlage für die Verarbeitung, einschließlich Einwilligung, Vertrag, rechtlicher Verpflichtung, lebenswichtiger Interessen, öffentlicher Aufgabe oder berechtigter Interessen. Wenn Daten für einen weiteren Zweck wiederverwendet werden, müssen Vereinbarkeit und Schutzmaßnahmen wie Verschlüsselung oder Pseudonymisierung berücksichtigt werden. Bei Daten mit höherem Risiko steigt die Nachweislast. GDPR Article 9 setzt enge Grenzen für besondere Kategorien personenbezogener Daten, etwa Gesundheitsdaten, biometrische Daten zur Identifizierung und andere sensible Informationen. Article 10 beschränkt die Verarbeitung von Daten zu strafrechtlichen Verurteilungen und Straftaten.

Für KMU formuliert Clarysec Risikobehandlung praxisnah:

„Kontrollen müssen umgesetzt werden, um identifizierte Risiken zu reduzieren, einschließlich Verschlüsselung, Anonymisierung, sicherer Entsorgung und Zugriffsbeschränkungen.“

Quelle: Richtlinie zu Datenschutz und Privatsphäre – KMU, Risikobehandlung und Ausnahmen, Richtlinienklausel 7.2.1. Richtlinie zu Datenschutz und Privatsphäre – KMU

Das ist eine starke TOM-Basis. Um auditbereit zu werden, muss jede Kontrolle zusätzlich mit einem Risiko, einem Verantwortlichen, einer Richtlinienanforderung, einem Nachweiselement und einem Überprüfungsturnus verknüpft sein.

ISO 27001:2022 ist das Rückgrat für Nachweise nach Article 32

ISO 27001:2022 eignet sich für GDPR Article 32 besonders gut, weil sie Sicherheit als Managementsystem behandelt und nicht als lose Kontroll-Checkliste. Sie verlangt ein Informationssicherheits-Managementsystem (ISMS), das darauf ausgelegt ist, Vertraulichkeit, Integrität und Verfügbarkeit durch Risikomanagement zu wahren.

Der erste kritische Schritt ist der Geltungsbereich. ISO 27001:2022 Klauseln 4.1 bis 4.4 verlangen, dass die Organisation interne und externe Themen versteht, interessierte Parteien und Anforderungen identifiziert, festlegt, welche Anforderungen durch das ISMS adressiert werden, und den ISMS-Geltungsbereich einschließlich Schnittstellen und Abhängigkeiten zu externen Organisationen definiert. Für TOMs nach Article 32 sollte der ISMS-Geltungsbereich die Verarbeitung personenbezogener Daten, Kundenverpflichtungen, Auftragsverarbeiter, Unterauftragsverarbeiter, Cloud-Plattformen, Remote-Arbeit, Supportfunktionen und Produktumgebungen abbilden.

Der zweite Schritt ist Führung. Klauseln 5.1 bis 5.3 verlangen das Engagement der obersten Leitung, eine Informationssicherheitsleitlinie, Ressourcen, Rollen und Verantwortlichkeiten sowie Leistungsberichterstattung. Das ist relevant, weil GDPR Article 32, NIS2 und DORA alle auf Governance beruhen. Eine Kontrolle ohne Verantwortlichkeit, Finanzierung oder Überprüfung ist ein schwacher Nachweis.

Die unternehmensweite Informationssicherheitsleitlinie von Clarysec macht dies ausdrücklich:

„Das ISMS muss definierte Grenzen des Geltungsbereichs, eine Methodik zur Risikobeurteilung, messbare Ziele und dokumentierte Kontrollen enthalten, die in der Anwendbarkeitserklärung (SoA) begründet sind.“

Quelle: Informationssicherheitsleitlinie, Anforderungen an die Umsetzung der Richtlinie, Richtlinienklausel 6.1.2. Informationssicherheitsleitlinie

Dieselbe Richtlinie legt die Nachweiserwartung fest:

„Alle umgesetzten Kontrollen müssen überprüfbar sein, durch dokumentierte Verfahren unterstützt werden und durch aufbewahrte Nachweise des Betriebs belegt sein.“

Quelle: Informationssicherheitsleitlinie, Anforderungen an die Umsetzung der Richtlinie, Richtlinienklausel 6.6.1.

ISO 27001:2022 Klauseln 6.1.1 bis 6.1.3 verlangen anschließend Risikobeurteilung, Risikobehandlung, eine Anwendbarkeitserklärung, Genehmigung des Restrisikos und Rechenschaftspflicht der Risikoverantwortlichen. Klausel 6.2 verlangt messbare Ziele. Klauseln 7.5, 9.1, 9.2, 9.3 und 10.2 verlangen dokumentierte Informationen, Überwachung, internes Audit, Managementbewertung und Korrekturmaßnahmen.

Für GDPR Article 32 entsteht dadurch eine belastbare Struktur.

ISO/IEC 27005:2022 stärkt diese Struktur. Sie empfiehlt Organisationen, Anforderungen aus ISO 27001:2022 Annex A, Vorschriften, Verträgen, Branchenstandards, internen Regeln und bestehenden Kontrollen zu identifizieren und in Risikobeurteilung und Risikobehandlung einfließen zu lassen. Außerdem verlangt sie Risikokriterien und Abnahmekriterien, die rechtliche, regulatorische, operative, lieferantenbezogene, technologische und menschliche Faktoren einschließlich Datenschutz berücksichtigen.

Die Risikomanagement-Richtlinie von Clarysec ist direkt darauf ausgerichtet:

„Ein formaler Risikomanagementprozess ist gemäß ISO/IEC 27005 und ISO 31000 aufrechtzuerhalten und umfasst Risikoidentifizierung, Analyse, Bewertung, Behandlung, Überwachung und Kommunikation.“

Quelle: Risikomanagement-Richtlinie, Governance-Anforderungen, Richtlinienklausel 5.1. Risikomanagement-Richtlinie

Für KMU wird dieselbe Anforderung einfach und umsetzbar:

„Jeder Risikoeintrag muss enthalten: Beschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Bewertung, Verantwortlichen und Behandlungsplan.“

Quelle: Risikomanagement-Richtlinie – KMU, Governance-Anforderungen, Richtlinienklausel 5.1.2. Risikomanagement-Richtlinie – KMU

Dieser Satz ist ein schneller Test auf Auditbereitschaft. Wenn ein Risiko keinen Risikoverantwortlichen oder keinen Behandlungsplan hat, ist es noch nicht nachweisbereit.

Die Clarysec-Brücke: Risiko, SoA, Kontrollen und Vorschriften

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandelt Compliance als Arbeit an der Nachvollziehbarkeit. In der Phase Risikomanagement konzentriert sich Schritt 13 auf die Planung der Risikobehandlung und die Anwendbarkeitserklärung. Er erläutert, dass Organisationen Kontrollen Risiken zuordnen, Annex A-Kontrollreferenzen zu Risikobehandlungseinträgen hinzufügen, externe Vorschriften querverweisen und Managementfreigaben einholen sollten.

Der Zenith Blueprint beschreibt die Rolle der SoA klar:

„Die SoA ist faktisch ein Brückendokument: Sie verknüpft Ihre Risikobeurteilung und Risikobehandlung mit den tatsächlich vorhandenen Kontrollen. Durch ihre Fertigstellung prüfen Sie zugleich, ob Kontrollen fehlen.“

Quelle: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Phase Risikomanagement, Schritt 13: Planung der Risikobehandlung und Anwendbarkeitserklärung (SoA). Zenith Blueprint

Schritt 14 des Zenith Blueprint ergänzt die regulatorische Querverweisebene. Er empfiehlt Organisationen zu dokumentieren, wie Anforderungen aus GDPR, NIS2 und DORA durch Richtlinien und Kontrollen abgedeckt werden. Für GDPR betont er den Schutz personenbezogener Daten in Risikobeurteilungen und Behandlungen, einschließlich Verschlüsselung als technische Maßnahme und Reaktion auf Datenschutzverletzungen als Teil des Kontrollumfelds. Für NIS2 hebt er Risikobeurteilung, Netzwerksicherheit, Zugriffskontrolle, Management von Informationssicherheitsvorfällen und Geschäftskontinuität hervor. Für DORA verweist er auf IKT-Risikomanagement, Incident Response, Berichtspflichten und Aufsicht über IKT-Drittparteien.

Das ist der Kern der Clarysec-Methode: ein ISMS, ein Risikoregister, eine SoA, eine Nachweisbibliothek, mehrere Compliance-Ergebnisse.

Zenith Controls: The Cross-Compliance Guide Zenith Controls unterstützt dies, indem Organisationen Kontrollthemen aus ISO/IEC 27002:2022 ISO/IEC 27002:2022 als Querverweisanker für die Compliance nutzen können. Für GDPR Article 32 gehören zu den wichtigsten Ankern häufig Datenschutz und Schutz personenbezogener Informationen (PII), Maßnahme 5.34; unabhängige Überprüfung der Informationssicherheit, Maßnahme 5.35; und Einsatz von Kryptographie, Maßnahme 8.24.

NIS2 macht TOMs zu einem Cybersicherheitsthema auf Ebene des Leitungsorgans

Viele Organisationen behandeln GDPR TOMs als Aufgabe des Datenschutzteams. NIS2 verändert diese Sichtweise.

NIS2 gilt für viele mittlere und große Einrichtungen in gelisteten Sektoren und in bestimmten Fällen unabhängig von der Größe. Abgedeckte digitale und technologische Sektoren umfassen Cloud-Computing-Anbieter, Rechenzentrumsanbieter, Content Delivery Networks, DNS-Dienstanbieter, TLD-Registrierungsstellen, Vertrauensdiensteanbieter, Anbieter öffentlicher elektronischer Kommunikationsdienste, Managed Service Provider, Managed Security Service Provider, Online-Marktplätze, Suchmaschinen und soziale Netzwerkplattformen. Die Anwendbarkeit für SaaS- und Technologie-KMU hängt von Sektor, Größe, Benennung durch den Mitgliedstaat sowie systemischer oder grenzüberschreitender Auswirkung ab.

NIS2 Article 20 legt die Verantwortung für Cybersicherheit bei den Leitungsorganen fest. Sie müssen Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen, deren Umsetzung überwachen und Schulungen absolvieren. Wesentliche Einrichtungen können mit Verwaltungsgeldbußen von mindestens 10 Mio. EUR oder mindestens 2 Prozent des weltweiten Jahresumsatzes belegt werden. Wichtige Einrichtungen können mit Geldbußen von mindestens 7 Mio. EUR oder mindestens 1,4 Prozent belegt werden.

NIS2 Article 21 ist für TOMs nach Article 32 unmittelbar relevant, weil er geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen verlangt. Diese Maßnahmen müssen den Stand der Technik, europäische und internationale Standards, Kosten, Exposition, Größe, Eintrittswahrscheinlichkeit, Schwere und gesellschaftliche oder wirtschaftliche Auswirkungen berücksichtigen. Erforderliche Bereiche umfassen Risikoanalyse, Sicherheitsrichtlinien, Management von Informationssicherheitsvorfällen, Geschäftskontinuität, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Behandlung von Schwachstellen, Wirksamkeitsbewertung, Cyberhygiene, Schulung, Kryptographie, HR-Sicherheit, Zugriffskontrolle, Asset-Management, MFA oder kontinuierliche Authentifizierung sowie sichere Kommunikation, soweit angemessen.

NIS2 Article 23 ergänzt ein gestuftes Verfahren für Vorfallmeldungen: Frühwarnung innerhalb von 24 Stunden, Vorfallmeldung innerhalb von 72 Stunden, Zwischenmeldungen auf Anforderung und ein Abschlussbericht spätestens einen Monat nach der 72-Stunden-Meldung. Wenn eine Verletzung des Schutzes personenbezogener Daten zugleich als erheblicher NIS2-Vorfall einzustufen ist, muss Ihr Nachweisdossier sowohl Datenschutz- als auch Cybersicherheitsentscheidungen zur Meldung unterstützen.

DORA erhöht die Anforderungen an finanzielle Resilienz und IKT-Anbieter

DORA gilt ab dem 17. Januar 2025 und schafft ein Regelwerk für digitale operationale Resilienz im Finanzsektor. Es umfasst IKT-Risikomanagement, Meldung schwerwiegender IKT-bezogener Vorfälle, Tests der operationalen Resilienz, Austausch von Informationen zu Cyberbedrohungen und Schwachstellen, IKT-Drittparteienrisiko, vertragliche Anforderungen an IKT-Anbieter, Aufsicht über kritische IKT-Drittdienstleister und Beaufsichtigung.

Für Finanzunternehmen, die auch nach nationalen NIS2-Regelungen identifiziert wurden, wirkt DORA als sektorspezifischer Rechtsakt der Union für überschneidende Pflichten im Cybersicherheitsrisikomanagement und in der Vorfallmeldung. In der Praxis sollten erfasste Finanzunternehmen DORA für diese Überschneidungsbereiche priorisieren und zugleich die Koordination mit zuständigen NIS2-Behörden und CSIRTs sicherstellen, soweit relevant.

Für Nachweise zu GDPR Article 32 ist DORA in zweierlei Hinsicht relevant. Erstens können Fintech-Unternehmen unmittelbar als Finanzunternehmen in den Geltungsbereich fallen, darunter Kreditinstitute, Zahlungsinstitute, Kontoinformationsdienstleister, E-Geld-Institute, Wertpapierfirmen, Anbieter von Kryptowerte-Dienstleistungen, Handelsplätze und Crowdfunding-Dienstleister. Zweitens können SaaS-, Cloud-, Daten-, Software- und Managed-Service-Anbieter von Finanzkunden als IKT-Drittdienstleister behandelt werden, weil DORA IKT-Dienste weit definiert.

DORA Article 5 verlangt Governance und interne Kontrollen für das IKT-Risikomanagement, wobei das Leitungsorgan IKT-Risikoregelungen definiert, genehmigt, überwacht und dafür verantwortlich bleibt. Article 6 verlangt ein dokumentiertes IKT-Risikomanagementrahmenwerk, einschließlich Strategien, Richtlinien, Verfahren, IKT-Protokollen und Werkzeugen zum Schutz von Informationen und IKT-Assets. Article 17 verlangt einen Prozess zum Management IKT-bezogener Vorfälle, der Erkennung, Management, Benachrichtigung, Aufzeichnung, Ursachenanalyse, Frühwarnindikatoren, Klassifizierung, Rollen, Kommunikation, Eskalation und Reaktion abdeckt. Article 19 verlangt, dass schwerwiegende IKT-bezogene Vorfälle an zuständige Behörden gemeldet werden.

DORA Articles 28 und 30 machen IKT-Drittparteienrisiken zu einem regulierten Kontrollbereich. Finanzunternehmen bleiben für die Einhaltung verantwortlich, wenn sie IKT-Dienste nutzen. Sie benötigen eine Strategie für Drittparteienrisiken, Vertragsregister, Kritikalitätsbewertungen, Due-Diligence-Prüfungen, Überprüfung von Konzentrationsrisiken, Audit- und Inspektionsrechte, Beendigungsgründe, Exit-Strategien und Vertragsklauseln zu Datenstandorten, Verfügbarkeit, Authentizität, Integrität, Vertraulichkeit, Unterstützung bei Vorfällen, Wiederherstellung, Service Levels und Zusammenarbeit mit Behörden.

Für Article 32 bedeutet dies: Lieferanten sind Teil des TOMs-Dossiers. Die Sicherheit der Verarbeitung kann nicht nachgewiesen werden, wenn kritische Auftragsverarbeiter, Cloud-Plattformen, Analyseanbieter, Support-Werkzeuge und IKT-Anbieter nicht gesteuert werden.

Ein praktischer einwöchiger Aufbau von Nachweisen nach Article 32

Ein belastbares Nachweisdossier beginnt mit einem klaren Risikoszenario.

Verwenden Sie dieses Beispiel: „Unbefugter Zugriff auf personenbezogene Kundendaten in der Produktivanwendung.“

Erstellen oder aktualisieren Sie den Risikoeintrag. Erfassen Sie Beschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Bewertung, Verantwortlichen und Behandlungsplan. Weisen Sie die Verantwortung der Entwicklungsleitung, dem Sicherheitsmanager oder einer gleichwertigen rechenschaftspflichtigen Rolle zu. Bewerten Sie die Eintrittswahrscheinlichkeit anhand des Zugriffsmodells, der exponierten Angriffsfläche, bekannter Schwachstellen und früherer Vorfälle. Bewerten Sie die Auswirkung anhand von Umfang und Sensitivität personenbezogener Daten, Kundenverträgen, GDPR-Folgen und möglichen NIS2- oder DORA-Auswirkungen auf Services.

Wählen Sie Behandlungen wie MFA für privilegierten Zugriff, rollenbasierte Zugriffskontrolle (RBAC), vierteljährliche Berechtigungsüberprüfungen, Verschlüsselung ruhender Daten, TLS, Schwachstellenscans, Protokollierung, Alarmierung, sichere Backups, Verfahren zur Incident Response und Datenmaskierung in Nicht-Produktivumgebungen.

Ordnen Sie das Risiko anschließend der SoA zu. Ergänzen Sie ISO/IEC 27002:2022-Referenzen wie 5.34 Datenschutz und Schutz personenbezogener Informationen (PII), 8.24 Einsatz von Kryptographie, 5.15 Zugriffskontrolle, 5.18 Zugriffsrechte, 8.13 Informationssicherung, 8.15 Protokollierung, 8.16 Überwachungsaktivitäten, 8.8 Management technischer Schwachstellen, 8.25 sicherer Entwicklungslebenszyklus und 8.10 Informationslöschung, soweit anwendbar. Ergänzen Sie Hinweise, wie diese Kontrollen GDPR Article 32, NIS2 Article 21 und das IKT-Risikomanagement nach DORA unterstützen, soweit relevant.

Für die regulatorische Zuordnung müssen Kontrollnamen korrekt bleiben; erzwingen Sie keine falsche Gleichsetzung.

Erstellen Sie nun den Nachweisordner. Die KMU-Richtlinie zur Audit- und Compliance-Überwachung von Clarysec formuliert eine einfache Regel:

„Alle Nachweise müssen in einem zentralen Auditordner gespeichert werden.“

Quelle: Richtlinie zur Audit- und Compliance-Überwachung – KMU, Anforderungen an die Umsetzung der Richtlinie, Richtlinienklausel 6.2.1. Richtlinie zur Audit- und Compliance-Überwachung – KMU

Für dieses eine Risikoszenario sollte der Ordner Folgendes enthalten:

Zugriffsnachweise sollten nicht bei Screenshots enden. Die Richtlinie zur Zugriffskontrolle – KMU ergänzt eine nützliche operative Anforderung:

„Der IT-Manager muss Überprüfungsergebnisse und Korrekturmaßnahmen dokumentieren.“

Quelle: Richtlinie zur Zugriffskontrolle – KMU, Governance-Anforderungen, Richtlinienklausel 5.5.3. Richtlinie zur Zugriffskontrolle – KMU

Backup-Nachweise müssen Wiederherstellbarkeit belegen, nicht nur erfolgreiche Jobs. Die Richtlinie für Backup und Wiederherstellung – KMU stellt fest:

„Wiederherstellungstests werden mindestens vierteljährlich durchgeführt, und die Ergebnisse werden dokumentiert, um die Wiederherstellbarkeit zu verifizieren.“

Quelle: Richtlinie für Backup und Wiederherstellung – KMU, Governance-Anforderungen, Richtlinienklausel 5.3.3. Richtlinie für Backup und Wiederherstellung – KMU

Damit entsteht eine vollständige Nachweiskette: Die Vorschrift erzeugt die Anforderung, das Risiko erklärt die Relevanz, die SoA wählt die Kontrolle aus, die Richtlinie definiert den Betrieb, und aufbewahrte Nachweise belegen, dass die Kontrolle funktioniert.

Kontrollen in der Praxis: Richtlinien in Betriebsnachweise überführen

Die Phase „Kontrollen in der Praxis“ des Zenith Blueprint, Schritt 19, konzentriert sich auf technische Verifikation. Sie empfiehlt die Überprüfung der Einhaltung von Endpoint-Sicherheit, Identitäts- und Zugriffsmanagement, Authentifizierungskonfigurationen, Sicherheit der Quellcodeverwaltung, Kapazität und Verfügbarkeit, Schwachstellen- und Patch-Management, sicheren Baselines, Schutz vor Schadsoftware, Löschung und Datenminimierung, Maskierung und Testdaten, DLP, Backup und Wiederherstellung, Redundanz, Protokollierung und Überwachung sowie Zeitsynchronisierung.

Für TOMs nach GDPR Article 32 ist Schritt 19 der Punkt, an dem abstrakte Kontrollsprache zu Nachweisen wird. Ein belastbares Nachweisdossier sollte zeigen, dass:

• Endpoint-Verschlüsselung aktiviert und überwacht wird.
• privilegierte Benutzer MFA verwenden.
• Eintritts-, Wechsel- und Austrittsprozesse mit HR-Aufzeichnungen abgeglichen werden.
• Servicekonten dokumentiert und beschränkt sind.
• Code-Repositories zugriffskontrolliert sind und Scans auf Geheimnisse durchgeführt werden.
• Schwachstellenscans durchgeführt und bis zur Mängelbehebung nachverfolgt werden.
• Produktionsdaten nicht beiläufig in Testumgebungen kopiert werden.
• sichere Löschung und Aufbewahrungsrichtlinien durchgesetzt werden.
• DLP-Warnmeldungen überprüft werden.
• Backup-Wiederherstellungstests die Wiederherstellbarkeit belegen.
• Protokolle zentralisiert, aufbewahrt und überprüfbar sind.
• Zeitsynchronisierung eine verlässliche Untersuchung von Vorfällen unterstützt.

Entscheidend ist die Verknüpfung. Ein Patch-Bericht ohne Risiko-, Richtlinien- und SoA-Referenz ist ein IT-Artefakt. Ein Patch-Bericht, der mit GDPR Article 32, NIS2 Article 21, IKT-Risikomanagement nach DORA und einem Risikobehandlungsplan nach ISO 27001:2022 verknüpft ist, ist ein auditbereiter Nachweis.

Ein Nachweisdossier, mehrere Audit-Perspektiven

Dieselben TOM-Nachweise werden von unterschiedlichen Stakeholdern unterschiedlich gelesen. Ein Datenschutzprüfer achtet möglicherweise auf personenbezogene Daten, Erforderlichkeit, Verhältnismäßigkeit und Rechenschaftspflicht. Ein ISO 27001-Auditor achtet auf Geltungsbereich, Risikobehandlung, SoA und Betriebsnachweise. Eine NIS2-Behörde achtet auf Managementaufsicht, Maßnahmen nach Article 21 und Meldebereitschaft nach Article 23. Eine DORA-Aufsicht oder ein Finanzkunde achtet auf IKT-Risiko-Governance, Resilienztests und Abhängigkeiten von Drittparteien.

Clarysec nutzt Zenith Controls als Leitfaden für Querverweise über Compliance-Anforderungen hinweg.

Das verhindert doppelte Compliance-Arbeit. Statt getrennte Nachweispakete für GDPR, NIS2 und DORA aufzubauen, erstellen Sie ein Kontrollnachweisdossier und kennzeichnen jedes Element nach den Verpflichtungen, die es unterstützt.

Häufige Lücken in TOM-Programmen nach Article 32

Die häufigste Lücke ist das Verwaisen von Kontrollen. Ein Unternehmen verfügt über eine Kontrolle, etwa Verschlüsselung, kann aber nicht erklären, welches Risiko sie behandelt, welche Richtlinie sie verlangt, wer sie verantwortet oder wie sie überprüft wird.

Die zweite Lücke sind schwache Lieferantennachweise. Unter GDPR sind Auftragsverarbeiter und Unterauftragsverarbeiter relevant. Unter NIS2 ist Sicherheit der Lieferkette Teil des Managements von Cybersicherheitsrisiken. Unter DORA ist IKT-Drittparteienrisiko ein regulierter Bereich mit Registern, Due-Diligence-Prüfungen, vertraglichen Schutzmaßnahmen, Auditrechten und Exit-Planung. Eine Lieferantentabelle reicht nicht aus, wenn kritische Abhängigkeiten nicht risikobewertet und gesteuert werden.

Die dritte Lücke sind Nachweise zu Vorfällen. Organisationen haben häufig einen Incident-Response-Plan, aber keinen Nachweis, dass Klassifizierung, Eskalation, Behördenmeldung und Kundenkommunikation getestet wurden. NIS2 und DORA erhöhen hier die Erwartungen, und die Bewertung von Verletzungen des Schutzes personenbezogener Daten nach GDPR muss in denselben Workflow integriert werden.

Die vierte Lücke sind Backup-Nachweise. Ein erfolgreicher Backup-Job belegt keine Wiederherstellbarkeit. Ein dokumentierter Wiederherstellungstest tut dies.

Die fünfte Lücke ist die Managementbewertung. TOMs nach Article 32 müssen dem Risiko angemessen sein. Wenn das Management Risiken, Vorfälle, Lieferantenthemen, Budget, Audit-Feststellungen und Restrisiko nie überprüft, lässt sich Verhältnismäßigkeit nur schwer belegen.

Das abschließende auditbereite Toolkit

Die Phase Audit, Review and Improvement des Zenith Blueprint, Schritt 30, stellt die abschließende Checkliste für die Bereitschaft bereit. Sie umfasst den ISMS-Geltungsbereich und Kontext, die freigegebene Informationssicherheitsleitlinie, Dokumente zur Risikobeurteilung und Risikobehandlung, SoA, Annex A-Richtlinien und -Verfahren, Schulungsaufzeichnungen, operative Aufzeichnungen, Bericht des internen Audits, Korrekturmaßnahmenprotokoll, Protokolle der Managementbewertung, Nachweise zur kontinuierlichen Verbesserung und Aufzeichnungen zu Compliance-Verpflichtungen.

Die unternehmensweite Richtlinie zur Audit- und Compliance-Überwachung von Clarysec beschreibt den Zweck dieser Disziplin:

„Belastbare Nachweise und einen Prüfpfad zur Unterstützung regulatorischer Anfragen, Gerichtsverfahren oder Kundenanfragen zur Vertrauensbildung erzeugen.“

Quelle: Richtlinie zur Audit- und Compliance-Überwachung, Ziele, Richtlinienklausel 3.4. Richtlinie zur Audit- und Compliance-Überwachung

Ein ausgereiftes Nachweisdossier zu TOMs nach Article 32 sollte Folgendes enthalten:

Nächste Schritte: Nachweise zu TOMs nach Article 32 mit Clarysec aufbauen

Wenn Sie technische und organisatorische Maßnahmen nach GDPR Article 32 nachweisen müssen, beginnen Sie nicht mit dem Sammeln zufälliger Screenshots. Beginnen Sie mit Nachvollziehbarkeit.

1. Definieren Sie den ISMS-Geltungsbereich und die Grenzen der Verarbeitung personenbezogener Daten.
2. Identifizieren Sie Anforderungen aus GDPR, NIS2, DORA, Verträgen und Kundenanforderungen.
3. Erstellen Sie Risikokriterien auf Basis von ISO/IEC 27005:2022 und der vom Management genehmigten Risikobereitschaft.
4. Erstellen oder aktualisieren Sie das Risikoregister.
5. Ordnen Sie jede Behandlung den Kontrollen nach ISO 27001:2022 und der SoA zu.
6. Nutzen Sie Zenith Controls, um Datenschutz-, Kryptographie-, Lieferanten-, Vorfalls- und unabhängige Überprüfungskontrollen über Compliance-Erwartungen hinweg querzuverweisen.
7. Folgen Sie Zenith Blueprint Schritt 13 und Schritt 14, um Risiken, Kontrollen und regulatorische Verpflichtungen zu verbinden.
8. Nutzen Sie Zenith Blueprint Schritt 19, um technische Kontrollen im Betrieb zu verifizieren.
9. Nutzen Sie Zenith Blueprint Schritt 30, um das endgültige auditbereite Nachweisdossier zusammenzustellen.
10. Speichern Sie alle Nachweise zentral, kennzeichnen Sie sie nach Risiko und Kontrollthema und halten Sie Korrekturmaßnahmen sichtbar.

Clarysec kann Ihnen helfen, GDPR Article 32 von einer vagen Compliance-Verpflichtung in ein belastbares, risikobasiertes Nachweissystem zu überführen, das an ISO 27001:2022, NIS2 und DORA ausgerichtet ist.

Beginnen Sie mit dem Zenith Blueprint, stärken Sie ihn mit Clarysec-Richtlinien und nutzen Sie Zenith Controls, um jede TOM nachvollziehbar, prüfbar und auditbereit zu machen.