BDAR atitiktis svetainėms: ką iš tikrųjų reikia sukurti

Dauguma internete pateikiamų patarimų apie BDAR parašyti teisininkams arba tiems, kurie perka privatumo politikos generatorių. Labai mažai jų skirta žmogui, kuriam reikia atsidaryti redaktorių ir kažką pakeisti.

Šis vadovas skirtas būtent jam. Jame aptariama, ko Bendrasis duomenų apsaugos reglamentas (BDAR, angl. GDPR) reikalauja iš svetainės ir už jos veikiančių sistemų, ir viskas išreikšta tuo, ką reikia sukurti, sukonfigūruoti arba ištrinti. Šį darbą ES veikiančioms įmonėms dirbame nuo tada, kai reglamentas pradėtas taikyti 2018 m., ir per tą laiką tipinės klaidos beveik nepasikeitė.

Vieną dalyką verta pasakyti iš karto: atsiradus naujesniems reglamentams, BDAR netapo lengvesnis. Jis tapo svarbesnis, nes beveik visos dabartinės ES skaitmeninių taisyklių bangos nuostatos daro prielaidą, kad su asmens duomenimis jūs jau esate susitvarkę.

Pradėkite nuo sąžiningos duomenų inventorizacijos

Beveik visi nepavykę BDAR projektai, kuriuos esame perėmę, žlugo toje pačioje vietoje. Komanda pirmiausia parašė politiką, o duomenis atrado vėliau.

Visų pirma išsiaiškinkite, kokius asmens duomenis jūsų svetainė iš tikrųjų renka. Ne tai, ką teigia produkto specifikacija, o tai, kas yra duomenų bazėje, žurnaluose, analitikos platformoje, CRM, klientų aptarnavimo įrankyje, rinkodaros automatizavimo sistemose, klaidų sekimo įrankyje, CDN žurnaluose ir trečiųjų šalių skriptuose puslapyje.

Praktiškai tai reiškia:

• Peržiūrėkite duomenų bazės schemą. Kiekvieną stulpelį, kuris gali identifikuoti asmenį tiesiogiai arba kartu su kitu stulpeliu.
• Atidarykite tinklo skirtuką realaus puslapio įkėlimo metu. Kiekviena išeinanti užklausa į domeną, kurio nekontroliuojate, yra galimas asmens duomenų perdavimas, nes IP adresas kartu su naršyklės identifikatoriumi (user agent) yra asmens duomenys.
• Patikrinkite, ką fiksuoja jūsų klaidų sekimo įrankis. Dėklo pėdsakuose (stack trace) dažnai būna el. pašto adresų, prieigos raktų ir užklausų turinio.
• Patikrinkite žurnalų saugojimo terminus. Prieigos žurnalai su IP adresais, saugomi neribotai, yra vienas dažniausių radinių ir vienas lengviausiai ištaisomų.

Užrašykite tai kaip duomenų tvarkymo veiklos įrašus. 30 straipsnis vis tiek to reikalauja iš daugumos organizacijų, o inžinieriams naudingiausia versija yra lentelė, kurioje nurodyta sistema, duomenys, tikslas, teisinis pagrindas, saugojimo terminas ir gavėjai.

Teisinį pagrindą rinkitės kiekvienam tikslui, ne kiekvienai sistemai

6 straipsnyje numatyti šeši teisiniai pagrindai. Dažniausia klaida, kurią matome: vienas pagrindas parenkamas visam produktui.

Beveik neabejotinai vienu metu turite kelis tikslus. Užsakymo įvykdymas yra sutartis. Sukčiavimo patikros paprastai grindžiamos teisėtais interesais arba teisine prievole. Sąskaitų faktūrų saugojimas teisės aktuose nustatytą laikotarpį yra teisinė prievolė. Rinkodaros el. laiškams daugumoje valstybių narių reikia sutikimo. Nebūtinai analitikai reikia sutikimo dėl e. privatumo taisyklių, reglamentuojančių prieigą prie galinių įrenginių, o ne dėl paties BDAR.

Praktinė pasekmė: jūsų duomenų modelis turi žinoti, kokiam tikslui skirtas kiekvienas įrašas. Jei negalite atskirti rinkodaros profilio nuo užsakymo įrašo, negalėsite patenkinti prieštaravimo dėl rinkodaros nesugadindami užsakymų istorijos. Toks atskyrimas yra duomenų bazės schemos sprendimas, ir jį įdiegti vėliau yra skausminga.

Sutikimas turi būti tikras ir užfiksuotas

Jei remiatės sutikimu, jis turi būti laisvas, konkretus, informuotas ir nedviprasmiškas, o vėliau turite galėti jį įrodyti.

Konkrečiai:

• Niekas, kas nėra būtina, neįsijungia, kol naudotojas neatliko veiksmo. Tai apima analitikos fragmentą, reklamos pikselį, pokalbių valdiklį, iš trečiosios šalies CDN įkeliamą šriftą ir A/B testavimo skriptą.
• Atsisakyti turi būti taip pat lengva, kaip sutikti. Tas pats lygmuo, tas pats matomumas, tas pats paspaudimų skaičius. Priežiūros institucijos visa kita laiko klaidinančiu dizainu (dark pattern) ir šios pozicijos laikosi nuosekliai.
• Sutikimas duodamas kiekvienam tikslui atskirai. Vienas jungiklis, apimantis „analitiką, rinkodarą ir personalizavimą“, nėra konkretus.
• Atšaukti sutikimą turi būti taip pat lengva, kaip jį duoti. Nuolat matoma nuoroda arba plaukiojantis mygtukas, o ne laiškas klientų aptarnavimui.
• Saugokite įrodymą: laiko žymą, sutikimo eilutę arba kiekvienos kategorijos būseną, juostos versiją ir tekstą, kurį naudotojas matė. Be versijos negalėsite apginti dvejų metų senumo sutikimo įrašo.

Priežiūra čia nėra teorinė. 2025 m. rugsėjį Prancūzijos duomenų apsaugos institucija tą pačią dieną skyrė baudas dėl slapukų praktikos: 325 mln. eurų Google ir 150 mln. eurų Shein. Abiem atvejais lėmė mechanika, o ne politikos tekstas: slapukai įrašomi dar prieš bet kokią sąveiką, o atsisakymo mygtukai iš tikrųjų nieko neatsisakydavo.

Šios srities taisyklės taip pat keičiasi. Komisijos pasiūlymu dėl skaitmeninio omnibuso (Digital Omnibus) sutikimas dėl galinių įrenginių būtų perkeltas į patį BDAR, o naršyklės lygmens signalai taptų privalomi. Taryba juda priešinga kryptimi: kaip skelbiama, jos 2026 m. spalio 2 d. derybinės pozicijos projekte sutikimas dėl slapukų paliekamas e. privatumo direktyvos 5 straipsnio 3 dalyje, o abu nauji BDAR straipsniai išbraukiami. 2026 m. spalio 10 d. Taryba šios pozicijos dar nebuvo priėmusi, o derybos su Parlamentu dar nebuvo prasidėjusios. Ką keistų Komisijos pasiūlymas, aptarėme straipsnyje sutikimas dėl slapukų po skaitmeninio omnibuso.

Duomenų subjektų teisių mechanizmą kurkite anksti

BDAR straipsniai nuo 15 iki 22 suteikia žmonėms teisę susipažinti su duomenimis, juos ištaisyti, ištrinti, apriboti jų tvarkymą, perkelti juos ir nesutikti. Atsakyti turite per vieną mėnesį, sudėtingais atvejais šį terminą galima pratęsti iki trijų mėnesių.

Pirmuosius kelis prašymus komandos paprastai tvarko rankiniu būdu, ir tai veikia iki tol, kol nustoja veikti. Ko jums reikia gerokai anksčiau, nei padaugės prašymų:

Paieškos mechanizmo, kuris randa asmenį visose sistemose. Pagal el. pašto adresą jis grąžina viską: paskyrą, užsakymus, klientų aptarnavimo užklausas, rinkodaros profilį, analitikos identifikatorių, žurnalus. Jei žmogus turi atsiminti, kad duomenis saugo ir trečiosios šalies atsiliepimų platforma, anksčiau ar vėliau kas nors pamirš.

Trynimo kelio, kuris paiso saugojimo prievolių. Teisė į ištrynimą nėra absoliuti. Sąskaitas faktūras paprastai reikia išsaugoti dėl mokesčių. Jums reikia švelnaus trynimo (soft delete) su tikslui pritaikytu galutiniu trynimu, kad galėtumėte pašalinti rinkodaros profilį išsaugodami apskaitos įrašą ir kad pats apskaitos įrašas nustatytu laiku nustotų galioti.

Perkeliamo eksporto. Susisteminto, įprastai naudojamo, kompiuterio skaitomo formato. JSON tinka. Sugeneruoto HTML puslapio PDF netinka.

Prieštaravimo žymos, kurią skaito visa sistema. Prieštaravimas dėl profiliavimo turi iš tikrųjų sustabdyti profiliavimą, taip pat ir paketinėje užduotyje, kuri paleidžiama 3 val. nakties ir žymos netikrina.

Saugojimas yra užduotis, ne politikos eilutė

Saugojimo apribojimo principą dažniausiai pažeidžia sistemos, kurios kitais atžvilgiais sukurtos gerai, nes duomenims ištrinti kažkas turi parašyti ir suplanuoti užduotį, kurios niekas neprašo.

Kiekvienai duomenų kategorijai nustatykite gyvavimo trukmę ir ją įgyvendinkite. Prieigos žurnalams, sesijų įrašams, apleistiems krepšeliams, nepatvirtintoms registracijoms, uždarytoms klientų aptarnavimo užklausoms, senoms atsarginėms kopijoms ir neapdorotiems analitikos duomenims reikia galiojimo pabaigos. Atsarginėms kopijoms verta skirti ypatingą dėmesį: jei atkūrimo procesas prikelia ištrintus asmens duomenis, ištrynimas nėra baigtas. Įprastas sprendimas yra dokumentuota atsarginių kopijų rotacija su didžiausiu amžiumi ir pakartotinis trynimų pritaikymas po kiekvieno atkūrimo.

Perdavimai, subtvarkytojai ir kur iš tikrųjų veikia jūsų sistemos

Perduodant duomenis už EEE ribų reikia teisinio mechanizmo: paprastai tai ES ir JAV duomenų privatumo sistema (Data Privacy Framework) sertifikuotiems JAV gavėjams arba standartinės sutarčių sąlygos kartu su perdavimo poveikio vertinimu kitais atvejais.

Inžinerinė pusė paprastesnė už teisinę: žinokite, kur fiziškai yra jūsų duomenys. Tai reiškia kiekvienos paslaugos debesijos regioną, atsarginių kopijų vietą, valdomos duomenų bazės regioną, CDN kraštinių mazgų konfigūraciją ir, svarbiausia, kiekvieno naudojamo SaaS įrankio klientų aptarnavimo modelį. Tiekėjas, kurio paslauga talpinama Frankfurte, bet kurio klientų aptarnavimo komanda jungiasi prie gamybinės aplinkos iš už EEE ribų, vis tiek perduoda duomenis.

Paprastai rekomenduojame asmens duomenis laikyti ES regionuose, jei nėra svarios priežasties elgtis kitaip. Taip išnyksta visa ginčų kategorija, o kainų skirtumas dažniausiai yra nereikšmingas.

Tvarkykite subtvarkytojų sąrašą ir nuolat jį atnaujinkite. 28 straipsnis reikalauja su kiekvienu iš jų sudaryti rašytinę duomenų tvarkymo sutartį, o šio sąrašo jūsų klientai paprašys ir atlikdami išsamų patikrinimą.

Pagal nutylėjimą užtikrintas saugumas, išreikštas konfigūracija

32 straipsnis reikalauja tinkamų techninių ir organizacinių priemonių. Formuluotė sąmoningai neapibrėžta, tačiau 2026 m. svetainei būtinas minimumas yra aiškus:

• TLS visur, įjungtas HSTS, jokio mišraus turinio.
• Slaptažodžiai maišomi šiuolaikine daug atminties reikalaujančia funkcija, o paskyroms, kuriose yra asmens duomenų, prieinamas kelių veiksnių autentiškumo patvirtinimas.
• Duomenų bazių ir atsarginių kopijų šifravimas saugojimo metu.
• Prieiga prie gamybinių asmens duomenų ribojama pagal vaidmenis ir registruojama, o peržiūros iš tikrųjų atliekamos.
• Pseudonimizavimas, kur tai įmanoma: analitikoje maišykite identifikatorių, o atitikmenų lentelę laikykite atskirai ir su ribota prieiga.
• Išbandytas atkūrimas, o ne vien atsarginė kopija.

Pritaikytoji ir standartizuotoji duomenų apsauga pagal 25 straipsnį reiškia, kad privatumą sauganti parinktis yra ta, kurią gaunate nieko nedarydami. Naujienlaiškio langelis nepažymėtas. Profilis matomas tik savininkui. Neprivalomi laukai iš tikrųjų neprivalomi.

Pranešimui apie pažeidimą reikia veiksmų plano

Septyniasdešimt dvi valandos nuo sužinojimo iki pranešimo priežiūros institucijai nėra daug, ypač jei pažeidimas aptinkamas penktadienio vakarą. Atkreipkite dėmesį, kad pagal skaitmeninio omnibuso pasiūlymą šis terminas būtų pailgintas iki devyniasdešimt šešių valandų, nors tai dar nėra įstatymas.

Pasiruoškite iš anksto: kas paskelbia incidentą, kas įvertina, ar buvo paveikti asmens duomenys, kas susisiekia su priežiūros institucija, ką turi apimti pranešimas ir kaip informuosite paveiktus asmenis, jei rizika didelė. Parašykite tai kaip veiksmų planą su įvardytais vaidmenimis ir vieną kartą jį išbandykite. Pirmą kartą jį naudodami neturėtumėte jo skaityti pirmą kartą.

Pati svetainė

Dalis BDAR reikalavimų matoma puslapyje, ir čia verta tiksliai sutvarkyti detales, nes būtent apie jas žmonės praneša.

Jūsų privatumo pranešime turi būti nurodyta duomenų valdytojo tapatybė ir kontaktai, tikslai ir teisiniai pagrindai, gavėjai ir gavėjų kategorijos, perdavimo mechanizmai, saugojimo terminai, visas teisių sąrašas, įskaitant teisę pateikti skundą priežiūros institucijai, ir ar taikomas automatizuotas sprendimų priėmimas. Rašykite kalba, kurią supranta paprastas žmogus. Daugiasluoksniai pranešimai, kai trumpa versija veda prie išsamesnės, veikia geriau nei teksto siena.

Formose rinkite tik tai, ko jums reikia. Kiekvieną lauką gali tekti pagrįsti. Jei rinkodaros sutikimo langelis pateikiamas kartu su užsakymu, jis turi būti atskirai nepažymėtas ir atskirai suformuluotas.

Trečiųjų šalių įterpiniai yra tylus pažeidimas. YouTube patobulinto privatumo režimu, žemėlapiai už įkėlimo paspaudus rezervuotos vietos, šriftai talpinami savame serveryje, o ne įkeliami iš trečiosios šalies CDN. Kiekvienas iš šių pakeitimų yra nedidelis, ir kiekvienas pašalina vieną radinį.

Ką dažniausiai matome blogai

Po pakankamo skaičiaus auditų nuolat kartojasi tas pats trumpas sąrašas:

1. Analitika įkeliama prieš sutikimą, dažniausiai todėl, kad žymų tvarkyklę sukonfigūravo rinkodaros komanda, o inžinieriai jos niekada nepatikrino.
2. Atsisakymo mygtukai, kurie vis tiek suaktyvina sutikimą dėl numatytosios trečiosios šalies skripto elgsenos.
3. Jokių saugojimo užduočių, nė vienoje lentelėje.
4. Ištrynimas, kuris neapima atsarginių kopijų, žurnalų ir CRM.
5. Privatumo pranešimas, aprašantis duomenų srautą, kuris pasikeitė prieš aštuoniolika mėnesių.
6. Subtvarkytojų sąrašai, kuriuose įrašyti tik trys akivaizdūs tiekėjai.
7. Sutikimo įrašai be parodyto teksto versijos.

Nė viena iš šių problemų nėra sudėtinga. Tai tiesiog darbas, kuris niekam nepaskirtas.

Pagalba

Jei norite, kad kas nors dar kartą peržiūrėtų esamą svetainę, atliekame techninius BDAR auditus, kurių rezultatas yra ne ataskaita, o pagal prioritetus sudarytas darbų sąrašas: ką taisyti, kokia tvarka ir kiek kiekvienas punktas užtruks. Jei kuriate kažką naujo, kur kas pigiau nuo pat pradžių teisingai suprojektuoti duomenų modelį ir sutikimų architektūrą.

Taip pat dirbame ir su platesne ES atitikties sritimi, įskaitant prieinamumą ir įėjimą į Europos rinką. Susisiekite su mumis adresu office@c9group.dev.

Mes kuriame programinę įrangą. Teisinių konsultacijų neteikiame, o kiekvieno konkretaus reikalavimo aiškinimas yra jūsų teisininko reikalas. Ką galime padaryti, tai užtikrinti, kad sistema veiktų taip, kaip sako jūsų teisininkas.