Súlad s GDPR: Kompletný sprievodca pre IT manažérov a lídrov digitálnej transformácie

Súlad s GDPR označuje stav, keď organizácia preukázateľne plní povinnosti podľa nariadenia (EÚ) 2016/679 – všeobecného nariadenia o ochrane údajov – vždy, keď zhromažďuje, ukladá, používa, zdieľa alebo maže osobné údaje osôb v Európskej únii. V praxi to znamená mať právny základ pre každú činnosť spracúvania, byť o nej transparentný, plniť práva dotknutých osôb, chrániť údaje vhodnými technickými a organizačnými opatreniami, hlásiť určité prípady porušenia zabezpečenia do 72 hodín a vedieť to všetko preukázať dozornému orgánu.

Práve posledná podmienka odlišuje súlad s GDPR od väčšiny regulačných projektov, aké kedy IT organizácia viedla. GDPR nezakazuje len určité správanie; prenáša dôkazné bremeno na prevádzkovateľa. Článok 24 vyžaduje, aby ste boli schopní súlad preukázať, čím sa z dokumentácie, logovania, návrhových rozhodnutí a výsledkov testov stávajú rovnocenné výstupy projektu. Pre CTO alebo IT manažéra teda súlad s GDPR nie je právny dokument, ktorý sa založí a zabudne. Je to prevádzková disciplína, ktorá zasahuje do architektúry, životného cyklu vývoja softvéru, správy testovacích dát, zmlúv s dodávateľmi aj reakcie na incidenty.

Tento sprievodca je určený ľuďom, ktorí ho musia vybudovať: IT manažérom, CTO, lídrom digitálnej transformácie a zodpovedným osobám za ochranu osobných údajov, ktoré spolupracujú s vývojovými tímami. Pokrýva vznik nariadenia, sedem zásad a ich význam v technickom vyjadrení, právne základy spracúvania, práva dotknutých osôb a ich plnenie vo veľkom rozsahu, kľúčové prevádzkové povinnosti, rozdiely oproti príbuzným režimom, ako sú CCPA a UK GDPR, dvanásťmesačný plán zavádzania, konkrétne dopady na vývoj softvéru a testovanie, mýty, ktoré programy brzdia, skutočné náklady nesúladu a smer, ktorým sa nariadenie vyvíja s účinnosťou aktu EÚ o umelej inteligencii.

Čo je súlad s GDPR a prečo je stále dôležitý?

Odkiaľ sa súlad s GDPR vzal?

GDPR nevzniklo z ničoho. Jeho línia vedie cez desaťročie európskeho práva na ochranu údajov, ktoré väčšina IT tímov nikdy nemusela čítať.

Východiskom je smernica 95/46/ES z roku 1995. Smernica stanovuje cieľ, ktorý musí každý členský štát vykonať vlastným vnútroštátnym právom. Dvadsaťosem krajín preto vytvorilo dvadsaťosem rôznych zákonov o ochrane údajov – s odlišnými definíciami, ohlasovacími povinnosťami, prahmi pre oznámenia a sankciami. Paneurópsky mzdový systém musel v roku 2010 súčasne uspokojiť nemeckú podnikovú radu, francúzsky registračný režim aj britský ohlasovací rámec. Táto roztrieštenosť bola drahá – a najdrahšia bola práve tam, kde dáta prúdia najrýchlejšie: cez hranice a vnútri nadnárodných skupín.

V januári 2012 navrhla Európska komisia jediné priamo použiteľné nariadenie namiesto smernice. Rozdiel je podstatný. Nariadenie platí vo všetkých členských štátoch bez vnútroštátneho vykonania, čo znamená jeden text, jednu sadu definícií a jednu sadu sankcií. Nariadenie (EÚ) 2016/679 bolo prijaté 27. apríla 2016, zverejnené v Úradnom vestníku 4. mája 2016 a vymáhateľné sa stalo 25. mája 2018 po dvojročnom prechodnom období, ktoré mnohé organizácie využili príliš pomaly.

Dve návrhové rozhodnutia v konečnom texte ovplyvnili všetko, čo nasledovalo. Po prvé, nariadenie dostalo podľa článku 3 extrateritoriálnu pôsobnosť, takže sleduje dotknutú osobu, nie organizáciu. Po druhé, zvolilo model výsledku a zodpovednosti namiesto modelu kontrolného zoznamu. Nariadenie len zriedka hovorí, ktorú technológiu použiť. Hovorí, aký výsledok musíte dosiahnuť, a potom od vás žiada, aby ste ho preukázali. Preto vyzerá súlad s GDPR inak v nemocnici, v banke a v rýchlo rastúcom SaaS startupe a preto tá istá klauzula v článku 32 môže v jednej organizácii vyžadovať šifrovanie a v inej riadenie prístupu podľa rolí plus automatizovaný nástroj na výmaz.

Slovo „súlad” nesie správny dôraz. Pochádza z latinského complere – naplniť, dokončiť. Súlad s GDPR je nepretržitý cyklus plnenia povinností, nie certifikát na stene. Dozorné orgány, súdy aj regulátori zdôrazňujú to isté: súlad je stav, ktorý udržiavate, a rozpadá sa v okamihu, keď vznikne nový systém, dodávateľ alebo tok dát bez kontroly.

Čo súlad s GDPR konkrétne vyžaduje?

Súlad s GDPR: preukázateľný súlad všetkého spracúvania osobných údajov s nariadením (EÚ) 2016/679 – zahŕňajúci právny základ, transparentnosť, obmedzenie účelu, minimalizáciu údajov, presnosť, obmedzenie uloženia, integritu a dôvernosť, zodpovednosť, práva dotknutých osôb, bezpečnosť spracúvania, riešenie porušenia zabezpečenia a zákonné medzinárodné prenosy – doložený dokumentáciou, ktorú dozorný orgán môže preskúmať.

Rozložená na časti prináša táto definícia osem konkrétnych povinností, ktoré musí byť IT organizácia schopná splniť na požiadanie:

1. Zaznamenaný právny základ pre každú činnosť spracúvania podľa článku 6 a prípadne článku 9.
2. Inventúru údajov, ktorá ukazuje, aké osobné údaje existujú, kde sú uložené, prečo existujú, kto k nim má prístup, ako dlho sa uchovávajú a kam sa prenášajú.
3. Transparentné informácie poskytované dotknutým osobám jasným a zrozumiteľným jazykom, zvyčajne prostredníctvom vrstvených zásad ochrany osobných údajov a rozhraní na súhlas v okamihu potreby.
4. Fungujúce procesy pre práva dotknutých osôb – prístup, opravu, výmaz, obmedzenie, prenosnosť, námietku a práva súvisiace s automatizovaným rozhodovaním – so sledovanými lehotami.
5. Bezpečnostné opatrenia zodpovedajúce riziku podľa článku 32, vrátane šifrovania, odolnosti, schopnosti obnovy a pravidelného testovania.
6. Schopnosť reakcie na porušenie zabezpečenia, ktorá vie klasifikovať, obmedziť, vyhodnotiť a prípadne oznámiť do 72 hodín.
7. Správu dodávateľov a prenosov zahŕňajúcu zmluvy o spracúvaní podľa článku 28 a mechanizmy prenosu podľa kapitoly V.
8. Vrstvu zodpovednosti – záznamy o činnostiach spracúvania, DPIA, politiky, záznamy o školeniach a protokoly o rozhodnutiach – ktorá mení vyššie uvedených sedem bodov z tvrdení na dôkazy.

Všimnite si, čo chýba: neexistuje žiadna povinná technológia, žiadna povinná certifikácia ani pevná šablóna dokumentu. GDPR definuje výsledky a vykonanie ponecháva na organizáciu. Táto sloboda je zároveň pascou. Znamená to, že neexistuje skratka k súladu iná než odviesť prácu: zmapovať, rozhodnúť, zdokumentovať a otestovať.

Prečo je súlad s GDPR obchodnou, a nie len právnou záležitosťou?

Považovať súlad s GDPR za právnu úlohu je najčastejším dôvodom, prečo sa programy zaseknú. Povinnosti majú právny pôvod, ale kontroly, ktoré ich napĺňajú, žijú v systémoch, kóde a prevádzke. Tri obchodné dynamiky to konkretizujú.

Nákup je riadený ochranou údajov. Podnikoví zákazníci v regulovaných odvetviach teraz rozosielajú bezpečnostné a dátové dotazníky s požiadavkami na dôkazy špecifické pre GDPR: aktuálne záznamy o činnostiach spracúvania, zhrnutia DPIA, zoznamy subdodávateľov, posúdenia vplyvu prenosu, históriu porušení zabezpečenia a práva na audit. Organizácie, ktoré tieto dokumenty nedokážu predložiť, strácajú zákazky alebo pohlcujú mesiace posudzovania. Artefakty súladu sa stali predajným materiálom.

Dôvera má svoju cenu. Zákazníci, zamestnanci aj partneri sa rozhodujú, kam umiestnia osobné údaje, podľa vnímanej kvality ich spracúvania. Verejne oznámené porušenie zabezpečenia túto percepciu naruší rýchlejšie, než ju akýkoľvek marketingový program dokáže obnoviť, a účinok pretrváva dlho po skončení ohlasovacej lehoty.

Dátové programy sú obmedzené zákonnosťou dát. Analytika, personalizácia, strojové učenie, migrácia do cloudu aj generatívna AI – to všetko spotrebúva osobné údaje. Každé z nich vyžaduje právny základ, účel, pravidlo pre výmaz a často DPIA. Organizácie s vyspelým súladom s GDPR dodávajú dátové iniciatívy rýchlejšie, pretože právny základ už stojí. Organizácie bez neho objavia problém uprostred projektu, keď je architektúra zamrznutá a prepracovanie drahé.

U klientov Greyson v regióne strednej a východnej Európy je vzorec konzistentný: organizácie, ktoré chápu súlad s GDPR ako inžiniersku schopnosť, a nie ako každoročné papierovanie, dokážu zavádzať nové technológie bez krízy súladu každý druhý kvartál.

Kto musí GDPR dodržiavať?

GDPR odpovedá na túto otázku v dvoch krokoch. Vecná pôsobnosť definuje, čo je regulované – osobné údaje a spracúvanie. Územná pôsobnosť definuje, kto je viazaný, a je širšia, než väčšina organizácií mimo EÚ predpokladá.

Čo je vecná pôsobnosť – čo sa považuje za osobné údaje?

Článok 4 ods. 1 definuje osobné údaje ako všetky informácie o identifikovanej alebo identifikovateľnej fyzickej osobe. Kľúčové slovo je identifikovateľná. Údaje sú osobné, ak ich možno prepojiť s osobou, priamo alebo nepriamo, s využitím prostriedkov, ktorých použitie je pravdepodobné. Patria sem zrejmé identifikátory, ako je meno, e-mailová adresa, rodné číslo a číslo účtu, ale aj menej zrejmé:

• Online identifikátory – IP adresy, ID súborov cookie, odtlačky zariadení, reklamné identifikátory a mobilné advertising ID. GDPR ich výslovne uvádza.
• Lokalizačné údaje – záznamy GPS, dáta mobilných sietí, záznamy o prihlásení na miesto.
• Pseudonymizované údaje – údaje, pri ktorých boli priame identifikátory nahradené, ale opätovná identifikácia zostáva možná. Pseudonymizované údaje sú naďalej osobnými údajmi a zostávajú v pôsobnosti nariadenia. Ide o jedno z najzávažnejších technických nedorozumení v tejto oblasti.
• Osobitné kategórie podľa článku 9 – rasový alebo etnický pôvod, politické názory, náboženské alebo filozofické presvedčenie, členstvo v odboroch, genetické údaje, biometrické údaje na jedinečnú identifikáciu, údaje o zdraví a údaje o sexuálnom živote alebo sexuálnej orientácii.
• Údaje o trestných činoch podľa článku 10, ktorých spracúvanie vyžaduje orgán verejnej moci alebo výslovné zákonné splnomocnenie.
• Kontaktné údaje B2B – pracovná e-mailová adresa a pracovná pozícia konkrétnej osoby sú osobnými údajmi. Firemný kontext ich nevyjme z pôsobnosti.

Dve upresnenia ušetria mnoho diskusií. Po prvé, anonymizované údaje nie sú v pôsobnosti nariadenia, ale len ak je anonymizácia skutočne nevratná. Európsky výbor pre ochranu údajov výslovne uviedol, že anonymizácia musí odolať útokom typu osamotenie, prepojiteľnosť a inferencia, s prihliadnutím na všetky pravdepodobne použiteľné prostriedky. Väčšina „anonymizovaných” exportov, ktoré v podnikoch kolujú, tento test nesplní. Po druhé, agregované štatistiky odvodené z osobných údajov nie sú automaticky mimo pôsobnosti – rozhodujúce je, či osoby zostávajú identifikovateľné.

Čo je územná pôsobnosť – platí GDPR aj mimo EÚ?

Článok 3 stanovuje dva nezávislé spúšťače a stačí ktorýkoľvek z nich.

Článok 3 ods. 1 – kritérium prevádzkarne. GDPR sa vzťahuje na spracúvanie v súvislosti s činnosťami prevádzkarne v Únii bez ohľadu na to, či spracúvanie samo prebieha v Únii. Slovenská spoločnosť spracúvajúca údaje na serveroch v Ázii je v pôsobnosti. Rovnako pobočka, zástupca alebo trvalé usporiadanie, prostredníctvom ktorého sa činnosť v Únii vykonáva.

Článok 3 ods. 2 – kritérium cielenia. GDPR sa vzťahuje na organizácie bez prevádzkarne v Únii, ak ponúkajú tovar alebo služby dotknutým osobám v Únii alebo sledujú ich správanie v Únii. Odôvodnenie 23 objasňuje, že samotná webová stránka dostupná z EÚ nestačí; musí existovať dôkaz o úmysle ponúkať tovar alebo služby osobám v EÚ – napríklad možnosť platby v eurách, jazykové verzie pre EÚ, možnosti doručenia do členských štátov alebo reklama cielená na trhy EÚ. Odôvodnenie 24 pokrýva sledovanie, ktoré zahŕňa behaviorálnu reklamu, analytický profiling, sledovacie technológie a nositeľné zariadenia.

Preto je americká, indická alebo brazílska spoločnosť s európskymi zákazníkmi, s európskymi návštevníkmi webu sledovanými analytikou alebo s európskymi zamestnancami na výplatnej páske zvyčajne v pôsobnosti nariadenia. Tam, kde platí článok 3 ods. 2, vyžaduje článok 27 určenie zástupcu v Únii, ak sa neuplatní výnimka. Vymáhanie voči organizáciám mimo EÚ sa opiera o mechanizmy spolupráce podľa článku 50, právnu pomoc a stále viac o praktický tlak prístupu na trh.

Kto je kto v ekosystéme GDPR?

Správne určenie role nie je sémantika. Rola určuje vaše povinnosti, vašu zodpovednosť aj zmluvy, ktoré musíte mať uzavreté. Prekvapivý podiel zlyhaní súladu možno vysledovať k organizácii, ktorá sa označila za sprostredkovateľa, hoci bola v skutočnosti prevádzkovateľom.

Kto je prevádzkovateľ a kto sprostredkovateľ?

Prevádzkovateľ je organizácia, ktorá rozhoduje, prečo a ako sa osobné údaje spracúvajú. Sprostredkovateľ tieto pokyny vykonáva. Test určenia je faktický, nie zmluvný: nemôžete sa zbaviť povinností prevádzkovateľa tým, že sa v zmluve označíte za sprostredkovateľa, ak v skutočnosti rozhodujete o účeloch a prostriedkoch.

Niekoľko situácií organizácie pravidelne zaskočí. Poskytovateľ SaaS, ktorý spracúva dáta zákazníkov striktne podľa zdokumentovaných pokynov, je sprostredkovateľom – ak však tieto dáta znovu využije pre vlastnú produktovú analytiku, porovnávanie alebo tréning AI modelov, stáva sa pre túto činnosť prevádzkovateľom a potrebuje vlastný právny základ. Marketingová agentúra, ktorá rozhoduje, na ktoré cieľové skupiny sa zamerať, je prevádzkovateľom, aj keď vzťah so zákazníkom vlastní jej klient. Ak sú účely stanovené spoločne, uplatní sa spoločné prevádzkovanie podľa článku 26 a ujednanie musí byť zdokumentované.

Praktický dôsledok: jedna organizácia môže mať pre rôzne činnosti spracúvania niekoľko rolí súčasne. Vyspelé programy súladu s GDPR preto vedú mapu rolí podľa toku dát, nie jednu značku pre celú organizáciu.

Akých je sedem zásad súladu s GDPR?

Článok 5 obsahuje sedem zásad, ktoré určujú všetko ostatné v nariadení. Každé právo, povinnosť, DPIA aj pokuta sa nakoniec odvíja od niektorej z nich. Čítané ako zoznam pôsobia abstraktne; čítané ako technické požiadavky sú veľmi konkrétne.

Sedem zásad jednotlivo

1. Zákonnosť, korektnosť a transparentnosť – čl. 5 ods. 1 písm. a). Spracúvanie musí spočívať na jednom zo šiestich právnych základov podľa článku 6, nesmie byť pre dotknutú osobu neprimerane nepriaznivé, neočakávané ani zavádzajúce a musí byť jasne komunikované. Technicky to znamená pole v registri spracúvania, značku účelu pri každom toku dát a zásady ochrany osobných údajov, ktorým porozumie aj neprávnik.

2. Obmedzenie účelu – čl. 5 ods. 1 písm. b). Údaje zhromaždené pre jeden stanovený, výslovný a legitímny účel nemožno použiť pre účel s ním nezlučiteľný. Zlučiteľnosť sa posudzuje s ohľadom na súvislosť medzi účelmi, kontext zhromaždenia, povahu údajov, dôsledky pre dotknuté osoby a existenciu záruk. Opätovné použitie fakturačnej adresy zákazníka na kontrolu podvodov je zvyčajne zlučiteľné; na tréning univerzálneho AI modelu zvyčajne nie.

3. Minimalizácia údajov – čl. 5 ods. 1 písm. c). Zhromažďujte len to, čo je primerané, relevantné a obmedzené na nevyhnutnú mieru. Túto zásadu najčastejšie porušujú analytické implementácie, formuláre na získavanie kontaktov v CRM a logovacie pipeline, ktoré zachytávajú viac, než ktokoľvek dokáže odôvodniť. Každé ďalšie pole zvyšuje riziko porušenia zabezpečenia, náročnosť vybavenia žiadostí o prístup a náklady na ukladanie.

4. Presnosť – čl. 5 ods. 1 písm. d). Osobné údaje musia byť presné a v prípade potreby aktuálne; nepresné údaje treba bez zbytočného odkladu vymazať alebo opraviť. V praxi to znamená kontrolu kvality dát, správu duplicít a opravné workflow, ktoré sa šíria do nadväzujúcich systémov vrátane analytiky a záloh.

5. Obmedzenie uloženia – čl. 5 ods. 1 písm. e). Údaje nesmú byť uchovávané v identifikovateľnej podobe dlhšie, než je nevyhnutné. Slovo „nevyhnutné” vyžaduje skutočný plán uchovávania pre každú kategóriu údajov a účel a jeho automatizované vymáhanie. Plány uchovávania, ktoré existujú len v dokumente s politikou, ale nie v kóde, sú najčastejším zistením auditu v celom nariadení.

6. Integrita a dôvernosť – čl. 5 ods. 1 písm. f). Vhodné technické a organizačné bezpečnostné opatrenia vrátane ochrany pred neoprávneným alebo protiprávnym spracúvaním, náhodnou stratou, zničením alebo poškodením. Článok 32 upresňuje: pseudonymizácia a šifrovanie, priebežné zabezpečenie dôvernosti a integrity, odolnosť, schopnosť obnovy a pravidelné testovanie.

7. Zodpovednosť – čl. 5 ods. 2. Prevádzkovateľ zodpovedá za preukázanie súladu s ostatnými šiestimi zásadami. Zodpovednosť je meta-zásada, ktorá mení úmysel na dôkaz, a je dôvodom existencie záznamov o činnostiach spracúvania, DPIA, záznamov o školeniach a návrhovej dokumentácie.

Ako zodpovednosť mení to, čo musíte vybudovať?

Zodpovednosť má nepríjemný dôsledok, ktorý by si IT lídri mali osvojiť včas: neprítomnosť dôkazov sa považuje za dôkaz neprítomnosti. Dozorný orgán nemusí preukazovať, že ste spracúvali údaje protiprávne. Môže vás vyzvať, aby ste súlad preukázali, a ak to nedokážete, je porušená samotná zásada zodpovednosti.

To mení niekoľko technických rozhodnutí. Platforma na správu súhlasov, ktorá zaznamenáva presné znenie, časovú pečiatku, verziu rozhrania a rozsah každého súhlasu, nie je byrokracia; je to dôkaz, ktorý robí zásadu zákonnosti obhájiteľnou. DPIA, ktorá dokumentuje zvažované riziká a zamietnuté alternatívy, nie je zbytočná záťaž; je to artefakt, ktorý preukazuje zodpovednosť. CI/CD pipeline, ktorá spúšťa testy relevantné pre ochranu údajov a archivuje výsledky, je kontrolou súladu, nie len kontrolou kvality.

Zodpovednosť tiež vyžaduje, aby bol súlad sledovaný, nie predpokladaný. Článok 32 ods. 1 písm. d) výslovne požaduje proces pravidelného testovania, posudzovania a vyhodnocovania účinnosti bezpečnostných opatrení. Tu sa testovacia disciplína stáva požiadavkou GDPR, nie príjemným doplnkom.

Sedem zásad prevedených na konkrétne kontroly

Aké sú právne základy na spracúvanie osobných údajov?

Spracúvanie osobných údajov je zakázané, ak sa neuplatní právny základ. Článok 6 ich ponúka šesť. Správna voľba je dôležitá, pretože základ určuje, čo smiete robiť, o čom musíte informovať a či môžu dotknuté osoby vzniesť námietku alebo odvolať súhlas.

Šesť právnych základov podľa článku 6

Súhlas – čl. 6 ods. 1 písm. a). Akýkoľvek slobodne daný, konkrétny, informovaný a jednoznačný prejav vôle dotknutej osoby. Súhlas musí byť rovnako ľahké odvolať ako udeliť, nesmie byť spojený s nesúvisiacimi podmienkami a pre výslovný súhlas podľa čl. 9 ods. 2 písm. a) musí spĺňať vyšší štandard. Súhlas je najviac nadužívaným a najkrehkejším základom, pretože ho možno kedykoľvek odvolať a vyžaduje úplnú auditnú stopu.

Zmluva – čl. 6 ods. 1 písm. b). Spracúvanie nevyhnutné na splnenie zmluvy s dotknutou osobou alebo na vykonanie opatrení pred uzavretím zmluvy na jej žiadosť. Zahŕňa vybavenie objednávky, doručenie, správu účtu a spracovanie platieb – nie však marketing, analytiku alebo zlepšovanie produktu, čo sú samostatné účely vyžadujúce samostatné základy.

Právna povinnosť – čl. 6 ods. 1 písm. c). Spracúvanie nevyhnutné na splnenie právnej povinnosti, ktorej prevádzkovateľ podlieha, pričom povinnosť musí vyplývať z práva Únie alebo členského štátu. Patria sem daňové záznamy, kontroly proti praniu špinavých peňazí, pracovnoprávne povinnosti a zákonné reportingu. Povinnosť musí byť konkrétna; všeobecná snaha uchovávať dáta preventívne nestačí.

Životne dôležité záujmy – čl. 6 ods. 1 písm. d). Spracúvanie nevyhnutné na ochranu života osoby. Ide o úzky základ určený pre mimoriadne situácie – lekárska starostlivosť, reakcia na katastrofy, ochrana ohrozených osôb – a nie o univerzálne záložné riešenie pre údaje o zdraví.

Verejná úloha – čl. 6 ods. 1 písm. e). Spracúvanie nevyhnutné na splnenie úlohy vo verejnom záujme alebo pri výkone verejnej moci. Relevantné pre orgány verejnej moci a pre organizácie vykonávajúce funkcie verejnej povahy.

Oprávnené záujmy – čl. 6 ods. 1 písm. f). Spracúvanie nevyhnutné pre oprávnené záujmy prevádzkovateľa alebo tretej strany, ak neprevažujú záujmy alebo základné práva a slobody dotknutej osoby. Ide o najpružnejší a najnáročnejší základ z hľadiska disciplíny: posúdenie oprávnených záujmov musí dokumentovať záujem, nevyhnutnosť spracúvania, test vyváženia proti právam dotknutej osoby a uplatnené záruky. Orgánom verejnej moci nie je dostupný pre ich verejné úlohy.

Voľbu určujú dve pravidlá. Po prvé, musíte zvoliť základ pred začatím spracúvania, nie spätne skonštruovať základ po sťažnosti. Po druhé, základ musí byť uvedený vo vašich zásadách ochrany osobných údajov podľa čl. 13 ods. 1 písm. c) a čl. 14 ods. 1 písm. d) a nemôžete ho ľubovoľne meniť – prechod od oprávnených záujmov k súhlasu uprostred spracúvania spravidla nie je prípustný, pretože súhlas získaný pod tlakom „súhlas, alebo prestaneme poskytovať službu” nie je slobodný.

Čo sa mení pri spracúvaní osobitných kategórií údajov?

Čl. 9 ods. 1 zakazuje spracúvanie osobitných kategórií údajov – rasového alebo etnického pôvodu, politických názorov, náboženského alebo filozofického presvedčenia, členstva v odboroch, genetických údajov, biometrických údajov na jedinečnú identifikáciu, údajov o zdraví a údajov o sexuálnom živote alebo sexuálnej orientácii – ak sa neuplatní niektorá z podmienok podľa čl. 9 ods. 2. Patrí sem výslovný súhlas, povinnosti v pracovnoprávnej a sociálnej oblasti, životne dôležité záujmy tam, kde dotknutá osoba nemôže dať súhlas, údaje zjavne zverejnené samotnou osobou, právne nároky, významný verejný záujem, preventívne a pracovné lekárstvo, verejné zdravie a archívne alebo výskumné účely.

Väčšina podmienok podľa čl. 9 ods. 2 vyžaduje základ v práve Únie alebo členského štátu, takže praktická analýza je špecifická podľa jurisdikcie. Článok 10 pridáva ďalšiu vrstvu: spracúvanie osobných údajov o odsúdeniach a trestných činoch vyžaduje splnomocnenie právom Únie alebo členského štátu alebo kontrolu orgánu verejnej moci.

Pre IT tímy majú prevádzkové dôsledky priamy dopad. Osobitné kategórie vyžadujú silnejšie kontroly – zvyčajne šifrovanie so samostatnou správou kľúčov, prísny prístup podľa účelu, rozšírené auditné logovanie a často DPIA, pretože je naplnený prah rizika podľa čl. 35 ods. 3 písm. b) pri rozsiahlom spracúvaní takých údajov. Biometrická autentifikácia si zaslúži zvláštnu opatrnosť: ak sa biometrická šablóna používa na jedinečnú identifikáciu, ide o osobitnú kategóriu, aj keď je šablóna matematickou reprezentáciou, nie obrazom.

Právne základy v praxi

Aké práva majú dotknuté osoby a ako ich plníte?

Práva dotknutých osôb sú miestom, kde sa súlad s GDPR mení na prevádzkovú službu s lehotami. Každé právo má spúšťač, lehotu na odpoveď a stopu dôkazov a každé sa dotýka niekoľkých systémov.

Osem práv dotknutých osôb

Právo na informácie – články 13–14. Dotknuté osoby musia pri zhromaždení dostať konkrétne informácie: totožnosť prevádzkovateľa, účely, právny základ, príjemcov, prenosy, dobu uchovávania, práva a právo podať sťažnosť. Ak údaje nie sú získané priamo od dotknutej osoby, informácie musia byť poskytnuté do jedného mesiaca (alebo pri prvej komunikácii, podľa toho, čo nastane skôr).

Právo na prístup – článok 15. Dotknuté osoby môžu získať potvrdenie, či sú ich údaje spracúvané, kópiu týchto údajov a informácie o účeloch, kategóriách, príjemcoch, dobe uchovávania a existencii automatizovaného rozhodovania. V praxi ide o právo s najvyšším objemom a o právo, ktoré najčastejšie odhalí slabé mapovanie dát, pretože odpoveď musí pokryť každý systém obsahujúci údaje danej osoby – vrátane logov, záloh, tiketov podpory, tabuliek a tieňového IT.

Právo na opravu – článok 16. Nepresné údaje musia byť opravené bez zbytočného odkladu, neúplné doplnené. Oprava sa musí šíriť do nadväzujúcich systémov, odvodených dátových sád a analytiky.

Právo na výmaz – článok 17. Známe aj ako právo byť zabudnutý. Uplatní sa, ak údaje už nie sú potrebné, bol odvolaný súhlas, dotknutá osoba vzniesla námietku a neexistuje prevažujúci oprávnený dôvod, spracúvanie bolo protiprávne alebo právna povinnosť vyžaduje výmaz. Nie je absolútne: neplatí, ak je spracúvanie nevyhnutné na splnenie právnych povinností, pre právne nároky, pre verejné zdravie alebo pre archívne a výskumné účely vo verejnom záujme. Výmaz sa musí vzťahovať aj na tretie strany, ktorým boli údaje poskytnuté.

Právo na obmedzenie spracúvania – článok 18. Spracúvanie možno pozastaviť, kým je spochybnená presnosť alebo zákonnosť. Technicky ide o stavový príznak, ktorý musí potlačiť všetko spracúvanie pri zachovaní záznamu.

Právo na prenosnosť údajov – článok 20. Ak je spracúvanie založené na súhlase alebo zmluve a prebieha automatizovane, dotknutá osoba môže dostať svoje údaje v štruktúrovanom, bežne používanom a strojovo čitateľnom formáte a nechať ich preniesť inému prevádzkovateľovi, ak je to technicky uskutočniteľné.

Právo vzniesť námietku – článok 21. Dotknuté osoby môžu vzniesť námietku proti spracúvaniu založenému na oprávnených záujmoch alebo verejnej úlohe a prevádzkovateľ musí spracúvanie ukončiť, ak nepreukáže naliehavé oprávnené dôvody. Pri priamom marketingu je právo absolútne a bezpodmienečné: spracúvanie musí skončiť okamihom prijatia námietky.

Práva pri automatizovanom rozhodovaní – článok 22. Dotknuté osoby majú právo nebyť predmetom rozhodnutia založeného výhradne na automatizovanom spracúvaní vrátane profilovania, ktoré má právne účinky alebo ich obdobne významne ovplyvňuje – ak to nie je nevyhnutné pre zmluvu, povolené zákonom alebo založené na výslovnom súhlase. Tam, kde sú také rozhodnutia prípustné, musia záruky zahŕňať ľudský zásah, vysvetlenie logiky a možnosť rozhodnutie napadnúť. Tento článok je čoraz relevantnejší pre úverové skórovanie, screening uchádzačov, stanovenie poistného a detekciu podvodov pomocou AI.

Ako prevádzkovo zvládnuť žiadosť o prístup k údajom?

Žiadosť o prístup podľa článku 15 musí byť vybavená do jedného mesiaca od prijatia. Túto lehotu možno predĺžiť o ďalšie dva mesiace pri komplexných alebo početných žiadostiach, ale predĺženie musí byť oznámené s odôvodnením v prvom mesiaci. Lehota začína plynúť, keď žiadosť prijme ktorákoľvek časť organizácie, nie keď dorazí k tímu pre ochranu údajov.

Overenie totožnosti je prípustné a očakávané. Prevádzkovateľ môže požiadať o informácie nevyhnutné na potvrdenie totožnosti, ale nesmie zhromažďovať viac, než je na tento účel potrebné. Ak je žiadosť zjavne nedôvodná alebo neprimeraná, možno účtovať primeraný poplatok alebo žiadosť odmietnuť – dôkazné bremeno však nesie prevádzkovateľ.

Fungujúci proces žiadostí o prístup potrebuje šesť komponentov:

1. Jediný vstupný kanál zverejnený v zásadách ochrany osobných údajov a monitorovaný, s protokolovaním každej žiadosti pri prijatí.
2. Zdokumentovaný rozsah vyhľadávania uvádzajúci každý systém, databázu, logovacie úložisko, zálohu, schránku a sprostredkovateľa, ktorý môže obsahovať osobné údaje danej osoby.
3. Workflow na získanie dát vrátane súčinnosti sprostredkovateľov, ktorí musia reagovať podľa čl. 28 ods. 3 písm. e).
4. Krok redakcie na odstránenie údajov tretích strán a právne chráneného alebo vylúčeného materiálu, so zaznamenaným dôvodom výnimky.
5. Zabezpečený spôsob doručenia – šifrovaný prenos alebo autentifikovaný portál – nikdy nie nešifrovaná príloha e-mailu.
6. Záznam o uzavretí s dátumami, rozhodnutiami, uplatnenými výnimkami a uchovanými dôkazmi pre účely zodpovednosti.

Organizácie, ktoré žiadosti o prístup zvládajú dobre, takmer vždy najprv investovali do mapovania dát. Nemožno získať to, čo nebolo nikdy inventarizované, a tridsaťdňová lehota neodpúšťa prácu s vyhľadávaním.

Práva dotknutých osôb v prehľade

Aké sú kľúčové prevádzkové povinnosti súladu s GDPR?

Okrem zásad a práv ukladá GDPR súbor pomenovaných prevádzkových povinností. Každá má spúšťaciu podmienku, požadovaný výstup a prirodzeného vlastníka. Považovať ich za zoznam dokumentov je najrýchlejšia cesta k zisteniu auditu; považovať ich za kontroly s vlastníkmi je najrýchlejšia cesta k trvalému súladu.

Záznamy o činnostiach spracúvania a mapovanie dát – článok 30

Článok 30 vyžaduje, aby prevádzkovatelia a sprostredkovatelia viedli záznamy o činnostiach spracúvania. U prevádzkovateľov musí záznam obsahovať účely, kategórie dotknutých osôb a osobných údajov, príjemcov, prenosy do tretích krajín a záruky, doby uchovávania a prípadne bezpečnostné opatrenia. Organizácie s menej ako 250 zamestnancami majú obmedzenú výnimku, ktorá je však užšia, než sa zdá: neplatí, ak spracúvanie nie je príležitostné, ak pravdepodobne povedie k riziku pre práva a slobody alebo ak sa týka osobitných kategórií údajov – teda podmienok, ktoré opisujú väčšinu komerčného spracúvania dát.

Záznam je len taký dobrý ako mapovanie dát, ktoré za ním stojí. Užitočná mapa vzniká systémovým prieskumom, nie z rozhovorov. Mala by pri každom poli osobných údajov odpovedať: ktorý systém ich obsahuje, kto je vlastníkom, aký je účel, ktorý právny základ platí, kto má prístup, kam sa prenášajú, ako dlho sa uchovávajú a ako sa mažú. Vo väčšine organizácií ide o najväčší diel práce v celom programe – a o základ pre všetko ostatné.

Ochrana údajov už vo fáze návrhu a v predvolenom nastavení – článok 25

Článok 25 vyžaduje, aby bola ochrana údajov zabudovaná do spracúvania od začiatku a v predvolenom nastavení sa uplatňovali nastavenia najviac chrániace súkromie, bez toho aby dotknutá osoba musela čokoľvek robiť. Práve klauzula o predvolenom nastavení organizácie zaskočí: aplikácia, ktorá zverejňuje profilové údaje, kým používateľ nenájde nastavenie, test nesplnila – bez ohľadu na to, ako dobre je nastavenie zdokumentované.

Zavedenie článku 25 znamená, že požiadavky na ochranu údajov vstupujú do životného cyklu vývoja ako testovateľné kritériá, nie ako právna príloha. Typické návrhové vzory zahŕňajú minimalizáciu na úrovni schémy, pseudonymizáciu ako predvolený stav pre analytické využitie, tokeny na prístup viazaný na účel, automatizované vymáhanie uchovávania, stav súhlasu ako prvotriedny atribút dátového modelu a nastavenia chrániace súkromie v používateľských rozhraniach.

Posúdenie vplyvu na ochranu osobných údajov – článok 35

DPIA je vyžadovaná, ak druh spracúvania pravdepodobne povedie k vysokému riziku pre práva a slobody fyzických osôb. Čl. 35 ods. 3 uvádza tri prípady, ktoré takmer vždy DPIA spúšťajú: systematické a rozsiahle vyhodnocovanie osobných aspektov na základe automatizovaného spracúvania vrátane profilovania, na základe ktorého sa prijímajú rozhodnutia s právnymi alebo obdobne významnými účinkami; rozsiahle spracúvanie osobitných kategórií alebo údajov o trestných činoch; a systematické rozsiahle sledovanie verejne prístupných priestorov.

Dozorné orgány zverejňujú zoznamy činností spracúvania vyžadujúcich DPIA a kritériá EDPB – vyhodnocovanie alebo skórovanie, automatizované rozhodovanie s právnym alebo obdobným účinkom, systematické sledovanie, citlivé údaje, spracúvanie vo veľkom rozsahu, párovanie alebo spájanie dátových sád, údaje o zraniteľných osobách, inovatívne využitie technológií a spracúvanie brániace dotknutým osobám vo výkone práva – sa používajú na určenie, či bol prah prekročený. Dve alebo viac kritérií zvyčajne znamenajú, že DPIA je nutná.

Obhájiteľná DPIA je štruktúrované posúdenie rizík, nie formulár. Mala by systematicky opísať spracúvanie, posúdiť nevyhnutnosť a primeranosť vzhľadom na účel, identifikovať riziká pre dotknuté osoby, definovať zmierňujúce opatrenia, zaznamenať stanovisko zodpovednej osoby, ak je určená, a zdokumentovať prijaté rozhodnutie – vrátane rozhodnutia pokračovať so zvyškovým rizikom, čo musí byť zaznamenané a pri pretrvávajúcom vysokom riziku vyžaduje konzultáciu s dozorným orgánom podľa článku 36.

Potrebujete zodpovednú osobu za ochranu osobných údajov? – články 37–39

DPO je povinná v troch situáciách podľa čl. 37 ods. 1: ak spracúvanie vykonáva orgán verejnej moci alebo verejný subjekt s výnimkou súdov v súdnej činnosti; ak hlavné činnosti prevádzkovateľa alebo sprostredkovateľa spočívajú v spracúvaní, ktoré svojou povahou, rozsahom alebo účelom vyžaduje pravidelné a systematické rozsiahle sledovanie dotknutých osôb; a ak hlavné činnosti spočívajú v rozsiahlom spracúvaní osobitných kategórií údajov alebo údajov o odsúdeniach a trestných činoch.

DPO musí byť riadne zapojená, musí sa zodpovedať najvyššiemu vedeniu, nesmie dostávať pokyny na výkon svojich úloh, nesmie byť odvolaná ani postihnutá za ich plnenie a musí mať zodpovedajúce zdroje. DPO môže byť externá na základe zmluvy o poskytovaní služieb, čo je bežné v stredne veľkých organizáciách, ktoré potrebujú nezávislosť bez plného úväzku. Úlohy stanovuje článok 39: informovať a radiť, sledovať súlad vrátane školení a auditov, radiť k DPIA, spolupracovať s dozorným orgánom a pôsobiť ako kontaktný bod. DPO, ktorá je zároveň vedúcou IT, CISO alebo marketingovou riaditeľkou, vytvára štrukturálny konflikt záujmov, ktorý dozorné orgány opakovane kritizovali.

Zmluvy so sprostredkovateľmi a due diligence – článok 28

Ak je spracúvanie vykonávané v mene prevádzkovateľa, vyžaduje článok 28 písomnú zmluvu, ktorá sprostredkovateľa zaväzuje ku konkrétnym podmienkam: spracúvanie len na základe zdokumentovaných pokynov, dôvernosť, bezpečnostné opatrenia podľa článku 32, povolenie pred zapojením subdodávateľov, pomoc s právami dotknutých osôb a DPIA, hlásenie porušenia zabezpečenia prevádzkovateľovi, výmaz alebo vrátenie údajov na konci spolupráce a práva na audit a kontrolu. Zmluva musí rovnako stanoviť predmet, trvanie, povahu a účel spracúvania, druh osobných údajov a kategórie dotknutých osôb.

Zmluvy samy o sebe nie sú due diligence. Čl. 28 ods. 1 vyžaduje používať len sprostredkovateľov poskytujúcich dostatočné záruky, čo znamená posúdiť bezpečnostný stav pred začatím spolupráce – certifikácie, zhrnutia penetračných testov, transparentnosť subdodávateľov, históriu porušení zabezpečenia, možnosti umiestnenia dát a záväzky v oblasti reakcie na incidenty. Toto posúdenie sa musí pravidelne opakovať, pretože sa stav sprostredkovateľa mení s jeho rastom, akvizíciou alebo zavádzaním nových funkcií AI, ktoré znovu využívajú dáta zákazníkov.

Zabezpečenie spracúvania a hlásenie porušenia – články 32–34

Článok 32 vyžaduje technické a organizačné opatrenia zodpovedajúce riziku a výslovne uvádza pseudonymizáciu a šifrovanie, schopnosť zabezpečiť trvalú dôvernosť, integritu, dostupnosť a odolnosť, schopnosť obnoviť dostupnosť a prístup po incidente a proces pravidelného testovania a vyhodnocovania účinnosti opatrení. Umožňuje tiež využiť súlad so schváleným certifikačným mechanizmom ako prvok preukazovania súladu.

Článok 33 vyžaduje oznámenie porušenia osobných údajov príslušnému dozornému orgánu bez zbytočného odkladu a ak je to možné najneskôr do 72 hodín od okamihu, keď sa o ňom prevádzkovateľ dozvedel. Oznámenie musí opísať povahu porušenia, kategórie a približný počet dotknutých osôb a záznamov, DPO alebo kontaktný bod, pravdepodobné dôsledky a prijaté alebo navrhované opatrenia. Ak oznámenie nie je vykonané do 72 hodín, musí byť doplnené odôvodnením zdržania. Ak porušenie pravdepodobne nepovedie k riziku pre práva a slobody, oznámenie sa nevyžaduje – rozhodnutie však musí byť interne zdokumentované a sprostredkovatelia musia informovať prevádzkovateľa bez zbytočného odkladu podľa čl. 33 ods. 2.

Článok 34 vyžaduje informovať dotknuté osoby bez zbytočného odkladu, ak porušenie pravdepodobne povedie k vysokému riziku pre ich práva a slobody, ak neboli údaje šifrovaním urobené nezrozumiteľnými, následné opatrenia vysoké riziko neodstránili alebo by informovanie znamenalo neprimerané úsilie. V poslednom prípade je nutné verejné oznámenie.

Lehota 72 hodín je požiadavka na schopnosť, nie na papierovanie. Jej dodržanie znamená mať vopred pripravené a nacvičené detekciu, kritériá triage, klasifikáciu závažnosti, eskalačné cesty, právne posúdenie aj šablóny oznámení. Organizácie, ktoré reakciu na porušenie testujú formou tabletop cvičení a simulovaných incidentov, lehotu bežne dodržia. Organizácie, ktoré napíšu politiku a nikdy ju neprecvičia, nie.

Medzinárodné prenosy údajov po rozsudku Schrems II

Kapitola V obmedzuje prenos osobných údajov mimo EHP. Prenos je zákonný, ak Komisia prijala rozhodnutie o primeranosti, alebo ak pri absencii primeranosti platia vhodné záruky. Hlavnými zárukami sú štandardné zmluvné doložky (SCC), záväzné podnikové pravidlá, schválené kódexy správania a certifikačné mechanizmy. SCC z roku 2021 vyžadujú posúdenie vplyvu prenosu, ktoré analyzuje právnu úpravu a prax cieľovej krajiny a v prípade potreby zavádza doplnkové opatrenia.

Oblasť primeranosti sa skomplikovala. Rámec EÚ–USA pre ochranu súkromia ponúka cestu pre organizácie, ktoré sa podľa neho certifikujú, zatiaľ čo skorší Privacy Shield Súdny dvor v roku 2020 zrušil v rozsudku Schrems II. Keďže rozhodnutia o primeranosti možno napadnúť, vyspelé programy sa vyhýbajú tomu, aby považovali jediný mechanizmus prenosu za trvalo vyriešený. Praktické kroky: viesť register prenosov, kontrolovať umiestnenie dát a reťazce subdodávateľov, uplatňovať šifrovanie a úschovu kľúčov, ktoré kľúče ponechávajú v EHP tam, kde to riziko vyžaduje, a dokumentovať posúdenia vplyvu prenosu podľa cieľovej krajiny a druhu údajov.

Kľúčové prevádzkové povinnosti v prehľade

Ako sa súlad s GDPR líši od iných zákonov na ochranu údajov?

Nadnárodné organizácie sa zriedka stretávajú s jediným režimom ochrany údajov. Pochopenie toho, kde GDPR stojí voči svojim susedom, zabraňuje častej chybe vybudovať jednu sadu kontrol a predpokladať, že bude fungovať všade.

GDPR vs. CCPA/CPRA

California Consumer Privacy Act v znení California Privacy Rights Act je zákon o súkromí spotrebiteľov s odlišnou architektúrou. Vzťahuje sa na ziskové podniky spĺňajúce prahy obratu alebo objemu dát, ktoré konajú s obyvateľmi Kalifornie, a je postavený na právach k „personal information” a „sensitive personal information”. Vyžaduje informácie pri zhromaždení, práva na informácie, výmaz, opravu, odmietnutie predaja alebo zdieľania a obmedzenie použitia citlivých údajov a vymáhajú ho predovšetkým California Privacy Protection Agency a generálny prokurátor formou občianskoprávnych sankcií, nie správnych pokút odvodených od globálneho obratu.

Praktické rozdiely, ktoré sú dôležité pre vývojové tímy, spočívajú v modeli opt-out (CCPA/CPRA umožňuje predaj a zdieľanie, kým spotrebiteľ neodmietne, zatiaľ čo GDPR vyžaduje právny základ pred začatím spracúvania), v absencii všeobecného rámca právnych základov v Kalifornii, v užšej definícii citlivých údajov a v odlišnom prístupe k údajom zamestnancov a B2B, ktoré GDPR pokrýva plne. Dobre postavený program GDPR zvyčajne napĺňa mnoho z CCPA/CPRA, ale architektúra súhlasu je skutočne odlišná a nemožno ju jednoducho znovu použiť.

GDPR vs. UK GDPR

Po odchode Spojeného kráľovstva z EÚ prevzala krajina GDPR do vnútroštátneho práva ako UK GDPR, v spojení s Data Protection Act 2018. Oba texty boli v okamihu divergencie v podstate totožné, takže jeden program súladu môže pokryť oba. Divergencia sa však sčítava: Spojené kráľovstvo sleduje vlastnú reformnú agendu, vlastný rámec medzinárodného prenosu s vlastnými pravidlami primeranosti, vlastný prístup k niektorým otázkam súhlasu a súborov cookie a vlastný regulátor v podobe Information Commissioner’s Office. Pre organizácie pôsobiace na oboch trhoch je praktickým prístupom spoločná základná sada kontrol s dokumentovaným registrom odchýlok podľa jurisdikcie.

GDPR vs. LGPD, PIPL a ďalšie režimy

Brazílska LGPD silne vychádza zo štruktúry GDPR – právne základy, práva dotknutých osôb, národný úrad ANPD a správne sankcie – obsahuje však samostatný právny základ ochrany úveru a odlišné pravidlá pre oprávnený záujem. Čínsky PIPL kombinuje koncepty podobné GDPR s rámovaním štátnej bezpečnosti, vyžaduje samostatný súhlas vo viacerých situáciách, ukladá lokalizáciu dát a bezpečnostné posúdenia pri určitých prenosoch a nemá nezávislý dozorný orgán v európskom zmysle. Indický DPDP Act volí iný prístup s modelom správcu súhlasov a vládou určenými významnými správcami dát. Revidovaný švajčiarsky FADP je GDPR natoľko blízky, že ho možno viesť v rámci toho istého programu, s vlastnými nuansami v registrácii a oznamovaní.

Strategickým záverom pre CTO je, že globálna architektúra ochrany súkromia má byť modulárna: spoločná inventúra dát, spoločný engine pre práva a spoločný bezpečnostný základ, s rozhodovacími vrstvami špecifickými pre jurisdikciu pre právny základ, súhlas, prenosy a uchovávanie. Snaha o jedinú globálnu politiku vedie buď k nákladnému nadmernému súladu, alebo k nákladnému nedostatočnému súladu.

Porovnanie naprieč jurisdikciami

Ako zaviesť program súladu s GDPR krok za krokom?

Programy súladu s GDPR zlyhávajú z predvídateľných dôvodov: začínajú písaním politík namiesto prieskumu, nemajú určených vlastníkov, považujú prácu za jednorazový projekt a nikdy neprodukujú dôkazy. Fázovaný program, ktorý stavia prieskum na začiatok a končí prevádzkovými rutinami, sa všetkým štyrom vyhýba.

Fáza 1 – Zistiť a posúdiť (dni 0–90)

Prvá fáza odpovedá na tri otázky: aké osobné údaje existujú, kam prúdia a kde sú najvyššie riziká. Kým na ne neexistujú odpovede, nemožno nič ďalšie spoľahlivo naplánovať.

• Určenie pôsobnosti. Overte, či platí čl. 3 ods. 1, čl. 3 ods. 2 alebo oboje, a určite vedúci dozorný orgán pri cezhraničnom spracúvaní.
• Mapovanie rolí. Určite postavenie prevádzkovateľa, spoločného prevádzkovateľa a sprostredkovateľa podľa toku dát – nie podľa právnickej osoby.
• Prieskum a inventúra dát. Skombinujte automatizované nástroje na objavovanie dát so štruktúrovanými rozhovormi s vlastníkmi systémov. Pokryte produkčné systémy, dátové sklady, logy, zálohy, SaaS aplikácie, tabuľky, nástroje podpory a tieňové IT. Zaznamenajte kategóriu údajov, účel, právny základ, uchovávanie, príjemcov a prenosy.
• Analýza medzier. Porovnajte súčasný stav so siedmimi zásadami a kľúčovými povinnosťami a ohodnoťte každú medzeru podľa pravdepodobnosti a dopadu na dotknuté osoby.
• Inventúra vysokých rizík. Identifikujte spracúvanie, ktoré pravdepodobne vyžaduje DPIA, a akékoľvek spracúvanie vyžadujúce predchádzajúcu konzultáciu.
• Nastavenie správy. Určite sponzora z vedenia, vedúceho programu, vlastníkov na úrovni systémov a rozhodnutie o DPO so zaznamenaným odôvodnením.

Fáza 2 – Napraviť a zdokumentovať (dni 90–180)

Druhá fáza mení zistenia na kontroly a vytvára dôkazy o zodpovednosti, ktorých absenciu odhalila fáza 1.

• Dokončite záznam podľa článku 30 a zaradte ho pod riadenie zmien, aby nové spracúvanie bolo pridané pred spustením.
• Uzavrite najprv rizikové medzery. Uprednostnite osobitné kategórie, rozsiahle sledovanie, cezhraničné prenosy a akékoľvek spracúvanie s nevyriešenou DPIA.
• Zaveďte vymáhanie uchovávania. Preveďte plán uchovávania do automatizovaných úloh výmazu, archivácie a expirácie záloh a overte, že fungujú.
• Prestavte proces práv. Zverejnite vstupný kanál, definujte rozsah vyhľadávania pre každý systém, vytvorte workflow na získanie dát a začnite protokolovať žiadosti a doby uzavretia.
• Opravte zmluvy. Uveďte zmluvy so sprostredkovateľmi do súladu s článkom 28, identifikujte subdodávateľov a uzavrite medzery v zárukách prenosu.
• Spevnite zabezpečenie. Zaveďte opatrenia podľa článku 32 identifikované v analýze medzier, vrátane šifrovania, riadenia prístupu, logovania, monitoringu a správy zraniteľností.
• Vytvorte runbook pre hlásenie. Definujte detekciu, triage, klasifikáciu závažnosti, eskaláciu, právne posúdenie, šablóny oznámení a plán cvičení.
• Školte. Školenia podľa rolí pre vývoj, marketing, HR, obchod a podporu s uchovanými záznamami o absolvovaní.

Fáza 3 – Prevádzkovať a preukazovať (dni 180–365, potom trvalý stav)

Posledná fáza mení súlad z projektu na rutinu. Práve táto fáza rozhoduje, či program prežije prvú zmenu vedenia alebo prvé veľké uvedenie produktu na trh.

• Zakotvite ochranu údajov v dodávke. Pridajte požiadavky na ochranu údajov do definície hotového a screening DPIA do procesov pre príjem požiadaviek a riadenie zmien.
• Prevádzkujte monitorovací cyklus. Mesačné metriky objemu žiadostí a dôb uzavretia, prípadov porušenia zabezpečenia, miery súhlasu, úspešnosti úloh výmazu, absolvovaných školení a revízií dodávateľov.
• Testujte. Ročné penetračné testy, pravidelné testy obnovy a aspoň ročné tabletop cvičenia reakcie na porušenie so zdokumentovanými poznatkami.
• Auditujte. Interný audit alebo externé hodnotenie proti siedmim zásadám a kľúčovým povinnostiam so sledovaním zistení do uzavretia.
• Revíziujte dodávateľov. Pravidelne prehodnocujte stav sprostredkovateľov, zoznamy subdodávateľov a usporiadanie prenosov a vždy, keď dodávateľ podstatne zmení svoju službu.
• Reportujte vedeniu. Krátka správa pre vedenie o stave súladu, zvyškových rizikách a potrebných rozhodnutiach.

Ak musí vaša organizácia prevádzkovať tento program súbežne s dodávkou produktu – a väčšina musí –, konzultačný tím Greyson spolupracuje s IT vedením na načasovaní prieskumu, nápravy a prevádzkových rutín tak, aby sa roadmapa nezastavila.

Dvanásťmesačný plán programu súladu s GDPR

Ako súlad s GDPR mení vývoj softvéru a testovanie?

Toto je oblasť, kde je súlad s GDPR najčastejšie nesprávne chápaný ako právna záležitosť a najčastejšie zlyháva ako inžinierska úloha. Povinnosti podľa článkov 25 a 32 sú návrhové a testovacie povinnosti. Nemožno ich splniť dokumentom s politikou napísaným po vydaní.

Ochrana údajov už vo fáze návrhu naprieč životným cyklom vývoja

Ochrana údajov už vo fáze návrhu funguje len vtedy, keď sa požiadavky na ochranu údajov správajú ako každá iná nefunkčná požiadavka: zachytené včas, testovateľné, sledované do splnenia a overené pred vydaním.

Fáza požiadaviek. Každá funkcia, ktorá sa dotýka osobných údajov, by mala deklarovať účel, právny základ, kategórie údajov, dobu uchovávania, príjemcov a príslušné práva dotknutých osôb. Screeningová otázka pri prijímaní požiadavky – spracúva tento zámer osobné údaje a spĺňa niektoré kritérium DPIA? – zachytí prípady, ktoré vyžadujú posúdenie skôr, než je architektúra zamrznutá.

Fáza návrhu. Minimalizácia údajov sa uplatňuje na úrovni schémy a API, nielen vo formulári. Pseudonymizácia, prístup viazaný na účel, šifrovanie a správa kľúčov sú navrhnuté vopred. Predvolené nastavenia chránia súkromie a napĺňajú klauzulu o predvolenom nastavení podľa článku 25.

Fáza vývoja. Stav súhlasu, značky účelu a metadáta o uchovávaní sa modelujú ako prvotriedne dátové atribúty, nie sa pridávajú dodatočne. Logovanie je v predvolenom stave konfigurované tak, aby osobné údaje vylučovalo alebo redigovalo, pretože logovacie úložiská patria medzi najčastejšie prehliadané zdroje osobných údajov.

Fáza testovania. Požiadavky na ochranu údajov sa testujú ako funkčné požiadavky: že výmaz skutočne maže vo všetkých úložiskách vrátane odvodených dátových sád a vyhľadávacích indexov, že úlohy uchovávania sa spúšťajú, že odvolanie súhlasu potlačí spracúvanie v nadväzujúcich systémoch, že riadenie prístupu obmedzuje podľa účelu, že export vytvára úplný a strojovo čitateľný záznam a že automatizované rozhodnutia poskytujú vysvetlenie a smerujú k ľudskej kontrole.

Fáza vydania. Kontroly ochrany údajov sa stávajú súčasťou definície hotového. Vydanie, ktoré mení spôsob spracúvania osobných údajov bez aktualizácie záznamu v registri alebo bez dokončenia screeningu DPIA, by nemalo prejsť bránou.

Fáza prevádzky. Vymáhanie uchovávania, revízie prístupov, monitoring a pravidelné prehodnocovanie DPIA podľa vývoja spracúvania. Čl. 32 ods. 1 písm. d) výslovne vyžaduje pravidelné testovanie účinnosti bezpečnostných opatrení, čím sa z kontinuálneho testovania stáva právne očakávanie, nie inžinierska preferencia.

Správa testovacích dát – pseudonymizácia verzus anonymizácia

Testovanie je miestom, kde sa súlad s GDPR a inžinierska prax najviditeľnejšie stretávajú. Vývojové a testovacie prostredia potrebujú realistické dáta, aby odhalili realistické chyby, ale produkčné osobné údaje nesmú byť kopírované do prostredí so slabšími kontrolami. GDPR ponúka dve cesty a nie sú zameniteľné.

Anonymizácia odstraňuje identifikovateľnosť do tej miery, že údaje úplne opúšťajú pôsobnosť GDPR. Aby sa to dosiahlo, musia údaje odolať osamoteniu (izolácia jednotlivca), prepojiteľnosti (spojenie záznamov o tej istej osobe) a inferencii (odvodenie atribútov z iných dát), s prihliadnutím na všetky pravdepodobne použiteľné prostriedky. Skutočná anonymizácia je náročná a pri mnohých podnikových dátových sadách – najmä tých s bohatými kvazi-identifikátormi, ako je PSČ, dátum narodenia a transakčné vzorce – nie je dosiahnuteľná bez zničenia analytického prínosu.

Pseudonymizácia nahrádza priame identifikátory umelými, pričom opätovná identifikácia zostáva možná prostredníctvom oddelene uloženého kľúčového materiálu. Pseudonymizované údaje zostávajú osobnými údajmi a v pôsobnosti nariadenia, ale článok 32 výslovne uznáva pseudonymizáciu ako bezpečnostné opatrenie a článok 25 ako návrhovú techniku. Pre väčšinu testovacích prostredí je pseudonymizácia s prísnym oddelením kľúčov praktickou a obhájiteľnou voľbou: zachováva referenčnú integritu a realistickosť dát, odstraňuje priamu identifikovateľnosť a napĺňa technické opatrenie podľa článku 32.

Nech zvolíte ktorúkoľvek cestu, niekoľko kontrol je neprekročiteľných. Testovacie prostredia nesmú byť dostupné s produkčnými prihlasovacími údajmi. Dáta musia byť maskované v mieste extrakcie, nie v cieľovom prostredí. Referenčná integrita musí byť zachovaná, aby testy zostali zmysluplné – rovnaký syntetický identifikátor musí byť konzistentný naprieč súvisiacimi tabuľkami. Musia byť pokryté voľné textové polia, prílohy, poznámky a metadáta dokumentov, pretože práve tam osobné údaje maskovanie najčastejšie prežijú. A samotný proces maskovania musí byť testovaný: vzorkovanie maskovaných dátových sád na zvyškové identifikátory je legitímna a očakávaná kontrola.

Cloud, dodávatelia a zabezpečenie sprostredkovateľov

Presun do cloudu neprenáša zodpovednosť. Podľa článku 28 zostáva prevádzkovateľ zodpovedný za výber sprostredkovateľa poskytujúceho dostatočné záruky a za to, že zmluva pokrýva požadované podmienky. Špeciálne pri cloude si zaslúžia pozornosť štyri oblasti.

Umiestnenie dát a reťazce prenosu. Cloudová služba môže replikovať dáta medzi regiónmi a využívať subdodávateľov v niekoľkých jurisdikciách. Mapovanie prenosov musí sledovať skutočnú cestu dát vrátane prístupu podpory z tretích krajín, čo je samo o sebe prenosom.

Transparentnosť subdodávateľov. Čl. 28 ods. 2 vyžaduje povolenie subdodávateľov. V praxi to znamená sledovať zverejnené zoznamy subdodávateľov, mať mechanizmus na námietku proti zmenám a zdokumentovaný postup pre prípad, že námietku skutočne vznesiete.

Výmaz a ukončenie. Čl. 28 ods. 3 písm. g) vyžaduje výmaz alebo vrátenie údajov na konci spolupráce. V multi-tenant architektúrach s veľkým objemom záloh overte, čo „výmaz” konkrétne znamená, aké sú lehoty a či zvyškové kópie pretrvávajú v zálohách alebo analytických úložiskách.

Rozširovanie funkcií a sekundárne využitie. Mnohé cloudové platformy dnes ponúkajú funkcie s podporou AI, ktoré môžu spracúvať dáta zákazníkov. Každú takú funkciu treba posúdiť: využíva dáta na tréning modelov, a ak áno, na akom právnom základe a s akou zmluvnou ochranou?

Kontroly ochrany údajov podľa fáz životného cyklu vývoja

Aké sú najčastejšie mýty o GDPR?

Väčšina zaseknutých programov nie je blokovaná zložitosťou. Blokuje ich malá skupina pretrvávajúcich presvedčení, ktoré vedú tímy k vynakladaniu úsilia na nesprávnom mieste.

Deväť mýtov, ktoré brzdia programy súladu

„Nie sme v EÚ, takže sa nás GDPR netýka.” Čl. 3 ods. 2 vzťahuje nariadenie na organizácie ponúkajúce tovar alebo služby osobám v EÚ alebo sledujúce ich správanie, bez požiadavky na prevádzkareň.

„Naše dáta sú anonymizované, takže nie sú v pôsobnosti.” Mimo pôsobnosti sú len nevratne anonymizované dáta. Pseudonymizované dáta a dáta, ktoré možno reidentifikovať kombináciou s inými dátovými sadami, zostávajú osobnými údajmi.

„Súhlas je jediný právny základ, ktorý potrebujeme.” Existuje ďalších päť základov. Použitie súhlasu tam, kde platí zmluva alebo právna povinnosť, vytvára zbytočné riziko, pretože súhlas možno kedykoľvek odvolať.

„Záznam sme vymazali, takže sme v súlade.” Výmaz musí zasiahnuť zálohy, odvodené dátové sady, analytické úložiská, vyhľadávacie indexy, cache a sprostredkovateľov. Výmaz, ktorý skončí pri primárnej databáze, je neúplný.

„DPIA je formalita pre právne oddelenie.” DPIA je posúdenie rizík, ktoré informuje návrhové rozhodnutia, musí byť vytvorené pred začatím spracúvania, so zaznamenaným stanoviskom DPO a prijatím zvyškového rizika na správnej úrovni.

„Náš poskytovateľ cloudu vyrieši GDPR za nás.” Sprostredkovatelia poskytujú záruky a zmluvné záväzky; zodpovednosť podľa čl. 5 ods. 2 a článku 24 zostáva na prevádzkovateľovi, vrátane prenosov a subdodávateľov.

„Máme na webe zásady ochrany osobných údajov, takže sme pokrytí.” Zásady ochrany osobných údajov plnia jednu povinnosť transparentnosti. Pre vymáhanie uchovávania, plnenie práv, bezpečnostné testy alebo pripravenosť na hlásenie nerobia nič.

„Súlad je jednorazový projekt.” Každý nový systém, dodávateľ, integrácia, marketingový kanál a funkcia AI mení podobu spracúvania. Súlad bez vstupu riadenia zmien sa rozpadne do jedného kvartálu.

„GDPR a AI Act sú oddelené problémy.” Systémy AI, ktoré spracúvajú osobné údaje, musia spĺňať oboje. Minimalizácia údajov, obmedzenie účelu a analýza právneho základu sa vzťahujú na tréningové dáta a článok 22 obmedzuje automatizované rozhodnutia, ktoré významne ovplyvňujú jednotlivcov.

Mýtus verzus realita

Koľko stojí nedodržanie predpisov?

Diskusii dominujú pokuty, ale tie zriedka bývajú najväčším nákladom. Pochopenie tak zákonnej štruktúry, ako aj prevádzkových dôsledkov pomáha postaviť obchodný prípad, ktorý obstojí pri kontrole rozpočtu.

Dvojstupňová štruktúra pokút podľa článku 83

Článok 83 stanovuje dve úrovne správnych pokút. Nižšia úroveň pokrýva povinnosti vrátane všeobecných zásad, povinností prevádzkovateľov a sprostredkovateľov, certifikačných orgánov a povinností kontrolných subjektov. Umožňuje pokuty až do výšky 10 miliónov eur alebo 2 % celkového celosvetového ročného obratu za predchádzajúci finančný rok, podľa toho, ktorá hodnota je vyššia.

Vyššia úroveň pokrýva porušenia základných zásad, práv dotknutých osôb, pravidiel medzinárodného prenosu a neplnenie príkazu dozorného orgánu. Umožňuje pokuty až do výšky 20 miliónov eur alebo 4 % celkového celosvetového ročného obratu, podľa toho, ktorá hodnota je vyššia.

Skutočnú výšku určuje niekoľko faktorov: povaha, závažnosť a trvanie porušenia, nedbanlivosť alebo úmysel, nápravné opatrenia, miera zodpovednosti, predchádzajúce porušenia, spolupráca s úradom a kategórie dotknutých osobných údajov. Pokuty musia byť v každom prípade účinné, primerané a odrádzajúce. Dozorné orgány môžu rovnako uložiť nápravné opatrenia – varovania, napomenutia, príkazy na nápravu, dočasné alebo trvalé zákazy spracúvania a pozastavenie tokov dát –, ktoré môžu byť obchodne škodlivejšie než pokuta.

Čo ukazujú dáta o vymáhaní

Agregované dáta o vymáhaní ukazujú, ako aktívne je režim uplatňovaný. Naprieč všetkými sledovanými prípadmi v EÚ a EHP ide celkový počet prípadov do tisícov a kumulované pokuty presahujú 7,5 miliardy eur, pričom najvyššia jednotlivá pokuta vo výške 1,2 miliardy eur bola uložená v Írsku. Španielsko je dlhodobo medzi najaktívnejšími úradmi podľa počtu prípadov, čo odráža vysoký podiel menších prípadov týkajúcich sa sťažností spotrebiteľov a súhlasu so súbormi cookie.

Rozloženie je dôležitejšie než titulky. Celkovej hodnote dominuje malý počet veľmi vysokých pokút, zatiaľ čo väčšina prípadov sa týka stredne veľkých a menších organizácií s podstatne nižšími sumami. Tento vzorec má jasný strategický dôsledok: riziko šetrenia nie je sústredené na nadnárodné spoločnosti. Sleduje viditeľnosť – sťažnosti spotrebiteľov, zle vybavené žiadosti dotknutých osôb, hlásenia porušenia zabezpečenia a sťažnosti konkurentov alebo zamestnancov. Organizácie, ktoré zle zareagujú na jedinú žiadosť o prístup alebo hlásenie porušenia, skončia v spise o vymáhaní oveľa pravdepodobnejšie než tie s plynulým a zdokumentovaným procesom.

Dva vzorce vymáhania sú pre IT vedenie obzvlášť relevantné. Po prvé, súhlas so súbormi cookie a sledovanie zostávajú v celej Európe trvalým zdrojom pokút, čo stavia marketingový technologický stack priamo do pôsobnosti. Po druhé, prípady nedostatočných technických a organizačných opatrení podľa článku 32 sú časté a vznikajú často zo zlyhaní, ktoré by vývojové tímy považovali za základné: neaktualizované systémy, nadmerné prístupové práva, nešifrované zálohy, exponované databázy a prihlasovacie údaje v kóde.

Náklady, ktoré sa v pokute nikdy neobjavia

Pre väčšinu organizácií je pokuta tou menšou čiastkou. Podstatné náklady sú prevádzkové:

• Náklady na nápravu. Krízová bezpečnostná práca, forenzné vyšetrovanie, prestavba systémov a externí poradcovia, zvyčajne pod časovým tlakom a za prémiové sadzby.
• Prerušenie prevádzky. Pozastavené spracúvanie, zmrazené toky dát, vypnutá marketingová schopnosť a zablokované uvedenia produktov.
• Strata zákazníkov a zmlúv. Vyradenie v nákupných procesoch, práva na ukončenie zmluvy, neúspešná due diligence a zdržané podnikové zákazky.
• Právna expozícia. Nároky na náhradu škody podľa článku 82 za hmotnú aj nehmotnú ujmu, vrátane hromadných žalôb.
• Pozornosť vedenia. Čas vedenia a predstavenstva odvedený k vyšetrovaniu, komunikácii s úradmi a riadeniu nápravy.
• Pretrvávajúci reputačný dopad. Rozhodnutia o vymáhaní sú verejné a trvalé a objavujú sa v každej následnej nákupnej revízii.

Správne pokuty v prehľade

Ako vyzerá budúcnosť súladu s GDPR?

GDPR je v platnosti dosť dlho na to, aby sa prax vymáhania ustálila a aby sa technologická krajina výrazne zmenila. Ďalšiu fázu budú formovať tri vývoje.

Konvergencia s aktom EÚ o umelej inteligencii

Akt EÚ o umelej inteligencii zavádza rizikový režim pre systémy AI s povinnosťami, ktoré sa pri systémoch spracúvajúcich osobné údaje výrazne prekrývajú s GDPR. Poskytovatelia aj používatelia vysokorizikových systémov musia riešiť správu dát vrátane kvality tréningových dát a sledovania biasu, viesť technickú dokumentáciu a logovanie, zabezpečiť ľudský dohľad a poskytovať transparentnosť dotknutým osobám. Mnohé z týchto povinností posilňujú požiadavky GDPR, ale nie sú totožné a vzťahujú sa na organizácie v rôznych rolách.

Pre IT vedenie z toho plynie, že správa AI a správa ochrany údajov by mali konvergovať, nie bežať ako paralelné programy. Jediný proces prijímania požiadaviek by mal viesť iniciatívy v oblasti AI tak cez screening DPIA, ako aj cez klasifikáciu podľa aktu o AI. Jediná inventúra dát by mala zaznamenávať pôvod tréningových dát, právny základ a uchovávanie. Jediná sada dokumentácie modelov by mala slúžiť obom režimom. Organizácie, ktoré to postavia oddelene, zdvojnásobia úsilie a vytvoria nekonzistencie, ktorých si regulátori všimnú.

Súhlas so súbormi cookie, ePrivacy a únava zo súhlasov

Rozhrania na súhlas zostávajú najviditeľnejšou časťou súladu s GDPR a jednou z najčastejšie súdne riešených tém. Dozorné orgány v celej Európe naďalej preverujú súhlasové bannery, symetriu odmietnutia, temné vzorce, predzaškrtnuté políčka a súčinnosť súhlasu s pravidlami smernice ePrivacy o ukladaní informácií do koncových zariadení. Trend smeruje k prísnejšiemu vymáhaniu zásady „odmietnuť musí byť rovnako ľahké ako prijať” a k jasnejšiemu rozlíšeniu medzi nevyhnutnými a nepotrebnými technológiami.

Zároveň sú používatelia voči žiadostiam o súhlas stále odolnejší, čo vytvára tlak na organizácie, aby tam, kde je to vhodné, používali alternatívne právne základy a obmedzili sledovanie na skutočne nevyhnutné. Serverové a na súkromie ohľaduplné meranie sa stáva mainstreamom práve preto, že znižuje tak právnu expozíciu, ako aj trenie okolo súhlasu. V tomto prípade minimalizácia údajov slúži právnemu súladu aj obchodným výsledkom súčasne.

Neistota režimu prenosov a cesta vpred

Medzinárodné prenosy zostávajú najvolatilnejšou oblasťou režimu. Rozhodnutia o primeranosti možno napadnúť a história Safe Harbour a Privacy Shield ukazuje, že mechanizmus platný dnes môže byť zajtra zrušený. Rámec EÚ–USA pre ochranu súkromia ponúka cestu pre certifikované organizácie, bol však už napadnutý na súde a jeho dlhodobá stabilita nie je zaručená.

Vyspelé organizácie reagujú znížením závislosti na jedinom mechanizme prenosu: minimalizujú objem osobných údajov prekračujúcich hranice, udržiavajú šifrovacie kľúče v úschove v EÚ tam, kde to riziko vyžaduje, štruktúrujú spracúvanie tak, aby citlivé operácie zostali v EHP, a vedú posúdenia vplyvu prenosu, ktoré možno rýchlo aktualizovať, ak mechanizmus padne. Najviac exponované sú organizácie, ktorých architektúra predpokladá, že právny mechanizmus zostane platný neobmedzene.

Často kladené otázky o súlade s GDPR

Čo je súlad s GDPR jednoducho povedané?

Súlad s GDPR znamená plniť požiadavky nariadenia (EÚ) 2016/679 vždy, keď spracúvate osobné údaje osôb v EÚ. V praxi to znamená mať právny základ pre každú činnosť spracúvania, jasne informovať osoby o tom, čo s ich údajmi robíte, plniť ich práva v lehotách, primerane zabezpečiť údaje, hlásiť určité porušenia do 72 hodín a vedieť to všetko preukázať dozornému orgánu.

Platí GDPR aj pre spoločnosti mimo EÚ?

Áno. Podľa čl. 3 ods. 2 sa GDPR vzťahuje na organizácie bez prevádzkarne v EÚ, ktoré ponúkajú tovar alebo služby osobám v EÚ alebo sledujú ich správanie, vrátane webovej analytiky alebo cielenej reklamy. Samotná dostupnosť webu nestačí – musí existovať dôkaz o úmysle cieliť na trh EÚ, napríklad jazykové verzie pre EÚ, ceny v eurách alebo možnosti doručenia do EÚ. Článok 27 spravidla vyžaduje určenie zástupcu v Únii.

Akých je sedem zásad súladu s GDPR?

Článok 5 stanovuje sedem zásad: zákonnosť, korektnosť a transparentnosť; obmedzenie účelu; minimalizácia údajov; presnosť; obmedzenie uloženia; integrita a dôvernosť; a zodpovednosť. Zodpovednosť je meta-zásadou – prevádzkovateľ musí byť schopný preukázať súlad s ostatnými šiestimi, a preto je dokumentácia, evidencia a dôkazy z testov ústredným prvkom každého dôveryhodného programu.

Aký je rozdiel medzi prevádzkovateľom a sprostredkovateľom?

Prevádzkovateľ určuje účely a prostriedky spracúvania; sprostredkovateľ spracúva osobné údaje v mene prevádzkovateľa na základe zdokumentovaných pokynov. Rozlíšenie je faktické, nie zmluvné, a tá istá organizácia môže mať pre rôzne činnosti obe role. Sprostredkovateľ, ktorý dáta zákazníkov znovu využije pre vlastné účely, napríklad na tréning vlastných AI modelov, sa pre túto činnosť stáva prevádzkovateľom a potrebuje vlastný právny základ.

Kedy je vyžadovaná zodpovedná osoba za ochranu osobných údajov?

Čl. 37 ods. 1 robí DPO povinnou v troch situáciách: ak spracúvanie vykonáva orgán verejnej moci alebo verejný subjekt (s výnimkou súdov v súdnej činnosti); ak hlavné činnosti zahŕňajú pravidelné a systematické rozsiahle sledovanie dotknutých osôb; a ak hlavné činnosti zahŕňajú rozsiahle spracúvanie osobitných kategórií údajov alebo údajov o trestných činoch. DPO musí byť nezávislá, zodpovedať sa najvyššiemu vedeniu, mať zodpovedajúce zdroje a byť chránená pred odvolaním alebo postihom za plnenie svojich úloh.

Kedy je posúdenie vplyvu na ochranu osobných údajov povinné?

DPIA je vyžadovaná pri spracúvaní, ktoré pravdepodobne povedie k vysokému riziku pre práva a slobody osôb. Čl. 35 ods. 3 uvádza tri prípady: systematické a rozsiahle automatizované vyhodnocovanie vrátane profilovania, na základe ktorého sa prijímajú rozhodnutia s právnymi alebo obdobne významnými účinkami; rozsiahle spracúvanie osobitných kategórií alebo údajov o trestných činoch; a systematické rozsiahle sledovanie verejne prístupných priestorov. Podľa kritérií EDPB dve alebo viac rizikových indícií zvyčajne znamená, že DPIA je nutná.

Ako dlho máte na nahlásenie porušenia zabezpečenia podľa GDPR?

Musíte informovať príslušný dozorný orgán bez zbytočného odkladu a ak je to možné do 72 hodín od okamihu, keď sa o porušení osobných údajov dozviete, v súlade s článkom 33. Ak oznámite neskôr, musíte zdržanie odôvodniť. Ak porušenie pravdepodobne povedie k vysokému riziku pre práva a slobody dotknutých osôb, článok 34 navyše vyžaduje informovať tieto osoby bez zbytočného odkladu. Sprostredkovatelia musia informovať prevádzkovateľa bez zbytočného odkladu.

Ako vysoké môžu byť pokuty podľa GDPR?

Článok 83 stanovuje dve úrovne. Porušenia nižšej úrovne môžu viesť k pokute až 10 miliónov eur alebo 2 % celkového celosvetového ročného obratu, podľa vyššej hodnoty. Porušenia vyššej úrovne – vrátane porušenia základných zásad, práv dotknutých osôb a pravidiel medzinárodného prenosu – až 20 miliónov eur alebo 4 % celosvetového ročného obratu, podľa vyššej hodnoty. Dozorné orgány môžu rovnako uložiť nepeňažné nápravné opatrenia, ako sú zákazy spracúvania, a jednotlivci môžu požadovať náhradu škody podľa článku 82.

Ako sa GDPR líši od CCPA?

GDPR je režim založený na právach, ktorý vyžaduje právny základ pred spracúvaním a vzťahuje sa na každú organizáciu spracúvajúcu údaje dotknutých osôb v EÚ. CCPA v znení CPRA je kalifornský zákon o súkromí spotrebiteľov, ktorý sa vzťahuje na kvalifikujúce ziskové podniky a sleduje model opt-out pre predaj a zdieľanie osobných informácií, bez všeobecného rámca právnych základov. Oba zákony priznávajú práva k osobným údajom, ale architektúra súhlasu a modely vymáhania sa zásadne líšia.

Ako dosiahnuť súlad s GDPR?

Súlad sleduje postupnosť, nie dokument. Najprv určite pôsobnosť a svoju rolu pre každý tok dát a potom zostavte inventúru dát a mapu tokov. Posúďte medzery voči siedmim zásadám a kľúčovým povinnostiam a identifikujte rizikové spracúvanie vyžadujúce DPIA. Potom napravte: dokončite záznam podľa článku 30, zaveďte vymáhanie uchovávania, postavte fungujúci proces práv, opravte zmluvy so sprostredkovateľmi, spevnite zabezpečenie a vytvorte otestovaný runbook pre hlásenie. Nakoniec prevádzkujte a preukazujte – zakotvite ochranu údajov v definícii hotového, sledujte metriky, pravidelne testujte a reportujte vedeniu. Súlad je udržiavaný stav, nie míľnik.