Pilvialueiden hallinta GDPR:n, NIS2:n ja DORA:n näkökulmasta

Tiistaiaamuna klo 08.17 nopeasti kasvavan eurooppalaisen fintech-yhtiön tietoturvajohtaja Maria saa viestin, jota jokainen säännelty pilvipalveluasiakas ennen pitkää pelkää.

Hankintatiimi välittää lyhyen toimittajailmoituksen:

“Pilvianalytiikan toimittajamme siirtää EU-asiakkaiden telemetrian uudelle alueelle suorituskykysyistä. Toimittajan mukaan tietoturvavaikutusta ei ole. Voimmeko hyväksyä tämän?”

Ennen kuin Maria ehtii vastata, ensisijaiselta pilvipalveluntarjoajalta saapuu toinen ilmoitus. 90 päivän kuluttua palveluntarjoaja aikoo “optimoida globaalin tukimallinsa” ohjaamalla Tier 2 -tukipyynnöt uuden alikäsittelijän kautta. Nopea tarkastelu osoittaa, että alikäsittelijän päätoimipaikka sijaitsee maassa, jolle ei ole annettu GDPR:n mukaista tietosuojan riittävyyspäätöstä.

Klo 09.00 keskusteluun ovat liittyneet lakitoiminto, tietosuoja, häiriönsietokyky, hankinta, pilviarkkitehtuuri ja taloushallinnon vaatimustenmukaisuus. DPO kysyy, tarvitaanko siirtovaikutusten arviointi. Häiriönsietokyvystä vastaava päällikkö kysyy, vaikuttaako uusi alue kriittisen palvelun palautussuunnitelmaan. Taloushallinnon vaatimustenmukaisuudesta vastaava henkilö kysyy, näkyykö palveluntarjoaja DORA:n ICT-kolmansien osapuolten rekisterissä. Pilvitiimi tarkistaa tuotantodatan käsittelytason ja huomaa, että kysymys on analytiikkaa laajempi. Varmuuskopiot, operatiiviset lokit, tukipyynnöt, data lake -tietovarantojen viennit, hätätilanteen käyttöoikeudet ja alihankkijoiden pääsy voivat kaikki kuulua soveltamisalaan.

Tämä on vuoden 2026 todellinen pilvipalvelujen hallintaongelma.

Useimmilla organisaatioilla on pilvipolitiikka. Monilla on toimittajarekisteri. Joillakin on GDPR-siirtoarviointi. Harvempi pystyy vastaamaan näyttöön perustuen vaikeampaan auditointikysymykseen:

Missä säännelty data ja kriittinen ICT-käsittely tarkalleen sijaitsevat, kuka voi käyttää niitä mistä sijainnista, mitä tapahtuu häiriösiirrossa ja mikä sopimusperusteinen kontrolli estää palveluntarjoajaa muuttamasta vastausta ilman hyväksyntää?

Tätä tarkoittaa pilvialueiden hallinta. Se ei ole yksittäinen oikeudellinen valintaruutu. Se on elävä kontrollijärjestelmä, joka kattaa ISO/IEC 27001:2022:n, ISO/IEC 27002:2022:n pilvi- ja toimittajakontrollit, GDPR:n osoitusvelvollisuuden, NIS2:n palvelujen häiriönsietokyvyn sekä DORA:n ICT-kolmansien osapuolten valvonnan.

Tietojen sijainnista on tullut operatiivinen kontrolli

Vuosien ajan “palvelun tuottaminen vain EU:ssa” miellettiin tietojenkäsittelysopimuksen lausekkeeksi. Se ei enää riitä. Nykyaikaisen pilvidatan sijaintia ja aluehallintaa koskevan ohjelman on katettava vähintään kuusi operatiivista tasoa:

1. Ensisijaiset tuotannon tallennus- ja laskenta-alueet.
2. Varmuuskopiointi-, arkistointi- ja katastrofipalautusalueet.
3. Lokituksen, valvonnan, SIEM-ratkaisujen ja havainnoitavuusdatan sijainnit.
4. Tukipääsy, mukaan lukien etähallinta ja hätätilanteen käyttöoikeudet.
5. Alikäsittelijät ja alihankkijat, mukaan lukien hallinnoidut palvelut ja markkinapaikkakomponentit.
6. Tietojen siirtoreitit ympäristöjen, ohjelmointirajapintojen, analytiikka-alustojen ja asiakastukityökalujen välillä.

GDPR tekee tästä välttämätöntä, koska henkilötiedot voivat sisältää verkkotunnisteita, IP-osoitteita, asiakastilitunnisteita, käyttäjätietueita, laitetunnisteita, operatiivista metatietoa ja tukitallenteita. Myös käsittely määritellään laajasti, ja siihen sisältyvät säilyttäminen, pääsy, käyttö, luovuttaminen, poistaminen ja tuhoaminen. “Lähetämme vain lokeja” ei ole turvallinen poikkeus, jos lokit sisältävät tunnisteita.

GDPR Article 5 sisältää myös osoitusvelvollisuuden periaatteen. Rekisterinpitäjien ei tule ainoastaan noudattaa lainmukaisuuden, kohtuullisuuden, läpinäkyvyyden, käyttötarkoitussidonnaisuuden, tietojen minimoinnin, säilytyksen rajoittamisen, eheyden ja luottamuksellisuuden periaatteita. Niiden on myös kyettävä osoittamaan noudattaminen. Pilvialueiden hallinta on yksi tapa tehdä tämä osoittaminen käytännössä todennettavaksi.

NIS2 laajentaa kysymyksen tietosuojasta häiriönsietokykyyn. Article 21:n mukaan keskeisten ja tärkeiden toimijoiden on toteutettava asianmukaiset tekniset, operatiiviset ja organisatoriset toimenpiteet niiden verkko- ja tietojärjestelmiin kohdistuvien riskien hallitsemiseksi, joita käytetään toiminnassa tai palvelujen tuottamisessa. Lueteltuihin toimenpiteisiin kuuluvat toimitusketjun tietoturva, liiketoiminnan jatkuvuus, varmuuskopioinnin hallinta, katastrofipalautus, kriisinhallinta, pääsynhallinta, omaisuudenhallinta, salaus ja vaikuttavuuden arviointi. Jos pilvialuetta koskeva päätös vaikuttaa soveltamisalaan kuuluvan palvelun saatavuuteen tai palautumiseen, kyse ei ole vain tietosuojasta. Kyse on häiriönsietokyvystä.

Rahoitusalan toimijoille DORA nostaa vaatimustasoa edelleen. DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja siinä asetetaan vaatimuksia ICT-riskien hallinnalle, poikkeamien raportoinnille, digitaalisen operatiivisen häiriönsietokyvyn testaukselle, ICT-kolmansien osapuolten riskienhallinnalle ja sopimusjärjestelyille. Article 28 edellyttää, että rahoitusalan toimijat hallitsevat ICT-kolmansien osapuolten riskiä olennaisena osana ICT-riskien hallinnan viitekehystä, ylläpitävät sopimusjärjestelyjen rekistereitä, arvioivat keskittymäriskiä ja suunnittelevat irtautumisen kriittisistä tai tärkeistä toiminnoista. Article 30 edellyttää sopimuksilta selkeyttä palvelujen ja tietojenkäsittelyn sijainneista, auditointi- ja käyttöoikeuksista, poikkeamatilanteiden tuesta, alihankinnasta, palautumisesta, palautuksesta ja irtautumissiirtymästä.

DORA toimii rahoitusalan toimijoiden sektorikohtaisena sääntelykehyksenä, kun taas NIS2 on edelleen merkityksellinen laajemmassa toimitusketjussa, erityisesti pilvipalvelujen tarjoajille, datakeskusten tarjoajille ja hallinnoitujen palvelujen tarjoajille (MSP). Yksittäinen arvioimaton alikäsittelijä voi siten aiheuttaa ketjureaktion rahoitusalan häiriönsietokyvyn, toimitusketjun tietoturvan ja tietosuojavelvoitteiden välillä.

Yksinkertaisesti sanottuna: jos säännelty liiketoiminta ei pysty hallitsemaan, missä sen pilvikäsittely tapahtuu, se ei voi uskottavasti hallita ICT-kolmansien osapuolten riskiä.

Käytä ISO 27001:tä hallintajärjestelmän ankkurina

ISO/IEC 27001:2022 tarjoaa rakenteen, jolla tietojen sijaintiin liittyvä epäselvyys muutetaan hallituksi hallintajärjestelmäksi.

Kohdat 4.1–4.4 edellyttävät, että organisaatio määrittää ISMS:n toimintaympäristössään, mukaan lukien sisäiset ja ulkoiset tekijät, sidosryhmien vaatimukset, lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset velvoitteet sekä rajapinnat ja riippuvuudet muihin organisaatioihin. Pilvialueiden hallinnassa ISMS:n soveltamisalaan tulee nimenomaisesti sisällyttää pilvipalvelut, ulkoistettu ICT-käsittely, kriittiset palveluriippuvuudet ja säännellyt tietovirrat.

Kohdat 5.1–5.3 asettavat johdon vastuuseen. Ylimmän johdon on yhdenmukaistettava tietoturvapolitiikka ja tavoitteet strategisen suunnan kanssa, varattava resurssit, osoitettava vastuut ja varmistettava, että ISMS:n suorituskyvystä raportoidaan. Tässä pilvidatan sijainnista tulee johdon ja hallituksen asia, erityisesti NIS2-toimijoilla, joiden johtoelinten on hyväksyttävä ja valvottava kyberturvallisuuden riskienhallintatoimenpiteitä, sekä DORA:n piiriin kuuluvilla rahoitusalan toimijoilla, joiden johtoelin vastaa ICT-riskien hallinnasta.

Kohdat 6.1.1–6.1.3 muodostavat riskienhallinnan moottorin. Organisaatio tarvitsee toistettavan riskien arviointiprosessin, riskinomistajat, vaikutus- ja todennäköisyyskriteerit, käsittelyvaihtoehdot, valitut kontrollit, soveltuvuuslausunnon ja jäännösriskin hyväksynnän. Pilvialuemuutos ei saa tulla hyväksytyksi epämuodollisella sähköpostilla. Sen tulee käynnistää riskien arviointi tai muutoksen katselmointi, kun se vaikuttaa säänneltyyn dataan, kriittisiin toimintoihin, toimittajiin tai jatkuvuusoletuksiin.

Kohta 8.1 muuttaa suunnittelun operatiiviseksi ohjaukseksi. Prosessit on toteutettava, ohjattava, dokumentoitava, muutettava hallitusti ja ulotettava ISMS:n kannalta olennaisiin ulkoisesti tuotettuihin tuotteisiin ja palveluihin. Kohdat 8.2 ja 8.3 edellyttävät uudelleenarviointia ja riskien käsittelyä suunnitelluin väliajoin tai merkittävien muutosten tapahtuessa. Pilvialueen migraatio, varmuuskopioiden replikointi, uusi lokitusalusta tai tukipalvelun alikäsittelijämuutos ovat kaikki uudelleenarvioinnin kohteita.

ISO/IEC 27002:2022:n kontrollikokonaisuus tarjoaa tämän jälkeen käytännön kontrolliperheen. Olennaisimpia kontrolleja ovat:

• 5.9 Tietojen ja muiden niihin liittyvien omaisuuserien inventaario.
• 5.14 Tiedonsiirto.
• 5.15 Pääsynhallinta.
• 5.19 Tietoturva toimittajasuhteissa.
• 5.20 Tietoturvan käsittely toimittajasopimuksissa.
• 5.22 Toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta.
• 5.23 Tietoturva pilvipalvelujen käytössä.
• 5.29 Tietoturva häiriötilanteissa.
• 5.30 ICT-valmius liiketoiminnan jatkuvuuteen.
• 5.31 Lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset vaatimukset.
• 5.34 Yksityisyys ja PII-tietojen suojaaminen.
• 5.36 Tietoturvapolitiikkojen, sääntöjen ja standardien noudattaminen.
• 8.11 Tietojen maskaus.
• 8.12 Tietovuodon estäminen.
• 8.13 Tietojen varmuuskopiointi.
• 8.15 Lokitus.
• 8.16 Valvontatoimet.
• 8.20 Verkkoturvallisuus.
• 8.24 Kryptografian käyttö.
• 8.25 Turvallisen kehittämisen elinkaari.
• 8.27 Turvallisen järjestelmäarkkitehtuurin ja suunnittelun periaatteet.
• 8.32 Muutoksenhallinta.

Clarysecin Zenith Controls: The Cross-Compliance Guide Zenith Controls käsittelee ISO/IEC 27002:2022:n kontrollia 5.23, tietoturvaa pilvipalvelujen käytössä, ennaltaehkäisevänä kontrollina, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta sekä tuottaa operatiivista kyvykkyyttä toimittajasuhteiden tietoturvassa ja tietoturvan osa-alueilla hallinnon, ekosysteemin ja suojauksen näkökulmista. Opas kytkee kontrollin 5.23 kontrolleihin 5.19 toimittajasuhteet, 5.14 tiedonsiirto, 5.9 omaisuusluettelo, 8.11 ja 8.12 tietojen maskaus ja tietovuodon estäminen, 8.20 verkkoturvallisuus sekä 8.25 turvallisen kehittämisen elinkaari.

Zenith Controls -oppaan keskeinen havainto on:

“Pilvipalveluntarjoajat (CSP) toimivat kriittisinä toimittajina, ja siksi kaikki 5.19:n mukaiset toimittajan valintaa, sopimista ja riskienhallintaa koskevat kontrollit soveltuvat niihin. 5.23 menee kuitenkin pidemmälle käsittelemällä pilvikohtaisia riskejä, kuten moniasiakkuutta, tietojen sijainnin läpinäkyvyyttä ja jaetun vastuun malleja.”

Tämä lause tiivistää hallinnan muutoksen. Pilvipalveluntarjoaja ei ole vain yksi toimittaja muiden joukossa. Se on usein paikka, jossa säännelty käsittely tosiasiallisesti tapahtuu.

Piilevät sijaintiansat: varmuuskopiot, lokit, tuki ja alikäsittelijät

Useimmat tietojen sijaintiin liittyvät epäonnistumiset eivät ala tuotantotietokannasta. Ne alkavat tukijärjestelmistä, joita ei koskaan sisällytetty asianmukaisesti tietovirtojen katselmointiin.

Varmuuskopiot ovat klassinen esimerkki. SaaS-alusta voi toimia Frankfurtissa tai Dublinissa, mutta automatisoidut varmuuskopiot replikoituvat muualle häiriönsietokyvyn tai kustannussyiden vuoksi. Jos varmuuskopio sisältää henkilötietoja, asiakastietueita, todennuslokeja tai säänneltyä tapahtumahistoriaa, varmuuskopioalueella on merkitystä. NIS2 Article 21:n mukaan varmuuskopioinnin hallinta ja katastrofipalautus ovat osa tietoturvan perustasoa. DORA:n mukaan kriittisten tai tärkeiden toimintojen jatkuvuus ja testatut irtautumisstrategiat edellyttävät palautussijaintien ja palautusriippuvuuksien tuntemista.

Lokit ovat toinen heikko kohta. Tietoturvatiimit keskittävät telemetrian SIEM-, havainnoitavuus- ja data lake -palveluihin. Nämä lokit voivat sisältää IP-osoitteita, käyttäjätunnisteita, ylläpitäjien toimia, maksujen metatietoja, epäonnistuneita todennusyrityksiä, asiakastilitunnisteita tai tukipalvelun jäljitettävyystietoja. Jos lokit siirtyvät globaaliin valvontapalveluun, organisaatio on saattanut luoda rajat ylittävän siirron huomaamattaan.

Clarysecin Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME käsittelee suoraan toimittajan näyttöä:

“Sopimusten on edellytettävä, että palveluntarjoajat säilyttävät lokit vähintään 12 kuukauden ajan ja antavat pääsyn niihin pyynnöstä”

Lainaus on osiosta “Hallintavaatimukset”, politiikan lauseke 5.5.1.3. Tietojen sijainnin hallinnassa saman sopimuskatselmoinnin tulee vahvistaa, missä lokit säilytetään, kuka voi käyttää niitä ja onko lokinäyttö saatavilla poikkeamatutkinnan tai viranomaistiedustelun aikana.

Tukipääsy on hienovaraisempi kysymys. Palveluntarjoaja voi ylläpitää dataa EU:ssa, mutta EU:n ulkopuolella toimivat tuki-insinöörit voivat päästä asiakasympäristöihin, tietokantojen tilannevedoksiin, diagnostiikkapaketteihin tai tikettien liitteisiin. Hyväksyttävyys riippuu käsiteltävästä datasta, siirtomekanismista, roolista, sopimusperusteisista suojatoimista, pääsynhallinnasta ja lokituksesta. Arkkitehtuuri voi olla alueellinen, mutta ihmisten pääsymalli globaali.

Alikäsittelijät muodostavat viimeisen katvealueen. Suora toimittajasi voi tukeutua pilvi-infrastruktuuriin, sisällönjakeluverkkoihin, hallinnoituihin tietokantoihin, tikettijärjestelmiin, analytiikkapalveluihin, offshore-tukitiimeihin tai tietoturvatoimittajiin. DORA Article 29 edellyttää alihankintariskien, kolmansien maiden palveluntarjoajien, tietojen palauttamista koskevien rajoitteiden, tietosuojavaatimustenmukaisuuden ja monimutkaisten alihankintaketjujen arviointia. NIS2 Article 21 edellyttää, että toimijat ottavat huomioon suorien toimittajien ja palveluntarjoajien kyberturvallisuuskäytännöt. GDPR edellyttää henkilötietojen käsittelijöiltä alikäsittelijöiden hallintaa tavalla, joka säilyttää rekisterinpitäjän kyvyn noudattaa velvoitteitaan.

Clarysecin Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME tekee tästä käytännönläheistä:

“Kun toimittajien edellytetään säilyttävän dataa muualla kuin organisaation omissa tiloissa, yrityksen on hankittava varmistus tietosuojasta, fyysisestä turvallisuudesta ja maantieteellisestä tallennussijainnista (esim. palvelun tuottaminen vain EU:ssa, kun GDPR sitä edellyttää).”

Tämä on osiosta “Politiikan toteutusvaatimukset”, politiikan lauseke 6.2.4. Sama politiikka edellyttää myös:

“Rajoitukset lisäalihankinnalle ilman hyväksyntää”

Lainaus on osiosta “Hallintavaatimukset”, politiikan lauseke 5.3.5. Yhdessä nämä lausekkeet muuttavat tietojen sijainnin toimittajahallinnan työnkuluksi, eivät hankinnan mieltymykseksi.

Muuta politiikka toimeenpantavaksi pilvialueiden hallinnaksi

Pilvialueiden hallinnan on oltava sovellettavissa, katselmoitavissa ja auditoitavissa.

Pk-yrityksille Cloud Usage Policy-sme Cloud Usage Policy - SME asettaa perustason:

“Tietojen sijainnin ja tietosuojakäytäntöjen on noudatettava sovellettavia lakisääteisiä vaatimuksia (esim. GDPR)”

Tämä on osiosta “Hallintavaatimukset”, politiikan lauseke 5.2.3. Sama politiikka edellyttää, että pilvipalvelujen hallintatallenteisiin sisällytetään:

“Maa tai alue, jossa dataa säilytetään”

Lainaus on osiosta “Hallintavaatimukset”, politiikan lauseke 5.3.4.

Suuremmille organisaatioille Cloud Usage Policy Cloud Usage Policy on sopimusperusteisen toimeenpanon osalta täsmällisempi:

“Tietojen sijaintia koskevat vaatimukset on toteutettava sopimusperusteisesti (esim. vain EU:ssa tapahtuva säilytys GDPR-säännellylle datalle).”

Tämä on osiosta “Politiikan toteutusvaatimukset”, politiikan lauseke 6.6.2. Se toteaa myös:

“Rajat ylittävien tietojen siirtojen on oltava GDPR Chapter V:n ja soveltuvin osin DORA Article 28:n mukaisia.”

Tämä on osiosta “Politiikan toteutusvaatimukset”, politiikan lauseke 6.6.3.

Yritysversio kiinnittää huomiota myös seuraavaan:

“Tietojen sijaintia ja tietojen omistajuutta koskevat takeet”

Lainaus on osiosta “Roolit ja vastuut”, politiikan lauseke 4.5.1.2.

Third party and supplier security policy Third party and supplier security policy lisää sopimuskerroksen edellyttämällä:

“Tietojen käsittelyvaatimukset, mukaan lukien tallennussijainti, pääsynhallinta sekä palautus- tai tuhoamislausekkeet”

Lainaus on osiosta “Hallintavaatimukset”, politiikan lauseke 5.3.2.

Lopuksi Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy tunnistaa muutokset, joiden tulee käynnistää vaatimustenmukaisuuskatselmointi, mukaan lukien:

“Muutokset tietojen siirtomekanismeihin, alikäsittelijöihin tai rajat ylittäviin tietovirtoihin”

Tämä on osiosta “Hallintavaatimukset”, politiikan lauseke 5.3.1.1.

Näiden asiakirjojen ei tule toimia erillisinä tiedostoina. Kypsässä ISMS:ssä niistä muodostuu yksi toimintamalli: pilvi-inventaario, tietovirtojen rekisteri, toimittajarekisteri, sopimusmatriisi, riskien arviointi, siirtokatselmointi, muutoksen hyväksyntä ja auditointinäyttöpaketti.

Laadi pilvialueiden hallintarekisteri

Käytännöllinen rekisteri muuttaa pilvidatan sijainnin oletuksesta näytöksi. Aloita yhdestä kriittisestä asiakasrajapinnan palvelusta, erityisesti sellaisesta, joka todennäköisesti kuuluu NIS2:n, DORA-asiakkaan due diligence -arvioinnin tai GDPR-tarkastelun piiriin.

Kytke seuraavaksi rekisteri toteutukseen.

Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint -oppaassa Controls in Action -vaiheen vaihe 23 keskittyy organisatorisiin kontrolleihin 5.19–5.37, mukaan lukien toimittajasopimukset ja pilvipalvelujen hallinta. Blueprint varoittaa, että toimittajasopimusten on katettava muutakin kuin yleinen luottamuksellisuus:

“Monilla toimialoilla toimittajasopimukset määrittelevät myös tietojen omistajuuden ja lainkäyttöalueen. Missä dataa käsitellään? Kuka säilyttää määräysvallan? Onko siirtorajoituksia? Onko pilvikohtaisia kontrolleja, kuten tietojen segmentointia, avainten omistajuutta tai maantieteellisiä rajoituksia? Nämä elementit eivät ole vain oikeudellisia kysymyksiä, vaan operatiivisia tietoturvakysymyksiä, erityisesti säännellyillä toimialoilla.”

Sama vaihe käsittelee toimittajien muutoksenhallintaa:

“Useimmat toimittajasuhteet alkavat hyvillä aikomuksilla. Perusteellinen katselmointi, selkeät odotukset, allekirjoitetut sopimukset (ks. 5.20), ehkä jopa tietoturvan tarkistuslista. Mutta mitä tapahtuu vuotta myöhemmin, kun toimittaja ehdottaa datasi siirtämistä uudelle pilvialueelle?”

Tämä on Marian tiistaiaamun ongelma. Rekisteri antaa tietoturvajohtajalle keinon vastata ennen siirron hyväksymistä.

Zenith Blueprint selventää myös pilvikontrollin 5.23 hallinnollista merkitystä:

“Virheellisesti konfiguroitu tallennussäiliö, julkisesti näkyvä hallintanäkymä tai liialliset käyttöoikeudet pilvi-IAM-kokoonpanossa eivät ole pilven epäonnistumisia. Ne ovat hallinnan epäonnistumisia.”

Controls in Action -vaiheen vaiheessa 22 Blueprint käsittelee tiedonsiirtoa ja toteaa:

“Jos henkilötietoja siirretään rajojen yli, menetelmän on täytettävä tietosuoja- ja oikeudelliset velvoitteet, ei vain sisäisiä mieltymyksiä.”

Tällä on merkitystä pilvitiimeille. Salaus, turvalliset ohjelmointirajapinnat ja yksityinen yhteys ovat välttämättömiä, mutta ne eivät korvaa tietojen siirtojen oikeudellista ja sääntelyyn perustuvaa hallintaa.

Järjestä ensimmäinen 90 minuutin näyttötyöpaja

Älä aloita kartoittamalla koko yritystä. Aloita yhdestä kriittisestä palvelusta ja järjestä kohdennettu työpaja pilviarkkitehtuurin, hankinnan, lakitoiminnon, tietosuojan, häiriönsietokyvyn ja tietoturvaoperaatioiden kanssa.

Ensiksi listaa jokainen pilvi- tai toimittajakomponentti, joka säilyttää, käsittelee, siirtää, varmuuskopioi, valvoo tai tukee palvelua. Sisällytä myös vähäisemmät järjestelmät, kuten käytettävyysvalvonta, tikettien liitteet, virheiden seuranta, tuen näytönjakotyökalut ja diagnostiikkaviennit.

Toiseksi merkitse jokainen tietoluokka. Jos tiimi sanoo “vain metatietoa”, kyseenalaista oletus. Metatieto voi silti olla henkilötietoa tai asiakkaan luottamuksellista dataa.

Kolmanneksi todenna alue näytön perusteella. Käytä pilvikonsolin konfiguraatiota, varmuuskopiointipolitiikkoja, SIEM-asiakasympäristön asetuksia, DPA-liitteitä, alikäsittelijäluetteloita, sopimusehtoja, tukipääsyn dokumentaatiota ja CSP-auditointiraportteja. Älä luota pelkästään myynnin vakuutteluihin.

Neljänneksi kirjaa puutteet ISMS-riskirekisteriin. Esimerkkejä ovat “varmuuskopioiden replikointialuetta ei ole rajoitettu sopimusperusteisesti”, “tukipääsy kolmannesta maasta puuttuu dokumentoitu hyväksyntätyönkulku”, “SIEM-lokeja säilytetään globaalisti”, “alikäsittelijäluettelo ei tunnista palvelun sijaintialuetta” tai “DORA-rekisteri ei erottele kriittisen tai tärkeän toiminnon riippuvuutta”.

Viidenneksi päätä käsittely. Käsittelytoimia voivat olla sopimusmuutos, aluelukitus, asiakasilmoitus, salaus asiakkaan hallinnoimilla avaimilla, tokenisointi, lokien minimointi, uuden toimittajan hyväksyntä, irtautumisstrategian päivitys tai riskinomistajan tekemä jäännösriskin hyväksyntä.

Kuudenneksi säilytä näyttö. Auditoijat eivät kysy ainoastaan, mitä päätitte. He kysyvät, mistä tiedätte, että päätös toteutettiin.

Yhdistä yksi näyttökokonaisuus ISOon, GDPR:ään, NIS2:een, DORA:an ja NIST CSF 2.0:aan

Vahva pilvialueiden hallintaohjelma välttää päällekkäisen vaatimustenmukaisuustyön. Sama näyttö voi tukea useita velvoitteita, jos se on jäsennelty oikein.

NIST CSF 2.0 on hyödyllinen integroivana kerroksena. Sen GOVERN-toiminto liittyy lakisääteisiin, sääntelyyn liittyviin, sopimusperusteisiin ja tietosuojavelvoitteisiin, riskinottohalukkuuteen, osoitusvelvollisuuteen, politiikkoihin ja valvontaan. Sen GV.SC-toimitusketjukategoria vastaa hyvin DORA:n ICT-kolmansia osapuolia koskevia odotuksia, NIS2:n toimitusketjuvaatimuksia ja ISO:n toimittajakontrolleja.

COBIT 2019 ja ISACA:n auditointinäkökulma testaavat usein samoja tosiseikkoja hallintatavoitteiden kautta: omistajuus, päätösoikeudet, riskien optimointi, toimittajan suoriutuminen, hyötyjen toteutuminen ja varmennus. COBIT-tyyppinen arvioija ei välttämättä aloita kysymällä “mikä pilvialue on konfiguroitu?” Hän voi aloittaa kysymällä “kenellä on valtuus hyväksyä aluemuutokset, miten riski eskaloidaan ja mistä johto tietää, että pilvitoimittajat pysyvät riskinsietorajojen sisällä?”

Tästä syystä Clarysec-malli tallentaa omistajat, hyväksyntäpisteet, sopimusnäytön ja johdon raportoinnin, ei vain teknisiä asetuksia.

Valmistaudu auditoijan kysymyksiin

Pilvialueiden hallinta on erinomainen esimerkki siitä, miten eri auditoijat tarkastelevat samaa kontrollia eri näkökulmista.

ISO/IEC 27001:2022 -auditoija aloittaa soveltamisalasta, sidosryhmävaatimuksista, riskien arvioinnista ja soveltuvuuslausunnosta. Hän kysyy, onko lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset vaatimukset tunnistettu, sisältyvätkö pilvi- ja toimittajakontrollit mukaan, onko riskit arvioitu, onko kontrollit toteutettu ja säilytetäänkö näyttö. Hän voi ottaa otokseen yhden pilvipalvelun ja pyytää käyttöönoton katselmoinnin, sopimuslausekkeet, aluekonfiguraation, valvontakatselmoinnin ja muutoksen hyväksynnän.

Tietosuojaviranomainen tai GDPR-arvioija keskittyy henkilötietoihin. Hän kysyy, mitä henkilötietoja käsitellään, missä niitä säilytetään, mistä niihin päästään, mitkä henkilötietojen käsittelijät ja alikäsittelijät ovat mukana, onko siirtomekanismit dokumentoitu, tarvitaanko siirtovaikutusten arviointi ja ovatko asianmukaiset tekniset ja organisatoriset toimenpiteet käytössä. Lokit, tukidata ja varmuuskopiot saavat usein huomiota, koska organisaatiot aliarvioivat ne.

NIS2-auditoija tai toimivaltainen viranomainen keskittyy soveltamisalaan kuuluviin palveluihin. Tarkastelussa ovat johdon vastuu Article 20:n mukaisesti, riskienhallintatoimenpiteet Article 21:n mukaisesti, jatkuvuus, varmuuskopioinnin hallinta, katastrofipalautus, poikkeamien käsittely, toimitusketjun tietoturva, pääsynhallinta, omaisuudenhallinta ja vaikuttavuuden arviointi.

DORA-valvoja tai sisäinen tarkastus etsii ICT-riskien hallintaa, johtoelimen valvontaa, ICT-kolmansien osapuolten järjestelyjen tietorekisteriä, kriittisten tai tärkeiden toimintojen kartoitusta, keskittymäriskiä, alihankintariskiä, tietojenkäsittelyn sijainteja, auditointioikeuksia, poikkeamaraportoinnin tukea, jatkuvuustestausta ja irtautumissuunnitelmia. DORA tekee selväksi, että ulkoistaminen ei siirrä vastuuvelvollisuutta.

Zenith Controls auttaa tietoturvajohtajia valmistautumaan näihin auditointityyleihin, koska se ristiviittaa kontrollisuhteet. ISO/IEC 27002:2022:n kontrollin 5.20, tietoturvan käsittely toimittajasopimuksissa, osalta Zenith Controls kytkee sen kontrolleihin 5.19 toimittajasuhteet, 5.14 tiedonsiirto, 5.22 toimittajien seuranta, 5.11 omaisuuserien palautus ja 5.36 politiikkojen, sääntöjen ja standardien noudattaminen. Kontrollin 5.22, toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta, osalta se kytkee jatkuvan toimittajavalvonnan kontrolleihin 5.29 tietoturva häiriötilanteissa, 8.8 teknisten haavoittuvuuksien hallinta, 5.15 pääsynhallinta, 8.27 turvallisen järjestelmäarkkitehtuurin ja suunnittelun periaatteet sekä 5.36 noudattaminen.

Tällä kontrollien välisellä näkymällä on merkitystä, koska aluemuutokset eivät koskaan ole vain aluemuutoksia. Ne voivat muuttaa toimittajariskiä, siirtoriskiä, pääsyriskiä, jatkuvuusriskiä, tietoturvapoikkeamiin reagoinnin näyttöä ja sopimuksenmukaisuutta.

Käytä tätä vuoden 2026 CISO-tarkistuslistaa ennen pilvimuutoksen hyväksymistä

Käytä tätä tarkistuslistaa ennen uuden pilvialueen, rajat ylittävän käsittelyreitin, varmuuskopiointisijainnin, lokitusalustan, tukimallin tai kriittisen ICT-toimittajamuutoksen hyväksymistä.

Jos vastaus mihin tahansa kysymykseen on “oletamme”, kontrolli ei ole riittävän kypsä säänneltyyn toimintaan.

Korjaavien toimenpiteiden tiekartta

Korjauspolku on käytännöllinen, kun se ankkuroidaan ISMS:ään.

1. Varmista, että ISMS:n soveltamisalaan sisältyvät pilvipalvelut, kriittiset ICT-riippuvuudet ja säännelty tietojenkäsittely.
2. Laadi pilvialueiden hallintarekisteri priorisoiduille palveluille.
3. Kartoita jokainen palvelu tietoluokkiin, alueisiin, varmuuskopiointisijainteihin, tukipääsyyn ja alikäsittelijöihin.
4. Katselmoi toimittajasopimukset tallennussijainnin, siirtojen, auditoinnin, poikkeamien, alihankinnan, palautuksen ja tuhoamislausekkeiden osalta.
5. Päivitä riskirekisteri puutteiden, keskittymäriskien ja dokumentoimattomien siirtojen osalta.
6. Yhdenmukaista DORA:n ICT-kolmansien osapuolten rekisteri ja NIS2-palveluriippuvuuksien kartoitus soveltuvin osin.
7. Validoi tekninen toimeenpano, mukaan lukien aluelukitukset, varmuuskopiointipolitiikat, lokitusasetukset, salaus, pääsynhallinta ja avaintenhallinta.
8. Valmistele auditointinäyttöpaketti, joka sisältää kuvakaappaukset, sopimukset, riskitallenteet, hyväksynnät, katselmointipöytäkirjat ja testitulokset.
9. Määritä muutoksen käynnistin uusille alueille, alikäsittelijöille, siirtomekanismeille tai kriittisille toimittajapalvelujen muutoksille.
10. Raportoi pilvidatan sijaintiriski, poikkeukset ja jäännösriskipäätökset johdolle.

Tämä ei ole teoreettista vaatimustenmukaisuutta. Kyse on erosta sellaisen pilviympäristön välillä, joka kestää auditoinnin tarkastelun, ja sellaisen, joka nojaa suullisiin vakuutteluihin.

Liiketoimintaperuste: suvereniteetti, häiriönsietokyky ja luottamus

Johto näkee tietojen sijainnin hallinnan toisinaan pilviketteryyden rajoitteena. Käytännössä kypsä aluehallinta parantaa ketteryyttä, koska tiimit tuntevat säännöt ennen hankintaa, rakentamista tai migraatiota.

Tuotetiimi voi julkaista nopeammin, kun hyväksytyt alueet ovat selkeitä. Hankinta voi neuvotella nopeammin, kun pakolliset lausekkeet on jo määritelty. Lakitoiminto voi arvioida siirtoja nopeammin, kun tietovirrat on dokumentoitu. Tietoturvaoperaatiot voivat tutkia nopeammin, kun lokien sijainnit ja käyttöoikeudet tunnetaan. Hallitus voi tehdä riskipäätöksiä nopeammin, kun keskittymäriski, jatkuvuusvaikutus ja jäännösriskin hyväksyntä ovat näkyvissä.

Asiakkaille, erityisesti säännellyille asiakkaille, tästä tulee luottamuksen merkki. SaaS-palveluntarjoaja, joka pystyy selittämään, missä data sijaitsee, miten varmuuskopioita hallitaan, miten tukipääsyä ohjataan, miten alikäsittelijät hyväksytään ja miten aluemuutokset katselmoidaan, menestyy paremmin kuin palveluntarjoaja, joka sanoo vain “käytämme johtavaa pilvipalveluntarjoajaa”.

Vuonna 2026 tällä erolla on merkitystä. NIS2 on tuonut kyberturvallisuuden hallinnan keskeisille ja tärkeille toimijoille kaikkialla EU:ssa. DORA on tehnyt ICT-kolmansien osapuolten valvonnasta rahoitusalan muodollisen käytännön. GDPR:n osoitusvelvollisuus pysyy keskiössä. ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän, joka sitoo nämä yhteen.

Seuraavat vaiheet Clarysecin kanssa

Jos organisaatiosi ei pysty vastaamaan siihen, missä säännelty data ja kriittinen ICT-käsittely sijaitsevat tuotannon, varmuuskopioiden, lokien, tukipääsyn ja alihankkijoiden osalta, aukko on aika sulkea nyt.

Clarysec voi auttaa pilvialueiden hallintaa koskevan näyttöpaketin rakentamisessa seuraavilla työkaluilla:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint vaiheittaiseen ISO-toteutukseen ja auditointivalmiuteen.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls ISO/IEC 27002:2022:n pilvi- ja toimittajakontrollien kartoittamiseen operatiiviseen näyttöön ja eri viitekehysten odotuksiin.
• Cloud Usage Policy Cloud Usage Policy ja Cloud Usage Policy-sme Cloud Usage Policy - SME pilvidatan sijaintivaatimuksiin.
• Third party and supplier security policy Third party and supplier security policy ja Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME toimittajasopimuksiin, alihankintaan ja maantieteellisen tallennussijainnin varmentamiseen.
• Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME lokien säilytykseen ja palveluntarjoajan näyttöön.
• Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy vaatimustenmukaisuuskatselmoinnin käynnistimiin siirtomekanismien, alikäsittelijöiden ja rajat ylittävien tietovirtojen osalta.

Aloita yhdestä kriittisestä palvelusta, yhdestä pilvipalveluntarjoajasta ja yhdestä rekisteristä. Muutamassa työpajassa voit siirtyä oletuksista näyttöön ja hajanaisesta vaatimustenmukaisuudesta hallittuun pilven häiriönsietokykyyn.

Lataa Clarysec-työkalupaketti, pyydä demo tai varaa pilvialueiden hallinnan arviointi, jotta pilvidatan sijaintisitoumuksesi muuttuvat auditointivalmiiksi näytöksi.