GDPR atbilstības kontrolsaraksts vietņu īpašniekiem: pilna praktiskā rokasgrāmata

GDPR (General Data Protection Regulation) joprojām ir viena no stingrākajām un visaptverošākajām datu privātuma sistēmām pasaulē. Ja tu apstrādā ES iedzīvotāju personas datus — neatkarīgi no tā, vai vadi mazu blogu, e-veikalu vai SaaS — atbilstība nav izvēles lieta. Neatbilstības gadījumā sods var sasniegt līdz 20 miljoniem € vai 4% no globālā gada apgrozījuma (atkarībā no tā, kurš skaitlis ir lielāks).

Šajā rakstā es salieku vienā vietā pilnu GDPR atbilstības kontrolsarakstu vietņu īpašniekiem un izstrādātājiem: kas ir jāsakārto datos, procesos, piekrišanās mehānismos, lietotāju tiesību izpildē, kā arī ko īpaši pārbaudīt WordPress vidē. Katrā sadaļā saglabāju arī atsauces uz atbilstošajiem GDPR pantiem (Article 6, 7, 12, 13 u.c.), lai ir vieglāk piesiet prasības konkrētam normatīvajam pamatojumam.

Kas ir GDPR (un uz ko tas attiecas)?

GDPR ir Eiropas Savienības regula, kas ir spēkā kopš 2018. gada 25. maija. Tā definē, kā organizācijas drīkst vākt, izmantot, glabāt un nodot tālāk personas datus. Būtiski: GDPR attiecas ne tikai uz uzņēmumiem ES, bet arī uz organizācijām ārpus ES, ja tās apstrādā ES iedzīvotāju personas datus.

Pirms sāc: saproti savu lomu (Controller/Processor)

GDPR terminoloģija vietņu pasaulē bieži šķiet “juridiska”, bet tehniskajā praksē tā palīdz saprast atbildību robežas.

• Data Controller (pārzinis): organizācija, kas nosaka, kāpēc un kā personas dati tiks apstrādāti. Parasti tas ir vietnes/biznesa īpašnieks, kas lemj par formām, mārketingu, analītiku u.tml. Pārzinim ir primārā atbildība par atbilstību.
• Data Processor (apstrādātājs): trešā puse, kas apstrādā datus pārziņa vārdā (piem., hostings, e-pasta sūtīšanas serviss, CRM). Arī apstrādātājam jāievieš atbilstoši tehniskie un organizatoriskie pasākumi.
• Data Subject (datu subjekts): persona, kuras dati tiek apstrādāti. GDPR mērķis ir aizsargāt tieši datu subjekta tiesības.

Svarīga nianse: vienā biznesā tu vari būt gan pārzinis, gan apstrādātājs (atkarībā no konkrētā datu plūsmas scenārija).

7 GDPR pamatprincipi, kas jāņem vērā visur

Pirms ķeries pie kontrolsaraksta, ir vērts nostiprināt bāzi — šie 7 principi praktiski nosaka, kā “pareizi” dizainēt datu plūsmas, UI un procesus:

1. Lawfulness, fairness, and transparency: apstrādā datus likumīgi un godprātīgi, un skaidri informē cilvēkus, kāpēc un kā dati tiks lietoti.
2. Purpose limitation: vāc datus tikai konkrētam, leģitīmam mērķim.
3. Data minimization: vāc tikai minimumu, kas ir nepieciešams.
4. Accuracy: dati jāuztur precīzi un aktuāli.
5. Storage limitation: neglabā ilgāk, nekā nepieciešams.
6. Integrity and confidentiality: aizsargā datus pret nesankcionētu piekļuvi ar atbilstošiem drošības pasākumiem.
7. Accountability: spēj pierādīt, ka ievēro atbilstību (ne tikai “domā, ka ievēro”).

Pilns GDPR atbilstības kontrolsaraksts (ar pantiem)

Dati

1) Tev ir saraksts ar visiem personas datu tipiem, avotiem, koplietošanu, nolūkiem un glabāšanas termiņiem (Controller, Processor)

Praktiski tas nozīmē: uzskaiti nevis tikai “mums ir lietotāji”, bet konkrētos datu laukus (kolonnas) — piemēram, vārds, e-pasts, adrese, identifikatori utt. Katram tipam dokumentē: no kurienes tas nāk, ar ko dalies, ko tieši dari ar šo datu tipu un cik ilgi glabāsi.

Reference: GDPR Article 30 – Records of processing activities

2) Tev ir saraksts ar vietām, kur glabā personas datus, un datu plūsma starp tām (Controller, Processor)

Šeit ietilpst gan klasiskās datubāzes (piem., MySQL), gan ārējie servisi, gan arī offline glabātuves (piem., papīra dokumenti). Galvenais — saprast, kur dati reāli “dzīvo” un kā tie pārvietojas.

Reference: GDPR Article 30 – Records of processing activities

3) Tev ir publiski pieejama Privacy Policy, kas apraksta visus procesus ar personas datiem (Controller, Processor)

Privātuma politikā ir jāatspoguļo visi procesi, kas skar personas datu apstrādi. Tajā jāiekļauj (vai jāieliek saites uz) datu tipi, kurus glabā, un vietas/sistēmas, kur tie tiek glabāti.

Reference: GDPR Article 30 – Records of processing activities

4) Privātuma politikā ir norādīts likumīgais pamats (lawful basis), kāpēc apstrādā personas datus (Controller)

Tev ir jāspēj izskaidrot “kāpēc mums tas ir vajadzīgs” juridiskā nozīmē — piemēram, līguma izpilde (pasūtījuma apstrāde), leģitīmās intereses utt.

Reference: GDPR Article 6 – Lawfulness of processing

Atbildība un pārvaldība (Accountability & Management)

5) Ir iecelts DPO (Data Protection Officer) tad, ja tas ir obligāti (Controller, Processor)

DPO (datu aizsardzības speciālists) ir obligāts tikai 3 gadījumos:

1. Apstrādi veic valsts iestāde vai institūcija (izņemot tiesas, kas darbojas tiesu varas ietvaros).
2. Biznesa pamatdarbības ietver apstrādi, kas pēc būtības, apjoma un/vai mērķa prasa regulāru un sistemātisku datu subjektu uzraudzību lielā mērogā.
3. Biznesa pamatdarbības ietver lielā mērogā īpašu kategoriju (sensitīvu) datu apstrādi saskaņā ar Article 9, kā arī personas datus par sodāmību un pārkāpumiem saskaņā ar Article 10.

Ja DPO ir vajadzīgs, viņam jāorientējas GDPR vadlīnijās un arī jāsaprot iekšējie procesi, kuros tiek lietoti personas dati.

Reference: GDPR Article 37 – Designation of the data protection officer

6) Lēmumu pieņēmējiem organizācijā ir izpratne par GDPR prasībām (Controller, Processor)

Tehniski pareizi risinājumi bieži “salūzt” pie biznesa lēmumiem (mārketings, integrācijas, datu eksports). Tāpēc atslēgas cilvēkiem zināšanām jābūt aktuālām.

Reference: GDPR Article 25 – Data protection by design and by default

7) Tehniskā drošība ir atjaunināta un atbilst mūsdienu līmenim (Controller, Processor)

SaaS un tīmekļa produktiem parasti ir vērts balstīties uz drošības checklist’iem kā starta punktu, lai pārliecinātos, ka tehniskie pasākumi reāli ir ieviesti, nevis tikai aprakstīti dokumentos.

Reference: GDPR Article 25 – Data protection by design and by default

8) Darbinieki ir apmācīti datu aizsardzībā (Processor)

Daļa drošības incidentu notiek tāpēc, ka kāds ar piekļuvi iekšējām sistēmām netīši palīdz uzbrukumam (phishing, sociālā inženierija, nejauša datu noplūde). Apmācībām ir jābūt reālām un regulārām.

Reference: GDPR Article 25 – Data protection by design and by default

9) Tev ir sub-processor saraksts, un Privacy Policy skaidri min šo sub-processor izmantošanu (Processor)

Ja tu kā apstrādātājs izmanto apakšapstrādātājus (sub-processors), klientiem par to ir jāzina un tiem jāpiekrīt (praktiski — pieņemot tavu privātuma politiku/terms, atkarībā no modeļa).

Reference: GDPR Article 28 – Processor

10) Ja strādā ārpus ES, bet apstrādā ES iedzīvotāju datus, ir iecelts pārstāvis ES (Controller, Processor)

Ja bizness ir ārpus ES un tomēr vāc/apstrādā ES iedzīvotāju datus, ir jānorīko pārstāvis kādā dalībvalstī. Šim pārstāvim jāspēj risināt ar apstrādi saistītie jautājumi, un uzraudzības iestādēm jābūt iespējai ar viņu sazināties.

Reference: GDPR Article 27 – Representatives of controllers or processors not established in the Union

11) Personas datu pārkāpumi tiek ziņoti uzraudzības iestādei un datu subjektiem (Controller, Processor)

Ja notiek personas datu pārkāpums, tas jāziņo uzraudzības iestādei 72 stundu laikā. Ziņojumā jānorāda, kādi dati ir zaudēti/noplūduši, kādas ir sekas un kādi pretpasākumi veikti. Ja noplūdušie dati nav bijuši šifrēti, par incidentu parasti jāinformē arī paši datu subjekti, kuru dati skarti.

Reference: GDPR Article 33 – Notification of a personal data breach to the supervisory authority; GDPR Article 34 – Communication of a personal data breach to the data subject

12) Ir līgumi ar visiem apstrādātājiem, kam nodod datus (piem., hostings) (Controller)

Ja tu nodod datus apstrādātājam, līgumā ir jābūt skaidrām instrukcijām par to, kā apstrādātājs drīkst glabāt/apstrādāt datus. Līgumam jādefinē: apstrādes priekšmets un ilgums, apstrādes veids un mērķis, personas datu tipi, datu subjektu kategorijas, kā arī pārziņa tiesības un pienākumi.

Tas pats princips attiecas arī uz situāciju, kad apstrādātājs piesaista sub-processor, lai palīdzētu izpildīt apstrādi pārziņa vārdā.

Reference: GDPR Article 28 – Processor; GDPR Article 29 – Processing under the authority of the controller or processor

Jaunās tiesības (New Rights) — ko lietotājam jāspēj izdarīt

13) Lietotājs var viegli pieprasīt piekļuvi saviem personas datiem (Controller, Processor)

Tev jābūt skaidram procesam, kā apstrādā datu subjekta piekļuves pieprasījumus (access requests) — gan organizatoriski, gan tehniski.

Reference: GDPR Article 15 – Right of access by the data subject

14) Lietotājs var viegli labot savus datus, lai tie būtu precīzi (Controller, Processor)

Nodrošini mehānismu, kā lietotājs var izlabot neprecīzus datus (piem., profilā) vai kā to var izdarīt, iesniedzot pieprasījumu.

Reference: GDPR Article 16 – Right to rectification

15) Tu automātiski dzēs datus, kas vairs nav vajadzīgi (Controller, Processor)

Praksē šeit bieži “iekārtojas” tehniskais parāds: dati krājas bez termiņiem. Mērķis ir automatizēt dzēšanu, piemēram, dzēst klientu datus, ja līgums nav atjaunots un nav cita likumīga pamata glabāšanai.

Reference: GDPR Article 5 – Principles relating to processing of personal data

16) Lietotājs var viegli pieprasīt savu datu dzēšanu (“right to be forgotten”) (Controller, Processor)

Tev jābūt procesam “dzēšanas pieprasījumiem” (erasure requests) un skaidriem soļiem, kā dzēšana tiek izpildīta sistēmās (arī integrācijās), ja vien nav citu tiesisku iemeslu datus paturēt.

Reference: GDPR Article 17 – Right to erasure (‘right to be forgotten’)

17) Lietotājs var viegli pieprasīt apstrādes ierobežošanu (Controller, Processor)

Tas nozīmē iespēju apturēt noteiktus apstrādes veidus, ja lietotājs to prasa un ir pamats. Tehniski bieži tas ir “flag” + darbību atslēgšana (piem., mārketinga sūtījumi).

Reference: GDPR Article 18 – Right to restriction of processing

18) Lietotājs var pieprasīt savu datu izsniegšanu sev vai trešajai pusei (Controller, Processor)

Datu pārnesamība nozīmē: dati jāizsniedz strukturētā, plaši izmantotā un mašīnlasāmā formātā, lai cilvēks tos varētu pārcelt pie cita pakalpojuma sniedzēja.

Reference: GDPR Article 20 – Right to data portability

19) Lietotājs var iebilst pret profilēšanu vai automatizētu lēmumu pieņemšanu, kas viņu ietekmē (Controller)

Šis punkts ir aktuāls tikai tad, ja tavā biznesā tiešām notiek profilēšana vai automatizēta lēmumu pieņemšana (piem., scoring, automātiska atteikšana u.tml.).

Reference: GDPR Article 22 – Automated individual decision-making, including profiling

Piekrišana (Consent)

20) Ja apstrāde balstās uz piekrišanu, tai jābūt brīvprātīgai, konkrētai, informētai un atsaucamai (Controller)

Ja vietne vāc personas datus un pamats ir piekrišana, blakus ir jābūt skaidrai saitei uz privātuma politiku un lietotājam jāveic aktīva darbība, lai piekristu. Iepriekš atķeksētas izvēles (pre-ticked checkboxes) nav atļautas, jo piekrišanai jābūt nepārprotami apstiprinošai.

Reference: GDPR Article 7 – Conditions for consent

21) Privātuma politika ir uzrakstīta skaidri un saprotami (Controller)

Tekstam jābūt vienkāršam, nepārprotamam un nedrīkst slēpt nolūku. Ja tas nav ievērots, piekrišana var tikt atzīta par nederīgu. Ja sniedz pakalpojumus bērniem, tekstam jābūt saprotamam arī viņiem.

Reference: GDPR Article 7.2 – Conditions for consent

22) Atsaukt piekrišanu ir tikpat viegli, kā to iedot (Controller)

Ja piekrišana tiek dota ar vienu klikšķi, arī atsaukšanai nevajadzētu būt “slepenā” iestatījumu lapā ar pieciem soļiem.

Reference: GDPR Article 7.3 – Conditions for consent

23) Ja apstrādā bērnu datus, pārbaudi vecumu un prasi aizbildņa piekrišanu (Controller)

Bērniem, kas jaunāki par 16 gadiem, ir jānodrošina, ka piekrišanu dod likumīgais aizbildnis. Ja piekrišana tiek iegūta vietnē, tev jāmēģina pārliecināties, ka apstiprinājumu tiešām sniedzis aizbildnis, nevis pats bērns.

Reference: GDPR Article 8 – Conditions applicable to child’s consent in relation to information society services

24) Atjauninot privātuma politiku, tu informē esošos klientus (Controller)

Praktisks piemērs: e-pasts ar gaidāmajām izmaiņām un vienkāršu izklāstu, kas ir mainījies.

Reference: GDPR Article 7 – Conditions for consent

Pēcpārbaude (Follow-up)

25) Tu regulāri pārskati politikas, efektivitāti, datu apstrādes izmaiņas un izmaiņas valstīs, uz kurām plūst dati (Controller)

GDPR atbilstība nav vienreizējs uzdevums. Mainās integrācijas, rīki, datu plūsmas, kā arī starptautiskais regulējums. Regulārs pārskats ir daļa no “privacy by design/default” domāšanas.

Reference: GDPR Article 25 – Data protection by design and by default

Īpašie gadījumi (Special Cases)

26) Tu saproti, kad jāveic DPIA augsta riska apstrādei (sensitīvi dati u.c.) (Controller)

DPIA (Data Protection Impact Assessment) parasti kļūst aktuāla, ja notiek lielā mērogā sensitīvu datu apstrāde, profilēšana vai cita darbība, kas rada augstu risku cilvēku tiesībām un brīvībām.

Reference: GDPR Article 35 – Data protection impact assessment

27) Datus ārpus ES nodod tikai uz valstīm ar atbilstošu aizsardzības līmeni, un to atklāj privātuma politikā (Controller, Processor)

Ja ir datu plūsmas uz trešajām valstīm, privātuma politikā tās ir jāatspoguļo. Ja valsts netiek uzskatīta par “adequate”, datu nodošanai tipiski izmanto Standard Contractual Clauses (SCCs) vai Binding Corporate Rules (BCRs).

Reference: GDPR Article 45 – Transfers on the basis of an adequacy decision

Datu subjekta tiesības (User Rights): ko tev jānodrošina lietotājam

Zemāk ir tiesību kopums, kas attiecas uz visiem Data Subjects (personām, kuru dati tiek apstrādāti). Šeit es to atstāju kā praktisku “atgādinājuma” sadaļu — daudz kas jau pārklājas ar iepriekšējiem punktiem, bet panti un nosacījumi ir svarīgi, lai korekti noformētu procesu un komunikāciju.

Tiesības uz caurspīdīgu informāciju

Pārzinim jānodrošina informācija par apstrādi kodolīgi, caurspīdīgi, saprotami un viegli pieejami, izmantojot skaidru valodu (īpaši, ja informācija adresēta bērnam). Informāciju var sniegt rakstiski vai citā veidā (arī elektroniski, ja piemērojams).

Reference: GDPR Article 12

Tiesības saņemt konkrētu informāciju, ja dati tiek iegūti tieši no personas

Ja personas dati tiek ievākti tieši no datu subjekta, jāsniedz vismaz šāda informācija:

1. Pārziņa identitāte un kontaktinformācija
2. Datu aizsardzības speciālista (DPO) kontaktinformācija (ja piemērojams)
3. Apstrādes mērķi un juridiskais pamats
4. Pārziņa leģitīmās intereses (ja piemērojams)
5. Personas datu saņēmēji vai saņēmēju kategorijas
6. Informācija par nodošanu uz trešajām valstīm

Reference: GDPR Article 13

Tiesības saņemt konkrētu informāciju, ja dati netiek iegūti tieši no personas

Ja dati tiek iegūti no cita avota, joprojām jāsniedz līdzīga informācija, tostarp jānorāda attiecīgo personas datu kategorijas un datu avots.

Reference: GDPR Article 14

Piekļuves tiesības (Right of access)

Personai ir tiesības saņemt apstiprinājumu, vai viņas dati tiek apstrādāti, un piekļuvi vismaz šādai informācijai:

• Apstrādes mērķi
• Attiecīgo personas datu kategorijas
• Saņēmēji, kuriem dati ir izpausti vai tiks izpausti
• Plānotais glabāšanas termiņš
• Tiesību esamība: labošana, dzēšana, ierobežošana un iebildums
• Tiesības iesniegt sūdzību uzraudzības iestādē
• Informācija par datu avotu (ja dati nav iegūti no datu subjekta)
• Automatizētas lēmumu pieņemšanas esamība, tostarp profilēšana

Reference: GDPR Article 15

Tiesības uz labošanu (Right to rectification)

Personai ir tiesības bez nepamatotas kavēšanās labot neprecīzus personas datus un papildināt nepilnīgus datus.

Reference: GDPR Article 16

Tiesības uz dzēšanu (“right to be forgotten”)

Personai ir tiesības panākt datu dzēšanu, ja:

1. Dati vairs nav nepieciešami sākotnējam mērķim
2. Persona atsauc piekrišanu un nav cita juridiska pamata apstrādei
3. Persona iebilst apstrādei un nepastāv pārāki leģitīmi pamati turpināt apstrādi
4. Dati ir apstrādāti nelikumīgi
5. Dati jādzēš, lai izpildītu juridisku pienākumu
6. Dati tika ievākti saistībā ar informācijas sabiedrības pakalpojumiem, kas piedāvāti bērnam

Reference: GDPR Article 17

Tiesības uz apstrādes ierobežošanu (Right to restriction of processing)

Personai ir tiesības panākt apstrādes ierobežošanu, ja:

1. Persona apstrīd datu precizitāti (uz periodu, kas ļauj pārzinim pārbaudīt)
2. Apstrāde ir nelikumīga un persona iebilst dzēšanai
3. Pārzinim dati vairs nav vajadzīgi, bet personai tie nepieciešami juridisku prasību celšanai/aizstāvībai
4. Persona ir iebildusi apstrādei, kamēr tiek pārbaudīti leģitīmie pamati

Reference: GDPR Article 18

Tiesības tikt informētam par labošanu, dzēšanu vai ierobežošanu

Pārzinim jāinformē katrs saņēmējs, kuram dati izpausti, par labošanu, dzēšanu vai apstrādes ierobežošanu, ja vien tas nav neiespējami vai neprasa nesamērīgas pūles.

Reference: GDPR Article 19

Tiesības uz datu pārnesamību (Right to data portability)

Personai ir tiesības saņemt savus datus strukturētā, plaši izmantotā un mašīnlasāmā formātā un nodot tos citam pārzinim bez kavēšanas.

Reference: GDPR Article 20

Tiesības iebilst (Right to object)

Personai ir tiesības jebkurā laikā iebilst pret apstrādi, kas balstīta uz leģitīmām interesēm vai sabiedrības interesēm, ieskaitot profilēšanu, pamatojoties uz savu konkrēto situāciju.

Reference: GDPR Article 21

Tiesības netikt pakļautam automatizētai lēmumu pieņemšanai

Personai ir tiesības netikt pakļautai lēmumam, kas balstīts tikai uz automatizētu apstrādi (tostarp profilēšanu), ja tas rada juridiskas sekas vai līdzīgi būtiski ietekmē personu.

Reference: GDPR Article 22

Praktiskie ieviešanas soļi (no drošības līdz e-pastiem)

1) Nostiprini vietnes drošību

Liela daļa GDPR atbilstības praksē sākas ar elementāru drošību un datu minimizāciju. Konkrēts checklists:

• Uzstādi SSL sertifikātu (HTTPS), lai šifrētu datu plūsmu starp vietni un serveri
• Izmanto stipras paroles visiem admin kontiem
• Pievieno papildu aizsardzību maksājumu informācijas apstrādei
• Izmanto CDN pakalpojumu sniedzēju ar DDoS aizsardzību
• Ievies anti-vīrusu risinājumu, lai novērstu nesankcionētu piekļuvi
• Samazini datu vākšanu — vākt tikai nepieciešamo
• Pseudonimizē vai anonimizē personas datus pirms glabāšanas (kur iespējams)
• Veido rezerves kopijas vairākās drošās lokācijās
• Dzēs datus, kad tie vairs nav vajadzīgi

2) Pievieno sīkdatņu (cookie) piekrišanas baneri

Ja vietnē ir ne-obligātas sīkdatnes (piem., mārketinga vai detalizēta analītika), tev vajag skaidru piekrišanu pirms to aktivizēšanas.

Sīkdatņu banerim jāizpilda šādas prasības:

• Bloķē sīkdatnes līdz piekrišanai: ielādē tikai obligātās sīkdatnes, kamēr lietotājs nav apstiprinājis pārējās
• Vienkārša, skaidra valoda: paskaidro, kādas sīkdatnes tiek lietotas un kāpēc
• Vienlīdz redzamas Accept/Reject pogas: nedeformē izvēli, neslēp “Reject”
• Granulāras opcijas: ļauj izvēlēties kategorijas, nevis tikai “viss vai nekas”
• Iespēja atsaukt piekrišanu: viegli mainīt izvēli arī vēlāk
• Piekrišanas pieraksts: glabā izvēli ar laika zīmogu, lai spētu pierādīt atbilstību

3) Pārskati visas vietnes formas (contact, checkout, lead forms u.c.)

Jebkurai formai, kas vāc personas datus, jābūt sakārtotai GDPR garā:

• Pievieno privātuma paziņojumu, kas paskaidro, kāpēc dati nepieciešami
• Pievieno neatķeksētu piekrišanas checkbox (ja pamats ir consent)
• Mārketingam nodrošini atsevišķu opt-in (ne “vienā paketē” ar formas nosūtīšanu)
• Ieliec saiti uz Privacy Policy
• Lieto skaidru un vienkāršu valodu

4) Iegūsti korektu piekrišanu mārketinga e-pastiem

E-pasta mārketingā visbiežāk klūp tieši piekrišanas un pierādāmības aspekts. Praktiskais checklists:

• Tikai skaidrs opt-in: neatķeksēts checkbox tieši e-pasta piekrišanai
• Double opt-in: apstiprinājums caur e-pastu pēc pieteikšanās
• Piekrišanas pieraksti: logi ar datumu, laiku, metodi un mērķi
• Redzama atteikšanās saite: one-click unsubscribe katrā e-pastā
• Ātra atteikumu apstrāde: ideāli 24 stundu laikā

5) Esi gatavs datu noplūdei (data breach)

Incidenti notiek arī sakārtotās sistēmās. Lai “accountability” būtu reāla, sagatavo procesu iepriekš:

• Paziņo uzraudzības iestādei 72 stundu laikā
• Informē skartos lietotājus, ja risks viņu tiesībām ir augsts
• Dokumentē visu (kas notika, kad, kādas sistēmas, kādi dati)
• Atjaunini politikas un pasākumus, lai mazinātu atkārtošanās risku

WordPress specifika: ko pārbaudīt īpaši rūpīgi

WordPress ekosistēmā GDPR atbilstība parasti sadalās starp core iespējas, spraudņu uzvedību un to, ko tu reāli esi konfigurējis.

• Uzturi atjauninātu WordPress core, tēmas un spraudņus
• Izmanto kontaktformu spraudņus, kas atbalsta piekrišanas checkbox un skaidru privātuma tekstu
• Ievies korektu cookie consent risinājumu
• Izvēlies GDPR saderīgu analytics risinājumu (un pārbaudi, kādi dati tiek sūtīti)
• Pārskati spraudņu datu vākšanas praksi (daži sūta telemetriju vai integrē trešo pušu skriptus)
• Ievies lietotāju datu eksporta/dzēšanas funkcionalitāti (praktiski — lai izpildītu pieprasījumus)

Sodi un sekas (ne tikai nauda)

GDPR soda apmēri tiek iedalīti divos “līmeņos”:

• Lower tier violations: līdz 10 miljoniem € vai 2% no globālā gada apgrozījuma
• Upper tier violations: līdz 20 miljoniem € vai 4% no globālā gada apgrozījuma

Papildus naudassodiem uzraudzības iestādes var:

• Izteikt brīdinājumus
• Pagaidu vai pastāvīgi aizliegt personas datu apstrādi
• Uzlikt par pienākumu dzēst datus
• Ierobežot datu nodošanu (t.sk. starp valstīm)

BUJ: biežākie jautājumi par GDPR atbilstību

Kas ir GDPR atbilstības kontrolsaraksts?

Tas ir darbību saraksts, kas palīdz sistemātiski ieviest prasības, kuras izriet no General Data Protection Regulation. Praktiski tas palīdz atrast “caurumus” datu aizsardzības praksē un sakārtot procesus.

Kurš ir atbildīgs par GDPR ievērošanu?

Primārā atbildība parasti ir data controller (bieži — vietnes vai biznesa īpašnieks). Taču arī data processors ir savi atbilstības pienākumi.

Vai GDPR attiecas uz ASV uzņēmumiem?

Jā — ja tu apstrādā ES iedzīvotāju personas datus, neatkarīgi no tā, kur atrodas tavs bizness.

Kāds ir maksimālais sods par neatbilstību?

Līdz 20 miljoniem € vai 4% no globālā gada apgrozījuma (atkarībā no tā, kurš skaitlis ir lielāks).

Vai man vajag cookie baneri?

Jā, ja vietnē ir jebkādas ne-obligātas sīkdatnes un tev ir ES apmeklētāji.

Vai man vajag DPO (Data Protection Officer)?

Tikai tad, ja: (1) esi publiska iestāde; vai (2) pamatdarbība ir liela mēroga, regulāra un sistemātiska personu uzraudzība; vai (3) lielā mērogā apstrādā sensitīvus datus vai datus par sodāmību/pārkāpumiem.