DORA-poikkeamaraportointi ja ISO 27001 -hallintakeinot vuonna 2026

Kello on 08.17 tiistaiaamuna vuonna 2026. Sarah, eurooppalaisen FinTech-yhtiön tietoturvajohtaja, näkee hallintanäkymässä keltaisen varoituksen, ei punaista hälytystä. Kriittinen maksujen selvitysalusta hidastuu. Transaktiot eivät epäonnistu kokonaan, mutta niiden käsittely kestää kolme kertaa kauemmin kuin palvelutasosopimus sallii. SOC havaitsee poikkeavia todennusyrityksiä ylläpitäjätiliä vastaan. Pilvi-infrastruktuurin palveluntarjoaja ilmoittaa palvelun heikentyneen yhdellä saatavuusvyöhykkeellä. Asiakastuki alkaa saada yritysasiakkailta puheluita siitä, miksi maksuaineistot viivästyvät.

Kukaan ei vielä tiedä, onko kyseessä kyberhyökkäys, operatiivisen häiriönsietokyvyn pettäminen, toimittajan palvelukatkos, tietosuojapoikkeama vai kaikki nämä samanaikaisesti.

Sarahilla on DORA-ongelma ennen kuin tekniset tosiseikat ovat selvillä. Onko tämä merkittävä ICT:hen liittyvä poikkeama? Vaikuttaako se kriittiseen tai tärkeään toimintoon? Onko sisäinen vakavuuskynnys ylittynyt? Kenelle on ilmoitettava, milloin ja millä näytöllä? Jos henkilötietoja on mukana, onko myös GDPR:n ilmoituskello käynnistynyt? Jos poikkeamaketjussa on mukana kolmannen osapuolen ICT-palveluntarjoaja, kuka omistaa tosiseikat?

Tässä kohdassa finanssialan toimijat huomaavat eron tietoturvapoikkeamiin reagointisuunnitelman ja auditoitavissa olevan DORA-poikkeamaraportoinnin toimintamallin välillä.

DORA-poikkeamaraportointi vuonna 2026 edellyttää muutakin kuin nopeaa eskalointia. Se edellyttää puolustettavissa olevaa ketjua havaitsemisesta luokitteluun, luokittelusta viranomaisraportointiin, raportoinnista korjaaviin toimenpiteisiin ja korjaavista toimenpiteistä opittuihin kokemuksiin. ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän rakenteen. ISO/IEC 27002:2022 -standardin liitteen A hallintakeinot määrittävät käytännön hallintakeino-odotukset. Clarysecin politiikat, 30-vaiheinen tiekartta ja cross-compliance-opas muuttavat nämä odotukset auditointivalmiiksi toteutukseksi.

Miksi DORA-poikkeamaraportointi epäonnistuu paineen alla

Useimmat DORA-poikkeamaraportoinnin epäonnistumiset eivät ala huolimattomuudesta. Ne alkavat epäselvyydestä.

Tietoturva-analyytikko näkee hälytyksen mutta ei tiedä, täyttääkö se DORA:n mukaisen ICT:hen liittyvän poikkeaman kriteerit. IT-palvelupäällikkö käsittelee heikentynyttä suorituskykyä teknisenä palveluongelmana, kun taas vaatimustenmukaisuustoiminto näkee sen sääntelyyn liittyvänä tapahtumana. Lakiasiat odottaa vahvistusta ennen eskalointia. Liiketoimintavastaava ei vielä pysty määrällistämään asiakasvaikutusta. Tietoturvajohtaja tarvitsee näyttöä, mutta asiaankuuluvat lokit ovat hajallaan pilvipalveluissa, päätelaitteissa, identiteettijärjestelmissä, SIEMissä ja toimittaja-alustoilla.

Kun organisaatio pääsee yhteisymmärrykseen luokittelusta, raportointi-ikkuna on jo paineen alla.

DORA Article 17–21 luovat jäsennetyn odotuksen ICT:hen liittyvien poikkeamien hallinnalle, luokittelulle, raportoinnille, raportoinnin sisällölle ja valvontakäsittelylle. Finanssialan toimijoille käytännön vaatimus on selvä: ICT:hen liittyviä poikkeamia on seurattava, hallittava, kirjattava, luokiteltava, raportoitava ja päivitettävä, ja niistä on opittava tavalla, joka voidaan jälkikäteen rekonstruoida.

Clarysecin Tietoturvapoikkeamien hallintapolitiikka [IRP] sisällyttää DORA:n suoraan viitekehykseen:

EU:n DORA-asetus (2022/2554): Article 17: ICT-poikkeamien raportointivaatimukset finanssilaitoksille toimivaltaisille viranomaisille.

Sama politiikka kytkee poikkeamien hallinnan ISO/IEC 27002:2022 -standardin hallintakeinoihin 5.25–5.27, jotka kattavat vastuut poikkeamien arvioinnista, reagoinnista, viestinnästä ja parantamisesta.

Pienemmille finanssiteknologiayrityksille ja kevytrakenteisille säännellyille toimijoille Clarysecin Tietoturvapoikkeamien hallintapolitiikka - SME [IRP-SME] tekee velvoitteesta käytännöllisen korostamalla, että DORA edellyttää finanssialan toimijoilta ICT:hen liittyvien poikkeamien ja häiriöiden luokittelua, raportointia ja seurantaa.

Tällä sanamuodolla on merkitystä. DORA:n noudattaminen ei ole pelkkä raportointimalli. Organisaation on luokiteltava, raportoitava ja seurattava. Se tarkoittaa näyttöä alkuperäisestä tapahtumasta, päätöskriteereistä, vakavuustasosta, raportointipäätöksestä, viestinnästä, palautustoimista, toimittajan osuudesta ja jatkotoimista.

ISO/IEC 27001:2022 DORA-poikkeamien johtokeskuksena

Kypsä ISO/IEC 27001:2022 -standardin mukainen tietoturvallisuuden hallintajärjestelmä (ISMS) ei saa muodostua DORA:n viereiseksi erilliseksi vaatimustenmukaisuussiiloksi. Sen tulee toimia DORA-poikkeamaraportoinnin johtokeskuksena.

ISMS edellyttää jo riskinomistajuutta, hallintakeinojen valintaa, sisäistä tarkastusta, johdon katselmointia, dokumentoitua tietoa, jatkuvaa parantamista ja näyttöä hallintakeinojen toiminnasta. DORA lisää toimialakohtaisen raportointipaineen, mutta ISO/IEC 27001:2022 antaa hallintarakenteen, jonka avulla prosessista tehdään toistettava.

Clarysecin Zenith Blueprint: auditoijan 30-vaiheinen tiekartta [ZB] vahvistaa tätä integraatiota vaiheessa 13, riskienkäsittelyn suunnittelu ja soveltuvuuslausunto. Blueprint suosittelee hallintakeinojen kytkemistä riskeihin ja lausekkeisiin jäljitettävyyden vuoksi, mukaan lukien liitteen A hallintakeinoviitteen lisääminen riskeihin sekä merkintä siitä, milloin hallintakeinot tukevat GDPR:ää, NIS2:ta tai DORA:a.

Sarahin maksujen selvitystä koskevassa poikkeamassa riskirekisterin kirjaus voisi olla:

”Maksunkäsittelyalustan häiriö tai vaarantuminen.”

Kytketyt ISO/IEC 27001:2022 -standardin liitteen A hallintakeinot sisältäisivät 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 ja 8.16 sekä DORA-huomautuksen merkittävän ICT:hen liittyvän poikkeaman luokittelusta ja raportoinnista.

Clarysecin Zenith Controls: Cross-Compliance-opas [ZC] toimii tämän jälkeen cross-compliance-kompassina. Zenith Controls -oppaassa Clarysec kytkee ISO/IEC 27002:2022 -hallintakeinot muihin ISO/IEC 27001:2022 -hallintakeinoihin, liittyviin standardeihin, auditointiodotuksiin ja sääntelyihin, kuten DORA, GDPR ja NIS2. Se ei luo erillisiä ”Zenith-kontrolleja”. Se osoittaa, miten olemassa olevat ISO-hallintakeinot toimivat yhdessä ja miten niitä testataan.

DORA-raportoinnin työnkulku voidaan nähdä hallintakeinoketjuna:

Et voi raportoida sitä, mitä et havainnut. Et voi luokitella sitä, mitä et arvioinut. Et voi perustella raportointipäätöstä ilman tallenteita. Et voi parantaa ilman poikkeaman jälkiarviointia.

Hallintakeino 6.8: DORA-kello käynnistyy ihmisistä

Sarahin tapauksessa ensimmäinen hyödyllinen signaali ei välttämättä tule SOC:sta. Se voi tulla asiakassuhdevastaavalta, joka kuulee asiakkaiden valituksia, taloushallinnon käyttäjältä, joka näkee epäonnistuneita selvityseriä, tai insinööriltä, joka huomaa poikkeavan viiveen.

Siksi ISO/IEC 27001:2022 -standardin liitteen A hallintakeino 6.8, tietoturvatapahtumien raportointi, on DORA:n kannalta olennainen. Se tekee raportoinnista koko henkilöstön vastuun, ei pelkästään tietoturvaoperaatioiden tehtävää.

Zenith Blueprint -oppaassa vaihe 16, henkilöstöön liittyvät hallintakeinot II, Clarysec toteaa:

Tehokas tietoturvapoikkeamiin reagointijärjestelmä ei ala työkaluista vaan ihmisistä.

Vaihe 16 suosittelee selkeitä ilmoituskanavia, tietoisuuskoulutusta, syyllistämätöntä kulttuuria, luokittelua, luottamuksellisuutta ja säännöllisiä simulaatioita. Hyödyllisin käytännön viesti on yksinkertainen:

”Jos olet epävarma, ilmoita.”

Tämä on DORA:n hallintakeinoperiaate. Jos työntekijät odottavat varmuutta, organisaatio menettää aikaa. Jos he ilmoittavat varhain, organisaatio voi arvioida, luokitella ja päättää.

Zenith Controls -oppaassa 6.8 on kytketty havaitsevaksi hallintakeinoksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Se liittyy hallintakeinoon 5.24, koska ilmoituskanavien on oltava osa poikkeamasuunnitelmaa. Se syöttää hallintakeinoa 5.25, koska tapahtumia voidaan arvioida vain, jos niistä ilmoitetaan. Se käynnistää hallintakeinon 5.26, koska muodollinen reagointi alkaa sen jälkeen, kun ilmoitukset on arvioitu.

DORA:n osalta tämä tukee Article 17 ja Article 18 -vaatimuksia, joiden mukaan finanssialan toimijoiden on hallittava, luokiteltava ja raportoitava merkittävät ICT:hen liittyvät poikkeamat ja merkittävät kyberuhat. Se tukee myös GDPR Article 33 ja Recital 85 -kohtia, koska sisäinen ilmoittaminen määrittää, kuinka nopeasti henkilötietojen tietoturvaloukkaus tunnistetaan ja eskaloidaan.

Käytännöllinen Clarysec-toteutus on yhden sivun ohje ”ICT-poikkeaman ilmoittaminen”. Sen tulee sisältää:

• Mitä ilmoitetaan, mukaan lukien käyttökatkot, epäilyttävät sähköpostit, kadonneet laitteet, poikkeava järjestelmäkäyttäytyminen, epäilty toimittajan vaarantuminen, luvaton pääsy, tietovuoto ja asiakasvaikutteinen palvelun heikentyminen.
• Miten ilmoitetaan käyttämällä valvottua sähköpostilaatikkoa, tikettikategoriaa, puhelinlinjaa, yhteistyökanavaa tai SOC-portaalia.
• Mitä tietoja ilmoitukseen sisällytetään, kuten aika, järjestelmä, käyttäjä, liiketoimintaprosessi, havaittu vaikutus, kuvakaappaukset, jos niiden ottaminen on turvallista, sekä tieto siitä, voiko vaikutus kohdistua asiakkaisiin tai henkilötietoihin.
• Mitä ei tehdä, mukaan lukien lokien poistamisen välttäminen, kriittisten järjestelmien uudelleenkäynnistämättä jättäminen ilman ohjeistusta, asiakkaisiin suuntautuvan ulkoisen yhteydenpidon välttäminen ilman hyväksyntää ja oman roolin ylittävän tutkinnan välttäminen.
• Mitä seuraavaksi tapahtuu, mukaan lukien triage, luokittelu, eskalointi, reagointi, todistusaineiston säilyttäminen ja mahdollinen sääntelyarviointi.

Tavoitteena ei ole tehdä jokaisesta työntekijästä tutkijaa. Tavoitteena on tehdä jokaisesta työntekijästä luotettava signaalilähde.

Hallintakeino 5.25: DORA-luokittelun päätöspiste

DORA:n mukaisten merkittävien ICT:hen liittyvien poikkeamien raportointi perustuu luokitteluun. Tässä ISO/IEC 27001:2022 -standardin liitteen A hallintakeino 5.25, tietoturvatapahtumien arviointi ja päätöksenteko, nousee keskeiseksi.

Zenith Blueprint -oppaan vaihe 23 kuvaa käytännön haasteen:

Kaikki poikkeamat eivät ole katastrofeja. Kaikki hälytykset eivät osoita vaarantumista.

Se kuvaa hallintakeinon 5.25 tarkoituksen seuraavasti:

erottaa harmiton haitallisesta ja tunnistaa, mikä edellyttää eskalointia.

DORA:n näkökulmasta tämä on hetki, jolloin tietoturvatapahtuma, palvelun heikentyminen, toimittajan palvelukatkos, tietojen altistuminen tai operatiivinen häiriö arvioidaan merkittävän poikkeaman kriteerejä vasten. Organisaation on huomioitava operatiivinen vaikutus, vaikutuksen kohteena olevat palvelut, kriittiset tai tärkeät toiminnot, vaikutuksen kohteena olevat asiakkaat ja transaktiot, kesto, maantieteellinen laajuus, tietovaikutus, mainevaikutukset ja taloudellinen vaikutus.

Zenith Controls -oppaassa 5.25 on kytketty suoraan DORA Article 18, Major ICT Incident Classification -vaatimukseen. Se on jäsennetty arviointiprosessi sen määrittämiseksi, täyttääkö havaittu tapahtuma tietoturvapoikkeaman määritelmän. Se liittyy myös hallintakeinoon 8.16, seurantatoimet, koska hälytykset ja lokitiedot on luokiteltava ja priorisoitava, sekä hallintakeinoon 5.26, koska luokittelu käynnistää reagoinnin.

Tässä monet organisaatiot epäonnistuvat auditoinneissa. Niillä on tikettejä mutta ei luokittelutallenteita. Niillä on vakavuusmerkintöjä mutta ei kriteerejä. Niillä on viranomaisraportteja mutta ei päätöksentekojälkeä, joka osoittaa, miksi poikkeamaa pidettiin tai ei pidetty merkittävänä.

Clarysec ratkaisee tämän sisällyttämällä DORA-luokittelun poikkeamien vakavuusmalliin. Yritystason Tietoturvapoikkeamien hallintapolitiikan lausekkeessa 5.3.1 on selkeä Tier 1 -esimerkki:

Tier 1: Kriittinen (esim. vahvistettu henkilötietojen tietoturvaloukkaus, kiristyshaittaohjelmaepidemia, tuotantojärjestelmän vaarantuminen)

Pienemmille organisaatioille Tietoturvapoikkeamien hallintapolitiikka - SME lisää tiukan operatiivisen odotuksen:

Toimitusjohtajan on IT-palveluntarjoajan tuella luokiteltava kaikki poikkeamat vakavuuden mukaan yhden tunnin kuluessa ilmoituksesta.

Tämä yhden tunnin luokittelutavoite on tehokas, koska se pakottaa hallintakurin. Pienemmällä säännellyllä toimijalla ei välttämättä ole 24/7 SOC:ia, mutta se voi silti määrittää, kuka luokittelee, kuka neuvoo ja kuinka nopeasti päätös on tehtävä.

DORA:n ja ISO:n yhdistävä poikkeaman triage-tallenne

Jotta luokittelu on puolustettavissa, luo DORA-poikkeaman triage-tallenne tikettijärjestelmään, GRC-alustaan tai poikkeamien hallintajärjestelmään. Tallenne tulee luoda jokaisesta mahdollisesti olennaisesta ICT-tapahtumasta, vaikka se myöhemmin alennettaisiin alempaan luokkaan.

Lisää päätösmuistio:

”Koska maksupalvelun häiriö vaikuttaa kriittiseen liiketoimintaprosessiin, juurisyy on ratkaisematta ja asiakasvaikutus on mahdollinen, tapahtuma eskaloidaan mahdollisena merkittävänä ICT:hen liittyvänä poikkeamana. Vaatimustenmukaisuustoiminto ja lakiasiat arvioivat sääntelyyn liittyvät ilmoitusvaatimukset. Todistusaineiston säilyttäminen on käynnistetty.”

Tämä yksittäinen tallenne tukee DORA Article 17 -seurantaa, Article 18 -luokittelua, Article 19 -raportointipäätöksiä, ISO/IEC 27001:2022 -standardin liitteen A 5.25-arviointia, 6.8-raportointia, 5.26-reagointia ja 5.28-todistusaineiston käsittelyä.

Hallintakeinot 5.24 ja 5.26: suunnittelu, roolit ja reagointi

Kun DORA-poikkeama tapahtuu, reagointisuunnitelman on jo vastattava epämukaviin kysymyksiin.

Kenellä on toimivalta luokitella? Kuka ottaa yhteyttä toimivaltaiseen viranomaiseen? Kuka hyväksyy alkuperäisen ilmoituksen? Kuka viestii asiakkaiden kanssa? Kuka ottaa yhteyttä ICT:n kolmannen osapuolen palveluntarjoajaan? Kuka päättää, käynnistääkö poikkeama myös GDPR-ilmoituksen? Kuka säilyttää todistusaineiston? Kuka omistaa loppuraportin?

ISO/IEC 27001:2022 -standardin liitteen A hallintakeino 5.24, tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu, vastaa näihin kysymyksiin ennen kriisiä. Hallintakeino 5.26, tietoturvapoikkeamiin reagointi, varmistaa, että suunnitelma muuttuu hallituksi toiminnaksi poikkeaman aikana.

Zenith Controls -oppaassa 5.24 liittyy DORA Article 17–21 -vaatimuksiin, koska se operationalisoi dokumentoidun, testatun ja katselmoidun tietoturvapoikkeamiin reagoinnin, mukaan lukien sisäisen eskaloinnin, ulkoisen viranomaisilmoittamisen, sidosryhmäviestinnän ja opitut kokemukset.

ISO/IEC 27035-1:2023 tukee tätä laajentamalla poikkeamien hallinnan reagointimenettelyistä politiikkaan, suunnitteluun, kyvykkyyksiin, suhteisiin, tukimekanismeihin, tietoisuuteen, koulutukseen ja säännölliseen testaukseen. ISO/IEC 27035-2:2023 tarkentaa poikkeamien hallintaprosessia valmistelusta opittuihin kokemuksiin.

Zenith Blueprint -oppaan vaihe 23 antaa suoran toteutusohjeen:

Varmista, että käytössäsi on ajantasainen tietoturvapoikkeamiin reagointisuunnitelma (5.24), joka kattaa valmistelun, eskaloinnin, reagoinnin ja viestinnän.

DORA-valmiin tietoturvapoikkeamiin reagointisuunnitelman tulee määrittää:

• ICT-poikkeamiin reagointitiimi ja varahenkilöt.
• Toimivalta vakavuusluokitteluun ja DORA-raportoinnin eskalointiin.
• Lakiasioiden, vaatimustenmukaisuuden, tietosuojan, viestinnän, IT:n, tietoturvan, toimittajien ja liiketoimintavastaavien vastuut.
• Kriteerit merkittävän ICT:hen liittyvän poikkeaman luokittelulle.
• Menettelyt alkuperäiselle, väli- ja loppuraportoinnille viranomaisille.
• GDPR-, NIS2-, sopimus-, kybervakuutus- ja hallitusilmoitusten arviointi.
• Rajaamis-, poistamis-, palautus- ja varmennusvaiheet.
• Todistusaineiston säilyttämisvaatimukset.
• Toimittajaeskaloinnin ja lokipääsyn menettelyt.
• Opittujen kokemusten ja korjaavien toimenpiteiden seuranta.

Tietoturvapoikkeamien hallintapolitiikka - SME kytkee myös reagointiaikataulut lakisääteisiin vaatimuksiin:

Reagointiaikataulut, mukaan lukien tietojen palautus ja ilmoitusvelvoitteet, on dokumentoitava ja sovitettava yhteen lakisääteisten vaatimusten kanssa, kuten GDPR:n 72 tunnin henkilötietojen tietoturvaloukkauksen ilmoitusvaatimuksen kanssa.

Tämä on olennaista, koska yksittäisestä ICT-poikkeamasta voi tulla DORA:n mukainen merkittävä poikkeama, GDPR:n mukainen henkilötietojen tietoturvaloukkaus, NIS2:n mukainen merkittävä poikkeama, sopimusperusteinen asiakasilmoitustapahtuma ja toimittajahallinnan asia. Suunnitelman on koordinoitava nämä päällekkäisyydet eikä käsiteltävä niitä erillisinä maailmoina.

Hallintakeinot 8.15 ja 8.16: lokit tekevät raportista puolustettavan

DORA-poikkeamaraportointi perustuu tosiseikkoihin. Tosiseikat perustuvat lokitukseen ja seurantaan.

Maksujen selvityksen skenaariossa Sarahin on tiedettävä, milloin heikentyminen alkoi, mihin järjestelmiin se vaikutti, käytettiinkö etuoikeutettuja tilejä, poistuiko data ympäristöstä, vastaako pilvipalveluntarjoajan katkos sisäistä telemetriaa ja milloin palautuminen oli valmis.

ISO/IEC 27001:2022 -standardin liitteen A hallintakeinot 8.15, lokitus, ja 8.16, seurantatoimet, tukevat tätä näyttöpohjaa. Zenith Controls -oppaassa molemmat liittyvät hallintakeinoon 5.24, koska tietoturvapoikkeamiin reagoinnin suunnitteluun on sisällytettävä käyttökelpoiset lokitiedot ja seurantakyvykkyys. Hallintakeino 8.16 liittyy myös hallintakeinoon 5.25, koska hälytykset on vietävä triagen kautta päätöksiksi.

Clarysecin Lokitus- ja valvontapolitiikka - SME [LMP-SME] sisältää käytännöllisen eskalointivaatimuksen:

Korkean prioriteetin hälytykset on eskaloitava toimitusjohtajalle ja tietosuojakoordinaattorille 24 tunnin kuluessa

DORA-säännellyissä toimijoissa mahdollisesti merkittävät ICT-poikkeamat edellyttävät yleensä nopeampaa operatiivista eskalointimallia, erityisesti silloin, kun kriittiset tai tärkeät toiminnot ovat vaikutuksen kohteena. Hallintamalli on silti oikea: korkean prioriteetin hälytykset eivät saa jäädä IT:n sisälle. Niiden on tavoitettava liiketoiminta-, tietosuoja- ja johtoroolit.

DORA-valmiin lokitusmallin tulee sisältää:

• Keskitetty lokitus kriittisille järjestelmille, identiteettialustoille, päätelaitteille, pilvipalveluille, verkkoturvallisuustyökaluille ja liiketoimintasovelluksille.
• Aikasynkronointi järjestelmien välillä, jotta poikkeamien aikajanat ovat luotettavia.
• Hälytysten luokittelu, joka on yhdenmukainen poikkeamien vakavuuden ja DORA-luokittelun kanssa.
• Lokien säilytys, joka on sovitettu sääntely-, sopimus- ja forensisiin tarpeisiin.
• Pääsynhallinta, joka suojaa lokien eheyttä.
• Menettelyt lokien tilannevedosten ottamiseen merkittävien poikkeamien aikana.
• Toimittajien lokipääsyvaatimukset kriittisille ICT-palveluille.

Auditoijat eivät hyväksy toteamusta ”SIEMissä se on” riittäväksi näytöksi. He kysyvät, olivatko oikeat lokit olemassa, tarkasteltiinko hälytyksiä, tapahtuiko eskalointi ajallaan ja säilytettiinkö lokit, kun poikkeamasta tuli mahdollisesti raportoitava.

Hallintakeino 5.28: todistusaineiston kerääminen ja hallussapitoketju

Merkittävässä ICT:hen liittyvässä poikkeamassa todistusaineistolla on kolme tarkoitusta: tekninen tutkinta, sääntelyyn liittyvä vastuun osoitettavuus ja oikeudellinen puolustettavuus.

Jos todistusaineisto on puutteellista, ylikirjoitettua, muutettua tai dokumentoimatonta, organisaatiolla voi olla vaikeuksia osoittaa, mitä tapahtui. Sillä voi myös olla vaikeuksia perustella luokittelupäätöksensä.

Clarysecin Todisteiden keräämisen ja forensiikan politiikka [ECF] toteaa:

Hallussapitoketjulokin on seurattava kaikkea fyysistä tai digitaalista todistusaineistoa hankintahetkestä arkistointiin tai siirtoon saakka, ja sen on dokumentoitava:

SME-versio, Todisteiden keräämisen ja forensiikan politiikka - SME [ECF-SME], pitää vaatimuksen yksinkertaisena:

Jokainen digitaalisen todistusaineiston kohde on kirjattava lokiin seuraavin tiedoin:

Operatiivinen opetus on suora. Todistusaineiston käsittely ei voi alkaa vasta, kun lakiasiat sitä pyytää. Sen on oltava sisällytetty tietoturvapoikkeamiin reagointiin.

ISO/IEC 27006-1:2024 vahvistaa tätä auditointiodotusta korostamalla menettelyjä, joilla tunnistetaan, kerätään ja säilytetään tietoturvapoikkeamiin liittyvä todistusaineisto. DORA:n osalta sama näyttökokonaisuus voi tukea alkuperäistä ilmoitusta, välipäivityksiä, loppuraporttia, poikkeaman jälkiarviointia ja valvontaviranomaisen kysymyksiä.

Käytännöllisen todistusaineiston tarkistuslistan DORA:an liittyville poikkeamille tulee sisältää:

• Poikkeamatiketti ja triage-muistiinpanot.
• Aikajana havaitsemisesta, eskaloinnista, luokittelusta, raportoinnista, rajaamisesta, palautumisesta ja sulkemisesta.
• SIEM-hälytykset ja korreloidut lokit.
• Päätelaite- ja palvelinartefaktit.
• Identiteetti- ja etuoikeutetun pääsyn lokit.
• Verkkoliikenteen yhteenvedot.
• Pilvipalveluntarjoajan tila- ja auditointilokit.
• Toimittajaviestintä ja poikkeamalausunnot.
• Liiketoimintavaikutuksia koskevat tallenteet, mukaan lukien asiakkaat, palvelut, transaktiot ja käyttökatko.
• Viranomaisilmoitusten luonnokset ja toimitukset.
• Johdon päätökset ja hyväksynnät.
• Juurisyyanalyysi.
• Opitut kokemukset ja korjaavat toimenpiteet.

Näytön on osoitettava sekä tekniset tosiseikat että hallintapäätökset. DORA-raportointi ei koske vain sitä, mitä järjestelmille tapahtui. Se koskee myös sitä, miten johto tunnisti, arvioi, eskaloi, hallitsi ja paransi toimintaa poikkeaman perusteella.

Hallintakeino 5.27: opitut kokemukset ja jatkuva parantaminen

DORA-poikkeama ei ole suljettu, kun loppuraportti on toimitettu. Se on suljettu, kun organisaatio on oppinut siitä, osoittanut korjaavat toimenpiteet, päivittänyt hallintakeinot ja varmistanut parantumisen.

ISO/IEC 27001:2022 -standardin liitteen A hallintakeino 5.27, tietoturvapoikkeamista oppiminen, kytkee DORA-raportoinnin ISO/IEC 27001:2022 -standardin jatkuvan parantamisen sykliin. Zenith Controls -oppaassa 5.24 on kytketty hallintakeinoon 5.27, koska poikkeamien hallinta on puutteellista ilman juurisyyanalyysiä, opittuja kokemuksia ja hallintakeinojen parantamista.

Zenith Blueprint -oppaan vaihe 23 ohjeistaa organisaatioita päivittämään suunnitelman opittujen kokemusten perusteella ja tarjoamaan kohdennettua koulutusta tietoturvapoikkeamiin reagoinnista ja todistusaineiston käsittelystä. Tämä on erityisen tärkeää DORA:n kannalta, koska toistuvat luokitteluviiveet, puuttuva toimittajanäyttö, heikot lokit tai epäselvä viestintä voivat muodostua valvontaviranomaisen huolenaiheiksi.

Opittujen kokemusten mallipohjan tulee kirjata:

• Mitä tapahtui ja milloin.
• Mitkä kriittiset tai tärkeät toiminnot olivat vaikutuksen kohteena.
• Oliko luokittelu oikea-aikainen ja tarkka.
• Tehtiinkö DORA-raportointipäätökset riittävän näytön perusteella.
• Arvioitiinko GDPR-, NIS2-, sopimus- tai asiakasilmoitusten käynnistymiskriteerit.
• Reagoivatko toimittajat sovituissa aikarajoissa.
• Säilytettiinkö lokit ja forensinen todistusaineisto.
• Mitkä hallintakeinot epäonnistuivat tai puuttuivat.
• Mitä politiikkoja, pelikirjoja, koulutuksia tai teknisiä hallintakeinoja on parannettava.
• Kuka omistaa kunkin korjaavan toimenpiteen ja mihin mennessä.

Tämä syöttää myös ISO/IEC 27001:2022 -standardin mukaista johdon katselmointia. Johdon tulee katselmoida poikkeamatrendit, eikä niitä pidä haudata teknisiin jälkiarviointeihin.

Cross-compliance: DORA, GDPR, NIS2, NIST ja COBIT 2019

DORA on finanssialan toimijoiden näkyvin otsikko, mutta poikkeamaraportointi kuuluu harvoin vain yhteen viitekehykseen.

Yksittäiseen ICT-poikkeamaan voi liittyä DORA:n merkittävien ICT:hen liittyvien poikkeamien raportointi, GDPR:n henkilötietojen tietoturvaloukkauksen ilmoittaminen, NIS2:n merkittävän poikkeaman raportointi, asiakassopimusten velvoitteet, kybervakuutusilmoitus ja hallitusraportointi.

Zenith Controls auttaa vähentämään tätä monimutkaisuutta kytkemällä ISO/IEC 27002:2022 -hallintakeinot eri viitekehysten välillä. Esimerkiksi:

NIST-näkökulmasta sama malli tukee Detect-, Respond- ja Recover-tuloksia. COBIT 2019- ja ISACA-auditointinäkökulmasta kyse on hallinnasta: ovatko poikkeamien hallinta, jatkuvuus, riski, vaatimustenmukaisuus, toimittajavastuut ja suorituskyvyn seuranta hallinnassa.

Kypsimmät organisaatiot eivät luo erillisiä työnkulkuja jokaiselle viitekehykselle. Ne luovat yhden poikkeamien hallintaprosessin, jossa on sääntelykohtaiset lisäkerrokset. Tiketti kerää samat ydintiedot kerran ja haarautuu sen jälkeen tarvittaessa DORA-, GDPR-, NIS2-, sopimus-, vakuutus- tai toimialakohtaiseen raportointiin.

Miten auditoijat testaavat DORA-poikkeamaprosessisi

DORA-valmiin poikkeamaraportointiprosessin on kestettävä eri auditointinäkökulmat.

ISO/IEC 27001:2022 -auditoija tarkastaa, onko ISMS valinnut ja toteuttanut asiaankuuluvat liitteen A hallintakeinot, tukeeko soveltuvuuslausunto näitä hallintakeinoja, onko poikkeamatallenteita olemassa ja sisältävätkö sisäinen tarkastus ja johdon katselmointi poikkeamasuorituskyvyn.

Zenith Controls viittaa ISO/IEC 19011:2018 -auditointimenetelmään hallintakeinojen 5.24, 5.25 ja 6.8 osalta. Hallintakeinon 5.24 kohdalla auditoijat tarkastavat tietoturvapoikkeamiin reagointisuunnitelmasta poikkeamatyypit, vakavuusluokittelut, nimetyt roolit, yhteystietoluettelot, eskalointipolut, sääntelyraportointiohjeet ja viestintävastuut. Hallintakeinon 5.25 osalta he tarkastavat, onko dokumentoidut luokittelukriteerit olemassa, kuten vakavuusmatriisit tai päätöspuut, jotka perustuvat järjestelmävaikutukseen, tietojen arkaluonteisuuteen ja kestoon. Hallintakeinon 6.8 osalta he arvioivat ilmoitusmekanismeja, ilmoittamiseen kuluvan ajan mittareita ja näyttöä siitä, että ilmoitetut tapahtumat kirjataan lokiin, triagoidaan ja ratkaistaan.

DORA-valvontatarkastelu keskittyy siihen, havaitaanko, luokitellaanko, raportoidaanko, päivitetäänkö ja suljetaanko merkittävät ICT:hen liittyvät poikkeamat sääntelyodotusten mukaisesti. Tarkastaja voi pyytää esimerkkipoikkeamaa ja jäljittää sen ensimmäisestä hälytyksestä loppuraporttiin.

Tietosuojan auditoija keskittyy siihen, arvioitiinko henkilötietojen tietoturvaloukkauksen riski ja käynnistyivätkö GDPR Article 33 ja Article 34 -velvoitteet. BS EN 17926:2023 on tässä merkityksellinen, koska se lisää tietosuojapoikkeamien vastuut, ilmoituskriteerit, aikarajat ja yhdenmukaisuuden valvontaviranomaiselle tehtävän ilmoittamisen odotusten kanssa.

Sama näyttö voi vastata useisiin auditointikysymyksiin, jos se on alusta alkaen jäsennetty oikein.

DORA-poikkeamaraportoinnin valmiustarkistuslista vuodelle 2026

Ennen seuraavaa pöytäharjoitusta, sisäistä tarkastusta tai valvontatarkastelua testaa organisaatiosi tämän tarkistuslistan perusteella:

• Tietävätkö työntekijät, miten epäillyistä ICT-poikkeamista ilmoitetaan?
• Onko käytössä erillinen poikkeamien ilmoituskanava?
• Kirjataanko tietoturvatapahtumat lokiin ja triagoidaanko ne johdonmukaisesti?
• Onko dokumentoitu vakavuus- ja DORA:n merkittävän poikkeaman luokittelumatriisi?
• Vaaditaanko luokittelu määritellyssä ajassa ilmoituksen jälkeen?
• Onko kriittiset tai tärkeät toiminnot kytketty järjestelmiin ja toimittajiin?
• Arvioidaanko DORA-, GDPR-, NIS2-, sopimus-, vakuutus- ja asiakasilmoitusten käynnistimet yhdessä työnkulussa?
• Onko poikkeamaroolit määritetty IT:n, tietoturvan, lakiasioiden, vaatimustenmukaisuuden, tietosuojan, viestinnän ja liiketoimintavastaavien välillä?
• Riittävätkö lokit poikkeaman aikajanan rekonstruointiin?
• Säilytetäänkö todistusaineisto hallussapitoketjun mukaisesti?
• Onko toimittajien poikkeamavelvoitteet ja lokipääsyoikeudet testattu?
• Toteutetaanko pöytäharjoituksia realistisilla DORA-skenaarioilla?
• Seurataanko opittuja kokemuksia korjaaviin toimenpiteisiin asti?
• Katselmoidaanko poikkeamamittarit johdon katselmoinnissa?
• Onko soveltuvuuslausunto kytketty DORA:n kannalta relevantteihin ISO/IEC 27001:2022 -hallintakeinoihin?

Jos vastaus johonkin näistä on ”osittain”, kyse ei ole vain vaatimustenmukaisuudesta. Kyse on operatiivisesta häiriönsietokyvystä.

Rakenna auditointivalmis DORA-poikkeamaraportoinnin malli

DORA-poikkeamaraportointi vuonna 2026 on testi siitä, miten hallinta toimii paineen alla. Parhaiten suoriutuvat organisaatiot eivät ole niitä, joilla on pisimmät tietoturvapoikkeamiin reagointiasiakirjat. Ne ovat organisaatioita, joilla on selkeät ilmoituskanavat, nopea luokittelu, luotettavat lokit, säilytetty todistusaineisto, koulutetut ihmiset, testattu toimittajaeskalointi ja viitekehysten välinen jäljitettävyys.

Clarysec voi auttaa rakentamaan tämän toimintamallin.

Aloita kartoittamalla poikkeamariskisi ja soveltuvuuslausuntosi Zenith Blueprint: auditoijan 30-vaiheisen tiekartan avulla. Kohdista sen jälkeen poikkeamien hallintakeinot Zenith Controls: Cross-Compliance-oppaan avulla. Vie prosessi käytäntöön Clarysecin Tietoturvapoikkeamien hallintapolitiikalla, Tietoturvapoikkeamien hallintapolitiikalla - SME, Lokitus- ja valvontapolitiikalla - SME, Todisteiden keräämisen ja forensiikan politiikalla ja Todisteiden keräämisen ja forensiikan politiikalla - SME.

Jos johtoryhmäsi haluaa varmuutta ennen seuraavaa todellista poikkeamaa, toteuta DORA:n merkittävää ICT:hen liittyvää poikkeamaa koskeva pöytäharjoitus Clarysecin työkalupaketilla ja tuota näyttöpaketti, jonka auditoija tai valvoja odottaa näkevänsä.