Compliance-Nachweiskarte für die EU Digital Identity Wallet 2026

Ein Fintech-Produktteam steht zwei Wochen vor dem Start eines Wallet-basierten Onboardings. Der neue Ablauf ermöglicht EU-Kunden, ausgewählte Identitätsattribute über die EU Digital Identity Wallet nachzuweisen, statt Identitätsdokumente manuell hochzuladen. Der CISO erkennt den Sicherheitsvorteil. Der Datenschutzbeauftragte (DPO) begrüßt das Potenzial zur Datenminimierung. Die Compliance-Leitung erwartet weniger abgebrochene Onboarding-Prozesse und ein saubereres Kundenerlebnis.

Dann stellt der Prüfungsausschuss die Frage, die die Stimmung im Raum verändert:

„Wenn eine Aufsichtsbehörde, ein Bankpartner, ein Kundenauditor oder eine zuständige Kontrollstelle fragt, wie diese Wallet-Integration gesteuert wird: Welche Nachweise legen wir vor?“

Das ist das eigentliche Problem für 2026.

Die EU Digital Identity Wallet, häufig als EUDI Wallet abgekürzt, ist nicht nur ein weiteres Produktmerkmal. Für regulierte digitale Dienste, Zahlungsdienstleister, Ökosysteme für Vertrauensdienste, Schnittstellen des öffentlichen Sektors und Onboarding-Prozesse mit hohem Vertrauensniveau wird sie Teil der Identitätssicherungskette der Organisation. Sie berührt personenbezogene Daten, Authentifizierungsereignisse, Lieferantenabhängigkeiten, Zugriffsgovernance, Protokollierung, Kryptografie, Vorfallmeldungen und die Rechenschaftspflicht des Leitungsorgans.

Die Falle besteht darin, eIDAS2 und die EUDI Wallet als isolierte rechtliche Umsetzung zu behandeln. Die praktische Antwort ist eine andere: Die Einführung der Wallet durch vertrauende Parteien muss in dasselbe Nachweissystem eingebunden werden, das für ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 und COBIT 2019 genutzt wird.

Genau hier ist der Ansatz von Clarysec besonders stark. Wir machen aus jeder neuen Regulierung nicht noch eine weitere Tabelle. Wir ordnen Verpflichtungen Richtlinien, Kontrollen, Verantwortlichen, Prüfpfaden und wiederholbaren Nachweisen zu.

Dieser Artikel zeigt, wie Sie dieses Nachweisrückgrat mit Clarysecs Zenith Blueprint: Eine 30-Schritte-Roadmap für Auditoren, Zenith Controls: Der Leitfaden für Cross-Compliance sowie Clarysec-Richtlinienvorlagen für Datenschutz, Identität, Protokollierung, Lieferanten-Governance und regulatorische Compliance aufbauen.

Das Wallet-Nachweisproblem 2026 ist größer als eIDAS2

Die meisten Diskussionen über die EU Digital Identity Wallet konzentrieren sich auf Vertrauen, Interoperabilität und Benutzererfahrung. Diese Punkte sind wichtig. Ein CISO, Compliance-Manager, DPO oder Auditor stellt jedoch eine stärker operative Frage: Welche Kontrollen belegen, dass aus der Wallet abgeleitete Identitätsattribute sicher, rechtmäßig und verhältnismäßig verwendet werden?

Eine vertrauende Partei, die Wallet-Assertions akzeptiert, muss Folgendes beantworten können:

• Welche Wallet-Attribute werden angefordert, und warum?
• Welche Rechtsgrundlage trägt die Verarbeitung?
• Sind Benutzer, Administratoren und Servicekonten eindeutig identifizierbar?
• Sind Wallet-Verifizierungsdienste, Identitätsbroker, API-Gateways und Cloud-Komponenten im Lieferantenregister erfasst?
• Werden Authentifizierungs- und Verifizierungsereignisse so protokolliert, dass Untersuchungen unterstützt werden, ohne personenbezogene Daten übermäßig zu erfassen?
• Gibt es einen Vorfallsprozess, wenn Wallet-Onboarding missbraucht wird, nicht verfügbar ist oder kompromittiert wird?
• Ist die Wallet-Integration bei Finanzunternehmen durch das Management von DORA-IKT-Risiken, Drittparteienrisiken und Vorfallklassifizierung abgedeckt?
• Beeinflusst die Wallet-Abhängigkeit bei NIS2-Einrichtungen wesentliche oder wichtige Leistungserbringung, Zugriffskontrolle, Geschäftskontinuität oder Kundenkommunikation?

NIS2 ist besonders relevant, weil sein Geltungsbereich viele Anbieter digitaler Infrastrukturen, Cloud-Services, Managed Service Provider (MSPs), Managed Security Service Provider und Vertrauensdiensteanbieter umfasst. Die Richtlinie stuft außerdem qualifizierte Vertrauensdiensteanbieter, DNS-Anbieter, TLD-Register und mehrere weitere Einrichtungen unter bestimmten Umständen als wesentlich ein. Bis 2026 werden viele Organisationen nicht mehr fragen, ob das Gesetz kommt. Sie werden Fragen von Aufsichtsbehörden, Kunden und der Internen Revision zur Umsetzung beantworten.

Für Finanzdienstleistungen fügt DORA eine weitere Ebene hinzu. DORA gilt seit dem 17. Januar 2025 und schafft ein einheitliches Rahmenwerk für IKT-Risiken, Vorfälle, Tests und Drittparteienrisiken bei Finanzunternehmen. NIS2 erkennt DORA für viele überschneidende Cybersicherheitsverpflichtungen im Finanzsektor als sektorspezifischen Rechtsakt der Union an. Praktisch bedeutet dies: Eine Wallet-basierte Onboarding-Funktion bei einem Zahlungsinstitut, Kryptowerte-Dienstleister, Wertpapierunternehmen oder Kontoinformationsdienstleister muss über eine DORA-konforme IKT-Risikogovernance nachgewiesen werden, auch wenn NIS2 für Koordination und Ökosystemabhängigkeiten weiterhin relevant bleibt.

Die falsche Reaktion besteht darin, ein Nachweispaket für eIDAS2, eines für GDPR, eines für NIS2, eines für DORA und eines für die ISO-Zertifizierung zu erstellen. Die richtige Reaktion ist, das ISMS als operatives Nachweismodell zu nutzen.

ISO 27001 als Nachweisrückgrat nutzen

ISO/IEC 27001:2022 ist hilfreich, weil die Norm nicht auf eine technische Checkliste beschränkt ist. Sie verlangt von Organisationen, Kontext, interessierte Parteien, gesetzliche und vertragliche Verpflichtungen, Geltungsbereich, Schnittstellen, Abhängigkeiten, Verantwortlichkeiten der Leitung, Risikobeurteilung, Risikobehandlung, die Erklärung zur Anwendbarkeit und kontinuierliche Verbesserung zu definieren.

Das ist für die Wallet-Einführung wichtig, weil das Risiko nicht nur in einem API-Aufruf liegt. Das Risiko liegt im durchgängigen Geschäftsprozess.

Eine Umsetzung der Wallet durch eine vertrauende Partei betrifft:

• Kunden-Onboarding und Kontozugriff;
• Datenschutzhinweise, RoPA-Einträge und Aufzeichnungen zur Rechtsgrundlage;
• Identitätsprüfung und Authentifizierungsmodelle;
• Lieferantenverträge und Zusicherungen;
• Protokollierung, Überwachung und Beweissicherung;
• Vorfallklassifizierung und Berichtspflichten;
• Datenaufbewahrung, Löschung und Berichtigung;
• Audit und Compliance-Überwachung;
• Risikoberichterstattung an das Leitungsorgan.

Die Unternehmensrichtlinie von Clarysec zur Compliance macht dieses Betriebsmodell ausdrücklich:

„Alle rechtlichen und regulatorischen Verpflichtungen müssen bestimmten Richtlinien, Kontrollen und Verantwortlichen innerhalb des Informationssicherheits-Managementsystems (ISMS) zugeordnet werden.“
Aus Richtlinie zur rechtlichen und regulatorischen Compliance, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.

Für KMU wird dasselbe Prinzip auf ein praktikables Compliance-Register skaliert:

„Wenn eine Regulierung mehrere Bereiche betrifft (z. B. gilt GDPR für Aufbewahrung, Sicherheit und Datenschutz), muss dies im Compliance-Register und in den Schulungsmaterialien eindeutig zugeordnet werden.“
Aus Richtlinie zur rechtlichen und regulatorischen Compliance – KMU, Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.2.

Die Organisation sollte nicht fragen: „Welche Abteilung ist für eIDAS2 zuständig?“ Sie sollte fragen: „Welche ISMS-Risiken, Kontrollen, Richtlinien, Verantwortlichen und Nachweisaufzeichnungen sind durch die Wallet-Abhängigkeit betroffen?“

In Zenith Blueprint heißt es in der Phase Risikomanagement, Schritt 14:

„Für jede Regulierung können Sie, sofern anwendbar, eine einfache Zuordnungstabelle erstellen (z. B. als Anhang in einem Bericht), die die wichtigsten Sicherheitsanforderungen der Regulierung und die entsprechenden Kontrollen/Richtlinien in Ihrem ISMS aufführt. Dies ist nach ISO 27001 nicht verpflichtend, aber eine sinnvolle interne Übung, um sicherzustellen, dass nichts übersehen wurde. Außerdem zeigt es Auditoren/Bewertenden, dass Sie Sicherheit nicht im luftleeren Raum steuern, sondern den rechtlichen Kontext berücksichtigen.“

Das ist die Grundlage: Erstellen Sie eine einheitliche Zuordnungstabelle, die Wallet-Verpflichtungen vertrauender Parteien mit GDPR, NIS2, DORA, ISO/IEC 27001:2022 Annex A-Kontrollen, Clarysec-Richtlinien und Nachweisaufzeichnungen verbindet.

Eine praktische Nachweiskarte für vertrauende Parteien der EU Digital Identity Wallet

Die EUDI Wallet wird beherrschbar, wenn sie als definierter Geschäftsprozess innerhalb des ISMS behandelt wird – mit zugeordneten Daten, Identitäten, Lieferanten, Protokollen, Vorfällen und Verantwortlichen.

Diese Tabelle ist keine Rechtsberatung. Sie ist ein Kontroll- und Nachweismodell, mit dem CISOs, Compliance-Teams und Auditoren Nachweise strukturieren können.

Beim Identitätsmanagement werden Auditoren beginnen

Für eine vertrauende Partei der Wallet ist Identität die naheliegende Kontrollfamilie. Identitätsmanagement ist jedoch nicht dasselbe wie Authentifizierung. Identitätsmanagement beantwortet die Frage: „Wer existiert im System und wie wird diese Identität gesteuert?“ Authentifizierung beantwortet die Frage: „Wie wird die behauptete Identität zum Zeitpunkt des Zugriffs verifiziert?“

In Zenith Controls wird ISO/IEC 27002:2022 control 5.16, Identitätsmanagement, als präventive Kontrolle behandelt, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Sie ist direkt mit Zugriffskontrolle, Authentifizierungsinformationen, Zugriffsrechten, Lieferantenbeziehungen, Compliance-Überwachung und privilegiertem Zugriff verknüpft. Die Cross-Compliance-Zuordnung verbindet diesen Bereich mit GDPR-Sicherheit und Rechenschaftspflicht, NIS2-Zugriffskontrolle und Asset-Management, DORA-Identitäts- und Zugriffsgovernance, NIST SP 800-53-Kennungsmanagement und COBIT 2019-Governance des Identitätslebenszyklus.

Für Wallet-Nachweise muss die Organisation nachweisen können:

• Kunden- und Mitarbeiteridentitäten werden nicht vermischt;
• administrative Identitäten sind eindeutig und nachvollziehbar;
• Lieferantenidentitäten werden mit derselben Disziplin gesteuert wie Mitarbeiteridentitäten;
• nicht-menschliche Identitäten, etwa API-Clients und Servicekonten, haben Verantwortliche;
• Identitäten werden entzogen, wenn sie nicht mehr erforderlich sind;
• Ausnahmen, Break-Glass-Konten und privilegierte Identitäten werden kontrolliert.

Die KMU-Kontenrichtlinie von Clarysec beschreibt das Prinzip in einfacher Sprache:

„Jedes Konto muss eindeutig sein, einer bestimmten Person zugeordnet werden können und mit einer Geschäftsrolle verknüpft sein.“
Aus Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen – KMU, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.2.

Für Unternehmen ist die Anforderung an gemeinsame Konten strenger:

„Alle Benutzeridentitäten müssen mit einer eindeutigen Kennung verknüpft sein. Die Nutzung gemeinsamer oder generischer Konten ist untersagt, ausgenommen genehmigte Break-Glass- oder Notfallkonten, die strengen Kontrollen unterliegen.“
Aus Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen, Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.

Unterstützende Normen verstärken dieselbe Nachweislogik. ISO/IEC 24760-1:2019 stellt Konzepte des Identitätslebenszyklus wie Registrierung, Bindung, Nutzung und Deregistrierung bereit. ISO/IEC 29115:2013 unterstützt risikobasierte Identitätssicherung. ISO/IEC 27005:2024 behandelt Schwächen in Identität und Zugriff als Themen der Risikobehandlung. ISO/IEC 27018:2020 erweitert Erwartungen an das Identitätsmanagement für die Verarbeitung personenbezogener Daten in Public Clouds. ISO/IEC 29100:2011 ergänzt die Datenschutzperspektive, indem Identifizierbarkeit mit dem Umgang mit personenbezogenen Informationen verknüpft wird.

Für die Einführung der EUDI Wallet ist die Auditfrage einfach: Können Sie jede privilegierte Handlung, jede Konfigurationsänderung, jede Änderung der Wallet-Verifizierungsintegration und jedes Lieferantenzugriffsereignis auf eine eindeutige Identität mit genehmigter Rolle zurückführen?

Wenn die Antwort nein lautet, ist das Wallet-Projekt nicht auditbereit.

Sichere Authentifizierung: Wallet-Vertrauen entbindet nicht von Kontrollpflichten

Ein verbreiteter Irrtum ist, dass Wallet-basierte Identitätsprüfung die Authentifizierungspflichten der vertrauenden Partei beseitigt. Sie kann die Vertrauenswürdigkeit bestimmter Identitätsattribute erhöhen, sie beseitigt aber nicht die Pflicht, Systeme, Sitzungen, APIs, administrative Schnittstellen und Kundenprozesse abzusichern.

In Zenith Blueprint, Phase „Controls in Action“, Schritt 19, stellt Clarysec fest:

„Authentifizierung ist die erste und wichtigste Verteidigungslinie zwischen einem Bedrohungsakteur und Ihren Systemen, Daten und Services. Wenn die Authentifizierung schwach ist, kann alles andere – Verschlüsselung, Überwachung, Segmentierung – umgangen werden.“

Derselbe Schritt erläutert, dass moderne Authentifizierung risikobasiert sein, für höherwertige Ziele stärker ausgeprägt sein und durch MFA, sichere Speicherung von Zugangsdaten, TLS, Token-Schutz, Management von Geheimnissen, sicheres Sitzungsmanagement und Überprüfung von Authentifizierungsprotokollen unterstützt werden muss.

In Zenith Controls wird ISO/IEC 27002:2022 control 8.5, sichere Authentifizierung, als präventive Kontrolle innerhalb der Fähigkeit Identitäts- und Zugriffsmanagement zugeordnet. Sie ist mit Identitätsmanagement, Authentifizierungsinformationen, privilegiertem Zugriff, Beschränkung des Informationszugriffs, Überwachungstätigkeiten, Incident Management und Schutz personenbezogener Daten verknüpft. Außerdem wird sie mit GDPR-Sicherheit und Datenschutz durch Technikgestaltung, NIS2-Management von Cybersicherheitsrisiken sowie MFA oder kontinuierlicher Authentifizierung, soweit angemessen, DORA-Governance von IKT-Risiken, den NIST SP 800-53-Familien IA und AC sowie COBIT 2019-Governance des logischen Zugriffs abgeglichen.

Für eine vertrauende Partei der Wallet müssen Nachweise zur sicheren Authentifizierung Folgendes umfassen:

• Authentifizierung und Autorisierung von Wallet-Verifizierungsendpunkten;
• Administrator-MFA für Wallet-Konfigurationsoberflächen;
• sichere API-Authentifizierung zwischen Onboarding-Services;
• Ablage von Wallet-Integrationsschlüsseln oder Zertifikaten in Schlüsselablagen;
• Sitzungszeitüberschreitungen und Token-Schutz, soweit angemessen;
• Warnmeldungen bei fehlgeschlagener Authentifizierung und Schutz vor Brute-Force-Versuchen;
• getrennte Kontrollen für Kundenanmeldung, Mitarbeiterzugriff und Machine-to-Machine-Zugriff.

Die Protokollierungsrichtlinie von Clarysec für KMU enthält eine praktische Nachweisanforderung:

„Authentifizierungsprotokolle: erfolgreiche und fehlgeschlagene Anmeldeversuche, Sitzungsdauer, MFA-Nutzung“
Aus Richtlinie zur Protokollierung und Überwachung – KMU, Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4.2.

Für Unternehmensumgebungen wird die Auditverlässlichkeit zentral:

„Protokolldateien müssen unveränderbar oder versionskontrolliert sein; Zugriff darf nur autorisiertem Personal gewährt werden.“
Aus Richtlinie zur Protokollierung und Überwachung, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.5.1.

Dies ist die Brücke zwischen Identitätssicherung und Incident Response. Wenn Wallet-Onboarding durch Credential Stuffing, Token-Replay, administrative Kompromittierung oder Lieferantenmissbrauch angegriffen wird, werden Authentifizierungsprotokolle zum Nachweispfad.

GDPR: Das Wallet-Versprechen ist Minimierung – aber Sie müssen sie nachweisen

Die EU Digital Identity Wallet kann datenschutzförderndes Onboarding unterstützen, weil eine vertrauende Partei bestimmte Attribute anfordern kann, statt vollständige Identitätsdokumente zu erfassen. Die Rechenschaftspflicht nach GDPR basiert jedoch nicht auf guten Absichten. Sie verlangt nachweisbare Compliance.

Aus der Wallet abgeleitete Attribute sind personenbezogene Daten, wenn sie sich auf eine identifizierte oder identifizierbare Person beziehen. Einige Anwendungsfälle können außerdem biometrische Daten, Daten zur Identitätsverifikation, Sanktionsprüfungen, Betrugsrisiken oder andere sensible Verarbeitungskontexte berühren.

Die Grundsätze der GDPR verlangen eine rechtmäßige, faire und transparente Verarbeitung, festgelegte Zwecke, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit sowie Rechenschaftspflicht. Eine vertrauende Partei muss nachweisen können, warum jedes Wallet-Attribut angefordert wird, wie lange es aufbewahrt wird, wer darauf zugreifen darf, wie es geschützt wird und wie Wiederverwendung kontrolliert wird.

Die Datenschutzrichtlinie von Clarysec für Unternehmen stellt fest:

„Es dürfen nur Daten erhoben und verarbeitet werden, die für einen bestimmten, legitimen Geschäftszweck erforderlich sind.“
Aus Richtlinie zu Datenschutz und Privatsphäre, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.

Die KMU-Version ist bewusst knapp gehalten:

„Es dürfen nur die mindestens erforderlichen personenbezogenen Daten erhoben und aufbewahrt werden.“
Aus Richtlinie zu Datenschutz und Privatsphäre – KMU, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.

In Zenith Controls wird ISO/IEC 27002:2022 control 5.34, Datenschutz und Schutz personenbezogener Daten, Asset-Inventar, Datenmaskierung, Governance für Cloud-Services, Informationsklassifizierung, sicherer Übertragung, Zugriffskontrolle, Identitätsmanagement und Projektänderungsprüfung zugeordnet. Außerdem besteht eine Verbindung zu ISO/IEC 27701:2021 für Datenschutzmanagement, ISO/IEC 27018 für die Verarbeitung personenbezogener Daten in der Cloud und den Datenschutzgrundsätzen von ISO/IEC 29100.

Für die Wallet-Einführung muss das Datenschutz-Nachweispaket Folgendes enthalten:

• Datenflussdiagramm für Wallet-Attribute;
• Eintrag im Register der Rechtsgrundlagen;
• Entscheidungsaufzeichnung zur Attributminimierung;
• Aufbewahrungsplan für aus der Wallet abgeleitete Daten;
• Aktualisierung des Datenschutzhinweises;
• DPIA oder Datenschutz-Risikobewertung, wenn der Anwendungsfall ein hohes Risiko aufweist;
• Zugriffskontrollmatrix für Wallet-Daten;
• Prozess zur Datenlöschung und Berichtigung;
• Überwachungsnachweise, die zeigen, dass der Zugriff auf aus der Wallet abgeleitete personenbezogene Daten kontrolliert wird.

Viele Organisationen erfassen zu viele Daten, weil die Wallet die Beschaffung verifizierter Daten erleichtert. Das ist der falsche Ansatz. Der Sicherheits- und Datenschutzvorteil entsteht dadurch, weniger anzufordern – nicht dadurch, mehr verifizierte Identitätsdaten zu speichern, als das Geschäft benötigt.

NIS2 und DORA: Rechenschaftspflicht des Leitungsorgans trifft Wallet-Resilienz

NIS2 und DORA verlagern Cybersicherheit beide in die Governance. Sie verlangen, dass Leitungsorgane Risikomaßnahmen genehmigen, überwachen und verantworten. Außerdem erwarten sie verhältnismäßige technische, operative und organisatorische Kontrollen.

NIS2 Article 21 verlangt Risikomanagementmaßnahmen, die Richtlinien, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Geschäftskontinuität, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Schwachstellenbehandlung, Kontrollwirksamkeit, Cyberhygiene, Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management und, soweit angemessen, MFA oder kontinuierliche Authentifizierung abdecken. Für vertrauende Parteien der Wallet in NIS2-Sektoren muss die Wallet-Integration in der Risikobeurteilung, im Asset-Inventar, im Lieferantenregister, im Vorfallsplan und im Zugriffskontrollrahmenwerk erscheinen.

NIS2 Article 23 ergänzt eine gestufte Meldung erheblicher Vorfälle. Wesentliche und wichtige Einrichtungen müssen eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats vorlegen, mit Benachrichtigung der Empfänger, sofern anwendbar. Wenn ein Ausfall der Wallet-Integration zu Betriebsunterbrechungen, finanziellen Verlusten oder materiellen oder immateriellen Schäden für Serviceempfänger führen könnte, muss er in die Logik der Vorfallklassifizierung aufgenommen werden.

DORA ist für Finanzunternehmen spezifischer. Die Verordnung verlangt ein internes Governance- und Kontrollrahmenwerk für IKT-Risiken, eine vom Leitungsorgan genehmigte Resilienzstrategie, IKT-Richtlinien, Pläne für Business Continuity und Reaktion, Auditpläne, Drittparteienrichtlinien, Meldekanäle für Sicherheitsvorfälle und ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken. Sie verlangt außerdem Management IKT-bezogener Vorfälle, Klassifizierung anhand von Kriterien wie betroffene Kunden, Ausfallzeit, geografische Ausbreitung, Datenverlust, Kritikalität und wirtschaftliche Auswirkungen sowie Meldung schwerwiegender IKT-bezogener Vorfälle.

Bei Wallet-basiertem Onboarding in Finanzdienstleistungen müssen Nachweise zeigen:

• die Wallet-Integration ist im IKT-Asset- und Prozessinventar enthalten;
• Risiken werden beurteilt und vom zuständigen Risikoverantwortlichen akzeptiert;
• die Kritikalität für Kunden-Onboarding oder Kontozugriff wird bewertet;
• Resilienz- und Rückfalloptionen bestehen;
• Vorfälle können nach DORA-Kriterien klassifiziert werden;
• Kundenbenachrichtigungen sind geplant, wenn finanzielle Interessen betroffen sind;
• ausgelagerte Berichterstattung hebt die Rechenschaftspflicht nicht auf, wenn sie genutzt wird.

Der Schlüssel ist Verhältnismäßigkeit. Ein kleines Fintech und eine große Bank werden nicht denselben Nachweisumfang erzeugen, aber beide benötigen nachvollziehbare Governance.

Lieferanten- und Cloud-Abhängigkeiten: Ihr Wallet-Ablauf ist nur so stark wie die Kette

Die meisten Umsetzungen vertrauender Parteien für die Wallet beinhalten externe Services: Cloud-Hosting, API-Gateways, Verifizierungsbibliotheken, Identitätsbroker, KYC-Anbieter, Betrugspräventionssysteme, Protokollierungsplattformen, Managed Detection and Response (MDR)-Anbieter oder Werkzeuge für den Kundensupport. Damit wird Lieferanten-Governance zentral.

NIS2 verpflichtet Einrichtungen, lieferantenspezifische Schwachstellen sowie die allgemeine Qualität und die Cybersicherheitspraktiken von Lieferanten und Dienstleistern zu berücksichtigen. DORA geht für Finanzunternehmen weiter und verlangt ein Register vertraglicher Vereinbarungen über IKT-Services, Bewertungen vor Vertragsabschluss, Analyse von Konzentrationsrisiken, gebotene Sorgfalt, Audit- und Inspektionsansätze, Kündigungsrechte und getestete Exit-Strategien für IKT-Services, die kritische oder wichtige Funktionen unterstützen.

In Zenith Blueprint, Phase „Controls in Action“, Schritt 23, weist Clarysec Teams an, eine vollständige Lieferantenliste zusammenzustellen, Anbieter nach Zugriff auf Systeme, Daten oder operative Kontrolle zu klassifizieren, Erwartungen in Verträge aufzunehmen, Unterauftragnehmer zu identifizieren, Auslöser für Änderungen zu definieren und einen Bewertungsprozess für Cloud-Services aufzubauen. Derselbe Schritt empfiehlt, Datenstandort, Zugriffsmodell, Protokollierung und Verschlüsselung zu bewerten, bevor künftige Cloud-Services genehmigt werden.

Die KMU-Lieferantenrichtlinie von Clarysec enthält eine klare Mindestzugriffsregel:

„Lieferanten darf nur Zugriff auf die minimal erforderlichen Systeme und Daten gewährt werden, die zur Erfüllung ihrer Funktion notwendig sind.“
Aus Richtlinie zur Lieferanten- und Drittparteiensicherheit – KMU, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.

NIST CSF 2.0 unterstützt diese integrierte Sicht. Die GOVERN-Funktion umfasst rechtliche, regulatorische, vertragliche und Datenschutzverpflichtungen, Risikobereitschaft, Rechenschaftspflicht, Richtlinien, Ressourcenbereitstellung und Aufsicht. Die Ergebnisse zur Lieferkette fordern Lieferantenrollen, Priorisierung nach Kritikalität, vertragliche Cybersicherheitsanforderungen, gebotene Sorgfalt, Überwachung, Vorfallsplanung und Regelungen für die Zeit nach Beendigung der Geschäftsbeziehung.

COBIT 2019-Auditoren werden auf Governance-Reife achten. Sie werden fragen, ob Lieferantenverantwortlichkeiten, Identitätslebenszyklus, Datenschutzkontrollen und Überwachung in Geschäftsprozesse eingebettet sind – nicht nur in Checklisten des Sicherheitsteams. Für Identität und logischen Zugriff ist COBIT 2019 DSS05.04, Benutzeridentität und logischen Zugriff verwalten, besonders relevant, wenn beurteilt wird, ob Kontenverantwortung, Genehmigungen, Berechtigungszuweisung und Entzug kontrolliert sind.

In einem Nachmittag ein Nachweispaket für vertrauende Parteien der Wallet erstellen

Eine praktische Übung im Clarysec-Stil beginnt mit einem konkreten Anwendungsfall, nicht mit einer allgemeinen Programmaussage. Nutzen Sie „Kunden-Onboarding mit von der Wallet bereitgestelltem rechtlichem Namen, Geburtsdatum und Adresse“ als ersten Datensatz. Ergänzen Sie Geschäftsverantwortlichen, Systemverantwortlichen, Dateneigentümer und Risikoverantwortlichen.

Erfassen Sie:

• Zweck der Verarbeitung;
• angeforderte Wallet-Attribute;
• ob Attribute gespeichert, zwischengespeichert oder nur verifiziert werden;
• beteiligte Systeme und APIs;
• Lieferanten und Unterauftragsverarbeiter;
• beteiligte Länder oder Cloud-Regionen;
• Rückfallprozess, wenn die Wallet-Verifizierung fehlschlägt;
• Berührungspunkte der Kundenkommunikation.

Fügen Sie den Anwendungsfall anschließend dem Compliance-Register hinzu.

Prüfen Sie anschließend die Erklärung zur Anwendbarkeit und den Risikobehandlungsplan. Für EUDI-Wallet-Anwendungsfälle sind die folgenden Kontrollbereiche nach ISO/IEC 27002:2022 häufig relevant.

Führen Sie abschließend ein Mini-Audit durch. Wählen Sie eine Wallet-Onboarding-Transaktion aus und verfolgen Sie:

1. die Begründung der Attributanforderung;
2. den Transparenzschritt oder die Einwilligungsaufzeichnung, sofern anwendbar;
3. das Systemereignisprotokoll;
4. den Nachweis der API-Authentifizierung;
5. die Zugriffskontrollaufzeichnung für Mitarbeitende, die das Onboarding-Ergebnis einsehen;
6. den beteiligten Lieferanten;
7. die Aufbewahrungsregel;
8. den Weg der Vorfallklassifizierung, falls diese Transaktion betrügerisch wäre oder offengelegt würde.

Wenn Sie die Reise nicht nachvollziehen können, ist der Prozess noch nicht nachweisbereit.

Wie unterschiedliche Auditoren denselben Wallet-Ablauf prüfen

Unterschiedliche Auditoren betrachten die EU Digital Identity Wallet aus unterschiedlichen fachlichen Perspektiven. Dieselben Nachweise können mehrere Fragen beantworten, wenn sie sauber strukturiert sind.

Zenith Controls liefert für diese Bereiche nützliche methodische Auditdetails. Beim Identitätsmanagement verfolgen Auditoren Benutzeridentitäten häufig über Onboarding, Änderung und Beendigung hinweg, gleichen HR-Aufzeichnungen mit Kontenlisten ab, prüfen Nicht-Mitarbeiter- und Servicekonten und suchen nach gemeinsamer Administratornutzung. Bei sicherer Authentifizierung vergleichen Auditoren Richtlinien mit technischen Konfigurationen, überprüfen MFA-Abdeckung, untersuchen Passwort- und Sitzungskontrollen und prüfen Protokolle erfolgreicher und fehlgeschlagener Anmeldungen. Bei Datenschutz und Schutz personenbezogener Daten ziehen Auditoren Stichproben aus DPIAs, Prozessen für Betroffenenanfragen, Datenschutzschulungen, Inventaren personenbezogener Daten, Verschlüsselung, Zugriffsprotokollen und Aufbewahrungskontrollen.

Clarysecs Richtlinie zur Audit- und Compliance-Überwachung erklärt das Nachweisziel klar:

„Belastbare Nachweise und einen Prüfpfad zur Unterstützung regulatorischer Anfragen, Gerichtsverfahren oder Kundenanfragen zur Vertrauensbildung erzeugen.“
Aus Richtlinie zur Audit- und Compliance-Überwachung, Abschnitt „Ziele“, Richtlinienklausel 3.4.

Dieser Ausdruck – belastbare Nachweise – ist der Unterschied zwischen einer Richtlinienbibliothek und einem auditbereiten Compliance-System.

Häufige Fallstricke in Wallet-Readiness-Projekten

Der erste Fallstrick ist die Erhebung zu vieler Daten. Wallets können die Beschaffung verifizierter Attribute erleichtern, doch GDPR verlangt das Gegenteil: Nur erfassen und aufbewahren, was erforderlich ist. Wenn das Produktteam vollständige Identitätsinformationen anfordert, obwohl nur eine Altersbestätigung erforderlich ist, ist das Datenschutz-Kontrolldesign bereits fehlerhaft.

Der zweite Fallstrick ist die Vernachlässigung nicht-menschlicher Identitäten. Wallet-Integrationen stützen sich häufig auf API-Clients, Zertifikate, Servicekonten, Automatisierungsskripte und Geheimnisse. Wenn diese Identitäten nicht verantwortet, rotiert, überwacht und außer Betrieb genommen werden, ist die Umgebung der vertrauenden Partei schwach, selbst wenn das Wallet-Ökosystem stark ist.

Der dritte Fallstrick ist, Lieferanten als Beschaffungsformalität zu behandeln. Unter NIS2 und DORA ist Lieferantensicherheit operativ. Sie benötigen gebotene Sorgfalt, Vertragsklauseln, Überwachung, Zusammenarbeit bei Vorfällen, Auditrechte und Exit-Pläne. Für DORA-regulierte Einrichtungen ist das IKT-Drittparteienregister ein zentraler Compliance-Nachweis.

Der vierte Fallstrick ist Protokollierung ohne Governance. Übermäßige Protokollierung kann Datenschutzrisiken erzeugen. Zu geringe Protokollierung zerstört die Untersuchungsfähigkeit. Definieren Sie Authentifizierungs-, Verifizierungs-, administrative und vorfallsrelevante Ereignisse, schützen Sie Protokolle vor Veränderung, beschränken Sie den Zugriff und richten Sie die Aufbewahrung an rechtlichen und geschäftlichen Anforderungen aus.

Der fünfte Fallstrick ist, Meldungen nicht zu üben. NIS2 sieht für erhebliche Vorfälle Meldeerwartungen von 24 Stunden, 72 Stunden und einem Monat vor. DORA verlangt Erst-, Zwischen- und Abschlussmeldungen für schwerwiegende IKT-bezogene Vorfälle. Wenn die Organisation einen walletbezogenen Vorfall zum ersten Mal während eines echten Ereignisses diesen Fristen zuordnet, ist die Governance gescheitert.

EUDI-Wallet-Einführung in auditbereite Nachweise überführen

Die EU Digital Identity Wallet wird Onboarding und digitales Vertrauen in Europa verändern. Für CISOs, DPOs, Compliance-Manager, Auditoren und Geschäftsverantwortliche besteht der richtige Schritt jedoch nicht darin, ein weiteres isoliertes Compliance-Programm aufzubauen. Der richtige Schritt besteht darin, die Wallet-Einführung in das ISMS einzubinden und über Datenschutz, Identität, Authentifizierung, Lieferanten, Protokollierung, Resilienz und Incident Response hinweg zuzuordnen.

Clarysec kann Sie dabei strukturiert unterstützen:

1. Nutzen Sie Zenith Blueprint, um die Wallet-Einführung in der Phase Risikomanagement zu verorten: Schritt 14 für regulatorische Querverweise, Schritt 19 für sichere Authentifizierung und Schritt 23 für die Umsetzung von Lieferanten-, Datenschutz- und rechtlichen Kontrollen.
2. Nutzen Sie Zenith Controls, um ISO/IEC 27002:2022-Kontrollen zu Identitätsmanagement, sicherer Authentifizierung und Datenschutz GDPR-, NIS2-, DORA-, NIST- und COBIT 2019-Nachweisen zuzuordnen.
3. Nutzen Sie Clarysec-Richtlinienvorlagen wie Richtlinie zur rechtlichen und regulatorischen Compliance, Richtlinie zu Datenschutz und Privatsphäre, Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen, Richtlinie zur Protokollierung und Überwachung, Richtlinie zur Lieferanten- und Drittparteiensicherheit – KMU und Richtlinie zur Audit- und Compliance-Überwachung, um Verpflichtungen in verantwortete und prüfbare Praktiken zu überführen.
4. Erstellen Sie ein Nachweispaket für vertrauende Parteien der Wallet vor dem Produktivstart – nicht erst nach der ersten Audit-Anfrage.

Wenn Ihre Organisation plant, sich 2026 auf die EU Digital Identity Wallet zu stützen, ist jetzt der richtige Zeitpunkt für eine Frage: Können wir mit belastbaren Nachweisen belegen, dass dieser Identitätsfluss sicher, rechtmäßig, resilient und gesteuert ist?

Die Antwort von Clarysec ist pragmatisch: zuordnen, verantworten, testen und die Nachweise bereithalten.