DORA:n 28 artiklan 3 kohta velvoittaa jokaisen finanssitoimijan ylläpitämään tietorekisteriä kaikista ICT-palveluntarjoajien kanssa tehdyistä sopimusjärjestelyistä ja raportoimaan siitä vuosittain Finanssivalvonnalle Euroopan valvontaviranomaisten (ESA) mallipohjilla.
Tietorekisteri – register of information – on DORA:n työläin yksittäinen velvoite, koska se pakottaa keräämään yhteen tiedot, jotka useimmissa organisaatioissa ovat hajallaan hankintasopimuksissa, toimittajarekisterissä, arkkitehtuurikuvauksissa ja laskutusjärjestelmässä. Tämä artikkeli antaa konkreettisen kenttä kentältä -mallin, kertoo miten rekisteri suhtautuu GDPR:n käsittelytoimien selosteeseen ja miten se toimitetaan valvojalle.
Keskeiset kohdat
- Velvoite perustuu asetuksen (EU) 2022/2554 28 artiklan 3 kohtaan ja on ollut sitova 17.1.2025 alkaen.
- Rekisteri ylläpidetään kolmella tasolla: toimijatasolla sekä ala- ja täyskonsolidoidulla tasolla.
- Rekisteriin merkitään kaikki ICT-palvelusopimukset, ei vain kriittisiä toimintoja tukevat – kriittisyys on rekisterin kenttä, ei sen rajaus.
- Rekisteri raportoidaan vuosittain toimivaltaiselle viranomaiselle, Suomessa Finanssivalvonnalle, joka toimittaa tiedot edelleen ESA:ille.
- Rekisteri on eri asia kuin GDPR:n käsittelytoimien seloste, mutta noin puolet lähdetiedoista on samoja.
Mikä DORA-tietorekisteri on?
Tietorekisteri on rakenteinen luettelo kaikista sopimusjärjestelyistä, joilla finanssitoimija käyttää ulkopuolisen tarjoamia ICT-palveluja. Se ei ole toimittajaluettelo eikä sopimusarkisto vaan suhderekisteri: se kuvaa, mikä toimija käyttää mitä palvelua miltä toimittajalta minkä liiketoimintatoiminnon tukemiseen, missä maassa tieto sijaitsee ja mitä alihankintaketjussa tapahtuu.
Rekisterin tarkoitus on kaksitasoinen. Toimijalle se on kolmannen osapuolen riskin hallintaväline. Valvojalle – ja ESA:ille – se on aineisto, jonka perusteella tunnistetaan kriittiset ICT-palveluntarjoajat ja arvioidaan keskittymäriski koko EU:n rahoitusjärjestelmässä. Juuri siksi muodon on oltava standardoitu: tiedot yhdistetään koko unionin laajuisesti. Kansallisen valvonnan yleiskuva on artikkelissa DORA Suomessa.
ESA:iden mallipohjat koostuvat toisiinsa kytkeytyvistä taulukoista (B_01.01, B_02.01, B_05.01 ja niin edelleen), joissa tiedot linkittyvät toisiinsa tunnisteiden – erityisesti LEI-tunnusten, sopimusviitteiden ja toimintotunnisteiden – kautta. Käytännössä tämä tarkoittaa, että viitetietojen on oltava kunnossa ennen kuin yhtään riviä voi täyttää.
Tietorekisterin malli: kentät ryhmittäin
Alla oleva malli kokoaa mallipohjien vaaditut tiedot loogisiin ryhmiin. Käytä sitä sisäisenä keruulomakkeena – ESA-muotoon konvertointi on viimeinen vaihe, ei ensimmäinen.
DORA-TIETOREKISTERI – keruumalli
1. Raportoiva toimija
Kenttä Sisältö LEI-tunnus Raportoivan finanssitoimijan LEI Nimi ja maa Virallinen nimi, kotipaikka Toimijatyyppi Luottolaitos, maksulaitos, vakuutusyhtiö, sijoituspalveluyritys jne. Konsolidointitaso Toimija / alakonsolidoitu / konsolidoitu Raportointiviitepäivä Rekisterin tilannepäivä 2. Sopimusjärjestely
Kenttä Sisältö Sopimusviite Yksilöivä sisäinen tunniste Sopimustyyppi Yksi palvelu / useita palveluja / puitesopimus Alkamis- ja päättymispäivä Voimassaolo Irtisanomisaika Toimijan ja toimittajan irtisanomisajat Sovellettava laki Sopimukseen sovellettava laki Vuotuinen kustannus Edellisen tilikauden kulut (EUR) Emosopimus Viite ylemmän tason sopimukseen, jos on 3. ICT-palveluntarjoaja
Kenttä Sisältö Tunniste LEI tai EUID, tyyppi merkittävä Nimi ja maa Virallinen nimi, päätoimipaikan maa Konsernin emo Ylimmän emoyhtiön tunniste Palveluntarjoajan tyyppi Pilvipalvelu, datakeskus, ohjelmisto, tietoliikenne jne. Onko konsernin sisäinen Kyllä / ei 4. ICT-palvelu ja toiminto
Kenttä Sisältö ICT-palvelutyyppi ESA-luokituksen mukainen palvelutyyppi Palvelun kuvaus Lyhyt sanallinen kuvaus Toimintotunniste Tuetun liiketoimintatoiminnon tunniste Toiminnon nimi ja kuvaus Esim. maksuliikenne, luotonanto, säilytys Kriittinen tai tärkeä Kyllä / ei + arvioinnin päivämäärä Perustelu Miksi toiminto on (tai ei ole) kriittinen 5. Sijainti ja tietosuoja
Kenttä Sisältö Palvelun tuottamisen maa Missä palvelu tosiasiassa tuotetaan Tietojen säilytysmaa Datan sijaintimaa Tietojenkäsittelymaa Missä käsittely tapahtuu Tietojen arkaluonteisuus Käsitelläänkö arkaluonteisia tietoja 6. Alihankintaketju
Kenttä Sisältö Alihankkijan tunniste LEI tai EUID Ketjun taso 1, 2, 3 … Alihankittu palvelu Mitä osaa palvelusta alihankinta koskee 7. Riskienhallinta ja exit
Kenttä Sisältö Korvattavuus Helposti / vaikeasti / ei korvattavissa Vaihtoehtoiset toimittajat Onko tunnistettu, ketkä Exit-suunnitelma Onko dokumentoitu, päivitetty milloin Uudelleenintegrointi Arvio siitä, voidaanko palvelu palauttaa sisäiseksi Tarkastusoikeudet Sopimusperusteiset audit- ja pääsyoikeudet Viimeisin arviointi Toimittaja-arvioinnin päivämäärä
Kenttien lukumäärä ei ole rekisterin vaikeus. Vaikeus on siinä, että sama sopimus tuottaa useita rivejä useaan taulukkoon ja että tunnisteiden on täsmättävä taulukosta toiseen. Yksi puuttuva LEI-tunnus kaataa validoinnin.
Suhde GDPR:n käsittelytoimien selosteeseen
Kysymys tulee jokaisessa projektissa: voidaanko rekisteri ja ROPA yhdistää? Vastaus on ei – mutta lähdetiedot kannattaa yhdistää.
| DORA-tietorekisteri | Käsittelytoimien seloste (GDPR 30 art.) | |
|---|---|---|
| Kohde | ICT-palvelusopimukset | Henkilötietojen käsittelytoimet |
| Rajaus | Kaikki ICT-palvelut, myös ilman henkilötietoja | Kaikki käsittely, myös ilman ICT-palvelua |
| Vastaanottaja | Finanssivalvonta vuosittain | Tietosuojavaltuutetun toimisto pyynnöstä |
| Muoto | Standardoitu ESA-mallipohja | Vapaamuotoinen, sisältö säädetty |
| Yhteinen aineisto | Toimittajat, alihankkijat, tietojen sijainti, siirrot, sopimusehdot |
Käytännön suositus: pidä yksi toimittaja- ja sopimustietokanta, josta molemmat raportit generoidaan eri näkyminä. Näin toimittajan vaihto päivittyy kerralla molempiin. ROPA-pohja löytyy artikkelista käsittelytoimien seloste malli, ja ohjelmistotuen vaihtoehdot artikkelista ROPA-ohjelmisto. Sopimusehtojen puolella DORA:n 30 artiklan vaatimukset menevät osin päällekkäin GDPR:n 28 artiklan kanssa – vertaa käsittelysopimuksen pakollisiin ehtoihin ja käytä samaa sopimusliitepohjaa molempiin, kuten käsittelysopimuksen mallissa.
Kuka toimittaa rekisterin ja milloin?
Rekisterin toimittaa finanssitoimija itse toimivaltaiselle viranomaiselle. Suomessa vastaanottaja on Finanssivalvonta, joka kokoaa tiedot ja toimittaa ne edelleen Euroopan valvontaviranomaisille. Finanssivalvonta ilmoittaa vuosittain raportoinnin viitepäivän ja toimitusaikataulun sekä käytettävän raportointikanavan; nämä on syytä tarkistaa Finanssivalvonnan sivuilta ennen jokaista toimituskierrosta.
Kolme asiaa kannattaa tietää etukäteen. Ensinnäkin rekisteri on ylläpidettävä jatkuvasti, ei koottava kerran vuodessa – 28 artikla puhuu rekisterin ylläpitämisestä ja päivittämisestä. Toiseksi valvoja voi pyytää rekisterin koska tahansa, ei vain vuosiraportoinnin yhteydessä. Kolmanneksi validointi on tiukka: tunnisteiden, luokitusten ja päivämäärien on oltava teknisesti kelvollisia, joten ensimmäinen toimitus kannattaa ajaa läpi testivalidoinnilla hyvissä ajoin.
Miten rekisteri pysyy ajan tasalla?
Ensimmäinen kokoaminen on projekti, ylläpito on prosessi – ja juuri ylläpito kaatuu useimmissa organisaatioissa. Syy on lähes aina sama: rekisterillä ei ole kenttäkohtaista omistajuutta, vaan koko rekisteri on “compliancen” nimissä yhden henkilön vastuulla, jolla ei ole pääsyä lähdetietoihin.
Toimiva jako on tämä. Hankinta ja sopimushallinta omistavat sopimusjärjestelyn kentät: sopimusviitteet, voimassaoloajat, irtisanomisajat, sovellettavan lain ja vuotuisen kustannuksen. Liiketoiminta omistaa toimintotunnisteen ja kriittisyysluokittelun – vain liiketoiminta pystyy perustelemaan, miksi toiminto on kriittinen. ICT-arkkitehtuuri omistaa palvelutyypin, palvelun kuvauksen ja riippuvuudet. Riskienhallinta omistaa korvattavuuden, keskittymäriskin ja exit-suunnitelmien tilan. Tietosuoja omistaa tietojen sijainti- ja arkaluonteisuuskentät, koska ne ovat samat tiedot, jotka kirjataan käsittelytoimien selosteeseen. Jokaiselle kenttäryhmälle nimetään yksi vastuuhenkilö ja varahenkilö, ja päivitys on osa normaalia työnkulkua – ei vuosittaista kyselykierrosta.
Sopimusmuutokset kesken vuoden ovat toinen kompastuskivi. 28 artikla velvoittaa ylläpitämään ja päivittämään rekisteriä, ei kokoamaan sitä kerran vuodessa. Käytännössä tämä tarkoittaa, että uusi ICT-sopimus, sopimuksen olennainen muutos, palveluntarjoajan vaihtuminen, alihankkijan lisääminen tai palvelun päättyminen kirjataan rekisteriin viiveettä. Yksinkertaisin toimiva kontrolli on portti hankintaprosessissa: ICT-palvelusopimusta ei hyväksytä allekirjoitettavaksi ennen kuin rekisteririvit on täytetty. Kriittisiä toimintoja tukevien sopimusten muutoksista on lisäksi ilmoitettava toimivaltaiselle viranomaiselle etukäteen suunniteltuina järjestelyinä, joten rekisteri ja hankintaprosessi on syytä kytkeä toisiinsa myös tähän suuntaan.
Tavallisimmat laatuvirheet keskittyvät tunnistekenttiin. Vanhentunut LEI. LEI-tunnus on uusittava vuosittain, ja vanhentunut tunnus tuottaa validointivirheen, vaikka tunnus itsessään on oikea. Väärä oikeushenkilö. Sopimuksen on tehnyt palveluntarjoajan paikallinen tytäryhtiö, mutta rekisteriin on merkitty konsernin emoyhtiön tunnus – tai päinvastoin. Puuttuva EUID. Toimittajalla, jolla ei ole LEI-tunnusta, on käytettävä eurooppalaista yksilöivää tunnistetta, eikä Y-tunnus kelpaa sen korvikkeeksi. Ristiriitainen kriittisyys. Sama toiminto on merkitty kriittiseksi yhdessä sopimusrivissä ja ei-kriittiseksi toisessa. Katkennut ketju. Alihankkijarivi viittaa sopimusviitteeseen, jota ei ole olemassa. Nämä viisi selittävät kokemukseni mukaan valtaosan hylätyistä toimituksista, ja kaikki ne ovat estettävissä yhdellä validointiajolla ennen määräpäivää.
Miten rekisteri kootaan käytännössä?
Toimiva järjestys on tämä:
- Toimintokartoitus ensin. Määrittele liiketoimintatoiminnot ja niiden kriittisyys ennen sopimusten läpikäyntiä. Tämä on sama työ kuin DORA:n 8 artiklan tunnistaminen, ks. DORA:n ICT-riskienhallinnan viitekehys.
- Sopimusinventaario. Kerää kaikki sopimukset, joissa vastapuoli tuottaa ICT-palvelua – myös pienet SaaS-tilaukset ja konsernin sisäiset palvelut.
- Tunnisteiden siivous. Hae jokaiselle toimittajalle LEI tai EUID. Tämä on yleensä pisin yksittäinen vaihe.
- Kriittisyysarviointi. Merkitse, tukeeko palvelu kriittistä tai tärkeää toimintoa, ja dokumentoi perustelu.
- Alihankintaketjut. Pyydä toimittajilta ketjutiedot; sopimusehto tähän kannattaa lisätä seuraavassa neuvottelukierroksessa.
- Puutteiden korjaus. Sopimukset, joista puuttuu DORA:n 30 artiklan pakollisia ehtoja, menevät korjauslistalle – tämä on käytännössä sama työjono kuin DORA pankeille -artikkelin sopimusremontti.
Usein kysytyt kysymykset
Onko tietorekisteri pakollinen kaikille DORA:n soveltamisalan toimijoille?
Kyllä. 28 artiklan 3 kohta koskee kaikkia finanssitoimijoita ilman kokorajaa. Myös kevennettyä ICT-riskienhallinnan viitekehystä soveltavat toimijat ylläpitävät rekisteriä.
Merkitäänkö rekisteriin vain kriittisiä toimintoja tukevat palvelut?
Ei. Rekisteriin merkitään kaikki ICT-palvelusopimukset. Kriittisyys on rekisterin tietokenttä, jonka perusteella osaan sopimuksista kohdistuu tiukempia vaatimuksia.
Kuuluvatko konsernin sisäiset ICT-palvelut rekisteriin?
Kyllä. Konsernin sisäiset järjestelyt merkitään rekisteriin ja ne yksilöidään omalla kentällään.
Korvaako tietorekisteri GDPR:n käsittelytoimien selosteen?
Ei. Ne ovat eri velvoitteita eri viranomaisille ja eri rajauksella. Lähdetiedot kannattaa silti pitää yhdessä tietokannassa.
Mitä tapahtuu, jos rekisteri toimitetaan puutteellisena?
Puutteellinen tai virheellinen rekisteri johtaa ensin korjauspyyntöön ja toistuessaan valvonnallisiin toimenpiteisiin. Rekisteri on ensimmäisiä asiakirjoja, joita valvoja pyytää DORA-arvioinnissa – vastaavasti kuin käsittelytoimien seloste on tietosuojatarkastuksen avausdokumentti.
Yhteenveto
DORA-tietorekisteri on 28 artiklan 3 kohdan mukainen standardoitu luettelo kaikista ICT-palvelusopimuksista, joka ylläpidetään jatkuvasti ja raportoidaan vuosittain Finanssivalvonnalle ESA-mallipohjilla. Työn painopiste ei ole taulukossa vaan sitä edeltävässä toimintokartoituksessa, tunnisteiden siivouksessa ja alihankintaketjujen selvittämisessä. Rakenna rekisteri samasta lähdetiedosta kuin GDPR-dokumentaatio, niin ylläpito ei kaksinkertaistu. Asetuksen teksti: DORA EUR-Lexissä.
Viimeksi tarkistettu: heinäkuu 2026.