DORA-testausohjelma: testien kartoittaminen ISO 27001 -auditointinäytöksi

On helmikuu 2026. Keskisuuren maksulaitoksen tietoturvajohtajalla on hallituksen kokous kahden päivän kuluttua, ISO/IEC 27001:2022 -seuranta-auditointi kuuden viikon kuluttua ja DORA-valvojan tietopyyntö odottamassa compliance-tiimin sähköpostilaatikossa.

Viranomainen ei pyydä näyttävää kyberstrategiaa. Pyyntö on käytännönläheinen:

• Toimittakaa vuoden 2026 digitaalisen häiriönsietokyvyn testausohjelmanne.
• Osoittakaa, mitkä testit kattavat kriittiset tai tärkeät toiminnot.
• Osoittakaa, miten havainnot korjataan ja testataan uudelleen.
• Esittäkää näyttö hallintoelimen valvonnasta.
• Selittäkää, miten ICT-palveluntarjoajat otetaan mukaan.
• Toimittakaa tallenteet haavoittuvuusarvioinneista, skenaariopohjaisista testeistä, suorituskyky- ja kapasiteettitestauksesta sekä penetraatiotestauksesta.

Tietoturvajohtaja avaa neljä kansiota. Haavoittuvuusskannaukset ovat SOC:n tikettijärjestelmässä. Pöytäharjoituksen muistiinpanot ovat jaetulla levyllä. Kuormitustestien tulokset ovat teknisen kehitystiimin hallussa. Penetraatiotestausraportit ovat lakiasioiden rajoitetussa tietovarastossa. Korjaavien toimenpiteiden seuranta jakautuu Jiran, sähköpostin ja viime vuoden ISO-auditointia varten luodun laskentataulukon välille.

Mikään ei ole tekaistua. Suuri osa työstä on laadukasta. Kyse ei kuitenkaan vielä ole hallinnoidusta DORA:n digitaalisen häiriönsietokyvyn testausohjelmasta. Kyse on testien kokoelmasta.

Tällä erolla on merkitystä vuonna 2026. DORAa sovelletaan 17. tammikuuta 2025 alkaen, ja se muodostaa yhtenäisen EU-kehyksen digitaaliselle häiriönsietokyvylle ICT-riskien hallinnan, poikkeamien ilmoittamisen, häiriönsietokyvyn testauksen, kyberuhkia ja haavoittuvuuksia koskevan tietojen jakamisen, ICT-palveluntarjoajiin liittyvän kolmannen osapuolen riskienhallinnan, sopimusvaatimusten ja kriittisten ICT-palveluntarjoajien valvonnan osalta. Se kattaa laajan joukon finanssialan toimijoita, kuten luottolaitokset, maksulaitokset, sijoituspalveluyritykset, kryptovarapalvelujen tarjoajat, vakuutusyritykset ja muut säännellyt toimijat. DORA toimii myös finanssialan toimijoiden sektorikohtaisena unionin säädöksenä tilanteissa, joissa niihin muutoin sovellettaisiin vastaavia NIS2-kyberturvallisuusvelvoitteita.

Hallitusten, tietoturvajohtajien, compliance-vastaavien ja ICT-palveluntarjoajien käytännön kysymys ei enää ole, tehdäänkö testausta. Kysymys on siitä, onko testaus suunniteltua, riskiperusteista, näytöllä osoitettavissa, korjattua, katselmoitua ja uudelleenkäytettävää DORA:n ja ISO/IEC 27001:2022:n vaatimuksissa.

Clarysecin toimintamalli on rakennettu juuri tätä ongelmaa varten. Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysecin ISO-yhteensopiva politiikkakokonaisuus ja Zenith Controls: The Cross-Compliance Guide auttavat organisaatioita muuttamaan hajanaiset häiriönsietokykytoimet hallituksi vuosittaiseksi testiluetteloksi, joka täyttää valvojien, auditoijien, asiakkaiden ja hallitusten odotukset.

Miksi DORA tekee testauksesta hallinnointikysymyksen

DORA on selkeä johdon vastuuvelvollisuudesta. Article 5 asettaa ICT-riskien hallinnan vastuun hallintoelimelle. Article 6 edellyttää toimivaa, kattavaa ja hyvin dokumentoitua ICT-riskien hallinnan viitekehystä, joka on integroitu organisaation yleiseen riskienhallintajärjestelmään. Article 4 lisää suhteellisuusperiaatteen, jonka mukaan vaatimuksia tulee soveltaa koon, yleisen riskiprofiilin sekä palvelujen, toiminnan ja operaatioiden luonteen, laajuuden ja monimutkaisuuden perusteella.

Tämä tekee digitaalisen häiriönsietokyvyn testauksesta muutakin kuin teknisen tehtävän. Siitä tulee näyttöä siitä, että hallintoelin ymmärtää riskin, on hyväksynyt strategian, saa merkityksellistä raportointia ja ohjaa korjaavia toimenpiteitä.

ISO/IEC 27001:2022 käyttää samankaltaista hallintajärjestelmälogiikkaa. Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmät, lakisääteiset ja sopimusvelvoitteet, soveltamisalan, rajapinnat ja riippuvuudet. Kohdat 5.1–5.3 edellyttävät johtajuutta, politiikkojen yhdenmukaisuutta, resursseja, viestintää, määritettyjä vastuita ja raportointia ylimmälle johdolle. Kohta 6.1 edellyttää tietoturvariskien arviointia ja riskien käsittelyä.

DORA-testausohjelman tulee siksi yhdistää:

• Liiketoimintapalvelut sekä kriittiset tai tärkeät toiminnot
• ICT-omaisuuserät, tiedot ja kolmansien osapuolten riippuvuudet
• Riskienarviointi, riskinomistajat ja riskienkäsittelysuunnitelmat
• Testityypit, testitiheys ja käynnistävät tekijät
• Valtuutus, riippumattomuus ja toimintasäännöt
• Havainnot, korjaavien toimenpiteiden määräajat ja uusintatestaus
• Näytön säilytys ja pääsynhallinta
• Johdon raportointi ja jatkuva parantaminen

Pienemmille tai alemman riskin finanssialan toimijoille Article 16 tarjoaa yksinkertaistetun ICT-riskien hallinnan viitekehyksen, mutta yksinkertaistettu ei tarkoita epämuodollista. Myös skaalatut ohjelmat tarvitsevat dokumentoitua ICT-riskien hallintaa, seurantaa, häiriönsietokykyisiä järjestelmiä, ICT-riskilähteiden ja poikkeamien tunnistamista, keskeisiä ICT-palveluntarjoajariippuvuuksia, jatkuvuus- ja palautustoimenpiteitä, säännöllistä testausta ja opittujen asioiden hyödyntämistä.

Toisin sanoen DORA ei palkitse testien määrää. Se palkitsee hallinnoidun, riskiperusteisen testauksen, joka osoittaa häiriönsietokyvyn tärkeimpien palvelujen osalta.

Mitä vuoden 2026 DORA-testausohjelmaan kuuluu?

Kypsän DORA-testausohjelman tulee toimia vuosittaisena testiluettelona. Sen ei tule rajoittua yhteen vuosittaiseen penetraatiotestiin tai haavoittuvuusskannausten vientitiedostojen kasaan. Sen tulee sisältää perustason ja edistyneitä testejä, jotka suunnitellaan riskin, palvelukriittisyyden, sääntelyvelvoitteiden, toimittajariippuvuuksien, merkittävien muutosten ja aiempien havaintojen perusteella.

DORA Article 24 perustaa digitaalisen häiriönsietokyvyn testausohjelman. Article 25 kuvaa joukon testejä, mukaan lukien haavoittuvuusarvioinnit ja skannaukset, avoimen lähdekoodin analyysit, verkkoturvallisuuden arvioinnit, puuteanalyysit, fyysisen turvallisuuden katselmoinnit, kyselyt, skannausohjelmistoratkaisut, lähdekoodikatselmoinnit silloin kun ne ovat toteutettavissa, skenaariopohjaiset testit, yhteensopivuustestaus, suorituskykytestaus, end-to-end-testaus ja penetraatiotestaus. Article 26 lisää uhkaperusteisen penetraatiotestauksen toimivaltaisten viranomaisten nimeämille finanssialan toimijoille.

Useimmissa organisaatioissa käytännön luettelo rakentuu neljän testausperheen ympärille.

Clarysecin Security Testing and Red-Teaming Policy tarjoaa tälle luettelolle vahvan politiikkaperustan:

“Testityypit: Tietoturvatestausohjelman tulee sisältää vähintään: (a) haavoittuvuusskannaus, joka koostuu viikoittaisista tai kuukausittaisista automatisoiduista verkkojen ja sovellusten skannauksista tunnettujen haavoittuvuuksien tunnistamiseksi; (b) penetraatiotestaus, joka koostuu pätevien testaajien suorittamasta tiettyjen järjestelmien tai sovellusten manuaalisesta syvätestauksesta monimutkaisten heikkouksien tunnistamiseksi; ja (c) red team -harjoitukset, jotka koostuvat todellisten hyökkäysten skenaariopohjaisista simulaatioista, mukaan lukien sosiaalinen manipulointi ja muut taktiikat, joilla testataan organisaation havaitsemis- ja reagointikyvykkyyttä kokonaisuutena.”

Sama politiikka edellyttää säännöllistä aikataulutusta:

“Testausaikataulu: Organisaation tulee suorittaa tietoturvatestausta säännöllisen aikataulun mukaisesti. Keskeisille internetiin avautuville järjestelmille ja kriittisille sisäisille sovelluksille on tehtävä penetraatiotestaus vähintään vuosittain. Korkean riskin muutokset, kuten uuden kriittisen järjestelmän käyttöönotto tai merkittävät päivitykset, edellyttävät ad hoc -testausta ennen tuotantokäyttöönottoa ja/tai pian sen jälkeen.”

Tämä on DORA:n kannalta kriittistä. Staattinen vuosisuunnitelma ei riitä, jos toimija ottaa käyttöön uuden maksuyhdyskäytävän, siirtää ydinjärjestelmän pilveen, vaihtaa hallinnoidun palveluntarjoajan tai julkaisee uuden asiakkaan todentamisprosessin. Korkean riskin muutoksen tulee käynnistää lisätestaus.

Rakenna vuosittainen testiluettelo yhdeksi totuuden lähteeksi

Tehokkain tapa täyttää DORA:n ja ISO/IEC 27001:2022:n odotukset on luoda yksi hallittu vuosittainen testiluettelo. Se voi sijaita GRC-alustalla, tikettityönkulussa tai hallitussa laskentataulukossa. Muoto on vähemmän tärkeä kuin jäljitettävyys.

Jokaisen testin tulee vastata viiteen auditointikysymykseen:

1. Mikä palvelu, omaisuuserä, toimittaja, sovellus tai prosessi testattiin?
2. Mikä riski, velvoite tai kontrollivaatimus käynnisti testin?
3. Kuka valtuutti ja suoritti testin?
4. Mitä havaintoja tunnistettiin, hyväksyttiin, korjattiin tai lykättiin?
5. Mikä näyttö osoittaa, että testi tehtiin ja lopputulos katselmoitiin?

Käytännöllinen Clarysec-tyylinen luettelo sisältää nämä kentät.

Clarysecin Audit and Compliance Monitoring Policy-sme - SME antaa tiiviin hallinnointisäännön, joka sopii tähän rakenteeseen:

“Jokaisella auditoinnilla on oltava määritelty soveltamisala, tavoitteet, vastuuhenkilöt ja vaadittu näyttö.”

Vaikka sääntö on kirjoitettu auditointeja varten, samaa sääntöä tulee soveltaa häiriönsietokyvyn testeihin. Jos haavoittuvuusskannauksella, pöytäharjoituksella, failover-simulaatiolla tai penetraatiotestillä ei ole määriteltyä soveltamisalaa, tavoitetta, omistajaa ja vaadittua näyttöä, se on heikko sekä DORA:n että ISO-auditoinnin tarkastelussa.

Sama politiikka toteaa:

“Näyttö on säilytettävä vähintään kaksi vuotta tai pidempään, jos sertifiointi- tai asiakassopimukset sitä edellyttävät.”

DORA-sääntelyn alaisille finanssialan toimijoille ja ICT-palveluntarjoajille kahta vuotta tulee pitää vähimmäistasona. Sopimusvelvoitteet, valvontaviranomaisten odotukset, sertifiointisyklit ja poikkeamatutkinnat voivat edellyttää pidempää säilytystä.

Kartoita DORA-testityypit ISO 27001 -auditointinäytöksi

Integroidun ohjelman voima on siinä, että yksi testi voi täyttää useita velvoitteita. Olennaista on merkitä näyttö oikein ja yhdistää se ISMS:ään.

Zenith Blueprint selittää tämän Audit, Review & Improvement -vaiheessa, vaiheessa 24:

“SoA:n tulee olla yhdenmukainen riskirekisterin ja riskienkäsittelysuunnitelman kanssa. Tarkista, että jokainen riskien käsittelyksi valitsemasi kontrolli on merkitty SoA:ssa soveltuvaksi.”

DORA-testausohjelmassa testiluettelosta tulee silta riskien käsittelyn ja operatiivisen näytön välille. Soveltuvuuslausunnossa ei tule todeta kontrollia soveltuvaksi, jos testinäyttö sijaitsee muualla kartoittamattomana ja hallitsemattomana.

Tämä taulukko auttaa tietoturvajohtajaa vastaamaan toimitusjohtajan yleiseen kysymykseen: “Riittävätkö ISO-penetraatiotestimme ja haavoittuvuusskannauksemme DORAa varten?”

Vastaus on: ne voivat olla osa DORA-vaatimustenmukaisuutta, mutta vain jos ne ovat riskiperusteisia, linkitettyjä kriittisiin tai tärkeisiin toimintoihin, politiikan hallinnoimia, korjaavien toimenpiteiden kautta seurattuja ja johdolle raportoituja.

Haavoittuvuusarvioinnit: jatkuvaa näyttöä, ei pelkkää skannaustulostetta

Haavoittuvuusarviointi on usein helpoin testausaktiviteetti toteuttaa ja helpoin käsitellä väärin. Monet organisaatiot voivat tuottaa skannausraportteja. Harvemmat voivat osoittaa, että skannaukset kattavat oikeat omaisuuserät, priorisoivat kriittiset palvelut, tuottavat oikea-aikaisia korjauksia ja syöttävät riskienkäsittelypäätöksiä.

Clarysecin Vulnerability and Patch Management Policy-sme - SME alkaa oikeasta tavoitteesta:

“Tunnistaa ja arvioida tunnetut haavoittuvuudet kaikissa IT-omaisuuserissä oikea-aikaisesti ja johdonmukaisesti”

DORA:n näkökulmasta tämä tukee ICT-riskilähteiden tunnistamista, häiriönsietokykyisiä ja päivitettyjä järjestelmiä, seurantaa, poikkeamien havaitsemista ja jatkuvaa parantamista. ISO/IEC 27001:2022:ssa se kartoittuu suoraan kohtaan 8.8 Teknisten haavoittuvuuksien hallinta, ja se tukeutuu myös kohtiin 5.9 Tietojen ja muun niihin liittyvän omaisuuden inventointi, 8.16 Valvontatoiminnot ja 8.32 Muutoksenhallinta.

Vahvan haavoittuvuusarvioinnin tallenteen tulee sisältää:

• Rajauksessa käytetty omaisuusluettelon tilannekuva
• Skannauspäivä, työkalu ja todennettu tai todentamaton menetelmä
• Poissulut ja liiketoimintaperuste
• Havainnot vakavuuden, hyväksikäytettävyyden ja liiketoimintapalvelun mukaan
• Kartoitus kriittisiin tai tärkeisiin toimintoihin ja tietotyyppeihin
• Tikettiviitteet ja riskinomistaja
• Korjauksen palvelutasotavoite ja määräpäivä
• Uusintatestauksen tulos
• Poikkeukset, joissa on jäännösriskin hyväksyntä

Zenith Controls sijoittaa kohdan 8.8 Teknisten haavoittuvuuksien hallinta keskeiseksi näyttöalueeksi tunnistamista, arviointia, priorisointia ja korjaavien toimenpiteiden seurantaa varten. Se myös osoittaa, miksi auditoijat testaavat viereisiä prosesseja. Jos omaisuusluettelo on puutteellinen, haavoittuvuuksien kattavuus on puutteellinen. Jos muutoksenhallinta ohitetaan, korjauspäivityksen käyttöönotto voi luoda uutta operatiivista riskiä. Jos valvonta on heikkoa, hyväksikäyttöyrityksiä ei välttämättä havaita.

Skenaariotestit: osoita päätöksenteko ennen todellista poikkeamaa

Skenaariotesteissä operatiivinen häiriönsietokyky tulee näkyväksi ylimmälle johdolle. Kiristyshaittaohjelmaa koskeva pöytäharjoitus, pilvialueen katkon simulointi, etuoikeutetun pääsyn vaarantumisharjoitus tai kriittisen ICT-palveluntarjoajan vikaantumisskenaario paljastaa heikkouksia, joita skannaus ei voi osoittaa.

DORA Articles 17–20 edellyttävät muodollista ICT-poikkeaman elinkaarta: havaitseminen, hallinta, ilmoittaminen, kirjaaminen, seuranta, käsittely, jatkotoimet, juurisyyn dokumentointi, korjaaminen, vakavuuden luokittelu, roolien osoittaminen, merkittävien poikkeamien eskalointi ja raportointi vaadituissa vaiheissa. Kun asiakkaiden taloudellisiin etuihin kohdistuu vaikutuksia, asiakkaille on ilmoitettava ilman aiheetonta viivytystä.

NIS2 sisältää samankaltaisen kiireellisyyden sen soveltamisalaan kuuluville toimijoille, mukaan lukien ennakkovaroitus, ilmoittaminen, väliraportointi ja loppuraportointi. Soveltamisalaan kuuluville finanssialan toimijoille DORA on sektorikohtainen säädös vastaaville kyberturvallisuusriskien hallintaa ja raportointia koskeville velvoitteille. ICT-palveluntarjoajien, SaaS-alustojen, MSP-palveluntarjoajien ja MSSP-palveluntarjoajien on silti tarkistettava, kuuluvatko ne suoraan NIS2:n soveltamisalaan vai tulevatko ne sopimuksellisesti DORA-varmentamisen piiriin säänneltyjen asiakkaiden kautta.

Zenith Blueprint, Controls in Action -vaihe, vaihe 23, antaa käytännön näyttömallin:

“Valitse tuore tapahtuma tai toteuta pöytäharjoitus suunnitelman validoimiseksi. Kerää ja kirjaa lokiin kaikki päätökset, roolit ja viestintä (5.26) sekä päivitä suunnitelma opittujen asioiden perusteella (5.27).”

DORA-skenaariotestin tulee tuottaa auditoitavia tallenteita, ei vain kokousmuistiinpanoja:

• Skenaariokuvaus ja tavoitteet
• Osallistujat ja roolit, mukaan lukien lakiasiat, viestintä, IT, SOC, liiketoimintavastaava ja toimittajayhteyshenkilöt
• Syötteiden ja päätösten aikajana
• Luokittelupäätös ja raportointikynnyksen analyysi
• Luonnokset sisäisestä ja ulkoisesta viestinnästä
• Todistusaineiston säilyttämistoimet
• Opitut asiat
• Toimenpiteiden omistajat ja määräpäivät
• Päivitetyt poikkeama-, jatkuvuus- tai viestintämenettelyt

Clarysecin Business Continuity Policy and Disaster Recovery Policy-sme - SME vahvistaa vuosittaisen testausodotuksen:

“Organisaation on testattava sekä BCP- että DR-kyvykkyytensä vähintään vuosittain. Testien tulee sisältää:”

Testiluettelon tulee muuntaa tämä velvoite konkreettisiksi harjoituksiksi, kuten kriisinhallinnan pöytäharjoitukseksi, varmuuskopion palautustestiksi, pilvipalvelun failover-testiksi, yhteystietoketjun testiksi ja toimittajahäiriön simuloinniksi.

Suorituskyky-, kapasiteetti- ja palautustestit: usein laiminlyöty häiriönsietokyvyn näyttö

Suorituskykytestausta käsitellään usein teknisen kehityksen asiana. DORA:n näkökulmasta siitä tulee häiriönsietokyvyn näyttöä.

Kaupankäyntialusta, maksupalvelu, korvauskäsittelyjärjestelmä, identiteettialusta tai asiakasportaali ei tarvitse kyberhyökkäystä epäonnistuakseen asiakkaiden näkökulmasta. Kapasiteetin loppuminen, jonojen saturoituminen, tietokantapullonkaulat, virheellisesti määritetty automaattinen skaalaus tai rikkinäinen failover voivat aiheuttaa saman operatiivisen häiriön kuin tietoturvapoikkeama.

ISO/IEC 27001:2022 liite A 8.6 Kapasiteetin hallinta on ensisijainen ankkuri. Näyttö voi sisältää kuormitustestauksen, stressitestauksen, palvelun heikkenemisen testauksen, infrastruktuurin kynnysarvojen validoinnin, varmuuskopioiden palautustestit ja failover-simulaatiot.

Hyvän suorituskyky- ja kapasiteettitestauksen tallenteen tulee kuvata:

• Perustason normaalikuormitus ja huippukuormitusoletukset
• Testatut kriittiset tapahtumapolut
• Testatut infrastruktuuri- ja pilvirajat
• Valvontamittaristot ja hälytyskynnykset
• Vikatilat, kuten jonojen saturoituminen tai tietokantapullonkaulat
• RTO- ja RPO-relevanssi, kun failoveria tai palautusta testataan
• Liiketoimintavaikutus, jos kynnysarvot ylittyvät
• Korjaavat toimenpiteet, skaalauspäätökset tai arkkitehtuurimuutokset
• Johdon hyväksyntä jäännöskapasiteettiriskille

Zenith Blueprint, vaihe 23, yhdistää palautusodotukset näyttöön:

“Varmista, että kriittisten järjestelmien toipumisaikatavoite (RTO) ja palautuspistetavoite (RPO) ovat linjassa liiketoiminnan jatkuvuuden odotusten kanssa (5.30). Suorita vähintään yksi tekninen palautustesti tai failover-simulaatio ja dokumentoi tulokset.”

Tämä on ero sen välillä, että sanotaan “meillä on varmuuskopiot”, ja sen välillä, että osoitetaan kriittisen palvelun palautuneen sovitun toleranssin puitteissa dokumentoiduin tuloksin ja johdon näkyvyydellä.

Penetraatiotestaus ja red team -harjoitukset: vahva näyttö edellyttää vahvaa hallintaa

Penetraatiotestaus on erittäin arvokasta näyttöä, mutta siihen liittyy myös operatiivista riskiä. Puutteellisesti hallinnoitu testaus voi vaikuttaa tuotantojärjestelmiin, altistaa arkaluonteisia tietoja, käynnistää hallitsemattomia hälytyksiä, luoda oikeudellisia ongelmia tai häiritä asiakkaita.

Application Security Requirements Policy-sme - SME asettaa selkeän julkaisuportin:

“Ennen käyttöönottoa kaikille sovelluksille on tehtävä tietoturvatestaus edellä lueteltujen perustason ominaisuuksien varmentamiseksi.”

Kriittisten sovellusten osalta tämän tulee syöttää DORA-luetteloon esituotannon tietoturvatestauksena, korkean riskin muutosten tuotantokäyttöönoton jälkeisenä validointina ja altistumiseen sekä kriittisyyteen perustuvana säännöllisenä penetraatiotestauksena.

Security Testing and Red-Teaming Policy vahvistaa korjausketjua:

“Havaintojen korjaaminen: Kaikki tunnistetut haavoittuvuudet tai heikkoudet on dokumentoitava havaintoraporttiin vakavuusluokituksineen. Raportin vastaanottamisen jälkeen järjestelmäomistajat vastaavat määräpäivällisen korjaussuunnitelman laatimisesta; esimerkiksi kriittiset havainnot on korjattava 30 päivän kuluessa ja vakavat havainnot 60 päivän kuluessa organisaation Vulnerability and Patch Management Policy -politiikan mukaisesti. STC seuraa korjaavien toimenpiteiden etenemistä. Uusintatestaus suoritetaan sen varmistamiseksi, että kriittiset ongelmat on ratkaistu tai lievennetty riittävästi.”

Sama politiikka määrittää raportointiodotukset:

“Raportointi: Jokaisen testin päätyttyä on annettava muodollinen raportti. Penetraatiotestauksen osalta raportin tulee sisältää johdon yhteenveto, menetelmäkuvaus sekä yksityiskohtaiset havainnot niitä tukevine näyttöineen ja suosituksineen.”

Zenith Blueprint, vaihe 21, korostaa myös suojausta auditoinnin ja testauksen aikana:

“Mitään testiä tai auditointia ei tule aloittaa ilman järjestelmäomistajien tai asiaankuuluvien sidosryhmien dokumentoitua hyväksyntää.”

Toimintasäännöt, testi-ikkunat, hätäyhteyshenkilöt, tilapäinen käyttöoikeus, tietojen käsittely, lokitus, palautusmenettelyt ja oikeudelliset hyväksynnät eivät ole byrokratiaa. Ne ovat häiriönsietokyvyn suojatoimia.

Ota ICT-palveluntarjoajat mukaan ennen kuin testi epäonnistuu

DORA tekee ICT-palveluntarjoajariskistä keskeisen häiriönsietokyvyn kysymyksen. Article 28 edellyttää, että finanssialan toimijat hallitsevat ICT-palveluntarjoajiin liittyvää riskiä ICT-riskien hallinnan viitekehyksessä, pysyvät vastuussa käyttäessään ICT-palveluja, ylläpitävät tietorekisteriä, raportoivat tietyistä järjestelyistä, tekevät sopimusta edeltäviä arviointeja ja käyttävät palveluntarjoajia, jotka täyttävät asianmukaiset tietoturvastandardit. Articles 29 ja 30 käsittelevät keskittymäriskiä, alihankintaa, tietojen palautusta, sopimuksellisia suojauksia, palvelutasoja, poikkeamissa avustamista, auditointioikeuksia, palveluntarjoajan varautumistestausta, osallistumista testaukseen soveltuvin osin ja irtautumisjärjestelyjä.

ISO/IEC 27001:2022 liite A tarjoaa tukevia toimittajakontrolleja, kuten 5.19 Tietoturva toimittajasuhteissa, 5.20 Tietoturvan huomiointi toimittajasopimuksissa, 5.21 Tietoturvan hallinta ICT-toimitusketjussa, 5.22 Toimittajapalvelujen valvonta, katselmointi ja muutoksenhallinta sekä 5.23 Tietoturva pilvipalvelujen käytössä.

DORA-testiluettelon tulee tunnistaa, mitkä testit edellyttävät toimittajan osallistumista tai toimittajanäyttöä. Esimerkkejä ovat:

• Pilvipalveluntarjoajan failover-oletukset
• Hallinnoidun SOC:n eskalointi ja todistusaineiston säilyttäminen
• Ydinpankkialustan poikkeamaviestintä
• Maksunkäsittelijän katkosskenaario
• Identiteetin tarjoajan palautustesti
• SaaS-toimittajan penetraatiotestauksen vaatimustenmukaisuusvakuutukset
• Kriittisen alihankintaketjun vaikutusten arviointi

Ohjelma, joka sulkee kriittiset ICT-palveluntarjoajat ulkopuolelle, epäonnistuu todellisuustestissä. Asiakasrajapinnan palvelu voi olla teidän, mutta häiriönsietokyvyn riippuvuus voi sijaita pilvialueessa, ulkoistetussa SOC:ssa, identiteetin tarjoajassa, ohjelmistotoimittajassa, maksunkäsittelijässä tai datakeskuksessa.

Ristiinvaatimustenmukaisuuden kartoitus: yksi näyttökokonaisuus, monta velvoitetta

Hyvin suunniteltu DORA-testausohjelma vähentää auditointikuormaa. Sama näyttö voi tukea DORAa, ISO/IEC 27001:2022:ta, NIS2:ta, GDPR:ää, NIST CSF 2.0:aa ja COBIT 2019 -hallinnointikatselmointeja, jos se merkitään, säilytetään ja raportoidaan oikein.

GDPR:ää ei pidä unohtaa. Jos häiriönsietokykytestit sisältävät henkilötietoja, lokeja, asiakastietueita, identiteettitietoja, HR-tietoja, biometrisiä tietoja tai erityisiin henkilötietoryhmiin kuuluvia tietoja, organisaation on noudatettava GDPR-periaatteita, mukaan lukien lainmukaisuus, kohtuullisuus, läpinäkyvyys, tietojen minimointi, säilytyksen rajoittaminen, eheys, luottamuksellisuus ja osoitusvelvollisuus. Testidatakopiot, viedyt lokit ja penetraatiotestauksen näyttö voivat muodostua sääntelyn alaisiksi tietovarastoiksi. Testausohjelman tulee määrittää, kenellä on pääsy niihin, kuinka kauan niitä säilytetään ja miten ne hävitetään turvallisesti.

Miten auditoijat testaavat samaa ohjelmaa

DORA-valvoja, ISO-auditoija, NIST-pohjainen arvioija, COBIT-katselmoija ja asiakasauditoija voivat tarkastaa samaa näyttöä eri näkökulmista.

Zenith Controls toimii tässä ristiinvaatimustenmukaisuuden kompassina. DORA-testauksen osalta Clarysec korostaa kohtia 5.35 Tietoturvan riippumaton katselmointi, 8.8 Teknisten haavoittuvuuksien hallinta ja 8.6 Kapasiteetin hallinta erityisen tärkeinä ISO/IEC 27001:2022 liite A -ankkureina. Ne auttavat kontrollien omistajia yhdistämään testauksen riippumattomaan varmentamiseen, haavoittuvuuksien käsittelyyn ja operatiiviseen kapasiteettiin.

Clarysecin Information Security Policy tukee myös auditointijälkeä:

“Kontrollien omistajien tulee ylläpitää testituloksia, lokeja ja katselmointitallenteita säännöllisten auditointien tueksi.”

Tästä lauseesta tulisi tehdä operatiivinen sääntö. Jokaisen testinomistajan tulee tietää, mitä säilytetään, missä sitä säilytetään, miten sitä suojataan ja miten se liittyy riski- ja kontrollinäyttöön.

Rakenna DORA–ISO-näyttöpaketti viikossa

Finanssialan toimija tai ICT-palveluntarjoaja voi edetä merkittävästi viidessä työpäivässä.

Päivä 1: Määritä soveltamisala ja kriittisyys

Hyödynnä ISO/IEC 27001:2022 kohtien 4.1–4.4 mukaista ajattelua. Tunnista sidosryhmät, sääntelyvelvoitteet, sopimusvelvoitteet, rajapinnat ja riippuvuudet. Listaa liiketoimintapalvelut, kriittiset tai tärkeät toiminnot, keskeiset omaisuuserät, tietotyypit ja ICT-palveluntarjoajat.

Tuotos: DORA-testauksen soveltamisalarekisteri.

Päivä 2: Luo vuosittainen testiluettelo

Käytä neljää testausperhettä: haavoittuvuus, skenaario, suorituskyky ja penetraatio. Määritä kullekin palvelulle sovellettavat testit, testitiheys, omistaja, riippumattomuustaso ja käynnistävä tekijä. Sisällytä korkean riskin muutosten käynnistävät tekijät.

Tuotos: vuoden 2026 digitaalisen häiriönsietokyvyn testiluettelo.

Päivä 3: Kartoita kontrollit ja velvoitteet

Kartoita jokainen testi ISO/IEC 27001:2022 liite A:han, riskirekisteriin, SoA:han, DORA-artikloihin, toimittajavelvoitteisiin ja asiaankuuluviin Zenith Controls -merkintöihin. Esimerkiksi kuukausittaiset ulkoiset haavoittuvuusskannaukset kartoittuvat kohtaan 8.8 Teknisten haavoittuvuuksien hallinta, riskien käsittelyyn, valvontaan, DORA:n ICT-riskien hallintaan ja NIST CSF:n haavoittuvuustuloksiin.

Tuotos: kontrollikartoitusmatriisi.

Päivä 4: Yhdenmukaista näyttökansiot

Luo hallittu näyttörakenne:

• 01 Suunnitelma ja valtuutus
• 02 Soveltamisala ja toimintasäännöt
• 03 Raakatulokset
• 04 Loppuraportti
• 05 Havaintorekisteri
• 06 Korjaavien toimenpiteiden tiketit
• 07 Uusintatestauksen näyttö
• 08 Johdon raportointi
• 09 Opitut asiat ja politiikkapäivitykset

Tuotos: näyttöaineiston tietovarasto säilytyssääntöineen.

Päivä 5: Katselmoi havainnot ja raportointi

Konsolidoi avoimet havainnot vakavuuden, palvelun, riskinomistajan ja määräpäivän mukaan. Tunnista myöhässä olevat korjaavat toimenpiteet, hyväksytyt riskit ja uusintatestauksen puutteet. Valmistele hallintoelimelle mittaristo, joka näyttää testikattavuuden, merkittävät havainnot, myöhässä olevat toimenpiteet, kolmansien osapuolten ongelmat ja jäännösriskin.

Tuotos: hallitukselle valmis DORA- ja ISO-testausmittaristo.

DORA-testausohjelmien yleiset sudenkuopat

Yleisin epäonnistuminen ei ole testauksen puute. Se on hallinnoinnin puute.

Tarkkaile seuraavia ongelmia:

• Penetraatiotestit tehdään vuosittain, mutta havaintoja ei seurata sulkemiseen asti
• Haavoittuvuusskannauksia ajetaan usein, mutta kriittiset omaisuuserät puuttuvat soveltamisalasta
• Pöytäharjoituksia pidetään, mutta päätösloki tai opittuihin asioihin perustuva toimintasuunnitelma puuttuu
• Varmuuskopioiden palautustestit on tehty, mutta niitä ei ole kartoitettu RTO:hon ja RPO:hon
• Tekninen kehitystiimi tekee kuormitustestit, mutta tuloksia ei raportoida riskienhallinnalle tai compliance-toiminnolle
• ICT-palveluntarjoajat jätetään skenaario- ja palautustestien ulkopuolelle
• Näyttö säilytetään henkilökohtaisissa kansioissa, chat-ketjuissa tai hallitsemattomilla levyillä
• Hallitusraportit keskittyvät aktiviteettimääriin ratkaisemattoman häiriönsietokykyriskin sijaan
• SoA toteaa kontrollin soveltuvan, mutta testinäyttöä ei ole
• Testaus aiheuttaa tuotantoriskin, koska valtuutus ja rajaukset ovat epäselvät

Jokainen puute on korjattavissa. Ratkaisu ei ole satunnaisen testauksen lisääminen. Ratkaisu on yksi hallittu ohjelma, joka yhdistää riskin, testausaktiviteetin, korjaavat toimenpiteet, näytön ja johdon valvonnan.

Mitä hallituksen tulisi tosiasiassa nähdä

DORA tekee ICT-häiriönsietokyvystä hallintoelimen vastuun. Hyödyllisen hallitusraportin ei tule sisältää jokaista teknistä havaintoa. Sen tulee vastata siihen, onko organisaation häiriönsietokyky riittävä sen riskinottohalukkuuteen ja häiriönsietotoleranssiin nähden.

Vahva neljännesvuosittainen tai puolivuosittainen raportti sisältää:

• Testikattavuus suhteessa kriittisiin tai tärkeisiin toimintoihin
• Toteutuneet verrattuna suunniteltuihin testeihin
• Kriittiset ja vakavat havainnot palveluittain
• Myöhässä olevat korjaavat toimenpiteet omistajittain
• Uusintatestauksen läpäisyaste
• Toimittajiin liittyvät havainnot ja keskittymähuolet
• Skenaariotestien opit, jotka vaikuttavat kriisi- tai poikkeamasuunnitelmiin
• Kapasiteettiriskit suhteessa liiketoiminnan kasvuun ja huippujaksoihin
• Jäännösriskit, jotka edellyttävät johdon hyväksyntää
• Budjetti-, resurssi- tai työkalurajoitteet

Tästä raportista tulee ISO:n johdon katselmoinnin syöte, DORA-hallinnointinäyttö ja käytännöllinen päätöksenteon väline.

Hajanaisista testeistä strategiseksi häiriönsietokyvyksi

Tietoturvajohtajan alkuperäinen ongelma ei ollut se, että testaus puuttui. Organisaatiolla oli skannauksia, pöytäharjoituksia, kuormitusraportteja ja penetraatiotestaus-PDF:iä. Ongelma oli, että nämä toimet eivät vielä muodostaneet yhtä johdonmukaista näyttötarinaa.

Yhtenäinen DORA- ja ISO/IEC 27001:2022 -testausohjelma muuttaa tämän. Riskienarviointi ohjaa luetteloa. Luettelo ohjaa valtuutettua testausta. Testaus tuottaa havaintoja. Havainnot ohjaavat korjaavia toimenpiteitä ja uusintatestausta. Tulokset syöttävät johdon raportointia. Opitut asiat päivittävät politiikkoja, menettelyjä, sopimuksia ja kontrolleja.

Näin vaatimustenmukaisuuskuormasta tulee strateginen kyvykkyys.

Clarysec auttaa organisaatioita välttämään rinnakkaiset vaatimustenmukaisuusohjelmat. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 ja COBIT 2019 eivät tarvitse erillisiä näyttömaailmoja. Ne tarvitsevat yhden hallinnoidun toimintamallin, joka voidaan esittää eri auditointinäkökulmista.

Lähestymistapamme yhdistää:

• Zenith Blueprint vaiheittaiseen ISO-toteutukseen ja auditointivalmiuteen
• Zenith Controls ristiinvaatimustenmukaisuuden kartoitukseen kontrollien, viitekehysten ja auditointiodotusten välillä
• Yritys- ja pk-yrityspolitiikat tietoturvatestaukseen, auditointiseurantaan, haavoittuvuuksien hallintaan, sovellusturvallisuuteen, jatkuvuuteen ja tietoturvaan
• Käytännölliset rekisterit, näyttörakenteet ja johdon raportointimallit

Jos vuoden 2026 DORA-testausnäyttönne on hajallaan skannaustyökaluissa, teknisen kehityksen kansioissa, pöytäharjoitusmuistiinpanoissa ja penetraatiotestaus-PDF:issä, nyt on aika konsolidoida se.

Aloita yhdestä vuosittaisesta testiluettelosta, joka on kartoitettu ISO/IEC 27001:2022 -riskien käsittelyyn, SoA:han, kriittisiin tai tärkeisiin toimintoihin, ICT-palveluntarjoajiin ja johdon raportointiin. Käytä sen jälkeen Clarysecin Zenith Blueprint, Zenith Controls ja politiikkatyökalustoa muuttaaksesi luettelon puolustettavaksi auditointinäytöksi.

Clarysec voi auttaa suunnittelemaan ohjelman, kartoittamaan kontrollit, rakentamaan näyttöpaketin ja valmistelemaan hallitustason häiriönsietokykyraportin ennen seuraavaa valvontapyyntöä.