NIS2- ja DORA-yhteystietorekisterit ISO 27001 -auditointinäyttöä varten

Kello 02.17 tapahtunut poikkeama: kun yhteystietoluettelosta tulee hallintakeino

Tiistaina kello 02.17 SOC-analyytikko näkee kuvion, jota kukaan ei halua nähdä. Etuoikeutettu palvelutili on todennettu epätavallisesta maantieteellisestä sijainnista, asiakastietueita on kyselty sarjana ja hallinnoidun havainnointipalvelun tarjoaja on avannut korkean vakavuustason tukipyynnön. Muutamassa minuutissa poikkeamajohtaja vahvistaa huolen: kiristyshaittaohjelman indikaattorit leviävät lateraalisesti, kriittinen tuotantopalvelu on heikentynyt ja asiakasdataa voi olla mukana.

Tekninen reagointi alkaa nopeasti. Päätelaitteet eristetään, identiteettilokit noudetaan, pilviympäristön tilannevedokset säilytetään ja hallinnoitu tietoturvapalveluntarjoaja liittyy tilannepalaveriin. Sen jälkeen alkaa kylmempi paniikki.

Tietoturvajohtaja kysyy: ”Kenelle ilmoitamme?”

Lakiasiat toteaa, että tietosuojaviranomainen voi olla tarpeen ottaa mukaan. Tietosuojavastaava (DPO) kysyy, onko kyseessä henkilötietojen tietoturvaloukkaus. Operatiivinen johtaja sanoo, että pilvipalveluntarjoaja on eskaloitava yritystuen sopimuslausekkeen perusteella. Vaatimustenmukaisuuspäällikkö kysyy, onko organisaatio NIS2:n mukainen tärkeä toimija tai sovelletaanko DORA:a, koska palvelu tukee säänneltyä finanssialan toimijaa. Hallitus haluaa tietää, mitä ensimmäisten 24 tunnin aikana on tehtävä.

Kukaan ei kiistä viestinnän tarvetta. Ongelma on se, että yhteystiedot, hyväksyntäpolku, oikeudelliset laukaisukriteerit ja näyttövaatimukset ovat hajallaan vanhassa liiketoiminnan jatkuvuuden taulukossa, toimittajasopimuksissa, sähköpostiketjuissa, vanhentuneessa vaatimustenmukaisuuswikissä ja yhden henkilön puhelimessa.

Tämä ei ole pelkkä operatiivinen hankaluus. Vuonna 2026 se on vaatimustenmukaisuuden puute.

NIS2 on tehnyt vaiheistetusta poikkeamailmoittamisesta hallinnointivelvoitteen, johon sisältyvät merkittävissä poikkeamissa 24 tunnin kuluessa annettava ennakkovaroitus, 72 tunnin ilmoitus ja loppuraportti yhden kuukauden kuluessa. DORA on luonut finanssialan toimijoille erillisen digitaalisen häiriönsietokyvyn järjestelmän, johon sisältyvät ICT-poikkeamien hallinta, luokittelu, valvontaviranomaisraportointi, ICT-kolmansien osapuolten riski ja kriisiviestintä. GDPR on edelleen olennainen aina, kun henkilötietoja on mukana. ISO/IEC 27001:2022 muuntaa nämä velvoitteet auditoitavaksi hallintajärjestelmän näytöksi.

Viranomais- ja sääntely-yhteystietorekisteri kuulostaa hallinnolliselta. Sitä se ei ole. Se on yhdistävä rakenne tietoturvapoikkeamiin reagoinnin, lakisääteisen ilmoittamisen, liiketoiminnan jatkuvuuden, toimittajakoordinoinnin, johdon vastuun osoittamisen ja auditointinäytön välillä.

Clarysec käsittelee tätä näyttöongelmana, ei paperityönä. Teoksessa Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint Controls in Action -vaiheen vaihe 22 selittää, miksi yhteydenpito viranomaisiin on määriteltävä etukäteen:

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

Tämä on kello 02.17 tapahtuneen poikkeaman todellinen opetus. Sääntelyviranomaisen ilmoitusportaali, CSIRT:n päivystysnumero, tietosuojavastaavan varahenkilö, finanssivalvontaviranomaisen raportointikanava ja toimittajan eskalointireitti on tunnistettava ennen poikkeamaa, ei silloin kun raportointikello jo käy.

Miksi viranomais- ja sääntely-yhteystietorekistereistä tuli vuoden 2026 vaatimustenmukaisuuden painopiste

Monilla organisaatioilla on jo hätäyhteystietoluetteloita. Ongelma on, että NIS2 ja DORA edellyttävät kurinalaisempaa hallintaa kuin nimien ja puhelinnumeroiden luettelo. Ne edellyttävät täsmällistä, roolipohjaista ja näyttövalmista yhteystietojen hallintaa, joka on kytketty oikeudellisiin laukaisukriteereihin, eskalointivaltuuksiin, raportointimääräaikoihin ja toimittajariippuvuuksiin.

NIS2 soveltuu laajaan joukkoon keskeisiä ja tärkeitä toimijoita esimerkiksi energia-, liikenne-, pankki-, finanssimarkkinainfrastruktuuri-, terveydenhuolto-, juomavesi-, jätevesi-, digitaalisen infrastruktuurin, ICT-palvelunhallinnan, julkishallinnon ja avaruussektorin aloilla. Se kattaa myös monia digitaalisia palveluntarjoajia, kuten pilvipalvelut, datakeskuspalvelut, sisällönjakeluverkot, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat, verkkomarkkinapaikat, verkon hakukoneet ja sosiaalisen verkostoitumisen alustat. Jäsenvaltioiden tuli perustaa luettelot keskeisistä ja tärkeistä toimijoista 17. huhtikuuta 2025 mennessä ja päivittää ne vähintään kahden vuoden välein. Monille pilvi-, SaaS-, hallinnoitujen palvelujen ja digitaalisten alustojen tarjoajille sääntelyaltistus on siirtynyt teoriasta operatiiviseksi todellisuudeksi.

DORA:a sovelletaan 17. tammikuuta 2025 alkaen finanssialan toimijoihin, kuten luottolaitoksiin, maksulaitoksiin, sähköisen rahan liikkeeseenlaskijalaitoksiin, sijoituspalveluyrityksiin, kryptovarapalveluntarjoajiin, kaupankäyntijärjestelmiin, arvopaperikeskuksiin, keskusvastapuoliin, vakuutus- ja jälleenvakuutusyrityksiin sekä muihin soveltamisalaan kuuluviin finanssisektorin organisaatioihin. DORA on erittäin olennainen myös ICT-kolmansien osapuolten ekosysteemille, koska finanssialan toimijoiden on hallittava kriittisiä tai tärkeitä toimintoja tukevia palveluntarjoajia. DORA Article 17 edellyttää ICT:hen liittyvien poikkeamien hallintaprosessia, Article 18 asettaa luokitteluodotukset ja Article 19 sääntelee merkittävien ICT:hen liittyvien poikkeamien raportointia toimivaltaiselle viranomaiselle.

GDPR tuo mukaan tietosuojanäkökulman. Kyberturvallisuuspoikkeama voi muuttua henkilötietojen tietoturvaloukkaukseksi, jos siihen liittyy henkilötietojen vahingossa tapahtuva tai lainvastainen tuhoaminen, häviäminen, muuttaminen, luvaton luovuttaminen tai luvaton pääsy henkilötietoihin. Rekisterinpitäjän on pystyttävä osoittamaan osoitusvelvollisuuden toteutuminen, arvioimaan yksilöihin kohdistuva riski ja tarvittaessa ilmoittamaan valvontaviranomaiselle sekä mahdollisesti vaikutuksen kohteena oleville rekisteröidyille.

Kypsän viranomais- ja sääntely-yhteystietorekisterin on siksi vastattava paineen alla viiteen kysymykseen:

• Mikä CSIRT, toimivaltainen viranomainen, finanssivalvontaviranomainen, tietosuojaviranomainen ja lainvalvontaviranomaisen yhteyspiste soveltuu tähän oikeushenkilöön, oikeudenkäyttöalueeseen ja palveluun?
• Mikä sisäinen rooli on valtuutettu käynnistämään yhteydenoton, hyväksymään sanamuodon ja toimittamaan ilmoitukset?
• Mihin toimittajiin on otettava yhteyttä rajaamista, lokeja, palauttamista, näytön säilyttämistä tai sopimusperusteista raportointia varten?
• Mikä asiakas-, vastapuoli- tai julkisen viestinnän reitti aktivoituu kullakin vakavuustasolla?
• Miten osoitamme, että rekisteri on katselmoitu, testattu ja sitä on käytetty oikein?

Vastaus ei voi olla vain lakiasiain sähköpostissa tai tietoturvajohtajan muistissa. Sen on oltava hallittu ISMS-tallenne.

Mitä näyttövalmis NIS2- ja DORA-yhteystietorekisteri sisältää

Viranomais- ja sääntely-yhteystietorekisteri tulee suunnitella käytettäväksi todellisessa poikkeamatilanteessa. Jos poikkeamajohtajan on tehtävä ensimmäinen eskalointipäätös muutamassa minuutissa, rekisteri ei voi olla epämääräinen verkkosivulista. Sen on oltava rakenteinen, varmennettu ja kytketty reagoinnin toimintaohjeisiin.

Täydellisen rekisterin tulee sisältää vähintään kuusi yhteystietoperhettä.

Ensinnäkin viralliset kyberturvallisuusviranomaiset: kansalliset CSIRT:t, toimivaltaiset viranomaiset, soveltuvin osin keskitetyt yhteyspisteet ja toimialakohtaiset kyberturvallisuusviranomaiset.

Toiseksi DORA:n mukaiset finanssivalvontaviranomaiset: toimivaltaiset viranomaiset ja raportointikanavat, joita käytetään merkittävien ICT:hen liittyvien poikkeamien alustavaan raportointiin, väliraportointiin ja loppuraportointiin.

Kolmanneksi tietosuojaviranomaiset: tietosuojaviranomaiset, rajat ylittävän käsittelyn johtavan valvontaviranomaisen logiikka ja tietosuojavastaavan eskalointipolut.

Neljänneksi lainvalvontaviranomaiset: kyberrikosyksiköt, petosyksiköt ja hätäyhteystiedot kiristyksen, kiristyshaittaohjelmien, luvattoman pääsyn ja näytön säilyttämisen varalta.

Viidenneksi toimittajat ja ICT-kolmannet osapuolet: pilvipalveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat, hallinnoidut palveluntarjoajat, identiteettialustat, maksunkäsittelijät, digitaalisen forensiikan palveluntarjoajat ja oikeudellinen neuvonantaja.

Kuudenneksi sisäiset eskalointiroolit: poikkeamajohtaja, tietoturvajohtaja (CISO), tietosuojavastaava (DPO), lakiasiainjohtaja, viestinnästä vastaava henkilö, liiketoiminnan jatkuvuudesta vastaava henkilö, johdon hyväksyjä, hallitusyhteyshenkilö ja palveluomistaja.

Rekisterin tulee sisältää myös erityisryhmät, kuten ISAC-yhteisöt tai toimialakohtaiset tiedonjakoyhteisöt, jos ne ovat olennaisia. Ne eivät ole sääntelyviranomaisia, mutta niistä voi tulla tärkeitä kanavia uhkatiedustelulle ja koordinoidulle reagoinnille.

Zenith Blueprint tekee tästä käytännöllistä vaiheessa 22:

Luo tai päivitä menettelyt viranomaisten kanssa toimimiseen tietoturvatapahtumien aikana (5.5), mukaan lukien paikallisten CERT-toimijoiden, sääntelyviranomaisten ja lainvalvontaviranomaisten yhteystiedot. Ylläpidä vastaavaa yhteystietoluetteloa tietoturvafoorumeihin tai toimialakohtaisiin ryhmiin osallistumista varten (5.6). Säilytä nämä tiedot helposti saatavilla mutta pääsynhallinnan piirissä olevassa sijainnissa ja sisällytä ne tietoturvapoikkeamiin reagoinnin toimintaohjeisiin.

Viimeisellä lauseella on merkitystä. Jos rekisteri ei ole tietoturvapoikkeamiin reagoinnin toimintaohjeissa, sitä ei todennäköisesti käytetä todellisen paineen alla.

Esimerkki yhteystietorekisterin rakenteesta FinTech- tai SaaS-palveluntarjoajalle

Kuvittele fintech-SaaS-palveluntarjoaja, joka tukee maksuanalytiikkaa EU-asiakkaille. Se käyttää pilvipalveluntarjoajaa, hallinnoidun havainnointipalvelun tarjoajaa, identiteettialustaa, asiakastukialustaa ja ulkoista oikeudellista neuvonantajaa. Roolistaan riippuen se voi olla finanssialan toimija, ICT-kolmannen osapuolen palveluntarjoaja, NIS2:n soveltamisalaan kuuluva digitaalinen palveluntarjoaja tai GDPR:n mukainen henkilötietojen käsittelijä.

Käytännöllinen rekisteri voisi alkaa näin:

Merkinnät eivät saa sisältää tarpeettomia henkilötietoja. Käytä roolipohjaisia yhteystietoja aina kun mahdollista, suojaa arkaluonteiset yhteystiedot ja varmista offline-saatavuus merkittävän palvelukatkoksen aikana. Rekisteri, joka on käytettävissä vain samoista järjestelmistä, joihin kiristyshaittaohjelmapoikkeama vaikuttaa, ei ole häiriönsietokykyinen.

Rekisterin kytkeminen ISO/IEC 27001:2022 -näyttöön

Auditoijat harvoin hylkäävät organisaation siksi, ettei sillä ole taulukkolaskentatiedostoa. He hylkäävät sen siksi, ettei organisaatio pysty osoittamaan, että taulukko on kattava, ajantasainen, hyväksytty, suojattu, testattu ja kytketty todellisiin prosesseihin.

ISO/IEC 27001:2022 alkaa organisaation toimintaympäristöstä. Lausekkeet 4.1–4.4 edellyttävät, että organisaatio ymmärtää sisäiset ja ulkoiset seikat, tunnistaa olennaiset sidosryhmät ja niiden vaatimukset, määrittää ISMS:n soveltamisalan sekä ymmärtää rajapinnat ja riippuvuudet. Viranomais- ja sääntely-yhteystietorekisteri on vahvaa näyttöä siitä, että lakisääteiset, sääntelyyn liittyvät, sopimusperusteiset ja sidosryhmävaatimukset on muunnettu operatiivisiksi suhteiksi.

Seuraavaksi tulee johtajuus. Lausekkeet 5.1–5.3 edellyttävät, että ylin johto osoittaa johtajuutta, määrittää vastuut, varmistaa viestinnän ja tukee ISMS:ää. Jos rekisteri tunnistaa, kuka on valtuutettu ilmoittamaan CSIRT:lle, valvontaviranomaiselle tai tietosuojaviranomaiselle, kuka hyväksyy ulkoisen viestinnän ja kuka raportoi poikkeaman tilasta ylimmälle johdolle, se tukee johtajuuteen liittyvää näyttöä.

Riskisuunnittelu muuntaa velvoitteet toiminnaksi. Lausekkeet 6.1.1–6.1.3 edellyttävät riskien arviointi- ja käsittelyprosessia, vertailua liitteeseen A, soveltuvuuslausuntoa, riskienkäsittelysuunnitelmaa ja jäännösriskin hyväksyntää. Rekisterin tulee näkyä riskienkäsittelysuunnitelmassa sellaisille riskeille kuin lakisääteisen ilmoittamisen epäonnistuminen, viivästynyt poikkeamaeskalointi, toimittajan reagoinnin epäonnistuminen, rajat ylittävä ilmoitusvirhe ja liiketoiminnan jatkuvuuden viestintäkatkos.

Liitteen A hallintakeinoankkurit ovat selkeät:

Teoksessa Zenith Controls: The Cross-Compliance Guide Zenith Controls yhteydenpito viranomaisiin käsitellään hallintakeinona 5.5, jolla on ennaltaehkäiseviä ja korjaavia ominaisuuksia. Se tukee luottamuksellisuutta, eheyttä ja saatavuutta sekä yhdistyy kyberturvallisuuden Identify-, Protect-, Respond- ja Recover-käsitteisiin. Zenith Controls kytkee sen poikkeamasuunnitteluun, tapahtumaraportointiin, uhkatiedusteluun, erityisryhmiin ja tietoturvapoikkeamiin reagointiin. Se selittää myös, miksi ennalta määritetyt yhteydet sääntelyviranomaisiin, lainvalvontaviranomaisiin, kansallisiin CERT-toimijoihin tai tietosuojaviranomaisiin mahdollistavat nopeamman eskaloinnin ja ohjauksen merkittävien tietomurtojen tai kiristyshaittaohjelmahyökkäysten kaltaisissa tapahtumissa.

Hallintakeino ei ole erillinen. Zenith Controls kartoittaa myös hallintakeinon 6.8, Tietoturvatapahtumien raportointi, havaitsevaksi kontrolliksi, joka liittyy poikkeamasuunnitteluun, tapahtumien arviointiin, reagointiin, oppeihin, tietoisuuteen, valvontaan ja kurinpitomenettelyyn. Hallintakeino 5.24, Tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu, liittyy tapahtumien arviointiin, oppeihin, lokitukseen, valvontaan, turvallisuuteen häiriön aikana, jatkuvuuteen ja yhteydenpitoon viranomaisiin. Auditointikertomus vahvistuu, kun tapahtumat raportoidaan, arvioidaan, eskaloidaan, viestitään, todennetaan ja parannetaan.

NIS2, DORA ja GDPR: yksi rekisteri, eri oikeudelliset kellot

Yksi poikkeama voi käynnistää useita oikeudellisia työnkulkuja. Luvaton pääsy SaaS-palveluntarjoajalla voi olla NIS2:n mukainen merkittävä poikkeama, GDPR:n mukainen henkilötietojen tietoturvaloukkaus ja sopimusperusteinen asiakasilmoitustapahtuma. Finanssialan toimijan käyttökatko voi olla DORA:n mukainen merkittävä ICT:hen liittyvä poikkeama ja edellyttää samalla GDPR-analyysiä ja toimittajakoordinointia.

NIS2 edellyttää, että keskeiset ja tärkeät toimijat ilmoittavat CSIRT:lleen tai toimivaltaiselle viranomaiselle ilman aiheetonta viivytystä merkittävistä poikkeamista, jotka vaikuttavat palvelun tuottamiseen. Vaiheistettu raportointimalli sisältää ennakkovaroituksen ilman aiheetonta viivytystä ja 24 tunnin kuluessa tiedoksisaannista, poikkeamailmoituksen ilman aiheetonta viivytystä ja 72 tunnin kuluessa, välitilaraportit pyynnöstä sekä loppuraportin yhden kuukauden kuluessa poikkeamailmoituksesta. Jos poikkeama on edelleen käynnissä, myös edistymisraportointi voi olla tarpeen.

DORA edellyttää finanssialan toimijoilta ICT:hen liittyvien poikkeamien hallintaprosessia, joka havaitsee, hallitsee ja ilmoittaa poikkeamat, kirjaa poikkeamat ja merkittävät kyberuhat, luokittelee vakavuuden ja kriittisyyden, osoittaa roolit, määrittää eskaloinnin ja viestinnän, raportoi merkittävät poikkeamat ylemmälle johdolle ja tukee oikea-aikaista palautumista. Merkittävien ICT:hen liittyvien poikkeamien raportointi noudattaa alustavan raportin, väliraportin ja loppuraportin logiikkaa, ja luokittelu perustuu tekijöihin, kuten vaikutuksen kohteena oleviin asiakkaisiin, kestoon, maantieteelliseen levinneisyyteen, tietojen menetykseen, palvelujen kriittisyyteen ja taloudelliseen vaikutukseen.

GDPR lisää henkilötietojen tietoturvaloukkauksen arvioinnin. Yhteystietorekisteri ei yksin ratkaise oikeudellista raportointivelvollisuutta. Se varmistaa, että oikeat henkilöt voivat tehdä päätöksen nopeasti käyttäen ajantasaisia kanavia ja dokumentoituja kriteerejä.

Clarysecin politiikkakirjasto tekee tästä operatiivista. Pk-yrityksille tarkoitetussa Tietoturvapoikkeamien hallintapolitiikassa Tietoturvapoikkeamien hallintapolitiikka - pk-yritys lauseke 5.1.1 toteaa:

Toimitusjohtaja (GM) vastaa kaikkien poikkeamien eskalointipäätösten, sääntelyilmoitusten ja ulkoisen viestinnän valtuuttamisesta.

Saman pk-yrityspolitiikan lauseke 7.4.1 lisää:

Kun asiakasdataa on mukana, toimitusjohtajan on arvioitava oikeudelliset ilmoitusvelvoitteet GDPR:n, NIS2:n tai DORA:n sovellettavuuden perusteella.

Yritysympäristöissä Tietoturvapoikkeamien hallintapolitiikan Tietoturvapoikkeamien hallintapolitiikka lauseke 5.5 määrittää viestintäviitekehyksen:

Kaiken poikkeamiin liittyvän viestinnän on noudatettava viestintä- ja eskalointimatriisia ja varmistettava:

Lauseke 6.4.2 lisää näyttövaatimuksen:

Kaikki loukkausilmoitukset on dokumentoitava ja hyväksyttävä ennen toimittamista, ja kopiot on säilytettävä SIMS-järjestelmässä.

Tässä rekisteristä tulee ISO-näyttöä. Kyse ei ole vain siitä, että tiedetään kenelle soittaa. Kyse on sen osoittamisesta, kuka oli valtuutettu, mitä arvioitiin, mitä hyväksyttiin, mitä toimitettiin ja missä säilytetty kopio sijaitsee.

Clarysecin näyttömalli: neljä artefaktia, jotka toimivat yhdessä

Vahva sääntely-yhteydenottokyvykkyys tarvitsee neljä artefaktia, jotka toimivat yhtenä näyttöketjuna.

Viranomais- ja sääntely-yhteystietorekisteri tunnistaa yhteystiedot, kanavat, laukaisukriteerit ja omistajat. Viestintä- ja eskalointimatriisi määrittää, kuka tekee mitä. Päätösloki kirjaa luokittelun, raportointivelvollisuuden arvioinnin, oikeudellisen tarkastelun ja hyväksynnän. Ilmoitusnäyttöpaketti säilyttää toimitetut ilmoitukset, portaalikuittaukset, sähköpostit, puhelumuistiinpanot, sääntelyviranomaisen palautteen, toimittajien vastaukset ja loppuraportit.

Clarysecin Laki- ja sääntelyvaatimusten noudattamisen politiikka Laki- ja sääntelyvaatimusten noudattamisen politiikka - pk-yritys tekee rekisterikäsitteen nimenomaiseksi. Lauseke 5.5.2 toteaa:

Keskeiset vaatimustenmukaisuusehdot (esimerkiksi loukkauksista ilmoittamisen määräajat ja tietojen käsittelylausekkeet) on poimittava ja seurattava vaatimustenmukaisuusrekisterissä.

Vaatimustenmukaisuusrekisterin tulee syöttää viranomais- ja sääntely-yhteystietorekisteriä. Oikeudellinen vaatimus voi sanoa ”NIS2-ennakkovaroitus 24 tunnin kuluessa”, kun taas yhteystietorekisteri tunnistaa kansallisen CSIRT-portaalin, varalla olevan päivystysnumeron, valtuutetun ilmoituksen tekijän, oikeudellisen tarkastajan, vaadittavan näytön ja säilytyspolun.

Liiketoiminnan jatkuvuuspolitiikat vahvistavat saman odotuksen. Pk-yritysten Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka - pk-yritys lauseke 5.2.1.1 viittaa:

yhteystietoluetteloihin ja vaihtoehtoisiin viestintäsuunnitelmiin

Yritysten Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikan Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka lauseke 5.3.3 edellyttää, että jatkuvuusjärjestelyjä:

tuetaan ajantasaisilla yhteystietoluetteloilla ja eskalointivirroilla

Myös toimittajien hallinta kuuluu malliin. Pk-yritysten Kolmansien osapuolten ja toimittajien tietoturvapolitiikassa Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys lauseke 5.4.3 edellyttää:

nimettyä yhteyshenkilöä

NIS2:n ja DORA:n kannalta tämä yhteyshenkilö ei voi olla yleisluonteinen. Jos kriittinen pilvipalveluntarjoaja, hallinnoitu tietoturvapalveluntarjoaja, identiteetin tarjoaja tai maksunkäsittelijä tukee säänneltyä palvelua, rekisterin tulee tunnistaa operatiivinen yhteyshenkilö, tietoturvapoikkeaman yhteyspiste, sopimusperusteinen ilmoituskanava ja eskalointireitti näyttöpyyntöjä varten.

Rakenna rekisteri yhdessä työpajassa

Hyödyllinen rekisteri voidaan rakentaa nopeasti, jos oikeat henkilöt ovat samassa tilassa. Varaa kahden tunnin työpaja, johon osallistuvat tietoturvajohtaja (CISO), tietosuojavastaava (DPO), oikeudellinen neuvonantaja, toimittajahallinnasta vastaava henkilö, liiketoiminnan jatkuvuudesta vastaava henkilö, poikkeamajohtaja ja vaatimustenmukaisuudesta vastaava henkilö.

Aloita vaatimustenmukaisuusrekisteristä. Poimi NIS2-, DORA-, GDPR-, sopimus- ja toimialakohtaiset raportointivelvoitteet. Kirjaa määräajat, raportointivelvollisuuden kriteerit ja näyttövaatimukset.

Avaa tietoturvapoikkeamiin reagoinnin toimintaohjeet. Tunnista tarvittavat ulkoiset yhteystiedot kullekin poikkeamaluokalle, kuten kiristyshaittaohjelma, luvaton pääsy, palvelukatkos, tietojen luvaton siirto, toimittajapoikkeama ja pilvialueen vika.

Täytä viranomais- ja sääntely-yhteystietorekisteriin viranomainen, oikeudenkäyttöalue, laukaisuehto, ensisijainen kanava, varakanava, omistaja, hyväksyjä, tarvittava näyttö, viimeisin validointipäivä ja säilytyssijainti.

Kytke toimittajien yhteystiedot. Tunnista kullekin kriittiselle tai tärkeälle toiminnolle palveluntarjoajan tietoturvapoikkeaman yhteyspiste, sopimusperusteinen ilmoituskanava, auditointiyhteyshenkilö ja hätäeskalointipolku.

Katselmoi suhteessa politiikkoihin. Varmista, että eskalointivaltuudet vastaavat Tietoturvapoikkeamien hallintapolitiikkaa, ilmoitusnäyttö säilytetään SIMS-järjestelmässä, liiketoiminnan jatkuvuuden yhteystietoluettelot ovat yhdenmukaisia ja toimittajayhteystiedoilla on nimetyt omistajat.

Testaa yksi skenaario. Käytä kohdennettua pöytäharjoitusta: ”Asiakasdatan altistuminen havaittu kello 02.17, vaikutus EU-asiakkaisiin ja mahdollinen syy vaarantuneet identiteetin tarjoajan tunnistetiedot.” Pyydä tiimiä tunnistamaan, voivatko CSIRT-, tietosuojaviranomais-, finanssivalvontaviranomais-, toimittaja- ja asiakasilmoitukset olla tarpeen. Tavoitteena ei ole pakottaa lopullista oikeudellista johtopäätöstä harjoituksen aikana. Tavoitteena on osoittaa, mistä yhteystiedot löytyvät, kuka hyväksyy yhteydenoton, mitä näyttöä tarvitaan ja minne päätökset kirjataan lokiin.

Luo näyttöpaketti. Tallenna rekisteriversio, osallistujat, hyväksynnät, skenaariomuistiinpanot, päätösloki, toimenpiteet ja päivitetty toimintaohjeviite.

Tässä Zenith Blueprint -teoksen vaihe 23 muuttuu käytännölliseksi:

Varmista, että käytössäsi on ajantasainen tietoturvapoikkeamiin reagointisuunnitelma (5.24), joka kattaa valmistelun, eskaloinnin, reagoinnin ja viestinnän. Määritä, mikä muodostaa raportoitavan tietoturvatapahtuman (5.25) ja miten päätöksentekoprosessi käynnistetään ja dokumentoidaan. Valitse äskettäinen tapahtuma tai toteuta pöytäharjoitus suunnitelman validoimiseksi.

Harjoituksen ei tarvitse olla monimutkainen. Sen on osoitettava valmius.

Vaatimustenmukaisuuden ristiinkartoitus: yksi rekisteri, monta viitekehystä

Viranomais- ja sääntely-yhteystietorekisterin arvo on siinä, että se vähentää päällekkäistä vaatimustenmukaisuustyötä. Yksi näyttövalmis artefakti voi tukea ISO/IEC 27001:2022:n, NIS2:n, DORA:n, GDPR:n, NIST CSF 2.0:n ja COBIT 2019:n hallinnointiodotuksia.

NIST CSF 2.0 on erityisen hyödyllinen integraatiokerroksena. Sen GOVERN-toiminto edellyttää, että organisaatiot ymmärtävät sidosryhmät, lakisääteiset ja sääntelyvelvoitteet, kriittiset palvelut, riippuvuudet, riskinottohalukkuuden, roolit, politiikat, valvonnan ja toimittajariskin. Sen CSF-profiilit auttavat organisaatioita dokumentoimaan nykyprofiilin, määrittämään tavoiteprofiilin, analysoimaan puutteet ja laatimaan priorisoidun toimintasuunnitelman. Viranomais- ja sääntely-yhteystietorekisteri voi olla konkreettista näyttöä, joka sulkee nykytilan ja tavoitetilan välisen poikkeaman poikkeamien hallinnointimallissa.

Toimitusketjun osalta NIST CSF 2.0 edellyttää, että toimittajilla, asiakkailla ja kumppaneilla on määritellyt kyberturvallisuusroolit ja -vastuut, toimittajien kriittisyys tunnetaan, kyberturvallisuusvaatimukset sisällytetään sopimuksiin, toimittajariskit arvioidaan ja olennaiset toimittajat sisällytetään poikkeamasuunnitteluun, reagointiin ja palautumiseen. Tämä kytkeytyy suoraan DORA:n ICT-kolmansien osapuolten riskiin ja NIS2:n toimitusketjuodotuksiin.

Miten auditoijat ja valvontaviranomaiset testaavat samaa rekisteriä

Hyvin ylläpidettyä rekisteriä tarkastellaan eri tavalla arvioijan näkökulmasta riippuen.

ISO/IEC 27001:2022 -auditoija aloittaa soveltamisalasta ja olennaisista sidosryhmistä. Hän kysyy, miten organisaatio tunnisti sovellettavat viranomaiset, oikeudelliset velvoitteet, sopimusperusteiset ilmoitusvelvoitteet ja ulkoistetut riippuvuudet. Sen jälkeen hän jäljittää rekisterin soveltuvuuslausuntoon, tietoturvapoikkeamiin reagointisuunnitelmaan, liiketoiminnan jatkuvuussuunnitelmaan ja näytön säilyttämiseen. Hän voi ottaa yhden yhteystiedon otokseen ja pyytää näyttöä viimeisimmästä validoinnista.

NIS2-arvioija keskittyy siihen, onko toimija tunnistanut oikean CSIRT:n tai toimivaltaisen viranomaisen ja onko merkittävän poikkeaman kynnysarvot muutettu operatiivisiksi. Hän etsii prosessia, joka pystyy tukemaan 24 tunnin ennakkovaroitusta, 72 tunnin ilmoitusta ja loppuraportointia. Hän tarkastelee myös johtoryhmän valvontaa, koska NIS2 Article 20 tekee kyberturvallisuuden hallinnasta johdon vastuun.

DORA-valvontaviranomainen tai sisäinen tarkastusryhmä testaa, tukeeko rekisteri poikkeamien hallintaa, luokittelua, merkittävien ICT:hen liittyvien poikkeamien raportointia, kriisiviestintää, ylemmälle johdolle raportointia, toimittajakoordinointia ja operatiivista palautumista. He voivat kysyä, onko kriittisiä tai tärkeitä toimintoja tukeville ICT-kolmannen osapuolen palveluntarjoajille yhteystiedot ja näkyvätkö viestintävelvoitteet sopimuksissa.

GDPR-auditoija tai tietosuojavastaavan katselmointi keskittyy henkilötietojen tietoturvaloukkauksen arviointiin. He kysyvät, ovatko tietosuojavastaava ja tietosuojan oikeudelliset yhteyshenkilöt mukana varhaisessa vaiheessa, ovatko rekisterinpitäjän ja käsittelijän roolit selviä, onko oikea valvontaviranomainen tunnistettu ja kirjataanko rekisteröityjen viestintäpäätökset.

NIST CSF -arvioija käsittelee rekisteriä näyttönä GOVERN-tuloksista: sidosryhmien odotuksista, oikeudellisista velvoitteista, rooleista, politiikoista, valvonnasta ja toimitusketjuriskistä. COBIT 2019- tai ISACA-tyylinen auditoija tarkastelee, onko sidosryhmien tarpeet muunnettu hallinnointi- ja johtamiskäytännöiksi, onko vastuut osoitettu ja seurataanko prosessin suorituskykyä.

Saman artefaktin on kestettävä kaikki nämä kysymykset. Siksi rekisterin tulee olla hallittu, omistettu, katselmoitu, pääsynhallittu ja testattu.

Yleiset epäonnistumismallit yhteystietojen hallinnassa

Organisaatiot harvoin epäonnistuvat siksi, ettei niillä ole lainkaan yhteystietoja. Ne epäonnistuvat siksi, ettei yhteystietoihin voi luottaa todellisessa poikkeamassa.

Jokainen ongelma luo ennakoitavan auditointihavainnon. Korjaavat toimenpiteet ovat yhtä ennakoitavia: yhdenmukaista rekisteri politiikan kanssa, integroi se tietoturvapoikkeamiin reagointiin, validoi yhteystiedot, testaa työnkulku ja säilytä näyttö.

Hallituksen ja johdon vastuun osoitettavuus

NIS2 edellyttää, että johtoryhmät hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat toteutusta ja osallistuvat koulutukseen. DORA Article 5 tekee johtoryhmästä vastuullisen ICT-riskijärjestelyjen määrittelystä, hyväksymisestä, valvonnasta ja vastuun kantamisesta, mukaan lukien politiikat, roolit, ICT-liiketoiminnan jatkuvuus, reagointi- ja palautussuunnitelmat, ICT-kolmansia osapuolia koskeva politiikka, tietoisuus ja koulutus. ISO/IEC 27001:2022 edellyttää, että johto yhdenmukaistaa ISMS:n strategisen suunnan kanssa, tarjoaa resurssit, osoittaa vastuut ja tukee jatkuvaa parantamista.

Hallituksen ei tarvitse opetella CSIRT:n puhelinnumeroa ulkoa. Sen tarvitsee saada varmuus siitä, että ilmoitusvalmius on olemassa, sillä on omistaja, se on testattu ja se katselmoidaan.

Neljännesvuosittaisen johdon raportointipaketin tulee sisältää:

• Viranomais- ja sääntely-yhteystietorekisterin katselmoinnin tila
• Muutokset sovellettavissa viranomaisissa, valvontaviranomaisissa tai oikeudenkäyttöalueissa
• Avoimet puutteet toimittajien poikkeamayhteystiedoissa
• Pöytäharjoitusten tulokset ja opit
• Näyttö ilmoitusten hyväksyntätyönkulun testauksesta
• Mittarit havaitsemisesta eskalointipäätökseen kuluneesta ajasta
• Päivitykset NIS2-, DORA-, GDPR- ja sopimusperusteisiin raportointivelvoitteisiin
• Johdon hyväksyntää edellyttävät jäännösriskit

Tämä siirtää rekisterin operatiivisesta taulukosta hallinnointikontrolliksi.

Miten Clarysec auttaa rakentamaan auditointivalmista yhteystietojen hallintaa

Clarysec yhdistää politiikkatekstin, toteutusjärjestyksen ja viitekehysten välisen kontrollikartoituksen yhdeksi näyttöpoluksi.

Politiikkakirjasto määrittää vastuun osoitettavuuden ja vaadittavat tallenteet. Tietoturvapoikkeamien hallintapolitiikka asettaa odotukset eskaloinnille, ilmoitusten hyväksynnälle ja säilytykselle. Laki- ja sääntelyvaatimusten noudattamisen politiikka edellyttää, että vaatimustenmukaisuusehtoja, kuten loukkauksista ilmoittamisen määräaikoja, seurataan. Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka edellyttää ajantasaisia yhteystietoluetteloita ja vaihtoehtoisia viestintäsuunnitelmia. Kolmansien osapuolten ja toimittajien tietoturvapolitiikka edellyttää nimettyjä toimittajayhteyshenkilöitä.

Zenith Blueprint antaa toteutusjärjestyksen. ISMS Foundation & Leadership -vaiheen vaihe 5 käsittelee viestintää, tietoisuutta ja pätevyyttä, mukaan lukien ulkoiset sidosryhmät, ajoitus, viestijäroolit ja viestintäsuunnitelmat. Vaihe 22 rakentaa viranomais- ja erityisryhmäyhteydet organisatorisiin kontrolleihin. Vaihe 23 validoi poikkeamien hallinnan, raportoitavia tapahtumia koskevat päätökset, forensisen todistusaineiston säilyttämisen ja opit.

Zenith Controls -opas antaa vaatimustenmukaisuuden ristiinkartoituksen kompassin. Se osoittaa, miten yhteydenpito viranomaisiin liittyy poikkeamasuunnitteluun, tapahtumaraportointiin, uhkatiedusteluun, erityisryhmiin ja tietoturvapoikkeamiin reagointiin. Se osoittaa myös, miksi tietoturvatapahtumien raportointi ja poikkeamiin valmistautuminen ovat välttämättömiä kumppaneita. Yhteystietorekisteri on tehokas vain, jos tapahtumat raportoidaan ja arvioidaan riittävän aikaisin sen käynnistämiseksi.

Pk-yrityksille tämä tarkoittaa kevyttä mutta puolustettavaa rekisteriä, selkeää vastuun osoitettavuutta ja suhteellisuusperiaatteeseen sopivaa näyttöä. Suuryrityksille se tarkoittaa integraatiota oikeudenkäyttöalueiden, oikeushenkilöiden, liiketoimintayksiköiden, toimittajien, sääntelyviranomaisten, valvontaviranomaisten, CSIRT-toimijoiden ja hallitusraportoinnin välillä.

Seuraavat askeleet: rakenna rekisteri ennen kuin kello käynnistyy

Jos organisaatiosi valmistautuu NIS2:een, DORA:an, GDPR-loukkausilmoitusten valmiuteen tai ISO/IEC 27001:2022 -sertifiointiin, älä odota elävää poikkeamaa saadaksesi selville, toimiiko yhteystietojen hallinta.

Aloita tällä viikolla neljällä toimenpiteellä:

1. Luo tai päivitä viranomais- ja sääntely-yhteystietorekisteri CSIRT-toimijoille, toimivaltaisille viranomaisille, finanssivalvontaviranomaisille, tietosuojaviranomaisille, lainvalvontaviranomaisille, kriittisille toimittajille ja sisäisille eskalointirooleille.
2. Kartoita jokainen yhteystieto laukaisuehtoon, omistajaan, hyväksyntäpolkuun, näyttövaatimukseen ja säilytyssijaintiin.
3. Toteuta yksi pöytäharjoitus, joka keskittyy ilmoituspäätöksiin, viranomaisyhteydenottoon, toimittajakoordinointiin ja näytön säilyttämiseen.
4. Päivitä ISMS-tallenteet, mukaan lukien vaatimustenmukaisuusrekisteri, tietoturvapoikkeamiin reagoinnin toimintaohjeet, liiketoiminnan jatkuvuuden yhteystietoluettelot ja toimittajayhteystietojen tallenteet.

Clarysec voi auttaa toteuttamaan tämän nopeasti käyttämällä Zenith Blueprint Zenith Blueprint-, Zenith Controls Zenith Controls -materiaaleja sekä pk-yritysten ja yritysten politiikkakirjastoja, mukaan lukien Tietoturvapoikkeamien hallintapolitiikka Tietoturvapoikkeamien hallintapolitiikka, Laki- ja sääntelyvaatimusten noudattamisen politiikka Laki- ja sääntelyvaatimusten noudattamisen politiikka - pk-yritys, Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka ja Kolmansien osapuolten ja toimittajien tietoturvapolitiikka Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys.

24 tunnin kello ei pysähdy siksi aikaa, kun tiimisi etsii oikeaa yhteystietoa. Rakenna rekisteri nyt, testaa se ja tee siitä osa ISO-näyttöäsi ennen kuin seuraava poikkeama päättää aikataulun puolestasi.