Poikkeamien vakavuusluokittelu DORA-, NIS2- ja GDPR-vaatimuksia varten

Kello 02.17 alkava poikkeamapuhelu, josta tulee sääntelypäätös

Torstaiaamuna kello 02.17 FinScalen tietoturvajohtaja Sarah näkee ensimmäisen hälytyksen: poikkeavaa API-liikennettä, epäonnistuneiden todennusten piikkejä ja maksujen hallintanäkymän vasteaika yli 3000 ms. Muutamassa minuutissa asiakastuki ilmoittaa maksujen tilatietojen virheistä. Pilvipalveluntarjoaja kertoo, ettei alustalla ole laajaa poikkeamaa. SOC havaitsee epäilyttäviä pääsytunnisteita kahdelta maantieteelliseltä alueelta. Tuotetiimi vahvistaa, että hallintanäkymä on jälleen käytettävissä 19 minuutin jälkeen, mutta kaksitoista asiakasta on jo avannut tukipyynnön.

Kello 03.05 Sarah on kriisipuhelussa yhdessä poikkeamapäällikön, lakiasiantuntijan, tietosuojavastaavan, pilvioperaatioiden vastuuhenkilön ja liiketoiminnan omistajan kanssa. Tekninen kysymys on riittävän selvä: mitä API-yhdyskäytävälle tapahtui? Sääntelyyn liittyvät kysymykset ovat vaikeampia:

1. Onko tämä DORA-asetuksen mukainen merkittävä ICT:hen liittyvä poikkeama?
2. Onko tämä NIS2-direktiivin mukainen merkittävä poikkeama?
3. Onko kyseessä GDPR:n mukainen henkilötietojen tietoturvaloukkaus, josta on ilmoitettava?
4. Voiko organisaatio osoittaa, miten se päätyi näihin vastauksiin?

Väärä vastaus voi aiheuttaa sääntelyriskin. Hidas vastaus voi johtaa ilmoitusmääräajan ylittymiseen. Dokumentoimaton vastaus voi kaataa ISO/IEC 27001:2022 -auditoinnin kuukausia myöhemmin.

Tämä on vuoden 2026 tietoturvapoikkeamiin reagoinnin haaste. Monilla organisaatioilla on tietoturvapoikkeamiin reagointisuunnitelma, forensiset menettelyt, tietosuojan pelikirjat ja kriisiviestinnän mallipohjat. Harvemmilla on puolustettava poikkeamien vakavuusluokittelumalli, joka muuntaa hälyisen tietoturvatapahtuman dokumentoiduksi päätökseksi DORA-, NIS2-, GDPR- ja ISO/IEC 27001:2022 -näyttöodotusten näkökulmasta.

Ratkaisu ei ole kolme erillistä triage-prosessia. Ratkaisu on yksi hallittu vakavuusmalli, jossa on erilliset sääntelytasot, mitattavat kynnysarvot, eskalointisäännöt, päätöslokit ja näytön keräämistä koskevat vaatimukset. Käytännössä poikkeaman vakavuus ei saa olla paineen alla valittu tunniste. Sen tulee olla hallittu liiketoimintapäätös, joka kestää viranomaisten, auditoijien, hallituksen jäsenten, asiakkaiden ja tietosuojavastaavan tarkastelun.

Miksi poikkeamien vakavuusluokittelu on nyt hallitustason kontrolli

Poikkeamien luokittelu oli aiemmin pääosin teknistä: haittaohjelman vakavuus, vaikutuksen kohteena olevat palvelimet, hyväksikäytetyt haavoittuvuudet ja se, siirrettiinkö tietoja luvattomasti ulos. Vuonna 2026 se on myös oikeudellista, taloudellista, yhteiskunnallista ja sopimusperusteista.

DORA tekee digitaalisesta toiminnallisesta häiriönsietokyvystä finanssialan toimijoiden hallinnointivelvoitteen. Johtoelimen odotetaan määrittelevän, hyväksyvän ja valvovan ICT-riskien hallinnan viitekehystä sekä pysyvän siitä vastuussa. Tähän sisältyvät ICT-liiketoiminnan jatkuvuus, reagointi- ja palautussuunnitelmat, merkittävien poikkeamien raportointikanavat, ICT:n kolmansien osapuolten riskit ja opit.

NIS2 nostaa hallinnointivaatimuksia keskeisille ja tärkeille toimijoille. Article 20 edellyttää, että johtoelimet hyväksyvät kyberturvallisuusriskien hallintatoimenpiteet, valvovat niiden toteutusta ja osallistuvat koulutukseen. Se yhdistää riskienhallinnan ja poikkeamaraportoinnin puutteet myös vakaviin valvonnallisiin seuraamuksiin. Keskeisten toimijoiden hallinnollisten seuraamusmaksujen enimmäistasojen lähtökohtana voi olla vähintään 10 000 000 euroa tai 2 prosenttia maailmanlaajuisesta vuotuisesta kokonaisliikevaihdosta sen mukaan, kumpi on suurempi. Tärkeiden toimijoiden lähtötaso on vähintään 7 000 000 euroa tai 1,4 prosenttia liikevaihdosta sen mukaan, kumpi on suurempi.

GDPR lisää toisen näkökulman. Henkilötietojen tietoturvaloukkaus ei rajoitu vahvistettuun julkiseen paljastumiseen tai varastettuihin tiedostoihin. Se kattaa henkilötietojen vahingossa tapahtuvan tai lainvastaisen tuhoamisen, häviämisen, muuttamisen, luvattoman luovuttamisen tai luvattoman pääsyn tietoihin. Rekisterinpitäjien on arvioitava yksilöihin kohdistuva riski ja pystyttävä osoittamaan päätös ilmoittaa tai jättää ilmoittamatta.

ISO/IEC 27001:2022 antaa näille velvoitteille näyttörungon. Lausekkeet 4.1–4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmien vaatimukset, soveltamisalan, rajapinnat ja riippuvuudet. Lausekkeet 5.1–5.3 edellyttävät johdon sitoutumista, politiikkaa, rooleja, vastuita ja raportointia. Lausekkeet 6.1.1–6.1.3 edellyttävät riskiperusteista suunnittelua, riskien arviointia, riskien käsittelyä ja soveltuvuuslausuntoa. Lausekkeet 8.1–8.3 edellyttävät operatiivista ohjausta, muutosten hallintaa, säilytettävää näyttöä ja uudelleenarviointia, kun riskiolosuhteet muuttuvat. ISO/IEC 27001:2022

Kun poikkeamapuhelu alkaa, kysymyksen ei pitäisi olla: ”Kenen mielestä tämä on kriittinen?” Sen pitäisi olla: ”Mitä hyväksytyt kriteerimme, oikeudelliset käynnistimet, näyttö ja eskalointisäännöt edellyttävät meiltä nyt?”

Yksi tapahtuma, kolme sääntelyyn perustuvaa luokittelujärjestelmää

DORA, NIS2 ja GDPR eivät käytä samaa poikkeamakieltä. Tämä on keskeinen syy siihen, miksi organisaatiot kompuroivat ensimmäisen tunnin aikana.

DORA Article 17 edellyttää finanssialan toimijoilta ICT:hen liittyvien poikkeamien hallintaprosessia, joka havaitsee, hallitsee ja ilmoittaa ICT-poikkeamista, kirjaa ICT:hen liittyvät poikkeamat ja merkittävät kyberuhat, käsittelee juurisyyt, käyttää ennakkovaroitusindikaattoreita, kategorisoi ja luokittelee poikkeamat, osoittaa roolit, hallitsee viestintää, eskaloi merkittävät poikkeamat ylemmälle johdolle ja palauttaa turvallisen toiminnan.

DORA Article 18 edellyttää luokittelua kriteereillä, kuten vaikutuksen kohteena olevat asiakkaat, vastapuolet, tapahtumat, kesto, käyttökatko, maantieteellinen levinneisyys, saatavuuteen, aitouteen, eheyteen tai luottamuksellisuuteen vaikuttava tietojen menetys, vaikutuksen kohteena olevien palvelujen kriittisyys ja taloudellinen vaikutus. DORA Article 19 edellyttää merkittävien ICT:hen liittyvien poikkeamien raportointia sekä asiakasviestintää silloin, kun asiakkaiden taloudelliset edut ovat vaikutuksen kohteena.

NIS2 Article 23 määrittelee merkittävän poikkeaman poikkeamaksi, joka on aiheuttanut tai voi aiheuttaa vakavan toimintahäiriön tai taloudellisen menetyksen, tai joka on vaikuttanut tai voi vaikuttaa muihin aiheuttamalla huomattavaa aineellista tai aineetonta vahinkoa. Se edellyttää ennakkovaroitusta 24 tunnin kuluessa merkittävästä poikkeamasta tietoiseksi tulemisesta, poikkeamailmoitusta 72 tunnin kuluessa, väliraportteja pyynnöstä ja loppuraporttia kuukauden kuluessa poikkeamailmoituksesta. Soveltuvissa tapauksissa myös vaikutuksen kohteena oleville palvelun vastaanottajille on kerrottava toimenpiteistä tai korjauskeinoista, joihin he voivat ryhtyä.

GDPR kysyy tietosuojariskin näkökulmasta. Aiheuttiko tietoturvaloukkaus henkilötietojen tuhoamisen, häviämisen, muuttamisen, luvattoman luovuttamisen tai luvattoman pääsyn henkilötietoihin? Jos kyllä, rekisterinpitäjän on arvioitava luonnollisten henkilöiden oikeuksiin ja vapauksiin kohdistuva riski. Jos loukkaus todennäköisesti aiheuttaa riskin, valvontaviranomaiselle on yleensä ilmoitettava 72 tunnin kuluessa siitä, kun loukkaus on tullut tietoon. Jos loukkaus todennäköisesti aiheuttaa korkean riskin, vaikutuksen kohteena oleville henkilöille voi olla tarpeen ilmoittaa ilman aiheetonta viivytystä.

Yksi poikkeama tarvitsee siksi samanaikaisen luokittelun.

Finanssialan toimijoille DORA on ICT-riskien hallintaa ja poikkeamien raportointivelvoitteita koskeva alakohtainen unionin säädös, jonka velvoitteet limittyvät NIS2:n kanssa. Tämä ei tee NIS2:sta merkityksetöntä. Sillä voi edelleen olla merkitystä yhteistyölle, tietovirroille, DORA-kehän ulkopuolisille palveluille, konsernin muille kuin finanssialan yhtiöille, pilvipalveluille, hallinnoiduille palveluille ja asiakkaiden sopimusvelvoitteille. Vakavuusmallin tulee kirjata lopputuloksen lisäksi myös soveltuvuuslogiikka.

Clarysecin malli: luokittele tapahtuma, älä tunnetta

Clarysec ottaa lähtökohdaksi ISO/IEC 27002:2022 -hallintakeinon 5.25, tietoturvatapahtumien arvioinnin ja päätöksenteon, moniviitekehysvaatimustenmukaisuuden ankkurina. Teoksessa Zenith Controls: The Cross-Compliance Guide Zenith Controls tämä aihe on kartoitettu hallintakeinon 5.25 kohdassa ”Tietoturvatapahtumien arviointi ja niitä koskeva päätöksenteko”, ja sitä tukevat hallintakeinon 5.24 ”Tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu” sekä hallintakeinon 5.28 ”Näytön kerääminen”.

Tärkein vaatimustenmukaisuuden hetki ei usein ole rajaaminen. Se on tienhaara, jossa tietoturvatapahtumasta tulee sääntelypoikkeama tai jossa se kirjataan puolustettavalla tavalla alemman vakavuuden tapahtumaksi.

Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint kuvaa tätä hetkeä Kontrollit käytännössä -vaiheen vaiheessa 23:

”Kaikki poikkeamat eivät ole katastrofeja. Kaikki hälytykset eivät tarkoita vaarantumista. Todellisessa maailmassa tietoturvatiimit ja liiketoimintayksiköt hukkuvat kohinaan: kirjautumisyrityksiin, lokipoikkeamiin, vähäisiin politiikkarikkomuksiin ja varjo-IT-toimintaan. Todellinen haaste ei ole vain havaitsemisessa, vaan siinä, että harmiton erotetaan haitallisesta ja tiedetään, mikä edellyttää eskalointia.”

Tämä lause tiivistää operatiivisen ongelman. SIEM-hälytys ei automaattisesti tarkoita DORA-asetuksen mukaista merkittävää poikkeamaa. Tilapäinen käyttökatko ei automaattisesti ole NIS2-direktiivin mukaisesti merkittävä. Epäilyttävä tietokantakysely ei automaattisesti ole GDPR:n mukaan ilmoitettava. Jokainen niistä voi kuitenkin muuttua ilmoitettavaksi vaikutuksen, laajuuden, tietojen, vaikutuksen kohteena olevien osapuolten ja näytön perusteella.

Zenith Blueprint suosittelee Riskienhallinta-vaiheen vaiheessa 10 myös, että vaikutusmääritelmät sovitetaan liiketoiminnan mittakaavaan ja sääntelyaltistukseen:

”Vaikutusta määriteltäessä tasot kannattaa suhteuttaa omaan liiketoimintamittakaavaan. Esimerkiksi ’merkittävä taloudellinen vaikutus = tappio > 100 000 $’ (sovita omaan kontekstiisi). Huomioi myös sääntelyvaikutus: esimerkiksi henkilötietojen tietoturvaloukkaus voi automaattisesti olla ’merkittävä’ tai ’vakava’ GDPR-sakkojen ja ilmoitusvaatimusten vuoksi, vaikka suora taloudellinen menetys olisi epäselvä.”

Tämä on vuoden 2026 poikkeamien vakavuusluokittelun suunnitteluperiaate: vakavuus on liiketoimintavaikutus plus oikeudellinen vaikutus plus näytön luotettavuus.

Käytännön vakavuustaksonomia DORA-, NIS2- ja GDPR-vaatimuksia varten

Puolustettavan taksonomian tulee erottaa sisäinen vakavuus sääntelyluokittelusta. Sisäinen vakavuus ohjaa reagoinnin kiireellisyyttä, resurssien kohdentamista ja johdon eskalointia. Sääntelyluokittelu ohjaa ilmoittamista, oikeudellista tarkastelua ja ulkoista viestintää.

Sisäinen vakavuustaso ei ole lopullinen sääntelyvastaus. Se on toimintatila. SEV 3 -tapahtumasta voi tulla GDPR:n mukaan ilmoitettava lokien tarkastelun jälkeen. SEV 2 -käyttökatko ei välttämättä ole DORA-asetuksen mukainen merkittävä poikkeama, jos vaikutuskynnykset eivät täyty. SEV 1 -kiristyshaittaohjelmapoikkeama voi käynnistää samanaikaisesti DORA-, NIS2- ja GDPR-velvoitteet, asiakassopimukset ja lainvalvontaviranomaisten koordinoinnin.

Yksityiskohtaisempi luokittelumatriisi auttaa tiimiä etenemään hälytyksestä toimenpiteisiin.

Malli tulee sisällyttää politiikkaan eikä jättää kriisipuhelun äänekkäimmän henkilön päätettäväksi. SME-ympäristöille tarkoitettu Tietoturvapoikkeamien hallintapolitiikka-sme Tietoturvapoikkeamien hallintapolitiikka-sme - SME, Hallinnointivaatimukset, lauseke 5.3.1, toteaa:

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

Sama SME-politiikka, Riskien käsittely ja poikkeukset, lauseke 7.4.1, lisää:

”Jos mukana on asiakastietoja, toimitusjohtajan on arvioitava oikeudelliset ilmoitusvelvoitteet GDPR:n, NIS2:n tai DORA:n soveltuvuuden perusteella.”

Suuremmille organisaatioille tarkoitettu yritystason Tietoturvapoikkeamien hallintapolitiikka Tietoturvapoikkeamien hallintapolitiikka, Hallinnointivaatimukset, lauseke 5.3, muodostaa saman periaatteen:

”Poikkeamien luokittelussa on noudatettava tasomallia:”

Politiikkakielellä on merkitystä, koska viranomaiset ja auditoijat kysyvät, olivatko luokittelukriteerit olemassa ennen poikkeamaa. Jälkikäteen keksitty matriisi on heikkoa näyttöä. Hyväksytty, koulutettu, harjoiteltu ja johdonmukaisesti käytetty matriisi on puolustettava.

Päätösloki: tärkein näyttöartefakti

Kun auditoijat, viranomaiset tai hallituksen jäsenet katselmoivat poikkeamaa, he harvoin kysyvät vain: ”Mitä tapahtui?” He kysyvät: ”Milloin tiesitte, kuka päätti, minkä näytön perusteella ja miksi ette ilmoittaneet aiemmin?”

Siksi Clarysec suosittelee vakavuuspäätöslokia jokaiselle SEV 3 -tason ja sitä vakavammalle tapahtumalle sekä kaikille tapahtumille, joihin liittyy henkilötietoja, kriittisiä palveluja, finanssialan asiakkaita, hallinnoituja palveluja, pilvi-infrastruktuuria tai rajat ylittävä vaikutus.

Tämä kytkeytyy suoraan ISO/IEC 27001:2022 -standardiin. Lauseke 8.1 edellyttää prosessien suunnittelua, toteuttamista ja ohjaamista sekä riittävän dokumentoidun tiedon säilyttämistä sen osoittamiseksi, että prosessit toimivat suunnitellusti. Lausekkeet 8.2 ja 8.3 edellyttävät uudelleenarviointia, kun merkittäviä muutoksia tapahtuu, sekä riskien käsittelyyn liittyvän näytön säilyttämistä. Liite A:n hallintakeinot A.5.24–A.5.28 muodostavat poikkeamien hallinnan rungon: suunnittelu ja valmistelu, tapahtumien arviointi ja päätöksenteko, reagointi, poikkeamista oppiminen ja näytön kerääminen.

SME-ympäristöille tarkoitettu Tietosuoja- ja yksityisyydensuojapolitiikka-sme Tietosuoja- ja yksityisyydensuojapolitiikka-sme - SME, Soveltaminen ja vaatimustenmukaisuus, lauseke 8.3.2, tukee mallin GDPR-puolta:

”Tietosuojakoordinaattori määrittää vakavuuden, käynnistää rajaamistoimet ja dokumentoi tapauksen”

Tietosuoja-arvioinnin ei tule alkaa vasta silloin, kun sääntelykello alkaa tuntua epämukavalta. Sen paikka on triage-työnkulussa.

Käytännön esimerkki: Sarahin API-poikkeaman luokittelu

Palataan FinScaleen. Se on B2B-fintech-alusta, joka käyttää pilvi-infrastruktuuria, ulkoista petosanalytiikan tarjoajaa ja hallinnoitua tietoturvapalveluntarjoajaa. Joidenkin toimintojen osalta se on DORA:n soveltamisalaan kuuluva finanssialan toimija. Se on myös digitaalisten palvelujen tarjoaja, jolla on NIS2:n kannalta merkityksellisiä toimintoja yhdessä jäsenvaltiossa. Se käsittelee asiakkaiden henkilötietoja rekisterinpitäjänä tilipalveluissa ja käsittelijänä joidenkin yritysasiakkaiden osalta.

Kello 02.17 havaitaan poikkeavaa API-liikennettä. Kello 02.35 poikkeamakirjaus avataan. Kello 03.00 Sarah saa valmiiksi alustavan triagen poikkeamapäällikön kanssa.

Ensiksi määritetään sisäinen vakavuus. Poikkeama vaikutti asiakashallintanäkymän saatavuuteen 19 minuutin ajan, siihen liittyi epäilyttäviä pääsytunnisteita ja se koski kriittistä asiakasrajapinnan toimintoa. Se luokitellaan vahvistusta odotettaessa tasolle SEV 3 Kohtalainen, ja se eskaloidaan poikkeamapäällikölle, tietosuojavastaavalle, lakiasiantuntijalle ja palveluomistajalle.

Toiseksi tehdään DORA-arviointi. Tiimi tarkistaa vaikutuksen kohteena olevat asiakkaat, vastapuolet, tapahtumat, keston, käyttökatkon, maantieteellisen levinneisyyden, tietojen menetyksen, kriittisyyden ja taloudellisen vaikutuksen. Epäonnistuneita tai muuttuneita tapahtumia ei vahvisteta. Käyttökatko on rajallinen. Tietojen menetystä ei ole osoitettu. Koska kyseessä voi kuitenkin olla kriittinen finanssipalvelun komponentti ja asiakkaiden taloudelliset edut voivat olla vaikutuksen kohteena, poikkeama jää DORA-seurantaan ja se voidaan luokitella uudelleen.

Kolmanneksi kirjataan NIS2-arviointi. Tiimi toteaa, että DORA on ensisijainen alakohtainen raportointikehys soveltamisalaan kuuluvan finanssialan toimijan velvoitteille. Se tarkistaa myös, vaikuttaako poikkeama palveluihin tai asiakkaisiin DORA-kehän ulkopuolella. Tässä vaiheessa ei vahvisteta vakavaa toimintahäiriötä eikä huomattavaa vahinkoa.

Neljänneksi käynnistetään GDPR-arviointi. Epäilyttävät tunnisteet ovat voineet mahdollistaa pääsyn asiakashallintanäkymän tietoihin. Tietosuojavastaava dokumentoi tietoluokat, vaikutuksen kohteena olevat käyttäjät, tunnisteiden laajuuden, katselmoidut lokit, sen, onko tietoja katsottu tai viety, sekä suojatoimet, kuten tunnisteiden vanhenemisen ja pääsynhallinnan.

Kello 04.20 lokianalyysi osoittaa, että kahta tunnistetta käytettiin 41 asiakkaan hallintanäkymän metatietoihin pääsemiseen. Tietoihin sisältyi nimiä, tili-ID:t ja tapahtumien tila, mutta ei maksutunnistetietoja eikä henkilöllisyysasiakirjoja. Tiimi päivittää poikkeaman tasolle SEV 2 Merkittävä, koska henkilötietojen luottamuksellisuus on vaarantunut ja asiakasviestintä voi olla tarpeen. Tietosuojavastaava arvioi GDPR-riskin yksilöille. DORA-päätös arvioidaan uudelleen asiakasvaikutuksen, tapahtumavaikutuksen ja taloudellisen vaikutuksen perusteella.

Tämä on mallin käytännön arvo. Alkuperäinen luokittelu ei ole lopullinen oikeudellinen johtopäätös. Se on näyttöön perustuva päätös, jota voidaan päivittää tosiseikkojen kehittyessä.

Lokitus, valvonta ja forensinen näyttö: todentamisen kerros

Vakavuusmalli ilman näyttöä on kokousmielipide. Vuoden 2026 odotus on, että luokittelua tukevat lokit, valvonta, säilytetyt artefaktit ja hallussapitoketju.

SME-ympäristöille tarkoitettu Lokitus- ja valvontapolitiikka-sme Lokitus- ja valvontapolitiikka-sme - SME, Soveltaminen ja vaatimustenmukaisuus, lauseke 8.3.4, toteaa:

”Loukkaustutkintojen tueksi on oltava riittävät lokit GDPR:n ja DORA:n mukaisen osoitusvelvollisuuden täyttämiseksi”

Forensinen käsittely on yhtä tärkeää. SME-ympäristöille tarkoitettu Todisteiden keräämisen ja forensiikan politiikka-sme Todisteiden keräämisen ja forensiikan politiikka-sme - SME, Hallinnointivaatimukset, lauseke 5.3.1, edellyttää:

”Jokaisesta poikkeamasta on ylläpidettävä yksinkertaista hallussapitoketjulokia (esim. Excel-tiedosto tai asiakirjamalli).”

Yritysympäristöissä Todisteiden keräämisen ja forensiikan politiikka Todisteiden keräämisen ja forensiikan politiikka, Hallinnointivaatimukset, lauseke 5.5, edellyttää:

”Kaikki kerätty näyttö on yksilöitävä, merkittävä ja säilytettävä turvallisessa tietovarastossa siten, että:”

Zenith Blueprint, Kontrollit käytännössä -vaihe, vaihe 23, selittää, miksi tällä on merkitystä ISO/IEC 27002:2022 -hallintakeinon 5.28 kannalta:

”Kun tietoturvapoikkeama tapahtuu, yksi reagoinnin kriittisimmistä mutta usein sivuutetuista osa-alueista on näyttö. Ei lokit, ei kuvakaappaukset, ei irralliset kertomukset, vaan asianmukaisesti säilytetty, hallussapitoketjua kunnioittava ja peukaloinnin kestävä näyttö.”

Merkittävän tai mahdollisesti ilmoitettavan poikkeaman käytännön näyttöpaketin tulisi sisältää:

• Poikkeamakirjaus ja aikajana
• Vakavuuspäätösloki ja uudelleenluokittelun historia
• SIEM-hälytykset, EDR-hälytykset, pilvilokit ja identiteettilokit
• Tietojen käyttölokit ja vientilokit
• Vaikutuksen kohteena olevien omaisuuserien ja palvelujen inventaariomerkinnät
• Asiakas-, tapahtuma- ja maantieteellisen vaikutuksen arviointi
• DORA-, NIS2- ja GDPR-arvioinnin työpohja
• Tietosuojavastaavan tai lakiasioiden arviointi
• Viestinnän hyväksynnät ja lähetetyt viestit
• Hallussapitoketjun tallenne
• Juurisyyanalyysi
• Korjaavat toimenpiteet ja opit

Tämä näyttöpaketti tukee myös ISO/IEC 27001:2022 -standardin liite A:n hallintakeinoja A.8.15 lokitus, A.8.16 valvontatoiminnot, A.5.28 näytön kerääminen, A.5.27 tietoturvapoikkeamista oppiminen, A.5.31 lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset vaatimukset sekä A.5.34 yksityisyyden suoja ja henkilötietojen suojaaminen.

Moniviitekehysvaatimustenmukaisuuden kartoitus: rakenna kerran, vastaa monelle auditoijalle

Vahvimmat poikkeamien vakavuusmallit rakennetaan kerran ja kartoitetaan moneen käyttötarkoitukseen. Zenith Controls on suunniteltu tämän työn moniviitekehysvaatimustenmukaisuuden kompassiksi. Tämän aiheen keskeiset ISO/IEC 27002:2022 -kohdat ovat 5.24 tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu, 5.25 tietoturvatapahtumien arviointi ja päätöksenteko, 5.26 tietoturvapoikkeamiin reagointi, 5.27 tietoturvapoikkeamista oppiminen ja 5.28 näytön kerääminen.

Nämä hallintakeinot kytkeytyvät luontevasti ISO/IEC 27001:2022 -hallintajärjestelmään. Lausekkeet 4, 5, 6 ja 8 määrittelevät soveltamisalan, johtajuuden, riskikriteerit, riskien käsittelyn ja operatiivisen näytön. ISO/IEC 27002:2022 tarjoaa kontrollien toteutuskielen. ISO 22301 -tyyppinen liiketoiminnan jatkuvuusajattelu tukee häiriökynnyksiä, palautusprioriteetteja ja kriisinhallintaa. ISO/IEC 27035 -tyyppiset poikkeamien hallintakäytännöt tukevat jäsenneltyä havaitsemista, raportointia, arviointia, reagointia ja oppimista. ISO/IEC 27701 -tyyppinen tietosuojan hallinnointi tukee henkilötietojen tietoturvaloukkauksiin liittyviä rooleja, rekisterinpitäjä- ja käsittelijänäkökulmia, tietosuojanäyttöä ja osoitusvelvollisuutta.

Sama malli voidaan kartoittaa NIST Cybersecurity Framework 2.0 -viitekehykseen. GOVERN-toiminto edellyttää, että lakisääteiset, sääntelyyn liittyvät, sopimusperusteiset, tietosuoja- ja perusoikeusvelvoitteet ymmärretään ja hallitaan. Se edellyttää myös riskinottohalukkuuden, roolien, toimivaltuuksien, politiikkojen ja valvonnan määrittelyä. DETECT-, RESPOND- ja RECOVER-toiminnot tukevat triagea, analyysiä, eskalointia, rajaamista, palauttamista, viestintää ja parantamista.

Hyöty on käytännöllinen. Kun DORA-valvoja pyytää perusteluja merkittävälle ICT:hen liittyvälle poikkeamalle, NIS2-viranomainen kysyy 24 tunnin ennakkovaroituspäätöksestä, tietosuojaviranomainen kysyy, miksi GDPR-ilmoitus tehtiin tai jätettiin tekemättä, ja ISO-auditoija kysyy, toimiko ISMS suunnitellusti, organisaatio voi vastata samasta näyttöaineistosta.

Miten auditoijat ja viranomaiset testaavat mallia

ISO/IEC 27001:2022 -auditoija aloittaa yleensä soveltamisalasta ja lakisääteisistä vaatimuksista. Hän kysyy, onko DORA, NIS2, GDPR, asiakassopimukset ja ICT:n kolmansia osapuolia koskevat velvoitteet tunnistettu sidosryhmien vaatimuksiksi. Sen jälkeen hän seuraa jälkeä riskikriteereihin, soveltuvuuslausuntoon, poikkeamamenettelyihin, operatiivisiin tallenteisiin ja näytön säilyttämiseen. Hän haluaa näytön siitä, ettei luokitteluprosessia keksitty poikkeaman aikana.

DORA-valvoja tai sisäinen tarkastus etsii elinkaarisilmukkaa: poikkeamien hallintaprosessi, ennakkovaroitusindikaattorit, luokittelukriteerit, merkittävien poikkeamien eskalointi, asiakasviestintä, juurisyy, lopulliset vaikutusluvut, häiriönsietokyvyn testaus ja johtoelimen valvonta. Hän kysyy myös, huomioitiinko ICT:n kolmansien osapuolten riippuvuudet erityisesti silloin, kun poikkeamaan liittyivät pilvi, SaaS, hallinnoitu tietoturva tai ulkoistetut palveluntarjoajat.

NIS2-keskeinen auditoija tai viranomainen testaa, pystyykö toimija tunnistamaan merkittävät poikkeamat, täyttämään vaiheistetut määräajat, viestimään vaikutuksen kohteena oleville palvelun vastaanottajille ja esittämään näytön rajat ylittävän vaikutuksen arvioinnista. Hän yhdistää poikkeamien käsittelyn Article 21 -riskienhallintatoimenpiteisiin, mukaan lukien liiketoiminnan jatkuvuus, kriisinhallinta, toimitusketjun tietoturva, pääsynhallinta, omaisuudenhallinta ja koulutus.

GDPR:n tietosuojavastaava tai valvontaviranomainen tarkastelee, tunnistiko organisaatio henkilötiedot, roolit, rekisteröidyt, luokat, vaikutuksen kohteena olevat järjestelmät, loukkaustyypin ja yksilöihin kohdistuvan riskin. Hän testaa, voiko rekisterinpitäjä osoittaa osoitusvelvollisuuden toteutumisen ja olivatko käsittelijöiden ilmoitukset rekisterinpitäjille oikea-aikaisia ja kattavia.

ISACA- tai COBIT 2019 -tyyppinen auditoija keskittyy hallinnointinäyttöön. Kuka hyväksyi vakavuustaksonomian? Kuka omistaa riskin? Mitä mittareita raportoidaan johdolle? Miten poikkeukset käsitellään? Miten opit muunnetaan kontrollien parannuksiksi?

Yleiset epäonnistumismallit poikkeamien luokittelussa

Ensimmäinen epäonnistuminen on yhden etiketin ajattelu. Tiimit luokittelevat tapahtuman korkeaksi, keskitasoiseksi tai matalaksi, mutta eivät arvioi DORA-, NIS2- ja GDPR-käynnistimiä erikseen. Tuloksena on vakavuusmerkintä, joka ei selitä raportointipäätöstä.

Toinen epäonnistuminen on vahvistettuun loukkaukseen liittyvä vinouma. Tiimit odottavat ehdotonta näyttöä tietojen luvattomasta siirrosta ennen tietosuojan tai lakiasioiden osallistamista. GDPR-loukkausarviointi alkaa usein mahdollisesta luvattomasta pääsystä, häviämisestä, muuttamisesta tai luovuttamisesta, ei vain tietojen vahvistetusta julkaisemisesta.

Kolmas epäonnistuminen on aikarajojen epäselvyys. NIS2- ja GDPR-määräajat riippuvat tietoisuudesta ja arvioinnista. Jos poikkeamakirjaus ei tallenna tietoisuusaikaa, luokitteluaikaa ja eskalointiaikaa, organisaation voi olla vaikea osoittaa oikea-aikaisuutta.

Neljäs epäonnistuminen on forensiikka siivouksen jälkeen. Insinöörit kierrättävät avaimia, rakentavat palvelimia uudelleen ja poistavat väliaikaista näyttöä ennen tutkintatilan käynnistämistä. Tämä voi tuhota näytön, jota tarvitaan sääntely-, sopimus- tai oikeudellista tarkastelua varten.

Viides epäonnistuminen on toimittajasokeus. DORA, NIS2 ja NIST CSF 2.0 korostavat kaikki kolmansien osapuolten ja toimitusketjun riskiä. Jos pilvipalveluntarjoaja, hallinnoitu palveluntarjoaja, maksunkäsittelijä, identiteetintarjoaja tai SaaS-toimittaja on osa poikkeamaketjua, luokittelumallin on sisällettävä toimittajavaikutus ja sopimusperusteiset ilmoitusvelvoitteet.

Clarysecin toteutuksen tarkistuslista vuodelle 2026

Puolustettavan poikkeamien vakavuusluokittelumallin käyttöönottoon Clarysec suosittelee seuraavaa etenemisjärjestystä:

1. Vahvista DORA:n, NIS2:n, GDPR:n, asiakassopimusten ja alakohtaisten sääntöjen soveltuvuus.
2. Päivitä ISMS:n soveltamisala ja sidosryhmien vaatimukset ISO/IEC 27001:2022 -standardin mukaisesti.
3. Määritä sisäiset vakavuustasot mitattavilla kynnysarvoilla käyttökatkolle, tiedoille, asiakkaille, maantieteelle, taloudelliselle menetykselle ja kriittisyydelle.
4. Lisää erilliset DORA-, NIS2- ja GDPR-arviointikysymykset poikkeamakirjauksen työnkulkuun.
5. Määritä eskalointikäynnistimet poikkeamapäällikölle, tietosuojavastaavalle, lakiasioille, ylemmälle johdolle ja hallitukselle.
6. Luo vakavuuspäätöslokin mallipohja.
7. Yhdistä luokittelu näytön keräämiseen ja hallussapitoketjun menettelyihin.
8. Validoi lokituskattavuus identiteetti-, pilvi-, sovellus-, tietokanta-, verkko- ja toimittajatapahtumille.
9. Toteuta pöytäharjoitukset DORA:n merkittävän poikkeaman, NIS2:n merkittävän poikkeaman ja GDPR-loukkauksen skenaarioille.
10. Syötä opit riskien käsittelyyn, soveltuvuuslausuntoon, koulutukseen ja häiriönsietokyvyn testaukseen.

Zenith Blueprint, Kontrollit käytännössä -vaihe, vaihe 16, vahvistaa tämän mallin inhimillistä puolta: ilmoitukset tulee kirjata lokiin, luokitella triagessa, eskaloida tietoturvapoikkeamiin reagointisuunnitelman kautta, ja myös vähäisiä tapahtumia tulee seurata, koska trendit paljastavat kontrolliheikkouksia. Se edistää matalan kynnyksen ilmoittamiskulttuuria: ”Jos olet epävarma, ilmoita.”

Tämä kulttuurinen näkökulma on kriittinen. Vakavuusmalli epäonnistuu, jos työntekijät viivyttelevät ilmoittamista ylireagoinnin pelossa. Tavoitteena on nopea ilmoittaminen, kurinalainen triage ja puolustettava luokittelu.

Muunna poikkeaman epävarmuus auditointivalmiiksi näytöksi

Vuonna 2026 poikkeamien vakavuusluokittelu ei ole enää pelkkä SOC-päätös. Se on säännelty hallinnointiprosessi, jonka on yhdistettävä DORA-asetuksen merkittävän ICT:hen liittyvän poikkeaman kriteerit, NIS2-direktiivin merkittävän poikkeaman kynnysarvot, GDPR-loukkausriski ja ISO/IEC 27001:2022 -näyttö.

Poikkeamatilanteissa parhaiten suoriutuvat organisaatiot eivät ole niitä, joilla on paksuin reagointikansio. Parhaiten suoriutuvat ne, jotka pystyvät vastaamaan nopeasti neljään kysymykseen ja todistamaan jokaisen vastauksen myöhemmin:

• Mitä tapahtui?
• Kuinka vakava se on?
• Mitä sääntelyvelvoitteita voi soveltua?
• Mikä näyttö tukee päätöstä?

Clarysec auttaa organisaatioita rakentamaan tämän sillan politiikkamallien, vakavuustaksonomioiden, päätöslokien, pöytäharjoitusskenaarioiden ja moniviitekehysvaatimustenmukaisuuden kartoitusten avulla. Aloita poikkeamapolitiikoista, validoi riskikriteerisi Zenith Blueprint -julkaisussa Zenith Blueprint ja käytä Zenith Controls -julkaisua Zenith Controls kartoittaaksesi ISO/IEC 27002:2022 -hallintakeinot 5.24, 5.25, 5.26, 5.27 ja 5.28 DORA-, NIS2-, GDPR-, NIST CSF - ja auditointiodotuksiin.

Jos tiimisi ei pysty vastaamaan ensimmäisen tunnin aikana kysymykseen ”Onko tämä DORA:n mukaan merkittävä, NIS2:n mukaan merkittävä tai GDPR:n mukaan ilmoitettava?”, seuraava askel ei ole uusi geneerinen tietoturvapoikkeamiin reagointisuunnitelma. Seuraava askel on puolustettava poikkeamien vakavuusluokittelun toimintamalli, joka on testattu ennen seuraavaa kello 02.17 alkavaa puhelua.

Oletko valmis korvaamaan paniikin prosessilla? Lataa Clarysecin tietoturvapoikkeamiin reagoinnin ja näytön keräämisen politiikkamallit, arvioi nykyinen vakavuustaksonomiasi Zenith Blueprintiä vasten tai pyydä Clarysecin auditointivalmiusarviointi valmiin DORA-, NIS2-, GDPR- ja ISO/IEC 27001 -poikkeamien luokittelumallin rakentamiseksi.