Auditointivalmis henkilötietojen (PII) suojaus GDPR-, NIS2- ja DORA-vaatimuksiin
Hälytys saapui Sarahin sähköpostiin tiistai-iltana kello 22.
Kasvavan FinTech SaaS -yhtiön tietoturvajohtajana Sarah oli tottunut myöhäisillan hälytyksiin. Tämä oli erilainen. Nuorempi kehittäjä oli julkaissut staging-tietokannan julkiseen päätepisteeseen testatessaan uutta analytiikkaominaisuutta. Tietokannan piti sisältää testidataa, mutta äskettäinen tuotannosta staging-ympäristöön tehty synkronointi oli täyttänyt sen aidolla asiakkaiden henkilötiedoilla.
Tietoturvapoikkeama rajattiin nopeasti. Sitten tehtiin toinen havainto. Samasta tietoaineistosta oli kopioitu migraatiotaulukko nimeltä customer_users_final_v7.xlsx. Se sisälsi nimiä, sähköpostiosoitteita, roolioikeuksia, käyttölokeja, maatietoja, tukimuistiinpanoja ja vapaamuotoisia kommentteja, joiden ei olisi koskaan pitänyt päätyä testauksen työnkulkuun. Tiedosto oli kopioitu jaetulle levylle, ladattu kehittäjän työasemalle, liitetty tikettiin ja unohdettu.
Puoleenyöhön mennessä Sarah ei enää johtanut teknisen virheellisen konfiguraation käsittelyä. Hän johti auditointiongelmaa.
Yhtiö oli jo sertifioitu ISO/IEC 27001:2022 -standardin mukaisesti. Hallitus pyysi GDPR-varmennusta ennen laajentumista EU-markkinoille. Rahoituspalvelualan asiakkaat lähettivät DORA:n mukaisia due diligence -kyselyitä. Pilvi- ja hallinnoitujen palvelujen suhteet nostivat esiin NIS2:n toimitusketjukysymyksiä. Lakitoiminto pystyi selittämään velvoitteet. Engineering pystyi osoittamaan salauksen. Tuotetiimillä oli sisäänrakennetun tietosuojan tavoitteet. Soveltuvuuslausunto mainitsi yksityisyydensuojan ja henkilötietojen suojauksen.
Kukaan ei kuitenkaan pystynyt osoittamaan yhdessä jäljitettävässä ketjussa, mitä henkilötietoja oli olemassa, miksi niitä käsiteltiin, kuka pääsi niihin käsiksi, missä ne oli peitetty, mitkä toimittajat käsittelivät niitä, kuinka kauan niitä säilytettiin ja miten poikkeama luokiteltaisiin GDPR:n, NIS2:n tai DORA:n perusteella.
Juuri tämän puutteen vuoksi ISO/IEC 27701:2025 ja ISO/IEC 29151:2022 ovat tärkeitä. Ne eivät ole pelkkiä tietosuojamerkintöjä. Ne auttavat organisaatioita muuttamaan tietosuojalupaukset auditointivalmiiksi henkilötietojen suojauskontrolleiksi. ISO/IEC 27701:2025 laajentaa ISO/IEC 27001:2022 -standardin mukaisen tietoturvallisuuden hallintajärjestelmän tietosuojatiedon hallintaan. ISO/IEC 29151:2022 lisää käytännön ohjeita henkilöä yksilöivien tietojen suojaamiseen koko niiden elinkaaren ajan.
Clarysecin lähestymistapa on rakentaa yksi näyttöön perustuva tietosuojan ja tietoturvan toimintamalli, ei erillisiä vaatimustenmukaisuussiiloja. Malli yhdistää Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint- ja Zenith Controls: The Cross-Compliance Guide Zenith Controls -kokonaisuudet sekä Clarysecin politiikat yhdeksi jäljitettäväksi järjestelmäksi GDPR-, ISO/IEC 27001:2022-, ISO/IEC 27701:2025-, ISO/IEC 29151:2022-, NIS2-, DORA-, NIST-tyyppisten varmennusarviointien ja COBIT 2019 -hallinnointiodotuksia varten.
Miksi henkilötietojen suojaus on nyt hallitustason auditointikysymys
Henkilötietojen suojausta pidettiin aiemmin tietosuojatiimin vastuuna. Nykyisin se on hallitustason luottamus-, häiriönsietokyky- ja sääntelykysymys.
GDPR on edelleen henkilötietojen suojan perustaso Euroopassa ja sen ulkopuolella. Se määrittelee henkilötiedot, käsittelyn, rekisterinpitäjän, käsittelijän, vastaanottajan, kolmannen osapuolen, suostumuksen ja henkilötietojen tietoturvaloukkauksen tavoilla, jotka vaikuttavat SaaS-sopimuksiin, tukitoimintoihin, analytiikkaan, tuotetelemetriaan, toimittajahallintaan ja tietoturvapoikkeamiin reagointiin. Sen periaatteet edellyttävät lainmukaisuutta, kohtuullisuutta, läpinäkyvyyttä, käyttötarkoitussidonnaisuutta, tietojen minimointia, täsmällisyyttä, säilytyksen rajoittamista, eheyttä, luottamuksellisuutta ja osoitusvelvollisuutta. Auditoinnin näkökulmasta GDPR ei kysy vain, onko data salattu. Se kysyy, pystyykö organisaatio osoittamaan, miksi data on olemassa ja miten vaatimustenmukaisuus saavutetaan.
NIS2 nostaa kyberturvallisuuden hallinnointivaatimusten tasoa keskeisille ja tärkeille toimijoille. Article 21 edellyttää kyberturvallisuusriskien hallintatoimenpiteitä, mukaan lukien riskianalyysi, tietojärjestelmien turvallisuuspolitiikat, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen kehittäminen, haavoittuvuuksien käsittely, kontrollien tehokkuuden arviointi, kyberhygienia, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta, todennus ja turvallinen viestintä. Article 23 lisää vaiheistetun poikkeamailmoittamisen, mukaan lukien varhaisvaroituksen 24 tunnin kuluessa, ilmoituksen 72 tunnin kuluessa ja loppuraportin kuukauden kuluessa ilmoituksesta.
DORA muuttaa keskustelun rahoitusalan toimijoiden ja niiden ICT-palveluntarjoajien osalta. Sitä sovelletaan 17. tammikuuta 2025 alkaen, ja se luo yhdenmukaistetun digitaalisen häiriönsietokyvyn sääntelykehikon, joka kattaa ICT-riskien hallinnan, merkittävien ICT:hen liittyvien poikkeamien raportoinnin, häiriönsietokyvyn testauksen, ICT-kolmansien osapuolten riskin, sopimusvaatimukset sekä kriittisten ICT-kolmansien osapuolten palveluntarjoajien valvonnan. Monille rahoitusalan toimijoille DORA toimii sektorikohtaisena unionin säädöksenä tilanteissa, joissa NIS2-vastaavat velvoitteet menevät päällekkäin. Rahoituslaitoksia palveleville SaaS- ja ICT-toimittajille DORA-paine näkyy usein sopimuslausekkeina, asiakasauditointeina, exit-suunnittelun vaatimuksina, poikkeamatilanteiden tukivelvoitteina ja häiriönsietokyvyn testauksena.
ISO/IEC 27001:2022 muodostaa hallintajärjestelmän rungon. Se edellyttää toimintaympäristön, sidosryhmien, soveltamisalan, johdon vastuuvelvollisuuden, politiikkojen, roolien, riskien arvioinnin, riskien käsittelyn, soveltuvuuslausunnon, sisäisen tarkastuksen, johdon katselmoinnin ja jatkuvan parantamisen määrittämistä ja ylläpitoa. Liite A sisältää henkilötietojen suojauksen kannalta suoraan olennaisia kontrolleja, kuten 5.34 Yksityisyydensuoja ja henkilötietojen suojaaminen, 5.18 Käyttöoikeudet, 8.11 Tietojen peittäminen, 5.23 Tietoturvallisuus pilvipalvelujen käytössä, 8.15 Lokitus, 8.33 Testitiedot, 8.24 Salaustekniikan käyttö ja 8.10 Tietojen poistaminen.
Haaste ei ole se, ettei organisaatioilla olisi kontrolleja. Haaste on kontrollien pirstaleisuus. Tietosuojan tallenteet ovat lakitoiminnolla. Käyttöoikeuskatselmoinnit ovat IT:llä. Peittämisskriptit ovat engineering-tiimillä. Toimittajasopimukset ovat hankinnalla. Näyttö on tiketeissä, kuvakaappauksissa, taulukoissa ja sähköposteissa.
ISO/IEC 27701:2025 ja ISO/IEC 29151:2022 auttavat kokoamaan tämän näytön tietosuojatiedon hallinnan ja henkilötietojen suojauskäytäntöjen ympärille. Clarysec muuttaa tämän rakenteen toimintamalliksi.
ISMS:stä PIMS:ään: integroitu tietosuojan kontrolliketju
ISO/IEC 27001:2022 -standardin mukainen ISMS vastaa ydinkysymykseen: hallinnoidaanko, toteutetaanko, seurataanko ja parannetaanko tietoturvaa riskiperusteisesti?
Privacy Information Management System eli PIMS laajentaa kysymyksen henkilötietoihin: hallitaanko tietosuojavastuita, henkilötietojen käsittelytoimia, tietosuojariskejä, rekisterinpitäjän ja käsittelijän velvoitteita, rekisteröityjen oikeuksia sekä tietosuojakontrollien näyttöä samassa järjestelmässä?
ISO/IEC 27701:2025 laajentaa ISMS:n tietosuojan hallinnointiin. ISO/IEC 29151:2022 täydentää sitä käytännön henkilötietojen suojausohjeilla, kuten keräämisen rajoittamisella, luovutusten hallinnalla, peittämisen tai pseudonymisoinnin soveltamisella, siirtojen suojaamisella, pääsyn rajoittamisella ja kontrollien sovittamisella tietosuojariskiin.
| Kerros | Ensisijainen kysymys | Tyypillinen auditointinäyttö |
|---|---|---|
| ISO/IEC 27001:2022 | Onko käytössä hallinnoitu ja riskiperusteinen ISMS, jossa valitut kontrollit toimivat? | Soveltamisala, sidosryhmät, riskien arviointi, riskienkäsittelysuunnitelma, SoA, politiikat, sisäinen tarkastus, johdon katselmointi |
| ISO/IEC 27701:2025 | Hallinnoidaanko tietosuojavastuita, tietosuojariskejä ja henkilötietojen käsittelytoimia hallintajärjestelmän sisällä? | Tietosuojaroolit, käsittelyrekisteri, rekisterinpitäjän ja käsittelijän menettelyt, tietosuojariskien arvioinnit, DPIA:t, rekisteröidyn pyyntöprosessi |
| ISO/IEC 29151:2022 | Onko käytännön henkilötietojen suojaustoimenpiteet toteutettu koko tiedon elinkaaren ajan? | Henkilötietojen luokittelu, pääsyn rajoitukset, peittäminen, pseudonymisointi, säilytyskontrollit, siirtojen suojatoimet, poikkeamanäyttö |
| GDPR | Voiko organisaatio osoittaa lainmukaisen, kohtuullisen, läpinäkyvän, minimoidun, turvallisen ja osoitusvelvollisuuden mukaisen käsittelyn? | Oikeusperustetta koskevat tallenteet, tietosuojailmoitukset, DPIA:t, loukkausprosessi, käsittelijäsopimukset, oikeuksien käsittely |
| NIS2 ja DORA | Voiko organisaatio hallinnoida kyberturvallisuus- ja häiriönsietokykyriskejä, mukaan lukien poikkeamat ja toimittajat? | Johdon valvonta, ICT-riskiviitekehys, poikkeamien luokittelu, raportoinnin pelikirjat, toimittajarekisterit, auditointioikeudet, jatkuvuustestit |
Tämä kerroksellinen malli ehkäisee yleisimmän virheen tietosuojan vaatimustenmukaisuudessa: henkilötietojen käsittelemisen vain yhtenä arkaluonteisen datan tyyppinä. Henkilötietoihin liittyy lakisääteisiä, eettisiä, operatiivisia, sopimusperusteisia ja maineeseen kohdistuvia velvoitteita. Ne tarvitsevat kontrolliketjun, joka alkaa tietoisuudesta ja päättyy näyttöön.
Aloita datatietoisuudesta, älä salauskaavioista
Yleisin Clarysecin havaitsema tietosuojapuutteiden syy on kontekstin puuttuminen. Yhtiö ei voi suojata henkilötietoja, jos se ei tiedä, mitä henkilötietoja sillä on, missä ne sijaitsevat, mihin tarkoitukseen niitä käytetään, kuinka kauan niitä säilytetään tai kuka voi päästä niihin käsiksi.
Zenith Blueprint käynnistää tämän työn varhain riskienhallintavaiheessa. Step 9, Identifying Assets, Threats, and Vulnerabilities, ohjeistaa organisaatioita inventoimaan tietovarat ja merkitsemään henkilötiedot nimenomaisesti:
”Kirjaa kustakin omaisuuserästä keskeiset tiedot: nimi/kuvaus, omistaja, sijainti ja luokittelu (arkaluonteisuus). Omaisuuserä voisi olla esimerkiksi ’Asiakastietokanta – IT-osaston omistama – ylläpidetään AWS:ssä – sisältää henkilö- ja taloustietoja (korkea arkaluonteisuus).’”
Lisäksi siinä todetaan: ”Varmista, että henkilötietoja sisältävät omaisuuserät merkitään (GDPR-relevanssin vuoksi) ja että kriittiset palveluomaisuuserät kirjataan (mahdollisen NIS2-sovellettavuuden vuoksi, jos toimit säännellyllä sektorilla).”
Tämä on perusta ISO/IEC 27701:2025- ja ISO/IEC 29151:2022 -standardien käyttöönotolle. Käytännön eteneminen on suoraviivaista:
- Tunnista järjestelmät, tietoaineistot, tietovarastot, lokit, raportit, varmuuskopiot, tukityökalut, kehitysympäristöt ja toimittajat, jotka käsittelevät henkilötietoja.
- Nimeä omistaja jokaiselle henkilötietoja sisältävälle omaisuuserälle.
- Luokittele henkilötiedot arkaluonteisuuden, liiketoimintatarkoituksen, oikeusperusteen, käsittelyroolin ja säilytysvaatimuksen perusteella.
- Kytke jokainen henkilötietoja sisältävä omaisuuserä uhkiin, haavoittuvuuksiin, riskiskenaarioihin ja sääntelyvelvoitteisiin.
- Valitse kontrollit, määritä näyttö ja seuraa toimintaa ajan kuluessa.
Clarysecin politiikat tekevät tästä toteutettavaa. SME Data Protection and Privacy Policy Tietosuoja- ja yksityisyydensuojapolitiikka - SME toteaa:
”Tietosuojakoordinaattorin on ylläpidettävä rekisteriä kaikista henkilötietojen käsittelytoimista, mukaan lukien tietoryhmät, tarkoitus, oikeusperuste ja säilytysajat.”
Osiossa ”Hallinnointivaatimukset”, politiikan kohta 5.2.1.
Yritystason organisaatioille Data Protection and Privacy Policy Tietosuoja- ja yksityisyydensuojapolitiikka asettaa tiukan minimointisäännön:
”Vain tiettyä, oikeutettua liiketoimintatarkoitusta varten tarpeellisia tietoja saa kerätä ja käsitellä.”
Osiossa ”Politiikan toimeenpanovaatimukset”, politiikan kohta 6.2.1.
Nämä kohdat muuttavat GDPR:n osoitusvelvollisuuden päivittäiseksi toiminnaksi. Ne tukevat myös tietosuojatiedon hallintaa ja henkilötietojen suojausta, koska ne velvoittavat organisaation määrittämään, mitä tietoja on olemassa, miksi niitä on olemassa ja ovatko ne tarpeellisia.
Kolme kontrollia, jotka tekevät henkilötietojen suojauksesta todellista
Kolme ISO/IEC 27001:2022 -standardin liite A:n kontrollia ratkaisee usein, onko henkilötietojen suojaus puolustettavissa auditoinnissa: 5.34 Yksityisyydensuoja ja henkilötietojen suojaaminen, 8.11 Tietojen peittäminen ja 5.18 Käyttöoikeudet.
5.34 Yksityisyydensuoja ja henkilötietojen suojaaminen
Kontrolli 5.34 on hallinnoinnin keskus. Zenith Controls käsittelee 5.34:ää ennaltaehkäisevänä kontrollina, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta sekä liittyy Identify- ja Protect-kyberturvallisuuskäsitteisiin ja operatiivisiin kyvykkyyksiin tietojen suojauksessa ja lakisääteisten vaatimusten noudattamisessa.
Zenith Controls tekee riippuvuuden selväksi:
”Tietovarojen inventaarion (5.9) tulee sisältää henkilötietoja sisältävät tietovarannot (asiakastietokannat, HR-tiedostot). Tämä tukee 5.34:ää varmistamalla, että organisaatio tietää, mitä henkilötietoja sillä on ja missä ne sijaitsevat, mikä on ensimmäinen askel niiden suojaamisessa.”
Kontrolli 5.34 riippuu kontrollista 5.9 Tiedon ja muiden siihen liittyvien omaisuuserien luettelo, koska henkilötietoja ei voi suojata, jos niitä ei löydetä. Se liittyy myös kontrolliin 5.23 Tietoturvallisuus pilvipalvelujen käytössä, koska suurin osa henkilötiedoista sijaitsee nykyisin pilvialustoilla, SaaS-työkaluissa, analytiikkaympäristöissä ja hallinnoiduissa palveluissa.
Korkean riskin käsittelyssä yritystason Data Protection and Privacy Policy edellyttää:
”Uhkamallinnus ja tietosuojaa koskevat vaikutustenarvioinnit (DPIA) ovat pakollisia korkean riskin käsittelyjärjestelmille.”
Osiossa ”Politiikan toimeenpanovaatimukset”, politiikan kohta 6.3.4.
Tämä kohta on kriittinen. Se muuttaa tietosuojan suunnittelu- ja riskienhallintatoimeksi, ei viime hetken juridiseksi tarkastukseksi.
8.11 Tietojen peittäminen
Kontrolli 8.11 on suora vastaus Sarahin staging-tietokannan altistumiseen. Zenith Controls kuvaa 8.11:n ennaltaehkäisevänä luottamuksellisuuskontrollina tietojen suojauksen osa-alueella. Se liittää 8.11:n kontrolliin 5.12 Tiedon luokittelu, koska peittämispäätökset riippuvat arkaluonteisuudesta, kontrolliin 5.34, koska peittäminen tukee tietosuojaa, ja kontrolliin 8.33 Testitiedot, koska testiympäristöjen ei tule altistaa aitoja henkilötietoja.
Data Masking and Pseudonymization Policy Tietojen peittämisen ja pseudonymisoinnin politiikka tekee säännön yksiselitteiseksi:
”Aitoja henkilötietoja ei saa käyttää kehitys-, testi- tai staging-ympäristöissä. Sen sijaan on käytettävä peitettyä tai pseudonymisoitua dataa, ja se on tuotettava ennalta hyväksytyistä muunnosmalleista.”
Osiossa ”Politiikan toimeenpanovaatimukset”, politiikan kohta 6.3.
Pk-yrityksille Data Masking and Pseudonymization Policy Tietojen peittämisen ja pseudonymisoinnin politiikka - SME lisää keskeisen turvallisuus- ja näyttövaatimuksen:
”Avaimiin pääsyn on oltava salattua, pääsynhallinnan piirissä ja lokitettua.”
Osiossa ”Politiikan toimeenpanovaatimukset”, politiikan kohta 6.2.1.3.
Tällä on merkitystä, koska pseudonymisointi vähentää riskiä vain, kun muunnoslogiikka, avaimet ja uudelleentunnistamisen polut ovat hallinnassa.
5.18 Käyttöoikeudet
Kontrolli 5.18 on vähimmän oikeuden periaatteen operatiivinen ydin. Zenith Controls käsittelee sitä ennaltaehkäisevänä kontrollina, joka liittyy luottamuksellisuuteen, eheyteen ja saatavuuteen ja sijoittuu identiteetin- ja pääsynhallinnan alueelle. Se kytkee 5.18:n kontrolliin 5.15 Pääsynhallinta, kontrolliin 5.16 Identiteetinhallinta ja kontrolliin 8.2 Etuoikeutetut käyttöoikeudet.
SME Data Classification and Labeling Policy Tiedon luokittelu- ja merkintäpolitiikka - SME toteaa:
”Pääsy on rajattava erikseen valtuutettuihin käyttäjiin, joilla on tarve tietää.”
Osiossa ”Hallinnointivaatimukset”, politiikan kohta 5.2.1.
Yritystason Data Classification and Labeling Policy Tiedon luokittelu- ja merkintäpolitiikka lisää luokittelun perustason:
”Kaikille tietovaroille on määritettävä selkeä luokittelu niiden luonti- tai käyttöönottohetkellä. Jos nimenomaista luokittelua ei ole, omaisuuserien oletusluokittelun on oltava ’Luottamuksellinen’, kunnes ne katselmoidaan muodollisesti.”
Osiossa ”Hallinnointivaatimukset”, politiikan kohta 5.4.
Yhdessä nämä kontrollit muodostavat käytännön henkilötietojen suojausketjun: tiedä, mitä henkilötietoja on olemassa, luokittele ne, rajoita pääsyä, peitä tiedot silloin kun täysi henkilöllisyys ei ole tarpeen, suojaa avaimet, kirjaa käyttö lokiin ja säilytä näyttö.
Rakenna jäljitettävyys soveltuvuuslausunnon kautta
Tietosuojan hallintajärjestelmästä tulee auditointivalmis, kun se pystyy osoittamaan jäljitettävyyden. Zenith Blueprint, riskienhallintavaihe, Step 13, Risk Treatment Planning and Statement of Applicability, kuvaa soveltuvuuslausuntoa yhdistäväksi asiakirjaksi:
”SoA on käytännössä yhdistävä asiakirja: se liittää riskien arvioinnin ja riskien käsittelyn käytössä oleviin varsinaisiin kontrolleihin. Kun se täytetään, samalla tarkistetaan, onko jokin kontrolli jäänyt huomaamatta.”
Tämä ajatus on keskeinen ISO/IEC 27701:2025-, ISO/IEC 29151:2022-, GDPR-, NIS2- ja DORA-valmiudessa. Jokaisen henkilötietokontrollin tulee olla jäljitettävissä vaatimuksesta riskiin, riskistä kontrolliin, kontrollista omistajaan, omistajasta näyttöön ja näytöstä katselmointiin.
| Jäljitettävyyskohde | Esimerkki asiakastuen henkilötiedoista | Odotettu näyttö |
|---|---|---|
| Henkilötietoja sisältävä omaisuuserä | Tukitikettialusta, jossa on asiakkaiden nimiä, sähköpostiosoitteita, lokeja ja liitteitä | Omaisuusrekisterimerkintä, omistaja, pilvisijainti, luokittelu |
| Käsittelyn tarkoitus | Asiakastuki ja palveludiagnostiikka | Käsittelyrekisteri, oikeusperuste, säilytysaika |
| Riskiskenaario | Tukihenkilö tai kehittäjä käyttää asiakkaan tietoja liian laajasti | Riskirekisterimerkintä, todennäköisyys, vaikutus, omistaja |
| Kontrollien valinta | 5.34 henkilötietojen suojaus, 5.18 käyttöoikeudet, 8.11 peittäminen, 8.15 lokitus, 5.23 pilvipalvelujen hallinta | SoA, pääsynhallintapolitiikka, peittämisstandardi, lokitusmääritys |
| Operatiivinen näyttö | Roolipohjainen pääsy, peitetyt viennit, neljännesvuosittainen käyttöoikeuskatselmointi, hälytys massalatauksista | Käyttöoikeuskatselmointien tallenteet, DLP-hälytykset, lokit, tikettinäyttö |
| Sääntelykartoitus | GDPR:n osoitusvelvollisuus ja turvallisuus, NIS2-riskienhallinta, DORA:n ICT-riski- ja toimittajavaatimukset | Vaatimustenmukaisuusmatriisi, poikkeamien pelikirja, toimittajasopimusrekisteri |
| Katselmointinäyttö | Sisäisen tarkastuksen havainto suljettu, johdon katselmoinnin toimenpide hyväksytty | Auditointiraportti, korjaavat toimenpiteet, johdon katselmuksen pöytäkirja |
ISO/IEC 27005:2022 tukee tätä riskiperusteista lähestymistapaa korostamalla sidosryhmävaatimuksia, yhteisiä riskikriteerejä, vastuullisia riskinomistajia, toistettavaa riskien arviointia, riskien käsittelyä, kontrollien valintaa, soveltuvuuslausunnon yhdenmukaistamista, jäännösriskin hyväksyntää, seurantaa ja jatkuvaa parantamista. Henkilötietojen suojauksen tulee olla elävä riskisykli, ei kertaluonteinen GDPR-dokumentointiharjoitus.
Korjaa riskialtis taulukko ja staging-tietokanta
Sarahin poikkeamasta voidaan muodostaa toistettava kontrollipaketti, jos korjaavat toimenpiteet toteutetaan järjestelmällisesti.
| Vaihe | Toimenpide | Clarysecin näyttötulos |
|---|---|---|
| 1 | Rekisteröi staging-tietokanta ja taulukko henkilötietoja sisältäviksi omaisuuseriksi | Omaisuusluettelon merkinnät, joissa on omistaja, sijainti, luokittelu, henkilötietoryhmät, tarkoitus ja säilytys |
| 2 | Päivitä käsittelytoimi | Rekisterimerkintä, joka osoittaa tietoryhmät, oikeusperusteen, tarkoituksen ja säilytysajan |
| 3 | Luokittele tiedostot ja tietoaineistot | Luottamuksellinen tai korkeampi luokittelu sovelletaan oletuksena, kunnes muodollinen katselmointi on tehty |
| 4 | Poista aidot henkilötiedot ei-tuotantoympäristöistä | Peitetty tai pseudonymisoitu tietoaineisto, joka on luotu hyväksytyistä muunnosmalleista |
| 5 | Rajoita ja katselmoi pääsy | Tarve tietää -periaatteen mukaiset oikeudet, liiallisten käyttöoikeuksien peruminen, käyttöoikeuskatselmoinnin tallenne |
| 6 | Suojaa muunnoslogiikka ja avaimet | Salattu, pääsynhallittu ja lokitettu pääsy avaimiin |
| 7 | Kerää näyttö keskitetysti | Omaisuuserän tallenne, riskimerkintä, käyttöoikeuskatselmointi, poistotodiste, peittämisen hyväksyntä ja tiketin sulkeminen |
| 8 | Päivitä SoA ja riskienkäsittelysuunnitelma | Riskiskenaario linkitetty kontrolleihin 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 sekä toimittajakontrolleihin |
| 9 | Päätä, edellytetäänkö DPIA:ta | DPIA tai dokumentoitu perustelu korkean riskin käsittelyä koskeville päätöksille |
| 10 | Kirjaa opit | Päivitetty koulutus, turvallisen kehityksen säännöt, vientikontrollit, DLP-seuranta ja testidataa koskeva ohjeistus |
Audit and Compliance Monitoring Policy Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - SME toteaa:
”Kaikki näyttö on säilytettävä keskitetyssä auditointikansiossa.”
Osiossa ”Politiikan toimeenpanovaatimukset”, politiikan kohta 6.2.1.
Information Security Policy Tietoturvapolitiikka tekee laajemman auditointiodotuksen yksiselitteiseksi:
”Kaikkien toteutettujen kontrollien on oltava auditoitavissa, niitä on tuettava dokumentoiduilla menettelyillä ja niiden toiminnasta on säilytettävä näyttö.”
Osiossa ”Politiikan toimeenpanovaatimukset”, politiikan kohta 6.6.1.
Nämä kaksi kohtaa erottavat kontrollin olemassaolon siitä, että sen toiminta voidaan myös osoittaa.
Vaatimustenmukaisuuksien välinen kartoitus yhdelle henkilötietojen kontrollikokonaisuudelle
Henkilötietojen suojausta on helpompi puolustaa, kun se on kartoitettu eri viitekehyksiin ennen kuin auditoija kysyy.
| Henkilötietojen suojauksen teema | GDPR-relevanssi | ISO/IEC 27001:2022-, ISO/IEC 27701:2025- ja ISO/IEC 29151:2022 -relevanssi | NIS2-relevanssi | DORA-relevanssi | NIST- ja COBIT 2019 -auditointinäkökulma |
|---|---|---|---|---|---|
| Henkilötietoinventaario ja käsittelyrekisteri | Osoitusvelvollisuus, oikeusperuste, käyttötarkoitussidonnaisuus, säilytyksen rajoittaminen | ISMS:n toimintaympäristö, 5.9 omaisuusluettelo, tietosuojatiedon hallinta, henkilötietojen suojaus | Omaisuudenhallinta ja riskianalyysi | ICT-omaisuuserien ja palveluriippuvuuksien tuntemus | Identify-toiminnon näyttö ja tietovarojen hallinnointi |
| Käyttöoikeudet ja vähimmän oikeuden periaate | Eheys ja luottamuksellisuus, rooliin perustuva rajattu pääsy | 5.15 pääsynhallinta, 5.16 identiteetinhallinta, 5.18 käyttöoikeudet, 8.2 etuoikeutetut käyttöoikeudet | Pääsynhallinta, henkilöstöturvallisuus, todennus | ICT-riskikontrollit ja etuoikeutetun pääsyn valvonta | Pääsyn soveltaminen, omistajuus, vastuu ja seuranta |
| Peittäminen ja pseudonymisointi | Tietojen minimointi, sisäänrakennettu tietosuoja, käsittelyn turvallisuus | 5.12 luokittelu, 5.34 henkilötietojen suojaus, 8.11 tietojen peittäminen, 8.33 testitiedot | Kyberhygienia ja turvallinen kehittäminen | Turvallinen testaus, tietovuodon vähentäminen, toiminnallinen häiriönsietokyky | Teknisten suojatoimien testaus ja kontrollien luotettava toiminta |
| Poikkeamien luokittelu ja raportointi | Henkilötietojen tietoturvaloukkauksen arviointi ja ilmoittaminen | Poikkeamasuunnittelu, tapahtuman arviointi, reagointi, näytön kerääminen | 24 tunnin varhaisvaroitus, 72 tunnin ilmoitus, loppuraportti | Merkittävän ICT:hen liittyvän poikkeaman luokittelu ja raportointi | Eskalointikriteerit, päätöslokit, juurisyy, korjaavat toimenpiteet |
| Toimittaja- ja pilvikäsittely | Käsittelijän velvoitteet, siirrot, sopimukset | 5.21 ICT-toimitusketju, 5.23 pilvipalvelut, 5.31 lakisääteiset ja sopimusperusteiset vaatimukset | Toimitusketjun turvallisuus | ICT-kolmannen osapuolen riski, auditointioikeudet, exit ja siirtymä | Kolmansien osapuolten hallinnointi, varmentaminen ja johdon vastuuvelvollisuus |
Tässä Zenith Controls on erityisen hyödyllinen. Kontrollissa 5.34 se kartoittaa henkilötietojen suojauksen omaisuusluetteloon, tietojen peittämiseen ja pilven hallinnointiin. Kontrollissa 8.11 se kartoittaa peittämisen luokitteluun, tietosuojaan ja testitietoihin. Kontrollissa 5.18 se kartoittaa käyttöoikeudet pääsynhallintaan, identiteetinhallintaan ja etuoikeutettuun pääsyyn. Näiden suhteiden avulla tiimi voi selittää paitsi sen, että kontrolli on olemassa, myös miksi se on olemassa ja mitkä viereiset kontrollit toimivat sen kanssa.
Miten eri auditoijat testaavat samaa henkilötietokontrollia
Yksittäistä kontrollia, kuten 8.11 Tietojen peittäminen, tarkastellaan eri tavoin auditointinäkökulmasta riippuen.
| Auditoijatyyppi | Ensisijainen painopiste | Odotettu näyttö |
|---|---|---|
| ISO/IEC 27001:2022- ja ISO/IEC 27701:2025 -auditoija | ISMS- ja PIMS-integraatio, riskien käsittely, SoA:n tarkkuus | Riskien arviointi, SoA-merkintä, peittämispolitiikka, muutostallenteet, sisäisen tarkastuksen tulokset |
| GDPR- tai tietosuojaviranomaisen arvioija | Sisäänrakennettu tietosuoja, minimointi, osoitusvelvollisuus | Käsittelyrekisteri, oikeusperuste, DPIA, pseudonymisointinäyttö, säilytyslogiikka |
| NIS2-arvioija | Turvallinen kehittäminen, poikkeamien ehkäisy, hallinnointi | Turvallisen kehityksen menettely, kehittäjäkoulutus, poikkeaman korjausnäyttö, kontrollin tehokkuuskatselmointi |
| DORA-asiakas tai -auditoija | ICT-toiminnan häiriönsietokyky ja kolmannen osapuolen riski | Kriittisen sovelluksen testausnäyttö, toimittajasopimuslausekkeet, poikkeamatilanteen tukivelvoitteet, palautus- ja exit-suunnittelu |
| NIST-tyyppinen tai COBIT 2019 -arvioija | Kontrollin suunnittelu, toiminta, omistajuus, seuranta | Kontrollin omistaja, mittarit, näyttötietovarasto, johdon raportointi, korjaavat toimenpiteet |
ISO/IEC 27001:2022 -auditoija aloittaa hallintajärjestelmän logiikasta. Kuuluuko henkilötietojen käsittely soveltamisalaan? Onko sidosryhmävaatimukset tunnistettu? Arvioidaanko tietosuojariskit määritettyjen kriteerien mukaisesti? Valitaanko kontrollit riskien käsittelyn kautta? Onko SoA tarkka? Kattavatko sisäiset tarkastukset ja johdon katselmoinnit henkilötietokontrollit?
Tietosuojan arvioija aloittaa osoitusvelvollisuudesta. Mitä henkilötietoja käsitellään? Mikä on oikeusperuste? Onko rekisteröityjä informoitu? Onko käsittely rajattu tiettyyn tarkoitukseen? Onko korkean riskin toimia arvioitu? Hallinnoidaanko käsittelijöitä?
NIS2-painotteinen arvioija aloittaa hallinnoinnista ja kyberturvallisuuden riskienhallinnasta. Hyväksyykö ja valvooko johto toimenpiteitä? Onko poikkeamien käsittely, jatkuvuus, toimittajaturvallisuus, pääsynhallinta, omaisuudenhallinta, turvallinen kehittäminen ja kontrollin tehokkuuden arviointi integroitu?
DORA-asiakas tai -auditoija kysyy, onko ICT-riskien hallinta dokumentoitu, hallituksen ohjaamaa, oikeasuhtaista ja sopimuksin tuettua. Jos henkilötietoja käsitellään rahoitusalan toimijoita tukevissa palveluissa, odotettavissa on kysymyksiä poikkeama-avusta, tietojen käsittelysijainneista, palautumisesta, auditointioikeuksista, palvelutasoista, työsuhteen päättämisestä tai palvelun päättämisestä sekä exitistä.
COBIT 2019- tai ISACA-tyyppinen arvioija testaa hallinnoinnin yhdenmukaisuutta. Kuka omistaa henkilötietoriskin? Mikä hallintoelin saa raportoinnin? Onko vastuut määritetty? Seurataanko toimittajia? Seurataanko poikkeamia? Käytetäänkö mittareita päätöksenteossa? Hyväksytäänkö jäännösriski muodollisesti?
Yksi näyttömalli voi täyttää kaikki nämä näkökulmat, mutta vain jos kontrollijärjestelmä suunnitellaan jäljitettäväksi alusta alkaen.
Yleiset auditointihavainnot henkilötietojen suojausohjelmissa
Organisaatiot, jotka lähestyvät ISO/IEC 27701:2025- tai ISO/IEC 29151:2022 -valmiutta ilman integroitua työkalupakkia, kohtaavat usein samat havainnot.
| Havainto | Miksi sillä on merkitystä | Clarysec-korjaus |
|---|---|---|
| Henkilötietoinventaario ei sisällä lokeja, varmuuskopioita, analytiikkavientejä tai tukiliitteitä | Piilossa olevia henkilötietoja ei voida suojata tai poistaa luotettavasti | Laajenna Step 9 -omaisuusluetteloa ja käsittelyrekisteriä kattamaan kaikki henkilötietojen sijainnit |
| Testiympäristöissä käytetään tuotantodataa | Aidot henkilötiedot altistuvat siellä, missä niitä ei tarvita | Sovella peittämispolitiikkaa ja hyväksyttyjä muunnosmalleja |
| Käyttöoikeuskatselmoinnit ovat yleisiä eivätkä keskity henkilötietovarastoihin | Liialliset käyttöoikeudet jäävät havaitsematta | Kartoita 5.18 käyttöoikeudet henkilötietoja sisältävien omaisuuserien omistajiin ja säännölliseen katselmointinäyttöön |
| Oikeusperuste on dokumentoitu, mutta sitä ei ole kytketty järjestelmiin tai säilytykseen | GDPR:n osoitusvelvollisuutta ei voida osoittaa | Lisää oikeusperuste- ja säilytyskentät käsittelyrekisteriin ja omaisuusluetteloon |
| Toimittajasopimuksista puuttuvat tietojen sijainti, poikkeama-apu, auditointioikeudet tai exit-ehdot | DORA-, NIS2- ja GDPR-toimittajavarmennukseen jää puutteita | Yhdenmukaista toimittajia koskeva due diligence ja sopimukset ICT-kolmansien osapuolten ja pilven hallinnoinnin kanssa |
| Poikkeamien pelikirjat eivät erota tietoturvapoikkeamia henkilötietojen tietoturvaloukkauksista | Raportointimääräajat voivat ylittyä | Rakenna luokittelupuut GDPR-, NIS2- ja DORA-raportointikynnyksille |
| Näyttö on hajallaan tiketeissä, levyasemilla, kuvakaappauksissa ja sähköposteissa | Auditointivalmius epäonnistuu, vaikka kontrollit toimisivat | Käytä keskitettyjä auditointikansioita ja näytön nimeämisstandardeja |
Nämä havainnot eivät ole paperityöongelmia. Ne ovat toimintamallin ongelmia. ISO/IEC 27701:2025 ja ISO/IEC 29151:2022 eivät korjaa niitä, ellei tietosuojan hallinnointia, tietoturvakontrolleja ja näytönhallintaa upoteta normaaleihin työnkulkuihin.
Mitä johdon tulisi kysyä ennen seuraavaa auditointia
Ennen ISO/IEC 27701:2025 -valmiuden, ISO/IEC 29151:2022 -toteutuksen tai GDPR-, NIS2- tai DORA-asiakasarvioinnin tavoittelua johdon tulee esittää kymmenen suoraa kysymystä:
- Onko meillä kattava rekisteri henkilötietojen käsittelytoimista, mukaan lukien tietoryhmät, tarkoitus, oikeusperuste ja säilytys?
- Onko henkilötietoja sisältävät omaisuuserät merkitty omaisuusluetteloon, mukaan lukien lokit, varmuuskopiot, viennit, analytiikkatyökalut ja tukiliitteet?
- Määritetäänkö tietoluokitukset luonti- tai käyttöönottohetkellä siten, että katselmoimattomien omaisuuserien oletusluokittelu on Luottamuksellinen?
- Voimmeko osoittaa, että pääsy henkilötietoihin on rajattu valtuutettuihin käyttäjiin, joilla on tarve tietää?
- Käyttävätkö kehitys-, testi- ja staging-ympäristöt peitettyä tai pseudonymisoitua dataa aitojen henkilötietojen sijasta?
- Onko peittämismallit hyväksytty ja avaimet suojattu, pääsynhallinnan piirissä ja lokitettu?
- Kytkeekö SoA henkilötietoriskit kontrolleihin ja sääntelyvelvoitteisiin?
- Katselmoidaanko pilvi- ja toimittajasopimukset tietojen sijainnin, turvallisuuden, poikkeamatuen, auditointioikeuksien, palautumisen ja exitin osalta?
- Pystyykö poikkeamaprosessimme luokittelemaan GDPR:n henkilötietojen tietoturvaloukkaukset, NIS2:n merkittävät poikkeamat ja DORA:n merkittävät ICT:hen liittyvät poikkeamat?
- Säilytetäänkö näyttö keskitetysti ja siten, että auditoija voi seurata sitä?
Jos vastaus yhteenkään näistä kysymyksistä on epäselvä, organisaatio ei ole vielä auditointivalmis.
Tee henkilötietojen suojauksesta todennettavaa
Sarahin myöhäisillan poikkeama olisi voinut muuttua pirstaleiseksi vaatimustenmukaisuuden hätätilanteeksi. Sen sijaan siitä voi tulla vahvemman toimintamallin lähtökohta: ISO/IEC 27001:2022 -standardin mukainen ISMS, joka laajennetaan tietosuojaan ISO/IEC 27701:2025 -standardilla, vahvistetaan ISO/IEC 29151:2022 -käytännöillä ja kartoitetaan GDPR-, NIS2-, DORA-, NIST-tyyppisten varmennusarviointien ja COBIT 2019 -hallinnointiodotuksiin.
Tämä on auditointivalmiin henkilötietojen suojauksen todellinen arvo. Se ei riipu oikean taulukon löytämisestä ennen auditoijan saapumista. Se perustuu järjestelmään, joka jo tietää, missä henkilötiedot ovat, miksi niitä on olemassa, miten ne suojataan, kuka on vastuussa, mitkä toimittajat ovat mukana ja missä näyttö sijaitsee.
Aloita Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint -kokonaisuudella toteutuksesi jäsentämiseksi. Käytä Zenith Controls: The Cross-Compliance Guide Zenith Controls -kokonaisuutta henkilötietojen suojauksen kartoittamiseen ISO/IEC 27001:2022-, GDPR-, NIS2-, DORA-, NIST-tyyppisten varmennusarviointien ja COBIT 2019 -hallinnointiodotusten välillä. Vie työ käytäntöön Clarysecin politiikoilla, mukaan lukien Data Protection and Privacy Policy Tietosuoja- ja yksityisyydensuojapolitiikka, Data Masking and Pseudonymization Policy Tietojen peittämisen ja pseudonymisoinnin politiikka, Data Classification and Labeling Policy Tiedon luokittelu- ja merkintäpolitiikka, Audit and Compliance Monitoring Policy Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - SME ja Information Security Policy Tietoturvapolitiikka.
Jos seuraava asiakasauditointisi, GDPR-katselmointisi, NIS2-valmiushankkeesi tai DORA-toimittaja-arviointisi lähestyy, älä odota tietoturvaloukkauksen paljastavan puutteita. Lataa Clarysecin työkalupakit, pyydä demo tai varaa henkilötietojen suojauksen arviointi ja rakenna tietosuojaohjelma, joka ei ole vain vaatimustenmukainen vaan myös puolustettavissa.
Frequently Asked Questions
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
