DPIA-arviointien hallinta ISO 27001-, NIS2- ja DORA-ympäristöissä

On torstai kello 17.40, ja nopeasti kasvavan fintech-yhtiön tietoturvajohtaja Mariaa pyydetään hyväksymään julkaisu ennen vuosineljänneksen päättymistä.

Tuoteorganisaatio pitää sitä läpimurtona: biometriseen maksutodennukseen ja käyttäytymisanalytiikkaan perustuvana ominaisuutena, joka sujuvoittaa asiakkaiden käyttökokemusta ja vähentää petoksia. Kehitystiimin mukaan uutta ydintietokantaa ei luoda. Myynnin mukaan säännelty finanssiasiakas odottaa toimitusta. Julkaisupäällikkö on jo merkinnyt tiketin vakiomuutokseksi.

Sitten tietosuojavastaava esittää kolme kysymystä.

Yhdistääkö ominaisuus biometrisiä tai käyttäytymistietoja tilin attribuutteihin? Vastaanottaako pilvipalvelun alikäsittelijä telemetriaa tai todennussignaaleja? Onko kukaan arvioinut, aiheuttaako muutos luonnollisille henkilöille korkean riskin?

Huone hiljenee.

Marialla on ISO/IEC 27001:2022 -riskirekisteri. Lakitiimillä on GDPR:n mukainen käsittelytoimien seloste. Hankinnalla on toimittajakysely. Pilvitiimillä on palveluntarjoajan tietoturvakatselmointi. Muutospäälliköllä on tiketti. Hallitukselle on juuri pidetty katsaus NIS2:n osoitusvelvollisuudesta ja DORA:n operatiivisen häiriönsietokyvyn odotuksista.

Mikään näistä kirjauksista ei yksin kerro koko tarinaa.

Tämä on vuoden 2026 DPIA-hallinnan ydinongelma. Tietosuojaa koskevat vaikutustenarvioinnit eivät voi jäädä odottamaan viranomaiskyselyä tietosuojakansioon. Niistä on tultava päätösaineistoa, joka yhdistää GDPR Article 25, 30, 32, 35 ja 36:n ISO/IEC 27001:2022 -riskienhallinnan näyttöön, NIS2:n kyberturvallisuusriskien hallintatoimenpiteisiin, DORA:n ICT-muutosten hallintaan, toimittajavarmennukseen ja hallitustason osoitusvelvollisuuteen.

Vaikeuksissa olevat organisaatiot eivät yleensä sivuuta vaatimustenmukaisuutta. Ne tekevät tietosuojakatselmoinnin, tietoturvakatselmoinnin, pilvipalvelukatselmoinnin ja muutoksen katselmoinnin erillisinä kokonaisuuksina. Onnistuvat organisaatiot luovat yhden jäljitettävän hallintatyönkulun, jossa DPIA-herätteet, riskien arviointi, toimittajien huolellisuusarviointi, kontrollikartoitus, testaus ja jäännösriskin hyväksyntä muodostavat yhden näyttöketjun.

Miksi siiloutuneet DPIA-arvioinnit epäonnistuvat vuonna 2026

GDPR toi DPIA:n muodolliseksi mekanismiksi sellaisen käsittelyn arviointiin, joka todennäköisesti aiheuttaa korkean riskin luonnollisille henkilöille. Monissa yrityksissä siitä tuli lakiasioiden tai tietosuojan tehtävä: lomake, joka täytettiin, kun projekti vaikutti arkaluonteiselta.

Tämä malli ei ole enää puolustettavissa.

Henkilötietojen käsittelyyn liittyvä muutos on harvoin pelkkä tietosuojatapahtuma. Se on myös:

• Tietoturvariskitapahtuma ISO/IEC 27001:2022 -standardin näkökulmasta.
• Kyberturvallisuuden hallintatapahtuma NIS2:n näkökulmasta, jos vaikutus kohdistuu verkko- ja tietojärjestelmiin, toimittajiin tai tietoturvakontrolleihin.
• ICT-muutokseen ja häiriönsietokykyyn liittyvä tapahtuma DORA:n näkökulmasta finanssialan toimijoille ja asiaankuuluville ICT-palveluntarjoajille.
• Toimittaja- ja pilviriskitapahtuma, kun mukana on käsittelijöitä, alikäsittelijöitä, ohjelmointirajapintoja, SDK-komponentteja tai isännöityjä palveluja.

Kun nämä arvioinnit tehdään erikseen, puutteista tulee vaarallisia. Tietosuojatiimi voi hyväksyä DPIA:n ymmärtämättä biometrisen SDK:n haavoittuvuuksia. IT-tiimi voi viedä muutoksen tuotantoon huomaamatta, että se koskee erityisiin henkilötietoryhmiin kuuluvia tietoja tai käyttäytymisen seurantaa. Tietoturvatiimi voi katselmoida pilvipalvelun yhdistämättä sitä DPIA:ssa tunnistettuihin luonnollisten henkilöiden oikeuksiin ja vapauksiin kohdistuviin riskeihin.

Ratkaisu ei ole lisädokumentointi. Ratkaisu on integroitu hallinta.

DPIA:ta tulee käsitellä herätteenä, joka käynnistää koordinoidun riskityönkulun tietosuojan, tietoturvan, pilvipalveluiden, toimittajien, kehityksen, lakiasioiden ja johdon välillä.

GDPR-perusta: DPIA-hallinta alkaa käsittelyn tuntemisesta

DPIA ei voi olla luotettava, jos organisaatio ei pysty selittämään, mitä se käsittelee, miksi se käsittelee sitä, kuka tiedot vastaanottaa ja kuinka kauan tietoja säilytetään.

GDPR:n osoitusvelvollisuus edellyttää enemmän kuin aikomuksen ilmaisua. Article 5 vahvistaa keskeiset periaatteet, kuten lainmukaisuuden, kohtuullisuuden, läpinäkyvyyden, käyttötarkoitussidonnaisuuden, tietojen minimoinnin, täsmällisyyden, säilytyksen rajoittamisen sekä eheyden ja luottamuksellisuuden. Se edellyttää myös, että rekisterinpitäjä osoittaa vaatimustenmukaisuuden. Article 25 edellyttää sisäänrakennettua ja oletusarvoista tietosuojaa. Article 30 edellyttää käsittelytoimien selosteita. Article 32 edellyttää käsittelyn turvallisuutta. Article 35 edellyttää DPIA:ta, kun käsittely todennäköisesti aiheuttaa korkean riskin. Article 36 edellyttää ennakkokuulemista, kun korkea riski jää ilman riittävää lieventämistä.

SaaS-, fintech-, pilvi- ja hallinnoitujen palvelujen organisaatioille tämä tarkoittaa, että jokainen olennainen muutos tulee seuloa tietosuojavaikutusten osalta. Heräte ei ole se, onko projekti nimetty ”tietosuojaprojektiksi”. Heräte on se, vaikuttaako muutos henkilötietoihin, käsittelyn tarkoitukseen, oikeusperusteeseen, vastaanottajiin, säilytykseen, käyttöoikeuksiin, toimittajiin, pilvisijainteihin tai jäännösriskiin.

Clarysecin Tietosuoja- ja yksityisyydensuojapolitiikka pk-yrityksille muuttaa tämän operatiiviseksi vaatimukseksi:

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

Osiosta ”Hallintavaatimukset”, politiikan lauseke 5.2.1.

Sama pk-yrityksen politiikka sisällyttää tietosuojan toimitukseen:

”Sisäänrakennettu ja oletusarvoinen tietosuoja tulee toteuttaa kaikissa uusissa järjestelmissä ja palveluissa.”

Osiosta ”Hallintavaatimukset”, politiikan lauseke 5.3.1.

Yritysympäristöissä Clarysecin Tietosuoja- ja yksityisyydensuojapolitiikka tekee DPIA-portista nimenomaisen:

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

Osiosta ”Hallintavaatimukset”, politiikan lauseke 5.6.

Tämä lauseke toimii siltana GDPR:n osoitusvelvollisuuden ja operatiivisen kontrollin välillä. Se siirtää DPIA:n oikeudellisesta jälkikäteisarvioinnista projektinhallintaan ja muutoksen hyväksyntään.

DPIA:n kytkeminen ISO/IEC 27001:2022 -riskienhallinnan näyttöön

ISO/IEC 27001:2022 tarjoaa hallintajärjestelmärakenteen, jota DPIA-hallinta tarvitsee.

Lausekkeet 4.1–4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmänsä, vaatimukset, ISMS:n soveltamisalan ja vuorovaikutteiset prosessit. Tietosuojalainsäädäntö, asiakassopimukset, NIS2-velvoitteet, DORA-vaatimukset, käsittelijän velvollisuudet ja toimittajariippuvuudet kuuluvat kaikki tähän kontekstiin.

Lausekkeet 5.1–5.3 edellyttävät johtajuutta, politiikkojen yhdenmukaisuutta, resursseja sekä rooleja ja vastuita. Tässä monet DPIA:t epäonnistuvat. DPO voi tunnistaa korkean riskin, mutta ilman riskinomistajia, eskalointisääntöjä ja johdon tukemia hyväksymiskriteerejä DPIA:sta tulee asiakirja päätöksen sijaan.

Lausekkeet 6.1.1–6.1.3 edellyttävät riskiperusteista suunnittelua, dokumentoitua tietoturvariskien arviointiprosessia, riskin hyväksymiskriteerejä, riskinomistajia, riskien käsittelyn suunnittelua, kontrollien valintaa, soveltuvuuslausuntoa ja jäännösriskin hyväksyntää. Tätä rakennetta DPIA:n tulee käyttää.

DPIA voi tunnistaa haittoja, kuten profilointiriskin, luvattoman paljastamisen, lainvastaisen toissijaisen käytön, identiteettipetoksen, syrjinnän tai liiallisen säilytyksen. ISMS muuntaa nämä haitat riskiskenaarioiksi, todennäköisyys- ja vaikutusanalyysiksi, riskienkäsittelytoimiksi, liite A:n kontrolleiksi ja jäännösriskin hyväksynnöiksi.

Clarysecin Riskienhallintapolitiikka pk-yrityksille määrittää vähimmäistason:

”Jokaisen riskimerkinnän tulee sisältää: kuvaus, todennäköisyys, vaikutus, pisteet, omistaja ja riskienkäsittelysuunnitelma.”

Osiosta ”Hallintavaatimukset”, politiikan lauseke 5.1.2.

Yritysympäristöissä Clarysecin Riskienhallintapolitiikka yhdistää riskien käsittelyn suunnittelun ISO/IEC 27001:2022 -näyttöön:

”Riskivastaavan tulee varmistaa, että käsittelytoimet ovat realistisia, aikarajoitettuja ja kartoitettu ISO/IEC 27001 liite A:n kontrolleihin.”

Osiosta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.4.2.

Zenith Blueprint: auditoijan 30 vaiheen tiekartta, Riskienhallinta-vaihe, vaihe 13, Riskien käsittelyn suunnittelu ja soveltuvuuslausunto, selittää SoA:n roolin selkeästi:

”SoA on käytännössä siltadokumentti: se yhdistää riskien arvioinnin ja riskien käsittelyn käytössä oleviin tosiasiallisiin kontrolleihin.”

Tämä on auditointivalmis DPIA-malli. DPIA-havainto ei saa päättyä toteamukseen ”riski hyväksytty”. Sen tulee kytkeytyä riskirekisteriin, riskienkäsittelysuunnitelmaan, soveltuvuuslausuntoon, toimittajakatselmointiin, pilvipalvelun huolellisuusarviointiin, muutostikettiin, testausnäyttöön ja johdon päätökseen.

Yksi päätösaineisto, useita vaatimustenmukaisuuden tuotoksia

Kypsä DPIA-hallintatyönkulku ei monista jokaista sääntelyvaatimusta. Se kerää näytön kerran ja hyödyntää sitä tarkoituksenmukaisesti uudelleen.

Tämä näyttöketju on suoraan yhdenmukainen ISO/IEC 27001:2022 Clause 8.1:n kanssa. Se edellyttää suunniteltuja ja hallittuja operatiivisia prosesseja, dokumentoitua näyttöä, suunniteltujen muutosten hallintaa ja tahattomien muutosten katselmointia. Clause 8.2 edellyttää riskien arviointeja suunnitelluin väliajoin tai silloin, kun merkittäviä muutoksia ehdotetaan tai tapahtuu. Clause 8.3 edellyttää riskienkäsittelysuunnitelman toteutusta. Clause 9 muuntaa näytön varmuudeksi seurannan, mittaamisen, sisäisen auditoinnin ja johdon katselmoinnin kautta.

Tietosuoja- ja yksityisyydensuojapolitiikka pk-yrityksille tekee ajoituksesta nimenomaisen:

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

Osiosta ”Riskienkäsittely ja poikkeukset”, politiikan lauseke 7.1.1.

Jos merkittävä henkilötietoihin kohdistuva muutos ei käynnistä DPIA-seulontaa ja ISMS:n uudelleenarviointia, hallintaprosessi on puutteellinen.

NIS2: DPIA-hallinnasta tulee johdon osoitusvelvollisuutta

NIS2 lisää hallintapainetta keskeisten ja tärkeiden toimialojen organisaatioissa. Sitä sovelletaan moniin julkisiin ja yksityisiin toimijoihin luetelluilla toimialoilla, kun olennaiset kokokynnykset täyttyvät. Tietyissä tapauksissa sitä voidaan soveltaa koosta riippumatta, esimerkiksi luottamuspalveluihin, DNS-palveluihin, TLD-rekistereihin, yleisiin sähköisiin viestintäpalveluihin, ainoisiin välttämättömän palvelun tarjoajiin tai toimijoihin, joilla on järjestelmäriskin kannalta merkittävä rooli.

DPIA-hallinnan kannalta keskeinen asia ei ole vain soveltamisala. Keskeistä on johdon vastuu.

NIS2 Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden hallintoelimet hyväksyvät kyberturvallisuusriskien hallintatoimenpiteet, valvovat niiden toteutusta ja osallistuvat koulutukseen. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, jotka perustuvat riskialtistukseen, kokoon, todennäköisyyteen, vakavuuteen, yhteiskunnalliseen ja taloudelliseen vaikutukseen, tekniikan tasoon ja olennaisiin standardeihin.

Article 21(2) sisältää osa-alueita, jotka ovat usein päällekkäisiä DPIA-tulosten kanssa, kuten:

• Riskianalyysi ja tietojärjestelmien turvallisuutta koskevat politiikat.
• Poikkeamien käsittely.
• Liiketoiminnan jatkuvuus ja kriisinhallinta.
• Toimitusketjun turvallisuus.
• Turvallisuus verkko- ja tietojärjestelmien hankinnassa, kehittämisessä ja ylläpidossa.
• Haavoittuvuuksien käsittely ja julkistaminen.
• Politiikat kyberturvallisuusriskien hallintatoimenpiteiden vaikuttavuuden arvioimiseksi.
• Kyberhygienia ja koulutus.
• Kryptografia ja salaus.
• Henkilöstöturvallisuus, pääsynhallinta ja omaisuudenhallinta.
• MFA, jatkuva todennus, suojattu viestintä ja suojattu hätäviestintä.

Uuden biometrisen, käyttäytymisanalytiikkaan perustuvan tai pilvipohjaisen käsittelytoimen DPIA:n tulee siksi esittää myös NIS2:n kannalta olennaisia kysymyksiä. Riippuuko käsittely uudesta toimittajasta? Tuoko se käyttöön uuden ohjelmointirajapinnan, SDK:n, identiteettivirran tai käyttöoikeusmallin? Muuttaako se poikkeaman vaikutusta? Edellyttääkö se salausta, vahvempaa lokitusta, turvallisen kehittämisen tarkistuksia tai johdon hyväksyntää?

Käytännön johdon kysymys on yksinkertainen: pystyykö organisaatio osoittamaan, että tietosuojavaikutteinen muutos käsiteltiin osana kyberturvallisuusriskien hallintaa ennen toteutusta?

Tämän näytön tulee näkyä DPIA-aloituskirjauksessa, päivitetyssä käsittelyrekisterissä, riskirekisterissä, riskienkäsittelysuunnitelmassa, soveltuvuuslausunnossa, toimittajien huolellisuusarvioinnissa, tietoturvatestauksen näytössä, muutoksen hyväksynnässä ja jäännösriskin hyväksynnässä.

DORA: ICT-muutosta ja kolmansia osapuolia koskevaa näyttöä ei voi ohittaa

DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se luo EU:hun yhtenäisen viitekehyksen ICT-riskien hallinnalle, merkittävien ICT:hen liittyvien poikkeamien raportoinnille, digitaalisen operatiivisen häiriönsietokyvyn testaukselle, kyberuhkia ja haavoittuvuuksia koskevan tiedon jakamiselle, kolmansien osapuolten aiheuttamien ICT-riskien hallinnalle sekä kriittisten ICT-palveluntarjoajina toimivien kolmansien osapuolten valvonnalle.

Finanssialan toimijoille DORA toimii yleensä ICT-riskien hallinnan ja poikkeamaraportointivelvoitteiden alakohtaisena unionin säädöksenä, kun taas NIS2 on edelleen merkityksellinen laajemman ekosysteemikoordinoinnin ja muiden kuin DORA-toimijoiden kannalta.

DPIA-hallinta on DORA:n näkökulmasta tärkeää, koska henkilötietojen käsittely tapahtuu yleensä ICT-järjestelmissä, kolmannen osapuolen palveluissa, pilviympäristöissä ja operatiivisissa työnkuluissa.

DORA Article 5 edellyttää sisäisiä hallinto- ja kontrolliviitekehyksiä ICT-riskien hallintaan sekä hallintoelimen vastuuta. Article 6 edellyttää dokumentoitua ICT-riskienhallinnan viitekehystä, joka on integroitu kokonaisriskienhallintaan. Articles 8 to 14 kattavat omaisuuden ja riippuvuuksien tunnistamisen, suojaamisen ja ennaltaehkäisyn, havaitsemisen, jatkuvuuden, varmuuskopioinnin, palautumisen, opit ja kriisiviestinnän.

DORA Article 28 edellyttää, että finanssialan toimijat hallitsevat kolmansien osapuolten aiheuttamia ICT-riskejä olennaisena osana ICT-riskien hallintaa ja säilyttävät vastuun käyttäessään ICT-palveluja. Se edellyttää ICT-palvelusopimusrekistereitä, sopimusta edeltäviä arviointeja, huolellisuusarviointia, keskittymäriskin arviointia, auditointi- ja tarkastussuunnittelua, irtisanomisoikeuksia ja exit-strategioita. Article 30 edellyttää kirjallisia sopimuksia, joissa määritellään selkeät palvelukuvaukset, tietojen sijainnit, luottamuksellisuuden, eheyden ja saatavuuden suojaukset, tietojen palautus ja palauttaminen, poikkeamatuki, yhteistyö viranomaisten kanssa, irtisanomisoikeudet sekä lisäsuojatoimet kriittisille tai tärkeille toiminnoille.

DPIA:n osalta tämä muuttaa toimittajakysymystä. ”Onko meillä tietojenkäsittelysopimus?” ei riitä. Parempi kysymys on: pystymmekö osoittamaan, että ICT-riippuvuus, tietojen sijainti, alihankinta, tietoturvastandardit, häiriönsietokyky, auditointioikeudet, poikkeamatuki ja exit-strategia arvioitiin ennen käsittelyn hyväksymistä?

Clarysecin Pilvipalvelujen käyttöpolitiikka tekee tästä käyttöönottoa edeltävästä kontrollista nimenomaisen:

”Kaiken pilvipalvelujen käytön tulee läpäistä riskiperusteinen huolellisuusarviointi ennen käyttöönottoa, mukaan lukien palveluntarjoajan arviointi, laki- ja sääntelyvaatimusten noudattamisen validointi sekä kontrollien validointikatselmoinnit.”

Osiosta ”Hallintavaatimukset”, politiikan lauseke 5.2.

DPIA:n ei tule hyväksyä uutta analytiikkakäsittelijää, identiteetintarjoajaa, biometristä SDK:ta tai pilvipohjaista telemetria-alustaa, ellei pilvipalvelun huolellisuusarviointia, oikeudellista validointia ja kontrollien validointia ole tehty tai ellei niitä ole nimenomaisesti seurattu riskienkäsittelytoimina.

ISO/IEC 27002:2022 -ankkurit: tietosuoja, projektit ja muutos

Clarysecin Zenith Controls: ristiin sovellettavan vaatimustenmukaisuuden opas käsittelee ISO/IEC 27002:2022 -kontrolleja ristiin sovellettavan vaatimustenmukaisuuden ankkureina. DPIA-hallinnassa kolme kontrollia on erityisen tärkeitä.

Zenith Controls -oppaan merkintä 5.34, Yksityisyydensuoja ja henkilötietojen suojaaminen, luokittelee sen ennaltaehkäiseväksi kontrolliksi, joka liittyy luottamuksellisuuteen, eheyteen ja saatavuuteen, on yhdenmukainen Identify- ja Protect-kyberturvallisuuskäsitteiden kanssa sekä kytkeytyy tietojen suojaamiseen ja laki- ja vaatimustenmukaisuuskyvykkyyksiin.

Zenith Blueprint, Controls in Action -vaihe, vaihe 23, tekee käytännön huomion:

”Tämän kontrollin perusta on tietojen tunteminen. Organisaation on tiedettävä, mitä henkilötietoja se kerää, missä ne sijaitsevat, miksi niitä käsitellään ja kuka voi käyttää niitä.”

Zenith Controls -oppaan merkintä 5.8, Tietoturvallisuus projektinhallinnassa, luokittelee sen ennaltaehkäiseväksi kontrolliksi, joka liittyy luottamuksellisuuteen, eheyteen ja saatavuuteen, on yhdenmukainen Identify- ja Protect-alueiden kanssa ja sijoittuu hallinnan, ekosysteemin ja suojausalueiden välille.

Zenith Blueprint, Controls in Action -vaihe, vaihe 22, toteaa:

”Tämän kontrollin tavoitteena ei ole kuormittaa projekteja byrokratialla. Tavoitteena on varmistaa, että tietoturvaa käsitellään suunnittelun lähtötietona, ei testausvaiheena.”

Tietosuojaa tulee käsitellä samalla tavalla. Tuotantokäyttöönoton jälkeen tehty DPIA on usein vahinkoraportti. Suunnitteluvaiheen DPIA on riskien ennaltaehkäisyä.

Zenith Controls -oppaan merkintä 8.32, Muutoksenhallinta, luokittelee sen ennaltaehkäiseväksi kontrolliksi, joka liittyy luottamuksellisuuteen, eheyteen ja saatavuuteen, on yhdenmukainen Protect-alueen kanssa ja kytkeytyy sovellusturvallisuuteen sekä järjestelmä- ja verkkoturvallisuuskyvykkyyksiin.

Zenith Blueprint, Controls in Action -vaihe, vaihe 21, on suoraviivainen:

”Muutos on väistämätöntä, mutta kyberturvallisuudessa hallitsematon muutos on vaarallinen.”

Clarysecin Muutoksenhallintapolitiikka pk-yrityksille kuvaa herätteen:

”Jos muutos koskee arkaluonteisia tietoja, järjestelmien käyttöoikeuksia tai ulkoisia integraatioita, tietoturvavaikutusten katselmointi on pakollinen. Nimetyn tietoturva- tai vaatimustenmukaisuusyhteyshenkilön tulee arvioida, tuoko muutos mukanaan lisäriskejä, ja suositella lisäsuojatoimia.”

Osiosta ”Riskienkäsittely ja poikkeukset”, politiikan lauseke 7.5.1.

Yritysympäristöissä Clarysecin Muutoksenhallintapolitiikka asettaa CAB-odotuksen:

”Arvioi muutokset tietoturva- ja vaatimustenmukaisuusriskejä vasten ennen muutoshallintalautakunnan hyväksyntää.”

Osiosta ”Roolit ja vastuut”, politiikan lauseke 4.6.1.

Käytännön esimerkki: biometrisen analytiikkaominaisuuden hyväksyminen

Maria ei tarvitse kolmea erillistä hallintaprojektia. Hän tarvitsee yhden integroidun projektin aloitus- ja riskityönkulun.

Tuotetiimi ehdottaa biometristä maksutodennusta käyttäytymisanalytiikalla. Ominaisuus kerää biometrisiä malleja, laitteen metatietoja, tilin attribuutteja, IP-osoitteita, todennustapahtumia ja petossignaaleja. Se käyttää pilvianalytiikan palveluntarjoajaa ja kolmannen osapuolen biometristä SDK:ta. Asiakkuustiimit saavat pääsyn koontitasoiseen hallintanäkymään.

Muutostiketin tulee käynnistää DPIA-seulonta ja riskien arviointi ennen resurssien allokointia tai CAB-hyväksyntää.

Integroidun arvioinnin tulee tämän jälkeen tuottaa yksi riskiaineisto.

Esimerkkiriskimerkinnät voisivat näyttää tältä:

Ennen julkaisua muutoskirjauksen tulee sisältää DPIA:n valmistuminen tai DPO:n hyväksymä riskienkäsittelysuunnitelma, päivitetty käsittelyrekisteri, toimittajan ja pilvipalvelun huolellisuusarviointi, tietoturvavaikutusten katselmointi, testitulokset, palautussuunnitelma, seurantasuunnitelma ja jäännösriskin hyväksyntä.

Julkaisun jälkeen omistajan tulee tarkistaa lokit, hälytykset, käyttöoikeusroolit, hallintanäkymät, säilytyssäännöt ja poistotyönkulut. Tämä sulkee suunnitellun muutoksen silmukan ISO/IEC 27001:2022 Clause 8.1:n mukaisesti ja tukee DORA-tyyppistä operatiivisen häiriönsietokyvyn kurinalaisuutta.

Mitä auditoijat kysyvät

Yhtenäinen DPIA antaa eri auditoijille yhden johdonmukaisen näyttöketjun.

NIST CSF 2.0 on hyödyllinen viestintäkerros, koska sen GOVERN-toiminto nostaa strategian, odotukset, politiikan, roolit, valvonnan ja toimitusketjun riskienhallinnan keskiöön. COBIT 2019 lisää prosessivarmennuksen erityisesti rakenteiseen muutoksen mahdollistamiseen, vaikutusanalyysiin, hyväksyntöihin, testaukseen ja muutoksen jälkeiseen arviointiin.

GDPR-viranomainen voi aloittaa yksilön oikeuksista ja vapauksista. ISO-auditoija voi aloittaa dokumentoidusta riskien arvioinnista ja kontrollien toteutuksesta. DORA-katselmoija voi aloittaa ICT-riippuvuudesta ja häiriönsietokyvystä. NIS2-katselmoija voi aloittaa johdon valvonnasta ja oikeasuhtaisista kyberturvallisuustoimenpiteistä.

Saman DPIA-näyttöketjun tulee palvella niitä kaikkia.

DPIA-päätösten tulee kestää poikkeamatilanteet

DPIA ei ole vain julkaisua edeltävä hyväksyntäartefakti. Sen tulee parantaa valmiutta henkilötietojen tietoturvaloukkauksiin ja tietoturvapoikkeamiin.

GDPR määrittää henkilötietojen tietoturvaloukkauksen tietoturvaloukkaukseksi, joka johtaa henkilötietojen vahingossa tapahtuvaan tai lainvastaiseen tuhoamiseen, häviämiseen, muuttamiseen, luvattomaan luovuttamiseen tai niihin pääsyyn. NIS2 edellyttää merkittävistä poikkeamista ilmoittamista ilman aiheetonta viivytystä, mukaan lukien varhaisvaroitus 24 tunnin kuluessa, ilmoitus 72 tunnin kuluessa ja loppuraportti viimeistään kuukauden kuluttua poikkeamailmoituksesta. DORA edellyttää, että finanssialan toimijat havaitsevat, hallitsevat, kirjaavat lokiin, luokittelevat, eskaloivat ja ilmoittavat merkittävistä ICT:hen liittyvistä poikkeamista alku-, väli- ja loppuraportoinnin kautta sekä ilmoittavat asiakkaille, kun taloudelliset edut voivat vaarantua.

Jos DPIA on kirjannut tietovirrat, käsittelijät, pääsynhallintakontrollit, säilytyksen, lokituksen, salauksen, pseudonymisoinnin ja poikkeamavastuut, poikkeamatiimi pystyy vastaamaan kriittisiin kysymyksiin nopeammin. Mitä henkilötietoja oli mukana? Mihin järjestelmiin ja toimittajiin vaikutus kohdistui? Keihin henkilöihin tai asiakkaisiin vaikutus voi kohdistua? Oliko salaus käytössä? Mitkä lokit ovat saatavilla? Mitkä raportointiajat soveltuvat? Mitä asiakas- tai viranomaisviestintää edellytetään?

Tästä syystä DPIA-hallinta tulee kytkeä ISO/IEC 27001:2022:n poikkeamakontrolleihin, liiketoiminnan jatkuvuuden kontrolleihin ja ICT-valmiuskontrolleihin sekä NIS2:n ja DORA:n poikkeaman elinkaarta koskeviin odotuksiin.

Yleiset DPIA-hallinnan epäonnistumiset

Epäonnistumiset johtuvat yleensä irti toisistaan olevista työnkuluista, eivät työn puutteesta.

DPIA-hallinnan tarkistuslista

Käytä tätä tarkistuslistaa integroidaksesi DPIA:t ISMS:ään, NIS2-valmiuteen ja DORA:n ICT-muutosten hallintaan.

Tämä ei ole byrokratiaa. Se on operatiivista osoitusvelvollisuutta. Se auttaa tietoturvajohtajaa osoittamaan, että tietoturva huomioitiin, DPO:ta osoittamaan, että tietosuojariski arvioitiin, vaatimustenmukaisuuspäällikköä osoittamaan, että kontrollit on kartoitettu viitekehysten välillä, ja liiketoimintavastaavaa osoittamaan, että innovaatio hallittiin vastuullisesti.

Miten Clarysec auttaa

Clarysecin lähestymistapa on suunniteltu organisaatioille, jotka kohtaavat päällekkäisiä vuoden 2026 velvoitteita ja hajanaista näyttöä.

Politiikkatyökalupakki antaa hallinnan kielen. Tietosuoja- ja yksityisyydensuojapolitiikka määrittää, milloin DPIA:t vaaditaan ja kuka ne katselmoi. Riskienhallintapolitiikka määrittää, miten riskimerkinnät tulee jäsentää ja kartoittaa. Muutoksenhallintapolitiikka varmistaa, että tietosuoja- ja tietoturvavaikutukset arvioidaan ennen hyväksyntää. Pilvipalvelujen käyttöpolitiikka edellyttää huolellisuusarviointia ennen pilvipalvelun käyttöönottoa.

Zenith Blueprint antaa toteutuksen tiekartan. Vaihe 13 muuttaa riskien käsittelyn ja soveltuvuuslausunnon ristiin sovellettavan vaatimustenmukaisuuden sillaksi. Vaihe 22 sisällyttää tietoturvan projektinhallintaan. Vaihe 21 tekee muutoksesta tarkoituksellisen, perustellun ja auditoitavissa olevan. Vaihe 23 muuttaa henkilötietojen suojan elinkaarikontrolliksi, joka perustuu tietojen tuntemiseen, lainmukaiseen käyttöön, pääsyn rajoittamiseen, toimittajien valvontaan ja operatiivisiin tietosuojaprosesseihin.

Zenith Controls -opas antaa ristiin sovellettavan vaatimustenmukaisuuden kompassin. DPIA-hallinnassa ISO/IEC 27002:2022 -kontrollit 5.34, 5.8 ja 8.32 yhdistävät tietosuojan, projektien hallinnan ja muutoksenhallinnan GDPR:n osoitusvelvollisuuteen, NIS2:n kyberturvallisuustoimenpiteisiin, DORA:n ICT-riskien hallintaan, NIST CSF -tuloksiin ja COBIT 2019 -varmennukseen.

Jos organisaatiosi valmistautuu GDPR:n osoitusvelvollisuuskatselmointeihin, ISO/IEC 27001:2022 -sertifiointiin, NIS2-valmiuteen tai DORA:n operatiiviseen häiriönsietokykyyn, aloita integroimalla DPIA-herätteet projektien ja muutosten aloitukseen. Kytke DPIA-havainnot riskirekisteriin. Kartoita käsittelytoimet SoA:ssa. Validoi toimittajat ja pilvipalvelut ennen käyttöönottoa. Säilytä yksi päätösaineisto, jota johto, auditoijat ja viranomaiset voivat seurata.

Paras DPIA ei ole se, joka kirjoitetaan viranomaisen pyydettyä sitä. Paras DPIA on se, joka muotoili järjestelmää ennen kuin asiakkaat, auditoijat tai poikkeamat testasivat sitä.

Katselmoi nykyinen DPIA-prosessisi Clarysecin politiikkatyökalupakkia vasten, käytä Zenith Blueprint -opasta auditointivalmiin jäljitettävyyden rakentamiseen ja käytä Zenith Controls -opasta yhden kontrolliviitekehyksen kartoittamiseen GDPR:n, ISO/IEC 27001:2022:n, NIS2:n, DORA:n, NIST CSF:n ja COBIT 2019:n välillä. Muuta sitten seuraava tietosuojavaikutteinen muutos hallituksi, näyttöön perustuvaksi julkaisupäätökseksi viime hetken vaatimustenmukaisuuspaniikin sijaan.