Acțiunile de aplicare ale ICO împotriva organizațiilor din Marea Britanie au crescut brusc în 2024 și 2025, cu amenzi totalizând peste 12 milioane de lire sterline pe parcursul celor doi ani pentru deficiențe în măsurile de securitate tehnică. Tiparul din notificările de aplicare ale ICO este consistent: organizațiile care au suferit o breșă și nu au putut demonstra că au implementat controale tehnice adecvate au făcut față celor mai dure rezultate. Pentru dezvoltatori, aceasta este o preocupare profesională directă. Deciziile pe care le luați cu privire la criptare, logare, controlul accesului și retenția datelor sunt controalele tehnice care determină dacă o organizație se poate apăra în fața ICO.

Acest ghid este scris pentru dezvoltatori și echipe de inginerie, nu pentru departamentele juridice sau de conformitate. Traduce cerințele UK GDPR în decizii tehnice concrete: ce să implementați, cum să implementați și de ce există fiecare măsură.

Rezumat

  • Articolul 32 din UK GDPR solicită “măsuri tehnice adecvate” proporționale cu riscul. Pentru majoritatea aplicațiilor care prelucrează date cu caracter personal, aceasta înseamnă criptarea în repaus și în tranzit, pseudonimizarea acolo unde este fezabilă, controale ale accesului și capacitate documentată de detectare a breșelor.
  • Cele mai frecvente greșeli ale dezvoltatorilor care creează expunere la GDPR: logarea datelor personale în ieșirea de debug, ștergerea logică a înregistrărilor care ar trebui șterse definitiv pentru dreptul la ștergere, și neimplementarea DPA-urilor cu fiecare serviciu terț care atinge datele personale.
  • Minimizarea datelor este o decizie de proiectare luată la nivel de câmp. Dacă nu aveți un motiv documentat pentru a colecta și stoca un câmp, nu îl colectați.
  • Dreptul la ștergere necesită ștergerea efectivă, în cascadă prin toate sistemele, inclusiv backup-uri și procesori terți. Ștergerea logică nu satisface obligația.

UK GDPR vs. EU GDPR: ce se schimbă pentru dezvoltatori

După Brexit, Regatul Unit a păstrat cadrul EU GDPR ca “UK GDPR” prin European Union (Withdrawal) Act 2018. Pentru dezvoltatori, cerințele tehnice sunt identice. Diferențele sunt administrative: autoritatea de supraveghere din Regatul Unit este Information Commissioner’s Office (ICO), nu o autoritate națională de protecție a datelor din UE, iar transferurile transfrontaliere între Regatul Unit și UE sunt reglementate de decizia de adecvare a Regatului Unit (menținută în prezent de UE, deși revizuită periodic).

Implicația practică este că dacă construiți software conform cu cerințele tehnice ale EU GDPR, satisface cerințele tehnice ale UK GDPR. Reciproca este de asemenea adevărată. Divergențele vor apărea în procedurile de notificare, mecanismele de transfer și îndrumarea specifică de aplicare a ICO, care diferă uneori în accent față de îndrumarea EDPB.

Articolul 32: ce solicită efectiv

Articolul 32 din UK GDPR solicită operatorilor și procesatorilor să implementeze “măsuri tehnice și organizatorice adecvate” pentru a asigura un nivel de securitate adecvat riscului, ținând cont de stadiul tehnicii, costurile de implementare și natura, sfera de aplicare, contextul și scopurile prelucrării.

Acel limbaj este deliberat flexibil. Ce înseamnă în practică depinde de profilul dvs. de risc, dar Articolul 32(1) oferă patru exemple specifice:

  1. Pseudonimizarea și criptarea datelor cu caracter personal
  2. Capacitatea de a asigura confidențialitatea, integritatea, disponibilitatea și rezistența continue ale sistemelor și serviciilor de prelucrare
  3. Capacitatea de a restabili disponibilitatea și accesul la datele cu caracter personal în timp util după un incident fizic sau tehnic
  4. Un proces de testare, evaluare și apreciere regulată a eficacității măsurilor de securitate

“Stadiul tehnicii” nu înseamnă că trebuie să implementați soluția cea mai scumpă sau de ultimă oră. Înseamnă că nu puteți justifica utilizarea unei abordări slabe (cum ar fi MD5 pentru hashing-ul parolelor) atunci când abordări clar mai bune (cum ar fi Argon2) sunt bine stabilite, disponibile pe scară largă și nu sunt substanțial mai scumpe de implementat.

Criptare în repaus

Parole. Nu stocați niciodată parolele în text clar și nu folosiți niciodată MD5 sau SHA-1 pentru hashing-ul parolelor. Ambele sunt complet inadecvate. Folosiți bcrypt cu un factor de lucru de cel puțin 12, sau Argon2id cu parametri ajustați pentru a dura cel puțin 100ms pe hardware-ul serverului. Argon2id este recomandarea actuală a OWASP și este preferabilă pentru implementările 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. Activați criptarea în repaus la nivelul bazei de date. Toate bazele de date principale și serviciile gestionate (PostgreSQL, MySQL, MongoDB Atlas, AWS RDS, Azure SQL) suportă acest lucru. Criptarea transparentă a datelor (TDE) protejează datele de pe disc, dar nu protejează împotriva unui utilizator de bază de date compromis cu acces la interogări. Pentru câmpurile extrem de sensibile (numere de asigurare națională, dosare medicale, numere de conturi financiare), luați în considerare criptarea câmpurilor la nivel de aplicație folosind AES-256-GCM cu un serviciu de gestionare a cheilor (AWS KMS, Azure Key Vault, HashiCorp Vault). Cheia trebuie stocată separat de datele pe care le criptează.

Gestionarea cheilor. Nu codați direct cheile de criptare în codul aplicației și nu le stocați în aceeași bază de date cu datele pe care le protejează. Folosiți variabile de mediu pentru dezvoltare și un serviciu gestionat de gestionare a cheilor pentru producție. Rotiți cheile periodic și asigurați-vă că aplicația dvs. poate gestiona rotația cheilor fără timp de nefuncționare.

Ce să nu faceți. Nu stocați date cu caracter personal în text clar în fișierele jurnal, fișierele temporare sau cache-urile aplicației unde criptarea poate să nu se aplice. Verificați fiecare cale de cod care gestionează date cu caracter personal și asigurați-vă că nu păstrează inadvertent copii necriptate.

Criptare în tranzit

Configurația TLS. Aplicați TLS 1.2 ca minim, cu TLS 1.3 ca implicit acolo unde este suportat. Dezactivați complet SSLv3, TLS 1.0 și 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. Setați antetul Strict-Transport-Security cu o valoare max-age lungă și includeSubDomains. Un max-age de cel puțin 31536000 (un an) este standardul. Trimiteți la lista de preîncărcare HSTS dacă implementarea dvs. permite acest lucru.

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

Conținut mixt. Servirea oricărei resurse (imagini, scripturi, foi de stil, apeluri API) prin HTTP de pe o pagină HTTPS creează o vulnerabilitate de conținut mixt și subminează securitatea transportului. Configurați Content Security Policy pentru a bloca conținutul mixt și verificați pagina dvs. pentru orice încărcări de resurse non-HTTPS.

Servicii interne. Criptarea în tranzit se aplică comunicării interne serviciu-la-serviciu la fel ca traficul orientat către utilizator. Conexiunile la baze de date, conexiunile la cozile de mesaje și apelurile la microservicii ar trebui să folosească toate TLS. Mulți dezvoltatori criptează corect stratul orientat către utilizator și trec cu vederea rețeaua internă.

Minimizarea datelor în cod

Minimizarea datelor nu este o abstractizare juridică. Este o decizie de proiectare luată câmp cu câmp. Înainte de a colecta orice date cu caracter personal, întrebați-vă: aplicația are într-adevăr nevoie de aceasta pentru a funcționa? Dacă nu puteți răspunde la această întrebare cu un caz de utilizare specific, nu o colectați.

În practică aceasta înseamnă:

  • Eliminați câmpurile de formular care sunt opționale și al căror scop este vag (“data nașterii” la o înscriere la newsletter unde nu aveți cerința de verificare a vârstei)
  • Auditați schema bazei de date în mod regulat și eliminați coloanele care conțin date cu caracter personal fără utilizare activă
  • Setați perioadele de retenție la nivelul schemei acolo unde este posibil, folosind sarcini programate pentru a elimina automat înregistrările expirate
  • Evitați colectarea datelor cu caracter personal extrem de sensibile (informații despre sănătate, detalii financiare, opinii politice) cu excepția cazului în care aplicația dvs. le necesită cu adevărat, deoarece evaluarea riscului din Articolul 32 se extinde cu sensibilitatea datelor prelucrate

Principiul responsabilității ICO necesită să puteți demonstra că ați luat în considerare minimizarea datelor. Deciziile de proiectare documentate în arhitectură sau notele de sprint satisfac această cerință. Deciziile nedocumentate nu o satisfac.

Pseudonimizare

Pseudonimizarea înlocuiește informațiile direct identificatoare cu un token sau identificator care nu poate identifica individul fără acces la o cheie sau tabel de mapare păstrat separat. Articolul 32 îl listează explicit ca măsură tehnică recomandată, iar Articolul 89 prevede obligații reduse pentru prelucrarea datelor pseudonimizate în scopuri de cercetare.

Pentru analitice și urmărirea comportamentului, un model comun este de a face hash identificatorilor de utilizator cu un salt specific site-ului folosind SHA-256 înainte 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. Fără el, hash-ul nu poate fi inversat pentru a identifica individul. Aceasta înseamnă că sistemul dvs. analitic conține numai identificatori pseudonimizați, reducând profilul de risc al unei breșe a acelui sistem.

Pseudonimizarea nu este anonimizare. Dacă dețineți cheia de mapare, ICO tratează datele pseudonimizate ca date cu caracter personal. Anonimizarea completă, unde re-identificarea nu este posibilă chiar și cu informații suplimentare disponibile în mod rezonabil, scoate datele complet din sfera GDPR. Obținerea anonimizării autentice este dificilă în practică; majoritatea implementărilor produc date pseudonimizate, care încă intră sub incidența GDPR dar cu risc redus.

Dreptul la ștergere: implementarea corectă

Dreptul la ștergere (Articolul 17) este una dintre cele mai solicitante tehnic obligații GDPR de implementat corect. Cerințele sunt specifice:

Ștergere definitivă, nu logică. Setarea unui indicator is_deleted și filtrarea lui din interogări nu satisface dreptul la ștergere. Datele trebuie să fie efectiv eliminate din baza de date. Construiți funcționalitatea de ștergere definitivă pentru fiecare entitate care conține date cu caracter personal.

Ștergeri în cascadă. Ștergerea înregistrării utilizatorului nu este suficientă dacă datele cu caracter personal sunt de asemenea păstrate în tabele conexe (comenzi, adrese, jurnale de activitate, preferințe, fișiere încărcate). Mapați fiecare tabel care conține date cu caracter personal legate de un identificator de utilizator și asigurați-vă că ștergerea cascadează corect, sau implementați un job de ștergere explicit care elimină atomic toate datele asociate.

Procesori terți. Dacă ați trimis date cu caracter personal către un serviciu terț (platformă de email marketing, CRM, instrument analitic, procesor de plăți), obligația dvs. de ștergere se extinde la instructarea acelui procesor să șteargă datele. Aceasta necesită:

  • Un inventar documentat al fiecărui serviciu terț care primește date cu caracter personal
  • Un mecanism de ștergere confirmat pentru fiecare (apel API, bilet de suport, gestionarea automatizată a cererilor persoanelor vizate)
  • Dovezi că ștergerea a fost finalizată

Backup-uri. Backup-urile sunt cea mai frecvent trecută cu vederea problemă de ștergere. Dacă faceți backup-uri zilnice ale bazei de date cu o perioadă de retenție de 90 de zile, o cerere de ștergere satisfăcută în baza de date activă nu va fi satisfăcută în backup-uri până când acestea expiră. Poziția ICO este că backup-urile restaurate după ștergere nu trebuie să reintroducă datele cu caracter personal șterse. Abordări practice includ: excluderea înregistrărilor șterse din exporturile de backup acolo unde este fezabil, implementarea proceselor de curățare specifice backup-urilor, sau utilizarea criptării la nivel de câmp și ștergerea cheii (făcând datele ilizibile, ceea ce se apropie de standardul ștergerii).

Excepții. Dreptul la ștergere nu este absolut. Puteți reține date necesare pentru revendicări legale, conformitate legală (de exemplu, înregistrări financiare conform Companies Act), sau scopuri de interes public. Documentați excepția și comunicați-o persoanei vizate atunci când respingeți sau îndepliniți parțial o cerere de ștergere.

Detectarea breșelor și cerința de notificare în 72 de ore

Articolul 33 din UK GDPR solicită să notificați ICO în termen de 72 de ore de la luarea la cunoștință a unei breșe de date cu caracter personal care poate duce la riscuri pentru persoane fizice. Aceasta nu reprezintă 72 de ore de la producerea breșei. Reprezintă 72 de ore de la momentul în care ați luat la cunoștință. Această distincție creează un stimulent direct pentru a construi capacitate de detectare a breșelor, deoarece ceasul începe să tichească când o descoperiți.

Ce să înregistrați pentru detectarea breșelor. Arhitectura dvs. de logare ar trebui să capteze:

  • Evenimente de autentificare: autentificări reușite și eșuate, provocări MFA, resetări de parolă
  • Eșecuri de autorizare: cereri care au fost refuzate din cauza verificărilor de permisiuni
  • Accesul la date: cine a accesat ce date cu caracter personal și când, în special exporturi în masă sau volume neobișnuite de interogări
  • Modificări de configurație: modificări ale permisiunilor utilizatorilor, cheilor de criptare sau setărilor de retenție a datelor
  • Modele anormale: acces de la adrese IP neobișnuite sau la ore neobișnuite, citiri în volum mare din tabelele cu date cu caracter personal

Ce să nu înregistrați. Nu înregistrați valorile datelor cu caracter personal în jurnalele de aplicație. Jurnalele de depanare care înregistrează corpuri complete de cerere, interogări de bază de date cu valori de parametri substituite sau date din formulare introduse de utilizator creează depozite secundare de date cu caracter personal care sunt dificil de gestionat și care sunt în sine în sfera GDPR. Înregistrați identificatori (ID-uri utilizator, ID-uri sesiune, ID-uri cerere) în 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 răspunsului la breșe. Logarea permite detectarea, dar aveți nevoie de un proces documentat pentru ce se întâmplă atunci când detectați o breșă. Cine este notificat intern? Cine ia decizia de notificare ICO? Ce informații trebuie să conțină notificarea ICO? Construiți acest proces înainte de a-l necesita.

Conformitatea API-urilor terțe

Operator vs procesor. Dacă folosiți un serviciu terț care prelucrează date cu caracter personal în numele dvs. (un furnizor de email tranzacțional, un furnizor de infrastructură cloud, un procesor de plăți), acesta este un procesor de date, iar dvs. sunteți operatorul. Sunteți responsabil pentru conformitatea lor cu UK GDPR în acel context.

Acorduri de procesare a datelor. Trebuie să aveți încheiat un Acord de procesare a datelor (DPA) scris cu fiecare serviciu terț care prelucrează date cu caracter personal în numele dvs. Majoritatea furnizorilor SaaS majori (AWS, Mailchimp, Stripe, Twilio, SendGrid) oferă DPA-uri standard. Semnați-le și păstrați-le. Dacă un furnizor nu poate produce un DPA, nu îl puteți folosi legal pentru a prelucra date cu caracter personal conform UK GDPR.

Sub-procesori. DPA-ul dvs. cu un procesor ar trebui să listeze sub-procesorii acestuia (serviciile pe care le folosesc la rândul lor pentru a prelucra datele dvs.). De exemplu, furnizorul dvs. de email tranzacțional poate folosi infrastructura AWS. Nu sunteți obligat să aveți un DPA direct cu sub-procesorii, dar trebuie să știți cine sunt și unde sunt prelucrate geografic datele în scopuri de conformitate cu transferul.

Mecanisme de transfer. Dacă un serviciu terț prelucrează date în afara Regatului Unit sau UE, aveți nevoie de un mecanism de transfer legal. Pentru transferurile din Regatul Unit, acestea sunt în prezent mecanisme specifice Regatului Unit (Acorduri internaționale de transfer de date din Regatul Unit, sau bazarea pe decizii de adecvare ale Regatului Unit acolo unde sunt disponibile). Verificați opțiunile de rezidență a datelor și documentația de transfer pentru fiecare serviciu.

Controlul accesului

Principiul privilegiului minim. Utilizatorii bazei de date folosiți de aplicația dvs. ar trebui să aibă permisiunile minime necesare: citire și scriere pe tabele specifice, fără acces administrativ. Creați acreditative separate pentru baza de date pentru servicii cu citire intensă (raportare, analitică) și servicii cu scriere intensă (aplicație orientată către utilizator). Aceasta limitează raza de explozie a unei acreditative compromise.

Controlul accesului bazat pe roluri. Implementați RBAC în aplicația dvs. și revizuiți atribuirile de roluri în mod regulat. Rolurile tind să acumuleze permisiuni în timp; un audit periodic față de ceea ce are nevoie fiecare rol detectează expansiunea privilegiilor.

Jurnale de audit pentru accesul la date. Pentru datele sensibile, implementați logarea de audit la nivelul stratului de aplicație care înregistrează ce utilizator autentificat a accesat ce înregistrare de date cu caracter personal și când. Aceasta este separată de jurnalele de erori ale aplicației și ar trebui să fie rezistentă la manipulare (write-once sau numai de adăugare, cu acces restricționat din codul aplicației).

Lista de verificare pentru dezvoltatori: 10 controale tehnice de implementat

  1. Hashing-ul parolelor. Folosiți bcrypt (factor de cost 12+) sau Argon2id. Eliminați imediat orice hashing de parolă MD5 sau SHA-1.
  2. Criptare în repaus. Activați TDE la nivel de bază de date și implementați criptarea câmpurilor AES-256-GCM pentru datele cu caracter personal extrem de sensibile cu chei păstrate într-un KMS gestionat.
  3. Configurația TLS. Aplicați TLS 1.2 minim, TLS 1.3 implicit, HSTS cu max-age de un an, fără conținut mixt.
  4. Auditul minimizării datelor. Revizuiți fiecare câmp din schema bazei de date care conține date cu caracter personal. Eliminați sau încetați să colectați orice câmp fără un caz de utilizare documentat și activ.
  5. Implementarea ștergerii definitive. Construiți ștergerea în cascadă verificată pentru toate datele cu caracter personal legate de un utilizator. Testați că ștergerea elimină efectiv înregistrările și nu doar le semnalează.
  6. Inventarul DPA-urilor terțe. Listați fiecare SaaS sau serviciu cloud care primește date cu caracter personal. Confirmați existența unui DPA semnat pentru fiecare. Eliminați orice serviciu care nu poate furniza unul.
  7. Igiena logării. Auditați jurnalele aplicației dvs. pentru date personale. Eliminați valorile datelor cu caracter personal din ieșirea jurnalului la fiecare nivel de jurnal. Înregistrați numai identificatori.
  8. Logarea pentru detectarea breșelor. Implementați logarea structurată pentru evenimentele de autentificare, eșecurile de autorizare și accesul la date în masă. Configurați alerte pentru modele anormale.
  9. Revizuirea controlului accesului. Auditați acreditativele bazei de date și rolurile aplicației față de principiul privilegiului minim. Eliminați accesul administrativ de la utilizatorii bazei de date ale aplicației.
  10. Pseudonimizare pentru analitică. Înlocuiți identificatorii direcți de utilizator din apelurile analitice și de urmărire ale terților cu valori hash HMAC folosind un secret specific site-ului.

Puncte cheie

  • Cerințele tehnice ale UK GDPR sunt identice cu ale EU GDPR. După Brexit, ICO le aplică și trebuie să urmați îndrumarea specifică ICO pentru notificări și transferuri.
  • Articolul 32 solicită măsuri tehnice adecvate proporționale cu riscul dvs. Pentru majoritatea aplicațiilor, aceasta înseamnă criptare puternică, controale ale accesului, pseudonimizare și detectare documentată a breșelor.
  • Minimizarea datelor este o decizie la nivel de câmp luată de dezvoltatori, nu o abstractizare juridică. Dacă nu puteți justifica colectarea unui câmp, nu îl colectați.
  • Dreptul la ștergere necesită ștergerea efectivă în cascadă prin toate sistemele, inclusiv backup-uri și procesori terți. Un indicator de ștergere logică nu satisface obligația.
  • Nu înregistrați valorile datelor cu caracter personal. Înregistrați identificatori. Fișierele jurnal sunt în sine un depozit de date cu caracter personal și unul dintre cei mai frecvent trecuți cu vederea vectori de breșă.
  • Aveți un DPA semnat cu fiecare serviciu terț care atinge datele cu caracter personal. Dacă un furnizor nu poate produce unul, nu îl puteți folosi legal în acel scop.

Articole similare: Ghid de audit de securitate a site-ului web pentru , OWASP Top 10 explicat pentru proprietarii de afaceri , Testarea de penetrare in Marea Britanie , Conformitatea Cyber Essentials: un ghid de evaluare UK 2026 .

Întrebări frecvente (FAQ)

Se aplică UK GDPR dacă toți utilizatorii mei se află în afara Regatului Unit? UK GDPR se aplică dacă sunteți stabilit în Regatul Unit, indiferent de locul unde se află utilizatorii dvs. Se aplică de asemenea organizațiilor din afara Regatului Unit care oferă bunuri sau servicii persoanelor din Regatul Unit sau monitorizează comportamentul persoanelor din Regatul Unit. Dacă sunteți un dezvoltator cu sediul în Regatul Unit care construiește pentru un public non-britanic, UK GDPR se aplică activităților dvs. de procesare.

Este criptarea obligatorie conform UK GDPR? Criptarea este menționată explicit în Articolul 32(1)(a) ca măsură recomandată. Nu este o cerință absolut obligatorie, deoarece regulamentul solicită măsuri “adecvate riscului”. În practică, pentru orice aplicație care gestionează date cu caracter personal prin internet, ar fi foarte dificil să justificați față de ICO lipsa criptării datelor în tranzit și în repaus. Tratați-o ca pe o cerință obligatorie.

Ce contează ca breșă de date cu caracter personal care necesită notificarea ICO? O breșă de date cu caracter personal este orice distrugere accidentală sau ilegală, pierdere, alterare, divulgare neautorizată sau acces neautorizat la date cu caracter personal. Aceasta include un compartiment S3 configurat greșit care a expus înregistrări public, un atac de phishing care a oferit unui atacator acces la contul dvs. de email conținând date de clienți și ștergerea accidentală a înregistrărilor fără backup. Nu toate breșele necesită notificarea ICO: numai cele care pot duce la riscuri pentru persoane fizice. Breșele cu risc ridicat necesită de asemenea notificarea directă a persoanelor afectate.

Cât timp trebuie să păstrăm datele cu caracter personal? UK GDPR nu specifică perioade de retenție. Trebuie să păstrați datele numai atât timp cât este necesar pentru scopul pentru care au fost colectate. Definiți perioade de retenție pentru fiecare categorie de date pe care o dețineți, documentați-le în avizul dvs. de confidențialitate și implementați curățarea automatizată. Înregistrările financiare sunt de obicei păstrate șase ani conform Companies Act. Înregistrările consimțământului de marketing ar trebui păstrate până când consimțământul este retras sau expiră.

Avem nevoie de un responsabil cu protecția datelor? Un DPO este obligatoriu pentru autoritățile publice, organizațiile care prelucrează date cu caracter personal sensibile la scară largă și organizațiile care efectuează monitorizare sistematică la scară largă. Pentru majoritatea companiilor de software din Regatul Unit, un DPO nu este obligatoriu, dar este recomandat dacă prelucrați volume semnificative de date cu caracter personal. ICO oferă îndrumări specifice cu privire la acest prag pe site-ul lor web.

Care este amenda maximă pentru neconformitate cu UK GDPR? ICO poate emite amenzi de până la 17,5 milioane de lire sterline sau 4% din cifra de afaceri anuală globală (oricare este mai mare) pentru cele mai grave încălcări. Amenzi de nivel inferior de până la 8,7 milioane de lire sterline sau 2% din cifra de afaceri globală se aplică încălcărilor mai puțin grave. În practică, majoritatea amenzilor ICO sunt semnificativ sub maximum și sunt calibrate în funcție de severitatea breșei, cooperarea organizației și măsurile luate pentru remedierea problemei.