GDPR ve webové aplikaci: Co navrhnout ještě před první databází
Aplikace funguje a těsně před spuštěním přichází otázka, kam vložit souhlas s GDPR. Jenže zákaznické údaje už putují do logů, analytiky a testovací databáze. Ochranu osobních údajů potřebujete promítnout do datového modelu a provozu. Dodatečný dokument sám nenapraví přístupová práva ani chybějící mazání.
01Začněte mapou údajů a odpovědností
Tento průvodce vychází z GDPR EU a míří na běžnou firemní aplikaci. Oborová pravidla a konkrétní právní tituly potvrďte s člověkem odpovědným za ochranu údajů. Pro britský trh se samostatně posuzuje UK GDPR; anglický překlad zásad zpracování neurčuje použitelný právní režim.
Nakreslete cestu jedné poptávky: formulář, aplikační server, databáze, e-mail, CRM, záloha a podpora. U každého místa poznamenejte účel, příjemce a dobu uchování. Zahrňte i fronty zpráv, vyhledávací indexy, exporty a chybové reporty. Právě vedlejší kopie bývají při návrhu přehlédnuté.
Podle GDPR správce rozhoduje o účelech a prostředcích zpracování, zpracovatel jedná jeho jménem. Vývojář není automaticky zpracovatelem jen proto, že napsal kód. Rozhoduje skutečná práce s údaji. Sepište, kdo určuje pravidla a kdo má přístup při údržbě.
02U každého údaje zdůvodněte účel
Ptejte se, jaký krok bez daného údaje nelze udělat. Pro doručení digitálního návodu nejspíš nepotřebujete adresu bydliště. Volné poznámkové pole může naopak přinést údaje, které jste vůbec nechtěli sbírat. Omezte jeho použití a vysvětlete, co do něj patří.
EDPB popisuje ochranu údajů už při návrhu a ve výchozím nastavení. Prakticky z toho pro váš tým plyne úkol: u nové tabulky, události nebo integrace projít stejné otázky jako u formuláře. Skrytý povinný údaj v API stále zůstává sbíraným údajem.
| Návrhová otázka | Co má vzniknout |
|---|---|
| Proč údaj sbíráme? | Konkrétní účel a vlastník rozhodnutí. |
| Kdo ho potřebuje? | Role a kontrola přístupu na serveru. |
| Jak dlouho je užitečný? | Pravidlo uchování a spouštěč výmazu. |
| Kam se kopíruje? | Seznam návazných systémů a dodavatelů. |
Tabulka je pracovní pomůcka, nikoliv hotový právní rozbor. Doplňte ji skutečnými daty z aplikace. Odpověď „pro jistotu“ vraťte k rozhodnutí zadavateli.
03Souhlas není univerzální právní titul
Ke každému účelu přiřaďte odpovídající právní základ. EDPB rozlišuje například smlouvu, právní povinnost, souhlas a oprávněný zájem. Nezbytné vyřízení zákazníkem vyžádané nabídky může vycházet z předsmluvních kroků. Marketing má vlastní posouzení; nelze jej automaticky připojit ke smluvnímu plnění.
Kde zpracování stojí na souhlasu, připravte jeho prokazatelné udělení a snadné odvolání. Doporučujeme ukládat účel, verzi vysvětlení, čas a způsob volby. Změna v profilu má doputovat také do propojených systémů. Zaškrtávátko „Souhlasím s GDPR“ tento proces nespecifikuje.
Informační text má odpovídat skutečnému provozu: kdo údaje zpracovává, proč, komu je předává a jak uplatnit práva. Umístěte relevantní vysvětlení také k místu sběru. Neměňte popis účelu jen proto, aby dodatečně pokryl již hotovou integraci.
04Přístup ověřujte ke konkrétnímu záznamu
Připravte matici rolí: zákazník, pracovník podpory, správce firmy a technický správce. Každé roli určete potřebné operace. V aplikaci s více zákaznickými firmami ověřujte také příslušnost záznamu k firmě, včetně exportů, příloh a vyhledávání.
Skryté tlačítko není kontrola oprávnění. Požadavek musí ověřit server. Do přejímky zařaďte pokus otevřít cizí identifikátor a použít odkaz po odebrání přístupu. Pro mimořádný zásah podpory navrhněte omezené oprávnění a dohledatelný důvod, místo trvalého sdíleného administrátorského hesla.
EDPB požaduje zabezpečení odpovídající riziku. Výběr konkrétních opatření proto opřete o dopad možného úniku, ztráty nebo změny údajů. Šifrování přenosu, správa klíčů, obnova záloh a aktualizace musí mít konkrétního vlastníka.
05Mazání navrhněte jako součást datového modelu
Pro jednotlivé kategorie nastavte odůvodněné lhůty a jejich začátek. Jinou potřebu má rozpracovaný formulář a jinou účetní doklad s povinnou archivací. Neexistuje jedna univerzální doba, po kterou má každá webová aplikace uchovávat všechno.
Modelový scénář: zákazník zruší účet. Přihlášení se uzavře, nepotřebný profil se odstraní a doklady se zákonnou povinností uchování zůstanou odděleně s omezeným přístupem. Přesné rozdělení potvrďte pro svůj provoz. Právo na výmaz má výjimky; aplikace musí umět vysvětlit, co zůstává a proč.
Do plánu zahrňte repliky, indexy a dodavatele. U záloh určete jejich cyklus, přístup a postup po obnově, aby se odstraněné údaje bez kontroly nevrátily do běžného provozu. Pouhý příznak „smazáno“ nepředstavuje fyzický výmaz. Pseudonymizované údaje také nejsou automaticky anonymní.
06Práva lidí potřebují funkční obsluhu
Připravte způsob přijetí žádosti, přiměřeného ověření totožnosti, dohledání záznamů a bezpečného předání odpovědi. EDPB uvádí základní lhůtu jednoho měsíce; při podmínkách pro prodloužení je třeba člověka včas informovat. Nečekejte s hledáním kopií až na první skutečnou žádost.
Vyzkoušejte přístup, opravu, výmaz a omezení zpracování podle relevantního scénáře. Přenositelnost se neuplatňuje automaticky na každý údaj. Export pro uživatele nesmí obsahovat cizí kontakty, interní tajemství nebo heslové hashe. Technická možnost stáhnout databázový řádek ještě není správně vyřízená žádost.
07Dodavatele posuzujte podle skutečných toků
U hostingu, e-mailu, monitoringu a AI služby zjistěte, které údaje dostávají, jak dlouho je drží a kdo jsou další zpracovatelé. Pokud jde o vztah správce a zpracovatele, řešte smlouvu podle článku 28 GDPR. Marketingové označení „GDPR ready“ vám neřekne, jaká konfigurace je vhodná pro váš účel.
Předávání mimo EHP má další pravidla. Prověřte příslušný mechanismus předávání a případná další opatření. Nestačí zaškrtnout evropský region serveru, pokud data jiným příjemcům mimo EHP zpřístupňuje podpora nebo další služba. Při návrhu integrací zachyťte i tyto přístupy.
08Cookies, logy a testovací data kontrolujte zvlášť
Souhlas s ukládáním cookies a právní titul pro další zpracování údajů jsou odlišné otázky. Pro české nasazení ÚOOÚ vysvětluje výjimku pro nezbytné technické cookies i snadné odmítnutí ostatních. Národní pravidla posuďte podle cílových trhů. Ověřte skutečné síťové požadavky před volbou i po jejím odvolání.
Z logů odstraňte hesla, tokeny a zbytečné obsahy formulářů. Nenechávejte osobní údaje v URL. Pro testování používejte syntetická data, pokud nepotřebujete jiný odůvodněný postup. Kopie produkční databáze na notebooku dodavatele není neškodná jen proto, že má název „test“. Zkontrolujte také snímání obrazovky v nástrojích podpory.
09Připravte incident a podmínky spuštění
Sepište kontakt na rozhodující osobu, způsob zajištění důkazů a dostupné informace o rozsahu incidentu. EDPB rozlišuje povinnosti při porušení zabezpečení: správce ohlašuje dozorovému úřadu bez zbytečného odkladu, pokud možno do 72 hodin od zjištění, pokud není nepravděpodobné riziko pro práva a svobody. Zpracovatel informuje správce bez zbytečného odkladu.
Lidem se porušení oznamuje bez zbytečného odkladu, jestliže pravděpodobně znamená vysoké riziko, s výjimkami podle GDPR. Každé porušení zdokumentujte. Při návrhu zároveň posuďte potřebu DPIA, tedy posouzení vlivu, pokud zpracování pravděpodobně přinese vysoké riziko. Malá firma není automaticky vyňata ze všech evidenčních povinností.
10Časté otázky
Stačí zásady zpracování a cookie lišta?
Nestačí. Popis musí odpovídat skutečnému sběru, přístupu, předávání a mazání údajů.
Musí být každé smazání účtu okamžitým výmazem všeho?
Ne. Posuďte právní povinnosti a další oprávněné důvody uchování. Oddělte takové údaje od běžně používaného profilu.
Co má vývojář předat?
Mapu toků, matici přístupů, nastavení lhůt, postup obsluhy práv, seznam dodavatelů a výsledky praktických kontrol. Právní rozhodnutí má potvrdit odpovědná osoba.
Proberme ochranu údajů ještě při návrhu aplikace. Konkrétní pravidla se lépe staví do datového modelu před spuštěním než dodatečně do hotového provozu.