VDAR atbilstība tīmekļa vietnēm: kas patiesībā vajadzīgs, lai to izveidotu

Lielākā daļa internetā atrodamo padomu par VDAR (Vispārīgo datu aizsardzības regulu, angliski GDPR) ir rakstīti juristiem vai tiem, kas pērk privātuma politikas ģeneratoru. Gandrīz nekas nav rakstīts cilvēkam, kuram jāatver redaktors un kaut kas jāmaina.

Šis ceļvedis ir domāts tieši viņam. Tajā aplūkots, ko Vispārīgā datu aizsardzības regula prasa no tīmekļa vietnes un sistēmām aiz tās, izsakot to kā lietas, kuras jāizveido, jākonfigurē vai jāizdzēš. Mēs šo darbu veicam uzņēmumiem, kas darbojas ES, kopš regulu sāka piemērot 2018. gadā, un tas, kas parasti noiet greizi, šajā laikā gandrīz nav mainījies.

Viena lieta jāpasaka uzreiz: VDAR nav kļuvusi vieglāka tāpēc, ka nākušas klāt jaunākas regulas. Tā kļuvusi svarīgāka, jo gandrīz viss pašreizējā ES digitālo noteikumu vilnī pieņem, ka ar personas datiem jums jau viss ir kārtībā.

Sāciet ar godīgu datu inventarizāciju

Gandrīz katrs neizdevies VDAR projekts, ko esam pārņēmuši, izgāzās vienā un tajā pašā vietā. Komanda vispirms uzrakstīja politiku un tikai pēc tam atklāja, kādi dati tai ir.

Pirms visa pārējā apzinieties, kādus personas datus jūsu vietne patiesībā vāc. Nevis to, ko saka produkta specifikācija, bet to, kas atrodas datubāzē, žurnālos, analītikas platformā, CRM, atbalsta rīkā, mārketinga automatizācijas sistēmās, kļūdu izsekotājā, CDN žurnālos un lapā ielādētajos trešo pušu skriptos.

Praksē tas nozīmē:

• Izskatiet shēmu ar grep. Katru kolonnu, kas var identificēt personu tieši vai kopā ar kādu citu kolonnu.
• Apskatiet tīkla cilni reālas lapas ielādes laikā. Katrs izejošais pieprasījums uz domēnu, ko jūs nekontrolējat, ir potenciāla personas datu nodošana, jo IP adrese kopā ar lietotāja aģentu ir personas dati.
• Pārbaudiet, ko fiksē jūsu kļūdu izsekotājs. Steka izsekojumos regulāri nonāk e-pasta adreses, marķieri un pieprasījumu saturs.
• Pārbaudiet žurnālu glabāšanas termiņus. Piekļuves žurnāli ar IP adresēm, kas glabājas bezgalīgi, ir viens no biežākajiem atradumiem un viens no vieglāk novēršamajiem.

Pierakstiet to kā apstrādes darbību reģistru. 30. pants to vairumam organizāciju tāpat prasa, un inženieriem noderīgā versija ir tabula ar sistēmu, datiem, nolūku, tiesisko pamatu, glabāšanas termiņu un saņēmējiem.

Izvēlieties tiesisko pamatu katram nolūkam, nevis katrai sistēmai

6. pants paredz sešus tiesiskos pamatus. Visbiežāk redzamā kļūda ir izvēlēties vienu visam produktam.

Gandrīz noteikti jums vienlaikus ir vairāki nolūki. Pasūtījuma izpilde balstās uz līgumu. Krāpšanas pārbaudes parasti balstās uz leģitīmām interesēm vai juridisku pienākumu. Rēķinu glabāšana likumā noteikto laiku ir juridisks pienākums. Mārketinga e-pastiem vairumā dalībvalstu vajadzīga piekrišana. Nebūtiskai analītikai vajadzīga piekrišana, un to nosaka e-privātuma noteikumi par piekļuvi gala iekārtām, nevis pati VDAR.

Praktiskās sekas: jūsu datu modelim jāzina, kuram nolūkam kalpo katrs ieraksts. Ja nevarat nodalīt mārketinga profilu no pasūtījuma ieraksta, jūs nevarat izpildīt iebildumu pret mārketingu, nesabojājot pasūtījumu vēsturi. Šī nodalīšana ir shēmas lēmums, un to ir sāpīgi ieviest vēlāk.

Piekrišanai jābūt īstai, un tā jāreģistrē

Ja balstāties uz piekrišanu, tai jābūt brīvi dotai, konkrētai, informētai un nepārprotamai, un vēlāk jums jāspēj to pierādīt.

Konkrēti:

• Nekas nebūtisks netiek palaists, pirms lietotājs ir izdarījis izvēli. Tas attiecas uz analītikas fragmentu, reklāmas pikseli, tērzēšanas logrīku, fontu no trešās puses CDN un A/B testēšanas skriptu.
• Noraidīt jābūt tikpat viegli kā pieņemt. Tajā pašā slānī, tikpat pamanāmi, ar tikpat daudz klikšķu. Regulatori visu pārējo uzskata par maldinošu dizainu (dark pattern), un šajā jautājumā viņi ir konsekventi.
• Piekrišana tiek dota katram nolūkam atsevišķi. Viens slēdzis „analītikai, mārketingam un personalizācijai“ nav konkrēts.
• Atsaukt jābūt tikpat viegli kā piekrist. Pastāvīga saite vai peldoša poga, nevis e-pasts atbalsta dienestam.
• Glabājiet pierādījumu: laika zīmogu, piekrišanas virkni vai katras kategorijas stāvokli, baneru versiju un tekstu, kas lietotājam tika parādīts. Bez versijas jūs nevarat aizstāvēt divus gadus vecu piekrišanas ierakstu.

Uzraudzība šeit nav teorētiska. 2025. gada septembrī Francijas datu aizsardzības iestāde vienā dienā piemēroja sodu Google 325 miljonu eiro apmērā un Shein 150 miljonu eiro apmērā par sīkdatņu praksi. Abās lietās izšķirošā bija tehniskā izpilde, nevis politikas teksts: sīkdatnes tika ielādētas pirms jebkādas mijiedarbības, un noraidīšanas pogas patiesībā neko nenoraidīja.

Arī noteikumi šajā jomā mainās. Komisijas priekšlikums „Digitālais omnibuss“ pārceltu piekrišanu piekļuvei gala iekārtām pašā VDAR un padarītu pārlūka līmeņa signālus saistošus. Padome virzās pretējā virzienā: tās sarunu nostājas projekts, kas datēts ar 2026. gada 2. oktobri, saskaņā ar ziņām saglabā sīkdatņu piekrišanu E-privātuma direktīvas 5. panta 3. punktā un svītro abus jaunos VDAR pantus. 2026. gada 10. oktobrī Padome šo nostāju vēl nebija pieņēmusi, un sarunas ar Parlamentu vēl nebija sākušās. Ko Komisijas priekšlikums mainītu, esam aprakstījuši rakstā sīkdatņu piekrišana pēc Digitālā omnibusa.

Izveidojiet datu subjektu tiesību mehānismu laikus

15. līdz 22. pants dod cilvēkiem tiesības piekļūt saviem datiem, tos labot, dzēst, ierobežot to apstrādi, pārnest tos un iebilst. Jums jāatbild viena mēneša laikā, ko sarežģītos gadījumos var pagarināt līdz trim mēnešiem.

Komandas parasti pirmos pieprasījumus apstrādā manuāli, un tas darbojas līdz brīdim, kad vairs nedarbojas. Krietni pirms pieprasījumu skaits pieaug, jums vajag:

Mehānismu, kas atrod personu visās sistēmās. Pēc e-pasta adreses tam jāatgriež viss: konts, pasūtījumi, atbalsta pieteikumi, mārketinga profils, analītikas identifikators, žurnāli. Ja cilvēkam jāatceras, ka datus glabā arī trešās puses atsauksmju platforma, agri vai vēlu kāds to aizmirsīs.

Dzēšanas ceļu, kas ievēro glabāšanas pienākumus. Tiesības uz dzēšanu nav absolūtas. Rēķini nodokļu dēļ parasti jāsaglabā. Jums vajadzīga mīkstā dzēšana ar nolūkam piesaistītu galīgo dzēšanu, lai varētu izdzēst mārketinga profilu, saglabājot grāmatvedības ierakstu, un lai arī pats grāmatvedības ieraksts noteiktajā laikā tiktu dzēsts.

Pārnesamu eksportu. Strukturētu, plaši izmantotu, mašīnlasāmu. JSON ir labi. Renderētas HTML lapas PDF nav.

Iebilduma karodziņu, ko nolasa visa sistēma. Iebildumam pret profilēšanu tiešām jāaptur profilēšana, arī pakešuzdevumā, kas darbojas trijos naktī un karodziņu nepārbauda.

Glabāšanas ierobežojums ir uzdevums, nevis politikas rinda

Glabāšanas ierobežošanas principu visbiežāk pārkāpj sistēmas, kas citādi ir labi uzbūvētas, jo datu dzēšanai kādam jāuzraksta un jāieplāno uzdevums, ko neviens nav pasūtījis.

Nosakiet katrai datu kategorijai glabāšanas laiku un tad to ieviesiet. Piekļuves žurnāliem, sesiju ierakstiem, pamestiem iepirkumu groziem, neapstiprinātām reģistrācijām, slēgtiem atbalsta pieteikumiem, vecām rezerves kopijām un analītikas neapstrādātajiem datiem vajadzīgs derīguma termiņš. Īpaša uzmanība jāpievērš rezerves kopijām: ja atjaunošanas process atgriež izdzēstus personas datus, jūsu dzēšana nav pilnīga, un parastais risinājums ir dokumentēta rezerves kopiju rotācija ar maksimālo vecumu, kā arī dzēšanas atkārtota piemērošana pēc katras atjaunošanas.

Datu nosūtīšana, apakšapstrādātāji un tas, kur jūsu sistēmas patiesībā darbojas

Datu nosūtīšanai ārpus EEZ vajadzīgs juridisks mehānisms: parasti ES un ASV datu privātuma regulējums sertificētiem saņēmējiem ASV vai citur līguma standartklauzulas kopā ar nosūtīšanas ietekmes novērtējumu.

Inženiertehniskā puse ir vienkāršāka par juridisko: jāzina, kur jūsu dati fiziski atrodas. Tas nozīmē katra pakalpojuma mākoņa reģionu, rezerves kopiju atrašanās vietu, pārvaldītās datubāzes reģionu, CDN malas konfigurāciju un, kas ir svarīgi, katra izmantotā SaaS rīka atbalsta modeli. Ja piegādātājs mitina datus Frankfurtē, bet tā atbalsta komanda piekļūst ražošanas videi no valsts ārpus EEZ, tā joprojām ir datu nosūtīšana.

Parasti iesakām glabāt personas datus ES reģionos, ja vien nav nopietna iemesla rīkoties citādi. Tas novērš veselu strīdu kategoriju, un izmaksu atšķirība parasti ir niecīga.

Uzturiet apakšapstrādātāju sarakstu un sekojiet, lai tas būtu aktuāls. 28. pants prasa rakstisku apstrādes līgumu ar katru no tiem, un tieši šo sarakstu jums prasīs klienti padziļinātās izpētes laikā.

Drošība pēc noklusējuma, izteikta kā konfigurācija

32. pants prasa atbilstošus tehniskus un organizatoriskus pasākumus. Formulējums ir apzināti neskaidrs, taču tīmekļa vietnes minimālās prasības 2026. gadā tādas nav:

• TLS visur, ieslēgts HSTS, nekāda jaukta satura.
• Paroles jaucētas ar modernu, daudz atmiņas prasošu funkciju, un kontiem, kuros ir personas dati, pieejama daudzfaktoru autentifikācija.
• Datubāzes un rezerves kopijas šifrētas glabāšanā.
• Piekļuve ražošanas vides personas datiem ierobežota pēc lomām un reģistrēta žurnālā, ar pārskatīšanu, kas tiešām notiek.
• Pseidonimizācija, kur tas iespējams: analītikā identifikatoru jauciet, bet sasaistes tabulu glabājiet atsevišķi un ar piekļuves kontroli.
• Pārbaudīta atjaunošana, nevis tikai rezerves kopija.

Integrēta datu aizsardzība un datu aizsardzība pēc noklusējuma, kā paredz 25. pants, nozīmē, ka privātumu saudzējošā iespēja ir tā, ko saņemat, neko nedarot. Jaunumu vēstules izvēles rūtiņa nav atzīmēta. Profils pēc noklusējuma ir privāts. Neobligātie lauki ir neobligāti.

Paziņošanai par datu aizsardzības pārkāpumu vajadzīga rīcības instrukcija

Septiņdesmit divas stundas no brīža, kad uzzināt par pārkāpumu, līdz paziņojumam uzraudzības iestādei nav ilgs laiks, it īpaši, ja pārkāpums atklāts piektdienas vakarā. Ņemiet vērā, ka Digitālā omnibusa priekšlikums šo termiņu pagarinātu līdz deviņdesmit sešām stundām, taču tas vēl nav likums.

Sagatavojieties iepriekš: kurš izsludina incidentu, kurš novērtē, vai ir skarti personas dati, kurš sazinās ar regulatoru, ko satur paziņojums un kā jūs informēsiet skartos cilvēkus, ja risks ir augsts. Uzrakstiet to kā rīcības instrukciju ar konkrētām lomām un vienreiz izmēģiniet. Pirmajai reizei, kad to izmantojat, nevajadzētu būt pirmajai reizei, kad to lasāt.

Pati vietnes saskarne

Daļa VDAR prasību ir redzamas lapā, un detaļas ir vērts nostrādāt pareizi, jo tieši par tām cilvēki ziņo.

Jūsu privātuma paziņojumā jānorāda pārziņa identitāte un kontaktinformācija, nolūki un tiesiskie pamati, saņēmēji un saņēmēju kategorijas, nosūtīšanas mehānismi, glabāšanas termiņi, pilns tiesību saraksts, ieskaitot tiesības iesniegt sūdzību uzraudzības iestādei, un tas, vai notiek automatizēta lēmumu pieņemšana. Rakstiet valodā, ko parasts cilvēks spēj saprast. Slāņoti paziņojumi, kuros īsā versija ved uz detalizētu, darbojas labāk nekā teksta siena.

Veidlapām jāvāc tikai tas, kas jums vajadzīgs. Katrs lauks ir pamatojums, kas jums var nākties sniegt. Ja mārketinga piekrišanas izvēles rūtiņa tiek iesniegta kopā ar pasūtījumu, tai jābūt atsevišķi neatzīmētai un atsevišķi formulētai.

Trešo pušu iegultais saturs ir klusā kļūme. YouTube privātumu uzlabojošā režīmā, kartes aiz vietturētāja, kas ielādējas tikai pēc klikšķa, fonti, kas mitināti pašu serverī, nevis ielādēti no trešās puses CDN. Katra no šīm izmaiņām ir neliela, un katra novērš vienu atradumu.

Kas visbiežāk noiet greizi

Pēc pietiekami daudz auditiem atkārtojas viens un tas pats īsais saraksts:

1. Analītika ielādējas pirms piekrišanas, parasti tāpēc, ka tagu pārvaldnieku konfigurējis mārketings un inženieri to nekad nav pārskatījuši.
2. Noraidīšanas pogas, kas tik un tā aktivizē piekrišanu kāda trešās puses skripta noklusējuma uzvedības dēļ.
3. Nekādu glabāšanas uzdevumu, nevienai tabulai.
4. Dzēšana, kas neaizsniedz rezerves kopijas, žurnālus un CRM.
5. Privātuma paziņojums, kas apraksta datu plūsmu, kura mainījās pirms astoņpadsmit mēnešiem.
6. Apakšapstrādātāju saraksti, kas beidzas ar trim acīmredzamajiem piegādātājiem.
7. Piekrišanas ieraksti bez parādītā teksta versijas.

Neviena no šīm nav sarežģīta problēma. Tas vienkārši ir darbs, kas nevienam nav uzticēts.

Palīdzība

Ja vēlaties, lai kāds no malas paskatās uz esošu vietni, mēs veicam tehniskus VDAR auditus, kuru rezultāts ir prioritizēts uzdevumu saraksts, nevis ziņojums: kas jālabo, kādā secībā un ar laika aplēsi katram punktam. Ja veidojat ko jaunu, ir ievērojami lētāk jau sākumā pareizi izveidot datu modeli un piekrišanas arhitektūru.

Mēs strādājam arī ar plašāku ES atbilstības jomu, tostarp piekļūstamību un ienākšanu Eiropas tirgū. Sazinieties ar mums: office@c9group.dev.

Mēs veidojam programmatūru. Mēs nesniedzam juridiskas konsultācijas, un jebkuras konkrētas prasības interpretācija ir jūsu juristu ziņā. Mēs varam parūpēties, lai sistēma dara to, ko jūsu juristi saka, ka tai jādara.