GDPR atbilstības saraksts Eiropas vietnēm

Visbiežākais atklājums mūsu GDPR pārbaudēs nav tas, ko gaidītu. Ne trūkstošas privātuma politikas vai neparakstīti datu apstrādes līgumi. Tās ir vietnes, kuras uzinstalēja kādu piekrišanas risinājumu, ieraudzīja banneri ekrānā un nolēma, ka darbs darīts, nevis pārbaudīja, vai analītikas un mārketinga skripti patiešām tiek bloķēti pirms piekrišanas. Cookiebot uz vietnes un Google Analytics, kas ielādējas pirms piekrišanas, ir divas lietas, kas labi sadzīvo. Auditētos projektos esam redzējuši abus vienlaikus vairāk reižu, nekā gribētos atzīt. Šis saraksts aptver to, kas praksē tiešām nestrādā, nevis tikai to, ko regula pasludina teorijā.

Sīkdatņu piekrišana: banneris nav pietiekams

Atbilstošam piekrišanas mehānismam pirms piekrišanas jābloķē visas neobligātās sīkdatnes. Tas nozīmē, ka analītika, mārketinga pikseļi un sociālo tīklu skripti nedrīkst aktivizēties lapas ielādē, vai pēc 3 sekunžu aizkaves, vai ja vien lietotājs nescrollē garām banneram. Pirms piekrišanas nozīmē pirms piekrišanas.

Lietotājiem jāvar arī pieņemt vai noraidīt sīkdatnes pa kategorijām (nepieciešamās, analītika, mārketings, preferences atsevišķi), un pogai "Noraidīt visas" jābūt tikpat pamanāmai kā "Pieņemt visas". Noraidīšanas iespējas apslēpšana apakšizvēlnē vai tās padarīšana pelēka, kamēr pieņemšanas poga ir spilgti zaļa, ir tumšs modelis, ko regulatori jau sākuši aktīvi sodīt. Piekrišanas ieraksti jāsaglabā, ietverot laika zīmogu, lietotāja identifikatoru un pieņemtās kategorijas, un lietotājiem jāvar mainīt preferences jebkurā brīdī.

Tādi rīki kā Cookiebot vai Complianz nodrošina piekrišanas saskarni, taču pareiza konfigurācija ir tas, kas tos faktiski liek strādāt. Daudzi standarta iestatījumi joprojām ielādē Google Analytics vai Facebook Pixel pirms piekrišanas, jo tag manager konfigurācija netika atjaunināta pēc piekrišanas rīka uzinstalēšanas. Ja izmantojat GA4, mūsu GA4 iestatīšanas ceļvedis izskaidro, kā pareizi ieviest consent mode, lai Analytics aktivizētos tikai tad, kad tas atļauts.

Privātuma politikas prasības

Privātuma politikai jābūt rakstītai skaidrā, saprotamā valodā, nevis juridiskā žargonā, kas pārkopēts no kādas veidnes. Tai jānorāda, ka esat datu pārzinis, ar kontaktinformāciju, un jāuzskaita apkopotie personas datu veidi, kā arī katras apstrādes darbības mērķis un juridiskais pamats (piekrišana, leģitīmā interese, līgumiska nepieciešamība vai juridisks pienākums). Jānorāda trešās puses, kas saņem datus: hostinga pakalpojumu sniedzējs, analītikas serviss, maksājumu apstrādātājs, e-pasta mārketinga platforma. Jānorāda arī katras datu kategorijas saglabāšanas termiņi. Un lietotājiem jāsaprot, kā izmantot savas tiesības: piekļuve, labošana, dzēšana, pārnesamība un iebildums.

Sīkdatņu politika un privātuma politika ir atsevišķi dokumenti. Daudzām vietnēm ir viens bez otra, un dažām nav neviena, tikai neskaidra "mēs rūpējamies par jūsu privātumu" rindiņa kājenē.

Datu apstrādes līgumi

Katram trešās puses pakalpojumam, kas apstrādā personas datus jūsu vārdā, nepieciešams datu apstrādes līgums (DPA). Tas attiecas uz hostinga pakalpojumu sniedzēju, analītikas servisu, e-pasta mārketinga platformu un CRM. Lielākie pakalpojumu sniedzēji (AWS, Google, Mailchimp, HubSpot) piedāvā standarta DPA, ko var parakstīt elektroniski. Nodrošināt to noslēgšanu ir jūsu pienākums, nevis pakalpojumu sniedzēja. Mazāki ES hostinga uzņēmumi šo bieži neizvirza paši, tāpēc trūkstoši DPA ir gandrīz katras vietnes atklājums, kas izmanto reģionālu hostingu.

Tiesības uz dzēšanu

Lietotāji var pieprasīt savu personas datu dzēšanu. Nepieciešams dokumentēts process šādu pieprasījumu saņemšanai, pieprasītāja identitātes pārbaudei un datu dzēšanai no visām sistēmām 30 dienu laikā, ieskaitot rezerves kopijas, kur tehniski iespējams. Trešās puses, kuras saņēmušas datus, jāinformē, un pieprasījums kopā ar atbildi jādokumentē.

E-komercijas vietnēm tas ir sarežģītāk, jo var pastāvēt juridisks pienākums saglabāt noteiktus darījumu datus (rēķini, nodokļu uzskaite) 5-10 gadus saskaņā ar nacionālo grāmatvedības likumdošanu. Juridiskais pamats šo datu saglabāšanai pārspēj dzēšanas pieprasījumu, taču viss pārējais tāpat jāizdzēš. Šo līdzsvaru noturēt prasa dokumentētu datu saglabāšanas politiku, nevis tikai dzēšanas pogu.

SSL/HTTPS un datu drošība

GDPR pieprasa "atbilstošus tehniskus un organizatoriskus pasākumus" personas datu aizsardzībai. Praksē tas nozīmē: visas lapas jāapkalpo caur HTTPS ar derīgu sertifikātu. Paroles jāhešo ar bcrypt vai Argon2 (MD5 un SHA-1 vēl sastopami vecākās vietnēs un nav pieņemami). Sensitīvi personas datu lauki datubāzē jāšifrē miera stāvoklī. Piekļuve personas datiem jāierobežo pilnvarotam personālam ar piekļuves reģistrēšanu. Un drošības auditi jāveic regulāri, īpaši pēc nozīmīgiem programmatūras atjauninājumiem.

Kur slēpjas īstās atbilstības nepilnības

Iepriekš atzīmētas piekrišanas rūtiņas kontaktformās un biļetenu pieteikumos parādās regulāri. Piekrišanai jābūt apstiprinošai darbībai, tāpēc iepriekš atzīmēta rūtiņa nav derīga neatkarīgi no tā, ko nosaka jūsu noteikumi. Saistītā problēma ir apvienota piekrišana: mārketinga e-pasta pieraksts apvienots ar pakalpojumu noteikumu pieņemšanu vienā rūtiņā. Pēc GDPR šiem abiem jābūt atsevišķiem piekrišanas posmiem, un daudzi e-komercijas norēķinu procesi tos joprojām apvieno.

Pārsteidzoši bieži kontaktformu iesniegumi netiek uzskatīti par personas datiem. Tie ir personas dati, un tas nozīmē dokumentēt, cik ilgi tos glabājat un kāpēc. Saglabāšanas jautājums uzķer daudzas vietnes: "mūžīgi" nav derīgs saglabāšanas termiņš, taču faktiski tā darbojas daudzas vietnes, jo neviens nekonfigurēja automātisko dzēšanu un nekad par to nepadomāja.

Piekrišanas ierakstu nereģistrēšana rada vislielāko riska pakāpi regulatoru skatījumā. "Mēs parādījām banneri" nav dokumentācija. Jāspēj pierādīt, kad un kā katra konkrētā piekrišana iegūta, un tas prasa laika zīmogotu ierakstu par katru lietotāju katrā sesijā.

No nesen veiktas GDPR pārbaudes pirms tirgus paplašināšanās

Latvijas modes mazumtirgotājs lūdza pārbaudīt viņu GDPR stāvokli pirms plānotās paplašināšanās Vācijā un Zviedrijā. Atradām piecas problēmas. Google Analytics un Facebook Pixel aktivizējās pirms piekrišanas, neraugoties uz Cookiebot instalāciju, jo GTM konteiners nebija konfigurēts ar consent mode mainīgajiem. Ar Lietuvas hostinga pakalpojumu sniedzēju nebija noslēgts DPA. Privātuma politika nebija atjaunināta kopš 2019. gada un joprojām pieminēja Universal Analytics. Kontaktformu iesniegumi tika glabāti bezgalīgi bez saglabāšanas politikas. Un norēķinu procesa e-pasta ievākšana automātiski pievienoja klientus mārketinga sarakstam bez atsevišķas piekrišanas.

Visas piecas problēmas novērsām trīs nedēļu laikā. DPA bija vienkāršākais labojums, divdesmit minūšu e-pasta apmaiņa. Piekrišanas konfigurācija prasīja visvairāk laika, jo viņu GTM iestatījums bija jāpārbūvē no nulles ar consent mode mainīgajiem, kas kontrolē katra taga aktivizēšanos. Privātuma politikas atjaunināšana prasīja pilnu dienu, strādājot kopā ar vadības komandu.

Sarežģītākā GDPR atbilstības daļa parasti nav tehniskie labojumi. Tā ir datu plūsmu pietiekami laba dokumentēšana, lai zinātu, ko vācat, kur tas nonāk un kāpēc, pirms varat izlemt, ko aizsargāt vai dzēst. Sāciet ar šo inventarizāciju un tehniskā ieviešana seko dabiski. Mūsu IT konsultāciju pakalpojums ietver GDPR atbilstības pārbaudes, aptverot tehniskās ieviešanas pusi. Ja vērtējat, kura e-komercijas platforma labāk pārvalda ES atbilstības prasības, mūsu PrestaShop vs WooCommerce salīdzinājums apskata piekrišanas un datu apstrādes funkcijas, ko katra platforma nodrošina.