ISO/IEC 27701:2025 -siirtymäsuunnitelma GDPR:n mukaiseen PIMS-järjestelmään

Hallituksen kysymys, joka paljastaa tietosuojan näyttöaukon
Nopeasti kasvavan FinTech-yhtiön tietoturvajohtaja Anya katsoi hallituksen kokouksen esityslistaa. Liikevaihtoennusteiden ja markkinalaajennuksen väliin oli sijoitettu aihe, joka oli vienyt hänen viikkonsa: GDPR-vaatimustenmukaisuus ja valmius ISO/IEC 27701:2025 -standardia varten.
Yhtiöllä oli GDPR-ohjelma. Sillä oli tietosuojavastaava, tietosuojaselosteet, tietojenkäsittelysopimukset, DPIA-malli ja prosessi rekisteröityjen pyyntöjen käsittelyyn. Myynti oli jo kertonut enterprise-asiakkaille, että yhtiö oli siirtymässä kohti ISO/IEC 27701:2025 -henkilötietojen hallintajärjestelmää eli PIMS-järjestelmää. Tuoteorganisaatio valmisteli tekoälyavusteista analytiikkaominaisuutta, joka käsittelisi asiakkaiden käyttäjien käyttäytymistä, tukipyyntöjä, laskutusmetatietoja ja tilitoimintaa. Merkittävä EU-asiakas oli pyytänyt todentavaa aineistoa siitä, että rekisterinpitäjän ja henkilötietojen käsittelijän velvoitteita hallittiin erillään.
Epämiellyttävä totuus ei ollut se, että tietosuojadokumentaatio puuttui. Ongelma oli todentava aineisto.
Käsittelyrekisteri ei osoittanut johdonmukaisesti oikeusperustetta, säilytysaikaa, alikäsittelijäriippuvuuksia, kansainvälisiä siirtoja tai sitä, toimiko yhtiö kunkin käsittelytarkoituksen osalta rekisterinpitäjänä vai henkilötietojen käsittelijänä. Toimittajakatselmoinnit painottuivat tietoturvaan, mutta eivät riittävästi tietosuojaohjeisiin, poistamiseen, tietoturvaloukkausten tukeen, auditointioikeuksiin ja alikäsittelijöitä koskeviin ketjutettaviin velvoitteisiin. Kehitystiimeillä oli tietoturvakatselmointeja, mutta sisäänrakennettu tietosuoja ei aina käynnistynyt, kun ominaisuus muutti käsittelyn tarkoitusta. Sisäinen tarkastus testasi GDPR-vaatimuksia yleisellä tasolla, mutta ei aina pystynyt jäljittämään velvoitetta vastuuhenkilöön, kontrolliin, rekisteriin, testiin ja johdon katselmoinnin päätökseen.
Tämä on ISO/IEC 27701:2025 -siirtymän todellinen haaste. Kyse ei ole vain sertifikaattihankkeesta. Kyse on kypsyystestistä: pystyykö organisaatiosi toteuttamaan tietosuojaa hallittuna järjestelmänä eikä pelkkänä lakidokumenttien kansiona?
GDPR-lähtöisille organisaatioille ratkaisu on laajentaa ISO/IEC 27001:2022 -tietoturvallisuuden hallintajärjestelmä tietosuojan hallintajärjestelmäksi, joka yhdistää PIMS-soveltamisalan, käsittelytoimia koskevat selosteet, tietosuojariskien arvioinnin, DPIA-menettelyt, toimittajahallinnan, tietoturvaloukkausten käsittelyn, kontrollikartoituksen, sisäisen auditoinnin ja jatkuvan parantamisen.
Miksi hajanainen GDPR-vaatimustenmukaisuus murtuu auditointipaineessa
Monet organisaatiot käsittelevät tietosuojan vaatimustenmukaisuutta tietoturvasta erillisenä työvirtana. Lakiosasto hallinnoi sopimuksia. IT hallinnoi salausta. Hankinta hallinnoi toimittajia. Tietosuojavastaava vastaa rekisteröityjen oikeuksia koskeviin pyyntöihin. Tuotetiimit julkaisevat ominaisuuksia. Tietoturva käsittelee poikkeamia. Kukin toiminto voi tehdä hyödyllistä työtä, mutta ilman yhteistä toimintamallia tietosuojan todentava aineisto pirstaloituu.
Tästä seuraa neljä toistuvaa ongelmaa.
Ensinnäkin tiimit tekevät päällekkäistä työtä. Tietoturvan ja tietosuojan riskien arvioinnit voivat käyttää eri menetelmiä, eri pisteytystä ja eri vastuuhenkilöitä.
Toiseksi aukkoja syntyy kolmansien osapuolten palveluihin, pilvikonfiguraatioihin, analytiikkaputkiin, tukityökaluihin ja uusiin kehitysprojekteihin, koska kenelläkään ei ole kattavaa näkymää henkilötietovirtoihin.
Kolmanneksi hallituksen ja asiakkaiden varmentamisesta tulee vaikeaa. Erillisistä politiikoista koostuva kokonaisuus ei osoita, että tietosuojavelvoitteet on toteutettu, niitä seurataan ja niitä parannetaan.
Neljänneksi nykyaikaiset sääntelyodotukset lähentyvät toisiaan. GDPR edellyttää osoitusvelvollisuutta ja todentavaa aineistoa. NIS2 edellyttää hallinnointia, riskienhallintaa, poikkeamien käsittelyä, pääsynhallintaa, omaisuudenhallintaa ja toimitusketjun tietoturvaa. DORA edellyttää, että finanssialan toimijat hallitsevat ICT-riskejä, poikkeamia, häiriönsietokyvyn testausta, kolmansien osapuolten sopimuksia ja irtautumisstrategioita. Siiloutunut tietosuojaohjelma ei pysty tukemaan näitä kaikkia tehokkaasti.
Vahvempi lähestymistapa on rakentaa ISO/IEC 27701:2025 -siirtymä ISO/IEC 27001:2022 -ISMS:n varaan. ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän rakenteen organisaation toimintaympäristölle, sidosryhmille, soveltamisalalle, riskien arvioinnille, riskien käsittelylle, tavoitteille, operatiiviselle suunnittelulle, sisäiselle auditoinnille, johdon katselmoinnille, korjaaville toimenpiteille ja jatkuvalle parantamiselle. ISO/IEC 27002:2022 tarjoaa kontrolliperustan lakisääteisille velvoitteille, omaisuusluettelolle, toimittajasuhteille, pilvipalveluille, pääsynhallinnalle, lokitukselle, seurannalle, poistamiselle, maskaukselle sekä henkilötietojen yksityisyyden suojalle ja suojaamiselle.
Siirtymän tulee vastata viiteen kysymykseen:
- Mikä on PIMS-soveltamisala, mukaan lukien rekisterinpitäjän, henkilötietojen käsittelijän, yhteisrekisterinpitäjän ja alikäsittelijän roolit?
- Mitkä käsittelytoimet, tietoluokat, tarkoitukset, oikeusperusteet, vastaanottajat, siirrot ja säilytyssäännöt kuuluvat soveltamisalaan?
- Mitkä tietosuojariskit edellyttävät DPIA-menettelyä, riskien käsittelyä, hyväksyntää ja jäännösriskin hyväksyntää?
- Mitkä politiikat, kontrollit, sopimukset, tekniset suojatoimet ja tallenteet osoittavat GDPR:n mukaisen osoitusvelvollisuuden?
- Miten sisäinen auditointi ja johdon katselmointi vahvistavat, että PIMS toimii ja paranee?
Vaihe 1: hyväksy PIMS-soveltamisala ennen politiikkojen uudelleenkirjoittamista
Vahva ISO/IEC 27701:2025 -siirtymäsuunnitelma ei ala kaikkien tietosuojapolitiikkojen uudelleenkirjoittamisesta. Se alkaa hallinnoinnista ja soveltamisalasta.
Nykyinen ISMS:n soveltamisala on lähtökohta, mutta PIMS-soveltamisalan tulee yksilöidä nimenomaisesti henkilötietojen käsittely, liiketoimintayksiköt, palvelut, järjestelmät, alueet, pilviympäristöt, toimittajat ja tietosuojaroolit. Hallituksen tai ylimmän johdon tulee ymmärtää, miksi siirtymä on tärkeä, erityisesti silloin, kun asiakkaat, viranomaiset tai toimialakohtaiset velvoitteet, kuten DORA, riippuvat osoitettavissa olevasta tietosuoja- ja häiriönsietokykynäytöstä.
Clarysecin henkilötietojen hallintajärjestelmän politiikka [PIMS-politiikka] tekee soveltamisalan hyväksynnästä pakollista:
[Molemmat] Ylimmän johdon TULEE hyväksyä PIMS-soveltamisala REG01:ssä ennen PIMS:n ensimmäistä toteutusta ja 30 päivän kuluessa olennaisesta muutoksesta.
Siirtymäohjelmissa, joissa käytetään Clarysecin politiikkakirjaston lausekenumerointia, tämä on lausekkeen 4.1.1 ydinedellytys. Se on tärkeää, koska implisiittinen tietosuojan soveltamisala on yksi yleisimmistä auditointiheikkouksista. Jos tuotelinja, lainkäyttöalue, käsittelyrooli, toimittaja, pilvialue tai liiketoimintaprosessi muuttuu olennaisesti, PIMS-soveltamisalaa ei saa jättää tulkinnanvaraiseksi.
Sama politiikka muuttaa siirtymän myös hallituksi ohjelmaksi:
[Molemmat] Tietosuojavastaavan / PIMS-päällikön TULEE kirjata PIMS:n toteutussuunnitelma REG12:een ennen PIMS:n käyttöönottoa tai merkittävää PIMS-muutosta.
REG12 ei ole hallinnollista lisätyötä. Se on siirtymän ohjaava kontrollipiste. Sen tulee osoittaa, mikä muuttuu, miksi muutoksella on merkitystä, kuka vastaa siitä, mitä todentavaa aineistoa vaaditaan, mitkä riskit ovat avoinna ja milloin valmius testataan.
Vaihe 2: rakenna rekistereihin perustuva siirtymäinventaario
GDPR:n mukaisissa tietosuojan hallintajärjestelmissä ensimmäisen käytännön tuotoksen tulisi olla näyttöinventaario, ei politiikan uudelleenkirjoitus. Clarysec käyttää rekistereihin perustuvaa lähestymistapaa, koska rekisterit muuttavat tietosuojatavoitteen auditoitavaksi todentavaksi aineistoksi.
REG01:n PIMS-soveltamisala kytkeytyy REG02:n käsittelytoimiin, REG03:n kontrollien sovellettavuuteen, REG04:n tietosuojariskien arviointiin ja DPIA-esiarviointiin sekä REG12:n toteutussuunnitteluun.
Pk-yrityksen tietosuoja- ja yksityisyydensuojapolitiikka [pk-yrityksen tietosuojapolitiikka] asettaa perustason:
Tietosuojakoordinaattorin tulee ylläpitää rekisteriä kaikista henkilötietojen käsittelytoimista, mukaan lukien tietoluokat, tarkoitus, oikeusperuste ja säilytysajat.
Laajemmissa ympäristöissä tietosuoja- ja yksityisyydensuojapolitiikka [P17 tietosuoja- ja yksityisyydensuojapolitiikka] nostaa hallinnointiodotusta:
Organisaation tulee ylläpitää muodollista tietosuojan hallinnointikehystä, joka on integroitu tietoturvallisuuden hallintajärjestelmään (ISMS) tämän politiikan soveltamiseksi.
Tämä integraatio on siirtymän periaate. Käsittelyrekisteri ilman riskien käsittelyä on laskentataulukko. DPIA ilman kontrollinomistajuutta on oikeudellinen muistio. Toimittajan DPA ilman seurantaa on sopimusarkisto. ISO/IEC 27701:2025 -siirtymätyön tulee tuoda nämä artefaktit yhdeksi hallinnoiduksi PIMS-järjestelmäksi.
| Siirtymäkohde | Kerättävä todentava aineisto | Clarysec-artefakti |
|---|---|---|
| PIMS-soveltamisala | Liiketoimintayksiköt, järjestelmät, alueet, käsittelyroolit, poissulut, riippuvuudet | REG01 PIMS-soveltamisala |
| Käsittelytoimet | Tarkoitus, oikeusperuste, tietoluokat, rekisteröidyt, säilytys, vastaanottajat, siirrot | REG02 käsittelyrekisteri |
| Kontrollien sovellettavuus | Mukaan otetut kontrollit, poissuljetut kontrollit, toteutustila, perustelu | REG03 PIMS-kontrollien sovellettavuus |
| DPIA-herätteet | Korkean riskin käsittely, uudet tarkoitukset, erityiset henkilötietoryhmät, valvonta, automatisoidut päätökset | REG04 tietosuojariski ja DPIA-esiarviointi |
| Siirtymäsuunnitelma | Vastuuhenkilöt, virstanpylväät, auditointiaikataulu, johdon katselmoinnin syötteet, korjaavat toimenpiteet | REG12 PIMS-toteutussuunnitelma |
Tämä inventaario tukee myös NIST Cybersecurity Framework 2.0 -tyyppistä nykyprofiilia ja tavoiteprofiilia. Nykyprofiili dokumentoi nykyiset tietosuojaprosessit, kontrollit ja todentavan aineiston. Tavoiteprofiili määrittää halutun ISO/IEC 27701:2025 -yhteensopivan PIMS-järjestelmän. Niiden välinen ero muodostaa siirtymän työjonon.
Vaihe 3: kartoita GDPR:n mukainen osoitusvelvollisuus PIMS-järjestelmään
GDPR:n mukainen osoitusvelvollisuus on tietosuojan todentavan aineiston selkäranka. GDPR soveltuu käsittelyyn EU:ssa sijaitsevan toimipaikan yhteydessä ja voi soveltua myös EU:n ulkopuolisiin rekisterinpitäjiin tai henkilötietojen käsittelijöihin, jotka tarjoavat tavaroita tai palveluja EU:ssa oleville henkilöille tai seuraavat heidän käyttäytymistään. Se määrittelee henkilötiedot laajasti, mukaan lukien suorat ja epäsuorat tunnisteet. Se erottaa rekisterinpitäjät henkilötietojen käsittelijöistä ja määrittelee henkilötietojen tietoturvaloukkauksen tietoturvaloukkaukseksi, joka johtaa henkilötietojen tahattomaan tai lainvastaiseen tuhoamiseen, häviämiseen, muuttamiseen, luvattomaan luovuttamiseen tai niihin pääsyyn.
Siirtymäsuunnittelun kannalta keskeistä on, ettei GDPR täyty toteamalla ”meillä on tietoturvakontrollit”. Article 5 edellyttää lainmukaista, kohtuullista ja läpinäkyvää käsittelyä, käyttötarkoitussidonnaisuutta, tietojen minimointia, täsmällisyyttä, säilytyksen rajoittamista, eheyttä ja luottamuksellisuutta sekä osoitettavissa olevaa osoitusvelvollisuutta. Article 6 edellyttää oikeusperustetta. Article 9 lisää tiukemmat edellytykset erityisille henkilötietoryhmille. Article 25 edellyttää sisäänrakennettua ja oletusarvoista tietosuojaa. Article 28 edellyttää henkilötietojen käsittelijöiden hallintaa. Article 32 edellyttää käsittelyn turvallisuutta.
Clarysecin pk-yrityksen laki- ja sääntelyvaatimusten noudattamisen politiikka [pk-yrityksen laki- ja sääntelyvaatimusten noudattamisen politiikka] antaa pienemmille organisaatioille yksinkertaisen lähtökohdan:
Toimitusjohtajan tulee ylläpitää yksinkertaista, rakenteista vaatimustenmukaisuusrekisteriä, jossa luetellaan:
Enterprise-tason laki- ja sääntelyvaatimusten noudattamisen politiikka [P37 laki- ja sääntelyvaatimusten noudattamisen politiikka] on täsmällisempi:
Kaikki lakisääteiset ja sääntelyvelvoitteet tulee kartoittaa tiettyihin politiikkoihin, kontrolleihin ja omistajiin tietoturvallisuuden hallintajärjestelmässä (ISMS).
Tämä lause erottaa epämuodollisen GDPR-vaatimustenmukaisuuden auditointivalmiista tietosuojan hallinnasta. Jokainen olennainen GDPR-velvoite tulee kartoittaa politiikkaan, kontrolliin, omistajaan, rekisterikenttään ja todentavan aineiston lähteeseen.
| GDPR-velvoitealue | PIMS-siirtymän todentava aineisto | Operatiivinen omistaja |
|---|---|---|
| Oikeusperuste ja käyttötarkoitussidonnaisuus | REG02-käsittelytallenne, jossa on tarkoitus, oikeusperuste, rooli ja katselmointipäivä | Tietosuojavastaava ja prosessin omistaja |
| Sisäänrakennettu ja oletusarvoinen tietosuoja | Muutosten vastaanoton tarkistuslista, DPIA-esiarviointi, arkkitehtuurikatselmointi, hyväksyntätallenne | Tuoteomistaja ja tietoturva-arkkitehti |
| Henkilötietojen käsittelijöiden hallinta | DPA, toimittajariskien arviointi, alikäsittelijäluettelo, auditointioikeudet, tietoturvaloukkauksen tukilauseke | Hankinta ja lakiasiat |
| Rekisteröidyn oikeudet | Pyyntöloki, identiteetin varmennustallenne, toteutusnäyttö, poikkeuspäätökset | Tietosuojatoiminnot |
| Henkilötietojen tietoturvaloukkauksen käsittely | Poikkeamatallenne, vakavuusarviointi, ilmoituspäätös, opit | Poikkeamapäällikkö ja tietosuojavastaava |
| Säilytys ja poistaminen | Säilytysaikataulu, poistamista koskeva todentava aineisto, poikkeushyväksyntä | Tiedon omistaja ja IT-operaatiot |
Rekisterinpitäjän ja henkilötietojen käsittelijän todentava aineisto tulee erottaa toisistaan. Rekisterinpitäjän tulee osoittaa oikeusperuste, läpinäkyvyys, oikeuksien käsittely, tarkoituksia koskevat päätökset ja säilytys. Henkilötietojen käsittelijän tulee osoittaa käsittely dokumentoitujen ohjeiden mukaisesti, alikäsittelijöiden hallinta, rekisterinpitäjän avustaminen, turvatoimet, tuki tietoturvaloukkausilmoituksiin sekä tietojen palauttaminen tai poistaminen palvelun päättyessä. Jos organisaatio toimii molemmissa rooleissa, yksi yleinen näyttömalli ei riitä.
Vaihe 4: käytä SoA:ta tietosuojakontrollien siltana
Yleinen siirtymävirhe on luoda erillinen PIMS-kontrollitaulukko samalla, kun ISMS:n soveltuvuuslausunto jätetään koskemattomaksi. Tämä luo kaksi keskenään kilpailevaa kontrollikokonaisuutta.
ISO/IEC 27001:2022 edellyttää, että riskienkäsittelypäätökset näkyvät soveltuvuuslausunnossa. Clarysecin riskienhallintapolitiikka [riskienhallintapolitiikka] toteaa:
Soveltuvuuslausunnon (SoA) tulee kuvata kaikki riskienkäsittelypäätökset, ja se tulee päivittää aina, kun kontrollien kattavuutta muutetaan.
ISO/IEC 27701:2025 -siirtymässä SoA toimii siltana ISMS:n ja PIMS:n välillä. Jos DPIA tai tietosuojariskien käsittely lisää salauksen, tietojen maskauksen, poistokontrollit, suostumusmekanismit, henkilötietojen käsittelijöitä koskevan due diligence -arvioinnin, pääsyrajoitukset tai DSAR-työnkulun seurannan, SoA:n ja REG03:n tulee kuvata päätös.
Zenith Blueprint: auditoijan 30-vaiheinen tiekartta [Zenith Blueprint] vahvistaa tämän vaiheessa 6:
✓ Lisäkontrollit: Onko liite A:n ulkopuolisia kontrolleja, jotka voisitte sisällyttää? ISO 27001
sallii muiden kontrollien lisäämisen SoA:han. Voitte esimerkiksi sisällyttää
NIST CSF -viitekehykseen liittyvän vaatimustenmukaisuuden tai erityisiä ISO 27701 -tietosuojakontrolleja.
Älä pakota tietosuojavelvoitteita kontrolleihin, joihin ne eivät sovi. Lisää tarvittaessa tietosuojakohtaisia kontrolleja, mutta hallinnoi niitä saman riskien käsittelyn, omistajuuden, toteutustilan, todentavan aineiston ja auditointimallin kautta.
ISO/IEC 27002:2022 -kontrollit, jotka ankkuroivat siirtymän
Zenith Controls: vaatimustenmukaisuuden ristiinkartoitusopas [Zenith Controls] -oppaassa kaksi ISO/IEC 27002:2022 -kontrollia ovat keskeisiä ISO/IEC 27701:2025 -siirtymälle: 5.31 lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset sekä 5.34 henkilötietojen yksityisyys ja suojaaminen.
Kontrolli 5.31 on vaatimustenmukaisuuden keskus. Se tukee lakisääteisten, sääntelyyn perustuvien ja sopimusperusteisten vaatimusten tunnistamista, dokumentointia, omistajuutta ja katselmointia. Se kytkeytyy luontevasti GDPR:n mukaiseen osoitusvelvollisuuteen, NIS2-hallinnointiin, DORA-asetuksen ICT-riskivelvoitteisiin, asiakkaiden tietosuojalausekkeisiin ja pilvikäsittelyä koskeviin sitoumuksiin.
Kontrolli 5.34 on operatiivinen tietosuojan ankkuri. Zenith Controls selittää riippuvuuden selkeästi:
Tietovarojen omaisuusluettelon (5.9) tulisi sisältää henkilötietovarannot, kuten asiakastietokannat ja HR-tiedostot. Tämä tukee kohtaa 5.34 varmistamalla, että organisaatio tietää, mitä henkilötietoja sillä on ja missä ne sijaitsevat, mikä on ensimmäinen askel niiden suojaamisessa.
Kontrollien ristiinkartoitusta tulisi käyttää käytännön suunnittelun tarkistuslistana.
| ISO/IEC 27002:2022 -kontrolli | Merkitys GDPR:n mukaisen PIMS-siirtymän kannalta |
|---|---|
| 5.9 Tietojen ja muiden niihin liittyvien omaisuuserien inventaario | Tunnistaa henkilötietojen tietovarastot, järjestelmät, omistajat ja tietovirrat |
| 5.12 Tiedon luokittelu | Merkitsee henkilötiedot ja erityiset henkilötietoryhmät, jotta vahvempia kontrolleja sovelletaan |
| 5.14 Tiedonsiirto | Hallitsee henkilötietojen sisäisiä ja ulkoisia siirtoja |
| 5.15 Pääsynhallinta | Toteuttaa tarpeellisuusperiaatteeseen perustuvan pääsyn henkilötietoihin |
| 5.16 Identiteetinhallinta | Varmistaa, että henkilötietoihin pääseviä identiteettejä hallinnoidaan ja ne ovat jäljitettävissä |
| 5.19 Tietoturva toimittajasuhteissa | Tukee toimittajien tietosuojahallintaa, henkilötietojen käsittelijöiden varmentamista ja kolmansien osapuolten seurantaa |
| 5.20 Tietoturvan huomioiminen toimittajasopimuksissa | Sisällyttää tietoturva- ja tietosuojavaatimukset sopimuksiin |
| 5.21 Tietoturvan hallinta ICT-toimitusketjussa | Tukee alikäsittelijöiden ja ICT-riippuvuuksien hallinnointia |
| 5.23 Tietoturva pilvipalvelujen käytössä | Varmistaa, että pilvipalveluntarjoajat täyttävät tietosuojaa, sijaintia, poistamista ja sopimuksia koskevat odotukset |
| 5.31 Lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset | Kartoittaa GDPR-, DORA-, NIS2-, asiakas- ja sopimusvelvoitteet |
| 5.33 Tallenteiden suojaaminen | Tukee todentavan aineiston säilytystä, eheyttä ja suojaamista |
| 5.34 Henkilötietojen yksityisyys ja suojaaminen | Ankkuroi tietosuojakontrollit koko henkilötietojen elinkaareen |
| 5.35 Tietoturvan riippumaton katselmointi | Tukee sisäistä auditointia ja ulkoista varmentamista |
| 5.36 Tietoturvapolitiikkojen, sääntöjen ja standardien noudattaminen | Testaa, noudatetaanko tietosuojakontrolleja |
| 5.8 Tietoturva projektinhallinnassa | Sisällyttää tietosuojan ja tietoturvan projektien hallinnointiin |
| 8.10 Tietojen poistaminen | Tukee säilytyksen rajoittamista ja poistamissitoumuksia |
| 8.11 Tietojen maskaus | Suojaa henkilötietoja ei-tuotantoympäristöissä ja analytiikkakäytössä |
| 8.15 Lokitus | Tuottaa todentavaa aineistoa henkilötietoihin liittyvästä pääsystä ja toiminnasta |
| 8.16 Seurantatoiminnot | Havaitsee epäilyttävää toimintaa ja tukee poikkeamatutkintaa |
| 8.32 Muutoksenhallinta | Varmistaa, että tietosuojavaikutus arvioidaan ennen tuotantomuutoksia |
Tässä kohtaa tietosuojasta tulee operatiivista. Kysy jokaisen korkean riskin käsittelytoimen osalta: mitkä omaisuuserät sisältävät henkilötietoja, miten ne on luokiteltu, kuka voi käyttää niitä, minne niitä siirretään, mitkä pilvipalvelut käsittelevät niitä, mikä säilytyssääntö koskee niitä, mikä seuranta havaitsee väärinkäytön ja mikä todentava aineisto osoittaa, että kontrollit toimivat?
Esimerkkityönkulku: tekoälyavusteisen analytiikkaominaisuuden käyttöönotto
Palataan Anyan FinTech-yhtiöön. Tuotetiimi haluaa julkaista tekoälyavusteisen analytiikkaominaisuuden, joka käsittelee käyttäjätunnisteita, tilitoimintaa, tukimetatietoja, laskutusmetatietoja ja käyttäytymissignaaleja. Osa enterprise-asiakkaista saattaa käyttää tuloksia henkilöstön valvontaan, mikä lisää tietosuojariskiä.
PIMS-siirtymän työnkulun tulisi käsitellä julkaisu hallittuna tietosuojatapahtumana.
Vaihe 1: päivitä REG02 käsittelyrooleja ja tarkoituksia varten
Prosessin omistaja luo tai päivittää käsittelytallenteen. Pakollisia kenttiä ovat tarkoitus, tietoluokat, rekisteröityjen ryhmät, oikeusperuste tai henkilötietojen käsittelijän ohje, säilytysaika, järjestelmät, toimittajat, vastaanottajat, siirrot ja roolikonteksti.
Jos yhtiö toimii asiakkaan analytiikan henkilötietojen käsittelijänä, REG02:n tulee osoittaa käsittely asiakkaan ohjeiden mukaisesti. Jos yhtiö käyttää myös koottuja tietoja oman tuotteensa parantamiseen, tämä erillinen tarkoitus voi tehdä siitä rekisterinpitäjän toissijaista käsittelyä varten. Tallenne ei saa hämärtää rooleja.
Vaihe 2: suorita REG04-esiarviointi
Clarysecin tietosuojariskien arviointi- ja DPIA-politiikka [tietosuojariskien arviointi- ja DPIA-politiikka] edellyttää:
[Molemmat] Prosessin omistajan / liiketoimintavastaavan TULEE suorittaa perustason REG04-esiarviointi kaikille soveltamisalaan kuuluville aktiivisille REG02-käsittelytoimille 30 työpäivän kuluessa PIMS-soveltamisalan hyväksynnästä tai laajentamisesta.
Esiarvioinnin tulee tunnistaa valvonta, profilointi, erityiset henkilötietoryhmät, haavoittuvassa asemassa olevat henkilöt, uusi teknologia, laajamittainen käsittely, rajat ylittävät siirrot tai muuttunut tarkoitus. Jos kynnysarvot täyttyvät, DPIA käynnistyy.
Vaihe 3: suorita DPIA ja määritä käsittelytoimet
P17 tietosuoja- ja yksityisyydensuojapolitiikka edellyttää:
Kaikki merkittävät muutokset järjestelmiin tai prosesseihin, joissa käsitellään henkilötietoja (PII), edellyttävät dokumentoitua tietosuojaa koskevaa vaikutustenarviointia (DPIA), jonka tietosuojavastaava (DPO) katselmoi.
Clarysecin kirjastossa tämä liittyy lausekkeeseen 5.6. DPIA:n tulee arvioida riskejä, kuten liiallista keräämistä, epäselvää tarkoitusta, uudelleentunnistamista, asiakkaan ylläpitäjän luvatonta pääsyä, epäselvää säilytystä ja alikäsittelijäaltistusta. Käsittelytoimia voivat olla kenttätason minimointi, pseudonymisointi, asiakaskohtaiset konfiguraatiokontrollit, säilytyksen oletusarvot, vahvempi auditointilokitus, DPA-päivitykset, tuoteilmoitukset ja mallikoulutuksen rajoitukset.
Vaihe 4: päivitä REG03 ja SoA
PIMS-politiikka edellyttää:
[Molemmat] Tietosuojavastaavan / PIMS-päällikön TULEE ylläpitää REG03:a siten, että se sisältää mukaan otetut kontrollit, poissuljetut kontrollit, toteutustilan ja perustelun vuosittain sekä 30 päivän kuluessa jokaisesta tietosuojariskin käsittelymuutoksesta.
Jos DPIA lisää maskausta ei-tuotannolliseen analytiikkaan, lokitusta ylläpitäjän pääsylle, poistokontrolleja, toimittajalausekkeita tai asiakkaan konfiguraatiosuojatoimia, REG03 ja SoA tulee päivittää.
Vaihe 5: osoita sisäänrakennettu tietosuoja
Pk-yrityksen tietosuojapolitiikka kuvaa periaatteen selkeästi:
Sisäänrakennettu ja oletusarvoinen tietosuoja tulee toteuttaa kaikissa uusissa järjestelmissä ja palveluissa.
Todentavan aineiston tulisi sisältää DPIA, arkkitehtuurikatselmointi, tietojen minimointipäätös, pääsymalli, lokituskonfiguraatio, säilytysasetus, testitulokset, julkaisuhyväksyntä ja julkaisun jälkeinen katselmointi. Tämä muuttaa ominaisuuden julkaisun uudelleenkäytettäväksi PIMS-näytöksi.
Toimittajien tietosuojahallinta DORA- ja NIS2-ympäristössä
Toimittajien tietosuojahallinta on kohta, jossa monet siirtymät epäonnistuvat. GDPR Article 28 edellyttää, että rekisterinpitäjät käyttävät henkilötietojen käsittelijöitä, jotka antavat riittävät takeet, ja että henkilötietojen käsittelijän velvoitteet kirjataan kirjallisiin sopimuksiin. DORA Articles 28 to 30 edellyttävät, että finanssialan toimijat hallitsevat ICT-kolmansien osapuolten riskejä, ylläpitävät sopimusjärjestelyjen rekistereitä, tekevät due diligence -arviointeja, sisällyttävät auditointioikeudet ja irtautumista koskevat ehdot, hallitsevat alihankintaa ja käsittelevät kriittisiä tai tärkeitä toimintoja. NIS2 Article 21 edellyttää toimitusketjun tietoturvatoimenpiteitä, mukaan lukien toimittajien haavoittuvuuksien, kyberturvallisuuskäytäntöjen ja turvallisen kehittämisen menettelyjen huomioiminen.
ISO/IEC 27002:2022 -kontrolli 5.19, tietoturva toimittajasuhteissa, on operatiivinen ankkuri. Zenith Controls kartoittaa tämän alueen toimittajasopimuksiin, ICT-toimitusketjun tietoturvaan, tietojen siirtoon, vaatimustenmukaisuuden seurantaan, hyväksyttävään käyttöön, GDPR:n mukaisiin henkilötietojen käsittelijän velvoitteisiin, NIS2:n mukaiseen toimitusketjun kyberturvallisuuteen, DORA-asetuksen ICT-kolmansien osapuolten riskeihin, NIST-toimittajahallinnointiin ja COBIT-toimittajahallintaan.
| Toimittajaluokka | Tarvittava tietosuojan todentava aineisto |
|---|---|
| Asiakkaan henkilötietoja käsittelevä henkilötietojen käsittelijä | DPA, ohjeet, tekniset ja organisatoriset toimenpiteet, alikäsittelijäluettelo, tuki tietoturvaloukkausilmoituksiin, auditointioikeudet |
| SaaS-toimitusketjun alikäsittelijä | Ketjutettavat velvoitteet, sijainti, siirtoperuste, poistamissitoumus, muutoksista ilmoittaminen |
| Pilvipalvelujen hosting-palveluntarjoaja | Aluevalinta, salaus, pääsynhallinta, poikkeama-avustus, poistamista ja palauttamista koskevat ehdot |
| Tukityökalun toimittaja | Pääsyrajoitus, tukipyyntöjen peittäminen, säilytys, lokitus, tukihenkilöstön luottamuksellisuus |
| Analytiikka- tai tekoälytoimittaja | Käyttötarkoitussidonnaisuus, mallikoulutuksen rajoitus, pseudonymisointi, opt-out- tai konfiguraatiokontrollit |
DORA-sääntelyn piiriin kuuluvilla finanssialan toimijoilla tämän todentavan aineiston tulee kytkeytyä ICT-kolmansien osapuolten rekistereihin ja kriittisten tai tärkeiden toimintojen arviointeihin. NIS2-toimijoilla samat toimittajatallenteet tukevat toimitusketjuriskien hallintaa. NIST CSF 2.0 -viitekehyksessä toimittajahallinnointi kohdistuu GOVERN-toimintoon, erityisesti toimitusketjuriskien hallinnan lopputuloksiin. COBIT 2019 -viitekehyksessä toimittajahallinnointi kohdistuu tavoitteisiin, kuten APO10 Managed Vendors, sekä DSS-alueen toimittajiin liittyviin operatiivisiin kontrolleihin.
Poikkeama- ja tietoturvaloukkausvalmius tulee integroida
Tietosuojan siirtymäsuunnitelmat painottavat usein liikaa dokumentaatiota ja liian vähän tietoturvaloukkausten käsittelyä. Tämä on vaarallista, koska GDPR, NIS2 ja DORA edellyttävät kaikki kurinalaisia poikkeamaprosesseja, vaikka kynnysarvot ja raportointiajat eroavat toisistaan.
GDPR edellyttää arviointia siitä, aiheuttiko tietoturvatapahtuma henkilötietojen tietoturvaloukkauksen ja edellytetäänkö ilmoitusta valvontaviranomaiselle tai asianomaisille henkilöille. NIS2 määrittää merkittävien poikkeamien vaiheistetun raportoinnin, mukaan lukien ennakkovaroitus 24 tunnin kuluessa, ilmoitus 72 tunnin kuluessa ja loppuraportti yhden kuukauden kuluessa. DORA edellyttää, että finanssialan toimijat havaitsevat, hallitsevat, luokittelevat, kirjaavat, ilmoittavat, käsittelevät ja analysoivat TVT-poikkeamia sekä raportoivat merkittävistä poikkeamista vaiheistetusti.
| Poikkeaman todentava aineisto | GDPR-tarkoitus | NIS2- tai DORA-tarkoitus |
|---|---|---|
| Poikkeaman luokittelutallenne | Määrittää, tapahtuiko henkilötietojen tietoturvaloukkaus | Määrittää merkittävän tai vakavan TVT-poikkeaman luokituksen |
| Tietovaikutusten arviointi | Tunnistaa asianomaiset rekisteröidyt ja riskin heidän oikeuksilleen ja vapauksilleen | Tukee vakavuuden ja vaikutusten raportointia |
| Aikajanaloki | Osoittaa tietoon tulemisen ajankohdan, eskaloinnin, päätökset ja ilmoituksen ajoituksen | Tukee vaiheistettua raportointia ja viranomaisviestintää |
| Juurisyyanalyysi | Tukee korjaavia toimenpiteitä ja osoitusvelvollisuutta | Tukee loppuraportointia ja häiriönsietokyvyn parantamista |
| Opit | Päivittää DPIA:t, kontrollit, koulutuksen ja toimittajien valvonnan | Syöttää testausta, auditointia ja johdon katselmointia |
NIST CSF 2.0 tukee tätä sykliä Detect-, Respond-, Recover- ja Govern-lopputulosten kautta. Siirtymätiimin tulee varmistaa, että tietosuojaloukkauksia koskevat päätökset sisältyvät tietoturvapoikkeamien työnkulkuun eikä niitä käsitellä erillisenä oikeudellisena jälkitoimena.
Yksi tiekartta, monta vaatimustenmukaisuustulosta
ISO/IEC 27701:2025 -siirtymästä tulee arvokkaampi, kun se vähentää päällekkäistä vaatimustenmukaisuustyötä. Zenith Blueprint, vaihe 14, suosittelee GDPR:n, NIS2:n ja DORA:n ristiinviittaamista, jotta organisaatiot voivat osoittaa, että riskien käsittely ja kontrollit täyttävät useita velvoitteita:
Voitte tarvittaessa luoda kullekin säädökselle yksinkertaisen kartoitustaulukon, joka voi olla
raportin liitteenä ja jossa luetellaan säädöksen keskeiset tietoturvavaatimukset sekä
niitä vastaavat ISMS:n kontrollit ja politiikat.
Tietosuojan siirtymäsuunnittelussa kartoituksen tulee olla käytännönläheinen ja näyttöön perustuva.
| Viitekehys | Mitä auditoijat tai arvioijat odottavat | PIMS-siirtymän vastaus |
|---|---|---|
| GDPR | Osoitusvelvollisuus, oikeusperuste, DPIA:t, henkilötietojen käsittelijöiden hallinta, tietoturvaloukkausten käsittely, oikeuksien tuki | REG02, REG04, DPIA-tallenteet, DPA-rekisteri, tietoturvaloukkauspäätösten lokit, DSAR-näyttö |
| NIS2 | Riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun tietoturva, pääsynhallinta, omaisuudenhallinta | ISMS-riskirekisteri, toimittajatasot, poikkeamien työnkulku, käyttöoikeuskatselmoinnit, omaisuusluettelo |
| DORA | ICT-riskikehys, poikkeamaraportointi, häiriönsietokyvyn testaus, ICT-kolmansien osapuolten riski, sopimuslausekkeet | ICT-riippuvuusrekisteri, kriittisten toimittajien kartoitus, poikkeamaraportit, testausnäyttö, irtautumissuunnitelmat |
| NIST CSF 2.0 | Hallinnointi, lakisääteiset ja tietosuojavelvoitteet, riskiprofiilit, toimittajariski, reagointi- ja palautumistulokset | Nyky- ja tavoiteprofiilit, vaatimustenmukaisuuskartoitus, toimittajien seuranta, reagoinnin ja palautumisen todentava aineisto |
| COBIT 2019 | Tietosuojaohjelman hallinnointi, vaatimustenmukaisuuden seuranta, toimittajasopimukset, operatiiviset tietosuojakontrollit | Hallitusraportointi, vaatimustenmukaisuusrekisteri, APO- ja DSS-yhteensovitettu näyttö, sisäisen auditoinnin havainnot |
Zenith Controls -oppaassa ISO/IEC 27002:2022 -kontrolli 5.31 tukee lakisääteistä ja sääntelyyn liittyvää jäljitettävyyttä GDPR:n mukaisen osoitusvelvollisuuden, DORA-asetuksen vaatimustenmukaisuusvelvoitteiden, NIS2:n hallinnointiodotusten, NIST CSF 2.0 GV.OC-03:n ja COBITin ulkoisen vaatimustenmukaisuuden seurannan välillä. Kontrolli 5.34 tukee GDPR Articles 25 and 32 -vaatimuksia, henkilötietojen elinkaaren suojausta, pilvessä tapahtuvan henkilötietojen käsittelyn odotuksia ja tietosuojatietoisia tietoturvakontrolleja.
Tuloksena ei ole yksinkertaistettu ”yksi kontrolli vastaa yhtä lakia” -malli. Kyse on puolustettavasta näyttömallista, jossa yksi hyvin suunniteltu kontrollikokonaisuus tukee useita varmentamistarpeita.
Miten auditoijat testaavat siirtymän
Vahva siirtymäsuunnitelma ennakoi auditointitekniikat.
ISO-hallintajärjestelmän auditoija aloittaa soveltamisalasta, sidosryhmistä, lakisääteisistä vaatimuksista, riskeistä, tavoitteista, operatiivisista kontrolleista, sisäisistä auditoinneista, johdon katselmoinneista, poikkeamista ja parantamisesta. Hän varmistaa, onko PIMS-soveltamisala hyväksytty, sisältyvätkö tietosuojavelvoitteet vaatimustenmukaisuusrekisteriin, onko kontrollit perusteltu SoA:ssa ja vastaako toteutuksen todentava aineisto ilmoitettua soveltamisalaa.
Tietosuojan auditoija ottaa näytteitä käsittelytallenteista, DPIA-menettelyistä, DSAR-pyynnöistä, tietoturvaloukkauspäätöksistä, henkilötietojen käsittelijöiden sopimuksista, säilytyskontrolleista ja projektien käyttöönotoista. Hän ei hyväksy politiikkatavoitetta, jos operatiivinen todentava aineisto puuttuu.
NIST-yhteensopiva arvioija etsii hallinnointia, lakisääteisiä ja sopimusperusteisia velvoitteita, tavoiteprofiileja, toimittajariskejä, seurantaa sekä reagoinnin ja palautumisen todentavaa aineistoa.
COBIT 2019 -auditoija keskittyy hallituksen valvontaan, vaatimustenmukaisuusraportointiin, toimittajahallintaan, rooleihin ja vastuisiin sekä siihen, hallitaanko tietosuojariskiä koko tiedon elinkaaren ajan.
Clarysecin PIMS-seuranta-, auditointi- ja parantamispolitiikka [PIMS-seuranta-, auditointi- ja parantamispolitiikka] tekee auditointiohjelmasta pakollisen:
[Kaikki] Sisäisen tarkastuksen / vaatimustenmukaisuuden katselmoijan TULEE laatia riskiperusteinen PIMS:n sisäinen auditointiohjelma REG12:een vuosittain ennen ensimmäistä suunniteltua PIMS-auditointisykliä.
Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka [auditointi- ja vaatimustenmukaisuuden seurantapolitiikka] soveltaa samaa kurinalaisuutta ISMS-tasolla:
Riskiperusteinen auditointisuunnitelma tulee laatia ja hyväksyä vuosittain ottaen huomioon:
Pienemmille organisaatioille pk-yrityksen auditointi- ja vaatimustenmukaisuuden seurantapolitiikka [pk-yrityksen auditointi- ja vaatimustenmukaisuuden seurantapolitiikka] pitää auditointisuunnittelun fokusoituna:
Suunnitelmassa tulee yksilöidä katselmoitavat keskeiset järjestelmät ja politiikat painottaen:
Siirtymän aikana ensimmäisen sisäisen auditoinnin ei tulisi testata kaikkea. Sen tulisi testata suurimmat siirtymäriskit: puutteelliset käsittelytallenteet, puuttuvat DPIA-herätteet, heikot toimittajien tietosuojalausekkeet, testaamattomat tietoturvaloukkauspäätökset, epäselvät rekisterinpitäjän ja henkilötietojen käsittelijän roolit sekä SoA:n ja toteutuksen ristiriita.
Käytännön 90 päivän ISO/IEC 27701:2025 -siirtymän tiekartta
Realistisen tiekartan tulee olla riittävän lyhyt toteutettavaksi ja riittävän rakenteinen todentavan aineiston tuottamiseksi.
| Aikajana | Siirtymän tavoite | Keskeiset tuotokset |
|---|---|---|
| Päivät 1–15 | Määritä soveltamisala ja hallinnointi | REG01-hyväksyntä, sponsori, roolikartta, vaatimustenmukaisuusrekisterin päivitys, REG12-siirtymäsuunnitelma |
| Päivät 16–35 | Rakenna tietosuojan näyttöperusta | REG02:n siivous, tietoluokat, tarkoitukset, oikeusperusteet, säilytys, järjestelmät, toimittajat, siirrot |
| Päivät 36–55 | Suorita tietosuojariskien arviointi ja DPIA-esiarviointi | REG04-esiarviointi, DPIA-herätteet, riskienkäsittelypäätökset, jäännösriskien hyväksynnät |
| Päivät 56–70 | Päivitä kontrollit, sopimukset ja suojatoimet | REG03-päivitys, SoA-päivitys, DPA-korjaustoimet, pääsy, poistaminen, maskaus, lokitus, pilvikontrollit |
| Päivät 71–85 | Testaa todentava aineisto sisäisellä auditoinnilla | Näytepohjainen auditointi yhdestä rekisterinpitäjän prosessista, yhdestä henkilötietojen käsittelijän palvelusta, yhdestä toimittajasta, yhdestä DPIA:sta, yhdestä DSAR-pyynnöstä ja yhdestä tietoturvaloukkausskenaariosta |
| Päivät 86–90 | Pidä johdon katselmointi ja päätä valmiudesta | Katselmointitoimet, toimittajaongelmat, poikkeamat, auditointihavainnot, tietosuojatavoitteet, päätös ulkoisesta arvioinnista |
90 päivän tavoite ei tarkoita, että jokainen korjaava toimenpide suljetaan. Se tarkoittaa, että johdolla tulisi olla hyväksytty soveltamisala, uskottava näyttöperusta, priorisoitu riskien käsittely, kohdennetut auditointitulokset ja johdon päätös valmiudesta.
Tee siirtymästä näyttöön perustuva
ISO/IEC 27701:2025 -siirtymässä onnistuvat organisaatiot eivät ole niitä, joilla on pisin tietosuojapolitiikka. Ne ovat niitä, jotka pystyvät osoittamaan, miten tietosuojavelvoitteet siirtyvät lainsäädännöstä soveltamisalaan, soveltamisalasta käsittelytallenteisiin, käsittelytallenteista riskien arviointiin, riskien arvioinnista kontrolleihin, kontrolleista todentavaan aineistoon ja todentavasta aineistosta parantamiseen.
Clarysec auttaa tiimejä tekemään siirtymästä käytännönläheisen. PIMS-politiikkakokonaisuutemme, GDPR-kartoitukset, rekisterinpitäjän ja henkilötietojen käsittelijän näyttörekisterit, DPIA-työnkulut, toimittajien tietosuojahallinnan mallit, tietoturvaloukkausten käsittelymateriaalit, johdon katselmointien agendat, Zenith Blueprint ja Zenith Controls antavat tietoturvajohtajille, tietosuojavastaaville, vaatimustenmukaisuuspäälliköille, auditoijille ja liiketoimintavastaaville rakenteisen polun tietosuojatavoitteesta auditointivalmiiseen toimintaan.
Jos organisaatiosi valmistautuu ISO/IEC 27701:2025 -standardia varten, aloita tällä viikolla kolmella toimenpiteellä: hyväksy PIMS-siirtymän soveltamisala REG01:ssä, täytä REG02 korkeariskisimmälle palvelullesi ja suorita ensimmäinen REG04-esiarviointi. Käytä sen jälkeen Clarysecia muuttaaksesi tämän näyttökokonaisuuden täydelliseksi GDPR-yhteensopivaksi PIMS-siirtymän tiekartaksi, joka on valmis asiakkaille, auditoijille, viranomaisille ja hallitukselle.
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