Tietosuojariskien arviointi ISO 27701:n ja GDPR:n mukaisesti

Maanantaiaamun kokous tuntui Marialle tutulta. Hän oli nopeasti kasvavan terveysteknologiayrityksen tietoturvajohtaja.

Toimitusjohtaja halusi yksinkertaisen hallintanäkymän, joka näyttäisi GDPR-riskialtistuksen ennen kuin yritys julkaisisi tekoälyyn perustuvan potilasanalytiikka-alustansa. Uudella tietosuojavastaavalla Davidilla oli 50 välilehden seloste käsittelytoimista eli RoPA. Kehitystiimi oli suojannut pilviympäristön. Tuote oli valmis julkaistavaksi. Toimittaja kuvasi alikäsittelijäkokonaisuuttaan ”yritystason” ratkaisuksi.

Yksi kysymys kuitenkin pysäytti keskustelun.

”Mikä todellinen riskimme on, ja pystymmekö osoittamaan yritysasiakkaille, että riski on hallinnassa?”

RoPA näytti, mitä yritys käsitteli. Tietoturvariskirekisteri näytti infrastruktuuriin liittyvät riskit. Muutama DPIA oli erillisissä asiakirjoissa. Toimittajakatselmoinnit olivat hankinnan kansioissa. Kukaan ei pystynyt näyttämään yhtä jäljitettävää päätösketjua käsittelytoimesta tietosuojariskiin, DPIA-päätökseen, riskienkäsittelysuunnitelmaan, kontrollikartoitukseen, jäännösriskin hyväksyntään ja katselmointipäivään.

Tämä on aukko, jonka moni organisaatio kohtaa siirtyessään kohti ISO/IEC 27701:2025 -standardia ja GDPR:n osoitusvelvollisuutta. Organisaatioilla on tietosuojaselosteita, toimittajakyselyitä, RoPA-kirjauksia, tietovirtakarttoja, DPIA-malleja ja ISO/IEC 27001:2022 -kontrolleja. Usein niiltä puuttuu kuitenkin operatiivinen kerros, joka yhdistää nämä toisiinsa.

Kypsä tietosuojan hallintajärjestelmä eli PIMS ei käsittele tietosuojariskien arviointia oikeudellisena liiteasiakirjana. Se käsittelee sitä toistettavana päätöksenteon työnkulkuna: tunnista käsittely, esiarvioi riski, päätä tarvitaanko DPIA, valitse kontrollit, nimeä omistajat, hyväksy jäännösriski, seuraa käynnistimiä ja säilytä todentava aineisto.

Tässä Clarysecin politiikkapaketit, Zenith Blueprint ja Zenith Controls auttavat tiimejä siirtymään irrallisista laskentataulukoista puolustettavissa olevaan tietosuojariskien hallintamalliin.

Tietosuojariskien arviointi on puuttuva operatiivinen kerros

GDPR:n osoitusvelvollisuus typistyy usein ajatukseen ”dokumentaation olemassaolosta”. Dokumentaatio on tärkeää, mutta Article 5(2) menee pidemmälle. Rekisterinpitäjä vastaa Article 5(1):ssä säädettyjen periaatteiden noudattamisesta ja sen osoittamisesta. Näihin periaatteisiin kuuluvat lainmukaisuus, kohtuullisuus, läpinäkyvyys, käyttötarkoitussidonnaisuus, tietojen minimointi, täsmällisyys, säilytyksen rajoittaminen, eheys ja luottamuksellisuus.

Tämä edellyttää enemmän kuin RoPA:a. Organisaation on pystyttävä selittämään, miksi käsittelytoimi on hyväksyttävä, mitä riskejä se aiheuttaa yksilöille, mitkä kontrollit vähentävät näitä riskejä, kuka omistaa päätöksen ja milloin päätös on katselmoitava.

ISO/IEC 27701:2025 vahvistaa tätä odotusta sisällyttämällä tietosuojan hallinnan johdettuun PIMS-järjestelmään. Käytännössä tietosuojariskien arvioinnin on yhdistettävä kuusi operatiivista kohdetta:

1. Henkilötietojen käsittelytoimien luettelo tai RoPA.
2. Oikeusperustetta ja tarkoitusta koskeva dokumentaatio.
3. Tietosuojariskien esiarviointi ja DPIA-päätöksenteko.
4. Riskien käsittely ja kontrollien valinta.
5. Toimittajien, henkilötietojen käsittelijöiden ja alikäsittelijöiden hallinta.
6. ISMS:ssä ja PIMS:ssä säilytettävä todentava aineisto.

Clarysec tekee tämän yhteyden näkyväksi. Enterprise-tason Tietosuojariskien arviointi- ja DPIA-politiikassa käynnistin sijoittuu ennen käsittelyn aloittamista:

[Molemmat] Prosessin omistajan / liiketoimintavastaavan TULEE käynnistää tietosuojariskien esiarviointi REG04:ssä ennen kuin REG02:een kirjattu uusi tai olennaisesti muuttunut henkilötietojen käsittely alkaa.

Sama ennakoiva kurinalaisuus näkyy Enterprise-tason Henkilötietojen käsittelytoimien luettelo- ja oikeusperustepolitiikassa:

[Molemmat] Prosessin omistajan / liiketoimintavastaavan TULEE käynnistää tietosuojariskien ja DPIA:n esiarviointi REG04:ssä ennen kuin uusi tai olennaisesti muuttunut henkilötietojen käsittely etenee.

Tämä ehkäisee tavallisen epäonnistumismallin: tuote julkaistaan, RoPA päivitetään myöhemmin, DPIA-kysymys nousee esiin liian myöhään, eikä tietosuojaskenaario koskaan päädy riskirekisteriin.

Rekisterinpitäjille tämä tukee GDPR Article 6:n mukaista oikeusperusteen hallintaa, Article 25:n mukaista sisäänrakennettua ja oletusarvoista tietosuojaa, Article 32:n mukaista käsittelyn turvallisuutta sekä Article 5:n mukaista osoitusvelvollisuutta. Henkilötietojen käsittelijöille se tukee dokumentoituja ohjeita, asiakkaiden varmentamista, sopimusrajoja ja alikäsittelijöiden läpinäkyvyyttä.

Aloita todellisesta käsittelystä, älä tyhjästä mallipohjasta

Tietosuojariskien arviointi epäonnistuu, jos se alkaa tyhjällä lomakkeella ilman operatiivista kontekstia. Ensimmäisen kysymyksen ei tulisi olla ”Tarvitsemmeko DPIA:n?” Sen tulisi olla ”Mikä käsittely tosiasiassa muuttuu?”

SaaS-, fintech- tai terveysteknologiaorganisaatiossa muutos voi koskea esimerkiksi seuraavia:

• Uusi tietoluokka, kuten käyttäytymistä kuvaavat käyttötiedot, terveystiedot, biometriset signaalit tai maksamisen metatiedot.
• Uusi tarkoitus, kuten petospisteytys, potilasanalytiikka, tekoälyavusteinen tuki, asiakaspoistuman ennustaminen tai personointi.
• Uusi vastaanottaja, henkilötietojen käsittelijä tai alikäsittelijä.
• Uusi tukityönkulku tai rajat ylittävä pääsypolku.
• Uusi säilytysaika.
• Uusi malli, algoritmi tai automaattinen suositus.
• Uusi rekisteröityjen ryhmä, kuten alaikäiset, työntekijät, potilaat tai taloudellisesti haavoittuvassa asemassa olevat henkilöt.

GDPR:n määritelmät ovat laajoja. Henkilötiedot kattavat tunnisteet, verkkotunnisteet, sijaintitiedot ja identiteettiin liittyvät tekijät. Käsittely kattaa keräämisen, säilyttämisen, hakemisen, käytön, luovuttamisen, rajoittamisen, poistamisen ja tuhoamisen. Henkilötietojen tietoturvaloukkaus kattaa vahingossa tapahtuvan tai lainvastaisen tuhoamisen, häviämisen, muuttamisen, luvattoman luovuttamisen tai luvattoman pääsyn.

Siksi tietosuojariskien työnkulun on katettava enemmän kuin kysymys siitä, onko tietokanta salattu. Sen on kuvattava, miksi käsittely on olemassa, onko tarkoitus yhteensopiva, onko oikeusperuste pätevä, liittyykö käsittelyyn erityisiä henkilötietoryhmiä, voivatko yksilöt ymmärtää käsittelyn ja ovatko suojatoimet oikeasuhtaisia.

Pienemmille tiimeille SME-tason Tietosuoja- ja yksityisyydensuojapolitiikka tarjoaa lähtökohdan kohdassa 5.2.1:

Tietosuojakoordinaattorin tulee ylläpitää rekisteriä kaikista henkilötietojen käsittelytoimista, mukaan lukien tietoluokat, tarkoitus, oikeusperuste ja säilytysajat

Tämä rekisteri ei ole paperityötä. Se on tietosuojariskien arvioinnin syöte. Ilman tietoluokkia, tarkoitusta, oikeusperustetta ja säilytysaikoja arviointi ei voi luotettavasti arvioida käyttötarkoitussidonnaisuutta, tietojen minimointia, säilytyksen rajoittamista, läpinäkyvyyttä tai kohtuullisuutta.

Sama SME-politiikka tekee riskien katselmoinnista toistuvan velvoitteen kohdassa 7.1.1:

Tietosuojakoordinaattorin tulee arvioida tietosuojariskit vuosittain ja merkittävien järjestelmämuutosten yhteydessä

Enterprise-organisaatioissa hallinnan rytmi on tiukempi. Enterprise-tason Tietosuoja- ja yksityisyydensuojapolitiikassa todetaan:

Tietosuojariskirekistereitä tulee ylläpitää ISMS:ssä, ja tietosuojavastaavan (DPO) ja tietoturvajohtajan tulee katselmoida ne vähintään neljännesvuosittain.

Tässä ISO/IEC 27701:2025:n ja ISO/IEC 27001:2022:n integrointi muuttuu käytännölliseksi. Tietosuojariskejä ei haudata lakiasioiden kansioihin. Ne katselmoidaan yhdessä tietoturvariskien, toimittajariskien, poikkeamien, auditointihavaintojen, riskienkäsittelysuunnitelmien ja johdon raportoinnin kanssa.

Clarysecin REG02–REG04-työnkulku

Tehokkain tietosuojariskien arviointiprosessi on riittävän yksinkertainen liiketoimintavastaaville ja riittävän perusteellinen auditoijille. Clarysecin malli käyttää REG02:ta henkilötietojen käsittelytoimien luettelona ja REG04:ää tietosuojariskien arvioinnin ja DPIA:n tallenteena.

Tietosuojariskien arviointi- ja DPIA-politiikka määrittää vähimmäisnäytön, joka tarvitaan ennen REG04:n sulkemista:

[Molemmat] Tietosuojavastaavan / PIMS-päällikön TULEE ennen sulkemista varmistaa, että jokainen REG04-arviointi kirjaa riskiluokituksen, riskienkäsittelypäätöksen, omistajan, määräpäivän, jäännösriskin, hyväksynnän tilan ja katselmointipäivän.

Tämä lause muodostaa operatiivisen rungon. Tietosuojariskien arviointi ei ole valmis siksi, että joku kirjoitti kommenttikenttään ”matala riski”. Se on valmis, kun tallenne sisältää luokituksen, riskienkäsittelypäätöksen, omistajan, määräpäivän, jäännösriskin, hyväksynnän tilan ja katselmointipäivän.

SME-organisaatioissa sama kurinalaisuus skaalataan kevyemmäksi. SME-tason Riskienhallintapolitiikassa todetaan:

Jokaisen riskikirjauksen tulee sisältää kuvaus, todennäköisyys, vaikutus, pisteet, omistaja ja riskienkäsittelysuunnitelma.

Periaate on suhteellisuus, ei epämuodollisuus. Pienemmät organisaatiot voivat käyttää yksinkertaisempaa rekisteriä, mutta jokainen riski tarvitsee silti kuvauksen, pisteytyksen, omistajan ja riskienkäsittelysuunnitelman.

Hyödynnä ISO/IEC 27001:2022:n riskienhallintamoottoria tietosuojaan

Tietosuojariskiä ei tulisi käsitellä organisaation riskienhallintamenetelmän ulkopuolella. ISO/IEC 27001:2022 tarjoaa jo hallintajärjestelmän moottorin: toimintaympäristö, sidosryhmät, soveltamisala, johtajuus, riskien arviointi, riskien käsittely, operatiivinen ohjaus, dokumentoitu tieto, suorituskyvyn arviointi ja jatkuva parantaminen.

Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää sisäiset ja ulkoiset kysymykset, sidosryhmien vaatimukset, ISMS:n soveltamisalan ja ISMS-prosessit. Tietosuojassa sidosryhmiä ovat asiakkaat, rekisteröidyt, työntekijät, sääntelyviranomaiset, henkilötietojen käsittelijät, alikäsittelijät, valvontaviranomaiset, tarvittaessa finanssialan valvojat sekä sopimusasiakkaat.

Kohta 6.1.2 edellyttää tietoturvariskien arviointiprosessia. Kohta 6.1.3 edellyttää tietoturvariskien käsittelyä, mukaan lukien kontrollien valinta, soveltuvuuslausunnon laatiminen, riskienkäsittelysuunnitelman muodostaminen sekä riskinomistajan hyväksynnän hankkiminen suunnitelmalle ja jäännösriskeille. Kohdat 8.2 ja 8.3 edellyttävät tietoturvariskien arviointien ja käsittelyjen toteuttamista suunnitelluin väliajoin tai merkittävien muutosten yhteydessä sekä dokumentoitujen tulosten säilyttämistä.

Clarysecin Enterprise-tason Riskienhallintapolitiikka on yhdenmukainen tämän rakenteen kanssa kohdassa 5.1:

Muodollista riskienhallintaprosessia tulee ylläpitää ISO/IEC 27005:n ja ISO 31000:n mukaisesti kattaen riskien tunnistamisen, analysoinnin, arvioinnin, käsittelyn, seurannan ja viestinnän.

Tietosuojassa riskikriteerien on sisällettävä vaikutus yksilöihin, ei pelkästään liiketoimintavaikutus. Pieni taloudellinen menetys voi silti olla korkea tietosuojavaikutus, jos käsittely koskee erityisiä henkilötietoryhmiä, haavoittuvassa asemassa olevia henkilöitä, profilointia, läpinäkymättömyyttä, lainvastaista säilyttämistä, kyvyttömyyttä käyttää oikeuksia tai aineetonta vahinkoa.

Clarysecin Zenith Blueprint: auditoijan 30 vaiheen tiekartta selittää tämän riskienhallintavaiheen vaiheessa 10:

Vaikutuksia määritettäessä tasot kannattaa suhteuttaa omaan liiketoiminnan mittakaavaan. Esimerkiksi ”merkittävä taloudellinen vaikutus = menetys > 100 000 USD” (mukauta omaan toimintaympäristöösi). Huomioi myös sääntelyvaikutus: esimerkiksi henkilötietojen tietoturvaloukkaus voi automaattisesti olla ”merkittävä” tai ”vakava” GDPR-sakkojen ja ilmoitusvaatimusten vuoksi, vaikka suora taloudellinen menetys olisi epäselvä.

Tämä ohje on erityisen tärkeä tekoälyanalytiikassa, terveystiedoissa, taloudellisessa profiloinnissa, työntekijöiden valvonnassa ja asiakaspisteytyksessä. Haitta voi olla oikeudellinen, maineeseen liittyvä, syrjivä, operatiivinen, sopimuksellinen tai henkilökohtainen.

Käytännön esimerkki: tekoälypohjainen potilasanalytiikka

Palataan Mariaan ja Davidiin. Heidän terveysteknologia-alustansa käsittelee GDPR Article 9:n mukaisia erityisiin henkilötietoryhmiin kuuluvia terveystietoja. Se käyttää potilashistoriaa, ajanvaraustietoja, kliinikon muistiinpanoja ja mallin tuottamia tuloksia riskinäkemysten muodostamiseen.

Zenith Blueprintin avulla he aloittavat vaiheesta 9 eli omaisuuserien, uhkien ja haavoittuvuuksien tunnistamisesta:

Kirjaa jokaisesta omaisuuserästä keskeiset tiedot: nimi/kuvaus, omistaja, sijainti ja luokittelu (arkaluonteisuus). Omaisuuserä voi olla esimerkiksi ”Asiakastietokanta – IT-osaston omistama – ylläpidetään AWS:ssä – sisältää henkilötietoja ja taloudellisia tietoja (korkea arkaluonteisuus).”

Sama vaihe lisää tietosuojanäkökulman:

Varmista, että henkilötietoja sisältävät omaisuuserät merkitään (GDPR:n kannalta) ja kriittiset palveluomaisuuserät tunnistetaan (mahdollisen NIS2-soveltuvuuden vuoksi, jos toimit säännellyllä toimialalla).

Marian tiimi tunnistaa tekoälypohjaisen potilasanalytiikka-alustan, potilastietokannan, tietovaraston, mallin koulutusputken, kliinikon hallintanäkymän, pilvitallennuksen, identiteetintarjoajan, auditointilokit, tukipyyntöalustan ja kolmannen osapuolen analytiikkatyökalun. Jokaiselle omaisuuserälle määritetään omistaja, sijainti, luokittelu ja suhde henkilötietoihin.

Sen jälkeen he määrittävät riskiskenaarioita. Yksi on luvaton pääsy terveystietoihin. Toinen on analytiikkavientien kautta tapahtuva tahaton luovutus. Kolmas on vinoutuneesta koulutusdatasta johtuva tekoälymallin vinouma, joka aiheuttaa epäoikeudenmukaista tai syrjivää potilasriskien pisteytystä.

Zenith Blueprintin vaihe 11 selittää riskirekisterin roolin:

Riskirekisteri on tyypillisesti laskentataulukko (mallissamme “Risk Register and SoA Builder.xlsx” on tätä varten erillinen välilehti). Se toimii riskien pääkirjana.

Tietosuojariskin kirjaus tekoälymallin vinoumaa koskevasta skenaariosta voisi näyttää tältä:

Tämä kirjaus tekee sen, mihin vanha laskentataulukko ei pystynyt. Se yhdistää käsittelytoimen omaisuuserään, uhkaan, haavoittuvuuteen, yksilöihin kohdistuvaan riskiin, omistajaan, pisteytykseen, riskienkäsittelysuunnitelmaan ja näyttöketjuun.

Koska käsittely on korkeariskistä ja koskee erityisiä henkilötietoryhmiä, DPIA ei ole erillinen jälkikäteen tehtävä lisäys. Siitä tulee perusteellisempi arviointivaihe riskille, joka on jo kirjattu järjestelmään. Enterprise-tason Tietosuoja- ja yksityisyydensuojapolitiikassa todetaan:

Kaikki merkittävät muutokset järjestelmiin tai prosesseihin, joihin liittyy henkilötietoja (PII), edellyttävät dokumentoitua tietosuojaa koskevaa vaikutustenarviointia (DPIA), jonka tietosuojavastaava (DPO) katselmoi.

Korkean jäännösriskin rekisterinpitäjätilanteissa Tietosuojariskien arviointi- ja DPIA-politiikka lisää:

[Rekisterinpitäjä] Ylimmän johdon TULEE hyväksyä korkean tietosuojaan kohdistuvan jäännösriskin hyväksyntä REG04:ssä ennen kuin korkean riskin rekisterinpitäjäkäsittely alkaa tai jatkuu.

Julkaisupäätöksellä on nyt jäljitettävyys: mikä muuttui, mitä arvioitiin, mitä riskejä tunnistettiin, mitkä kontrollit valittiin, kuka omistaa riskien käsittelyn, kuka hyväksyi jäännösriskin ja milloin päätös katselmoidaan.

Riskeistä kontrolleihin Zenith Controlsin avulla

Tietosuojariskien arvioinnilla on merkitystä vain, jos se johtaa kontrollipäätöksiin. Clarysecin Zenith Controls: Cross-Compliance Guide on eri vaatimusten välinen opas, joka kartoittaa ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -kontrollit niihin liittyviin eri viitekehysten vaatimuksiin. Se ei ole erillinen kontrollikokonaisuus. Se auttaa tiimejä ymmärtämään, miten kontrollinäyttö tukee useita velvoitteita.

Tietosuojariskien arvioinnissa Zenith Controls nostaa esiin kolme keskeistä ISO/IEC 27002:2022 -kontrollia:

Kontrolli 5.34 tukee myös GDPR Article 25:tä ja Article 32:ta, NIS2 Article 21:n mukaisia kyberturvallisuusriskien hallintatoimenpiteitä, DORA:n ICT-riskien hallinnan odotuksia sekä NIST CSF 2.0 -tuloksia, kuten GV.OC-03:a lakisääteisiin, sääntelyyn perustuviin, sopimuksellisiin, tietosuojaa koskeviin ja kansalaisvapauksiin liittyviin velvoitteisiin sekä PR.DS-01:tä lepotilassa olevien tietojen suojaamiseen.

Zenith Blueprintin vaihe 13 yhdistää nämä päätökset soveltuvuuslausuntoon:

Tee ristiinviittaukset sääntelyyn: jos tietyt kontrollit on toteutettu nimenomaisesti GDPR:n, NIS2:n tai DORA:n noudattamiseksi, voit kirjata tämän joko riskirekisteriin (osana riskin vaikutuksen perustelua) tai SoA:n huomautuksiin.

Näin tietosuojahavainnosta tulee ISMS- ja PIMS-kontrollipäätös, ei pelkkä oikeudellinen kommentti.

Toimittaja- ja käsittelijäriski on arvioitava ennen hyväksyntää

Monet tietosuojan epäonnistumiset alkavat toimittajahallinnasta. Henkilötietojen käsittelijä lisää uuden alikäsittelijän. Tukitoimittaja saa tuotantoympäristön käyttöoikeuden. Analytiikka-alusta tallentaa tapahtumatietoja uudelle alueelle. Hankinta allekirjoittaa sopimuksen ennen kuin tietosuoja näkee riskin.

Clarysecin Enterprise-tason Henkilötietojen käsittelijöiden, alikäsittelijöiden ja kolmansien osapuolten tietosuojahallintapolitiikka ehkäisee tämän yhdistämällä toimittajakatselmoinnin, REG04:n ja kolmannen osapuolen rekisterin:

[Molemmat] Tietosuojavastaavan / PIMS-päällikön TULEE käynnistää tietosuojariskien ja DPIA:n esiarviointi REG04:ssä korkeariskisille henkilötietojen käsittelijäsuhteille ja olennaisille kolmansien osapuolten tietosuojamuutoksille ennen hyväksyntää siten, että REG04-viite kirjataan REG08:aan.

SME-organisaatioissa Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka asettaa ennen toimeksiantoa tehtävän katselmoinnin vaatimuksen:

Ennen toimeksiannon aloittamista jokainen toimittaja tulee katselmoida mahdollisten riskien osalta. Tämän katselmoinnin tulee sisältää:

Operatiivinen viesti on selvä. Toimittajariski arvioidaan ennen hyväksyntää, ei allekirjoituksen jälkeen.

Tämä tukee myös NIS2:ta ja DORA:a. NIS2 Article 21 edellyttää toimitusketjun tietoturvaa osana kyberturvallisuusriskien hallintatoimenpiteitä. DORA Articles 28–30 edellyttävät, että finanssialan toimijat hallitsevat ICT-kolmansien osapuolten riskejä, tekevät sopimusta edeltäviä arviointeja, ylläpitävät sopimuksellisia suojatoimia, ymmärtävät alihankintaan liittyvän riskin, seuraavat riippuvuuksia ja suunnittelevat irtautumisen kriittisten tai tärkeiden toimintojen osalta.

Jos toimittaja käsittelee henkilötietoja tai tukee tietosuojakriittistä käsittelyä, tietosuojariskin tallenteen tulisi näyttää toimittaja, käsittelyrooli, tietojen sijainti, alikäsittelijäriippuvuus, sopimukselliset suojatoimet, poikkeamasitoumukset, säilytyssäännöt, seurantatapa ja irtautumissuunnitelma.

Yksi työnkulku, monta vaatimustenmukaisuustulosta

Integroidun PIMS-työnkulun etu on, että sama todentava aineisto tukee useita viitekehyksiä ilman työn päällekkäisyyttä.

NIST CSF 2.0 on erityisen hyödyllinen johdon viestinnässä. Sen GOVERN-toiminto kattaa organisaation toimintaympäristön, riskienhallintastrategian, politiikan, roolit, valvonnan ja toimitusketjuriskin. Sen organisaatioprofiilit auttavat kääntämään nykyiset ja tavoitellut tulokset priorisoiduksi toimintasuunnitelmaksi, kuten riskirekisteriksi tai toimenpide- ja virstanpylvässuunnitelmaksi.

NIS2:n, DORA:n tai alakohtaisten sääntöjen piiriin kuuluvissa organisaatioissa tietosuojariskien todentava aineisto tukee myös kyberturvallisuuden hallintaa, toimittajien valvontaa, valmiutta poikkeamatilanteisiin ja häiriönsietokyvyn raportointia.

Tietosuojariskien käsittely on laajempaa kuin salaus

Salaus on tärkeää, mutta se ei korjaa pätemätöntä oikeusperustetta, liiallista keräämistä, ilmoittamatonta profilointia, epäoikeudenmukaista käsittelyä, lainvastaista säilyttämistä tai sitä, että henkilötietojen käsittelijä toimii ohjeiden vastaisesti.

SME-tason Tietosuoja- ja yksityisyydensuojapolitiikassa todetaan:

Kontrollit tulee toteuttaa tunnistettujen riskien vähentämiseksi, mukaan lukien salaus, anonymisointi, turvallinen hävittäminen ja pääsyn rajoitukset

Nämä ovat vahvoja esimerkkejä, mutta käsittelyn tulee sopia skenaarioon. Tietosuojariskien käsittelysuunnitelma voi sisältää käsittelyn tarkoituksen rajaamisen, tarpeettomien tietoluokkien poistamisen, tietojen aggregoinnin tai pseudonymisoinnin, tietosuojaselosteiden päivittämisen, oikeusperusteen muuttamisen tarvittaessa, säilytyksen rajoittamisen, pääsyn rajoittamisen, lokituksen lisäämisen, sopimusten päivittämisen, DPIA:n loppuunsaattamisen, julkaisun lykkäämisen tai sellaisen käsittelyn hylkäämisen, joka jää hyväksymättömäksi.

Enterprise-tason Riskienhallintapolitiikka vahvistaa riskinsietorajan ylittävien riskien käsittelysuunnittelua:

Kaikilla riskinsietorajan ylittäviksi luokitelluilla riskeillä tulee olla niihin liittyvä riskienkäsittelysuunnitelma, jossa määritetään:

Käytännössä tämä tarkoittaa, että korkeaa tietosuojariskiä ei voida hyväksyä hiljaisesti. Se tulee käsitellä, siirtää soveltuvin osin, välttää tai hyväksyä muodollisesti oikean vastuullisen omistajan toimesta.

Katselmoinnin käynnistimet pitävät arvioinnin elävänä

Tietosuojariskien arviointi, johon ei koskaan palata, muuttuu vanhentuneeksi näytöksi. ISO/IEC 27001:2022:n kohdat 8.2 ja 8.3 edellyttävät riskien arviointia ja käsittelyä suunnitelluin väliajoin tai merkittävien muutosten tapahtuessa. GDPR:n osoitusvelvollisuus edellyttää ajantasaisia päätöksiä. ISO/IEC 27701:2025 perustuu seurantaan ja jatkuvaan parantamiseen.

REG04-arviointi tulisi avata uudelleen, kun tarkoitus muuttuu, uusia tietoluokkia lisätään, mukaan tulee erityisiin henkilötietoryhmiin kuuluvia tietoja, oikeusperuste muuttuu, henkilötietojen käsittelijä tai alikäsittelijä vaihtuu, tallennus siirtyy uudelle alueelle, säilytysajat muuttuvat, profilointilogiikka muuttuu, tapahtuu tietoturvaloukkaus tai läheltä piti -tilanne, asiakassopimukset muuttuvat tai uusi NIS2-, DORA- tai alakohtainen velvoite tulee sovellettavaksi.

Poikkeamaprosessien tulisi palauttaa havainnot tietosuojariskien työnkulkuun. NIS2 Article 23 asettaa vaiheittaisen merkittävien poikkeamien raportoinnin. DORA Articles 17–20 edellyttävät TVT-poikkeamien kirjaamista, luokittelua, eskalointia, viestintää, juurisyyanalyysiä ja parantamista. Myös GDPR:n henkilötietojen tietoturvaloukkauksia koskevat velvoitteet voivat käynnistyä. Jos poikkeama paljastaa heikot käyttöoikeuskontrollit, liiallisen säilytyksen, epäselvän toimittajailmoittamisen tai puutteelliset asiakkaan ohjeet, REG04 on päivitettävä.

Mitä auditoijat odottavat näkevänsä

Vahvan tietosuojariskien työnkulun tulee kestää useita varmennusnäkökulmia.

Enterprise-tason Tietosuoja- ja yksityisyydensuojapolitiikka edellyttää myös sisäistä auditointitoimintaa:

Sisäinen tietosuojan vaatimustenmukaisuusauditointi tulee tehdä vuosittain tai merkittävien organisatoristen tai sääntelymuutosten yhteydessä. Auditoinnin soveltamisalan tulee sisältää:

Tämä luo johdon palautesilmukan. Ovatko REG02-tallenteet täydellisiä? Ovatko REG04-esiarvioinnit oikea-aikaisia? Tehdäänkö DPIA:t silloin, kun niitä edellytetään? Hyväksytäänkö korkeat jäännösriskit? Tallennetaanko toimittajamuutokset? Suljetaanko riskienkäsittelysuunnitelmat? Ovatko tietosuojaselosteet yhdenmukaisia todellisen käsittelyn kanssa?

Tarkistuslista seuraavaan tietosuojamuutosta koskevaan kokoukseen

Käytä tätä tarkistuslistaa ennen kuin uusi käsittelytoimi, tuoteominaisuus, toimittaja, malli tai tukityönkulku otetaan tuotantoon.

Tämä tarkistuslista ei korvaa politiikkaa. Se on käytännöllinen tapa operationalisoida politiikka tuote-, hankinta-, kehitys-, vaatimustenmukaisuus-, laki- ja johtoryhmän kokouksissa.

Muuta tietosuojan osoitusvelvollisuus toimivaksi järjestelmäksi

ISO/IEC 27701:2025 ja GDPR:n osoitusvelvollisuus edellyttävät enemmän kuin asiakirjoja. Ne edellyttävät toimivaa järjestelmää, joka yhdistää käsittelytallenteet, oikeusperusteen, tietosuojariskin, DPIA-päätökset, toimittajat, kontrollit, omistajat, hyväksynnät ja todentavan aineiston.

Aloita Zenith Blueprintin riskienhallintavaiheesta, erityisesti vaiheista 9–13. Käytä Risk Register and SoA Builderia yhdistääksesi omaisuuserät, uhat, haavoittuvuudet, tietosuojariskit, riskienkäsittelypäätökset ja kontrolliviitteet. Käytä sen jälkeen Zenith Controlsia henkilötietojen suojan, omaisuusluettelon ja toimittajaturvallisuuden kartoittamiseen GDPR:n, ISO/IEC 27001:2022:n, NIS2:n, DORA:n, NIST CSF 2.0:n ja COBIT 19:n varmennusodotuksiin.

Yhdenmukaista operatiiviset politiikat, jotka tekevät työnkulusta sovellettavan: Tietosuojariskien arviointi- ja DPIA-politiikka, Henkilötietojen käsittelytoimien luettelo- ja oikeusperustepolitiikka, Henkilötietojen käsittelijöiden, alikäsittelijöiden ja kolmansien osapuolten tietosuojahallintapolitiikka, Riskienhallintapolitiikka ja Tietosuoja- ja yksityisyydensuojapolitiikka. Pienemmät tiimit voivat käyttää myös Clarysecin SME-politiikkoja, kun taas suuremmat organisaatiot voivat rakentaa hallintaa Enterprise-politiikkojen avulla.

Jos tiimisi on käynnistämässä uutta käsittelyä, vaihtamassa toimittajia, valmistautumassa ISO/IEC 27701:2025 -standardiin tai yrittämässä tehdä GDPR:n osoitusvelvollisuuden näytöstä toistettavaa, aloita yhdestä käynnissä olevasta käsittelytoimesta. Avaa REG02, tee REG04-esiarviointi, kartoita riskit kontrolleihin, nimeä riskien käsittelyn omistajat ja katselmoi jäännösriski oikean päätöksentekijän kanssa.

Tässä yksittäisessä työnkulussa tietosuojan hallinnasta tulee operatiivista.