Auditointivalmis ISO 27001 -riskienarviointi NIS2- ja DORA-vaatimuksiin

Sarahin työpöydällä oleva kahvi oli jäähtynyt.

Nopeasti kasvavan fintech-yhtiön CISO:na hän oli tottunut paineeseen. Yhtiö oli juuri saanut merkittävän pankkikumppanin, ja näytöllä oleva due diligence -kysely olisi pitänyt olla muodollisuus. Ensimmäiset kysymykset olivat tuttuja: toimittakaa ISO/IEC 27001:2022 -soveltuvuuslausunto, jakakaa viimeisin riskirekisteri ja selittäkää riskienarviointimenetelmänne.

Sitten kysely muuttui.

Osoittakaa, miten riskienhallintaohjelmanne huomioi DORA:n. Selittäkää NIS2-valmiutenne, mukaan lukien johdon vastuu ja toimitusketjuriskien hallintatoimet. Toimittakaa näyttö siitä, että kriittiset ICT-toimittajat arvioidaan ja niitä seurataan ja että ne on huomioitu tietoturvapoikkeamiin reagoinnin ja liiketoiminnan jatkuvuussuunnitelmissa.

Maanantaiaamuun mennessä sama asia oli hallituksen riskivaliokunnan esityslistalla. ISO 27001 -sertifiointiauditointi olisi kahdeksan viikon kuluttua. Finanssisektorin asiakkaat edellyttivät DORA-valmiutta. Pilvipohjaisen palvelulinjan laajentuminen EU:hun nosti esiin NIS2-luokittelukysymyksiä. Hankinta kertoi, että toimittajakatselmointeja oli tehty, mutta näyttö oli hajallaan sähköposteissa, sopimuskansioissa ja toimittajataulukossa. Lakiasiat totesi, että sääntelykartoitus oli vielä kesken. Tuotekehitys sanoi, että riskirekisteri oli pääosin valmis.

Hallitus esitti ainoan kysymyksen, jolla oli merkitystä:

Voimmeko osoittaa, että riskienarviointimme ja riskienkäsittelysuunnitelmamme ovat riittäviä?

Tämä on todellinen ongelma SaaS-, fintech-, hallinnoitujen palvelujen, pilvipalvelujen ja digitaalisten alustojen yrityksille. Kyse ei ole siitä, onko riskirekisteri olemassa. Kyse ei ole siitä, onko liite A:n kontrollit kopioitu laskentataulukkoon. Kyse on siitä, pystyykö organisaatio osoittamaan auditointi- ja asiakaspaineessa, että sen ISO 27001 -riskienarviointiprosessi on toistettava, riskiperusteinen, riskinomistajien hyväksymä, sidottu käsittelytoimiin, kartoitettu lakisääteisiin velvoitteisiin ja aidosti käytössä operatiivisessa toiminnassa.

Hyvin toteutettuna yksi ISO 27001 -riskienarviointi ja yksi riskienkäsittelysuunnitelma voivat tukea ISO/IEC 27001:2022 -sertifiointia, NIS2 Article 21:n kyberturvallisuuden riskienhallintatoimenpiteitä, DORA:n ICT-riskienhallinnan vaatimuksia, GDPR:n osoitusvelvollisuutta, toimittajavarmennusta, poikkeamavalmiutta ja hallitusraportointia.

Huonosti toteutettuna siitä tulee laskentataulukko, jonka auditoijat purkavat kolmessakymmenessä minuutissa.

Tässä oppaassa kuvataan, miten Clarysec rakentaa auditointivalmista ISO 27001 -riskienarvioinnin ja riskien käsittelyn näyttöä hyödyntämällä Zenith Blueprint: auditoijan 30 vaiheen tiekarttaa, Clarysec-politiikkoja ja Zenith Controls: vaatimustenmukaisuuksien välistä opasta.

Miksi ISO 27001 -riskienarvioinnista on tullut vaatimustenmukaisuuden keskus

EU:n sääntely-ympäristö lähestyy samaa yksinkertaista periaatetta: kyberturvallisuusriskiä on hallittava, dokumentoitava, testattava ja vastuutettava.

ISO/IEC 27001:2022 toimii jo tällä tavalla. Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmänsä, ISMS:n soveltamisalan ja prosessien väliset yhteydet ennen riskien arviointia. Kohdat 6.1.2 ja 6.1.3 edellyttävät määriteltyä tietoturvariskien arviointi- ja käsittelyprosessia. Kohdat 8.2 ja 8.3 edellyttävät, että organisaatio suorittaa riskienarviointeja, toteuttaa riskienkäsittelysuunnitelman ja säilyttää dokumentoitua tietoa.

NIS2 ja DORA tekevät samasta riskiperusteisesta logiikasta kiireellisemmän.

NIS2 Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat niiden toteutusta ja osallistuvat kyberturvallisuuskoulutukseen. Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä verkko- ja tietojärjestelmiin kohdistuvien riskien hallitsemiseksi. Näihin toimenpiteisiin kuuluvat riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen kehittäminen, haavoittuvuuksien käsittely, vaikuttavuuden arviointi, kyberhygienia, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta sekä tarvittaessa monivaiheinen tunnistautuminen tai suojattu viestintä.

DORA kohdistaa vastaavaa painetta finanssialan toimijoihin. Articles 5 and 6 edellyttävät, että hallintoelin määrittää, hyväksyy ja valvoo ICT-riskienhallinnan järjestelyjä ja vastaa niistä edelleen. DORA edellyttää dokumentoitua ICT-riskienhallinnan viitekehystä, joka on integroitu kokonaisriskienhallintaan ja jota tukevat politiikat, menettelyt, protokollat, työkalut, sisäinen tarkastus, korjaavat toimenpiteet, jatkuvuus, testaus, poikkeamien hallinta ja ICT-palveluihin liittyvien kolmansien osapuolten hallinta.

Johtopäätös on käytännöllinen ja väistämätön: riskirekisteri ei ole enää teknisen tiimin työtaulukko. Se on hallinnon näyttöä.

Clarysecin Enterprise Riskienhallintapolitiikka tekee tästä odotuksesta nimenomaisen:

Muodollista riskienhallintaprosessia on ylläpidettävä ISO/IEC 27005:n ja ISO 31000:n mukaisesti, ja sen on katettava riskien tunnistaminen, analysointi, arviointi, käsittely, seuranta ja viestintä.

Enterprise Riskienhallintapolitiikka, kohta ”Hallintavaatimukset”, politiikkalauseke 5.1.

Sama politiikka määrittää auditointivalmiin lopputuloksen:

Keskitettyä ja versionhallittua riskirekisteriä ja riskienkäsittelysuunnitelmaa on ylläpidettävä siten, että ne kuvaavat riskien nykytilaa, kontrollien kattavuutta ja riskien pienentämisen etenemistä.

Enterprise Riskienhallintapolitiikka, kohta ”Tavoitteet”, politiikkalauseke 3.3.

Ilmaus ”riskien nykytila, kontrollien kattavuus ja riskien pienentämisen eteneminen” erottaa staattisen vaatimustenmukaisuustiedoston puolustettavasta riskienhallintaohjelmasta.

Aloita soveltamisalasta, velvoitteista ja riskikriteereistä

Monet heikot ISO 27001 -riskienarvioinnit alkavat kontrollien tarkistuslistasta. Se on väärä järjestys.

ISO 27001 edellyttää, että organisaatio määrittää toimintaympäristön, sidosryhmien vaatimukset, ISMS:n soveltamisalan, johdon vastuut ja riskienhallinnan suunnittelun ennen kontrollien valintaa. ISO/IEC 27005:2022 vahvistaa tätä ohjeistamalla organisaatioita tunnistamaan sidosryhmien perusvaatimukset ennen riskienarviointia. Nämä vaatimukset voivat perustua ISO-standardeihin, toimialasääntelyyn, kansallisiin lakeihin, asiakassopimuksiin, sisäisiin politiikkoihin, aiempiin käsittelytoimiin ja toimittajavelvoitteisiin.

EU-markkinoille suuntautuvan SaaS- tai fintech-yhtiön riskiprosessin tulisi alkaa vaatimustenmukaisuus- ja velvoiteinventaarilla.

Pk-yrityksille Clarysecin Laki- ja sääntelyvaatimusten noudattamisen politiikka - SME asettaa lähtökohdan:

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

SME Laki- ja sääntelyvaatimusten noudattamisen politiikka, kohta ”Hallintavaatimukset”, politiikkalauseke 5.1.1.

Tämä yksinkertainen rekisteri toimii siltana vaatimustenmukaisuuden ja riskienhallinnan välillä. Jos siinä todetaan, että GDPR soveltuu, koska EU:n henkilötietoja käsitellään, NIS2 voi soveltua, koska organisaatio tarjoaa digitaalisia tai hallinnoituja palveluja, tai DORA on merkityksellinen finanssisektorin asiakkaiden kautta, näiden velvoitteiden on vaikutettava riskikriteereihin ja riskien käsittelyn prioriteetteihin.

Zenith Blueprint käsittelee tätä suoraan Riskienhallinta-vaiheen Step 10:ssä ”Riskikriteerien ja vaikutusmatriisin määrittäminen”:

Huomioi hyväksymiskriteereissä myös lakisääteiset ja sääntelyyn perustuvat vaatimukset. Jotkin riskit voivat olla hyväksymättömiä todennäköisyydestä riippumatta lakien vuoksi.

Zenith Blueprint, Riskienhallinta-vaihe, Step 10.

Se antaa myös käytännön säännön työpajoihin:

”Kaikki riskit, jotka voivat johtaa sovellettavien lakien noudattamatta jättämiseen (GDPR jne.), eivät ole hyväksyttäviä, ja ne on lievennettävä.”

Zenith Blueprint, Riskienhallinta-vaihe, Step 10.

Sarahin fintech-yhtiössä tämä muuttaa pisteytysmallia. Toimittajan ohjelmointirajapinnan haavoittuvuuden todennäköisyys voi olla pieni, mutta jos sen hyväksikäyttö voisi laukaista DORA:n mukaisen merkittävän ICT:hen liittyvän poikkeaman, NIS2:n mukaisen merkittävän poikkeaman, GDPR:n mukaisen tietoturvaloukkauksen arvioinnin, asiakkaan SLA:n epäonnistumisen tai hallitustason eskaloinnin, vaikutus on suuri tai kriittinen. Vaatimustenmukaisuusaltistus kuuluu riskilogiikkaan, ei erilliseen laskentataulukkoon.

Rakenna riskirekisteri, jota auditoijat voivat testata

Auditoijat eivät kysy vain, mitkä ovat merkittävimmät riskinne. He testaavat, onko menetelmä määritelty, toistettava, jäljitettävä ja noudatettu.

He kysyvät:

• Miten nämä riskit tunnistettiin?
• Mitkä omaisuuserät, palvelut, toimittajat, tietotyypit ja prosessit olivat soveltamisalassa?
• Mitä kriteerejä käytettiin todennäköisyyden ja vaikutuksen arviointiin?
• Kuka omistaa kunkin riskin?
• Mitkä nykyiset kontrollit pienentävät riskiä?
• Miksi valittu käsittelypäätös tehtiin?
• Missä on näyttö siitä, että käsittely toteutettiin?
• Kuka hyväksyi jäännösriskin?
• Milloin riski arvioidaan uudelleen?

Clarysecin Riskienhallintapolitiikka - SME kuvaa riskimerkinnän vähimmäissisällön auditointia varten:

Jokaisen riskimerkinnän on sisällettävä kuvaus, todennäköisyys, vaikutus, pisteytys, omistaja ja riskienkäsittelysuunnitelma.

SME Riskienhallintapolitiikka, kohta ”Hallintavaatimukset”, politiikkalauseke 5.1.2.

Yritystason ohjelmissa Zenith Blueprint laajentaa rakennetta Riskienhallinta-vaiheen Step 11:ssä ”Riskirekisterin rakentaminen ja dokumentointi”. Se suosittelee sarakkeita, kuten riskitunnus, omaisuuserä, uhka, haavoittuvuus, riskikuvaus, todennäköisyys, vaikutus, riskitaso, nykyiset kontrollit, riskinomistaja, käsittelypäätös, riskienkäsittelysuunnitelma tai kontrollit sekä tila.

Vahva riskimerkintä näyttää tältä:

Tämä eroaa olennaisesti merkinnästä ”Kolmannen osapuolen riski, korkea, lievennä”. Auditointivalmis versio yhdistää omaisuuserän, uhan, haavoittuvuuden, seurauksen, nykyiset kontrollit, omistajan, sääntelyn, näytön ja hallinnon.

Muuta riskien käsittely näyttösuunnitelmaksi

Riskienkäsittelysuunnitelman on vastattava neljään operatiiviseen kysymykseen:

1. Mitä teemme?
2. Kuka omistaa sen?
3. Milloin se valmistuu?
4. Miten osoitamme, että se pienensi riskiä?

ISO/IEC 27001:2022 kohta 6.1.3 edellyttää, että organisaatio valitsee riskien käsittelyvaihtoehdot, määrittää tarvittavat kontrollit, vertaa niitä liite A:han puutteiden välttämiseksi, tuottaa soveltuvuuslausunnon, laatii riskienkäsittelysuunnitelman ja hankkii riskinomistajan hyväksynnän suunnitelmalle ja jäännösriskeille. Kohta 8.3 edellyttää tämän jälkeen riskienkäsittelysuunnitelman toteutusta ja tuloksia koskevan dokumentoidun tiedon säilyttämistä.

Enterprise Riskienhallintapolitiikka tekee tästä käytännöllistä:

Riskivastaavan on varmistettava, että käsittelytoimet ovat realistisia, aikarajattuja ja kartoitettu ISO/IEC 27001 liite A:n kontrolleihin.

Enterprise Riskienhallintapolitiikka, kohta ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.4.2.

SME-politiikka selventää myös, ettei hyväksyntä ole oikotie:

Hyväksy: Perustele, miksi lisätoimia ei tarvita, ja kirjaa jäännösriski.

SME Riskienhallintapolitiikka, kohta ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.1.1.

Hyväksynnän on perustuttava kriteereihin, oikean omistajan hyväksyntään ja seurantaan. NIS2:n ja DORA:n näkökulmasta hyväksymätön jäännösriski voi muodostua hallintapuutteeksi.

Täydellisen riskienkäsittelysuunnitelman tulisi sisältää nämä kentät:

Sarahin R-042-riskin osalta riskienkäsittelysuunnitelmasta tulee vaatimustenmukaisuuksien välinen toimenpidelista.

Tämä suunnitelma on vahva, koska se luo suoran yhteyden yhdestä riskiskenaariosta ISO 27001 -kontrolleihin, NIS2-velvoitteisiin, DORA-artikloihin, omistajiin ja näyttöön.

Hyödynnä soveltuvuuslausuntoa laajemmin

Soveltuvuuslausuntoa käsitellään usein sertifiointiartefaktina. Sen tulisi olla enemmän.

ISO/IEC 27001:2022 kohta 6.1.3 edellyttää, että SoA sisältää tarvittavat kontrollit, perustelut sisällyttämiselle, toteutustilan ja perustelut poissulkemisille. ISO/IEC 27005:2022 -ohjeistus vahvistaa tarvetta verrata valittuja kontrolleja ISO/IEC 27001 liite A:han puutteiden välttämiseksi.

Auditointivalmiissa ohjelmassa SoA:sta tulee silta riskien käsittelyn ja vaatimustenmukaisuuksien välisen näytön välillä. Jos riskienkäsittelysuunnitelma edellyttää MFA:ta, lokitusta, toimittajien seurantaa, varmuuskopioiden palautusta, turvallista kehittämistä, poikkeamien eskalointia tai pilvipalvelusta irtautumisen suunnittelua, SoA:n tulisi osoittaa, että asiaankuuluvat liite A:n kontrollit on sisällytetty, perusteltu, toteutettu tai suunniteltu ja näytetty toteen.

Tämä auttaa myös välttämään yleisen auditointihavainnon: riskirekisteri sanoo yhtä, riskienkäsittelysuunnitelma toista ja SoA vaikenee. Kun nämä artefaktit ovat ristiriidassa, auditoijat menettävät nopeasti luottamuksensa.

ISO 27001 -riskien käsittelyn kartoitus NIS2:een, DORA:an ja GDPR:ään

ISO 27001 ei korvaa NIS2:ta, DORA:a tai GDPR:ää. Se tarjoaa jäsennellyn mekanismin niiden edellyttämän näytön tuottamiseen.

Keskeistä on rakentaa kartoitus riskiprosessiin sen sijaan, että se liimataan päälle myöhemmin.

Tämä kartoitus on erityisen tärkeä silloin, kun sääntelyt menevät päällekkäin. DORA on monille finanssialan toimijoille toimialakohtainen ICT-häiriönsietokyvyn sääntelykehikko, kun taas NIS2 voi edelleen olla suoraan merkityksellinen tietyille palveluntarjoajille, koordinoinnille tai DORA:n soveltamisalan ulkopuolisille toimijoille. Fintech-yhtiölle DORA voi olla ensisijainen ICT-häiriönsietokyvyn viitekehys, kun taas kyseistä fintech-yhtiötä tukeva hallinnoitu palveluntarjoaja voi olla suoraan NIS2-velvoitteiden piirissä.

Riskirekisterin on pystyttävä osoittamaan riippuvuuden molemmat puolet.

Käytä Zenith Controlsia vaatimustenmukaisuuksien välisenä kompassina

Clarysec käyttää Zenith Controlsia vaatimustenmukaisuuksien välisenä oppaana estääkseen yleisen epäonnistumisen, jossa ISO-kontrollit, sääntelyartiklat ja auditointikysymykset elävät erillisissä maailmoissa. Se ei luo erillistä kontrolliviitekehystä. Se kartoittaa ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -kontrollialueet muihin standardeihin, auditointiodotuksiin ja vaatimustenmukaisuusnäkökulmiin.

ISO 27001 -riskienarvioinnin ja riskien käsittelyn kannalta nämä viitteet ovat erityisen tärkeitä:

Vaatimustenmukaisuuksien välinen opetus on yksinkertainen. Jos lakisääteiset velvoitteet eivät ole mukana riskienarviointimenetelmässä, pisteytys on puutteellinen. Jos pisteytys on puutteellinen, käsittelyprioriteetit voivat olla vääriä. Jos prioriteetit ovat vääriä, SoA:sta ja hallitusraportoinnista tulee epäluotettavia.

Zenith Blueprint tekee saman havainnon Riskienhallinta-vaiheen Step 14:ssä ”Riskien käsittelyn politiikat ja sääntelyviitteet”. Se ohjeistaa organisaatioita luomaan kartoitustaulukon, jossa luetellaan keskeiset sääntelyyn perustuvat turvallisuusvaatimukset ja niitä vastaavat ISMS:n kontrollit tai politiikat. Tämä ei ole pakollista ISO 27001 -sertifioinnissa, mutta se on erittäin hyödyllistä osoitettaessa, että turvallisuutta hallitaan lakisääteisessä ja sopimusperusteisessa kontekstissa.

Mitä eri auditoijat kysyvät

Sertifiointiauditoija, NIS2-arvioija, DORA-suuntautunut asiakas, GDPR-arvioija, NIST-arvioija tai COBIT-asiantuntija voi tarkastella samaa näyttöä mutta esittää eri kysymyksiä.

Siksi näyttöarkkitehtuurilla on merkitystä. Saman riskimerkinnän tulisi olla jäljitettävissä liiketoimintatavoitteesta omaisuuserään, uhkaan, haavoittuvuuteen, kontrolliin, omistajaan, sääntelyperusteeseen, käsittelytoimeen, testitulokseen ja johdon päätökseen.

Clarysec-politiikat on suunniteltu tukemaan tätä arkkitehtuuria. Enterprise Riskienhallintapolitiikka toteaa kohdassa ”Viitestandardit ja viitekehykset”:

Article 5: Edellyttää dokumentoitua ICT-riskienhallinnan viitekehystä, jonka tämän politiikan rakenne kattaa kokonaan, mukaan lukien SoA-kartoitus ja KRI:t.

Tämä muuttaa politiikan staattisesta asiakirjasta auditointinäytöksi, joka osoittaa, että ICT-riskien hallinta on suunniteltu tarkoituksellisesti DORA huomioiden.

Yleiset havainnot, jotka rikkovat riskiohjelmat

Kun Clarysec katselmoi ISO 27001 -riskienarvioinnin ja riskien käsittelyn näyttöä, samat havainnot toistuvat.

Ensinnäkin riskikriteerit sivuuttavat lakisääteisen, sääntelyyn perustuvan, sopimusperusteisen, toimittajiin liittyvän ja tietosuojavaikutuksen. Tämä johtaa heikkoon pisteytykseen. Henkilötietojen tietoturvaloukkaus tai kriittisen toimittajan epäonnistuminen voidaan arvioida keskitasoiseksi, koska todennäköisyys on pieni, vaikka GDPR-, NIS2-, DORA- tai asiakasvaikutuksen tulisi nostaa se korkeaksi tai kriittiseksi.

Toiseksi riskinomistajat ovat geneerisiä. ”IT” ei ole riskinomistaja. Riskinomistajan tulisi olla rooli tai henkilö, joka vastaa käsittelypäätöksistä, budjetista, aikataulusta ja jäännösriskistä.

Kolmanneksi riskienkäsittelysuunnitelmat eivät ole aikarajattuja. ”Paranna seurantaa” ei ole suunnitelma. ”Ota käyttöön etuoikeutettujen istuntojen hälytykset SIEMissä tuotannon ylläpitotileille 30. kesäkuuta mennessä, omistajana SOC-päällikkö, testattu simuloidulla ylläpitokirjautumisella ja hälytysnäyttö liitettynä” on suunnitelma.

Neljänneksi SoA on irti riskien käsittelystä. Jos riskienkäsittelysuunnitelma edellyttää toimittajien seurantaa, varmuuskopiointitestausta, poikkeamien eskalointia, MFA:ta tai lokitusta, SoA:n tulisi kuvata asiaankuuluvat kontrollit ja niiden toteutustila.

Viidenneksi jäännösriskiä ei ole hyväksytty. ISO 27001 edellyttää, että riskinomistaja hyväksyy riskienkäsittelysuunnitelman ja jäännösriskit. NIS2 ja DORA tekevät tästä vielä tärkeämpää, koska johdon vastuu on nimenomainen.

Kuudenneksi toimittajariskiä käsitellään hankinnan hallintotehtävänä. NIS2 Article 21(2)(d):n ja DORA Articles 28 and 30:n mukaan toimittaja- ja ICT-palveluihin liittyvien kolmansien osapuolten riskien on oltava osa riskienhallintaa, ei erillään säilytettävä vuosittainen kyselylomake.

Seitsemänneksi vaikuttavuudesta ei ole näyttöä. ISO 27001 kohta 6.1.1 edellyttää, että suunniteltujen toimenpiteiden vaikuttavuus arvioidaan. NIS2 sisältää vaikuttavuuden arvioinnin Article 21(2)(f):ssä. DORA edellyttää testausta ja korjaavia toimenpiteitä. Kontrolli, joka on olemassa mutta jota ei koskaan testata, on heikkoa näyttöä.

SME Riskienhallintapolitiikka - SME asettaa odotuksen selkeästi:

Toimitusjohtajan ja riskikoordinaattorin on varmistettava, että riskienhallintatoimet ovat auditointivalmiita. Riskirekisteri ja siihen liittyvät toimet kuuluvat sisäisen ja ulkoisen auditoinnin piiriin.

SME Riskienhallintapolitiikka, kohta ”Soveltaminen ja vaatimustenmukaisuus”, politiikkalauseke 8.2.1.

Hallitusraportointi ilman johdon hukuttamista yksityiskohtiin

NIS2, DORA ja ISO 27001 osoittavat kaikki kohti johdon vastuuta, mutta hallitukset eivät tarvitse jokaista riskiriviä. Ne tarvitsevat päätöksentekoa tukevaa raportointia.

Hyvän hallituksen riskipaketin tulisi näyttää:

• Korkeat ja kriittiset riskit osa-alueittain
• Myöhässä olevat käsittelytoimet
• Sääntelyriskit, jotka liittyvät NIS2:een, DORA:an, GDPR:ään tai sopimuksiin
• Toimittajariskit, jotka vaikuttavat kriittisiin tai tärkeisiin palveluihin
• Poikkeama- ja läheltä piti -trendit
• Hyväksyntää odottavat jäännösriskit
• Kontrollien vaikuttavuustestien tulokset
• Olennaiset muutokset soveltamisalaan, toimittajiin, teknologiaan tai lainsäädäntöön
• Sisäisen tarkastuksen havainnot ja korjaavat toimenpiteet

Clarysec suosittelee yleensä kuukausittaisia operatiivisia riskikatselmointeja ja neljännesvuosittaisia johdon katselmuksia. Kuukausittaiset katselmoinnit keskittyvät käsittelytoimien toteutukseen. Neljännesvuosittaiset katselmukset keskittyvät hyväksyntään, rahoitukseen, priorisointiin, sääntelyaltistukseen ja strategisiin riskipäätöksiin.

Tämä rytmi tukee myös jatkuvaa parantamista. Riskienarvioinnit tulisi päivittää, kun poikkeamia tapahtuu, haavoittuvuuksia ilmenee, uusia omaisuuseriä otetaan käyttöön, teknologia muuttuu, toimittajat vaihtuvat, lait muuttuvat, asiakasvelvoitteet muuttuvat tai riskinottohalukkuus muuttuu.

Clarysecin toteutuspolku

Yhtenäinen riskiohjelma välttää irralliset ISO-, NIS2-, DORA-, GDPR- ja asiakasvarmennuksen laskentataulukot. Käytännön polku on seuraava:

1. Vahvista ISMS:n soveltamisala, palvelut, omaisuuserät, toimittajat, lainkäyttöalueet ja asiakasvelvoitteet.
2. Rakenna tai päivitä vaatimustenmukaisuusrekisteri käyttäen tarvittaessa Laki- ja sääntelyvaatimusten noudattamisen politiikka - SME -politiikkaa.
3. Määritä riskimenetelmä, hyväksymiskriteerit, todennäköisyysasteikot, vaikutusasteikot ja sääntelyvaikutusta koskevat säännöt.
4. Rakenna riskirekisteri hyödyntämällä Zenith Blueprintin Riskienhallinta-vaihetta ja Clarysecin Risk Register and SoA Builder -lähestymistapaa.
5. Tunnista omaisuuseräperusteiset ja skenaariopohjaiset riskit, mukaan lukien toimittaja-, pilvi-, tietosuoja-, jatkuvuus-, poikkeama-, haavoittuvuus-, turvallisen kehittämisen ja pääsynhallinnan skenaariot.
6. Pisteytä riskit kriteereillä, jotka sisältävät lakisääteisen, sääntelyyn perustuvan, sopimusperusteisen, operatiivisen, tietosuoja-, toimittaja- ja taloudellisen vaikutuksen.
7. Valitse käsittelyvaihtoehdot: lievennä, vältä, siirrä tai hyväksy.
8. Kartoita tarvittavat kontrollit ISO/IEC 27001:2022 liite A:han ja ISO/IEC 27002:2022 -ohjeistukseen.
9. Luo tai päivitä soveltuvuuslausunto.
10. Kartoita käsittelytoimet NIS2 Article 21:een, DORA:n ICT-riskienhallinnan ja kolmansia osapuolia koskeviin odotuksiin, GDPR:n osoitusvelvollisuuteen ja asiakkaiden sopimusvelvoitteisiin.
11. Kerää näyttö, validoi kontrollien vaikuttavuus ja hanki jäännösriskin hyväksyntä.
12. Valmistele auditointipaketti, joka on järjestetty riskin, kontrollin, sääntelyn ja näyttöartefaktin mukaan.
13. Syötä tulokset johdon katselmukseen, sisäiseen tarkastukseen, korjaaviin toimenpiteisiin ja jatkuvaan parantamiseen.

Tämä ei ole paperityötä paperityön vuoksi. Se on puolustettavan kyberhallinnon käyttöjärjestelmä.

Rakenna auditointivalmis riskienkäsittelypaketti

Sarahin tarina päättyy hyvin, koska hän lakkasi käsittelemästä ISO 27001:tä, NIS2:ta ja DORA:a erillisinä vaatimustenmukaisuushankkeina. Hän käytti ISO 27001 -riskienarviointia keskeisenä moottorina, sisällytti sääntelyvelvoitteet riskikriteereihin, kartoitti käsittelytoimet liite A:han ja EU-vaatimuksiin sekä keräsi näyttöä, jonka asiakkaat, auditoijat ja hallitus pystyivät ymmärtämään.

Organisaatiosi voi tehdä samoin.

Käytä Zenith Blueprint: auditoijan 30 vaiheen tiekarttaa riskikriteerien määrittämiseen, riskirekisterin rakentamiseen, riskienkäsittelysuunnitelman luomiseen ja sääntelyvaatimusten ristiviittaamiseen.

Käytä Zenith Controls: vaatimustenmukaisuuksien välistä opasta yhdistääksesi ISO/IEC 27001:2022 liite A:n kontrollialueet hallintoon, lakisääteisten vaatimusten noudattamiseen, varmentamiseen ja auditointinäkökulmiin.

Käytä Clarysecin Riskienhallintapolitiikkaa, Riskienhallintapolitiikka - SME ja Laki- ja sääntelyvaatimusten noudattamisen politiikka - SME omistajuuden, rekisterien, käsittelypäätösten ja auditointivalmiin näytön standardointiin.

Nopein käytännön seuraava askel on ottaa kymmenen merkittävintä riskiänne ja testata ne viidellä kysymyksellä:

1. Näkyykö sääntelyvaikutus?
2. Onko riskienkäsittelysuunnitelma aikarajattu ja omistettu?
3. Onko jokainen käsittelytoimi kartoitettu liite A:han ja SoA:han?
4. Onko NIS2-, DORA-, GDPR- tai asiakasmerkitys dokumentoitu soveltuvin osin?
5. Onko olemassa näyttöä siitä, että kontrolli toimii?

Jos vastaus on ei, Clarysec voi auttaa muuttamaan riskirekisterisi puolustettavaksi, vaatimustenmukaisuuksien väliseksi riskienkäsittelyohjelmaksi, johon auditoijat, sääntelyviranomaiset, asiakkaat ja hallitukset voivat luottaa.