Actiunile de aplicare ale ICO impotriva organizatiilor din Marea Britanie au crescut brusc in 2024 si 2025, cu amenzi totalizand peste 12 milioane de lire sterline pe parcursul celor doi ani pentru deficiente in masurile de securitate tehnica. Tiparul din notificarile de aplicare ale ICO este consistent: organizatiile care au suferit o bresa si nu au putut demonstra ca au implementat controale tehnice adecvate au facut fata celor mai dure rezultate. Pentru dezvoltatori, aceasta este o preocupare profesionala directa. Deciziile pe care le luati cu privire la criptare, logare, controlul accesului si retentia datelor sunt controalele tehnice care determina daca o organizatie se poate apara in fata ICO.

Acest ghid este scris pentru dezvoltatori si echipe de inginerie, nu pentru departamentele juridice sau de conformitate. Traduce cerintele UK GDPR in decizii tehnice concrete: ce sa implementati, cum sa implementati si de ce exista fiecare masura.

Rezumat

  • Articolul 32 din UK GDPR solicita “masuri tehnice adecvate” proportionale cu riscul. Pentru majoritatea aplicatiilor care prelucreaza date cu caracter personal, aceasta inseamna criptarea in repaus si in tranzit, pseudonimizarea acolo unde este fezabila, controale ale accesului si capacitate documentata de detectare a breselor.
  • Cele mai frecvente greseli ale dezvoltatorilor care creeaza expunere la GDPR: logarea datelor personale in iesirea de debug, stergerea logica a inregistrarilor care ar trebui sterse definitiv pentru dreptul la stergere, si neimplementarea DPA-urilor cu fiecare serviciu tert care atinge datele personale.
  • Minimizarea datelor este o decizie de proiectare luata la nivel de camp. Daca nu aveti un motiv documentat pentru a colecta si stoca un camp, nu il colectati.
  • Dreptul la stergere necesita stergerea efectiva, in cascada prin toate sistemele, inclusiv backup-uri si procesori terti. Stergerea logica nu satisface obligatia.

UK GDPR vs. EU GDPR: ce se schimba pentru dezvoltatori

Dupa Brexit, Regatul Unit a pastrat cadrul EU GDPR ca “UK GDPR” prin European Union (Withdrawal) Act 2018. Pentru dezvoltatori, cerintele tehnice sunt identice. Diferentele sunt administrative: autoritatea de supraveghere din Regatul Unit este Information Commissioner’s Office (ICO), nu o autoritate nationala de protectie a datelor din UE, iar transferurile transfrontaliere intre Regatul Unit si UE sunt reglementate de decizia de adecvare a Regatului Unit (mentinuta in prezent de UE, desi revizuita periodic).

Implicatia practica este ca daca construiti software conform cu cerintele tehnice ale EU GDPR, satisface cerintele tehnice ale UK GDPR. Reciproca este de asemenea adevarata. Divergentele vor aparea in procedurile de notificare, mecanismele de transfer si indrumarea specifica de aplicare a ICO, care difera uneori in accent fata de indrumarea EDPB.

Articolul 32: ce solicita efectiv

Articolul 32 din UK GDPR solicita operatorilor si procesatorilor sa implementeze “masuri tehnice si organizatorice adecvate” pentru a asigura un nivel de securitate adecvat riscului, tinand cont de stadiul tehnicii, costurile de implementare si natura, sfera de aplicare, contextul si scopurile prelucrarii.

Acel limbaj este deliberat flexibil. Ce inseamna in practica depinde de profilul dvs. de risc, dar Articolul 32(1) ofera patru exemple specifice:

  1. Pseudonimizarea si criptarea datelor cu caracter personal
  2. Capacitatea de a asigura confidentialitatea, integritatea, disponibilitatea si rezistenta continue ale sistemelor si serviciilor de prelucrare
  3. Capacitatea de a restabili disponibilitatea si accesul la datele cu caracter personal in timp util dupa un incident fizic sau tehnic
  4. Un proces de testare, evaluare si apreciere regulata a eficacitatii masurilor de securitate

“Stadiul tehnicii” nu inseamna ca trebuie sa implementati solutia cea mai scumpa sau de ultima ora. Inseamna ca nu puteti justifica utilizarea unei abordari slabe (cum ar fi MD5 pentru hashing-ul parolelor) atunci cand abordari clar mai bune (cum ar fi Argon2) sunt bine stabilite, disponibile pe scara larga si nu sunt substantial mai scumpe de implementat.

Criptare in repaus

Parole. Nu stocati niciodata parolele in text clar si nu folositi niciodata MD5 sau SHA-1 pentru hashing-ul parolelor. Ambele sunt complet inadecvate. Folositi bcrypt cu un factor de lucru de cel putin 12, sau Argon2id cu parametri ajustati pentru a dura cel putin 100ms pe hardware-ul serverului. Argon2id este recomandarea actuala a OWASP si este preferabila pentru implementarile noi.

1# Argon2id with libsodium (Node.js example)
2const hash = await argon2.hash(password, {
3  type: argon2.argon2id,
4  memoryCost: 65536,   // 64 MB
5  timeCost: 3,
6  parallelism: 1
7});

Criptarea bazei de date. Activati criptarea in repaus la nivelul bazei de date. Toate bazele de date principale si serviciile gestionate (PostgreSQL, MySQL, MongoDB Atlas, AWS RDS, Azure SQL) suporta acest lucru. Criptarea transparenta a datelor (TDE) protejeaza datele de pe disc, dar nu protejeaza impotriva unui utilizator de baza de date compromis cu acces la interogari. Pentru campurile extrem de sensibile (numere de asigurare nationala, dosare medicale, numere de conturi financiare), luati in considerare criptarea campurilor la nivel de aplicatie folosind AES-256-GCM cu un serviciu de gestionare a cheilor (AWS KMS, Azure Key Vault, HashiCorp Vault). Cheia trebuie stocata separat de datele pe care le cripteaza.

Gestionarea cheilor. Nu codati direct cheile de criptare in codul aplicatiei si nu le stocati in aceeasi baza de date cu datele pe care le protejeaza. Folositi variabile de mediu pentru dezvoltare si un serviciu gestionat de gestionare a cheilor pentru productie. Rotiti cheile periodic si asigurati-va ca aplicatia dvs. poate gestiona rotatia cheilor fara timp de nefunctionare.

Ce sa nu faceti. Nu stocati date cu caracter personal in text clar in fisierele jurnal, fisierele temporare sau cache-urile aplicatiei unde criptarea poate sa nu se aplice. Verificati fiecare cale de cod care gestioneaza date cu caracter personal si asigurati-va ca nu pastreaza inadvertent copii necriptate.

Criptare in tranzit

Configuratia TLS. Aplicati TLS 1.2 ca minim, cu TLS 1.3 ca implicit acolo unde este suportat. Dezactivati complet SSLv3, TLS 1.0 si TLS 1.1. Pe nginx:

1ssl_protocols TLSv1.2 TLSv1.3;
2ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
3ssl_prefer_server_ciphers off;

HSTS. Setati antetul Strict-Transport-Security cu o valoare max-age lunga si includeSubDomains. Un max-age de cel putin 31536000 (un an) este standardul. Trimiteti la lista de preincarnare HSTS daca implementarea dvs. permite acest lucru.

1Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Continut mixt. Servirea oricarei resurse (imagini, scripturi, foi de stil, apeluri API) prin HTTP de pe o pagina HTTPS creeaza o vulnerabilitate de continut mixt si submineaza securitatea transportului. Configurati Content Security Policy pentru a bloca continutul mixt si verificati pagina dvs. pentru orice incarcari de resurse non-HTTPS.

Servicii interne. Criptarea in tranzit se aplica comunicarii interne serviciu-la-serviciu la fel ca traficul orientat catre utilizator. Conexiunile la baze de date, conexiunile la cozile de mesaje si apelurile la microservicii ar trebui sa foloseasca toate TLS. Multi dezvoltatori cripteaza corect stratul orientat catre utilizator si trec cu vederea reteaua interna.

Minimizarea datelor in cod

Minimizarea datelor nu este o abstractizare juridica. Este o decizie de proiectare luata camp cu camp. Inainte de a colecta orice date cu caracter personal, intrebati-va: aplicatia are intr-adevar nevoie de aceasta pentru a functiona? Daca nu puteti raspunde la aceasta intrebare cu un caz de utilizare specific, nu o colectati.

In practica aceasta inseamna:

  • Eliminati campurile de formular care sunt optionale si al caror scop este vag (“data nasterii” la o inscriere la newsletter unde nu aveti cerinta de verificare a varstei)
  • Auditati schema bazei de date in mod regulat si eliminati coloanele care contin date cu caracter personal fara utilizare activa
  • Setati perioadele de retentie la nivelul schemei acolo unde este posibil, folosind sarcini programate pentru a elimina automat inregistrarile expirate
  • Evitati colectarea datelor cu caracter personal extrem de sensibile (informatii despre sanatate, detalii financiare, opinii politice) cu exceptia cazului in care aplicatia dvs. le necesita cu adevarat, deoarece evaluarea riscului din Articolul 32 se extinde cu sensibilitatea datelor prelucrate

Principiul responsabilitatii ICO necesita sa puteti demonstra ca ati luat in considerare minimizarea datelor. Deciziile de proiectare documentate in arhitectura sau notele de sprint satisfac aceasta cerinta. Deciziile nedocumentate nu o satisfac.

Pseudonimizare

Pseudonimizarea inlocuieste informatiile direct identificatoare cu un token sau identificator care nu poate identifica individul fara acces la o cheie sau tabel de mapare pastrat separat. Articolul 32 il listeaza explicit ca masura tehnica recomandata, iar Articolul 89 prevede obligatii reduse pentru prelucrarea datelor pseudonimizate in scopuri de cercetare.

Pentru analitice si urmarirea comportamentului, un model comun este de a face hash identificatorilor de utilizator cu un salt specific site-ului folosind SHA-256 inainte de a-i transmite sistemului dvs. analitic:

1import hmac, hashlib
2
3def pseudonymise(user_id: str, site_secret: str) -> str:
4    return hmac.new(
5        site_secret.encode(),
6        user_id.encode(),
7        hashlib.sha256
8    ).hexdigest()

Salt-ul trebuie stocat separat de datele analitice. Fara el, hash-ul nu poate fi inversat pentru a identifica individul. Aceasta inseamna ca sistemul dvs. analitic contine numai identificatori pseudonimizati, reducand profilul de risc al unei brese a acelui sistem.

Pseudonimizarea nu este anonimizare. Daca detineti cheia de mapare, ICO trateaza datele pseudonimizate ca date cu caracter personal. Anonimizarea completa, unde re-identificarea nu este posibila chiar si cu informatii suplimentare disponibile in mod rezonabil, scoate datele complet din sfera GDPR. Obtinerea anonimizarii autentice este dificila in practica; majoritatea implementarilor produc date pseudonimizate, care inca intra sub incidenta GDPR dar cu risc redus.

Dreptul la stergere: implementarea corecta

Dreptul la stergere (Articolul 17) este una dintre cele mai solicitante tehnic obligatii GDPR de implementat corect. Cerintele sunt specifice:

Stergere definitiva, nu logica. Setarea unui indicator is_deleted si filtrarea lui din interogari nu satisface dreptul la stergere. Datele trebuie sa fie efectiv eliminate din baza de date. Construiti functionalitatea de stergere definitiva pentru fiecare entitate care contine date cu caracter personal.

Stergeri in cascada. Stergerea inregistrarii utilizatorului nu este suficienta daca datele cu caracter personal sunt de asemenea pastrate in tabele conexe (comenzi, adrese, jurnale de activitate, preferinte, fisiere incarcate). Mapati fiecare tabel care contine date cu caracter personal legate de un identificator de utilizator si asigurati-va ca stergerea cascadeaza corect, sau implementati un job de stergere explicit care elimina atomic toate datele asociate.

Procesori terti. Daca ati trimis date cu caracter personal catre un serviciu tert (platforma de email marketing, CRM, instrument analitic, procesor de plati), obligatia dvs. de stergere se extinde la instructarea acelui procesor sa stearga datele. Aceasta necesita:

  • Un inventar documentat al fiecarui serviciu tert care primeste date cu caracter personal
  • Un mecanism de stergere confirmat pentru fiecare (apel API, bilet de suport, gestionarea automatizata a cererilor persoanelor vizate)
  • Dovezi ca stergerea a fost finalizata

Backup-uri. Backup-urile sunt cea mai frecvent trecuta cu vederea problema de stergere. Daca faceti backup-uri zilnice ale bazei de date cu o perioada de retentie de 90 de zile, o cerere de stergere satisfacuta in baza de date activa nu va fi satisfacuta in backup-uri pana cand acestea expira. Pozitia ICO este ca backup-urile restaurate dupa stergere nu trebuie sa reintroduca datele cu caracter personal sterse. Abordari practice includ: excluderea inregistrarilor sterse din exporturile de backup acolo unde este fezabil, implementarea proceselor de curatare specifice backup-urilor, sau utilizarea criptarii la nivel de camp si stergerea cheii (facand datele ilizibile, ceea ce se apropie de standardul stergerii).

Exceptii. Dreptul la stergere nu este absolut. Puteti retine date necesare pentru revendicari legale, conformitate legala (de exemplu, inregistrari financiare conform Companies Act), sau scopuri de interes public. Documentati exceptia si comunicati-o persoanei vizate atunci cand respingeti sau indepliniti partial o cerere de stergere.

Detectarea breselor si cerinta de notificare in 72 de ore

Articolul 33 din UK GDPR solicita sa notificati ICO in termen de 72 de ore de la luarea la cunostinta a unei brese de date cu caracter personal care poate duce la riscuri pentru persoane fizice. Aceasta nu reprezinta 72 de ore de la producerea bresei. Reprezinta 72 de ore de la momentul in care ati luat la cunostinta. Aceasta distinctie creeaza un stimulent direct pentru a construi capacitate de detectare a breselor, deoarece ceasul incepe sa ticheasca cand o descoperiti.

Ce sa inregistrati pentru detectarea breselor. Arhitectura dvs. de logare ar trebui sa capteze:

  • Evenimente de autentificare: autentificari reusit si esuate, provocari MFA, resetari de parola
  • Esecuri de autorizare: cereri care au fost refuzate din cauza verificarilor de permisiuni
  • Accesul la date: cine a accesat ce date cu caracter personal si cand, in special exporturi in masa sau volume neobisnuite de interogari
  • Modificari de configuratie: modificari ale permisiunilor utilizatorilor, cheilor de criptare sau setarilor de retentie a datelor
  • Modele anormale: acces de la adrese IP neobisnuite sau la ore neobisnuite, citiri in volum mare din tabelele cu date cu caracter personal

Ce sa nu inregistrati. Nu inregistrati valorile datelor cu caracter personal in jurnalele de aplicatie. Jurnalele de depanare care inregistreaza corpuri complete de cerere, interogari de baza de date cu valori de parametri substituite sau date din formulare introduse de utilizator creeaza depozite secundare de date cu caracter personal care sunt dificil de gestionat si care sunt in sine in sfera GDPR. Inregistrati identificatori (ID-uri utilizator, ID-uri sesiune, ID-uri cerere) in loc de valori.

1# Gresit: inregistreaza adresa de email efectiva
2logger.debug(f"Login attempt for user {request.form['email']}")
3
4# Corect: inregistreaza numai un identificator
5logger.debug(f"Login attempt, user_id={user.id}, request_id={request_id}")

Planificarea raspunsului la brese. Logarea permite detectarea, dar aveti nevoie de un proces documentat pentru ce se intampla atunci cand detectati o bresa. Cine este notificat intern? Cine ia decizia de notificare ICO? Ce informatii trebuie sa contina notificarea ICO? Construiti acest proces inainte de a-l necesita.

Conformitatea API-urilor terte

Operator vs procesor. Daca folositi un serviciu tert care prelucreaza date cu caracter personal in numele dvs. (un furnizor de email tranzactional, un furnizor de infrastructura cloud, un procesor de plati), acesta este un procesor de date, iar dvs. sunteti operatorul. Sunteti responsabil pentru conformitatea lor cu UK GDPR in acel context.

Acorduri de procesare a datelor. Trebuie sa aveti incheiat un Acord de procesare a datelor (DPA) scris cu fiecare serviciu tert care prelucreaza date cu caracter personal in numele dvs. Majoritatea furnizorilor SaaS majori (AWS, Mailchimp, Stripe, Twilio, SendGrid) ofera DPA-uri standard. Semnati-le si pastrati-le. Daca un furnizor nu poate produce un DPA, nu il puteti folosi legal pentru a prelucra date cu caracter personal conform UK GDPR.

Sub-procesori. DPA-ul dvs. cu un procesor ar trebui sa listeze sub-procesorii acestuia (serviciile pe care le folosesc la randul lor pentru a prelucra datele dvs.). De exemplu, furnizorul dvs. de email tranzactional poate folosi infrastructura AWS. Nu sunteti obligat sa aveti un DPA direct cu sub-procesorii, dar trebuie sa stiti cine sunt si unde sunt prelucrate geografic datele in scopuri de conformitate cu transferul.

Mecanisme de transfer. Daca un serviciu tert prelucreaza date in afara Regatului Unit sau UE, aveti nevoie de un mecanism de transfer legal. Pentru transferurile din Regatul Unit, acestea sunt in prezent mecanisme specifice Regatului Unit (Acorduri internationale de transfer de date din Regatul Unit, sau bazarea pe decizii de adecvare ale Regatului Unit acolo unde sunt disponibile). Verificati optiunile de rezidenta a datelor si documentatia de transfer pentru fiecare serviciu.

Controlul accesului

Principiul privilegiului minim. Utilizatorii bazei de date folositi de aplicatia dvs. ar trebui sa aiba permisiunile minime necesare: citire si scriere pe tabele specifice, fara acces administrativ. Creati acreditative separate pentru baza de date pentru servicii cu citire intensa (raportare, analitica) si servicii cu scriere intensa (aplicatie orientata catre utilizator). Aceasta limiteaza raza de explozie a unei acreditative compromise.

Controlul accesului bazat pe roluri. Implementati RBAC in aplicatia dvs. si revizuiti atribuirile de roluri in mod regulat. Rolurile tind sa acumuleze permisiuni in timp; un audit periodic fata de ceea ce are nevoie fiecare rol detecteaza expansiunea privilegiilor.

Jurnale de audit pentru accesul la date. Pentru datele sensibile, implementati logarea de audit la nivelul stratului de aplicatie care inregistreaza ce utilizator autentificat a accesat ce inregistrare de date cu caracter personal si cand. Aceasta este separata de jurnalele de erori ale aplicatiei si ar trebui sa fie rezistenta la manipulare (write-once sau numai de adaugare, cu acces restrictionat din codul aplicatiei).

Lista de verificare pentru dezvoltatori: 10 controale tehnice de implementat

  1. Hashing-ul parolelor. Folositi bcrypt (factor de cost 12+) sau Argon2id. Eliminati imediat orice hashing de parola MD5 sau SHA-1.
  2. Criptare in repaus. Activati TDE la nivel de baza de date si implementati criptarea campurilor AES-256-GCM pentru datele cu caracter personal extrem de sensibile cu chei pastrate intr-un KMS gestionat.
  3. Configuratia TLS. Aplicati TLS 1.2 minim, TLS 1.3 implicit, HSTS cu max-age de un an, fara continut mixt.
  4. Auditul minimizarii datelor. Revizuiti fiecare camp din schema bazei de date care contine date cu caracter personal. Eliminati sau incetati sa colectati orice camp fara un caz de utilizare documentat si activ.
  5. Implementarea stergerii definitive. Construiti stergerea in cascada verificata pentru toate datele cu caracter personal legate de un utilizator. Testati ca stergerea elimina efectiv inregistrarile si nu doar le semnaleaza.
  6. Inventarul DPA-urilor terte. Listati fiecare SaaS sau serviciu cloud care primeste date cu caracter personal. Confirmati existenta unui DPA semnat pentru fiecare. Eliminati orice serviciu care nu poate furniza unul.
  7. Igiena logarii. Auditati jurnalele aplicatiei dvs. pentru date personale. Eliminati valorile datelor cu caracter personal din iesirea jurnalului la fiecare nivel de jurnal. Inregistrati numai identificatori.
  8. Logarea pentru detectarea breselor. Implementati logarea structurata pentru evenimentele de autentificare, esecurile de autorizare si accesul la date in masa. Configurati alerte pentru modele anormale.
  9. Revizuirea controlului accesului. Auditati acreditativele bazei de date si rolurile aplicatiei fata de principiul privilegiului minim. Eliminati accesul administrativ de la utilizatorii bazei de date ale aplicatiei.
  10. Pseudonimizare pentru analitica. Inlocuiti identificatorii directo de utilizator din apelurile analitice si de urmarire ale tertilor cu valori hash HMAC folosind un secret specific site-ului.

Puncte cheie

  • Cerintele tehnice ale UK GDPR sunt identice cu ale EU GDPR. Dupa Brexit, ICO le aplica si trebuie sa urmati indrumarea specifica ICO pentru notificari si transferuri.
  • Articolul 32 solicita masuri tehnice adecvate proportionale cu riscul dvs. Pentru majoritatea aplicatiilor, aceasta inseamna criptare puternica, controale ale accesului, pseudonimizare si detectare documentata a breselor.
  • Minimizarea datelor este o decizie la nivel de camp luata de dezvoltatori, nu o abstractizare juridica. Daca nu puteti justifica colectarea unui camp, nu il colectati.
  • Dreptul la stergere necesita stergerea efectiva in cascada prin toate sistemele, inclusiv backup-uri si procesori terti. Un indicator de stergere logica nu satisface obligatia.
  • Nu inregistrati valorile datelor cu caracter personal. Inregistrati identificatori. Fisierele jurnal sunt in sine un depozit de date cu caracter personal si unul dintre cei mai frecvent trecuti cu vederea vectori de bresa.
  • Aveti un DPA semnat cu fiecare serviciu tert care atinge datele cu caracter personal. Daca un furnizor nu poate produce unul, nu il puteti folosi legal in acel scop.

Intrebari frecvente (FAQ)

Se aplica UK GDPR daca toti utilizatorii mei se afla in afara Regatului Unit? UK GDPR se aplica daca sunteti stabilit in Regatul Unit, indiferent de locul unde se afla utilizatorii dvs. Se aplica de asemenea organizatiilor din afara Regatului Unit care ofera bunuri sau servicii persoanelor din Regatul Unit sau monitorizeaza comportamentul persoanelor din Regatul Unit. Daca sunteti un dezvoltator cu sediul in Regatul Unit care construieste pentru un public non-britanic, UK GDPR se aplica activitatilor dvs. de procesare.

Este criptarea obligatorie conform UK GDPR? Criptarea este mentionata explicit in Articolul 32(1)(a) ca masura recomandata. Nu este o cerinta absolut obligatorie, deoarece regulamentul solicita masuri “adecvate riscului”. In practica, pentru orice aplicatie care gestioneaza date cu caracter personal prin internet, ar fi foarte dificil sa justificati fata de ICO lipsa criptarii datelor in tranzit si in repaus. Tratati-o ca pe o cerinta obligatorie.

Ce conteaza ca bresa de date cu caracter personal care necesita notificarea ICO? O bresa de date cu caracter personal este orice distrugere accidentala sau ilegala, pierdere, alterare, divulgare neautorizata sau acces neautorizat la date cu caracter personal. Aceasta include un compartiment S3 configurat gresit care a expus inregistrari public, un atac de phishing care a oferit unui atacator acces la contul dvs. de email continand date de clienti si stergerea accidentala a inregistrarilor fara backup. Nu toate bresele necesita notificarea ICO: numai cele care pot duce la riscuri pentru persoane fizice. Bresele cu risc ridicat necesita de asemenea notificarea directa a persoanelor afectate.

Cat timp trebuie sa pastram datele cu caracter personal? UK GDPR nu specifica perioade de retentie. Trebuie sa pastrati datele numai atat timp cat este necesar pentru scopul pentru care au fost colectate. Definiti perioade de retentie pentru fiecare categorie de date pe care o detineti, documentati-le in avizul dvs. de confidentialitate si implementati curatarea automatizata. Inregistrarile financiare sunt de obicei pastrate sase ani conform Companies Act. Inregistrarile consimtamantului de marketing ar trebui pastrate pana cand consimtamantul este retras sau expira.

Avem nevoie de un responsabil cu protectia datelor? Un DPO este obligatoriu pentru autoritatile publice, organizatiile care prelucreaza date cu caracter personal sensibile la scara larga si organizatiile care efectueaza monitorizare sistematica la scara larga. Pentru majoritatea companiilor de software din Regatul Unit, un DPO nu este obligatoriu, dar este recomandat daca prelucrati volume semnificative de date cu caracter personal. ICO ofera indrumari specifice cu privire la acest prag pe site-ul lor web.

Care este amenda maxima pentru neconformitate cu UK GDPR? ICO poate emite amenzi de pana la 17,5 milioane de lire sterline sau 4% din cifra de afaceri anuala globala (oricare este mai mare) pentru cele mai grave incalcari. Amenzi de nivel inferior de pana la 8,7 milioane de lire sterline sau 2% din cifra de afaceri globala se aplica incalcarilor mai putin grave. In practica, majoritatea amenzilor ICO sunt semnificativ sub maximum si sunt calibrate in functie de severitatea bresei, cooperarea organizatiei si masurile luate pentru remedierea problemei.