Sisäänrakennettu tietosuoja 2026: GDPR 25 artikla käytännössä

Sisäänrakennettu tietosuoja (englanniksi privacy by design) tarkoittaa, että tietosuoja otetaan huomioon jo järjestelmiä ja prosesseja suunniteltaessa, ei vasta jälkikäteen. Oletusarvoinen tietosuoja (privacy by default) tarkoittaa, että oletusasetuksin käsitellään vain käyttötarkoituksen kannalta välttämättömiä tietoja. Molemmat velvoitteet asettaa yleisen tietosuoja-asetuksen (GDPR) 25 artikla, ja ne kohdistuvat rekisterinpitäjään. Periaate on siirtymä reaktiivisesta compliance-työstä ennakoivaan suunnitteluun: tietosuojaa ei voi liimata valmiiseen tuotteeseen, vaan se on rakennettava sisään alusta alkaen. Tässä oppaassa käydään läpi, mitä 25 artikla vaatii, mitä ero on “by design” ja “by default” välillä ja miten periaate toteutetaan käytännössä.

Mitä 25 artikla vaatii?

25 artiklan 1 kohta (sisäänrakennettu tietosuoja) velvoittaa rekisterinpitäjän toteuttamaan asianmukaiset tekniset ja organisatoriset toimet – sekä käsittelytapoja määriteltäessä että itse käsittelyn aikana – tietosuojaperiaatteiden tehokkaaksi toteuttamiseksi ja tarvittavien suojatoimien sisällyttämiseksi käsittelyyn. Toimissa on otettava huomioon:

• käytettävissä oleva tekniikka ja toteuttamiskustannukset;
• käsittelyn luonne, laajuus, asiayhteys ja tarkoitukset;
• käsittelyn aiheuttamat riskit rekisteröityjen oikeuksille ja vapauksille.

25 artiklan 2 kohta (oletusarvoinen tietosuoja) velvoittaa toteuttamaan toimet, joilla varmistetaan, että oletusarvoisesti käsitellään vain kunkin tarkoituksen kannalta tarpeellisia henkilötietoja. Tämä koskee kerättävien tietojen määrää, käsittelyn laajuutta, säilytysaikaa ja saatavuutta. Käytännössä: tietoja ei saa oletuksena kerätä enempää kuin tarkoitus vaatii, eikä niitä saa oletuksena tehdä rajattomasti saataville.

Selkein esimerkki oletusarvoisesta tietosuojasta on sosiaalisen median profiili, joka on oletuksena yksityinen – ei julkinen. Käyttäjän on aktiivisesti valittava laajempi jakaminen, ei suppeampi. Sama periaate koskee mitä tahansa palvelua: uuden käyttäjän asetusten on oltava lähtökohtaisesti tietosuojaa suojaavimmat, ja käsittelyn laajentaminen edellyttää käyttäjän aktiivista valintaa. Tämä kääntää perinteisen asetelman päinvastoin – aiemmin oletuksena oli usein mahdollisimman laaja tietojen keruu, josta käyttäjän piti erikseen kieltäytyä. Oletusarvoinen tietosuoja tekee suojasta oletuksen ja avautumisesta valinnan, joten jokaisen uuden ominaisuuden kohdalla on kysyttävä, mikä on tietosuojan kannalta turvallisin oletusasetus.

By design vs. by default

Kahden käsitteen ero on hyödyllistä pitää selkeänä:

• Sisäänrakennettu tietosuoja (by design) koskee koko suunnitteluprosessia: tietosuojaperiaatteet – tietojen minimointi, säilytyksen rajoittaminen, käyttötarkoitussidonnaisuus, turvallisuus – rakennetaan järjestelmään ja prosesseihin sisään. Esimerkkejä ovat pseudonymisointi, tietojen minimointi jo tietokantarakenteessa ja automaattinen poisto säilytysajan päättyessä.
• Oletusarvoinen tietosuoja (by default) koskee oletusasetuksia: kun tuote luovutetaan käyttäjälle, sen oletusasetusten on oltava tietosuojan kannalta suojaavimmat. Käyttäjän ei tarvitse tehdä mitään ollakseen suojassa; hänen on tehtävä aktiivinen valinta laajentaakseen käsittelyä.

Molemmat periaatteet toteutuvat parhaiten, kun ne kytketään vaikutustenarviointiin: vaikutustenarviointi tunnistaa riskit, ja sisäänrakennettu tietosuoja tarjoaa keinot niiden pienentämiseen jo suunnitteluvaiheessa. Näin kaksi velvoitetta muodostavat yhtenäisen kokonaisuuden riskien tunnistamisesta niiden hallintaan.

Miten periaate toteutetaan käytännössä?

Sisäänrakennettu tietosuoja ei ole yksittäinen tehtävä vaan toimintatapa. Käytännössä se toteutuu seuraavilla toimilla:

1. Tietosuoja mukaan projektin alusta. Kun uutta järjestelmää, tuotetta tai kampanjaa suunnitellaan, tietosuoja-asiantuntija tai tietosuojavastaava otetaan mukaan jo vaatimusmäärittelyyn, ei vasta ennen julkaisua.
2. Tietojen minimointi rakenteeseen. Kerää vain tarpeelliset kentät. Jos et tarvitse henkilötunnusta, älä kysy sitä. Suunnittele lomakkeet ja tietokannat niin, että tarpeeton tieto ei ole mahdollista tallentaa.
3. Oletusasetukset suojaaviksi. Näkyvyys, jakaminen ja seuranta oletuksena pois päältä tai suppeimmillaan. Käyttäjä laajentaa aktiivisella valinnalla.
4. Pseudonymisointi ja salaus. Erota tunnistetiedot varsinaisista tiedoista ja salaa tiedot lepotilassa ja siirrossa (kytkeytyy 32 artiklan tietoturvaan).
5. Automaattinen elinkaari. Rakenna säilytysajat ja automaattinen poisto järjestelmään, jotta säilytyksen rajoittaminen toteutuu ilman manuaalista työtä.
6. Läpinäkyvyys ja oikeudet valmiiksi. Suunnittele tarkastusoikeuden, poiston ja siirto-oikeuden toteutus järjestelmään heti, ettei niitä tarvitse rakentaa jälkikäteen käsityönä.

Näiden toimien takana on yksi ydinajatus: tietosuoja on suunnitteluvaatimus, ei jälkitarkastus. Se tarkoittaa, että tietosuoja-asiantuntija tai tietosuojavastaava on mukana jo silloin, kun järjestelmän vaatimuksia määritellään ja arkkitehtuuria piirretään – ei vasta silloin, kun valmis tuote esitellään hyväksyttäväksi. Tässä vaiheessa tehdyt ratkaisut, kuten se mitä tietoja kerätään ja miten ne rakenteellisesti erotellaan, määrittävät koko elinkaaren tietosuojan tason. Käytännön haaste on, että suunnitteluvaiheessa tietosuoja kilpailee muiden vaatimusten – aikataulun, kustannusten ja ominaisuuksien – kanssa. Juuri siksi 25 artikla asettaa velvoitteen nimenomaan rekisterinpitäjälle: se pakottaa punnitsemaan tietosuojan mukaan päätöksentekoon. Hyödyllinen työkalu tähän on vaikutustenarviointi, joka tuo riskit näkyviksi jo suunnitteluvaiheessa ja tekee tietosuojaratkaisut perustelluiksi.

Sisäänrakennettu tietosuoja tuottaa myös liiketaloudellista hyötyä: jälkikäteen tehty tietosuojakorjaus on lähes aina kalliimpi kuin suunnitteluvaiheessa tehty ratkaisu. Legiscopen kaltainen ratkaisu tuo tietosuojan osaksi projektien elinkaarta linkittämällä käsittelytoimet, vaikutustenarvioinnit ja säilytysajat yhteen näkymään. Tietosuojavaltuutetun toimisto käsittelee aihetta sisäänrakennettua ja oletusarvoista tietosuojaa koskevalla sivullaan, ja lakiteksti löytyy GDPR:n 25 artiklasta EUR-Lexissä sekä tietosuojalaista (1050/2018).

Esimerkkejä toteutuksesta ja sertifiointi

Sisäänrakennettu tietosuoja jää helposti julistukseksi, ellei sitä konkretisoi. Muutama esimerkki osoittaa, miltä periaate näyttää käytännössä.

Lomakesuunnittelu. Kun rakennat yhteydenotto- tai rekisteröitymislomakkeen, kysy vain tarpeelliset kentät. Jos et tarvitse henkilötunnusta tai syntymäaikaa, älä pyydä niitä. Tee vapaaehtoiset kentät selkeästi vapaaehtoisiksi. Tämä on tietojen minimointia jo suunnitteluvaiheessa.

Oletusasetukset. Uuden käyttäjätilin näkyvyys, sijainnin jakaminen ja markkinointiseuranta oletuksena pois päältä. Käyttäjä laajentaa käsittelyä aktiivisella valinnalla, ei suppenna sitä.

Tietokantarakenne. Erota tunnistetiedot varsinaisista tiedoista (pseudonymisointi), salaa arkaluonteiset kentät ja rakenna automaattinen poisto säilytysajan päättyessä osaksi tietokannan elinkaarta – näin säilytyksen rajoittaminen toteutuu ilman manuaalista työtä.

Oikeuksien toteutus. Rakenna tarkastusoikeuden, poiston ja siirto-oikeuden toteutus järjestelmään heti, jotta rekisteröityjen pyynnöt hoituvat toiminnallisuudella eikä käsityönä.

Sertifiointi. 25 artiklan 3 kohta toteaa, että hyväksytty sertifiointimekanismi (42 artikla) voi toimia osoituksena velvoitteen noudattamisesta. Vaikka sertifiointi ei ole pakollista eikä poista vastuuta, se voi olla hyödyllinen tapa osoittaa sisäänrakennetun tietosuojan toteutuminen erityisesti toimittajasuhteissa. Sertifiointi tai tunnustetut käytännesäännöt voivat myös helpottaa käsittelijän valintaa, koska ne antavat riippumattoman arvion tietosuojan tasosta.

Legiscopen kaltainen ratkaisu tuo nämä käytännöt yhteen näkymään linkittämällä käsittelytoimet, vaikutustenarvioinnit ja säilytysajat, jolloin sisäänrakennettu tietosuoja on myös osoitettavissa.

Euroopan tietosuojaneuvosto (EDPB) on antanut 25 artiklasta yksityiskohtaiset suuntaviivat (Guidelines 4/2019), joissa se painottaa, että toimien on oltava tehokkaita, ei muodollisia: pelkkä periaatteiden mainitseminen dokumentissa ei riitä, vaan niiden on näyttävä konkreettisina järjestelmäratkaisuina ja mitattavina vaikutuksina. Suuntaviivat korostavat myös oletusarvoisen tietosuojan käytännön ulottuvuutta – kerättävän tietomäärän, käsittelyn laajuuden, säilytysajan ja saatavuuden on kaikkien oltava oletuksena minimoituja. Ajantasainen ohjeistus ja suuntaviivat löytyvät Euroopan tietosuojaneuvoston sivuilta. Käytännössä tämä tarkoittaa, että jokainen suojaavaksi väitetty oletusasetus on voitava myös osoittaa toimivaksi – väite ilman todennettavaa toteutusta ei täytä 25 artiklaa.

Usein kysytyt kysymykset

Mitä eroa on sisäänrakennetulla ja oletusarvoisella tietosuojalla?

Sisäänrakennettu tietosuoja (25 artiklan 1 kohta) tarkoittaa, että tietosuoja rakennetaan järjestelmään ja prosesseihin jo suunnitteluvaiheessa. Oletusarvoinen tietosuoja (25 artiklan 2 kohta) tarkoittaa, että oletusasetukset ovat suojaavimmat ja että oletuksena käsitellään vain tarpeellisia tietoja. Ensimmäinen koskee suunnittelua, jälkimmäinen oletusasetuksia.

Koskeeko 25 artikla myös olemassa olevia järjestelmiä?

Kyllä. Velvoite koskee sekä käsittelytapojen määrittelyä että itse käsittelyä, joten se ulottuu myös käytössä oleviin järjestelmiin. Olemassa olevia järjestelmiä on kehitettävä tietosuojaperiaatteiden mukaisiksi, vaikka täydellinen uudelleensuunnittelu ei aina ole mahdollista.

Onko sisäänrakennettu tietosuoja pakollista pienyritykselle?

Kyllä, mutta vaadittavat toimet suhteutetaan käsittelyn riskiin, laajuuteen ja toteuttamiskustannuksiin. Pieneltä yritykseltä ei odoteta samoja resursseja kuin suuryritykseltä, mutta perusperiaatteet – tietojen minimointi ja suojaavat oletusasetukset – koskevat kaikkia rekisterinpitäjiä.

Miten sisäänrakennettu tietosuoja liittyy vaikutustenarviointiin?

Ne täydentävät toisiaan. Vaikutustenarviointi (35 artikla) tunnistaa käsittelyn riskit, ja sisäänrakennettu tietosuoja (25 artikla) tarjoaa keinot niiden pienentämiseen jo suunnitteluvaiheessa. Korkean riskin käsittelyssä nämä kaksi kannattaa tehdä yhdessä.

Kuka vastaa sisäänrakennetun tietosuojan toteutumisesta?

Rekisterinpitäjä. Velvoite kohdistuu 25 artiklassa nimenomaan rekisterinpitäjään, ei ohjelmiston toimittajaan. Toimittajan tuotteen ominaisuudet vaikuttavat toteutukseen, mutta vastuu periaatteen noudattamisesta on aina rekisterinpitäjällä. Siksi tietosuojavaatimukset kannattaa asettaa jo hankintavaiheessa ja kirjata käsittelysopimukseen.

Mitä “asianmukaiset toimet” tarkoittavat käytännössä?

Asianmukaisuus suhteutetaan käytettävissä olevaan tekniikkaan, toteuttamiskustannuksiin sekä käsittelyn luonteeseen ja riskiin. Korkean riskin käsittelyssä edellytetään vahvempia toimia kuin matalan riskin käsittelyssä. Pieneltä toimijalta ei odoteta samoja resursseja kuin suurelta, mutta perustoimet – tietojen minimointi ja suojaavat oletusasetukset – koskevat kaikkia.

Riittääkö tietosuojan lisääminen valmiiseen tuotteeseen?

Ei. Sisäänrakennetun tietosuojan idea on, että periaatteet rakennetaan sisään jo suunnitteluvaiheessa. Jälkikäteen lisätty tietosuoja on lähes aina kalliimpi, hauraampi ja epätäydellisempi. Olemassa olevia järjestelmiä on kuitenkin kehitettävä periaatteen mukaisiksi mahdollisuuksien mukaan.

Yhteenveto

Sisäänrakennettu ja oletusarvoinen tietosuoja on GDPR 25 artiklan velvoite, joka siirtää tietosuojan jälkikäteisestä korjaamisesta ennakoivaan suunnitteluun. Sisäänrakennettu tietosuoja rakentaa periaatteet järjestelmiin ja prosesseihin suunnitteluvaiheessa; oletusarvoinen tietosuoja varmistaa, että oletusasetukset ovat suojaavimmat ja että vain tarpeellisia tietoja käsitellään. Ota tietosuoja mukaan projektin alusta, minimoi tiedot, tee oletusasetukset suojaaviksi ja rakenna rekisteröityjen oikeudet valmiiksi järjestelmään. Periaate kytkeytyy suoraan vaikutustenarviointiin ja säilytyksen rajoittamiseen – toteuta ne yhtenä kokonaisuutena.