Evidenskort for efterlevelse af EU Digital Identity Wallet i 2026

Et fintech-produktteam er to uger fra at lancere walletbaseret onboarding. Det nye flow gør det muligt for EU-kunder at dokumentere udvalgte identitetsattributter via EU Digital Identity Wallet i stedet for manuelt at uploade identitetsdokumenter. CISO’en ser sikkerhedsgevinsten. Databeskyttelsesrådgiveren ser potentialet for dataminimering. Den efterlevelsesansvarlige ser færre afbrudte onboarding-forløb og en bedre kundeoplevelse.

Så stiller revisionsudvalget spørgsmålet, der ændrer stemningen i lokalet:

“Hvis en regulator, bankpartner, kunderevisor eller tilsynsmyndighed spørger, hvordan denne wallet-integration styres, hvilken evidens viser vi så?”

Det er det egentlige problem i 2026.

EU Digital Identity Wallet, ofte forkortet EUDI Wallet, er ikke blot endnu en produktfunktion. For regulerede digitale tjenester, betalingsudbydere, økosystemer for tillidstjenester, grænseflader til den offentlige sektor og onboarding-forløb med høje sikringskrav bliver den en del af organisationens kæde for identitetssikring. Den berører personoplysninger, autentifikationshændelser, leverandørafhængigheder, adgangsgovernance, logning, kryptografi, hændelsesrapportering og ledelsesansvar.

Faldgruben er at behandle eIDAS2 og EUDI Wallet som en isoleret juridisk implementering. Den praktiske løsning er en anden: Bring modtagende parters anvendelse af walleten ind i det samme evidenssystem, der bruges til ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 og COBIT 2019.

Her er Clarysec-tilgangen stærkest. Vi gør ikke hver ny regulering til endnu et regneark. Vi kortlægger forpligtelser til politikker, kontroller, ejere, revisionsspor og gentageligt revisionsbevis.

Denne artikel viser, hvordan du opbygger denne evidensrygrad ved hjælp af Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap, Zenith Controls: The Cross-Compliance Guide og Clarysec-politikskabeloner for databeskyttelse, identitet, logning, leverandørstyring og efterlevelse af lovgivning.

Wallet-evidensproblemet i 2026 er større end eIDAS2

De fleste diskussioner om EU Digital Identity Wallet fokuserer på tillid, interoperabilitet og brugeroplevelse. Det er vigtigt. Men en CISO, efterlevelsesansvarlig, databeskyttelsesrådgiver eller revisor har et mere driftsnært spørgsmål: Hvilke kontroller dokumenterer, at identitetsattributter afledt af walleten bruges sikkert, lovligt og proportionalt?

En modtagende part, der accepterer wallet-erklæringer, skal kunne svare på:

• Hvilke wallet-attributter anmodes der om, og hvorfor?
• Hvilket behandlingsgrundlag understøtter behandlingen?
• Er brugere, administratorer og servicekonti entydigt identificerbare?
• Er wallet-verifikationstjenester, identitetsbrokere, API-gateways og cloudkomponenter registreret i leverandørregisteret?
• Logges autentifikations- og verifikationshændelser på en måde, der understøtter undersøgelser uden at overindsamle personoplysninger?
• Findes der en hændelsesproces, hvis wallet-onboarding misbruges, er utilgængelig eller kompromitteres?
• For finansielle enheder: Er wallet-integrationen omfattet af DORA-styring af IKT-risiko, tredjepartsrisiko og hændelsesklassificering?
• For NIS2-enheder: Påvirker afhængigheden af walleten levering af væsentlige eller vigtige tjenester, adgangsstyring, forretningskontinuitet eller kundekommunikation?

NIS2 er særligt relevant, fordi direktivets anvendelsesområde omfatter mange udbydere af digital infrastruktur, cloudtjenester, administrerede tjenester, administrerede sikkerhedstjenester og tillidstjenester. Direktivet klassificerer også kvalificerede tillidstjenesteudbydere, DNS-udbydere, TLD-registre og flere andre enheder som væsentlige under bestemte omstændigheder. I 2026 vil mange organisationer ikke længere spørge, om lovgivningen kommer. De skal besvare spørgsmål fra tilsynsmyndigheder, kunder og intern revision om implementering.

For finansielle tjenester tilføjer DORA endnu et lag. Den finder anvendelse fra 17. januar 2025 og etablerer en ensartet ramme for IKT-risiko, hændelser, test og tredjepartsrisiko for finansielle enheder. NIS2 anerkender DORA som en sektorspecifik EU-retsakt for mange overlappende cybersikkerhedsforpligtelser i finanssektoren. I praksis betyder det, at en walletbaseret onboarding-funktion hos et betalingsinstitut, en udbyder af kryptoaktivtjenester, et investeringsselskab eller en kontooplysningstjenesteudbyder skal dokumenteres gennem DORA-lignende IKT-risikostyring, selv om NIS2 fortsat er relevant for koordinering og afhængigheder i økosystemet.

Den forkerte reaktion er at oprette én evidenspakke for eIDAS2, én for GDPR, én for NIS2, én for DORA og én for ISO-certificering. Den rigtige reaktion er at bruge ISMS’et som den driftsmodel, der styrer evidensen.

Brug ISO 27001 som evidensrygrad

ISO/IEC 27001:2022 er nyttig, fordi den ikke er begrænset til en teknologisk tjekliste. Standarden kræver, at organisationer definerer kontekst, interessenter, retlige og kontraktlige forpligtelser, omfang, grænseflader, afhængigheder, ledelsesansvar, risikovurdering, risikobehandling, anvendelighedserklæring og løbende forbedring.

Det er vigtigt ved wallet-adoption, fordi risikoen ikke kun ligger i et API-kald. Risikoen ligger i den samlede forretningsproces fra ende til ende.

En implementering for en modtagende wallet-part påvirker:

• kundeonboarding og kontoadgang;
• privatlivsmeddelelser, RoPA-registreringer og registreringer af behandlingsgrundlag;
• identitetskontrol og autentifikationsmodeller;
• leverandørkontrakter og assurance;
• logning, overvågning og opbevaring af evidens;
• hændelsesklassificering og rapportering;
• dataopbevaring, sletning og berigtigelse;
• revision og overvågning af efterlevelse;
• risikorapportering på bestyrelsesniveau.

Clarysec-virksomhedspolitikken for efterlevelse gør denne driftsmodel eksplicit:

“Alle retlige og regulatoriske forpligtelser skal kortlægges til specifikke politikker, kontroller og ejere i ledelsessystemet for informationssikkerhed (ISMS).”
Fra Politik for juridisk og regulatorisk efterlevelse, afsnittet “Krav til implementering af politikken”, politikklausul 6.2.1.

For SMV’er skaleres samme princip til et praktisk efterlevelsesregister:

“Hvor en regulering gælder på tværs af flere områder (f.eks. GDPR gælder for opbevaring, sikkerhed og databeskyttelse), skal dette kortlægges tydeligt i efterlevelsesregisteret og træningsmaterialet.”
Fra Politik for juridisk og regulatorisk efterlevelse - SME, afsnittet “Governancekrav”, politikklausul 5.2.2.

Organisationen bør ikke spørge: “Hvilken afdeling ejer eIDAS2?” Den bør spørge: “Hvilke ISMS-risici, kontroller, politikker, ejere og evidensregistreringer påvirkes af afhængigheden af walleten?”

I Zenith Blueprint fremgår det i risikostyringsfasen, trin 14:

“For hver regulering kan du, hvis relevant, oprette en simpel kortlægningstabel (eventuelt som et bilag i en rapport), der viser reguleringens centrale sikkerhedskrav og de tilsvarende kontroller/politikker i dit ISMS. Dette er ikke obligatorisk i ISO 27001, men det er en nyttig intern øvelse for at sikre, at intet falder mellem to stole. Det viser også revisorer/vurderingsparter, at I ikke styrer sikkerhed i et vakuum, men er opmærksomme på den juridiske kontekst.”

Det er fundamentet: Byg én samlet kortlægningstabel, der forbinder forpligtelser for modtagende wallet-parter med GDPR, NIS2, DORA, ISO/IEC 27001:2022 Annex A-kontroller, Clarysec-politikker og evidensregistreringer.

En praktisk evidensoversigt for modtagende parter i EU Digital Identity Wallet

EUDI Wallet bliver håndterbar, når den behandles som en defineret forretningsproces i ISMS’et med kortlagte data, identiteter, leverandører, logfiler, hændelser og ejere.

Denne tabel er ikke en juridisk vurdering. Den er en kontrol- og evidensmodel, som CISO’er, efterlevelsesfunktioner og revisorer kan bruge til at strukturere revisionsbevis.

Identitetsstyring er dér, revisorer vil starte

For en modtagende wallet-part er identitet den oplagte kontrolfamilie. Men identitetsstyring er ikke det samme som autentifikation. Identitetsstyring besvarer spørgsmålet “hvem findes i systemet, og hvordan styres denne identitet?” Autentifikation besvarer spørgsmålet “hvordan verificeres den påståede identitet på adgangstidspunktet?”

I Zenith Controls behandles ISO/IEC 27002:2022-kontrol 5.16, Identitetsstyring, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Den hænger direkte sammen med adgangsstyring, autentifikationsoplysninger, adgangsrettigheder, leverandørrelationer, overvågning af efterlevelse og privilegeret adgang. Cross-compliance-kortlægningen forbinder dette område med GDPR-sikkerhed og ansvarlighed, NIS2-adgangsstyring og styring af aktiver, DORA-identitets- og adgangsgovernance, NIST SP 800-53 identifier management og COBIT 2019-governance for identitetslivscyklus.

For wallet-evidens skal organisationen kunne dokumentere, at:

• kundeidentiteter og medarbejderidentiteter ikke sammenblandes;
• administrative identiteter er unikke og sporbare;
• leverandøridentiteter styres med samme disciplin som medarbejderidentiteter;
• ikke-menneskelige identiteter, f.eks. API-klienter og servicekonti, har ejere;
• identiteter deprovisioneres, når de ikke længere er nødvendige;
• undtagelser, break-glass-konti og privilegerede identiteter kontrolleres.

Clarysec SMV-kontopolitikken beskriver princippet klart:

“Hver konto skal være unik, sporbar til en bestemt person og knyttet til en forretningsrolle.”
Fra Politik for styring af brugerkonti og privilegier - SME, afsnittet “Krav til implementering af politikken”, politikklausul 6.1.2.

For virksomheder er kravet strengere for delte konti:

“Alle brugeridentiteter skal være knyttet til en unik identifikator. Brug af delte eller generiske konti er forbudt, undtagen godkendte break-glass- eller nødkonti, der er underlagt strenge kontroller.”
Fra Politik for styring af brugerkonti og privilegier, afsnittet “Governancekrav”, politikklausul 5.3.

Understøttende standarder forstærker samme evidenslogik. ISO/IEC 24760-1:2019 beskriver koncepter for identitetslivscyklus, såsom registrering, binding, brug og afregistrering. ISO/IEC 29115:2013 understøtter risikobaseret identitetssikring. ISO/IEC 27005:2024 behandler svagheder i identitet og adgang som emner i risikobehandling. ISO/IEC 27018:2020 udvider forventningerne til identitetsstyring ved behandling af PII i public cloud. ISO/IEC 29100:2011 tilføjer databeskyttelsesvinklen ved at knytte identificerbarhed til håndtering af personoplysninger.

Ved adoption af EUDI Wallet er revisionsspørgsmålet enkelt: Kan I spore hver privilegeret handling, konfigurationsændring, ændring i wallet-verifikationsintegration og leverandøradgangshændelse til en unik identitet med en godkendt rolle?

Hvis svaret er nej, er wallet-projektet ikke revisionsklart.

Sikker autentifikation: tillid til walleten fjerner ikke jeres kontrolansvar

En udbredt misforståelse er, at walletbaseret identitetskontrol fjerner den modtagende parts autentifikationsforpligtelser. Den kan forbedre sikringen for bestemte identitetsattributter, men den fjerner ikke pligten til at sikre systemer, sessioner, API’er, administrative grænseflader og kunderejser.

I Zenith Blueprint, fasen Controls in Action, trin 19, skriver Clarysec:

“Autentifikation er den første og mest kritiske forsvarslinje mellem en trusselsaktør og jeres systemer, data og tjenester. Hvis autentifikation er svag, kan alt andet — kryptering, overvågning, segmentering — omgås.”

Samme trin forklarer, at moderne autentifikation skal være risikobaseret, stærkere for mål med højere værdi og understøttet af MFA, sikker opbevaring af legitimationsoplysninger, TLS, tokenbeskyttelse, håndtering af hemmeligheder, sikker sessionshåndtering og gennemgang af autentifikationslogfiler.

I Zenith Controls kortlægges ISO/IEC 27002:2022-kontrol 8.5, Sikker autentifikation, som en forebyggende kontrol i kapabiliteten for identitets- og adgangsstyring. Den knytter sig til identitetsstyring, autentifikationsoplysninger, privilegeret adgang, begrænsning af informationsadgang, overvågningsaktiviteter, hændelsesstyring og beskyttelse af PII. Den krydskortlægges også til GDPR-sikkerhed og databeskyttelse gennem design, NIS2-cybersikkerhedsrisikostyring og MFA eller løbende autentifikation, hvor relevant, DORA IKT-risikostyring, NIST SP 800-53 IA- og AC-familierne samt COBIT 2019-governance for logisk adgang.

For en modtagende wallet-part skal evidens for sikker autentifikation omfatte:

• autentifikation og autorisation for wallet-verifikationsendpoints;
• administrator-MFA for wallet-konfigurationspaneler;
• sikker API-autentifikation mellem onboarding-tjenester;
• opbevaring af wallet-integrationsnøgler eller certifikater i nøglebokse;
• sessionstimeout og tokenbeskyttelse, hvor relevant;
• alarmer ved mislykket autentifikation og beskyttelse mod brute-force;
• særskilte kontroller for kundelogin, medarbejderadgang og maskine-til-maskine-adgang.

Clarysec-logningspolitikken for SMV’er angiver et praktisk evidenskrav:

“Autentifikationslogfiler: vellykkede og mislykkede loginforsøg, sessionsvarighed, MFA-brug”
Fra Lognings- og overvågningspolitik - SME, afsnittet “Governancekrav”, politikklausul 5.4.2.

For virksomhedsmiljøer bliver revisionspålidelighed central:

“Logfiler skal være immutable eller versionsstyrede, med adgang kun for autoriseret personale.”
Fra Lognings- og overvågningspolitik, afsnittet “Krav til implementering af politikken”, politikklausul 6.5.1.

Dette er broen mellem identitetssikring og hændelseshåndtering. Hvis wallet-onboarding angribes gennem credential stuffing, token replay, administrativ kompromittering eller leverandørmisbrug, bliver autentifikationslogfilerne evidenssporet.

GDPR: walletens løfte er minimering, men I skal kunne dokumentere det

EU Digital Identity Wallet kan understøtte privatlivsfremmende onboarding, fordi en modtagende part kan anmode om specifikke attributter i stedet for at indsamle fulde identitetsdokumenter. Men GDPR-ansvarlighed bygger ikke på gode intentioner. Den kræver dokumenterbar efterlevelse.

Wallet-afledte attributter er personoplysninger, når de vedrører en identificeret eller identificerbar person. Nogle anvendelsesscenarier kan også berøre biometriske data, identitetsverifikationsdata, sanktionsscreening, svigrisiko eller andre følsomme behandlingskontekster.

GDPR-principperne kræver lovlig, rimelig og gennemsigtig behandling, specificerede formål, dataminimering, korrekthed, opbevaringsbegrænsning, integritet og fortrolighed samt ansvarlighed. En modtagende part skal kunne dokumentere, hvorfor hver wallet-attribut anmodes om, hvor længe den opbevares, hvem der har adgang, hvordan den beskyttes, og hvordan genbrug kontrolleres.

Clarysec-virksomhedspolitikken for databeskyttelse fastslår:

“Kun data, der er nødvendige for et specifikt, legitimt forretningsformål, må indsamles og behandles.”
Fra Databeskyttelses- og privatlivspolitik, afsnittet “Krav til implementering af politikken”, politikklausul 6.2.1.

SMV-versionen er bevidst kortfattet:

“Kun de minimale nødvendige personoplysninger skal indsamles og opbevares”
Fra Databeskyttelses- og privatlivspolitik - SME, afsnittet “Krav til implementering af politikken”, politikklausul 6.2.1.

I Zenith Controls kortlægges ISO/IEC 27002:2022-kontrol 5.34, Databeskyttelse og beskyttelse af PII, til aktivfortegnelse, datamaskering, governance for cloudtjenester, informationsklassificering, sikker overførsel, adgangsstyring, identitetsstyring og gennemgang af projektændringer. Den forbindes også med ISO/IEC 27701:2021 for privacy management, ISO/IEC 27018 for behandling af PII i cloud og ISO/IEC 29100’s privatlivsprincipper.

For wallet-adoption skal evidenspakken for databeskyttelse omfatte:

• dataflowdiagram for wallet-attributter;
• registrering i registeret over behandlingsgrundlag;
• beslutningsregistrering om attributminimering;
• opbevaringsplan for wallet-afledte data;
• opdatering af privatlivsmeddelelse;
• DPIA eller risikovurdering vedrørende databeskyttelse, hvor anvendelsesscenariet er højrisiko;
• adgangskontrolmatrix for wallet-data;
• proces for sletning og berigtigelse af data;
• overvågningsevidens, der viser, at adgang til wallet-afledte PII kontrolleres.

Mange organisationer overindsamler, fordi walleten gør verificerede data lettere at indhente. Det er den forkerte vej. Sikkerheds- og privatlivsgevinsten opstår ved at anmode om mindre, ikke ved at lagre flere verificerede identitetsdata, end forretningen har brug for.

NIS2 og DORA: ledelsesansvar møder wallet-robusthed

NIS2 og DORA flytter begge cybersikkerhed ind i governance. De kræver, at ledelsesorganer godkender, fører tilsyn med og er ansvarlige for risikoforanstaltninger. De forventer også proportionale tekniske, driftsmæssige og organisatoriske kontroller.

NIS2 Article 21 kræver risikostyringsforanstaltninger, der dækker politikker, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse og udvikling, håndtering af sårbarheder, kontroleffektivitet, cyberhygiejne, træning, kryptografi, HR-sikkerhed, adgangsstyring, styring af aktiver og, hvor relevant, MFA eller løbende autentifikation. For modtagende wallet-parter i NIS2-sektorer skal wallet-integrationen fremgå af risikovurderingen, aktivfortegnelsen, leverandørregisteret, hændelsesplanen og adgangskontrolrammen.

NIS2 Article 23 tilføjer trinvis rapportering af væsentlige hændelser. Væsentlige og vigtige enheder skal give en tidlig advarsel inden for 24 timer, en underretning inden for 72 timer og en endelig rapport inden for én måned samt kommunikere med modtagere, hvor relevant. Hvis en fejl i wallet-integrationen kan medføre driftsafbrydelse, økonomisk tab eller væsentlig materiel eller immateriel skade for tjenestemodtagere, skal den indgå i hændelsesklassificeringen.

DORA er mere specifik for finansielle enheder. Den kræver et internt governance- og kontrolrammeværk for IKT-risiko, en ledelsesgodkendt robusthedsstrategi, IKT-politikker, planer for forretningskontinuitet og respons, revisionsplaner, tredjepartspolitikker, kanaler for hændelsesrapportering og et dokumenteret rammeværk for IKT-risikostyring. Den kræver også styring af IKT-relaterede hændelser, klassificering ud fra kriterier som berørte kunder, nedetid, geografisk udbredelse, datatab, kritikalitet og økonomisk påvirkning samt rapportering af større IKT-relaterede hændelser.

For walletbaseret onboarding i finansielle tjenester skal evidensen vise, at:

• wallet-integrationen indgår i IKT-aktiv- og procesfortegnelsen;
• risici er vurderet og accepteret af den rette ejer;
• kritikalitet er vurderet for kundeonboarding eller kontoadgang;
• der findes robustheds- og fallback-ordninger;
• hændelser kan klassificeres efter DORA-kriterier;
• kundeunderretninger er planlagt, hvor finansielle interesser påvirkes;
• outsourcet rapportering, hvis anvendt, ikke fjerner ansvarlighed.

Nøglen er proportionalitet. En mindre fintech og en stor bank vil ikke producere samme evidensmængde, men begge har brug for sporbar governance.

Leverandør- og cloudafhængigheder: jeres wallet-flow er kun så stærkt som kæden

De fleste implementeringer for modtagende wallet-parter involverer eksterne tjenester: cloudhosting, API-gateways, verifikationsbiblioteker, identitetsbrokere, KYC-leverandører, svigmotorer, logningsplatforme, managed detection and response-udbydere eller kundesupportværktøjer. Det gør leverandørstyring central.

NIS2 kræver, at enheder tager højde for leverandørspecifikke sårbarheder og leverandørers og tjenesteudbyderes samlede kvalitet og cybersikkerhedspraksis. DORA går længere for finansielle enheder ved at kræve et register over kontraktlige aftaler om IKT-tjenester, vurderinger før kontraktindgåelse, analyse af koncentrationsrisiko, due diligence, revisions- og inspektionstilgange, opsigelsesrettigheder og testede exitstrategier for IKT-tjenester, der understøtter kritiske eller vigtige funktioner.

I Zenith Blueprint, fasen Controls in Action, trin 23, instruerer Clarysec teams i at udarbejde en fuldstændig leverandørliste, klassificere udbydere efter adgang til systemer, data eller operationel kontrol, indarbejde forventninger i kontrakter, identificere underleverandører, definere ændringsudløsere og opbygge en proces for vurdering af cloudtjenester. Samme trin anbefaler, at datalokation, adgangsmodel, logning og kryptering vurderes, før fremtidige cloudtjenester godkendes.

Clarysec SMV-leverandørpolitikken giver en klar regel om mindst mulig adgang:

“Leverandører må kun tildeles adgang til de minimale systemer og data, der er nødvendige for at udføre deres funktion.”
Fra Politik for tredjeparts- og leverandørsikkerhed - SME, afsnittet “Krav til implementering af politikken”, politikklausul 6.2.1.

NIST CSF 2.0 understøtter dette integrerede syn. GOVERN-funktionen omfatter retlige, regulatoriske, kontraktlige og privatlivsrelaterede forpligtelser, risikovillighed, ansvarlighed, politik, ressourcer og tilsyn. Dens resultater for forsyningskæden kræver leverandørroller, prioritering efter kritikalitet, kontraktlige cybersikkerhedskrav, due diligence, overvågning, hændelsesplanlægning og bestemmelser efter relationens ophør.

COBIT 2019-revisorer vil se efter governance-modenhed. De vil spørge, om leverandøransvar, identitetslivscyklus, databeskyttelseskontroller og overvågning er indlejret i forretningsprocesser og ikke kun i sikkerhedsteamets tjeklister. For identitet og logisk adgang er COBIT 2019 DSS05.04, Manage user identity and logical access, særligt relevant ved vurdering af, om kontoejerskab, godkendelser, tildeling af rettigheder og fjernelse er kontrolleret.

Byg en evidenspakke for modtagende wallet-parter på én eftermiddag

En praktisk Clarysec-lignende øvelse starter med ét konkret anvendelsesscenarie, ikke en bred programerklæring. Brug “kundeonboarding med juridisk navn, fødselsdato og adresse leveret via wallet” som den første registrering. Tilføj forretningsejer, systemejer, dataejer og risikoejer.

Registrér:

• behandlingsformål;
• ønskede wallet-attributter;
• om attributter gemmes, caches eller kun verificeres;
• involverede systemer og API’er;
• leverandører og underdatabehandlere;
• involverede lande eller cloudregioner;
• fallback-proces, hvis wallet-verifikation fejler;
• kontaktpunkter i kundekommunikationen.

Tilføj derefter anvendelsesscenariet til efterlevelsesregisteret.

Gennemgå derefter anvendelighedserklæringen og risikobehandlingsplanen. For EUDI Wallet-anvendelsesscenarier er følgende ISO/IEC 27002:2022-kontrolområder ofte relevante.

Til sidst gennemføres en mini-revision. Vælg én wallet-onboardingtransaktion, og spor:

1. begrundelsen for attributanmodningen;
2. transparenstrinnet eller samtykkeregistreringen, hvor relevant;
3. systemets hændelseslog;
4. evidens for API-autentifikation;
5. adgangskontrolregistreringen for medarbejdere, der ser onboarding-resultatet;
6. den involverede leverandør;
7. opbevaringsreglen;
8. hændelsesklassificeringsruten, hvis transaktionen var svigagtig eller eksponeret.

Hvis I ikke kan spore forløbet, er processen endnu ikke klar til evidenskrav.

Hvordan forskellige revisorer vil teste det samme wallet-flow

Forskellige revisorer tilgår EU Digital Identity Wallet gennem forskellige faglige linser. Den samme evidens kan besvare flere spørgsmål, hvis den er struktureret rigtigt.

Zenith Controls giver nyttige detaljer om revisionsmetodik for disse områder. For identitetsstyring sporer revisorer typisk brugeridentiteter gennem onboarding, ændring og fratrædelse, afstemmer HR-registreringer med kontolister, inspicerer ikke-medarbejderkonti og servicekonti og ser efter brug af delte administratorkonti. For sikker autentifikation sammenholder revisorer politikker med tekniske konfigurationer, gennemgår MFA-dækning, undersøger adgangskode- og sessionskontroller og inspicerer logfiler for vellykkede og mislykkede loginforsøg. For databeskyttelse og beskyttelse af PII udtager revisorer stikprøver af DPIA’er, processer for anmodninger fra registrerede, privatlivstræning, PII-fortegnelser, kryptering, adgangslogfiler og opbevaringskontroller.

Clarysec Politik for revision og overvågning af efterlevelse forklarer evidensmålet klart:

“At generere juridisk forsvarligt bevismateriale og et revisionsspor til støtte for regulatoriske forespørgsler, retssager eller anmodninger fra kunder om dokumentation.”
Fra Politik for revision og overvågning af efterlevelse, afsnittet “Mål”, politikklausul 3.4.

Udtrykket juridisk forsvarligt bevismateriale er forskellen mellem et politikbibliotek og et efterlevelsessystem, der er revisionsklart.

Almindelige faldgruber i wallet-readiness-projekter

Den første faldgrube er at indsamle for mange data. Wallets kan gøre verificerede attributter lettere at indhente, men GDPR presser adfærden i den modsatte retning: Indsaml og opbevar kun det nødvendige. Hvis produktteamet anmoder om fulde identitetsoplysninger, når kun aldersbekræftelse er nødvendig, er databeskyttelseskontroldesignet allerede mangelfuldt.

Den anden faldgrube er at ignorere ikke-menneskelige identiteter. Wallet-integrationer er ofte afhængige af API-klienter, certifikater, servicekonti, automatiseringsscripts og hemmeligheder. Hvis disse identiteter ikke har ejere, ikke roteres, ikke overvåges og ikke udfases, er den modtagende parts miljø svagt, selv om wallet-økosystemet er stærkt.

Den tredje faldgrube er at behandle leverandører som indkøbspapirarbejde. Under NIS2 og DORA er leverandørsikkerhed operationel. I har brug for due diligence, kontraktklausuler, overvågning, samarbejde om hændelser, revisionsrettigheder og exitplaner. For DORA-regulerede enheder er IKT-tredjepartsregisteret centralt revisionsbevis.

Den fjerde faldgrube er logning uden governance. Overlogning kan skabe privatlivsrisiko. Underlogning ødelægger evnen til at undersøge hændelser. Definér autentifikations-, verifikations-, administrative og hændelsesrelevante begivenheder, beskyt logfiler mod ændring, begræns adgang, og tilpas opbevaring til retlige og forretningsmæssige behov.

Den femte faldgrube er ikke at øve rapportering. NIS2 har forventninger om rapportering inden for 24 timer, 72 timer og én måned ved væsentlige hændelser. DORA har indledende, mellemliggende og endelig rapportering for større IKT-relaterede hændelser. Hvis første gang organisationen kortlægger en wallet-relateret hændelse til disse tidsfrister er under en faktisk hændelse, har governance svigtet.

Gør EUDI Wallet-adoption til revisionsklar evidens

EU Digital Identity Wallet vil ændre onboarding og digital tillid i hele Europa. Men for CISO’er, databeskyttelsesrådgivere, efterlevelsesansvarlige, revisorer og forretningsejere er den rigtige tilgang ikke at oprette endnu et isoleret efterlevelsesprogram. Den rigtige tilgang er at bringe wallet-adoption ind i ISMS’et og kortlægge den på tværs af databeskyttelse, identitet, autentifikation, leverandører, logning, robusthed og hændelseshåndtering.

Clarysec kan hjælpe jer med at gøre det struktureret:

1. Brug Zenith Blueprint til at placere wallet-adoption i risikostyringsfasen, trin 14 for regulatoriske krydshenvisninger, trin 19 for sikker autentifikation og trin 23 for implementering af leverandør-, databeskyttelses- og juridiske kontroller.
2. Brug Zenith Controls til at kortlægge ISO/IEC 27002:2022-identitetsstyring, sikker autentifikation og databeskyttelseskontroller til GDPR-, NIS2-, DORA-, NIST- og COBIT 2019-evidens.
3. Brug Clarysec-politikskabeloner såsom Politik for juridisk og regulatorisk efterlevelse, Databeskyttelses- og privatlivspolitik, Politik for styring af brugerkonti og privilegier, Lognings- og overvågningspolitik, Politik for tredjeparts- og leverandørsikkerhed - SME og Politik for revision og overvågning af efterlevelse til at omsætte forpligtelser til ejede, testbare praksisser.
4. Byg en evidenspakke for modtagende wallet-parter før lancering, ikke efter den første revisionsanmodning.

Hvis jeres organisation planlægger at basere sig på EU Digital Identity Wallet i 2026, er det nu, I skal stille ét spørgsmål: Kan vi med juridisk forsvarligt bevismateriale dokumentere, at dette identitetsflow er sikkert, lovligt, robust og styret?

Clarysec-svaret er praktisk: Kortlæg det, tildel ejerskab, test det, og hold evidensen klar.