Soulad s GDPR: Kompletní průvodce pro IT manažery a vedoucí digitální transformace

Soulad s GDPR označuje stav, kdy organizace prokazatelně plní povinnosti podle nařízení (EU) 2016/679 – obecného nařízení o ochraně osobních údajů – vždy, když shromažďuje, ukládá, používá, sdílí nebo maže osobní údaje osob v Evropské unii. V praxi to znamená mít právní základ pro každou činnost zpracování, být o ní transparentní, plnit práva subjektů údajů, chránit údaje vhodnými technickými a organizačními opatřeními, hlásit určité případy porušení zabezpečení do 72 hodin a umět to vše prokázat dozorovému úřadu.

Právě posledně jmenovaná podmínka odlišuje soulad s GDPR od většiny regulatorních projektů, jaké kdy IT organizace vedla. GDPR nezakazuje pouze určité chování; přenáší důkazní břemeno na správce. Článek 24 vyžaduje, abyste byli schopni soulad prokázat, což z dokumentace, logování, návrhových rozhodnutí a výsledků testů činí rovnocenné výstupy projektu. Pro CTO nebo IT manažera tedy soulad s GDPR není právní dokument, který se založí a zapomene. Je to provozní disciplína, která zasahuje do architektury, životního cyklu vývoje softwaru, správy testovacích dat, smluv s dodavateli i reakce na incidenty.

Tento průvodce je určen lidem, kteří jej musí vybudovat: IT manažerům, CTO, vedoucím digitální transformace a pověřencům pro ochranu osobních údajů, kteří spolupracují s vývojovými týmy. Pokrývá vznik nařízení, sedm zásad a jejich význam v technickém vyjádření, právní základy zpracování, práva subjektů údajů a jejich plnění ve velkém měřítku, klíčové provozní povinnosti, rozdíly oproti příbuzným režimům, jako jsou CCPA a UK GDPR, dvanáctiměsíční plán zavádění, konkrétní dopady na vývoj softwaru a testování, mýty, které programy brzdí, skutečné náklady nevyhovujícího stavu a směr, kterým se nařízení vyvíjí s účinností aktu EU o umělé inteligenci.

Co je soulad s GDPR a proč je stále důležitý?

Odkud se soulad s GDPR vzal?

GDPR nevzniklo z ničeho. Jeho linie vede přes desetiletí evropského práva na ochranu údajů, které většina IT týmů nikdy nemusela číst.

Výchozím bodem je směrnice 95/46/ES z roku 1995. Směrnice stanoví cíl, který musí každý členský stát provést vlastním vnitrostátním právem. Dvacet osm zemí proto vytvořilo dvacet osm různých zákonů o ochraně údajů – s odlišnými definicemi, ohlašovacími povinnostmi, prahy pro oznámení a sankcemi. Panevropský mzdový systém musel v roce 2010 současně uspokojit německou podnikovou radu, francouzský registrační režim i britský ohlašovací rámec. Tato roztříštěnost byla drahá – a nejdražší byla právě tam, kde data proudí nejrychleji: přes hranice a uvnitř nadnárodních skupin.

V lednu 2012 navrhla Evropská komise jediné přímo použitelné nařízení místo směrnice. Rozdíl je podstatný. Nařízení platí ve všech členských státech bez vnitrostátního provedení, což znamená jeden text, jednu sadu definic a jednu sadu sankcí. Nařízení (EU) 2016/679 bylo přijato 27. dubna 2016, zveřejněno v Úředním věstníku 4. května 2016 a vymahatelné se stalo 25. května 2018 po dvouletém přechodném období, které mnohé organizace využily příliš pomalu.

Dvě návrhová rozhodnutí ve finálním textu ovlivnila vše, co následovalo. Za prvé, nařízení dostalo podle článku 3 extrateritoriální působnost, takže sleduje subjekt údajů, nikoli organizaci. Za druhé, zvolilo model výsledku a odpovědnosti místo modelu kontrolního seznamu. Nařízení jen zřídka říká, kterou technologii použít. Říká, jakého výsledku musíte dosáhnout, a pak po vás chce, abyste jej prokázali. Proto vypadá soulad s GDPR jinak v nemocnici, v bance a v rychle rostoucím SaaS startupu a proto stejná klauzule v článku 32 může v jedné organizaci vyžadovat šifrování a v jiné řízení přístupu podle rolí plus automatizovaný nástroj pro výmaz.

Slovo „soulad” nese správný důraz. Pochází z latinského complere – naplnit, dokončit. Soulad s GDPR je nepřetržitý cyklus plnění povinností, nikoli certifikát na zdi. Dozorové úřady, soudy i regulátoři zdůrazňují totéž: soulad je stav, který udržujete, a rozpadá se v okamžiku, kdy vznikne nový systém, dodavatel nebo tok dat bez kontroly.

Co soulad s GDPR konkrétně vyžaduje?

Soulad s GDPR: prokazatelný soulad veškerého zpracování osobních údajů s nařízením (EU) 2016/679 – zahrnující právní základ, transparentnost, omezení účelu, minimalizaci údajů, přesnost, omezení uložení, integritu a důvěrnost, odpovědnost, práva subjektů údajů, zabezpečení zpracování, řešení porušení zabezpečení a zákonné mezinárodní předávání – doložený dokumentací, kterou dozorový úřad může prověřit.

Rozloženo na části přináší tato definice osm konkrétních povinností, které musí být IT organizace schopna splnit na vyžádání:

1. Zaznamenaný právní základ pro každou činnost zpracování podle článku 6 a případně článku 9.
2. Inventuru údajů, která ukazuje, jaké osobní údaje existují, kde jsou uloženy, proč existují, kdo k nim má přístup, jak dlouho se uchovávají a kam se předávají.
3. Transparentní informace poskytované subjektům údajů jasným a srozumitelným jazykem, obvykle prostřednictvím vrstvených zásad ochrany osobních údajů a rozhraní pro souhlas v okamžiku potřeby.
4. Fungující procesy pro práva subjektů údajů – přístup, opravu, výmaz, omezení, přenositelnost, námitku a práva související s automatizovaným rozhodováním – se sledovanými lhůtami.
5. Bezpečnostní opatření odpovídající riziku podle článku 32, včetně šifrování, odolnosti, schopnosti obnovy a pravidelného testování.
6. Schopnost reakce na porušení zabezpečení, která umí klasifikovat, omezit, vyhodnotit a případně oznámit do 72 hodin.
7. Správu dodavatelů a předávání zahrnující smlouvy o zpracování podle článku 28 a mechanismy předávání podle kapitoly V.
8. Vrstvu odpovědnosti – záznamy o činnostech zpracování, DPIA, politiky, záznamy o školení a protokoly o rozhodnutích – která mění výše uvedených sedm bodů z tvrzení na důkazy.

Povšimněte si, co chybí: neexistuje žádná povinná technologie, žádná povinná certifikace ani pevná šablona dokumentu. GDPR definuje výsledky a provádění ponechává na organizaci. Tato svoboda je zároveň pastí. Znamená to, že neexistuje zkratka k souladu jiná než odvést práci: zmapovat, rozhodnout, zdokumentovat a otestovat.

Proč je soulad s GDPR obchodní, a ne jen právní záležitostí?

Považovat soulad s GDPR za právní úkol je nejčastějším důvodem, proč se programy zaseknou. Povinnosti mají právní původ, ale kontroly, které je naplňují, žijí v systémech, kódu a provozu. Tři obchodní dynamiky to konkretizují.

Nákup je řízen ochranou údajů. Podnikoví zákazníci v regulovaných odvětvích nyní rozesílají bezpečnostní a datové dotazníky s požadavky na důkazy specifické pro GDPR: aktuální záznamy o činnostech zpracování, shrnutí DPIA, seznamy subdodavatelů, posouzení dopadů předávání, historii porušení zabezpečení a práva na audit. Organizace, které tyto dokumenty nedokážou předložit, ztrácejí zakázky nebo pohlcují měsíce posuzování. Artefakty souladu se staly prodejním materiálem.

Důvěra má svou cenu. Zákazníci, zaměstnanci i partneři se rozhodují, kam umístí osobní údaje, podle vnímané kvality jejich zpracování. Veřejně oznámené porušení zabezpečení tuto percepci naruší rychleji, než ji jakýkoli marketingový program dokáže obnovit, a účinek přetrvává dlouho po skončení ohlašovací lhůty.

Datové programy jsou omezeny zákonností dat. Analytika, personalizace, strojové učení, migrace do cloudu i generativní AI – to vše spotřebovává osobní údaje. Každé z nich vyžaduje právní základ, účel, pravidlo pro výmaz a často DPIA. Organizace s vyspělým souladem s GDPR dodávají datové iniciativy rychleji, protože právní základ už stojí. Organizace bez něj objeví problém uprostřed projektu, kdy je architektura zamrzlá a přepracování drahé.

U klientů Greyson v regionu střední a východní Evropy je vzorec konzistentní: organizace, které chápou soulad s GDPR jako inženýrskou schopnost, a ne jako každoroční papírování, dokážou zavádět nové technologie bez krize souladu každé druhé čtvrtletí.

Kdo musí GDPR dodržovat?

GDPR odpovídá na tuto otázku ve dvou krocích. Věcná působnost definuje, co je regulováno – osobní údaje a zpracování. Územní působnost definuje, kdo je vázán, a je širší, než většina organizací mimo EU předpokládá.

Co je věcná působnost – co se považuje za osobní údaje?

Článek 4 odst. 1 definuje osobní údaje jako veškeré informace o identifikované nebo identifikovatelné fyzické osobě. Klíčové slovo je identifikovatelné. Údaje jsou osobní, pokud je lze propojit s osobou, přímo nebo nepřímo, s využitím prostředků, jejichž použití je pravděpodobné. Patří sem zřejmé identifikátory, jako je jméno, e-mailová adresa, rodné číslo a číslo účtu, ale i méně zřejmé:

• Online identifikátory – IP adresy, ID souborů cookie, otisky zařízení, reklamní identifikátory a mobilní advertising ID. GDPR je výslovně uvádí.
• Lokalizační údaje – záznamy GPS, data mobilních sítí, záznamy o přihlášení na místo.
• Pseudonymizované údaje – údaje, u nichž byly přímé identifikátory nahrazeny, ale opětovná identifikace zůstává možná. Pseudonymizované údaje jsou nadále osobními údaji a zůstávají v působnosti nařízení. Jde o jedno z nejzávažnějších technických nedorozumění v této oblasti.
• Zvláštní kategorie podle článku 9 – rasový nebo etnický původ, politické názory, náboženské nebo filozofické přesvědčení, členství v odborech, genetické údaje, biometrické údaje pro jedinečnou identifikaci, údaje o zdraví a údaje o sexuálním životě nebo sexuální orientaci.
• Údaje o trestných činech podle článku 10, jejichž zpracování vyžaduje orgán veřejné moci nebo výslovné zákonné zmocnění.
• Kontaktní údaje B2B – pracovní e-mailová adresa a pracovní pozice konkrétní osoby jsou osobními údaji. Firemní kontext je nevyjímá z působnosti.

Dvě upřesnění ušetří mnoho diskusí. Za prvé, anonymizované údaje nejsou v působnosti nařízení, ale pouze pokud je anonymizace skutečně nevratná. Evropský sbor pro ochranu osobních údajů výslovně uvedl, že anonymizace musí odolat útokům typu osamocení, propojitelnosti a inference, s přihlédnutím ke všem pravděpodobně použitelným prostředkům. Většina „anonymizovaných” exportů, které v podnicích kolují, tento test nesplní. Za druhé, agregované statistiky odvozené z osobních údajů nejsou automaticky mimo působnost – rozhodující je, zda osoby zůstávají identifikovatelné.

Co je územní působnost – platí GDPR i mimo EU?

Článek 3 stanoví dva nezávislé spouštěče a stačí kterýkoli z nich.

Článek 3 odst. 1 – kritérium provozovny. GDPR se vztahuje na zpracování v souvislosti s činnostmi provozovny v Unii bez ohledu na to, zda zpracování samo probíhá v Unii. Slovenská společnost zpracovávající údaje na serverech v Asii je v působnosti. Stejně tak pobočka, zástupce nebo trvalé uspořádání, jehož prostřednictvím je činnost v Unii vykonávána.

Článek 3 odst. 2 – kritérium cílení. GDPR se vztahuje na organizace bez provozovny v Unii, pokud nabízejí zboží nebo služby subjektům údajů v Unii nebo sledují jejich chování v Unii. Bod odůvodnění 23 objasňuje, že pouhá webová stránka dostupná z EU nestačí; musí existovat důkaz o úmyslu nabízet zboží nebo služby osobám v EU – například možnost platby v eurech, jazykové verze pro EU, možnosti doručení do členských států nebo reklama cílená na trhy EU. Bod odůvodnění 24 pokrývá sledování, které zahrnuje behaviorální reklamu, analytický profiling, sledovací technologie a nositelná zařízení.

Proto je americká, indická nebo brazilská společnost s evropskými zákazníky, s evropskými návštěvníky webu sledovanými analytikou nebo s evropskými zaměstnanci na výplatní pásce obvykle v působnosti nařízení. Tam, kde platí článek 3 odst. 2, vyžaduje článek 27 určení zástupce v Unii, pokud se neuplatní výjimka. Vymáhání vůči organizacím mimo EU se opírá o mechanismy spolupráce podle článku 50, právní pomoc a stále více o praktický tlak přístupu na trh.

Kdo je kdo v ekosystému GDPR?

Správné určení role není sémantika. Role určuje vaše povinnosti, vaši odpovědnost i smlouvy, které musíte mít uzavřené. Překvapivý podíl selhání souladu lze vysledovat k organizaci, která se označila za zpracovatele, ačkoli byla ve skutečnosti správcem.

Kdo je správce a kdo zpracovatel?

Správce je organizace, která rozhoduje, proč a jak se osobní údaje zpracovávají. Zpracovatel tyto pokyny vykonává. Test určení je faktický, nikoli smluvní: nemůžete se zbavit povinností správce tím, že se ve smlouvě označíte za zpracovatele, pokud ve skutečnosti rozhodujete o účelech a prostředcích.

Několik situací organizace pravidelně zaskočí. Poskytovatel SaaS, který zpracovává data zákazníků striktně podle zdokumentovaných pokynů, je zpracovatelem – pokud však tato data znovu využije pro vlastní produktovou analytiku, srovnávání nebo trénink AI modelů, stává se pro tuto činnost správcem a potřebuje vlastní právní základ. Marketingová agentura, která rozhoduje, na které cílové skupiny se zaměřit, je správcem, i když vztah se zákazníkem vlastní její klient. Pokud jsou účely stanoveny společně, uplatní se společné správcovství podle článku 26 a ujednání musí být zdokumentováno.

Praktický důsledek: jedna organizace může mít pro různé činnosti zpracování několik rolí současně. Vyspělé programy souladu s GDPR proto vedou mapu rolí podle toku dat, nikoli jednu značku pro celou organizaci.

Jakých je sedm zásad souladu s GDPR?

Článek 5 obsahuje sedm zásad, které určují vše ostatní v nařízení. Každé právo, povinnost, DPIA i pokuta se nakonec odvíjí od některé z nich. Čteny jako seznam působí abstraktně; čteny jako technické požadavky jsou velmi konkrétní.

Sedm zásad jednotlivě

1. Zákonnost, korektnost a transparentnost – čl. 5 odst. 1 písm. a). Zpracování musí spočívat na jednom ze šesti právních základů podle článku 6, nesmí být pro subjekt údajů nepřiměřeně nepříznivé, neočekávané ani zavádějící a musí být jasně komunikováno. Technicky to znamená pole v registru zpracování, značku účelu u každého toku dat a zásady ochrany osobních údajů, kterým porozumí i neprávník.

2. Omezení účelu – čl. 5 odst. 1 písm. b). Údaje shromážděné pro jeden stanovený, výslovný a legitimní účel nelze použít pro účel s ním neslučitelný. Slučitelnost se posuzuje s ohledem na souvislost mezi účely, kontext shromáždění, povahu údajů, důsledky pro subjekty údajů a existenci záruk. Opětovné použití fakturační adresy zákazníka pro kontrolu podvodů je obvykle slučitelné; pro trénink univerzálního AI modelu obvykle nikoli.

3. Minimalizace údajů – čl. 5 odst. 1 písm. c). Shromažďujte jen to, co je přiměřené, relevantní a omezené na nezbytnou míru. Tuto zásadu nejčastěji porušují analytické implementace, formuláře pro získávání kontaktů v CRM a logovací pipeline, které zachycují více, než kdokoli dokáže odůvodnit. Každé další pole zvyšuje riziko porušení zabezpečení, náročnost vyřízení žádostí o přístup a náklady na ukládání.

4. Přesnost – čl. 5 odst. 1 písm. d). Osobní údaje musí být přesné a v případě potřeby aktuální; nepřesné údaje je nutné bez zbytečného odkladu vymazat nebo opravit. V praxi to znamená kontrolu kvality dat, správu duplicit a opravné workflow, které se šíří do navazujících systémů včetně analytiky a záloh.

5. Omezení uložení – čl. 5 odst. 1 písm. e). Údaje nesmí být uchovávány v identifikovatelné podobě déle, než je nezbytné. Slovo „nezbytné” vyžaduje skutečný plán uchovávání pro každou kategorii údajů a účel a jeho automatizované vymáhání. Plány uchovávání, které existují jen v dokumentu s politikou, ale ne v kódu, jsou nejčastějším zjištěním auditu v celém nařízení.

6. Integrita a důvěrnost – čl. 5 odst. 1 písm. f). Vhodná technická a organizační bezpečnostní opatření, včetně ochrany před neoprávněným nebo protiprávním zpracováním, náhodnou ztrátou, zničením nebo poškozením. Článek 32 upřesňuje: pseudonymizace a šifrování, průběžné zajištění důvěrnosti a integrity, odolnost, schopnost obnovy a pravidelné testování.

7. Odpovědnost – čl. 5 odst. 2. Správce odpovídá za prokázání souladu s ostatními šesti zásadami. Odpovědnost je meta-zásada, která mění úmysl v důkaz, a je důvodem existence záznamů o činnostech zpracování, DPIA, záznamů o školeních a návrhové dokumentace.

Jak odpovědnost mění to, co musíte vybudovat?

Odpovědnost má nepříjemný důsledek, který by si IT vedoucí měli osvojit včas: nepřítomnost důkazů se považuje za důkaz nepřítomnosti. Dozorový úřad nemusí prokazovat, že jste zpracovávali údaje protiprávně. Může vás vyzvat, abyste soulad prokázali, a pokud to nedokážete, je porušena samotná zásada odpovědnosti.

To mění několik technických rozhodnutí. Platforma pro správu souhlasů, která zaznamenává přesné znění, časové razítko, verzi rozhraní a rozsah každého souhlasu, není byrokracie; je to důkaz, který činí zásadu zákonnosti obhajitelnou. DPIA, která dokumentuje zvažovaná rizika a zamítnuté alternativy, není zbytečná zátěž; je to artefakt, který prokazuje odpovědnost. CI/CD pipeline, která spouští testy relevantní pro ochranu údajů a archivuje výsledky, je kontrolou souladu, nejen kontrolou kvality.

Odpovědnost také vyžaduje, aby byl soulad sledován, nikoli předpokládán. Článek 32 odst. 1 písm. d) výslovně požaduje proces pravidelného testování, posuzování a vyhodnocování účinnosti bezpečnostních opatření. Zde se testovací disciplína stává požadavkem GDPR, nikoli příjemným doplňkem.

Sedm zásad převedených na konkrétní kontroly

Jaké jsou právní základy pro zpracování osobních údajů?

Zpracování osobních údajů je zakázáno, pokud se neuplatní právní základ. Článek 6 jich nabízí šest. Správná volba je důležitá, protože základ určuje, co smíte dělat, o čem musíte informovat a zda mohou subjekty údajů vznést námitku nebo odvolat souhlas.

Šest právních základů podle článku 6

Souhlas – čl. 6 odst. 1 písm. a). Jakýkoli svobodně daný, konkrétní, informovaný a jednoznačný projev vůle subjektu údajů. Souhlas musí být stejně snadné odvolat jako udělit, nesmí být spojen s nesouvisejícími podmínkami a pro výslovný souhlas podle čl. 9 odst. 2 písm. a) musí splňovat vyšší standard. Souhlas je nejvíce nadužívaným a nejkřehčím základem, protože jej lze kdykoli odvolat a vyžaduje úplnou auditní stopu.

Smlouva – čl. 6 odst. 1 písm. b). Zpracování nezbytné pro splnění smlouvy se subjektem údajů nebo pro provedení opatření před uzavřením smlouvy na jeho žádost. Zahrnuje vyřízení objednávky, doručení, správu účtu a zpracování plateb – nikoli však marketing, analytiku nebo zlepšování produktu, což jsou samostatné účely vyžadující samostatné základy.

Právní povinnost – čl. 6 odst. 1 písm. c). Zpracování nezbytné pro splnění právní povinnosti, jíž správce podléhá, přičemž povinnost musí vyplývat z práva Unie nebo členského státu. Patří sem daňové záznamy, kontroly proti praní peněz, pracovněprávní povinnosti a zákonné reportingy. Povinnost musí být konkrétní; obecná snaha uchovávat data preventivně nestačí.

Životně důležité zájmy – čl. 6 odst. 1 písm. d). Zpracování nezbytné pro ochranu života osoby. Jde o úzký základ určený pro mimořádné situace – lékařská péče, reakce na katastrofy, ochrana ohrožených osob – a nikoli o univerzální záložní řešení pro údaje o zdraví.

Veřejný úkol – čl. 6 odst. 1 písm. e). Zpracování nezbytné pro splnění úkolu ve veřejném zájmu nebo při výkonu veřejné moci. Relevantní pro orgány veřejné moci a pro organizace vykonávající funkce veřejné povahy.

Oprávněné zájmy – čl. 6 odst. 1 písm. f). Zpracování nezbytné pro oprávněné zájmy správce nebo třetí strany, pokud nepřevažují zájmy nebo základní práva a svobody subjektu údajů. Jde o nejpružnější a nejnáročnější základ z hlediska disciplíny: posouzení oprávněných zájmů musí dokumentovat zájem, nezbytnost zpracování, test vyvážení proti právům subjektu údajů a uplatněné záruky. Orgánům veřejné moci není dostupný pro jejich veřejné úkoly.

Volbu určují dvě pravidla. Za prvé, musíte zvolit základ před zahájením zpracování, nikoli zpětně zkonstruovat základ po stížnosti. Za druhé, základ musí být uveden ve vašich zásadách ochrany osobních údajů podle čl. 13 odst. 1 písm. c) a čl. 14 odst. 1 písm. d) a nemůžete jej libovolně měnit – přechod od oprávněných zájmů k souhlasu uprostřed zpracování zpravidla není přípustný, protože souhlas získaný pod tlakem „souhlas, nebo přestaneme poskytovat službu” není svobodný.

Co se mění při zpracování zvláštních kategorií údajů?

Čl. 9 odst. 1 zakazuje zpracování zvláštních kategorií údajů – rasového nebo etnického původu, politických názorů, náboženského nebo filozofického přesvědčení, členství v odborech, genetických údajů, biometrických údajů pro jedinečnou identifikaci, údajů o zdraví a údajů o sexuálním životě nebo sexuální orientaci – pokud se neuplatní některá z podmínek podle čl. 9 odst. 2. Patří sem výslovný souhlas, povinnosti v pracovněprávní a sociální oblasti, životně důležité zájmy tam, kde subjekt nemůže dát souhlas, údaje zjevně zveřejněné samotným subjektem, právní nároky, významný veřejný zájem, preventivní a pracovní lékařství, veřejné zdraví a archivní nebo výzkumné účely.

Většina podmínek podle čl. 9 odst. 2 vyžaduje základ v právu Unie nebo členského státu, takže praktická analýza je specifická podle jurisdikce. Článek 10 přidává další vrstvu: zpracování osobních údajů o odsouzeních a trestných činech vyžaduje zmocnění právem Unie nebo členského státu nebo kontrolu orgánu veřejné moci.

Pro IT týmy mají provozní důsledky přímý dopad. Zvláštní kategorie vyžadují silnější kontroly – obvykle šifrování se samostatnou správou klíčů, přísný přístup podle účelu, rozšířené auditní logování a často DPIA, protože je naplněn práh rizika podle čl. 35 odst. 3 písm. b) při rozsáhlém zpracování takových údajů. Biometrická autentizace si zaslouží zvláštní opatrnost: pokud se biometrická šablona používá pro jedinečnou identifikaci, jde o zvláštní kategorii, i když je šablona matematickou reprezentací, nikoli obrazem.

Právní základy v praxi

Jaká práva mají subjekty údajů a jak je plníte?

Práva subjektů údajů jsou místem, kde se soulad s GDPR mění v provozní službu se lhůtami. Každé právo má spouštěč, lhůtu pro odpověď a stopu důkazů a každé se dotýká několika systémů.

Osm práv subjektů údajů

Právo na informace – články 13–14. Subjekty údajů musí při shromáždění obdržet konkrétní informace: totožnost správce, účely, právní základ, příjemce, předávání, dobu uchovávání, práva a právo podat stížnost. Pokud údaje nejsou získány přímo od subjektu, musí být informace poskytnuty do jednoho měsíce (nebo při první komunikaci, podle toho, co nastane dříve).

Právo na přístup – článek 15. Subjekty údajů mohou získat potvrzení, zda jsou jejich údaje zpracovávány, kopii těchto údajů a informace o účelech, kategoriích, příjemcích, době uchovávání a existenci automatizovaného rozhodování. V praxi jde o právo s nejvyšším objemem a o právo, které nejčastěji odhalí slabé mapování dat, protože odpověď musí pokrýt každý systém obsahující údaje dané osoby – včetně logů, záloh, tiketů podpory, tabulek a stínové IT.

Právo na opravu – článek 16. Nepřesné údaje musí být opraveny bez zbytečného odkladu, neúplné doplněny. Oprava se musí šířit do navazujících systémů, odvozených datových sad a analytiky.

Právo na výmaz – článek 17. Známé také jako právo být zapomenut. Uplatní se, pokud údaje již nejsou potřebné, byl odvolán souhlas, subjekt vznesl námitku a neexistuje převažující oprávněný důvod, zpracování bylo protiprávní nebo právní povinnost vyžaduje výmaz. Není absolutní: neplatí, pokud je zpracování nezbytné pro splnění právních povinností, pro právní nároky, pro veřejné zdraví nebo pro archivní a výzkumné účely ve veřejném zájmu. Výmaz se musí vztahovat i na třetí strany, kterým byly údaje poskytnuty.

Právo na omezení zpracování – článek 18. Zpracování lze pozastavit, dokud je zpochybněna přesnost nebo zákonnost. Technicky jde o stavový příznak, který musí potlačit veškeré zpracování při zachování záznamu.

Právo na přenositelnost údajů – článek 20. Pokud je zpracování založeno na souhlasu nebo smlouvě a probíhá automatizovaně, může subjekt obdržet své údaje ve strukturovaném, běžně používaném a strojově čitelném formátu a nechat je předat jinému správci, je-li to technicky proveditelné.

Právo vznést námitku – článek 21. Subjekty mohou vznést námitku proti zpracování založenému na oprávněných zájmech nebo veřejném úkolu a správce musí zpracování ukončit, pokud neprokáže naléhavé oprávněné důvody. U přímého marketingu je právo absolutní a bezpodmínečné: zpracování musí skončit okamžikem obdržení námitky.

Práva u automatizovaného rozhodování – článek 22. Subjekty mají právo nebýt předmětem rozhodnutí založeného výhradně na automatizovaném zpracování, včetně profilování, které má právní účinky nebo je obdobně významně ovlivňuje – pokud to není nezbytné pro smlouvu, povolené zákonem nebo založené na výslovném souhlasu. Tam, kde jsou taková rozhodnutí přípustná, musí záruky zahrnovat lidský zásah, vysvětlení logiky a možnost rozhodnutí napadnout. Tento článek je stále relevantnější pro úvěrové skórování, screening uchazečů, stanovení pojistného a detekci podvodů pomocí AI.

Jak provozně zvládnout žádost o přístup k údajům?

Žádost o přístup podle článku 15 musí být vyřízena do jednoho měsíce od obdržení. Tuto lhůtu lze prodloužit o další dva měsíce u komplexních nebo početných žádostí, ale prodloužení musí být sděleno s odůvodněním v prvním měsíci. Lhůta začíná běžet, když žádost obdrží kterákoli část organizace, nikoli když dorazí k týmu pro ochranu údajů.

Ověření totožnosti je přípustné a očekávané. Správce může požádat o informace nezbytné pro potvrzení totožnosti, ale nesmí shromažďovat více, než je pro tento účel potřeba. Pokud je žádost zjevně nedůvodná nebo nepřiměřená, lze účtovat přiměřený poplatek nebo žádost odmítnout – důkazní břemeno však nese správce.

Fungující proces žádostí o přístup potřebuje šest komponent:

1. Jediný vstupní kanál zveřejněný v zásadách ochrany osobních údajů a monitorovaný, s protokolováním každé žádosti při obdržení.
2. Zdokumentovaný rozsah vyhledávání uvádějící každý systém, databázi, logovací úložiště, zálohu, schránku a zpracovatele, který může obsahovat osobní údaje dané osoby.
3. Workflow pro získání dat včetně součinnosti zpracovatelů, kteří musí reagovat podle čl. 28 odst. 3 písm. e).
4. Krok redakce pro odstranění údajů třetích stran a právně chráněného nebo vyloučeného materiálu, se zaznamenaným důvodem výjimky.
5. Zabezpečený způsob doručení – šifrovaný přenos nebo autentizovaný portál – nikdy ne nešifrovaná příloha e-mailu.
6. Záznam o uzavření s daty, rozhodnutími, uplatněnými výjimkami a uchovanými důkazy pro účely odpovědnosti.

Organizace, které žádosti o přístup zvládají dobře, téměř vždy nejprve investovaly do mapování dat. Nelze získat to, co nebylo nikdy inventarizováno, a třicetidenní lhůta neodpouští práci s vyhledáváním.

Práva subjektů údajů v přehledu

Jaké jsou klíčové provozní povinnosti souladu s GDPR?

Kromě zásad a práv ukládá GDPR soubor pojmenovaných provozních povinností. Každá má spouštěcí podmínku, požadovaný výstup a přirozeného vlastníka. Považovat je za seznam dokumentů je nejrychlejší cesta ke zjištění auditu; považovat je za kontroly s vlastníky je nejrychlejší cesta k trvalému souladu.

Záznamy o činnostech zpracování a mapování dat – článek 30

Článek 30 vyžaduje, aby správci a zpracovatelé vedli záznamy o činnostech zpracování. U správců musí záznam obsahovat účely, kategorie subjektů údajů a osobních údajů, příjemce, předávání do třetích zemí a záruky, doby uchovávání a případně bezpečnostní opatření. Organizace s méně než 250 zaměstnanci mají omezenou výjimku, která je však užší, než se zdá: neplatí, pokud zpracování není příležitostné, pokud pravděpodobně povede k riziku pro práva a svobody nebo pokud se týká zvláštních kategorií údajů – tedy podmínek, které popisují většinu komerčního zpracování dat.

Záznam je jen tak dobrý jako mapování dat, které za ním stojí. Užitečná mapa vzniká systémovým průzkumem, nikoli z rozhovorů. Měla by u každého pole osobních údajů odpovídat: který systém je obsahuje, kdo je vlastníkem, jaký je účel, který právní základ platí, kdo má přístup, kam se předávají, jak dlouho se uchovávají a jak se mažou. Ve většině organizací jde o největší díl práce v celém programu – a o základ pro vše ostatní.

Ochrana údajů již ve fázi návrhu a ve výchozím nastavení – článek 25

Článek 25 vyžaduje, aby byla ochrana údajů zabudována do zpracování od počátku a ve výchozím nastavení se uplatňovala nastavení nejvíce chránící soukromí, aniž by subjekt údajů musel cokoli dělat. Právě klauzule o výchozím nastavení organizace zaskočí: aplikace, která zveřejňuje profilové údaje, dokud uživatel nenajde nastavení, test nesplnila – bez ohledu na to, jak dobře je nastavení zdokumentováno.

Zavedení článku 25 znamená, že požadavky na ochranu údajů vstupují do životního cyklu vývoje jako testovatelná kritéria, nikoli jako právní příloha. Typické návrhové vzory zahrnují minimalizaci na úrovni schématu, pseudonymizaci jako výchozí stav pro analytické využití, tokeny pro přístup vázaný na účel, automatizované vymáhání uchovávání, stav souhlasu jako prvotřídní atribut datového modelu a nastavení chránící soukromí v uživatelských rozhraních.

Posouzení vlivu na ochranu osobních údajů – článek 35

DPIA je vyžadována, pokud druh zpracování pravděpodobně povede k vysokému riziku pro práva a svobody fyzických osob. Čl. 35 odst. 3 uvádí tři případy, které téměř vždy DPIA spouštějí: systematické a rozsáhlé vyhodnocování osobních aspektů na základě automatizovaného zpracování, včetně profilování, na jehož základě jsou přijímána rozhodnutí s právními nebo obdobně významnými účinky; rozsáhlé zpracování zvláštních kategorií nebo údajů o trestných činech; a systematické rozsáhlé sledování veřejně přístupných prostor.

Dozorové úřady zveřejňují seznamy činností zpracování vyžadujících DPIA a kritéria EDPB – vyhodnocování nebo skórování, automatizované rozhodování s právním nebo obdobným účinkem, systematické sledování, citlivé údaje, zpracování ve velkém rozsahu, párování nebo spojování datových sad, údaje o zranitelných osobách, inovativní využití technologií a zpracování bránící subjektům údajů ve výkonu práva – se používají pro určení, zda byl práh překročen. Dvě nebo více kritérií obvykle znamenají, že DPIA je nutná.

Obhajitelná DPIA je strukturované posouzení rizik, nikoli formulář. Měla by systematicky popsat zpracování, posoudit nezbytnost a přiměřenost vzhledem k účelu, identifikovat rizika pro subjekty údajů, definovat zmírňující opatření, zaznamenat stanovisko DPO, pokud je určen, a zdokumentovat přijaté rozhodnutí – včetně rozhodnutí pokračovat se zbytkovým rizikem, což musí být zaznamenáno a při přetrvávajícím vysokém riziku vyžaduje konzultaci s dozorovým úřadem podle článku 36.

Potřebujete pověřence pro ochranu osobních údajů? – články 37–39

DPO je povinný ve třech situacích podle čl. 37 odst. 1: pokud zpracování provádí orgán veřejné moci nebo veřejný subjekt s výjimkou soudů v soudní činnosti; pokud hlavní činnosti správce nebo zpracovatele spočívají ve zpracování, které svou povahou, rozsahem nebo účelem vyžaduje pravidelné a systematické rozsáhlé sledování subjektů údajů; a pokud hlavní činnosti spočívají v rozsáhlém zpracování zvláštních kategorií údajů nebo údajů o odsouzeních a trestných činech.

DPO musí být řádně zapojen, musí se zodpovídat nejvyššímu vedení, nesmí dostávat pokyny k výkonu svých úkolů, nesmí být odvolán ani postižen za jejich plnění a musí mít odpovídající zdroje. DPO může být externí na základě smlouvy o poskytování služeb, což je běžné u středně velkých organizací, které potřebují nezávislost bez plného úvazku. Úkoly stanoví článek 39: informovat a radit, sledovat soulad včetně školení a auditů, radit k DPIA, spolupracovat s dozorovým úřadem a působit jako kontaktní bod. DPO, který je zároveň vedoucím IT, CISO nebo marketingovým ředitelem, vytváří strukturální střet zájmů, který dozorové úřady opakovaně kritizovaly.

Smlouvy se zpracovateli a due diligence – článek 28

Pokud je zpracování prováděno jménem správce, vyžaduje článek 28 písemnou smlouvu, která zpracovatele zavazuje ke konkrétním podmínkám: zpracování pouze na základě zdokumentovaných pokynů, důvěrnost, bezpečnostní opatření podle článku 32, povolení před zapojením subdodavatelů, pomoc s právy subjektů údajů a DPIA, hlášení porušení zabezpečení správci, výmaz nebo vrácení údajů na konci spolupráce a práva na audit a kontrolu. Smlouva musí rovněž stanovit předmět, dobu trvání, povahu a účel zpracování, druh osobních údajů a kategorie subjektů údajů.

Smlouvy samy o sobě nejsou due diligence. Čl. 28 odst. 1 vyžaduje používat pouze zpracovatele poskytující dostatečné záruky, což znamená posoudit bezpečnostní stav před zahájením spolupráce – certifikace, shrnutí penetračních testů, transparentnost subdodavatelů, historii porušení zabezpečení, možnosti umístění dat a závazky v oblasti reakce na incidenty. Toto posouzení se musí pravidelně opakovat, protože se stav zpracovatele mění s jeho růstem, akvizicí nebo zaváděním nových funkcí AI, které znovu využívají data zákazníků.

Zabezpečení zpracování a hlášení porušení – články 32–34

Článek 32 vyžaduje technická a organizační opatření odpovídající riziku a výslovně uvádí pseudonymizaci a šifrování, schopnost zajistit trvalou důvěrnost, integritu, dostupnost a odolnost, schopnost obnovit dostupnost a přístup po incidentu a proces pravidelného testování a vyhodnocování účinnosti opatření. Umožňuje také využít soulad se schváleným certifikačním mechanismem jako prvek prokazování souladu.

Článek 33 vyžaduje oznámení porušení osobních údajů příslušnému dozorovému úřadu bez zbytečného odkladu a pokud možno nejpozději do 72 hodin od okamžiku, kdy se o něm správce dozvěděl. Oznámení musí popsat povahu porušení, kategorie a přibližný počet dotčených subjektů údajů a záznamů, DPO nebo kontaktní bod, pravděpodobné důsledky a přijatá nebo navržená opatření. Pokud oznámení není provedeno do 72 hodin, musí být doplněno odůvodněním zpoždění. Pokud porušení pravděpodobně nepovede k riziku pro práva a svobody, oznámení se nevyžaduje – rozhodnutí však musí být interně zdokumentováno a zpracovatelé musí informovat správce bez zbytečného odkladu podle čl. 33 odst. 2.

Článek 34 vyžaduje informovat subjekty údajů bez zbytečného odkladu, pokud porušení pravděpodobně povede k vysokému riziku pro jejich práva a svobody, ledaže byly údaje učiněny nesrozumitelnými šifrováním, následná opatření vysoké riziko odstranila nebo by informování znamenalo nepřiměřené úsilí. V posledním případě je nutné veřejné sdělení.

Lhůta 72 hodin je požadavek na schopnost, ne na papírování. Její dodržení znamená mít předem připravené a nacvičené detekci, kritéria triage, klasifikaci závažnosti, eskalační cesty, právní posouzení i šablony oznámení. Organizace, které reakci na porušení testují formou tabletop cvičení a simulovaných incidentů, lhůtu běžně dodrží. Organizace, které napíší politiku a nikdy ji neprocvičí, nikoli.

Mezinárodní předávání údajů po rozsudku Schrems II

Kapitola V omezuje předávání osobních údajů mimo EHP. Předávání je zákonné, pokud Komise přijala rozhodnutí o odpovídající ochraně, nebo pokud při absenci odpovídající ochrany platí vhodné záruky. Hlavními zárukami jsou standardní smluvní doložky (SCC), závazná podniková pravidla, schválené kodexy chování a certifikační mechanismy. SCC z roku 2021 vyžadují posouzení dopadů předávání, které analyzuje právní úpravu a praxi cílové země a v případě potřeby zavádí doplňková opatření.

Oblast odpovídající ochrany se zkomplikovala. Rámec EU–USA pro ochranu soukromí nabízí cestu pro organizace, které se podle něj certifikují, zatímco dřívější Privacy Shield Soudní dvůr v roce 2020 zrušil v rozsudku Schrems II. Protože rozhodnutí o odpovídající ochraně lze napadnout, vyspělé programy se vyhýbají tomu, aby považovaly jediný mechanismus předávání za trvale vyřešený. Praktické kroky: vést registr předávání, kontrolovat umístění dat a řetězce subdodavatelů, uplatňovat šifrování a úschovu klíčů, které klíče ponechávají v EHP tam, kde to riziko vyžaduje, a dokumentovat posouzení dopadů předávání podle cílové země a druhu údajů.

Klíčové provozní povinnosti v přehledu

Jak se soulad s GDPR liší od jiných zákonů na ochranu údajů?

Nadnárodní organizace se zřídka setkávají s jediným režimem ochrany údajů. Pochopení toho, kde GDPR stojí vůči svým sousedům, zabraňuje časté chybě vybudovat jednu sadu kontrol a předpokládat, že bude fungovat všude.

GDPR vs. CCPA/CPRA

California Consumer Privacy Act ve znění California Privacy Rights Act je zákon o soukromí spotřebitelů s odlišnou architekturou. Vztahuje se na ziskové podniky splňující prahy obratu nebo objemu dat, které jednají s obyvateli Kalifornie, a je postaven na právech k „personal information” a „sensitive personal information”. Vyžaduje informace při shromáždění, práva na informace, výmaz, opravu, odmítnutí prodeje nebo sdílení a omezení použití citlivých údajů a vymáhají jej především California Privacy Protection Agency a generální prokurátor formou občanskoprávních sankcí, nikoli správních pokut odvozených od globálního obratu.

Praktické rozdíly, které jsou důležité pro vývojové týmy, spočívají v modelu opt-out (CCPA/CPRA umožňuje prodej a sdílení, dokud spotřebitel neodmítne, zatímco GDPR vyžaduje právní základ před zahájením zpracování), v absenci obecného rámce právních základů v Kalifornii, v užší definici citlivých údajů a v odlišném přístupu k údajům zaměstnanců a B2B, které GDPR pokrývá plně. Dobře postavený program GDPR obvykle naplňuje mnoho z CCPA/CPRA, ale architektura souhlasu je skutečně odlišná a nelze ji jednoduše znovu použít.

GDPR vs. UK GDPR

Po odchodu Spojeného království z EU převzala země GDPR do vnitrostátního práva jako UK GDPR, ve spojení s Data Protection Act 2018. Oba texty byly v okamžiku divergence v podstatě totožné, takže jeden program souladu může pokrýt oba. Divergence se však sčítá: Spojené království sleduje vlastní reformní agendu, vlastní rámec mezinárodního předávání s vlastními pravidly odpovídající ochrany, vlastní přístup k některým otázkám souhlasu a souborů cookie a vlastní regulátor v podobě Information Commissioner’s Office. Pro organizace působící na obou trzích je praktickým přístupem společná základní sada kontrol s dokumentovaným registrem odchylek podle jurisdikce.

GDPR vs. LGPD, PIPL a další režimy

Brazilská LGPD silně vychází ze struktury GDPR – právní základy, práva subjektů údajů, národní úřad ANPD a správní sankce – obsahuje však samostatný právní základ ochrany úvěru a odlišná pravidla pro oprávněný zájem. Čínský PIPL kombinuje koncepty podobné GDPR s rámováním státní bezpečnosti, vyžaduje samostatný souhlas ve více situacích, ukládá lokalizaci dat a bezpečnostní posouzení u určitých předávání a nemá nezávislý dozorový úřad v evropském smyslu. Indický DPDP Act volí jiný přístup s modelem správce souhlasů a vládou určenými významnými správci dat. Revidovaný švýcarský FADP je GDPR natolik blízký, že jej lze vést v rámci téhož programu, s vlastními nuancemi v registraci a oznamování.

Strategickým závěrem pro CTO je, že globální architektura ochrany soukromí má být modulární: společná inventura dat, společný engine pro práva a společný bezpečnostní základ, s rozhodovacími vrstvami specifickými pro jurisdikci pro právní základ, souhlas, předávání a uchovávání. Snaha o jedinou globální politiku vede buď k nákladnému nadměrnému souladu, nebo k nákladnému nedostatečnému souladu.

Srovnání napříč jurisdikcemi

Jak zavést program souladu s GDPR krok za krokem?

Programy souladu s GDPR selhávají z předvídatelných důvodů: začínají psaním politik místo průzkumem, nemají určené vlastníky, považují práci za jednorázový projekt a nikdy neprodukují důkazy. Fázovaný program, který staví průzkum na začátek a končí provozními rutinami, se všem čtyřem vyhýbá.

Fáze 1 – Zjistit a posoudit (dny 0–90)

První fáze odpovídá na tři otázky: jaké osobní údaje existují, kam proudí a kde jsou nejvyšší rizika. Dokud na ně neexistují odpovědi, nelze nic dalšího spolehlivě naplánovat.

• Určení působnosti. Ověřte, zda platí čl. 3 odst. 1, čl. 3 odst. 2 nebo obojí, a určete vedoucí dozorový úřad při přeshraničním zpracování.
• Mapování rolí. Určete postavení správce, společného správce a zpracovatele podle toku dat – nikoli podle právnické osoby.
• Průzkum a inventura dat. Zkombinujte automatizované nástroje pro objevování dat se strukturovanými rozhovory s vlastníky systémů. Pokryjte produkční systémy, datové sklady, logy, zálohy, SaaS aplikace, tabulky, nástroje podpory a stínové IT. Zaznamenejte kategorii údajů, účel, právní základ, uchovávání, příjemce a předávání.
• Analýza mezer. Porovnejte současný stav se sedmi zásadami a klíčovými povinnostmi a ohodnoťte každou mezeru podle pravděpodobnosti a dopadu na subjekty údajů.
• Inventura vysokých rizik. Identifikujte zpracování, které pravděpodobně vyžaduje DPIA, a jakékoli zpracování vyžadující předchozí konzultaci.
• Nastavení správy. Určete sponzora z vedení, vedoucího programu, vlastníky na úrovni systémů a rozhodnutí o DPO se zaznamenaným odůvodněním.

Fáze 2 – Napravit a zdokumentovat (dny 90–180)

Druhá fáze mění zjištění v kontroly a vytváří důkazy o odpovědnosti, jejichž absenci odhalila fáze 1.

• Dokončete záznam podle článku 30 a zařaďte jej pod řízení změn, aby nové zpracování bylo přidáno před spuštěním.
• Uzavřete nejprve rizikové mezery. Upřednostněte zvláštní kategorie, rozsáhlé sledování, přeshraniční předávání a jakékoli zpracování s nevyřešenou DPIA.
• Zaveďte vymáhání uchovávání. Převeďte plán uchovávání do automatizovaných úloh výmazu, archivace a expirace záloh a ověřte, že fungují.
• Přestavte proces práv. Zveřejněte vstupní kanál, definujte rozsah vyhledávání pro každý systém, vytvořte workflow pro získání dat a začněte protokolovat žádosti a doby uzavření.
• Opravte smlouvy. Uveďte smlouvy se zpracovateli do souladu s článkem 28, identifikujte subdodavatele a uzavřete mezery v zárukách předávání.
• Zpevněte zabezpečení. Zaveďte opatření podle článku 32 identifikovaná v analýze mezer, včetně šifrování, řízení přístupu, logování, monitoringu a správy zranitelností.
• Vytvořte runbook pro hlášení. Definujte detekci, triage, klasifikaci závažnosti, eskalaci, právní posouzení, šablony oznámení a plán cvičení.
• Školte. Školení podle rolí pro vývoj, marketing, HR, obchod a podporu s uchovanými záznamy o absolvování.

Fáze 3 – Provozovat a prokazovat (dny 180–365, poté trvalý stav)

Poslední fáze mění soulad z projektu na rutinu. Právě tato fáze rozhoduje, zda program přežije první změnu vedení nebo první velké uvedení produktu na trh.

• Zakotvěte ochranu údajů v dodávce. Přidejte požadavky na ochranu údajů do definice hotového a screening DPIA do procesů pro příjem požadavků a změnové řízení.
• Provozujte monitorovací cyklus. Měsíční metriky objemu žádostí a dob uzavření, případů porušení zabezpečení, míry souhlasu, úspěšnosti úloh výmazu, absolvovaných školení a revizí dodavatelů.
• Testujte. Roční penetrační testy, pravidelné testy obnovy a alespoň roční tabletop cvičení reakce na porušení s zdokumentovanými poznatky.
• Auditujte. Interní audit nebo externí hodnocení proti sedmi zásadám a klíčovým povinnostem se sledováním zjištění do uzavření.
• Revizujte dodavatele. Pravidelně přehodnocujte stav zpracovatelů, seznamy subdodavatelů a uspořádání předávání a vždy, když dodavatel podstatně změní svou službu.
• Reportujte vedení. Krátká zpráva pro vedení o stavu souladu, zbytkových rizicích a potřebných rozhodnutích.

Pokud musí vaše organizace provozovat tento program souběžně s dodávkou produktu – a většina musí –, konzultační tým Greyson spolupracuje s IT vedením na načasování průzkumu, nápravy a provozních rutin tak, aby se roadmapa nezastavila.

Dvanáctiměsíční plán programu souladu s GDPR

Jak soulad s GDPR mění vývoj softwaru a testování?

Toto je oblast, kde je soulad s GDPR nejčastěji nesprávně chápán jako právní záležitost a nejčastěji selhává jako inženýrská úloha. Povinnosti podle článků 25 a 32 jsou návrhové a testovací povinnosti. Nelze je splnit dokumentem s politikou napsaným po vydání.

Ochrana údajů již ve fázi návrhu napříč životním cyklem vývoje

Ochrana údajů již ve fázi návrhu funguje jen tehdy, když se požadavky na ochranu údajů chovají jako každý jiný nefunkční požadavek: zachycené včas, testovatelné, sledované do splnění a ověřené před vydáním.

Fáze požadavků. Každá funkce, která se dotýká osobních údajů, by měla deklarovat účel, právní základ, kategorie údajů, dobu uchovávání, příjemce a příslušná práva subjektů údajů. Screeningová otázka při příjmu požadavku – zpracovává tento záměr osobní údaje a splňuje některé kritérium DPIA? – zachytí případy, které vyžadují posouzení dříve, než je architektura zamrzlá.

Fáze návrhu. Minimalizace údajů se uplatňuje na úrovni schématu a API, nejen ve formuláři. Pseudonymizace, přístup vázaný na účel, šifrování a správa klíčů jsou navrženy předem. Výchozí nastavení chrání soukromí a naplňují klauzuli o výchozím nastavení podle článku 25.

Fáze vývoje. Stav souhlasu, značky účelu a metadata o uchovávání se modelují jako prvotřídní datové atributy, nikoli se přidávají dodatečně. Logování je ve výchozím stavu konfigurováno tak, aby osobní údaje vylučovalo nebo redigovalo, protože logovací úložiště patří mezi nejčastěji přehlížené zdroje osobních údajů.

Fáze testování. Požadavky na ochranu údajů se testují jako funkční požadavky: že výmaz skutečně maže ve všech úložištích včetně odvozených datových sad a vyhledávacích indexů, že úlohy uchovávání se spouštějí, že odvolání souhlasu potlačí zpracování v navazujících systémech, že řízení přístupu omezuje podle účelu, že export vytváří úplný a strojově čitelný záznam a že automatizovaná rozhodnutí poskytují vysvětlení a směřují k lidské kontrole.

Fáze vydání. Kontroly ochrany údajů se stávají součástí definice hotového. Vydání, které mění způsob zpracování osobních údajů bez aktualizace záznamu v registru nebo bez dokončení screeningu DPIA, by nemělo projít branou.

Fáze provozu. Vymáhání uchovávání, revize přístupů, monitoring a pravidelné přehodnocování DPIA podle vývoje zpracování. Čl. 32 odst. 1 písm. d) výslovně vyžaduje pravidelné testování účinnosti bezpečnostních opatření, což z kontinuálního testování činí právní očekávání, nikoli inženýrskou preferenci.

Správa testovacích dat – pseudonymizace versus anonymizace

Testování je místem, kde se soulad s GDPR a inženýrská praxe nejviditelněji střetávají. Vývojová a testovací prostředí potřebují realistická data, aby odhalila realistické chyby, ale produkční osobní údaje nesmí být kopírovány do prostředí se slabšími kontrolami. GDPR nabízí dvě cesty a nejsou zaměnitelné.

Anonymizace odstraňuje identifikovatelnost do té míry, že údaje zcela opouštějí působnost GDPR. Aby toho bylo dosaženo, musí údaje odolat osamocení (izolace jednotlivce), propojitelnosti (spojení záznamů o stejné osobě) a inferenci (odvození atributů z jiných dat), s přihlédnutím ke všem pravděpodobně použitelným prostředkům. Skutečná anonymizace je obtížná a u mnoha podnikových datových sad – zejména těch s bohatými kvazi-identifikátory, jako je PSČ, datum narození a transakční vzorce – není dosažitelná bez zničení analytického přínosu.

Pseudonymizace nahrazuje přímé identifikátory umělými, přičemž opětovná identifikace zůstává možná prostřednictvím odděleně uloženého klíčového materiálu. Pseudonymizované údaje zůstávají osobními údaji a v působnosti nařízení, ale článek 32 výslovně uznává pseudonymizaci jako bezpečnostní opatření a článek 25 jako návrhovou techniku. Pro většinu testovacích prostředí je pseudonymizace s přísným oddělením klíčů praktickou a obhajitelnou volbou: zachovává referenční integritu a realističnost dat, odstraňuje přímou identifikovatelnost a naplňuje technické opatření podle článku 32.

Ať zvolíte kteroukoli cestu, několik kontrol je nepřekročitelných. Testovací prostředí nesmí být dostupná s produkčními přihlašovacími údaji. Data musí být maskována v místě extrakce, nikoli v cílovém prostředí. Referenční integrita musí být zachována, aby testy zůstaly smysluplné – stejný syntetický identifikátor musí být konzistentní napříč souvisejícími tabulkami. Musí být pokryta volná textová pole, přílohy, poznámky a metadata dokumentů, protože právě tam osobní údaje maskování nejčastěji přežijí. A samotný proces maskování musí být testován: vzorkování maskovaných datových sad na zbytkové identifikátory je legitimní a očekávaná kontrola.

Cloud, dodavatelé a zajištění zpracovatelů

Přesun do cloudu nepřenáší odpovědnost. Podle článku 28 zůstává správce odpovědný za výběr zpracovatele poskytujícího dostatečné záruky a za to, že smlouva pokrývá požadované podmínky. Speciálně u cloudu si zaslouží pozornost čtyři oblasti.

Umístění dat a řetězce předávání. Cloudová služba může replikovat data mezi regiony a využívat subdodavatele v několika jurisdikcích. Mapování předávání musí sledovat skutečnou cestu dat včetně přístupu podpory ze třetích zemí, což je samo o sobě předáváním.

Transparentnost subdodavatelů. Čl. 28 odst. 2 vyžaduje povolení subdodavatelů. V praxi to znamená sledovat zveřejněné seznamy subdodavatelů, mít mechanismus pro námitku proti změnám a zdokumentovaný postup pro případ, že námitku skutečně vznesete.

Výmaz a ukončení. Čl. 28 odst. 3 písm. g) vyžaduje výmaz nebo vrácení údajů na konci spolupráce. V multi-tenant architekturách s velkým objemem záloh ověřte, co „výmaz” konkrétně znamená, jaké jsou lhůty a zda zbytkové kopie přetrvávají v zálohách nebo analytických úložištích.

Rozšiřování funkcí a sekundární využití. Mnoho cloudových platforem dnes nabízí funkce s podporou AI, které mohou zpracovávat data zákazníků. Každou takovou funkci je třeba posoudit: využívá data pro trénink modelů, a pokud ano, na jakém právním základě a s jakou smluvní ochranou?

Kontroly ochrany údajů podle fází životního cyklu vývoje

Jaké jsou nejčastější mýty o GDPR?

Většina zaseknutých programů není blokována složitostí. Blokuje je malá skupina přetrvávajících přesvědčení, která vedou týmy k vynakládání úsilí na špatném místě.

Devět mýtů, které brzdí programy souladu

„Nejsme v EU, takže se nás GDPR netýká.” Čl. 3 odst. 2 vztahuje nařízení na organizace nabízející zboží nebo služby osobám v EU nebo sledující jejich chování, bez požadavku na provozovnu.

„Naše data jsou anonymizovaná, takže nejsou v působnosti.” Mimo působnost jsou pouze nevratně anonymizovaná data. Pseudonymizovaná data a data, která lze reidentifikovat kombinací s jinými datovými sadami, zůstávají osobními údaji.

„Souhlas je jediný právní základ, který potřebujeme.” Existuje dalších pět základů. Použití souhlasu tam, kde platí smlouva nebo právní povinnost, vytváří zbytečné riziko, protože souhlas lze kdykoli odvolat.

„Záznam jsme smazali, takže jsme v souladu.” Výmaz musí zasáhnout zálohy, odvozené datové sady, analytická úložiště, vyhledávací indexy, cache a zpracovatele. Výmaz, který skončí u primární databáze, je neúplný.

„DPIA je formalita pro právní oddělení.” DPIA je posouzení rizik, které informuje návrhová rozhodnutí, musí být vytvořeno před zahájením zpracování, se zaznamenaným stanoviskem DPO a přijetím zbytkového rizika na správné úrovni.

„Náš poskytovatel cloudu vyřeší GDPR za nás.” Zpracovatelé poskytují záruky a smluvní závazky; odpovědnost podle čl. 5 odst. 2 a článku 24 zůstává na správci, včetně předávání a subdodavatelů.

„Máme na webu zásady ochrany osobních údajů, takže jsme pokryti.” Zásady ochrany osobních údajů plní jednu povinnost transparentnosti. Pro vymáhání uchovávání, plnění práv, bezpečnostní testy nebo připravenost na hlášení nedělají nic.

„Soulad je jednorázový projekt.” Každý nový systém, dodavatel, integrace, marketingový kanál a funkce AI mění podobu zpracování. Soulad bez vstupu řízení změn se rozpadne do jednoho čtvrtletí.

„GDPR a AI Act jsou oddělené problémy.” Systémy AI, které zpracovávají osobní údaje, musí splňovat obojí. Minimalizace údajů, omezení účelu a analýza právního základu se vztahují na tréninková data a článek 22 omezuje automatizovaná rozhodnutí, která významně ovlivňují jednotlivce.

Mýtus versus realita

Kolik stojí nedodržení předpisů?

Diskusi dominují pokuty, ale ty zřídka bývají největším nákladem. Pochopení jak zákonné struktury, tak provozních důsledků pomáhá postavit obchodní případ, který obstojí při kontrole rozpočtu.

Dvoustupňová struktura pokut podle článku 83

Článek 83 stanoví dvě úrovně správních pokut. Nižší úroveň pokrývá povinnosti včetně obecných zásad, povinností správců a zpracovatelů, certifikačních orgánů a povinností kontrolních subjektů. Umožňuje pokuty až do výše 10 milionů EUR nebo 2 % celkového celosvětového ročního obratu za předchozí finanční rok, podle toho, která hodnota je vyšší.

Vyšší úroveň pokrývá porušení základních zásad, práv subjektů údajů, pravidel mezinárodního předávání a neplnění příkazu dozorového úřadu. Umožňuje pokuty až do výše 20 milionů EUR nebo 4 % celkového celosvětového ročního obratu, podle toho, která hodnota je vyšší.

Skutečnou výši určuje několik faktorů: povaha, závažnost a doba trvání porušení, nedbalost nebo úmysl, nápravná opatření, míra odpovědnosti, předchozí porušení, spolupráce s úřadem a kategorie dotčených osobních údajů. Pokuty musí být v každém případě účinné, přiměřené a odrazující. Dozorové úřady mohou rovněž uložit nápravná opatření – varování, napomenutí, příkazy k nápravě, dočasné nebo trvalé zákazy zpracování a pozastavení toků dat –, která mohou být obchodně škodlivější než pokuta.

Co ukazují data o vymáhání

Agregovaná data o vymáhání ukazují, jak aktivně je režim uplatňován. Napříč všemi sledovanými případy v EU a EHP jde celkový počet případů do tisíců a kumulované pokuty přesahují 7,5 miliardy EUR, přičemž nejvyšší jednotlivá pokuta ve výši 1,2 miliardy EUR byla uložena v Irsku. Španělsko je dlouhodobě mezi nejaktivnějšími úřady podle počtu případů, což odráží vysoký podíl menších případů týkajících se stížností spotřebitelů a souhlasu se soubory cookie.

Rozložení je důležitější než titulky. Celkové hodnotě dominuje malý počet velmi vysokých pokut, zatímco většina případů se týká středně velkých a menších organizací s podstatně nižšími částkami. Tento vzorec má jasný strategický důsledek: riziko šetření není soustředěno na nadnárodní společnosti. Sleduje viditelnost – stížnosti spotřebitelů, špatně vyřízené žádosti subjektů údajů, hlášení porušení zabezpečení a stížnosti konkurentů nebo zaměstnanců. Organizace, které špatně zareagují na jedinou žádost o přístup nebo hlášení porušení, skončí ve spisu o vymáhání mnohem pravděpodobněji než ty s plynulým a zdokumentovaným procesem.

Dva vzorce vymáhání jsou pro IT vedení obzvláště relevantní. Za prvé, souhlas se soubory cookie a sledování zůstávají v celé Evropě trvalým zdrojem pokut, což staví marketingový technologický stack přímo do působnosti. Za druhé, případy nedostatečných technických a organizačních opatření podle článku 32 jsou časté a vznikají často ze selhání, která by vývojové týmy považovaly za základní: neaktualizované systémy, nadměrná přístupová práva, nešifrované zálohy, exponované databáze a přihlašovací údaje v kódu.

Náklady, které se v pokutě nikdy neobjeví

Pro většinu organizací je pokuta tou menší částkou. Podstatné náklady jsou provozní:

• Náklady na nápravu. Krizová bezpečnostní práce, forenzní vyšetřování, přestavba systémů a externí poradci, obvykle pod časovým tlakem a za prémiové sazby.
• Přerušení provozu. Pozastavené zpracování, zmrazené toky dat, vypnutá marketingová schopnost a zablokovaná uvedení produktů.
• Ztráta zákazníků a smluv. Vyřazení v nákupních procesech, práva na ukončení smlouvy, neúspěšná due diligence a zpožděné podnikové zakázky.
• Právní expozice. Nároky na náhradu škody podle článku 82 za hmotnou i nehmotnou újmu, včetně hromadných žalob.
• Pozornost vedení. Čas vedení a představenstva odvedený k vyšetřování, komunikaci s úřady a řízení nápravy.
• Trvající reputační dopad. Rozhodnutí o vymáhání jsou veřejná a trvalá a objevují se v každé následné nákupní revizi.

Správní pokuty v přehledu

Jak vypadá budoucnost souladu s GDPR?

GDPR je v platnosti dost dlouho na to, aby se praxe vymáhání ustálila a aby se technologická krajina výrazně změnila. Další fázi budou utvářet tři vývoje.

Konvergence s aktem EU o umělé inteligenci

Akt EU o umělé inteligenci zavádí rizikový režim pro systémy AI s povinnostmi, které se u systémů zpracovávajících osobní údaje výrazně překrývají s GDPR. Poskytovatelé i uživatelé vysoce rizikových systémů musí řešit správu dat včetně kvality tréninkových dat a sledování biasu, vést technickou dokumentaci a logování, zajistit lidský dohled a poskytovat transparentnost dotčeným osobám. Mnohé z těchto povinností posilují požadavky GDPR, ale nejsou totožné a vztahují se na organizace v různých rolích.

Pro IT vedení z toho plyne, že správa AI a správa ochrany údajů by měly konvergovat, nikoli běžet jako paralelní programy. Jediný proces příjmu požadavků by měl vést iniciativy v oblasti AI jak přes screening DPIA, tak přes klasifikaci podle aktu o AI. Jediná inventura dat by měla zaznamenávat původ tréninkových dat, právní základ a uchovávání. Jediná sada dokumentace modelů by měla sloužit oběma režimům. Organizace, které to postaví odděleně, zdvojnásobí úsilí a vytvoří nekonzistence, kterých si regulátoři všimnou.

Souhlas se soubory cookie, ePrivacy a únava ze souhlasů

Rozhraní pro souhlas zůstávají nejviditelnější částí souladu s GDPR a jedním z nejčastěji soudně řešených témat. Dozorové úřady v celé Evropě nadále prověřují souhlasové bannery, symetrii odmítnutí, temné vzorce, předzaškrtnutá políčka a součinnost souhlasu s pravidly směrnice ePrivacy o ukládání informací do koncových zařízení. Trend směřuje k přísnějšímu vymáhání zásady „odmítnout musí být stejně snadné jako přijmout” a k jasnějšímu rozlišení mezi nezbytnými a nezbytnými technologiemi.

Zároveň jsou uživatelé vůči žádostem o souhlas stále odolnější, což vytváří tlak na organizace, aby tam, kde je to vhodné, používaly alternativní právní základy a omezily sledování na skutečně nezbytné. Serverové a na soukromí ohleduplné měření se stává mainstreamem právě proto, že snižuje jak právní expozici, tak tření kolem souhlasu. V tomto případě minimalizace údajů slouží právnímu souladu i obchodním výsledkům současně.

Nejistota režimu předávání a cesta vpřed

Mezinárodní předávání zůstávají nejvolatilnější oblastí režimu. Rozhodnutí o odpovídající ochraně lze napadnout a historie Safe Harbour a Privacy Shield ukazuje, že mechanismus platný dnes může být zítra zrušen. Rámec EU–USA pro ochranu soukromí nabízí cestu pro certifikované organizace, byl však již napaden u soudu a jeho dlouhodobá stabilita není zaručena.

Vyspělé organizace reagují snížením závislosti na jediném mechanismu předávání: minimalizují objem osobních údajů překračujících hranice, udržují šifrovací klíče v úschově v EU tam, kde to riziko vyžaduje, strukturují zpracování tak, aby citlivé operace zůstaly v EHP, a vedou posouzení dopadů předávání, která lze rychle aktualizovat, pokud mechanismus padne. Nejvíce exponované jsou organizace, jejichž architektura předpokládá, že právní mechanismus zůstane platný neomezeně.

Často kladené otázky o souladu s GDPR

Co je soulad s GDPR jednoduše řečeno?

Soulad s GDPR znamená plnit požadavky nařízení (EU) 2016/679 vždy, když zpracováváte osobní údaje osob v EU. V praxi to znamená mít právní základ pro každou činnost zpracování, jasně informovat osoby o tom, co s jejich údaji děláte, plnit jejich práva ve lhůtách, přiměřeně zabezpečit údaje, hlásit určitá porušení do 72 hodin a umět to vše prokázat dozorovému úřadu.

Platí GDPR i pro společnosti mimo EU?

Ano. Podle čl. 3 odst. 2 se GDPR vztahuje na organizace bez provozovny v EU, které nabízejí zboží nebo služby osobám v EU nebo sledují jejich chování, včetně webové analytiky nebo cílené reklamy. Pouhá dostupnost webu nestačí – musí existovat důkaz o úmyslu cílit na trh EU, například jazykové verze pro EU, ceny v eurech nebo možnosti doručení do EU. Článek 27 zpravidla vyžaduje určení zástupce v Unii.

Jakých je sedm zásad souladu s GDPR?

Článek 5 stanoví sedm zásad: zákonnost, korektnost a transparentnost; omezení účelu; minimalizace údajů; přesnost; omezení uložení; integrita a důvěrnost; a odpovědnost. Odpovědnost je meta-zásadou – správce musí být schopen prokázat soulad s ostatními šesti, a proto je dokumentace, evidence a důkazy z testů ústředním prvkem každého důvěryhodného programu.

Jaký je rozdíl mezi správcem a zpracovatelem?

Správce určuje účely a prostředky zpracování; zpracovatel zpracovává osobní údaje jménem správce na základě zdokumentovaných pokynů. Rozlišení je faktické, nikoli smluvní, a stejná organizace může mít pro různé činnosti obě role. Zpracovatel, který data zákazníků znovu využije pro vlastní účely, například pro trénink vlastních AI modelů, se pro tuto činnost stává správcem a potřebuje vlastní právní základ.

Kdy je vyžadován pověřenec pro ochranu osobních údajů?

Čl. 37 odst. 1 činí DPO povinným ve třech situacích: pokud zpracování provádí orgán veřejné moci nebo veřejný subjekt (s výjimkou soudů v soudní činnosti); pokud hlavní činnosti zahrnují pravidelné a systematické rozsáhlé sledování subjektů údajů; a pokud hlavní činnosti zahrnují rozsáhlé zpracování zvláštních kategorií údajů nebo údajů o trestných činech. DPO musí být nezávislý, zodpovídat se nejvyššímu vedení, mít odpovídající zdroje a být chráněn před odvoláním nebo postihem za plnění svých úkolů.

Kdy je posouzení vlivu na ochranu osobních údajů povinné?

DPIA je vyžadována u zpracování, které pravděpodobně povede k vysokému riziku pro práva a svobody osob. Čl. 35 odst. 3 uvádí tři případy: systematické a rozsáhlé automatizované vyhodnocování včetně profilování, na jehož základě se přijímají rozhodnutí s právními nebo obdobně významnými účinky; rozsáhlé zpracování zvláštních kategorií nebo údajů o trestných činech; a systematické rozsáhlé sledování veřejně přístupných prostor. Podle kritérií EDPB dvě nebo více rizikových indicií obvykle znamená, že DPIA je nutná.

Jak dlouho máte na nahlášení porušení zabezpečení podle GDPR?

Musíte informovat příslušný dozorový úřad bez zbytečného odkladu a pokud možno do 72 hodin od okamžiku, kdy se o porušení osobních údajů dozvíte, v souladu s článkem 33. Pokud oznámíte později, musíte zpoždění odůvodnit. Pokud porušení pravděpodobně povede k vysokému riziku pro práva a svobody subjektů údajů, článek 34 navíc vyžaduje informovat tyto osoby bez zbytečného odkladu. Zpracovatelé musí informovat správce bez zbytečného odkladu.

Jak vysoké mohou být pokuty podle GDPR?

Článek 83 stanoví dvě úrovně. Porušení nižší úrovně mohou vést k pokutě až 10 milionů EUR nebo 2 % celkového celosvětového ročního obratu, podle vyšší hodnoty. Porušení vyšší úrovně – včetně porušení základních zásad, práv subjektů údajů a pravidel mezinárodního předávání – až 20 milionů EUR nebo 4 % celosvětového ročního obratu, podle vyšší hodnoty. Dozorové úřady mohou rovněž uložit nepeněžní nápravná opatření, jako jsou zákazy zpracování, a jednotlivci mohou požadovat náhradu škody podle článku 82.

Jak se GDPR liší od CCPA?

GDPR je režim založený na právech, který vyžaduje právní základ před zpracováním a vztahuje se na každou organizaci zpracovávající údaje subjektů údajů v EU. CCPA ve znění CPRA je kalifornský zákon o soukromí spotřebitelů, který se vztahuje na kvalifikující ziskové podniky a sleduje model opt-out pro prodej a sdílení osobních informací, bez obecného rámce právních základů. Oba zákony přiznávají práva k osobním údajům, ale architektura souhlasu a modely vymáhání se zásadně liší.

Jak dosáhnout souladu s GDPR?

Soulad sleduje posloupnost, nikoli dokument. Nejprve určete působnost a svou roli pro každý tok dat a poté sestavte inventuru dat a mapu toků. Posuďte mezery vůči sedmi zásadám a klíčovým povinnostem a identifikujte rizikové zpracování vyžadující DPIA. Poté napravte: dokončete záznam podle článku 30, zaveďte vymáhání uchovávání, postavte fungující proces práv, opravte smlouvy se zpracovateli, zpevněte zabezpečení a vytvořte otestovaný runbook pro hlášení. Nakonec provozujte a prokazujte – zakotvěte ochranu údajů v definici hotového, sledujte metriky, pravidelně testujte a reportujte vedení. Soulad je udržovaný stav, nikoli milník.