Az ICO végrehajtási intézkedései a brit szervezetekkel szemben 2024-ben és 2025-ben meredeken emelkedtek, a két év alatt összesen több mint 12 millió font bírságot szabtak ki műszaki biztonsági intézkedések megsértése miatt. Az ICO végrehajtási határozataiban következetes mintázat figyelhető meg: azok a szervezetek jártak a legsúlyosabb következményekkel, amelyek jogsértést szenvedtek el, és nem tudták igazolni, hogy megfelelő műszaki kontrollokat vezettek be. A fejlesztők számára ez közvetlen szakmai aggály. A titkosítással, naplózással, hozzáférés-vezérléssel és adatmegőrzéssel kapcsolatos döntések azok a műszaki kontrollok, amelyek meghatározzák, hogy egy szervezet képes-e védekezni az ICO előtt.

Ez az útmutató fejlesztőknek és mérnöki csapatoknak szól, nem jogi vagy megfelelési osztályoknak. Az UK GDPR követelményeit konkrét műszaki döntésekre fordítja le: mit kell megvalósítani, hogyan kell megvalósítani, és miért létezik minden egyes intézkedés.

Összefoglalás

  • Az UK GDPR 32. cikke a kockázattal arányos “megfelelő műszaki intézkedéseket” követel meg. A személyes adatokat kezelő legtöbb alkalmazás esetében ez titkosítást jelent tároláskor és átvitelkor, pseudonimizálást ahol lehetséges, hozzáférés-vezérlést és dokumentált jogsértés-észlelési képességet.
  • A leggyakoribb fejlesztői hibák, amelyek GDPR-kitettséget teremtenek: személyes adatok naplózása hibakeresési kimenetben, azoknak a rekordoknak a logikai törlése, amelyeket a törlési jog alapján ténylegesen törölni kellene, és az adatfeldolgozási szerződések hiánya minden olyan harmadik féllel, amely személyes adatokhoz hozzáfér.
  • Az adatminimalizálás mező szintű tervezési döntés. Ha nincs dokumentált oka egy mező gyűjtésére és tárolására, ne gyűjtse.
  • A törlési jog tényleges törlést igényel, amely minden rendszerre kiterjed, beleértve a biztonsági mentéseket és a harmadik fél adatfeldolgozókat. A logikai törlések nem teljesítik a kötelezettséget.

UK GDPR vs. EU GDPR: mi változik a fejlesztők számára

A Brexit után az Egyesült Királyság az EU GDPR-keretrendszert “UK GDPR”-ként megtartotta a European Union (Withdrawal) Act 2018 révén. A fejlesztők számára a műszaki követelmények azonosak. A különbségek adminisztratív jellegűek: az Egyesült Királyságban a felügyeleti hatóság az Information Commissioner’s Office (ICO), nem egy EU-s nemzeti adatvédelmi hatóság, és az Egyesült Királyság és az EU közötti határon átnyúló adattovábbításokat az Egyesült Királyság megfelelőségi határozata szabályozza (amelyet az EU jelenleg fenntart, bár időszakosan felülvizsgálják).

A gyakorlati következmény az, hogy ha az EU GDPR műszaki követelményeinek megfelelő szoftvert épít, az kielégíti az UK GDPR műszaki követelményeit is. A fordítottja szintén igaz. Eltéréseket az értesítési eljárásokban, az adattovábbítási mechanizmusokban és az ICO specifikus végrehajtási útmutatójában fog tapasztalni, amely néha eltér az EDPB iránymutatásaitól.

32. cikk: mit követel valójában

Az UK GDPR 32. cikke előírja az adatkezelők és adatfeldolgozók számára, hogy a kockázatnak megfelelő biztonsági szint biztosítása érdekében “megfelelő műszaki és szervezési intézkedéseket” hajtsanak végre, figyelembe véve a technika állását, a megvalósítási költségeket, valamint a feldolgozás jellegét, hatókörét, kontextusát és céljait.

Ez a megfogalmazás szándékosan rugalmas. A gyakorlatban való értelmezése a kockázati profiltól függ, de a 32. cikk (1) bekezdése négy konkrét példát ad:

  1. A személyes adatok álnevesítése és titkosítása
  2. Az adatfeldolgozó rendszerek és szolgáltatások folyamatos bizalmassága, sértetlensége, rendelkezésre állása és rezilienciájának biztosítása
  3. A személyes adatokhoz való hozzáférés és rendelkezésre állás haladéktalan visszaállítása fizikai vagy műszaki incidens esetén
  4. A biztonsági intézkedések hatékonyságának rendszeres tesztelésére, értékelésére és értékelésére vonatkozó eljárás

A “technika állása” nem azt jelenti, hogy a legdrágább vagy legkorszerűbb megoldást kell bevezetni. Azt jelenti, hogy nem igazolható egy gyenge megközelítés alkalmazása (például MD5 jelszókivonat-képzésre), ha egyértelműen jobb megközelítések (például Argon2) jól megalapozottak, széles körben elérhetőek és nem lényegesen drágábbak a megvalósítani.

Titkosítás tároláskor

Jelszavak. Soha ne tárolja a jelszavakat egyszerű szövegként, és soha ne használjon MD5-öt vagy SHA-1-et jelszókivonat-képzéshez. Mindkettő teljesen alkalmatlan. Használjon bcrypt-et legalább 12-es munkafaktorral, vagy Argon2id-t olyan paraméterekkel beállítva, hogy legalább 100 ms-t vegyen igénybe a szerver hardverén. Az Argon2id az OWASP jelenlegi ajánlása, és előnyösebb az új megvalósításokhoz.

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

Adatbázis-titkosítás. Engedélyezze a titkosítást tároláskor az adatbázis szintjén. Minden főbb adatbázis és felügyelt szolgáltatás (PostgreSQL, MySQL, MongoDB Atlas, AWS RDS, Azure SQL) támogatja ezt. Az átlátható adattitkosítás (TDE) védi a lemezen lévő adatokat, de nem véd a lekérdezési hozzáféréssel rendelkező kompromittált adatbázis-felhasználó ellen. Rendkívül érzékeny mezőkhöz (nemzeti biztosítási számok, orvosi nyilvántartások, pénzügyi számlaszámok) fontolja meg az alkalmazásszintű mezőtitkosítást AES-256-GCM segítségével kulcskezelési szolgáltatással (AWS KMS, Azure Key Vault, HashiCorp Vault). A kulcsot a titkosítandó adatoktól elkülönítve kell tárolni.

Kulcskezelés. Ne kódolja be a titkosítási kulcsokat az alkalmazáskódba, és ne tárolja azokat ugyanabban az adatbázisban, mint a védendő adatokat. Használjon környezeti változókat fejlesztéshez, és felügyelt kulcskezelési szolgáltatást éles környezethez. Rendszeresen cserélje a kulcsokat, és gondoskodjon arról, hogy az alkalmazás leállás nélkül kezelje a kulcscserét.

Mit ne tegyen. Ne tárolja az egyszerű szöveges személyes adatokat naplófájlokban, ideiglenes fájlokban vagy alkalmazás-gyorsítótárakban, ahol a titkosítás esetleg nem érvényesül. Ellenőrizze minden kódútvonalat, amely személyes adatokat kezel, és győződjön meg arról, hogy nem tárol véletlenül titkosítatlan másolatokat.

Titkosítás átvitel közben

TLS-konfiguráció. Követelje meg a TLS 1.2-t minimumként, TLS 1.3-at alapértelmezettként, ahol támogatott. Teljesen tiltsa le az SSLv3, TLS 1.0 és TLS 1.1 protokollokat. nginx esetén:

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. Állítsa be a Strict-Transport-Security fejlécet hosszú max-age értékkel és includeSubDomains beállítással. Legalább 31536000 (egy év) max-age az elfogadott szabvány. Ha a telepítés lehetővé teszi, nyújtsa be a HSTS előtöltési listára.

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

Vegyes tartalom. Bármely erőforrás (képek, szkriptek, stíluslapok, API-hívások) HTTP-n keresztüli kiszolgálása egy HTTPS-oldalról vegyes tartalom sebezhetőséget hoz létre és aláásja az átviteli biztonságot. Konfigurálja a Content Security Policy-t a vegyes tartalom blokkolására, és ellenőrizze az oldalt nem HTTPS-en keresztül betöltött erőforrások szempontjából.

Belső szolgáltatások. Az átvitel közbeni titkosítás a belső szolgáltatások közötti kommunikációra is vonatkozik, nem csak a felhasználói forgalomra. Az adatbázis-kapcsolatoknak, üzenetsor-kapcsolatoknak és mikroszolgáltatás-hívásoknak mind TLS-t kell használniuk. Sok fejlesztő helyesen titkosítja a felhasználói réteget, de figyelmen kívül hagyja a belső hálózatot.

Adatminimalizálás a kódban

Az adatminimalizálás nem jogi elvonatkoztatás. Ez egy mező szintű tervezési döntés. Mielőtt bármilyen személyes adatot gyűjt, kérdezze meg: az alkalmazásnak valóban szüksége van erre a működéshez? Ha ezt a kérdést nem tudja megválaszolni egy konkrét felhasználási esettel, ne gyűjtse.

A gyakorlatban ez azt jelenti:

  • Távolítsa el az opcionális és homályos célú űrlapmezőket (pl. “születési dátum” egy hírlevél-feliratkozásnál, ahol nincs korhatár-ellenőrzési követelmény)
  • Rendszeresen ellenőrizze az adatbázissémát, és törölje az aktív felhasználás nélküli személyes adatokat tartalmazó oszlopokat
  • Állítson be megőrzési időszakokat séma szinten, ahol lehetséges, ütemezett feladatokat használva a lejárt rekordok automatikus törlésére
  • Kerülje a magas érzékenységű személyes adatok (egészségügyi információk, pénzügyi adatok, politikai nézetek) gyűjtését, hacsak az alkalmazásnak ténylegesen nem szüksége van rájuk, mivel a 32. cikk szerinti kockázatértékelés a feldolgozott adatok érzékenységével arányosan nő

Az ICO elszámoltathatósági elve megköveteli, hogy be tudja bizonyítani, hogy figyelembe vette az adatminimalizálást. Az architektúrában vagy sprint-feljegyzésekben dokumentált tervezési döntések kielégítik ezt. A dokumentálatlan döntések nem.

Álnevesítés

Az álnevesítés közvetlenül azonosító információkat token-re vagy azonosítóra cserél, amely az egyén azonosítására nem képes egy külön tárolt kulcs vagy leképezési táblázat elérése nélkül. A 32. cikk kifejezetten ajánlott műszaki intézkedésként sorolja fel, és a 89. cikk csökkentett kötelezettségeket ír elő az álnevesített adatok kutatási célú feldolgozásához.

Az analitika és viselkedéskövetés esetén egy elterjedt minta a felhasználói azonosítók oldal-specifikus sóval való SHA-256 kivonat-képzése az analitikai rendszernek való átadás előtt:

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()

A sót az analitikai adatoktól elkülönítve kell tárolni. Nélküle a kivonat nem fordítható vissza az egyén azonosítása céljából. Ez azt jelenti, hogy az analitikai rendszer csak álnevesített azonosítókat tartalmaz, csökkentve a rendszer megsértésének kockázati profilját.

Az álnevesítés nem anonimizálás. Ha rendelkezik a leképezési kulccsal, az ICO az álnevesített adatokat személyes adatként kezeli. A teljes anonimizálás, ahol az újra-azonosítás nem lehetséges még az ésszerűen rendelkezésre álló kiegészítő információkkal sem, teljesen kiveszi az adatokat a GDPR hatálya alól. A valódi anonimizálás elérése nehéz a gyakorlatban; a legtöbb megvalósítás álnevesített adatokat állít elő, amelyek még mindig a GDPR hatálya alá esnek, de csökkentett kockázattal.

Törlési jog: helyes megvalósítás

A törlési jog (17. cikk) az egyik műszakilag legigényesebb GDPR-kötelezettség, amelyet helyesen kell megvalósítani. A követelmények konkrétak:

Tényleges törlés, nem logikai törlés. Egy is_deleted jelző beállítása és lekérdezésekből való kiszűrése nem elégíti ki a törlési jogot. Az adatokat ténylegesen el kell távolítani az adatbázisból. Hozzon létre tényleges törlési funkciót minden személyes adatot tartalmazó entitáshoz.

Kaszkádolt törlések. A felhasználói rekord törlése nem elegendő, ha személyes adatokat kapcsolódó táblákban is tárolnak (megrendelések, címek, tevékenységi naplók, beállítások, feltöltött fájlok). Térképezze fel minden táblát, amely felhasználói azonosítóhoz kapcsolódó személyes adatokat tartalmaz, és gondoskodjon arról, hogy a törlés megfelelően kaszkádoljon, vagy valósítson meg egy explicit törlési feladatot, amely atomikusan eltávolítja az összes kapcsolódó adatot.

Harmadik fél adatfeldolgozók. Ha személyes adatokat küldött egy harmadik fél szolgáltatásnak (e-mail marketing platform, CRM, analitikai eszköz, fizetési feldolgozó), a törlési kötelezettség kiterjed arra, hogy utasítsa az adatfeldolgozót az adatok törlésére. Ez szükségessé teszi:

  • Minden személyes adatokat fogadó harmadik fél szolgáltatás dokumentált nyilvántartását
  • Megerősített törlési mechanizmust minden esethez (API-hívás, támogatási jegy, automatizált érintetti kérelem-kezelés)
  • Bizonyítékot arra, hogy a törlés megtörtént

Biztonsági mentések. A biztonsági mentések a leggyakrabban figyelmen kívül hagyott törlési problémák. Ha napi adatbázis-biztonsági mentéseket készít 90 napos megőrzési időszakkal, az élő adatbázisban teljesített törlési kérelem nem lesz teljesítve a biztonsági mentésekben, amíg azok le nem járnak. Az ICO álláspontja az, hogy a törlés utáni visszaállított biztonsági mentések nem hozhatják vissza a törölt személyes adatokat. Gyakorlati megközelítések: törölt rekordok kizárása biztonsági mentési exportokból, ahol lehetséges, biztonsági mentés-specifikus törlési folyamatok megvalósítása, vagy mezőszintű titkosítás és a kulcs törlése (az adatokat olvashatatlanná téve, ami közelít a törlés szabványához).

Kivételek. A törlési jog nem abszolút. Megtarthatja a jogi igényekhez, törvényes megfelelőséghez (például a Companies Act szerinti pénzügyi nyilvántartásokhoz) vagy közérdekű célokhoz szükséges adatokat. Dokumentálja a kivételt, és közölje azt az érintettel, ha megtagadja vagy csak részlegesen teljesíti a törlési kérelmet.

Jogsértés-észlelés és a 72 órás értesítési követelmény

Az UK GDPR 33. cikke értelmében 72 órán belül értesíteni kell az ICO-t, miután tudomást szerzett egy olyan személyes adatvédelmi incidensről, amely valószínűleg kockázatot jelent az egyének számára. Ez nem 72 óra az incidens bekövetkezésétől számítva. Ez 72 óra attól az időponttól, amikor tudomást szerzett róla. Ez a különbségtétel közvetlen ösztönzőt teremt az jogsértés-észlelési képesség kiépítésére, mivel az óra akkor kezd el ketyegni, amikor felfedezi.

Mit kell naplózni az jogsértés-észleléshez. A naplózási architektúrának rögzítenie kell:

  • Hitelesítési eseményeket: sikeres és sikertelen bejelentkezések, MFA-kihívások, jelszó-visszaállítások
  • Engedélyezési hibák: engedélyezési ellenőrzések miatt megtagadott kérések
  • Adathozzáférés: ki fért hozzá milyen személyes adatokhoz és mikor, különösen tömeges exportok vagy szokatlan lekérdezési kötetek esetén
  • Konfigurációs változások: felhasználói engedélyek, titkosítási kulcsok vagy adatmegőrzési beállítások módosítása
  • Anomális minták: szokatlan IP-címekről vagy szokatlan időpontokban érkező hozzáférés, személyes adattáblák nagy mennyiségű olvasása

Mit ne naplózzon. Ne naplózza a személyes adatok értékeit az alkalmazásnaplókban. A teljes kérési törzseket, adatbázis-lekérdezéseket behelyettesített paraméterértékekkel, vagy felhasználó által megadott űrlapadatokat rögzítő hibakeresési naplók másodlagos személyes adattárhelyeket hoznak létre, amelyeket nehéz kezelni és amelyek maguk is a GDPR hatálya alá esnek. Naplózzon azonosítókat (felhasználói azonosítók, munkamenet-azonosítók, kérés-azonosítók) értékek helyett.

1# Helytelen: naplózza a tényleges e-mail-címet
2logger.debug(f"Login attempt for user {request.form['email']}")
3
4# Helyes: csak egy azonosítót naplóz
5logger.debug(f"Login attempt, user_id={user.id}, request_id={request_id}")

Jogsértés-reagálás tervezése. A naplózás lehetővé teszi az észlelést, de szüksége van egy dokumentált folyamatra arra vonatkozóan, mi történik, ha jogsértést észlel. Kik kerülnek értesítésre belsőleg? Ki hozza meg az ICO-értesítési döntést? Milyen információkat kell tartalmaznia az ICO-értesítésnek? Építse ki ezt a folyamatot mielőtt szüksége lenne rá.

Harmadik fél API-k megfelelősége

Adatkezelő vs. adatfeldolgozó. Ha olyan harmadik fél szolgáltatást használ, amely az Ön nevében személyes adatokat dolgoz fel (tranzakciós e-mail szolgáltató, felhőinfrastruktúra-szolgáltató, fizetési feldolgozó), ők adatfeldolgozók és Ön az adatkezelő. Ön felelős az UK GDPR-nak való megfelelésükért ebben a kontextusban.

Adatfeldolgozási megállapodások. Írásban kötött Adatfeldolgozási Megállapodással (DPA) kell rendelkeznie minden olyan harmadik fél szolgáltatással, amely az Ön nevében személyes adatokat dolgoz fel. A legtöbb nagy SaaS-szolgáltató (AWS, Mailchimp, Stripe, Twilio, SendGrid) szabványos DPA-kat kínál. Írja alá és tartsa meg azokat. Ha egy szolgáltató nem tud DPA-t bemutatni, az UK GDPR értelmében nem használhatja legálisan a személyes adatok feldolgozásához.

Alfeldolgozók. Az adatfeldolgozóval kötött DPA-nak fel kell sorolnia az alfeldolgozókat (azokat a szolgáltatásokat, amelyeket az adatfeldolgozó viszont az adatok feldolgozásához használ). Például a tranzakciós e-mail szolgáltató AWS-infrastruktúrát használhat. Nem köteles közvetlen DPA-t kötni az alfeldolgozókkal, de tisztában kell lennie azzal, kik ők és hol dolgozzák fel az adatokat földrajzilag, az adattovábbítási megfelelőség érdekében.

Adattovábbítási mechanizmusok. Ha egy harmadik fél szolgáltatás az Egyesült Királyságon vagy az EU-n kívül dolgoz fel adatokat, jogi adattovábbítási mechanizmust kell bevezetnie. Az Egyesült Királyságból való továbbításhoz jelenleg UK-specifikus mechanizmusok szükségesek (UK International Data Transfer Agreements, vagy UK megfelelőségi határozatokra való támaszkodás, ahol rendelkezésre állnak). Ellenőrizze minden szolgáltatás adatrezidencia-lehetőségeit és adattovábbítási dokumentációját.

Hozzáférés-vezérlés

Legkisebb jogosultság elve. Az alkalmazás által használt adatbázis-felhasználóknak a minimálisan szükséges engedélyekkel kell rendelkezniük: olvasás és írás adott táblákra, nem adminisztrátori hozzáférés. Hozzon létre külön adatbázis-hitelesítési adatokat az olvasásintenzív szolgáltatásokhoz (jelentések, analitika) és az írásintenzív szolgáltatásokhoz (felhasználói alkalmazás). Ez korlátozza a kompromittált hitelesítési adat által okozott kár mértékét.

Szerepalapú hozzáférés-vezérlés. Vezessen be RBAC-ot az alkalmazásban, és rendszeresen vizsgálja felül a szerepkör-hozzárendeléseket. A szerepkörök idővel hajlamosak engedélyeket felhalmozni; az egyes szerepkörök tényleges szükségleteivel szemben végzett időszakos ellenőrzés észreveszi a privilégiumszintek növekedését.

Adathozzáférési naplók. Érzékeny adatok esetén alkalmazzon naplózást az alkalmazásrétegen, amely rögzíti, melyik hitelesített felhasználó melyik személyes adatrekordhoz fért hozzá és mikor. Ez elkülönül az alkalmazás hibanaplóitól, és manipulációállónak kell lennie (egyszer írható vagy csak hozzáfűzhető, az alkalmazáskódból korlátozott hozzáféréssel).

Fejlesztői ellenőrzőlista: 10 megvalósítandó műszaki kontroll

  1. Jelszókivonat-képzés. Használjon bcrypt-et (12+ költségfaktor) vagy Argon2id-t. Azonnal távolítson el minden MD5 vagy SHA-1 jelszókivonat-képzést.
  2. Titkosítás tároláskor. Engedélyezzen adatbázisszintű TDE-t, és valósítson meg mezőszintű AES-256-GCM titkosítást a magas érzékenységű személyes adatokhoz, felügyelt KMS-ben tárolt kulcsokkal.
  3. TLS-konfiguráció. Követelje meg a TLS 1.2-t minimumként, TLS 1.3-at alapértelmezettként, HSTS-t egyéves max-age-dzsel, vegyes tartalom nélkül.
  4. Adatminimalizálási ellenőrzés. Vizsgálja felül az adatbázissémájában minden személyes adatot tartalmazó mezőt. Távolítson el vagy szüntesse meg a gyűjtést minden dokumentált, aktív felhasználási eset nélküli mezőnél.
  5. Tényleges törlés megvalósítása. Hozzon létre ellenőrzött kaszkádolt törlést a felhasználóhoz kapcsolódó összes személyes adathoz. Tesztelje, hogy a törlés ténylegesen eltávolítja-e a rekordokat, és nem csupán jelöli azokat.
  6. Harmadik fél DPA-leltár. Sorolja fel minden személyes adatokat fogadó SaaS- vagy felhőszolgáltatást. Erősítse meg az aláírt DPA meglétét mindegyikhez. Távolítson el minden olyan szolgáltatást, amely nem tud egyet bemutatni.
  7. Naplózási higiénia. Ellenőrizze az alkalmazásnaplókat személyes adatok szempontjából. Távolítson el személyes adatértékeket a naplókimenetből minden naplózási szinten. Csak azonosítókat naplózzon.
  8. Jogsértés-észlelési naplózás. Valósítson meg strukturált naplózást hitelesítési eseményekhez, engedélyezési hibákhoz és tömeges adathozzáféréshez. Állítson be riasztásokat anomális mintákhoz.
  9. Hozzáférés-vezérlési felülvizsgálat. Ellenőrizze az adatbázis-hitelesítési adatokat és az alkalmazásszerepköröket a legkisebb jogosultság elvével szemben. Távolítsa el az adminisztrátori hozzáférést az alkalmazás adatbázis-felhasználóitól.
  10. Álnevesítés az analitikához. Cserélje le a közvetlen felhasználói azonosítókat az analitikai és harmadik fél nyomkövetési hívásokban HMAC-kivonatolt értékekre, oldal-specifikus titkos kulccsal.

Legfontosabb tanulságok

  • Az UK GDPR műszaki követelményei azonosak az EU GDPR követelményeivel. A Brexit után az ICO érvényesíti ezeket, és követnie kell az ICO-specifikus iránymutatásokat az értesítésekre és adattovábbításokra vonatkozóan.
  • A 32. cikk a kockázatával arányos megfelelő műszaki intézkedéseket igényel. A legtöbb alkalmazás esetében ez erős titkosítást, hozzáférés-vezérlést, álnevesítést és dokumentált jogsértés-észlelést jelent.
  • Az adatminimalizálás mező szinten fejlesztők által hozott döntés, nem jogi elvonatkoztatás. Ha nem tudja igazolni egy mező gyűjtését, ne gyűjtse.
  • A törlési jog tényleges törlést igényel, amely kaszkádoltan kiterjed az összes rendszerre, beleértve a biztonsági mentéseket és a harmadik fél adatfeldolgozókat. A logikai törlési jelző nem teljesíti a kötelezettséget.
  • Ne naplózza a személyes adatok értékeit. Naplózzon azonosítókat. A naplófájlok maguk is személyes adattárhelyek, és az egyik leggyakrabban figyelmen kívül hagyott jogsértési vektorok.
  • Rendelkezzen aláírt DPA-val minden személyes adatokhoz hozzáférő harmadik fél szolgáltatással. Ha egy szolgáltató nem tud egyet bemutatni, legálisan nem használhatja arra a célra.

Gyakran Ismételt Kérdések (GYIK)

Vonatkozik az UK GDPR, ha az összes felhasználóm az Egyesült Királyságon kívül van? Az UK GDPR vonatkozik, ha az Egyesült Királyságban van letelepedve, függetlenül attól, hol vannak a felhasználói. Az Egyesült Királyságon kívül letelepedett szervezetekre is vonatkozik, amelyek árut vagy szolgáltatást kínálnak az Egyesült Királyságban tartózkodó személyeknek, vagy az Egyesült Királyságban tartózkodó személyek viselkedését figyelik. Ha Ön brit fejlesztő, aki nem brit közönségnek épít, az UK GDPR vonatkozik az Ön feldolgozási tevékenységeire.

Kötelező a titkosítás az UK GDPR értelmében? A titkosítás kifejezetten szerepel a 32. cikk (1) bekezdésének a) pontjában ajánlott intézkedésként. Nem abszolút kötelező követelmény, mivel a rendelet “a kockázatnak megfelelő” intézkedéseket igényel. A gyakorlatban bármely interneten keresztül személyes adatokat kezelő alkalmazás esetében nagyon nehéz lenne igazolni az ICO előtt az adatok átvitel közbeni és tároláskor való titkosításának hiányát. Kezelje kötelezőként.

Mi minősül személyes adatvédelmi incidensnek, amely ICO-értesítést igényel? A személyes adatvédelmi incidens a személyes adatok véletlen vagy jogellenes megsemmisítése, elvesztése, megváltoztatása, jogosulatlan közlése vagy az azokhoz való jogosulatlan hozzáférés. Ide tartozik egy rosszul konfigurált S3-vödör, amely nyilvánosan tette elérhetővé a rekordokat, egy adathalász támadás, amely hozzáférést adott egy támadónak az ügyféladatokat tartalmazó e-mail-fiókhoz, és a rekordok véletlen törlése biztonsági mentés nélkül. Nem minden incidens igényel ICO-értesítést: csak azok, amelyek valószínűleg kockázatot jelentenek az egyének számára. A magas kockázatú incidensek szintén közvetlen értesítést igényelnek az érintetteknek.

Mennyi ideig kell megőrizni a személyes adatokat? Az UK GDPR nem határozza meg a megőrzési időszakokat. Az adatokat csak addig kell megőrizni, ameddig az a gyűjtésük céljára szükséges. Határozzon meg megőrzési időszakokat minden egyes általa tartott adatkategóriához, dokumentálja azokat az adatvédelmi tájékoztatójában, és valósítson meg automatizált törlést. A pénzügyi nyilvántartásokat általában hat évig kell megőrizni a Companies Act értelmében. A marketing-hozzájárulási nyilvántartásokat a hozzájárulás visszavonásáig vagy lejártáig kell megőrizni.

Szükségünk van adatvédelmi tisztviselőre? Az adatvédelmi tisztviselő (DPO) kötelező a közigazgatási szervek, a nagy léptékben érzékeny személyes adatokat feldolgozó szervezetek és a nagy léptékű szisztematikus megfigyelést végző szervezetek számára. A legtöbb brit szoftvercég számára nem kötelező, de ajánlott, ha jelentős mennyiségű személyes adatot dolgoz fel. Az ICO weboldalán konkrét útmutatást ad erről a küszöbértékről.

Mekkora a maximális bírság az UK GDPR megsértéséért? Az ICO a legsúlyosabb jogsértések esetén legfeljebb 17,5 millió font vagy a globális éves forgalom 4%-ának megfelelő bírságot szabhat ki (attól függően, melyik a magasabb). Kevésbé súlyos jogsértésekre legfeljebb 8,7 millió fontos vagy a globális forgalom 2%-ának megfelelő alacsonyabb szintű bírságok vonatkoznak. A gyakorlatban a legtöbb ICO-bírság lényegesen alacsonyabb a maximumnál, és a jogsértés súlyosságához, a szervezet együttműködéséhez és a probléma orvoslása érdekében tett lépésekhez igazodik.