Datenklassifizierung für ISO 27001, GDPR, NIS2 und DORA
Der Audit-Moment 2026: „Zeigen Sie mir die Nachweise“
Es ist Februar 2026, und die vierteljährliche Sitzung des Leitungsorgans eines schnell wachsenden Fintech-SaaS-Unternehmens verläuft nicht so reibungslos, wie der CISO erwartet hatte.
Das Unternehmen hat vor Kurzem die Zertifizierung nach ISO/IEC 27001:2022 erreicht. Es verfügt über MFA, Endpunktschutz, Schwachstellenscans, Berechtigungsüberprüfungen, Verfahren zum Umgang mit Informationssicherheitsvorfällen und einen ausgearbeiteten DORA-Bereitschaftsbericht. Dann stellt der CEO die Frage, die die Stimmung im Raum verändert.
„Unser Hauptinvestor fragt, wie wir nachweisen können, dass Finanzdaten unserer Kunden über AWS, Azure, unsere SaaS-Supportplattform und das Analyse-Warehouse hinweg konsistent geschützt werden. Wenn ein Auditor eine Datei aus dem Objektspeicher und eine andere aus einem Kollaborationsordner zieht, woher wissen wir, dass sie denselben Regeln unterliegen?“
Der CISO öffnet das Asset-Register. Es enthält Datenbanken, Cloud-Konten, Anwendungen, SaaS-Plattformen und Speicherorte. Das Klassifizierungsfeld ist jedoch unvollständig. Einige Ordner sind nach Abteilung benannt, nicht nach Sensibilität. Kundenexporte liegen neben internen Berichtsdateien. Einige Support-Tabellen enthalten Kundenkennungen, Zahlungsreferenzen und Fallnotizen, sind aber als „intern“ gekennzeichnet. DLP-Regeln existieren, greifen aber nur bei offensichtlichen Mustern. Die Cloud-Richtlinie besagt, dass personenbezogene Daten aus der EU in genehmigten Regionen verbleiben müssen; das Team kann jedoch nicht nachweisen, dass Datenresidenzregeln aus Klassifizierungsmetadaten abgeleitet werden.
Dann ergänzt der Compliance-Manager die regulatorische Perspektive: „Genügt das für GDPR Article 32, NIS2 Article 21 und DORA-IKT-Risikonachweise?“
Die ehrliche Antwort lautet: noch nicht.
Das ist die Lücke, vor der 2026 viele Organisationen stehen. Sie haben Sicherheitskontrollen, aber nicht die Governance-Schicht, die jeder Kontrolle vorgibt, was zu schützen ist, wie stark es zu schützen ist und wie dies nachzuweisen ist. Diese Governance-Schicht besteht aus Datenklassifizierung und Informationskennzeichnung.
Im Kontext von ISO/IEC 27001:2022 sind Klassifizierung und Kennzeichnung keine kosmetischen Dokumentenmanagement-Praktiken. Sie bilden die praktische Brücke zwischen Risikobeurteilung, Zugriffskontrolle, Verschlüsselung, Aufbewahrung, DLP, Cloud-Datenresidenz, Lieferanten-Due-Diligence, Überwachung und Vorfallmeldung. Im Umsetzungsmodell von Clarysec stehen sie im Zentrum der ISMS-Nachweiskette: Asset inventarisieren, Verantwortlichen zuweisen, klassifizieren, kennzeichnen, Handhabungsregeln anwenden, Ausnahmen überwachen und Auditoren die Nachvollziehbarkeit zeigen.
Warum Klassifizierung und Kennzeichnung heute Kontrollen auf Ebene des Leitungsorgans sind
Aufsichtsbehörden und Kunden erwarten zunehmend, dass Organisationen nachweisen, dass Sicherheitsmaßnahmen der Sensibilität der Daten, der Kritikalität des Services und den geschäftlichen Auswirkungen eines Ausfalls angemessen sind.
GDPR macht dies über Rechenschaftspflicht ausdrücklich. Article 5 verlangt, dass personenbezogene Daten rechtmäßig, fair und transparent verarbeitet, auf das Erforderliche beschränkt, nur so lange wie nötig aufbewahrt und mit geeigneten technischen und organisatorischen Maßnahmen geschützt werden. Der Verantwortliche muss die Einhaltung außerdem nachweisen können. GDPR Article 32 lässt sich ohne Kenntnis darüber, welche Systeme personenbezogene Daten verarbeiten, welche Daten ein hohes Risiko oder besondere Kategorien darstellen, wo sie gespeichert sind und welche Schutzmaßnahmen gelten, nur schwer belegen.
NIS2 hebt die Anforderungen an Governance an. Article 20 verlangt von Leitungsorganen wesentlicher und wichtiger Einrichtungen, Maßnahmen zum Cybersicherheitsrisikomanagement zu genehmigen, deren Umsetzung zu überwachen und Schulungen zu erhalten. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Sicherheitsrichtlinien, Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, Sicherheit bei Beschaffung und Entwicklung, Wirksamkeitsbewertung, Cyberhygiene, Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle und Asset-Management. Klassifizierung ist in dieser Liste keine separate Checkbox. Sie ist das Entscheidungssystem, das diese Maßnahmen verhältnismäßig macht.
DORA wendet dieselbe Logik auf Finanzunternehmen und Fintech-Ökosysteme an. Seit dem 17. Januar 2025 verlangt DORA ein dokumentiertes IKT-Risikomanagementrahmenwerk, Verantwortung des Leitungsorgans, Richtlinien für Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität, Vorfallklassifizierung, Resilienztests und IKT-Drittparteienrisikomanagement. Für DORA-regulierte Finanzunternehmen kann DORA als sektorspezifischer Rechtsakt der Union an die Stelle sich überschneidender NIS2-Pflichten zum Risikomanagement und zur Berichterstattung treten; die Nachweiserwartung bleibt jedoch dieselbe: zeigen, wie kritische Informationen und IKT-Assets identifiziert, geschützt, getestet, überwacht und gesteuert werden.
ISO/IEC 27001:2022 eignet sich sehr gut als Betriebssystem für diese Nachweise. Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation interne und externe Themen, Anforderungen interessierter Parteien, regulatorische und vertragliche Verpflichtungen sowie Schnittstellen zu anderen Organisationen versteht. Die Klauseln 6.1.1 bis 6.1.3 verlangen Risikobeurteilung, Risikobehandlung, Kontrollauswahl, eine Anwendbarkeitserklärung und aufbewahrte Nachweise. ISO/IEC 27001:2022
Wenn GDPR, NIS2 und DORA fragen: „Warum haben Sie diese Maßnahmen angewendet?“, hilft ISO/IEC 27001:2022 bei der Antwort: „Weil diese Assets, Datentypen, Risiken, Verpflichtungen und Behandlungsentscheidungen uns hierher geführt haben.“
Klassifizierung ist die Risikoentscheidung. Kennzeichnung ist das operative Signal.
Clarysec trennt Klassifizierung und Kennzeichnung, weil Auditoren dies ebenfalls tun.
Klassifizierung ist die Entscheidung über Sensibilität, Wert und Kritikalität von Informationen. Kennzeichnung ist die Handlung, diese Entscheidung im Tagesgeschäft sichtbar, dauerhaft und durchsetzbar zu machen.
Clarysecs Richtlinie zur Datenklassifizierung und Kennzeichnung – KMU beschreibt den Zweck klar:
Diese Richtlinie legt fest, wie alle von der Organisation verarbeiteten Informationen klassifiziert und gekennzeichnet werden müssen, damit ihre Vertraulichkeit, Integrität und Verfügbarkeit während ihres gesamten Lebenszyklus gewahrt bleiben.
Dieselbe Richtlinie zur Datenklassifizierung und Kennzeichnung – KMU verlangt von Organisationen:
Es ist sicherzustellen, dass jedes Daten-Asset entsprechend seiner Sensibilität klassifiziert und entsprechend gekennzeichnet wird, um sachgerechte Handhabung, Speicherung und Zugriff zu steuern.
Für Unternehmensumgebungen definiert Clarysecs P13 Richtlinie zur Datenklassifizierung und Kennzeichnung das Mindestmodell für die Klassifizierung:
Die Organisation muss ein standardisiertes Klassifizierungsschema mit klar definierten Stufen unterhalten. Mindestens die folgenden Klassifizierungsstufen müssen verwendet werden: 5.1.1 Öffentlich: Informationen, die zur offenen Veröffentlichung und uneingeschränkten Verteilung bestimmt sind 5.1.2 Intern: Nicht öffentliche Geschäftsinformationen, die nicht für externe Veröffentlichung bestimmt sind 5.1.3 Vertraulich: Sensible Geschäfts-, Vertrags- oder Kundendaten, die eine strenge Zugriffskontrolle erfordern 5.1.4 Streng vertraulich (oder Hochvertraulich): Kritische oder regulierte Informationen, bei denen unbefugte Offenlegung zu erheblichem Schaden oder rechtlicher Haftung führen könnte
Diese Unterscheidung ist wesentlich. Eine Klassifizierung als „Vertraulich“ kann Verschlüsselung, rollenbasierten Zugriff und vertragliche Schutzmaßnahmen erfordern. Eine Klassifizierung als „Streng vertraulich“ kann MFA, CISO-Genehmigung für externe Weitergabe, erweiterte Protokollierung, strengere Aufbewahrungs-Governance, Trennung und priorisierte Vorfalleskalation auslösen.
Die Unternehmensrichtlinie ist hinsichtlich operativer Kennzeichnung eindeutig:
Alle Informations-Assets müssen so gekennzeichnet werden, dass die Kennzeichnung: 6.2.1.1 dauerhaft ist: nicht leicht entfernt oder überschrieben werden kann 6.2.1.2 sichtbar ist: für Benutzer am Ort der Nutzung eindeutig erkennbar ist 6.2.1.3 maschinenlesbar ist: soweit möglich muss metadatenbasierte Kennzeichnung unterstützt werden
Maschinenlesbare Kennzeichnungen sind der Punkt, an dem das Programm von Sensibilisierung zu Durchsetzung reift. Wenn Kennzeichnungen metadatenbasiert sind, können Cloud-Plattformen, DLP-Systeme, E-Mail-Gateways, Identitätswerkzeuge, SIEM-Regeln, CASB-Plattformen und Aufbewahrungs-Engines darauf reagieren. Wenn Kennzeichnungen nur als Fußzeile in einem Dokument erscheinen, unterstützen sie Benutzer, können Regeln aber nicht zuverlässig in großem Maßstab durchsetzen.
Wo Klassifizierung in die Clarysec-Roadmap gehört
Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren verankert Klassifizierung früh im Risikomanagementlebenszyklus, nicht erst nach der Technologieeinführung. In der Phase Risikomanagement, Schritt 9, „Identifizierung von Assets, Bedrohungen und Schwachstellen“, weist die Roadmap Teams an, Informations-Assets zu inventarisieren und Verantwortliche, Standort und Klassifizierung zu erfassen.
Dies verhindert ein häufiges Versäumnis: ein Cloud-Inventar zu haben, aber kein Informationsinventar. Eine Datenbank, ein SaaS-Mandant oder ein Data Warehouse ist ein Technologie-Asset. Die darin enthaltenen Kundendatensätze, Mitarbeiterakten, Zahlungsprotokolle, Trainingsdatenbestände für Modelle, Support-Transkripte und Vorfallsnachweise sind Informations-Assets. Klassifizierung findet auf dieser Informationsebene statt.
Die Anleitung des Zenith Blueprint zu ISO/IEC 27002:2022 Maßnahme 5.12, Klassifizierung von Informationen, erklärt das Prinzip:
Jede jemals formulierte Informationssicherheitskontrolle – Zugriffsbeschränkung, Verschlüsselung, Backup, Überwachung oder Entsorgung – setzt eines voraus: dass die Organisation weiß, was sie schützt. Maßnahme 5.12 verlangt, dass Informationen auf Grundlage ihres Werts, ihrer Sensibilität und ihrer Kritikalität klassifiziert werden; dies bildet die Grundlage für alle nachfolgenden Entscheidungen im ISMS.
Für ISO/IEC 27002:2022 Maßnahme 5.13, Kennzeichnung von Informationen, überführt dieselbe Roadmap Klassifizierung in tägliches Verhalten:
Kennzeichnung ist der Weg, abstrakte Richtlinien in operative Realität zu überführen. Es ist der Moment, in dem ein Benutzer beim Blick auf ein Dokument, eine E-Mail, ein Datenbankfeld oder einen gedruckten Bericht sofort erkennen kann: um welche Information es sich handelt, wie sensibel sie ist und wie sie zu behandeln ist.
Die letzte Roadmap-Verknüpfung erscheint in Schritt 13, „Planung der Risikobehandlung und Anwendbarkeitserklärung“. Der Zenith Blueprint beschreibt die SoA als Brücke zwischen Risiken, Behandlungen und Kontrollen. Hier wird Klassifizierung zu Nachvollziehbarkeit im Audit. Ein Risikoszenario wie „unbefugte Offenlegung von Kundenfinanzdaten aus gemeinsam genutztem Cloud-Speicher“ kann Klassifizierung, Kennzeichnung, Zugriffskontrolle, Verschlüsselung, Protokollierung, DLP, Cloud-Nutzung, Lieferantenanforderungen und Incident Response zugeordnet werden.
Die Kontrollbeziehungen, die Auditoren erwarten
In Clarysecs Zenith Controls: Leitfaden zur übergreifenden Einhaltung wird ISO/IEC 27002:2022 Maßnahme 5.12, Klassifizierung von Informationen, als präventive Kontrolle abgebildet, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Sie ist dem Cybersicherheitskonzept Identify, der operativen Fähigkeit Information Protection sowie den Sicherheitsdomänen Protection und Defense zugeordnet.
Für ISO/IEC 27002:2022 Maßnahme 5.13, Kennzeichnung von Informationen, ordnet Zenith Controls die Kontrolle als präventiv, auf Protect ausgerichtet und mit denselben Informationssicherheitseigenschaften sowie derselben operativen Fähigkeit Information Protection ein.
Die zentrale Erkenntnis lautet: Klassifizierung und Kennzeichnung stehen nicht isoliert. Sie machen angrenzende Kontrollen belastbar.
| ISO/IEC 27002:2022 Kontrollbereich | Warum er von Klassifizierung oder Kennzeichnung abhängt | Nachweise, die ein Auditor anfordern kann |
|---|---|---|
| 5.9 Inventar von Informationen und anderen zugehörigen Assets | Klassifizierungsmetadaten sollten ein Kernfeld im Asset-Inventar sein | Asset-Register mit Verantwortlichem, Standort, Lebenszyklusstatus und Klassifizierung |
| 5.12 Klassifizierung von Informationen | Definiert Sensibilität, Wert und Kritikalität | Genehmigtes Klassifizierungsschema, Kriterien, Beispiele und Überprüfungsaufzeichnungen |
| 5.13 Kennzeichnung von Informationen | Macht Klassifizierung sichtbar und durchsetzbar | Kennzeichnungskonfiguration, beispielhaft gekennzeichnete Dateien, E-Mail-Kennzeichnungen, SaaS-Tags und Benutzeranleitungen |
| 5.14 Informationsübertragung | Bestimmt, ob externe Weitergabe, Verschlüsselung oder Genehmigung erforderlich ist | Übertragungsregeln je Klassifizierung, genehmigte Kanäle und Ausnahmeaufzeichnungen |
| 5.15 Zugriffskontrolle | Zugriffsberechtigungen sollten Klassifizierungsgrenzen folgen | Rollenmatrix, Berechtigungsüberprüfung, Regeln für privilegierten Zugriff und Genehmigungshistorie |
| 5.25 Bewertung und Entscheidung zu Informationssicherheitsereignissen | Der Schweregrad eines Vorfalls hängt teilweise von der Sensibilität der betroffenen Daten ab | Kriterien für Sicherheitsvorfall-Triage anhand von Klassifizierung und Servicekritikalität |
| 5.34 Datenschutz und Schutz von PII | Kategorien personenbezogener Daten benötigen datenschutzspezifische Handhabung | PII-Register, Zuordnung der Rechtsgrundlagen, Aufbewahrungsregeln und Kontrollen für Auftragsverarbeiter |
| 8.15 Protokollierung | Zugriff auf streng vertrauliche Daten erfordert stärkere Nachvollziehbarkeit | Datenzugriffsprotokolle, Einstellungen zur Protokollaufbewahrung und Überprüfungsnachweise |
| 8.16 Überwachungstätigkeiten | Die Priorität der Überwachung ändert sich, wenn streng vertrauliche Daten berührt werden | SIEM-Anwendungsfälle, Alarmschwellen und Eskalationsaufzeichnungen |
Zenith Controls ordnet Maßnahme 5.12 GDPR Article 32 und Erwägungsgrund 83, NIS2 Article 21(2)(a) und 21(2)(f), ISO/IEC 27701 Annex B, NIST SP 800-53 MP-3 und PM-11, FIPS 199 und NIST SP 800-60 sowie COBIT 2019 DSS06.06 und APO13.01 zu. Maßnahme 5.13 wird GDPR Article 32, NIS2 Article 21(2)(a) und 21(2)(f), DORA Article 9(1) und 9(2), NIST SP 800-53 MP-3 und COBIT 2019 DSS06.06 zugeordnet.
Das bedeutet: Ein Nachweissatz kann mehrere Assurance-Fragen beantworten.
| Treiber der Einhaltung | Beitrag von Klassifizierung und Kennzeichnung | Praktischer Nachweis |
|---|---|---|
| GDPR Article 32 | Zeigt, welche personenbezogenen Daten Schutzmaßnahmen für Vertraulichkeit, Integrität, Verfügbarkeit und Resilienz benötigen | PII-Klassifizierung, Verschlüsselungsregeln, Zugriffsbeschränkungen, Zuordnung von Aufbewahrungsfristen und Kriterien für Vorfalls-Triage |
| NIS2 Article 21 | Unterstützt Risikoanalyse, Sicherheitsrichtlinien, Wirksamkeitsbewertung, Zugriffskontrolle, Asset-Management und verhältnismäßige Maßnahmen | Vom Management genehmigte Richtlinie, Asset-Inventar, Schulung, Überprüfungskennzahlen und getestete Handhabungsregeln |
| DORA-IKT-Risikomanagement | Unterstützt Identifizierung und Schutz von Informations- und IKT-Assets, Vorfallklassifizierung und IKT-Drittparteienrisiko | IKT-Asset-Register, Datenkritikalität, Anforderungen an Lieferantenverträge, Testumfang und Kriterien für den Vorfallschweregrad |
| NIST CSF 2.0 | Unterstützt Ergebnisse aus GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND und RECOVER | Current und Target Profiles mit Klassifizierungslücken und priorisierten Abhilfemaßnahmen |
| COBIT 2019 | Unterstützt Governance- und Prozesskontrollen für Sicherheit, Datenverarbeitung und Kontrollbetrieb | Kontrollziele, Prozessverantwortung, Assurance-Tests und Ausnahmemanagement |
Das Asset-Register ist der Ort, an dem Klassifizierung zum Nachweis wird
Viele Klassifizierungsprogramme scheitern, weil das Klassifizierungsschema nur in einer Richtlinie existiert. Clarysecs Ansatz beginnt mit dem Asset-Inventar.
Clarysecs P12 Richtlinie zum Asset-Management verlangt, dass das Asset-Inventar die Klassifizierungsstufe als Mindestfeld enthält:
Das Asset-Inventar muss mindestens Folgendes enthalten: 5.3.1 Asset-Kennung, Kategorie und Typ 5.3.2 Seriennummer oder eindeutige Kennzeichnung (für physische Vermögenswerte) 5.3.3 Softwareversion oder Lizenzschlüssel (für Software-Assets) 5.3.4 Asset-Verantwortlicher 5.3.5 Klassifizierungsstufe (Öffentlich, Intern, Vertraulich, Streng vertraulich) 5.3.6 Standort (physisch, virtuell, Cloud) 5.3.7 Lebenszyklusstatus (aktiv, in Wartung, außer Betrieb)
Dies ist direkt auf die Risikoplanung nach ISO/IEC 27001:2022 ausgerichtet. Wenn Sie Informations-Asset, Verantwortlichen, Standort und Klassifizierung nicht identifizieren können, können Sie Eintrittswahrscheinlichkeit, Auswirkung, Behandlungspriorität oder Restrisiko nicht konsistent beurteilen. Sie können auch nicht verlässlich entscheiden, ob eine Lieferantenbeziehung, ein Cloud-Service oder eine SaaS-Integration regulierte Informationen betrifft.
Für GDPR unterstützt dies die Rechenschaftspflicht. Aufzeichnungen zu Verarbeitungstätigkeiten nach Article 30 und Sicherheitsmaßnahmen nach Article 32 werden glaubwürdiger, wenn das Asset-Register ausweist, wo personenbezogene Daten verarbeitet werden und wie sie geschützt sind. Für DORA unterstützt dasselbe Register die Kritikalität von IKT-Assets und Services, den Umfang von Resilienztests und die Analyse von Abhängigkeiten von Drittparteien. Für NIS2 unterstützt es Risikoanalyse, Zugriffskontrolle und Asset-Management.
| Feld | Beispieleintrag |
|---|---|
| Asset-Name | Kundendatenbank für Abrechnung |
| Asset-Verantwortlicher | Leiter Plattform-Engineering |
| Geschäftsprozess | Abonnementabrechnung und Rechnungsstellung |
| Standort | EU-Cloud-Region, verwalteter Datenbankdienst |
| Klassifizierung | Streng vertraulich |
| Datenkategorien | Kundenkennungen, Abrechnungskontaktdaten, Transaktionsreferenzen |
| GDPR-Relevanz | Personenbezogene Daten, Kontexte als Verantwortlicher und Auftragsverarbeiter |
| Kritikalität | Unterstützt Umsatzprozesse und Kundenservice |
| Wesentliche Kontrollen | MFA, Verschlüsselung ruhender Daten, Verschlüsselung von Daten während der Übertragung, Genehmigung privilegierter Zugriffe, Audit-Protokollierung, Backup-Tests |
| Lieferantenabhängigkeit | Cloud-Datenbankanbieter, Zahlungsdienstleister |
| Überprüfungsrhythmus | Vierteljährliche Berechtigungsüberprüfung, jährliche Klassifizierungsüberprüfung, Überprüfung bei Systemänderung |
Diese Art von Aufzeichnung verändert den Ton eines Audits. Statt zu sagen: „Wir glauben, dass sensible Daten geschützt sind“, kann die Organisation zeigen, um welche Daten es sich handelt, wem sie gehören, warum sie als streng vertraulich eingestuft sind, welche Kontrollen gelten und wann diese Kontrollen zuletzt überprüft wurden.
Kennzeichnungen müssen Handhabungsregeln für Cloud und SaaS steuern
Die meisten sensiblen Daten bewegen sich heute durch Cloud-Plattformen, SaaS-Anwendungen, Analysepipelines und Kollaborationswerkzeuge. Eine Richtlinie, die Benutzer anweist, „vertrauliche Daten sorgfältig zu behandeln“, reicht nicht aus.
Clarysecs P27 Richtlinie zur Nutzung von Cloud-Diensten verknüpft Cloud-Nutzung unmittelbar mit Klassifizierung und Datenresidenz:
Datenklassifizierung und Datenresidenz 6.6.1 Daten dürfen nicht ohne Klassifizierung gemäß der Richtlinie zur Datenklassifizierung und Kennzeichnung (P13) auf eine Cloud-Plattform verschoben werden. 6.6.2 Anforderungen an die Datenresidenz müssen vertraglich durchgesetzt werden (z. B. ausschließlich EU-Speicherung für GDPR-regulierte Daten). 6.6.3 Grenzüberschreitende Datenübermittlungen müssen GDPR Chapter V und, soweit anwendbar, DORA Article 28 entsprechen.
Das ist wichtig, weil Cloud-Risiken häufig durch Bequemlichkeit entstehen. Ein Team exportiert einen Datenbestand in ein neues Analysewerkzeug. Der Vertrieb synchronisiert Kundenlisten mit einer Automatisierungsplattform. Ein Entwickler kopiert Produktivdaten in eine Testumgebung. Ohne Klassifizierung und Kennzeichnung lösen solche Handlungen möglicherweise keine rechtliche Prüfung, Sicherheitsfreigabe oder Lieferantenprüfung aus.
Die Richtlinie zur Datenklassifizierung und Kennzeichnung – KMU gibt kleineren Organisationen ein einfaches Umsetzungsmuster:
Gemeinsame Ordner oder Cloud-Laufwerke müssen Ordnernamen oder Tags verwenden, um die Klassifizierung anzugeben (z. B. „/Clients_Confidential“).
In reiferen Umgebungen sollten Ordnernamen durch maschinenlesbare Kennzeichnungen, Richtlinien für bedingten Zugriff, Sperren externer Freigaben, Verschlüsselung, Aufbewahrungskennzeichnungen, DLP-Regeln und Protokollierung ergänzt werden. Das Ziel besteht nicht nur darin, Informationen zu kennzeichnen. Das Ziel besteht darin, die Kennzeichnung handlungswirksam zu machen.
Eine Kennzeichnung „Streng vertraulich“ kann Sperren für externe Freigaben, Verschlüsselung ruhender Daten und von Daten während der Übertragung, MFA, Download-Beschränkungen auf nicht verwalteten Geräten, Audit-Log-Aufbewahrung, SIEM-Warnmeldungen, Aufbewahrungsregeln, Standortbeschränkungen für Lieferanten und Eskalation des Vorfallschweregrads auslösen.
Die P13 Richtlinie zur Datenklassifizierung und Kennzeichnung setzt die Baseline:
Sämtliche Datenhandhabung, Übertragung, Zugriffe, Speicherung und Entsorgung von Informationen müssen an ihrer Klassifizierungsstufe ausgerichtet sein. Mindestens gilt: 6.3.1.1 Öffentlich: Darf frei offengelegt werden; keine besondere Handhabung erforderlich 6.3.1.2 Intern: Wird innerhalb der Organisation geteilt; Speicherung in sicheren internen Systemen 6.3.1.3 Vertraulich: 6.3.1.3.1 Zugriff nur für autorisiertes Personal 6.3.1.3.2 Muss während der Übertragung und im Ruhezustand verschlüsselt werden 6.3.1.3.3 Darf extern nur unter einer NDA oder gleichwertigen vertraglichen Schutzmaßnahmen geteilt werden 6.3.1.4 Streng vertraulich: 6.3.1.4.1 Es gelten die höchsten Sicherheitsanforderungen 6.3.1.4.2 Starke Zugriffskontrollen, Multi-Faktor-Authentifizierung (MFA) und Audit-Protokollierung sind erforderlich 6.3.1.4.3 Physische und logische Trennung, soweit umsetzbar 6.3.1.4.4 Externe Weitergabe ist ohne CISO-Genehmigung untersagt
Jede Kennzeichnung hat ein Verhalten. Jedes Verhalten hat eine Kontrolle. Jede Kontrolle hat Nachweise.
Ein praktisches Beispiel für Durchsetzung
Betrachten wir einen Fintech-Analysten, der Q3_2026_Customer_Churn_Analysis.xlsx erstellt. Die Tabelle enthält Kundenkennungen, Transaktionsvolumina und prädiktive Churn-Bewertungen.
Der Analyst klassifiziert sie als Vertraulich, weil sie Kundendaten und strategische Analysen enthält. Mit dem Informationsschutzwerkzeug des Unternehmens wendet der Analyst die Kennzeichnung Vertraulich an. Da die Kennzeichnung dauerhaft, sichtbar und maschinenlesbar ist, werden Kontrollen automatisch aktiviert.
Die Datei wird auf dem Gerät und im Cloud-Speicher verschlüsselt gespeichert. Eine sichtbare Kopfzeile markiert sie als Vertraulich. Wenn der Analyst versucht, sie mit einem persönlichen Cloud-Laufwerk zu synchronisieren, blockiert eine DLP-Regel die Aktion und protokolliert den Versuch. Wenn der Analyst versucht, sie per E-Mail an eine externe Domain zu senden, die nicht zu einem Partner gehört, versetzt das E-Mail-Gateway die Nachricht in Quarantäne und alarmiert den Sicherheitsbetrieb. Wird die Datei später als streng vertraulich neu klassifiziert, weil sie regulierte Finanztransaktionsdaten enthält, wird externe Weitergabe deaktiviert, sofern nicht der CISO oder der Dateneigentümer die Ausnahme genehmigt.
Dies ist der Nachweis, den der CEO gefordert hat. Er ist nachvollziehbar, automatisiert und an eine vom Leitungsorgan genehmigte Richtlinie gebunden. Er ist außerdem an der P27 Richtlinie zur Nutzung von Cloud-Diensten ausgerichtet, weil keine Cloud-Verlagerung ohne Klassifizierung zulässig ist und grenzüberschreitende Übermittlungen GDPR Chapter V sowie, soweit anwendbar, DORA Article 28 erfüllen müssen.
Eine Klassifizierungs-Kontroll-Matrix in einer Woche aufbauen
Ein vollständiges Programm benötigt Zeit, aber ein fokussierter Sprint kann vor einem Audit, einer Kundenprüfung oder einer regulatorischen Bewertung das Nachweisgerüst schaffen.
Tag 1: Klassifizierungsschema bestätigen
Beginnen Sie mit vier Stufen: Öffentlich, Intern, Vertraulich und Streng vertraulich. Nutzen Sie die P13 Richtlinie zur Datenklassifizierung und Kennzeichnung als Baseline. Definieren Sie Kriterien anhand geschäftlicher Auswirkungen, rechtlicher Auswirkungen, vertraglicher Sensibilität, Risiken personenbezogener Daten, Servicekritikalität und finanziellem Schaden.
| Klassifizierung | Typische Beispiele | Risikologik |
|---|---|---|
| Öffentlich | Genehmigte Marketinginhalte, Pressemitteilungen, Stellenausschreibungen | Für uneingeschränkte Verteilung bestimmt |
| Intern | Interne Verfahren, Projektnotizen, interne Ankündigungen | Nicht öffentliche Geschäftsinformationen |
| Vertraulich | Kundenverträge, HR-Akten, nicht öffentliche Finanzberichterstattung | Sensible Geschäfts-, Vertrags- oder Kundendaten |
| Streng vertraulich | Besondere Kategorien personenbezogener Daten, Zahlungsdaten, Authentifizierungsgeheimnisse, Produktiv-Kundendatenbanken | Kritische oder regulierte Informationen mit erheblichen rechtlichen oder geschäftlichen Auswirkungen |
Tag 2: Zehn kritische Informations-Assets auswählen
Nutzen Sie Zenith Blueprint Schritt 9. Beziehen Sie eine Kundendatenbank, ein Support-Ticketsystem, eine HR-Plattform, einen Identitätsanbieter, einen Zahlungsexport, ein Data Warehouse, einen Objektspeicher-Bucket, einen Ordner für Berichte an das Leitungsorgan, ein Quellcode-Repository und ein Repository für Vorfallsnachweise ein. Erfassen Sie Verantwortlichen, Standort, Klassifizierung und GDPR-Relevanz.
Tag 3: Handhabungsregeln zuordnen
Definieren Sie Handhabungsanforderungen für Zugriff, Speicherung, Übertragung, Überwachung und Entsorgung.
| Klassifizierung | Zugriff | Speicherung | Übertragung | Überwachung | Entsorgung |
|---|---|---|---|---|---|
| Öffentlich | Offene oder genehmigte Veröffentlichungsrollen | Genehmigte öffentliche Kanäle | Nach Freigabe keine besondere Beschränkung | Grundlegende Integritätsüberwachung | Standardlöschung |
| Intern | Mitarbeiter und genehmigte Auftragnehmer | Verwaltete Systeme | Interne Kanäle | Standardmäßige Zugriffsprotokolle | Standard-Aufbewahrungsplan |
| Vertraulich | Need-to-know-Zugriff | Genehmigte sichere Repositories | Verschlüsselung und NDA oder vertragliche Schutzmaßnahmen | Berechtigungsüberprüfung und DLP-Warnmeldungen | Sichere Löschung |
| Streng vertraulich | Prinzip der minimalen Berechtigung mit MFA und Genehmigung des Verantwortlichen | Getrennte oder gehärtete Systeme | Externe Weitergabe untersagt, sofern nicht genehmigt | Erweiterte Audit-Protokollierung und SIEM-Alarmierung | Verifizierte sichere Vernichtung |
Tag 4: Einen technischen Durchsetzungspfad konfigurieren
Wählen Sie eine Plattform, etwa ein Cloud-Dokumentenrepository, ein E-Mail-System oder einen Objektspeicherdienst. Implementieren Sie sichtbare und maschinenlesbare Kennzeichnungen. Konfigurieren Sie eine Regel für vertrauliche Daten und eine Regel für streng vertrauliche Daten. Verlangen Sie beispielsweise Verschlüsselung für externe E-Mails mit vertraulichen Daten und blockieren Sie die externe Weitergabe streng vertraulicher Dateien.
Tag 5: Risikoregister und SoA aktualisieren
Nutzen Sie Zenith Blueprint Schritt 13. Ergänzen Sie die Anwendbarkeitserklärung um Kontrollen für Klassifizierung und Kennzeichnung. Verknüpfen Sie diese mit Risiken wie unbefugter Offenlegung, fehlerhafter Cloud-Konfiguration, übermäßiger Lieferantenexposition, Versagen der Datenaufbewahrung und Untererfassung von Vorfällen.
Tag 6: Kontrolle testen
Erstellen Sie eine Testdatei mit der Kennzeichnung Streng vertraulich. Versuchen Sie, sie von einem nicht verwalteten Gerät extern zu teilen. Bestätigen Sie, ob das Werkzeug blockiert, warnt, protokolliert oder eskaliert. Erfassen Sie Screenshots, Protokolleinträge und Ticket-Nachweise. Wenn die Kontrolle versagt, dokumentieren Sie die Ausnahme und den Abhilfeplan.
Tag 7: Benutzer der ersten Verteidigungslinie schulen
Schulungen sollten rollenspezifisch sein. Entwickler müssen wissen, wann Produktivdaten nicht in Testumgebungen verwendet werden dürfen. HR muss verstehen, warum Mitarbeiterakten vertraulich oder streng vertraulich sind. Der Vertrieb muss wissen, warum Kundenexporte nicht in nicht genehmigte SaaS-Werkzeuge hochgeladen werden dürfen. Führungskräfte müssen verstehen, warum Unterlagen für das Leitungsorgan, Akquisitionsdateien und Investorendaten eine strengere Handhabung erfordern.
Dieser Sprint schließt nicht das gesamte Programm ab, schafft aber das Nachweisgerüst: Richtlinie, Inventar, Kennzeichnungen, Handhabungsregeln, technische Durchsetzung, Risikonachvollziehbarkeit und Schulung.
Wie Auditoren Klassifizierung und Kennzeichnung prüfen
Auditoren prüfen Klassifizierung selten isoliert. Sie folgen den Daten.
Ein ISO/IEC 27001:2022-Auditor wird Klassifizierung mit ISMS-Geltungsbereich, Anforderungen interessierter Parteien, rechtlichen und vertraglichen Verpflichtungen, Risikobeurteilung und Anwendbarkeitserklärung verbinden. Erwartet werden Nachweise zu ISO/IEC 27002:2022 Maßnahmen 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 und relevanten technischen Kontrollen. Typische Nachweise umfassen genehmigte Richtlinien, Aufzeichnungen im Asset-Inventar, Einträge im Risikoregister, gekennzeichnete Muster, Handhabungsregeln, Berechtigungsüberprüfungen, Feststellungen aus internen Audits und Korrekturmaßnahmen.
Ein GDPR-Prüfer konzentriert sich auf personenbezogene Daten. Er wird fragen, ob personenbezogene Daten identifiziert sind, ob besondere Kategorien von Daten unterschieden werden, ob Aufbewahrungsregeln am Zweck ausgerichtet sind und ob Sicherheitsmaßnahmen nach Article 32 angemessen sind. Klassifizierung hilft, gewöhnliche Geschäftsinformationen von personenbezogenen Daten, sensiblen personenbezogenen Daten, vertraulichen Kundendaten und regulierten Aufzeichnungen zu trennen. Kennzeichnung hilft operativen Teams, versehentliche Offenlegung, überlange Aufbewahrung und unbefugte Übermittlung zu vermeiden.
Ein NIST CSF 2.0-Assessor wird Klassifizierung voraussichtlich unter GOVERN, IDENTIFY und PROTECT einordnen. Er kann fragen, ob Current und Target Profiles die Erkennung sensibler Daten definieren, ob Kennzeichnungsdurchsetzung über SaaS- und Cloud-Systeme hinweg funktioniert, ob Lieferanten Daten entsprechend der Klassifizierung behandeln und ob sich Überwachungsprioritäten anhand der Sensibilität anpassen.
Ein COBIT 2019- oder ISACA-orientierter Auditor wird Governance-Ziele, Prozessverantwortung, Kontrolldesign und operative Wirksamkeit betonen. Zenith Controls ordnet Inventarkontrolle 5.9 COBIT 2019 BAI09.01, BAI09.02 und DSS05.04 zu und verweist auf ISACA ITAF 2204 und 2301. Für Klassifizierung ordnet Zenith Controls Maßnahme 5.12 COBIT 2019 DSS06.06 und APO13.01 zu, während Kennzeichnung DSS06.06 zugeordnet wird. Der Auditor wird fragen, wem der Prozess gehört, wie Ausnahmen genehmigt werden, ob die Leistung überwacht wird und ob das Management Berichte erhält.
Ein DORA-fokussierter Prüfer wird fragen, welche Informations-Assets kritische oder wichtige Funktionen unterstützen, welche Daten streng vertraulich sind, welche IKT-Drittdienstleister diese Daten speichern oder übertragen, ob Verträge Standorte und Sicherheitsmaßnahmen definieren, ob Tests auf kritische Daten ausgerichtet sind und ob Vorfälle teilweise nach Datenverlust in Bezug auf Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit klassifiziert werden.
Wenn die Antworten aus einem einheitlichen, klassifizierungsgetriebenen Nachweismodell für Assets und Lieferanten stammen, werden Audits schneller, konsistenter und belastbarer.
Häufige Fehlermuster
Klassifizierungsfehler entstehen in der Regel, weil Organisationen Kennzeichnungen als Sensibilisierungsinstrumente statt als Kontrollsignale behandeln.
Erstens klassifizieren sie Dokumente, aber keine Datenbanken, Programmierschnittstellen, Protokolle, Backups, Exporte oder SaaS-Datensätze. Sensible Daten in einem Debug-Protokoll können ebenso schädlich sein wie sensible Daten in einer Tabellenkalkulation.
Zweitens kennzeichnen sie Informationen, verknüpfen Kennzeichnungen aber nicht mit Zugriffskontrolle. Eine Kennzeichnung als streng vertraulich bei offenem Zugriff belegt, dass die Organisation die Sensibilität kannte und die Handhabungsregel dennoch nicht durchgesetzt hat.
Drittens erfolgen Cloud-Migrationen vor der Klassifizierung. Teams verschieben Daten in neue SaaS-Werkzeuge, ohne Datenresidenz, Lieferantenbedingungen, Zugriff von Unterauftragsverarbeitern, Anforderungen an grenzüberschreitende Übermittlungen oder Löschrechte zu bestätigen. Die P27 Richtlinie zur Nutzung von Cloud-Diensten adressiert dies unmittelbar, indem sie das Verschieben auf Cloud-Plattformen ohne Klassifizierung untersagt.
Viertens ignorieren Reaktionspläne für Sicherheitsvorfälle die Klassifizierung. Wenn Schweregradkriterien die Datensensibilität nicht berücksichtigen, verlieren Incident-Teams in der Krise Zeit damit herauszufinden, was betroffen war. GDPR-Verstoßanalyse, NIS2-Vorfallsbehandlung und DORA-Vorfallklassifizierung profitieren alle von schnellem Datenkontext.
Fünftens erklärt die SoA nicht, warum Kontrollen für Klassifizierung und Kennzeichnung anwendbar sind. Die Organisation hat Kennzeichnungen möglicherweise implementiert, aber die SoA verknüpft sie nicht mit GDPR Article 32, NIS2 Article 21, DORA-IKT-Risiko, Kundenverträgen oder konkreten Risikoszenarien.
Managementberichterstattung: Klassifizierung sichtbar machen
NIS2 und DORA machen Cybersicherheit zu einer Frage der Rechenschaftspflicht des Managements. ISO/IEC 27001:2022 verlangt ebenfalls Führungsverpflichtung, Ausrichtung der Richtlinien, Ressourcen, Rollen und Leistungsberichterstattung. Klassifizierungskennzahlen sollten daher in die Managementbewertung einfließen.
Nützliche Kennzahlen sind:
- Anteil kritischer Informations-Assets mit zugewiesenen Verantwortlichen.
- Anteil der Assets mit genehmigter Klassifizierung.
- Anzahl streng vertraulicher Assets ohne erweiterte Protokollierung.
- Anzahl vertraulicher oder streng vertraulicher Repositories mit aktivierter externer Freigabe.
- Anteil der Lieferanten, die vertrauliche oder streng vertrauliche Daten verarbeiten, mit aktualisierten Vertragsklauseln.
- Anzahl von Klassifizierungsausnahmen und überfälligen Abhilfemaßnahmen.
- DLP-Vorfälle nach Kennzeichnung.
- Abschlussquote der Berechtigungsüberprüfung für streng vertrauliche Assets.
- Cloud-Speicherorte für GDPR-regulierte Daten.
- Incident-Response-Übungen, die klassifizierungsbasierte Schweregradkriterien verwendet haben.
Diese Kennzahlen unterstützen die ISO/IEC 27001:2022-Managementbewertung, die Managementaufsicht nach NIS2, die Governance-Berichterstattung nach DORA und Programme zur Vertrauensbildung bei Kunden. Sie machen Klassifizierung außerdem für Führungskräfte verständlich. Die Leitung kann schneller handeln, wenn sie erkennt, dass mehreren streng vertraulichen Repositories getestete Wiederherstellung fehlt oder dass kritische Lieferanten Kundendaten ohne bestätigte EU-Speicherung verarbeiten.
Von der Richtlinie zum Nachweis
Das Umsetzungsmuster von Clarysec ist nachweisorientiert:
- Definieren Sie das Klassifizierungsschema in der P13 Richtlinie zur Datenklassifizierung und Kennzeichnung oder beginnen Sie mit der Richtlinie zur Datenklassifizierung und Kennzeichnung – KMU.
- Ergänzen Sie das Asset-Inventar gemäß P12 Richtlinie zum Asset-Management um die Klassifizierung.
- Wenden Sie Cloud-Beschränkungen und Anforderungen an die Datenresidenz über die P27 Richtlinie zur Nutzung von Cloud-Diensten an.
- Nutzen Sie Zenith Blueprint Schritt 9, um Informations-Assets, Verantwortliche, Standorte und Sensibilität zu identifizieren.
- Nutzen Sie Zenith Blueprint Schritt 13, um Risiken in der SoA Kontrollen zuzuordnen.
- Nutzen Sie Zenith Blueprint Schritt 22, um ISO/IEC 27002:2022 Maßnahmen 5.12 und 5.13 im Tagesgeschäft umzusetzen.
- Nutzen Sie Zenith Controls, um dieselben Nachweise GDPR, NIS2, DORA, NIST CSF, COBIT 2019 und unterstützenden Standards zuzuordnen.
- Testen Sie Kennzeichnungsdurchsetzung, Zugriffsbeschränkungen, Protokollierung, DLP und Sicherheitsvorfall-Triage.
- Berichten Sie die Klassifizierungsleistung an das Management.
- Überprüfen Sie die Klassifizierung nach wesentlichen Änderungen an Systemen, Prozessen, Lieferanten oder regulatorischen Anforderungen.
Dies funktioniert, weil Klassifizierung zur gemeinsamen Sprache zwischen Geschäftswert, rechtlicher Verpflichtung, technischer Kontrolle und Auditnachweis wird.
Wenn Ihre Organisation sich auf eine ISO/IEC 27001:2022-Zertifizierung, GDPR-Assurance, NIS2-Readiness, DORA-Kunden-Due-Diligence oder ein kombiniertes Compliance-Audit vorbereitet, beginnen Sie mit einer Frage:
Können Sie für jedes kritische Informations-Asset zeigen, was es ist, wem es gehört, wo es sich befindet, wie es klassifiziert ist, wie es gekennzeichnet ist, wer darauf zugreifen kann, wie es geschützt ist, wie lange es aufbewahrt wird, welcher Lieferant es berührt und was geschieht, wenn es offengelegt wird?
Wenn die Antwort noch nicht „Ja“ lautet, kann Clarysec Ihnen helfen, die Nachweiskette schnell und belastbar aufzubauen.
Nutzen Sie die Richtlinie zur Datenklassifizierung und Kennzeichnung – KMU, P13 Richtlinie zur Datenklassifizierung und Kennzeichnung, P12 Richtlinie zum Asset-Management, P27 Richtlinie zur Nutzung von Cloud-Diensten, Zenith Blueprint: 30-Schritte-Roadmap für Auditoren und Zenith Controls: Leitfaden zur übergreifenden Einhaltung, um Klassifizierung von einer statischen Richtlinie in eine operative Kontrollschicht für GDPR Article 32, NIS2-Cyberrisikomanagement und DORA-IKT-Risikonachweise zu überführen.
Der beste Zeitpunkt zur Klassifizierung von Daten war, bevor die Audit-Anfrage einging. Der nächstbeste Zeitpunkt ist vor der nächsten Cloud-Migration, dem nächsten Lieferanten-Onboarding, dem nächsten Kundenfragebogen oder dem nächsten Vorfall.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
