Karta över regelefterlevnad och bevismaterial för EU Digital Identity Wallet 2026

Ett produktteam inom fintech står två veckor från att lansera plånboksbaserad kundetablering. Det nya flödet ska låta EU-kunder styrka utvalda identitetsattribut via EU Digital Identity Wallet i stället för att manuellt ladda upp identitetshandlingar. Informationssäkerhetschefen ser säkerhetsvinsterna. Dataskyddsombudet uppskattar möjligheten till dataminimering. Chefen för regelefterlevnad ser färre avbrutna kundetableringsflöden och en smidigare kundupplevelse.

Sedan ställer revisionsutskottet frågan som förändrar allt:

”Om en tillsynsmyndighet, bankpartner, kundrevisor eller annan behörig myndighet frågar hur denna plånboksintegration styrs, vilket bevismaterial visar vi då?”

Det är den verkliga utmaningen inför 2026.

EU Digital Identity Wallet, ofta förkortad EUDI Wallet, är inte bara ännu en produktfunktion. För reglerade digitala tjänster, betalningsleverantörer, ekosystem för betrodda tjänster, gränssnitt mot offentlig sektor och kundetableringsflöden med hög tillitsnivå blir den en del av organisationens kedja för identitetsförsäkran. Den berör personuppgifter, autentiseringshändelser, leverantörsberoenden, åtkomststyrning, loggning, kryptografi, incidentrapportering och styrelsens ansvarsskyldighet.

Fällan är att behandla eIDAS2 och EUDI Wallet som ett fristående juridiskt införande. Den praktiska lösningen är en annan: införande hos förlitande parter ska integreras i samma bevissystem som används för ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 och COBIT 2019.

Det är här Clarysec:s metod är som starkast. Vi gör inte varje ny reglering till ännu ett kalkylblad. Vi mappar skyldigheter till policyer, kontroller, ägare, revisionsspår och återanvändbart underlag.

Den här artikeln visar hur ni bygger den bevismässiga ryggraden med Clarysec:s Zenith Blueprint: en revisors 30-stegs färdplan, Zenith Controls: vägledning för korsmappad regelefterlevnad och Clarysec:s policymallar för integritetsskydd, identitet, loggning, leverantörsstyrning och regulatorisk efterlevnad.

Bevisfrågan för plånböcker 2026 är större än eIDAS2

De flesta diskussioner om EU Digital Identity Wallet fokuserar på tillit, interoperabilitet och användarupplevelse. Det är viktigt. Men en informationssäkerhetschef, chef för regelefterlevnad, dataskyddsombud eller revisor har en mer operativ fråga: vilka kontroller visar att identitetsattribut från plånboken används säkert, lagenligt och proportionerligt?

En förlitande part som accepterar plånboksintyg bör kunna svara på följande:

• Vilka plånboksattribut begärs, och varför?
• Vilken rättslig grund stödjer behandlingen?
• Är användare, administratörer och tjänstekonton unikt identifierbara?
• Finns tjänster för plånboksverifiering, identitetsförmedlare, API-gateways och molnkomponenter i leverantörsregistret?
• Loggas autentiserings- och verifieringshändelser på ett sätt som stödjer utredning utan att för mycket personuppgifter samlas in?
• Finns en incidentprocess om plånboksbaserad kundetablering missbrukas, blir otillgänglig eller komprometteras?
• För finansiella entiteter: omfattas plånboksintegrationen av DORA:s IKT-riskhantering, tredjepartsrisk och incidentklassificering?
• För NIS2-entiteter: påverkar beroendet av plånboken leverans av väsentliga eller viktiga tjänster, åtkomstkontroll, verksamhetskontinuitet eller kundkommunikation?

NIS2 är särskilt relevant eftersom tillämpningsområdet omfattar många leverantörer av digital infrastruktur, molntjänster, hanterade tjänsteleverantörer, hanterade säkerhetstjänsteleverantörer och leverantörer av betrodda tjänster. Direktivet klassificerar också kvalificerade leverantörer av betrodda tjänster, DNS-leverantörer, TLD-register och flera andra aktörer som väsentliga under vissa omständigheter. År 2026 kommer många organisationer inte längre att fråga sig om lagen är på väg. De kommer att besvara frågor från tillsynsmyndigheter, kunder och internrevision om genomförandet.

För finansiella tjänster tillkommer DORA som ytterligare lager. DORA gäller från den 17 januari 2025 och etablerar ett enhetligt ramverk för IKT-risker, incidenter, testning och tredjepartsrisker för finansiella entiteter. NIS2 erkänner DORA som en sektorsspecifik unionsrättsakt för många överlappande cybersäkerhetsskyldigheter inom finanssektorn. I praktiken innebär det att en plånboksbaserad kundetableringsfunktion hos ett betalningsinstitut, en leverantör av kryptotillgångstjänster, ett värdepappersföretag eller en kontoinformationstjänstleverantör måste kunna beläggas genom DORA-liknande IKT-riskstyrning, även om NIS2 fortfarande är relevant för samordning och ekosystemberoenden.

Fel svar är att skapa ett bevispaket för eIDAS2, ett för GDPR, ett för NIS2, ett för DORA och ett för ISO-certifiering. Rätt svar är att använda ISMS som operativ modell för bevismaterial.

Använd ISO 27001 som bevismässig ryggrad

ISO/IEC 27001:2022 är användbar eftersom den inte är begränsad till en teknisk checklista. Den kräver att organisationer definierar kontext, intressenter, rättsliga och avtalsmässiga skyldigheter, omfattning, gränssnitt, beroenden, ledningens ansvar, riskbedömning, riskbehandling, tillämpbarhetsförklaring och ständig förbättring.

Det är avgörande för plånboksinförande eftersom risken inte bara ligger i ett API-anrop. Risken finns i hela verksamhetsprocessen från början till slut.

Ett införande hos en förlitande part påverkar:

• kundetablering och kontoåtkomst;
• integritetsmeddelanden, RoPA-poster och dokumentation av rättslig grund;
• identitetskontroll och autentiseringsmodeller;
• leverantörsavtal och säkerhetsförsäkran;
• loggning, övervakning och bevarande av bevismaterial;
• incidentklassificering och rapportering;
• databevarande, radering och rättelse;
• revision och övervakning av regelefterlevnad;
• riskrapportering på styrelsenivå.

Clarysec:s policy för regelefterlevnad i större organisationer gör denna operativa modell tydlig:

”Alla rättsliga och regulatoriska skyldigheter ska mappas till specifika policyer, kontroller och ägare inom ledningssystemet för informationssäkerhet.”
Från Policy för rättslig och regulatorisk efterlevnad, avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.1.

För små och medelstora företag skalas samma princip till ett praktiskt register över krav på regelefterlevnad:

”När en reglering gäller flera områden (t.ex. att GDPR gäller bevarande, säkerhet och integritetsskydd) ska detta tydligt mappas i registret över regelefterlevnadskrav och i utbildningsmaterial.”
Från Policy för rättslig och regulatorisk efterlevnad – små och medelstora företag, avsnittet ”Styrningskrav”, policyklausul 5.2.2.

Organisationen bör inte fråga: ”Vilken avdelning äger eIDAS2?” Den bör fråga: ”Vilka ISMS-risker, kontroller, policyer, ägare och bevisposter påverkas av beroendet av plånboken?”

I Zenith Blueprint, fasen Riskhantering, steg 14, anges följande:

”För varje reglering, om tillämpligt, kan ni skapa en enkel mappningstabell (till exempel som bilaga i en rapport) som listar regleringens viktigaste säkerhetskrav och motsvarande kontroller/policyer i ert ISMS. Detta är inte obligatoriskt enligt ISO 27001, men det är en användbar intern övning för att säkerställa att inget faller mellan stolarna. Det ger också ett gott intryck på revisorer och bedömare eftersom det visar att ni inte hanterar säkerhet i ett vakuum utan är medvetna om den rättsliga kontexten.”

Det är grunden: bygg en enda mappningstabell som kopplar skyldigheter för förlitande parter till GDPR, NIS2, DORA, ISO/IEC 27001:2022 bilaga A-kontroller, Clarysec-policyer och bevisposter.

En praktisk beviskarta för förlitande parter i EU Digital Identity Wallet

EUDI Wallet blir hanterbar när den behandlas som en definierad verksamhetsprocess i ISMS, med mappade data, identiteter, leverantörer, loggar, incidenter och ägare.

Tabellen är inte ett juridiskt utlåtande. Den är en kontroll- och bevismodell som informationssäkerhetschefer, regelefterlevnadsteam och revisorer kan använda för att strukturera underlag.

Identitetshantering är där revisorerna börjar

För en förlitande part är identitet den uppenbara kontrollfamiljen. Men identitetshantering är inte samma sak som autentisering. Identitetshantering besvarar frågan ”vem finns i systemet och hur styrs identiteten?” Autentisering besvarar frågan ”hur verifieras den påstådda identiteten vid åtkomsttillfället?”

I Zenith Controls behandlas ISO/IEC 27002:2022 kontroll 5.16, Identitetshantering, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Den knyter direkt till åtkomstkontroll, autentiseringsinformation, åtkomsträttigheter, leverantörsrelationer, uppföljning av efterlevnad och privilegierad åtkomst. Mappningen för korsmappad regelefterlevnad kopplar området till GDPR-säkerhet och ansvarsskyldighet, NIS2-åtkomstkontroll och tillgångshantering, DORA-styrning av identitet och åtkomst, NIST SP 800-53 identitetshantering och COBIT 2019-styrning av identitetslivscykeln.

För bevismaterial kopplat till plånboken ska organisationen kunna visa att:

• kundidentiteter och personalidentiteter inte blandas ihop;
• administrativa identiteter är unika och spårbara;
• leverantörsidentiteter styrs med samma disciplin som anställdas identiteter;
• icke-mänskliga identiteter, såsom API-klienter och tjänstekonton, har ägare;
• identiteter avprovisioneras när de inte längre behövs;
• undantag, break-glass-konton och privilegierade identiteter är kontrollerade.

Clarysec:s kontopolicy för små och medelstora företag fångar principen på ett tydligt sätt:

”Varje konto ska vara unikt, spårbart till en specifik person och kopplat till en verksamhetsroll.”
Från Policy för hantering av användarkonton och privilegier – små och medelstora företag, avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.2.

För större organisationer är kravet striktare när det gäller delade konton:

”Alla användaridentiteter ska vara kopplade till en unik identifierare. Användning av delade eller generiska konton är förbjuden, med undantag för godkända break-glass-konton eller nödkonton som omfattas av strikta kontroller.”
Från Policy för hantering av användarkonton och privilegier, avsnittet ”Styrningskrav”, policyklausul 5.3.

Stödjande standarder förstärker samma bevislogik. ISO/IEC 24760-1:2019 ger begrepp för identitetslivscykeln, såsom registrering, bindning, användning och avregistrering. ISO/IEC 29115:2013 stödjer riskbaserad identitetsförsäkran. ISO/IEC 27005:2024 behandlar svagheter inom identitet och åtkomst som riskbehandlingsområden. ISO/IEC 27018:2020 utökar förväntningarna på identitetshantering vid behandling av PII i publika molntjänster. ISO/IEC 29100:2011 lägger till integritetsperspektivet genom att koppla identifierbarhet till hantering av personuppgifter.

För införande av EUDI Wallet är revisionsfrågan enkel: kan ni spåra varje privilegierad åtgärd, konfigurationsändring, ändring av plånboksverifieringsintegration och leverantörsåtkomsthändelse till en unik identitet med en godkänd roll?

Om svaret är nej är plånboksprojektet inte redo för revision.

Säker autentisering: tillit till plånboken tar inte bort era kontrollskyldigheter

En vanlig missuppfattning är att plånboksbaserad identitetskontroll tar bort den förlitande partens autentiseringsskyldigheter. Den kan höja tillitsnivån för specifika identitetsattribut, men den tar inte bort skyldigheten att skydda system, sessioner, API:er, administrativa gränssnitt och kundresor.

I Zenith Blueprint, fasen Kontroller i praktiken, steg 19, anger Clarysec:

”Autentisering är den första och mest kritiska försvarslinjen mellan en hotaktör och era system, data och tjänster. Om autentiseringen är svag kan allt annat – kryptering, övervakning och segmentering – kringgås.”

Samma steg förklarar att modern autentisering ska vara riskbaserad, starkare för mål med högre värde och stödjas av MFA, säker lagring av autentiseringsuppgifter, TLS, tokenskydd, hemlighetshantering, säker sessionshantering och granskning av autentiseringsloggar.

I Zenith Controls mappas ISO/IEC 27002:2022 kontroll 8.5, Säker autentisering, som en förebyggande kontroll inom förmågan för identitets- och åtkomsthantering. Den kopplar till identitetshantering, autentiseringsinformation, privilegierad åtkomst, åtkomstbegränsning till information, övervakningsaktiviteter, incidenthantering och integritetsskydd för PII. Den korsmappas även till GDPR-säkerhet och inbyggt dataskydd, NIS2-riskhantering för cybersäkerhet och MFA eller kontinuerlig autentisering där det är lämpligt, DORA IKT-riskstyrning, NIST SP 800-53 IA- och AC-familjerna samt COBIT 2019-styrning av logisk åtkomst.

För en förlitande part bör bevismaterial för säker autentisering omfatta:

• autentisering och auktorisering av slutpunkter för plånboksverifiering;
• MFA för administratörer till konfigurationspaneler för plånboken;
• säker API-autentisering mellan kundetableringstjänster;
• nyckelvalv för integrationsnycklar eller certifikat för plånboken;
• tidsgränser för sessioner och tokenskydd där det är lämpligt;
• larm vid misslyckad autentisering och skydd mot brute force;
• separata kontroller för kundinloggning, medarbetaråtkomst och maskin-till-maskin-åtkomst.

Clarysec:s loggningspolicy för små och medelstora företag anger ett praktiskt beviskrav:

”Autentiseringsloggar: lyckade och misslyckade inloggningsförsök, sessionslängd, MFA-användning”
Från Loggnings- och övervakningspolicy – små och medelstora företag, avsnittet ”Styrningskrav”, policyklausul 5.4.2.

För större organisationer blir revisionsmässig tillförlitlighet central:

”Loggfiler ska vara oföränderliga eller versionshanteras, och åtkomst ska endast ges till behörig personal.”
Från Loggnings- och övervakningspolicy, avsnittet ”Krav för genomförande av policyn”, policyklausul 6.5.1.

Detta är bryggan mellan identitetsförsäkran och incidentrespons. Om plånboksbaserad kundetablering angrips genom credential stuffing, återspelningsattacker mot token, administrativ kompromettering eller leverantörsmissbruk blir autentiseringsloggarna revisionsspåret.

GDPR: plånbokens löfte är minimering, men ni måste kunna visa det

EU Digital Identity Wallet kan stödja integritetsförstärkande kundetablering eftersom en förlitande part kan begära specifika attribut i stället för att samla in fullständiga identitetshandlingar. Men ansvarsskyldighet enligt GDPR bygger inte på goda avsikter. Den kräver att efterlevnad kan visas.

Attribut från plånboken är personuppgifter när de avser en identifierad eller identifierbar person. Vissa användningsfall kan också beröra biometriska data, identitetsverifieringsdata, sanktionsscreening, bedrägeririsk eller andra känsliga behandlingssammanhang.

GDPR:s principer kräver laglig, korrekt och transparent behandling, specificerade ändamål, dataminimering, korrekthet, lagringsminimering, integritet och konfidentialitet samt ansvarsskyldighet. En förlitande part ska kunna visa varför varje plånboksattribut begärs, hur länge det bevaras, vem som kan få åtkomst till det, hur det skyddas och hur återanvändning kontrolleras.

Clarysec:s integritetspolicy för större organisationer anger:

”Endast data som är nödvändiga för ett specifikt, legitimt verksamhetsändamål får samlas in och behandlas.”
Från Policy för dataskydd och integritet, avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.1.

Versionen för små och medelstora företag är avsiktligt koncis:

”Endast de minsta nödvändiga personuppgifterna ska samlas in och bevaras”
Från Policy för dataskydd och integritet – små och medelstora företag, avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.1.

I Zenith Controls mappas ISO/IEC 27002:2022 kontroll 5.34, Integritetsskydd och skydd av PII, till tillgångsförteckning, datamaskering, styrning av molntjänster, informationsklassificering, säker överföring, åtkomstkontroll, identitetshantering och granskning av projektändringar. Den kopplas också till ISO/IEC 27701:2021 för integritetshantering, ISO/IEC 27018 för behandling av PII i molntjänster och ISO/IEC 29100:s integritetsprinciper.

För plånboksinförande bör integritetsunderlaget omfatta:

• dataflödesdiagram för plånboksattribut;
• post i registret över rättslig grund;
• beslutsunderlag för attributminimering;
• bevarandeschema för data från plånboken;
• uppdatering av integritetsmeddelande;
• DPIA eller integritetsriskbedömning där användningsfallet innebär hög risk;
• åtkomstkontrollmatris för plånboksdata;
• process för dataradering och rättelse;
• övervakningsunderlag som visar att åtkomst till PII från plånboken är kontrollerad.

Många organisationer samlar in för mycket eftersom plånboken gör verifierade data enklare att hämta. Det är fel riktning. Säkerhets- och integritetsvinsten kommer av att begära mindre, inte av att lagra mer verifierade identitetsdata än verksamheten behöver.

NIS2 och DORA: styrelseansvar möter plånbokens operativa motståndskraft

NIS2 och DORA för båda in cybersäkerhet i styrningen. De kräver att ledningsorgan godkänner, övervakar och ansvarar för riskåtgärder. De förväntar sig också proportionerliga tekniska, operativa och organisatoriska kontroller.

NIS2 Article 21 kräver riskhanteringsåtgärder som omfattar policyer, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och utveckling, sårbarhetshantering, kontrolleffektivitet, cyberhygien, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och, där det är lämpligt, MFA eller kontinuerlig autentisering. För förlitande parter inom NIS2-sektorer bör plånboksintegrationen ingå i riskbedömningen, tillgångsförteckningen, leverantörsregistret, incidentplanen och ramverket för åtkomstkontroll.

NIS2 Article 23 lägger till stegvis rapportering av betydande incidenter. Väsentliga och viktiga entiteter ska lämna en tidig varning inom 24 timmar, en anmälan inom 72 timmar och en slutrapport inom en månad, med kommunikation till mottagare där det är tillämpligt. Om ett fel i en plånboksintegration kan orsaka driftstörning, ekonomisk förlust eller materiell eller immateriell skada för tjänstemottagare bör det ingå i incidentklassificeringslogiken.

DORA är mer specifik för finansiella entiteter. DORA kräver ett internt styrnings- och kontrollramverk för IKT-risk, en styrelsegodkänd strategi för operativ motståndskraft, IKT-policyer, verksamhetskontinuitets- och responsplaner, revisionsplaner, tredjepartspolicyer, rapporteringskanaler för incidenter och ett dokumenterat ramverk för IKT-riskhantering. DORA kräver också hantering av IKT-relaterade incidenter, klassificering enligt kriterier som berörda kunder, avbrottstid, geografisk spridning, dataförlust, kritikalitet och ekonomisk påverkan samt rapportering av större IKT-relaterade incidenter.

För plånboksbaserad kundetablering inom finansiella tjänster bör bevismaterial visa att:

• plånboksintegrationen finns i IKT-tillgångs- och processförteckningen;
• risker bedöms och accepteras av rätt ägare;
• kritikalitet bedöms för kundetablering eller kontoåtkomst;
• alternativ för operativ motståndskraft och fallback finns;
• incidenter kan klassificeras enligt DORA-kriterier;
• kundaviseringar är planerade när kunders finansiella intressen påverkas;
• outsourcad rapportering, om den används, inte tar bort ansvarsskyldigheten.

Nyckeln är proportionalitet. Ett litet fintechbolag och en stor bank kommer inte att producera samma mängd bevismaterial, men båda behöver spårbar styrning.

Leverantörs- och molnberoenden: plånboksflödet är bara så starkt som kedjan

De flesta implementationer hos förlitande parter omfattar externa tjänster: molndrift, API-gateways, verifieringsbibliotek, identitetsförmedlare, KYC-leverantörer, bedrägerimotorer, loggningsplattformar, leverantörer av hanterad detektering och respons eller verktyg för kundsupport. Det gör leverantörsstyrning central.

NIS2 kräver att entiteter beaktar leverantörsspecifika sårbarheter och leverantörers och tjänsteleverantörers övergripande kvalitet och cybersäkerhetspraxis. DORA går längre för finansiella entiteter genom att kräva ett register över avtalsarrangemang för IKT-tjänster, bedömningar före avtal, analys av koncentrationsrisk, leverantörsgranskning, metoder för revision och inspektion, rätt att säga upp avtalet och testade exitstrategier för IKT-tjänster som stödjer kritiska eller viktiga funktioner.

I Zenith Blueprint, fasen Kontroller i praktiken, steg 23, instruerar Clarysec team att sammanställa en fullständig leverantörslista, klassificera leverantörer efter åtkomst till system, data eller operativ kontroll, skriva in förväntningar i avtal, identifiera underleverantörer, definiera ändringsutlösare och bygga en process för utvärdering av molntjänster. Samma steg rekommenderar att datalagringsplats, åtkomstmodell, loggning och kryptering utvärderas innan framtida molntjänster godkänns.

Clarysec:s leverantörspolicy för små och medelstora företag anger en tydlig regel om minsta åtkomst:

”Leverantörer ska endast ges åtkomst till de minsta system och data som krävs för att utföra sin funktion.”
Från Policy för leverantörssäkerhet och tredjepartssäkerhet – små och medelstora företag, avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.1.

NIST CSF 2.0 stödjer detta integrerade perspektiv. Funktionen GOVERN omfattar rättsliga, regulatoriska, avtalsmässiga och integritetsrelaterade skyldigheter, riskaptit, ansvarsskyldighet, policy, resurssättning och tillsyn. Dess resultat för leveranskedjan kräver leverantörsroller, prioritering efter kritikalitet, avtalsmässiga cybersäkerhetskrav, leverantörsgranskning, övervakning, incidentplanering och bestämmelser efter avslutad relation.

COBIT 2019-revisorer kommer att leta efter styrningsmognad. De kommer att fråga om leverantörsansvar, identitetslivscykel, dataskyddskontroller och övervakning är inbyggda i verksamhetsprocesser, inte bara i checklistor hos säkerhetsteamet. För identitet och logisk åtkomst är COBIT 2019 DSS05.04, Manage user identity and logical access, särskilt relevant vid bedömning av om kontoägarskap, godkännanden, privilegietilldelning och borttagning är kontrollerade.

Bygg ett bevispaket för förlitande part på en eftermiddag

En praktisk övning i Clarysec-stil börjar med ett specifikt användningsfall, inte med ett brett programuttalande. Använd ”kundetablering med juridiskt namn, födelsedatum och adress från plånboken” som första post. Lägg till verksamhetsägare, systemägare, dataägare och riskägare.

Registrera:

• ändamål med behandlingen;
• begärda plånboksattribut;
• om attribut lagras, cachas eller endast verifieras;
• berörda system och API:er;
• leverantörer och underbiträden;
• berörda länder eller molnregioner;
• fallback-process om plånboksverifiering misslyckas;
• kontaktpunkter för kundkommunikation.

Lägg därefter till användningsfallet i registret över regelefterlevnadskrav.

Granska därefter tillämpbarhetsförklaringen och riskbehandlingsplanen. För EUDI Wallet-användningsfall är följande kontrollområden i ISO/IEC 27002:2022 ofta relevanta.

Genomför slutligen en minirevision. Välj en plånboksbaserad kundetableringstransaktion och spåra:

1. motiveringen till attributbegäran;
2. transparenssteget eller samtyckesregistreringen där det är tillämpligt;
3. systemets händelselogg;
4. underlaget för API-autentisering;
5. åtkomstkontrollposten för personal som granskar kundetableringsresultatet;
6. berörd leverantör;
7. bevaranderegeln;
8. incidentklassificeringsvägen om transaktionen skulle vara bedräglig eller exponerad.

Om ni inte kan spåra resan är processen ännu inte bevisredo.

Hur olika revisorer testar samma plånboksflöde

Olika revisorer närmar sig EU Digital Identity Wallet genom olika professionella perspektiv. Samma bevismaterial kan besvara flera frågor om det är välstrukturerat.

Zenith Controls ger användbar detaljering av revisionsmetodik för dessa områden. För identitetshantering spårar revisorer ofta användaridentiteter genom introduktion, ändring och avslut, stämmer av HR-poster mot kontolistor, granskar icke-anställda och tjänstekonton samt söker efter delad administratörsanvändning. För säker autentisering jämför revisorer policyer med tekniska konfigurationer, granskar MFA-täckning, undersöker lösenords- och sessionskontroller samt granskar loggar över lyckade och misslyckade inloggningar. För integritetsskydd och skydd av PII tar revisorer stickprov på DPIA:er, processer för registrerades begäranden, integritetsutbildning, PII-förteckningar, kryptering, åtkomstloggar och bevarandekontroller.

Clarysec:s Policy för revision och övervakning av regelefterlevnad förklarar bevismålet tydligt:

”Att generera försvarbart bevismaterial och ett revisionsspår till stöd för regulatoriska förfrågningar, rättsprocesser eller förfrågningar om säkerhetsförsäkran från kunder.”
Från Policy för revision och övervakning av regelefterlevnad, avsnittet ”Mål”, policyklausul 3.4.

Begreppet försvarbart bevismaterial är skillnaden mellan ett policybibliotek och ett revisionsklart efterlevnadssystem.

Vanliga fallgropar i projekt för plånboksberedskap

Den första fallgropen är att samla in för mycket data. Plånböcker kan göra verifierade attribut enklare att få tillgång till, men GDPR driver motsatt beteende: samla in och bevara endast det som är nödvändigt. Om produktteamet begär fullständig identitetsinformation när endast åldersbekräftelse krävs är utformningen av integritetskontrollen redan bristfällig.

Den andra fallgropen är att ignorera icke-mänskliga identiteter. Plånboksintegrationer bygger ofta på API-klienter, certifikat, tjänstekonton, automatiseringsskript och hemligheter. Om dessa identiteter inte ägs, roteras, övervakas och avvecklas är den förlitande partens miljö svag även om plånboksekosystemet är starkt.

Den tredje fallgropen är att behandla leverantörer som upphandlingsdokumentation. Enligt NIS2 och DORA är leverantörssäkerhet operativ. Ni behöver leverantörsgranskning, avtalsklausuler, övervakning, incidentsamverkan, revisionsrätt och exitplaner. För DORA-reglerade entiteter är IKT-tredjepartsregistret centralt underlag för regelefterlevnad.

Den fjärde fallgropen är loggning utan styrning. För mycket loggning kan skapa integritetsrisk. För lite loggning förstör utredningsförmågan. Definiera autentiserings-, verifierings-, administrativa och incidentrelevanta händelser, skydda loggar från ändring, begränsa åtkomst och anpassa bevarande till rättsliga och verksamhetsmässiga behov.

Den femte fallgropen är att inte öva rapportering. NIS2 har rapporteringsförväntningar på 24 timmar, 72 timmar och en månad för betydande incidenter. DORA har initial, mellanliggande och slutlig rapportering för större IKT-relaterade incidenter. Om första gången organisationen mappar en plånboksrelaterad incident mot dessa tidslinjer är under en faktisk händelse har styrningen fallerat.

Gör införandet av EUDI Wallet till revisionsklart bevismaterial

EU Digital Identity Wallet kommer att förändra kundetablering och digital tillit i Europa. Men för informationssäkerhetschefer, dataskyddsombud, chefer för regelefterlevnad, revisorer och verksamhetsägare är rätt väg inte att skapa ännu ett isolerat efterlevnadsprogram. Rätt väg är att föra in plånboksinförandet i ISMS och mappa det över integritetsskydd, identitet, autentisering, leverantörer, loggning, operativ motståndskraft och incidentrespons.

Clarysec kan hjälpa er att göra det strukturerat:

1. Använd Zenith Blueprint för att placera plånboksinförandet i fasen Riskhantering, steg 14 för regulatoriska korsreferenser, steg 19 för säker autentisering och steg 23 för genomförande av leverantörs-, integritets- och rättsliga kontroller.
2. Använd Zenith Controls för att mappa ISO/IEC 27002:2022-kontroller för identitetshantering, säker autentisering och integritetsskydd till bevismaterial för GDPR, NIS2, DORA, NIST och COBIT 2019.
3. Använd Clarysec:s policymallar, såsom Policy för rättslig och regulatorisk efterlevnad, Policy för dataskydd och integritet, Policy för hantering av användarkonton och privilegier, Loggnings- och övervakningspolicy, Policy för leverantörssäkerhet och tredjepartssäkerhet – små och medelstora företag och Policy för revision och övervakning av regelefterlevnad för att omvandla skyldigheter till ägda, testbara arbetssätt.
4. Bygg ett bevispaket för förlitande part innan lansering, inte efter den första revisionsförfrågan.

Om er organisation planerar att förlita sig på EU Digital Identity Wallet under 2026 är det dags att ställa en fråga: kan vi visa, med försvarbart bevismaterial, att detta identitetsflöde är säkert, lagenligt, motståndskraftigt och styrt?

Clarysec:s svar är praktiskt: mappa det, äg det, testa det och håll bevismaterialet redo.