DORA pankeille 2026: velvoitteet ja tiekartta

Suomalaiselle pankille DORA tarkoittaa käytännössä viittä työjonoa: puuteanalyysi 5–15 artiklaa vastaan, ICT-sopimusten remontti 30 artiklan pakkoehtojen mukaisiksi, tietorekisterin kokoaminen ja vuosittainen toimitus Finanssivalvonnalle, poikkeamaprosessin viritys 4 tunnin määräaikaan ja säännöllinen hallitusraportointi.

Asetusta (EU) 2022/2554 on sovellettu 17.1.2025 alkaen ilman siirtymäaikaa, joten kysymys ei ole enää valmistautumisesta vaan puutteiden sulkemisesta ja näytön tuottamisesta. Tämä artikkeli on kirjoitettu luottolaitosten ICT-riskienhallinnasta, compliancesta ja sisäisestä tarkastuksesta vastaaville: se kertoo, mitä Finanssivalvonta käytännössä pyytää nähtäväkseen ja missä järjestyksessä työ kannattaa tehdä.

Keskeiset kohdat

• Pankit ovat DORA:n täyden viitekehyksen piirissä – 16 artiklan kevennys ei koske luottolaitoksia.
• Sopimusremontti on suurin yksittäinen työjono: 30 artikla luettelee pakolliset sopimusehdot kaikkiin ICT-palvelusopimuksiin.
• Tietorekisteri on käytännössä ensimmäinen asiakirja, jonka valvoja pyytää nähtäväkseen.
• TLPT koskee toimivaltaisen viranomaisen nimeämiä toimijoita ja toteutetaan vähintään joka kolmas vuosi.
• Hallitusraportointi on 5 artiklan velvoite, ei hyvä hallintotapa: ilman pöytäkirjamerkintää velvoite ei ole täytetty.

Mitä DORA vaatii pankilta?

Luottolaitokset kuuluvat DORA:n 2 artiklan soveltamisalaan ilman kokorajaa, ja niihin sovelletaan täyttä ICT-riskienhallinnan viitekehystä. Käytännössä velvoitteet jakautuvat viiteen pilariin, joista jokainen tuottaa oman näyttöaineistonsa.

Pilari	Artiklat	Mitä valvoja pyytää nähtäväkseen
ICT-riskienhallinta	5–16 art.	Hallituksen hyväksymä viitekehys, toimintokartoitus, kontrollikartta, vuosikatselmointi
Poikkeamien hallinta ja raportointi	17–23 art.	Luokittelusääntö, ilmoitusloki, jälkiarvioinnit
Häiriönsietokyvyn testaus	24–27 art.	Testausohjelma, tulokset, korjaustoimien seuranta, TLPT-dokumentaatio
Kolmannen osapuolen ICT-riski	28–44 art.	Tietorekisteri, sopimusehtojen kattavuus, keskittymäriskin arviointi, exit-suunnitelmat
Uhkatiedon jakaminen	45 art.	Osallistuminen jakelujärjestelyihin, sisäinen käyttö

Yleiskuva kansallisesta valvonnasta on artikkelissa DORA Suomessa ja viitekehyksen artiklakohtainen erittely artikkelissa DORA:n ICT-riskienhallinnan viitekehys.

Vaihe 1: puuteanalyysi, joka tuottaa työjonon

Puuteanalyysi epäonnistuu tyypillisesti siksi, että se tehdään liian karkealla tasolla – “meillä on ISO 27001, joten olemme kunnossa”. Tee se artiklakohtaisesti. Jokaiselle 5–15 artiklan vaatimukselle kirjataan kolme asiaa: mikä dokumentti tai kontrolli sen täyttää, missä näyttö sijaitsee ja kuka omistaa sen.

Tyypilliset puutteet suomalaisessa pankissa ovat toistuvasti samat:

• Hallituksen näyttö ohut. Viitekehys on olemassa, mutta hallituksen hyväksyntäpäätöstä, riskinsietotason määrittelyä tai koulutuskirjanpitoa ei löydy pöytäkirjoista.
• Toimintokartoitus keskeneräinen. 8 artiklan mukainen luettelo liiketoimintatoiminnoista, niitä tukevista ICT-varannoista ja riippuvuuksista on osittainen, jolloin kriittisyysluokittelu ei kestä tarkastelua.
• Palautusta ei ole testattu. Varmuuskopiot otetaan, mutta 12 artiklan edellyttämää palautusta ei ole ajettu läpi tuotantoa vastaavassa laajuudessa.
• Sopimuksista puuttuu ehtoja. Vanhat puitesopimukset eivät sisällä tarkastusoikeuksia, exit-järjestelyjä eivätkä poikkeamien ilmoitusaikoja.
• Konsernin sisäiset palvelut sivuutettu. Emoyhtiön tai sisaryhtiön tuottamat ICT-palvelut ovat DORA:n mielessä kolmannen osapuolen palveluja ja kuuluvat rekisteriin.

Puuteanalyysin tuotos ei ole raportti vaan priorisoitu työjono, jossa jokaisella rivillä on omistaja ja määräpäivä. Se on myös se dokumentti, jonka sisäinen tarkastus ja valvoja lukevat ensimmäisenä.

Vaihe 2: ICT-sopimusten remontti

30 artikla luettelee ehdot, joiden on oltava jokaisessa ICT-palvelusopimuksessa – ja tiukemmat vaatimukset niissä sopimuksissa, jotka tukevat kriittisiä tai tärkeitä toimintoja. Keskeiset ehdot:

1. Palvelun täydellinen kuvaus ja tieto siitä, missä maissa palvelua tuotetaan sekä missä tietoa käsitellään ja säilytetään.
2. Palvelutasot määrällisin tavoittein ja niiden seuranta.
3. Tietoturva- ja tietosuojaehdot, saatavuus, eheys ja luottamuksellisuus.
4. Poikkeamien ilmoittaminen määräaikoineen – tunneissa, ei työpäivissä.
5. Tuki poikkeamatilanteessa sovituin ehdoin.
6. Tarkastus- ja pääsyoikeudet toimijalle, sen tarkastajille ja toimivaltaiselle viranomaiselle.
7. Osallistuminen häiriönsietokyvyn testaukseen, kriittisten toimintojen osalta myös TLPT-testeihin.
8. Alihankinnan ehdot ja ketjun läpinäkyvyys.
9. Irtisanomisoikeudet, irtisanomisajat ja exit-strategia hallittuine siirtymineen.

Työjärjestys kannattaa olla tämä: luokittele sopimukset kriittisyyden mukaan, korjaa ensin kriittisiä toimintoja tukevat, laadi vakioliite muille ja kytke se seuraavaan uusimiskierrokseen. Vakioliite kannattaa laatia yhdessä tietosuojan kanssa, koska GDPR:n 28 artiklan käsittelysopimuksen ehdot menevät osin päällekkäin – ks. käsittelysopimuksen pakolliset ehdot ja valmis käsittelysopimuksen malli. Yksi neuvottelukierros, kaksi sääntelyä.

Sopimusehtojen rinnalla kulkee kaksi asiaa, jotka jäävät usein tekemättä. Keskittymäriskin arviointi (29 art.) edellyttää, että pankki tunnistaa, kuinka moni kriittinen toiminto nojaa samaan palveluntarjoajaan, samaan pilvialueeseen tai samaan alihankintaketjun solmuun. Suomalaisessa pankkikentässä keskittymä syntyy helposti myös yhteisten toimialaratkaisujen kautta, jolloin usea toimija riippuu samasta järjestelmätoimittajasta. Exit-suunnitelma puolestaan on kirjoitettava toteutettavaksi: siitä on käytävä ilmi siirtymäaika, tietojen palautusmuoto, vastuunjako siirtymässä ja se, mihin toiminto siirretään. Suunnitelma, jossa lukee vain “palvelu kilpailutetaan uudelleen”, ei ole exit-suunnitelma.

Sopimusremontin lopputulos syötetään suoraan tietorekisteriin. Kenttä kentältä -malli on artikkelissa DORA-tietorekisteri: malli ja ohje.

Vaihe 3: tietorekisteri ja sen toimitus

Tietorekisteri on 28 artiklan 3 kohdan velvoite ja käytännössä pankin näkyvin DORA-suorite. Se raportoidaan vuosittain Finanssivalvonnalle Euroopan valvontaviranomaisten mallipohjilla, ja Finanssivalvonta toimittaa aineiston edelleen ESA:ille kriittisten ICT-palveluntarjoajien nimeämistä varten.

Pankille ominaisia haasteita on kolme. Ensimmäinen on volyymi: keskisuurellakin luottolaitoksella ICT-palvelusopimuksia on satoja, kun mukaan lasketaan SaaS-tilaukset ja konsernin sisäiset järjestelyt. Toinen on tunnisteet: jokaiselle toimittajalle tarvitaan LEI tai EUID, ja niiden hankinta on käytännössä pisin yksittäinen vaihe. Kolmas on alihankintaketjut, joiden selvittäminen edellyttää toimittajilta tietoa, jota vanhoissa sopimuksissa ei ole velvoitettu antamaan.

Aikatauluta rekisterityö niin, että aineisto on validoitu vähintään kuukautta ennen Finanssivalvonnan ilmoittamaa toimituspäivää. Ensimmäinen validointi paljastaa lähes aina puuttuvia tunnisteita ja ristiriitaisia luokituksia.

Vaihe 4: testaus ja TLPT-valmius

Kaikkien pankkien on ylläpidettävä digitaalisen häiriönsietokyvyn testausohjelmaa (24–25 art.): haavoittuvuusarvioinnit, tunkeutumistestit, verkkoturvallisuuden arvioinnit, lähdekoodin tarkastukset kriittisissä järjestelmissä ja jatkuvuusharjoitukset. Kriittisiä toimintoja tukevat järjestelmät testataan vähintään vuosittain, ja havainnot viedään korjaustoimien seurantaan.

Uhkaperusteinen tunkeutumistestaus (TLPT, 26–27 art.) on eri asia. Se koskee toimivaltaisen viranomaisen nimeämiä toimijoita, se toteutetaan vähintään joka kolmas vuosi, se kohdistuu tuotantoympäristöön ja se perustuu räätälöityyn uhkatiedusteluun. TLPT-testit rakentuvat TIBER-EU-kehyksen periaatteille, ja testaajille on 27 artiklassa omat pätevyys- ja riippumattomuusvaatimukset.

Valmistautumisessa kannattaa muistaa kolme asiaa. TLPT sitoo huomattavasti sisäistä työaikaa – valkoisen tiimin, uhkatiedustelun ja testauksen koordinointi kestää kuukausia. Kriittisten ICT-palveluntarjoajien on osallistuttava testeihin, mikä on kirjattava sopimuksiin etukäteen. Ja testien tulokset sekä korjaussuunnitelmat menevät viranomaisen tietoon, joten korjausten seuranta on osa suoritetta, ei sen jälkihoitoa.

Vaihe 5: hallitusraportointi ja jatkuva valvonta

5 artiklan mukaan ylin hallintoelin vastaa viitekehyksestä. Käytännössä tämä tarkoittaa vakioitua raportointipakettia hallitukselle vähintään neljännesvuosittain:

• ICT-riskiprofiilin muutokset ja riskinsietotason toteutuminen;
• merkittävät ja lähes merkittävät poikkeamat, ilmoitusten määräaikojen toteutuminen;
• testausohjelman tila ja avoimet korjaustoimet;
• kolmannen osapuolen riski: uudet sopimukset, keskittymäriski, exit-valmius;
• tietorekisterin tila ja seuraava toimitus;
• hallituksen oma ICT-riskikoulutus.

Poikkeamaraportoinnin määräajat ja luokittelu on käyty läpi artikkelissa DORA-poikkeamailmoitukset, ja kolmen sääntelyn yhteensovittaminen artikkelissa häiriöilmoitukset: DORA, NIS2 ja GDPR. Jos pankkikonsernilla on toimintaa myös DORA:n ulkopuolella, rajanveto kannattaa dokumentoida – ks. DORA vs NIS2 ja NIS2 Suomessa.

Finanssivalvonnan odotukset on syytä lukea suoraan lähteestä ennen jokaista raportointikierrosta: Finanssivalvonnan sivut sisältävät voimassa olevat ohjeet, raportointikanavat ja aikataulut. Henkilötietojen puolella vastaava kansallinen ohjeistus tulee Tietosuojavaltuutetun toimistolta.

Näytön kokoaminen kolmesta lähteestä – dokumentit, kontrollit ja tapahtumahistoria – on työtä, joka kannattaa keskittää yhteen järjestelmään; vaihtoehdot on vertailtu artikkelissa paras DORA-ohjelmisto. Legiscope hoitaa tietosuojadokumentaation EU-isännöinnissä, jolloin toimittaja- ja alihankkijatiedot pysyvät yhtenäisinä molempien sääntelyjen tarpeisiin.

Usein kysytyt kysymykset

Koskeeko DORA pieniä talletuspankkeja ja osuuspankkeja?

Kyllä. Luottolaitoksiin ei sovelleta 16 artiklan kevennettyä viitekehystä. Suhteellisuusperiaate vaikuttaa toteutuksen yksityiskohtaisuuteen, ei velvoitteiden olemassaoloon.

Onko TLPT pakollinen kaikille pankeille?

Ei. TLPT koskee toimivaltaisen viranomaisen nimeämiä toimijoita, jotka valitaan muun muassa koon, riskiprofiilin ja järjestelmäkriittisyyden perusteella. Kaikkien on kuitenkin ylläpidettävä testausohjelmaa.

Riittääkö EBA:n ulkoistusohjeiden noudattaminen DORA:aan?

Ei sellaisenaan. Aiemmat ulkoistusohjeet kattavat osan 28–30 artiklan vaatimuksista, mutta eivät tietorekisterin muotoa, kriittisten ICT-palveluntarjoajien valvontakehystä eivätkä poikkeamaraportoinnin määräaikoja.

Kuuluvatko konsernin sisäiset ICT-palvelut DORA:n piiriin?

Kyllä. Konsernin sisäiset ICT-palvelujärjestelyt kuuluvat kolmannen osapuolen riskin hallintaan ja merkitään tietorekisteriin omalla tunnisteellaan.

Mistä pankin kannattaa aloittaa, jos työ on kesken?

Artiklakohtaisesta puuteanalyysistä ja hallituksen hyväksyntäpäätöksestä. Ilman niitä muut suoritteet jäävät ilman omistajaa, eikä valvojalle ole näytettävää.

Yhteenveto

Pankin DORA-työ jakautuu viiteen jonoon: artiklakohtainen puuteanalyysi, ICT-sopimusten remontti 30 artiklan mukaiseksi, tietorekisterin kokoaminen ja vuositoimitus Finanssivalvonnalle, testausohjelma ja mahdollinen TLPT sekä vakioitu hallitusraportointi. Kaksi ensimmäistä vievät eniten aikaa, kolmas on näkyvin ja viides ratkaisee, katsotaanko velvoitteet täytetyiksi. Aloita puuteanalyysistä artiklatasolla ja vie jokaiselle riville omistaja ja määräpäivä. Asetuksen teksti: DORA EUR-Lexissä.

Viimeksi tarkistettu: heinäkuu 2026.