EU:n digitaalisen identiteettilompakon vaatimustenmukaisuuden näyttökartta 2026

Fintech-tuotetiimi on kahden viikon päässä lompakkopohjaisen asiakkaaksi ottamisen käyttöönotosta. Uusi prosessi antaa EU-asiakkaille mahdollisuuden todistaa valitut identiteettiattribuutit EU:n digitaalisen identiteettilompakon avulla sen sijaan, että he lataisivat henkilöllisyysasiakirjoja manuaalisesti. Tietoturvajohtaja näkee ratkaisun tietoturvahyödyt. Tietosuojavastaava pitää tietojen minimoinnin mahdollisuudesta. Vaatimustenmukaisuudesta vastaava johtaja näkee vähemmän keskeytyneitä asiakkaaksi ottamisen polkuja ja selkeämmän asiakaskokemuksen.

Sitten auditointikomitea esittää kysymyksen, joka muuttaa keskustelun suunnan:

”Jos viranomainen, pankkikumppani, asiakkaan auditoija tai valvontaviranomainen kysyy, miten tätä lompakkointegraatiota hallitaan, mitä näyttöä esitämme?”

Tämä on vuoden 2026 todellinen ongelma.

EU:n digitaalinen identiteettilompakko, josta käytetään usein lyhennettä EUDI Wallet, ei ole vain uusi tuoteominaisuus. Sääntelyn alaisissa digitaalisissa palveluissa, maksupalveluntarjoajilla, luottamuspalveluekosysteemeissä, julkisen sektorin rajapinnoissa ja korkean varmuustason asiakkaaksi ottamisen poluissa siitä tulee osa organisaation identiteettivarmuuden ketjua. Se koskettaa henkilötietoja, todentamistapahtumia, toimittajariippuvuuksia, käyttöoikeuksien hallintaa, lokitusta, kryptografiaa, poikkeamien ilmoittamista ja hallituksen vastuuvelvollisuutta.

Ansana on käsitellä eIDAS2:ta ja EUDI Walletia erillisenä lakisääteisenä toteutuksena. Käytännön vastaus on toinen: lompakon luottavan osapuolen käyttöönotto tulee tuoda samaan näyttöjärjestelmään, jota käytetään ISO/IEC 27001:2022-, GDPR-, NIS2-, DORA-, NIST CSF 2.0- ja COBIT 2019 -vaatimusten hallintaan.

Tässä Clarysecin lähestymistapa on vahvimmillaan. Emme muuta jokaista uutta säädöstä uudeksi laskentataulukoksi. Kartoitamme velvoitteet politiikkoihin, kontrolleihin, omistajiin, auditointijälkiin ja toistettavaan näyttöön.

Tässä artikkelissa kuvataan, miten tällainen näyttörunko rakennetaan Clarysecin Zenith Blueprint: auditoijan 30-vaiheinen tiekartta- ja Zenith Controls: vaatimustenmukaisuuksien välinen opas -materiaalien sekä Clarysecin tietosuojaa, identiteettiä, lokitusta, toimittajahallintaa ja sääntelyvaatimusten noudattamista koskevien politiikkamallien avulla.

Vuoden 2026 lompakkonäytön ongelma on laajempi kuin eIDAS2

Useimmat EU:n digitaalista identiteettilompakkoa koskevat keskustelut keskittyvät luottamukseen, yhteentoimivuuteen ja käyttäjäkokemukseen. Ne ovat tärkeitä. Tietoturvajohtajalla, vaatimustenmukaisuuspäälliköllä, tietosuojavastaavalla tai auditoijalla on kuitenkin operatiivisempi kysymys: mitkä kontrollit osoittavat, että lompakosta johdettuja identiteettiattribuutteja käytetään turvallisesti, lainmukaisesti ja oikeasuhtaisesti?

Luottavan osapuolen, joka hyväksyy lompakon väittämiä, tulee pystyä vastaamaan seuraaviin kysymyksiin:

• Mitä lompakon attribuutteja pyydetään ja miksi?
• Mikä oikeusperuste tukee käsittelyä?
• Ovatko käyttäjät, ylläpitäjät ja palvelutilit yksilöllisesti tunnistettavissa?
• Ovatko lompakon varmennepalvelut, identiteettivälittäjät, API-yhdyskäytävät ja pilvikomponentit toimittajarekisterissä?
• Lokitetaanko todennus- ja varmentamistapahtumat tavalla, joka tukee tutkintaa ilman henkilötietojen liiallista keräämistä?
• Onko olemassa poikkeamaprosessi, jos lompakkopohjaista asiakkaaksi ottamista väärinkäytetään, se ei ole saatavilla tai se vaarantuu?
• Kattaako DORA:n mukainen ICT-riskien hallinta, kolmansien osapuolten riski ja poikkeamien luokittelu lompakkointegraation finanssialan toimijoissa?
• Vaikuttaako lompakkoon tukeutuminen NIS2-toimijoilla keskeisen tai tärkeän palvelun tuottamiseen, pääsynhallintaan, liiketoiminnan jatkuvuuteen tai asiakasviestintään?

NIS2 on erityisen olennainen, koska sen soveltamisalaan kuuluu monia digitaalisen infrastruktuurin tarjoajia, pilvipalveluja, hallinnoituja palveluntarjoajia (MSP), hallinnoituja tietoturvapalveluntarjoajia ja luottamuspalveluntarjoajia. Direktiivi luokittelee myös hyväksytyt luottamuspalveluntarjoajat, DNS-palveluntarjoajat, TLD-rekisterit ja useita muita toimijoita tietyissä olosuhteissa keskeisiksi. Vuoteen 2026 mennessä monet organisaatiot eivät enää kysy, onko laki tulossa. Ne vastaavat valvonnan, asiakkaiden ja sisäisen tarkastuksen kysymyksiin toteutuksesta.

Finanssipalveluissa DORA lisää uuden kerroksen. Sitä sovelletaan 17. tammikuuta 2025 alkaen, ja se luo finanssialan toimijoille yhdenmukaisen ICT-riskien, poikkeamien, testauksen ja kolmansien osapuolten riskienhallinnan viitekehyksen. NIS2 tunnistaa DORA:n alakohtaiseksi unionin säädökseksi monien päällekkäisten finanssisektorin kyberturvallisuusvelvoitteiden osalta. Käytännössä tämä tarkoittaa, että maksulaitoksen, kryptovarapalveluntarjoajan, sijoituspalveluyrityksen tai tilitietopalveluntarjoajan lompakkopohjaisesta asiakkaaksi ottamisen toiminnosta on esitettävä näyttö DORA-tyyppisen ICT-riskienhallinnan kautta, vaikka NIS2 olisi edelleen merkityksellinen koordinoinnin ja ekosysteemiriippuvuuksien kannalta.

Virheellinen vastaus on luoda yksi näyttöpaketti eIDAS2:lle, yksi GDPR:lle, yksi NIS2:lle, yksi DORA:lle ja yksi ISO-sertifioinnille. Oikea vastaus on käyttää ISMS:ää näytön operatiivisena mallina.

Käytä ISO 27001:tä näyttörunkona

ISO/IEC 27001:2022 on hyödyllinen, koska se ei rajoitu teknologiseen tarkistuslistaan. Se edellyttää, että organisaatiot määrittävät toimintaympäristön, sidosryhmät, lakisääteiset ja sopimusperusteiset velvoitteet, soveltamisalan, rajapinnat, riippuvuudet, johdon vastuut, riskien arvioinnin, riskien käsittelyn, soveltuvuuslausunnon ja jatkuvan parantamisen.

Tämä on olennaista lompakon käyttöönotossa, koska riski ei ole vain API-kutsussa. Riski on koko päästä päähän -liiketoimintaprosessissa.

Lompakon luottavan osapuolen toteutus vaikuttaa seuraaviin osa-alueisiin:

• asiakkaaksi ottaminen ja tilinkäyttö;
• tietosuojailmoitukset, RoPA-merkinnät ja oikeusperustetallenteet;
• henkilöllisyyden varmistamisen ja todennuksen mallit;
• toimittajasopimukset ja varmentaminen;
• lokitus, valvonta ja näytön säilyttäminen;
• poikkeamien luokittelu ja raportointi;
• tietojen säilytys, poistaminen ja oikaisu;
• auditointi ja vaatimustenmukaisuuden seuranta;
• hallitustason riskiraportointi.

Clarysecin yritystason vaatimustenmukaisuuspolitiikka tekee tästä operatiivisesta mallista nimenomaisen:

”Kaikki lakisääteiset ja sääntelyyn perustuvat velvoitteet on kartoitettava tietoturvallisuuden hallintajärjestelmässä (ISMS) tiettyihin politiikkoihin, kontrolleihin ja omistajiin.”
Lähde: Laki- ja sääntelyvaatimusten noudattamisen politiikka, osio ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.2.1.

Pk-yrityksille sama periaate skaalataan käytännölliseksi vaatimustenmukaisuusrekisteriksi:

”Kun sääntelyä sovelletaan useilla osa-alueilla, esimerkiksi GDPR:ää säilytykseen, turvallisuuteen ja tietosuojaan, tämä on kartoitettava selkeästi vaatimustenmukaisuusrekisterissä ja koulutusmateriaaleissa.”
Lähde: Laki- ja sääntelyvaatimusten noudattamisen politiikka - pk-yritys, osio ”Hallinnointivaatimukset”, politiikkalauseke 5.2.2.

Organisaation ei tulisi kysyä: ”Mikä osasto omistaa eIDAS2:n?” Sen tulisi kysyä: ”Mihin ISMS-riskeihin, kontrolleihin, politiikkoihin, omistajiin ja näyttötallenteisiin lompakkoon tukeutuminen vaikuttaa?”

Zenith Blueprint -materiaalin Riskienhallinta-vaiheen vaiheessa 14 todetaan:

”Kunkin säädöksen osalta voit tarvittaessa luoda yksinkertaisen kartoitustaulukon, esimerkiksi raportin liitteeksi, jossa luetellaan säädöksen keskeiset tietoturvavaatimukset ja niitä vastaavat ISMS:n kontrollit ja politiikat. Tämä ei ole ISO 27001:ssä pakollista, mutta se on hyödyllinen sisäinen harjoitus sen varmistamiseksi, ettei mitään jää huomaamatta. Se myös vakuuttaa auditoijat ja arvioijat siitä, ettet hallitse tietoturvaa tyhjiössä vaan tunnet oikeudellisen kontekstin.”

Tämä on perusta: rakenna yksi kartoitustaulukko, joka yhdistää lompakon luottavan osapuolen velvoitteet GDPR-, NIS2-, DORA- ja ISO/IEC 27001:2022 liite A -kontrolleihin, Clarysec-politiikkoihin ja näyttötallenteisiin.

Käytännön näyttökartta EU:n digitaalisen identiteettilompakon luottaville osapuolille

EUDI Wallet on hallittavissa, kun sitä käsitellään ISMS:n sisällä määriteltynä liiketoimintaprosessina, jossa tiedot, identiteetit, toimittajat, lokit, poikkeamat ja omistajat on kartoitettu.

Tämä taulukko ei ole oikeudellinen lausunto. Se on kontrolli- ja näyttömalli, jota tietoturvajohtajat, vaatimustenmukaisuustiimit ja auditoijat voivat käyttää näytön jäsentämiseen.

Auditoijat aloittavat identiteetinhallinnasta

Lompakon luottavalle osapuolelle identiteetti on ilmeinen kontrolliperhe. Identiteetinhallinta ei kuitenkaan ole sama asia kuin todennus. Identiteetinhallinta vastaa kysymykseen ”kuka järjestelmässä on olemassa ja miten kyseistä identiteettiä hallitaan?” Todennus vastaa kysymykseen ”miten väitetty identiteetti varmistetaan käyttöhetkellä?”

Zenith Controls käsittelee ISO/IEC 27002:2022 -kontrollia 5.16, Identiteetinhallinta, ennaltaehkäisevänä kontrollina, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Se liittyy suoraan pääsynhallintaan, todentamistietoihin, käyttöoikeuksiin, toimittajasuhteisiin, vaatimustenmukaisuuden seurantaan ja etuoikeutettuun pääsyyn. Vaatimustenmukaisuuksien välinen kartoitus yhdistää tämän alueen GDPR:n tietoturvaan ja osoitusvelvollisuuteen, NIS2:n pääsynhallintaan ja omaisuudenhallintaan, DORA:n identiteetin- ja pääsynhallintaan, NIST SP 800-53 -standardin tunnisteiden hallintaan sekä COBIT 2019 -viitekehyksen identiteetin elinkaaren hallintaan.

Lompakkonäytön osalta organisaation tulee pystyä osoittamaan, että:

• asiakkaiden ja henkilöstön identiteettejä ei sekoiteta keskenään;
• hallinnolliset identiteetit ovat yksilöllisiä ja jäljitettävissä;
• toimittajien identiteettejä hallitaan samalla kurinalaisuudella kuin työntekijöiden identiteettejä;
• ei-inhimillisillä identiteeteillä, kuten API-asiakkailla ja palvelutileillä, on omistajat;
• identiteetit poistetaan käytöstä, kun niitä ei enää tarvita;
• poikkeukset, hätäkäyttötilit ja etuoikeutetut identiteetit ovat kontrolloituja.

Clarysecin pk-yrityksille tarkoitettu käyttäjätilipolitiikka tiivistää periaatteen selkeästi:

”Jokaisen tilin on oltava yksilöllinen, jäljitettävissä tiettyyn henkilöön ja yhdistetty liiketoiminnalliseen rooliin.”
Lähde: Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka - pk-yritys, osio ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.1.2.

Yritysympäristöissä vaatimus on tiukempi jaetuille tunnuksille:

”Kaikki käyttäjäidentiteetit on yhdistettävä yksilölliseen tunnisteeseen. Jaettujen tai geneeristen käyttäjätilien käyttö on kielletty, lukuun ottamatta hyväksyttyjä hätäkäyttö- tai poikkeustilatilejä, joihin sovelletaan tiukkoja kontrolleja.”
Lähde: Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka, osio ”Hallinnointivaatimukset”, politiikkalauseke 5.3.

Tukevat standardit vahvistavat saman näyttölogiikan. ISO/IEC 24760-1:2019 tarjoaa identiteetin elinkaaren käsitteitä, kuten rekisteröinti, sitominen, käyttö ja rekisteristä poistaminen. ISO/IEC 29115:2013 tukee riskiperusteista identiteettivarmuutta. ISO/IEC 27005:2024 käsittelee identiteetti- ja pääsynhallinnan heikkouksia riskien käsittelyn aiheina. ISO/IEC 27018:2020 laajentaa identiteetinhallinnan odotuksia julkisen pilven henkilötietojen käsittelyyn. ISO/IEC 29100:2011 lisää tietosuojanäkökulman yhdistämällä tunnistettavuuden henkilötietojen käsittelyyn.

EUDI Wallet -käyttöönotossa auditointikysymys on yksinkertainen: pystytkö jäljittämään jokaisen etuoikeutetun toimenpiteen, konfiguraatiomuutoksen, lompakon varmentamisintegraation muutoksen ja toimittajan pääsytapahtuman yksilölliseen identiteettiin, jolla on hyväksytty rooli?

Jos vastaus on ei, lompakkoprojekti ei ole valmis auditointia varten.

Turvallinen todennus: lompakon luottamus ei poista kontrollivelvoitteita

Yleinen väärinkäsitys on, että lompakkopohjainen henkilöllisyyden varmistaminen poistaa luottavan osapuolen todennusvelvoitteet. Se voi parantaa tiettyjen identiteettiattribuuttien varmuutta, mutta se ei poista velvollisuutta suojata järjestelmiä, istuntoja, ohjelmointirajapintoja, hallintaliittymiä ja asiakaspolkuja.

Zenith Blueprint -materiaalin Controls in Action -vaiheen vaiheessa 19 Clarysec toteaa:

”Todennus on ensimmäinen ja kriittisin puolustuslinja uhkatoimijan ja järjestelmien, tietojen ja palvelujen välillä. Jos todennus on heikko, kaikki muu — salaus, seuranta ja segmentointi — voidaan ohittaa.”

Sama vaihe selittää, että nykyaikaisen todennuksen on oltava riskiperusteista, vahvempaa arvokkaammille kohteille ja sitä on tuettava MFA:lla, tunnistetietojen turvallisella säilytyksellä, TLS:llä, token-suojauksella, salaisuuksien hallinnalla, turvallisella istunnonhallinnalla ja todennuslokien katselmoinnilla.

Zenith Controls kartoittaa ISO/IEC 27002:2022 -kontrollin 8.5, Turvallinen todennus, ennaltaehkäiseväksi kontrolliksi identiteetin- ja pääsynhallinnan kyvykkyydessä. Se liittyy identiteetinhallintaan, todentamistietoihin, etuoikeutettuun pääsyyn, tietojen pääsyn rajoittamiseen, valvontatoimiin, poikkeamien hallintaan ja henkilötietojen tietosuojaan. Se kartoitetaan myös GDPR:n tietoturvaan ja sisäänrakennettuun tietosuojaan, NIS2:n kyberturvallisuusriskien hallintaan ja tarvittaessa MFA:han tai jatkuvaan todennukseen, DORA:n ICT-riskienhallintaan, NIST SP 800-53 -standardin IA- ja AC-perheisiin sekä COBIT 2019 -viitekehyksen loogisen pääsyn hallintaan.

Lompakon luottavan osapuolen turvallisen todennuksen näytön tulee sisältää:

• lompakon varmentamispäätepisteen todennus ja valtuutus;
• ylläpitäjien MFA lompakon konfigurointipaneeleihin;
• turvallinen API-todennus asiakkaaksi ottamisen palvelujen välillä;
• lompakkointegraation avainten tai varmenteiden säilytys salaisuusholvissa;
• istunnon aikakatkaisut ja token-suojaus tarvittaessa;
• epäonnistuneiden todennusten hälytykset ja brute force -suojaukset;
• erilliset kontrollit asiakaskirjautumiselle, työntekijöiden pääsylle ja koneiden väliselle pääsylle.

Clarysecin pk-yritysten lokituspolitiikka tarjoaa käytännöllisen näyttövaatimuksen:

”Todennuslokit: onnistuneet ja epäonnistuneet kirjautumisyritykset, istunnon kesto, MFA:n käyttö”
Lähde: Lokitus- ja valvontapolitiikka - pk-yritys, osio ”Hallinnointivaatimukset”, politiikkalauseke 5.4.2.

Yritysympäristöissä auditoinnin luotettavuudesta tulee keskeistä:

”Lokitiedostojen on oltava muuttumattomia tai versiohallittuja, ja pääsy niihin on myönnettävä vain valtuutetulle henkilöstölle.”
Lähde: Lokitus- ja valvontapolitiikka, osio ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.5.1.

Tämä on silta identiteettivarmuuden ja tietoturvapoikkeamiin reagoinnin välillä. Jos lompakkopohjaista asiakkaaksi ottamista vastaan hyökätään credential stuffing -menetelmällä, tokenien toistohyökkäyksellä, hallinnollisen tilin vaarantamisella tai toimittajan väärinkäytöllä, todennuslokeista tulee näyttöjälki.

GDPR: lompakon lupaus on minimointi, mutta se on osoitettava

EU:n digitaalinen identiteettilompakko voi tukea tietosuojaa parantavaa asiakkaaksi ottamista, koska luottava osapuoli voi pyytää tiettyjä attribuutteja sen sijaan, että se keräisi kokonaisia henkilöllisyysasiakirjoja. GDPR:n osoitusvelvollisuus ei kuitenkaan perustu hyviin aikomuksiin. Se edellyttää todennettavissa olevaa vaatimustenmukaisuutta.

Lompakosta johdetut attribuutit ovat henkilötietoja, kun ne liittyvät tunnistettuun tai tunnistettavissa olevaan henkilöön. Osa käyttötapauksista voi koskea myös biometrisiä tietoja, henkilöllisyyden varmentamistietoja, pakoteseulontaa, petosriskiä tai muita arkaluonteisia käsittelykonteksteja.

GDPR:n periaatteet edellyttävät lainmukaista, kohtuullista ja läpinäkyvää käsittelyä, määriteltyjä käyttötarkoituksia, tietojen minimointia, täsmällisyyttä, säilytyksen rajoittamista, eheyttä ja luottamuksellisuutta sekä osoitusvelvollisuutta. Luottavan osapuolen tulee pystyä osoittamaan, miksi kutakin lompakon attribuuttia pyydetään, kuinka kauan sitä säilytetään, kuka siihen pääsee, miten se suojataan ja miten uudelleenkäyttöä hallitaan.

Clarysecin yritystason tietosuojapolitiikassa todetaan:

”Vain tietoja, jotka ovat välttämättömiä tiettyä, oikeutettua liiketoimintatarkoitusta varten, saa kerätä ja käsitellä.”
Lähde: Tietosuoja- ja yksityisyydensuojapolitiikka, osio ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.2.1.

Pk-yritysversio on tarkoituksella tiivis:

”Vain välttämättömät vähimmäishenkilötiedot tulee kerätä ja säilyttää”
Lähde: Tietosuoja- ja yksityisyydensuojapolitiikka - pk-yritys, osio ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.2.1.

Zenith Controls kartoittaa ISO/IEC 27002:2022 -kontrollin 5.34, Henkilötietojen suoja ja yksityisyydensuoja, omaisuusluetteloon, tietojen maskaukseen, pilvipalvelujen hallintaan, tiedon luokitteluun, turvalliseen siirtoon, pääsynhallintaan, identiteetinhallintaan ja projektimuutosten katselmointiin. Se liittyy myös ISO/IEC 27701:2021 -standardiin tietosuojan hallinnasta, ISO/IEC 27018 -standardiin pilvessä tapahtuvasta henkilötietojen käsittelystä ja ISO/IEC 29100 -standardin tietosuojaperiaatteisiin.

Lompakon käyttöönoton tietosuojanäyttöpaketin tulee sisältää:

• tietovirtojen kaavio lompakon attribuuteista;
• oikeusperusterekisterin merkintä;
• attribuuttien minimointia koskeva päätöstallenne;
• säilytysaikataulu lompakosta johdetuille tiedoille;
• tietosuojailmoituksen päivitys;
• DPIA tai tietosuojariskien arviointi, kun käyttötapaus on korkean riskin käyttötapaus;
• pääsynhallintamatriisi lompakkotiedoille;
• tietojen poistamisen ja oikaisun prosessi;
• valvontaan perustuva näyttö siitä, että pääsy lompakosta johdettuihin henkilötietoihin on kontrolloitu.

Monet organisaatiot keräävät liikaa, koska lompakko tekee varmistetun tiedon hankkimisesta helpompaa. Tämä on väärä suunta. Tietoturva- ja tietosuojahyöty syntyy siitä, että pyydetään vähemmän, ei siitä, että säilytetään enemmän varmennettua identiteettidataa kuin liiketoiminta tarvitsee.

NIS2 ja DORA: hallituksen vastuuvelvollisuus kohtaa lompakon häiriönsietokyvyn

NIS2 ja DORA nostavat kyberturvallisuuden osaksi hallinnointia. Ne edellyttävät, että johtoelimet hyväksyvät riskienhallintatoimet, valvovat niitä ja vastaavat niistä. Ne odottavat myös oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia kontrolleja.

NIS2 Article 21 edellyttää riskienhallintatoimia, jotka kattavat politiikat, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun tietoturvan, turvallisen hankinnan ja kehittämisen, haavoittuvuuksien käsittelyn, kontrollien tehokkuuden, kyberhygienian, koulutuksen, kryptografian, henkilöstöturvallisuuden, pääsynhallinnan, omaisuudenhallinnan sekä tarvittaessa MFA:n tai jatkuvan todennuksen. NIS2-sektoreilla toimivilla lompakon luottavilla osapuolilla lompakkointegraation tulee näkyä riskien arvioinnissa, omaisuusluettelossa, toimittajarekisterissä, poikkeamasuunnitelmassa ja pääsynhallinnan viitekehyksessä.

NIS2 Article 23 lisää vaiheistetun merkittävien poikkeamien raportoinnin. Keskeisten ja tärkeiden toimijoiden on annettava varhaisvaroitus 24 tunnin kuluessa, ilmoitus 72 tunnin kuluessa ja loppuraportti yhden kuukauden kuluessa sekä tarvittaessa viestittävä vastaanottajille. Jos lompakkointegraation häiriö voisi aiheuttaa operatiivisen häiriön, taloudellista menetystä tai aineellista tai aineetonta haittaa palvelun vastaanottajille, se tulee sisällyttää poikkeamien luokittelulogiikkaan.

DORA on finanssialan toimijoille täsmällisempi. Se edellyttää sisäistä hallinnointi- ja kontrolliviitekehystä ICT-riskille, hallituksen hyväksymää häiriönsietokyvyn strategiaa, ICT-politiikkoja, liiketoiminnan jatkuvuus- ja reagointisuunnitelmia, auditointisuunnitelmia, kolmansien osapuolten politiikkoja, poikkeamien ilmoituskanavia ja dokumentoitua ICT-riskienhallinnan viitekehystä. Se edellyttää myös ICT:hen liittyvien poikkeamien hallintaa, luokittelua esimerkiksi vaikutuksen kohteena olevien asiakkaiden, käyttökatkon, maantieteellisen laajuuden, tietojen menetyksen, kriittisyyden ja taloudellisen vaikutuksen perusteella sekä merkittävien ICT:hen liittyvien poikkeamien raportointia.

Lompakkopohjaisessa asiakkaaksi ottamisessa finanssipalveluissa näytön tulee osoittaa, että:

• lompakkointegraatio sisältyy ICT-omaisuus- ja prosessi-inventaarioon;
• riskit arvioidaan ja oikea omistaja hyväksyy ne;
• kriittisyys arvioidaan asiakkaaksi ottamisen tai tilinkäytön kannalta;
• häiriönsietokyky ja varamenettelyt ovat olemassa;
• poikkeamat voidaan luokitella DORA-kriteerien mukaisesti;
• asiakasilmoitukset on suunniteltu tilanteisiin, joissa taloudelliset edut vaarantuvat;
• ulkoistettu raportointi, jos sitä käytetään, ei poista vastuuvelvollisuutta.

Keskeistä on oikeasuhtaisuus. Pieni fintech-yritys ja suuri pankki eivät tuota samaa määrää näyttöä, mutta molemmat tarvitsevat jäljitettävää hallinnointia.

Toimittaja- ja pilviriippuvuudet: lompakkopolkusi on vain yhtä vahva kuin sen ketju

Useimmat lompakon luottavan osapuolen toteutukset sisältävät ulkoisia palveluja: pilvipalvelussa ylläpidetty infrastruktuuri, API-yhdyskäytävät, varmentamiskirjastot, identiteettivälittäjät, KYC-toimittajat, petostenhallintamoottorit, lokitusalustat, hallinnoidun havainnoinnin ja reagoinnin palveluntarjoajat tai asiakastukityökalut. Tämä tekee toimittajahallinnasta keskeistä.

NIS2 edellyttää, että toimijat ottavat huomioon toimittajakohtaiset haavoittuvuudet sekä toimittajien ja palveluntarjoajien yleisen laadun ja kyberturvallisuuskäytännöt. DORA menee finanssialan toimijoilla pidemmälle edellyttämällä ICT-palvelujen sopimusjärjestelyjen rekisteriä, sopimusta edeltäviä arviointeja, keskittymäriskin analyysia, huolellisuutta, auditointi- ja tarkastusmenettelyjä, irtisanomisoikeuksia sekä testattuja irtautumisstrategioita ICT-palveluille, jotka tukevat kriittisiä tai tärkeitä toimintoja.

Zenith Blueprint -materiaalin Controls in Action -vaiheen vaiheessa 23 Clarysec ohjeistaa tiimejä kokoamaan kattavan toimittajaluettelon, luokittelemaan palveluntarjoajat järjestelmiin, tietoihin tai operatiiviseen kontrolliin kohdistuvan pääsyn perusteella, sisällyttämään odotukset sopimuksiin, tunnistamaan alihankkijat, määrittämään muutosherätteet ja rakentamaan pilvipalvelujen arviointiprosessin. Sama vaihe suosittelee tietojen sijainnin, pääsymallin, lokituksen ja salauksen arviointia ennen tulevien pilvipalvelujen hyväksymistä.

Clarysecin pk-yritysten toimittajapolitiikka antaa selkeän vähimmäispääsyn säännön:

”Toimittajille saa myöntää pääsyn vain niihin vähimmäisjärjestelmiin ja tietoihin, joita tarvitaan niiden tehtävän suorittamiseen.”
Lähde: Kolmansien osapuolten ja toimittajaturvallisuuden politiikka - pk-yritys, osio ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.2.1.

NIST CSF 2.0 tukee tätä integroitua näkymää. Sen GOVERN-toiminto sisältää lakisääteiset, sääntelyyn perustuvat, sopimusperusteiset ja tietosuojavelvoitteet, riskinottohalukkuuden, osoitusvelvollisuuden, politiikan, resursoinnin ja valvonnan. Sen toimitusketjun tulokset edellyttävät toimittajien rooleja, kriittisyyden priorisointia, sopimuksellisia kyberturvallisuusvaatimuksia, huolellisuutta, seurantaa, poikkeamasuunnittelua ja suhteen päättymisen jälkeisiä ehtoja.

COBIT 2019 -auditoijat tarkastelevat hallinnoinnin kypsyystasoa. He kysyvät, onko toimittajavastuut, identiteetin elinkaari, tietosuojakontrollit ja valvonta sisällytetty liiketoimintaprosesseihin eikä pelkästään tietoturvatiimin tarkistuslistoihin. Identiteetin ja loogisen pääsyn osalta COBIT 2019 DSS05.04, Manage user identity and logical access, on erityisen olennainen arvioitaessa, ovatko käyttäjätilien omistajuus, hyväksynnät, oikeuksien myöntäminen ja poistaminen kontrolloituja.

Rakenna lompakon luottavan osapuolen näyttöpaketti yhden iltapäivän aikana

Käytännön Clarysec-tyylinen harjoitus alkaa yhdestä täsmällisestä käyttötapauksesta, ei laajasta ohjelmajulistuksesta. Käytä ensimmäisenä tallenteena esimerkiksi ”asiakkaaksi ottaminen käyttäen lompakon tarjoamaa virallista nimeä, syntymäaikaa ja osoitetta”. Lisää liiketoimintavastaava, järjestelmäomistaja, tiedon omistaja ja riskinomistaja.

Kirjaa:

• käsittelyn tarkoitus;
• pyydettävät lompakon attribuutit;
• tallennetaanko, välimuistitetaanko vai ainoastaan varmennetaanko attribuutit;
• mukana olevat järjestelmät ja ohjelmointirajapinnat;
• toimittajat ja alikäsittelijät;
• mukana olevat maat tai pilvialueet;
• varamenettely, jos lompakkovarmentaminen epäonnistuu;
• asiakasviestinnän kosketuspisteet.

Lisää sitten käyttötapaus vaatimustenmukaisuusrekisteriin.

Seuraavaksi katselmoi soveltuvuuslausunto ja riskienkäsittelysuunnitelma. EUDI Wallet -käyttötapauksissa seuraavat ISO/IEC 27002:2022 -kontrollialueet ovat yleensä olennaisia.

Tee lopuksi miniauditointi. Valitse yksi lompakkopohjaisen asiakkaaksi ottamisen tapahtuma ja jäljitä:

1. attribuuttipyynnön perustelu;
2. läpinäkyvyysvaihe tai suostumustallenne tarvittaessa;
3. järjestelmän tapahtumaloki;
4. API-todennuksen näyttö;
5. pääsynhallintatallenne henkilöstöstä, joka tarkastelee asiakkaaksi ottamisen tulosta;
6. mukana oleva toimittaja;
7. säilytyssääntö;
8. poikkeaman luokittelureitti, jos kyseinen tapahtuma olisi petollinen tai paljastuisi.

Jos et pysty jäljittämään polkua, prosessi ei ole vielä näyttövalmis.

Miten eri auditoijat testaavat samaa lompakkopolkua

Eri auditoijat lähestyvät EU:n digitaalista identiteettilompakkoa eri ammatillisista näkökulmista. Sama näyttö voi vastata useisiin kysymyksiin, jos se on jäsennetty hyvin.

Zenith Controls antaa hyödyllisiä auditointimenetelmiä koskevia yksityiskohtia näille alueille. Identiteetinhallinnassa auditoijat jäljittävät yleensä käyttäjäidentiteettejä käyttöönoton, muutosten ja työsuhteen päättämisen läpi, täsmäyttävät HR-tallenteita käyttäjätililuetteloihin, tarkastavat ulkopuoliset ja palvelutilit sekä etsivät jaetun ylläpitäjäkäytön merkkejä. Turvallisessa todennuksessa auditoijat vertaavat politiikkoja teknisiin konfiguraatioihin, katselmoivat MFA-kattavuutta, tarkastelevat salasana- ja istuntokontrolleja sekä tarkastavat onnistuneet ja epäonnistuneet kirjautumislokit. Tietosuojassa ja henkilötietojen suojauksessa auditoijat ottavat otoksia DPIA:sta, rekisteröityjen pyyntöjen prosesseista, tietosuojakoulutuksesta, henkilötietoinventaarioista, salauksesta, käyttölokeista ja säilytyskontrolleista.

Clarysecin Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka kuvaa näyttötavoitteen selkeästi:

”Tuottaa puolustettavissa olevaa näyttöä ja auditointijälki sääntelytiedustelujen, oikeudellisten menettelyjen tai asiakkaiden varmentamispyyntöjen tueksi.”
Lähde: Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka, osio ”Tavoitteet”, politiikkalauseke 3.4.

Ilmaus puolustettavissa oleva näyttö erottaa politiikkakirjaston auditointia varten valmiista vaatimustenmukaisuusjärjestelmästä.

Yleiset sudenkuopat lompakkovalmiushankkeissa

Ensimmäinen sudenkuoppa on liiallinen tiedonkeruu. Lompakot voivat tehdä varmennettujen attribuuttien hankkimisesta helpompaa, mutta GDPR ohjaa päinvastaiseen toimintaan: kerää ja säilytä vain välttämätön. Jos tuotetiimi pyytää täydellisiä identiteettitietoja, vaikka vain iän vahvistaminen on tarpeen, tietosuojakontrollien suunnittelu on jo virheellinen.

Toinen sudenkuoppa on ei-inhimillisten identiteettien sivuuttaminen. Lompakkointegraatiot nojaavat usein API-asiakkaisiin, varmenteisiin, palvelutileihin, automaatioskripteihin ja salaisuuksiin. Jos näillä identiteeteillä ei ole omistajaa, niitä ei kierrätetä, valvota ja poisteta käytöstä, luottavan osapuolen ympäristö on heikko, vaikka lompakkoekosysteemi olisi vahva.

Kolmas sudenkuoppa on toimittajien käsittely pelkkänä hankintapaperityönä. NIS2:n ja DORA:n mukaan toimittajaturvallisuus on operatiivista. Tarvitset huolellisuusarvioinnin, sopimuslausekkeet, valvonnan, poikkeamayhteistyön, auditointioikeudet ja irtautumissuunnitelmat. DORA-sääntelyn alaisille toimijoille ICT-kolmansien osapuolten rekisteri on keskeistä vaatimustenmukaisuusnäyttöä.

Neljäs sudenkuoppa on lokitus ilman hallinnointia. Ylilokitus voi luoda tietosuojariskin. Alilokitus tuhoaa tutkintakyvyn. Määritä todennus-, varmentamis-, hallinnolliset ja poikkeamien kannalta olennaiset tapahtumat, suojaa lokit muutoksilta, rajoita pääsyä ja sovita säilytys lakisääteisiin ja liiketoiminnallisiin tarpeisiin.

Viides sudenkuoppa on raportoinnin harjoittelematta jättäminen. NIS2:ssa on 24 tunnin, 72 tunnin ja yhden kuukauden raportointiodotukset merkittäville poikkeamille. DORA:ssa on alustava raportointi, väliraportointi ja loppuraportointi merkittäville ICT:hen liittyville poikkeamille. Jos organisaatio kartoittaa lompakkoon liittyvän poikkeaman näihin määräaikoihin ensimmäistä kertaa varsinaisen tapahtuman aikana, hallinnointi on epäonnistunut.

Muuta EUDI Wallet -käyttöönotto auditointivalmiiksi näytöksi

EU:n digitaalinen identiteettilompakko muuttaa asiakkaaksi ottamista ja digitaalista luottamusta Euroopassa. Tietoturvajohtajille, tietosuojavastaaville, vaatimustenmukaisuuspäälliköille, auditoijille ja liiketoimintavastaaville oikea siirto ei kuitenkaan ole uuden erillisen vaatimustenmukaisuusohjelman luominen. Oikea siirto on tuoda lompakon käyttöönotto ISMS:ään ja kartoittaa se tietosuojaan, identiteettiin, todennukseen, toimittajiin, lokitukseen, häiriönsietokykyyn ja tietoturvapoikkeamiin reagointiin.

Clarysec voi auttaa tekemään tämän jäsennellysti:

1. Käytä Zenith Blueprint -materiaalia sijoittaaksesi lompakon käyttöönoton Riskienhallinta-vaiheeseen, vaiheeseen 14 sääntelyn ristiinviittauksia varten, vaiheeseen 19 turvallista todennusta varten ja vaiheeseen 23 toimittaja-, tietosuoja- ja lakisääteisten kontrollien toteutusta varten.
2. Käytä Zenith Controls -materiaalia kartoittaaksesi ISO/IEC 27002:2022 -standardin identiteetinhallinnan, turvallisen todennuksen ja tietosuojakontrollit GDPR-, NIS2-, DORA-, NIST- ja COBIT 2019 -näyttöön.
3. Käytä Clarysec-politiikkamalleja, kuten Laki- ja sääntelyvaatimusten noudattamisen politiikka, Tietosuoja- ja yksityisyydensuojapolitiikka, Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka, Lokitus- ja valvontapolitiikka, Kolmansien osapuolten ja toimittajaturvallisuuden politiikka - pk-yritys ja Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka, muuntaaksesi velvoitteet omistetuiksi ja testattaviksi käytännöiksi.
4. Rakenna lompakon luottavan osapuolen näyttöpaketti ennen käyttöönottoa, ei ensimmäisen auditointipyynnön jälkeen.

Jos organisaatiosi aikoo tukeutua EU:n digitaaliseen identiteettilompakkoon vuonna 2026, nyt on aika kysyä yksi kysymys: pystymmekö osoittamaan puolustettavissa olevalla näytöllä, että tämä identiteettipolku on turvallinen, lainmukainen, häiriönsietokykyinen ja hallittu?

Clarysecin vastaus on käytännöllinen: kartoita se, määritä omistajat, testaa se ja pidä näyttö valmiina.