DORA-ohjelmiston valinta on finanssitoimijan oma hankintapäätös, jonka pitää perustua soveltuvaan toimijaluokkaan, nykyisiin järjestelmiin ja todellisiin puutteisiin. EU:n DORA-asetusta (EU) 2022/2554 on sovellettu 17.1.2025 alkaen. Se sisältää ICT-riskienhallinnan, poikkeamien, testauksen ja kolmansien osapuolten riskien velvoitteita; kaikki sen yksityiskohdat eivät koske kaikkia samalla tavalla. Tässä ostajan oppaassa näytetään, miten vaatimukset muutetaan tarkistettaviksi tuotekokeiksi ilman väitettä yhdestä markkinoiden parhaasta tuotteesta. Suomen soveltamista käsittelee erikseen DORA Suomessa.
Mitä DORA vaatii Suomessa?
DORA (Digital Operational Resilience Act) yhtenäistää finanssisektorin digitaalisen häiriönsietokyvyn vaatimukset. Suomessa asetus koskee asetuksen 2 artiklan soveltamisalaan kuuluvia finanssiyhteisöjä, esimerkiksi pankkeja, vakuutusyhtiöitä ja sijoituspalveluyrityksiä; ICT-palveluntarjoajien erityinen valvontajärjestely on erotettava finanssiyhteisöiden omista velvoitteista. Asetusta on sovellettu 17.1.2025 alkaen; yksittäiset tekniset standardit ja valvonnan menettelyt on tarkistettava ajantasaisina. Yksityiskohdat kansallisesta valvonnasta: DORA Suomessa.
DORA rakentuu viidestä pilarista: ICT-riskienhallinta, ICT-poikkeamien hallinta ja raportointi, häiriönsietokyvyn testaus, kolmannen osapuolen ICT-riskien hallinta ja tiedon jakaminen. Hankkijan on jaettava nämä vaatimukset nykyisten työkalujen ja uusien tarpeiden kesken. Perusteet: DORA:n ICT-riskienhallinta ja ICT-sopimusjärjestelyjen tietorekisteri.
Vertailukriteerit DORA-ohjelmistolle
| Kriteeri | Miksi ratkaisee | Vähimmäisvaatimus |
|---|---|---|
| ICT-riskienhallinta | DORA:n ydinvelvoite | Riskirekisteri ja kontrollit |
| ICT-sopimusjärjestelyjen tietorekisteri | Vuosittain Finanssivalvonnalle | Standardoitu, vietävä muoto |
| Poikkeamaraportointi | Määräaikainen ilmoitus | Ohjattu luokittelu ja ilmoitus |
| Kolmannen osapuolen riskit | ICT-toimittajien valvonta | Sopimus- ja toimittajarekisteri |
| TLPT-testaus | Viranomaisen nimeämille toimijoille | Testauksen dokumentointi |
| Auditointijälki | Valvonta edellyttää näyttöä | Versiointi ja lokit |
Markkinan vaihtoehdot
Vaihtoehtoina voi olla finanssialaan keskittynyt työkalu, nykyisen GRC-järjestelmän laajennus tai usean erikoistyökalun kokonaisuus. Pyydä jokaiselta tarjoajalta sama demonstraatio ja kirjallinen rajaus siitä, mitkä DORA:n artiklat tai tietomuodot sen tuote todella tukee. Tuotenimi tai moduulin otsikko ei ole näyttö vientimuodosta, ajantasaisesta sääntelystä tai käyttöönoton työmäärästä. Vertaa myös nykyisen hankinta- ja turvallisuusjärjestelmän käyttöä, jos tietojen omistajat voivat ylläpitää niitä luotettavasti.
Monelle finanssitoimijalle DORA, NIS2 ja GDPR limittyvät. GDPR:n sisäinen dokumentointi ja DORA:n viranomaisilmoitus edellyttävät erillistä arviointia.
DORA:n viisi pilaria ja ohjelmiston tehtävä kussakin
DORA-asetuksen (EUR-Lex) rakenne perustuu viiteen pilariin. Organisaatio tarvitsee menettelyn jokaiseen soveltuvaan osa-alueeseen. Kaiken ei tarvitse olla yhdessä tuotteessa, jos tiedot, vastuut ja viennit toimivat yhdessä.
| Osa-alue | Sisältö | Hankinnassa kokeiltava tuki |
|---|---|---|
| 1. ICT-riskienhallinta | Hallintakehys, johdon vastuu, kontrollit | Riskirekisteri, politiikat, hyväksynnät, johdon raportointi |
| 2. ICT-poikkeamien hallinta ja raportointi | Havaitseminen, luokittelu, viranomaisilmoitus | Ohjattu luokittelu ja määräaikainen ilmoitusvirta |
| 3. Digitaalisen häiriönsietokyvyn testaus | Soveltuvat testit, TLPT nimetylle joukolle | Testausohjelman ja tulosten dokumentointi |
| 4. Kolmannen osapuolen ICT-riskit | ICT-sopimusjärjestelyt ja toimittajat | Tietorekisteri ja toimittajien seuranta |
| 5. Tiedon jakaminen | Vapaaehtoinen uhkatietojen jakaminen | Tarvittaessa osallistumisen dokumentointi |
Ensimmäinen pilari korostaa johdon vastuuta: DORA:ssa hallitus vastaa ICT-riskienhallinnan kehyksestä, joten hyväksyntöjen ja katselmusten kirjaaminen on osa vaatimustenmukaisuutta. Perusteet: DORA:n ICT-riskienhallinta.
ICT-sopimusjärjestelyjen tietorekisteri
DORA:n konkreettinen tietovaatimus on ICT-sopimusjärjestelyjen tietorekisteri (register of information), joka toimijan on ylläpidettävä ICT-palveluntarjoajien kanssa tehdyistä sopimusjärjestelyistä DORA:n 28 artiklan 3 kohdan mukaan. Rekisteri asetetaan toimivaltaisen viranomaisen saataville pyynnöstä; EU-tason vuosittainen tiedonkeruu ja kansalliset toimitusohjeet on tarkistettava erikseen. Rekisteriin kirjataan muun muassa palveluntarjoajat, sopimukset, palvelut, kriittisiä tai tärkeitä toimintoja tukevat järjestelyt sekä alihankintaketjut. Muoto on yhtenäistetty EU-tasolla, joten myös taulukon tietomallin ja muunnoksen toimivuus on testattava ennen raportointia. Jos rekisteri hoidetaan ohjelmistolla, kokeile sen tietojen kattavuus, vienti ja auditointihistoria. Yksityiskohdat: tietorekisterin mallia käsittelevä opas.
TLPT-testaus – viranomaisen nimeämille toimijoille
DORA edellyttää soveltuvia häiriönsietokykytestejä. Uhkatiedusteluun perustuva TLPT koskee toimivaltaisen viranomaisen nimeämiä finanssiyhteisöjä asetuksen 26 artiklan kriteerien mukaan (Threat-Led Penetration Testing, TLPT). TLPT jäljittelee todellisia hyökkääjiä ja kohdistuu tuotantojärjestelmiin, joten se vaatii huolellisen suunnittelun, laajuuden määrittelyn ja tulosten dokumentoinnin viranomaista varten. Ohjelmiston tehtävä on hallita testausohjelmaa, kirjata havainnot ja seurata korjaustoimenpiteitä. Testaustyypit ja soveltamiskynnykset: DORA:n häiriönsietokyvyn testaus ja TLPT.
Käyttöönoton vaiheet finanssitoimijalle
DORA:aa on sovellettu 17.1.2025 alkaen. Työ etenee tyypillisesti näin: (1) soveltuvuuden ja kriittisten toimintojen kartoitus, (2) ICT-riskienhallinnan kehyksen ja johdon vastuiden vahvistaminen, (3) ICT-sopimusjärjestelyjen tietorekisterin kokoaminen ja sopimusaukkojen korjaus, (4) poikkeamien luokittelu- ja ilmoitusprosessin määrittäminen, (5) testausohjelman ja mahdollisen TLPT:n suunnittelu sekä (6) jatkuvan seurannan ja vuosiraportoinnin vakiinnuttaminen. Vaikein vaihe riippuu lähtötilanteesta; perusta järjestys todettuun puutteeseen.
DORA, NIS2 ja GDPR saman tapahtuman arvioinnissa
Finanssitoimijaa voivat koskea samanaikaisesti DORA, NIS2 ja GDPR. Yksi ICT-poikkeama voi vaatia usean sääntelyn arviointia, mutta NIS2:n ja DORA:n päällekkäisyyteen sovelletaan erityissääntelyn rajausta; ilmoituksia ei tule olettaa kolmea automaattisesti. Tapaus voi johtaa esimerkiksi DORA:n merkittävän ICT-poikkeaman ilmoituksen toimivaltaiselle viranomaiselle, NIS2:n soveltuvuuden tarkistukseen sekä – jos henkilötiedoille on sattunut loukkaus ja ilmoituskynnys täyttyy – GDPR:n ilmoitukseen. Määräajat, vastaanottajat ja kynnykset eroavat toisistaan, joten yhtenäinen poikkeamien luokittelu on käytännön edellytys virheettömälle raportoinnille. Vertailu: DORA:n poikkeamaraportointi ja sääntelyjen rajaus. Pankkien näkökulma: DORA-vaatimustenmukaisuus pankeille.
Hintojen ja kokonaiskustannusten vertailu
DORA ei määrää ohjelmiston hintaa, eikä tällä sivulla ole varmennettua markkinahinta-aineistoa. Pyydä tarjoukset samoilla oletuksilla: finanssiyhteisöiden määrä, käyttäjät, ICT-sopimukset, tietorekisterin vienti, poikkeamien määrä, auditointitietojen säilytys ja integraatiot. Erottele lisenssi, käyttöönotto, tietojen siivous, koulutus, ylläpito ja poistuminen. Kysy myös, kuuluuko sääntelymuodon päivitys sopimukseen vai lisätyöhön.
Vertaile vaihtoehtoa nykyjärjestelmillä. Jos hankinta pitää jo sopimukset ja turvallisuustiimi riskit toisessa palvelussa, uusi työkalu voi tarvita kalliin kaksisuuntaisen integraation. Toisaalta erillinen taulukko voi olla riittävä, jos sopimuksia on vähän ja omistaja pystyy todistamaan päivitysprosessin. Hankintapäätös perustuu näin mitattuihin aukkoihin, ei lähteettömään väitteeseen 70–90 prosentin säästöstä tai tietystä sakon odotusarvosta. GDPR-ohjelmiston kustannusopas voi auttaa yleisen tarjouspyynnön rakenteessa, mutta eri sääntelyn lisenssejä ei pidä rinnastaa ilman samanlaista laajuutta.
Kolmannen osapuolen ICT-riskit – kriittiset palveluntarjoajat
DORA:n neljäs pilari kohdistuu ICT-palveluntarjoajiin, ja se on monelle toimijalle työläin. Finanssitoimija ei voi ulkoistaa vastuutaan pois: vaikka pilvipalvelu tai konesalitoimittaja hoitaisi tekniikan, häiriönsietokyvystä vastaa edelleen valvottava toimija. Käytännössä tämä edellyttää, että ICT-sopimukset sisältävät 30 artiklan 2 kohdan yleiset ehdot ja kriittistä tai tärkeää toimintoa tukevat sopimukset myös 30 artiklan 3 kohdan lisäehdot, kuten laajemmat auditointi- ja irtautumisjärjestelyt, että kriittisiä tai tärkeitä toimintoja tukevat palveluntarjoajat on tunnistettu ja että keskittymäriskit on arvioitu. Sopimusjärjestelyt kuvataan tietorekisterissä, joten sopimushallinta ja rekisteri kannattaa pitää samassa järjestelmässä. Jos järjestelmä tarjoaa tietorekisterin vientiä, kokeile sitä aidolla testiaineistolla ja tarkista, mitkä kentät on edelleen koottava käsin.
EU:n valvontaviranomaiset voivat nimetä kriittisiä ICT-palveluntarjoajia EU-tason valvontaan. Tämä ei poista valvottavan toimijan omaa vastuuta, mutta korostaa sitä, että toimittajatietojen on oltava täydelliset ja ajantasaiset. Ostajan kannattaa kokeilla, helpottaako järjestelmä tietojen jatkuvaa ylläpitoa.
ICT-poikkeamien luokittelu käytännössä
DORA:n toinen pilari edellyttää, että ICT-poikkeamat havaitaan, luokitellaan ja merkittävistä poikkeamista ilmoitetaan toimivaltaiselle viranomaiselle. Luokittelu perustuu vaikutukseen: kuinka monta asiakasta ja liiketointa poikkeama koskee, kuinka pitkä on palvelukatko, kuinka laaja on maantieteellinen ulottuvuus ja mikä on tietojen menetyksen sekä taloudellisten ja maineeseen liittyvien vaikutusten suuruus. Näiden kriteerien perusteella arvioidaan, ylittyykö merkittävyyskynnys ja käynnistyykö ilmoitusvelvollisuus. Luokittelun on oltava johdonmukainen ja jäljitettävä, koska sama tapaus voidaan joutua perustelemaan valvojalle jälkikäteen. Ohjelmisto voi auttaa kokoamaan luokittelun lähtötiedot ja versiot; varmista erikseen, tuottaako kyseinen tuote ajantasaisen ilmoitusmuodon. Myös työkalun käytössä nimetty asiantuntija hyväksyy luokittelun ja korjaa puuttuvat tiedot. Koska merkittävän poikkeaman ilmoitus on vaiheistettu – alustava ilmoitus, väliraportti ja loppuraportti – prosessin on kyettävä seuraamaan saman tapauksen etenemistä alusta loppuun.
Näin valitset DORA-ohjelmiston – tarkistuslista
Vaihtoehtoja kannattaa arvioida seuraavia kysymyksiä vasten: (1) Mitä soveltuvia osa-alueita työkalu kattaa ja mitkä jäävät nykyisiin järjestelmiin? (2) Tuottaako se standardoidun ICT-sopimusjärjestelyjen tietorekisterin toimivaltaisen viranomaisen vaatimassa muodossa? (3) Ohjaako se ICT-poikkeamien luokittelua ja määräaikaista ilmoitusta? (4) Tukeeko se testausohjelmaa ja viranomaisen nimeämille toimijoille TLPT:n dokumentointia? (5) Sisältääkö se sopimus- ja toimittajarekisterin auditointioikeuksineen? (6) Voiko samat poikkeamatiedot palvella myös NIS2- ja GDPR-raportointia? (7) Onko versiointi ja auditointijälki riittävä valvontaa varten ja sijaitseeko data EU:ssa? Priorisoi todetut puutteet vaikutuksen, lakisääteisen velvoitteen ja korjausajan perusteella; pelkkä näyttävä käyttöliittymä ei nosta tietojen laatua. Yleiskuva vaatimuksista: DORA-vaatimustenmukaisuuden opas.
Yleisimmät sudenkuopat käyttöönotossa
Hankinnassa kannattaa testata seuraavat mahdolliset virheet. Ensimmäinen on ICT-sopimusjärjestelyjen tietorekisterin aliarviointi: sopimustiedot ovat hajallaan hankinnassa, taloushallinnossa ja IT:ssä, ja niiden kokoaminen määrämuotoon vie odotettua kauemmin. Toinen on poikkeamien luokittelun epäjohdonmukaisuus, kun kriteerit eivät ole kirjattuina työkaluun. Kolmas on kolmannen osapuolen sopimusehtojen puutteet – vanhoista sopimuksista puuttuvat usein auditointioikeudet ja irtautumisstrategiat, jotka DORA edellyttää. Neljäs on johdon vastuun jääminen muodolliseksi: hyväksynnät ja katselmukset on tehtävä ja kirjattava, ei vain oletettava. Ohjelmisto voi auttaa näyttämään puutteet ja seuraamaan korjausta, jos omistajat kirjaavat tiedot oikein.
Kolme näyttökoetta ennen ostamista
Ensimmäinen koe koskee tietorekisteriä. Luo kuvitteellinen finanssiyhteisö, jolla on yksi pilvisopimus, yksi alihankintaketju ja palvelu, joka tukee kriittistä tai tärkeää toimintoa. Syötä sopimus tunnisteineen, toimittajayhteydet, palvelun luokka ja muut tiedot, joita täytäntöönpanoasetuksen (EU) 2024/2956 vakiomallit vaativat. Pyydä ulosvientiä ja tarkista se teknisen tiedonkeruun vaatimuksia vasten. Esittele toimittajalle tahallaan puuttuva tunniste; katso, antaako ohjelma ymmärrettävän virheen vai tuottaako se muodollisesti valmiin mutta puutteellisen paketin. Rekisterin tarkka termi on ICT-palvelujen sopimusjärjestelyjä koskeva tietorekisteri, ei yleinen lista kaikista tietojärjestelmistä.
Toinen koe on merkittäväksi epäilty ICT-poikkeama. Syötä palvelukatkon alkaminen, havainto, alustava asiakkaiden määrä, maantieteellinen vaikutus ja palautumisen vaihe. Pyydä järjestelmää näyttämään, mitkä luokittelukriteerit ovat ratkaisematta ja kuka hyväksyi johtopäätöksen. Kokeile ilmoituksen alku-, väli- ja loppuvaihetta käyttäen toimivaltaisen viranomaisen ajantasaisia ohjeita. Tuotteen väite ”DORA-yhteensopiva” ei yksin osoita, että käytössä on viimeisin lomake tai lähetyskanava. Poikkeamailmoitusten tarkempi opas auttaa muodostamaan testiaineiston.
Kolmas koe koskee sopimuksen muutosta. Kriittistä toimintoa tukeva palvelu siirtyy uuteen alihankintaketjuun. Tarkista, yhdistääkö työkalu tämän tietorekisterin riviin, sopimuksen auditointiehtoihin, keskittymäriskin arviointiin ja mahdolliseen irtautumisvaihtoehtoon. Seuraa, säilyykö vanha päätös versiohistoriassa. Ilman historiatietoa on vaikea osoittaa, millä tiedoilla johto hyväksyi aiemman järjestelyn.
Vastuunjako testauksessa ja viranomaisraportoinnissa
Kaikki finanssiyhteisöt eivät tee TLPT:tä. Toimivaltainen viranomainen tunnistaa asetuksen 26 artiklan perusteella ne, joilta vaaditaan uhkatiedusteluun perustuva tunkeutumistestaus. Tavallinen häiriönsietokyvyn testausohjelma on eri velvoite. Jos tarjoaja ilmoittaa ”TLPT-moduulin”, kysy, hoitaako se vain aikataulun ja havaintojen dokumentoinnin vai myös varsinaisen testipalvelun. Ohjelmisto ei itsessään korvaa hyväksyttyä testaajaa, sovittua laajuutta tai viranomaisen mahdollisia ohjeita. Testauksen erillinen opas avaa rajauksen.
Johdon vastuu kohdistuu ICT-riskienhallinnan kehykseen ja sen seurantaan. Hyvä työkalu tuo päätöksen pohjaksi riskin, puutteen, vaihtoehdot ja toimenpiteen omistajan. Vihreä status ilman perustelua ei riitä. Dokumentoi myös päättämättä jäänyt asia ja syy, miksi toimintaa jatketaan korjausaikana. Tämä on käytännöllinen hallintatapa, ei väite siitä, että DORA vaatisi juuri yhden ohjelmiston tiettyä hyväksymispainiketta.
Kun poikkeama koskee henkilötietoja, kirjaa GDPR:n erillinen riskikynnys ja mahdollinen ilmoitus samalle tapahtumalle ilman, että aikarajat sekoittuvat. DORA:n ja NIS2:n mahdollinen päällekkäisyys arvioidaan säädösten erityissäännösten mukaan. Sääntelyjen rajanveto auttaa tunnistamaan kysymykset, mutta oman toimivaltaisen viranomaisen ajantasainen ohje ratkaisee raportoinnin kanavan. DORA:n tietorekisteri-, ilmoitus- tai TLPT-toimintoa ei pidä olettaa GDPR-työkalusta.
Lähteet: DORA-asetus (EU) 2022/2554, tietorekisterin tekninen vakiomalli ja Euroopan valvontaviranomaisten DORA-aineisto. Tuoteominaisuudet ja hinta vahvistetaan tarjouksesta.
Sopimusrekisterin tietojen omistajuus
Tietorekisterin laatu riippuu ensisijaisesti sopimus- ja palvelutiedoista. Hankinta tietää usein sopimuksen osapuolet ja voimassaolon, turvallisuustiimi tietää ICT-riippuvuudet ja liiketoiminta tietää kriittisen toiminnon. Nimeä jokaiselle kenttäryhmälle lähde ja tarkistaja. Jos ohjelmisto kopioi vanhan sopimuskansion sellaisenaan, puuttuva toimittajatunniste tai epäselvä palveluluokitus vain siirtyy uuteen näkymään. Koevienti paljastaa ongelman aikaisemmin kuin vuotuinen tiedonkeruu.
Hahmottele kuvitteellinen esimerkki: pankki käyttää samaa konsernitoimittajaa tunnistautumiseen ja analytiikkaan kahdella eri sopimuksella. Tietorekisterissä pitää erottaa sopimusjärjestelyt, niihin liittyvät palvelut ja tuetut toiminnot. Jos analytiikka ei tue kriittistä toimintoa mutta tunnistautuminen tukee, tämä ero vaikuttaa arvioon. Kysy tarjoajalta, voiko sama toimittaja esiintyä oikein useassa järjestelyssä ilman, että tieto monistetaan ristiriitaisesti. Tarkista myös, miten alihankintaketjun muutos näkyy historiassa.
Viranomaisen pyytämä tai vuosittain kerättävä tieto tulee tuottaa sovellettavan teknisen mallin mukaan. Vuoden 2025 tai 2026 yksittäistä toimituspäivää ei pidä kovakoodata tähän yleiseen ostajan oppaaseen, sillä kansalliset ohjeet voivat muuttua. Pyydä toimittajaa osoittamaan, miten se päivittää mallin, kuka testaa vientituloksen ja miten virheet korjataan ennen toimitusta. Tietorekisterin mallia käsittelevä opas auttaa kysymään oikeat kenttäkysymykset.
Tietojen laatuun kannattaa varata erillinen hyväksymisvaihe. Jos sopimuksen nimi, palveluntuottajan tunniste tai kriittisen toiminnon luokitus on epäselvä, ohjelma ei voi päätellä oikeaa arvoa luotettavasti pelkästä PDF:stä. Nimeä hankinnan, riskienhallinnan ja liiketoiminnan tarkistajat ja näytä heille juuri ne kentät, joita he voivat vahvistaa. Kun kaksi yksikköä antaa ristiriitaisen vastauksen, säilytä molemmat lähteet ja ratkaisu perusteluineen. Vasta hyväksytty tieto viedään viranomaisen edellyttämään muotoon. Näin ostopäätös huomioi myös organisaation työn, jota automaatiolupaus ei poista.
Vastaavasti poikkeamailmoituksen laatua voidaan koestaa syöttämällä muuttuva tapaus: vaikutusalue laajenee ensimmäisen viestin jälkeen ja yksi toiminto palautuu ennen väliraporttia. Järjestelmän pitää säilyttää, mitä tiedettiin missäkin vaiheessa, eikä vain viimeistä lukua. Tarjoajalta kysytään, mitä tapahtuu, jos tieto korjataan jo lähetetyn ilmoituksen jälkeen ja miten uusi raportti yhdistyy alkuperäiseen tunnisteeseen. Toimivaltainen viranomainen, luokittelukynnys ja aikarajat tarkistetaan soveltuvista DORA:n teknisistä säännöistä sekä kansallisista ohjeista. Käyttöliittymän laskuri ei ole oikeuslähde.
Käyttöönotto ilman kadotettua päätöshistoriaa
Kun tiedot tuodaan vanhasta GRC-järjestelmästä, vie muutakin kuin viimeinen riskiluokka. Säilytä arvioinnin päivä, hyväksyjä, hyväksymisen peruste, avoin korjaustoimi ja linkki lähdeaineistoon. Tuonti kannattaa kokeilla pienellä otoksella, jossa on sekä yksinkertainen ICT-sopimus että usean alihankkijan ketju. Vertaa sitten uutta rekisteririviä allekirjoitettuun sopimukseen ja toiminnon omistajan vahvistukseen. Jos vain nimi siirtyi oikein, organisaatio ei vielä hallitse DORA:n tietorekisterin sisältöä.
Sovi käyttöönotossa myös, mistä järjestelmästä tieto muutetaan jatkossa. Jos hankinta päivittää sopimuksen alkuperäiseen palveluunsa mutta uusi DORA-työkalu pysyy erillään, raportointi vanhenee heti ensimmäisestä muutoksesta. Automaattinen integraatio on yksi vaihtoehto; nimetty muutosilmoitus ja säännöllinen täsmäytys voi olla toinen. Testaa prosessi sopimusmuutoksella ennen tuotantokäyttöä ja nimeä ristiriidan ratkaiseva henkilö. Finanssiyhteisö vastaa tietojen paikkansapitävyydestä, vaikka palveluntoimittaja toimittaisi vientitiedoston.
Poikkeamademossa kannattaa tuoda mukaan lokitietojen säilyttämistä ja tulkintaa koskeva todellinen sisäinen menettely. Työkalu ei voi päätellä palvelun vaikutusta lokiriveistä ilman omistajan selitystä. Samalla järjestelmäriippuvuuksien kartta auttaa osoittamaan, mitä kriittistä toimintoa ICT-palvelu tukee. Pyydä tarjoajaa näyttämään, miten nämä lähteet liitetään päätökseen ilman että arkaluonteinen lokiaineisto kopioidaan tarpeettomasti.
Usein kysytyt kysymykset
Paljonko DORA-ohjelmisto maksaa?
Tähän ei ole luotettavaa yleishintaa. Pyydä tarjouksessa eritellyt lisenssi-, käyttöönotto-, vienti-, integraatio- ja tukikulut. TLPT-testauksen oma palvelu voi olla erillinen hankinta; ohjelmiston kyky hallita sen dokumentteja on eri asia.
Riittääkö olemassa oleva GRC-työkalu DORA:aan?
Mahdollisesti. Koesta nykyisen työkalun tietorekisterin kentät, ajantasainen vienti, poikkeamien luokittelu ja päätöshistoria. Jos se ei kata tarvittavaa osaa, selvitä lisämoduuli tai muu menettely ilman oletusta, että yksi tietty tuoteperhe on välttämätön.
Kuka valvoo DORA:aa Suomessa?
Finanssivalvonta valvoo asetuksen soveltumista omiin valvottaviinsa; tarkista yksittäisen toimijan toimivaltainen viranomainen. Valvonta keskittyy ICT- ja tietoturvariskien hallintaan, poikkeamien ilmoitusprosesseihin ja ICT-palveluntarjoajien valvontaan. Lue DORA Suomessa.
Mikä on DORA:n ICT-sopimusjärjestelyjen tietorekisteri?
DORA:n 28 artiklan 3 kohdan rekisteri kokoaa ICT-palveluntarjoajien kanssa tehdyt sopimusjärjestelyt. Se on annettava toimivaltaiselle viranomaiselle pyynnöstä, ja vuotuinen tiedonkeruu seuraa viranomaisohjeita. Rekisteri kattaa palveluntarjoajat, sopimukset, tuetut toiminnot ja alihankintaketjut. Muoto on yhtenäistetty EU-tasolla, joten sen ylläpito manuaalisesti on työlästä, kun sopimuksia on paljon.
Mitä ovat DORA:n viisi pilaria?
ICT-riskienhallinta, ICT-poikkeamien hallinta ja raportointi, digitaalisen häiriönsietokyvyn testaus, kolmannen osapuolen ICT-riskien hallinta sekä tiedon ja tietämyksen jakaminen. Arvioi ohjelmiston tuki oman toimijan soveltuviin tehtäviin ja nykyisiin järjestelmiin suhteutettuna; kaikkea ei tarvitse hoitaa yhdellä tuotteella, eikä vapaaehtoinen tiedonjako tarkoita pakollista moduulia.
Yhteenveto
Sopiva ratkaisu tuottaa näyttöä organisaation soveltuvista DORA-velvoitteista ja toimii yhteen muiden järjestelmien kanssa. Varmista tietorekisterin vienti, poikkeamien päätöshistoria ja mahdollisen TLPT:n dokumentointi omalla koeaineistolla. DORA-ominaisuudet on todennettava erikseen valitusta ratkaisusta.
Viimeksi tarkistettu: syyskuu 2026.