Kdo všechno vidí data vašich zákazníků? Bezpečnost dat v systému na míru

01Kde data unikají: čísla za Česko

Počet ohlášení u ÚOOÚ se v posledních pěti letech pohybuje zhruba mezi 300 a 400 ročně. Ohlašuje se jen to, co správce údajů sám odhalí a vyhodnotí jako riziko, takže skutečných případů bude víc.

Zajímavější než samotný počet jsou příčiny. Nedbalost vede s velkým náskokem. Mezi příklady ÚOOÚ uvádí i neodebrání přístupových práv bývalým zaměstnancům a nedostatečnou anonymizaci zveřejněných dokumentů. Obojí je chyba procesu, kterou dobře navržený systém umí zachytit.

Bezpečnost dat ale neznamená jen únik. Podle Eurostatu mělo v roce 2023 nějaký bezpečnostní incident s následky 26,6 % českých firem s aspoň deseti zaměstnanci, víc, než je průměr EU (21,5 %). Nejčastějším následkem byla nedostupnost služeb kvůli selhání hardwaru nebo softwaru (22,1 % firem), zatímco útok zvenčí vyřadil služby jen 4,5 % firem. Zálohy a schopnost systém rychle obnovit jsou proto stejně důležité jako ochrana před útočníky.

Úniky jsou také drahé. Podle zprávy IBM Cost of a Data Breach 2026, pro kterou Ponemon Institute zkoumal 602 organizací v 16 zemích a regionech, vyšla průměrná škoda z jednoho úniku na 4,99 milionu USD. Nejčastěji unikaly osobní údaje zákazníků, a to v 52 % případů. Co z toho plyne pro vedení firmy, rozebíráme v článku Co musí vedení zařídit, než aplikaci spustí.

02O bezpečnosti se rozhoduje v každé fázi projektu

GDPR v článku 25 chce, aby správce zavedl ochranu údajů už ve chvíli, kdy určuje prostředky zpracování, tedy když se systém navrhuje. Evropský sbor pro ochranu osobních údajů (EDPB) ve svých pokynech k článku 25 výslovně jmenuje i výběr dodavatele, vývoj, testování, údržbu a mazání. Prakticky to znamená, že každá fáze projektu má své bezpečnostní úkoly.

Jak celý projekt probíhá u nás, od prvního hovoru po předání, popisujeme na stránce Jak to probíhá.

03Na začátku je soupis dat

Než vznikne první obrazovka, sepište, jaká data bude systém ukládat. Ke každému údaji patří tři otázky: proč ho potřebujeme, jak dlouho ho budeme mít a kdo ho smí vidět. GDPR tomu říká minimalizace údajů. Co systém nesbírá, to nemůže uniknout.

Stejně důležité je mazání. Když zákazník odejde nebo uplyne zákonná lhůta, data se mají smazat nebo nevratně anonymizovat. EDPB připomíná, že správce musí určit, jaké osobní údaje a na jak dlouho potřebuje i v zálohách a logech. Mazání proto patří do zadání jako samostatná funkce, třeba noční úloha, která projde staré záznamy.

Pokud bude systém ve velkém rozsahu zpracovávat zvláštní kategorie údajů nebo lidi systematicky hodnotit či sledovat, vyžaduje GDPR (čl. 35) ještě před spuštěním posouzení vlivu na ochranu osobních údajů. Zjistěte to už při zadání.

04Kdo smí k čemu: role, oprávnění a dvoufázové ověření

Chybné řízení přístupu je v žebříčku rizik OWASP Top 10:2025 na prvním místě a nějakou jeho formu našli testeři u 100 % testovaných aplikací. Typický příklad: obchodník si v adrese změní číslo zákazníka a otevře kartu klienta, kterého nemá vidět. Podrobně tyto chyby rozebíráme v článku Chyby v kódu, přes které unikají data.

• Oprávnění kontroluje server u každého požadavku. Skryté tlačítko v aplikaci nic nechrání.
• Role podle skutečné práce. Obchodník vidí své klienty, účetní faktury, podpora jen to, co potřebuje k vyřešení požadavku.
• Nejmenší nutná oprávnění. Nový uživatel začíná s minimem a oprávnění se mu přidávají podle potřeby.
• Hromadný export zvlášť. Stáhnout celou databázi zákazníků do Excelu má umět jen pár lidí a každý export se zapíše.
• Osobní účty, žádné sdílené. Účet „admin“ se společným heslem znemožní zjistit, kdo co udělal.
• Odchod zaměstnance = zrušení přístupu týž den. Nejlépe napojením na personální evidenci nebo firemní účty, aby se na to nedalo zapomenout.

K oprávněním patří i bezpečné přihlášení. Dvoufázové ověření je nejběžnější forma vícefaktorového ověření. ÚOOÚ ve výroční zprávě za rok 2024 popisuje aplikaci pro rozvoz jídla, kde šlo se správnou kombinací e-mailu a hesla získat osobní údaje a objednávat na cizí účet. Hesla neměla žádné požadavky na složitost a chybělo dvoufázové ověření. Úřad to vyhodnotil jako porušení čl. 32 GDPR. U interního systému s daty zákazníků by dvoufázové ověření mělo být samozřejmostí, alespoň pro administrátory a pro role s exportem. Jak ho nastavit u běžných účtů, ukazujeme v návodu Jak zabezpečit telefon a účty.

05Auditní log: kdo se na co díval a co změnil

Když se něco stane, první otázka zní: kdo k datům přistupoval? Bez záznamu přístupů na ni neodpovíte. ÚOOÚ v roce 2025 kontroloval Policii ČR a zjistil, že ne všechny útvary zaznamenávaly přístupy k nahrávkám z osobních kamer, takže nebylo možné doložit, kdo a proč si je pouštěl. Úřad v tom viděl porušení čl. 25 i čl. 32 GDPR. Pro firemní systém platí totéž: bez logu neprokážete, že data nikdo nepovolaný neviděl.

• kdo, kdy a odkud se přihlásil, včetně neúspěšných pokusů,
• kdo otevřel, změnil, smazal nebo exportoval který záznam,
• změny rolí a oprávnění a kdo je provedl,
• přístupy administrátorů a dodavatele, zvlášť ty mimo běžnou pracovní dobu.

Do logu naopak nepatří hesla, přístupové tokeny, celá rodná čísla ani čísla karet. Log musí být chráněný proti úpravám a mít stanovenou dobu uchování. Nemá smysl ho držet věčně, ale ani tak krátce, aby zmizel dřív, než se na únik přijde. IBM uvádí, že odhalení a zastavení úniku trvalo v průměru 247 dní.

Česko je v silných heslech nad průměrem EU, v logování, vícefaktorovém ověření a šifrování ale zaostává. Přitom jde o opatření, která se do systému na míru dají levně zabudovat, když se s nimi počítá od začátku.

06Šifrování: po cestě, v databázi i v záloze

Podle IBM 53 % organizací, kterým unikla data, nešifrovalo citlivá data zároveň při uložení i při přenosu. U organizací, které šifrování používaly, byla cena úniku v průměru o 213 478 USD nižší.

• Přenos: HTTPS všude, i mezi vlastními službami a při volání API. Nastavení serveru a certifikátů popisujeme v článku Jak zabezpečit server, HTTPS a cloud.
• Uložení: šifrovaný disk a databáze. V cloudu jde většinou jen o zapnutí, ale je potřeba to ověřit.
• Citlivá pole: rodná čísla nebo zdravotní údaje šifrovat navíc přímo v aplikaci, s klíčem uloženým mimo databázi.
• Hesla: nikdy šifrovat, ale ukládat jako hash pomalým algoritmem (Argon2, bcrypt), aby se z uniklé databáze nedala snadno zjistit.
• Zálohy: šifrované a s jiným klíčem a jinými přístupy než ostrý systém.

Šifrování má i právní výhodu. Když uniknou data, která jsou pro nepovolané osoby nesrozumitelná, například díky šifrování, nemusí je správce podle čl. 34 odst. 3 písm. a) GDPR dotčeným lidem oznamovat, pokud nebyl prozrazen i klíč. Ohlášení úřadu tím ale automaticky neodpadá.

07Ostrá data nepatří do vývoje ani na testovací server

Nejrychlejší způsob, jak otestovat novou funkci, je stáhnout si kopii ostré databáze. Zároveň je to snadná cesta, jak data opustí kontrolované prostředí. Testovací server bývá hůř chráněný, přistupuje k němu víc lidí a kopie končí na noteboocích vývojářů.

Americký standard NIST SP 800-53 (opatření SA-3(2) a PM-25) varuje, že použití ostrých dat ve vývoji a testování znamená výrazné riziko, a doporučuje testovací nebo smyšlená data. GDPR samo testování na ostrých datech výslovně nezakazuje, ale zásady minimalizace a ochrany už při návrhu míří stejným směrem. Pozor na častý omyl: pseudonymizovaná data jsou pořád osobní údaje. EDPB to zdůrazňuje ve svých pokynech k pseudonymizaci z ledna 2025 (zatím verze pro veřejnou konzultaci). Když jde záznam podle klíče nebo jiných údajů přiřadit ke konkrétnímu člověku, GDPR se na něj vztahuje dál.

• Pro vývoj používejte generovaná data, která vypadají realisticky, ale nepatří nikomu skutečnému.
• Když potřebujete skutečný objem nebo strukturu, anonymizujte kopii nevratně ještě na produkčním serveru, dřív než ho opustí.
• Testovací server schovejte za přihlášení a nenechávejte ho veřejně dostupný.
• Vývojáři nemají mít trvalý přístup do ostré databáze. Výjimky jen na nezbytnou dobu a se záznamem v logu.

/* Kopie pro testování: osobní údaje přepsat dřív, než data opustí produkci */
UPDATE customers SET
  name = 'Zákazník ' || id,
  email = 'zakaznik' || id || '@example.com',
  phone = NULL,
  birth_number = NULL,
  note = NULL;

Jak snadno data opustí kontrolované prostředí i ve velkých firmách, ukázal případ Microsoftu. Tým výzkumníků AI v roce 2020 zveřejnil na GitHubu odkaz na trénovací data. Sdílecí token ale místo jedné složky otevíral celý úložný účet s právy k úplné kontrole a s platností později prodlouženou až do roku 2051. Podle společnosti Wiz, která chybu v roce 2023 našla, bylo dostupných 38 TB dat včetně zálohy počítačů dvou zaměstnanců s hesly, klíči a více než 30 000 interními zprávami z Teams. Microsoft potvrdil, že data zákazníků mezi nimi nebyla.

08Tajné klíče a zdrojový kód u dodavatele

Toyota v říjnu 2022 oznámila (tisková zpráva je jen japonsky), že mohlo uniknout 296 019 e-mailových adres a zákaznických čísel uživatelů služby T-Connect. Příčina: firma, která pro Toyotu vyvíjela web služby, v prosinci 2017 v rozporu s pravidly nahrála část zdrojového kódu do veřejného účtu na GitHubu. V kódu byl přístupový klíč k datovému serveru a nikdo si toho téměř pět let nevšiml.

Není to ojedinělé. Podle zprávy GitGuardian State of Secrets Sprawl 2026 přibylo jen za rok 2025 ve veřejných commitech na GitHubu 28,65 milionu nových tajných klíčů a hesel. Z platných klíčů nalezených v roce 2022 jich v lednu 2026 stále fungovalo přes 64 %. Jak klíče chránit a jak se bránit útokům přes závislosti, rozebíráme v článku Jak se kradou API klíče.

• Repozitář se zdrojovým kódem má být na účtu vaší firmy a dodavatel v něm má vlastní přístup.
• Hesla a klíče patří do trezoru na hesla a klíče (secrets manager) nebo do proměnných prostředí, nikdy do kódu.
• Repozitář má mít zapnutou automatickou kontrolu uniklých klíčů.
• Po skončení spolupráce s dodavatelem nebo po odchodu vývojáře se klíče vymění.

09AI nástroje: data zákazníků do chatu nepatří

Podle letošní zprávy IBM se 43 % bezpečnostních incidentů zkoumaných organizací týkalo takzvané stínové AI, tedy nástrojů, které zaměstnanci používají bez schválení firmy. Proti předchozí zprávě jde o víc než dvojnásobek. Stačí, aby někdo vložil export zákazníků do veřejného chatbotu a požádal o shrnutí.

Mezi organizacemi, které řešily únik související s AI, navíc 92 % nemělo správně nastavené řízení přístupu pro AI. To se týká i AI funkcí přímo v systému. Asistent, který odpovídá nad daty z CRM, musí respektovat stejná oprávnění jako přihlášený uživatel, jinak se přes něj dá zeptat na cokoli.

• Určete, které AI nástroje se ve firmě smí používat a s jakými daty.
• Data zákazníků posílejte jen do služeb, se kterými máte smlouvu o zpracování a které data nepoužívají k trénování.
• AI funkce v systému napojte na stejná oprávnění, jaká má uživatel, a jejich dotazy logujte.

Jaké povinnosti přináší evropské nařízení o umělé inteligenci, shrnujeme v článku AI Act: co musí firmy řešit.

10Zálohy, ze kterých jde data opravdu obnovit

GDPR v čl. 32 počítá se schopností včas obnovit dostupnost osobních údajů po incidentu. Zálohu na oddělené místo má podle Eurostatu 78,7 % českých firem s aspoň deseti zaměstnanci. Jestli z ní jde něco obnovit, je ale jiná otázka. Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) ve zprávě o stavu kybernetické bezpečnosti za rok 2025 mezi nejvýznamnějšími nedostatky ze svých kontrol uvádí, že zálohy nejsou dostatečně testovány ani chráněny.

• Pravidlo 3-2-1, které doporučuje i NÚKIB: aspoň tři kopie dat, na dvou různých typech médií a jedna mimo pracoviště.
• Aspoň jedna kopie offline nebo neměnná, aby ji ransomware nemohl zašifrovat ani smazat. Americký úřad CISA doporučuje zálohy šifrované, offline a pravidelně testované.
• Zálohy s jinými přístupy než ostrý systém. Kdo ovládne server, nesmí se tím dostat i k zálohám.
• Obnovu pravidelně zkoušet naostro, nejen kontrolovat, že záloha proběhla.
• Předem určit, jak dlouho smí systém stát a o kolik dat můžete nejvýš přijít. Podle toho se nastaví četnost záloh.

11Kde data leží: hosting, cloud a přenos mimo EU

Služba, která za vás a na váš pokyn osobní údaje ukládá nebo zpracovává, je podle GDPR zpracovatel. Typicky jde o hosting, cloud, rozesílání e-mailů, sledování chyb v aplikaci nebo AI služby. ÚOOÚ připomíná, že osobní údaje musí být zabezpečené i u zpracovatele a ten nesmí zapojit dalšího zpracovatele bez vašeho povolení. Chtějte proto po dodavateli seznam všech služeb, přes které data v systému potečou, i se zemí, kde jsou data uložená.

U služeb z USA hraje roli rámec pro ochranu osobních údajů mezi EU a USA (Data Privacy Framework). Evropská komise ho schválila 10. 7. 2023 a platí jen pro americké firmy, které se k němu přihlásily. Tribunál EU v září 2025 zamítl žalobu, která ho napadala, proti rozsudku se ale žalobce odvolal k Soudnímu dvoru EU. Kde to jde, je proto jednodušší mít data uložená v EU.

Cloud neznamená, že bezpečnost řeší poskytovatel. V roce 2024 upozornily firmy Mandiant a Snowflake zhruba 165 zákazníků datové platformy Snowflake, že jim útočníci mohli odcizit data. Podle vyšetřování společnosti Mandiant přitom nebyla prolomena samotná platforma. Útočníci použili ukradené přihlašovací údaje k účtům bez vícefaktorového ověření. V mnoha případech se nezměnily až čtyři roky.

Myslete i na odchod. Nařízení EU o datech (Data Act) se použije od 12. 9. 2025 a ukládá poskytovatelům cloudu usnadnit přechod k jinému poskytovateli. Od 12. 1. 2027 za přechod a za přenos dat ven nesmí účtovat žádné poplatky, jak uvádí Evropská komise.

12Smlouva s dodavatelem: co v ní nesmí chybět

Přes dodavatele dnes vede velká část úniků. Podle zprávy Verizon DBIR 2026 se třetí strana podílela na 48 % úniků, o 60 % víc než o rok dřív. NÚKIB ve zprávě za rok 2025 píše, že ve veřejném sektoru „pozoruhodně vzrostlo množství útoků skrze dodavatele služeb“.

Pokud dodavatel při vývoji, správě nebo podpoře osobní údaje za vás zpracovává, je zpracovatelem a GDPR v čl. 28 vyžaduje písemnou smlouvu. Nařízení mluví o smlouvě nebo jiném právním aktu, takže náležitosti mohou být součástí smlouvy o dílo. Úřad ale při kontrole krajů upozornil, že smlouvy často jen opisují text nařízení bez konkrétních opatření. Smlouva by měla obsahovat hlavně tohle:

• zpracování jen na váš pokyn a mlčenlivost všech lidí dodavatele, kteří k datům mají přístup,
• konkrétní bezpečnostní opatření (šifrování, dvoufázové ověření, logy, zálohy), ne jen odkaz na čl. 32,
• subdodavatelé jen s vaším souhlasem a se stejnými povinnostmi,
• ohlášení incidentu bez zbytečného odkladu, nejlépe s lhůtou v hodinách, abyste stihli své 72 hodiny,
• pomoc s žádostmi lidí o přístup k údajům nebo o výmaz,
• vrácení nebo smazání dat včetně kopií po skončení spolupráce, podle vaší volby,
• právo na kontrolu nebo audit,
• mimo GDPR: zdrojový kód a repozitář na vašem účtu, bezpečnostní test před spuštěním, aktualizace knihoven a individuální přístupy pro každého člověka dodavatele.

Pokud vaše firma spadá pod nový zákon o kybernetické bezpečnosti č. 264/2025 Sb., účinný od 1. 11. 2025, a bezpečnostní opatření zajišťujete přes dodavatele, musíte požadavky z nich zahrnout do smlouvy s ním (§ 13 odst. 5). Vyhláška č. 410/2025 Sb. pro režim nižších povinností přitom u dodavatele výslovně zmiňuje i postupy bezpečného vývoje. Co dělat, když dodavatel přestane komunikovat a data i kód drží u sebe, popisujeme v článku Jak převzít web od dodavatele.

13Když data přece jen uniknou

Na plán reakce je pozdě ve chvíli, kdy k úniku dojde. Lhůty jsou krátké a běží od okamžiku, kdy se o problému dozvíte.

Únik se ohlašuje přes formulář ÚOOÚ. Pokud to do 72 hodin nestihnete, musíte zpoždění zdůvodnit. Úřad podle vlastních slov při posuzování zkoumá hlavně to, jaká opatření jste přijali před incidentem. Dokumentovat přitom musíte všechny případy, i ty, které se neohlašují.

Do plánu reakce patří, kdo o dalším postupu rozhoduje, jak se kontaktuje dodavatel mimo pracovní dobu a jak rychle zjistíte, ke kterým záznamům se kdo dostal. Tady znovu přichází na řadu auditní log. Kdo ho nemá, často nedokáže doložit, co zůstalo v bezpečí, a musí počítat s nejhorší variantou.

14Otázky, které položit dodavateli

Než podepíšete smlouvu na systém na míru, položte dodavateli těchto osm otázek. Na každou by měl odpovědět konkrétně a bez dlouhého přemýšlení.

Pokud zvažujete, jestli systém na míru vůbec potřebujete, pomůže článek Kdy už firmě nestačí Excel. Orientační ceny vývoje najdete v ceníku.

15Časté otázky

16Zdroje

• ÚOOÚ: Výroční zpráva za rok 2025
• ÚOOÚ: Výroční zpráva za rok 2024
• ÚOOÚ: Zpracovatel
• ÚOOÚ: Porušení zabezpečení osobních údajů
• NÚKIB: Zpráva o stavu kybernetické bezpečnosti ČR za rok 2025
• Zákon č. 264/2025 Sb., o kybernetické bezpečnosti
• Vyhláška č. 410/2025 Sb.
• Nařízení GDPR na EUR-Lex
• EDPB: Guidelines 4/2019 on Article 25
• EDPB: Guidelines 01/2025 on Pseudonymisation
• Eurostat: ICT security in enterprises
• IBM: Cost of a Data Breach Report 2026
• Verizon: 2026 DBIR Executive Summary
• OWASP Top 10:2025, A01 Broken Access Control
• NIST SP 800-53 Rev. 5
• GitGuardian: State of Secrets Sprawl 2026
• Wiz: 38 TB dat z Microsoftu
• Toyota: tisková zpráva k T-Connect (japonsky)
• Mandiant: UNC5537 a Snowflake
• CISA: #StopRansomware Guide
• Evropská komise: Data Act explained