NIS2-näytön kartoitus ISO 27001:2022 -standardiin vuonna 2026

Vuoden 2026 NIS2-haaste ei ole tietoisuus vaan näyttö

On maanantaiaamu klo 08.35. Maria, nopeasti kasvavan B2B-pilvi- ja hallinnoitujen palvelujen tarjoajan hiljattain nimitetty tietoturvajohtaja, liittyy hallituksen neljännesvuosittaiseen riskikokoukseen kannettavallaan avoinna laaja NIS2-puutearviointi. Ensimmäinen dia näyttää rauhoittavalta. Politiikat ovat olemassa. Riskienarviointi on tehty. Tietoturvapoikkeamiin reagointi on dokumentoitu. Toimittajat on listattu. Haavoittuvuusskannaukset suoritetaan kuukausittain.

Sitten puheenjohtaja esittää kysymyksen, joka muuttaa kokouksen suunnan:

“Voimmeko osoittaa, että nämä toimenpiteet toimivat viime neljänneksellä, ja voimmeko näyttää, mitkä ISO 27001:2022 -kontrollit, omistajat ja tallenteet tukevat kutakin NIS2-velvoitetta?”

Huone hiljenee.

Lakitoiminto tietää, että yhtiö kuuluu NIS2:n soveltamisalaan, koska se tuottaa hallinnoituja ICT- ja pilvipalveluja EU-asiakkaille. Vaatimustenmukaisuustoiminto tietää, että Article 21 edellyttää teknisiä, operatiivisia ja organisatorisia kyberturvallisuusriskien hallintatoimenpiteitä. Operatiivinen toiminta tietää, että tiimi korjaa järjestelmiä, katselmoi toimittajia ja valvoo lokeja. Näyttö on kuitenkin hajallaan tikettijärjestelmissä, SIEM-vienneissä, politiikkakansioissa, laskentataulukoissa, pilvihallintakonsoleissa, toimittajaportaaleissa ja kokousmuistiinpanoissa.

Kukaan ei pysty nopeasti osoittamaan puolustettavaa ketjua NIS2 Article 21:stä ISO 27001:2022 -soveltamisalaan, riskiin, kontrolliin, politiikkaan, omistajaan, menettelyyn, operatiiviseen tallenteeseen ja auditointihavaintoon.

Tämä on vuoden 2026 todellinen haaste.

Moni organisaatio ei enää kysy: “Kuulummeko NIS2:n soveltamisalaan?” Ne kysyvät vaikeamman kysymyksen: “Voimmeko osoittaa, että NIS2:n tekniset toimenpiteemme todella toimivat?” Vastaus ei voi olla kertaluonteinen kartoitustaulukko. Sen on oltava elävä toimintamalli tietoturvallisuuden hallintajärjestelmässä, jossa lakisääteiset velvoitteet muunnetaan riskeiksi, politiikoiksi, kontrolleiksi, omistajiksi, näytöksi ja jatkuvaksi parantamiseksi.

Clarysecin malli käyttää ISO/IEC 27001:2022 -standardia hallintajärjestelmän runkona, NIS2 Article 21:tä sääntelyvelvoitteiden kokonaisuutena, politiikkalausekkeita operatiivisena sääntökirjana, Zenith Blueprint: auditoijan 30 vaiheen tiekartta -kokonaisuutta toteutuspolkuna ja Zenith Controls: vaatimustenmukaisuuksien välinen opas -kokonaisuutta ISO 27001:2022:n, NIS2:n, DORA:n, GDPR:n, NIST CSF:n ja COBIT-tyyppisen varmentamisen yhteisenä karttana.

Aloita soveltamisalasta, koska NIS2-näyttö alkaa ennen kontrolleja

Yleinen NIS2-epäonnistuminen on siirtyä suoraan MFA:han, lokitukseen, tietoturvapoikkeamiin reagointiin ja haavoittuvuuksien hallintaan ennen kuin toimijan soveltamisala, palvelujen soveltamisala ja lainkäyttöalueellinen soveltamisala on vahvistettu.

NIS2 koskee säänneltyjen toimialojen piiriin kuuluvia julkisia ja yksityisiä toimijoita, jotka täyttävät koko- ja toimintakriteerit, sekä tiettyjä toimijatyyppejä koosta riippumatta. Relevantteja digitaalisia ja ICT-luokkia ovat pilvipalveluntarjoajat, datakeskuspalvelujen tarjoajat, sisällönjakeluverkkojen tarjoajat, luottamuspalvelujen tarjoajat, yleisten sähköisten viestintäpalvelujen tarjoajat, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat, verkossa toimivat markkinapaikat, hakukoneet ja sosiaalisen verkostoitumisen palvelualustat.

Pilvipalveluntarjoajille, SaaS-alustoille, MSP- ja MSSP-toimijoille sekä digitaalisen infrastruktuurin tarjoajille tämä soveltamisalan määrittely ei ole teoreettista. Article 3 edellyttää jäsenvaltioita erottamaan keskeiset ja tärkeät toimijat. Article 27 edellyttää ENISA:a ylläpitämään rekisteriä useista digitaalisista ja ICT-palveluntarjoajista, mukaan lukien DNS-palveluntarjoajat, TLD-nimirekisterit, verkkotunnusten rekisteröintipalvelujen tarjoajat, pilvipalveluntarjoajat, datakeskuspalvelujen tarjoajat, sisällönjakeluverkkojen tarjoajat, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat, verkossa toimivat markkinapaikat, hakukoneet ja sosiaalisen verkostoitumisen palvelualustat.

ISO 27001:2022 antaa oikean rakenteen. Lausekkeet 4.1–4.4 edellyttävät, että organisaatio ymmärtää ulkoiset ja sisäiset tekijät, sidosryhmät, vaatimukset, rajapinnat ja riippuvuudet ja määrittää tämän jälkeen ISMS:n soveltamisalan. NIS2 on kirjattava tähän, ei jätettävä erilliseen lakimuistioon.

Käytännöllisen NIS2-soveltamisalatallenteen tulee sisältää:

• Oikeushenkilöä ja EU-sijoittautumista koskeva analyysi
• NIS2-toimiala ja palveluluokka
• Keskeisen tai tärkeän toimijan asema, kun kansallinen laki tai viranomaisen nimeäminen vahvistaa sen
• ENISA-rekisterin merkityksellisyys, jos sovellettavissa
• Asiakkaille tuotettavat kriittiset palvelut
• Näitä palveluja tukevat verkko- ja tietojärjestelmät
• Riippuvuudet pilvi-, datakeskus-, tele-, tietoturvan valvonta-, identiteetti- ja ohjelmistopalveluntarjoajista
• Yhteydet DORA:an, GDPR:ään, asiakassopimuksiin ja toimialakohtaisiin velvoitteisiin
• Näyttötietovarastot, järjestelmäomistajat ja katselmointitiheys

Tässä kohdassa myös DORA on erotettava oikein. NIS2 tunnistaa, että jos toimialakohtainen EU:n säädös asettaa vastaavat kyberturvallisuuden riskienhallinta- tai poikkeamailmoitusvelvoitteet, kyseistä toimialakohtaista järjestelmää sovelletaan vastaavien NIS2-säännösten sijasta. Soveltamisalaan kuuluville finanssialan toimijoille DORA on yleensä keskeinen kyberturvallisuutta ja ICT-poikkeamien raportointia koskeva järjestelmä. DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se kattaa ICT-riskien hallinnan, poikkeamaraportoinnin, digitaalisen operatiivisen häiriönsietokyvyn testauksen, ICT-kolmansien osapuolten riskit ja kriittisten ICT-kolmansien osapuolten valvonnan.

Fintech-konsernilla voi siksi olla eri vaatimustenmukaisuuskäsittelyjä saman konsernirakenteen sisällä. Maksuyhteisö voi kuulua ensisijaisesti DORA:n piiriin. MSP-tytäryhtiö voi kuulua suoraan NIS2:n piiriin. Jaettu pilvialusta voi tukea molempia. Kypsä vastaus ei ole päällekkäiset kontrollit, vaan yksi ISMS-näyttömalli, joka palvelee useita sääntelynäkökulmia.

ISO 27001:2022 NIS2-vaatimustenmukaisuuden käyttöjärjestelmänä

NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä verkko- ja tietojärjestelmiin kohdistuvien riskien hallitsemiseksi sekä poikkeamien vaikutusten estämiseksi tai minimoimiseksi palvelujen vastaanottajiin ja muihin palveluihin.

ISO 27001:2022 soveltuu hyvin tämän vaatimuksen käytännön toteutukseen, koska se pakottaa kolmeen kurinalaiseen toimintatapaan.

Ensimmäinen on hallinnointi. Lausekkeet 5.1–5.3 edellyttävät ylimmän johdon sitoutumista, yhdenmukaisuutta strategisen suunnan kanssa, resursointia, viestintää, vastuiden osoittamista ja dokumentoitua tietoturvapolitiikkaa. Tämä vastaa suoraan NIS2 Article 20:tä, joka edellyttää johtoa hyväksymään kyberturvallisuuden riskienhallintatoimenpiteet, valvomaan niiden toteutusta ja saamaan koulutusta.

Toinen on riskien käsittely. Lausekkeet 6.1.1–6.1.3 edellyttävät toistettavaa riskienarviointiprosessia, riskinomistajia, riskien arviointia, käsittelyvaihtoehtoja, kontrollien valintaa, soveltuvuuslausuntoa, riskienkäsittelysuunnitelmaa ja jäännösriskin hyväksyntää.

Kolmas on operatiivinen ohjaus. Lauseke 8.1 edellyttää, että organisaatio suunnittelee, toteuttaa ja ohjaa ISMS-prosesseja, ylläpitää dokumentoitua tietoa, hallitsee muutoksia ja hallitsee ISMS:n kannalta relevantteja ulkoisesti tuotettuja prosesseja, tuotteita ja palveluja.

Näin NIS2 muuttuu juridisesta tarkistuslistasta kontrollien toimintamalliksi.

Jokaisella rivillä on oltava omistaja, tallennelähde ja otantamenetelmä. Jos ne puuttuvat, organisaatiolla on kontrollia koskeva tavoitetila, ei toimiva kontrolli.

Politiikka muuttaa NIS2:n operatiiviseksi toiminnaksi

Politiikkoja käsitellään usein mallipohjina. NIS2:n kannalta se on vaarallista. Sääntelyviranomainen tai auditoija ei vakuutu politiikkakansiosta, jos politiikat eivät osoita omistajuutta, määritä tallenteita, linkity riskeihin ja tuota näyttöä.

Yritystason Laki- ja sääntelyvaatimusten noudattamisen politiikka luo perustan lausekkeessa 6.2.1:

Kaikki lakisääteiset ja sääntelyyn perustuvat velvoitteet on kartoitettava tiettyihin politiikkoihin, kontrolleihin ja omistajiin tietoturvallisuuden hallintajärjestelmässä (ISMS).

Tämä lauseke on silta NIS2:n ja ISO 27001:2022:n välillä. NIS2 Article 21:tä ei vain listata ulkoiseksi vaatimukseksi. Se puretaan politiikkavelvoitteiksi, kartoitetaan kontrolleihin, osoitetaan omistajille ja testataan näytön avulla.

Pienemmille organisaatioille pk-yritysten Laki- ja sääntelyvaatimusten noudattamisen politiikka säilyttää saman periaatteen kevyempänä. Lauseke 5.1.1 edellyttää:

Toimitusjohtajan on ylläpidettävä yksinkertaista ja rakenteista vaatimustenmukaisuusrekisteriä, jossa luetellaan:

Lause on tarkoituksella käytännönläheinen. Pk-yritykset eivät tarvitse aluksi monimutkaista GRC-toteutusta. Ne tarvitsevat vaatimustenmukaisuusrekisterin, joka kirjaa velvoitteen, sovellettavuuden, omistajan, politiikan, näytön ja katselmointitiheyden.

Riskien käsittely muuttaa velvoitteen toiminnaksi. Yritystason Riskienhallintapolitiikka, lauseke 6.4.2 toteaa:

Riskivastaavan tulee varmistaa, että riskien käsittelytoimet ovat realistisia, aikarajattuja ja kartoitettu ISO/IEC 27001 liite A -kontrolleihin.

Pk-yrityksille Riskienhallintapolitiikka - pk-yritys, lauseke 5.1.2 antaa vähimmäiskelpoisen riskitallenteen:

Jokaisen riskimerkinnän tulee sisältää: kuvaus, todennäköisyys, vaikutus, pisteet, omistaja ja käsittelysuunnitelma.

Näillä lausekkeilla on merkitystä, koska NIS2 on nimenomaisesti riskiperusteinen ja oikeasuhtainen. Article 21 odottaa, että toimenpiteet kuvastavat tekniikan tasoa, relevantteja standardeja, toteutuskustannuksia, riskialtistusta, kokoa sekä poikkeaman todennäköisyyttä ja vakavuutta, mukaan lukien yhteiskunnalliset ja taloudelliset vaikutukset. Riskirekisteri ilman omistajia ja käsittelysuunnitelmia ei voi osoittaa oikeasuhtaisuutta.

Yritystason Tietoturvapolitiikka täydentää näyttöperiaatteen lausekkeessa 6.6.1:

Kaikkien toteutettujen kontrollien tulee olla auditoitavissa, niiden tulee perustua dokumentoituihin menettelyihin ja niillä tulee olla säilytetty näyttö toiminnasta.

Tämä erottaa NIS2-ohjelman NIS2-näyttöohjelmasta.

Clarysecin reitti kartoituksesta toimintaan

Zenith Blueprint on arvokas, koska se vastaa auditoijien ajattelutapaa. He eivät kysy vain, onko kontrolli olemassa. He kysyvät, miksi se valittiin, missä se on dokumentoitu, miten se toimii, kuka sen omistaa, mikä näyttö osoittaa sen ja miten organisaatio parantaa sitä.

Riskienhallintavaiheessa vaihe 13 ohjeistaa tiimejä lisäämään jäljitettävyyden riskien, kontrollien ja lausekkeiden välille:

✓ Kartoita kontrollit riskeihin: Riskirekisterisi käsittelysuunnitelmassa olet listannut tietyt kontrollit kullekin riskille. Voit lisätä sarakkeen “Annex A Control Reference” kuhunkin riskiin ja listata kontrollinumerot.

NIS2:n osalta tämä tarkoittaa, että riskirekisterin ja soveltuvuuslausunnon tulee osoittaa, miksi kontrollit kuten 8.8 teknisten haavoittuvuuksien hallinta, 5.19 tietoturvallisuus toimittajasuhteissa ja 5.24 poikkeamien hallinnan suunnittelu ja valmistelu ovat sovellettavia.

Zenith Blueprint -kokonaisuuden vaihe 14 tekee sääntelykartoituksesta nimenomaisen:

Kunkin sääntelyn osalta voit tarvittaessa luoda yksinkertaisen kartoitustaulukon (esimerkiksi raportin liitteeksi), jossa luetellaan sääntelyn keskeiset tietoturvavaatimukset ja vastaavat kontrollit/politiikat ISMS:ssäsi.

Tämä estää pirstoutumista. GDPR:n henkilötietojen turvallisuus, NIS2:n poikkeamaraportointi, DORA:n ICT-häiriönsietokyvyn testaus ja asiakkaiden tietoturvasitoumukset voivat kaikki nojata samaan näyttöön: käyttöoikeuskatselmointeihin, haavoittuvuuksien korjaamiseen, lokitallenteisiin, varmuuskopioiden testeihin, toimittajakatselmointeihin ja poikkeamaraportteihin.

Vaihe 19 siirtyy suunnittelusta toimintaan:

Liitä kukin näistä asiakirjoista asianmukaiseen kontrolliin SoA:ssasi tai ISMS-käsikirjassasi. Ne toimivat toteutuksen näyttönä ja sisäisenä viitteenä.

Vaiheen 19 dokumentaatiokokonaisuus sisältää päätelaiteturvallisuuden, käyttöoikeuksien hallinnan, todennuksen, turvalliset peruskonfiguraatiot, lokituksen ja valvonnan, korjauspäivitysten hallinnan, haavoittuvuuksien hallinnan, kapasiteettisuunnittelun ja IT-operaatioiden raportoinnin. Nämä ovat juuri ne operatiiviset asiakirjat, joita tarvitaan NIS2:n teknisten toimenpiteiden auditoitavuuteen.

Vaihe 26 selittää, miten auditointinäyttöä tulee kerätä:

Kun keräät näyttöä, kirjaa havaintosi. Merkitse, missä asiat ovat vaatimuksen mukaisia (positiiviset havainnot) ja missä eivät (mahdolliset poikkeamat tai huomiot).

NIS2:n osalta tämä tarkoittaa näytön otantaa ennen kuin sääntelyviranomainen, asiakasarvioija tai sertifiointiauditoija pyytää sitä.

Zenith Controls -kokonaisuuden rooli vaatimustenmukaisuuksien välillä

Zenith Controls ei ole erillinen kontrolliviitekehys. Se on Clarysecin opas ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -kontrollien kartoittamiseen niihin liittyviin kontrolleihin, auditointiodotuksiin ja ulkoisiin viitekehyksiin. Se auttaa tiimejä ymmärtämään, miten yksi ISO 27001:2022 -kontrolli voi tukea NIS2:ta, DORA:a, GDPR:ää, NIST CSF 2.0:aa ja COBIT-tyyppistä varmentamista.

Kolme ISO 27001:2022 -kontrollia ovat erityisen tärkeitä NIS2-näytön kartoituksessa.

Kontrolli 5.1 Tietoturvapolitiikat on lähtöpiste, koska NIS2 Article 21 sisältää riskianalyysin ja tietojärjestelmien tietoturvapolitiikat. Jos NIS2:n tekninen toimenpide ei näy politiikassa, sitä on vaikea hallinnoida ja auditoida johdonmukaisesti.

Kontrolli 5.36 Tietoturvapolitiikkojen, sääntöjen ja standardien noudattaminen on todellisuustarkastus. Se yhdistää politiikkavaatimukset todelliseen yhdenmukaisuuteen sisäisten sääntöjen, standardien ja ulkoisten velvoitteiden kanssa. NIS2-termein tässä organisaatio kysyy, tekeekö se sitä, mitä sen Article 21 -kartoitus sanoo sen tekevän.

Kontrolli 8.8 Teknisten haavoittuvuuksien hallinta on yksi vuoden 2026 vaikeimmista testialueista. Haavoittuvuuksien hallinta liittyy suoraan turvalliseen hankintaan, kehittämiseen, ylläpitoon, haavoittuvuuksien käsittelyyn ja julkistamiseen. Se tukee myös DORA:n testausta ja korjaamista, GDPR:n tietoturvaa koskevaa osoitusvelvollisuutta, NIST CSF:n Identify- ja Protect-tuloksia sekä ISO 27001 -auditoinnin otantaa.

Tukevat standardit voivat täsmentää suunnittelua ilman lisäsertifiointeja. ISO/IEC 27002:2022 antaa toteutusohjeita liite A -kontrolleille. ISO/IEC 27005 tukee tietoturvariskien hallintaa. ISO/IEC 27017 tukee pilviturvallisuutta. ISO/IEC 27018 tukee henkilötietojen suojaa julkisen pilven käsittelijätilanteissa. ISO 22301 tukee liiketoiminnan jatkuvuutta. ISO/IEC 27035 tukee poikkeamien hallintaa. ISO/IEC 27036 tukee toimittajasuhteiden tietoturvallisuutta.

Tavoitteena ei ole lisätä standardeja standardien vuoksi. Tavoitteena on parempi näyttösuunnittelu.

Käytännön esimerkki: rakenna NIS2-haavoittuvuusnäyttöpaketti

Tarkastellaan Marian SaaS-alustaa. Se palvelee EU:ssa toimivia valmistavan teollisuuden asiakkaita ja riippuu pilvipalveluista, avoimen lähdekoodin komponenteista, CI/CD-putkista ja hallitusta valvonnasta. Hänen puuteraporttinsa mukaan “haavoittuvuuksien hallinta on toteutettu”, mutta näyttö on hajallaan skannereissa, Jirassa, GitHubissa, pilvikonfiguraatiotyökaluissa ja muutostiketeissä.

NIS2-valmis näyttöpaketti voidaan rakentaa yhdessä kohdennetussa sprintissä.

Vaihe 1: Määritä riskiskenaario

Riski: hyödynnettävissä oleva haavoittuvuus internetiin avautuvassa sovelluksessa, riippuvuudessa tai pilvikomponentissa aiheuttaa palvelukatkoksen, luvattoman pääsyn tai asiakastietojen altistumisen.

Riskirekisterin tulee sisältää kuvaus, todennäköisyys, vaikutus, pisteet, omistaja ja käsittelysuunnitelma. Käsittelysuunnitelmassa tulee viitata ISO 27001:2022 -kontrolliin 8.8 teknisten haavoittuvuuksien hallinta sekä siihen liittyviin kontrolleihin omaisuusluettelon, turvallisen kehittämisen, lokituksen, pääsynhallinnan, toimittajahallinnan ja tietoturvapoikkeamiin reagoinnin osalta.

Vaihe 2: Kartoita riski NIS2 Article 21:een

Riski tukee Article 21:n vaatimuksia turvalliselle hankinnalle, kehittämiselle ja ylläpidolle, haavoittuvuuksien käsittelylle ja julkistamiselle, riskianalyysille, poikkeamien käsittelylle, toimitusketjun turvallisuudelle ja kontrollien tehokkuuden arvioinnille.

Vaihe 3: Ankkuroi toimintaa koskevat säännöt politiikkaan

Käytä haavoittuvuuksien hallintamenettelyä, turvallisen kehittämisen standardia, korjauspäivitysten hallintavaatimuksia, tietoturvatestauspolitiikkaa ja auditointinäyttöä koskevia sääntöjä.

Yritystason Tietoturvatestauksen ja red team -harjoitusten politiikka, lauseke 6.1 toteaa:

Testityypit: Tietoturvatestausohjelman tulee sisältää vähintään: (a) haavoittuvuusskannaus, joka koostuu verkkojen ja sovellusten automatisoiduista viikoittaisista tai kuukausittaisista skannauksista tunnettujen haavoittuvuuksien tunnistamiseksi; (b) penetraatiotestaus, joka koostuu ammattitaitoisten testaajien suorittamasta tiettyjen järjestelmien tai sovellusten manuaalisesta syvätestauksesta monimutkaisten heikkouksien tunnistamiseksi; ja (c) red team -harjoitukset, jotka koostuvat skenaariopohjaisista todellisten hyökkäysten simulaatioista, mukaan lukien sosiaalinen manipulointi ja muut taktiikat, joilla testataan organisaation havainnointi- ja reagointikyvykkyyttä kokonaisuutena.

Tämä lauseke luo puolustettavan testauksen perustason. Se on myös yhdenmukainen DORA:n odotuksen kanssa, jonka mukaan soveltamisalaan kuuluvien finanssialan toimijoiden on tehtävä toistuvaa, riskiperusteista digitaalisen operatiivisen häiriönsietokyvyn testausta.

Vaihe 4: Määritä näytön metatiedot

Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - pk-yritys, lauseke 6.2.3 toteaa:

Metatiedot (esim. kuka keräsi näytön, milloin ja mistä järjestelmästä) on dokumentoitava.

Haavoittuvuusnäytön osalta paketin tulee kirjata:

• Skannerin nimi ja konfiguraatio
• Skannauksen päivämäärä ja aika
• Omaisuuserien soveltamisala ja poissulut
• Kriittiset ja korkeat havainnot
• Tikettinumero ja omistaja
• Paikkaus- tai lieventämispäätös
• Riskin hyväksymispäätös, jos sovellettavissa
• Korjauspäivä
• Validointiskannaus
• Linkki muutostallenteeseen
• Poikkeuksen omistaja ja päättymispäivä

Vaihe 5: Lisää lokitusnäyttö

Lokitus- ja valvontapolitiikka - pk-yritys, lauseke 5.4.4 sisältää järjestelmälokit, kuten:

Järjestelmälokit: konfiguraatiomuutokset, hallinnolliset toimet, ohjelmistoasennukset, paikkaustoiminta

Pelkkä paikkaustiketti ei välttämättä osoita, että muutos tehtiin. Konfiguraatiolokit, hallinnolliset toimet ja ohjelmistoasennusten tallenteet vahvistavat näyttöketjua.

Vaihe 6: Suorita otantaan perustuva auditointi

Valitse viisi kriittistä tai korkean vakavuuden haavoittuvuutta edelliseltä neljännekseltä. Varmista jokaisen kohteen osalta, että omaisuuserä oli omaisuusluettelossa, skanneri havaitsi löydöksen, tiketti avattiin palvelutason mukaisessa ajassa, omistaja oli osoitettu, korjaaminen vastasi vakavuutta ja hyväksikäytettävyyttä, lokit osoittavat muutoksen, validointi vahvistaa sulkemisen ja jokaisella poikkeuksella on riskinomistajan hyväksyntä sekä päättymispäivä.

Tämä sprintti tuottaa NIS2-valmiin haavoittuvuusnäyttöpaketin ja ISO 27001:2022 -sisäisen auditoinnin otoksen.

Toimittajaturvallisuus on ekosysteemin hallinnointia

NIS2 Article 21 edellyttää toimitusketjun turvallisuutta, mukaan lukien suoriin toimittajiin ja palveluntarjoajiin liittyvät turvallisuusnäkökohdat. Se edellyttää myös, että organisaatiot huomioivat toimittajien haavoittuvuudet, tuotteiden laadun, toimittajien kyberturvallisuuskäytännöt ja turvallisen kehittämisen käytännöt.

Tässä Marian puuteraportin ensimmäinen versio oli heikoin. Se listasi toimittajat, mutta ei osoittanut due diligence -arviointia, sopimusten tietoturvalausekkeita, seurantaa tai exit-valmiutta.

Kolmansien osapuolten ja toimittajien tietoturvapolitiikka toimii politiikka-ankkurina. Liittyvää toteutusta voivat tukea Turvallisen kehityksen politiikka, Tietoturvatietoisuus- ja koulutuspolitiikka, Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka, Kryptografisten hallintakeinojen politiikka, Pääsynhallintapolitiikka ja Etätyöpolitiikka.

Yksi toimittajanäyttörekisteri voi tukea NIS2:ta, DORA:a ja ISO 27001:2022:ta.

Tämä taulukko estää päällekkäiset kyselyt, päällekkäiset rekisterit ja ristiriitaisen kontrollien omistajuuden.

Yksi poikkeamien työnkulku NIS2:lle, DORA:lle ja GDPR:lle

NIS2 Article 23 edellyttää merkittävien poikkeamien ilmoittamista ilman aiheetonta viivytystä. Se määrittää vaiheistetun aikajanan: varhaisvaroitus 24 tunnin kuluessa tietoisuuteen tulemisesta, poikkeamailmoitus 72 tunnin kuluessa alustavalla vakavuus- tai vaikutusarvioinnilla ja saatavilla olevilla vaarantumisen indikaattoreilla, välipäivitykset pyydettäessä sekä loppuraportti viimeistään kuukauden kuluttua poikkeamailmoituksesta.

DORA:ssa on finanssialan toimijoille samankaltainen elinkaari: havaitseminen, luokittelu, lokitus, vakavuuden arviointi, eskalointi, asiakasviestintä, viranomaisraportointi, juurisyyanalyysi ja korjaaminen. GDPR lisää henkilötietojen tietoturvaloukkauksen analyysin, mukaan lukien rekisterinpitäjän ja käsittelijän roolit, vaikutukset rekisteröityihin sekä 72 tunnin ilmoitusaikataulun soveltuvissa tilanteissa.

Oikea suunnittelu ei ole kolme poikkeamaprosessia. Se on yksi poikkeamien työnkulku, jossa on sääntelyyn perustuvat päätöshaarat.

Tietoturvapoikkeamien hallintapolitiikka - pk-yritys, lauseke 5.4.1 toteaa:

Kaikki poikkeamatutkinnat, havainnot ja korjaavat toimenpiteet on kirjattava toimitusjohtajan ylläpitämään poikkeamarekisteriin.

Vahvan poikkeamarekisterin tulee sisältää:

GDPR-yhteyttä ei tule aliarvioida. NIS2:n toimivaltaiset viranomaiset voivat informoida GDPR:n valvontaviranomaisia, jos kyberturvallisuuden riskienhallinnan tai raportoinnin puutteet voivat johtaa henkilötietojen tietoturvaloukkaukseen. ISMS:n tulee siksi tehdä tietosuojan arvioinnista osa poikkeamien luokittelua ja priorisointia, ei jälkiajatus.

Miten auditoijat ja sääntelyviranomaiset testaavat NIS2-näyttöäsi

Vuoteen 2026 valmis organisaatio voi odottaa, että samaa kontrollia testataan eri näkökulmista.

ISO 27001:2022 -auditoija aloittaa ISMS:stä. Hän kysyy, onko NIS2-velvoitteet tunnistettu sidosryhmävaatimuksina, kattaako ISMS:n soveltamisala relevantit palvelut ja riippuvuudet, arvioidaanko ja käsitelläänkö riskit, perusteleeko soveltuvuuslausunto sovellettavat kontrollit ja osoittavatko tallenteet toiminnan.

NIS2:n toimivaltainen viranomainen keskittyy oikeudellisiin lopputuloksiin. Se voi kysyä, onko kaikki Article 21 -toimenpiteet käsitelty, ovatko kontrollit asianmukaisia ja oikeasuhtaisia, onko johto hyväksynyt toimenpiteet ja valvooko se niitä sekä pystyykö poikkeamaraportointi täyttämään vaaditut määräajat.

DORA-valvoja testaa soveltamisalaan kuuluvien finanssialan toimijoiden osalta ICT-riskien hallintaa, poikkeamien luokittelua, häiriönsietokyvyn testausta, kolmannen osapuolen riskejä, sopimusjärjestelyjä, keskittymäriskiä ja exit-strategioita.

GDPR-arvioija testaa, suojaavatko tekniset ja organisatoriset toimenpiteet henkilötietoja, onko loukkausarviointi upotettu poikkeamien käsittelyyn, ovatko rekisterinpitäjän ja käsittelijän roolit selkeät ja onko osoitusvelvollisuutta tukevia tallenteita olemassa.

NIST CSF 2.0- tai COBIT 2019 -tyyppinen arvioija keskittyy hallinnointiin, riskinomistajuuteen, suorituskykymittareihin, nykyisiin ja tavoitetuloksiin, prosessikyvykkyyteen ja yhdenmukaisuuteen organisaation riskinottohalukkuuden kanssa.

Yritystason Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka, lauseke 3.4 tiivistää näytön tarkoituksen:

Tuottaa puolustettavaa näyttöä ja auditointijälki sääntelyviranomaisten tiedustelujen, oikeudellisten menettelyjen tai asiakkaiden varmentamispyyntöjen tueksi.

Tämä on operatiivinen taso, jota kohti NIS2-tiimien tulee rakentaa.

Johdon vastuuvelvollisuus: hallitus ei voi delegoida NIS2:ta pois

NIS2 Article 20 edellyttää keskeisten ja tärkeiden toimijoiden johtoa hyväksymään kyberturvallisuuden riskienhallintatoimenpiteet, valvomaan niiden toteutusta ja saamaan koulutusta. Johtoon kuuluvia henkilöitä voidaan pitää vastuussa rikkomuksista kansallisten vastuusääntöjen mukaisesti.

Tämä on yhdenmukaista ISO 27001:2022:n johtajuusvaatimusten kanssa. Ylimmän johdon on varmistettava, että tietoturvapolitiikka ja tavoitteet ovat yhdenmukaisia strategisen suunnan kanssa, ISMS-vaatimukset integroidaan liiketoimintaprosesseihin, resurssit annetaan, tärkeydestä viestitään, vastuut osoitetaan ja jatkuvaa parantamista edistetään.

Hallitus ei tarvitse raakamuotoisia skannerivientejä tai täydellisiä SIEM-lokeja. Se tarvitsee päätöksentekokelpoista varmuutta.

Neljännesvuosittaisen NIS2-hallituksen näyttöpaketin tulee sisältää:

1. Soveltamisalan ja sääntelyaseman muutokset
2. Merkittävimmät NIS2-riskit ja käsittelyn tila
3. Article 21 -kontrollien tehokkuusmittaristo
4. Merkittävät poikkeamat, läheltä piti -tilanteet ja raportointipäätökset
5. Toimittaja- ja pilviriskien poikkeukset
6. Sisäisen auditoinnin havainnot, korjaavat toimenpiteet ja myöhässä oleva näyttö

Tämä paketti antaa johdolle tiedot, joita se tarvitsee toimenpiteiden hyväksymiseen, poikkeusten haastamiseen ja jäännösriskin hyväksymiseen.

Clarysecin vuoden 2026 toimintamalli

NIS2:n teknisten toimenpiteiden käytäntöön vieminen ISO 27001:2022:n avulla edellyttää yksinkertaista mutta kurinalaista mallia:

• Määritä NIS2:n, DORA:n, GDPR:n ja sopimusvelvoitteiden soveltamisala ISMS:ssä
• Kartoita velvoitteet riskeihin, politiikkoihin, kontrolleihin, omistajiin ja näyttöön
• Käytä soveltuvuuslausuntoa kontrollien totuuden lähteenä
• Rakenna näyttöpaketit korkean riskin Article 21 -alueille
• Integroi poikkeamaraportointi yhteen sääntelyn työnkulkuun
• Käsittele toimittajaturvallisuutta elinkaarena, ei kyselynä
• Suorita sisäiset auditoinnit todellisilla otoksilla
• Raportoi kontrollien tehokkuus johdolle
• Paranna toimintaa poikkeamien, auditointihavaintojen, testien ja sääntelymuutosten perusteella

Marialle käännekohta oli oivallus, ettei hän tarvinnut erillistä NIS2-projektia. Hän tarvitsi vahvemman ISMS-näyttömoottorin.

Clarysecin politiikat, Zenith Blueprint ja Zenith Controls on suunniteltu toimimaan yhdessä. Politiikat määrittävät odotetun toiminnan ja tallenteet. Zenith Blueprint antaa 30 vaiheen toteutus- ja auditointireitin. Zenith Controls tarjoaa vaatimustenmukaisuuksien välisen kartoituksen, jotta NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF ja COBIT-tyyppinen varmentaminen voidaan hallita yhtenä johdonmukaisena ohjelmana.

Seuraava askel: rakenna NIS2–ISO 27001:2022 -näyttökartta

Jos NIS2-työsi on edelleen puutetaulukossa, vuosi 2026 on aika viedä se käytäntöön.

Aloita yhdestä korkean riskin teknisestä toimenpiteestä, kuten haavoittuvuuksien hallinnasta, poikkeamien käsittelystä tai toimittajaturvallisuudesta. Kartoita se ISO 27001:2022 -riskeihin, politiikkoihin, liite A -kontrolleihin, omistajiin, menettelyihin ja näyttöön. Tee sitten otanta viime neljänneksen tallenteista ja kysy vaikea kysymys: riittäisikö tämä sääntelyviranomaiselle, asiakasarvioijalle ja ISO 27001:2022 -auditoijalle?

Clarysec voi auttaa rakentamaan vastauksen politiikkakirjaston, Zenith Blueprint ja Zenith Controls avulla.

Tavoitteena ei ole lisädokumentaatio. Tavoitteena on puolustettava ja toistettava näyttö siitä, että NIS2:n tekniset toimenpiteesi todella toimivat.