Bewijsmatrix voor naleving van de EU Digital Identity Wallet in 2026

Een fintech-productteam staat twee weken voor de lancering van onboarding op basis van de wallet. De nieuwe flow stelt EU-klanten in staat geselecteerde identiteitsattributen aan te tonen via de EU Digital Identity Wallet, in plaats van identiteitsdocumenten handmatig te uploaden. De CISO ziet de beveiligingswinst. De DPO ziet de belofte van gegevensminimalisatie. Het hoofd Compliance ziet minder afgebroken onboardingtrajecten en een betere klantervaring.

Dan stelt het auditcomité de vraag die de sfeer in de ruimte verandert:

“Als een toezichthouder, bankpartner, klantauditor of toezichthoudende autoriteit vraagt hoe deze walletintegratie wordt bestuurd, welk bewijsmateriaal tonen we dan?”

Dat is het echte vraagstuk voor 2026.

De EU Digital Identity Wallet, vaak afgekort tot EUDI Wallet, is niet zomaar een extra productfunctie. Voor gereguleerde digitale diensten, betalingsdienstverleners, ecosystemen voor vertrouwensdiensten, interfaces met de publieke sector en onboardingtrajecten met een hoog betrouwbaarheidsniveau wordt de wallet onderdeel van de identiteitswaarborgingsketen van de organisatie. Dit raakt persoonsgegevens, authenticatiegebeurtenissen, leveranciersafhankelijkheden, toegangsgovernance, logging, cryptografie, incidentmelding en bestuurlijke verantwoording.

De valkuil is om eIDAS2 en de EUDI Wallet te behandelen als een op zichzelf staande juridische implementatie. Het praktische antwoord is anders: breng walletadoptie door vertrouwende partijen onder in hetzelfde bewijssysteem dat wordt gebruikt voor ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 en COBIT 2019.

Daar is de aanpak van Clarysec het sterkst. We maken van elke nieuwe regelgeving geen nieuwe spreadsheet. We koppelen verplichtingen aan beleid, beheersmaatregelen, eigenaren, audittrails en herhaalbaar bewijsmateriaal.

Dit artikel laat zien hoe u die bewijsstructuur opbouwt met Clarysec’s Zenith Blueprint: een 30-stappenroadmap voor auditors, Zenith Controls: de gids voor frameworkoverstijgende compliance en Clarysec-beleidssjablonen voor privacy, identiteit, logging, leveranciersgovernance en naleving van wet- en regelgeving.

Het wallet-bewijsvraagstuk voor 2026 is groter dan eIDAS2

De meeste discussies over de EU Digital Identity Wallet gaan over vertrouwen, interoperabiliteit en gebruikerservaring. Die zijn belangrijk. Maar een CISO, compliancemanager, DPO of auditor heeft een operationelere vraag: welke beheersmaatregelen tonen aan dat identiteitsattributen uit de wallet veilig, rechtmatig en proportioneel worden gebruikt?

Een vertrouwende partij die walletasserties accepteert, moet kunnen beantwoorden:

• Welke walletattributen worden opgevraagd, en waarom?
• Welke rechtsgrondslag ondersteunt de verwerking?
• Zijn gebruikers, beheerders en serviceaccounts uniek identificeerbaar?
• Zijn walletverificatiediensten, identity brokers, API-gateways en cloudcomponenten opgenomen in het leveranciersregister?
• Worden authenticatie- en verificatiegebeurtenissen gelogd op een manier die onderzoek ondersteunt zonder onnodig persoonsgegevens te verzamelen?
• Is er een incidentproces als wallet-onboarding wordt misbruikt, niet beschikbaar is of wordt gecompromitteerd?
• Is de walletintegratie voor financiële entiteiten opgenomen in DORA ICT-risicobeheer, risico’s van derde partijen en incidentclassificatie?
• Heeft afhankelijkheid van de wallet voor NIS2-entiteiten gevolgen voor de levering van essentiële of belangrijke diensten, toegangsbeveiliging, bedrijfscontinuïteit of klantcommunicatie?

NIS2 is bijzonder relevant omdat het toepassingsgebied veel aanbieders van digitale infrastructuur, cloudservices, managed service providers, managed security service providers en trust service providers omvat. De richtlijn classificeert onder specifieke omstandigheden ook gekwalificeerde verleners van vertrouwensdiensten, DNS-providers, TLD-registers en diverse andere entiteiten als essentieel. In 2026 zullen veel organisaties niet langer vragen of de wet eraan komt. Zij zullen vragen van toezichthouders, klanten en interne auditors over de implementatie moeten beantwoorden.

Voor financiële diensten voegt DORA een extra laag toe. DORA is van toepassing vanaf 17 januari 2025 en introduceert een uniform kader voor ICT-risico’s, incidenten, testen en risico’s van derde partijen voor financiële entiteiten. NIS2 erkent DORA als sectorspecifieke rechtshandeling van de Unie voor veel overlappende cyberbeveiligingsverplichtingen in de financiële sector. In de praktijk betekent dit dat een onboardingfunctie op basis van de wallet bij een betalingsinstelling, aanbieder van cryptoactivadiensten, beleggingsonderneming of aanbieder van rekeninginformatiediensten moet worden onderbouwd met DORA-achtig bewijsmateriaal voor ICT-risicogovernance, ook als NIS2 nog steeds relevant is voor coördinatie en ecosysteemafhankelijkheden.

De verkeerde reactie is om één bewijsdossier voor eIDAS2, één voor GDPR, één voor NIS2, één voor DORA en één voor ISO-certificering te maken. De juiste reactie is om het ISMS als operationeel model voor bewijsmateriaal te gebruiken.

Gebruik ISO 27001 als ruggengraat voor bewijsmateriaal

ISO/IEC 27001:2022 is nuttig omdat de norm niet beperkt is tot een technologische checklist. De norm vereist dat organisaties context, belanghebbenden, wettelijke en contractuele verplichtingen, toepassingsgebied, interfaces, afhankelijkheden, verantwoordelijkheden van leiderschap, risicobeoordeling, risicobehandeling, de Verklaring van Toepasselijkheid en voortdurende verbetering definiëren.

Dat is van belang voor walletadoptie, omdat het risico niet alleen in een API-call zit. Het risico zit in het end-to-end bedrijfsproces.

Een implementatie van de wallet door een vertrouwende partij raakt:

• klantonboarding en accounttoegang;
• privacyverklaringen, RoPA-vermeldingen en registraties van rechtsgrondslagen;
• identiteitsvaststelling en authenticatiemodellen;
• leverancierscontracten en assurance;
• logging, monitoring en bewaring van bewijsmateriaal;
• incidentclassificatie en rapportage;
• gegevensbewaring, verwijdering en correctie;
• audit en compliancemonitoring;
• risicorapportage op bestuursniveau.

Clarysec’s enterprisebeleid voor naleving maakt dit operationele model expliciet:

“Alle wettelijke en regelgevende verplichtingen moeten binnen het Informatiebeveiligingsmanagementsysteem (ISMS) worden gekoppeld aan specifieke beleidslijnen, beheersmaatregelen en eigenaren.”
Uit Beleid inzake naleving van wet- en regelgeving, sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.2.1.

Voor mkb-organisaties wordt hetzelfde principe vertaald naar een praktisch complianceregister:

“Wanneer regelgeving op meerdere gebieden van toepassing is (bijv. GDPR is van toepassing op bewaring, beveiliging en privacy), moet dit duidelijk worden vastgelegd in het complianceregister en in opleidingsmaterialen.”
Uit Beleid inzake naleving van wet- en regelgeving - mkb, sectie “Governancevereisten”, beleidsclausule 5.2.2.

De organisatie moet niet vragen: “Welke afdeling is eigenaar van eIDAS2?” Zij moet vragen: “Welke ISMS-risico’s, beheersmaatregelen, beleidslijnen, eigenaren en bewijsregistraties worden geraakt door afhankelijkheid van de wallet?”

In Zenith Blueprint, de fase Risicomanagement, stap 14, staat:

“Voor elke regelgeving kunt u, indien van toepassing, een eenvoudige mappingtabel maken (bijvoorbeeld als bijlage bij een rapport) waarin de belangrijkste beveiligingsvereisten van de regelgeving en de bijbehorende beheersmaatregelen/beleidslijnen in uw ISMS zijn opgenomen. Dit is niet verplicht in ISO 27001, maar het is een nuttige interne oefening om te waarborgen dat niets tussen wal en schip valt. Het maakt ook indruk op auditors/beoordelaars omdat u beveiliging niet in een vacuüm beheert, maar de juridische context kent.”

Dat is de basis: bouw één mappingtabel die verplichtingen voor vertrouwende partijen bij walletgebruik koppelt aan GDPR, NIS2, DORA, ISO/IEC 27001:2022 Annex A-beheersmaatregelen, Clarysec-beleid en bewijsregistraties.

Een praktische bewijsmatrix voor vertrouwende partijen bij de EU Digital Identity Wallet

De EUDI Wallet wordt beheersbaar wanneer deze wordt behandeld als een gedefinieerd bedrijfsproces binnen het ISMS, met in kaart gebrachte gegevens, identiteiten, leveranciers, logboeken, incidenten en eigenaren.

Deze tabel is geen juridisch advies. Het is een beheers- en bewijsmodel waarmee CISO’s, complianceteams en auditors bewijsmateriaal kunnen structureren.

Identiteitsbeheer is waar auditors zullen beginnen

Voor een vertrouwende partij bij walletgebruik is identiteit de voor de hand liggende beheersfamilie. Maar identiteitsbeheer is niet hetzelfde als authenticatie. Identiteitsbeheer beantwoordt de vraag: “Wie bestaat er in het systeem en hoe wordt die identiteit bestuurd?” Authenticatie beantwoordt de vraag: “Hoe wordt de geclaimde identiteit op het moment van toegang geverifieerd?”

In Zenith Controls wordt ISO/IEC 27002:2022-beheersmaatregel 5.16, Identiteitsbeheer, behandeld als een preventieve beheersmaatregel ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid. Deze maatregel is direct verbonden met toegangsbeveiliging, authenticatie-informatie, toegangsrechten, leveranciersrelaties, compliancemonitoring en geprivilegieerde toegang. De frameworkoverstijgende mapping koppelt dit gebied aan GDPR-beveiliging en verantwoordingsplicht, NIS2-toegangsbeveiliging en beheer van bedrijfsmiddelen, DORA-identiteits- en toegangsgovernance, NIST SP 800-53 identifier management en COBIT 2019-governance voor de identiteitslevenscyclus.

Voor walletbewijsmateriaal moet de organisatie kunnen aantonen dat:

• klantidentiteiten en personeelsidentiteiten niet worden verward;
• beheerdersidentiteiten uniek en traceerbaar zijn;
• leveranciersidentiteiten met dezelfde discipline worden bestuurd als werknemersidentiteiten;
• niet-menselijke identiteiten, zoals API-clients en serviceaccounts, eigenaren hebben;
• identiteiten worden gedeprovisioneerd wanneer zij niet langer nodig zijn;
• uitzonderingen, break-glass-accounts en geprivilegieerde identiteiten worden beheerst.

Clarysec’s mkb-accountbeleid vat het principe helder samen:

“Elk account moet uniek zijn, traceerbaar zijn naar een specifieke persoon en gekoppeld zijn aan een zakelijke rol.”
Uit Beleid inzake beheer van gebruikersaccounts en privileges - mkb, sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.2.

Voor enterpriseomgevingen is de eis rond gedeelde accounts strenger:

“Alle gebruikersidentiteiten moeten aan een unieke identificator zijn gekoppeld. Het gebruik van gedeelde of generieke accounts is verboden, behalve voor goedgekeurde break-glass- of noodaccounts die aan strikte beheersmaatregelen zijn onderworpen.”
Uit Beleid inzake beheer van gebruikersaccounts en privileges, sectie “Governancevereisten”, beleidsclausule 5.3.

Ondersteunende normen versterken dezelfde bewijslogica. ISO/IEC 24760-1:2019 biedt concepten voor de identiteitslevenscyclus, zoals registratie, binding, gebruik en uitschrijving. ISO/IEC 29115:2013 ondersteunt risicogebaseerde identiteitswaarborging. ISO/IEC 27005:2024 behandelt zwaktes in identiteit en toegang als onderwerpen voor risicobehandeling. ISO/IEC 27018:2020 breidt verwachtingen voor identiteitsbeheer uit naar verwerking van PII in de publieke cloud. ISO/IEC 29100:2011 voegt de privacydimensie toe door identificeerbaarheid te koppelen aan de omgang met persoonsgegevens.

Voor adoptie van de EUDI Wallet is de auditvraag eenvoudig: kunt u elke geprivilegieerde handeling, configuratiewijziging, wijziging in de walletverificatie-integratie en toegangsgebeurtenis van leveranciers herleiden tot een unieke identiteit met een goedgekeurde rol?

Als het antwoord nee is, is het walletproject niet auditgereed.

Veilige authenticatie: vertrouwen in de wallet neemt uw beheersverplichtingen niet weg

Een veelvoorkomende misvatting is dat identiteitsvaststelling op basis van de wallet de authenticatieverplichtingen van de vertrouwende partij wegneemt. De wallet kan de zekerheid voor specifieke identiteitsattributen verbeteren, maar neemt uw plicht niet weg om systemen, sessies, API’s, beheerinterfaces en klanttrajecten te beveiligen.

In Zenith Blueprint, de fase Beheersmaatregelen in de praktijk, stap 19, stelt Clarysec:

“Authenticatie is de eerste en meest kritieke verdedigingslinie tussen een dreigingsactor en uw systemen, gegevens en diensten. Als authenticatie zwak is, kan al het andere — encryptie, monitoring, segmentatie — worden omzeild.”

Dezelfde stap legt uit dat moderne authenticatie risicogebaseerd moet zijn, sterker moet zijn voor doelen met een hogere waarde, en moet worden ondersteund door MFA, veilige opslag van inloggegevens, TLS, tokenbescherming, secretsmanagement, veilige sessieafhandeling en beoordeling van authenticatielogboeken.

In Zenith Controls wordt ISO/IEC 27002:2022-beheersmaatregel 8.5, Veilige authenticatie, gemapt als preventieve beheersmaatregel binnen de capability voor identiteits- en toegangsbeheer. Deze is gekoppeld aan identiteitsbeheer, authenticatie-informatie, geprivilegieerde toegang, beperking van informatietoegang, monitoringactiviteiten, incidentbeheer en privacybescherming van PII. De maatregel is ook gekoppeld aan GDPR-beveiliging en gegevensbescherming door ontwerp, NIS2-cyberbeveiligingsrisicobeheer en MFA of continue authenticatie waar passend, DORA ICT-risicogovernance, NIST SP 800-53 IA- en AC-families en COBIT 2019-governance voor logische toegang.

Voor een vertrouwende partij bij walletgebruik moet bewijsmateriaal voor veilige authenticatie omvatten:

• authenticatie en autorisatie van het walletverificatie-endpoint;
• MFA voor beheerders van walletconfiguratiepanelen;
• veilige API-authenticatie tussen onboardingdiensten;
• opslag in een secrets vault voor walletintegratiesleutels of certificaten;
• sessietime-outs en tokenbescherming waar passend;
• waarschuwingen bij mislukte authenticatie en bescherming tegen brute-force-aanvallen;
• afzonderlijke beheersmaatregelen voor klantlogin, medewerkerstoegang en machine-to-machine-toegang.

Clarysec’s loggingbeleid voor mkb-organisaties geeft een praktische bewijsvereiste:

“Authenticatielogboeken: geslaagde en mislukte aanmeldpogingen, sessieduur, MFA-gebruik”
Uit Beleid voor logging en monitoring - mkb, sectie “Governancevereisten”, beleidsclausule 5.4.2.

Voor enterpriseomgevingen staat auditbetrouwbaarheid centraal:

“Logbestanden moeten onveranderbaar zijn of onder versiebeheer staan, waarbij toegang uitsluitend wordt verleend aan geautoriseerd personeel.”
Uit Beleid voor logging en monitoring, sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.5.1.

Dit is de brug tussen identiteitswaarborging en incidentrespons. Als wallet-onboarding wordt aangevallen via credential stuffing, token replay, compromittering van beheerders of misbruik door leveranciers, worden authenticatielogboeken de bewijsroute.

GDPR: de belofte van de wallet is minimalisatie, maar u moet die aantonen

De EU Digital Identity Wallet kan privacyverhogende onboarding ondersteunen doordat een vertrouwende partij specifieke attributen kan opvragen in plaats van volledige identiteitsdocumenten te verzamelen. Maar GDPR-verantwoordingsplicht is niet gebaseerd op goede bedoelingen. Zij vereist aantoonbare naleving.

Attributen uit de wallet zijn persoonsgegevens wanneer zij betrekking hebben op een geïdentificeerde of identificeerbare persoon. Sommige use cases kunnen ook biometrie, gegevens voor identiteitsverificatie, sanctiescreening, frauderisico of andere gevoelige verwerkingscontexten raken.

De GDPR-beginselen vereisen rechtmatige, behoorlijke en transparante verwerking, specifieke doeleinden, gegevensminimalisatie, juistheid, opslagbeperking, integriteit en vertrouwelijkheid, plus verantwoordingsplicht. Een vertrouwende partij moet kunnen aantonen waarom elk walletattribuut wordt opgevraagd, hoe lang het wordt bewaard, wie er toegang toe heeft, hoe het wordt beschermd en hoe hergebruik wordt beheerst.

Clarysec’s enterpriseprivacybeleid stelt:

“Alleen gegevens die noodzakelijk zijn voor een specifiek, legitiem zakelijk doel mogen worden verzameld en verwerkt.”
Uit Beleid inzake gegevensbescherming en privacy, sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.2.1.

De mkb-versie is bewust beknopt:

“Alleen de minimaal noodzakelijke persoonsgegevens mogen worden verzameld en bewaard”
Uit Beleid inzake gegevensbescherming en privacy - mkb, sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.2.1.

In Zenith Controls wordt ISO/IEC 27002:2022-beheersmaatregel 5.34, Privacy en bescherming van PII, gekoppeld aan inventaris van bedrijfsmiddelen, datamasking, governance van cloudservices, informatieclassificatie, veilige overdracht, toegangsbeveiliging, identiteitsbeheer en beoordeling van projectwijzigingen. De maatregel sluit ook aan op ISO/IEC 27701:2021 voor privacybeheer, ISO/IEC 27018 voor verwerking van PII in de cloud en ISO/IEC 29100-privacybeginselen.

Voor walletadoptie moet het privacybewijspakket omvatten:

• gegevensstroomdiagram voor walletattributen;
• vermelding in het register van rechtsgronden;
• besluitregistratie voor attribuutminimalisatie;
• bewaarschema voor gegevens uit de wallet;
• actualisering van de privacyverklaring;
• DPIA of privacyrisicobeoordeling wanneer de use case een hoog risico inhoudt;
• toegangscontrolematrix voor walletgegevens;
• proces voor gegevensverwijdering en correctie;
• monitoringbewijsmateriaal waaruit blijkt dat toegang tot PII uit de wallet wordt beheerst.

Veel organisaties verzamelen te veel omdat de wallet het gemakkelijker maakt om geverifieerde gegevens te verkrijgen. Dat is de verkeerde richting. Het beveiligings- en privacyvoordeel ontstaat door minder op te vragen, niet door meer geverifieerde identiteitsgegevens op te slaan dan de organisatie nodig heeft.

NIS2 en DORA: bestuursverantwoordelijkheid ontmoet walletweerbaarheid

NIS2 en DORA brengen cyberbeveiliging beide naar het niveau van governance. Zij vereisen dat bestuursorganen risicomaatregelen goedkeuren, daarop toezien en daarvoor verantwoordelijk zijn. Zij verwachten ook proportionele technische, operationele en organisatorische beheersmaatregelen.

NIS2 Article 21 vereist risicobeheersmaatregelen voor beleid, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving en ontwikkeling, afhandeling van kwetsbaarheden, doeltreffendheid van beheersmaatregelen, cyberhygiëne, training, cryptografie, HR-beveiliging, toegangsbeveiliging, beheer van bedrijfsmiddelen en, waar passend, MFA of continue authenticatie. Voor vertrouwende partijen bij walletgebruik in NIS2-sectoren moet de walletintegratie zichtbaar zijn in de risicobeoordeling, inventaris van bedrijfsmiddelen, het leveranciersregister, het incidentplan en het toegangsbeveiligingskader.

NIS2 Article 23 voegt gefaseerde rapportage over significante incidenten toe. Essentiële en belangrijke entiteiten moeten binnen 24 uur een vroegtijdige waarschuwing, binnen 72 uur een melding en binnen één maand een eindrapport verstrekken, met communicatie naar ontvangers waar van toepassing. Als een storing in de walletintegratie operationele verstoring, financieel verlies of materiële of immateriële schade voor dienstontvangers kan veroorzaken, moet dit in de incidentclassificatielogica worden opgenomen.

DORA is specifieker voor financiële entiteiten. DORA vereist een intern governance- en beheerskader voor ICT-risico’s, een door het bestuur goedgekeurde weerbaarheidsstrategie, ICT-beleid, bedrijfscontinuïteits- en responsplannen, auditplannen, beleid voor derde partijen, meldkanalen voor incidenten en een gedocumenteerd ICT-risicobeheerkader. DORA vereist ook beheer van ICT-gerelateerde incidenten, classificatie aan de hand van criteria zoals getroffen cliënten, uitvaltijd, geografische spreiding, gegevensverlies, criticaliteit en economische impact, plus rapportage van majeure ICT-gerelateerde incidenten.

Voor onboarding op basis van de wallet in financiële diensten moet bewijsmateriaal aantonen dat:

• de walletintegratie is opgenomen in de ICT-asset- en procesinventaris;
• risico’s worden beoordeeld en door de juiste eigenaar worden geaccepteerd;
• criticaliteit wordt beoordeeld voor klantonboarding of accounttoegang;
• weerbaarheids- en fallback-opties bestaan;
• incidenten volgens DORA-criteria kunnen worden geclassificeerd;
• klantmeldingen zijn voorbereid wanneer financiële belangen worden geraakt;
• uitbestede rapportage, indien gebruikt, de verantwoordingsplicht niet wegneemt.

De sleutel is proportionaliteit. Een kleine fintech en een grote bank zullen niet hetzelfde volume aan bewijsmateriaal produceren, maar beide hebben traceerbare governance nodig.

Leveranciers- en cloudafhankelijkheden: uw walletflow is zo sterk als de keten

De meeste implementaties van walletgebruik door vertrouwende partijen omvatten externe diensten: cloudhosting, API-gateways, verificatiebibliotheken, identity brokers, KYC-leveranciers, fraude-engines, loggingplatforms, managed detection and response providers of tooling voor klantenondersteuning. Daardoor staat leveranciersgovernance centraal.

NIS2 vereist dat entiteiten rekening houden met leveranciersspecifieke kwetsbaarheden en de algehele kwaliteit en cyberbeveiligingspraktijken van leveranciers en dienstverleners. DORA gaat verder voor financiële entiteiten door een register van contractuele regelingen voor ICT-diensten, precontractuele beoordelingen, analyse van concentratierisico’s, due diligence, audit- en inspectiebenaderingen, beëindigingsrechten en geteste exitstrategieën te vereisen voor ICT-diensten die kritieke of belangrijke functies ondersteunen.

In Zenith Blueprint, de fase Beheersmaatregelen in de praktijk, stap 23, geeft Clarysec teams de instructie een volledige leverancierslijst op te stellen, aanbieders te classificeren op basis van toegang tot systemen, gegevens of operationele controle, verwachtingen in contracten op te nemen, subcontractanten te identificeren, wijzigingstriggers te definiëren en een evaluatieproces voor clouddiensten te bouwen. Dezelfde stap adviseert om gegevenslocatie, toegangsmodel, logging en encryptie te beoordelen voordat toekomstige clouddiensten worden goedgekeurd.

Clarysec’s mkb-leveranciersbeleid geeft een duidelijke regel voor minimale toegang:

“Leveranciers mogen uitsluitend toegang krijgen tot de minimale systemen en gegevens die nodig zijn om hun functie uit te voeren.”
Uit Beleid inzake beveiliging van derde partijen en leveranciers - mkb, sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.2.1.

NIST CSF 2.0 ondersteunt deze geïntegreerde benadering. De GOVERN-functie omvat wettelijke, regelgevende, contractuele en privacyverplichtingen, risicobereidheid, verantwoordingsplicht, beleid, resourcing en toezicht. De uitkomsten voor de toeleveringsketen vragen om leveranciersrollen, prioritering op basis van criticaliteit, contractuele cyberbeveiligingsvereisten, due diligence, monitoring, incidentplanning en bepalingen na beëindiging van de relatie.

COBIT 2019-auditors zullen kijken naar governancevolwassenheid. Zij zullen vragen of leveranciersverantwoordelijkheden, de identiteitslevenscyclus, privacybeheersmaatregelen en monitoring zijn ingebed in bedrijfsprocessen, en niet alleen in checklists van het beveiligingsteam. Voor identiteit en logische toegang is COBIT 2019 DSS05.04, Manage user identity and logical access, bijzonder relevant bij de beoordeling of accounteigenaarschap, goedkeuringen, toewijzing van privileges en verwijdering worden beheerst.

Bouw in één middag een bewijsdossier voor vertrouwende partijen bij walletgebruik

Een praktische oefening in Clarysec-stijl begint met één specifieke use case, niet met een brede programmaverklaring. Gebruik “klantonboarding met door de wallet verstrekte wettelijke naam, geboortedatum en adres” als eerste registratie. Voeg de bedrijfseigenaar, systeemeigenaar, gegevenseigenaar en risico-eigenaar toe.

Leg vast:

• doel van de verwerking;
• opgevraagde walletattributen;
• of attributen worden opgeslagen, gecachet of alleen geverifieerd;
• betrokken systemen en API’s;
• leveranciers en subverwerkers;
• betrokken landen of cloudregio’s;
• fallback-proces als walletverificatie faalt;
• contactmomenten in klantcommunicatie.

Voeg de use case vervolgens toe aan het complianceregister.

Beoordeel vervolgens de Verklaring van Toepasselijkheid en het risicobehandelingsplan. Voor EUDI Wallet-use cases zijn de volgende ISO/IEC 27002:2022-beheersgebieden vaak relevant.

Voer tot slot een mini-audit uit. Kies één wallet-onboardingtransactie en traceer:

1. de onderbouwing van het attribuutverzoek;
2. de transparantiestap of toestemmingsregistratie waar van toepassing;
3. het systeemgebeurtenislogboek;
4. het API-authenticatiebewijsmateriaal;
5. de toegangscontroleregistratie voor medewerkers die het onboardingresultaat bekijken;
6. de betrokken leverancier;
7. de bewaarregel;
8. de incidentclassificatieroute als die transactie frauduleus zou zijn of zou zijn blootgesteld.

Als u de keten niet kunt traceren, is het proces nog niet gereed als bewijsmateriaal.

Hoe verschillende auditors dezelfde walletflow zullen toetsen

Verschillende auditors benaderen de EU Digital Identity Wallet vanuit verschillende professionele invalshoeken. Hetzelfde bewijsmateriaal kan meerdere vragen beantwoorden als het goed is gestructureerd.

Zenith Controls biedt nuttige auditmethodologische details voor deze gebieden. Voor identiteitsbeheer traceren auditors doorgaans gebruikersidentiteiten via onboarding, wijziging en beëindiging, stemmen zij HR-registraties af op accountlijsten, inspecteren zij niet-werknemersaccounts en serviceaccounts, en zoeken zij naar gebruik van gedeelde beheerdersaccounts. Voor veilige authenticatie vergelijken auditors beleid met technische configuraties, beoordelen zij MFA-dekking, onderzoeken zij wachtwoord- en sessiebeheersmaatregelen en inspecteren zij geslaagde en mislukte aanmeldlogboeken. Voor privacy en bescherming van PII nemen auditors steekproeven van DPIA’s, processen voor verzoeken van betrokkenen, privacytraining, PII-inventarissen, encryptie, toegangslogboeken en beheersmaatregelen voor bewaring.

Clarysec’s Beleid voor audit en compliancemonitoring licht de bewijsdoelstelling helder toe:

“Het genereren van verdedigbaar bewijsmateriaal en een audittrail ter ondersteuning van verzoeken van toezichthouders, juridische procedures of assuranceverzoeken van klanten.”
Uit Beleid voor audit en compliancemonitoring, sectie “Doelstellingen”, beleidsclausule 3.4.

Die term, verdedigbaar bewijsmateriaal, is het verschil tussen een beleidsbibliotheek en een compliancesysteem dat auditgereed is.

Veelvoorkomende valkuilen in projecten voor walletgereedheid

De eerste valkuil is te veel gegevens verzamelen. Wallets kunnen het gemakkelijker maken om geverifieerde attributen te verkrijgen, maar GDPR stuurt juist op het tegenovergestelde gedrag: verzamel en bewaar alleen wat noodzakelijk is. Als het productteam volledige identiteitsinformatie opvraagt terwijl alleen leeftijdsbevestiging vereist is, is het ontwerp van de privacybeheersmaatregelen al gebrekkig.

De tweede valkuil is het negeren van niet-menselijke identiteiten. Walletintegraties steunen vaak op API-clients, certificaten, serviceaccounts, automatiseringsscripts en secrets. Als die identiteiten niet worden beheerd, geroteerd, gemonitord en buiten gebruik gesteld, is de omgeving van de vertrouwende partij zwak, ook als het walletecosysteem sterk is.

De derde valkuil is leveranciers behandelen als inkoopdocumentatie. Onder NIS2 en DORA is leveranciersbeveiliging operationeel. U hebt due diligence, contractuele clausules, monitoring, samenwerking bij incidenten, auditrechten en exitplannen nodig. Voor entiteiten die onder DORA vallen, is het ICT-register van derde partijen kernbewijsmateriaal voor naleving.

De vierde valkuil is logging zonder governance. Overmatig loggen kan privacyrisico’s creëren. Te weinig loggen vernietigt het onderzoeksvermogen. Definieer authenticatie-, verificatie-, beheer- en incidentrelevante gebeurtenissen, bescherm logboeken tegen wijziging, beperk toegang en stem bewaring af op wettelijke en zakelijke behoeften.

De vijfde valkuil is het niet oefenen van rapportage. NIS2 kent rapportageverwachtingen van 24 uur, 72 uur en één maand voor significante incidenten. DORA kent initiële, tussentijdse en eindrapportage voor majeure ICT-gerelateerde incidenten. Als de organisatie een walletgerelateerd incident pas tijdens een echt incident aan deze termijnen koppelt, heeft de governance gefaald.

Zet EUDI Wallet-adoptie om in auditgereed bewijsmateriaal

De EU Digital Identity Wallet zal onboarding en digitaal vertrouwen in Europa veranderen. Maar voor CISO’s, DPO’s, compliancemanagers, auditors en bedrijfseigenaren is de winnende zet niet het opzetten van nog een geïsoleerd nalevingsprogramma. De winnende zet is walletadoptie in het ISMS onderbrengen en deze mappen over privacy, identiteit, authenticatie, leveranciers, logging, weerbaarheid en incidentrespons.

Clarysec kan u helpen dit gestructureerd te doen:

1. Gebruik Zenith Blueprint om walletadoptie onder te brengen in de fase Risicomanagement, stap 14 voor regelgevende kruisverwijzingen, stap 19 voor veilige authenticatie en stap 23 voor de implementatie van leveranciers-, privacy- en juridische beheersmaatregelen.
2. Gebruik Zenith Controls om ISO/IEC 27002:2022-beheersmaatregelen voor identiteitsbeheer, veilige authenticatie en privacy te koppelen aan bewijsmateriaal voor GDPR, NIS2, DORA, NIST en COBIT 2019.
3. Gebruik Clarysec-beleidssjablonen zoals Beleid inzake naleving van wet- en regelgeving, Beleid inzake gegevensbescherming en privacy, Beleid inzake beheer van gebruikersaccounts en privileges, Beleid voor logging en monitoring, Beleid inzake beveiliging van derde partijen en leveranciers - mkb en Beleid voor audit en compliancemonitoring om verplichtingen om te zetten in toegewezen, toetsbare praktijken.
4. Bouw vóór de lancering een bewijsdossier voor de vertrouwende partij bij walletgebruik, niet pas na het eerste auditverzoek.

Als uw organisatie in 2026 van plan is te vertrouwen op de EU Digital Identity Wallet, is dit het moment om één vraag te stellen: kunnen wij met verdedigbaar bewijsmateriaal aantonen dat deze identiteitsflow veilig, rechtmatig, weerbaar en bestuurd is?

Het antwoord van Clarysec is praktisch: map het, wijs eigenaarschap toe, test het en houd het bewijsmateriaal gereed.