DSAR, tietojen poistaminen ja ISO 27001 -auditointinäyttö vuonna 2026

Sähköposti saapui Sarahin postilaatikkoon klo 9.03.
Se ei ollut ensimmäinen Data Subject Access Request, jonka hänen nopeasti kasvava SaaS-yrityksensä oli saanut. Se oli ensimmäinen, joka tuntui julkiselta auditoinnilta.
Lähettäjä oli entinen työntekijä, nykyinen tietosuoja-aktivisti. Pyynnössä viitattiin GDPR:n artikloihin numeroittain ja vaadittiin kaikkia henkilötietoja, käsittelyn välitöntä rajoittamista, luetteloa kaikista kolmannen osapuolen palveluista, joissa hänen tietojaan säilytetään, sekä todennettavaa näyttöä tietojen poistamisesta tuotanto- ja varmuuskopiointijärjestelmistä. Kopiossa oli toimittaja.
Muutamassa minuutissa puutteet tulivat näkyviin. Ohjelmistokehitys varoitti, että monivuokraajaympäristön tietokannasta tehtävä ”varsinainen poistaminen” voisi vaikuttaa muihin asiakkaisiin. Markkinointi selvitteli käyttäjätietoja analytiikka-alustoilta. Lakiasiat löysi ratkaisemattoman työsuhdeasian. Tietoturva oli huolissaan siitä, että lokit voisivat paljastaa havaitsemislogiikkaa tai toisen henkilön tietoja. Asiakastuki löysi tallenteita kahden sähköpostiosoitteen alta. Taloushallinnolla oli laskuja kolmannen osoitteen alla.
Kello oli jo alkanut käydä.
Tämä tilanne ei ole enää poikkeuksellinen. Rekisteröidyn oikeudet vuonna 2026 eivät ole pelkkä tietosuojapostilaatikon asia. Ne muodostavat kontrolloidun liiketoimintaprosessin, joka perustuu omaisuusluetteloihin, oikeusperustetta koskeviin päätöksiin, identiteetin varmentamiseen, pääsynhallintaan, säilytyssääntöihin, oikeudellisiin säilytysvelvoitteisiin, toimittajakoordinointiin, turvalliseen luovuttamiseen, poistamista koskevaan näyttöön ja auditointivalmiiseen lokitukseen.
GDPR määrittää, mitä oikeuksia henkilöillä on. ISO/IEC 27001:2022 antaa tietoturva- ja vaatimustenmukaisuustiimeille hallintajärjestelmän kurinalaisuuden, jolla voidaan osoittaa, että nämä oikeudet käsitellään johdonmukaisesti, turvallisesti ja toistettavasti.
Tietoturvajohtajille, vaatimustenmukaisuuspäälliköille, tietosuojavastaaville ja liiketoimintavastaaville tavoite ei ole tuottaa lisää paperityötä. Tavoitteena on rakentaa yksi luotettava DSAR-, poisto- ja rajoittamistyönkulku, joka tuottaa GDPR:n, ISO/IEC 27001:2022 -auditointien sekä NIS2:n, DORA:n, NIST CSF 2.0:n ja COBIT 2019:n mukaisten laajempien varmentamisodotusten edellyttämän auditointinäytön.
Miksi ad hoc -DSAR-käsittely pettää paineen alla
Useimmat DSAR-epäonnistumiset eivät johdu huonoista aikomuksista. Ne johtuvat pirstaleisuudesta.
Organisaatiolla voi olla tietosuojaseloste, tietosuojavastaavan postilaatikko ja GDPR-lauseke toimittajasopimuksissa, mutta se voi silti kamppailla perusluonteisten operatiivisten kysymysten kanssa:
- Kuka varmentaa pyynnön esittäjän identiteetin?
- Mikä oikeushenkilö toimii rekisterinpitäjänä tai henkilötietojen käsittelijänä?
- Mitkä järjestelmät on haettava?
- Kuka omistaa kunkin järjestelmän?
- Mitkä tiedot kuuluvat soveltamisalaan?
- Mitkä tiedot on peitettävä ennen luovuttamista?
- Mitä tietoja ei voida poistaa verotuksen, auditoinnin, oikeudenkäynnin, petostentorjunnan tai lakisääteisen velvoitteen vuoksi?
- Miten käsittelyn rajoittaminen toteutetaan teknisesti?
- Minkä toimittajien on tuettava hakua, vientiä, poistamista tai rajoittamista?
- Mikä näyttö osoittaa, että pyyntö käsiteltiin määräajassa?
- Mitä tapahtuu, jos DSAR paljastaa henkilötietojen tietoturvaloukkauksen?
GDPR Article 5 edellyttää, että henkilötietoja käsitellään lainmukaisesti, kohtuullisesti ja läpinäkyvästi, että ne kerätään määriteltyihin tarkoituksiin, rajoitetaan tarpeelliseen, pidetään täsmällisinä, säilytetään enintään tarpeellisen ajan ja suojataan asianmukaisilla teknisillä ja organisatorisilla toimenpiteillä. Article 5(2) tekee osoitusvelvollisuudesta nimenomaisen: rekisterinpitäjän on pystyttävä osoittamaan vaatimustenmukaisuus. Article 4 määrittelee käsittelyn laajasti, mukaan lukien kerääminen, säilyttäminen, käyttö, luovuttaminen, rajoittaminen, poistaminen ja tuhoaminen.
Tämä tarkoittaa, että DSAR-prosessi itsessään on käsittelytoimi. Sitä on kontrolloitava.
GDPR Article 3 on tärkeä myös EU:n ulkopuolisille pilvi-, SaaS-, fintech- ja digitaalisille yrityksille. Jos tarjoatte tavaroita tai palveluja unionissa oleville henkilöille, seuraatte heidän käyttäytymistään tai käsittelette henkilötietoja EU:ssa sijaitsevan toimipaikan yhteydessä, GDPR voi soveltua myös silloin, kun toiminta on ulkoistettu tai infrastruktuuri on globaali.
ISO/IEC 27001:2022 tuo tähän todellisuuteen rakenteen. Lausekkeet 4.1–4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmät, vaatimukset, ISMS:n soveltamisalan ja keskenään vuorovaikutuksessa olevat prosessit. Rekisteröity on sidosryhmä. GDPR-oikeudet ovat vaatimuksia. SaaS-sovellukset, identiteetintarjoajat, analytiikka-alustat, tukityökalut, tietovarastot ja pilvivarmuuskopiot ovat vuorovaikutuksessa olevia prosesseja. DSAR-työnkulun paikka on ISMS:n sisällä, ei sen vieressä.
Kolme rekisteröidyn oikeutta, jotka aiheuttavat eniten painetta
Pääsy tietoihin, tietojen poistaminen ja käsittelyn rajoittaminen paljastavat suurimman kuilun oikeudellisen lupauksen ja operatiivisen kyvykkyyden välillä.
| Oikeus | GDPR-painopiste | Operatiivinen kysymys | Yleinen epäonnistuminen | Auditoinnissa odotettu näyttö |
|---|---|---|---|---|
| Pääsypyyntö tai DSAR | Article 15 | Pystymmekö paikantamaan, katselmoimaan ja luovuttamaan pyynnön esittäjän henkilötiedot turvallisesti? | Puutteellinen järjestelmähaku, heikko identiteetin varmentaminen tai kolmannen osapuolen tietojen tahaton luovutus | Vastaanottokirjaus, identiteetin validointi, järjestelmähakujen loki, peittämistä koskeva kirjaus, hyväksyntä, vastauskopio, sulkemisnäyttö |
| Poistopyyntö | Article 17 | Pystymmekö poistamaan henkilötiedot silloin, kun sitä vaaditaan, ja samalla säilyttämään tiedot, jotka on lain mukaan säilytettävä? | Liian laaja poistaminen, liian vähäinen poistaminen, varmuuskopioiden sivuuttaminen tai poikkeusten kirjaamatta jättäminen | Poistamispäätös, oikeusperusteen analyysi, poistotiketit, järjestelmävahvistukset, varmuuskopioiden käsittely, oikeudellisen säilytysvelvoitteen tarkastukset |
| Käsittelyn rajoittamispyyntö | Article 18 | Pystymmekö lopettamaan aktiivisen käsittelyn vaarantamatta liiketoimintaa, turvallisuutta tai lakisääteisiä velvoitteita? | Ei teknistä menetelmää rajoitettujen tietueiden merkitsemiseen SaaS-työkaluissa ja dataputkissa | Rajoitusmerkintä, käyttöoikeusmuutokset, eston näyttö, poikkeusrekisteri, määräaikainen katselmointi |
GDPR Article 6 on tämän päätöslogiikan ytimessä. Ette voi käsitellä, säilyttää tai luovuttaa henkilötietoja tai kieltäytyä poistamisesta ymmärtämättä oikeusperustetta. Article 9 nostaa vaatimustasoa erityisiin henkilötietoryhmiin, kuten terveystietoihin, yksilölliseen tunnistamiseen käytettäviin biometrisiin tietoihin tai arkaluonteisia ominaisuuksia paljastaviin tietoihin. Vuoden 2026 SaaS-ympäristössä tämä voi vaikuttaa perehdytykseen, identiteetin varmentamiseen, petosseurantaan, asiakastuen liitteisiin ja työntekijätietoihin.
Clarysecin yritystason Tietosuoja- ja yksityisyydensuojapolitiikka [P17] jäsentää velvoitteen suoraan. Tavoitteet-kohdan lausekkeessa 3.6 se edellyttää organisaatiolta seuraavaa:
Ylläpidetään rekisteröidyn oikeuksia, mukaan lukien pääsy tietoihin, oikaisu, poistaminen, rajoittaminen, siirrettävyys, vastustaminen ja suoja automatisoidulta päätöksenteolta.
Tavoitteesta tulee auditoitavissa oleva vasta, kun se on kytketty omistajiin, rekistereihin, työnkulkuihin, kontrolleihin ja näyttöön.
Aloita siitä, mistä auditoijat aloittavat: soveltamisala, sidosryhmät ja omistajuus
Zenith Blueprint: auditoijan 30-vaiheinen tiekartta [ZB] -materiaalissa ISMS:n perustaa ja johtajuutta koskevan vaiheen vaihe 2 keskittyy sidosryhmien tarpeisiin ja ISMS:n soveltamisalaan. GDPR:n osalta Blueprint tunnistaa viranomaisten odotukset seuraavasti:
EU:n viranomaiset
(GDPR)Henkilötietojen lainmukainen
käsittely, loukkauksista ilmoittaminen 72 tunnissa,
rekisteröidyn oikeudetNimeä tietosuojavastaava, luo
loukkauksiin reagoinnin prosessi sekä menettelyt
tietopyyntöjen käsittelyyn.
Tämä on oikea lähtökohta. Ennen tikettien automatisointia tai portaalien konfigurointia määritelkää rekisteröidyn oikeuksien käsittelyn soveltamisala:
- Mitkä oikeushenkilöt toimivat rekisterinpitäjänä, yhteisrekisterinpitäjänä tai henkilötietojen käsittelijänä?
- Mitkä tuotteet, palvelut ja alueet kuuluvat soveltamisalaan?
- Mitä rekisteröityjen ryhmiä on olemassa, kuten asiakkaat, työntekijät, kokeilukäyttäjät, prospektit, toimittajat, verkkosivuston kävijät tai sovelluksen käyttäjät?
- Mitkä järjestelmät, tietovarastot ja toimittajat sisältävät henkilötietoja?
- Mitkä roolit hyväksyvät luovuttamisen, hylkäämisen, poistamisen, rajoittamisen tai eskaloinnin?
- Mitkä mittarit raportoidaan johdolle?
ISO/IEC 27001:2022 -lausekkeet 5.1–5.3 edellyttävät johtajuutta, politiikan yhdenmukaisuutta, resursseja ja osoitettuja vastuita. Tämä vastaa suoraan GDPR:n osoitusvelvollisuutta.
Tietosuoja- ja yksityisyydensuojapolitiikka [P17], politiikan toteutusvaatimusten lauseke 6.4.1, toteaa:
Tietosuojavastaavan (DPO) on ylläpidettävä dokumentoituja prosesseja rekisteröidyn pyyntöjen (DSR) vastaanottamista, validointia, seurantaa ja niihin vastaamista varten.
Pk-yrityksille Clarysecin Tietosuoja- ja yksityisyydensuojapolitiikka – SME [P17S] käyttää tarkoituksenmukaisesti mitoitettua omistajuutta. Hallintavaatimusten lauseke 5.2.1 toteaa:
Tietosuojakoordinaattorin on ylläpidettävä rekisteriä kaikista henkilötietojen käsittelytoimista, mukaan lukien tietoryhmät, tarkoitus, oikeusperuste ja säilytysajat.
Tämä käsittelyrekisteri on DSAR-valmiuden operatiivinen ydin. Jos se on puutteellinen, DSAR-tiimi hakee tietoja muistin, Slack-viestien ja hiljaisen tiedon perusteella. Jos se on täsmällinen, tiimi hakee tietoja käsittelytoimen, tietoryhmän, järjestelmäomistajan, toimittajan ja säilytyssäännön perusteella.
Clarysecin DSAR-työnkulku: vastaanotosta sulkemiseen
Auditointivalmiin DSAR-työnkulun tulee olla riittävän yksinkertainen paineen alla suoritettavaksi, mutta riittävän kontrolloitu kestääkseen viranomaisen, asiakkaan varmentamiskatselmuksen tai ISO/IEC 27001:2022 -auditoinnin.
1. Vastaanotto ja kuittaus
Pyyntöjen tulee saapua kontrolloidun kanavan kautta, kuten tietosuojapostilaatikkoon, portaaliin, tukilomakkeelle tai lakiasioiden vastaanottojonoon. Henkilöstön on tunnistettava luonnollisella kielellä esitetyt pyynnöt. Henkilön ei tarvitse kirjoittaa ”DSAR” käyttääkseen oikeuttaan. ”Mitä tietoja teillä on minusta?” tai ”poistakaa profiilini” voi riittää käynnistämään työnkulun.
Tietosuoja- ja yksityisyydensuojapolitiikka – SME [P17S], politiikan toteutusvaatimusten lauseke 6.5.2, asettaa selkeän palvelutason:
Tietosuojakoordinaattorin on kuitattava pyynnöt 3 työpäivän kuluessa ja vastattava 30 päivän kuluessa.
Kuittauksen tulee sisältää pyynnön viite, tarvittaessa soveltamisalan täsmennys, identiteetin varmentamisohjeet ja odotettu vastausaika.
2. Identiteetin varmentaminen ja toimivallan tarkastus
DSAR voi muuttua henkilötietojen tietoturvaloukkaukseksi, jos tiedot lähetetään väärälle henkilölle. Varmentamisen tulee olla oikeasuhtaista eikä sen tule kerätä tarpeettomasti uusia henkilötietoja. Käyttäkää todennettuja portaaleja aina kun mahdollista. Entisten käyttäjien osalta validoikaa tiedot tunnettujen tilitietojen perusteella. Työntekijöiden osalta koordinoikaa HR:n kanssa. Edustajien osalta edellyttäkää näyttöä toimivallasta.
Säilyttäkää näyttö varmentamismenetelmästä, valmistumispäivästä, hyväksyjästä, mahdollisista pyydetyistä lisätiedoista ja päätöksestä, jos varmentaminen epäonnistuu.
3. Luokittele pyyntö
Yksi viesti voi sisältää useita oikeuksia. Luokittele kukin oikeus erikseen, koska pääsy tietoihin, poistaminen, rajoittaminen, vastustaminen ja siirrettävyys edellyttävät erilaista päätöslogiikkaa ja näyttöä. Merkitse myös mahdolliset valitukset, työntekijäasiat, lasten tiedot, erityiset henkilötietoryhmät ja mahdolliset henkilötietojen tietoturvaloukkaukset.
4. Hae omaisuusluettelosta, ei vain ilmeisistä järjestelmistä
Tässä ISO/IEC 27001:2022 muuttuu käytännölliseksi. Zenith Blueprint [ZB], Kontrollit käytännössä -vaiheen vaihe 22, varoittaa, että inventaarion soveltamisala on laajempi kuin moni organisaatio olettaa:
Tämän inventaarion soveltamisala on laajempi kuin useimmat ymmärtävät. Sen tulisi sisältää:
✓ Fyysiset omaisuuserät: kannettavat tietokoneet, palvelimet, puhelimet, varmuuskopionauhat, siirrettävät tallennusvälineet, tulostetut
tallenteet.
✓ Digitaaliset omaisuuserät: asiakirjat, tietoaineistot, tietovarastot, sähköpostit, lähdekoodi, pilveen tallennetut
tiedostot.
✓ Loogiset omaisuuserät: käyttäjätilit, tunnistetiedot, avaimet, ohjelmistolisenssit, ohjelmointirajapinnat.
✓ Palveluihin liittyvät omaisuuserät: SaaS-alustat, hallinnoidut tietoturvapalvelut, ulkoistettu
tallennus.
✓ Ihmiset omaisuuserinä: ei esineellistävässä merkityksessä, vaan nimettyjen vastuiden,
pääsyn ja roolipohjaisen tietoaltistuksen näkökulmasta.
Vaihe 22 selittää myös omistajuuden:
Jokaisella omaisuuserällä tulisi olla määritelty omistaja – ei sitä käyttävä henkilö, vaan se, joka on vastuussa
sen käytöstä, suojaamisesta ja elinkaaresta. Omistajuus on välttämätöntä kontrollien yhdenmukaistamisessa: kuka luokittelee
omaisuuserän (5.10), kuka päättää sen pääsytasosta (8.3), kuka käsittelee sen poistamisen (8.10), kuka varmistaa, että
se palautetaan (5.9 limittyy hienovaraisesti omaisuuden palautusmenettelyihin).
Zenith Controls: poikkivaatimustenmukaisuuden opas [ZC] käsittelee ISO/IEC 27002:2022 -kontrollia 5.9, tietojen ja muiden niihin liittyvien omaisuuserien inventaario, ennaltaehkäisevänä kontrollina, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Sen kyberturvallisuuskonsepti on Identify, sen operatiivinen kyvykkyys on omaisuudenhallinta ja sen tietoturva-alueisiin kuuluvat hallinnointi, ekosysteemi ja suojaus.
DSAR-pyyntöjen osalta tämä tarkoittaa, että inventaario ei ole IT-taulukkolaskenta. Se on kartta, joka kertoo tietosuojalle, lakiasioille ja tietoturvalle, missä henkilötietoja voi olla.
5. Katselmoi, peitä ja hyväksy luovutus
DSAR-vastauksen ei tule olla raakamuotoinen vientitiedosto. Katselmoinnin on suojattava muiden henkilöiden henkilötietoja, luottamuksellisia liiketoimintatietoja, oikeudellista salassapitovelvollisuutta, tietoturvaherkkiä tietoja, petossignaaleja ja pyynnön soveltamisalan ulkopuolisia tietoja.
Hyväksynnän tulee olla riskiperusteinen. Rutiininomaiset pääsyvastaukset voi hyväksyä tietosuojakoordinaattori tai tietosuojavastaava. Pyyntöihin, jotka koskevat työntekijöitä, oikeudenkäyntiä, erityisiä henkilötietoryhmiä, lapsia, petoksia, tietoturvalokeja tai suuria vientiaineistoja, tulee osallistaa lakiasiat, HR tai tietoturvajohdon edustaja.
6. Toimita turvallisesti
Älä liitä suuria salaamattomia tiedostoja sähköpostiin. Käytä todennettuja portaaleja, salattuja tiedostoja erillisellä salasanan toimituksella tai turvallisia siirtolinkkejä, joissa on vanhenemisaika ja käytön lokitus. Kirjaa toimitustapa, päivämäärä, vastaanottajan tili, vanhenemispäivä ja vahvistus, jos sellainen on saatavilla.
7. Sulje näyttöön perustuen
Tietosuoja- ja yksityisyydensuojapolitiikka [P17], lauseke 6.4.3, on yksiselitteinen:
Kaikki toteutetut toimet on kirjattava auditointitarkoituksia varten, mukaan lukien pyyntöjen hylkäämistä koskevat päätökset.
Tietosuoja- ja yksityisyydensuojapolitiikka – SME [P17S], lauseke 6.5.4, toteaa:
Kaikki rekisteröidyn pyyntöihin annetut vastaukset on kirjattava suojattuun rekisteriin, jonka käyttöoikeus on rajattu tietosuojakoordinaattorille ja toimitusjohtajalle.
DSAR ei ole valmis, kun sähköposti on lähetetty. Se on valmis, kun rekisteristä ilmenevät pyyntö, identiteettitarkastus, päätökset, haetut järjestelmät, vastaus, poikkeukset, hyväksynnät, toimitus ja sulkeminen.
Poistaminen on kontrolloitua tuhoamista, ei poistopainike
Poistopyynnöt paljastavat, onko tietosuoja rakennettu järjestelmiin vai liimattu päälle julkaisun jälkeen.
Clarysecin yritystason Tietojen säilytys- ja hävityspolitiikka [P14], roolit ja vastuut -kohdan lauseke 4.3.3, osoittaa vastuun roolille, joka:
Vastaa poistopyyntöihin ja varmistaa henkilötietojen oikea-aikaisen ja todennettavan poistamisen silloin, kun sitä vaaditaan.
Ilmaus ”silloin, kun sitä vaaditaan” on ratkaiseva. GDPR:n mukainen poistaminen ei ole ehdoton oikeus. Organisaatioiden voi olla tarpeen säilyttää tietoja lakisääteisten velvoitteiden, auditoinnin, verotuksen, sääntelyvelvoitteiden, petostentorjunnan, turvallisuuden, oikeudenkäynnin tai oikeudellisten vaateiden laatimisen, esittämisen tai puolustamisen vuoksi. Työnkulkuun on sisällyttävä lainmukaista säilyttämistä ja poikkeuksia koskeva päätös.
Zenith Blueprint [ZB], Kontrollit käytännössä -vaiheen vaihe 19, selittää ISO/IEC 27002:2022 -kontrollin 8.10, tietojen poistaminen, operatiivisesti:
Tämä kontrolli varmistaa, ettei tietoja säilytetä pidempään kuin on tarpeen, ja kun niitä ei enää
tarvita, ne on poistettava turvallisesti ja luotettavasti. Monet organisaatiot keräävät ajan mittaan suuria
tietomääriä, mutta ilman selkeää poistoprosessia tieto voi jäädä käyttämättömänä ja
suojaamattomana paikoilleen ja kasvattaa hiljaisesti altistumisen, loukkauksen tai sääntelyrikkomuksen riskiä.
Se varoittaa myös:
Älä unohda varmuuskopioita ja arkistoituja järjestelmiä; ne säilyttävät usein historiallisia tietoja pitkään sen jälkeen, kun niiden
operatiivinen arvo on päättynyt. Poistopolitiikkojen on ulotuttava seuraaviin:✓ Varmuuskopioiden säilytysasetukset,
✓ tilannevedosten elinkaaret,
✓ arkistoidut sähköposti- tai asiakirjatietovarastot.
Ja se päättää näyttöön:
Itse poistoprosessi on kirjattava lokiin, ja korkean riskin tai sääntelyn alaisten tietojen osalta se on
katselmoitava tai hyväksyttävä. Tämä varmistaa jäljitettävyyden ja suojaa arvokkaiden tallenteiden tahattomalta tai
luvattomalta tuhoamiselta.
Zenith Controls [ZC] yhdistää ISO/IEC 27002:2022 -kontrollin 8.10, tietojen poistaminen, ennaltaehkäisevään kontrolliin, joka keskittyy luottamuksellisuuteen, on linjassa Protect-kyberturvallisuuskonseptin kanssa ja liittyy tietojen suojaamisen sekä laki- ja vaatimustenmukaisuuden operatiivisiin kyvykkyyksiin.
Monimutkaisissa pilviarkkitehtuureissa kryptografinen poisto voi olla asianmukaista, jos se on suunniteltu oikein. Jos henkilötiedot on salattu rekisteröity- tai vuokralaiskohtaisella avaimella, avaimen tuhoaminen voi tehdä tiedoista pysyvästi saavuttamattomia myös silloin, kun salattuja jäännöstietoja säilyy varmuuskopioissa ajastettuun kiertoon asti. Tämä on suunniteltava, dokumentoitava, testattava ja hyväksyttävä huolellisesti. Se ei ole kiertotapa puutteelliselle poistoarkkitehtuurille.
Sovellusvalmius on siksi välttämätöntä. Clarysecin Sovellusturvallisuusvaatimusten politiikka – SME [P09S], lauseke 6.5.1.3, edellyttää sovelluksilta, että ne:
mahdollistavat henkilötietojen turvallisen viennin ja poistamisen silloin, kun laki sitä edellyttää (esim. GDPR Article 17 – oikeus tietojen poistamiseen).
Jos tuotetiimit eivät rakenna vienti- ja poistokyvykkyyttä, tietosuojatiimit joutuvat turvautumaan tietokantaskripteihin, toimittajatiketteihin ja epäyhtenäiseen manuaaliseen työhön.
Oikeudellinen säilytysvelvoite ja poistamisen keskeyttäminen
Kypsään poistotyönkulkuun on sisällyttävä ”älä poista” -polku. Tämä ei ole peruste sivuuttaa poistamista. Se on kontrolloitu poikkeus.
Clarysecin pk-yrityksille tarkoitettu Tietojen säilytyspolitiikka ja turvallisen hävittämisen politiikka – SME [P14S], hallintavaatimusten lauseke 5.4, toteaa:
Tiedot, joihin kohdistuu oikeudellinen säilytysvelvoite ja poistamisen keskeytys (esim. oikeudenkäynnin, auditoinnin tai tutkinnan yhteydessä), on yksilöitävä järjestelmässä selkeästi ja suojattava poistamiselta, vaikka ajastettu säilytysaika olisi päättynyt.
Tietojen säilytys- ja hävityspolitiikka [P14], lauseke 6.4.1, noudattaa samaa periaatetta:
Jos oikeudellinen säilytysvelvoite ja poistamisen keskeytys annetaan (esim. vireillä olevan oikeudenkäynnin, tutkinnan tai auditoinnin vuoksi), muutoin tuhoamisen kohteena olevat tiedot on säilytettävä niiden normaalin säilytysajan yli.
Auditoijat haluavat nähdä molemmat puolet: näytön oikea-aikaisesta poistamisesta ja näytön perustellusta säilyttämisestä.
Käsittelyn rajoittaminen: aliarvioitu oikeus
Rajoituspyynnöt eivät aina edellytä poistamista. Ne edellyttävät, että organisaatio rajoittaa aktiivista käsittelyä ja säilyttää tiedot kontrolloiduissa olosuhteissa.
Yleisiä esimerkkejä ovat:
- Asiakas kiistää tietojen paikkansapitävyyden ja pyytää, että tietojen käyttö lopetetaan tarkistuksen ajaksi.
- Entinen työntekijä vastustaa käsittelyä, mutta tietuetta tarvitaan oikeudellisia vaateita varten.
- Käyttäjä pyytää tietojen poistamista, mutta minimaalinen tietomäärä on säilytettävä estolistan ylläpitämiseksi.
- Petostutkinta edellyttää säilyttämistä, mutta ei normaalia operatiivista käyttöä.
Käytännöllisen rajoittamistyönkulun tulee sisältää oikeudellinen päätös, järjestelmämerkintä, pääsynhallinnan muutos, markkinointiestot, analytiikan poissulkeminen, toimittajaohjeistus, määräaikainen katselmointi ja poikkeuksia koskeva näyttö.
Zenith Controls [ZC] käsittelee ISO/IEC 27002:2022 -kontrollia 5.34, yksityisyydensuoja ja henkilötietojen suojaaminen, ennaltaehkäisevänä kontrollina, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Se liittyy Identify- ja Protect-konsepteihin sekä tietojen suojaamisen ja laki- ja vaatimustenmukaisuuden operatiivisiin kyvykkyyksiin.
Zenith Blueprint [ZB], Kontrollit käytännössä -vaiheen vaihe 23, tiivistää auditointitestin:
Vahvista, että organisaationne on toteuttanut sovellettavien lakisääteisten vaatimusten mukaiset tietosuojatoimenpiteet (5.34). Varmista henkilötietojen luokittelu, asianmukaiset pääsynhallintatoimet, turvalliset käsittelykäytännöt ja tietoisuuskoulutus. Validoi, tuetaanko rekisteröidyn pääsypyyntöjä, tietojen poistamista tai käsittelylokeja operatiivisesti eikä vain politiikan tasolla.
Avainilmaus on ”operatiivisesti eikä vain politiikan tasolla”.
DSAR-työnkulkujen yhdistäminen ISO/IEC 27001:2022 -auditointinäyttöön
ISO/IEC 27001:2022 ei korvaa GDPR:ää. Se jäsentää auditointinäytön.
Lausekkeet 6.1.1–6.1.3 edellyttävät riskien arviointia, riskien käsittelyä, riskin hyväksymiskriteereitä, riskinomistajia, kontrollien valintaa, soveltuvuuslausuntoa ja riskienkäsittelysuunnitelmaa. DSAR-riskeihin kuuluvat luvaton luovutus, määräaikojen ylittäminen, puutteellinen poistaminen, lainvastainen säilyttäminen, liiallinen identiteetin varmentaminen, toimittajan yhteistyöhaluttomuus ja kyvyttömyys rajoittaa käsittelyä.
Lauseke 8.1 edellyttää, että organisaatiot suunnittelevat, toteuttavat ja kontrolloivat ISMS-prosesseja, säilyttävät dokumentoitua näyttöä, kontrolloivat muutoksia ja varmistavat, että ISMS:n kannalta merkitykselliset ulkoisesti tuotetut prosessit, tuotteet ja palvelut ovat kontrolloituja. Tämä sopii DSAR-toimintaan, koska pyynnöt ylittävät sisäisten toimintojen ja ulkoisten käsittelijöiden rajat.
| ISO/IEC 27001:2022- tai ISO/IEC 27002:2022 -viite | DSAR-relevanssi | Tyypillinen näyttö |
|---|---|---|
| Lausekkeet 4.1–4.4 | Toimintaympäristö, sidosryhmät, ISMS:n soveltamisala ja prosessit | ISMS:n soveltamisala, sidosryhmävaatimukset, GDPR:n sovellettavuutta koskevat merkinnät |
| Lausekkeet 5.1–5.3 | Johtajuus, politiikka ja vastuut | Tietosuojavastaavan tai tietosuojakoordinaattorin rooli, RACI, politiikkahyväksynnät |
| Lausekkeet 6.1.1–6.1.3 | Riskien arviointi ja käsittely | DSAR-riskirekisteri, riskienkäsittelysuunnitelma, soveltuvuuslausunto |
| Lauseke 8.1 | Operatiivinen suunnittelu ja ohjaus | DSR-menettely, työnkulun tallenteet, toimittajatehtävien seuranta |
| Kontrolli 5.9 | Tietojen ja muiden niihin liittyvien omaisuuserien inventaario | Omaisuusluettelo, järjestelmäomistajien vaatimustenmukaisuusvakuutukset, linkit käsittelyrekisteriin |
| Kontrolli 5.15 | Pääsynhallinta | Roolipohjainen DSAR-pääsy, rajoitetut rekisterit, hyväksyntätallenteet |
| Kontrollit 5.19 ja 5.20 | Toimittajasuhteet ja toimittajasopimukset | Henkilötietojen käsittelijän lausekkeet, DSAR-avustusehdot, toimittajien vastauslokit |
| Kontrolli 5.23 | Pilvipalvelujen käytön tietoturva | Pilvidatan sijainti, SaaS-omistajuus, pilvipoistamisen näyttö |
| Kontrolli 5.31 | Lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset vaatimukset | GDPR-vaatimusrekisteri, oikeusperustetta ja säilyttämistä koskevat päätökset |
| Kontrolli 5.34 | Yksityisyydensuoja ja henkilötietojen suojaaminen | DSR-työnkulku, henkilötietojen käsittelysäännöt, koulutustallenteet |
| Kontrolli 8.10 | Tietojen poistaminen | Poistotiketit, kryptografisen poiston näyttö, poikkeuslokit |
| Kontrolli 8.13 | Tietojen varmuuskopiointi | Varmuuskopioiden säilytysaikataulut, palautus- ja poistotapa |
| Kontrolli 8.15 | Lokitus | DSAR-toimiloki, vientilokit, ylläpidon toimintatallenteet |
| Kontrolli 8.16 | Valvontatoiminnot | Hälytykset, katselmoinnit, DSAR-käsittelystä lähtevä poikkeamaeskalointi |
Vahva näyttöpaketti sisältää DSR-menettelyn, DSR-rekisterin, käsittelytoimien rekisterin, omaisuusluettelon, tietojen säilytysaikataulun, oikeudellisen säilytysvelvoitteen rekisterin, identiteetin varmentamismenettelyn, peittämisohjeet, turvallisen luovutusmenetelmän, poistomenettelyn, rajoittamismenettelyn, toimittajien pelikirjan, poikkeusrekisterin, koulutustallenteet, sisäisen tarkastuksen tulokset ja johdon katselmointiraportoinnin.
Käytännön työnkulku pääsylle, poistamiselle ja rajoittamiselle
| Työnkulun vaihe | Clarysec-artefakti | Toimi | Tuotettu näyttö |
|---|---|---|---|
| Vastaanotto | Tietosuoja- ja yksityisyydensuojapolitiikka [P17] tai Tietosuoja- ja yksityisyydensuojapolitiikka – SME [P17S] | Kirjaa pyyntö, nimeä omistaja, kuittaa sisäisen palvelutasotavoitteen puitteissa | DSR-rekisterimerkintä, kuittauksen aikaleima |
| Soveltamisala ja identiteetti | Zenith Blueprint [ZB] vaihe 2 | Vahvista GDPR sidosryhmävaatimukseksi, validoi pyynnön esittäjän identiteetti | Identiteetin validointitallenne, soveltamisalamuistiinpanot |
| Inventaariohaku | Zenith Blueprint [ZB] vaihe 22 ja Zenith Controls [ZC] 5.9 -kartoitus | Hae CRM:stä, laskutuksesta, tuotetietokannasta, tuesta, IdP:stä, analytiikasta, sähköpostista ja toimittajilta | Järjestelmähaun tarkistuslista, omistajien vahvistukset |
| Pääsypaketti | Tietosuoja- ja yksityisyydensuojapolitiikka [P17] | Katselmoi, peitä, hyväksy ja luovuta tiedot turvallisesti | Peittämismuistiinpanot, hyväksyntä, turvallisen toimituksen tallenne |
| Poistamispäätös | Tietojen säilytys- ja hävityspolitiikka [P14] | Vahvista, mitä voidaan poistaa ja mitä on säilytettävä | Oikeusperustetta ja säilytyspoikkeusta koskeva päätös |
| Sovelluskyvykkyys | Sovellusturvallisuusvaatimusten politiikka – SME [P09S] | Käytä vienti- ja poistotoimintoja, kun laki sitä edellyttää | Poistotiketti, tuotteen ylläpitolokit |
| Oikeudellisen säilytysvelvoitteen tarkastus | Tietojen säilytyspolitiikka ja turvallisen hävittämisen politiikka – SME [P14S] | Vahvista, soveltuuko oikeudenkäyntiin, auditointiin tai tutkintaan liittyvä säilytysvelvoite | Oikeudellisen säilytysvelvoitteen tarkastustulos |
| Rajoittaminen | Zenith Controls [ZC] 5.34 -kartoitus | Estä markkinointi- ja analytiikkakäsittely käsittelyn valmistumiseen asti | Rajoitusmerkintä, eston näyttö |
| Sulkeminen | Tietosuoja- ja yksityisyydensuojapolitiikka [P17] | Kirjaa kaikki toimet ja mahdollinen hylkääminen tai osittainen hylkääminen | Sulkemistallenne, vastauskopio, poikkeusrekisteri |
Tämä työnkulku muuttaa Sarahin kriisin auditoitavissa olevaksi prosessiksi. Jokaisella vaiheella on omistaja, kontrolliperusta ja näyttö.
Vaatimustenmukaisuuden arvo GDPR:n ulkopuolella
DSAR-työnkulku perustuu GDPR:ään, mutta samat kontrollit tukevat laajempia viitekehyksiä.
NIS2 Article 20 tekee kyberturvallisuudesta johdon vastuun keskeisille ja tärkeille toimijoille. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, vaikuttavuuden arviointi, kyberhygienia, koulutus, pääsynhallinta, omaisuudenhallinta, todennus ja turvallinen viestintä. DSAR-pyynnöt nojaavat moniin samoihin kyvykkyyksiin.
DORA:a sovelletaan 17. tammikuuta 2025 alkaen moniin finanssialan toimijoihin, ja se asettaa yhdenmukaiset ICT-riskien hallintaa, poikkeamien raportointia, häiriönsietokyvyn testausta ja ICT-kolmansien osapuolten riskivaatimuksia koskevat säännöt. Articles 5 and 6 edellyttävät hallinnointia ja dokumentoitua ICT-riskien hallintaa. Articles 17 to 20 käsittelevät poikkeamien havaitsemista, luokittelua, eskalointia, viestintää ja sulkemista. Articles 24 to 30 käsittelevät häiriönsietokyvyn testausta, ICT-kolmansien osapuolten riskejä, palvelurekistereitä, tarkastusoikeuksia, tietojen sijaintia, poikkeama-avustusta ja exit-strategioita. Fintech-yrityksen, joka käsittelee DSAR-pyyntöjä pilvialustojen kautta, tulisi yhdenmukaistaa tietosuojapyyntöjen käsittely ICT-palvelurekisterinsä kanssa.
NIST CSF 2.0 auttaa kääntämään saman työn kyberturvallisuustuloksiksi. GOVERN käsittelee lakisääteisiä, sääntelyyn liittyviä ja sopimusperusteisia vaatimuksia, riskistrategiaa, rooleja, politiikkaa ja valvontaa. IDENTIFY ja PROTECT vastaavat vahvasti omaisuusnäkyvyyttä, tietojen luokittelua, pääsynhallintaa, poistamista, toimittajien hallinnointia ja tietosuojaa.
COBIT 2019 esittää hallinnointikysymyksiä. Kuka omistaa prosessin? Mitkä tavoitteet on määritelty? Miten suorituskykyä mitataan? Miten poikkeukset hyväksytään? Miten varmuus hankitaan? DSAR-näyttö voi tukea tavoitteita, kuten APO13 Managed Security, APO14 Managed Data ja DSS06 Managed Business Process Controls.
Auditoijan näkökulma
| Auditoijan näkökulma | Mihin huomio kohdistuu | Tyypillinen näyttöpyyntö |
|---|---|---|
| ISO/IEC 27001:2022 -auditoija | Onko DSAR-prosessit sisällytetty soveltamisalaan, riskiperusteisesti arvioitu, kontrolloitu, resursoitu ja osoitettu ISMS:ssä | ISMS:n soveltamisala, riskien arviointi, soveltuvuuslausunto, DSR-menettely, rekisterit, sisäisen tarkastuksen tallenteet |
| GDPR-tietosuoja-auditoija tai viranomainen | Onko rekisteröidyn oikeudet käsitelty lainmukaisesti, läpinäkyvästi, turvallisesti ja määräajoissa | Pyyntötiedosto, identiteetin varmentaminen, vastausaikajana, oikeusperusteen analyysi, poistamista tai rajoittamista koskeva näyttö |
| NIST CSF -arvioija | Onko hallinnointi, omaisuusnäkyvyys, tietosuoja, pääsynhallinta, havaitsemis- ja reagointitulokset määritelty ja parannettu | Nykyinen ja tavoiteprofiili, puutesuunnitelma, omaisuusluettelo, toimittajakontrollit, mittarit |
| COBIT 2019- tai ISACA-auditoija | Toimivatko hallinnointitavoitteet, roolit, prosessikontrollit, suorituskykymittarit ja varmentamistoimet | RACI, KPI:t, kontrollien testaus, poikkeushyväksynnät, johdon raportointi |
| DORA-painotteinen auditoija | Onko finanssialan toimijan ICT-riskit, kolmansien osapuolten riippuvuudet, poikkeamapolut ja häiriönsietokyky integroitu | ICT-palvelurekisteri, toimittajalausekkeet, poikkeamamenettelyt, häiriönsietotestit, exit-näyttö |
| NIS2-painotteinen katselmoija | Onko johto hyväksynyt riskitoimenpiteet ja ovatko omaisuuteen, pääsyyn, poikkeamiin, toimittajiin ja koulutukseen liittyvät kontrollit oikeasuhtaisia | Hallituksen pöytäkirjat, riskitoimenpiteet, koulutuslokit, toimittajien valvonta, poikkeamien pelikirjat |
Älä luo erillistä näyttöä jokaista viitekehystä varten. Luo yksi luotettava DSAR-työnkulku ja kartoita se hyvin.
DSAR-mittarit, jotka johdon tulisi nähdä
Johto ei voi valvoa sitä, mitä se ei näe. Hyödyllisiä mittareita ovat pyyntömäärä oikeustyypeittäin, keskimääräinen kuittausaika, keskimääräinen sulkemisaika, määräaikojen toteutuminen, identiteetin täsmennysasteet, poistopoikkeukset, oikeudellisen säilytysvelvoitteen tapaukset, toimittajien vasteajat, osittaiset hylkäykset, käsittelyn aikana tunnistetut poikkeamat ja avoimet korjaavat toimenpiteet.
Nämä mittarit osoittavat, ovatko rekisteröidyn oikeudet operatiivisesti kunnossa vai riippuvaisia yksittäisten henkilöiden sankarisuorituksista.
Yleiset DSAR-valmiuden puutteet
Clarysec näkee yleisesti samoja heikkouksia SaaS-, fintech-, asiantuntijapalvelu- ja pilvilähtöisissä pk-yrityksissä:
- Henkilötietoja sisältäville järjestelmille ei ole omistajaa
- Käsittelyrekisteri ei vastaa todellista SaaS-käyttöä
- Markkinointi-, analytiikka- ja tietovarastoalustat jätetään hakujen ulkopuolelle
- Dokumentoitua identiteetin varmentamisstandardia ei ole
- Ennen luovuttamista ei tehdä peittämiskatselmointia
- Tuotantopoisto tehdään ilman varmuuskopioiden käsittelyä
- Oikeudellista säilytysvelvoitetta ei tarkasteta ennen poistamista
- Rajoittaminen hoidetaan manuaalisesti ilman järjestelmämerkintää
- Toimittajasopimuksista puuttuvat DSAR-avustusehdot
- Hylkäyksiä ja osittaisia hylkäyksiä ei dokumentoida
- Valmiita DSAR-pyyntöjä ei otosperusteisesti tarkasteta sisäisessä tarkastuksessa
- Etulinjan henkilöstöä ei ole koulutettu tunnistamaan pyyntöjä
Vuoden 2026 DSAR-valmiuden tarkistuslista
Käytä tätä kypsyystestinä:
- Onko meillä dokumentoitu DSR-pyyntöjen vastaanotto-, validointi-, seuranta- ja vastausprosessi?
- Kuittaammeko pyynnöt määritellyn sisäisen palvelutasotavoitteen kuluessa?
- Ylläpidämmekö suojattua DSR-rekisteriä, johon pääsy on rajoitettu?
- Onko meillä ajantasainen käsittelytoimien rekisteri, joka sisältää tietoryhmät, tarkoitukset, oikeusperusteet ja säilytysajat?
- Tiedämmekö jokaisen järjestelmän, SaaS-alustan, tietovaraston ja toimittajan, jossa voi olla henkilötietoja?
- Onko jokaisella relevantilla omaisuuserällä vastuutettu omistaja?
- Voimmeko viedä henkilötiedot turvallisesti?
- Voimmeko poistaa henkilötiedot turvallisesti silloin, kun laki sitä edellyttää?
- Voimmeko rajoittaa käsittelyä teknisesti tai menettelyllisesti?
- Tarkastammeko oikeudellisen säilytysvelvoitteen ennen poistamista?
- Dokumentoimmeko hylkäys-, osittainen hylkäys- ja poikkeuspäätökset?
- Tukevatko toimittajasopimukset DSAR-avustusta?
- Testaammeko työnkulkua sisäisen tarkastuksen tai pöytäharjoitusten avulla?
- Raportoimmeko DSAR-suorituskyvyn johdolle?
- Kartoitammeko DSAR-kontrollit ISO/IEC 27001:2022 -riskien käsittelyyn ja soveltuvuuslausuntoon?
Jos useaan vastaukseen sopii ”ei johdonmukaisesti”, seuraava pyyntö voi paljastaa puutteen.
Muuta rekisteröidyn oikeudet auditointivalmiiksi näytöksi
Rekisteröidyn oikeudet vuonna 2026 edellyttävät muutakin kuin hyviä aikomuksia ja tietosuojapostilaatikkoa. Ne edellyttävät työnkulkua, joka pystyy löytämään tiedot, validoimaan identiteetin, tekemään lainmukaiset päätökset, koordinoimaan toimittajia, suojaamaan luovutuksen, toteuttamaan poistamisen, soveltamaan rajoittamista ja säilyttämään näytön.
Clarysec auttaa organisaatioita rakentamaan tämän työnkulun ilman rinnakkaista vaatimustenmukaisuusbyrokratiaa. Aloita Zenith Blueprintistä, jotta rekisteröidyn oikeudet sijoittuvat oikeaan ISMS-vaiheeseen ja oikeisiin askeliin. Käytä Clarysecin Tietosuoja- ja yksityisyydensuojapolitiikkaa, Tietosuoja- ja yksityisyydensuojapolitiikkaa – SME, Tietojen säilytys- ja hävityspolitiikkaa, Tietojen säilytyspolitiikkaa ja turvallisen hävittämisen politiikkaa – SME sekä Sovellusturvallisuusvaatimusten politiikkaa – SME omistajuuden ja operatiivisten sääntöjen määrittämiseen.
Käytä sen jälkeen Zenith Controlsia kartoittaaksesi ISO/IEC 27002:2022 -kontrollit 5.9, 5.34 ja 8.10 GDPR:n, ISO/IEC 27001:2022:n, NIS2:n, DORA:n, NIST CSF 2.0:n ja COBIT 2019:n poikkivaatimustenmukaisuutta tukevaan auditointinäyttöön.
Jos haluat tietää, kestäisivätkö DSAR-, poisto- ja rajoittamistyönkulkusi auditoinnin huomenna, Clarysec voi auttaa testaamaan prosessin, sulkemaan puutteet ja rakentamaan näyttöpaketin ennen seuraavan pyynnön saapumista. Lataa asiaankuuluvat Clarysec-politiikkamallit tai varaa DSAR-valmiuden arviointi siirtyäksesi reaktiivisesta vastaamisesta kontrolloituun, auditointivalmiiseen tietosuojatoimintaan.
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


