⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Governance für biometrische Daten nach GDPR und ISO 27701

Igor Petreski

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:

  1. Wo ist die biometrische Verarbeitungstätigkeit aufgezeichnet?
  2. Was ist die Rechtsgrundlage nach GDPR Article 6 und, soweit anwendbar, die Bedingung für besondere Kategorien nach Article 9?
  3. Wurde eine DSFA abgeschlossen, bevor die Verarbeitung begann?
  4. Können Sie nachweisen, dass biometrische Templates gelöscht werden, wenn der Zweck entfällt?
  5. 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:

EntscheidungspunktErforderliche NachweiseClarysec-Toolkit-Anker
Zweck und ErforderlichkeitGeschäftszweck, geprüfte Alternativen, Entscheidung zur VerhältnismäßigkeitRichtlinie zum Verarbeitungsinventar personenbezogener Daten und zur Rechtsgrundlage, REG02
Rechtsgrundlage und Bedingung für besondere KategorienGrundlage nach GDPR Article 6 und Bedingung nach Article 9, soweit anwendbarRichtlinie zu Datenschutz und Privatsphäre, REG02
DSFA-Auslöser und ErgebnisDSFA-Screening, Risikobeurteilung, Genehmigung des RestrisikosRichtlinie zur Datenschutz-Risikobeurteilung und DSFA, REG04
SicherheitsarchitekturVerschlüsselung, Zugriffskontrolle, Authentifizierung, Protokollierung, SegmentierungRichtlinie zur Sicherheit und Zugriffskontrolle personenbezogener Daten, REG12
Transparenz und Einwilligung, soweit relevantDatenschutzhinweis, Nachweis ausdrücklicher Einwilligung, soweit erforderlich, WiderrufsbearbeitungRichtlinie zu Einwilligungs- und Präferenzmanagement, REG05
Lieferanten-GovernanceRolle als Auftragsverarbeiter, Vertragsbedingungen, Prüfung von Unterauftragsverarbeitern, jährliche NeubewertungRichtlinie zum Datenschutzmanagement für Auftragsverarbeiter, Unterauftragsverarbeiter und Drittparteien, Lieferantenregister
Aufbewahrung und LöschungDatenaufbewahrungsplan, Löschprotokolle, Umgang mit Backups, LöschungsnachweiseRichtlinie 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:

DatenobjektWarum es relevant istTypische Klassifizierungsbehandlung
Rohbild oder Audiodaten aus der ErfassungKönnen biometrische Merkmale und zusätzliche personenbezogene Daten offenlegenStreng vertraulich oder höchste Sensitivität
Biometrisches TemplateWird zur eindeutigen Identifizierung oder Verifikation verwendetStreng vertraulich oder höchste Sensitivität
Matching-ScoreKann Zugriff, Onboarding oder Betrugsergebnisse beeinflussenVertraulich oder Streng vertraulich
RegistrierungsmetadatenVerknüpfen Person, Gerät, Zeit, Ort und MethodeVertraulich
Protokolle fehlgeschlagener MatchesKönnen Verhaltensmuster oder False-Rejection-Ereignisse offenlegenVertraulich
Support-Exporte des AnbietersWerden bei der Fehlerbehebung häufig übersehenStreng vertraulich, wenn biometrisch oder identitätsbezogen
Backup-Kopien und SnapshotsRisiko für Aufbewahrung und LöschungWie 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-AnliegenGDPRISO/IEC 27001:2022 und ISO/IEC 27002:2022Relevanz für NIS2 und DORAAuditperspektive nach NIST CSF 2.0 und COBIT 19
Rechtsgrundlage und Bedingung für besondere KategorienArticles 6 und 9ISMS-Kontext, rechtliche Anforderungen, Risikobehandlung und 5.34 Datenschutz und Schutz personenbezogener DatenRechenschaftspflicht des Managements und regulierte LeistungserbringungGOVERN-Ergebnisse und Governance-Ziele erwarten, dass Verpflichtungen bekannt sind und gesteuert werden
DSFA und DatenschutzrisikoArticle 5 Rechenschaftspflicht, Article 35 DSFA, soweit erforderlichAbschnitte 6.1.1 bis 6.1.3 Risikobeurteilung und -behandlung, SoA, Überwachung und VerbesserungVerhältnismäßiges Risikomanagement und KontrollwirksamkeitRisikobereitschaft, Profile, Ausrichtung am Unternehmensrisiko und Assurance
Authentifizierung und ZugriffIntegrität und Vertraulichkeit5.17 Authentifizierungsinformationen, 8.5 Sichere Authentifizierung, Zugriffskontrolle, Protokollierung und KryptografieMFA oder kontinuierliche Authentifizierung, soweit angemessen, IKT-RisikokontrollenErgebnisse zu Identität, Authentifizierung, Prinzip der minimalen Berechtigung, Protokollierung und Überwachung
Verarbeitung durch LieferantenPflichten des Auftragsverarbeiters nach Article 285.19 bis 5.22 Lieferantensicherheit und Kontrollen der IKT-LieferketteLieferkettensicherheit, IKT-Drittparteienrisiko, Exit-StrategienLebenszyklus des Lieferkettenrisikomanagements, Verträge, gebotene Sorgfalt und Überwachung
Incident ResponseBewertung von Verletzungen des Schutzes personenbezogener Daten und MeldepflichtenVorfallsplanung, Bewertung, Reaktion, Nachweise und Lessons LearnedGestufte Meldung nach NIS2, DORA-Prozess für schwerwiegende IKT-VorfälleErkennung, Reaktion, Wiederherstellung, Benachrichtigung von Interessenträgern und Integrität der Beweismittel
Aufbewahrung und LöschungSpeicherbegrenzung und Löschung8.10 Informationslöschung, Klassifizierung und Backup-GovernanceResilienz, Kontinuität und sicheres LebenszyklusmanagementDatenschutz, 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üferperspektiveWas gefragt wirdVon Clarysec vorbereitete Nachweise
ISO/IEC 27001:2022-AuditorLiegt 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-AuditorKö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ördeIst 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-AssessorSind 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-AuditorSind Governance-Ziele, Risikoverantwortung, Assurance, Änderungskontrolle und Lieferantenaufsicht operativ wirksam?RACI, Managementbewertung, Kontrollkennzahlen, Drittparteienprüfung, Prüfpfad, Korrekturmaßnahmen
DORA- oder NIS2-Readiness-PrüferKö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:

  1. Einen Verarbeitungsdatensatz in REG02 erstellen.
  2. Rollen als Verantwortlicher, Auftragsverarbeiter und Unterauftragsverarbeiter bestimmen.
  3. Die Rechtsgrundlage nach Article 6 und die Bedingung nach Article 9 erfassen, wenn biometrische Daten zur eindeutigen Identifizierung verwendet werden.
  4. Datenkategorien wie Selfie, Dokumentenbild, biometrisches Template, Liveness-Ergebnis, Matching-Score, Audit-Protokolle und Support-Exporte erfassen.
  5. REG04-DSFA vor der Implementierung auslösen.
  6. Erforderlichkeit, Verhältnismäßigkeit und nicht-biometrische Alternativen bewerten.
  7. Ausdrückliche Einwilligung in REG05 definieren, soweit erforderlich.
  8. Rohbilder und Templates als Streng vertraulich oder höchste Sensitivität klassifizieren.
  9. REG12-Sicherheitsanforderungen für Verschlüsselung, Schlüsselmanagement, Zugriff, Protokollierung, Überwachung, Exportbeschränkungen und Löschung definieren.
  10. Lieferanten-Due-Diligence, Liste der Unterauftragsverarbeiter, Hosting-Standort, Vorfallmeldung, Auditrechte und Workflow für Löschzertifikate prüfen.
  11. Aufbewahrungsregeln für erfolgreiches Onboarding, fehlgeschlagenes Onboarding, widerrufene Einwilligung, Einsprüche, Betrugsuntersuchungen und Backups ergänzen.
  12. Restrisiko mit namentlich benannten Verantwortlichen genehmigen.
  13. Auditnachweise im PIMS-Nachweisrepository speichern.
  14. 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:

  1. Inventarisieren Sie jeden biometrischen Anwendungsfall, einschließlich Zutritt am Arbeitsplatz, Kunden-Onboarding, Geräteauthentifizierung, Betrugsprävention und Sprachverifikation.
  2. Klassifizieren Sie die Daten und bestätigen Sie, ob sie zur eindeutigen Identifizierung verwendet werden.
  3. Erfassen Sie Rechtsgrundlage und jede Bedingung für besondere Kategorien im Verzeichnis der Verarbeitungstätigkeiten.
  4. Führen Sie eine DSFA durch, bevor neue oder wesentlich geänderte Verarbeitung beginnt.
  5. Validieren Sie ausdrückliche Einwilligung und Alternativen, soweit erforderlich.
  6. Prüfen Sie Lieferantenverträge und Unterauftragsverarbeiter.
  7. Definieren Sie Nachweise für Verschlüsselung, Zugriff, Protokollierung, Überwachung und Löschung.
  8. 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

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

Share this article