PII:n hallinta ISO 27701:2025:n ja GDPR:n mukaisesti

Pyyntö saapui tietoturvajohtajan postilaatikkoon petollisen yksinkertaisena: “Project Wellness.” Nopeasti kasvava fintech-yritys halusi analysoida olemassa olevia asiakkaiden maksutapahtumatietoja tarjotakseen yksilöllisiä säästövinkkejä, tuotesuosituksia ja näkymiä asiakaspoistuman riskiin. Markkinointi näki asiakassitoutumista. Tuoteorganisaatio näki innovaatiota. Johto näki kilpailuetua.

Tietoturvajohtaja näki hallinnan ansan.

Maksutapahtumatiedot oli kerätty maksujen käsittelyä varten määritellyn käyttötarkoituksen ja oikeusperusteen nojalla. Nyt liiketoiminta halusi käyttää niitä uudelleen taloudellisen hyvinvoinnin analytiikkaan, kampanjoiden personointiin ja ennakoivaan pisteytykseen. Toimituksen nopeuttamiseksi tiimi halusi myös lähettää pseudonymisoidun tietoaineiston kolmannen osapuolen tekoälyanalytiikan toimittajalle.

Verkossa ei ollut hyökkääjää. Tietokanta ei ollut vuotanut. Yksikään poikkeamatiketti ei ollut punaisena.

Silti juuri tästä monet GDPR:n osoitusvelvollisuuden epäonnistumiset alkavat.

Ongelma ei ole se, onko organisaatiolla tietosuojaseloste, tietosuojavastaava, käsittelyn oikeusperusteiden rekisteri tai säilytysaikataulu. Syvempi kysymys on operatiivinen: kuka hyväksyy uuden PII:n keräämisen, kuka vahvistaa tarpeellisuuden, kuka määrittää sallitun sisäisen käytön, kuka päättää toissijaisen käytön yhteensopivuudesta, kuka valtuuttaa luovutuksen toimittajalle ja kuka pystyy myöhemmin todentamaan päätöksen?

Tämä on kontrolliaukko, joka ISO/IEC 27701:2025 -standardin mukaisissa henkilötietojen hallintajärjestelmän eli PIMS:n toteutuksissa on suljettava. GDPR Article 5 edellyttää, että henkilötietoja käsitellään lainmukaisesti, kohtuullisesti ja läpinäkyvästi, että ne kerätään nimenomaisia, yksilöityjä ja laillisia tarkoituksia varten, rajataan tarpeelliseen, pidetään täsmällisinä, säilytetään vain tarvittavan ajan, suojataan asianmukaisesti ja käsitellään rekisterinpitäjän osoitusvelvollisuuden mukaisesti. GDPR Article 6 lisää jatkokäsittelyn oikeusperustetta ja yhteensopivuutta koskevan logiikan. Nämä periaatteet ovat kuitenkin puolustettavissa vasta, kun ne muutetaan työnkuluiksi, rekistereiksi, hyväksynnöiksi, pääsysäännöiksi, toimittajakontrolleiksi, seurannaksi ja todentavaksi aineistoksi.

Clarysecin lähestymistapa on yksinkertainen: PII:n keräämisen, käytön ja luovuttamisen hallintaa on käsiteltävä hallittuna toimintamallina, ei oikeudellisena muistiona. Malli sijoittuu ISO/IEC 27001:2022 -standardin ISMS-rungon sisään, laajenee ISO/IEC 27701:2025 -standardin PIMS-rooleihin ja todennetaan Clarysecin politiikoilla, rekistereillä, Zenith Blueprint: auditointivalmis 30 vaiheen tiekartta -aineistolla ja Zenith Controls: ristiinvaatimustenmukaisuuden opas -oppaalla.

Miksi PII:n hallinta epäonnistuu, vaikka tietosuoja-asiakirjat ovat olemassa

Useimmat tietosuojaohjelmat eivät epäonnistu siksi, ettei kukaan tietäisi GDPR:n olemassaolosta. Ne epäonnistuvat siksi, että tietosuojapäätöksiä tehdään tuotetukipyynnöissä, toimittajien käyttöönottoa koskevissa sähköposteissa, taulukkolaskentavienneissä, mittaristokokeiluissa ja tekoälypiloteissa ilman toistettavaa kontrolliporttia.

Tyypillinen malli on tuttu:

1. Tiimi lisää rekisteröitymislomakkeelle uuden kentän, koska se parantaa segmentointia.
2. Kukaan ei kirjaa, miksi juuri kyseinen kenttä on tarpeellinen.
3. Toinen tiimi käyttää myöhemmin tietoja uudelleen eri tarkoitukseen.
4. Toimittaja saa viennin laajan palvelusopimuksen perusteella.
5. Käsittelyrekisteri päivitetään julkaisun jälkeen, jos sitä päivitetään lainkaan.
6. Auditoinnissa organisaatio voi esittää tietosuojaselosteen, mutta ei päätöksentekoa koskevaa todentavaa aineistoa.

GDPR Articles 4 ja 5 määrittelevät käsittelyn laajasti. Kerääminen, tallentaminen, säilyttäminen, käyttö, luovuttaminen, poistaminen ja tuhoaminen kuuluvat kaikki käsittelyyn. Article 5 tekee myös osoitusvelvollisuudesta nimenomaisen. Rekisterinpitäjien on pystyttävä osoittamaan periaatteiden noudattaminen.

Siksi auditointikysymys ei ole vain “Onko teillä politiikka?” vaan “Näyttäkää, miten tämä yksittäinen tietoelementti hyväksyttiin, miksi sitä tarvittiin, miten sitä käytettiin, kuka sen sai ja mitkä kontrollit estivät väärinkäytön.”

Clarysecin P17 Tietosuoja- ja yksityisyydensuojapolitiikka määrittää elinkaarta koskevan odotuksen selkeästi:

Se virallistaa organisaation vastuut kansainvälisten standardien ja sääntelyviitekehysten mukaisesti ja varmistaa, että henkilötietoja (PII) kerätään, käsitellään, säilytetään, jaetaan ja hävitetään lainmukaisesti, turvallisesti ja läpinäkyvästi.

Pk-yrityksille Clarysecin Tietosuoja- ja yksityisyydensuojapolitiikka - SME muuttaa saman periaatteen käytännön toimintasäännöksi:

Henkilötietoja saa kerätä vain silloin, kun se on tarpeen hyväksyttävää, lainmukaista tai sopimusperusteista tarkoitusta varten.

Minimoinnin osalta:

Vain tarpeellisten henkilötietojen vähimmäismäärä saa olla kerättävänä ja säilytettävänä.

Nämä linjaukset ovat vaikuttavia vain, jos niitä sovelletaan ennen käsittelyn aloittamista. Muussa tapauksessa ne jäävät tietosuojakieleksi ilman operatiivista näyttöä.

Kontrollitavoite: pysäytä hallitsematon käsittely kolmessa portissa

Vahvan PIMS:n on hallittava PII:tä koskevia päätöksiä kolmessa kohdassa: ennen keräämistä, ennen käyttöä ja ennen luovuttamista.

Ennen keräämistä organisaation on tiedettävä, mitä se haluaa kerätä, keneltä, minkä kanavan kautta, mihin tarkoitukseen, millä oikeusperusteella ja miksi kukin kenttä on tarpeellinen.

Ennen käyttöä organisaation on määritettävä sallitun sisäisen käytön säännöt. Tuki, asiakasmenestys, markkinointi, petostentorjunta, talous ja kehitys eivät yleensä tarvitse samaa näkyvyyttä tai samoja oikeuksia käsitellä PII:tä.

Ennen luovuttamista organisaation on tiedettävä, kuka vastaanottaja on, mikä rooli vastaanottajalla on, miksi luovutus on tarpeen, missä käsittely tapahtuu, mitä PII-luokkia jaetaan, kuinka usein jakamista tapahtuu ja mikä valtuutus sallii jakamisen.

Clarysecin PII09 PII:n keräämistä, käyttöä, luovuttamista ja jakamista koskeva politiikka on suunniteltu tätä hallintakerrosta varten. Se käyttää PIMS-roolimerkintöjä, erityisesti rekisterinpitäjäroolia, koska keräämistä, käyttöä ja luovuttamista koskevat päätökset ovat yleensä organisaatiolla, joka määrittää käsittelyn tarkoitukset ja keinot.

Keräämisen rajoittamisen osalta PII09 PII:n keräämistä, käyttöä, luovuttamista ja jakamista koskeva politiikka edellyttää:

[Rekisterinpitäjä] Prosessin omistajan / liiketoimintavastaavan on kirjattava keräämisen tarkoitus, lähde tai kanava, PII-luokat, rekisteröityjen luokat ja vähimmäistietoelementit REG02:een ennen uuden keruutoimen tai olennaisen keruumuutoksen aloittamista.

Sen jälkeen se tekee minimoinnista testattavaa:

[Rekisterinpitäjä] Prosessin omistajan / liiketoimintavastaavan on kirjattava REG02:een tarpeellisuusperustelu jokaiselle PII-tietoelementille ennen kyseisen elementin keräämistä.

Vaatimus “jokaiselle PII-tietoelementille” erottaa yleisluonteisen käsittelytoimien luettelon kenttätason osoitusvelvollisuudesta.

Sisäisen käytön osalta sama politiikka edellyttää:

[Rekisterinpitäjä] Prosessin omistajan / liiketoimintavastaavan on kirjattava hyväksytyt sisäisen käytön säännöt REG02:een kullekin käsittelytoimelle ennen käytön aloittamista.

Toissijaisen käytön osalta:

[Rekisterinpitäjä] Prosessin omistajan / liiketoimintavastaavan on kirjattava REG02:een toissijaisen käytön yhteensopivuustarkistus ennen kuin PII:tä käytetään tarkoitukseen, jota ei ole jo hyväksytty kyseiselle käsittelytoimelle.

Ja ulkoisen luovuttamisen osalta:

[Rekisterinpitäjä] Toimittajasta tai hankinnasta vastaavan omistajan on kirjattava vastaanottajan identiteetti, vastaanottajan rooli, luovutuksen tarkoitus, PII-luokat, jakamistiheys, käsittelyn sijainti ja valtuutuslähde REG08:aan ennen toistuvan ulkoisen jakamisen aloittamista.

Nämä lausekkeet antavat selkeän vastauksen, kun johto kysyy, voiko liiketoiminta innovoida nopeasti: kyllä, jos päätös läpäisee dokumentoidun hallintatyönkulun ja kontrollit vastaavat hyväksyntää.

REG02 ja REG08: ketju politiikasta kontrolliksi

Clarysec-toteutuksissa REG02 ei ole passiivinen käsittelytoimien luettelo. Se on päätöksentekotallenne keräämisen tarkoitukselle, oikeusperusteelle, PII-luokille, tarpeellisuudelle, sisäisen käytön säännöille, säilytyksen yhdenmukaisuudelle ja toissijaisen käytön yhteensopivuudelle.

REG08 on luovutusten ja jakamisen kontrollirekisteri. Se on erityisen tärkeä toimittajille, kumppaneille, konserniyhtiöille, viranomaisille, alikäsittelijöille, integraatioille ja toistuville vienneille.

Yhdessä ne muodostavat politiikasta kontrolliksi etenevän ketjun, jota tietosuoja-, tietoturva-, hankinta- ja auditointitiimit voivat testata.

Tämä malli on luontevasti linjassa ISO/IEC 27001:2022 -standardin kanssa. Lausekkeet 4–10 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmien vaatimukset, soveltamisalan, johdon vastuut, riskien arvioinnin, riskien käsittelyn, operatiivisen ohjauksen, suorituskyvyn arvioinnin ja parantamisen. GDPR:n ja ISO/IEC 27701:2025:n mukaisista tietosuojavelvoitteista tulee osa hallintajärjestelmää erillisen tietosuojasaarekkeen sijaan.

Myös ISO/IEC 27002:2022 tukee toimintamallia. Control 5.31, lakisääteiset, viranomais- ja sopimusperusteiset vaatimukset, kiinnittää GDPR:n ja alakohtaiset velvoitteet. Control 5.34, yksityisyydensuoja ja PII:n suojaus, käsittelee tietosuojakohtaista suojausta. Control 5.9, tietojen ja muiden niihin liittyvien omaisuuserien luettelo, tukee tiedon tuntemista. Controls 5.12 ja 5.13 tukevat luokittelua ja merkintöjä. Control 5.14 ohjaa tiedon siirtoa. Controls 5.19–5.23 kattavat toimittajasuhteet, toimittajasopimukset, ICT-toimitusketjun, toimittajapalvelujen seurannan ja pilvipalvelut. Control 8.11 tukee tietojen maskausta, 8.12 tiedonvuodon estoa, 8.15 lokitusta, 8.16 valvontatoimintoja ja 8.24 kryptografian käyttöä.

Zenith Blueprint sijoittaa nämä kontrollit toteutuspolkuun. Kontrollit käytännössä -vaiheessa vaihe 23 kattaa organisatoriset kontrollit 5.19–5.37, mukaan lukien control 5.34 yksityisyydensuoja ja PII:n suojaus. Blueprint selittää:

Nykypäivän datavetoisessa maailmassa henkilöön yhdistettävissä oleva tieto ei ole vain yksi tietotyyppi muiden joukossa, vaan erittäin arkaluonteinen luottamuksen ilmentymä. Nimet, osoitteet, tunnisteet, terveystiedot ja taloudelliset tiedot kertovat todellisten ihmisten tarinaa.

Sen jälkeen se antaa operatiivisen perustason:

Tämän kontrollin perusta on tiedon tunteminen. Organisaation on tiedettävä, mitä PII:tä se kerää, missä se sijaitsee, miksi sitä käsitellään ja kuka voi käyttää sitä.

Tämän REG02 ja REG08 tarjoavat, kun niitä käsitellään elävinä hallintatallenteina.

Käytännön esimerkki: Project Wellnessin hyväksyminen hallinnan säilyttäen

Palataan fintech-skenaarioon. Liiketoiminta haluaa analysoida asiakkaiden maksutapahtumatietoja yksilöllisiä taloudellisen hyvinvoinnin suosituksia varten. Markkinointi haluaa käyttää tuotoksia kampanjoissa. Tuoteorganisaatio haluaa rakentaa asiakaspoistuma- ja sitoutumispisteytyksiä. Kolmannen osapuolen tekoälyanalytiikka-alusta käsittelee osan tietoaineistosta.

Näin Clarysec hallitsisi pyynnön.

Vaihe 1: Luo tai päivitä REG02-käsittelytoimi

Prosessin omistaja avaa REG02:n ja kirjaa käsittelytoimen ennen työn aloittamista.

Keskeistä on ajoitus. REG02 päivitetään ennen uuden käsittelyn aloittamista, ei vasta sen jälkeen, kun ominaisuus on jo tuotannossa.

Vaihe 2: Kirjaa kenttäkohtaiset tarpeellisuusperustelut

Markkinointi pyytää aluksi viiden vuoden täydellistä maksutapahtumahistoriaa, mukaan lukien kauppiaiden nimet, tarkat aikaleimat, korttien metatiedot ja asiakkaan profiiliattribuutit. Hallintatiimi haastaa jokaisen kentän.

Tämä on tietojen minimointia näyttönä, ei pelkkänä tavoitteena. Liiketoiminta saa edelleen hyödyllistä analytiikkaa, mutta tietoaineisto rajataan hyväksyttyä tarkoitusta varten tarpeelliseen.

Vaihe 3: Luokittele ja merkitse tietoaineisto

Tietoaineisto luokitellaan Clarysecin Tiedon luokittelu- ja merkintäpolitiikan mukaisesti. SME-versio edellyttää:

Ulkoinen jakaminen on nimenomaisesti valtuutettava ja kirjattava lokiin.

Yritystason Tiedon luokittelu- ja merkintäpolitiikka lisää arkaluonteisille tiedoille suojatoimen:

Tietoja saa jakaa ulkoisesti vain NDA:n tai vastaavien sopimusperusteisten suojatoimien nojalla.

Käytännössä Project Wellness -tietoaineistoa ei voi viedä tekoälyalustalle satunnaisesti. Se tarvitsee hyväksytyn luovutustallenteen, sopimusperusteiset suojatoimet, tekniset siirtokontrollit ja lokit.

Zenith Blueprint selittää vaiheessa 22, control 5.12 tiedon luokittelu, miksi tämä on tärkeää:

Jokainen koskaan kirjoitettu tietoturvakontrolli — pääsyn rajoittaminen, salaus, varmuuskopiointi, seuranta tai hävittäminen — olettaa yhden asian: organisaatio tietää, mitä se suojaa.

Ilman luokittelua pääsyrajoituksista, salauksesta, DLP:stä ja säilytyssäännöistä tulee arvailua.

Vaihe 4: Määritä sisäisen käytön säännöt ennen tuotantojulkaisua

Prosessin omistaja kirjaa hyväksytyt sisäisen käytön säännöt REG02:een. Tässä käyttötarkoituksen laajeneminen usein pysäytetään.

Puolustettavissa oleva sääntökokonaisuus voisi todeta:

• Tuoteorganisaatio saa käyttää koottuja suositusten suorituskykymittareita.
• Asiakastuki saa nähdä tukipyynnön käsittelyn yhteydessä, onko suositus näytetty asiakkaalle.
• Markkinointi ei saa käyttää yksilötason hyvinvointipisteitä kampanjoiden segmentointiin, ellei toissijaisen käytön yhteensopivuustarkistusta ole tehty.
• Talous ei saa käyttää yksityiskohtaista hyvinvointianalytiikkaa, ellei erillistä hyväksyttyä tarkoitusta ole olemassa.
• Kehittäjät eivät saa käyttää tuotanto-PII:tä testiympäristöissä.
• Tekoälymallin arvioinnissa on käytettävä maskattuja, pseudonymisoituja tai koottuja tietoaineistoja silloin, kun se on mahdollista.

Kaksi viimeistä sääntöä liittyvät ISO/IEC 27002:2022 -standardin control 8.11 tietojen maskaus -kontrolliin. Zenith Blueprint, vaihe 19, kuvaa tietojen maskauksen käytännön menetelmänä tarpeettoman altistumisen estämiseksi testiympäristöissä, koulutustietoaineistoissa, analytiikka-alustoilla, kolmannen osapuolen integraatioissa ja CI/CD-testiputkissa.

Vaihe 5: Suorita toissijaisen käytön yhteensopivuustarkistus

Markkinointi pyytää myöhemmin saada käyttää hyvinvointipisteitä kohdennettuihin kampanjoihin. Se on uusi tarkoitus. PII09 PII:n keräämistä, käyttöä, luovuttamista ja jakamista koskevan politiikan lausekkeen 4.3.1 mukaan liiketoimintavastaavan on kirjattava yhteensopivuustarkistus REG02:een ennen uuden käytön aloittamista.

Tarkistuksessa on arvioitava:

• Onko taloudellisen hyvinvoinnin markkinointi yhteensopivaa alkuperäisen käsittelytarkoituksen kanssa.
• Mitä asiakkaille kerrottiin keruun yhteydessä ja tietosuojaselosteessa.
• Voivatko maksutapahtumista johdetut päätelmät olla arkaluonteisia tai odottamattomia.
• Voiko uusi käyttö aiheuttaa painostusta, poissulkemista tai epäoikeudenmukaista profilointia.
• Vähentävätkö suojatoimet, kuten aggregointi, opt-out, pseudonymisointi tai tilitason segmentointi, riskiä.
• Säilyykö oikeusperuste pätevänä.
• Tarvitaanko läpinäkyvyyttä koskevia päivityksiä tai suostumusmekanismeja.

Lopputulos voi olla hyväksyntä, hyväksyntä suojatoimin tai hylkäys. Arvo syntyy siitä, että päätös dokumentoidaan ennen käytön aloittamista.

Vaihe 6: Hyväksy ulkoinen luovutus REG08:n kautta

Jos tekoälyanalytiikan toimittaja saa tietoja, toimittajasta tai hankinnasta vastaava omistaja kirjaa REG08:aan:

Clarysecin Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - SME vahvistaa toimittajan pääsyn minimointia:

Toimittajille saa myöntää pääsyn vain niihin vähimmäisjärjestelmiin ja tietoihin, joita ne tarvitsevat tehtävänsä suorittamiseen.

Tämä on tietosuojan minimointia sovellettuna toimittajan pääsyyn ja luovutuksiin.

Vaihe 7: Lisää tekninen täytäntöönpano

Hallintatallenteiden tueksi tarvitaan teknisiä kontrolleja. Project Wellness -tapauksessa Clarysec suosittelisi tyypillisesti DLP-sääntöjä vienteihin, roolipohjaisia pääsyrajoituksia, pääsy- ja siirtotapahtumien lokitusta, maskattuja tietoaineistoja kehitykseen, salausta siirtoon ja säilytykseen, toimittajien käyttöoikeuskatselmointeja, pilviturvallisuuden huolellisuusarviointia sekä REG02:n ja REG08:n säännöllistä otantavertausta järjestelmien tosiasialliseen toimintaan.

Näin ISO/IEC 27701:2025:n ja GDPR:n osoitusvelvollisuudesta tulee operatiivista näyttöä.

Kontrollikartoitus: tietosuojapäätöksestä tietoturvan toteutukseen

PII:n hallinta ei ole yksittäinen erillinen kontrolli. Se on tietosuojavaatimusten, tietoturvakontrollien, toimittajahallinnan ja auditointinäytön välinen kokonaisuus.

Zenith Controls käsittelee ISO/IEC 27002:2022 -standardin control 5.34 yksityisyydensuoja ja PII:n suojaus -kontrollia ennaltaehkäisevänä kontrollina, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta, Identify- ja Protect-kyberturvallisuuskäsitteitä sekä operatiivisia kyvykkyyksiä tietojen suojaamisessa sekä laki- ja vaatimustenmukaisuusalueella.

Control 5.34:n osalta Zenith Controls kartoittaa ympäröivän kontrolliekosysteemin, mukaan lukien inventaarion, luokittelun, siirron, pääsyn, identiteetin, pilven, toimittajaturvallisuuden, maskauksen, vuodon estämisen, lokituksen, seurannan ja kryptografian.

Maskauksesta Zenith Controls toteaa:

Tietojen maskaus (8.11) on tekniikka, jota käytetään usein PII:n suojaamiseen ei-tuotantoympäristöissä tai tietojen jakamisen yhteydessä. Se tukee suoraan control 5.34:ää vähentämällä aitojen henkilötietojen altistumista ja siten pienentämällä tietosuojariskiä.

Tiedonvuodon estosta opas selittää käytännön rajan:

DLP:llä on suora rooli henkilötietojen suojaamisessa. Control 8.12 asettaa rajat sille, miten PII:tä voidaan käyttää, jakaa tai siirtää, ja varmistaa, ettei henkilötietoja voi vuotaa luvattomien kanavien kautta.

Luovutusten hallintaa testaava auditoija voi siksi pyytää REG08:n lisäksi DLP-politiikkoja, estettyjen siirtojen lokeja, lähtevän sähköpostin kontrolleja, pilvijakamisen rajoituksia, salausvaatimuksia, toimittajien käyttöoikeustallenteita ja hyväksyttyjä poikkeuksia koskevaa todentavaa aineistoa.

Ristiinvaatimustenmukaisuuden arvo: GDPR, ISO 27701, NIS2, DORA, NIST ja COBIT

PII:n keräämisen, käytön ja luovuttamisen hallinta on tietosuojavetoinen, mutta sen todentava aineisto tukee laajempia kyberturvallisuus-, häiriönsieto- ja hallintavelvoitteita.

GDPR Articles 2 ja 3 määrittävät laajan aineellisen ja alueellisen soveltamisalan, joka voi kattaa SaaS-palvelut, fintech-toimijat ja EU:n ulkopuoliset digitaaliset palveluntarjoajat, kun ne palvelevat EU:ssa olevia henkilöitä tai seuraavat heidän käyttäytymistään. Article 5 edellyttää käyttötarkoitussidonnaisuutta, tietojen minimointia, täsmällisyyttä, säilytyksen rajoittamista, eheyttä, luottamuksellisuutta ja osoitusvelvollisuutta. Article 6 edellyttää jatkokäsittelyn oikeusperustetta ja yhteensopivuuden arviointia. Article 9 lisää tiukemmat ehdot erityisiin henkilötietoryhmiin kuuluville tiedoille, mikä on olennaista esimerkiksi profiloinnissa, terveyteen läheisesti liittyvissä tiedoissa, biometrisessä perehdytyksessä tai arkaluonteisissa attribuuteissa.

NIS2 Article 21 edellyttää, että keskeiset ja tärkeät toimijat toteuttavat oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia riskienhallintatoimenpiteitä. Sen vähimmäisalueisiin kuuluvat riskianalyysi, tietojärjestelmien turvallisuuspolitiikat, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen kehittäminen, kontrollien tehokkuus, koulutus, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta ja todennus.

DORA edellyttää, että finanssialan toimijat ylläpitävät ICT-riskienhallinnan viitekehystä, hallintoelimen vastuuvelvollisuutta, ICT-omaisuuserien ja riippuvuuksien tunnistamista, suojaus- ja ennaltaehkäisykontrolleja, havaitsemista, reagointia, palautumista, varmuuskopiointia, oppimista, poikkeamien hallintaa, testausta ja ICT-kolmansien osapuolten riskienhallintaa. Se edellyttää myös ICT-palvelusopimusten tietorekistereitä, huolellisuusarviointia, auditointioikeuksia, tietoturvavaatimuksia ja irtautumisstrategioita.

NIST Cybersecurity Framework 2.0 tarjoaa yhdistävän hallintakielen. Sen GOVERN-toiminto edellyttää, että lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset, mukaan lukien tietosuojavelvoitteet, ymmärretään ja niitä hallitaan. Se kattaa myös riskistrategian, roolit, politiikat, valvonnan ja toimittajariskien hallinnan.

COBIT 2019 -auditoijat etsivät hallintatavoitteita, päätösvaltuuksia, osoitusvelvollisuutta, prosessinomistajuutta, suorituskykyindikaattoreita ja varmennusnäyttöä. PII:n hallinnassa tämä tarkoittaa, että tietosuojavaatimukset on sisällytettävä yrityksen hallinnointiin, ei hallittava sivuprosessina.

Miten auditoijat testaavat samaa hallintakerrosta

Vahvan PIMS-toteutuksen on kestettävä erilaiset auditointitavat.

ISO/IEC 27001:2022- ja ISO/IEC 27701:2025 -auditoija aloittaa soveltamisalasta, sidosryhmistä, lakisääteisistä ja sopimusperusteisista vaatimuksista, riskien arvioinnista, soveltuvuuslausunnosta, operatiivisesta suunnittelusta ja dokumentoidusta näytöstä. Auditoija voi ottaa otoksia REG02:n käsittelytoimista ja testata, onko kontrollit kuten 5.34, 5.12, 5.14, 5.19–5.23, 8.11, 8.12, 8.15, 8.16 ja 8.24 toteutettu ja seurannassa.

GDPR-painotteinen auditoija tai viranomainen testaa osoitusvelvollisuutta. Hän voi aloittaa tietosuojaselosteesta, valituksesta, rekisteröidyn pyynnöstä tai toimittajaluovutuksesta ja jäljittää päätöksen taaksepäin. Miksi nämä tiedot kerättiin? Mikä oikeusperuste soveltui? Oliko tarkoitus yksilöity? Oliko myöhempi käyttö yhteensopivaa? Oliko vastaanottaja valtuutettu? Informoitiinko yksilöitä? Päivitettiinkö tallenteet ennen käsittelyn aloittamista?

DORA-valvontaviranomainen keskittyy soveltuvissa tapauksissa ICT-tuettuihin liiketoimintatoimintoihin, kolmannen osapuolen ICT-palveluntarjoajiin, sopimuslausekkeisiin, auditointioikeuksiin, tietosuojaan, poikkeamaviestintään, häiriönsietokyvyn testaukseen ja irtautumissuunnitteluun. Jos asiakkaiden PII:tä jaetaan kriittisen analytiikka- tai pilvipalveluntarjoajan kanssa, REG08, toimittajahuolellisuusarviointi ja sopimuskontrollit ovat keskeistä näyttöä.

NIST CSF -arvioija jäsentää asian hallintatulosten kautta. Hallitaanko lakisääteisiä ja sääntelyvaatimuksia? Ovatko roolit ja vastuut selkeitä? Ylläpidetäänkö ja noudatetaanko politiikkoja? Hallitaanko toimittajariskejä? Toimivatko tietosuojan, seurannan ja reagoinnin tulokset?

COBIT- tai ISACA-tyylinen auditoija kysyy, onko päätösvaltuudet määritelty, hyväksyvätkö liiketoimintavastaavat tietosuojariskin, mitataanko kontrollien suorituskykyä, seurataanko poikkeuksia ja saako johto merkityksellistä raportointia.

Yleiset sudenkuopat, joita Clarysec havaitsee toteutuksissa

Ensimmäinen sudenkuoppa on käsittelytoimien luettelon käsitteleminen dokumentointiharjoituksena hyväksyntäportin sijaan. Jos REG02 päivitetään julkaisun jälkeen, se ei voi osoittaa ennakkohallintaa.

Toinen on epämääräinen käyttötarkoituskieli. “Analytiikka,” “palvelun parantaminen” tai “asiakasymmärrys” on harvoin riittävän täsmällistä sisäisen käytön tai toissijaisen käytön ohjaamiseen.

Kolmas on kenttätason tarpeellisuuden puuttuminen. Tietojen minimointia ei voi osoittaa toteamalla, että jokainen kenttä on hyödyllinen. Liiketoiminnan on selitettävä, miksi kukin kenttä on tarpeellinen hyväksyttyä tarkoitusta varten.

Neljäs on hallitsematon toissijainen käyttö. Tilinhallintaa varten kerätyt tiedot muuttuvat hiljaisesti myynnin tiedusteluksi, sitten markkinointisegmentoinniksi ja lopulta tekoälyn koulutusaineistoksi. Jokainen käyttötarkoituksen muutos edellyttää yhteensopivuusanalyysiä ja joissakin tapauksissa uutta oikeusperustetta tai läpinäkyvyyspäivitystä.

Viides on heikko luovutusten hallinta. Toimittajaluettelot eivät ole sama asia kuin luovutustallenteet. REG08 sitoo vastaanottajan, roolin, tarkoituksen, PII-luokat, sijainnin, tiheyden ja valtuutuslähteen yhdeksi hyväksyntäketjuksi.

Kuudes on teknisen täytäntöönpanon puuttuminen. Politiikat voivat todeta, ettei PII:n pidä poistua hyväksytyistä kanavista, mutta sähköposti, viennit, jaetut asemat ja analytiikkatyökalut usein mahdollistavat sen. Tässä ISO/IEC 27002:2022 -standardin kontrollit 5.14, 8.12, 8.15, 8.16 ja 8.24 ovat olennaisia.

Käytännön 30 päivän aloitussuunnitelma

Organisaatioiden ei tarvitse ratkaista kaikkea kerralla. Aloita yhdestä korkean riskin käsittelytoimesta, mieluiten sellaisesta, johon liittyy asiakkaiden profilointia, tekoälyanalytiikkaa, arkaluonteisia attribuutteja, rajat ylittävä siirto tai kolmannen osapuolen alusta.

Ensimmäisellä viikolla tunnista käsittelytoimi, omistaja, PII-luokat, järjestelmät, toimittajat ja nykyinen tarkoitus. Varmista, onko toiminto jo kuvattu REG02:ssa ja onko luovutus kuvattu REG08:ssa.

Toisella viikolla täydennä kenttäkohtaiset tarpeellisuusperustelut. Haasta liialliset tietoelementit. Vahvista luokittelu ja merkinnät. Selvitä, voivatko maskaus, aggregointi tai pseudonymisointi vähentää riskiä.

Kolmannella viikolla määritä sisäisen käytön säännöt ja suorita tarvittavat toissijaisen käytön yhteensopivuustarkistukset. Päätä, tarvitsevatko tietosuojaselosteet, oikeusperusteen arvioinnit tai rekisteröityjen hallintakeinot päivityksiä.

Neljännellä viikolla validoi ulkoisten luovutusten tallenteet, toimittajien pääsy, sopimusperusteiset suojatoimet, tietojenkäsittelysopimuksen ehdot, siirtokontrollit, lokitus, DLP ja poistamisvelvoitteet. Ota sen jälkeen otos järjestelmien tosiasiallisesta toiminnasta ja vertaa sitä hyväksyntöihin.

30 päivän lopussa johdolla tulisi olla konkreettinen näyttöpaketti: REG02, REG08, luokittelutallenteet, käyttöoikeusmatriisit, DLP- ja lokitusnäyttö, toimittajahuolellisuusarviointi, sopimusperusteiset suojatoimet, yhteensopivuustarkistukset ja avoimet korjaavat toimenpiteet.

Politiikasta näyttöön

PII:n keräämisen, käytön ja luovuttamisen hallinta on kohta, jossa tietosuojasta tulee todellista. Se erottaa väitteen “noudatamme GDPR:ää” siitä, että jokainen keräämistä, käyttöä, uudelleenkäyttöä ja luovutusta koskeva päätös on ollut hallinnassa ennen käsittelyn tapahtumista.

Clarysecin työkalupaketti tarjoaa tietosuoja-, tietoturva- ja vaatimustenmukaisuustiimeille käytännön etenemistavan:

• Käytä PII09 PII:n keräämistä, käyttöä, luovuttamista ja jakamista koskevaa politiikkaa pakollisten hyväksyntäporttien määrittämiseen.
• Käytä P17 Tietosuoja- ja yksityisyydensuojapolitiikkaa tai Tietosuoja- ja yksityisyydensuojapolitiikka - SME lainmukaisen, kohtuullisen, läpinäkyvän ja minimoidun käsittelyn perustana.
• Käytä Tiedon luokittelu- ja merkintäpolitiikkaa ja Kolmansien osapuolten ja toimittajien tietoturvapolitiikkaa - SME luokittelun, jakamisen ja toimittajien pääsyn hallintaan.
• Seuraa Zenith Blueprint: auditointivalmista 30 vaiheen tiekarttaa, jotta kontrolliympäristö toteutetaan oikeassa järjestyksessä.
• Käytä Zenith Controls: ristiinvaatimustenmukaisuuden opasta ymmärtääksesi, miten ISO/IEC 27002:2022 -kontrollit, kuten 5.34, 5.12, 5.14, 8.11 ja 8.12, tukevat GDPR:n, NIS2:n, DORA:n, NIST:n ja auditoinnin odotuksia.

Jos seuraava auditointi, asiakkaan huolellisuusarviointipyyntö tai hallituksen katselmus kysyy, miten hallitsette, mitä PII:tä kerätään, miten sitä käytetään ja milloin sitä luovutetaan, älkää luottako pelkkiin politiikkalauseisiin.

Aloita yhdestä korkean riskin toiminnosta. Rakenna REG02-tallenne. Perustele jokainen tietoelementti. Määritä sisäisen käytön säännöt. Suorita toissijaisen käytön yhteensopivuustarkistus. Luo REG08-luovutustallenne. Testaa sen jälkeen, vastaavatko pääsy, DLP, maskaus, lokitus, salaus ja toimittajakontrollit päätöstä.

Näin ISO/IEC 27701:2025:n ja GDPR:n osoitusvelvollisuudesta tulee näyttöä.

Tutustu Clarysec PIMS -työkalupakettiin, aloita PII09 PII:n keräämistä, käyttöä, luovuttamista ja jakamista koskevasta politiikasta ja käytä Zenith Blueprint -aineistoa muuttaaksesi tietosuojan hallinnan politiikkatavoitteesta auditointivalmiiksi näytöksi.