NIS2- ja DORA-vaatimustenmukaisuuden jatkuva seuranta

Perjantai-iltapäivän kysymys, johon jokaisen tietoturvajohtajan on nyt vastattava

Perjantaina klo 16.40 pilvipohjaisen maksualustan tietoturvajohtaja saa kymmenen minuutin aikana kolme viestiä.

Ensimmäinen on talousjohtajalta: “Pankkikumppanimme pyytää päivitettyä näyttöä siitä, että täytämme DORA:n odotukset ICT-kolmansien osapuolten riskien ja poikkeamaraportoinnin osalta.”

Toinen on lakiasiainjohtajalta: “Hallinnoitu tietoturvapalvelumme voi tuoda meidät kansallisen NIS2-täytäntöönpanon soveltamisalaan. Pystymmekö osoittamaan johdon valvonnan ja kontrollien vaikuttavuuden?”

Kolmas on kehitysjohtajalta: “Korjasimme kriittisen haavoittuvuuden, mutta työjonossa näkyy 38 määräajan ylittänyttä keskitasoista havaintoa. Pitääkö tämä eskaloida?”

Tämä on hetki, jolloin vuosittainen vaatimustenmukaisuusmalli pettää.

Politiikka-PDF, ennen edellistä auditointia viimeksi päivitetty riskirekisteri ja kuvakaappauskansio eivät riitä NIS2:lle ja DORA:lle. Nämä sääntelykehykset edellyttävät elävää hallintaa, johdon valvontaa, poikkeamien työnkulkuja, toimittajanäkyvyyttä, häiriönsietokyvyn testausta, korjaavia toimenpiteitä ja todennettavaa kontrollien vaikuttavuutta.

Monelle tietoturvajohtajalle paine ei ole teoreettinen. NIS2:n täytäntöönpano EU:n jäsenvaltioissa on siirtänyt kyberturvallisuuden teknisestä ohjelmasta johdon vastuuvelvollisuutta koskevaksi asiaksi. DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se antaa finanssialan toimijoille toimialakohtaisen operatiivisen häiriönsietokyvyn sääntökokonaisuuden ICT-riskien, poikkeamaraportoinnin, testauksen ja kolmansien osapuolten riskien hallintaan. Myös pilvi-, SaaS-, hallinnoitujen palvelujen, hallinnoitujen tietoturvapalvelujen, konesalien, sisällönjakelun, luottamuspalvelujen ja julkisten sähköisten viestintäpalvelujen tarjoajilla voi olla suoria tai epäsuoria velvoitteita soveltamisalasta, koosta, toimialasta, kansallisesta luokittelusta ja asiakassopimuksista riippuen.

Käytännön kysymys ei enää ole: “Onko meillä kontrolli?”

Se on: “Kuka omistaa kontrollin, mikä mittari osoittaa sen toimivan, kuinka usein keräämme näyttöä ja mitä tapahtuu, kun mittari ei täytä kynnysarvoa?”

Tämä on NIS2- ja DORA-vaatimustenmukaisuuden jatkuvan seurannan ydin. Clarysecin toteutuksissa käytämme ISO/IEC 27001:2022 -standardia hallintajärjestelmän runkona, ISO/IEC 27002:2022 -standardia kontrollikielenä, Zenith Blueprint: auditoijan 30 vaiheen tiekarttaa toteutusjärjestyksenä ja Zenith Controls: vaatimustenmukaisuuksien välistä opasta kompassina, joka yhdistää ISO/IEC 27001:2022 -näytön NIS2:een, DORA:an, GDPR:ään, NIST CSF 2.0:aan, COBIT 2019:ään ja auditointiodotuksiin.

Miksi NIS2 ja DORA tekevät määräajoin tehtävästä vaatimustenmukaisuustyöstä riittämätöntä

NIS2 ja DORA eroavat oikeudelliselta rakenteeltaan, valvontamalliltaan ja soveltamisalaltaan, mutta ne synnyttävät saman operatiivisen paineen. Kyberturvallisuutta ja ICT-häiriönsietokykyä on hallittava jatkuvasti.

NIS2 edellyttää, että keskeiset ja tärkeät toimijat soveltavat asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä kaikki uhat huomioon ottavan lähestymistavan mukaisesti. Näihin toimenpiteisiin kuuluvat riskianalyysi, tietojärjestelmien turvallisuuspolitiikat, poikkeamien käsittely, liiketoiminnan jatkuvuus, kriisinhallinta, toimitusketjun tietoturva, turvallinen hankinta ja kehittäminen, haavoittuvuuksien käsittely, vaikuttavuuden arviointi, kyberhygienia, koulutus, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta ja tarvittaessa monivaiheinen todennus. Johdon toimielinten on hyväksyttävä kyberturvallisuuden riskienhallintatoimenpiteet, valvottava niiden toteutusta ja osallistuttava koulutukseen.

DORA tekee tästä vielä nimenomaisempaa finanssialan toimijoille. Se edellyttää ICT-riskien sisäisiä hallinto- ja kontrollijärjestelyjä, dokumentoitua ICT-riskien hallintakehystä, ylimmän hallintoelimen vastuuta, ICT:hen liittyvien poikkeamien hallintaa ja raportointia, digitaalisen operatiivisen häiriönsietokyvyn testausta, ICT-kolmansien osapuolten riskien hallintaa, auditointihavaintojen seurantaa, koulutusta ja viestintäjärjestelyjä. DORA tekee myös selväksi, että finanssialan toimijat säilyttävät vastuun vaatimustenmukaisuudesta käyttäessään ICT-palveluja tarjoavia kolmansia osapuolia.

Tämä luo uuden vaatimustenmukaisuuden todellisuuden. Tietoturvajohtaja ei voi odottaa auditointikuukauteen asti huomatakseen, että:

• etuoikeutettujen käyttöoikeuksien katselmoinnit jäivät tekemättä kahden vuosineljänneksen ajan;
• toimittajien irtautumissuunnitelmat dokumentoitiin mutta niitä ei koskaan testattu;
• poikkeamien vakavuuskriteerit eivät vastaa sääntelyraportoinnin kynnysarvoja;
• varmuuskopiot on määritetty, mutta palautusnäyttö puuttuu;
• johto ei ole koskaan katselmoinut määräajan ylittäneitä riskienkäsittelyjä;
• pilvisopimuksista puuttuvat auditointioikeudet, alihankkijanäkyvyys tai poikkeamien ilmoituslausekkeet.

Vanha projektipohjainen malli synnyttää paniikkisyklejä. Tiimit kiirehtivät ennen auditointia, keräävät kuvakaappauksia, päivittävät politiikkojen päivämääriä ja toivovat, että näyttö kertoo johdonmukaisen tarinan. NIS2 ja DORA on suunniteltu tekemään tästä lähestymistavasta toimimaton. Ne keskittyvät vastuun osoitettavuuteen, oikeasuhtaisuuteen, häiriönsietokykyyn ja toiminnan näyttöön.

ISO/IEC 27001:2022 tarjoaa käyttöjärjestelmän tähän ongelmaan. Sen kohdat edellyttävät, että organisaatio ymmärtää toimintaympäristön, sidosryhmät, lakisääteiset ja sopimusperusteiset vaatimukset, soveltamisalan, johtajuuden, roolit, riskien arvioinnin, riskien käsittelyn, soveltuvuuslausunnon, operatiivisen suunnittelun, suorituskyvyn arvioinnin, sisäisen auditoinnin, johdon katselmoinnin, poikkeamien käsittelyn ja jatkuvan parantamisen. Tämä rakenne soveltuu erinomaisesti NIS2:n, DORA:n, GDPR:n, asiakkaiden varmentamisen ja sisäisen riskin yhdistämiseen yhdeksi jatkuvan seurannan malliksi.

Jatkuva vaatimustenmukaisuus ei tarkoita lisää hallintanäkymiä. Se tarkoittaa hallittua näytön keruusykliä.

Rakenna vaatimustenmukaisuuden koneisto ISO/IEC 27001:2022 -standardin varaan

Monet organisaatiot ymmärtävät ISO/IEC 27001:2022 -standardin virheellisesti vain sertifiointiviitekehykseksi. Käytännössä se on riskienhallintajärjestelmä, jonka avulla tietoturvan hallinnasta tehdään toistettavaa, mitattavaa ja auditoitavissa olevaa.

Tällä on merkitystä, koska NIS2 ja DORA eivät ole erillisiä tarkistuslistoja. Ne edellyttävät toimintamallia, joka pystyy vastaanottamaan lakisääteiset vaatimukset, kääntämään ne kontrolleiksi, osoittamaan omistajuuden, seuraamaan suorituskykyä ja parantamaan toimintaa, kun puutteita havaitaan.

ISO/IEC 27001:2022 -standardin perustavat kohdat tarjoavat tämän mallin:

FinTechille, SaaS-palveluntarjoajalle, hallinnoidulle tietoturvapalvelulle tai finanssialan toimijoiden ICT-toimittajalle tämä rakenne estää päällekkäiset vaatimustenmukaisuusprojektit. Yksi ISMS voi kartoittaa velvoitteet kontrolleihin kerran ja hyödyntää näyttöä uudelleen NIS2:n, DORA:n, GDPR:n, NIST CSF 2.0:n, COBIT 2019:n, ISO/IEC 27001:2022 -sertifioinnin ja asiakkaiden varmennuskatselmusten tarpeisiin.

Aloita kontrollinomistajuudesta, älä työkaluista

Ensimmäinen epäonnistumismalli jatkuvassa vaatimustenmukaisuudessa on työkalulähtöinen toteutus. Yritys ostaa GRC-alustan, tuo siihen satoja vaatimuksia, osoittaa kaiken “tietoturvalle” ja kutsuu sitä jatkuvaksi seurannaksi. Kuuden kuukauden kuluttua hallintanäkymä on punainen, kehitystiimi kiistää haavoittuvuusnäytön, lakiasiat toteavat toimittajadokumenttien olevan puutteellisia eikä johto näe jäännösriskiä selkeästi.

ISO/IEC 27001:2022 välttää tämän edellyttämällä, että vastuut ja toimivaltuudet osoitetaan ja viestitään. NIS2 ja DORA vahvistavat samaa odotusta johdon vastuuvelvollisuuden, määritettyjen roolien ja valvonnan kautta.

Clarysecin Hallintoroolit ja vastuut -politiikka pk-yrityksille toteaa:

Jokainen tietoturvavastuun sisältävä rooli on kirjattava keskitettyyn lokiin ja hyväksyttävä kirjallisesti.

Tämä kohta on tärkeämpi kuin useimmat hallintanäkymät. Jos varmuuskopioinnin testauksella, haavoittuvuuksien korjaamisella, toimittajien due diligence -arvioinnilla, poikkeamien luokittelulla ja etuoikeutettujen käyttöoikeuksien katselmoinnilla ei ole nimettyjä omistajia, luotettavaa näytön keruusykliä ei ole.

Tietoturvapolitiikka tekee tästä operatiivista yritysympäristöissä:

Kerää ja säilytä auditointinäyttöä auditointeja ja kontrollikatselmointeja varten.

Se edellyttää myös kontrollien omistajilta, että he:

Raportoivat kontrollien suorituskyvystä sekä mahdollisista puutteista tai ongelmista ISMS-päällikölle.

Zenith Controls -oppaassa tämä aihe kytkeytyy suoraan ISO/IEC 27002:2022 -standardin kontrolliin 5.2 tietoturvaroolit ja -vastuut, 5.35 tietoturvan riippumaton katselmointi ja 5.36 tietoturvapolitiikkojen, -sääntöjen ja -standardien noudattaminen.

Zenith Blueprint antaa käytännön lähtökohdan ISMS Foundation & Leadership -vaiheen vaiheessa 4: roolit ja vastuut ISMS:ssä. Se suosittelee muodollista nimittämistä, tehtävänkuvausten päivityksiä, KPI-yhdenmukaistusta, koko organisaatiolle tehtävää viestintää ja osastotason vastuuta.

Tyypillinen nimityskirjaus voi kuulua näin:

“Tästä päivästä alkaen sinut nimitetään tietoturvavastaavaksi, jonka vastuulla on valvoa ja koordinoida ISMS:ää, mukaan lukien riskienhallinta, kontrollien toteutus ja vaatimustenmukaisuuden seuranta.”

Tämä nimitys ei ole byrokratiaa. Se on auditointinäyttöä ISO/IEC 27001:2022 -standardin johtajuudesta ja roolien osoittamisesta. Se tukee myös NIS2:n johdon valvontaa ja DORA:n hallintoa. Valvojat, sertifiointiauditoijat ja pankkiasiakkaat haluavat nähdä, ettei vastuu ole oletettu. Se on osoitettu, hyväksytty, resursoitu ja seurattu.

Käytännöllisen kontrollinomistajuusrekisterin tulee sisältää seuraavat kentät:

Tästä rekisteristä tulee silta politiikan ja todentavan aineiston välille.

Määritä KPI- ja KRI-mittarit, jotka osoittavat kontrollien vaikuttavuuden

Kun omistajat on nimetty, heidän on tiedettävä, miltä “hyvä” näyttää. Vaatimustenmukaisuuden jatkuva seuranta perustuu merkityksellisiin indikaattoreihin, ei yleisluonteisiin aikomuksiin.

“Paranna paikkausta” ei ole KPI. “Katselmoi toimittajat säännöllisesti” ei ole näyttöä. “Ylläpidä häiriönsietokykyä” ei ole mitattava kontrolli.

Clarysec erottaa kaksi indikaattorityyppiä selkeästi:

• KPI eli keskeinen suorituskykymittari mittaa, toimiiko prosessi odotetusti.
• KRI eli keskeinen riski-indikaattori viestii kasvavasta riskistä tai kynnysarvon ylittymisestä, joka edellyttää eskalointia.

Yritystason Riskienhallintapolitiikka toteaa:

Kriittisille riskeille on määritettävä KRI-mittarit (keskeiset riski-indikaattorit) ja tietoturvamittarit, ja niitä on seurattava kuukausittain.

Se edellyttää myös eskalointilogiikkaa:

Eskalointiherätteet on sisällytettävä seurantamalliin (esimerkiksi tilanteissa, joissa jäännösriski kasvaa yli yhdellä tasolla tai riskienkäsittelyn määräajat ylittyvät).

Pienemmille organisaatioille Clarysecin Riskienhallintapolitiikka pk-yrityksille tarjoaa oikeasuhtaisen lähestymistavan:

Riskien lieventämisen edistymistä on katselmoitava neljännesvuosittain.

Se sallii myös kevyet mittarit:

Epämuodollisia mittareita voidaan seurata (esimerkiksi avoimien riskien määrä, määräajan ylittäneet toimenpiteet ja uudet poikkeamat).

Tämä oikeasuhtaisuus on tärkeää. Monikansallinen pankki ja 60 hengen FinTech-toimittaja eivät tarvitse identtistä telemetriaa, mutta molemmat tarvitsevat osoitetun omistajuuden, toistettavan mittauksen, eskalointikynnykset ja näytön korjaavista toimenpiteistä.

Käytännöllinen KPI- ja KRI-malli NIS2:lle ja DORA:lle näyttää tältä:

Nämä mittarit tukevat muutakin kuin ISO/IEC 27001:2022 -sertifiointia. Ne tukevat myös NIS2:n kyberturvallisuuden riskienhallintatoimenpiteitä, NIS2:n poikkeamaraportointivalmiutta, DORA:n ICT-riskien hallintaa, DORA:n kolmansien osapuolten riskejä, GDPR:n osoitusvelvollisuutta, NIST CSF 2.0:n hallintotuloksia ja COBIT-tyyppistä suorituskyvyn hallintaa.

Määritä näytön keruusykli ennen kuin auditointi pyytää sitä

Monet organisaatiot keräävät näyttöä sattumanvaraisesti. Kuvakaappaus ilmestyy Teams-kanavaan. Jira-tiketti linkitetään sähköpostiin. Toimittajakysely tallennetaan hankintaan. Varmuuskopiointitesti kuvataan suullisesti. Auditointiviikolla ISMS-päälliköstä tulee forensinen tutkija.

Jatkuva vaatimustenmukaisuus edellyttää suunniteltua sykliä ja hyvää näyttöhygieniaa.

Clarysecin Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille toteaa:

Jokaisella auditoinnilla on oltava määritetty soveltamisala, tavoitteet, vastuuhenkilöt ja vaadittava näyttö.

Se sanoo myös:

Näyttöä on säilytettävä vähintään kaksi vuotta tai pidempään, jos sertifiointi tai asiakassopimukset sitä edellyttävät.

Yritystason organisaatioille Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka lisää automaatio-odotuksia:

Automaattisia työkaluja on otettava käyttöön konfiguraation vaatimustenmukaisuuden, haavoittuvuuksien hallinnan, paikkaustilan ja etuoikeutettujen käyttöoikeuksien seurantaan.

Automaation tulee olla kohdennettua. Korkean riskin ja tiheästi toistuvien kontrollien ei tule riippua manuaalisista kuvakaappauksista. Paras näyttömalli yhdistää automatisoidun telemetrian, omistajien varmennukset, poikkeuslokit, tikettitiedot, testitulokset ja johdon katselmoinnin pöytäkirjat.

Myös nimeämiskäytännöllä on merkitystä. Näytön on oltava löydettävissä ilman poikkeuksellista vaivannäköä. Esimerkiksi:

• viikoittainen haavoittuvuusraportti: YYYY-MM-DD_Vulnerability-SLA_ControlOwner
• kuukausittainen etuoikeutettujen käyttöoikeuksien katselmointi: YYYY-MM_IAM-Privileged-Review_Attestation
• neljännesvuosittainen toimittajakatselmointi: YYYY-QX_Critical-Supplier-Review
• poikkeamapaketti: INC-YYYY-###_Timeline-Classification-RCA-CAPA

Tässä kohtaa politiikasta tulee operatiivista. Näytön säilyttäminen ei ole arkistointitehtävä. Se on osa kontrollia.

Kartoita yksi näyttökohde moniin velvoitteisiin

Jatkuva vaatimustenmukaisuus muuttuu tehokkaaksi, kun yksi näyttökohde täyttää useiden viitekehysten vaatimuksia. Siksi Zenith Controls on keskeinen osa Clarysecin vaatimustenmukaisuuksien välistä lähestymistapaa.

Tarkastellaan poikkeamien käsittelyä. NIS2:n mukaan merkittävät poikkeamat edellyttävät vaiheittaista raportointia, mukaan lukien varhaisvaroitus 24 tunnin kuluessa tietoisuudesta, ilmoitus 72 tunnin kuluessa ja loppuraportti yhden kuukauden kuluessa kansallisesta täytäntöönpanosta ja poikkeaman tosiseikoista riippuen. DORA edellyttää, että finanssialan toimijat hallitsevat, luokittelevat, eskaloivat ja raportoivat merkittävät ICT:hen liittyvät poikkeamat vaadittujen prosessien ja mallipohjien mukaisesti. GDPR edellyttää, että rekisterinpitäjät arvioivat ja hallitsevat henkilötietojen tietoturvaloukkauksia, kun henkilötietojen luottamuksellisuus, eheys tai saatavuus vaarantuu.

Yksi poikkeaman näyttöpaketti voi tukea kaikkia kolmea, jos se sisältää:

• poikkeaman aikajanan ja tietoisuuden ajankohdan;
• luokitteluperustelun;
• vaikutuksen kohteena olevat palvelut ja lainkäyttöalueet;
• asiakas-, tapahtuma- tai käyttäjävaikutuksen;
• henkilötietojen vaikutusten arvioinnin;
• juurisyyn;
• lieventävät ja palauttavat toimet;
• viestinnän ja ilmoitukset;
• johdon eskalointikirjauksen;
• korjaavan toimenpiteen merkinnän.

Sama vaatimustenmukaisuuksien välinen logiikka koskee toimittajariskiä. NIS2 edellyttää toimitusketjun tietoturvaa ja huomiota suoriin toimittaja- ja palveluntarjoajasuhteisiin. DORA edellyttää ICT-kolmansien osapuolten riskistrategiaa, rekistereitä, sopimusta edeltävää due diligence -arviointia, sopimuslausekkeita, auditointioikeuksia, palvelutasoja, irtautumisstrategioita ja keskittymäriskin seurantaa. NIST CSF 2.0 käsittelee toimitusketjuriskiä elinkaaren mittaisena hallintokäytäntönä. ISO/IEC 27001:2022 kytkee nämä vaatimukset soveltamisalaan, sidosryhmävaatimuksiin, riskien käsittelyyn ja ulkoistettujen prosessien operatiiviseen hallintaan.

Käytännöllinen näyttömatriisi auttaa kontrollien omistajia ymmärtämään, miksi näytöllä on merkitystä:

Tämä lähestymistapa estää päällekkäisen vaatimustenmukaisuustyön. Organisaatio kerää yhden vahvan näyttökokonaisuuden ja kartoittaa sen useisiin velvoitteisiin.

Clarysecin seurantamalli: velvoitteesta omistajaan ja todentavaan aineistoon

Vahva seurantamalli noudattaa yksinkertaista järjestystä.

Ensiksi määritetään velvoite. DORA esimerkiksi edellyttää, että ICT-kolmansien osapuolten riskiä hallitaan osana ICT-riskien hallintaa rekisterien, due diligence -arvioinnin, sopimusvaatimusten, auditointioikeuksien ja kriittisiä tai tärkeitä toimintoja koskevien irtautumisstrategioiden avulla. NIS2 edellyttää toimitusketjun tietoturvaa ja asianmukaisia korjaavia toimenpiteitä.

Toiseksi velvoite käännetään ISO/IEC 27001:2022 -standardin ISMS-vaatimuksiksi. Tähän kuuluvat sidosryhmävaatimukset, soveltamisala, riskien arviointi, riskien käsittely, soveltuvuuslausunto, operatiivinen hallinta, seuranta, sisäinen auditointi, johdon katselmointi ja parantaminen.

Kolmanneksi valitaan operatiiviset kontrollit. Zenith Controls -oppaassa jatkuvan vaatimustenmukaisuuden keskeisiin hallintokontrolleihin kuuluvat ISO/IEC 27002:2022 -kontrollit 5.2, 5.35 ja 5.36. Tukikontrolleihin sisältyvät usein 5.19 toimittajasuhteiden tietoturva, 5.21 tietoturvan hallinta ICT-toimitusketjussa, 5.22 toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta, 5.23 pilvipalvelujen käytön tietoturva, 5.24 tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu, 5.26 tietoturvapoikkeamiin reagointi, 5.30 ICT-valmius liiketoiminnan jatkuvuutta varten, 5.31 lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset vaatimukset, 8.8 teknisten haavoittuvuuksien hallinta, 8.13 tietojen varmuuskopiointi, 8.15 lokitus, 8.16 seurantatoiminnot ja 8.9 konfiguraationhallinta.

Neljänneksi osoitetaan omistaja ja keruusykli. Toimittajariski voi koskea hankintaa, lakiasioita, tietoturvaa ja liiketoimintapalvelun omistajaa, mutta yhden vastuullisen omistajan on ylläpidettävä rekisteriä ja raportoitava poikkeuksista.

Viidenneksi määritetään KPI:t, KRI:t ja näyttö. Toimittaja-KPI:t voivat sisältää kriittisten ICT-toimittajien osuuden, joille due diligence -arviointi on tehty, hyväksytyt sopimuslausekkeet sisältävien osuuden, testattuja irtautumissuunnitelmia vailla olevien määrän ja määräajan ylittäneiden toimittajakatselmointien määrän. KRI:t voivat sisältää ratkaisemattomat korkean riskin toimittajahavainnot, riskinsietorajan ylittävän keskittymäriskin tai puuttuvat auditointioikeudet palvelulta, joka tukee kriittistä tai tärkeää toimintoa.

Kuudenneksi raportoidaan ja eskaloidaan. Kuukausittaisten ISMS-hallintanäkymien ei pidä näyttää pelkkää vihreää tilaa. Niiden tulee tunnistaa myöhässä oleva näyttö, riskin muutos, ohitetut käsittelymääräajat ja johdon päätöstä edellyttävät asiat.

Seitsemänneksi auditoidaan ja parannetaan. Näyttöpuutteista tulee korjaavia toimenpiteitä, ei selityksiä.

Tämä vastaa Zenith Blueprint -mallin Audit, Review & Improvement -vaihetta. Vaihe 25, Internal Audit Program, suosittelee kattamaan olennaiset ISMS-prosessit ja -kontrollit auditointisyklin aikana, mukaan lukien vuosittainen koko soveltamisalan auditointi ja tarvittaessa pienemmät neljännesvuosittaiset pistokoetarkastukset korkean riskin alueille. Vaihe 28, Management Review, edellyttää syötteinä esimerkiksi vaatimusten muutoksia, seuranta- ja mittaustuloksia, auditointituloksia, poikkeamia, vaatimuksista poikkeamisia, parantamismahdollisuuksia ja resurssitarpeita. Vaihe 29, Continual Improvement, käyttää CAPA-lokia ongelman kuvauksen, juurisyyn, korjaavan toimenpiteen, vastuullisen omistajan, tavoitepäivän ja tilan kirjaamiseen.

Tämä on jatkuvaa vaatimustenmukaisuutta käytännössä.

Käytännön skenaario: kriittinen haavoittuvuus julkisessa API:ssa

Klo 02.15 SIEM-hälytys aktivoituu. Haavoittuvuusskannaus on tunnistanut kriittisen etäkoodin suorittamisen haavoittuvuuden julkisille rajapinnoille altistuvassa API-yhdyskäytävässä, joka tukee säänneltyä maksupalvelua.

Jatkuvan seurannan mallin tulee reagoida ilman kokouksen odottamista.

Ensiksi omaisuusluettelo luokittelee yhdyskäytävän kriittiseksi. Haavoittuvuuksien hallinnan KPI-kello käynnistyy. Korjaamattomien kriittisten haavoittuvuuksien KRI kasvaa. Jos omaisuuserä on internetiin avautuva ja hyväksikäyttömenetelmä on aktiivinen, eskalointikynnys laukeaa välittömästi.

Toiseksi tiketti ohjataan päivystävälle DevOps-tiimille. DevOps-johtaja saa haavoittuvuuksien hallinnan kontrollin omistajana automaattisen ilmoituksen. SOC-päällikkö seuraa, onko hyväksikäyttöindikaattoreita olemassa. ISMS-päällikkö seuraa, täyttyvätkö poikkeamakriteerit.

Kolmanneksi näyttöä kertyy työnkulun sivutuotteena. SIEM-hälytys, haavoittuvuusskannaus, omaisuuden luokittelu, tiketin aikaleimat, reagointikeskustelu, korjauspäivityskirjaus, validointiskannaus ja sulkemishyväksyntä liitetään näyttöpakettiin.

Neljänneksi tiimi arvioi, onko tapahtuma vain haavoittuvuus, tietoturvatapahtuma vai poikkeama. Jos palveluvaikutusta, vaarantumisen indikaattoreita, asiakasvaikutusta tai henkilötietojen altistumista ilmenee, poikkeamatyönkulku käynnistää NIS2-, DORA-, GDPR- ja sopimusperusteiset raportointiarvioinnit.

Viidenneksi johto saa tiiviin raportin. Jos haavoittuvuus korjattiin neljän tunnin kuluessa, näyttö tukee kontrollin vaikuttavuutta. Jos palvelutasosopimus ylittyi, CAPA-lokiin kirjataan juurisyy, korjaava toimenpide, omistaja, tavoitepäivä ja tila.

Tämä yksittäinen tapahtuma tuottaa hyödyllistä näyttöä haavoittuvuuksien hallintaan, poikkeamavalmiuteen, seurantaan, kriittisten omaisuuserien käyttöoikeuksiin, johdon katselmointiin ja jatkuvaan parantamiseen.

Miten auditoijat ja valvojat testaavat samaa seurantamallia

Kypsän jatkuvan vaatimustenmukaisuuden ohjelman on kestettävä erilaiset auditointinäkökulmat. Näyttö ei muutu, mutta kysymykset muuttuvat.

ISO/IEC 27002:2022 -kontrollin 5.35 tietoturvan riippumaton katselmointi osalta ISO/IEC 27001:2022 -auditoija keskittyy sisäisen auditoinnin suunnitelmaan, soveltamisalaan, pätevyyteen, havaintoihin ja korjaaviin toimenpiteisiin. NIS2- tai DORA-valvoja keskittyy siihen, ymmärsikö johto havainnot, rahoittiko se korjaamisen ja vähensikö se järjestelmätason riskiä. NIST CSF 2.0 -arvioija voi kartoittaa katselmoinnin GOVERN-toimintoon, mukaan lukien valvonta ja suorituskyvyn mukauttaminen.

Sama näyttökokonaisuus palvelee kaikkia, jos se on kattava, ajantasainen ja kytketty omistajuuteen.

Yleiset sudenkuopat, jotka heikentävät jatkuvaa vaatimustenmukaisuutta

Ensimmäinen sudenkuoppa on NIS2:n ja DORA:n käsitteleminen erillisinä projekteina. Se luo päällekkäisiä rekistereitä, ristiriitaisia mittareita ja kuormittuneita kontrollien omistajia. Käytä ISO/IEC 27001:2022 -standardia ISMS:n runkona ja kartoita velvoitteet yhden kontrollikirjaston kautta.

Toinen sudenkuoppa on kontrollien osoittaminen tiimeille henkilöiden sijaan. “IT omistaa varmuuskopiot” ei riitä. Nimetyn omistajan on annettava varmennus, raportoitava poikkeukset ja eskaloitava riski.

Kolmas sudenkuoppa on näytön kerääminen ilman vaikuttavuuden arviointia. Varmuuskopioinnin onnistumisesta otettu kuvakaappaus ei osoita palautuskelpoisuutta. Palautustesti osoittaa. Toimittajakysely ei osoita kolmannen osapuolen häiriönsietokykyä. Sopimuslausekkeet, auditointioikeudet, poikkeamien ilmoitusehdot, suorituskykyraportit ja irtautumissuunnittelu luovat vahvempaa näyttöä.

Neljäs sudenkuoppa on toiminnan mittaaminen riskin sijaan. Haavoittuvuuksien laskeminen on hyödyllistä. Määräajan ylittäneiden kriittisten haavoittuvuuksien seuraaminen internetiin avautuvissa järjestelmissä on parempaa. Toimittajien laskeminen on hyödyllistä. Kriittisten toimittajien seuraaminen ilman irtautumissuunnitelmia on parempaa.

Viides sudenkuoppa on heikko korjaavien toimenpiteiden kurinalaisuus. Zenith Blueprint -mallin vaihe 29 on selkeä: havainnot tarvitsevat ongelman kuvauksen, juurisyyn, korjaavan toimenpiteen, vastuullisen omistajan, tavoitepäivän ja tilan. Jos CAPA-lokia ei katselmoida, jatkuvasta vaatimustenmukaisuudesta tulee tunnettujen heikkouksien jatkuvaa kertymistä.

Mitä johdon tulisi nähdä joka kuukausi

NIS2:n ja DORA:n alaiset johdon toimielimet eivät tarvitse raakoja skannerivientejä. Ne tarvitsevat päätöksenteon kannalta laadukkaan näkymän kyber- ja ICT-riskiin.

Kuukausittaisen hallituksen tai johdon hallintanäkymän tulisi sisältää:

• merkittävimmät kyber- ja ICT-riskit sekä jäännösriskin muutos;
• määräajan ylittäneet riskienkäsittelyt ja ohitetut määräajat;
• merkittävät poikkeamat, merkittävien ICT:hen liittyvien poikkeamien ehdokkaat ja opit;
• kriittiset toimittajariskipoikkeukset;
• kriittisten omaisuuserien haavoittuvuuksien SLA-suorituskyky;
• varmuuskopiointi- ja palautustestien tila;
• etuoikeutettujen käyttöoikeuksien katselmointipoikkeukset;
• vaatimustenmukaisuusnäytön valmistumisaste;
• auditointihavainnot ja CAPA-tila;
• tarvittavat resurssipäätökset.

Tämä tukee suoraan ISO/IEC 27001:2022 -standardin johdon katselmointia sekä NIS2:n ja DORA:n hallinto-odotuksia. Se on myös linjassa NIST CSF 2.0:n kanssa, jossa ylin johto asettaa prioriteetit, vastuuvelvollisuuden, resurssit ja riskinottohalukkuuden, kun taas esihenkilöt kääntävät nämä prioriteetit tavoiteprofiileiksi ja toimintasuunnitelmiksi.

Rakenna NIS2:n ja DORA:n näyttörytmi tällä viikolla

Aloittaminen ei edellytä kaiken ratkaisemista kerralla. Hyödyllinen ensimmäinen viikko voi olla yksinkertainen.

Päivä 1: luo kontrollinomistajarekisteri viidelle osa-alueelle: hallinto ja riskienhallinta, poikkeamien hallinta ja raportointi, haavoittuvuuksien ja korjauspäivitysten hallinta, toimittaja- ja pilviriski sekä liiketoiminnan jatkuvuus ja palautus.

Päivä 2: määritä yksi KPI ja yksi KRI jokaiselle osa-alueelle. Pidä ne täsmällisinä, mitattavina ja riskinottohalukkuuteen kytkettyinä.

Päivä 3: kartoita jokainen näyttökohde NIS2:n, DORA:n, ISO/IEC 27001:2022 -standardin, GDPR:n ja asiakkaiden varmentamisen arvoon.

Päivä 4: määritä näytön keruusykli, säilytyssijainti, nimeämiskäytäntö, säilytyssääntö ja katselmoija.

Päivä 5: aja pöytäharjoituksen eskalointi. Käytä pilvipalvelukatkoa tai kriittisen haavoittuvuuden skenaariota. Vahvista luokittelu, sääntelyraportoinnin arviointi, asiakasviestintä, näytön tallennus ja CAPA-kirjauksen luonti.

Jos organisaatiosi hallitsee NIS2:ta ja DORA:a edelleen laskentataulukoilla, vuosittaisilla työpajoilla ja hajanaisilla näyttökansioilla, nyt on aika siirtyä seurattuun toimintarytmiin.

Aloita kolmella toimenpiteellä:

1. Rakenna kontrollinomistajarekisteri korkeimman riskin osa-alueille.
2. Määritä jokaiselle kontrollille yksi KPI, yksi KRI, yksi näyttökohde ja yksi keruusykli.
3. Pidä 30 minuutin näyttökatselmointi ja avaa CAPA-toimenpiteet kaikelle puuttuvalle.

Clarysec voi auttaa nopeuttamaan siirtymää Zenith Blueprint -mallilla toteutusjärjestykseen, Zenith Controls -oppaalla vaatimustenmukaisuuksien väliseen kartoitukseen sekä Clarysecin politiikkakirjastolla, johon kuuluvat Tietoturvapolitiikka, Riskienhallintapolitiikka, Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka, Hallintoroolit ja vastuut -politiikka pk-yrityksille, Riskienhallintapolitiikka pk-yrityksille ja Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille.

Tavoitteena ei ole lisätä vaatimustenmukaisuuden paperityötä. Tavoitteena on vastata perjantai-iltapäivän kysymykseen luottavaisesti:

“Kyllä, tiedämme kuka omistaa kontrollin, tiedämme KPI-mittarin, meillä on näyttö, tunnemme poikkeukset ja johto on katselmoinut riskin.”

Ota yhteyttä Claryseciin rakentaaksesi vaatimustenmukaisuuden jatkuvan seurannan mallin, joka on auditointi- ja hallitusvalmis sekä riittävän häiriönsietokykyinen NIS2:lle, DORA:lle ja seuraavalle tulevalle sääntelylle.