ISO 27001 NIS2- ja DORA-näytön kontrollikehikkona

Maanantaiaamun vaatimustenmukaisuuden yhteentörmäys
Maanantaina klo 08.12 eurooppalaisen maksunkäsittelijän tietoturvajohtaja Maria saa kolme viestiä, jotka näyttävät toisistaan riippumattomilta.
Sisäisen tarkastuksen päällikkö pyytää näyttöä siitä, että ISO 27001:2022 -soveltuvuuslausunto on ajan tasalla. Lakitiimi välittää pankkikumppanin kyselyn DORA:n mukaisesta ICT-kolmansien osapuolten riskien valvonnasta. Operatiivinen johtaja kysyy, voidaanko samaa poikkeamatilanteiden pelikirjaa käyttää vastikään hankitun EU-liiketoimintayksikön NIS2-ilmoitusodotusten tukena.
Klo 09.00 Marian toimiston valkotaulu on täynnä lyhenteitä: ISO 27001, NIS2, DORA, GDPR, NIST, COBIT 2019. Organisaatiolla on kontrolleja. Sillä on pääsynhallinta, varmuuskopiot, toimittajakyselyt, salaus, tietoturvapoikkeamiin reagointi, politiikkojen hyväksynnät, johdon katselmukset ja koulutustallenteet. Siltä puuttuu yksi auditointivalmis näyttökehikko, joka selittää, miksi kontrollit ovat olemassa, mitä riskejä ne käsittelevät, mitä sääntelyä ne tukevat, kuka ne omistaa ja missä todentava aineisto sijaitsee.
Tämä ongelma yleistyy Euroopassa. NIS2 painottaa kyberturvallisuuden riskienhallintaa, hallinnointia, poikkeamien käsittelyä ja toimitusketjun häiriönsietokykyä. DORA lisää yksityiskohtaisia vaatimuksia finanssialan toimijoiden ICT-riskien hallintaan, häiriönsietokyvyn testaukseen, poikkeamien raportointiin ja ICT-kolmansien osapuolten valvontaan. GDPR edellyttää edelleen osoitusvelvollisuutta, käsittelyn turvallisuutta, henkilötietojen käsittelijöiden hallintaa ja henkilötietojen tietoturvaloukkausten arviointia.
Väärä ratkaisu on rakentaa kolme rinnakkaista vaatimustenmukaisuusohjelmaa. Se tuottaa päällekkäisiä kontrolleja, epäyhtenäistä näyttöä ja kuormittuneita tiimejä.
Vahvempi ratkaisu on käyttää ISO 27001:2022 -standardia kontrollikehikkona. Ei seinällä olevana sertifikaattina, vaan riskien, politiikkojen, toimittajahallinnan, tietoturvapoikkeamiin reagoinnin, vaatimustenmukaisuuskartoituksen ja auditointinäytön käyttöjärjestelmänä.
Clarysecin käytännön malli on yksinkertainen: käytä ISO 27001:2022 -standardin mukaista tietoturvallisuuden hallintajärjestelmää (ISMS) organisointijärjestelmänä, soveltuvuuslausuntoa siltana, politiikkoja velvoittavina operatiivisina sääntöinä ja Zenith Controls: vaatimustenmukaisuuden ristiinkartoituksen opas -ratkaisua ristiinkartoituksen kompassina. Rakenna kerran, kartoita huolellisesti ja osoita jatkuvasti.
Miksi ISO 27001:2022 toimii vaatimustenmukaisuuden kehikkona
NIS2:lla ja DORA:lla on erilaiset soveltamisalat, oikeudelliset mekanismit ja valvontamallit. NIS2 koskee keskeisiä ja tärkeitä toimijoita eri toimialoilla. DORA koskee finanssialan toimijoita ja luo yksityiskohtaiset vaatimukset digitaaliseen operatiiviseen häiriönsietokykyyn. GDPR keskittyy henkilötietojen käsittelyyn ja osoitusvelvollisuuteen.
Näiden viitekehysten taustalla olevat operatiiviset kysymykset ovat kuitenkin päällekkäisiä:
- Ohjataanko kyberturvallisuutta johdon hyväksymillä politiikoilla?
- Tunnistetaanko, arvioidaanko ja käsitelläänkö tietoturva- ja ICT-riskit?
- Valitaanko kontrollit riskin, liiketoimintaympäristön ja lakisääteisten velvoitteiden perusteella?
- Hallitaanko toimittajia due diligence -arviointien, sopimusten, seurannan ja irtautumiskontrollien avulla?
- Osaako henkilöstö tunnistaa tietoturvatapahtamat ja ilmoittaa niistä ajoissa?
- Voidaanko poikkeamat luokitella, priorisoida, eskaloida, tutkia ja arvioida sääntelyyn perustuvaa ilmoittamista varten?
- Voiko organisaatio hakea näytön nopeasti auditoinnin, asiakaskatselmoinnin tai viranomaistiedustelun aikana?
ISO 27001:2022 antaa johdolle hallintajärjestelmän näihin kysymyksiin vastaamiseksi yhdenmukaisesti. ISO/IEC 27007:2022 käsittelee soveltuvuuslausuntoa auditoitavissa olevana luettelona valituista tietoturvakontrolleista, mukaan lukien ISO 27001:2022 -standardin liitteen A kontrollit, muiden standardien kontrollit tai organisaatiokohtaiset toimenpiteet, sekä dokumentoidut perustelut sisällyttämiselle tai poissulkemiselle. ISO/IEC 27006-1:2024 vahvistaa, että SoA ja siihen liittyvä ISMS-dokumentaatio muodostavat keskeisen näyttöpohjan sen osoittamiseksi, mitä kontrolleja vaaditaan, miten vastuut on osoitettu ja miten politiikat on toteutettu ja viestitty.
Tämän vuoksi SoA on paljon enemmän kuin laskentataulukko. Siitä tulee kontrollisopimus riskienhallinnan, vaatimustenmukaisuuden, operatiivisen toiminnan, lakiasioiden, hankinnan, auditoinnin ja hallituksen välillä.
Clarysecin [P01] Tietoturvapolitiikka ankkuroi tämän hallinnointivaatimuksen:
Organisaation tulee ottaa käyttöön ja ylläpitää Information Security Management System (ISMS) ISO/IEC 27001:2022 Clauses 4 through 10 -vaatimusten mukaisesti.
Kohdasta “Politiikan toteutusvaatimukset”, politiikkalauseke 6.1.1.
Tällä on merkitystä, koska NIS2- ja DORA-näyttöpyynnöt eivät yleensä tule ISO-kielellä. Sääntelyviranomainen, asiakas tai hallituksen valiokunta voi pyytää näyttöä kyberturvallisuuden riskienhallinnasta, ICT-hallinnosta, kolmansien osapuolten riippuvuuksien valvonnasta, poikkeamien eskaloinnista tai operatiivisen häiriönsietokyvyn testauksesta. ISO 27001:2022 -standardin mukainen ISMS antaa näille vastauksille rakenteen.
SoA on silta, ei paperiharjoitus
Zenith Blueprint: auditoijan 30 vaiheen tiekartta -oppaassa, riskienhallintavaiheen vaiheessa 13, Clarysec määrittää SoA:n keskeiseksi jäljitettävyysmekanismiksi riskien käsittelyn ja toteutettujen kontrollien välillä:
SoA on käytännössä sillan muodostava asiakirja: se yhdistää riskien arvioinnin ja riskien käsittelyn tosiasiallisiin kontrolleihin.
Tämä lause on vaatimusten ristiinkartoituksen ydin. Kontrolli ilman jäljitettävyyttä jää irralliseksi artefaktiksi. Kontrolli, joka on yhdistetty riskiin, lakisääteiseen velvoitteeseen, politiikkaan, omistajaan, näyttötallenteeseen ja testitulokseen, on auditointivalmis.
Vaihe 13 suosittelee myös lisäämään kontrolliviittaukset riskiskenaarioihin, esimerkiksi yhdistämään asiakastietokannan tietoturvaloukkauksen skenaarion pääsynhallintaan, kryptografiaan, haavoittuvuuksien hallintaan, tietoturvapoikkeamiin reagointiin ja toimittajakontrolleihin. Lisäksi se suosittelee merkitsemään, milloin kontrollit tukevat ulkoisia vaatimuksia, kuten GDPR, NIS2 tai DORA.
Clarysecin [P06] Riskienhallintapolitiikka tekee tästä operatiivisesta säännöstä nimenomaisen:
Riskien käsittelyprosessista johtuvat kontrollipäätökset tulee kuvata SoA:ssa.
Kohdasta “Politiikan toteutusvaatimukset”, politiikkalauseke 6.5.1.
Pienemmille organisaatioille Riskienhallintapolitiikka – pk-yritys käyttää samaa logiikkaa:
Se varmistaa, että riskienhallinta on aktiivinen osa suunnittelua, projektien toteutusta, toimittajavalintaa ja tietoturvapoikkeamiin reagointia yhdenmukaisesti ISO 27001-, ISO 31000- ja sovellettavien sääntelyvaatimusten kanssa.
Kohdasta “Tarkoitus”, politiikkalauseke 1.2.
Jos DORA:n kolmannen osapuolen riskien käsittely, NIS2:n poikkeamien käsittelytoimenpide tai GDPR:n käsittelijän turvallisuusvaatimus ei näy SoA:ssa tai siihen liittyvässä vaatimustenmukaisuusrekisterissä, organisaatio saattaa silti tehdä tarvittavan työn. Sen on kuitenkin vaikea osoittaa työ johdonmukaisesti.
Käytännön ISO 27001:2022 -ristiinkartoitus NIS2:lle ja DORA:lle
Seuraava ristiinkartoitus ei ole oikeudellista neuvontaa. Se on käytännön näyttömalli tietoturvajohtajille, vaatimustenmukaisuudesta vastaaville johtajille, sisäisille auditoijille ja liiketoimintavastaaville, joiden on sovitettava ISO 27001:2022 -näyttö NIS2- ja DORA-odotuksiin.
ENISA on yhdessä Euroopan komission ja NIS-yhteistyöryhmän kanssa toimittanut neuvoa-antavaa ristiinviittausohjeistusta, joka auttaa sovittamaan EU:n kyberturvallisuusvaatimuksia kansainvälisiin ja kansallisiin standardeihin, mukaan lukien ISO 27001. Ohjeistus ei ole oikeudellisesti sitova, ja sitä on täydennettävä kansallisten viranomaisten ohjeilla, toimialasäännöillä ja oikeudellisella arviolla. Se tukee kuitenkin puolustettavissa olevaa kartoitustapaa.
| Vaatimustenmukaisuuskysymys | ISO 27001:2022 -kehikon näyttö | NIS2-relevanssi | DORA-relevanssi | Clarysecin näyttöartefakti |
|---|---|---|---|---|
| Ohjataanko kyberturvallisuutta johdon hyväksymillä politiikoilla? | Tietoturvapolitiikka, ISMS:n soveltamisala, roolit, johdon katselmuksen tallenteet, SoA | Kyberturvallisuuden riskienhallinnan ja hallinnoinnin odotukset | ICT-hallinto ja ICT-riskienhallinnan viitekehys | Tietoturvapolitiikka, SoA, johdon katselmointiaineisto |
| Arvioidaanko ja käsitelläänkö riskit? | Riskirekisteri, riskienkäsittelysuunnitelma, SoA-perustelut, jäännösriskin hyväksynnät | Riskiperusteiset kyberturvallisuustoimenpiteet Article 21:n mukaisesti | ICT-riskien tunnistaminen, suojaaminen, ennaltaehkäisy, havaitseminen, reagointi ja toipuminen | Riskirekisteri, riskienkäsittelysuunnitelma, SoA_Builder.xlsx |
| Hallitaanko toimittajia? | Toimittajapolitiikka, due diligence -tallenteet, sopimukset, auditointioikeudet, tietoturvaloukkauksista ilmoittamisen lausekkeet | Toimitusketjun kyberturvallisuus Article 21(2)(d):n mukaisesti | ICT-kolmansien osapuolten riskienhallinta Articles 28 to 30:n mukaisesti | Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka, toimittajarekisteri |
| Havaitaanko, eskaloidaanko ja raportoidaanko poikkeamat? | Tietoturvapoikkeamiin reagointisuunnitelma, raportointikanava, luokittelu- ja priorisointitallenteet, pöytäharjoitustestit, opit | Merkittävien poikkeamien käsittely ja raportointi Article 23:n mukaisesti | ICT:hen liittyvien poikkeamien hallinta ja raportointi Articles 17 to 19:n mukaisesti | Tietoturvapoikkeamien hallintapolitiikka, poikkeamatiketit, harjoitusraportti |
| Onko näyttö keskitetty ja auditoitavissa? | Sisäisen auditoinnin ohjelma, näyttötietovarasto, vaatimustenmukaisuusrekisteri, korjaavat toimenpiteet | Valmius esittää näyttö valvontaa varten | Valmius sääntely- ja valvontatarkastuksiin | Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka, keskitetty auditointikansio |
Ristiinkartoitus toimii, koska se ei luo erillisiä kontrolleja jokaiselle sääntelylle. Se käyttää ISO 27001:2022 -standardia kontrollikehikkona ja lisää sääntelytunnisteet, omistajuuden ja näyttöodotukset.
Kolme ISO 27001:2022 -kontrollia, jotka avaavat kehikon
Useat kontrollit ovat tärkeitä NIS2:n ja DORA:n kannalta, mutta kolme ISO/IEC 27002:2022 -kontrollia muodostaa usein näyttömallin selkärangan: 5.1, 5.19 ja 5.24. Neljäs kontrolli, 6.8, ratkaisee usein, toimiiko poikkeamien raportointi käytännössä.
| ISO/IEC 27002:2022 -kontrolli | Miksi sillä on merkitystä | Ristiinkartoituksen arvo |
|---|---|---|
| 5.1 Tietoturvapolitiikat | Määrittää johdon hyväksymän tietoturvan suunnan ja vastuun osoitettavuuden | Tukee NIS2-hallinnointia, DORA:n ICT-hallintoa, GDPR-osoitusvelvollisuutta ja ISO 27001 -politiikkanäyttöä |
| 5.19 Tietoturva toimittajasuhteissa | Määrittää toimittajaturvallisuuden odotukset toimittajien käyttöönotossa, seurannassa ja suhteenhallinnassa | Tukee NIS2:n toimitusketjun kyberturvallisuutta, DORA:n ICT-kolmansien osapuolten riskejä ja GDPR-käsittelijöiden valvontaa |
| 5.24 Tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu | Luo poikkeamien hallinnan viitekehyksen, roolit, eskalointipolut ja valmiustoimet | Tukee NIS2:n poikkeamien käsittelyä, DORA:n ICT:hen liittyvien poikkeamien raportointia ja GDPR:n tietoturvaloukkausten arviointia |
| 6.8 Tietoturvatapahtumien raportointi | Varmistaa, että henkilöstö voi ilmoittaa epäillyistä tapahtumista nopeasti selkeiden kanavien kautta | Tukee varhaista havaitsemista, eskalointia, ilmoitusarviointia ja poikkeamanäytön laatua |
Zenith Controls kuvaa ISO/IEC 27002:2022 -kontrollin 5.1, Tietoturvapolitiikat, ennaltaehkäisevänä kontrollina, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta ja jonka keskeisiä operatiivisia kyvykkyyksiä ovat hallinnointi ja politiikkojen hallinta. Ristiinkartoitus selittää, että GDPR Articles 5(2), 24 ja 32 edellyttävät osoitusvelvollisuutta, vastuuta ja käsittelyn turvallisuutta. Se kartoittaa saman kontrollin myös NIS2:n kyberturvallisuuden riskienhallinnan ja hallinnoinnin odotuksiin sekä DORA:n ICT-hallinnon ja riskienhallinnan viitekehysvaatimuksiin.
Siksi tietoturvapolitiikka ei ole vain yksi politiikka muiden joukossa. NIS2-arvioija voi lukea sen hallinnointinäyttönä. DORA-valvoja voi lukea sen ICT-riskien viitekehyksen näyttönä. GDPR-arvioija voi lukea sen osoitusvelvollisuuden näyttönä. ISO 27001:2022 -auditoija voi lukea sen osaksi ISMS-politiikkarakennetta.
Kontrolli 5.19, Tietoturva toimittajasuhteissa, on kohta, jossa hankinta, lakiasiat, tietoturva, tietosuoja ja häiriönsietokyky kohtaavat. Zenith Controls kartoittaa sen GDPR-käsittelijävelvoitteisiin, NIS2:n toimitusketjun kyberturvallisuuteen ja DORA:n ICT-kolmansien osapuolten riskienhallintaan. DORA:n osalta näyttö vahvistuu entisestään, kun sitä tukevat kontrollit 5.20, Tietoturvan käsittely toimittajasopimuksissa, 5.21, Tietoturvan hallinta ICT-toimitusketjussa, ja 5.23, Tietoturva pilvipalvelujen käytössä.
Kontrolli 5.24, Tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu, on poikkeamavalmiuden operatiivinen moottori. Zenith Controls kartoittaa sen NIS2:n poikkeamien käsittelyyn ja ilmoittamiseen, GDPR:n henkilötietojen tietoturvaloukkauksista ilmoittamiseen sekä DORA:n ICT:hen liittyvien poikkeamien hallintaan ja raportointiin. Sen näyttö ei ole pelkkä tietoturvapoikkeamiin reagoinnin politiikka. Siihen sisältyvät raportointikanavat, luokittelu- ja priorisointikriteerit, eskalointitallenteet, oikeudelliset ilmoitusarvioinnit, pöytäharjoitukset, poikkeamatiketit ja opit.
Kontrolli 6.8, Tietoturvatapahtumien raportointi, kuroo umpeen kuilun kirjallisen suunnitelman ja ihmisten käyttäytymisen välillä. Jos henkilöstö ei tiedä, miten epäillystä tietojenkalastelusta, tietovuodosta, toimittajakatkoksesta tai epäilyttävästä järjestelmätoiminnasta ilmoitetaan, organisaatio voi menettää kriittistä aikaa ennen kuin oikeudelliset tai sääntelyyn perustuvat raportointiarvioinnit edes alkavat.
Yksi toimittajapoikkeama, yksi koordinoitu näyttöketju
Kuvitellaan, että Marian maksunkäsittelijän käyttämä pilvipohjainen analytiikkapalveluntarjoaja havaitsee luvattoman pääsyn tukipolkuun. Palveluntarjoaja ylläpitää pseudonymisoituja asiakkaiden käyttötietoja ja tukee liiketoimintakriittistä raportointityönkulkua. Poikkeama voi vaikuttaa henkilötietoihin, säänneltyyn ICT-häiriönsietokykyyn ja palvelun saatavuuteen.
Pirstaloitunut vaatimustenmukaisuusohjelma avaa kolme erillistä työvirtaa: GDPR-tietoturvaloukkauksen arvioinnin, DORA:n ICT-poikkeaman katselmoinnin ja ISO 27001 -toimittajatiketin. Kukin tiimi pyytää samankaltaista näyttöä eri muodossa. Hankinta etsii sopimusta. Lakiasiat kysyy, onko palveluntarjoaja käsittelijä. Tietoturva kysyy, täyttääkö poikkeama raportointikynnykset. Vaatimustenmukaisuustiimi aloittaa uuden laskentataulukon.
Kypsä ISO 27001:2022 -kehikko avaa yhden koordinoidun näyttöketjun.
Ensiksi tapahtuma kirjataan tietoturvapoikkeamiin reagointiprosessin mukaisesti. Ilmoittaja käyttää määritettyä kanavaa, tietoturvatiimi luokittelee ja priorisoi tapahtuman, ja lakiasiat arvioi ilmoitusvelvoitteet. Clarysecin [P30] Tietoturvapoikkeamien hallintapolitiikka edellyttää, että lakiasiat ja tietosuojavastaava (DPO) arvioivat sääntelyn alaisia tietoja koskevat poikkeamat:
Jos poikkeama johtaa vahvistettuun tai todennäköiseen henkilötietojen tai muiden sääntelyn alaisten tietojen altistumiseen, lakiasioiden ja DPO:n on arvioitava soveltuvuus seuraaviin:
Kohdasta “Politiikan toteutusvaatimukset”, politiikkalauseke 6.4.1.
Pienemmille organisaatioille Tietoturvapoikkeamiin reagoinnin politiikka – pk-yritys osoittaa saman käytännön päätöspisteen:
Kun kyse on asiakastiedoista, toimitusjohtajan on arvioitava oikeudelliset ilmoitusvelvoitteet GDPR:n, NIS2:n tai DORA:n soveltuvuuden perusteella.
Kohdasta “Riskienkäsittely ja poikkeukset”, politiikkalauseke 7.4.1.
Toiseksi toimittajasuhde katselmoidaan. Oliko palveluntarjoaja luokiteltu kriittiseksi? Sisälsikö sopimus tietoturvaloukkauksista ilmoittamisen velvoitteet, auditointioikeudet, tietosuojavastuut, palvelun jatkuvuutta koskevat odotukset ja irtautumismääräykset? Clarysecin Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka asettaa tämän odotuksen:
Sisällytä vakioidut tietoturvavaatimukset kaikkiin toimittajasopimuksiin, mukaan lukien tietoturvaloukkauksista ilmoittamisen velvoitteet, auditointioikeudet ja tietosuojavastuut.
Kohdasta “Tavoitteet”, politiikkalauseke 3.2.
Pk-yrityksille Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka – pk-yritys tekee ristiinkartoituksen tarkoituksesta nimenomaisen:
Tue ISO/IEC 27001:2022-, GDPR-, NIS2- ja DORA-velvoitteiden noudattamista toimittajahallintaan liittyen.
Kohdasta “Tavoitteet”, politiikkalauseke 3.6.
Kolmanneksi riskirekisteri, käsittelysuunnitelma ja SoA päivitetään, jos poikkeama paljastaa puutteen. Ehkä toimittajasopimuksesta puuttuu tietty sääntelyyn perustuva ilmoitusaikataulu. Ehkä toimittajaseurannan tiheys on liian harva kriittiselle ICT-palveluntarjoajalle. Ehkä tietoturvapoikkeamiin reagointisuunnitelma ei selkeästi erota henkilötietojen tietoturvaloukkauksen kriteerejä ICT-palveluhäiriön kriteereistä.
Tarkoitus ei ole luoda uutta vaatimustenmukaisuuden universumia. Tarkoitus on päivittää yhtä integroitua näyttöketjua, jotta samat tallenteet voivat vastata useisiin auditointikysymyksiin.
SoA:n muuttaminen NIS2- ja DORA-näyttökartaksi
Tavanomainen SoA vastaa usein hyvin ISO-kysymyksiin: mitkä kontrollit ovat sovellettavia, miksi ne on valittu ja onko ne toteutettu. Jotta siitä tulee käytännön NIS2- ja DORA-näyttökartta, täydennä sitä sääntelyyn ja operatiiviseen näyttöön liittyvillä kentillä.
Avaa SoA_Builder.xlsx Audit Ready Toolkitista, johon viitataan Zenith Blueprint -oppaassa, Auditointi-, katselmointi- ja parantamisvaiheen vaiheessa 24. Vaihe 24 selittää, että auditoijat ottavat usein otoksen SoA:n kontrollista ja kysyvät, miksi se on toteutettu. Perustelusarakkeen ja linkitetyn riskin tai vaatimuksen tulee vastata tähän kysymykseen.
Lisää nämä sarakkeet:
| Uusi SoA-sarake | Tarkoitus | Esimerkkimerkintä |
|---|---|---|
| Sääntelyperuste | Osoittaa, tukeeko kontrolli NIS2-, DORA- tai GDPR-vaatimuksia, asiakassopimuksia tai häiriönsietokykyä | NIS2, DORA, GDPR |
| Kartoitettu riskitunnus | Yhdistää kontrollin riskirekisteriin | R-017 Toimittajakatkos vaikuttaa sääntelyn alaiseen raportointiin |
| Näytön omistaja | Määrittää, kuka ylläpitää todentavaa aineistoa | Tietoturvaoperaatioiden johtaja |
| Ensisijainen näyttö | Määrittää artefaktin, jonka auditoijan tulee tarkastaa ensin | Tietoturvapoikkeamiin reagointisuunnitelma ja poikkeamatikettiloki |
| Operatiivinen näyttö | Osoittaa, että kontrolli toimii ajan kuluessa | Pöytäharjoitusraportti, toimittajan tietoturvaloukkauksesta ilmoittamisen testi |
| Auditoinnin tila | Seuraa valmiutta | Testattu, puute avoinna, korjaavan toimenpiteen määräpäivä |
Sovella sitä nyt ydinkontrollijoukkoon.
| ISO/IEC 27002:2022 -kontrolli | Sääntelyperuste | Ensisijainen näyttö | Operatiivinen näyttö | Auditoijan johtopäätös |
|---|---|---|---|---|
| 5.1 Tietoturvapolitiikat | NIS2, DORA, GDPR | Hyväksytty tietoturvapolitiikka, ISMS:n soveltamisala, roolien osoittaminen | Politiikan katselmointitallenne, koulutuksen hyväksyntä, johdon katselmuksen pöytäkirjat | Hallinnointi on olemassa, johto on hyväksynyt suunnan ja vastuun osoitettavuus on dokumentoitu |
| 5.19 Tietoturva toimittajasuhteissa | NIS2, DORA, GDPR | Toimittajapolitiikka, toimittajarekisteri, toimittajaluokitus | Due diligence -arvioinnit, kriittisyysarvioinnit, sopimuskatselmoinnit, auditointioikeusnäyttö | Kolmansien osapuolten riskiä hallitaan toimittajien käyttöönotossa, sopimuksissa, seurannassa ja irtautumisessa |
| 5.20 Tietoturvan käsittely toimittajasopimuksissa | NIS2, DORA, GDPR | Vakiosopimuslausekkeet, tietoturvaliite, tietojenkäsittelyehdot | Sopimusotanta, lausekepoikkeusten hyväksynnät, oikeudellisten katselmusten tallenteet | Tietoturvavaatimukset on sisällytetty toimittajasopimuksiin |
| 5.23 Tietoturva pilvipalvelujen käytössä | DORA, NIS2, GDPR | Pilviturvallisuusstandardi, pilviriskin arviointi, arkkitehtuurihyväksyntä | Pilvitoimittajan katselmointi, keskittymäriskin arviointi, pilvipoikkeamatesti | Pilvipalveluriski on tunnistettu, hallittu, seurattu ja testattu |
| 5.24 Tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu | NIS2, DORA, GDPR | Tietoturvapoikkeamiin reagoinnin politiikka, eskalointimatriisi, ilmoituspäätöspuu | Poikkeamatiketit, pöytäharjoitusraportit, opit, ilmoitusarvioinnit | Poikkeamat voidaan havaita, luokitella, priorisoida ja eskaloida sekä arvioida sääntelyraportointia varten |
| 6.8 Tietoturvatapahtumien raportointi | NIS2, DORA, GDPR | Raportointikanava, tietoisuusmateriaali, tapahtumien raportointimenettely | Tietojenkalasteluraportit, hotline-lokit, simulaatiotallenteet, henkilöstöhaastattelut | Henkilöstö tietää, miten epäillyistä tietoturvatapahtumista ilmoitetaan nopeasti |
Tee sen jälkeen otospohjainen jäljitys. Valitse yksi toimittajapoikkeama viime vuodelta ja seuraa sitä poikkeamatiketistä toimittajasopimukseen, toimittajaluokituksesta riskirekisteriin, riskien käsittelystä SoA:han ja SoA:sta johdon katselmukseen.
Jos ketju katkeaa, se ei ole epäonnistuminen. Se on täsmällinen korjaava toimenpide ennen kuin auditoija, asiakas, sääntelyviranomainen tai hallituksen valiokunta löytää puutteen.
Keskitetty näyttö on aliarvostettu kiihdytin
Monilla organisaatioilla on riittävät kontrollit mutta heikko näytön löydettävyys. Todentava aineisto on hajallaan sähköpostissa, tikettijärjestelmissä, SharePoint-kansioissa, sopimustietovarastoissa, HR-alustoissa, GRC-työkaluissa ja toimittajaportaaleissa. Auditointikauden aikana vaatimustenmukaisuustiimi käyttää viikkoja kuvakaappausten metsästämiseen.
Tämä ei ole auditointivalmiutta. Se on auditoinnista toipumista.
Clarysecin [P33S] Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka – pk-yritys toteaa:
Kaikki näyttö on tallennettava keskitettyyn auditointikansioon.
Kohdasta “Politiikan toteutusvaatimukset”, politiikkalauseke 6.2.1.
Keskitetty auditointikansio ei tarkoita hallitsematonta kaatopaikkaa. Se tarkoittaa jäsenneltyä tietovarastoa, joka on linjassa ISMS:n, SoA:n, riskirekisterin, auditointisuunnitelman ja vaatimustenmukaisuusrekisterin kanssa.
| Kansio | Sisältö | Ristiinkartoituksen käyttö |
|---|---|---|
| 01 Hallinnointi | ISMS:n soveltamisala, tietoturvapolitiikka, roolien osoittaminen, johdon katselmuksen pöytäkirjat | NIS2-hallinnointi, DORA:n ICT-hallinto, GDPR-osoitusvelvollisuus |
| 02 Riskit ja SoA | Riskirekisteri, riskienkäsittelysuunnitelma, SoA, jäännösriskin hyväksynnät | NIS2-riskienhallinta, DORA:n ICT-riskienhallinta |
| 03 Toimittajat | Toimittajarekisteri, due diligence -arvioinnit, sopimukset, kriittisyysluokitukset, katselmustallenteet | NIS2-toimitusketju, DORA:n ICT-kolmansien osapuolten riski, GDPR-käsittelijät |
| 04 Poikkeamat | Poikkeamatiketit, tietoturvaloukkausten arvioinnit, ilmoituspäätökset, pöytäharjoitukset | NIS2-raportointi, DORA-poikkeamien hallinta, GDPR-tietoturvaloukkauksista ilmoittaminen |
| 05 Auditointi ja parantaminen | Sisäisen auditoinnin raportit, korjaavat toimenpiteet, näyttöotanta, johdon seuranta | ISO 27001:2022 -auditointivalmius, valvontavalmius |
Clarysecin Laki- ja sääntelyvaatimusten noudattamisen politiikka – pk-yritys käsittelee kartoitusongelmaa suoraan:
Kun sääntely koskee useita alueita (esim. GDPR koskee säilytystä, tietoturvaa ja tietosuojaa), tämä on kartoitettava selkeästi vaatimustenmukaisuusrekisterissä ja koulutusmateriaaleissa.
Kohdasta “Hallinnointivaatimukset”, politiikkalauseke 5.2.2.
Juuri näin ISO 27001:2022:sta tulee NIS2:n ja DORA:n kontrollikehikko. Et nojaa hiljaiseen tietoon. Kartoitat sääntelyn prosesseihin, politiikkoihin, kontrolleihin, näyttöön ja koulutukseen.
Poikkeamien raportointi alkaa ihmisistä, ei portaaleista
Yleinen auditointiheikkous ilmenee, kun tietoturvapoikkeamiin reagointisuunnitelma näyttää vahvalta, mutta työntekijät eivät tiedä, milloin tai miten ilmoittaa. Tämä on vaarallista NIS2:n, DORA:n ja GDPR:n kannalta, koska sääntelyyn perustuvat arviointiaikataulut riippuvat havaitsemisesta, eskaloinnista ja luokittelusta.
Zenith Blueprint -oppaassa, Kontrollit käytännössä -vaiheen vaiheessa 16, Clarysec korostaa henkilöstölähtöistä poikkeamien raportointia ISO/IEC 27002:2022 -kontrollin 6.8 mukaisesti. Ohjeistuksen mukaan tietoturvapoikkeamiin reagointi alkaa ihmisistä. Organisaatioiden tulee luoda selkeä, yksinkertainen ja saavutettava raportointikanava, kuten valvottu sähköpostiosoite, sisäinen portaali, hotline tai tikettikategoria. Se suosittelee myös tietoisuuskoulutusta, syyllistämätöntä ilmoituskulttuuria, luottamuksellisuutta, matalan kynnyksen raportointia ja säännöllisiä simulaatioita.
Vaikutus ristiinkartoitukseen on suora. Zenith Blueprint yhdistää tämän henkilöstön raportointikyvykkyyden GDPR Article 33:een, NIS2 Article 23:een ja DORA Article 17:ään. Jos työntekijät epäröivät ilmoittaa epäilyttävästä toiminnasta, organisaatio voi menettää kriittistä aikaa ennen kuin laki-, tietoturva- tai sääntelytiimit voivat arvioida ilmoitusvelvoitteita.
Käytännön kontrollitesti on yksinkertainen:
- Kysy viideltä työntekijältä, miten epäillystä tietojenkalasteluviestistä ilmoitetaan.
- Tarkista, valvotaanko raportointikanavaa.
- Varmista, onko tikettijärjestelmässä tietoturvapoikkeamakategoria.
- Katselmoi viimeisin simulaatio tai pöytäharjoitus.
- Varmista, että opit käsiteltiin johdon katselmuksessa.
Jos jokin vastaus on epäselvä, päivitä poikkeamaohje, koulutusmateriaali, raportointikanava ja SoA:n näyttöviittaus.
Miten eri auditoijat tarkastavat samaa kehikkoa
Ristiinkartoitettu näyttö on kestettävä erilaiset auditointinäkökulmat. Sama kontrolli voidaan testata eri tavoin tarkastajan toimeksiannosta riippuen.
| Auditoijan näkökulma | Todennäköinen kysymys | Odotettu näyttö | Yleinen epäonnistuminen |
|---|---|---|---|
| ISO 27001:2022 -auditoija | Miksi tämä kontrolli on sovellettava, ja toimiiko se kuvatulla tavalla? | SoA-perustelu, yhteys riskien käsittelyyn, politiikka, operatiiviset tallenteet, sisäisen auditoinnin tulokset | Kontrolli on olemassa, mutta SoA-perustelu on epämääräinen tai vanhentunut |
| NIS2-painotteinen arvioija | Voitteko osoittaa riskiperusteiset kyberturvallisuustoimenpiteet ja poikkeamien koordinoinnin? | Riskirekisteri, hallinnointipolitiikka, poikkeamasuunnitelma, raportointityönkulku, toimittajariskinäyttö | NIS2-kartoitus on diasarjassa, mutta ei operatiivisessa näytössä |
| DORA-painotteinen valvoja | Voitteko osoittaa ICT-riskienhallinnan, poikkeamaluokituksen, testauksen ja kolmansien osapuolten valvonnan? | ICT-riskirekisteri, toimittajan kriittisyys, poikkeamaluokitus, häiriönsietokykytestit, sopimuslausekkeet | Toimittajatallenteet eivät erota kriittisiä ICT-palveluntarjoajia tavallisista toimittajista |
| GDPR-painotteinen arvioija | Voitteko osoittaa osoitusvelvollisuuden, käsittelyn turvallisuuden, käsittelijäkontrollit ja tietoturvaloukkausten arvioinnin? | Tietosuojakartoitus, käsittelijälausekkeet, tietoturvaloukkausten arviointitallenteet, pääsynhallinta- ja salausnäyttö | Tietoturvakontrollit on toteutettu, mutta niitä ei ole yhdistetty henkilötietoriskeihin |
| NIST-painotteinen auditoija | Voitteko osoittaa hallinnoinnin, riskien tunnistamisen, suojauksen, havaitsemisen, reagoinnin ja toipumisen? | Politiikkahallinnointi, omaisuus- ja riskitallenteet, havaitsemislokit, poikkeama- ja palautumisnäyttö | Teknistä näyttöä on, mutta hallinnointiomistajuus on heikko |
| COBIT 2019- tai ISACA-tyylinen auditoija | Onko hallinnointitavoitteet, vastuut, suorituskyvyn seuranta ja varmentamistoimet määritetty? | RACI, kontrolliomistajuus, johdon raportointi, auditointisuunnitelma, mittarit, korjaavat toimenpiteet | Kontrollit ovat teknisiä, mutta niitä ei hallita mitattavan vastuun kautta |
Tässä Zenith Controls tuo arvoa yksinkertaista kartoitustaulukkoa pidemmälle. Se auttaa muuntamaan ISO/IEC 27002:2022 -kontrollit auditoinnin kannalta olennaisiksi näkökulmiksi, mukaan lukien kontrolliattribuutit, sääntelysuhteet ja näyttöodotukset. Kontrollissa 5.1 attribuutit tukevat hallinnointia, politiikkojen hallintaa, osoitusvelvollisuutta ja tietoturvatavoitteita. Kontrollissa 5.24 attribuutit tukevat reagointi- ja toipumiskäsitteitä, poikkeamavalmiutta ja korjaavia toimenpiteitä. Kontrollissa 5.19 toimittajasuhteen attribuutit yhdistävät hallinnoinnin, ekosysteemiriskin, suojauksen ja kolmansien osapuolten valvonnan.
Mitä hallituksen tulisi nähdä
Hallituksen ei tarvitse nähdä jokaista SoA-riviä. Sen on nähtävä tarina, jonka SoA kertoo.
Vahvan hallituspaketin ISO 27001:2022-, NIS2- ja DORA-yhdenmukaistamisesta tulisi sisältää:
- ISMS:n soveltamisala ja katetut liiketoimintapalvelut.
- Merkittävimmät tietoturva- ja ICT-riskit.
- Yhteenveto sovellettavista kontrolleista osa-alueittain.
- NIS2-, DORA- ja GDPR-kartoituksen tila.
- Kriittiset toimittajat ja keskittymäriskit.
- Poikkeamien raportointimittarit ja pöytäharjoitusten tulokset.
- Avoimet korjaavat toimenpiteet ja erääntyneet riskien käsittelyt.
- Päätökset, joita tarvitaan riskin hyväksymisestä, budjetista, omistajuudesta ja resursseista.
Tämä muuttaa vaatimustenmukaisuuden hallinnointinäytöksi. Se on myös linjassa Zenith Controls -ratkaisussa kuvatun kontrollin 5.1 tarkoituksen kanssa, jossa tietoturvapolitiikat tukevat johdon tason suuntaa, osoitusvelvollisuutta ja tietoturvatavoitteita.
Yleiset virheet, joita tulee välttää
Ensimmäinen virhe on olettaa, että ISO 27001:2022 -sertifiointi osoittaa automaattisesti NIS2- tai DORA-vaatimustenmukaisuuden. Näin ei ole. ISO 27001:2022 antaa vahvan hallintajärjestelmän ja kontrollikehikon, mutta tarvitset edelleen sääntelyn soveltamisalan määrittelyä, oikeudellista analyysiä, toimialakohtaista tulkintaa, ilmoitustyönkulkuja ja ymmärrystä kansallisten viranomaisten odotuksista.
Toinen virhe on käsitellä SoA:ta staattisena. SoA:n on kehityttävä, kun uusia toimittajia, järjestelmiä, poikkeamia, sääntelyä, palveluja tai riskejä ilmenee. Zenith Blueprint, vaihe 24, suosittelee SoA:n ristiintarkistamista riskirekisteriä ja käsittelysuunnitelmaa vasten sekä varmistamaan, että jokaisella valitulla kontrollilla on perustelu, joka perustuu kartoitettuun riskiin, lakisääteiseen vaatimukseen tai liiketoimintatarpeeseen.
Kolmas virhe on kartoittaa liian ylätasolla. Dia, jossa lukee “ISO 27001 maps to DORA”, ei ole auditointinäyttöä. Yksittäinen SoA-merkintä, joka yhdistää toimittajasuhteen turvallisuuden kriittiseen ICT-toimittajariskiin, sopimuslausekkeeseen, toimittajakatselmoinnin tallenteeseen ja DORA:n kolmansien osapuolten valvontaodotukseen, on paljon vahvempi.
Neljäs virhe on näytön keskittämättä jättäminen. Jos vaatimustenmukaisuuspäällikkö käyttää kaksi viikkoa kuvakaappausten keräämiseen ennen jokaista auditointia, organisaatiolla on löydettävyysongelma.
Viides virhe on henkilöstöön liittyvien kontrollien sivuuttaminen. Poikkeamien raportointi, toimittajien käyttöönotto, käyttöoikeuskatselmoinnit, politiikan hyväksyntä ja eskalointi riippuvat kaikki ihmisten käyttäytymisestä. Viimeistelty prosessi, jota kukaan ei noudata, romahtaa auditointiotannassa.
Clarysecin toimintamalli ristiinkartoitukseen
Clarysecin menetelmä yhdistää vaatimustenmukaisuuden tarinan strategiasta näyttöön:
- Zenith Blueprint -oppaassa, riskienhallintavaiheen vaiheessa 13, kartoitat kontrollit riskeihin ja rakennat SoA:n sillan muodostavaksi asiakirjaksi.
- Zenith Blueprint -oppaassa, riskienhallintavaiheen vaiheessa 14, ristiinviittaat GDPR-, NIS2- ja DORA-vaatimukset politiikkoihin ja kontrolleihin.
- Zenith Blueprint -oppaassa, Kontrollit käytännössä -vaiheen vaiheessa 16, operationalisoit henkilöstölähtöisen poikkeamien raportoinnin, jotta eskalointi alkaa ajoissa.
- Zenith Blueprint -oppaassa, Auditointi-, katselmointi- ja parantamisvaiheen vaiheessa 24, viimeistelet ja testaat SoA:n, ristiintarkistat sen riskienkäsittelysuunnitelmaa vasten ja valmistelet sen yhdeksi ensimmäisistä asiakirjoista, joita auditoija pyytää.
Tätä menetelmää tukevat Clarysecin politiikat, jotka muuttavat periaatteet operatiivisiksi säännöiksi: tietoturvan hallinnointi, riskien käsittely, toimittajaturvallisuus, tietoturvapoikkeamiin reagointi, laki- ja sääntelykartoitus sekä näytön säilytys.
Tulos ei ole pelkkä ISO 27001:2022 -valmius. Se on uudelleenkäytettävä vaatimustenmukaisuuden näyttöjärjestelmä NIS2:lle, DORA:lle, GDPR:lle, asiakkaiden varmentamiselle, sisäiselle auditoinnille ja hallituksen valvonnalle.
Seuraavat vaiheet: rakenna kerran, osoita monta kertaa
Jos organisaatiosi kohtaa NIS2-, DORA- tai GDPR-vaatimuksia, asiakasauditointeja tai ISO 27001:2022 -sertifiointipainetta, aloita kehikosta.
- Katselmoi SoA ja lisää sääntelyperustesarakkeet NIS2:lle, DORA:lle ja GDPR:lle.
- Ristiintarkista SoA riskirekisteriä ja riskienkäsittelysuunnitelmaa vasten.
- Kartoita kriittiset toimittajat toimittajaturvallisuuden kontrolleihin, sopimuslausekkeisiin ja seurantaan liittyvään näyttöön.
- Testaa poikkeamien raportointityönkulku pöytäharjoituksella.
- Keskitä auditointinäyttö kontrollin, sääntelyn, omistajan ja testauksen tilan mukaan.
- Käytä Zenith Controls -ratkaisua ISO/IEC 27002:2022 -kontrollien muuntamiseen ristiinkartoitusnäytöksi.
- Käytä Zenith Blueprint -opasta siirtyäksesi riskien käsittelystä auditointivalmiiseen SoA-validointiin.
- Ota käyttöön Clarysecin politiikkakokonaisuus, mukaan lukien Tietoturvapolitiikka, Riskienhallintapolitiikka, Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka ja Tietoturvapoikkeamien hallintapolitiikka, toteutuksen nopeuttamiseksi.
Nopein polku ei ole lisää irrallisia tarkistuslistoja. Se on yksi integroitu ISMS, yksi jäljitettävä SoA, yksi keskitetty näyttömalli ja yksi ristiinkartoituksen operatiivinen rytmi.
Clarysec voi auttaa muuttamaan ISO 27001:2022 -standardin sertifiointiprojektista käytännön kontrollikehikoksi NIS2:lle ja DORA:lle. Lataa Zenith Blueprint, tutustu Zenith Controls -ratkaisuun tai varaa Clarysec-arviointi rakentaaksesi auditointivalmiin näyttömallin ennen kuin seuraava sääntelyviranomainen, asiakas tai hallituksen valiokunta pyytää todentavaa aineistoa.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


