EU:n kybersolidaarisuussäädökseen valmistautuminen ISO 27001:n avulla

Kello 03.17 tapahtuva poikkeama, joka tekee EU-yhteistyöstä auditointihaasteen

Tiistaiaamuna kello 03.17 InnovateCloudin tietoturvajohtaja Maria katsoo näyttöä, joka on täynnä hälytyksiä. Hänen yrityksensä on keskisuuri eurooppalainen SaaS-palveluntarjoaja, joka palvelee logistiikka-asiakkaita Saksassa, Ranskassa ja Puolassa. Ensimmäinen hälytys viittaa epäilyttävään etuoikeutettuun käyttöön tuotannon asiakasympäristössä. Kymmenen minuuttia myöhemmin hallinnoitu tietoturvapalveluntarjoaja raportoi vastaavaa toimintaa kahdella muulla asiakkaalla. Kello 04.00 mennessä SOC havaitsee ohjelmointirajapintakutsuja infrastruktuurista, joka on aiemmin yhdistetty kiristyshaittaohjelmien valmisteluun.

InnovateCloud ei ollut alkuperäinen kohde. Keskeinen infrastruktuuripalveluntarjoaja näyttää olevan vaikutuksen piirissä. Vaikutus on kuitenkin nyt Marian ongelma.

Yksi vaikutuksen kohteena oleva asiakas on saksalainen pankki, joka vaatii vastauksia DORA:n perusteella. Toinen on energiasektorin kriittinen toimittaja, joka on jo luokiteltu kansallisten NIS2-sääntöjen mukaisesti. Ympäristö voi sisältää henkilötietoja, mutta tietojen luvaton siirto ei ole vielä varmistunut. Tietoturvatiimi haluaa rajata uhan välittömästi. Lakitoiminto haluaa tietää, onko NIS2:n 24 tunnin ennakkovaroituksen määräaika alkanut. Tietosuojavastaava kysyy, voiko kyseessä olla GDPR:n mukainen henkilötietojen tietoturvaloukkausilmoitusta edellyttävä tapahtuma. Hallitus haluaa tietää, voiko palvelukatko levitä jäsenvaltioiden yli.

Vuonna 2026 tämä ei ole enää vain sisäinen kriisi.

EU:n kybersolidaarisuussäädös muuttaa laajamittaisten ja rajat ylittävien kyberpoikkeamien toimintaympäristöä. Se tuo käyttöön EU-tason havaitsemis-, valmius- ja reagointimekanismeja, kuten Euroopan kyberturvallisuushälytysjärjestelmän, kyberturvallisuuden hätätilamekanismin ja EU:n kyberturvallisuusreservin. Vaikka organisaatio ei koskaan pyytäisi suoraan apua reserviltä, sen näyttö, viranomaisyhteydet, toimittajasopimukset, poikkeamien aikajanat ja asiakasviestintä voivat muodostua osaksi laajempaa eurooppalaista reagointiketjua.

Puutteet näkyvät nopeasti. Monilla organisaatioilla on työkalut, tiketit ja politiikat, mutta ei näyttöä, joka kestää sääntelyvalvonnan. Ne voivat sanoa: ”otimme yhteyttä viranomaiseen”, mutta eivät pysty osoittamaan, kuka oli valtuutettu, mikä kynnys laukaisi yhteydenoton, mitä viestittiin, säilytettiinkö lokit, oliko toimittajalla sopimusperusteinen avustamisvelvollisuus tai voidaanko loppuraportti rekonstruoida tapahtumahetkellä tehtyjen päätösten perusteella.

Ratkaisu ei ole erillinen ”kybersolidaarisuussäädöksen kansio”. Ratkaisu on ISO/IEC 27001:2022 -standardin mukainen tietoturvallisuuden hallintajärjestelmä, joka tuottaa näytön kerran ja hyödyntää sitä uudelleen NIS2:n, DORA:n, GDPR:n, NIST CSF 2.0:n ja COBIT 2019:n odotusten täyttämiseen.

Tämä näyttö alkaa ennen poikkeamaa.

Miksi EU:n kybersolidaarisuussäädös nostaa näytön vaatimustasoa

Kybersolidaarisuussäädös on suunniteltu EU-tason kyberuhkien havaitsemiseen, valmiuteen ja kriisireagointiin. Sen käytännön vaikutus tietoturvajohtajille, auditoijille ja vaatimustenmukaisuudesta vastaaville on selvä: laajamittainen poikkeamien koordinointi edellyttää näyttöä, joka on nopeampaa, selkeämpää, johdonmukaisempaa ja helpommin jaettavissa luotetuille sidosryhmille.

Kun rajat ylittävä vaikutus on mahdollinen, organisaation on ehkä koordinoitava kansallisten CSIRT-toimijoiden, toimivaltaisten viranomaisten, sektorivalvojien, tietosuojaviranomaisten, finanssivalvojien, lainvalvontaviranomaisten, asiakkaiden, henkilötietojen käsittelijöiden, toimittajien ja ulkoisten poikkeamavasteen toimijoiden kanssa. EU:n kyberturvallisuusreservi tuo mukaan lisäulottuvuuden, koska ennalta arvioidut yksityiset palveluntarjoajat voivat tukea valmiutta, reagointia ja toipumista. Tämä tekee toimittajahallinnasta, oikeudellisesta toimivallasta, tietojen käsittelystä ja näytön säilyttämisestä entistä tärkeämpää.

Yksityiset toimijat ovat tämän toimintaympäristön ytimessä. Pilvipalveluntarjoajilla, datakeskuksilla, hallinnoiduilla palveluntarjoajilla, hallinnoiduilla tietoturvapalveluntarjoajilla, digitaalisen infrastruktuurin operaattoreilla, fintech-yrityksillä ja SaaS-alustoilla on usein hallussaan telemetriatiedot, lokit, asiakasvaikutusta koskevat tiedot ja tekniset faktat, joita viranomaiset tarvitsevat merkittävän poikkeaman ymmärtämiseksi.

NIS2 osoittaa jo tähän suuntaan. Sitä sovelletaan moniin keskisuuriin ja suuriin toimijoihin liitteen I ja liitteen II sektoreilla, kun ne tarjoavat palveluja tai harjoittavat toimintaa EU:ssa. Se kattaa myös tietyt toimijat koosta riippumatta, kuten luottamuspalveluntarjoajat, DNS-palveluntarjoajat, ylimmän tason verkkotunnusrekisterit ja verkkotunnusten rekisteröintipalveluntarjoajat. Liite I sisältää digitaalisen infrastruktuurin, kuten pilvipalvelut, datakeskuspalvelut, sisällönjakeluverkot, DNS-palveluntarjoajat, luottamuspalveluntarjoajat ja TLD-rekisterit. Se sisältää myös B2B-ICT-palvelunhallinnan, mukaan lukien hallinnoidut palveluntarjoajat ja hallinnoidut tietoturvapalveluntarjoajat. Liite II sisältää digitaalisia palveluntarjoajia, kuten verkkomarkkinapaikkoja, hakukoneita ja sosiaalisen verkostoitumisen palvelualustoja.

DORA lisää toisen kerroksen finanssisektorille. Sitä on sovellettu 17. tammikuuta 2025 alkaen laajaan joukkoon finanssialan toimijoita, kuten luottolaitoksiin, maksulaitoksiin, sähköisen rahan liikkeeseenlaskijoihin, sijoituspalveluyrityksiin, kryptovarapalveluntarjoajiin, kaupankäyntipaikkoihin, vakuutus- ja jälleenvakuutusyrityksiin, luottoluokituslaitoksiin, joukkorahoituspalveluntarjoajiin ja muihin toimijoihin. Se luo myös merkittäviä odotuksia ICT-kolmansien osapuolten palveluntarjoajille, koska finanssialan toimijat säilyttävät vastuun ulkoistetuista ICT-palveluista.

Fintech-poikkeama vuonna 2026 voidaan siksi koordinoida DORA-valvontakanavien kautta, kun taas fintech-yritystä tukeva SaaS-palveluntarjoaja tai MSSP voi kuulua NIS2:n piiriin. Sama tekninen tapahtuma voi synnyttää eri toimijoille erilaisia raportointivelvollisuuksia, näyttöodotuksia ja sopimusvelvoitteita.

ISO/IEC 27001:2022 antaa organisaatioille hallintamallin tämän monimutkaisuuden johtamiseen. Kohdat 4.1–4.4 edellyttävät, että organisaatio määrittää ISMS:n liiketoimintaympäristössään, tunnistaa sidosryhmät sekä niiden lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset, määrittää rajat ja riippuvuudet sekä perustaa hallintajärjestelmän. Kohdat 5.1–5.3 asettavat johdolle vastuun politiikasta, resursseista, integroinnista ja roolien osoittamisesta. Kohdat 6.1.1–6.1.3 edellyttävät toistettavaa riskien arviointia, riskien käsittelyä ja soveltuvuuslausuntoa. Kohta 8.1 edellyttää operatiivista ohjausta, mukaan lukien ulkoisesti tuotettujen prosessien, tuotteiden ja palvelujen hallinta.

Tämä on kybersolidaarisuussäädökseen valmistautumisen ydin: osoittaa, että kriisireagointi on hallittua, testattua ja auditoitavissa, ei improvisoitua.

Clarysecin näyttömalli: yksi poikkeama, monta velvoitetta

Rajat ylittävä poikkeama ei odota, että lakitiimit luokittelevat sen. Näyttö on kerättävä ensimmäisestä hälytyksestä alkaen ja ohjattava sen jälkeen oikeille raportointi- ja koordinointipoluille.

Clarysecin lähestymistapa yhdistää kolme osa-aluetta:

1. Zenith Blueprint: auditoijan 30 vaiheen tiekartta Zenith Blueprint, joka muuttaa ISO/IEC 27001:2022 -toteutuksen vaiheistetuksi ja auditointivalmiiksi etenemispoluksi.
2. Zenith Controls: vaatimustenmukaisuuden ristiinopas Zenith Controls, joka kartoittaa ISO/IEC 27002:2022 -hallintakeinot niihin liittyviin hallintakeinoihin, attribuutteihin, operatiivisiin kyvykkyyksiin, tietoturva-alueisiin ja viitekehysten välisiin näyttöodotuksiin.
3. Clarysecin politiikkamallit tietoturvapoikkeamiin reagointiin, todistusaineiston keräämiseen, toimittajaturvallisuuteen, lokitukseen, seurantaan ja liiketoiminnan jatkuvuuteen, mukautettuina yritys- ja pk-yritysympäristöihin.

Zenith Blueprintin Controls in Action -vaiheen vaihe 22 käsittelee ISO/IEC 27002:2022 -hallintakeinoa 5.5, yhteydenpitoa viranomaisiin. Siinä todetaan:

Hallintakeino 5.5 varmistaa, että organisaatio on valmis toimimaan ulkoisten viranomaisten kanssa tarvittaessa, ei reaktiivisesti tai paniikissa, vaan ennalta määriteltyjen, jäsenneltyjen ja hyvin ymmärrettyjen kanavien kautta.

Sama osio esittää kysymyksen, johon jokaisen tietoturvajohtajan tulisi vastata ennen kriisiä:

jos organisaationne joutuisi kyberhyökkäyksen kohteeksi, osalliseksi tietomurtoon tai tutkinnan kohteeksi, kuka ottaisi yhteyttä viranomaisiin? Miten hän tietäisi, mitä sanoa? Millä edellytyksillä tällainen yhteydenotto käynnistettäisiin?

Tämä ei ole hallinnollista paperityötä. Kybersolidaarisuussäädöksen toimintaympäristössä se on ero hallitun ennakkovaroituksen ja eri lainkäyttöalueille lähetettyjen ristiriitaisten viestien välillä.

Zenith Controls käsittelee ISO/IEC 27002:2022 -hallintakeinoa 5.5, yhteydenpitoa viranomaisiin, ennaltaehkäisevänä ja korjaavana hallintakeinona, joka liittyy luottamuksellisuuteen, eheyteen ja saatavuuteen sekä on linjassa Identify-, Protect-, Respond- ja Recover-käsitteiden kanssa. Se yhdistää 5.5:n poikkeamien hallinnan suunnitteluun ja valmisteluun, tapahtumien raportointiin, uhkatiedusteluun, erityisryhmiin ja poikkeamiin reagointiin.

Sama opas käsittelee ISO/IEC 27002:2022 -hallintakeinoa 5.24, tietoturvapoikkeamien hallinnan suunnittelua ja valmistelua, korjaavana hallintakeinona, joka liittyy Respond- ja Recover-toimintoihin. Sen yhteydet tapahtumien arviointiin, tietoturvapoikkeamiin reagointiin, opittuihin asioihin, lokitukseen, seurantaan, tietoturvaan häiriön aikana ja jatkuvuuteen osoittavat, mitä auditoijat usein testaavat: yhdistääkö suunnitelma havaitsemisen, luokittelun, eskaloinnin, näytön, toipumisen ja oppimisen.

Todistusaineiston käsittelyssä ISO/IEC 27002:2022 -hallintakeino 5.28, todistusaineiston kerääminen, on erityisen tärkeä. Zenith Controls yhdistää sen tietoturvapoikkeamiin reagointiin, lokitukseen, seurantaan ja tapahtumien raportointiin. Vakavassa rajat ylittävässä poikkeamassa tämä on kohta, jossa teknisestä tutkinnasta tulee puolustettavissa olevaa.

Kybersolidaarisuussäädökseen valmistautumisen kartoitus ISO 27001 -näyttöön

EU:n kybersolidaarisuussäädös luo valmius- ja koordinointiympäristön. ISO/IEC 27001:2022 tarjoaa näytön tuottamisen perustan. NIS2, DORA ja GDPR määrittävät monia yksityiskohtaisia raportointi-, hallinnointi- ja suojausodotuksia.

Huomaa, mikä puuttuu: erillinen vaatimustenmukaisuussiilo. Sama näyttö, joka tukee ISO/IEC 27001:2022 -sertifiointia, voi tukea NIS2:n johdon vastuuvelvollisuutta, DORA:n ICT-riskien hallintaa, GDPR:n tietoturvan osoitusvelvollisuutta, NIST CSF:n viestintätuloksia ja COBIT 2019:n varmennusodotuksia.

NIS2: raportointikello käynnistyy, kun poikkeama tulee tietoon

NIS2 on keskeinen vuoden 2026 valmiuden kannalta, koska se määrittää vaiheistetun poikkeamien raportointityönkulun.

Article 23 edellyttää, että keskeiset ja tärkeät toimijat ilmoittavat merkittävistä palvelun tuottamiseen vaikuttavista poikkeamista CSIRT-toimijalleen tai toimivaltaiselle viranomaiselle ilman aiheetonta viivytystä. Ennakkovaroitus on toimitettava ilman aiheetonta viivytystä ja viimeistään 24 tunnin kuluessa siitä, kun merkittävä poikkeama on tullut tietoon. Sen tulisi tarvittaessa osoittaa, epäilläänkö pahantahtoisia tai lainvastaisia tekoja ja onko rajat ylittävä vaikutus mahdollinen.

Poikkeamailmoitus seuraa ilman aiheetonta viivytystä ja viimeistään 72 tunnin kuluessa poikkeaman tietoon tulemisesta. Se päivittää ennakkovaroituksen ja antaa alustavan arvion vakavuudesta, vaikutuksesta ja käytettävissä olevista vaarantumisen indikaattoreista. Loppuraportti on toimitettava kuukauden kuluessa poikkeamailmoituksesta, ja siinä kuvataan vakavuus, vaikutus, todennäköinen uhkatyyppi tai juurisyy, lieventämistoimenpiteet ja rajat ylittävä vaikutus.

Siksi tietoturvapoikkeamiin reagointi ei voi alkaa tyhjästä asiakirjasta.

Yritystason Tietoturvapoikkeamien hallintapolitiikka Tietoturvapoikkeamien hallintapolitiikka toteaa:

NIS2 Article 23 (ilmoitus 24 tunnin kuluessa siitä, kun poikkeama on tullut tietoon)

Pk-yrityksille tarkoitettu Tietoturvapoikkeamien hallintapolitiikka - SME Tietoturvapoikkeamien hallintapolitiikka - SME tuo saman ajoituslogiikan käytännön hallinnointiin:

“Reagointiaikataulut, mukaan lukien tietojen palauttaminen ja ilmoitusvelvoitteet, on dokumentoitava ja yhdenmukaistettava lakisääteisten vaatimusten kanssa, kuten GDPR:n 72 tunnin henkilötietojen tietoturvaloukkausta koskevan ilmoitusvaatimuksen kanssa.”

Lähde: Tietoturvapoikkeamien hallintapolitiikka - SME, osio “Hallinnointivaatimukset”, lauseke 5.3.2.

Se velvoittaa myös usean sääntelyjärjestelmän arvioinnin osaksi poikkeamaprosessia:

“Kun kyse on asiakastiedoista, toimitusjohtajan on arvioitava lakisääteiset ilmoitusvelvoitteet GDPR:n, NIS2:n tai DORA:n soveltuvuuden perusteella.”

Lähde: Tietoturvapoikkeamien hallintapolitiikka - SME, osio “Riskienkäsittely ja poikkeukset”, lauseke 7.4.1.

Kybersolidaarisuussäädöksen skenaariossa ”rajat ylittävä vaikutus on mahdollinen” muuttuu operatiivisesti tärkeäksi. Ennakkovaroituksessa ei ehkä ole kaikkia faktoja, mutta organisaation on pystyttävä osoittamaan käytettävissä olevan näytön perusteella, miksi se epäili tai ei epäillyt rajat ylittävää vaikutusta.

Poikkeamatallenteeseen tulisi kirjata:

• Milloin organisaatio tuli tietoiseksi tapahtumasta.
• Kuka määritti tapahtuman mahdolliseksi poikkeamaksi.
• Mitkä palvelut, maat, asiakkaat tai sektorit saattoivat olla vaikutuksen kohteena.
• Epäiltiinkö pahantahtoista tai lainvastaista toimintaa.
• Mitkä vaarantumisen indikaattorit olivat käytettävissä.
• Mitä viranomaisyhteydenottopolkua käytettiin.
• Tarvittiinko asiakasviestintää.
• Mikä näyttö säilytettiin ennen merkittäviä korjaavia toimenpiteitä.

Paras aika suunnitella nämä kentät on ennen kello 03.17:ää.

DORA: kun asiakas on säännelty, mutta toimittajalla on lokit

DORA muuttaa toimittajakeskustelua. Finanssialan toimijoiden on hallittava ICT-kolmansien osapuolten riskiä osana ICT-riskienhallinnan viitekehystään. ICT-palvelujen ulkoistaminen ei siirrä sääntelyvastuuta pois finanssialan toimijalta.

DORA edellyttää ICT-kolmansien osapuolten riskistrategioita, ICT-palvelusopimusten rekistereitä, huolellisuusarviointia, auditointi- ja tarkastussuunnittelua, irtisanomisoikeuksia ja testattuja exit-strategioita kriittisille tai tärkeille ICT-palveluille. Article 30 edellyttää sopimuksellista selkeyttä, mukaan lukien palvelukuvaukset, sijainnit, tietojen käsittely, luottamuksellisuus, eheys, saatavuus, palvelutasot, avustaminen ICT-poikkeamien aikana, yhteistyö viranomaisten kanssa ja irtisanomisoikeudet. Kriittisten tai tärkeiden toimintojen osalta sovelletaan tiukempia ehtoja.

Palataan Marian poikkeamaan. Saksalainen pankki on DORA:n sääntelyn piirissä. InnovateCloud tarjoaa SaaS-palveluja. MSSP havaitsee epäilyttävää toimintaa. Pilvi-infrastruktuurin tarjoajalla on osa keskeisistä auditointilokeista. Alihankkija operoi osaa telemetriaputkesta. Pankki säilyttää vastuun, mutta se ei pysty luokittelemaan ja raportoimaan tehokkaasti ilman toimittajan näyttöä.

Clarysec käsittelee tätä toimittajaluokittelun ja sopimusnäytön avulla. Yritystason Kolmansien osapuolten ja toimittajien tietoturvapolitiikka Kolmansien osapuolten ja toimittajien tietoturvapolitiikka edellyttää:

Toimittajasopimusten on sisällettävä:

Pk-yrityksille tarkoitettu Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - SME Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - SME soveltaa samaa vaatimustenmukaisuuslogiikkaa kevyemmässä toimintamallissa:

Sopimusten on sisällettävä pakolliset lausekkeet, jotka kattavat:

Arvo on näiden sanojen takana olevassa sopimusliitteessä: poikkeamien ilmoitusvelvoitteet, lokien käyttöoikeus, auditointioikeudet, luottamuksellisuus, tietojen sijainti, alihankkijakontrollit, yhteistyö viranomaisten kanssa, toipumisen tuki ja exit-velvoitteet.

Zenith Blueprintin Controls in Action -vaiheen vaihe 23 antaa toteutuspolun:

Kokoa täydellinen luettelo nykyisistä toimittajista ja palveluntarjoajista (5.19) ja luokittele ne sen perusteella, onko niillä pääsy järjestelmiin, tietoihin tai operatiiviseen ohjaukseen. Varmista kunkin luokitellun toimittajan osalta, että tietoturvaodotukset on sisällytetty selkeästi sopimuksiin (5.20), mukaan lukien luottamuksellisuus, pääsy, poikkeamien raportointi ja vaatimustenmukaisuusvelvoitteet.

Se jatkaa alaspäin ketjutettavalla riskillä:

Tunnista jokaisen kriittisen toimittajan osalta, käyttävätkö ne alihankkijoita (alikäsittelijöitä), joilla voi olla pääsy tietoihinne tai järjestelmiinne. Dokumentoi, miten tietoturvavaatimuksenne ketjutetaan näille osapuolille joko toimittajanne sopimusehtojen tai omien suorien lausekkeidenne kautta.

Tämä on myös kyberturvallisuusreservivalmiutta. Jos ulkoinen reagointipalveluntarjoaja tulee ympäristöösi hätätilanteessa, sinun on tiedettävä oikeusperuste, pääsyn laajuus, näyttösäännöt, tietojen käsittelyvelvoitteet, viranomaiskoordinoinnin polku ja exit-ehdot. DORA tekee tämän nimenomaiseksi finanssialan toimijoille. NIS2 tekee siitä merkityksellistä keskeisille ja tärkeille toimijoille. ISO/IEC 27001:2022 tekee siitä auditoitavaa.

GDPR: tietoturvaloukkauskysymys kyberkriisin sisällä

Kaikki kyberturvallisuuspoikkeamat eivät ole henkilötietojen tietoturvaloukkauksia, mutta jokainen vakava poikkeama tulisi arvioida tämän mahdollisuuden osalta.

GDPR soveltuu käsittelyyn EU:ssa sijaitsevan toimipaikan yhteydessä sekä EU:n ulkopuolisiin rekisterinpitäjiin tai henkilötietojen käsittelijöihin, jotka tarjoavat tavaroita tai palveluja EU:ssa oleville henkilöille tai seuraavat heidän käyttäytymistään EU:ssa. Se määrittää henkilötiedot, käsittelyn, rekisterinpitäjän, henkilötietojen käsittelijän ja henkilötietojen tietoturvaloukkauksen. Sen periaatteisiin kuuluvat eheys, luottamuksellisuus ja osoitusvelvollisuus, mikä tarkoittaa, että rekisterinpitäjien on pystyttävä osoittamaan vaatimustenmukaisuus.

Kello 03.17 alkaneen poikkeaman aikana Marian tiimin on kysyttävä:

• Onko henkilötietoihin päästy, onko niitä luovutettu, muutettu, kadotettu tai tuhottu?
• Onko InnovateCloud rekisterinpitäjä, henkilötietojen käsittelijä vai molempia vaikutuksen kohteena olevien tietojen osalta?
• Sisältyykö käsittelyyn erityisiin henkilötietoryhmiin kuuluvia tietoja?
• Mitkä asiakkaat tai henkilöt ovat vaikutuksen kohteena?
• Riittävätkö lokit soveltamisalan arviointiin?
• Kulkevatko GDPR:n ilmoitusvelvoitteet rinnakkain NIS2- tai DORA-velvoitteiden kanssa?

Siksi tietosuojakoordinointi kuuluu poikkeaman eskalointiin, ei myöhäiseen oikeudelliseen tarkasteluun sen jälkeen, kun järjestelmät on rakennettu uudelleen ja lokit ovat kiertäneet pois.

Pk-yrityksille tarkoitettu Lokitus- ja valvontapolitiikka - SME Lokitus- ja valvontapolitiikka - SME toteaa:

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

Lauseke on yksinkertainen, mutta se ratkaisee todellisen epäonnistumismallin. Tietosuojavastaavat tarvitsevat näyttöä silloin, kun se on vielä riittävän tuoretta sen määrittämiseksi, onko henkilötietojen tietoturvaloukkaus tapahtunut ja ovatko henkilöt vaarassa.

Rakenna 24 tunnin näyttöpaketti rajat ylittävälle poikkeamalle

Käytännön valmiusharjoituksen tulisi simuloida rajat ylittävän poikkeaman ensimmäiset 24 tuntia. Tavoitteena ei ole yliraportointi. Tavoitteena on osoittaa, että organisaatio pystyy kokoamaan faktat, tekemään puolustettavissa olevat päätökset ja pitämään viestinnän johdonmukaisena.

Skenaario

MSSP havaitsee epäilyttävää etuoikeutettua käyttöä epätavalliselta alueelta tuotannon asiakasympäristöön. Sama lähdeinfrastruktuuri näkyy hälytyksissä, jotka vaikuttavat kahteen asiakkaaseen kahdessa jäsenvaltiossa. Yksi asiakas on finanssialan toimija. Vaikutuksen kohteena oleva ympäristö sisältää henkilötietoja, mutta tietojen luvaton siirto ei ole varmistunut.

Vaihe 1: Avaa poikkeamatallenne

Luo poikkeamatiketti hyväksyttyjä luokittelukenttiä käyttäen. Sisällytä tietoon tuloaika, havaitsemislähde, vaikutuksen kohteena olevat omaisuuserät, vaikutuksen kohteena olevat palvelut, mahdollisesti vaikutuksen kohteena olevat maat, epäilty pahantahtoinen toiminta, alustava vakavuus ja poikkeaman johtaja.

Kytke tämä ISO/IEC 27002:2022 -hallintakeinoihin 5.24, 5.25 ja 5.26 sekä ISO/IEC 27001:2022:n liite A:n hallintakeinoihin A.5.24, A.5.25 ja A.5.26.

Vaihe 2: Käynnistä viranomaispäätösten työnkulku

Käytä Zenith Blueprintin vaiheen 22 edellyttämää viranomaisyhteyksien matriisia. Tunnista, mitkä viranomaiset voivat olla merkityksellisiä: kansallinen CSIRT, tietosuojaviranomainen, finanssivalvoja, lainvalvontaviranomainen ja sektorivalvoja.

Kirjaa päätös ja sen perustelut. Jos NIS2-ennakkovaroitusta ei tehdä, kirjaa miksi. Jos rajat ylittävä vaikutus on mahdollinen, kirjaa päätelmää tukeva näyttö.

Vaihe 3: Säilytä näyttö ennen merkittäviä korjaavia toimenpiteitä

Yritystason Todisteiden keräämisen ja forensiikan politiikka Todisteiden keräämisen ja forensiikan politiikka toteaa:

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

Pk-yrityksille tarkoitettu Todisteiden keräämisen ja forensiikan politiikka - SME Todisteiden keräämisen ja forensiikan politiikka - SME antaa saman kurinalaisuuden yksinkertaisemmassa muodossa:

“Jokainen digitaalisen todistusaineiston kohde on kirjattava lokiin seuraavilla tiedoilla:”

Lähde: Todisteiden keräämisen ja forensiikan politiikka - SME, osio “Hallinnointivaatimukset”, lauseke 5.2.1.

Pöytäharjoitusta varten kerää esimerkkimerkinnät todistusaineistosta: SIEM-hälytyksen vienti, identiteetintarjoajan lokit, etuoikeutettujen istuntojen tallenteet, päätelaitteen tilannevedos, palomuurilokit, pilvipalvelun auditointilokit, asiakasvaikutusmuistiinpanot ja viestinnän hyväksynnät.

Vaihe 4: Aktivoi toimittajien avustaminen

Tarkista toimittajarekisteri. Tunnista MSSP, pilvipalveluntarjoaja ja kriittiset alihankkijat. Vahvista poikkeamatilanteen tukilausekkeet, eskalointiyhteydet, lokien säilytysajat, näytön muoto ja viranomaisyhteistyövelvoitteet.

Tämä tukee suoraan DORA:n ICT-kolmansien osapuolten riskivaatimuksia ja NIS2:n toimitusketjun tietoturvaodotuksia.

Vaihe 5: Laadi kolme viestiä

Laadi kolme viestiä samasta faktapohjasta:

Vaihe 6: Päätä harjoitus opittuihin asioihin

Päivitä riskirekisteri, soveltuvuuslausunto, toimittajarekisteri ja tietoturvapoikkeamiin reagointisuunnitelma. Jos harjoitus paljastaa puuttuvia lokeja, epäselviä viranomaisyhteyksiä tai heikkoja toimittajalausekkeita, käynnistä korjaavat toimenpiteet.

Zenith Blueprintin Controls in Action -vaiheen vaihe 23 ohjeistaa organisaatioita validoimaan poikkeamakyvykkyydet näin:

Valitse viimeaikainen tapahtuma tai toteuta pöytäharjoitus suunnitelman validoimiseksi. Tallenna ja kirjaa lokiin kaikki päätökset, roolit ja viestintä (5.26) ja päivitä suunnitelma opituilla asioilla (5.27). Varmista, että käytössä on menettelyt forensisen todistusaineiston säilyttämiseksi (5.28), mukaan lukien lokien tilannevedokset, varmuuskopiot ja vaikutuksen kohteena olevien järjestelmien turvallinen eristäminen.

Tämä kappale on auditointivalmis harjoitusagenda.

Lokitus: ero koordinoinnin ja spekulaation välillä

Rajat ylittävien poikkeamien koordinointi epäonnistuu, kun kaikilla on mielipiteitä mutta kenelläkään ei ole aikaleimoja.

Zenith Blueprintin Controls in Action -vaiheen vaihe 19 ilmaisee asian selkeästi:

Lokitus on minkä tahansa turvallisen IT-ympäristön elinehto. Ilman sitä poikkeamat jäävät näkymättömiksi, vastuullisuus hälvenee ja syy-seuraussuhteet katoavat ilmaan.

Se jatkaa:

Pohjimmiltaan lokituksessa on kyse jäljitettävyydestä. Kun jokin menee vikaan, olipa kyse epäonnistuneesta kirjautumisyrityksestä, kriittisten tiedostojen poistamisesta tai luvattoman skriptin ajamisesta palvelimella, lokit tarjoavat forensisen säikeen, joka auttaa selvittämään, mitä todella tapahtui.

NIS2:ssa lokit tukevat 72 tunnin poikkeamailmoitusta alustavalla vakavuudella, vaikutuksella ja vaarantumisen indikaattoreilla. DORA:ssa lokit tukevat merkittävän ICT-poikkeaman luokittelua, juurisyyanalyysiä, operatiivista vaikutusta ja kolmannen osapuolen vastuun osoittamista. GDPR:ssä lokit tukevat arviota siitä, onko henkilötietoihin päästy tai onko niitä luovutettu. Kybersolidaarisuussäädöksen kontekstissa lokit tukevat jaettua tilannekuvaa ilman, että reagointitoimijoiden on tukeuduttava spekulaatioon.

Jos vastaus mihin tahansa kysymykseen on ”emme ole varmoja”, asia kuuluu riskienkäsittelysuunnitelmaan.

Liiketoiminnan jatkuvuus ja turvallinen kriisitoiminta

Kybersolidaarisuussäädöksestä käytävä keskustelu keskittyy luonnollisesti tietoturvapoikkeamiin reagointiin, mutta häiriönsietokyky tarkoittaa myös kriittisten palvelujen pitämistä turvallisina häiriön aikana.

NIS2 Article 21 edellyttää kaikki vaarat kattavaa lähestymistapaa, joka kattaa poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, varmuuskopioiden hallinnan, katastrofipalautuksen, kriisinhallinnan, toimitusketjun tietoturvan, haavoittuvuuksien käsittelyn, vaikuttavuuden arvioinnin, kyberhygienian, kryptografian, HR-turvallisuuden, pääsynhallinnan, omaisuudenhallinnan, monivaiheisen todennuksen, turvallisen viestinnän ja suojatun hätäviestinnän soveltuvin osin.

DORA edellyttää vastaavasti hallinnointia, ICT-riskien hallintaa, poikkeamien hallintaa, häiriönsietokyvyn testausta, kolmansien osapuolten riskienhallintaa, jatkuvuutta ja toipumista. Pienemmillä toimijoilla voi olla yksinkertaistetut vaatimukset, mutta ne tarvitsevat silti dokumentoidun ICT-riskien hallinnan, seurannan, häiriönsietokykyiset järjestelmät, poikkeamien käsittelyn, kolmannen osapuolen riippuvuuksien tunnistamisen, varmuuskopiot, palautuksen, testauksen, poikkeaman jälkeisen oppimisen ja koulutuksen.

Yritystason Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka lähtee yksinkertaisesta vaatimuksesta:

Suunnitelmien on katettava:

Tämän ilmauksen takana on jatkuvuusnäyttö, jota auditoijat odottavat: palautusprioriteetit, toipumisaikatavoitteet, palautuspistetavoitteet, varmuuskopiointiaikataulut, palautustestit, kriisiroolit, vaihtoehtoinen viestintä, toimittajariippuvuudet ja harjoituksen jälkeiset parantamistoimet.

ISO/IEC 27002:2022 -hallintakeinot 5.29 ja 5.30 ovat tässä keskeisiä. Hallintakeino 5.29 käsittelee tietoturvaa häiriön aikana. Hallintakeino 5.30 käsittelee ICT-valmiutta liiketoiminnan jatkuvuutta varten. Zenith Controls yhdistää 5.24:n mukaisen poikkeamasuunnittelun tietoturvaan häiriön aikana ja laajempaan jatkuvuussuunnitteluun. Tämä on erityisen merkityksellistä, kun normaalit kanavat eivät ole käytettävissä, identiteettijärjestelmät ovat heikentyneet tai kriisitiimien on koordinoitava viranomaisten kanssa suojatun hätäviestinnän kautta.

Vaatimustenmukaisuuden ristiinkartoitus: NIS2, DORA, GDPR, NIST CSF 2.0 ja COBIT 2019

Tietoturvajohtaja ei tarvitse viittä erillistä poikkeamaohjelmaa. Hän tarvitsee yhden näyttömallin, jota voidaan tarkastella viiden eri linssin kautta.

NIST CSF 2.0:n nyky- ja tavoiteprofiilimenetelmä on erityisen hyödyllinen organisaatioille, jotka eivät vielä ole riittävän kypsiä täysimittaiseen integroituun GRC-alustaan. Se kannustaa organisaatioita määrittämään profiilin soveltamisalan, keräämään syötteitä, kuten politiikkoja, yrityksen riskiprioriteetteja, liiketoimintavaikutusten arviointeja, vaatimuksia, standardeja, menettelyjä, suojatoimia ja rooleja, analysoimaan puutteita ja luomaan priorisoidun toimintasuunnitelman. Tämä on lähellä käytännön kybersolidaarisuussäädösvalmiuden sprinttiä: nykyinen näyttö, tavoitevelvoitteet, puutesuunnitelma, omistajat, päivämäärät ja auditointijälki.

COBIT 2019- ja ISACA-tyyppiset auditoijat kysyvät yleensä, onko hallinnointitavoitteille määritetty omistajat ja mitataanko ja seurataanko niitä. Heille ei riitä vastaus ”SOC hoitaa sen”. He kysyvät, miten hallintoelimet hyväksyvät riskitoimenpiteet, miten suorituskyvystä raportoidaan, miten kolmansien osapuolten riskiä hallitaan, miten poikkeukset hyväksytään ja miten korjaavia toimenpiteitä seurataan.

Miten auditoijat testaavat samaa poikkeamaa

Sama kello 03.17 alkanut poikkeama tuottaa erilaisia auditointikysymyksiä arvioijan toimeksiannon mukaan.

ISO/IEC 27001:2022 -auditoija aloittaa ISMS:stä. Hän kysyy, kuuluuko poikkeamaprosessi soveltamisalaan, sisältävätkö sidosryhmävaatimukset NIS2:n, DORA:n, GDPR:n ja sopimukset, onko riskien arvioinnissa huomioitu rajat ylittävät ja toimittajaskenaariot, onko liite A:n hallintakeinot valittu soveltuvuuslausunnossa ja osoittavatko operatiiviset tallenteet, että prosessia noudatettiin.

NIS2:een keskittyvä viranomainen tai arvioija keskittyy johdon vastuuvelvollisuuteen, Article 21:n riskienhallintatoimenpiteisiin ja Article 23:n raportointiin. Hän voi kysyä, milloin organisaatio tuli tietoiseksi poikkeamasta, miksi poikkeama oli tai ei ollut merkittävä, miten rajat ylittävä vaikutus arvioitiin, tiedotettiinko asiakkaita ja toteutettiinko korjaavat toimenpiteet ilman aiheetonta viivytystä.

DORA-valvoja tai sisäinen tarkastusryhmä kysyy, vaikuttiko poikkeama kriittisiin tai tärkeisiin toimintoihin, tukivatko ICT-kolmansien osapuolten palveluntarjoajat reagointia, säilyttikö finanssialan toimija vastuun, oliko tietorekisteri tarkka, luokiteltiinko poikkeama oikein ja palautuivatko opitut asiat häiriönsietokyvyn testaukseen ja toimittajien valvontaan.

GDPR-auditoija tai tietosuojaviranomainen kysyy, oliko organisaatiolla riittävästi näyttöä sen määrittämiseen, oliko henkilötietoja loukattu, olivatko rekisterinpitäjän ja henkilötietojen käsittelijän roolit selkeät, olivatko rekisteröidyt vaarassa, olivatko luottamuksellisuutta ja eheyttä koskevat kontrollit asianmukaisia ja ylläpidettiinkö osoitusvelvollisuuden dokumentaatiota.

NIST CSF 2.0 -arvioija kääntää tapahtuman Govern-, Identify-, Protect-, Detect-, Respond- ja Recover-tuloksiksi. Hän etsii sidosryhmien odotuksia, lakisääteisiä velvoitteita, riskinottohalukkuutta, toimittajahallintaa, lokitusta, seurantaa, reagoinnin toteutusta, viestintää ja palautuksen validointia.

COBIT 2019- tai ISACA-auditoija keskittyy hallinnointiin ja hallintajärjestelmän tehokkuuteen: omistajuuteen, päätösoikeuksiin, mittareihin, riskin hyväksymiseen, prosessin suorituskykyyn, varmentamiseen ja jatkuvaan parantamiseen.

Tässä Zenith Controls on hyödyllinen vaatimustenmukaisuuden ristiinkompassina. Se ei nimeä virallisia hallintakeinoja uudelleen eikä luo rinnakkaista hallintakeinoviitekehystä. Se näyttää, miten ISO/IEC 27002:2022 -hallintakeinot, kuten 5.5, 5.24 ja 5.28, liittyvät operatiivisiin kyvykkyyksiin, niihin liittyviin hallintakeinoihin ja auditoinnin kannalta merkitykselliseen näyttöön.

Mitä tietoturvajohtajien tulisi tehdä nyt vuoden 2026 valmiutta varten

Jos valmistaudut EU:n kybersolidaarisuussäädöksen toimintaympäristöön, aloita näytöstä, älä iskulauseista.

Ensiksi päivitä ISMS:n toimintaympäristö ja sidosryhmäanalyysi. Tunnista, kuuluvatko organisaatiosi, asiakkaasi tai toimittajasi NIS2:n, DORA:n tai GDPR:n piiriin. Sisällytä jäsenvaltiojalanjälki, sektoriluokitus, kriittiset asiakkaat, ICT-palveluriippuvuudet ja viranomaisyhteydet.

Toiseksi toteuta rajat ylittävän poikkeaman pöytäharjoitus. Käytä skenaariota, joka sisältää toimittajan, useamman kuin yhden jäsenvaltion, mahdollisen henkilötietojen altistumisen ja säännellyn finanssiasiakkaan. Rajaa ensimmäiset 24 tuntia ajallisesti.

Kolmanneksi katselmoi toimittajasopimukset. Vahvista ilmoitusvelvoitteet, lokien käyttöoikeus, forensinen tuki, viranomaisyhteistyö, alihankkijoille ketjutettavat velvoitteet, tietojen sijainti, auditointioikeudet, jatkuvuustuki ja irtisanomisoikeudet.

Neljänneksi testaa todistusaineiston kerääminen. Vie lokit, säilytä tilannevedokset, merkitse näyttö, kirjaa hallussapitoketju ja validoi tietovarastoon pääsy. Jos politiikkasi sanoo, että näyttö yksilöidään ja säilytetään turvallisesti, osoita se.

Viidenneksi yhdenmukaista poikkeamaviestintä. NIS2-ennakkovaroituksen, DORA-eskaloinnin, GDPR:n tietoturvaloukkauksen arvioinnin ja asiakasviestin ei tule olla ristiriidassa keskenään. Niillä voi olla eri oikeudelliset tarkoitukset, mutta niiden on perustuttava samaan faktapohjaan.

Kuudenneksi ota hallitus mukaan harjoitukseen. Sekä NIS2 että DORA nostavat johdon vastuuvelvollisuuden merkitystä. ISO/IEC 27001:2022:n johtamista koskevat kohdat tekevät tästä auditoitavaa. Hallitus, joka ei ole koskaan nähnyt 24 tunnin kyberilmoituksen määräaikaa, ei ole valmis rajat ylittävään kriisiin.

Seuraavat askeleet Clarysecin kanssa

EU:n kyberturvallisuuden tulevaisuus rakentuu yhteistyölle ja osoitetulle luottamukselle. Organisaatiot, jotka käsittelevät NIS2:ta ja DORA:a erillisinä tarkistuslistoina, kamppailevat rajat ylittävissä poikkeamissa. Organisaatiot, jotka rakentavat näyttöön perustuvia ISO/IEC 27001:2022 -toimintamalleja, pystyvät vastaamaan viranomaisille, asiakkaille, auditoijille ja kriisireagointitoimijoille luottamuksella.

Clarysec auttaa tietoturvajohtajia, vaatimustenmukaisuudesta vastaavia, auditoijia ja liiketoiminnan omistajia muuttamaan EU:n kybersääntelyn auditointivalmiiksi operatiiviseksi näytöksi seuraavien avulla:

• Zenith Blueprint: auditoijan 30 vaiheen tiekartta jäsenneltyyn ISO/IEC 27001:2022 -toteutukseen ja auditointien vaiheistamiseen.
• Zenith Controls: vaatimustenmukaisuuden ristiinopas poikkeama-, viranomais-, toimittaja-, näyttö-, lokitus- ja jatkuvuushallintakeinojen kartoittamiseen viitekehysten välillä.
• Clarysecin politiikkamallit, mukaan lukien Tietoturvapoikkeamien hallintapolitiikka, Todisteiden keräämisen ja forensiikan politiikka, Kolmansien osapuolten ja toimittajien tietoturvapolitiikka, Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka sekä pk-yritysversiot silloin, kun suhteellisuus on tärkeää.

Paras aika valmistautua rajat ylittävien poikkeamien koordinointiin on ennen kello 03.17 tulevaa hälytystä. Toiseksi paras aika on tänään.

Aloita Clarysecin valmiuskatselmoinnilla, lataa asiaankuuluva politiikkatyökalupaketti tai pyydä läpikäynti siitä, miten Zenith Blueprint ja Zenith Controls voivat auttaa ISMS:ääsi tuottamaan näytön, jota vuoden 2026 kyberhäiriönsietokyky edellyttää.