Jak GDPR pracuje s riziky
Obecné nařízení o ochraně osobních údajů (GDPR) požaduje, aby správci a zpracovatelé hodnotili rizika plynoucí ze zpracování osobních dat. A podle nich nastavili své procesy pro zpracování a ochranu osobních údajů. Například jmenovali, nebo nejmenovali, pověřence pro ochranu osobních údajů, zpracovali posouzení vlivu na ochranu osobních údajů u nového zpracování, oznámili bezpečností incident Úřadu pro ochranu osobních údajů atd.
Pojem riziko se v GDPR objevuje celkem 71x. GDPR ale v drtivé většině případů s pojmy riziko a hodnocení rizik pracuje jinak, než jak je známe například z kybernetické bezpečnosti, aplikace ISO standardů, projektového řízení nebo regulací typu NIS2 či DORA.
Co je to řízení rizik?
Řízením rizik se rozumí postup pro identifikaci negativních skutečností, které mohou v budoucnu nastat.
Na identifikaci rizik navazuje vyhodnocení jejich závažnosti, resp. závažnosti dopadu, pokud by se riziko materializovalo, tzn. skutečně projevilo v praxi.
Dalším krokem je rozhodnutí, co s riziky daná organizace bude dělat. Jestli je akceptuje, protože pravděpodobnost materializace rizika nebo jeho závažnost je nízká, a případné náklady na předcházení rizika by byly neúměrně vysoké. Anebo se rozhodne konkrétní rizika snižovat, protože se jejich zhmotnění skutečně nechce dočkat.
V úvahu přichází i riziko přenést na někoho jiného, například tím, že se organizace proti jeho možným dopadům, například úniku dat nebo výpadku IT systémů, pojistí.
Kdy je vhodné řídit rizika?
S řízením rizik se setkáváme kupříkladu v oblasti informační a kybernetické bezpečnosti. Z pohledu kybernetické bezpečnosti řešíme rizika ztráty dat, nedostupnosti výpočetních zdrojů, nekontrolovaných změn IT prostředí, útoků, výpadků atd.
Projektová rizika se zabývají tím, zda organizace dosáhne požadovaného výstupy (zavedení nového produktu, změny procesů, rozšíření distribuce atd.) v definovaném čase a v rámci stanoveného rozpočtu. Lépe řečeno, projektová rizika popisují negativní scénáře, kdy naopak projekt nedoručí to, co má, nebo výsledek dodá pozdě, špatně, za výrazně více nákladů atd.
Rizika ale mohou být i obchodní, související například s pohyby na trhu, zásahy centrálních bank nebo pohyby kurzů měn.
Další oblastí, kde se s řízením rizik v poslední často setkáváme, je riziko spojené s dodavateli, resp. s dodavatelským řetězcem. Řeší se jejich spolehlivost a důvěryhodnost, ale i schopnost zajistit slíbené plnění. Významným impulsem pro řízení rizik dodavatelů bude zřejmě i nový zákon o kybernetické bezpečnosti.
Klasické řízení rizik nesplňuje požadavky GDPR
Tradiční oblasti, ve kterých se s řízením rizik již nějakou dobu pracuje, mají jednu společnou věc: Identifikují a hodnotí rizika pro danou organizaci.
Jak moc by mi vadilo, kdybych 4 hodiny neměl přístup k datům v cloudu a nemohl obsloužit klienty?
Na kterých zaměstnancích jsem závislý při vývoji nové aplikace a jak omezím riziko, že v průběhu projektu nebudou mít na spolupráci kapacitu nebo z firmy úplně odejdou?
Nakolik je v nejbližších měsících reálný výrazný pokles kurzu amerického dolaru a co by to pro mě znamenalo?
K jak citlivým informacím bude mít dodavatel přístup a jak je mohu ochránit?
Přístup založený na riziku podle GDPR
GDPR také pracuje s pojmem riziko. Rizika plynoucí ze zpracování osobních údajů je správce povinen zohlednit zejména při:
Nastavení celého procesu pro zpracování osobních údajů a zajištění a dokumentování souladu s regulací (čl. 24 GDPR)
Aplikaci postupů privacy by desing a privacy by default (čl. 25 GDPR)
Vedení záznamů o zpracování osobních údajů (čl. 30 GDPR)
Zabezpečení osobních údajů (čl. 32 GDPR)
Posuzování a ohlašování případů porušení zabezpečení osobních údajů, tzv. data breaches (čl. 33-34 GDPR)
Posuzování vlivu zpracování dat na ochranu osobních údaj, tzv. data protection impact assessment, DPIA, včetně povinné konzultace s dozorovým úřadem (čl. 35-36 GDPR)
Předávání osobních údajů do třetích zemí mimo EU (čl. 44-49 GDPR)
GDPR: Hodnoťte rizika pro dotčené lidi, ne pro organizaci!
Základním rozdílem proti klasickým procesům pro řízení rizik je ale právě v tom, jaká rizika se podle GDPR hodnotí, resp. rizika pro koho.
Při řízení rizik informační bezpečnosti, finančních, právních, projektových nebo operačních rizik totiž předvídáme, hodnotíme a řešíme hrozby pro organizaci jako takovou. Finanční ztrátu, únik interních informací, porušení regulace, pokutu od dozorového úřadu, nedostupnost skladu.
GDPR ale požaduje, aby správce údajů hodnotil rizika pro práva a svobody subjektů údajů. Tedy lidí, jejichž osobní údaje zpracovává nebo hodlá zpracovávat.
Nedostupnost osobních údajů v cloudu a jí způsobené problémy při obsluze klienta tak při aplikaci GDPR nehodnotíme podle negativního dopadu na organizaci (jaké budou náklady na obnovu provozu a kompenzaci dotčených klientů?), ale z pohledu osob, jejichž data mají být nebo už jsou zpracovávána (jaké dopady do práv každého jednoho člověka může tento výpadek mít?).
Rizika pro subjekty údajů
Jaká rizika hrozí dotčeným lidem ze zpracování jejich údajů?
Kompletní výčet možných rizik a hrozeb neexistuje. GDPR upravuje příklady typických rizik, které by měl správce hodnotit. A k tomu přidat i další, která plynou ze specifik a okolností jeho činnosti.
Jaká ta rizika jsou?
Fyzická újma
Diskriminace
Krádež či zneužití identity
Finanční (majetková) ztráta
Poškození pověsti či jiný zásah do osobnostních práv
Ztráta důvěrnosti údajů chráněných zvláštní povinností mlčenlivosti
Neoprávněné zrušení pseudonymizace
Hospodářské či společenské znevýhodnění
Jeden bezpečnostní incident, dva úhly pohledu
V čem je rozdíl? Není to jen slovíčkaření?
Není.
Odlišná perspektiva a odlišný chráněný zájem při řízení rizik totiž znamená odlišné hodnocení jejich závažnosti. Riziko, které se z pohledu organizace (správce osobních údajů) může jevit jako nízké a akceptovatelné, může být pro dotčené subjekty údajů skutečně velkým problémem.
Jeden příklad za všechny:
Pojišťovna nabízí řadu pojistných produktů, mezi nimi i životní pojištění. To od ní využívá cca milion klientů. Pro sjednání životního pojištění i pro výplatu pojistného musí zpracovávat řadu údajů o zdravotním stavu. Pro posuzování pojistných událostí používá online nástroj od dodavatele. U něj jsou i dočasně uchovávány údaje o úrazech, nemocech či dalších pojistných událostech.
Jednoho dne dojde u dodavatele k technickému incidentu, problému s výkonem. Po dobu 10 minut nejsou data zaslaná pojišťovně pomocí online formuláře uložena, ale „ztratí se po cestě“. Incident je odhalen až s odstupem 10 dní. Dodavatel ani pojišťovna nedokáží přesně určit, kolika klientů se mohl dotknout, jejich počet proto odhadnou na základě srovnatelných období na max. 20 lidí. Citlivé údaje o zdravotním stavu nebyly zpřístupněny neoprávněným subjektům, systémy fungují, nedošlo k průniku útočníků ani zásahu do integrity dat.
Pojišťovna incident vyhodnotila jak málo závažný, protože se dotkl jen malého počtu klientů, nedošlo k úniku dat a ani k systematickému selhání či narušení provozní odolnosti.
Bylo její hodnocení správné z pohledu GDPR? Nebylo.
Proč ne?
Protože pro dotčené osoby, klienty, znamenal tento incident podstatné rizika. A není důležité, že jen pro zlomek promile celkového počtu klientů, ani že celkový systém kybernetické bezpečnosti dané pojišťovny narušen nebyl.
Jak to?
Těch blíže neurčených 20 klientů si myslelo, že svoji pojistnou událost uplatnili včas. Další kroky nedělají, čekají na zprávu od pojišťovny. A čekají na pojistné plnění, které pro ně může být existenčně důležité, například při výpadku příjmu, nutnosti hradit drahou léčbu či hospitalizaci v zahraničí atd. Jeho neposkytnutí, resp. pozdější výplata způsobená tímto „drobným“ výpadkem, pro ně může mít závažné negativní důsledky.
Drobný incident může být závažný GDPR problém
A to je právě ten rozdíl. Z pohledu pojišťovny se jednalo o drobný technický problém s malým dopadem na mizivý počet klientů. Ovšem z pohledu dotčených klientů mohlo dojít k vážnému zásahu do jejich práv.
Právě z tohoto hlediska je nutno hodnotit rizika související se zpracováním a ochranou osobních údajů. Jinak nemůže být organizace v souladu s požadavky GDPR.
