Personenbezogene Daten (PII) in Sicherheitsprotokollen: Playbook für GDPR, NIS2 und DORA

Ein Sicherheitsanalyst öffnet um 02:17 Uhr das SIEM. Die Warnmeldung wirkt zunächst routinemäßig: mehrere fehlgeschlagene Anmeldungen, eine erfolgreiche Sitzung von einer ungewöhnlichen IP-Adresse und anschließend eine Reihe von API-Aufrufen gegen einen Export-Endpunkt für Kundendaten. Innerhalb weniger Minuten ist der Vorfallkanal voll. Der CISO will wissen, ob es sich um eine Kontoübernahme handelt. Die Rechtsabteilung fragt, ob die Protokolle personenbezogene Daten enthalten. Der Datenschutzbeauftragte fragt, ob Benutzerkennung, IP-Adresse, Gerätekennung und Request-URLs im SIEM durch den Datenschutzhinweis und das Verzeichnis von Verarbeitungstätigkeiten abgedeckt sind. Der Compliance-Verantwortliche fragt, ob die Protokolle für regulatorische Meldungen gesichert werden müssen. Die Kundenbetreuung fragt, ob ein Kunde morgen die Löschung derselben Protokolleinträge verlangen kann.

An diesem Punkt stellen viele Organisationen fest, dass Sicherheitsprotokollierung und Datenschutz-Governance als getrennte Welten aufgebaut wurden.

Sicherheitsteams benötigen detaillierte Protokolle, lange Aufbewahrungsfristen, unveränderliche Speicherung und schnellen Zugriff. Datenschutzteams verlangen Datenminimierung, Zweckbindung, rollenbasierten Zugriff, disziplinierte Aufbewahrung und Löschung, sobald Daten nicht mehr benötigt werden. Incident Handler benötigen unverändert gesicherte Nachweise. Die Rechenschaftspflicht nach GDPR verlangt, dass die Organisation erklären kann, warum personenbezogene Daten vorhanden sind, wer darauf zugegriffen hat und wie lange sie aufbewahrt werden. NIS2 und DORA erhöhen die Dringlichkeit, weil wesentliche Einrichtungen, wichtige Einrichtungen und Finanzunternehmen ausreichende Nachweise benötigen, um Vorfälle zu klassifizieren, fristgerecht zu melden und wirksames IKT-Risikomanagement nachzuweisen.

Die unbequeme Wahrheit ist einfach: Sicherheitsprotokolle sind häufig Ablagen für personenbezogene Daten. Authentifizierungsprotokolle können Benutzernamen, E-Mail-Adressen, IP-Adressen, Geräte-Fingerprints und Geolokalisierungsdaten enthalten. Anwendungsprotokolle können URLs, Suchbegriffe, Payload-Fragmente, Fallnummern und Nachrichteninhalte offenlegen. EDR- und Cloud-Protokolle können Hostnamen mit Bezug zu Beschäftigten, Dateipfade mit Namen, Sitzungskennungen und Administratorhandlungen enthalten. IAM-Protokolle können Berechtigungsänderungen, Gruppenmitgliedschaften und fehlgeschlagene Zugriffsversuche auf sensitive Systeme offenlegen.

Wenn Protokolle personenbezogene Daten enthalten, sind sie nicht mehr nur ein ISO 27001-Thema der Protokollierung. Sie werden zu einem Thema für Datenschutz, Aufbewahrung, Nachweise, Vorfallmeldung und Lieferanten-Governance. Clarysec behandelt Governance für personenbezogene Daten in Sicherheitsprotokollen als übergreifendes Compliance-Thema, nicht als reine Werkzeugkonfiguration.

Das eigentliche Dilemma des CISO: Erkennungsnachweise versus Datenminimierung

Der CISO im 02:17-Szenario steht vor einem echten operativen Zielkonflikt. Sind Protokolle zu knapp, kann das SOC eine Kompromittierung nicht erkennen, Zeitachsen nicht rekonstruieren und Meldungen nach NIS2 und DORA nicht unterstützen. Sind Protokolle zu umfangreich, kann die Organisation mehr personenbezogene Daten als erforderlich erheben, sie zu lange aufbewahren, sie zu vielen Administratoren zugänglich machen oder Betroffenenrechte und Transparenzpflichten nach GDPR nicht angemessen unterstützen.

GDPR definiert personenbezogene Daten weit als Informationen, die sich auf eine identifizierte oder identifizierbare Person beziehen. Verarbeitung umfasst Erhebung, Speicherung, Nutzung, Offenlegung, Löschung und Vernichtung. In der Praxis können Protokolle mit IP-Adressen, Benutzerkennungen, Gerätekennungen oder Aktivitätsaufzeichnungen je nach Kontext personenbezogene Daten sein. Die Grundsätze der GDPR verlangen rechtmäßige, faire und transparente Verarbeitung, Zweckbindung, Datenminimierung, Speicherbegrenzung, Integrität und Vertraulichkeit sowie Rechenschaftspflicht.

Die Governance-Frage lautet nicht: „Dürfen wir personenbezogene Daten überhaupt protokollieren?“ Die bessere Frage lautet: „Welche personenbezogenen Daten müssen wir für Sicherheit, Incident Response und Compliance protokollieren, welche Rechtsgrundlage trägt dies, welche Schutzmaßnahmen gelten und wann müssen die Daten gelöscht, anonymisiert oder unter eine genehmigte Aufbewahrungssperre gestellt werden?“

Die Enterprise-Datenschutzrichtlinienbibliothek von Clarysec adressiert diese Spannung direkt. Die Richtlinie zu Datenschutz und Privatsphäre, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.2.1, stellt fest:

Es dürfen nur Daten erhoben und verarbeitet werden, die für einen konkreten, legitimen Geschäftszweck erforderlich sind.

Für KMU wird derselbe Grundsatz in der Richtlinie zu Datenschutz und Privatsphäre für KMU, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.2.1, formuliert:

Es dürfen nur die mindestens erforderlichen personenbezogenen Daten erhoben und aufbewahrt werden.

Dieser Satz sollte jede Designentscheidung zur Protokollierung steuern. Ist jedes Feld in jeder Protokollquelle für einen definierten sicherheitsbezogenen, operativen, rechtlichen oder vertraglichen Zweck erforderlich?

Warum ISO 27701 die Protokollierungsdiskussion verändert

ISO/IEC 27001:2022 liefert das Managementsystem: Geltungsbereich, interessierte Parteien, Risikobeurteilung, Risikobehandlung, operative Steuerung, Überwachung, internes Audit und kontinuierliche Verbesserung. ISO/IEC 27002:2022 liefert praxisorientierte Kontrollleitlinien für Protokollierung, Überwachung, Schutz personenbezogener Daten, Beweissicherung, Schutz von Aufzeichnungen, Löschung, Zugriffskontrolle und Lieferantenmanagement. ISO/IEC 27701 erweitert das Governance-Modell um das Datenschutz-Informationsmanagement mit Fokus auf PII-Verantwortliche und Auftragsverarbeiter, Datenschutzrollen, Aufzeichnungen zur PII-Verarbeitung, Datenschutz durch Technikgestaltung, Bearbeitung von Betroffenenrechten und Pflichten von Auftragsverarbeitern.

Für Sicherheitsprotokolle ist ISO 27701 relevant, weil sie datenschutzspezifische Fragen erzwingt, die Sicherheitsteams mitunter überspringen:

• Verarbeitet die Protokollquelle personenbezogene Daten als Verantwortlicher, Auftragsverarbeiter, gemeinsam Verantwortlicher oder Unterauftragsverarbeiter?
• Sind die Protokolldaten im Verarbeitungsinventar enthalten?
• Weiß die Organisation, welche Protokollfelder personenbezogene Daten enthalten?
• Sind personenbezogene Daten in Protokollen mit Aufbewahrungs- und Löschregeln verknüpft?
• Werden Kunden eines Auftragsverarbeiters über Zugriffsprotokollierung für personenbezogene Daten informiert, sofern dies vertraglich erforderlich ist?
• Werden Protokolle bei der Beantwortung von Auskunfts-, Lösch- oder Einschränkungsanträgen berücksichtigt?
• Werden Datenschutzvorfälle über Datenschutz-, Cybersicherheits- und Finanzsektor-Meldeauslöser hinweg bewertet?

Die Richtlinie für Sicherheit und Zugriffskontrolle personenbezogener Daten von Clarysec übersetzt dies in Betriebsanforderungen. Aus Protokollierung und Überwachung, Klausel 4.6.1:

[Beide] Der Systemverantwortliche / Anwendungsverantwortliche MUSS den Umfang der PII-Protokollierung für Authentifizierungsereignisse, Zugriffsereignisse, privilegierte Aktionen, PII-Exportaktivitäten und wesentliche Konfigurationsänderungen vor der Produktivnutzung oder vor wesentlichen Änderungen in REG12 definieren.

Klausel 4.6.2 schließt anschließend den Regelkreis zwischen Protokollierung, Zugriffskontrolle und Aufbewahrung:

[Beide] Der Informationssicherheitsverantwortliche MUSS sicherstellen, dass Protokolle mit personenbezogenen Daten zugriffsbeschränkt sind und vor Beginn der Protokollüberwachung mit einer genehmigten Aufbewahrungs- oder Löschregel in REG02 oder REG12 verknüpft werden.

Dadurch wird PIMS-Governance praktisch umsetzbar. REG12 definiert, welche PII-Protokollierung zulässig und erforderlich ist. REG02 identifiziert, wo personenbezogene Daten vorhanden sind, einschließlich Protokollen. Aufbewahrungs- und Löschregeln sind kein nachträglich ergänzter Papiernachweis. Sie werden zu Vorbedingungen für die Protokollierung in der Produktion.

Sicherheitsprotokolle sind Aufzeichnungen, Nachweise und Verarbeitungstätigkeit für personenbezogene Daten

Eine reife Organisation sollte Protokolle nicht als wegwerfbares technisches Nebenprodukt behandeln. Protokolle sind Aufzeichnungen. Während eines Vorfalls können sie zu rechtlichen Beweismitteln werden. Wenn sie personenbezogene Daten enthalten, sind sie außerdem datenschutzrelevante Verarbeitungsdaten.

Die Richtlinie zur Protokollierung und Überwachung von Clarysec definiert Erwartungen an die Protokollnormalisierung. Aus Governance-Anforderungen, Klausel 5.1.4:

Anforderungen an Protokollformat und Normalisierung (z. B. Zeitstempel, Benutzerkennung, Ereignistyp, Quell-IP)

Genau diese Felder machen Protokolle für Incident Response nützlich. Es sind zugleich die Felder, die Protokolle häufig zu personenbezogenen Daten machen. Dieselbe Enterprise-Richtlinie markiert, was niemals passieren darf, aus Governance-Anforderungen, Klausel 5.3.3:

Speicherung sensitiver Daten im Klartext (z. B. Passwörter, kryptografische Geheimnisse)

Der Punkt ist nicht, dass Protokolle alle Kennungen vermeiden sollen. Der Punkt ist, dass Kennungen bewusst, geschützt und begründet sein müssen. Passwörter, Geheimnisse, vollständige Token und unnötige Payloads dürfen nicht protokolliert werden. Benutzerkennungen, IP-Adressen und Ereignismetadaten können erforderlich sein, benötigen aber Kontrollen.

Für KMU verankert die Richtlinie zur Protokollierung und Überwachung für KMU von Clarysec die Datenschutzprüfung in der Rollenstruktur. Aus Rollen und Verantwortlichkeiten, Klausel 4.3.1, verlangt sie von der Organisation:

Sie prüft, dass Protokolldaten mit Bezug zu personenbezogenen oder sensitiven Informationen im Einklang mit GDPR und anderen Datenschutzgesetzen gehandhabt werden.

Die KMU-Version gibt außerdem eine klare Baseline für die Aufbewahrung vor. Aus Governance-Anforderungen, Klausel 5.2.1:

Protokolle müssen mindestens 12 Monate aufbewahrt werden, sofern keine längere Aufbewahrungsfrist gesetzlich oder vertraglich vorgeschrieben oder im Rahmen eines aktiven Vorfalls oder Rechtsstreits begründet ist.

Und sie legt die Schutzerwartung fest, aus Governance-Anforderungen, Klausel 5.3.1:

Protokolle müssen an schreibgeschützten Speicherorten gespeichert werden, und der Zugriff muss auf autorisiertes Personal beschränkt sein.

Für Enterprise-Incident-Response verlangt die Richtlinie zur Beweissicherung und Forensik, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.3.1:

Protokolle aus Firewalls, SIEM, Endpoint-Agenten, Identitäts- und Zugriffsmanagementplattformen (IAM) und Cloud-Plattformen sind zu exportieren und in unveränderlichen Formaten zu speichern.

Die KMU-Version ergänzt eine Verhältnismäßigkeitsleitplanke. Die Richtlinie zur Beweissicherung und Forensik für KMU, Risikobehandlung und Ausnahmen, Klausel 7.2.1, stellt fest:

Den Umfang der Erhebung minimieren; nur erfassen, was erforderlich ist.

Das ist der Kern datenschutzbewusster Protokollierung: bewahren, was erforderlich ist, begründen, warum es erforderlich ist, einschränken, wer es sehen darf, und löschen, wenn der genehmigte Zweck abgelaufen ist.

Das Clarysec-Kontrollmodell für datenschutzsichere Nachweise

In Zenith Blueprint: Eine 30-Schritte-Roadmap für Auditoren ordnet Clarysec Protokollierung der Phase „Controls in Action“, Schritt 19: Technische Maßnahmen I, zu. Der Leitfaden erläutert die Kontrollerwartung aus ISO/IEC 27002:2022:

A.8.15 – Protokollierung: „Protokolle, die Aktivitäten, Ausnahmen, Fehler und andere relevante Ereignisse aufzeichnen, sollten erzeugt, gespeichert, geschützt und analysiert werden.“

Derselbe Schritt weist Organisationen an, Protokolle für Schlüsselereignisse zu erzeugen, sie sicher und gegen Veränderung geschützt zu speichern, sie für einen definierten Zeitraum aufzubewahren und sie über ein SIEM oder einen Prüfprozess zu analysieren. Außerdem verbindet er Protokollierung mit Meldungen von Datenschutzverletzungen nach GDPR, DORA-Vorfallsaufzeichnungen, NIS2-Risikomanagement und COBIT-Sicherheitsprotokollanalyse.

Protokollierung allein reicht jedoch nicht aus. In derselben Phase „Controls in Action“, Schritt 19, behandelt Zenith Blueprint die Löschung. Der Leitfaden warnt, dass Daten, die über ihren operativen Wert hinaus aufbewahrt werden, Exponierung und regulatorisches Risiko erhöhen, und nennt ausdrücklich Backups, Snapshots und Archive. Das ist relevant, weil eine SIEM-Aufbewahrungsregel bedeutungslos ist, wenn replizierte Protokollarchive oder Cloud-Objektspeicher-Buckets dieselben personenbezogenen Daten unbegrenzt behalten.

In Schritt 23: Organisatorische Maßnahmen behandelt Zenith Blueprint die Beweissicherung. Der Leitfaden stellt fest, dass Vorfallsnachweise so identifiziert, erhoben und gesichert werden müssen, dass sie rechtlich zulässig, verlässlich und an Untersuchungsanforderungen ausgerichtet sind. Er betont außerdem eine operative Realität: Nachweise gehen häufig in den ersten Minuten der Reaktion verloren, wenn Protokolle rotieren, Systeme neu gestartet werden oder Administratoren kompromittierte Konten ändern, bevor Snapshots erstellt wurden.

Schritt 23 behandelt außerdem Datenschutz und Schutz personenbezogener Daten. Der Leitfaden rahmt personenbezogene Daten als Lebenszyklusthema, das Datenbewusstsein, Klassifizierung, Zugriffskontrolle, Maskierung, Löschung, Verschlüsselung und Lieferantenpflichten erfordert. Für Protokolle bedeutet das, dass SIEM, EDR, Cloud-Protokollierungsplattform und Ticketsystem Teil des PII-Inventars sein müssen.

Cross-Compliance-Zuordnung für personenbezogene Daten in Protokollen

Zenith Controls: Der Cross-Compliance-Leitfaden ordnet ISO/IEC 27002:2022 Maßnahme 8.15, Protokollierung, verwandten Maßnahmen zu, die für PII-Governance wesentlich sind. Diese Beziehungen zeigen, warum Protokollierung nicht nur ein SOC-Thema ist.

Zenith Controls ordnet Protokollierung außerdem ISO/IEC 27002:2022 Klausel 8.15, ISO/IEC 27035-1 und ISO/IEC 27035-2 für Vorfallmanagement, ISO/IEC 27701 für die Protokollierung von PII-Verarbeitungstätigkeiten, ISO/IEC 27017 für Cloud-Audit-Protokolle, ISO/IEC 27018 für Cloud-PII-Zugriffsprotokollierung, ISO/IEC 27005 für Risiken aus unzureichender Protokollierung, ISO/IEC 27033 für Protokollierung von Netzwerkaktivitäten und ISO/IEC 15408-2 für Audit-Funktionalität in evaluierten Produkten zu.

Für Datenschutz ordnet Zenith Controls ISO/IEC 27002:2022 Maßnahme 5.34, Datenschutz und Schutz von PII, insbesondere Asset-Inventar, Datenmaskierung, Cloud-Services, Klassifizierung, Informationsübermittlung, Zugriffskontrolle, Identitätsmanagement und Sicherheitsprüfung von Projekten und Änderungen zu. Für ein Programm zur Governance der Protokollierung werden diese Verknüpfungen zu praktischen Designanforderungen:

• Protokollspeicher als Speicherorte für personenbezogene Daten inventarisieren.
• Personenbezogene Daten maskieren oder tokenisieren, wenn vollständige Kennungen nicht erforderlich sind.
• Cloud-Protokollierungsdienste und SIEM-Anbieter unter Cloud- und Lieferantenkontrollen prüfen.
• Protokolle mit personenbezogenen Daten als sensitive Aufzeichnungen klassifizieren.
• Protokollexporte und -übermittlungen als Übermittlungen personenbezogener Daten steuern.
• Protokollzugriff über Identitäts- und Privileged-Access-Kontrollen beschränken.
• Änderungen an der Anwendungsprotokollierung vor der Produktivfreigabe prüfen.

GDPR, NIS2 und DORA: ein Protokolleintrag, drei regulatorische Perspektiven

Derselbe Protokolleintrag kann unter GDPR, NIS2 und DORA unterschiedlich betrachtet werden.

Unter GDPR fragt die Organisation, ob der Protokolleintrag personenbezogene Daten enthält, welche Rechtsgrundlage die Verarbeitung trägt, ob die Daten erforderlich sind, wie lange sie aufbewahrt werden, wer darauf zugreifen kann, ob sie gegenüber Auftragsverarbeitern oder Kunden offengelegt werden und ob sie in einer Betroffenenanfrage oder Bewertung einer Datenschutzverletzung zu berücksichtigen sind.

Unter NIS2 fragt die Organisation, ob Protokolle Cybersicherheitsrisikomanagement, Verfahren zum Umgang mit Sicherheitsvorfällen, Aufrechterhaltung des Betriebs, Zugriffskontrolle, Sicherheit der Lieferkette und Bewertung der Kontrollwirksamkeit unterstützen. NIS2 Article 20 macht Leitungsorgane für die Genehmigung und Überwachung von Maßnahmen zum Cybersicherheitsrisikomanagement verantwortlich. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Verfahren zum Umgang mit Sicherheitsvorfällen, Aufrechterhaltung des Betriebs, Sicherheit der Lieferkette, sichere Entwicklung, Schwachstellenmanagement, Wirksamkeitsbewertung, Cyberhygiene, Zugriffskontrolle und Asset-Management. Article 23 schafft gestufte Meldungen für erhebliche Vorfälle, einschließlich Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats.

Unter DORA müssen Finanzunternehmen ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken betreiben. DORA Article 5 weist dem Leitungsorgan Verantwortung zu. Article 10 behandelt Erkennung. Article 17 verlangt einen Prozess für das Management IKT-bezogener Vorfälle. Article 18 behandelt die Klassifizierung IKT-bezogener Vorfälle und Cyberbedrohungen. Article 19 behandelt die Meldung schwerwiegender IKT-bezogener Vorfälle. Protokolle unterstützen Erkennung, Klassifizierung, Ursachenanalyse, Auswirkungsbewertung, Reaktion, Wiederherstellung und Nachweise der Abhilfemaßnahmen.

Eine detailliertere Kontrollzuordnung hilft dem CISO, Protokollierung zu begründen, ohne sich auf vage Aussagen wie „wir brauchen das für Sicherheit“ zu stützen.

Umfang der PII-Protokollierung in REG12 aufbauen

Ein Clarysec-Kunde würde den SIEM-Vorfall um 02:17 Uhr behandeln, bevor er überhaupt eintritt. Die Organisation beginnt mit einer kundenbezogenen Anwendung, die Kontodaten verarbeitet. Vor der Produktivsetzung nutzt der Anwendungsverantwortliche REG12, um den Umfang der PII-Protokollierung zu definieren. Ziel ist es, genügend Ereignisse für Sicherheits- und regulatorische Nachweise zu erfassen, ohne unnötige personenbezogene Daten oder Payload-Inhalte zu protokollieren.

Anschließend bestätigt die Datenschutzleitung, ob die Organisation für jede Protokollquelle als Verantwortlicher, Auftragsverarbeiter oder beides handelt. Ist die Organisation Auftragsverarbeiter, können Kundenweisungen und Offenlegungen zu Unterauftragsverarbeitern den Protokollzugriff und die Weitergabe beschränken. Ist sie Verantwortlicher, müssen Datenschutzhinweise, Rechtsgrundlage und Bearbeitung von Betroffenenrechten adressiert werden.

Der Dateneigentümer aktualisiert anschließend REG02, um aktive Protokollspeicher, SIEM-Indizes, Archive, Backups und temporäre forensische Exporte aufzunehmen. Dies entspricht der Richtlinie für PII-Aufbewahrung, Löschung und Entsorgung, Backups, Archive, Replikate, Protokolle und temporäre Dateien, Klausel 4.4.1:

[Beide] Der Systemverantwortliche / Anwendungsverantwortliche MUSS Live-Speicher, Archive, Sicherungskopien, Replikate, Protokolle, Staging-Bereiche und temporäre Dateien mit personenbezogenen Daten vor dem Produktivstart und im Rahmen jeder jährlichen Aufbewahrungsprüfung in REG02 identifizieren.

Die Richtlinie zur Datenaufbewahrung und Entsorgung sollte anschließend geschäftliche Aufbewahrungsregeln mit rechtlichen, vertraglichen und nachweisbezogenen Sicherungsanforderungen in Einklang bringen.

Zum Schluss konfiguriert das Sicherheitsteam das SIEM so, dass Passwörter, Geheimnisse und Payload Bodies vor der Aufnahme in das SIEM verworfen oder redigiert werden. Protokolle mit personenbezogenen Daten werden eingeschränkten Indizes zugeordnet. Die Aufbewahrung wird automatisch durchgesetzt, sofern kein Vorfall oder Legal Hold genehmigt ist. Löschhandlungen werden protokolliert. Forensische Exporte erfordern Genehmigung und Nachverfolgung der Übertragungskette. Dashboards zeigen pseudonymisierte Kennungen, wenn die vollständige Identität nicht benötigt wird. Der historische Abruf von Protokollen wird im Rahmen interner Audits getestet.

Das ist der Unterschied zwischen der Aussage „wir protokollieren aus Sicherheitsgründen“ und dem Nachweis „wir protokollieren nur, was erforderlich ist, schützen es, bewahren es nach genehmigten Regeln auf und können es als Nachweis nutzen, ohne Datenschutzpflichten zu verletzen.“

DSARs, Löschung und Protokolle: entscheiden, bevor die Anfrage eintrifft

Eine der schwierigsten Fragen ist, ob Protokolle als Reaktion auf Auskunftsersuchen betroffener Personen oder Löschanträge durchsucht, offengelegt oder gelöscht werden müssen. Die Antwort hängt von Rolle, Zweck, Rechtsgrundlage, Machbarkeit, Ausnahmen und Aufbewahrungspflichten ab. Der Governance-Prozess darf jedoch nicht von Anfrage zu Anfrage neu erfunden werden.

Die Richtlinie zum Management von Betroffenenrechten, Identitätsprüfung, Geltungsbereich und Bewertung, Klausel 4.2.3, stellt fest:

[Verantwortlicher] Der Prozessverantwortliche / Geschäftsverantwortliche MUSS vor der Bewertung der Erfüllung relevante Systeme, Aufzeichnungen, Zwecke, PII-Kategorien, Empfänger und Aufbewahrungsbeschränkungen aus REG02 identifizieren.

Das bedeutet: Protokolle müssen mit klaren Metadaten in REG02 enthalten sein – welche PII-Kategorien sie enthalten, welchem Zweck sie dienen, welche Aufbewahrungsbeschränkung gilt und ob eine Anfrage durch direkte Offenlegung, zusammengefasste Auskunft, Einschränkung, Löschung bei Fristablauf oder Ablehnung auf dokumentierter Rechtsgrundlage erfüllt werden kann.

Clarysec empfiehlt einen dreistufigen Ansatz:

1. Betriebsprotokolle mit geringer Datenschutzwirkung, etwa Systemereignisprotokolle mit pseudonymen Benutzerkennungen, können gegebenenfalls durchsuchbar und offenlegbar sein.
2. Sicherheitsprotokolle mit hoher Sicherheitssensitivität, etwa SIEM-Korrelationsdaten oder Kontext aus Bedrohungsinformationen, können Filterung, zusammengefasste Offenlegung oder Einschränkung erfordern, um Erkennungslogik oder Daten Dritter nicht offenzulegen.
3. Forensische Beweismittel unter aktivem Vorfall oder Legal Hold sollten nicht unüberlegt verändert werden. Eine Löschung kann aufgeschoben oder eingeschränkt werden, sofern dies rechtlich begründet ist; die Entscheidung ist durch Datenschutz- und Rechtsverantwortliche zu dokumentieren.

Wenn Datenschutzbeauftragter und SOC jede DSAR von Grund auf diskutieren, wird die Organisation inkonsistent und langsam. Wenn REG02 und REG12 gepflegt werden, wird die Bearbeitung von Betroffenenrechten nachweisbasiert.

Meldung von Datenschutzverletzungen und Vorfällen: ein Ereignis, mehrere Fristen

Die Warnmeldung um 02:17 Uhr kann mehrere Fristen auslösen. Die Bewertung einer Verletzung des Schutzes personenbezogener Daten nach GDPR kann eine Meldung an eine Aufsichtsbehörde erfordern, wenn Risikoschwellen erreicht sind. Die Meldung erheblicher Vorfälle nach NIS2 kann eine Frühwarnung binnen 24 Stunden, eine Meldung binnen 72 Stunden und einen Abschlussbericht erfordern. DORA kann die Meldung schwerwiegender IKT-bezogener Vorfälle über initiale, Zwischen- und Abschlussphasen verlangen. Kundenverträge können noch kürzere Mitteilungsfenster enthalten.

Die Richtlinie zum Management von PII-Vorfällen und Datenschutzverletzungen von Clarysec adressiert dieses Problem übergreifender Meldeauslöser direkt. Aus Klassifizierung und Bewertung der Datenschutzverletzung, Klausel 4.2.6:

[Bedingt] Der Datenschutzverantwortliche / PIMS-Manager MUSS für jeden PII-Vorfall mit hoher Auswirkung anwendbare gesetzliche, sektorale, finanzsektorbezogene, cybersicherheitsbezogene, vertragliche, kundenbezogene und leistungsempfängerbezogene Meldeauslöser bewerten und das Ergebnis der Anwendbarkeit in REG01, REG08 und REG10 dokumentieren.

Während der Triage sollte die Organisation fragen:

• Hat der Angreifer auf personenbezogene Daten zugegriffen oder nur auf Metadaten?
• Haben die Protokolle zusätzliche personenbezogene Daten gegenüber unbefugten Benutzern offengelegt?
• Werden Protokolle benötigt, um betroffene Personen, Systeme und Zeitraum zu bestimmen?
• Sind Protokolle unveränderlich gespeichert und zugriffsbeschränkt?
• Hat eine vorfallbezogene Aufbewahrungssperre die Löschung relevanter Protokolle ausgesetzt?
• Sind Kunden, für die die Organisation Auftragsverarbeiter ist, Finanzsektorkunden oder Leistungsempfänger betroffen?
• Welche Meldefristen gelten, und wer ist für jede Meldung verantwortlich?

Gut gesteuerte Protokolle beschleunigen Meldungen, weil sie Entscheidungsträgern verlässliche Fakten liefern. Schlechte Protokollierung verursacht Verzögerung. Übermäßige Protokollierung schafft Datenschutzrisiken. Die richtige Antwort ist zielgerichtete, geschützte und zugeordnete Protokollierung.

Lieferanten- und Cloud-Protokollierung: das im SIEM verborgene Auftragsverarbeiterproblem

Die meisten Organisationen speichern nicht alle Protokolle auf Infrastruktur, die sie vollständig kontrollieren. Protokolle fließen in SIEM-Plattformen, EDR-Portale, cloudnative Protokollierungsdienste, Observability-Werkzeuge, Ticketsysteme und Managed-Detection-and-Response-Anbieter. Unter GDPR können diese Anbieter Auftragsverarbeiter oder Unterauftragsverarbeiter sein. Unter NIS2 und DORA können sie außerdem direkte Lieferanten, IKT-Drittdienstleister, Managed Service Provider oder Anbieter verwalteter Sicherheitsdienste sein.

NIS2 Article 21 umfasst ausdrücklich Sicherheit der Lieferkette, Schwachstellen bei Lieferanten und die gesamten Cybersicherheitspraktiken von Lieferanten. DORA ergänzt detaillierte Anforderungen an IKT-Drittparteienrisiken für Finanzunternehmen, einschließlich vorvertraglicher Due Diligence, Informationsregister, Audit- und Zugriffsrechte, Vorfallsunterstützung, Datenstandort, Datenschutzklauseln, Exit-Strategien und Vertragsbestimmungen für kritische oder wichtige Funktionen.

Für personenbezogene Daten in Sicherheitsprotokollen sollten Lieferantenprüfungen diese Fragen enthalten:

Ein SIEM-Vertrag ist nicht nur ein Softwareabonnement. Er ist eine Abhängigkeit für PII-Verarbeitung und Vorfallsnachweise.

Audit-Perspektive: wie Prüfer personenbezogene Daten in Sicherheitsprotokollen testen

Ein guter Auditor akzeptiert die Aussage „Protokolle sind geschützt“ nicht. Er prüft die Kette von Richtlinie über Konfiguration und Nachweis bis zur Überprüfung.

Ein praktischer Audittest ist einfach, aber aufschlussreich: Bitten Sie das SOC, einen zehn Monate alten Protokolleintrag abzurufen, der eine privilegierte Zugriffsänderung in einer Cloud-Plattform zeigt; nachzuweisen, wer auf dieses Protokoll zugegriffen hat; nachzuweisen, dass es nicht verändert wurde; die Aufbewahrungsregel zu zeigen, die seine Existenz erlaubt; die enthaltenen Felder mit personenbezogenen Daten zu zeigen; und darzustellen, wie der Eintrag in einer DSAR oder einem Vorfallsbericht behandelt würde. Wenn das Team dies über Sicherheit, Datenschutz und Compliance hinweg nicht beantworten kann, ist die Governance unvollständig.

Häufige Feststellungen in Audits zu PII-Protokollen

Clarysec sieht häufig dieselben Muster:

• Anwendungsteams protokollieren vollständige Request-Payloads zu Debugging-Zwecken, einschließlich Namen, E-Mail-Adressen, Kontonummern oder Nachrichteninhalten.
• SIEM-Indizes sind für breite IT-Administratorgruppen statt für eingeschränkte SOC-Rollen geöffnet.
• Die Protokollaufbewahrung wird global gesetzt, ohne Sensitivität personenbezogener Daten, Kundenverträge oder Regeln für vorfallbezogene Aufbewahrungssperren zu berücksichtigen.
• Cloud-Anbieterprotokolle sind aktiviert, aber der Administratorzugriff des Anbieters auf Kundenprotokolldaten wird nicht überprüft.
• DSAR-Verfahren erwähnen Protokolle, SIEM-Fälle oder forensische Exporte nicht.
• Incident-Response-Playbooks sichern Nachweise, aber Datenschutzteams sind nicht in die Klassifizierung eingebunden.
• Backups und Archive bewahren personenbezogene Daten aus Protokollen länger auf als das SIEM.
• Entwickler können Protokollierungsgrade in der Produktion ohne Datenschutz- oder Sicherheitsprüfung ändern.
• Testumgebungen erhalten Produktionsprotokolle mit personenbezogenen Daten.
• Die Organisation hat Meldepflichten nach NIS2 oder DORA, kann verlässliche Nachweise aber nicht schnell abrufen.

Diese Feststellungen entstehen selten aus böser Absicht. Sie entstehen durch isolierte Verantwortlichkeiten. Sicherheitsprotokolle liegen zwischen SOC, Plattform-Engineering, Datenschutz, Recht, Compliance, Audit und Lieferanten. Wenn niemand den gesamten Lebenszyklus verantwortet, entstehen Lücken.

Eine Clarysec-Checkliste für auditfähige Governance der Protokollierung

Nutzen Sie diese Checkliste als praktischen Ausgangspunkt für Ihre nächste Governance-Überprüfung:

1. Definieren Sie, welche Protokollquellen personenbezogene Daten enthalten können: IAM, Anwendung, API-Gateway, SIEM, EDR, Cloud, Datenbank, Netzwerk, physischer Zugriff und Ticketing.
2. Erfassen Sie jeden Protokollspeicher in REG02, einschließlich aktiver Speicher, Archive, Backups, Replikate und temporärer forensischer Exporte.
3. Definieren Sie den Umfang der PII-Protokollierung in REG12 vor Produktivnutzung oder wesentlichen Änderungen.
4. Identifizieren Sie Zweck und Rechtsgrundlage für die Verarbeitung von Sicherheitsprotokollen.
5. Verbieten Sie Passwörter, Geheimnisse, vollständige Token und unnötige Payloads in Protokollen.
6. Verwenden Sie Maskierung, Hashing oder Pseudonymisierung, wenn vollständige Kennungen nicht erforderlich sind.
7. Beschränken Sie den Zugriff auf Protokolle mit personenbezogenen Daten rollenbasiert, einschließlich Berechtigungsüberprüfung für privilegierten Zugriff.
8. Speichern Sie hochwertige Protokolle in unveränderlichen oder schreibgeschützten Formaten.
9. Definieren Sie Aufbewahrung nach Protokolltyp, rechtlicher Verpflichtung, Vertrag, Vorfallsbedarf und Datenschutzrisiko.
10. Implementieren Sie vorfallbezogene Aufbewahrungssperren mit Genehmigung, Geltungsbereich und Ablaufdatum.
11. Beziehen Sie Protokolle in die Bewertungslogik für DSARs und Löschanträge ein.
12. Prüfen Sie SIEM-, EDR-, Cloud- und MDR-Lieferanten als Auftragsverarbeiter oder IKT-Dritte.
13. Testen Sie historischen Abruf und Integrität der Nachweise.
14. Ordnen Sie Protokollierung den Meldeanforderungen aus GDPR, ISO 27701, NIS2, DORA, NIST CSF und COBIT zu.
15. Schulen Sie SOC-, Datenschutz- und Anwendungsteams dazu, was protokolliert werden darf und was nicht.

Diese Checkliste macht datenschutzbewusste Protokollierung zu einem wiederholbaren Kontrollprozess.

Vom Dilemma zum Vertrauen auf Ebene des Leitungsorgans

NIS2 macht Cybersicherheit zur Managementverantwortung. DORA macht das Leitungsorgan verantwortlich für IKT-Risikomanagement, Strategie zur digitalen operationalen Resilienz, Datenvertraulichkeit, Vorfallkommunikation und Richtlinien für IKT-Drittdienstleister. ISO/IEC 27001:2022 verlangt von der obersten Leitung, das ISMS an den Geschäftszielen auszurichten, Verantwortlichkeiten zuzuweisen, Ressourcen bereitzustellen und kontinuierliche Verbesserung voranzutreiben.

Personenbezogene Daten in Sicherheitsprotokollen sind daher kein enges technisches Detail. Es ist eine Vertrauensfrage auf Ebene des Leitungsorgans. Die Fähigkeit der Organisation, Vorfälle zu erkennen, personenbezogene Daten zu schützen, Nachweise zu sichern, Kunden zu antworten, Aufsichtsbehörden zufriedenzustellen und den Betrieb wiederherzustellen, hängt von Protokollierungsentscheidungen ab, die lange vor dem Vorfall getroffen wurden.

Die besten Governance-Programme wählen nicht zwischen Datenschutz und Sicherheit. Sie definieren die Mindestprotokollierung, die für robuste Sicherheit benötigt wird, schützen diese Protokollierung bei Bedarf als sensitive personenbezogene Daten und verknüpfen sie mit Aufbewahrung, Nachweisen, Bearbeitung von Betroffenenrechten und Lieferantenpflichten.

Nächste Schritte mit Clarysec

Wenn Ihre SIEM-, IAM-, EDR- oder Cloud-Protokolle personenbezogene Daten enthalten, ist jetzt der Zeitpunkt, sie bewusst zu steuern.

Clarysec kann Sie unterstützen:

• Aufbau eines Umfangs der PII-Protokollierung mit REG12 und Abgleich mit der Richtlinie für Sicherheit und Zugriffskontrolle personenbezogener Daten.
• Inventarisierung von Protokollspeichern, Archiven, Backups und forensischen Exporten mit REG02 und der Richtlinie für PII-Aufbewahrung, Löschung und Entsorgung.
• Ausrichtung von Protokollierung, Überwachung, Nachweisen und Datenschutzkontrollen an Zenith Blueprint.
• Zuordnung Ihrer Kontrollen über GDPR, ISO 27701, NIS2, DORA, NIST CSF und COBIT hinweg mit Zenith Controls.
• Vorbereitung auditfähiger Nachweise für Assurance-Prüfungen zu ISO, Datenschutz, NIST, COBIT, NIS2 und DORA.

Beginnen Sie mit einem Hochrisikosystem: Ihrer IAM-Plattform, Ihrem SIEM oder einer kundenbezogenen Anwendung. Ermitteln Sie, welche personenbezogenen Daten in die Protokolle gelangen, warum sie benötigt werden, wer darauf zugreifen kann, wie lange sie aufbewahrt werden und wie sie während eines Vorfalls oder einer Betroffenenanfrage genutzt würden. Diese einzelne Übung zeigt, ob Ihr aktuelles Protokollierungsprogramm lediglich operativ funktioniert oder tatsächlich auditfähig ist.