Siirry sisältöön
Legiscope
Valikko
Tietosuoja

Tietojen minimointi: lomakkeista järjestelmien asetuksiin

Tietojen minimointi lomakkeissa: täytetty kenttäarvio, Mousse-ratkaisun opetus sekä tietojen rajaus keräämisestä vastaanottajiin ja poistamiseen.

Tietojen minimointi tarkoittaa, että henkilötietoja käsitellään vain siinä laajuudessa ja tarkkuudessa, jota määritelty tarkoitus tarvitsee. Lomakkeessa tämä näkyy konkreettisesti: jokaisella kentällä on tehtävä, eikä palvelua estetä tarpeettoman kentän tyhjyyden vuoksi. Sama vaatimus koskee taustalla kerättäviä tunnisteita, liitteitä ja järjestelmien välisiä kopioita.

Hyvä minimointipäätös ei ole pelkkä poistolista. Sen pitää myös säilyttää riittävät tiedot palvelun oikeaan toteuttamiseen. Tässä oppaassa kuvitteellinen Retkipaja Oy uudistaa päiväretken ilmoittautumisen. Täytetty kenttäarvio näyttää, mitä poistetaan, mitä kysytään vasta tarvittaessa ja mitä tietoa on edelleen perusteltua kerätä.

Jos osallistujilta kerätään myöhemmin palautetta, tee erillinen kyselylomakkeen tietosuoja-arvio. Retken järjestämiseen tarvittavat tunnisteet eivät automaattisesti ole tarpeen palauteraportissa.

Kolme kysymystä jokaiselle tiedolle

GDPR:n 5 artiklan 1 kohdan c alakohdan mukaan tietojen tulee olla asianmukaisia, olennaisia ja rajoitettuja siihen, mikä on tarpeellista käsittelyn tarkoituksiin nähden. Arvio alkaa siksi tarkoituksen nimeämisestä. ”Asiakaspalvelu” ei vielä selitä, miksi ilmoittautujan syntymäaika tai työnantaja olisi tarpeen. GDPR:n 5 artikla.

Asianmukaisuus kysyy, onko tieto tehtävään sopivaa ja riittävää. Olennaisuus kysyy sen yhteyttä tarkoitukseen. Tarpeellisuus kysyy, voidaanko sama tarkoitus saavuttaa kohtuudella vähemmillä tai epätarkemmilla tiedoilla. Näin minimointi eroaa siitä, että kaikki kentät muutetaan vapaaehtoisiksi ilman sisällöllistä arviointia.

Retkipajan täsmennetty tarkoitus on ”varata osallistujalle paikka valitulle päiväretkelle, lähettää saapumisohjeet ja järjestää hänen valitsemansa palvelut”. Mainonnan kohdentaminen ei sisälly tähän automaattisesti. Käyttötarkoitussidonnaisuuden arviointi tarvitaan, jos vanhoja osallistujatietoja myöhemmin halutaan käyttää uuteen toimintaan.

Miksi yksi pieni kenttäkin voi olla liikaa?

EU-tuomioistuimen Mousse-ratkaisussa C-394/23 tarkasteltiin SNCF Connectin asiakkailta vaatimaa puhuttelua ”Monsieur” tai ”Madame”. Tuomioistuin katsoi, ettei sukupuoli-identiteettiin perustuva kaupallisen viestinnän personointi ollut kyseisen kuljetussopimuksen toteuttamiselle objektiivisesti välttämätöntä. Neutraali puhuttelu oli vähemmän puuttuva vaihtoehto. Joidenkin erityispalvelujen tarve ei myöskään perustellut kaikkien asiakkaiden tietojen järjestelmällistä keräämistä. Mousse, 9.1.2025, kohdat 33–43.

Ratkaisu ei muodosta luetteloa kaikissa yhteyksissä kielletyistä kentistä. Se näyttää, miksi sopimukseen kirjoittaminen tai vakiintunut kohteliaisuustapa ei yksin osoita tarpeellisuutta. Esimerkiksi tiettyyn palveluun liittyvä yksilöity tarve arvioidaan sen käyttäjien osalta, eikä sitä levitetä varmuuden vuoksi jokaiseen asiakassuhteeseen.

Retkipaja soveltaa tätä periaatetta omassa lomakkeessaan. Puhuttelutitteli poistetaan kokonaan: saapumisohje alkaa tervehdyksellä ja osallistujan nimellä. Asiakkaan sukupuolta ei päätellä nimestä eikä siirretä taustalla uuteen kenttään. Muutos vähentää keräämistä vain, jos sama tieto ei synny toisella tavalla uudelleen.

Täytetty kenttäarvio päiväretken ilmoittautumiselle

Seuraavat ratkaisut koskevat harjoituksen aikuisille tarkoitettua tavallista päiväretkeä. Erityistä ikärajaa, vakuutusehtoa tai laissa määrättyä tunnistamista ei ole oletettu. Jos todellisella palvelulla on tällainen vaatimus, sen tarpeelliset tiedot perustellaan erikseen.

Vanha kenttä Todellinen tarve tässä retkessä Päätetty muutos
Osallistujan nimi Paikan varaaminen ja osallistujan erottaminen paikan päällä Säilytetään; samannimiset erotetaan varausnumerolla
Sähköpostiosoite Vahvistus ja saapumisohje Säilytetään yhteydenpitokanavana
Kotiosoite Retki ei sisällä toimitusta kotiin Poistetaan ilmoittautumisesta
Tarkka syntymäaika Ohjelma ei tarvitse syntymäpäivää Poistetaan; mahdollinen ikäehdon tarkistus suunnitellaan erikseen
Työnantaja ja ammattinimike Eivät vaikuta retken toteutukseen Poistetaan
Puhelinnumero Tarve vain asiakkaan valitsemalle viime hetken tekstiviestille Kysytään kyseisen palvelun valinnan yhteydessä
Ruokavalio ja terveydentila Kaikki eivät tilaa ateriaa; koko terveydentilaa ei tarvita Aterian valitsijoille rajattu järjestelykysymys, terveystietojen peruste erikseen
Vapaa lisätietokenttä Tarpeelliset poikkeavat järjestelyt Rajataan tarkoitus ja ohjeistetaan sisältö

Puhelinnumeron tekeminen vapaaehtoiseksi ei yksin olisi riittävä perustelu. Retkipaja määrittelee palvelun, jossa sitä käytetään, kertoo tämän asiakkaalle ja arvioi käsittelyperusteen. Numeron antaminen viime hetken tiedotteisiin ei tarkoita lupaa puhelinmarkkinointiin.

Ateriajärjestelyissä yritys välttää diagnoosien keräämistä. Se kysyy tarvittavaa käytännön järjestelyä eikä avointa sairaushistoriaa. Jos vastaus kuitenkin paljastaa terveystietoja, minimointi ei poista erityisiin henkilötietoryhmiin liittyviä lisäedellytyksiä. Tavallisen käsittelyperusteen lisäksi on ratkaistava soveltuva 9 artiklan poikkeus ja tarvittavat suojatoimet.

Kysy oikeassa vaiheessa ja vain oikealta joukolta

Retkipajan vanha lomake pyysi kaikilta laskutusosoitteen, vaikka suurin osa maksoi heti. Uudessa kulussa laskutustiedot avautuvat vain laskutuksen valitsevalle asiakkaalle. Jos maksamiseen tai kirjanpitoon tarvitaan tietty tieto, sen tarve arvioidaan kyseisessä vaiheessa ja tietoa käytetään siihen tarkoitukseen.

Samoin aterian tiedot näkyvät vasta aterian valinnan jälkeen. Päiväretkestä kiinnostunut uutiskirjeen tilaaja ei täytä koko osallistujalomaketta. Asiakkaan myöhempää tilausta ei valmistella keräämällä ennakolta tietoja, joille ei ole nykyistä tarkoitusta.

EDPB:n 4/2019-ohjeessa minimointia tarkastellaan myös tietojen tarkkuuden, pääsyn, kopioiden ja tunnistamisen tarpeen kautta. Ensin selvitetään, tarvitaanko henkilötietoja lainkaan; seuraavaksi, riittäisikö pienempi, karkeampi tai koottu aineisto. EDPB:n lopullinen ohje, kohdat 73–76. Tämä antaa käytännön sisältöä sisäänrakennetulle ja oletusarvoiselle tietosuojalle.

Minimointi jatkuu vastaanottajan näkymään

Retkipajan keittiö tarvitsee aterioiden määrät ja välttämättömät ruokajärjestelyt. Se ei tarvitse osallistujien kotiosoitteita, maksutapaa tai työpaikkaa. Oppaalle tarvitaan osallistujaluettelo ja turvalliseen toteutukseen olennaiset järjestelyt. Taloushallinnolle toimitetaan sen tehtävän edellyttämät tiedot, ei koko ilmoittautumisen avointa tekstiä.

Täytetty jakopäätös kuuluu: ”Keittiön listassa käytetään ateriatilausten tunnuksia ja järjestelytietoja. Yhteys osallistujaan on nimetyn vastuuhenkilön hallussa, jos yksittäinen ateria pitää varmistaa.” Tunnusten käyttö ei tee aineistosta automaattisesti anonyymiä. Se rajaa tietoa ja käyttöoikeuksia; pseudonymisoinnin järjestelyt ratkaistaan erikseen.

Ryhmäviestiin ei liitetä kaikkien ilmoittautujien taulukkoa. Tarpeellinen yhteystieto pysyy järjestäjän hallussa eikä siirry osallistujalta toiselle. Myös ulkoisen palveluntarjoajan tiedonsaanti rajataan sen tehtävään. Koko rekisterin jakaminen siksi, että vientipainike tarjoaa sitä oletuksena, ei ole tarpeellisuusarvio.

Vapaa teksti ja liitteet tarvitsevat omat rajansa

Retkipajan vanhaan lisätietokenttään kirjoitettiin henkilötunnuksia, lääkityksiä ja toisten osallistujien yhteystietoja. Uusi kenttä opastaa kertomaan vain retken järjestämiseen tarvittavan käytännön tiedon. Se myös ohjaa yksityiskohtaisen erityisjärjestelyn erilliseen yhteydenottoon, jonka vastaanottaja ja käsittelytapa on määritelty.

Liitteen lähettäminen ei ole oletusarvoinen vaihtoehto. Jos erityinen tilanne tarvitsee asiakirjan, järjestäjä selvittää ensin, riittääkö yksittäisen asian vahvistaminen ilman koko asiakirjaa. Pelkkä asiakkaan halu lähettää paljon tietoja ei tee kaikista niistä organisaatiolle tarpeellisia.

Työntekijälle annetaan toimintatapa tarpeettoman tiedon saapuessa: erotetaan käsiteltävän asian kannalta olennainen osa, rajoitetaan alkuperäisen aineiston saatavuus ja ratkaistaan poistaminen. Arkaluonteista liitettä ei kopioida koko tiimille kysymyksellä ”kuka hoitaa tämän?”. Asiakkaalle voidaan tarvittaessa neuvoa turvallisempi ja suppeampi tapa toimittaa puuttuva tieto.

Tarkista myös piilossa oleva kerääminen

Näkyvän kentän poistaminen ei riitä, jos selain lähettää arvon edelleen taustalla tai palvelin täydentää sen vanhasta asiakasprofiilista. Retkipaja tarkistaa sekä ensimmäisen ilmoittautumisen että palaavan asiakkaan kulun. Tietokannan tarpeeton kenttä poistetaan tai sen täyttäminen estetään sovitussa muutoksessa.

Harjoituksessa käyttöliittymästä poistettu syntymäaika palautui vahvistusviestin malliin aiemmasta asiakasrekisteristä. Korjaus kohdistettiin viestipohjaan ja taustalla tehtävään tietohakuun. Samalla vanhojen syntymäaikojen säilytys arvioitiin erikseen. Lomakkeen uusi versio ei oikeuta vanhan aineiston säilyttämistä määräämättömästi.

Myös IP-osoitteiden ja muiden verkkotunnisteiden käsittely kuuluu tarkastukseen. Palvelun toiminnalle tarvittava tekninen tapahtuma erotetaan analytiikasta ja markkinoinnista. Sivulla näkyvä lyhyt lomake voi silti kerätä taustalla laajan käyttäjäprofiilin, jos näitä yhteyksiä ei tarkisteta.

Säilytys ja tietojen laatu ratkaistaan yhdessä

Minimointi ei tarkoita, että retken jälkeen poistetaan automaattisesti jokainen tieto riippumatta sen muusta perustellusta tarpeesta. Maksun ja kirjanpidon tiedot, palvelun toteutuksen tiedot ja erityisjärjestelyjen tiedot arvioidaan omiin tarkoituksiinsa nähden. Säilytysaikojen määrittely ratkaisee, milloin kukin ryhmä poistetaan tai rajataan muusta käytöstä.

Retkipaja lopettaa ateriajärjestelyjen jakamisen retken päätyttyä ja arvioi niiden jatkosäilytyksen mahdolliset perusteet erikseen. Seuraavan kesän ruokalistan suunnitteluun käytetään riittävän laajoja koontimääriä. Koosteen anonymiteetti arvioidaan ennen kuin sitä jaetaan laajemmin; pienen retkiryhmän yksittäinen poikkeus voi edelleen paljastaa osallistujan.

Tietojen vähentäminen ei saa aiheuttaa vaarallista sekaannusta. Kahden samannimisen osallistujan varausta ei yhdistetä, vaan käytetään tarkoitukseen sopivaa varausnumeroa ja varmistettua yhteystietoa. Kokonaisen henkilötunnuksen kysyminen varmuuden vuoksi ei ole tämän ongelman ainoa ratkaisu. Täsmällisyysperiaate ja minimointi ohjaavat yhdessä riittävän mutta rajatun tunnistamisen suunnittelua.

Miten muutos hyväksytään käytännössä?

Retkipaja käy läpi kolme ilmoittautumista: pelkkä retki, retki aterialla ja retki laskutuksella. Jokaisessa tarkistetaan, että vain valittuun palveluun kuuluvat kentät pyydetään. Tyhjän vapaaehtoisen kentän pitää sallia eteneminen myös puhelimella ja virhetilanteesta palaamisen jälkeen.

Seuraavaksi tarkistetaan vastaanottajien aineistot, vahvistusviesti ja vanhasta profiilista haetut tiedot. Hyväksyjä vertaa havaintoja kenttätaulukkoon. Tulos kirjataan osoitusvelvollisuuden dokumentaatioon: päätetty tarkoitus, poistettu tieto, valittu vaihtoehto ja todettu toiminta. Pelkkä lomakkeen kuvakaappaus ei osoittaisi taustalla tehtävää tiedonsiirtoa.

Jos uusi retkipalvelu myöhemmin tarvitsee lisää tietoja, kenttä voidaan arvioida uudelleen. Päätös sisältää silloin uuden tarpeen, vaihtoehdot ja kohderyhmän. Näin lomake pysyy tarkoituksen mukaisena eikä kasva vähitellen yleiseksi varastoksi kaikelle tiedolle, jota organisaatio saattaa joskus haluta käyttää.

L
Kirjoittanut
Legiscope
Legiscope

Vie ohjeistus käytäntöön

Katso, miten Legiscope yhdistää tietosuojarekisterit, lähdeaineiston ja tarkastettavan työn.

Varaa räätälöity esittely
Jatka lukemista

Aiheeseen liittyvät artikkelit

01Tietosuoja

Automaattinen henkilötietojen käsittely ja GDPR:n soveltamisala

GDPR:n tarkoittama automaattinen henkilötietojen käsittely ei edellytä tekoälyä, robottia tai koneen itsenäistä päätöstä. Tavallinen asiakastietojen tallentaminen tietokoneelle voi kuulua sen…

8. syyskuuta 2026
02Tietosuoja

Automaattiset päätökset: GDPR 22 artiklan rajat ja suojatoimet

GDPR:n 22 artikla koskee päätöksiä, jotka perustuvat pelkästään automaattiseen käsittelyyn ja joilla on henkilöön kohdistuvia oikeusvaikutuksia tai vastaavalla tavalla merkittäviä vaikutuksia. Kyse…

8. syyskuuta 2026
03Tietosuoja

DORA Suomessa 2026: Finanssivalvonta ja digitaalinen häiriönsietokyky

DORA-asetusta on Suomessa sovellettu 17.1.2025 alkaen ilman siirtymäaikaa, ja sen toteutumista valvoo Finanssivalvonta. Asetus koskee yli 400 valvottavaa toimijaa: pankkeja, vakuutusyhtiöitä,…

4. heinäkuuta 2026
04Tietosuoja

Erityiset henkilötietoryhmät: GDPR 9 artiklan käsittelyehdot

Erityisiin henkilötietoryhmiin kuuluvien tietojen käsittely on lähtökohtaisesti kielletty. GDPR:n 9 artikla sisältää poikkeukset tähän kieltoon. Organisaation on tunnistettava sekä soveltuva poikkeus…

8. syyskuuta 2026
05Tietosuoja

GDPR 12 artikla: selkeä informointi ja tietopyyntöjen käsittely

GDPR:n 12 artikla määrää, miten rekisterinpitäjä kertoo henkilötietojen käsittelystä ja auttaa ihmisiä käyttämään oikeuksiaan. Tiedot on annettava selkeästi, ymmärrettävästi ja helposti saatavilla.…

8. syyskuuta 2026
06Tietosuoja

GDPR 14 artikla: muualta kerättyjen tietojen informointi

Yritys saa uuden yhteyshenkilön tiedot sopimuskumppanilta, täydentää asiakasrekisteriä julkisesta lähteestä tai ostaa ammatillisia yhteystietoja. Henkilö ei itse täyttänyt yrityksen lomaketta, mutta…

8. syyskuuta 2026
07Tietosuoja

GDPR-ohjelmisto pk-yrityksille 2026: valinta, ominaisuudet ja hinnat

Pk-yritykselle paras GDPR-ohjelmisto on kevyt, EU-isännöity alusta, joka automatisoi käsittelytoimien selosteen, tietopyynnöt ja käsittelysopimukset ilman kokopäiväisen tietosuojatiimin tarvetta.…

4. heinäkuuta 2026
08Tietosuoja

GDPR-ohjelmiston hinta 2026: mitä tietosuojaohjelmisto maksaa?

Hinta ei ole pelkkä kuukausilisenssi. Kokonaiskustannus (TCO) muodostuu neljästä osasta:

4. heinäkuuta 2026