ISO 27001 -soveltuvuuslausunto NIS2- ja DORA-valmiuden tukena
On maanantai klo 08.30, ja nopeasti kasvavan B2B FinTech SaaS -palveluntarjoajan tietoturvajohtaja Elena avaa hallituksen kiireelliseksi merkitsemän pyynnön. Yritys on juuri saavuttanut ISO/IEC 27001:2022 -sertifioinnin, mutta merkittävä EU:ssa toimiva pankkialan potentiaalinen asiakas esittää tavanomaista tietoturvakyselyä vaativampia kysymyksiä.
He eivät kysy vain, salataanko tiedot, käytetäänkö MFA:ta tai onko penetraatiotestausraportti olemassa. He haluavat tietää, tukeeko SaaS-alusta heidän DORA-velvoitteitaan, voisiko palveluntarjoaja kuulua NIS2:n soveltamisalaan ICT-palveluna tai digitaalisen infrastruktuurin riippuvuutena ja voiko ISO 27001 -standardin soveltuvuuslausunto perustella jokaisen sisällytetyn hallintakeinon, jokaisen poissuljetun hallintakeinon ja jokaisen todentavan näytön.
Hallitus esittää kysymyksen, jonka jokainen tietoturvajohtaja, vaatimustenmukaisuuspäällikkö ja SaaS-perustaja kuulee yhä useammin:
Voiko ISO 27001 -soveltuvuuslausunto osoittaa NIS2- ja DORA-valmiutemme?
Elena tietää, että väärä vastaus olisi käynnistää kolme erillistä vaatimustenmukaisuusohjelmaa: yksi ISO 27001:lle, yksi NIS2:lle ja yksi DORA:lle. Se johtaisi päällekkäiseen näyttöön, ristiriitaisiin hallintakeinojen omistajiin ja jatkuvaan kiireeseen ennen jokaista asiakasarviointia. Parempi vastaus on käyttää nykyistä ISMS:ää vaatimustenmukaisuuden käyttöjärjestelmänä ja soveltuvuuslausuntoa eli SoA:ta jäljitettävyyden pääasiakirjana.
SoA ei ole pelkkä ISO-sertifiointia varten laadittu taulukko. EU:n kyberturvallisuuden ja operatiivisen häiriönsietokyvyn ympäristössä se on paikka, jossa organisaatio osoittaa, miksi hallintakeinot ovat olemassa, miksi poissulkemiset ovat puolustettavissa, kuka omistaa kunkin hallintakeinon, mikä näyttö tukee toteutusta ja miten hallintakeinokokonaisuus vastaa NIS2:een, DORA:an, GDPR:ään, asiakassopimuksiin ja sisäiseen riskien käsittelyyn.
Clarysecin Enterprise Tietoturvapolitiikka Tietoturvapolitiikka toteaa:
ISMS:n tulee sisältää määritellyt soveltamisalan rajat, riskienarviointimenetelmä, mitattavat tavoitteet sekä dokumentoidut hallintakeinot, jotka on perusteltu soveltuvuuslausunnossa (SoA).
Tämä Tietoturvapolitiikan politiikkakohdan 6.1.2 vaatimus on auditointivalmiin lähestymistavan perusta. SoA:n tulee muodostaa silta velvoitteiden, riskien, hallintakeinojen, näytön ja johdon päätösten välille.
Miksi NIS2 ja DORA muuttivat sitä, mitä ”soveltuva” tarkoittaa
Perinteinen ISO/IEC 27001:2022 -standardin SoA alkaa usein yksinkertaisesta kysymyksestä: ”Mitkä liite A:n hallintakeinot soveltuvat riskienkäsittelysuunnitelmaamme?” Tämä on edelleen oikein, mutta se ei enää riitä SaaS-, pilvi-, hallittujen palvelujen, fintech-, finanssiteknologia- ja kriittisen toimitusketjun palveluntarjoajille.
NIS2 nostaa kyberturvallisuusriskien hallinnan perustasoa EU:n keskeisissä ja tärkeissä toimijoissa. Se kattaa toimialoja, kuten digitaalisen infrastruktuurin, pilvipalveluntarjoajat, datakeskuspalveluntarjoajat, sisällönjakeluverkot, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat, pankkitoiminnan ja finanssimarkkinoiden infrastruktuurit. Jäsenvaltioiden on tunnistettava keskeiset ja tärkeät toimijat sekä verkkotunnusten rekisteröintipalvelujen tarjoajat, ja monet teknologiatoimittajat, jotka aiemmin pitivät kyberturvallisuussääntelyä asiakkaan asiana, ovat nyt joko suoraan soveltamisalassa tai sopimusperusteisten läpivirtausvaatimusten piirissä.
NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä riskianalyysin, tietoturvapolitiikkojen, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun turvallisuuden, turvallisen hankinnan ja kehittämisen, hallintakeinojen tehokkuuden arvioinnin, kyberhygienian, koulutuksen, kryptografian, henkilöstöturvallisuuden, pääsynhallinnan, omaisuudenhallinnan ja tarvittaessa todennuksen osalta. NIS2 Article 23 lisää vaiheistetut poikkeamien raportointiodotukset, mukaan lukien ennakkovaroituksen, ilmoituksen, päivitykset ja merkittäviä poikkeamia koskevan loppuraportoinnin.
DORA, Digital Operational Resilience Act, soveltuu 17. tammikuuta 2025 alkaen ja keskittyy finanssialan toimijoihin sekä niiden ICT-riskiekosysteemiin. Se kattaa ICT-riskien hallinnan, ICT:hen liittyvien poikkeamien raportoinnin, tietyillä toimijoilla operatiivisten tai turvallisuuteen liittyvien maksupoikkeamien raportoinnin, digitaalisen operatiivisen häiriönsietokyvyn testauksen, kyberuhkatietojen jakamisen, ICT-kolmansien osapuolten riskienhallinnan, sopimusjärjestelyt sekä kriittisten ICT-kolmansien osapuolten palveluntarjoajien valvonnan.
Niille finanssialan toimijoille, jotka ovat myös NIS2:n mukaisia keskeisiä tai tärkeitä toimijoita, DORA toimii toimialakohtaisena sääntelykehyksenä vastaaville ICT-riskien hallinnan ja poikkeamien raportoinnin velvoitteille. SaaS-palveluntarjoajille, pilvipalveluntarjoajille, MSP-toimijoille ja finanssiasiakkaita palveleville MDR-palveluntarjoajille käytännön todellisuus on kuitenkin se, että DORA-odotukset tulevat hankinnan, sopimusten, auditointioikeuksien, poikkeamatilanteiden tukivelvoitteiden, exit-suunnittelun, alihankkijoiden läpinäkyvyyden ja häiriönsietokykyä koskevan näytön kautta.
Tämä muuttaa SoA-keskustelua. Kysymys ei enää ole: ”Sisältääkö liite A tämän hallintakeinon?” Parempi kysymys on:
Voimmeko osoittaa, että hallintakeinon valinta on riskiperusteinen, velvoitteet huomioiva, oikeasuhtainen, omistettu, toteutettu, seurattu, näytöllä tuettu ja hyväksytty?
ISO 27001 on NIS2:n ja DORA:n yhteinen tulkintakerros
ISO/IEC 27001:2022 on arvokas, koska se on hallintajärjestelmästandardi eikä suppea tarkistuslista. Se edellyttää, että ISMS integroidaan organisaation prosesseihin ja mitoitetaan organisaation tarpeiden mukaan. Siksi se toimii tehokkaana yhteisenä tulkintakerroksena päällekkäisille vaatimustenmukaisuusvaatimuksille.
Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, tunnistaa sidosryhmät, määrittää olennaiset vaatimukset ja määrittelee ISMS:n soveltamisalan. Elenan yrityksen kaltaisella FinTech SaaS -palveluntarjoajalla sidosryhmävaatimuksiin voi sisältyä EU-asiakkaita, DORA:n vaikutuspiirissä olevia finanssiasiakkaita, NIS2-toimialoihin liittyvä altistus, GDPR:n rekisterinpitäjä- ja käsittelijävelvoitteita, ulkoistettuja pilviriippuvuuksia, toimittajarajapintoja ja hallituksen odotuksia.
Kohdat 6.1.1–6.1.3 edellyttävät riskien ja mahdollisuuksien suunnittelua, toistettavaa tietoturvariskien arviointiprosessia, riskien käsittelyprosessia, vertailua liite A:han sekä soveltuvuuslausuntoa, jossa tunnistetaan sisällytetyt hallintakeinot, toteutustila ja poissulkemisten perustelut.
Tässä SoA:sta tulee hallintakeinopäätösten tallenne. Hallintakeino voidaan sisällyttää, koska se käsittelee riskiä, täyttää lakisääteisen vaatimuksen, toteuttaa asiakassopimuksen, tukee liiketoimintatavoitetta tai edustaa tietoturvan perustasoa. Hallintakeino voidaan poissulkea vasta, kun organisaatio on tietoisesti arvioinut sen, todennut sen epäolennaiseksi ISMS:n soveltamisalan kannalta, dokumentoinut perustelun ja saanut asianmukaisen hyväksynnän.
Clarysecin Enterprise Riskienhallintapolitiikka Riskienhallintapolitiikka toteaa:
Soveltuvuuslausunnon (SoA) tulee kuvata kaikki riskien käsittelypäätökset, ja sitä tulee päivittää aina, kun hallintakeinojen kattavuutta muutetaan.
Tämä Riskienhallintapolitiikan politiikkakohdan 5.4 vaatimus on kriittinen NIS2- ja DORA-valmiuden kannalta. Uusi säännelty asiakas, uusi pilviriippuvuus, uusi poikkeamien raportointivelvoite tai uusi toimittajakeskittymäriski voi muuttaa hallintakeinojen soveltuvuutta.
Aloita vaatimustenmukaisuusrekisteristä, älä hallintakeinoluettelosta
Heikko SoA alkaa liite A:sta ja kysyy: ”Mitkä hallintakeinot meillä jo on?” Vahva SoA alkaa organisaation operatiivisesta todellisuudesta ja kysyy: ”Mitkä velvoitteet, palvelut, riskit, tiedot, toimittajat ja asiakkaat ISMS:n on katettava?”
ISO/IEC 27005:2022 tukee tätä lähestymistapaa korostamalla sidosryhmävaatimuksia, riskikriteerejä sekä tarvetta huomioida standardit, sisäiset säännöt, lait, määräykset, sopimukset ja olemassa olevat hallintakeinot. Se korostaa myös, että soveltumattomuus tai vaatimustenvastaisuus tulee selittää ja perustella.
Clarysecin SME Laki- ja sääntelyvaatimusten noudattamisen politiikka-sme Laki- ja sääntelyvaatimusten noudattamisen politiikka-sme - SME kuvaa saman toimintaperiaatteen:
Toimitusjohtajan on ylläpidettävä yksinkertaista, jäsenneltyä vaatimustenmukaisuusrekisteriä, jossa luetellaan:
Tämä vaatimus tulee Laki- ja sääntelyvaatimusten noudattamisen politiikka-sme -politiikan kohdasta 5.1.1. Pienemmässä organisaatiossa rekisteri voi olla yksinkertainen. Suuryrityksessä sen tulee olla yksityiskohtaisempi. Logiikka on sama: velvoitteiden on oltava näkyvissä ennen kuin ne voidaan kartoittaa.
Clarysecin Enterprise Laki- ja sääntelyvaatimusten noudattamisen politiikka Laki- ja sääntelyvaatimusten noudattamisen politiikka on yksiselitteinen:
Kaikki lakisääteiset ja sääntelyvelvoitteet on kartoitettava tietoturvallisuuden hallintajärjestelmän (ISMS) tiettyihin politiikkoihin, hallintakeinoihin ja omistajiin.
Tämä on Laki- ja sääntelyvaatimusten noudattamisen politiikan politiikkakohta 6.2.1. Se on hallinnollinen selkäranka ISO 27001 -standardin soveltuvuuslausunnon käyttämiselle NIS2- ja DORA-vaatimustenmukaisuusvalmiudessa.
| Rekisterikenttä | Esimerkkimerkintä | Miksi sillä on merkitystä SoA:n kannalta |
|---|---|---|
| Velvoitteen lähde | NIS2 Article 21 | Ohjaa riskianalyysin, poikkeamien käsittelyn, jatkuvuuden, toimittajaturvallisuuden, kryptografian, pääsynhallinnan, omaisuudenhallinnan ja koulutushallintakeinojen sisällyttämistä |
| Soveltuvuusperustelu | SaaS-palveluntarjoaja, joka tukee EU:n finanssialan ja keskeisten toimialojen asiakkaita | Osoittaa, miksi NIS2 huomioidaan, vaikka lopullinen oikeudellinen asema riippuu jäsenvaltion nimeämisestä |
| Hallintakeinon omistaja | Tietoturvaoperaatioiden johtaja | Tukee osoitusvelvollisuutta ja näytön omistajuutta |
| Kartoitettu ISO/IEC 27001:2022 -hallintakeino | A.5.24–A.5.28 poikkeamien hallinnan hallintakeinot | Linkittää lakisääteisen velvoitteen liite A:n hallintakeinovalintaan |
| Näytön lähde | Tietoturvapoikkeamiin reagointisuunnitelma, tikettiesimerkit, poikkeaman jälkiarviointi, raportointiharjoitus | Helpottaa auditointiotantaa |
| SoA-päätös | Soveltuva | Luo jäljitettävyyden velvoitteen, riskin, hallintakeinon ja näytön välille |
Rakenna riskikriteerit, jotka huomioivat häiriönsietokyvyn, tietosuojan, toimittajat ja sääntelyn
Monet SoA-perustelut epäonnistuvat, koska riskipisteytysmalli on liian kapea. Se mittaa teknistä todennäköisyyttä ja vaikutusta, mutta ei huomioi sääntelyaltistusta, palvelun kriittisyyttä, asiakkaalle aiheutuvaa haittaa, toimittajariippuvuutta, tietosuojavaikutusta tai järjestelmätason operatiivista häiriötä.
NIS2 ei koske vain luottamuksellisuutta. Se keskittyy poikkeamien palveluihin ja palvelujen vastaanottajiin kohdistuvien vaikutusten ehkäisemiseen ja minimointiin. DORA määrittelee kriittiset tai tärkeät toiminnot sen perusteella, heikentäisikö häiriö olennaisesti taloudellista suorituskykyä, palvelun jatkuvuutta tai sääntelyvaatimusten noudattamista. GDPR lisää osoitusvelvollisuuden, eheyden, luottamuksellisuuden, valmiuden tietoturvaloukkauksiin ja rekisteröidyille aiheutuvan haitan.
Clarysecin SME Riskienhallintapolitiikka-sme Riskienhallintapolitiikka-sme - SME antaa käytännön vähimmäistason:
Jokaisen riskimerkinnän tulee sisältää: kuvaus, todennäköisyys, vaikutus, pisteet, omistaja ja riskienkäsittelysuunnitelma.
Tämä on Riskienhallintapolitiikka-sme -politiikan kohta 5.1.2. NIS2- ja DORA-valmiutta varten Clarysec laajentaa vähimmäistasoa kentillä, kuten velvoitteen lähde, vaikutuksen kohteena oleva palvelu, tietoluokka, toimittajariippuvuus, liiketoimintavastaava, sääntelyvaikutus, jäännösriski, käsittelytila ja näytön lähde.
| Riski-ID | Riskiskenaario | Velvoiteajuri | Käsittelyhallintakeinot | SoA-perustelu |
|---|---|---|---|---|
| R-021 | Pilvialustan käyttökatko estää asiakkaita käyttämästä säänneltyjä petosanalytiikan hallintanäkymiä | NIS2 Article 21, DORA-asiakasriippuvuus, sopimusperusteinen SLA | A.5.29, A.5.30, A.8.13, A.8.15, A.8.16 | Soveltuva, koska palvelun jatkuvuus, varmuuskopiointi, lokitus, valvonta ja ICT-valmius vähentävät operatiivista häiriötä ja tukevat asiakkaiden häiriönsietokykyvelvoitteita |
| R-034 | EU:n henkilötietoja koskevaa tietoturvapoikkeamaa ei havaita, eskaloida tai raportoida vaadituissa määräajoissa | GDPR:n osoitusvelvollisuus, NIS2 Article 23, DORA:n poikkeamatilanteiden tukivelvoitteet | A.5.24–A.5.28, A.8.15, A.8.16 | Soveltuva, koska vaiheistettu poikkeamien käsittely, näytön kerääminen, oppiminen, lokitus ja valvonta tukevat viranomais- ja asiakasilmoitusten työnkulkuja |
| R-047 | Kriittisen alihankkijan heikkous vaikuttaa turvalliseen palvelutuotantoon finanssiasiakkaille | NIS2 Article 21 toimitusketjun turvallisuus, DORA:n ICT-kolmansien osapuolten riski | A.5.19–A.5.23, A.5.31, A.5.36 | Soveltuva, koska toimittajariski, sopimusvaatimukset, pilvihallinnointi, vaatimustenmukaisuusvelvoitteet ja politiikan noudattaminen ovat välttämättömiä ICT-riippuvuuksien varmentamiseksi |
Huomaa sanavalinta. Vahva perustelu ei sano vain ”toteutettu”. Se selittää, miksi hallintakeino soveltuu organisaation liiketoiminta-, sääntely- ja riskikontekstissa.
Kartoita NIS2- ja DORA-osa-alueet ISO 27001:2022 -hallintakeinoihin
Kun vaatimustenmukaisuusrekisteri ja riskikriteerit on määritetty, käytännön työ on kartoittaa sääntelyn osa-alueet liite A:n hallintakeinoihin. Kartoitus ei yksinään osoita vaatimustenmukaisuutta, mutta se antaa auditoijille ja asiakkaille selkeän hakemiston näytön testaamista varten.
| Sääntelyvaatimuksen osa-alue | NIS2-viite | DORA-viite | Esimerkkejä ISO/IEC 27001:2022 -hallintakeinoista |
|---|---|---|---|
| Hallinnointi ja johdon osoitusvelvollisuus | Article 20 | Article 5 | A.5.1, A.5.2, A.5.31, A.5.35, A.5.36 |
| Riskienhallinnan viitekehys | Article 21(1) | Article 6 | ISO 27001 kohdat 6.1.1–6.1.3, A.5.7, A.5.31, A.5.36 |
| Poikkeamien käsittely ja raportointi | Article 23 | Articles 17 to 19 | A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16 |
| Liiketoiminnan jatkuvuus ja häiriönsietokyky | Article 21(2)(c) | Articles 11 and 12 | A.5.29, A.5.30, A.8.13, A.8.14, A.8.15, A.8.16 |
| Toimitusketju ja kolmansien osapuolten riski | Article 21(2)(d), Article 21(3) | Articles 28 to 30 | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 |
| Turvallinen hankinta ja kehittäminen | Article 21(2)(e) | Article 9 | A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.32 |
| Testaus ja hallintakeinojen tehokkuus | Article 21(2)(f) | Articles 24 to 27 | A.5.35, A.5.36, A.8.8, A.8.29, A.8.34 |
| Pääsynhallinta ja omaisuudenhallinta | Article 21(2)(i) | Article 9(4)(d) | A.5.9, A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3 |
| Kryptografia ja salaus | Article 21(2)(h) | Article 9(4)(d) | A.8.24 |
Elenalle tämä kartoitus muutti hallituskeskustelun. Sen sijaan, että hän olisi esittänyt NIS2:n ja DORA:n erillisinä projekteina, hän pystyi näyttämään niiden päällekkäisyyden: hallinnointi, riskienhallinta, poikkeamat, jatkuvuus, toimittajat, testaus, pääsynhallinta ja kryptografia.
Kolme ISO-hallintakeinoa, joista jokainen NIS2- ja DORA-SoA riippuu
Zenith Controls: The Cross-Compliance Guide Zenith Controls -oppaassa Clarysec käsittelee kolmea ISO/IEC 27002:2022 -hallintakeinoa keskeisinä auditointivalmiin SoA-hallinnoinnin kannalta NIS2:lle ja DORA:lle. Nämä ovat ISO-hallintakeinoja, joita Zenith Controls -oppaassa on rikastettu poikkivaatimustenmukaisuuden attribuuteilla.
| ISO/IEC 27002:2022 -hallintakeino | Hallintakeinon nimi | Zenith Controls -attribuutit | Miksi sillä on merkitystä SoA-hallinnoinnissa |
|---|---|---|---|
| 5.31 | Lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset vaatimukset | Ennaltaehkäisevä, CIA, tunnista, laki- ja vaatimustenmukaisuus, hallinnointi, ekosysteemi, suojaus | Määrittää velvoitteiden perustason, joka ohjaa hallintakeinojen sisällyttämistä ja omistajien osoittamista |
| 5.35 | Tietoturvan riippumaton katselmointi | Ennaltaehkäisevä ja korjaava, CIA, tunnista ja suojaa, tietoturvavarmennus, hallinnointi, ekosysteemi | Antaa varmuutta siitä, että SoA-päätökset ja toteutusnäyttö kestävät riippumattoman katselmoinnin |
| 5.36 | Tietoturvapolitiikkojen, sääntöjen ja standardien noudattaminen | Ennaltaehkäisevä, CIA, tunnista ja suojaa, laki- ja vaatimustenmukaisuus, tietoturvavarmennus, hallinnointi, ekosysteemi | Kytkee SoA:n operatiiviseen vaatimustenmukaisuuteen, politiikan noudattamiseen ja valvontaan |
Nämä hallintakeinot eivät ole erillisiä. Ne liittyvät suoraan toimittajasuhteiden hallintakeinoihin A.5.19–A.5.23, poikkeamien hallinnan hallintakeinoihin A.5.24–A.5.28, jatkuvuuden hallintakeinoihin A.5.29 ja A.5.30, tietosuojan hallintakeinoon A.5.34, haavoittuvuuksien hallintaan A.8.8, konfiguraationhallintaan A.8.9, tietojen varmuuskopiointiin A.8.13, lokitukseen A.8.15, valvontatoimiin A.8.16, kryptografiaan A.8.24, turvallisen kehityksen hallintakeinoihin A.8.25–A.8.29 ja muutoksenhallintaan A.8.32.
Zenith Controls -oppaan arvo on siinä, että se auttaa tiimejä välttämään SoA:n käsittelyä yhden standardin artefaktina. Hallintakeino 5.31 tukee lakisääteistä ja sopimusperusteista kartoitusta. Hallintakeino 5.35 tukee sisäistä tarkastusta, riippumatonta katselmointia ja johdon varmuutta. Hallintakeino 5.36 tukee operatiivista vaatimustenmukaisuutta politiikkojen, menettelyjen, standardien ja hallintakeinovaatimusten kanssa.
Käytä Zenith Blueprintiä SoA:n rakentamiseen, testaamiseen ja puolustamiseen
Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint -oppaassa Clarysec sijoittaa SoA:n rakentamisen riskienhallintavaiheeseen, vaiheeseen 13: riskienkäsittelysuunnittelu ja soveltuvuuslausunto. Blueprint ohjeistaa organisaatioita käyttämään “Risk Register and SoA Builder.xlsx” -mallin SoA-välilehteä, päättämään, soveltuuko kukin 93 liite A:n hallintakeinosta, ja perustamaan päätöksen riskien käsittelyyn, lakisääteisiin ja sopimusperusteisiin vaatimuksiin, soveltamisalan olennaisuuteen ja organisaation toimintaympäristöön.
Blueprint toteaa:
SoA on käytännössä siltadokumentti: se yhdistää riskien arvioinnin ja käsittelyn käytössä oleviin hallintakeinoihin.
Tämä lause tiivistää toimintamallin. SoA yhdistää velvoitteet, riskit, politiikat, hallintakeinot, näytön ja auditointipäätelmät.
Zenith Blueprint ohjeistaa tiimejä myös ristiviittaamaan sääntelyyn SoA:n huomautuksissa tarvittaessa. Jos hallintakeino toteutetaan GDPR:n, NIS2:n tai DORA:n vuoksi, sen tulee näkyä riskirekisterissä tai SoA:n huomautuksissa. Myöhemmin vaiheessa 24 Blueprint kehottaa organisaatioita päivittämään SoA:n toteutuksen jälkeen ja varmistamaan sen riskienkäsittelysuunnitelmaa vasten. Vaiheessa 30, sertifiointiin valmistautumisessa, loppukatselmoinnissa ja koeauditoinnissa, Blueprint ohjaa tiimejä varmistamaan, että jokaisella soveltuvalla liite A:n hallintakeinolla on näyttöä, kuten politiikka, menettely, raportti, suunnitelma tai toteutustallenne.
Tämä järjestys tekee SoA:sta elävän vaatimustenmukaisuuden työvälineen:
- Vaihe 13 rakentaa sen riskien käsittelystä ja velvoitteista.
- Vaihe 24 testaa sitä toteutuksen todellisuutta vasten.
- Vaihe 30 puolustaa sitä lopullisen näytön katselmoinnin ja koeauditoinnin kautta.
Miten kirjoittaa sisällyttämisperustelut, joita auditoijat voivat seurata
Hallintakeino tulee sisällyttää, kun sille on olemassa vähintään yksi puolustettava ajuri: riskien käsittely, lakisääteinen vaatimus, sopimusperusteinen vaatimus, soveltamisalan olennaisuus, tietoturvan perustaso, asiakkaan varmentamisodotus tai johdon hyväksymä häiriönsietokyvyn tavoite.
Hyödyllinen kaava on:
Soveltuva, koska [riski tai velvoite] vaikuttaa [palveluun, omaisuuserään, tietoon tai prosessiin], ja tämä hallintakeino tuottaa [ennaltaehkäisevän, havaitsevan, korjaavan tai häiriönsietokykyä tukevan lopputuloksen], mikä todennetaan [politiikalla, tallenteella, testillä, raportilla tai järjestelmätulosteella].
| Hallintakeinoalue | Heikko perustelu | Auditointivalmis perustelu |
|---|---|---|
| Poikkeamien hallinta | Toteutettu | Soveltuva, koska NIS2 Article 23 ja DORA:n poikkeaman elinkaaren odotukset edellyttävät havaitsemista, luokittelua, eskalointia, raportoinnin tukea, viestintää, juurisyyanalyysiä, näytön keräämistä ja opittuja asioita poikkeamista, jotka vaikuttavat säänneltyihin asiakkaisiin |
| Toimittajaturvallisuus | Vaadittu | Soveltuva, koska pilvi-isännöinti, tukipalveluntarjoajat ja MDR-palvelut vaikuttavat palvelun saatavuuteen ja tietojen luottamuksellisuuteen, ja NIS2 Article 21 sekä DORA:n ICT-kolmansien osapuolten riskiodotukset edellyttävät huolellisuutta, sopimusperusteisia suojatoimia, seurantaa, alihankkijoiden katselmointia ja exit-suunnittelua |
| Kryptografia | Käytössä | Soveltuva, koska asiakastiedot, todennussalaisuudet, varmuuskopiot ja sääntelyn alaiset finanssitiedot edellyttävät luottamuksellisuuden ja eheyden suojatoimia NIS2:n, DORA:n, GDPR:n, asiakassopimusten ja sisäisen riskien käsittelyn perusteella |
| Riippumaton katselmointi | Kyllä | Soveltuva, koska johto, asiakkaat ja auditoijat tarvitsevat varmuutta siitä, että ISMS-hallintakeinot, SoA-päätökset, näyttö ja sääntelykartoitukset katselmoidaan säännöllisesti riippumattomasti |
FinTech SaaS -palveluntarjoajalla yksi SoA-rivi voisi näyttää tältä:
| SoA-kenttä | Esimerkkimerkintä |
|---|---|
| Hallintakeino | A.5.19 Tietoturvan hallinta toimittajasuhteissa |
| Soveltuvuus | Kyllä |
| Perustelu | Soveltuva, koska pilvi-isännöinti, tukityökalut ja MDR-palvelut vaikuttavat luottamuksellisuuteen, saatavuuteen, poikkeamien havaitsemiseen ja säänneltyjen asiakkaiden varmentamiseen. Tukee NIS2:n toimitusketjuodotuksia, DORA:n ICT-kolmansien osapuolten riskiodotuksia finanssiasiakkaille, GDPR:n käsittelijän osoitusvelvollisuutta ja sopimusperusteisia auditointivaatimuksia. |
| Toteutustila | Toteutettu ja seurannassa |
| Omistaja | Toimittajahallinnan johtaja |
| Näyttö | Toimittajarekisteri, due diligence -tarkistuslista, sopimusten tietoturvalausekkeet, vuosittaiset katselmointitallenteet, SOC- tai varmentamisraportit, alihankkijoiden katselmointi, exit-suunnitelma kriittisille palveluntarjoajille |
| Linkitetyt riskit | R-047, R-021, R-034 |
| Linkitetyt politiikat | Kolmannen osapuolen ja toimittajaturvallisuuden politiikka, Laki- ja sääntelyvaatimusten noudattamisen politiikka, Riskienhallintapolitiikka |
| Katselmointitiheys | Vuosittain sekä toimittajamuutoksen, merkittävän poikkeaman, uuden säännellyn asiakkaan tai palvelulaajennuksen yhteydessä |
Tämä on auditointivalmis, koska se kytkee hallintakeinon toimintaympäristöön, riskiin, velvoitteeseen, toteutukseen, omistajuuteen ja näyttöön.
Miten poissulkemiset perustellaan ilman auditointialtistusta
Poissulkemiset eivät ole epäonnistumisia. Huonosti perustellut poissulkemiset ovat epäonnistumisia.
ISO/IEC 27001:2022 edellyttää, että SoA perustelee poissuljetut liite A:n hallintakeinot. ISO/IEC 27005:2022 vahvistaa, että soveltumattomuus tulee selittää ja perustella. Clarysecin Enterprise Tietoturvapolitiikka toteaa:
Perustasoa voidaan räätälöidä; poissulkemiset on kuitenkin dokumentoitava SoA:ssa muodollisella hyväksynnällä ja perustelulla.
Tämä on Tietoturvapolitiikan kohta 7.2.2.
Clarysecin Tietoturvapolitiikka-sme Tietoturvapolitiikka-sme - SME toteaa:
Kaikki poikkeamat tästä politiikasta on dokumentoitava siten, että selitetään selkeästi, miksi poikkeama on tarpeen, mitkä vaihtoehtoiset suojatoimet ovat käytössä ja mikä päivämäärä on määritetty uudelleenarvioinnille.
Tämä vaatimus tulee Tietoturvapolitiikka-sme -politiikan kohdasta 7.2.1.
| Hallintakeinoalue | Poissulkemisen perustelu | Vaaditut suojatoimet |
|---|---|---|
| Sisäisen koodin turvallisen kehityksen hallintakeinot | Ei sovellu, koska ISMS:n soveltamisala kattaa vain jälleenmyyntipalvelun, jossa ei ole sisäistä ohjelmistokehitystä, koodimuutoksia eikä CI/CD-putkea | Toimittajavarmennus, muutosten hyväksyntä, haavoittuvuuksien vastaanotto, asiakasviestintä ja vuosittainen uudelleenarviointi |
| Omien toimitilojen fyysisen turvallisuuden valvonta | Ei sovellu, koska organisaatiolla ei ole ISMS:n soveltamisalaan kuuluvaa omaa datakeskusta, palvelintilaa tai toimistotilaa, ja auditoidut pilvipalveluntarjoajat operoivat koko tuotantoinfrastruktuuria | Pilvitoimittajan huolellisuusarviointi, sopimusperusteiset hallintakeinot, käyttöoikeuskatselmoinnit, jaetun vastuun katselmointi ja palveluntarjoajan varmentamisraporttien näyttö |
| Tietyt paikallisten tallennusvälineiden käsittelytoimet | Ei sovellu, koska soveltamisalaan kuuluvassa palvelussa ei käytetä siirrettäviä tallennusvälineitä eikä paikallista tallennusta | Päätelaiterajoitukset, DLP-valvonta tarvittaessa, omaisuusluettelo ja säännöllinen validointi |
NIS2:n ja DORA:n osalta poissulkemiset edellyttävät erityistä huolellisuutta. SaaS-yhtiön tulisi harvoin poissulkea lokitus, valvonta, varmuuskopiot, poikkeamien hallinta, pääsynhallinta, toimittajaturvallisuus tai haavoittuvuuksien hallinta. Vaikka hallintakeino ei liittyisi yhteen tiettyyn riskiin, se voi silti olla tarpeellinen tietoturvan perustasona, asiakkaan varmentamisena, sopimusodotuksena tai lakisääteisenä velvoitteena.
Clarysecin Riskienhallintapolitiikka-sme muistuttaa myös, miten hyväksyttyä riskiä on käsiteltävä:
Hyväksy: Perustele, miksi lisätoimia ei tarvita, ja kirjaa jäännösriski.
Tämä Riskienhallintapolitiikka-sme -politiikan kohta 6.1.1 on juuri se ajattelutapa, jota poissulkemiset ja jäännösriskiä koskevat päätökset edellyttävät.
Poikkeamien raportointi: osoita työnkulku, älä pelkkää politiikan olemassaoloa
NIS2 Article 23 edellyttää merkittävien poikkeamien vaiheistettua raportointia, mukaan lukien ennakkovaroitus 24 tunnin kuluessa tietoisuudesta, ilmoitus 72 tunnin kuluessa, pyydettäessä päivitykset sekä loppuraportti kuukauden kuluessa 72 tunnin ilmoituksesta. DORA edellyttää, että finanssialan toimijat havaitsevat, hallitsevat, luokittelevat, eskaloivat, viestivät ja raportoivat merkittävät ICT:hen liittyvät poikkeamat, tiedottavat asianomaisille asiakkaille tarvittaessa, tekevät juurisyyanalyysin ja parantavat hallintakeinoja.
SaaS-palveluntarjoaja ei aina raportoi suoraan DORA-viranomaiselle, mutta sen on ehkä tuettava finanssiasiakkaiden raportointiaikatauluja. Tämä tekee poikkeamahallintakeinoista erittäin olennaisia SoA:ssa.
Heikko SoA sanoo: ”Tietoturvapoikkeamiin reagointipolitiikka on olemassa.”
Vahva SoA sanoo: ”Soveltuva, koska organisaation on havaittava, arvioitava, luokiteltava, eskaloitava, viestittävä, säilytettävä näyttö, tuettava sääntelyraportoinnin aikatauluja, ilmoitettava asianomaisille asiakkaille sopimuksen niin edellyttäessä ja opittava poikkeamista, jotka vaikuttavat palveluihin, tietoihin tai säänneltyihin asiakkaisiin.”
Näytön tulee sisältää:
- Tietoturvapoikkeamiin reagointisuunnitelma ja eskalointimatriisi.
- Vakavuusluokittelun kriteerit.
- Asiakasilmoitusten työnkulku.
- Sääntelyilmoitusten päätöspuu tarvittaessa.
- Poikkeamatiketit ja aikajanat.
- Lokit ja valvontahälytykset.
- Pöytäharjoitusten tallenteet.
- Poikkeaman jälkiarviointi ja korjaavat toimenpiteet.
- Näytön säilyttämisen menettelyt.
Clarysecin Enterprise Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka selittää, miksi tämä on tärkeää:
Tuottaa puolustettavissa olevaa näyttöä ja auditointijälki viranomaiskyselyjen, oikeudenkäyntien tai asiakkaiden varmentamispyyntöjen tueksi.
Tämä tavoite tulee Auditointi- ja vaatimustenmukaisuuden seurantapolitiikan kohdasta 3.4.
Pienemmissä organisaatioissa myös näytön säilytys on määritettävä selkeästi. Clarysecin Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka-sme Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka-sme - SME toteaa:
Näyttöä on säilytettävä vähintään kaksi vuotta tai pidempään, jos sertifiointi tai asiakassopimukset sitä edellyttävät.
Tämä on Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka-sme -politiikan kohta 6.2.4.
Yksi SoA, monta auditointikeskustelua
Paras SoA ei monista viitekehyksiä. Se luo jäljitettävän hallintakeinokertomuksen, jonka eri auditoijat voivat ymmärtää.
| Viitekehys tai näkökulma | Mitä auditoija tai arvioija kysyy | Miten SoA auttaa |
|---|---|---|
| ISO/IEC 27001:2022 | Miksi tämä liite A:n hallintakeino on sisällytetty tai poissuljettu, mikä on toteutustila ja missä näyttö on? | Linkittää hallintakeinopäätökset riskeihin, velvoitteisiin, toteutustilaan, omistajiin ja näyttöön |
| NIS2 | Miten hallinnointi, riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketju, salaus, pääsynhallinta, omaisuudenhallinta ja koulutus toimivat käytännössä? | Kartoittaa Article 21- ja Article 23 -odotukset liite A:n hallintakeinoihin ja operatiivisiin tallenteisiin |
| DORA | Miten ICT-riski, poikkeamien hallinta, häiriönsietokyvyn testaus, kolmansien osapuolten riski, sopimukset, auditointioikeudet, exit-suunnitelmat ja johdon valvonta todennetaan? | Osoittaa, mitkä hallintakeinot tukevat finanssialan toimijoiden velvoitteita tai SaaS-toimittajan varmentamista |
| GDPR | Voiko organisaatio osoittaa eheyden, luottamuksellisuuden, osoitusvelvollisuuden, valmiuden tietoturvaloukkauksiin, lainmukaisen käsittelyn tuen ja käsittelijähallintakeinot? | Linkittää tietosuojavelvoitteet pääsynhallintaan, kryptografiaan, lokitukseen, toimittajiin, poikkeamiin, säilytykseen ja näyttöhallintakeinoihin |
| NIST CSF 2.0 | Miten Govern-, Identify-, Protect-, Detect-, Respond- ja Recover-tulokset tuetaan toteutetuilla hallintakeinoilla? | Käyttää samaa näyttöpohjaa toiminnallisen kyberturvallisuuskattavuuden osoittamiseen |
| COBIT 2019 ja ISACA-auditointi | Onko hallinnointitavoitteet, hallintakeinojen omistajuus, varmentamistoimet, mittarit ja johdon osoitusvelvollisuus määritelty? | Kytkee SoA-päätökset omistajiin, suorituskyvyn katselmointiin, riippumattomaan katselmointiin ja korjaaviin toimenpiteisiin |
ISO 27001 -auditoija aloittaa yleensä kohtien logiikasta: soveltamisala, sidosryhmät, riskien arviointi, riskien käsittely, SoA, tavoitteet, sisäinen tarkastus, johdon katselmointi ja parantaminen. NIS2-painotteinen arvioija keskittyy oikeasuhtaisuuteen, johdon osoitusvelvollisuuteen, koulutukseen, toimitusketjuun, poikkeamien määräaikoihin ja palveluvaikutuksiin. DORA-painotteinen asiakasarvioija keskittyy ICT-riskiin, kriittisiin tai tärkeisiin toimintoihin, merkittäviin ICT-poikkeamiin, häiriönsietokyvyn testaukseen, sopimuslausekkeisiin, auditointioikeuksiin, exit-suunnitelmiin, alihankintaan ja keskittymäriskiin. Tietosuojan arvioija keskittyy GDPR:n osoitusvelvollisuuteen ja valmiuteen tietoturvaloukkauksiin. COBIT 2019- tai ISACA-tyylinen auditoija testaa hallinnointia, mittareita, omistajuutta, varmentamista ja korjaavia toimenpiteitä.
Siksi SoA:ta ei voi ylläpitää pelkästään tietoturvatiimi. Se tarvitsee lakiasioiden, tietosuojan, hankinnan, engineering-toiminnon, operaatioiden, HR:n ja ylimmän johdon omistajuutta.
Yleiset SoA-epäonnistumiset NIS2- ja DORA-valmiushankkeissa
Clarysec löytää valmiushankkeissa toistuvasti samat ongelmat:
- SoA merkitsee hallintakeinot soveltuviksi, mutta riskiä, velvoitetta tai liiketoimintaperustetta ei ole kirjattu.
- NIS2 ja DORA mainitaan politiikoissa, mutta niitä ei ole kartoitettu hallintakeinoihin, omistajiin tai näyttöön.
- Toimittajahallintakeinot on merkitty toteutetuiksi, mutta toimittajarekisteriä, kriittisyysluokitusta, sopimuskatselmointia tai exit-suunnitelmaa ei ole.
- Poikkeamahallintakeinot ovat olemassa, mutta prosessi ei tue 24 tunnin, 72 tunnin, asiakas- tai loppuraportoinnin työnkulkuja.
- Johdon hyväksyntä oletetaan, mutta riskin hyväksymisestä, SoA:n hyväksynnästä tai jäännösriskiä koskevasta päätöksestä ei ole tallennetta.
- Poissulkemiset on kopioitu mallipohjasta, eivätkä ne vastaa todellista pilvi-, etä-, SaaS- tai fintech-toimintamallia.
- Näyttöä on eri työkaluissa, mutta mikään auditointijälki ei yhdistä näyttöä SoA:han.
- GDPR:n mukainen henkilötietojen käsittely ei ole linkitetty tietoturvahallintakeinoihin, tietoturvaloukkauksiin reagointiin, toimittajasopimuksiin tai säilytykseen.
- Sisäinen tarkastus tarkistaa asiakirjoja, mutta ei testaa, vastaako SoA todellista toteutusta.
- SoA päivitetään vain ennen sertifiointia, ei uusien asiakkaiden, toimittajien, poikkeamien, auditointihavaintojen tai sääntelymuutosten jälkeen.
Nämä eivät ole paperityöongelmia. Ne ovat hallinnointiongelmia.
Käytännön tarkistuslista auditointivalmiille ISO 27001 -soveltuvuuslausunnolle
Käytä tätä tarkistuslistaa ennen ISO 27001 -sertifiointiauditointia, NIS2-valmiuskatselmointia, DORA-asiakasarviointia, hallituksen kokousta tai sijoittajan due diligence -prosessia.
| Tarkistuspiste | Hyvä vastaus |
|---|---|
| Soveltamisala | ISMS:n soveltamisala kattaa palvelut, asiakkaat, tiedot, toimittajat, ulkoistetut rajapinnat ja säännellyt riippuvuudet |
| Sidosryhmät | NIS2, DORA-asiakkaat, GDPR-roolit, viranomaiset, asiakkaat, toimittajat ja sisäiset sidosryhmät on tunnistettu |
| Vaatimustenmukaisuusrekisteri | Lakisääteiset, sääntelyyn liittyvät, sopimusperusteiset ja asiakasvelvoitteet on kartoitettu politiikkoihin, hallintakeinoihin ja omistajiin |
| Riskikriteerit | Lakisääteiset, operatiiviset, tietosuoja-, toimittaja-, häiriönsietokyky-, taloudelliset ja mainevaikutukset sisältyvät kriteereihin |
| Riskirekisteri | Jokainen riski sisältää kuvauksen, todennäköisyyden, vaikutuksen, pisteet, omistajan, riskienkäsittelysuunnitelman ja jäännösriskin |
| SoA-sisällyttäminen | Jokaisella soveltuvalla hallintakeinolla on perustelu, joka liittyy riskiin, velvoitteeseen, soveltamisalaan, sopimukseen tai tietoturvan perustasoon |
| SoA-poissulkeminen | Jokaisella poissuljetulla hallintakeinolla on täsmällinen, hyväksytty, näyttöön perustuva perustelu ja katselmoinnin käynnistävä ehto |
| Näyttö | Jokaisella soveltuvalla hallintakeinolla on näyttöä politiikasta, menettelystä, konfiguraatiosta, raportista, testistä, tiketistä, lokista, katselmoinnista tai tallenteesta |
| Johdon hyväksyntä | Riskinomistajat hyväksyvät riskienkäsittelysuunnitelmat ja jäännösriskit, ja johto katselmoi ISMS:n suorituskyvyn |
| Riippumaton katselmointi | Sisäinen tarkastus tai riippumaton katselmointi testaa SoA:n tarkkuuden, näytön laadun ja toteutuksen todellisuuden |
| Päivityksen käynnistävät tekijät | SoA päivitetään palvelumuutosten, toimittajamuutosten, poikkeamien, uusien asiakkaiden, sääntelymuutosten tai auditointihavaintojen jälkeen |
Muuta SoA puolustettavissa olevaksi vaatimustenmukaisuuden sillaksi
Elenan hallitusesitys onnistui, koska hän ei esittänyt kolmea toisistaan irrallista vaatimustenmukaisuusprojektia. Hän esitti yhden hallitun, näyttöön perustuvan toimintamallin, joka rakentui ISO/IEC 27001:2022 -standardin varaan ja jossa SoA toimii siltana sääntelyn, riskien, hallintakeinojen toteutuksen, näytön ja johdon valvonnan välillä.
NIS2 ja DORA eivät tee ISO 27001:stä vanhentunutta. Ne tekevät hyvin rakennetusta ISO 27001 -standardin soveltuvuuslausunnosta arvokkaamman. SoA voi olla yksi paikka, jossa organisaatiosi selittää, miksi hallintakeinot ovat olemassa, miksi poissulkemiset ovat puolustettavissa, miten näyttöä säilytetään, miten toimittajia hallinnoidaan, miten poikkeamat eskaloidaan ja miten johto tietää, että ISMS toimii.
Välitön toimenpiteesi on yksinkertainen:
- Avaa nykyinen SoA.
- Valitse viisi soveltuvaksi merkittyä hallintakeinoa ja kysy: ”Mikä riski, velvoite tai sopimus perustelee tämän?”
- Valitse viisi poissulkemista ja kysy: ”Olisiko tämä edelleen järkevää NIS2-, DORA-, GDPR- tai ISO/IEC 27001:2022 -auditoijalle?”
- Tarkista, että jokaisella soveltuvalla hallintakeinolla on ajantasainen näyttö.
- Varmista, että johto on hyväksynyt jäännösriskit ja SoA-päätökset.
- Päivitä vaatimustenmukaisuusrekisteri, riskirekisteri ja SoA aina, kun palvelut, toimittajat, asiakkaat, sääntely tai poikkeamat muuttuvat.
Clarysec auttaa organisaatioita tekemään tämän Zenith Blueprint Zenith Blueprint -oppaan, Zenith Controls Zenith Controls -oppaan, Enterprise- ja SME-politiikkakokonaisuuksien, riskirekisterityökalujen, SoA-mallien, auditointivalmistelun sekä NIS2:n, DORA:n, GDPR:n, NIST CSF 2.0:n, COBIT 2019:n ja asiakasvarmentamisen poikkivaatimustenmukaisuuden kartoituksen avulla.
Jos SoA ei pysty vastaamaan, miksi hallintakeino on olemassa, kuka sen omistaa, mikä näyttö todentaa sen ja mitä velvoitetta se tukee, se ei ole vielä valmis. Käytä Claryseciä muuttaaksesi sen auditointivalmiiksi vaatimustenmukaisuuden sillaksi ennen kuin viranomainen, auditoija tai asiakas esittää samat kysymykset ensin.
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
