⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

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

Igor Petreski

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:

  1. Mikä on PIMS-soveltamisala, mukaan lukien rekisterinpitäjän, henkilötietojen käsittelijän, yhteisrekisterinpitäjän ja alikäsittelijän roolit?
  2. Mitkä käsittelytoimet, tietoluokat, tarkoitukset, oikeusperusteet, vastaanottajat, siirrot ja säilytyssäännöt kuuluvat soveltamisalaan?
  3. Mitkä tietosuojariskit edellyttävät DPIA-menettelyä, riskien käsittelyä, hyväksyntää ja jäännösriskin hyväksyntää?
  4. Mitkä politiikat, kontrollit, sopimukset, tekniset suojatoimet ja tallenteet osoittavat GDPR:n mukaisen osoitusvelvollisuuden?
  5. 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äkohdeKerättävä todentava aineistoClarysec-artefakti
PIMS-soveltamisalaLiiketoimintayksiköt, järjestelmät, alueet, käsittelyroolit, poissulut, riippuvuudetREG01 PIMS-soveltamisala
KäsittelytoimetTarkoitus, oikeusperuste, tietoluokat, rekisteröidyt, säilytys, vastaanottajat, siirrotREG02 käsittelyrekisteri
Kontrollien sovellettavuusMukaan otetut kontrollit, poissuljetut kontrollit, toteutustila, perusteluREG03 PIMS-kontrollien sovellettavuus
DPIA-herätteetKorkean riskin käsittely, uudet tarkoitukset, erityiset henkilötietoryhmät, valvonta, automatisoidut päätöksetREG04 tietosuojariski ja DPIA-esiarviointi
SiirtymäsuunnitelmaVastuuhenkilöt, virstanpylväät, auditointiaikataulu, johdon katselmoinnin syötteet, korjaavat toimenpiteetREG12 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-velvoitealuePIMS-siirtymän todentava aineistoOperatiivinen omistaja
Oikeusperuste ja käyttötarkoitussidonnaisuusREG02-käsittelytallenne, jossa on tarkoitus, oikeusperuste, rooli ja katselmointipäiväTietosuojavastaava ja prosessin omistaja
Sisäänrakennettu ja oletusarvoinen tietosuojaMuutosten vastaanoton tarkistuslista, DPIA-esiarviointi, arkkitehtuurikatselmointi, hyväksyntätallenneTuoteomistaja ja tietoturva-arkkitehti
Henkilötietojen käsittelijöiden hallintaDPA, toimittajariskien arviointi, alikäsittelijäluettelo, auditointioikeudet, tietoturvaloukkauksen tukilausekeHankinta ja lakiasiat
Rekisteröidyn oikeudetPyyntöloki, identiteetin varmennustallenne, toteutusnäyttö, poikkeuspäätöksetTietosuojatoiminnot
Henkilötietojen tietoturvaloukkauksen käsittelyPoikkeamatallenne, vakavuusarviointi, ilmoituspäätös, opitPoikkeamapäällikkö ja tietosuojavastaava
Säilytys ja poistaminenSä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 -kontrolliMerkitys GDPR:n mukaisen PIMS-siirtymän kannalta
5.9 Tietojen ja muiden niihin liittyvien omaisuuserien inventaarioTunnistaa henkilötietojen tietovarastot, järjestelmät, omistajat ja tietovirrat
5.12 Tiedon luokitteluMerkitsee henkilötiedot ja erityiset henkilötietoryhmät, jotta vahvempia kontrolleja sovelletaan
5.14 TiedonsiirtoHallitsee henkilötietojen sisäisiä ja ulkoisia siirtoja
5.15 PääsynhallintaToteuttaa tarpeellisuusperiaatteeseen perustuvan pääsyn henkilötietoihin
5.16 IdentiteetinhallintaVarmistaa, että henkilötietoihin pääseviä identiteettejä hallinnoidaan ja ne ovat jäljitettävissä
5.19 Tietoturva toimittajasuhteissaTukee toimittajien tietosuojahallintaa, henkilötietojen käsittelijöiden varmentamista ja kolmansien osapuolten seurantaa
5.20 Tietoturvan huomioiminen toimittajasopimuksissaSisällyttää tietoturva- ja tietosuojavaatimukset sopimuksiin
5.21 Tietoturvan hallinta ICT-toimitusketjussaTukee 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 vaatimuksetKartoittaa GDPR-, DORA-, NIS2-, asiakas- ja sopimusvelvoitteet
5.33 Tallenteiden suojaaminenTukee todentavan aineiston säilytystä, eheyttä ja suojaamista
5.34 Henkilötietojen yksityisyys ja suojaaminenAnkkuroi tietosuojakontrollit koko henkilötietojen elinkaareen
5.35 Tietoturvan riippumaton katselmointiTukee sisäistä auditointia ja ulkoista varmentamista
5.36 Tietoturvapolitiikkojen, sääntöjen ja standardien noudattaminenTestaa, noudatetaanko tietosuojakontrolleja
5.8 Tietoturva projektinhallinnassaSisällyttää tietosuojan ja tietoturvan projektien hallinnointiin
8.10 Tietojen poistaminenTukee säilytyksen rajoittamista ja poistamissitoumuksia
8.11 Tietojen maskausSuojaa henkilötietoja ei-tuotantoympäristöissä ja analytiikkakäytössä
8.15 LokitusTuottaa todentavaa aineistoa henkilötietoihin liittyvästä pääsystä ja toiminnasta
8.16 SeurantatoiminnotHavaitsee epäilyttävää toimintaa ja tukee poikkeamatutkintaa
8.32 MuutoksenhallintaVarmistaa, 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.

ToimittajaluokkaTarvittava 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-palveluntarjoajaAluevalinta, salaus, pääsynhallinta, poikkeama-avustus, poistamista ja palauttamista koskevat ehdot
Tukityökalun toimittajaPääsyrajoitus, tukipyyntöjen peittäminen, säilytys, lokitus, tukihenkilöstön luottamuksellisuus
Analytiikka- tai tekoälytoimittajaKä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 aineistoGDPR-tarkoitusNIS2- tai DORA-tarkoitus
Poikkeaman luokittelutallenneMäärittää, tapahtuiko henkilötietojen tietoturvaloukkausMäärittää merkittävän tai vakavan TVT-poikkeaman luokituksen
Tietovaikutusten arviointiTunnistaa asianomaiset rekisteröidyt ja riskin heidän oikeuksilleen ja vapauksilleenTukee vakavuuden ja vaikutusten raportointia
AikajanalokiOsoittaa tietoon tulemisen ajankohdan, eskaloinnin, päätökset ja ilmoituksen ajoituksenTukee vaiheistettua raportointia ja viranomaisviestintää
JuurisyyanalyysiTukee korjaavia toimenpiteitä ja osoitusvelvollisuuttaTukee loppuraportointia ja häiriönsietokyvyn parantamista
OpitPäivittää DPIA:t, kontrollit, koulutuksen ja toimittajien valvonnanSyö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.

ViitekehysMitä auditoijat tai arvioijat odottavatPIMS-siirtymän vastaus
GDPROsoitusvelvollisuus, oikeusperuste, DPIA:t, henkilötietojen käsittelijöiden hallinta, tietoturvaloukkausten käsittely, oikeuksien tukiREG02, REG04, DPIA-tallenteet, DPA-rekisteri, tietoturvaloukkauspäätösten lokit, DSAR-näyttö
NIS2Riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun tietoturva, pääsynhallinta, omaisuudenhallintaISMS-riskirekisteri, toimittajatasot, poikkeamien työnkulku, käyttöoikeuskatselmoinnit, omaisuusluettelo
DORAICT-riskikehys, poikkeamaraportointi, häiriönsietokyvyn testaus, ICT-kolmansien osapuolten riski, sopimuslausekkeetICT-riippuvuusrekisteri, kriittisten toimittajien kartoitus, poikkeamaraportit, testausnäyttö, irtautumissuunnitelmat
NIST CSF 2.0Hallinnointi, lakisääteiset ja tietosuojavelvoitteet, riskiprofiilit, toimittajariski, reagointi- ja palautumistuloksetNyky- ja tavoiteprofiilit, vaatimustenmukaisuuskartoitus, toimittajien seuranta, reagoinnin ja palautumisen todentava aineisto
COBIT 2019Tietosuojaohjelman hallinnointi, vaatimustenmukaisuuden seuranta, toimittajasopimukset, operatiiviset tietosuojakontrollitHallitusraportointi, 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.

AikajanaSiirtymän tavoiteKeskeiset tuotokset
Päivät 1–15Määritä soveltamisala ja hallinnointiREG01-hyväksyntä, sponsori, roolikartta, vaatimustenmukaisuusrekisterin päivitys, REG12-siirtymäsuunnitelma
Päivät 16–35Rakenna tietosuojan näyttöperustaREG02:n siivous, tietoluokat, tarkoitukset, oikeusperusteet, säilytys, järjestelmät, toimittajat, siirrot
Päivät 36–55Suorita tietosuojariskien arviointi ja DPIA-esiarviointiREG04-esiarviointi, DPIA-herätteet, riskienkäsittelypäätökset, jäännösriskien hyväksynnät
Päivät 56–70Päivitä kontrollit, sopimukset ja suojatoimetREG03-päivitys, SoA-päivitys, DPA-korjaustoimet, pääsy, poistaminen, maskaus, lokitus, pilvikontrollit
Päivät 71–85Testaa todentava aineisto sisäisellä auditoinnillaNä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–90Pidä johdon katselmointi ja päätä valmiudestaKatselmointitoimet, 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

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

Share this article