DORA 2026 -tiekartta ICT-riskeihin, toimittajiin ja TLPT:hen

DORA 2026 -hakupaniikissa ei ole varsinaisesti kyse sääntelystä vaan näytöstä

On maanantai kello 08.15, ja keskisuuren maksulaitoksen tietoturvajohtaja on avannut selaimeensa kolme välilehteä: “DORA RTS/ITS checklist,” “DORA ICT third-party register template” ja “TLPT requirements financial entities.”

Vaatimustenmukaisuudesta vastaava päällikkö on jo kysynyt, pitäisikö hallitusmateriaalissa olla mukana uusin poikkeamien luokittelutyönkulku. Hankinta haluaa ottaa käyttöön uuden pilvipohjaisen analytiikka-alustan. Operatiivinen johtaja haluaa varmuuden siitä, ettei ydinpankkitoimintoja tukevalla SaaS-palveluntarjoajalla ole piileviä alihankkija-altistuksia EU:n ulkopuolella. Sisäinen tarkastus pyytää testauskalenteria. Lakiasiat kysyy, onko GDPR:n tietoturvaloukkauksista ilmoittamisen määräajat sovitettu yhteen DORA:n poikkeamaraportoinnin kanssa.

Kukaan ei esitä teoreettista kysymystä. He kysyvät: “Voimmeko todistaa tämän perjantaihin mennessä?”

Tämä on DORA 2026:n todellinen ongelma. Useimmat finanssialan toimijat ymmärtävät päävelvoitteet: ICT-riskien hallinta, ICT:hen liittyvien poikkeamien raportointi, digitaalisen toiminnallisen häiriönsietokyvyn testaus, ICT-kolmansien osapuolten riskienhallinta sekä kriittisten ICT-palveluntarjoajien tehostettu valvonta. Vaikeinta on muuntaa Regulatory Technical Standards, Implementing Technical Standards ja artiklatasoiset velvoitteet hallituiksi, toistettaviksi ja auditoitaviksi käytännöiksi.

Digital Operational Resilience Act edellyttää, että finanssialan toimijoilla on vahvat ICT-riskienhallinnan kyvykkyydet, politiikat ICT:hen liittyvien poikkeamien hallintaan ja raportointiin, ICT-järjestelmien, kontrollien ja prosessien testaus sekä järjestelmällinen ICT-kolmansien osapuolten valvonta. DORA edellyttää myös suhteellisuutta. Pienempi sijoituspalveluyritys ja suuri pankkiryhmä eivät tarvitse identtisiä näyttömalleja, mutta molempien on pystyttävä osoittamaan, että niiden lähestymistapa on tarkoituksenmukainen suhteessa kokoon, riskiprofiiliin, monimutkaisuuteen ja kriittisiin toimintoihin.

DORA-hankkeet epäonnistuvat yleensä kolmesta syystä. Ensiksi organisaatio käsittelee DORA:a juridisena kartoitusharjoituksena eikä toimintamallina. Toiseksi toimittajariski dokumentoidaan toimittajaluettelona eikä riippuvuuksina, korvattavuutena ja keskittymäriskinä. Kolmanneksi testaus ymmärretään vuosittaiseksi penetraatiotestiksi eikä häiriönsietokykyohjelmaksi, joka sisältää haavoittuvuusskannaukset, skenaariotestauksen, poikkeamaharjoitukset ja soveltuvin osin uhkalähtöisen penetraatiotestauksen, jota haetaan usein termillä TLPT.

Parempi lähestymistapa on rakentaa yksi näyttöjärjestelmä, joka yhdistää politiikat, rekisterit, omistajat, riskit, poikkeamat, toimittajat, testauksen, palautumisen ja johdon katselmoinnin. Tässä Clarysecin Zenith Blueprint, käyttövalmiit politiikat ja Zenith Controls auttavat finanssialan toimijoita muuttamaan DORA:n määräpäivästä jatkuvaksi toimintarytmiksi.

Aloita DORA-toimintamallista, älä RTS/ITS-taulukosta

Monet tiimit aloittavat taulukosta, jossa luetellaan DORA-artiklat ja RTS/ITS-vaatimukset. Se on hyödyllistä, mutta ei riitä. Taulukko voi kertoa, mitä on oltava olemassa. Se ei nimeä omistajia, määritä katselmointitiheyttä, säilytä näyttöä tai osoita, että kontrolli todella toimii.

Zenith Blueprint: auditoijan 30 vaiheen tiekartta -materiaalissa Clarysec käsittelee tätä riskienhallinnan vaiheessa, vaiheessa 14, riskienkäsittelypolitiikat ja sääntelyviittaukset:

“DORA: Finanssisektorin yrityksille DORA edellyttää ICT-riskienhallinnan viitekehystä, joka on hyvin pitkälti linjassa sen kanssa, mitä olemme tehneet: riskien tunnistamista, kontrollien ja politiikkojen käyttöönottoa sekä niiden testaamista. DORA korostaa myös tietoturvapoikkeamiin reagointia ja raportointia sekä kolmansien osapuolten ICT-palveluntarjoajien valvontaa.”

Käytännön viesti on yksinkertainen: älä rakenna “DORA-vaatimustenmukaisuudesta” rinnakkaista byrokratiaa. Rakenna riskiperusteinen ICT-hallinnointikerros, joka kytkee DORA-vaatimukset politiikkoihin, rekistereihin, kontrollien omistajiin, testaustallenteisiin, toimittajanäyttöön ja johdon katselmointiin.

Käytännöllisessä DORA-toimintamallissa tulisi olla viisi näyttöpilaria:

Säännellyille finanssialan toimijoille tämä rakenne muuntaa RTS/ITS-toteutuksen auditointivalmiiksi näyttöjärjestelmäksi. Yksinkertaistetun ICT-riskien hallinnan piirissä olevilla toimijoilla sama malli voidaan skaalata harvempiin asiakirjoihin ja yksinkertaisempiin rekistereihin. Ydinkäytännöt pysyvät samoina: tunnista, suojaa, havaitse, reagoi, palaudu, testaa ja hallinnoi toimittajia.

ICT-riskien hallinta: rekisteri on valvomo

DORA:n ICT-riskienhallintaa koskevat odotukset edellyttävät, että finanssialan toimijat tunnistavat, luokittelevat ja hallitsevat ICT-riskejä järjestelmissä, tiedoissa, prosesseissa, kriittisissä tai tärkeissä toiminnoissa sekä kolmansien osapuolten riippuvuuksissa.

Yleinen epäonnistuminen ei ole riskirekisterin puuttuminen. Ongelma on, että rekisteri on irti toimittajista, omaisuuseristä, poikkeamista ja testeistä. DORA ei palkitse näyttävästä taulukosta, jos se ei pysty selittämään, miksi korkean riskin toimittajalla ei ole irtautumissuunnitelmaa tai miksi kriittistä asiakasmaksualustaa ei ole testattu.

Clarysecin pk-yrityksille suunnattu Riskienhallintapolitiikka antaa pienemmille finanssialan toimijoille tiiviin näyttöperustason:

“Jokaisen riskimerkinnän on sisällettävä: kuvaus, todennäköisyys, vaikutus, pisteytys, omistaja ja riskienkäsittelysuunnitelma.”
Osio “Hallinnointivaatimukset”, politiikan lauseke 5.1.2.

Suuremmille finanssialan toimijoille Clarysecin Enterprise-tason Riskienhallintapolitiikka edellyttää muodollisempaa prosessia:

“Muodollista riskienhallintaprosessia on ylläpidettävä ISO/IEC 27005:n ja ISO 31000:n mukaisesti. Prosessin on katettava riskien tunnistaminen, analyysi, arviointi, käsittely, seuranta ja viestintä.”
Osio “Hallinnointivaatimukset”, politiikan lauseke 5.1.

Tällä erolla on merkitystä. DORA on suhteellinen, mutta suhteellisuus ei tarkoita epämuodollisuutta. Pieni maksuyritys voi käyttää virtaviivaistettua rekisteriä, kun taas pankkiryhmä voi käyttää integroitua GRC-työkalustoa. Molemmissa tapauksissa auditoija kysyy silti: Mitkä ovat ICT-riskinne? Kuka omistaa ne? Mikä on riskienkäsittelysuunnitelma? Mikä näyttö osoittaa etenemisen? Miten toimittajat ja kriittiset toiminnot vaikuttavat pisteytykseen?

Vahvan DORA ICT-riskirekisterin tulisi sisältää nämä kentät:

Käytännön harjoitus on valita yksi kriittinen ICT-palvelu, esimerkiksi pilvessä toimiva transaktioiden valvonta-alusta, ja luoda riskimerkintä 20 minuutissa. Kuvaa vika- tai vaarantumisskenaario, pisteytä todennäköisyys ja vaikutus, nimeä omistaja, tunnista liittyvät toimittajat, määritä riskienkäsittelysuunnitelma ja kytke merkintä näyttöön, kuten toimittajan huolellisuusarviointiin, SLA:han, poikkeamalausekkeisiin, BIA:an, DR-testituloksiin, valvontanäkymiin ja käyttöoikeuskatselmointeihin.

Yhdestä merkinnästä tulee lanka, joka yhdistää DORA:n ICT-riskien hallinnan, kolmansien osapuolten valvonnan, poikkeamien havaitsemisen, jatkuvuuden ja testauksen. Näin riskirekisteristä tulee valvomo eikä arkistokaappi.

RTS/ITS-valmius: kartoita velvoitteet politiikkoihin, älä lupauksiin

Käytännön hakutermi “DORA RTS/ITS checklist” tarkoittaa yleensä “Mitä asiakirjoja valvojat odottavat?” Finanssialan toimijoiden tulee välttää vaatimustenmukaisuuden lupaamista yleisluonteisilla lausumilla. Ne tarvitsevat kartoituksen, joka sitoo jokaisen velvoitteen politiikkaan, kontrolliin, omistajaan ja näyttökohteeseen.

Clarysecin pk-yrityksille suunnattu Laki- ja sääntelyvaatimusten noudattamisen politiikka muodostaa yksinkertaisen hallinnointiperustan:

“Toimitusjohtajan on ylläpidettävä yksinkertaista, rakenteista vaatimustenmukaisuusrekisteriä, jossa luetellaan:”
Osio “Hallinnointivaatimukset”, politiikan lauseke 5.1.1.

DORA 2026:ta varten vaatimustenmukaisuusrekisterin tulisi sisältää:

• DORA-velvoite tai RTS/ITS-vaatimusalue.
• Soveltuvuus, mukaan lukien suhteellisuusperuste.
• Viittaus politiikkaan tai menettelyyn.
• Kontrollin omistaja.
• Näytön sijainti.
• Katselmointitiheys.
• Avoimet puutteet ja korjaavien toimenpiteiden määräaika.
• Hallitukselle tai johdolle raportoinnin tila.

Tämä vastaa Zenith Blueprintin vaiheen 14 lähestymistapaa: sääntelyvaatimukset kartoitetaan ISMS-kontrolleihin ja politiikkoihin, jotta mikään ei putoa väliin. Sen sijaan, että johto kysyisi “Olemmeko DORA-vaatimusten mukaisia?”, se voi kysyä “Mitkä DORA-näyttökohteet ovat myöhässä, miltä kriittisiltä toimittajilta puuttuvat irtautumissuunnitelmat ja mitkä testaustoimet eivät ole vielä tuottaneet korjaavia toimenpiteitä koskevaa näyttöä?”

ICT-kolmansien osapuolten riski: keskittymä, korvattavuus ja alihankkijat

DORA on muuttanut finanssipalvelujen toimittajakeskustelua. Ei enää riitä kysyä, onko palveluntarjoajalla tietoturvasertifiointi, vakuutus tai tietojenkäsittelysopimus. Finanssialan toimijoiden on arvioitava, aiheuttaako palveluntarjoaja keskittymäriskiä, voidaanko palveluntarjoaja realistisesti korvata, ovatko useat kriittiset palvelut riippuvaisia yhdestä toimittajasta tai toisiinsa liittyvistä toimittajista ja tuoko alihankinta mukanaan lisäaltistusta oikeudellisesta tai häiriönsietokyvyn näkökulmasta.

Tämä on kysymys, joka valvottaa monia tietoturvajohtajia. Yritys voi olla riippuvainen yhdestä suuresta pilvipalveluntarjoajasta transaktioiden käsittelyssä, data-analytiikassa, asiakasportaaleissa ja sisäisessä yhteistyössä. Jos kyseinen palveluntarjoaja kärsii pitkittyneestä katkosta, sääntelykiistasta tai alihankkijan epäonnistumisesta, kysymys ei ole vain “Onko meillä sopimus?” Kysymys on “Voimmeko jatkaa kriittisiä palveluja, viestiä asiakkaille ja osoittaa, että ymmärsimme riippuvuuden ennen sen pettämistä?”

Clarysecin pk-yrityksille suunnattu Kolmansien osapuolten ja toimittajaturvallisuuden politiikka asettaa perustan:

“Hallinnollisen tai hankinnan yhteyshenkilön on ylläpidettävä ja päivitettävä toimittajarekisteriä. Sen on sisällettävä:”
Osio “Hallinnointivaatimukset”, politiikan lauseke 5.4.

Yritystason ohjelmissa Clarysecin Toimittajariippuvuuksien riskienhallintapolitiikka menee syvemmälle DORA-kohtaiseen riippuvuuteen ja korvattavuuteen:

“Toimittajariippuvuusrekisteri: Toimittajahallintatoiminnon on ylläpidettävä ajantasaista rekisteriä kaikista kriittisistä toimittajista. Rekisterin on sisällettävä esimerkiksi toimitetut palvelut tai tuotteet; tieto siitä, onko toimittaja ainoa lähde; käytettävissä olevat vaihtoehtoiset toimittajat tai korvattavuus; nykyiset sopimusehdot; sekä arvio vaikutuksista, jos toimittaja epäonnistuisi tai vaarantuisi. Rekisterissä on yksilöitävä selkeästi korkean riippuvuuden toimittajat, esimerkiksi ne, joille ei ole nopeasti käytettävissä vaihtoehtoa.”
Osio “Toteutusvaatimukset”, politiikan lauseke 6.1.

Tämä on toimittajanäyttö, joka DORA-hankkeista usein puuttuu. Toimittajarekisteri kertoo, kuka toimittaja on. Riippuvuusrekisteri kertoo, mitä tapahtuu, kun toimittaja epäonnistuu.

Zenith Blueprintin Controls in Action -vaihe, vaihe 23, organisatoriset kontrollit, antaa käytännön työnkulun toimittajien valvontaan. Se suosittelee koko toimittajaluettelon kokoamista, toimittajien luokittelua järjestelmiin, tietoihin tai operatiiviseen ohjaukseen kohdistuvan pääsyn perusteella, tietoturvaodotusten sisällyttämisen varmistamista sopimuksiin, alihankkija- ja jatkoketjuriskien hallintaa, muutos- ja seurantamenettelyjen määrittämistä sekä pilvipalvelujen arviointiprosessin luomista.

Zenith Controls: The Cross-Compliance Guide -oppaassa ISO/IEC 27002:2022 -kontrolli 5.21, tietoturvan hallinta ICT-toimitusketjussa, on kartoitettu ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Se liittyy toimittajasuhteiden turvallisuuteen ja Identify-kyberturvallisuuskäsitteeseen. Se kytkeytyy turvalliseen suunnitteluun, turvalliseen ohjelmointiin, pääsynhallintaan, tietoturvatestaukseen, todistusaineiston keräämiseen, turvallisen kehityksen elinkaareen ja ulkoistettuun kehittämiseen.

Juuri tämä on DORA:n kolmansien osapuolten valvonnan todellisuus. Toimittajariski ei ole vain hankintaa. Se koskee arkkitehtuuria, kehitystä, tietoturvapoikkeamiin reagointia, pääsynhallintaa, liiketoiminnan jatkuvuutta ja lakiasioita.

Ristiinvaatimustenmukaisuuden näkökulmasta Zenith Controls kartoittaa ICT-toimitusketjun turvallisuuden GDPR Articles 28 and 32 -vaatimuksiin, koska käsittelijät ja alikäsittelijät on valittava ja niitä on valvottava asianmukaisin teknisin ja organisatorisin toimenpitein. Se tukee NIS2:n toimitusketjun turvallisuutta koskevia odotuksia, mukaan lukien Article 21:n kyberturvallisuuden riskienhallintatoimenpiteet ja Article 22:n koordinoidut toimitusketjun riskinarvioinnit. Se kytkeytyy vahvasti DORA Articles 28, 29 and 30 -vaatimuksiin, joissa ICT-kolmansien osapuolten riski, keskittymäriski, alihankinnan edelleenulkoistus ja sopimusmääräykset ovat keskeisiä.

Tukevat standardit vahvistavat näyttöä. ISO/IEC 27036-3:2021 tukee ICT-hankintojen ja toimittajavalinnan turvallisuutta. ISO/IEC 20243:2018 tukee luotettujen teknologiatuotteiden eheyttä ja toimitusketjun turvallisuutta. ISO/IEC 27001:2022 kytkee tämän riskien käsittelyyn ja liitteen A toimittajakontrolleihin.

Poikkeamien raportointi: rakenna eskalointiketju ennen poikkeamaa

DORA:n poikkeamaraportoinnissa ei ole kyse vain ilmoituksen toimittamisesta. Kyse on ICT:hen liittyvien poikkeamien havaitsemisesta, luokittelusta, eskaloinnista, viestinnästä ja niistä oppimisesta. Finanssialan toimijoiden on ylläpidettävä prosesseja ICT-poikkeamien hallintaan ja raportointiin. Prosesseissa on määriteltävä roolit, luokittelukriteerit, ilmoitusreitit ja poikkeaman jälkiarviointi.

Clarysecin pk-yrityksille suunnattu Tietoturvapoikkeamien hallintapolitiikka kytkee tietoturvapoikkeamiin reagoinnin määräajat lakisääteisiin vaatimuksiin:

“Reagoinnin määräajat, mukaan lukien tietojen palautus ja ilmoitusvelvoitteet, on dokumentoitava ja sovitettava yhteen lakisääteisten vaatimusten kanssa, kuten GDPR:n 72 tunnin henkilötietojen tietoturvaloukkauksesta ilmoittamisen vaatimuksen kanssa.”
Osio “Hallinnointivaatimukset”, politiikan lauseke 5.3.2.

Yritysympäristöissä Clarysecin Tietoturvapoikkeamien hallintapolitiikka lisää sääntelyn alaisten tietojen eskalointinäkökulman:

“Jos poikkeama johtaa henkilötietojen tai muiden sääntelyn alaisten tietojen vahvistettuun tai todennäköiseen altistumiseen, lakiasioiden ja tietosuojavastaavan on arvioitava seuraavien soveltuvuus:”
Osio “Politiikan toteutusvaatimukset”, politiikan lauseke 6.4.1.

Lainaus päättyy herätekohtaan, ja juuri siinä moni poikkeamaprosessi epäonnistuu. Jos heräte on epäselvä, tiimit keskustelevat ilmoitusvelvollisuuksista samalla kun kello jo käy.

Zenith Blueprintin Controls in Action -vaihe, vaihe 16, henkilöstöön liittyvät kontrollit II, korostaa henkilöstölähtöistä poikkeamien ilmoittamista. Työntekijöiden, sopimuskumppaneiden ja sidosryhmien on tiedettävä, miten mahdolliset tietoturvapoikkeamat tunnistetaan ja raportoidaan yksinkertaisten kanavien, kuten erillisen sähköpostilaatikon, portaalin tai ilmoituskanavan, kautta. Blueprint kytkee tämän GDPR Article 33:een, NIS2 Article 23:een ja DORA Article 17:ään, koska sääntelyyn liittyvä raportointi alkaa sisäisestä tietoisuudesta ja eskaloinnista.

Zenith Controls -oppaassa ISO/IEC 27002:2022 -kontrolli 5.24, tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu, on kartoitettu korjaavaksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta sekä on linjassa Respond- ja Recover-toimintojen kanssa. Se liittyy suoraan tapahtumien arviointiin, poikkeamista oppimiseen, lokitukseen ja seurantaan, turvallisuuteen häiriötilanteissa, tietoturvan jatkuvuuteen ja yhteydenpitoon viranomaisten kanssa. Opas kartoittaa tämän DORA Articles 17 to 23 -artikloihin ICT:hen liittyvien poikkeamien hallinnan, luokittelun, raportoinnin ja vapaaehtoisen kyberuhkailmoittamisen osalta, GDPR Articles 33 and 34 -artikloihin tietoturvaloukkauksista ilmoittamisen osalta sekä NIS2 Article 23 -artiklaan poikkeamailmoittamisen osalta.

DORA-valmiin poikkeamaprosessin tulisi sisältää:

• Selkeät poikkeamien vastaanottokanavat.
• Tapahtumien luokittelu ja priorisointi sekä luokittelukriteerit.
• Merkittävien ICT:hen liittyvien poikkeamien eskalointityönkulku.
• Lakiasioiden, tietosuojavastaavan ja viranomaisilmoitusten päätöspisteet.
• Toimittajapoikkeamien ilmoitusherätteet.
• Todentavan aineiston säilyttämisvaatimukset.
• Johdon ja hallituksen viestintäsäännöt.
• Poikkeaman jälkiarviointi ja opit.
• Kytkentä riskirekisterin päivityksiin ja kontrollien korjaaviin toimenpiteisiin.

Tukevat standardit tuovat rakennetta. ISO/IEC 27035-1:2023 antaa suunnittelun ja valmistelun periaatteet poikkeamien hallintaan. ISO/IEC 27035-2:2023 kuvaa poikkeamien käsittelyvaiheet. ISO/IEC 22320:2018 tukee johtamista, ohjausta ja rakenteista kriisiviestintää. Tällä on merkitystä, kun ICT-katkoksesta tulee asiakkaille näkyvä kriisi ja toimijan on osoitettava, että päätökset olivat oikea-aikaisia, koordinoituja ja näyttöön perustuvia.

Digitaalisen toiminnallisen häiriönsietokyvyn testaus ja TLPT: älä anna testin muuttua poikkeamaksi

Testaus on yksi haetuimmista DORA 2026 -aiheista, koska se on sekä tekninen että vahvasti hallinnollinen. Finanssialan toimijoiden on testattava ICT-järjestelmiä, kontrolleja ja prosesseja. Nimettyjen toimijoiden osalta edistynyt testaus, kuten TLPT, muodostuu keskeiseksi vaatimukseksi DORA Article 26:n nojalla.

Auditointikysymys ei ole vain “Testasitko?” Se on “Oliko testi riskiperusteinen, hyväksytty, turvallinen, tarvittaessa riippumaton, korjattu ja kytketty häiriönsietokykytavoitteisiin?”

Clarysecin Enterprise-tason Tietoturvatestauksen ja red team -harjoitusten politiikka määrittää vähimmäistestausohjelman selkeästi:

“Testityypit: Tietoturvatestausohjelman on sisällettävä vähintään: (a) haavoittuvuusskannaus, joka koostuu verkkojen ja sovellusten automatisoiduista viikoittaisista tai kuukausittaisista skannauksista tunnettujen haavoittuvuuksien tunnistamiseksi; (b) penetraatiotestaus, joka koostuu osaavien testaajien tekemästä tiettyjen järjestelmien tai sovellusten manuaalisesta syvätestauksesta monimutkaisten heikkouksien tunnistamiseksi; sekä (c) red team -harjoitukset, jotka koostuvat todellisten hyökkäysten skenaariopohjaisista simulaatioista, mukaan lukien sosiaalinen manipulointi ja muut taktiikat, organisaation havaitsemis- ja reagointikyvykkyyden testaamiseksi kokonaisuutena.”
Osio “Toteutusvaatimukset”, politiikan lauseke 6.1.

Tämä on silta rutiinitestauksen ja TLPT-kypsyyden välillä. Haavoittuvuusskannaus löytää tunnetut heikkoudet. Penetraatiotestaus validoi hyväksikäytettävyyden. Red team -harjoitukset testaavat havaitsemista ja reagointia järjestelmänä. TLPT:n, jos sitä sovelletaan, tulisi olla osa hallinnoitua testausohjelmaa, jossa on rajauksen hallinta, turvallisuussäännöt, tuotantoriskien hallinta, näytön kerääminen ja korjaavien toimenpiteiden seuranta.

Zenith Blueprintin Controls in Action -vaihe, vaihe 21, käsittelee tietojärjestelmien suojaamista auditoinnin ja testauksen aikana. Se varoittaa, että auditoinnit, penetraatiotestit, forensiset katselmukset ja operatiiviset arvioinnit voivat aiheuttaa riskiä, koska niissä voidaan käyttää korotettuja käyttöoikeuksia, tunkeilevia työkaluja tai tilapäisiä muutoksia järjestelmän käyttäytymiseen. Blueprint kartoittaa tämän huolen GDPR Article 32:een, DORA:n digitaalisen toiminnallisen häiriönsietokyvyn testausodotuksiin, NIS2:n jatkuvuusnäkökulmiin ja COBIT 2019 -käytäntöihin auditointien ja arviointien turvallisesta suorittamisesta.

Zenith Controls -oppaassa ISO/IEC 27002:2022 -kontrolli 5.35, riippumaton tietoturvan katselmointi, on kartoitettu ennaltaehkäiseväksi ja korjaavaksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Se liittyy politiikkojen noudattamiseen, johdon vastuisiin, poikkeamista oppimiseen, tallenteiden suojaamiseen, tietojen poistamiseen sekä lokitukseen ja seurantaan. DORA:n kannalta olennaiset testausvelvoitteet ovat ensisijaisesti Articles 24 to 27, mukaan lukien Article 26 TLPT:tä varten. Tämä tukee myös GDPR Article 32(1)(d):tä, joka edellyttää teknisten ja organisatoristen toimenpiteiden säännöllistä testausta ja arviointia, sekä NIS2 Article 21:tä, joka edellyttää kyberturvallisuuden riskienhallintatoimenpiteitä.

DORA TLPT -valmiuspaketin tulisi sisältää:

DORA:n keskeinen opetus on, ettei testausnäyttö saa päättyä raporttiin. Auditoijat kysyvät, onko havainnot riskiluokiteltu, osoitettu omistajille, korjattu ja testattu uudelleen. He voivat myös tarkistaa, kattoiko testaus kriittiset tai tärkeät toiminnot eikä vain internetiin avautuvia omaisuuseriä.

Liiketoiminnan jatkuvuus ja katastrofipalautus: häiriönsietokyvyn on oltava operatiivista

DORA on digitaalisen toiminnallisen häiriönsietokyvyn sääntelyä. Palautuminen on yhtä tärkeää kuin ennaltaehkäisy. Dokumentoitu ICT-riskienhallinnan viitekehys ei auta, jos maksualustan katkos paljastaa, ettei toipumisaikatavoitteita ole koskaan testattu, toimittajien yhteyspuut ovat vanhentuneita ja kriisiryhmä ei pääse yksimielisyyteen siitä, kuka viestii asiakkaille.

Clarysecin pk-yrityksille suunnattu Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka asettaa selkeän perustason:

“Organisaation on testattava sekä BCP- että DR-kyvykkyytensä vähintään vuosittain. Testien on sisällettävä:”
Osio “Politiikan toteutusvaatimukset”, politiikan lauseke 6.4.1.

Enterprise-tason Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka alkaa liiketoimintavaikutuksesta:

“Liiketoimintavaikutusten arviointi (BIA) on tehtävä vähintään vuosittain kaikille kriittisille liiketoimintayksiköille ja katselmoitava, kun järjestelmiin, prosesseihin tai riippuvuuksiin tehdään merkittäviä muutoksia. BIA-tuotosten on määriteltävä:”
Osio “Hallinnointivaatimukset”, politiikan lauseke 5.2.

DORA:n näkökulmasta BIA tulee kytkeä ICT-omaisuuseriin, toimittajiin, tietoturvapoikkeamiin reagointiin ja testaukseen. Jos BIA tunnistaa “asiakasmaksut” kriittiseksi toiminnoksi, toimittajariippuvuusrekisterin tulee tunnistaa sitä tukevat käsittelijät, pilvipalvelut ja verkkopalveluntarjoajat. Riskirekisterin tulee sisältää vikaskenaariot. Testaussuunnitelman tulee sisältää häiriönsietokyvyn validointi. Tietoturvapoikkeamiin reagointisuunnitelman tulee sisältää eskalointi ja viestintä. DR-testin tulee tuottaa näyttöä, ei vain kokousmuistiinpanoa.

Tämä jäljitettävyys muuttaa DORA-vaatimustenmukaisuuden toiminnallisen häiriönsietokyvyn järjestelmäksi.

Ristiinvaatimustenmukaisuus: yksi näyttökokonaisuus, monta auditointikysymystä

Finanssialan toimijat eivät yleensä kohtaa DORA:a yksin. Niillä on usein GDPR-velvoitteita, NIS2-altistusta, sopimusperusteisia tietoturvasitoumuksia, ISO/IEC 27001:2022 -tavoitteita, sisäisen tarkastuksen vaatimuksia, asiakkaiden huolellisuusarviointeja, SOC-odotuksia ja hallituksen riskiraportointia. Ratkaisu ei ole erillisten näyttösiilojen luominen. Ratkaisu on rakentaa ristiinvaatimustenmukaisuuden näyttömalli.

Zenith Controls on Clarysecin ristiinvaatimustenmukaisuuden kompassi. Se ei keksi uusia velvoitteita. Se kartoittaa virallisia standardeja ja viitekehyksiä, jotta organisaatiot ymmärtävät, miten yksi kontrollialue tukee useita vaatimustenmukaisuustuloksia.

Tällä on merkitystä budjetille ja hallinnoinnille. Tietoturvajohtaja voi selittää hallitukselle, että poikkeamien luokittelun parantaminen tukee DORA-raportointia, GDPR:n tietoturvaloukkauksista ilmoittamista, NIS2:n poikkeamien käsittelyä ja sisäistä häiriönsietokykyä. Hankintajohtaja voi perustella toimittajariippuvuuksien kartoittamisen, koska se tukee DORA:n keskittymäriskiä, GDPR:n käsittelijöitä koskevaa huolellisuusarviointia ja NIS2:n toimitusketjun turvallisuutta. Testausvastaava voi osoittaa, että red team -harjoitukset ja riippumattomat katselmoinnit tukevat DORA-testausta, GDPR:n kontrolliarviointia ja laajempaa varmentamista.

Auditointinäkökulma: miten arvioijat testaavat DORA-näyttösi

DORA-valmiudesta tulee todellista, kun joku pyytää näyttöä. Eri auditoijat ja arvioijat lähestyvät samaa aihetta eri näkökulmista.

ISO/IEC 27001:2022 -lähtöinen auditoija aloittaa ISMS-logiikasta: soveltamisala, riskien arviointi, riskien käsittely, liitteen A kontrollien soveltuvuus, sisäinen tarkastus, johdon katselmointi ja näyttö siitä, että kontrollit on toteutettu. ICT-toimitusketjun turvallisuuden osalta hän tarkastelee politiikkoja, toimittajaluokittelua, sopimuslausekkeita, huolellisuusarviointia ja jatkuvaa seurantaa. Poikkeamien hallinnassa hän tarkastaa suunnitelman, roolit, eskalointireitit, työkalut ja tallenteet. Testauksen osalta hän odottaa suunniteltuja aikavälejä, riippumattomuutta tarvittaessa, korjaavia toimenpiteitä ja johdon katselmoinnin syötteitä.

ISO/IEC 19011:2018 -auditointinäkökulma keskittyy auditoinnin toteutukseen. Zenith Controls -oppaassa ICT-toimitusketjun turvallisuuden auditointimenetelmä toteaa, että auditoijat tarkastelevat hankintapolitiikkoja, RFP-malleja ja toimittajahallintaprosesseja varmistaakseen, että ICT-kohtaiset tietoturvavaatimukset sisältyvät prosessiin hankinnasta hävittämiseen. Poikkeamien hallinnassa auditoijat tarkastelevat tietoturvapoikkeamiin reagointisuunnitelman kattavuutta ja linjausta parhaisiin käytäntöihin. Riippumattoman katselmoinnin osalta auditoijat etsivät näyttöä siitä, että riippumattomia auditointeja tai katselmointeja on tehty.

ISO/IEC 27007:2020 -näkökulma on tarkemmin ISMS-auditointiin kohdistuva. Zenith Controls toteaa, että auditoijat voivat haastatella hankintavastaavia, IT-tietoturvahenkilöstöä ja toimittajahallinnasta vastaavia henkilöitä arvioidakseen ICT-toimitusketjun kontrollien ymmärrystä ja toteutusta. Poikkeamiin valmistautumisen osalta he varmistavat, että tietoturvapoikkeamiin reagointitiimi on olemassa ja operatiivinen. Riippumattoman katselmoinnin osalta he varmistavat, että sisäinen auditointiohjelma kattaa koko ISMS:n soveltamisalan ja että sille on osoitettu asianmukaiset resurssit.

NIST SP 800-115 -lähtöinen testausarvioija keskittyy haavoittuvuuksien arvioinnin ja penetraatiotestauksen menetelmään. Hän voi tarkastella, onko testin soveltamisala, toimintasäännöt, havainnot, vakavuusluokitukset, korjaavat toimenpiteet ja uusintatestaus dokumentoitu. DORA TLPT:n osalta tämä tarkoittaa, ettei arvioija tyydy red team -diasarjaan. Hän haluaa todisteet hallinnoinnista, turvallisuudesta, teknisestä syvyydestä ja sulkemisesta.

COBIT 2019- tai ISACA-tyylinen auditoija kysyy, täyttyvätkö hallinnointitavoitteet: kuka omistaa prosessin, miten suorituskykyä mitataan, miten poikkeukset hyväksytään ja miten johto saa varmuuden.

Käytännön DORA 2026 -valmiuden tarkistuslista

Käytä tätä tarkistuslistaa työskentelyn perustasona, kun muutat DORA-hakuja toiminnaksi.

Hallinnointi ja RTS/ITS-kartoitus

• Ylläpidä DORA-vaatimustenmukaisuusrekisteriä, jossa on velvoitealue, soveltuvuus, omistaja, näyttö, katselmointitiheys ja puutteiden tila.
• Kartoita DORA-vaatimukset politiikkoihin, rekistereihin, kontrolleihin ja johdon raportointiin.
• Määritä suhteellisuusperuste yksinkertaistetulle tai skaalatulle ICT-riskien hallinnalle, jos soveltuu.
• Määritä ylimmän johdon vastuu ICT-riskistä, poikkeamien raportoinnista, kolmansien osapuolten valvonnasta ja testauksesta.
• Sisällytä DORA-tila johdon katselmointiin ja hallituksen riskiraportointiin.

ICT-riskien hallinta

• Ylläpidä ICT-riskirekisteriä, jossa on kuvaus, todennäköisyys, vaikutus, pisteytys, omistaja ja riskienkäsittelysuunnitelma.
• Kytke riskit kriittisiin tai tärkeisiin toimintoihin.
• Kytke riskit ICT-omaisuuseriin, toimittajiin ja prosesseihin.
• Katselmoi riskit merkittävien poikkeamien, toimittajamuutosten, teknologiamuutosten tai testihavaintojen jälkeen.
• Seuraa riskienkäsittelytoimet sulkemiseen tai muodolliseen riskin hyväksymiseen asti.

ICT-kolmansien osapuolten valvonta

• Ylläpidä toimittajarekisteriä ja toimittajariippuvuusrekisteriä.
• Tunnista kriittisiä tai tärkeitä toimintoja tukevat toimittajat.
• Arvioi ainoan lähteen toimittajat ja korvattavuus.
• Katselmoi alihankkijat ja edelleenulkoistusjärjestelyt.
• Sisällytä sopimuksiin tietoturva-, pääsy-, poikkeamien raportointi-, auditointi- ja irtautumislausekkeet.
• Seuraa kriittisiä toimittajia vähintään vuosittain tai olennaisten muutosten jälkeen.
• Ylläpidä irtautumis- ja varautumissuunnitelmia korkean riippuvuuden palveluntarjoajille.

Poikkeamien hallinta ja raportointi

• Ylläpidä tietoturvapoikkeamiin reagoinnin menettelyjä, joissa on selkeät roolit ja eskalointireitit.
• Määritä ICT-poikkeamien luokittelukriteerit.
• Sovita DORA-raportointiherätteet yhteen GDPR:n, NIS2:n ja sopimusperusteisten ilmoitusvelvoitteiden kanssa.
• Kouluta työntekijät ja sopimuskumppanit poikkeamien ilmoituskanavista.
• Ylläpidä poikkeamalokeja, päätöstallenteita ja näyttöä.
• Toteuta poikkeamien jälkiarvioinnit ja päivitä riskit ja kontrollit.

Testaus, red team -harjoitukset ja TLPT

• Ylläpidä riskiperusteista testauskalenteria.
• Toteuta haavoittuvuusskannaukset ja penetraatiotestaus määritellyin väliajoin.
• Käytä skenaariopohjaisia red team -harjoituksia havaitsemisen ja reagoinnin testaamiseen.
• Määritä TLPT-valmiutta varten soveltamisala, toimintasäännöt, turvallisuuskontrollit ja toimittajakoordinointi.
• Suojaa tuotantojärjestelmät testauksen aikana.
• Seuraa havaintoja, korjaavia toimenpiteitä, uusintatestausta ja oppeja.
• Raportoi testaustulokset johdolle.

Jatkuvuus ja palautuminen

• Tee vuosittainen BIA kriittisille liiketoimintayksiköille ja päivitä se merkittävien muutosten jälkeen.
• Määritä palautumistavoitteet kriittisille toiminnoille ja niitä tukeville ICT-palveluille.
• Testaa BCP- ja DR-kyvykkyydet vähintään vuosittain.
• Sisällytä mukaan toimittajakatkos- ja kyberpoikkeamaskenaariot.
• Säilytä testinäyttö, puutteet, korjaavat toimenpiteet ja uusintatestauksen tulokset.
• Sovita jatkuvuussuunnitelmat yhteen tietoturvapoikkeamiin reagoinnin ja kriisiviestinnän kanssa.

Miten Clarysec auttaa finanssialan toimijoita siirtymään hakutuloksista auditointivalmiiseen näyttöön

DORA 2026 -valmiutta ei saavuteta lataamalla tarkistuslista ja toivomalla, että organisaatio täyttää puutteet myöhemmin. Se edellyttää rakenteista toimintamallia, joka yhdistää riskit, toimittajat, poikkeamat, testauksen, jatkuvuuden ja auditointinäytön.

Clarysecin lähestymistapa yhdistää kolme kerrosta.

Ensiksi Zenith Blueprint tarjoaa toteutuksen tiekartan. Vaihe 14 auttaa organisaatioita ristiviittaamaan sääntelyvaatimukset riskien käsittelyyn ja politiikkoihin. Vaihe 16 vahvistaa henkilöstölähtöistä poikkeamien ilmoittamista. Vaihe 21 varmistaa, etteivät auditoinnit ja testit vaaranna tuotantojärjestelmiä. Vaihe 23 muuntaa toimittajavalvonnan käytännön työnkuluksi, joka kattaa luokittelun, sopimukset, alihankkijat, seurannan ja pilvipalvelujen arvioinnin.

Toiseksi Clarysecin politiikat tarjoavat käyttöön vietävää hallinnointia. Riskienhallintapolitiikka, Laki- ja sääntelyvaatimusten noudattamisen politiikka, Kolmansien osapuolten ja toimittajaturvallisuuden politiikka, Toimittajariippuvuuksien riskienhallintapolitiikka, Tietoturvapoikkeamien hallintapolitiikka, Tietoturvatestauksen ja red team -harjoitusten politiikka sekä Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka antavat tiimeille konkreettiset lausekkeet, omistajuusmallit ja näyttöodotukset.

Kolmanneksi Zenith Controls tarjoaa ristiinvaatimustenmukaisuuden kartan. Se näyttää, miten ICT-toimitusketjun turvallisuus, poikkeamien hallinnan suunnittelu ja riippumaton katselmointi kytkeytyvät DORA:an, GDPR:ään, NIS2:een, ISO/IEC 27001:2022:een, ISO/IEC 27002:2022:een, ISO/IEC 27035:een, ISO/IEC 27036:een, ISO/IEC 22320:een, ISO/IEC 20243:een, COBIT 2019:ään ja NIST:n testauskäytäntöihin.

Tuloksena on DORA-vaatimustenmukaisuusohjelma, joka on auditoinnissa puolustettavissa ja hyödyllinen todellisessa poikkeamassa, toimittajahäiriössä tai häiriönsietokyvyn testissä.

Seuraava askel: rakenna DORA-näyttöpaketti ennen seuraavaa auditointipyyntöä

Jos tiimisi hakee yhä “DORA RTS/ITS checklist,” “DORA ICT risk management template,” “DORA third-party oversight” tai “DORA TLPT requirements,” seuraava askel on muuttaa nämä haut hallituksi näytöksi.

Aloita tällä viikolla neljällä toimella:

1. Luo tai päivitä DORA-vaatimustenmukaisuusrekisteri Clarysecin politiikkamallin avulla.
2. Valitse yksi kriittinen toiminto ja jäljitä se riskirekisterin, toimittajariippuvuusrekisterin, poikkeamatyönkulun, BIA:n ja testaussuunnitelman läpi.
3. Katselmoi viisi tärkeintä ICT-toimittajaasi korvattavuuden, alihankkijoiden, poikkeamalausekkeiden ja irtautumisvaihtoehtojen osalta.
4. Rakenna testausnäyttöpaketti, joka sisältää soveltamisalan, valtuutuksen, tulokset, korjaavat toimenpiteet ja uusintatestauksen.

Clarysec voi auttaa toteuttamaan tämän Zenith Blueprintin, politiikkamallien ja Zenith Controlsin avulla, jotta DORA 2026 -ohjelmasi on käytännöllinen, suhteellinen ja auditointivalmis.