DORA-valmius rahoitusalan yhteisöille ja niiden ICT-toimittajille

Rahoitusalan digitaalista häiriönsietokykyä koskevaa asetusta (DORA) on sovellettu 17.1.2025 alkaen. Rahoitusalan yhteisöille valmius tarkoittaa nyt digitaalisen häiriönsietokyvyn toimintamallin ylläpitämistä, ei valmistautumista tulevaan määräaikaan. Teknologiatoimittajille se tarkoittaa asiakkaisiin kohdistuvien vastuiden ymmärtämistä ja sen selvittämistä, sovelletaanko niihin erillistä suoraa valvontajärjestelmää.

Johdon kysymys on käytännöllinen: pystyykö organisaatio selittämään, mitkä rahoituspalvelut riippuvat mistäkin ICT-järjestelmistä, miten häiriöt käsitellään ja mikä näyttö tukee sen palautumisoletuksia? Politiikoilla on merkitystä, mutta ne eivät yksinään vastaa tähän kysymykseen. Johto tarvitsee yhtenäisen näkymän vastuisiin, riippuvuuksiin, sopimuksiin, testeihin, poikkeamiin ja ratkaisemattomiin riskeihin.

Määritä roolisi ennen tarkistuslistan rakentamista

Aloita dokumentoidulla sovellettavuuspäätöksellä kunkin asiaankuuluvan oikeushenkilön osalta. DORAn 2 artikla yksilöi katetut ryhmät ja poikkeukset. Liiketoiminta, joka kuvaa itseään fintech-yritykseksi, startupiksi tai pk-yritykseksi, ei automaattisesti kuulu soveltamisalaan tai ole vapautettu siitä.

Esimerkkejä katetuista rahoitusalan yhteisöistä ovat luottolaitokset, maksulaitokset, sijoituspalveluyritykset ja vakuutusyritykset asetuksen yksityiskohtaisten soveltamisalasääntöjen mukaisesti. Kirjaa sovellettava ryhmä, mahdollinen poikkeus tai vapautus, asianomainen toimivaltainen viranomainen ja johtopäätöksesi perustelut.

Erota toimittajien osalta kolme asemaa:

Toimittaja, joka tukee rahoitusalan kriittistä tai tärkeää toimintoa, ei pelkästään sen vuoksi ole nimetty kriittinen kolmannen osapuolen ICT-palveluntarjoaja. Rahoitusalan yhteisöt arvioivat toimintojensa ja riippuvuuksiensa merkityksen; kriittiset palveluntarjoajat nimetään 31 artiklan mukaisen valvontakehyksen kautta.

Sijainti ei ratkaise toimittajakysymystä. Yhdysvaltalaiseen pilvi- tai ohjelmistotoimittajaan voi kohdistua DORAan liittyviä asiakasvaatimuksia, kun se palvelee EU:n rahoitusalan yhteisöjä. Tämä kaupallinen suhde ei automaattisesti tee siitä kaikkien rahoitusalan yhteisöille asetettujen velvoitteiden alaista.

Myös oikeasuhteisuus edellyttää perusteltua arviointia. 4 artiklassa otetaan huomioon muun muassa koko, yleinen riskiprofiili sekä palvelujen luonne, laajuus ja monimutkaisuus. 16 artikla säätää yksinkertaistetusta ICT-riskienhallintakehyksestä tietyille ryhmille. Nämä eivät ole keskenään vaihdettavia käsitteitä, eikä tavallinen pk-yrityksen asema ole yleinen oikotie. Säilytä kelpoisuusanalyysi soveltamisalapäätöksen yhteydessä.

Tee johdon vastuu näkyväksi

DORAn 5 artiklan mukaan hallinto- ja toimielimellä on perimmäinen vastuu rahoitusalan yhteisön ICT-riskien hallinnasta. Toteutuksen delegointi tietoturvajohtajalle, teknologiatiimille tai ulkoiselle palveluntarjoajalle ei siirrä tätä vastuuta.

Johdon tulisi määrittää, kuka ehdottaa päätöksiä, kuka hyväksyy ne ja kuka tarkistaa, toimiiko toteutus. Toimintamallin tulisi kattaa liiketoiminnan jatkuvuus, poikkeamiin reagointi ja niistä palautuminen, kolmansien osapuolten järjestelyt, budjetti ja tietämys, jota merkityksellinen valvonta edellyttää.

Käytännön suosituksena anna johdolle päätöksiin keskittyvä raportointipaketti valmiusprosentteja näyttävän hallintapaneelin sijaan. Sisällytä siihen:

• Kriittiset tai tärkeät toiminnot, joiden palautumisoletuksia ei ole testattu.
• Merkittävät poikkeamat, vaikutukset asiakkaisiin ja keskeneräiset korjaavat toimenpiteet.
• Toimittajariippuvuudet, joiden sopimukset ovat puutteellisia tai irtautumisvaihtoehdot heikkoja.
• Merkittävät kontrollipuutteet, vastuulliset omistajat ja korjauspäivät.
• Päätökset, jotka edellyttävät rahoitusta, toimittajan vaihtoa tai nimenomaista riskivastetta.

Kussakin puutteessa tulisi erottaa sääntelyvaatimus, nykyinen operatiivinen heikkous ja ehdotettu korjaus. Puuttuva hyväksymismerkintä on eri asia kuin varmuuskopio, jota ei voida palauttaa. Molemmat voivat edellyttää toimia, mutta niillä on eri omistajat ja prioriteetit.

Johdon hyväksyntä korjaussuunnitelmalle ei ole lupa lykätä sovellettavia velvoitteita määrittelemättömästi. Jos puute on olennainen, harkitse välittömiä suojatoimia, eskalointia ja mahdollisia valvontaan liittyviä vaikutuksia pidemmän aikavälin korjauksen rinnalla.

Rakenna ohjelma rahoitusalan toimintojen ympärille

Omaisuusluettelo on välttämätön, mutta häiriönsietokyvyn suunnittelun tulisi alkaa palvelusta, jonka on jatkuttava. Tunnista rahoitusalan toiminto, sen liiketoiminnan omistaja, häiriön seuraukset sekä sitä tukevat järjestelmät ja palveluntarjoajat.

Maksupalvelun osalta kartoita identiteetinhallinta, pilvi-infrastruktuuri, transaktioiden käsittely, valvonta ja toimittajien eskalointi. Ota mukaan vähemmän näkyvät riippuvuudet, kuten DNS, verkkoyhteydet, pääkäyttäjäoikeudet, salausavaimet ja tukityökalut. Vaihtoehtoinen tuotantoympäristö voi olla käyttökelvoton, jos se riippuu samasta vikaantuneesta identiteettipalvelusta.

Tuloksena syntyvän kartan tulisi kytkeä kukin toiminto seuraaviin:

• Tukevat sovellukset, infrastruktuuri, tietovarannot ja ulkoiset palvelut.
• Asiaankuuluvat sopimukset ja palvelujen omistajat.
• Palautumistavoitteet ja niitä tukeva liiketoiminnan vaikutusanalyysi.
• Havaitsemis-, reagointi-, palautumis- ja viestintäjärjestelyt.
• Testit, havainnot ja ratkaisemattomat riippuvuusriskit.

Validoi kartta sekä operatiivisten että liiketoimintatiimien kanssa. Hankintatiedot näyttävät, mitä on ostettu; ne eivät välttämättä näytä, miten palvelu toimii tänään.

Käytä tätä mallia ICT-riskienhallinnan, poikkeamien hallinnan ja niistä ilmoittamisen, häiriönsietokyvyn testauksen ja kolmansien osapuolten ICT-riskien järjestämiseen. DORA sisältää myös säännöksiä vapaaehtoisesta kyberuhkatietojen jakamisesta. Jos osallistutte, määrittäkää jäsenyys, luottamuksellisuus, sallittu käyttö ja käsittelysäännöt sen sijaan, että jakamista pidettäisiin poikkeamatietojen rajoittamattomana vaihtona.

Muunna ICT-riskienhallinta rahoitetuksi työksi

DORAn ICT-riskienhallintaa koskevat säännökset kattavat tunnistamisen, suojaamisen ja ennaltaehkäisyn, havaitsemisen, reagoinnin ja palautumisen, oppimisen sekä viestinnän. Kehyksen on kytkettävä nämä toiminnot toisiinsa sen sijaan, että ne jäisivät erillisiksi politiikkakokoelmiksi.

Aloita puuteanalyysi kartoitetuista toiminnoista. Kysy, suojaavatko käyttöoikeuksien hallinnan kontrollit niiden järjestelmiä, käsitelläänkö haavoittuvuudet, hallitaanko muutoksia, havaitaanko epäilyttävä toiminta ja vastaavatko palautumisjärjestelyt realistisia vikatilanteita. Ota huomioon haitallisten hyökkäysten lisäksi tekniset viat ja operatiiviset virheet.

Luo jokaisesta olennaisesta heikkoudesta korjausmerkintä, joka sisältää omistajan, liiketoimintavaikutuksen, vaaditun toimenpiteen, valmistumisen kriteerit ja näytön sulkemisesta. Riippuvuuksilla on merkitystä: palautusmenettelyjen parantaminen voi edellyttää muutoksia varmuuskopioiden käyttöoikeuksiin, toimittajasitoumuksiin ja henkilöstön koulutukseen ennen kuin onnistunut testi on mahdollinen.

Palautumistavoitteiden tulisi perustua liiketoiminnan tarpeisiin ja vaikutusanalyysiin, ei siihen, mitä toimittajan vakiopalvelutaso sattuu tarjoamaan. Jos tekninen kyvykkyys ei riitä tavoitteen saavuttamiseen, johdon on päätettävä, parannetaanko arkkitehtuuria, muutetaanko palvelujärjestelyä vai arvioidaanko toimintamalli uudelleen. Jatkuvuussuunnitelmaan kirjattu tavoite ei ole näyttöä palautettavuudesta.

Valmistele poikkeamapäätökset ennen häiriötä

DORA edellyttää, että rahoitusalan yhteisöt hallitsevat ICT:hen liittyviä poikkeamia ja ilmoittavat merkittävistä poikkeamista asianomaiselle toimivaltaiselle viranomaiselle. 17–23 artikla luovat kehyksen; sovellettavat tekniset sääntely- ja täytäntöönpanostandardit antavat yksityiskohtaiset luokittelukriteerit, raja-arvot, ilmoitusten sisällön ja menettelyt.

Älä luota yleiseen poikkeamien tarkistuslistaan yksityiskohtaisen ilmoitusaikataulun osalta. Ylläpidä ajantasaista ilmoitusmatriisia, joka yksilöi sovellettavat standardit, viranomaisen ohjeet, toimituskanavan, ilmoitusvaiheet ja määräaikojen laskennan. Nimeä vastuuhenkilö pitämään se ajan tasalla.

Reagointiprosessin tulisi tehdä useista päätöksistä toteutettavia paineen alla:

• Kuka kirjaa havaitsemisen, arvioinnin ja luokittelun aikaleimat?
• Kuka hankkii vaikutustiedot operatiivisilta toiminnoilta ja toimittajilta?
• Kuka päättää, täyttyvätkö merkittävän poikkeaman kriteerit?
• Kuka hyväksyy ja toimittaa ilmoitukset, myös normaalin työajan ulkopuolella?
• Kuka hoitaa asiakasviestinnän ja muut sovellettavat ilmoitukset?

Kirjaa luokittelun perustelut myös silloin, kun poikkeamasta ei ilmoiteta merkittävänä. Puutteellisen alustavan kuvan tulisi käynnistää uudelleenarviointi tietojen tarkentuessa, ei pysyvää oletusta siitä, että tapahtuma on vähäinen.

Toimittajien ilmoitussitoumusten tulisi jättää rahoitusalan yhteisölle riittävästi aikaa arvioida ja täyttää omat velvoitteensa. Ilmoitustehtäviä voidaan ulkoistaa, jos se on sallittua, mutta vastuu säilyy rahoitusalan yhteisöllä.

Jos merkittävä ICT:hen liittyvä poikkeama vaikuttaa asiakkaiden taloudellisiin etuihin, DORA edellyttää rahoitusalan yhteisöjä ilmoittamaan näille asiakkaille ilman aiheetonta viivytystä poikkeamasta ja toimenpiteistä, joihin on ryhdytty sen haitallisten vaikutusten lieventämiseksi. Arvioi erikseen henkilötietojen tietoturvaloukkauksia koskevat velvoitteet ja muut sovellettavat säännöt. Yksi häiriö voi synnyttää useita ilmoituspäätöksiä, joilla on eri vastaanottajat ja oikeudelliset kriteerit.

Testaa oletukset, joihin johto luottaa

Digitaalisen häiriönsietokyvyn testausohjelman tulisi olla oikeasuhteinen ja riskiperusteinen. Haavoittuvuusarvioinnit, skenaarioharjoitukset, tietoturvatestaus ja palautustestit vastaavat eri kysymyksiin; mitään niistä ei pidä pitää muiden yleisenä korvikkeena.

Pöytäharjoitus voi osoittaa, ymmärtävätkö päätöksentekijät eskaloinnin. Se ei voi todistaa, että transaktiotiedot voidaan palauttaa tarkasti. Tunkeutumistestaus voi paljastaa hyödynnettäviä heikkouksia todistamatta, että vaihtoehtoinen toimittaja voi ottaa palvelun hoitaakseen.

Määritä kullekin testille toiminto, skenaario, laajuus, onnistumiskriteerit, tarvittaessa riippumattomuusjärjestelyt ja odotettu näyttö. Säilytä tulokset, havainnot, korjauspäätökset ja uudelleentestauksen tulokset. Tarkista sovellettavat kattavuus- ja tiheysvaatimukset DORAa ja asiaankuuluvia standardeja vasten, mukaan lukien mahdolliset poikkeukset tai yksinkertaistettua kehystä koskevat säännökset.

Uhkiin perustuva penetraatiotestaus (TLPT) on 26 artiklan mukainen erillinen valvontavaatimus valituille rahoitusalan yhteisöille. Se ei ole yleinen velvoite jokaiselle rahoitusalan yritykselle tai ICT-toimittajalle.

Johdon tulisi tarkastella epäonnistuneita oletuksia, ei pelkästään sitä, onko testejä tehty. Jos harjoitus paljastaa, että palautus riippuu yhdestä ylläpitäjästä, joka ei ole tavoitettavissa, lopputulos on toimia edellyttävä operatiivinen riski, ei saavutettu testauksen välitavoite.

Käsittele kolmansien osapuolten riskit palvelun jatkuvuuden kysymyksenä

DORAn mukaan rahoitusalan yhteisö vastaa edelleen velvoitteistaan käyttäessään ICT-toimittajia. 28–30 artikla kytkevät toisiinsa kolmansien osapuolten riskiarvioinnin, sopimusjärjestelyt, seurannan ja irtautumissuunnittelun.

Ylläpidä tietorekisteriä ja operatiivista kokonaiskuvaa

Rahoitusalan yhteisöjen on ylläpidettävä ICT-sopimusjärjestelyjä koskevaa tietorekisteriä vaadituilla yksittäisillä, osittain konsolidoiduilla ja konsolidoiduilla tasoilla. Käytä sen rakenteessa sovellettavia täytäntöönpanostandardeja. Hankintataulukko tai hyväksyttyjen toimittajien luettelo ei automaattisesti riitä.

Täsmäytä rekisteri sopimuksiin, palvelujen omistajuuteen ja riippuvuuskarttoihin. Ylläpidä vaaditut erottelut kriittisiä tai tärkeitä toimintoja tukeville palveluille. Uusi alihankkija, palvelun sijainti tai laajentunut soveltamisala voi muuttaa riskikuvaa, vaikka toimittajan nimi pysyisi samana.

Tarkasta sopimukset todellista palvelua vasten

Arvioi sovellettavat sopimusvaatimukset, mukaan lukien palvelukuvaukset, sijainnit, tietosuoja, pääsy tietoihin ja niiden palauttaminen, poikkeamiin liittyvä apu, yhteistyö, irtisanomisoikeudet ja palvelutasot. Kriittisiä tai tärkeitä toimintoja tukevat järjestelyt edellyttävät lisäsäännöksiä, mukaan lukien asiaankuuluvat raportointi-, jatkuvuus-, pääsy-, tarkastus-, auditointi- ja irtautumisjärjestelyt.

Oikeudellisten, hankinta-, teknologia- ja liiketoiminnan omistajien tulisi tarkastella näitä yhdessä. Sopimukseen kirjattua auditointioikeutta voi olla vaikea käyttää käytännössä; luvattu palautumisjärjestely ei välttämättä kata asiakkaan koko palveluketjua. Tunnista nämä rajoitukset ennen järjestelyn hyväksymistä.

Tarkastele keskittymää ja irtautumiskykyä

Keskittymäriski ei rajoitu useiden palvelujen ostamiseen yhdeltä yritykseltä. Eri toimittajat voivat tukeutua samaan pilvialustaan, alueeseen, verkkoon tai alihankkijaan. Arvioi korvattavuus, siirron monimutkaisuus ja yhteisen vikaantumisen seuraukset.

Irtautumissuunnitelman tulisi käsitellä tietomuodot, tietojen poiminta, pääsy, siirron riippuvuudet, siirtymävaiheen tuki, poistaminen ja jatkuvuus siirron aikana. Kriittisten tai tärkeiden toimintojen osalta käsittele irtautumisen testausta ja katselmointia asiasisältöisenä työnä, ei asiakirjan kirjoitusharjoituksena.

Toimittajat voivat valmistella yhdenmukaisen varmistuspaketin, joka sisältää palvelun laajuuden, vastuurajat, poikkeamayhteyshenkilöt, jatkuvuusnäytön, alihankintatiedot ja sopimuskannat. Asiakaskohtaiset vaatimukset on silti tarkastettava; sertifikaatti ei korvaa niitä.

Ymmärrä, missä DORA ja NIS2 kohtaavat

DORA on suoraan sovellettava EU-asetus. NIS2 on kansallisella lainsäädännöllä täytäntöön pantava direktiivi, jonka soveltaminen riippuu toimialasta, koosta, palvelusta ja sisällyttämissäännöistä. Sen kansallisen täytäntöönpanon määräaika oli 17.10.2024; organisaatioiden on tarkasteltava sovellettavaa kansallista täytäntöönpanoa sen sijaan, että ne olettaisivat yhden samanlaisen toimintajärjestelmän.

DORAn 1 artiklan 2 kohta yhdessä NIS2-direktiivin 4 artiklan kanssa luo toimialakohtaisen suhteen katetuille rahoitusalan yhteisöille asiaankuuluvilla alueilla. Älä tulkitse tätä ohjeeksi monistaa vastaavia riskienhallinnan ja poikkeamista ilmoittamisen kontrolleja. Älä myöskään oleta, että se poistaa velvoitteet kaikilta rahoitusalan konsernin yhtiöiltä tai sen toimitusketjulta.

Pankkia palveleva hallinnoitujen palvelujen tarjoaja voi tarvita oman NIS2-arviointinsa samalla kun se täyttää DORAan liittyvät sopimukselliset sitoumukset. Yhteisökohtaisessa velvoitematriisissa tulisi kirjata oikeusperusta, soveltamisala, viranomainen, ilmoitusreitti ja vaadittu näyttö.

Yhteiset kontrollit voivat tukea DORAa, ISO 27001:tä, tietosuojavelvoitteita ja asiakkaiden varmistustarpeita, kun soveltamisala ja näyttö vastaavat toisiaan. Hyödynnä käyttöoikeuskatselmointia tai palautustestiä, kun se aidosti tukee useita vaatimuksia, ja säilytä samalla rahoitusalan erityispiirteet. ISO 27001 -sertifikaatti ei osoita DORAn noudattamista.

Myös täytäntöönpano eroaa. Rahoitusalan yhteisöihin kohdistuvat DORAn valvontavaltuudet ja seuraamukset riippuvat sen säännöksistä ja sovellettavista kansallisista toimenpiteistä; nimetyillä kriittisillä palveluntarjoajilla on erillinen valvontajärjestelmä. Älä budjetoi riskiä oletetun yleisen DORA-sakon varaan. Arvioi asiaankuuluva oikeudellinen altistuminen ja riittämättömän häiriönsietokyvyn operatiiviset seuraukset.

Esimerkki: maksupalvelun riippuvuuksien katselmointi

Tarkastellaan havainnollistavaa maksulaitosta, joka käyttää pilvialustaa, identiteetintarjoajaa ja ulkoistettua valvontapalvelua. Oletetaan, että laitos kuuluu DORAn soveltamisalaan ja maksujen toteuttaminen on luokiteltu kriittiseksi tai tärkeäksi toiminnoksi.

Ensimmäinen katselmointi löytää kolme heikkoutta: tuotanto- ja palautusympäristöillä on sama identiteettiriippuvuus; valvontatoimittajan poikkeamien eskalointiprosessi on epäselvä; ja pilvipalvelun irtautumissuunnitelmassa mainitaan vaihtoehtoinen palveluntarjoaja osoittamatta tietojen poimintaa ja siirtoa.

Johto käynnistää kolme toisiinsa liittyvää työpakettia:

Liiketoiminnan omistaja tarkistaa, ovatko maksujen palautumistavoitteet edelleen saavutettavissa. Compliance-toiminto varmistaa, että ilmoitusmenettelyt ja rekisterimerkinnät vastaavat järjestelyjä. Johto hyväksyy tarvittavan rahoituksen ja tarkastelee jäljellä olevia rajoituksia.

Tämä esimerkki ei sellaisenaan osoita vaatimustenmukaisuutta. Se näyttää, miten yksi toiminto voi tuoda esiin päätöksiä, jotka jäisivät piiloon erillisissä politiikka-, toimittaja- ja testaustarkistuslistoissa.

Luo näyttöön perustuva katselmointirytmi

DORAssa ei ole yleistä sertifiointiprosessia, joka korvaisi jatkuvat velvoitteet. Riippumaton varmistus voi antaa johdolle tietoa, mutta valmius on osoitettava toimivilla kontrolleilla, tallenteilla ja tarvittaessa vuorovaikutuksella valvojan kanssa.

Käytännön seuraava askel on valita yksi kriittinen tai tärkeä toiminto ja koota sen soveltamisalapäätös, riippuvuuskartta, riskiarvio, sopimukset, poikkeamamenettelyt, testitulokset ja avoimet toimenpiteet. Tarkastele, kertovatko nämä tallenteet johdonmukaisen tarinan.

Secani tukee tätä työnkulkua mallintamalla järjestelmiä ja palveluja, kytkemällä riippuvuuksia ja pitämällä vaatimukset, näytön, vastuuhenkilöt, tehtävät ja katselmointipäätökset samassa kontekstissa. Lataa olemassa oleva aineisto asiaankuuluvien kohteiden yhteyteen, muuta puutteet osoitetuksi työksi ja säilytä nimenomainen ihmisen hyväksyntä tekoälyavusteisille ehdotuksille ja johtopäätöksille.

Laajenna ensimmäisestä toiminnosta, kun omistajuus ja näyttöpolut ovat selvät. Johdon tulisi nähdä, mitä on osoitettu, mikä on vielä epävarmaa ja mikä päätös tarvitaan seuraavaksi.