Evästesuostumus Digital Omnibusin jälkeen: mikä muuttuu ja mitä kannattaa rakentaa nyt

Evästebannerit ovat internetin vähiten rakastettu käyttöliittymä. Ne ovat myös yksi eniten valvotuista, koska ne ovat näkyviä, testattavia ja tuhannet ihmiset ilmoittavat niistä.

Marraskuussa 2025 Euroopan komissio ehdotti Digital Omnibus -pakettia, joka muun muassa siirtäisi evästesuostumussäännöt sähköisen viestinnän tietosuojadirektiivistä suoraan GDPR:ään uusina artikloina 88a ja 88b. Kolmikantaneuvottelut jatkuivat vuoden 2026 puoliväliin, eikä lopullista tekstiä ole.

Tässä on ristiriita, jonka kanssa jokainen tuotetiimi elää juuri nyt: nykyiset säännöt ovat yhä voimassa ja niitä valvotaan aktiivisesti, mutta säännöt, joiden mukaan rakennat, muuttuvat todennäköisesti vuoden tai kahden sisällä. Tässä on näkemyksemme siitä, mitä kannattaa tehdä sillä välin.

Missä ollaan tänään

Nykyinen oikeustila on epämukava yhdistelmä kahdesta säädöksestä.

Sähköisen viestinnän tietosuojadirektiivi hoitaa itse laitteen. Tietojen tallentaminen käyttäjän päätelaitteelle tai niiden lukeminen sieltä vaatii suostumusta, ellei se ole ehdottoman välttämätöntä käyttäjän nimenomaisesti pyytämän palvelun tarjoamiseksi. Tämä koskee evästeitä, localStorage-tallennusta, laitesormenjälkiä ja seurantapikseleitä.

GDPR hoitaa sen jälkeen kerätyt henkilötiedot: käsittelyperusteen, avoimuuden, oikeudet, säilytyksen.

Siksi «meillä on oikeutettu etu analytiikkaan» ei ratkaise evästekysymystä. Käsittelyperuste kattaa käsittelyn. Laitteelle pääsy vaatii silti suostumuksen.

Voimassa olevat vaatimukset pätevälle suostumukselle, sellaisina kuin useat valvojat ovat niitä täsmentäneet:

• Yhtä helppo hylätä kuin hyväksyä, samalla tasolla samannäköisillä painikkeilla.
• Ei esivalintoja ei-välttämättömille tarkoituksille.
• Eriteltävissä tarkoituksen mukaan.
• Selkeä tieto siitä, kuka tietoja saa.
• Peruutettavissa yhtä helposti kuin annettu.
• Ei estoseinää, joka pakottaa hyväksymään pääsyn ehtona ilman aitoa vaihtoehtoa.
• Suostumustodiste säilytettynä.

Ja käytännön testi, jolla useimmat sivustot kaatuvat: mitään ei-välttämätöntä ei ladata ennen kuin käyttäjä on tehnyt valinnan.

Mitä Digital Omnibus muuttaisi

Ehdotus on merkittävä yritys yksinkertaistaa, ja sen keskeiset kohdat:

Suostumuksesta ja evästeistä tulee GDPR-asiaa. Artikla 88a siirtäisi säännöt laitteelle tallennetuista tiedoista ja niihin pääsystä GDPR:ään, mikä lopettaisi kahden säädöksen jaon ja antaisi tietosuojaviranomaisille selkeän toimivallan.

Laajemmat poikkeukset. Ehdotus laajentaisi tilanteita, joissa suostumusta ei tarvita, käsittäen tietoturvan, yleisömittauksen tietyin edellytyksin sekä palvelun toiminnan kannalta välttämättömän. Tämä on yksityiskohdissa kiistanalaisin osa.

Kuuden kuukauden hiljaisuus hylkäyksen jälkeen. Jos käyttäjä hylkää, samaa pyyntöä ei saa esittää uudelleen kuuteen kuukauteen, paitsi rajatuissa tilanteissa. Tämä tähtää suoraan bannerin väsyttämiseen.

Koneluettavat signaalit oikeudellisesti sitovina. Artikla 88b velvoittaisi kunnioittamaan selaimen tai käyttöjärjestelmän tasolla annettuja automaattisia suostumussignaaleja. Tässä kohtaa arkkitehtuuri muuttuu eniten.

Muualla paketissa ehdotetaan täsmennyksiä henkilötiedon määritelmään, tekoälyn koulutukseen liittyvään oikeutettuun etuun sekä tietoturvaloukkausten ilmoittamiseen. Nekään eivät ole lopullisia.

Miksi et voi vain odottaa

Kaksi asiaa tekevät odottamisesta huonon valinnan.

Ensinnäkin nykyinen valvonta ei ole tauolla. Tietosuojaviranomaiset ajavat edelleen bannerikampanjoita, ja hylkäysvaihtoehdon puuttuminen on yhä yleisin havainto. «Odotimme Omnibusia» ei ole puolustus vuoden 2026 tarkastuksessa.

Toiseksi ehdotuksen suunta on riittävän selvä ohjatakseen arkkitehtuuria, vaikka yksityiskohdat muuttuisivat. Koneluettavat signaalit, hylkäystilan kunnioittaminen ja tarkoituskohtainen erittely ovat kaikki asioita, joita kannattaa rakentaa nyt riippumatta lopputekstistä.

Mitä rakentaisimme tänään

Tässä on suostumusarkkitehtuuri, joka toimii nykysääntöjen mukaan ja selviää todennäköisistä muutoksista pienin korjauksin.

Tee suostumustilasta palvelinpuolen käsite

Yleisin virhe on kohdella suostumusta selaimen huolena. Suostumusalusta asettaa evästeen, skriptit kysyvät sitä, ja siihen se jää.

Se hajoaa heti, kun palvelin tekee jotain suostumuksesta riippuvaista: personointi, palvelinpuolen seuranta, tapahtumien lähetys mainosalustoille, A/B-jako. Nämä tapahtuvat ennen kuin selaimen skripti ehtii lausua mielipiteensä.

Tallenna suostumustila muodossa, jonka palvelin voi lukea pyyntökohtaisesti, ja tee siitä ehtona kaikelle ei-välttämättömälle käsittelylle molemmilla puolilla.

Ehdollista skriptien lataus, älä estä sitä jälkikäteen

Estäminen on jälkikorjaus. Se toimii, kun suostumusalusta tuntee skriptin, ja epäonnistuu hiljaa, kun ei tunne.

Rakenna sen sijaan tunnisteiden lataus siten, että ei-välttämättömiä skriptejä ei ole olemassa DOM:ssa, ennen kuin suostumustila on tiedossa ja myönteinen. Tämä tarkoittaa yleensä pientä latausohjainta, joka lukee tarkoituskohtaisen suostumuksen ja injektoi vastaavat tunnisteet.

Testaus on sitten yksinkertaista: tyhjä profiili, verkkovälilehti, ei klikkauksia, ei pyyntöjä kolmansille osapuolille. Se on sama testi, jonka valvoja ajaa.

Mallinna tarkoitukset, älä toimittajia

Bannerit, jotka listaavat 47 toimittajaa, ovat huonoja käyttöliittymiä ja vaikeita ylläpitää. Bannerit, jotka listaavat neljä tarkoitusta, ovat luettavia ja pysyvät oikeina, kun toimittajat vaihtuvat.

Pidä toimittajakartoitus tarkoitusten alla, älä käyttäjälle näkyvänä ensimmäisenä valintana. Käyttäjän on silti päästävä toimittajaluetteloon, mutta se voi olla toisella tasolla.

Rakenna suostumusloki, jota voi kysellä

Sinun on voitava vastata: kuka suostui, mihin tarkoituksiin, milloin, mistä bannerin versiosta, ja koska tila muuttui. Tallenna se tapahtumalokina, ei nykytilana, koska nykytila ei kerro, mitä oli voimassa silloin kun tapahtuma tallennettiin.

Tämä on myös se, mikä tekee ehdotetusta kuuden kuukauden säännöstä helpon: jos sinulla on hylkäystapahtumat aikaleimoineen, hiljaisen jakson toteuttaminen on yhden ehdon lisäys.

Valmistaudu koneluettaviin signaaleihin

Vaikka artikla 88b ei mene läpi nykymuodossaan, suunta on selvä. Suunnittele suostumuskerroksesi ottamaan syötettä useammasta lähteestä: käyttöliittymän valinta, tallennettu aiempi valinta ja ulkoinen signaali, ja anna niille selkeä etusijajärjestys.

Käytännössä tämä tarkoittaa, että suostumuksen ratkaisulogiikka on yhdessä paikassa funktiona, ei hajautettuna bannerin komponenttipuuhun.

Erottele välttämätön ja perustele se

Kirjoita ylös, miksi jokainen välttämättömäksi luokiteltu eväste on välttämätön. Istunto, kuormantasaus, CSRF-tunnus, kielivalinta: nämä ovat helppoja. Analytiikka ei ole, vaikka sitä kutsuttaisiin ensimmäisen osapuolen analytiikaksi.

Tämä luettelo on ensimmäinen asia, jota kysytään, ja se on myös se, joka ratkaisee, hyötyisitkö laajennetuista poikkeuksista, jos Omnibus menee läpi.

Yleisimmät virheet, joita näemme

Hylkää-painike on toisella tasolla. Yhä. Se on yleisin yksittäinen havainto valvontatoimissa.

Suostumus ei kata palvelinpuolen seurantaa. Tiimit siirtyivät palvelinpuolen tapahtumien lähetykseen selainten rajoitusten vuoksi eivätkä liittäneet sitä suostumukseen. Nyt tapahtumat lähtevät riippumatta siitä, mitä käyttäjä valitsi.

Suostumus resetoituu joka käynnillä. Yleensä väärin asetetun evästeen elinkaaren tai domain-alueen vuoksi. Käyttäjä joutuu vastaamaan samaan kysymykseen loputtomasti, mikä on juuri se, mitä ehdotettu hiljainen jakso yrittää lopettaa.

Peruuttaminen on piilotettu. Jos hyväksyminen kestää yhden klikkauksen ja peruuttaminen vaatii tietosuojaselosteen selaamista, se ei ole yhtä helppoa.

Suostumustodistetta ei ole. Alusta näyttää kojelaudan, mutta mitään ei ole omassa järjestelmässäsi. Jos vaihdat toimittajaa, todiste katoaa.

Alitoimittajat ilmestyvät hiljaa. Tunnisteiden hallinnan kautta lisätty markkinointityökalu tuo mukanaan kolme muuta. Kukaan ei päivitä bannerin toimittajaluetteloa.

Mikä on realistinen aikataulu

Jos Digital Omnibus hyväksytään, odota siirtymäaikaa ennen soveltamista, ja odota kansallisten viranomaisten julkaisevan ohjeistusta sen jälkeen. Käytännössä tämä tarkoittaa, että nykysäännöt ovat se, jonka mukaan sinut arvioidaan vielä jonkin aikaa.

Se, mitä me kerromme asiakkaille: rakenna nykysääntöjen mukaan, mutta rakenna se niin, että muutokset ovat konfiguraatiota eivätkä uudelleenkirjoitus. Tarkoituskohtainen erittely, tapahtumapohjainen loki, palvelinpuolen tila ja yksi ratkaisufunktio antavat sen joustavuuden.

Missä tämä osuu muuhun

Suostumusinfrastruktuuri koskettaa enemmän kuin bannerin. Se ohjaa personointia, analytiikkaa, mainontaa ja yhä useammin tekoälyominaisuuksia. Jos tuotteesi käyttää tekoälyä, tekoälyasetuksen avoimuusvelvoitteet tuovat oman ilmoituskerroksensa, ja käyttäjän kannalta ne ovat sama keskustelu: mitä tapahtuu, kuka päättää, miten kerrotaan.

Perusta on yhä GDPR itsessään, jonka käymme läpi verkkosivustojen GDPR-oppaassa, ja koko sääntelykuva on oppaassamme EU:n digitaaliseen sääntelyyn 2026.

Jos tarvitset apua

Rakennamme suostumusarkkitehtuuria, tunnisteiden hallintaa ja analytiikkaputkia yrityksille, jotka toimivat Euroopassa. Käytännössä tämä on enimmäkseen putkiremonttia: saada suostumustila sinne, missä sitä tarvitaan, ja varmistaa, ettei mitään lähde ulos ennen kuin sen pitäisi.

Kirjoita osoitteeseen office@c9group.dev, tai lue lisää EU-markkinoille tuloa käsittelevältä sivultamme.

Emme anna oikeudellista neuvontaa. Se, mikä lasketaan välttämättömäksi ja mikä ei, on kysymys juristeillenne, ja me rakennamme järjestelmän heidän vastauksensa ympärille.