ISO 27001 -standardin mukaisen ISMS:n soveltamisala NIS2:n, DORA:n ja GDPR:n näkökulmasta

Maria, nopeasti kasvavan eurooppalaisen fintech-yhtiön tietoturvajohtaja, ajatteli ISO 27001 -seuranta-auditoinnin olevan hallinnassa.

Sertifikaatti oli tuore. Soveltuvuuslausunto näytti kypsältä. Soveltamisalakuvaus kattoi ”yrityksen tietoturvallisuuden hallintajärjestelmän, joka tukee SaaS-alustan operointia”. Tuotannon pilviympäristö oli dokumentoitu. Tietoturvapoikkeamiin reagoinnin menettely oli olemassa. Riskirekisterissä oli omistajat, päivämäärät ja jäännösriskiluokitukset.

Sitten auditoija esitti yhden yksinkertaisen kysymyksen:

”Mitkä tämän SaaS-alustan osat kuuluvat myös NIS2-rekisteröinnin soveltamisalaan, mitkä ulkoistetut palvelut tukevat DORA-asetuksen mukaisia kriittisiä tai tärkeitä toimintoja rahoitusalan asiakkaillenne, ja missä GDPR:n mukaisia henkilötietoja tarkalleen käsitellään?”

Huone hiljeni.

Lakitiimi avasi taulukon sääntelyvelvoitteista. Tuotetiimi avasi arkkitehtuurikaavion. Tietosuojavastaava avasi käsittelytoimien selosteen. Hankinta avasi toimittajaluettelon. Operatiivinen yksikkö avasi katastrofipalautussuunnitelman. Mikään niistä ei vastannut toisiaan.

ISMS:n soveltamisala sanoi ”SaaS-alusta”. NIS2-arviointi tunnisti digitaalisen infrastruktuurin palveluja useissa jäsenvaltioissa. Asiakassopimuksissa alustan kuvattiin tukevan säänneltyä rahoitusalan toimintaa. GDPR-selosteet sisälsivät identiteettitietoja, telemetriaa, IP-osoitteita, maksujen metatietoja, tukipyyntöjä ja alihankittua analytiikkaa. Katastrofipalautussuunnitelma kattoi tuotannon, mutta ei asiakastukialustaa, jota käytettiin tietoturvaloukkauksia koskevaan viestintään. Toimittajien huolellisuusarviointi kattoi hosting-palveluntarjoajan, mutta ei hallittua havainnointipalvelua, joka oli kytketty tuotannon lokeihin.

Tämä on vuoden 2026 ISMS:n soveltamisalan määrittämisen ongelma. ISO 27001 -sertifiointi on edelleen arvokas, mutta kapea ”vähimmäiskelpoisen soveltamisalan” malli voi muuttua vastuuksi, kun valvojat, asiakkaat ja auditoijat odottavat saman hallintajärjestelmän selittävän NIS2:n keskeiset palvelut, DORA:n kriittiset tai tärkeät toiminnot sekä GDPR-käsittelyn rajat.

ISO/IEC 27001:2022:n, NIS2:n, DORA:n ja GDPR:n näkökulmasta heikko soveltamisala ei ole hallinnollinen puute. Se on ensimmäinen kaatuva palikka. Jos soveltamisala on väärä, riskienarviointi on puutteellinen, SoA johtaa harhaan, toimittajakontrollit ohittavat kriittiset palveluntarjoajat, poikkeamien raportointiaikataulut muuttuvat epävarmoiksi ja tietosuojan osoitusvelvollisuus pirstoutuu tiimien kesken.

Miksi ISO 27001 -standardin mukaisen ISMS:n soveltamisala on nyt sääntelyraja

ISO/IEC 27001:2022 kohta 4.3 edellyttää, että organisaatio määrittää ISMS:n rajat ja sovellettavuuden ottaen huomioon sisäiset ja ulkoiset asiat, sidosryhmien vaatimukset sekä rajapinnat ja riippuvuudet muihin organisaatioihin ISO/IEC 27001:2022.

Tällä sanamuodolla on vuonna 2026 suurempi merkitys kuin aiemmissa sertifiointisykleissä. NIS2, DORA, GDPR, pilvipalvelujen ulkoistaminen, asiakassopimukset, konsernin teknologiapalvelut ja hallinnoidut palveluntarjoajat eivät ole sivuhuomioita. Ne ovat ISMS-rajan määrittämisen lähtötietoja.

NIS2 nostaa hallinnointivaatimuksia keskeisille ja tärkeille toimijoille. Se edellyttää, että johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat niiden toteutusta ja saavat koulutusta. NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun tietoturva, turvallinen hankinta ja kehittäminen, vaikuttavuuden arviointi, kyberhygienia, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta ja tarvittaessa monivaiheinen todennus.

DORA muuttaa soveltamisalakeskustelua rahoitusalan toimijoissa. Sitä sovelletaan 17. tammikuuta 2025 alkaen, ja se asettaa yhdenmukaiset vaatimukset ICT-riskien hallinnalle, ICT:hen liittyvien poikkeamien raportoinnille, digitaalisen operatiivisen häiriönsietokyvyn testaukselle, tietojen jakamiselle ja kolmansien osapuolten ICT-riskien hallinnalle. DORA Article 6 edellyttää dokumentoitua ICT-riskien hallinnan viitekehystä. DORA Article 8 edellyttää ICT:n tukemien liiketoimintatoimintojen, tietovarojen ja ICT-omaisuuserien tunnistamista, luokittelua ja dokumentointia riippuvuuksineen. DORA Article 28 edellyttää kolmansien osapuolten ICT-riskien hallintaa.

GDPR lisää henkilötietojen ulottuvuuden. Sitä sovelletaan automatisoituun tai rakenteiseen henkilötietojen käsittelyyn, mukaan lukien EU:ssa sijaitsevien toimipaikkojen suorittama käsittely sekä tiettyjen EU:n ulkopuolisten rekisterinpitäjien tai käsittelijöiden käsittely, kun ne tarjoavat tavaroita tai palveluja unionissa oleville henkilöille tai seuraavat heidän käyttäytymistään. GDPR Article 30 edellyttää käsittelytoimien selostetta, Article 32 edellyttää käsittelyn turvallisuutta ja Article 33 asettaa odotukset tietoturvaloukkauksista ilmoittamiselle.

Puolustettavissa olevaa ISMS:n soveltamisalaa ei siksi laadita osastojen ympärille. Se laaditaan säänneltyjen palvelujen, kriittisten tai tärkeiden toimintojen, henkilötietojen käsittelyn, tukevien omaisuuserien ja kolmansien osapuolten riippuvuuksien ympärille.

Virhe: ISO 27001:n, NIS2:n, DORA:n ja GDPR:n käsitteleminen erillisinä ohjelmina

Monissa organisaatioissa näkyy yleinen malli:

• Tietoturva laatii ISO 27001 -soveltamisalan.
• Lakitoiminto arvioi NIS2:n sovellettavuuden.
• Riskienhallinta tai vaatimustenmukaisuudesta vastaava toiminto hallinnoi DORA-velvoitteita.
• Tietosuojatoiminto ylläpitää GDPR:n käsittelytoimien selostetta.
• Hankinta omistaa toimittajaluettelon.
• Operatiivinen toiminto omistaa liiketoiminnan jatkuvuuden ja katastrofipalautuksen.

Jokainen tiimi voi tehdä perusteltua työtä. Ongelma on, että säännelty todellisuus kulkee niiden kaikkien läpi.

Pilvipalvelussa ylläpidetty asiakkaan identiteettipalvelu voi samanaikaisesti tukea NIS2-palvelutuotantoa, DORA:n sääntelyn alaista asiakastoimintaa ja GDPR:n mukaista henkilötietojen käsittelyä. Hallittu havainnointipalveluntarjoaja voi olla tietoturvatoimittaja, tietoturvapoikkeamiin reagoinnin riippuvuus, lokitietojen käsittelijä tai alikäsittelijä sekä keskeinen lähtötieto sääntelyilmoituksia koskeville päätöksille. Tukialustaa voidaan pitää ”ei-tuotantoympäristönä”, vaikka siinä käsitellään henkilötietojen tietoturvaloukkauksia koskevaa viestintää ja asiakkaiden näyttöpyyntöjä.

ISMS on paras paikka näiden velvoitteiden yhdistämiseen, koska ISO 27001 pakottaa yhteen kurinalaiseen kysymykseen: mikä on rajan sisällä, mikä on sen ulkopuolella ja miksi?

Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint käsittelee tätä ISMS:n perustan ja johtajuuden vaiheessa, vaiheessa 2: Sidosryhmien tarpeet ja ISMS:n soveltamisala:

”Kun toimintaympäristö on ymmärretty ja sidosryhmien vaatimukset tunnistettu, kohta 4.3 edellyttää ISMS:n rajojen ja sovellettavuuden määrittämistä sen soveltamisalan vahvistamiseksi. ISMS:n soveltamisala on keskeinen määritys, joka kertoo, mikä sisältyy tietoturvan hallintaohjelmaan ja mikä ei.”

Zenith Blueprint korostaa myös kohtaa, joka puuttuu edelleen monista soveltamisalakuvausten teksteistä:

”Jos ulkoistat IT-infrastruktuurisi pilvipalveluntarjoajalle, se ei sulje sitä soveltamisalan ulkopuolelle; sen sijaan sisällytät kyseisen suhteen hallinnan ja pilviomaisuuden osaksi soveltamisalaa.”

Ulkoistaminen siirtää toteutusta. Se ei poista vastuuvelvollisuutta.

Neljän rajan malli ISO 27001 -soveltamisalalle vuonna 2026

NIS2:n, DORA:n ja GDPR:n vaikutuspiirissä oleville organisaatioille Clarysec suosittelee ISO 27001 -standardin mukaisen ISMS:n soveltamisalan määrittämistä neljän toisiinsa kytkeytyvän rajan kautta.

Heikko soveltamisalakuvaus sanoo vain ”SaaS-alusta”. Vahvempi kuvaus kertoo, mitkä liiketoimintapalvelut, järjestelmät, ympäristöt, sijainnit, tietojenkäsittelytoimet, henkilöstöryhmät, toimittajasuhteet ja hallintaprosessit sisältyvät siihen.

Puolustettavampi versio voisi kuulua näin:

”ISMS kattaa yrityksen EU:n SaaS-maksuanalytiikka-alustan tietoturvan hallinnoinnin, riskienhallinnan, operoinnin ja jatkuvan parantamisen, mukaan lukien tuotanto- ja ei-tuotantopilviympäristöt, asiakkaiden identiteettipalvelut, hallintaliittymät, tukitoiminnot, lokitus- ja valvonta-alustat, tietoturvapoikkeamiin reagoinnin, liiketoiminnan jatkuvuuden, toimittajahallinnan sekä kaikki palvelua tukevat henkilötietojen käsittelytoimet. ISMS sisältää ulkoistetun pilvihostingin, hallitun havainnoinnin ja asiakastuen työkalujen hallinnan, kun niitä käytetään palvelun tuottamiseen, häiriönsietokykyyn, tietoturvavalvontaan tai GDPR:ään liittyvään viestintään.”

Tämä soveltamisala ei ole vain pidempi. Se on paremmin auditoitavissa, koska se kytkee yhteen palvelut, omaisuuserät, käsittelyn ja riippuvuudet.

Miten Clarysecin politiikat muuttavat soveltamisalan hallinnointikieleksi

Soveltamisalan ei tule elää erillisessä asiakirjassa. Sen on oltava yhdenmukainen tietoturvapolitiikan, laki- ja sääntelyvaatimusten noudattamisen, riskienhallinnan, tietosuojan, toimittajahallinnan, auditointikriteerien ja jatkuvuussuunnittelun kanssa.

Enterprise Tietoturvapolitiikka Tietoturvapolitiikka ehkäisee rajausten epäselvyyttä:

”Kaikki tätä soveltamisalaa koskevat poissulkemiset tai rajoitukset on dokumentoitava ISMS:n soveltamisalakuvausta koskevassa asiakirjassa ja perusteltava ylimmän johdon muodollisella hyväksynnällä.”

Tällä lausekkeella on merkitystä, kun liiketoimintayksikkö väittää asiakastuen olevan alustan ulkopuolella, vaikka tukihenkilöt pääsevät asiakkaiden tunnisteisiin ja käsittelevät tietoturvaloukkauksia koskevaa viestintää. Poissulkeminen on mahdollista vain, jos se dokumentoidaan, perustellaan ja hyväksytään.

Enterprise Laki- ja sääntelyvaatimusten noudattamisen politiikka Laki- ja sääntelyvaatimusten noudattamisen politiikka tekee oikeudellisesta kartoituksesta operatiivista:

”Kaikki laki- ja sääntelyvelvoitteet on kartoitettava tietoturvallisuuden hallintajärjestelmässä (ISMS) tiettyihin politiikkoihin, kontrolleihin ja omistajiin.”

Tämä on silta oikeudellisen sovellettavuuden ja soveltuvuuslausunnon välillä. NIS2 Article 21 ei saa jäädä lakimuistioon. DORA:n kolmannen osapuolen ICT-palveluja koskevien velvoitteiden ei pidä jäädä vain hankintaohjeisiin. GDPR Article 30- ja Article 32 -velvoitteiden ei tule sijaita vain tietosuojarekisterissä. Niille tarvitaan kartoitetut omistajat, kontrollit ja näyttö.

Enterprise Riskienhallintapolitiikka Riskienhallintapolitiikka laajentaa soveltamisalan kolmansiin osapuoliin:

”Tätä politiikkaa sovelletaan kaikkiin organisaatioyksiköihin, liiketoimintaprosesseihin, järjestelmiin, henkilöstöön ja kolmansien osapuolten järjestelyihin, jotka osallistuvat tietovarojen käsittelyyn, kehittämiseen, säilyttämiseen tai hallintaan.”

Tämä sanamuoto on yhdenmukainen NIS2:n toimitusketjun tietoturvan, DORA:n kolmansien osapuolten ICT-riskien sekä GDPR:n rekisterinpitäjän tai käsittelijän osoitusvelvollisuuden kanssa.

Enterprise Tietosuoja- ja yksityisyydensuojapolitiikka Tietosuoja- ja yksityisyydensuojapolitiikka ankkuroi tietosuojan soveltamisalan käsittelyyn:

”Tätä politiikkaa sovelletaan kaikkiin organisaatioyksiköihin, henkilöstöön ja järjestelmiin, jotka osallistuvat henkilötietojen käsittelyyn, mukaan lukien:”

Periaate on ratkaiseva. Jos järjestelmä käsittelee henkilötietoja, se ei voi olla näkymätön ISMS:lle sillä perusteella, että se on ”vain tuki”, ”ei-tuotantoa” tai ”markkinoinnin omistama”.

Enterprise Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka kytkee soveltamisalan BIA-tuloksiin:

”Tätä politiikkaa sovelletaan kaikkiin organisaatioyksiköihin, tietojärjestelmiin, liiketoimintaprosesseihin, henkilöstöön ja kolmansien osapuolten palveluihin, jotka on luokiteltu kriittisiksi tai keskeisiksi liiketoimintavaikutusten arvioinnin (BIA) tulosten perusteella.”

Tämä lauseke sopii luontevasti yhteen DORA:n kriittisten tai tärkeiden toimintojen ja NIS2:n palvelujatkuvuuden kanssa.

Pienemmille organisaatioille Clarysecin pk-yrityksille tarkoitetut politiikat pitävät sanamuodot tiiviinä säilyttäen saman logiikan. Pk-yritysten Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille määrittää auditoinnin kattavuuden seuraavasti:

”Kaikki tietoturvallisuuden hallintajärjestelmän (ISMS) soveltamisalaan kuuluvat kontrollit ja järjestelmät”

Pk-yritysten Tietosuoja- ja yksityisyydensuojapolitiikka Tietosuoja- ja yksityisyydensuojapolitiikka pk-yrityksille määrittää tietosuojan soveltamisalan seuraavasti:

”Mikä tahansa järjestelmä, sovellus tai sijainti, jossa henkilötietoja säilytetään tai siirretään”

Pk-yritysten Riskienhallintapolitiikka Riskienhallintapolitiikka pk-yrityksille pitää ulkoistetut palvelut näkyvissä:

”Kaikki tiedot, palvelut ja omaisuuserät, joita hallitaan sisäisesti tai kolmansien osapuolten kautta”

Tällaiset lyhyet lausekkeet ovat tehokkaita, koska ne estävät sertifiointirajaa sulkemasta pois säänneltyjä tietoja, pilvipalveluja tai toimittajan hallinnoimia omaisuuseriä.

Omaisuusluettelo on kohta, jossa soveltamisala muuttuu todelliseksi

Soveltamisalakuvaus on uskottava vain, jos se voidaan jäljittää omaisuuseriin, omistajiin, toimittajiin, tietovirtoihin ja näyttöön.

Zenith Blueprint ohjeistaa riskienhallintavaiheen vaiheessa 9: Omaisuuserien, uhkien ja haavoittuvuuksien tunnistaminen organisaatioita luetteloimaan ISMS:n soveltamisalaan kuuluvat omaisuuserät sekä tallentamaan omistajan, sijainnin ja luokittelun. Se antaa käytännön esimerkin:

”Asiakastietokanta – IT-osaston omistama – ylläpidetty AWS:ssä – sisältää henkilötietoja ja taloudellisia tietoja (korkea arkaluonteisuus).”

Sama vaihe lisää soveltamisalaa koskevan muistutuksen, joka liittyy suoraan NIS2:een ja GDPR:ään:

”Varmista, että henkilötietoja sisältävät omaisuuserät on merkitty (GDPR-relevanssia varten) ja kriittisten palvelujen omaisuuserät on tunnistettu (mahdollista NIS2-sovellettavuutta varten, jos toimit säännellyllä sektorilla).”

Clarysecin Zenith Controls: The Cross-Compliance Guide Zenith Controls käsittelee ISO/IEC 27002:2022 control 5.9:ää, tietojen ja muiden niihin liittyvien omaisuuserien luetteloa, perustavana vaatimustenmukaisuuksien välisenä kontrollina. Sen attribuutit luokittelevat kontrollin ennaltaehkäiseväksi, luottamuksellisuutta, eheyttä ja saatavuutta tukevaksi sekä Identify-kyberturvallisuuskonseptiin, omaisuudenhallinnan operatiiviseen kyvykkyyteen ja hallinnointi-, ekosysteemi- ja suojausalueisiin yhdenmukaiseksi.

Zenith Controls selittää GDPR- ja NIS2-relevanssin selkeästi:

”Ilman tarkkaa ja ajantasaista omaisuusluetteloa organisaatiot eivät voi arvioida tai toteuttaa asianmukaisia suojauksia.”

NIS2:n osalta omaisuusluettelo tukee keskeisiä tai tärkeitä palveluja tukevien kriittisten järjestelmien ja komponenttien tunnistamista. DORA:n osalta DORA Article 8 tekee ICT-omaisuuserien ja tietovarojen tunnistamisesta operatiivisen häiriönsietokyvyn keskeisen osan. GDPR:n osalta omaisuusluettelo tukee tietovirtojen kartoitusta, RoPA:n laatua ja tietoturvaloukkauksiin reagointia.

Tukevat ISO-standardit vahvistavat samaa logiikkaa. ISO/IEC 27005:2024 vahvistaa omaisuuserien tunnistamista tietoturvariskien arvioinnissa. ISO 22301:2019 tukee liiketoiminnan jatkuvuuteen tarvittavien resurssien tunnistamista. ISO/IEC 19770-1:2017 tukee IT-omaisuudenhallinnan kypsyyttä. ISO/IEC 27017:2015 ja ISO/IEC 27018:2019 tukevat pilvikohtaisia kontrolleja ja henkilötietojen suojaamista julkisissa pilvipalveluissa. ISO/IEC 27701:2019 laajentaa tietosuojatietojen hallintaa. ISO/IEC 29100:2011 tuo mukaan tietosuojaperiaatteita, kuten läpinäkyvyyden, minimoinnin ja tietoturvan suojatoimet.

Käytännön soveltamisalaharjoitus SaaS- ja fintech-tiimeille

Aloita yhdestä säännellystä palvelusta, älä koko yrityksestä. Esimerkiksi: ”EU:n maksuanalytiikka-SaaS rahoituslaitoksille.”

Rakenna sen jälkeen palvelu–omaisuuserä–käsittely-kartta.

Yksityiskohtaisempi omaisuuseränäyte voi näyttää tältä.

Käytä seuraavaksi Zenith Blueprint -oppaan vaihetta 13: Riskienkäsittelyn suunnittelu ja soveltuvuuslausunto. Opas ohjeistaa käyttäjiä rakentamaan SoA:n mallipohjalla, jossa luetellaan kaikki liitteen A kontrollit, ja päättämään sovellettavuudesta riskien käsittelyn, lakisääteisten tai sopimusperusteisten vaatimusten, soveltamisalarelevanssin ja organisaation toimintaympäristön perusteella. Siinä todetaan:

”Päätä kunkin SoA-taulukon kontrollin eli rivin osalta, sovelletaanko sitä ISMS:ään.”

Yllä olevan esimerkin osalta SoA:n tulisi huomioida kontrollit toimittajaturvallisuudelle, pilvipalveluille, poikkeamien hallinnalle, jatkuvuudelle, laki- ja sääntelyvaatimuksille, tietosuojalle, haavoittuvuuksien hallinnalle, varmuuskopioille, lokitukselle, seurannalle, kryptografialle, turvalliselle kehittämiselle, tietoturvatestaukselle ja muutoksenhallinnalle.

Käytännön työnkulku on seuraava:

1. Luo riskirekisteriin ja SoA Builderiin välilehti ”ISMS:n soveltamisalan kartoitus”.
2. Lisää yksi rivi kutakin säänneltyä palvelua tai tuotelinjastoa kohti.
3. Linkitä jokainen palvelu omaisuuseriin, tietotyyppeihin, toimittajiin, sijainteihin ja liiketoimintavastaaviin.
4. Merkitse NIS2-relevanssi, DORA-relevanssi ja GDPR-käsittelyn relevanssi.
5. Lisää riskiskenaariot palvelun poissaololle, henkilötietojen tietoturvaloukkaukselle, toimittajan häiriölle, pilven virheelliselle konfiguraatiolle, kriittiselle haavoittuvuudelle ja poikkeamaraportoinnin epäonnistumiselle.
6. Valitse SoA-kontrollit näiden riskien ja velvoitteiden perusteella.
7. Dokumentoi poissulkemiset, korvaavat kontrollit ja riskin hyväksyminen.
8. Hanki ylimmän johdon hyväksyntä lopullisille rajoille ja poissulkemisille.
9. Syötä lopullinen raja sisäiseen tarkastukseen, johdon katselmointiin ja toimittajien seurantaan.

Lopputulos ei ole vain parempi soveltamisalakuvaus. Se on puolustettavissa oleva ketju säännellystä palvelusta omaisuuserään, toimittajaan, tietoon, kontrolliin, omistajaan ja näyttöön.

Vaatimustenmukaisuuksien välinen kartoitus: yksi soveltamisala, monta velvoitetta

Hyvin rajattu ISO 27001 -standardin mukainen ISMS toimii operatiivisena kerroksena, jossa NIS2:n, DORA:n, GDPR:n, NIST CSF:n ja COBITin odotukset voidaan sovittaa yhteen.

ISO/IEC 27002:2022 control 5.31:n, lakisääteisten, sääntelyyn perustuvien ja sopimusperusteisten vaatimusten, osalta Zenith Controls kytkee vaatimustenmukaisuusvelvoitteet tietosuojaan, henkilötietojen suojaan, tallenteiden säilytykseen, riippumattomaan katselmointiin ja sisäisen politiikan noudattamiseen. Se kartoittuu luontevasti GDPR:n osoitusvelvollisuuteen, NIS2:n toimitusketjun vaatimustenmukaisuuteen, DORA:n ICT-riskien hallintaan ja vaatimustenmukaisuuteen, NIST CSF:n hallinnointiin sekä COBIT 2019:n ulkoisen vaatimustenmukaisuuden seurantaan.

ISO/IEC 27002:2022 control 5.34:n, henkilötietojen yksityisyyden ja suojan, osalta Zenith Controls kytkee tietosuojan omaisuusluetteloon, pilvipalveluihin, luokitteluun, tietojen siirtoon, pääsynhallintaan, identiteetinhallintaan ja projektimuutosten katselmointeihin. Sen GDPR-kartoitus kattaa käsittelyn turvallisuuden ja sisäänrakennetun tietosuojan. Sen DORA-kartoitus tukee tietojen eheyttä, turvallisuutta ja luottamuksellisuutta, mukaan lukien ICT-palveluissa käsiteltävät henkilötiedot.

Periaate on yksinkertainen: älä luo neljää irrallista vaatimustenmukaisuusohjelmaa. Luo yksi rajattu ISMS, joka pystyy selittämään, miten velvoitteet täytetään, miten niistä esitetään näyttö ja miten ne auditoidaan.

Poikkeamaraportoinnin soveltamisala: missä rajat vaikuttavat sääntelyn aikarajoihin

Virheellinen soveltamisala tulee kivuliaan näkyväksi poikkeamatilanteissa.

NIS2 Article 23 edellyttää merkittävien poikkeamien vaiheittaista raportointia, mukaan lukien varhaisvaroitus 24 tunnin kuluessa, poikkeamailmoitus 72 tunnin kuluessa, väliraportit pyydettäessä sekä loppuraportti yhden kuukauden kuluessa. Myös viestintä vaikutuksen kohteena oleville vastaanottajille voi olla tarpeen.

DORA edellyttää, että rahoitusalan toimijat havaitsevat, hallitsevat, luokittelevat ja raportoivat merkittävät ICT:hen liittyvät poikkeamat käyttäen kriteerejä, kuten vaikutuksen kohteena olevat asiakkaat tai vastapuolet, kesto, käyttökatko, maantieteellinen levinneisyys, tietojen menetykset, vaikutuksen kohteena olevien palvelujen kriittisyys ja taloudellinen vaikutus. Asiakkaille on ilmoitettava ilman aiheetonta viivytystä, jos merkittävä ICT-poikkeama vaikuttaa heidän taloudellisiin etuihinsa.

GDPR:n henkilötietojen tietoturvaloukkauksesta ilmoittaminen riippuu siitä, johtaako loukkaus henkilötietojen vahingossa tapahtuvaan tai lainvastaiseen tuhoutumiseen, häviämiseen, muuttamiseen, luvattomaan luovuttamiseen tai luvattomaan pääsyyn henkilötietoihin.

Jos tukialusta, lokiympäristö, identiteettipalvelu, asiakasviestintäkanava tai hallittu havainnointipalveluntarjoaja on ISMS:n soveltamisalan ulkopuolella, poikkeamatiimit eivät välttämättä tiedä, laukaiseeko tapahtuma NIS2-, DORA-, GDPR- tai asiakassopimusraportoinnin vai kaikki nämä. Tämä epävarmuus kuluttaa raportointiaikaa.

Kypsä soveltamisala sisältää poikkeamiin liittyvät riippuvuudet: havainnointityökalut, lokisäilöt, forensiset tietovarastot, asiakasviestintäkanavat, tukityökalut, varmuuskopiointiympäristöt, poikkeamatilanteen viestintäsillat ja toimittajat, jotka osallistuvat luokitteluun tai palautumiseen.

Miten auditoijat ja valvojat testaavat ISMS:n soveltamisalaa

Vahva soveltamisala kestää otannan. Heikko soveltamisala romahtaa, kun auditoijat vertaavat dokumentteja todellisuuteen.

Zenith Controls tarjoaa hyödyllisiä auditointiodotuksia ISO/IEC 27002:2022 control 5.9:lle. ISO/IEC 19011 -tyyppiset auditoijat pyytävät inventaariota varhaisessa vaiheessa rajatakseen muita arviointeja ja tehdäkseen pistokoetarkastuksia fyysisistä, ohjelmisto- ja pilviomaisuuseristä. ISO/IEC 27007 -tyyppiset auditoijat kysyvät, miten ja milloin inventaariota päivitetään, ja etsivät yhteyksiä hankintaan, muutoksenhallintaan ja käytöstäpoistoon. NIST SP 800-53A -tyyppiset auditoijat varmistavat, että inventaarion tiedot sisältävät omaisuuserän tyypin, omistajan, sijainnin, tarvittaessa verkko-osoitteen ja tilan sekä että pilvi-, virtuaali- ja mobiiliomaisuuserät sisältyvät mukaan.

Control 5.31:n osalta Zenith Controls toteaa, että sertifiointiauditoijat odottavat vaatimustenmukaisuusrekisteriä tai luetteloa laeista ja sopimuksista, joihin viitataan SoA:ssa ja riskienkäsittelysuunnitelmissa. COBIT-auditoijat etsivät vaatimustenmukaisuuden omistajia, arviointeja ja raportointia ylemmälle johdolle. ISACA ITAF -auditoijat ottavat näytöstä otoksia varmistaakseen, että organisaatio ei ainoastaan tunne velvoitteitaan vaan myös varmistaa aktiivisesti niiden täyttymisen.

Control 5.34:n osalta auditoijat katselmoivat tietosuojapolitiikkoja, tietoaineistorekistereitä, DPIA:ita, koulutuslokeja, salausnäyttöä, pääsynhallintaa, DSAR-otoksia, sisäänrakennetun tietosuojan näyttöä ja henkilötietoja koskevien poikkeamien kirjauksia. Soveltamisalakuvaus, joka sulkee pois henkilötietoja käsittelevän järjestelmän, kyseenalaistetaan nopeasti.

Hallituksen kysymys: mitä ei voida sulkea pois?

Ylin johto kysyy usein, voiko liiketoimintayksikkö, sijainti, toimittaja tai järjestelmä jäädä ISMS:n soveltamisalan ulkopuolelle. Joskus vastaus on kyllä. Ei kuitenkaan silloin, jos poissulkeminen estää organisaatiota täyttämästä lakisääteisiä, sääntelyyn perustuvia, sopimusperusteisia tai palvelun tietoturvaa koskevia velvoitteita.

Käytä tätä poissulkemistestiä ennen minkään rajauksen hyväksymistä:

• Tukeeko yksikkö, järjestelmä tai toimittaja NIS2:n sääntelyn alaista palvelua?
• Tukeeko se DORA:n mukaista kriittistä tai tärkeää toimintoa organisaatiolle tai sen säännellyille asiakkaille?
• Kerääkö, säilyttääkö, siirtääkö, lokittaako, tukeeko tai poistaako se henkilötietoja?
• Tarjoaako se soveltamisalaan kuuluvalle palvelulle tietoturvavalvontaa, identiteettiä, varmuuskopiointia, tietoturvapoikkeamiin reagointia tai palautumista?
• Tuottaako se näyttöä, jota tarvitaan poikkeaman luokitteluun tai sääntelyilmoitukseen?
• Edellyttääkö asiakassopimus sen kuulumista ISMS:n piiriin?
• Vaikuttaisiko sen vaarantuminen luottamuksellisuuteen, eheyteen, saatavuuteen, lakisääteisten vaatimusten noudattamiseen tai palvelun jatkuvuuteen ilmoitetussa soveltamisalassa?

Jos vastaus on kyllä, poissulkeminen edellyttää vahvaa näyttöä, korvaavaa hallinnointia, riskin hyväksymistä ja ylimmän johdon muodollista hyväksyntää. Monissa tapauksissa sitä ei pidä sulkea pois.

Nykyaikaisen ISO 27001 -standardin mukaisen ISMS:n soveltamisalan tulisi sisältää:

1. Katetut liiketoimintapalvelut ja tuotelinjat.
2. Katetut oikeushenkilöt, organisaatioyksiköt ja sijainnit.
3. Asiakassegmentit ja lainkäyttöalueet, jotka synnyttävät velvoitteita.
4. Kriittiset tai tärkeät toiminnot sekä BIA-perusteiset keskeiset palvelut.
5. Tietovarat, ICT-omaisuuserät ja pilviympäristöt.
6. Henkilötietojen käsittelytoimet ja henkilötietovarannot.
7. Kehitys-, testaus-, tuki-, seuranta- ja poikkeamaprosessit.
8. Toimittajat ja ulkoistetut palvelut, jotka tukevat soveltamisalaan kuuluvia palveluja.
9. Rajapinnat ja riippuvuudet konserniyhtiöihin tai ulkoisiin palveluntarjoajiin.
10. Nimenomaiset poissulkemiset perusteluineen, riskin hyväksymisineen ja ylimmän johdon hyväksyntöineen.

Näin ISO 27001 -soveltamisalasta tulee hallitustason hallinnointikannanotto, ei sertifioinnin oikotie.

Tee ISMS:n soveltamisalasta auditointivalmis ennen kuin auditoija määrittää sen puolestasi

Huonoin hetki havaita soveltamisalaongelma on sertifioinnin, seurantatarkastelun, asiakkaan toimittajahuolellisuusarvioinnin tai käynnissä olevan poikkeaman aikana.

Kapea sertifikaatti voi täyttää hankinnan valintaruudun, mutta se ei kestä vakavaa tarkastelua, jos se sulkee pois palvelut, ICT-toiminnot, toimittajat ja henkilötietojen käsittelyn, jotka aiheuttavat sääntelyaltistusta. Vuonna 2026 auditoinnit läpäisevät luottavaisesti ne organisaatiot, jotka voivat näyttää yhden yhtenäisen kartan säännellystä palvelusta omaisuuserään, toimittajaan, henkilötietoihin, kontrolliin, omistajaan ja näyttöön.

Aloita kolmella konkreettisella toimenpiteellä:

1. Käytä Zenith Blueprint Zenith Blueprint -oppaan ISMS:n perusta ja johtajuus -vaiheen vaihetta 2 laatiaksesi ISMS:n soveltamisalan uudelleen palvelujen, toimintojen, käsittelyn ja riippuvuuksien ympärille.
2. Käytä Zenith Controls Zenith Controls -opasta omaisuusluettelon, lakisääteisten velvoitteiden ja henkilötietojen suojan kartoittamiseen ISO 27001:n, NIS2:n, DORA:n, GDPR:n, NISTin ja COBIT 2019:n auditointiodotuksiin.
3. Yhdenmukaista politiikkojen soveltamisala Clarysecin Tietoturvapolitiikan Tietoturvapolitiikka, Laki- ja sääntelyvaatimusten noudattamisen politiikan Laki- ja sääntelyvaatimusten noudattamisen politiikka, Riskienhallintapolitiikan Riskienhallintapolitiikka, Tietosuoja- ja yksityisyydensuojapolitiikan Tietosuoja- ja yksityisyydensuojapolitiikka sekä Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikan Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka avulla.

Jos nykyinen ISMS:n soveltamisalasi näyttää edelleen osastotunnisteelta, rakenna se uudelleen vaatimustenmukaisuuden rajaksi. Lataa Clarysecin työkalupaketit, kartoita yksi säännelty palvelu alusta loppuun ja muuta ISO 27001 -soveltamisalasi auditointivalmiiksi näytöksi NIS2:lle, DORA:lle ja GDPR:lle.