Governance für biometrische Daten nach GDPR und ISO 27701

Die Einladung zur Krisensitzung landete mit Nachdruck im Posteingang von CISO Maria Petrova. Die Betreffzeile lautete: „DRINGEND: Biometrische Authentifizierung – Go/No-Go für Q3-Launch.“
Maria wusste, worum es ging. Ihr Unternehmen, ein schnell wachsendes FinTech namens Finura, bereitete die Einführung einer In-App-Zahlungsverifikation mittels Gesichts- und Fingerabdruckerkennung vor. Das Produktmanagement sah ein marktprägendes Feature. Die Geschäftsleitung sah schnellere Akzeptanz. Die Betrugspräventionsteams sahen weniger Fake Accounts. Der COO sah weniger Reibung. Maria sah ein anderes Bild: besondere Kategorien personenbezogener Daten, DSFA-Auslöser, Lieferantenabhängigkeit, Aufbewahrungsrisiken, Widerruf von Einwilligungen, operationale Resilienz und ein Vorfallsszenario, das sich nicht durch die Ausgabe eines neuen Passworts lösen ließ.
Im Call entstand sofort Druck. „Der Wettbewerb liegt Monate hinter uns“, argumentierte der Head of Product. „Wir können uns keine Verzögerung leisten.“
Dann begannen die Fragen.
War die ausdrückliche Einwilligung ausgestaltet und dokumentiert worden? Gab es eine gültige Rechtsgrundlage nach GDPR Article 6 und eine Bedingung nach Article 9? War der Biometrieanbieter als IKT-Drittpartei anhand der DORA-Erwartungen geprüft worden? Hatte jemand vor Beginn der Entwicklung eine Datenschutz-Folgenabschätzung (DSFA) abgeschlossen? Konnte Finura nachweisen, dass ein widerrufenes Gesichtstemplate aus Produktivsystemen, Backups und Anbieterumgebungen gelöscht würde?
Das Schweigen sagte alles.
Governance für biometrische Daten ist anders, weil die Kennung die Person selbst ist. Ein Passwort kann rotiert werden. Eine Karte kann ersetzt werden. Ein kompromittiertes Gesichtstemplate, Fingerabdruckmuster, Stimmprofil, Handvenentemplate oder aus der Iris abgeleitete Kennung kann nicht sinnvoll geändert werden. Wenn biometrische Daten zur eindeutigen Identifizierung verwendet werden, behandelt GDPR sie als besondere Kategorien personenbezogener Daten. ISO/IEC 27701:2025 erwartet ein Datenschutz-Informationsmanagementsystem (PIMS), das nachweisen kann, warum die Verarbeitung erforderlich ist, wie sie kontrolliert wird, wer sie genehmigt hat, wie lange sie aufbewahrt wird, welche Lieferanten darauf zugreifen und wie Betroffenenanfragen und Vorfälle bearbeitet werden.
Das Problem besteht darin, dass viele Organisationen ein biometrisches Identitätsprodukt beschaffen, einen Sicherheitsfragebogen ausfüllen, einen generischen Datenschutzhinweis ergänzen und annehmen, Verschlüsselung löse das Thema. Das tut sie nicht. Verschlüsselung ist erforderlich, aber biometrische Governance benötigt ein verknüpftes Betriebsmodell.
Der Ansatz von Clarysec kombiniert ISO/IEC 27701:2025 PIMS-Governance, ISO/IEC 27001:2022-Kontrollnachweise, GDPR-Rechenschaftspflicht und Cross-Framework-Mapping über Zenith Controls: Der Cross-Compliance-Leitfaden Zenith Controls. In Zenith Controls ist der Cluster für biometrische Governance um ISO/IEC 27002:2022-Maßnahme 5.34, Datenschutz und Schutz personenbezogener Daten, verankert. Unterstützt wird er durch 5.17, Authentifizierungsinformationen, 8.5, Sichere Authentifizierung, 8.10, Informationslöschung, 8.24, Einsatz von Kryptografie, sowie Lieferantenmaßnahmen wie 5.20, Behandlung von Informationssicherheit in Lieferantenvereinbarungen.
Ziel ist nicht, Innovation zu verlangsamen. Ziel ist, biometrische Authentifizierung, Identitätsprüfung, Zutritt am Arbeitsplatz und Betrugsprävention nachvollziehbar, verhältnismäßig, sicher und auditfähig zu machen.
Warum biometrische Governance in reifen Unternehmen scheitert
Ein Unternehmen kann ein starkes Sicherheitsprogramm haben und dennoch eine schwache biometrische Governance aufweisen.
Betrachten wir einen SaaS-Anbieter, der Gesichtsverifikation für das Kunden-Onboarding einführt. Das Sicherheitsteam fordert TLS, verschlüsselte Speicherung, Administrator-MFA, Zugriffskontrollen und Protokollierung. Der Anbieter erklärt, biometrische Templates seien „irreversibel“. Das Produktmanagement dokumentiert Betrugsreduktion als geschäftliche Begründung. Legal prüft den Auftragsverarbeitungsvertrag. Der Einkauf gibt den Lieferanten frei.
Dann stellt der Auditor fünf Fragen:
- Wo ist die biometrische Verarbeitungstätigkeit aufgezeichnet?
- Was ist die Rechtsgrundlage nach GDPR Article 6 und, soweit anwendbar, die Bedingung für besondere Kategorien nach Article 9?
- Wurde eine DSFA abgeschlossen, bevor die Verarbeitung begann?
- Können Sie nachweisen, dass biometrische Templates gelöscht werden, wenn der Zweck entfällt?
- Was geschieht, wenn der Biometrieanbieter eine Datenschutzverletzung erleidet oder Unterauftragsverarbeiter ändert?
Wenn die Antworten über E-Mail-Verläufe, Beschaffungstickets, Produktnotizen und ein Lieferantenportal verstreut sind, ist das Programm nicht auditfähig.
GDPR Article 5 fordert Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht. Article 6 verlangt eine Rechtsgrundlage. Article 9 ergänzt eine strengere Bedingung, wenn biometrische Daten zum Zweck der eindeutigen Identifizierung einer Person verarbeitet werden. Die Definitionen in Article 4 sind wichtig, weil Verarbeitung Erhebung, Speicherung, Nutzung, Offenlegung, Löschung und Vernichtung umfasst. Pseudonymisierung hilft nur, wenn zusätzliche identifizierende Informationen getrennt und durch angemessene technische und organisatorische Maßnahmen geschützt werden.
Für Nicht-EU-Unternehmen kann GDPR dennoch gelten, wenn sie Personen in der EU Waren oder Dienstleistungen anbieten oder Verhalten in der EU beobachten. Dadurch werden biometrisches Onboarding, Betrugsbewertung, Remote-Zugriff für Beschäftigte, Sprachverifikation im Callcenter und Identitätsprüfung von Kunden weit über Europa hinaus relevant.
Das Governance-Versagen ist selten eine einzelne fehlende Kontrolle. Es ist meist das Fehlen einer verknüpften Nachweiskette.
Die Clarysec-Nachweiskette für biometrische PIMS
Clarysec behandelt biometrische Anwendungsfälle als lebenszyklusgesteuerte Verarbeitung personenbezogener Daten, nicht als isolierte Authentifizierungsfunktionen. Die Nachweiskette beginnt, bevor das System gekauft, konfiguriert oder bereitgestellt wird.
In Zenith Blueprint: 30-Schritte-Fahrplan für Auditoren Zenith Blueprint beschreibt die Phase „Controls in Action“, Schritt 23, ISO/IEC 27002:2022-Maßnahme 5.34 wie folgt:
Namen, Anschriften, IDs, Gesundheitsdaten, Finanzdaten – diese Daten erzählen eine Geschichte über reale Menschen. Werden sie falsch behandelt, gestohlen oder missbraucht, gehen die Folgen weit über Compliance-Verstöße hinaus. Es wird zu einer Frage persönlicher Verletzung, von Reputationsschaden und rechtlicher Exponierung.
Für biometrische Kennungen wird diese Aussage noch schärfer. Ein biometrisches Template ist nicht nur ein Anmeldedatum. Es ist mit physischen oder verhaltensbezogenen Merkmalen einer Person verknüpft und kann zur eindeutigen Identifizierung dieser Person verwendet werden.
Ein belastbarer Workflow für biometrische Governance verknüpft sieben Entscheidungen mit sieben Nachweisarten:
| Entscheidungspunkt | Erforderliche Nachweise | Clarysec-Toolkit-Anker |
|---|---|---|
| Zweck und Erforderlichkeit | Geschäftszweck, geprüfte Alternativen, Entscheidung zur Verhältnismäßigkeit | Richtlinie zum Verarbeitungsinventar personenbezogener Daten und zur Rechtsgrundlage, REG02 |
| Rechtsgrundlage und Bedingung für besondere Kategorien | Grundlage nach GDPR Article 6 und Bedingung nach Article 9, soweit anwendbar | Richtlinie zu Datenschutz und Privatsphäre, REG02 |
| DSFA-Auslöser und Ergebnis | DSFA-Screening, Risikobeurteilung, Genehmigung des Restrisikos | Richtlinie zur Datenschutz-Risikobeurteilung und DSFA, REG04 |
| Sicherheitsarchitektur | Verschlüsselung, Zugriffskontrolle, Authentifizierung, Protokollierung, Segmentierung | Richtlinie zur Sicherheit und Zugriffskontrolle personenbezogener Daten, REG12 |
| Transparenz und Einwilligung, soweit relevant | Datenschutzhinweis, Nachweis ausdrücklicher Einwilligung, soweit erforderlich, Widerrufsbearbeitung | Richtlinie zu Einwilligungs- und Präferenzmanagement, REG05 |
| Lieferanten-Governance | Rolle als Auftragsverarbeiter, Vertragsbedingungen, Prüfung von Unterauftragsverarbeitern, jährliche Neubewertung | Richtlinie zum Datenschutzmanagement für Auftragsverarbeiter, Unterauftragsverarbeiter und Drittparteien, Lieferantenregister |
| Aufbewahrung und Löschung | Datenaufbewahrungsplan, Löschprotokolle, Umgang mit Backups, Löschungsnachweise | Richtlinie zu Datenschutz und Privatsphäre, Löschregister |
Das ist der Unterschied zwischen „wir nutzen Biometrie sicher“ und „wir können Governance für biometrische Daten nach GDPR und ISO/IEC 27701:2025 nachweisen“.
Die Rechtsgrundlage ist keine Checkbox
Biometrische Projekte scheitern häufig bereits bei der Rechtsgrundlage, weil Teams Sicherheitsnutzen mit rechtlicher Erlaubnis verwechseln.
GDPR Article 6 verlangt eine Rechtsgrundlage, etwa Einwilligung, Vertragserforderlichkeit, rechtliche Verpflichtung, lebenswichtige Interessen, Wahrnehmung einer Aufgabe im öffentlichen Interesse oder berechtigte Interessen, soweit anwendbar. Article 9 untersagt die Verarbeitung biometrischer Daten zur eindeutigen Identifizierung grundsätzlich, sofern keine spezifische Ausnahme greift, etwa ausdrückliche Einwilligung, arbeits- und sozialschutzrechtliche Pflichten auf gesetzlicher Grundlage, lebenswichtige Interessen, erhebliches öffentliches Interesse, Gesundheitsversorgung, öffentliche Gesundheit, Rechtsansprüche oder Forschung und Archivierung mit Schutzmaßnahmen.
Eine biometrische Zeiterfassung für Beschäftigte, Fingerabdruck-Zutritt, Gesichts-Onboarding und Sprachauthentifizierung können jeweils unterschiedliche Analysen erfordern. Dieselbe Technologie kann je nach Zweck, Wahlmöglichkeit der Nutzer, Machtungleichgewicht, lokalem Recht, Verhältnismäßigkeit und Verfügbarkeit nicht-biometrischer Alternativen zu unterschiedlichen Ergebnissen bei der Rechtsgrundlage führen.
Clarysecs Enterprise-Richtlinie zu Datenschutz und Privatsphäre Richtlinie zu Datenschutz und Privatsphäre macht die Grundlage klar:
Jede Verarbeitung muss auf einer gültigen Rechtsgrundlage beruhen (z. B. Einwilligung, Vertrag, rechtliche Verpflichtung).
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1.
Für besondere Kategorien von Daten verschärft Clarysecs Richtlinie zum Verarbeitungsinventar personenbezogener Daten und zur Rechtsgrundlage Richtlinie zum Verarbeitungsinventar personenbezogener Daten und zur Rechtsgrundlage die Nachweisanforderung:
[Bedingt] Der Prozessverantwortliche / Geschäftsinhaber MUSS die Bedingung für die Verarbeitung besonderer Kategorien in REG02 erfassen, bevor besondere Kategorien personenbezogener Daten verarbeitet werden.
Aus Abschnitt „Aufzeichnungen zu Zweck und Rechtsgrundlage des Verantwortlichen“, Richtlinienklausel 4.2.6.
Für KMU wendet Clarysec dieselbe Disziplin in einem einfacheren Betriebsmodell an. Die KMU-Richtlinie zu Datenschutz und Privatsphäre Richtlinie zu Datenschutz und Privatsphäre - KMU legt fest:
Der Datenschutzkoordinator muss ein Register sämtlicher Verarbeitungstätigkeiten für personenbezogene Daten führen, einschließlich Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrungsfristen.
Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.1.
Und sie ergänzt:
Die Rechtsgrundlage (z. B. Einwilligung, Vertrag, rechtliche Verpflichtung) muss im Verzeichnis der Verarbeitungstätigkeiten dokumentiert werden.
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.2.
Für die Governance biometrischer Daten ist das Verzeichnis der Verarbeitungstätigkeiten keine administrative Nebentätigkeit. Es ist der Kontrollpunkt, an dem die Organisation nachweist, dass der biometrische Anwendungsfall bekannt, klassifiziert, begründet und begrenzt ist.
Erst DSFA, dann Rollout
Wenn es eine operative Regel für biometrische Systeme gibt, dann diese: Die Beschaffung darf die DSFA nicht überholen.
Biometrische Technologien umfassen häufig besondere Kategorien personenbezogener Daten, eindeutige Identifizierung, systematische Überwachung, Betrugsprofiling, vulnerable betroffene Personen, Machtungleichgewichte am Arbeitsplatz, innovative Technologie oder automatisierte Entscheidungsunterstützung. Das sind klassische DSFA-Auslöser. Die DSFA ist nicht nur ein Datenschutzformular. In ihr prüft die Organisation Erforderlichkeit, Verhältnismäßigkeit, Alternativen, Restrisiko, Schutzmaßnahmen, Transparenz, Aufbewahrung, Lieferantenabhängigkeit und Vorfallauswirkungen.
Die Enterprise-Richtlinie zu Datenschutz und Privatsphäre verlangt formale Analysen für Hochrisikosysteme:
Bedrohungsmodellierung und Datenschutz-Folgenabschätzungen (DSFA) sind für Verarbeitungssysteme mit hohem Risiko verpflichtend.
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.4.
Die PIMS-spezifische Richtlinie zur Datenschutz-Risikobeurteilung und DSFA Richtlinie zur Datenschutz-Risikobeurteilung und DSFA ist direkter:
[Verantwortlicher] Der Prozessverantwortliche / Geschäftsinhaber MUSS Verarbeitungsvorgänge, die umfangreiche Verarbeitung, systematische Überwachung, Profiling, automatisierte Entscheidungen, besondere Kategorien personenbezogener Daten, Daten zu strafrechtlichen Verurteilungen oder Straftaten, vulnerable betroffene Personen, innovative Technologie oder wesentlich geänderte Verarbeitung umfassen, vor Beginn der Verarbeitung in REG04 an den Privacy Lead / PIMS-Manager verweisen.
Aus Abschnitt „DSFA-Auslöser und Erforderlichkeitsbestimmung“, Richtlinienklausel 4.2.2.
Eine biometrische DSFA sollte mindestens diese Fragen beantworten:
- Welche biometrische Modalität wird verarbeitet, etwa Gesicht, Fingerabdruck, Stimme, Iris, Handfläche oder Verhaltensmuster?
- Werden biometrische Daten zur eindeutigen Identifizierung oder nur zur lokalen Geräteverifikation verwendet?
- Ist die Organisation Verantwortlicher, Auftragsverarbeiter, gemeinsam Verantwortlicher oder Unterauftragsverarbeiter?
- Welche nicht-biometrische Alternative besteht, und ist sie gleichwertig verfügbar?
- Ist ausdrückliche Einwilligung erforderlich, und kann sie freiwillig erteilt und widerrufen werden?
- Werden biometrische Rohbilder, Audiodaten oder Templates gespeichert?
- Wo werden Templates gespeichert, etwa in einer sicheren Enklave des Geräts, in einem zentralen System oder in der Anbieter-Cloud?
- Wer kann auf Templates, Matching-Scores und biometrische Protokolle zugreifen?
- Welche Aufbewahrung gilt für registrierte Nutzer, abgelehnte Antragsteller, inaktive Konten und ausgeschiedene Beschäftigte?
- Wie werden Löschung und Ablauf von Backups nachgewiesen?
- Was geschieht nach False Positives, False Rejects oder Fehlern automatisierter Entscheidungen?
- Welche Unterauftragsverarbeiter sind beteiligt, und wo werden Daten verarbeitet?
Bei Finura wurde die DSFA zum zentralen Governance-Dokument. Sie stoppte den Launch nicht. Sie verwandelte eine riskante Idee in einen kontrollierten Implementierungsplan.
Ausdrückliche Einwilligung und das Problem erzwungener Bequemlichkeit
Biometrische Programme stützen sich häufig auf Einwilligung, weil dies intuitiv wirkt. Eine Person registriert Gesicht, Stimme oder Fingerabdruck – also muss sie doch zugestimmt haben. Einwilligung nach GDPR muss spezifisch, informiert, eindeutig und freiwillig sein. Wenn ausdrückliche Einwilligung nach Article 9 erforderlich ist, ist der Maßstab höher.
Im Beschäftigungskontext oder wenn der Zugang zu einem notwendigen Dienst von biometrischer Registrierung abhängt, ist Einwilligung schwer zu verteidigen, sofern keine echte Alternative besteht. Eine „bequeme“ biometrische Option wird problematisch, wenn die Alternative versteckt, langsamer, nachteilig oder nicht verfügbar ist.
Clarysecs Richtlinie zu Einwilligungs- und Präferenzmanagement Richtlinie zu Einwilligungs- und Präferenzmanagement liefert die operative Regel:
[Bedingt] Der Privacy Lead / PIMS-Manager MUSS die Einwilligung in REG05 als ausdrücklich kennzeichnen, bevor die Verarbeitung beginnt, wenn für den ausgewählten Zweck ausdrückliche Einwilligung erforderlich ist.
Aus Abschnitt „Einwilligungsanfrage und Erfassung“, Richtlinienklausel 4.2.5.
Für biometrische Systeme sollte REG05 Folgendes ausweisen:
- Den genauen Einwilligungstext.
- Den biometrischen Zweck, etwa Authentifizierung, Betrugsprävention, Zugriffskontrolle oder Identitätsprüfung.
- Ob die Einwilligung ausdrücklich ist.
- Datum, Kanal und Version des Datenschutzhinweises.
- Die Widerrufsmethode.
- Die nicht-biometrische Alternative.
- Ob eine Verweigerung den Zugang zu einem Dienst beeinflusst.
- Den Systemauslöser, der die Verarbeitung nach Widerruf beendet.
Die KMU-Richtlinie zu Datenschutz und Privatsphäre legt fest:
Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen muss in allen neuen Systemen und Services durchgesetzt werden.
Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.1.
In biometrischen Systemen bedeutet Datenschutz durch datenschutzfreundliche Voreinstellungen, dass Nutzer nicht stillschweigend registriert werden, Rohbilder nicht ohne Begründung aufbewahrt werden, biometrisches Matching nicht ohne Neubewertung für Analysen zweckentfremdet wird und Alternativen nicht hinter Support-Tickets verborgen sind.
Den vollständigen biometrischen Datenbestand klassifizieren
Ein biometrisches System kann nicht gesteuert werden, wenn die biometrischen Daten im Asset-Inventar unsichtbar sind.
Clarysecs Enterprise-Richtlinie zur Datenklassifizierung und Kennzeichnung Richtlinie zur Datenklassifizierung und Kennzeichnung legt fest:
Stellt sicher, dass personenbezogene Daten, die GDPR, DORA oder anderen Datenschutzgesetzen unterliegen, korrekt klassifiziert werden (z. B. als „Vertraulich“ oder „Streng vertraulich“ gekennzeichnet).
Aus Abschnitt „Rollen und Verantwortlichkeiten“, Richtlinienklausel 4.6.1.
Für KMU legt die Richtlinie zur Datenklassifizierung und Kennzeichnung - KMU Richtlinie zur Datenklassifizierung und Kennzeichnung - KMU die Schutzerwartung fest:
Alle als „Vertraulich“ klassifizierten Daten müssen das höchste Schutzniveau erhalten:
Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.
Die Klassifizierung sollte mehr als nur die Template-Datenbank umfassen:
| Datenobjekt | Warum es relevant ist | Typische Klassifizierungsbehandlung |
|---|---|---|
| Rohbild oder Audiodaten aus der Erfassung | Können biometrische Merkmale und zusätzliche personenbezogene Daten offenlegen | Streng vertraulich oder höchste Sensitivität |
| Biometrisches Template | Wird zur eindeutigen Identifizierung oder Verifikation verwendet | Streng vertraulich oder höchste Sensitivität |
| Matching-Score | Kann Zugriff, Onboarding oder Betrugsergebnisse beeinflussen | Vertraulich oder Streng vertraulich |
| Registrierungsmetadaten | Verknüpfen Person, Gerät, Zeit, Ort und Methode | Vertraulich |
| Protokolle fehlgeschlagener Matches | Können Verhaltensmuster oder False-Rejection-Ereignisse offenlegen | Vertraulich |
| Support-Exporte des Anbieters | Werden bei der Fehlerbehebung häufig übersehen | Streng vertraulich, wenn biometrisch oder identitätsbezogen |
| Backup-Kopien und Snapshots | Risiko für Aufbewahrung und Löschung | Wie Quelldaten |
ISO/IEC 27001:2022 verstärkt diese Disziplin. Die Abschnitte 4.1 bis 4.4 verlangen, dass die Organisation Kontext, Anforderungen interessierter Parteien, ISMS-Geltungsbereich und Abhängigkeiten bestimmt. Die Abschnitte 6.1.1 bis 6.1.3 verlangen Risikobeurteilung, Risikobehandlung, Anwendbarkeitserklärung und Genehmigung durch Risikoverantwortliche. Wenn biometrische Systeme Vertraulichkeit, Integrität, Verfügbarkeit oder Datenschutz beeinflussen, gehören sie in den Geltungsbereich.
Sicherheitskontrollen: Verschlüsselung ist nur eine Ebene
Biometrische Sicherheit erfordert mehrschichtige Kontrollen. Verschlüsselung ist wichtig, kann aber eine schwache Rechtsgrundlage, übermäßige Aufbewahrung, unkontrollierten Lieferantenzugriff oder fehlende Löschungsnachweise nicht kompensieren.
Die Zenith Blueprint-Phase „Controls in Action“, Schritt 20, erläutert ISO/IEC 27002:2022-Maßnahme 8.24, Einsatz von Kryptografie:
Bei dieser Maßnahme geht es nicht darum, einfach „Verschlüsselung einzuschalten“; es geht darum, Kryptografie in Design, Richtlinien und Lebenszyklusmanagement der Organisation einzubetten.
Clarysecs Richtlinie zur Sicherheit und Zugriffskontrolle personenbezogener Daten Richtlinie zur Sicherheit und Zugriffskontrolle personenbezogener Daten legt die PIMS-Regel für sensitive personenbezogene Daten fest:
[Beide] Der Leiter der Informationssicherheit MUSS Verschlüsselung oder genehmigte kompensierende Schutzanforderungen in REG12 definieren, bevor personenbezogene Daten mit hoher Tragweite, sensitive oder extern übermittelte personenbezogene Daten gespeichert, übertragen oder zugänglich gemacht werden.
Aus Abschnitt „Verschlüsselung und sichere Speicherung“, Richtlinienklausel 4.5.1.
REG12 sollte biometrische Schutzmaßnahmen definieren, etwa Verschlüsselung ruhender Daten, Verschlüsselung von Daten während der Übertragung, Schlüsselverantwortung, Schlüsselrotation, administrative MFA, Zugriffsgenehmigung, Trennung zwischen Identitätsdaten und biometrischen Templates, Protokollierung von Registrierung, Match-, Export- und Löschereignissen, Überwachung ungewöhnlicher Template-Zugriffe, sichere Löschung und Vorfallauslöser bei Template-Kompromittierung.
In Zenith Controls sind ISO/IEC 27002:2022-Maßnahme 5.17, Authentifizierungsinformationen, und 8.5, Sichere Authentifizierung, besonders wichtig, weil Biometrie häufig in Authentifizierungsabläufe eingebettet ist. Die Frage ist nicht nur, ob die biometrische Anmeldung sicher ist. Entscheidend ist auch, ob Fallback-Methoden, Wiederherstellungsabläufe, Liveness-Erkennung, privilegierter Zugriff und biometrische Umgehungspfade kontrolliert sind.
Aufbewahrung, Löschung und der biometrische Datenfriedhof
Biometrische Systeme bewahren häufig mehr Daten auf, als Teams erkennen: fehlgeschlagene Registrierungen, alte Templates, inaktive Nutzer, Support-Bundles, archivierte Datenbanken, Snapshots und Backups. Dadurch entsteht das Problem des biometrischen Datenfriedhofs. Die Daten sind operativ nicht mehr nützlich, bleiben aber hochsensitiv.
Die Enterprise-Richtlinie zu Datenschutz und Privatsphäre legt fest:
Personenbezogene Daten dürfen nicht länger als erforderlich aufbewahrt werden.
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.5.1.
Die Zenith Blueprint-Phase „Controls in Action“, Schritt 19, erläutert ISO/IEC 27002:2022-Maßnahme 8.10, Informationslöschung:
Diese Maßnahme stellt sicher, dass Daten nicht länger als erforderlich aufbewahrt werden und, wenn sie nicht mehr benötigt werden, sicher und zuverlässig gelöscht werden müssen.
Für biometrische Daten muss Löschung in das Systemdesign eingebaut werden. Regeln sollten Widerruf der Einwilligung, Kontoschließung, Austritt von Beschäftigten, fehlgeschlagenes Onboarding nach Ablauf von Einspruchsfristen, inaktive Konten, Geräteersatz, Beendigung von Lieferantenverträgen, Legal Holds, Ablauf von Backups und, soweit angemessen, kryptografische Löschung abdecken.
Auditoren werden „der Anbieter übernimmt die Löschung“ nicht akzeptieren, sofern Sie nicht nachweisen können, wie, wann, unter welchem Auslöser und mit welchem Nachweis dies erfolgt.
Lieferanten-Governance: Der Anbieter ist Teil des Kontrollumfelds
Die meisten Organisationen bauen biometrische Engines nicht selbst. Sie verlassen sich auf Anbieter für Face Matching, Sprachverifikation, Liveness-Erkennung, Zutrittskontrollhardware, SDKs, Betrugsbewertung, Cloud-Speicher oder Support-Analysen. Damit wird Lieferanten-Governance zentral.
Die Enterprise-Richtlinie zu Datenschutz und Privatsphäre verlangt die Neubewertung von Lieferanten:
Beschaffung sowie Recht und Compliance müssen die Einhaltung von Article 28 GDPR überprüfen und eine jährliche Neubewertung aller Lieferanten mit hohem Risiko verlangen.
Aus Abschnitt „Durchsetzung und Einhaltung“, Richtlinienklausel 8.5.2.
Die Richtlinie zum Datenschutzmanagement für Auftragsverarbeiter, Unterauftragsverarbeiter und Drittparteien Richtlinie zum Datenschutzmanagement für Auftragsverarbeiter, Unterauftragsverarbeiter und Drittparteien ergänzt ein PIMS-Genehmigungsgate:
[Bedingt] Der Datenschutzbeauftragte / Datenschutzberater MUSS vor Genehmigung einer Beziehung mit hohem Datenschutz-Restrisiko, besonderen Kategorien personenbezogener Daten, umfangreicher Verarbeitung, systematischer Überwachung oder ungeklärter Rollenklassifizierung in REG04 oder REG12 beraten.
Aus Abschnitt „Gebotene Sorgfalt und Risikobeurteilung“, Richtlinienklausel 4.2.4.
Die KMU-Richtlinie zur Lieferanten- und Drittparteiensicherheit Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU erinnert kleinere Unternehmen daran, dass Verträge eine Kontrollfläche sind:
Verträge müssen verbindliche Klauseln enthalten zu:
Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.
Die Zenith Blueprint-Phase „Controls in Action“, Schritt 23, beschreibt ISO/IEC 27002:2022-Maßnahme 5.20, Behandlung von Informationssicherheit in Lieferantenvereinbarungen:
Vertrauen darf bei Lieferanten nicht auf Annahmen beruhen. Es muss vertraglich festgeschrieben sein.
Biometrische Verträge sollten die Rolle als Auftragsverarbeiter, Zweckbindung, Genehmigung von Unterauftragsverarbeitern, Datenstandort, Verschlüsselung, Zugriffskontrollen, Vorfallmeldung, Auditrechte, Löschung, Rückgabe von Daten, Support-Zugriff, Unterstützung bei Datenschutzverletzungen, Beschränkungen für Modelltraining und Exit-Unterstützung abdecken.
Für von DORA erfasste Finanzunternehmen können biometrische Identitätsanbieter IKT-Drittdienstleister sein. DORA gilt ab dem 17. Januar 2025 und erwartet von Finanzunternehmen das Management von IKT-Risiken, Vorfallmeldung, Testen der operationalen Resilienz und IKT-Drittparteienrisiko. Wenn biometrisches Onboarding eine kritische oder wichtige Funktion unterstützt, werden Lieferantenverträge, Vorfalleskalation, Resilienztests und Exit-Pläne ebenso zu Nachweisen operationaler Resilienz wie zu Datenschutznachweisen.
NIS2 ist außerdem für viele Cloud-, SaaS-, Managed-Service-, Managed-Security-, digitale Infrastruktur- und IKT-Service-Management-Anbieter relevant. Die Erwartungen an das Risikomanagement überschneiden sich stark mit ISO/IEC 27001:2022 und der biometrischen PIMS-Nachweiskette.
Cross-Compliance-Mapping für die Governance biometrischer Daten
Biometrische Governance sollte keine getrennten Silos für GDPR, ISO/IEC 27701:2025, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 und COBIT 19 schaffen. Ein Nachweismodell kann viele Verpflichtungen unterstützen.
| Governance-Anliegen | GDPR | ISO/IEC 27001:2022 und ISO/IEC 27002:2022 | Relevanz für NIS2 und DORA | Auditperspektive nach NIST CSF 2.0 und COBIT 19 |
|---|---|---|---|---|
| Rechtsgrundlage und Bedingung für besondere Kategorien | Articles 6 und 9 | ISMS-Kontext, rechtliche Anforderungen, Risikobehandlung und 5.34 Datenschutz und Schutz personenbezogener Daten | Rechenschaftspflicht des Managements und regulierte Leistungserbringung | GOVERN-Ergebnisse und Governance-Ziele erwarten, dass Verpflichtungen bekannt sind und gesteuert werden |
| DSFA und Datenschutzrisiko | Article 5 Rechenschaftspflicht, Article 35 DSFA, soweit erforderlich | Abschnitte 6.1.1 bis 6.1.3 Risikobeurteilung und -behandlung, SoA, Überwachung und Verbesserung | Verhältnismäßiges Risikomanagement und Kontrollwirksamkeit | Risikobereitschaft, Profile, Ausrichtung am Unternehmensrisiko und Assurance |
| Authentifizierung und Zugriff | Integrität und Vertraulichkeit | 5.17 Authentifizierungsinformationen, 8.5 Sichere Authentifizierung, Zugriffskontrolle, Protokollierung und Kryptografie | MFA oder kontinuierliche Authentifizierung, soweit angemessen, IKT-Risikokontrollen | Ergebnisse zu Identität, Authentifizierung, Prinzip der minimalen Berechtigung, Protokollierung und Überwachung |
| Verarbeitung durch Lieferanten | Pflichten des Auftragsverarbeiters nach Article 28 | 5.19 bis 5.22 Lieferantensicherheit und Kontrollen der IKT-Lieferkette | Lieferkettensicherheit, IKT-Drittparteienrisiko, Exit-Strategien | Lebenszyklus des Lieferkettenrisikomanagements, Verträge, gebotene Sorgfalt und Überwachung |
| Incident Response | Bewertung von Verletzungen des Schutzes personenbezogener Daten und Meldepflichten | Vorfallsplanung, Bewertung, Reaktion, Nachweise und Lessons Learned | Gestufte Meldung nach NIS2, DORA-Prozess für schwerwiegende IKT-Vorfälle | Erkennung, Reaktion, Wiederherstellung, Benachrichtigung von Interessenträgern und Integrität der Beweismittel |
| Aufbewahrung und Löschung | Speicherbegrenzung und Löschung | 8.10 Informationslöschung, Klassifizierung und Backup-Governance | Resilienz, Kontinuität und sicheres Lebenszyklusmanagement | Datenschutz, Backup-Verifikation, Wiederherstellungsdokumentation und Lebenszykluskontrollen |
Für NIS2-Einrichtungen können erhebliche Sicherheitsvorfälle eine Frühwarnung innerhalb von 24 Stunden, eine Vorfallsmeldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats erfordern. Wenn eine biometrische Identitätsplattform gestört oder kompromittiert wird, können Sicherheits-, Datenschutz- und operative Melde-Workflows gleichzeitig ausgelöst werden.
Auditperspektive: Was Prüfer fragen werden
Verschiedene Auditoren prüfen biometrische Governance aus unterschiedlichen Blickwinkeln. Clarysec nutzt Zenith Controls, um ISO/IEC 27002:2022-Maßnahmen mit Datenschutz-, Authentifizierungs-, Lieferanten-, Verschlüsselungs-, Löschungs-, Vorfalls- und Auditnachweisen zu verknüpfen.
| Prüferperspektive | Was gefragt wird | Von Clarysec vorbereitete Nachweise |
|---|---|---|
| ISO/IEC 27001:2022-Auditor | Liegt die biometrische Verarbeitung im Geltungsbereich, wurde sie risikobeurteilt, behandelt und durch die SoA gestützt? | Geltungsbereichserklärung, Risikoregister, Behandlungsplan, SoA, Richtlinienfreigaben, Kontrolltests |
| ISO/IEC 27701:2025 PIMS-Auditor | Können Zweck, Rechtsgrundlage, Rolle, DSFA, Bearbeitung von Betroffenenrechten, Aufbewahrung und Governance für Auftragsverarbeiter nachgewiesen werden? | REG02, REG04, REG05, REG12, Datenschutzhinweise, Datenaufbewahrungsplan, Lieferanten-Due-Diligence |
| GDPR-fokussierter Auditor oder Aufsichtsbehörde | Ist die Verarbeitung nach Article 9 gerechtfertigt, transparent, erforderlich, verhältnismäßig und sicher? | Aufzeichnung der Rechtsgrundlage, Bedingung für besondere Kategorien, DSFA, Einwilligungsnachweise, Löschprotokolle |
| NIST CSF-Assessor | Sind Ergebnisse zu Governance, Identität, Datenschutz, Überwachung, Reaktion und Wiederherstellung umgesetzt? | CSF-Profilzuordnung, Lückenplan, Berechtigungsüberprüfung, Protokolle, Vorfallsaufzeichnungen, Wiederherstellungsnachweise |
| COBIT 19- oder ISACA-Auditor | Sind Governance-Ziele, Risikoverantwortung, Assurance, Änderungskontrolle und Lieferantenaufsicht operativ wirksam? | RACI, Managementbewertung, Kontrollkennzahlen, Drittparteienprüfung, Prüfpfad, Korrekturmaßnahmen |
| DORA- oder NIS2-Readiness-Prüfer | Können Störung oder Kompromittierung des biometrischen Dienstes gesteuert, gemeldet und behoben werden? | Playbook zur Vorfallsklassifizierung, Lieferantenklauseln, BIA, Kontinuitätstests, Melde-Workflow |
Häufige Audit-Feststellungen sind technische Kontrollen ohne Governance-Entscheidungen, Rechtsgrundlage nach Article 6 ohne Bedingung nach Article 9, DSFAs nach der Produktivsetzung, Einwilligungsaufzeichnungen ohne Lösch-Auslöser, Lieferantenverträge ohne biometriespezifische Klauseln und Incident-Response-Playbooks, die die Kompromittierung biometrischer Templates wie eine gewöhnliche Kompromittierung von Zugangsdaten behandeln.
Ein praktischer Genehmigungs-Workflow für biometrisches Onboarding
Eine von Clarysec begleitete Organisation, die Gesichtsverifikation für Kunden-Onboarding einsetzt, würde einem strukturierten Pfad folgen:
- Einen Verarbeitungsdatensatz in REG02 erstellen.
- Rollen als Verantwortlicher, Auftragsverarbeiter und Unterauftragsverarbeiter bestimmen.
- Die Rechtsgrundlage nach Article 6 und die Bedingung nach Article 9 erfassen, wenn biometrische Daten zur eindeutigen Identifizierung verwendet werden.
- Datenkategorien wie Selfie, Dokumentenbild, biometrisches Template, Liveness-Ergebnis, Matching-Score, Audit-Protokolle und Support-Exporte erfassen.
- REG04-DSFA vor der Implementierung auslösen.
- Erforderlichkeit, Verhältnismäßigkeit und nicht-biometrische Alternativen bewerten.
- Ausdrückliche Einwilligung in REG05 definieren, soweit erforderlich.
- Rohbilder und Templates als Streng vertraulich oder höchste Sensitivität klassifizieren.
- REG12-Sicherheitsanforderungen für Verschlüsselung, Schlüsselmanagement, Zugriff, Protokollierung, Überwachung, Exportbeschränkungen und Löschung definieren.
- Lieferanten-Due-Diligence, Liste der Unterauftragsverarbeiter, Hosting-Standort, Vorfallmeldung, Auditrechte und Workflow für Löschzertifikate prüfen.
- Aufbewahrungsregeln für erfolgreiches Onboarding, fehlgeschlagenes Onboarding, widerrufene Einwilligung, Einsprüche, Betrugsuntersuchungen und Backups ergänzen.
- Restrisiko mit namentlich benannten Verantwortlichen genehmigen.
- Auditnachweise im PIMS-Nachweisrepository speichern.
- Wirksamkeit nach dem Launch und nach Änderungen beim Anbieter überprüfen.
Dies gibt dem CISO technische Kontrollnachweise, dem DPO Rechenschaftspflicht im Datenschutz, der Beschaffung vertragliche Gates, dem Produktmanagement einen Launch-Pfad und Auditoren eine nachvollziehbare Geschichte.
Biometrische Risiken in Vertrauen überführen
Zurück bei Finura sagte Maria das biometrische Feature nicht ab. Sie setzte es neu auf. Produktmanagement und Engineering integrierten PIMS-Anforderungen in den Entwicklungslebenszyklus. Der Einwilligungsablauf wurde ausdrücklich und getrennt. Der Lieferantenvertrag erhielt stärkere Verpflichtungen zu Löschung, Audit, Datenschutzverletzungen und Unterauftragsverarbeitern. REG02, REG04, REG05 und REG12 wurden zum Rückgrat der Nachweise. Für widerrufene Daten wurde kryptografische Löschung implementiert. Der Launch verschob sich um ein Quartal, ging aber auf einer Vertrauensbasis produktiv.
Genau darum geht es bei Governance für biometrische Daten. Sie verbietet Innovation nicht. Sie macht Innovation belastbar.
Ihre nächsten Schritte sind klar:
- Inventarisieren Sie jeden biometrischen Anwendungsfall, einschließlich Zutritt am Arbeitsplatz, Kunden-Onboarding, Geräteauthentifizierung, Betrugsprävention und Sprachverifikation.
- Klassifizieren Sie die Daten und bestätigen Sie, ob sie zur eindeutigen Identifizierung verwendet werden.
- Erfassen Sie Rechtsgrundlage und jede Bedingung für besondere Kategorien im Verzeichnis der Verarbeitungstätigkeiten.
- Führen Sie eine DSFA durch, bevor neue oder wesentlich geänderte Verarbeitung beginnt.
- Validieren Sie ausdrückliche Einwilligung und Alternativen, soweit erforderlich.
- Prüfen Sie Lieferantenverträge und Unterauftragsverarbeiter.
- Definieren Sie Nachweise für Verschlüsselung, Zugriff, Protokollierung, Überwachung und Löschung.
- Bilden Sie die Nachweise auf Erwartungen aus ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 und COBIT 19 ab.
Clarysec kann Ihnen helfen, Governance für biometrische Daten in einen auditfähigen PIMS-Workflow zu überführen. Starten Sie mit Zenith Blueprint: 30-Schritte-Fahrplan für Auditoren Zenith Blueprint, validieren Sie Ihr Cross-Framework-Mapping mit Zenith Controls: Der Cross-Compliance-Leitfaden Zenith Controls und operationalisieren Sie die Nachweise über Clarysecs ISO/IEC 27701:2025 PIMS-Richtlinienset, einschließlich der Richtlinie zum Verarbeitungsinventar personenbezogener Daten und zur Rechtsgrundlage, Richtlinie zur Datenschutz-Risikobeurteilung und DSFA, Richtlinie zu Einwilligungs- und Präferenzmanagement, Richtlinie zur Sicherheit und Zugriffskontrolle personenbezogener Daten und Richtlinie zum Datenschutzmanagement für Auftragsverarbeiter, Unterauftragsverarbeiter und Drittparteien.
Biometrie kann Sicherheit stärken und die Benutzererfahrung verbessern. Nur gesteuerte Biometrie verdient dauerhaftes Vertrauen.
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