DLP v roce 2026: ISO 27001 pro GDPR, NIS2 a DORA

Začíná to tabulkou.

V pondělí v 08:17 exportuje manažer péče o zákazníky z CRM 14 000 kontaktů podnikových zákazníků, aby připravil kampaň na obnovu smluv. V 08:24 je tabulka připojena k e-mailu. V 08:26 je e-mail odeslán na osobní účet Gmail, protože zaměstnanec chce pracovat během cesty vlakem. V 08:31 je stejný soubor nahrán do neschválené AI služby pro pořizování poznámek, aby se „vyčistily duplicity“.

Zatím nic nevypadá jako porušení zabezpečení. Neexistuje žádná ransomwarová zpráva, žádný malware beacon, žádný kompromitovaný administrátorský účet ani žádný veřejný únik. Pro CISO, manažera compliance a pověřence pro ochranu osobních údajů však už nastala klíčová otázka: dokáže organizace prokázat, že tento pohyb dat byl povolený, klasifikovaný, zaznamenaný do logů, šifrovaný, odůvodněný a v případě potřeby odvolatelný?

Stejný scénář se ve finančních službách odehrává každý týden. Vývojář se pokusí nahrát Q1_Investor_Projections_DRAFT.xlsx na osobní cloudové úložiště, protože VPN je pomalá. Obchodní manažer exportuje seznam zákazníků do spotřebitelské aplikace pro spolupráci. Analytik podpory vloží záznamy zákazníků do neschváleného AI nástroje. V každém případě může být motivací pohodlí, nikoli zlý úmysl, ale riziko je stejné. Citlivá data překročila, nebo téměř překročila, hranici, kterou organizace nemá pod kontrolou.

To je dnešní problém Data Loss Prevention. DLP už není jen pravidlo e-mailové brány nebo agent na koncovém zařízení. V roce 2026 je účinná prevence úniku dat řízeným systémem opatření podloženým důkazy napříč SaaS, cloudovým úložištěm, koncovými zařízeními, mobilními zařízeními, dodavateli, rozhraními API, vývojovými prostředími, exporty záloh, nástroji pro spolupráci a uživatelskými zkratkami.

GDPR Article 32 očekává vhodná technická a organizační opatření pro zabezpečení zpracování. NIS2 Article 21 očekává kyberbezpečnostní opatření založená na rizicích, včetně kybernetické hygieny, řízení přístupu, správy aktiv, zabezpečení dodavatelského řetězce, zvládání incidentů, šifrování a testování účinnosti. DORA očekává, že finanční subjekty budou řídit rizika v oblasti ICT prostřednictvím správy, detekce, reakce, obnovy, testování, dohledu nad třetími stranami a auditovatelnosti. ISO/IEC 27001:2022 poskytuje základ systému řízení, díky němuž lze tyto povinnosti převést do provozní, měřitelné a auditovatelné podoby.

Chybou mnoha organizací je nákup nástroje DLP dříve, než definují, co znamená „únik“. Přístup Clarysec začíná dříve: klasifikovat data, definovat povolené přenosy, prosazovat politiku, monitorovat výjimky, připravit důkazy pro reakci a vše propojit s ISMS.

Jak uvádí Zenith Blueprint: 30krokový plán auditora ve fázi Controls in Action, krok 19, Technological Controls I:

Data Leakage Prevention je o zastavení neoprávněného nebo náhodného zpřístupnění citlivých informací, ať už uniknou e-mailem, nahráním do cloudu, přenosným médiem, nebo dokonce zapomenutým výtiskem. Opatření 8.12 řeší potřebu monitorovat, omezovat a řešit veškerá data, která opouštějí důvěryhodné hranice organizace, bez ohledu na to, zda jde o digitální, fyzický nebo lidským jednáním způsobený pohyb. Zenith Blueprint

Tato věta vystihuje jádro DLP v roce 2026: monitorovat, omezovat a reagovat.

Proč je DLP nyní otázkou souladu na úrovni řídicích orgánů

Řídicí orgán se obvykle neptá, zda regulární výraz v DLP detekuje čísla národních průkazů totožnosti. Ptá se, zda organizace dokáže chránit důvěru zákazníků, pokračovat v provozu, vyhnout se regulatorní expozici a prokázat přiměřené zabezpečení, když se něco pokazí.

Právě zde se GDPR, NIS2 a DORA protínají.

GDPR se široce vztahuje na automatizované zpracování osobních údajů, včetně správců a zpracovatelů usazených v EU a organizací mimo EU, které nabízejí zboží nebo služby osobám v EU nebo monitorují jejich chování. Osobní údaje vymezuje široce a zahrnuje operace, jako je shromažďování, ukládání, používání, zpřístupnění, výmaz a zničení. Neoprávněné zpřístupnění osobních údajů nebo neoprávněný přístup k nim může představovat porušení zabezpečení osobních údajů. GDPR Article 5 také výslovně stanoví odpovědnost: organizace musí nejen dodržovat zásady, jako jsou minimalizace údajů, omezení uložení, integrita a důvěrnost, ale musí být schopny soulad doložit.

NIS2 rozšiřuje tlak nad rámec ochrany soukromí. Vztahuje se na mnoho základních a důležitých subjektů, včetně sektorů, jako jsou bankovnictví, infrastruktury finančních trhů, poskytovatelé služeb cloud computingu, poskytovatelé datových center, poskytovatelé řízených služeb, poskytovatelé řízených bezpečnostních služeb, online tržiště, vyhledávače a platformy sociálních sítí. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, politik bezpečnosti informačních systémů, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného vývoje, testování účinnosti, kybernetické hygieny, školení, kryptografie, řízení přístupu, správy aktiv a autentizace.

DORA se použije od 17. ledna 2025 a funguje jako specializovaný předpis finančního sektoru pro digitální provozní odolnost. Pro finanční subjekty v působnosti se považuje za sektorově specifický právní akt Unie pro účely překryvu s NIS2. DORA začleňuje DLP do řízení rizik v oblasti ICT, klasifikace incidentů, ztráty dat ovlivňující dostupnost, autenticitu, integritu nebo důvěrnost, testování digitální provozní odolnosti, řízení třetích stran v oblasti ICT a smluvních kontrol.

Otázka DLP v roce 2026 nezní „Máme nástroj?“ Zní:

1. Víme, které informace jsou citlivé?
2. Víme, kde jsou uloženy, zpracovávány a přenášeny?
3. Jsou definovány povolené a zakázané přenosové trasy?
4. Jsou uživatelé proškoleni a technicky omezeni?
5. Jsou cloudové a SaaS trasy řízeny?
6. Jsou logy dostatečné pro vyšetřování?
7. Jsou upozornění rychle tříděna a incidenty klasifikovány?
8. Jsou dodavatelé a outsourcované ICT služby smluvně vázáni?
9. Dokážeme prokázat, že opatření fungují?

ISO/IEC 27001:2022 je pro zodpovězení těchto otázek vhodná, protože vyžaduje kontext, požadavky zainteresovaných stran, posouzení rizik, ošetření rizik, měřitelné cíle, operativní řízení, dokumentované důkazy, řízení dodavatelů, interní audit, přezkoumání vedením a neustálé zlepšování. Není to norma pro DLP, ale mění DLP z izolované technologické konfigurace na řízený proces systému řízení.

Řetězec opatření ISO 27001 za účinným DLP

Důvěryhodný program DLP nestojí na jednom opatření. Je postaven na řetězci.

Clarysec Zenith Controls: Průvodce napříč souladem mapuje opatření ISO/IEC 27002:2022 8.12, Data leakage prevention, jako preventivní a detekční opatření zaměřené na důvěrnost, sladěné s koncepty kybernetické bezpečnosti Protect a Detect, s ochranou informací jako provozní schopností a s ochranou/obranou jako bezpečnostní doménou. Zenith Controls

To je důležité, protože auditoři očekávají blokování i viditelnost. Preventivní pravidlo DLP bez přezkumu upozornění je neúplné. Přístup založený pouze na protokolování bez vynucování u vysoce rizikových přenosů je také slabý.

Stejný průvodce mapuje opatření ISO/IEC 27002:2022 5.12, Klasifikace informací, jako preventivní, podporující důvěrnost, integritu a dostupnost a sladěné s Identify. Opatření 5.14, Přenos informací, mapuje jako preventivní, podporující důvěrnost, integritu a dostupnost a sladěné s Protect, správou aktiv a ochranou informací.

V praxi řetězec opatření DLP vypadá takto:

Zenith Blueprint, krok 22, vysvětluje závislost mezi evidencí aktiv, klasifikací a DLP:

Přezkoumejte aktuální evidenci aktiv (5.9), abyste zajistili, že zahrnuje fyzická i logická aktiva, vlastníky a klasifikace. Propojte tuto evidenci s vaším schématem klasifikace (5.12) a zajistěte, aby citlivá aktiva byla vhodně označena a chráněna. V případě potřeby definujte uchovávání, zálohování nebo izolaci podle klasifikace.

Proto Clarysec zřídka začíná DLP engagement laděním pravidel. Začínáme sladěním aktiv, vlastníků, typů dat, klasifikačních štítků, přenosových tras a důkazních záznamů. Pokud organizace nedokáže říci, které datové sady jsou důvěrné, regulované, vlastněné zákazníkem, související s platbami nebo kritické pro podnikání, nástroj DLP může jen odhadovat.

Tři pilíře moderního programu DLP

Moderní program DLP stojí na třech vzájemně se posilujících pilířích: znát data, řídit tok a bránit hranici. Tyto pilíře převádějí ISO/IEC 27001:2022 do praxe pro soulad s GDPR, NIS2 a DORA.

Pilíř 1: Poznejte svá data pomocí klasifikace a označování

Nemůžete chránit to, čemu nerozumíte. Opatření ISO/IEC 27002:2022 5.12 a 5.13 vyžadují, aby organizace klasifikovaly informace a označovaly je podle citlivosti a požadavků na nakládání. Nejde o papírové cvičení. Je to základ pro automatizované vynucování.

Pro malé a střední podniky uvádí Politika klasifikace dat a označování:

Důvěrné: Vyžaduje šifrování při přenosu a v klidu, omezený přístup, výslovné schválení sdílení a bezpečné zničení při likvidaci. Politika klasifikace dat a označování pro malé a střední podniky

Tato citace ze sekce „Požadavky na implementaci politiky“, kapitola 6.3.3, dává programu DLP čtyři vymahatelné podmínky: šifrování, omezený přístup, schválení sdílení a bezpečnou likvidaci.

V podnikovém prostředí je Politika klasifikace dat a označování ještě přímočařejší. Ze sekce „Požadavky na implementaci politiky“, kapitola 6.2.6.2:

Blokování přenosu (např. externího e-mailu) u nesprávně označených citlivých dat Politika klasifikace dat a označování

A ze sekce „Vynucování a dodržování“, kapitola 8.3.2:

Automatizované ověření klasifikace pomocí Data Loss Prevention (DLP) a nástrojů pro vyhledávání dat

Tato ustanovení mění klasifikaci v opatření. Soubor označený jako Důvěrný může spustit šifrování, zablokovat externí přenos, vyžadovat schválení nebo vygenerovat bezpečnostní upozornění. DLP se tím stává vrstvou vynucování politiky, které rozumějí uživatelé, systémy i auditoři.

Pilíř 2: Řiďte tok pomocí bezpečného přenosu informací

Jakmile jsou data klasifikována, organizace musí řídit, jak se pohybují. Opatření ISO/IEC 27002:2022 5.14, Přenos informací, bývá často přehlíženo, ale právě zde začíná mnoho selhání DLP.

Zenith Blueprint rámuje opatření 5.14 jako potřebu řídit tok informací tak, aby přenos byl bezpečný, záměrný a v souladu s klasifikací i obchodním účelem. To platí pro e-mail, bezpečné sdílení souborů, rozhraní API, SaaS integrace, výměnná média, tištěné reporty a dodavatelské portály.

Práce na dálku to činí zvlášť důležitým. Politika práce na dálku, sekce „Požadavky na implementaci politiky“, kapitola 6.3.1.3, vyžaduje po zaměstnancích:

Používat pouze schválená řešení pro sdílení souborů (např. M365, Google Workspace s opatřeními Data Loss Prevention (DLP)) Politika práce na dálku

Pro mobilní zařízení a BYOD poskytuje Politika mobilních zařízení a používání vlastních zařízení (BYOD), sekce „Požadavky na implementaci politiky“, kapitola 6.6.4, konkrétní vynucování na koncových zařízeních:

Politiky Data Loss Prevention (DLP) musí blokovat neoprávněná nahrání, snímky obrazovky, přístup ke schránce nebo sdílení dat ze spravovaných aplikací do osobních prostor. Politika mobilních zařízení a používání vlastních zařízení (BYOD)

Je to důležité, protože data neodcházejí jen e-mailem. Odcházejí přes snímky obrazovky, synchronizaci schránky, nespravované profily prohlížeče, osobní úložiště, sdílecí nabídky mobilních zařízení, doplňky pro spolupráci a AI nástroje.

Stejně důležitá je správa cloudu. V Politice používání cloudových služeb pro malé a střední podniky, sekce „Požadavky na správu a řízení“, kapitola 5.5:

Shadow IT, definované jako používání neschválených cloudových nástrojů, musí být považováno za porušení politiky a přezkoumáno generálním ředitelem a poskytovatelem IT služeb za účelem určení rizika a požadovaných nápravných opatření. Politika používání cloudových služeb pro malé a střední podniky

U podnikových organizací zvyšuje Politika používání cloudových služeb, sekce „Požadavky na správu a řízení“, kapitola 5.5, nároky na monitorování:

Tým informační bezpečnosti musí pravidelně posuzovat síťový provoz, DNS aktivitu a logy za účelem detekce neoprávněného používání cloudu (shadow IT). Zjištěná porušení musí být neprodleně vyšetřena. Politika používání cloudových služeb

Shadow IT není jen provozní potíž IT. Podle GDPR se může stát nezákonným zpřístupněním nebo nekontrolovaným zpracováním. Podle NIS2 jde o slabinu kybernetické hygieny a dodavatelského řetězce. Podle DORA se může stát rizikem třetí strany v oblasti ICT a otázkou klasifikace incidentu.

Pilíř 3: Braňte hranici pomocí technologie DLP, politiky a povědomí

Opatření ISO/IEC 27002:2022 8.12, Data leakage prevention, je opatření, které si většina lidí s DLP spojuje. Ve vyspělém programu je však poslední linií obrany, nikoli první.

Zenith Blueprint vysvětluje, že DLP vyžaduje třívrstvý přístup: technologii, politiku a povědomí. Technologie zahrnuje DLP na koncových zařízeních, zabezpečení e-mailu, inspekci obsahu, zabezpečení přístupu do cloudu, opatření v SaaS, opatření v prohlížeči, filtrování odchozího síťového provozu a směrování upozornění. Politika definuje, co nástroje vynucují. Povědomí zajišťuje, aby zaměstnanci chápali, proč osobní e-mail, spotřebitelské cloudové úložiště a neschválené AI nástroje nejsou přípustnými způsoby nakládání s regulovanými nebo důvěrnými informacemi.

Složka reakce je stejně důležitá jako prevence. Zenith Blueprint, krok 19, uvádí:

DLP však není jen prevence, je to také reakce. Pokud je detekován potenciální únik:

✓ upozornění mají být rychle tříděna, ✓ protokolování má podporovat forenzní analýzu, ✓ plán reakce na incidenty musí být spuštěn bez prodlení.

Program DLP, který události blokuje, ale netřídí je, nevyšetřuje a nepoučí se z nich, není připraven na audit. Je pouze částečně nasazený.

Od úniku tabulky k reakci připravené na audit

Vraťme se k pondělní ranní tabulce.

Ve slabém programu organizace zjistí nahrání o tři týdny později během přezkumu ochrany soukromí. Nikdo neví, kdo export schválil, zda šlo o osobní údaje, zda byly zahrnuty zvláštní kategorie údajů, zda AI nástroj soubor uchoval, nebo zda musí být informováni zákazníci.

V programu navrženém Clarysec vypadá sled událostí jinak.

Zaprvé je export z CRM označen jako Důvěrný, protože obsahuje osobní údaje a obchodní informace zákazníků. Zadruhé je exportní událost zaznamenána do logů. Zatřetí e-mailová brána detekuje důvěrnou přílohu směřující na osobní e-mailovou doménu a zablokuje ji, pokud neexistuje schválená výjimka. Začtvrté pokus o nahrání do neschválené cloudové služby spustí upozornění na používání cloudu. Zapáté je upozornění vytříděno podle postupu reakce na incidenty. Zašesté bezpečnostní tým určí, zda došlo ke skutečnému zpřístupnění, zda byla data šifrována, zda je poskytovatel zpracoval nebo uchoval, zda jsou splněna kritéria porušení zabezpečení podle GDPR a zda se uplatní prahové hodnoty incidentů podle NIS2 nebo DORA.

Politika protokolování a monitorování pro malé a střední podniky, sekce „Požadavky na správu a řízení“, kapitola 5.4.3, týmu přesně říká, co má být viditelné:

Logy přístupu: přístup k souborům (zejména u citlivých nebo osobních údajů), změny oprávnění, používání sdílených zdrojů Politika protokolování a monitorování pro malé a střední podniky

Toto ustanovení je krátké, ale rozhodující. Pokud nejsou protokolovány přístupy k souborům, změny oprávnění a používání sdílených zdrojů, vyšetřování DLP se mění v odhadování.

Podle NIS2 Article 23 vyžadují významné incidenty postupné hlášení: včasné varování do 24 hodin od okamžiku, kdy se o nich subjekt dozví, oznámení incidentu do 72 hodin a závěrečnou zprávu nejpozději jeden měsíc po oznámení incidentu. Podle DORA vyžadují Articles 17 to 19, aby finanční subjekty detekovaly, řídily, klasifikovaly, zaznamenávaly, eskalovaly a hlásily významné incidenty související s ICT. Klasifikace zahrnuje ztrátu dat ovlivňující dostupnost, autenticitu, integritu nebo důvěrnost spolu s dotčenými klienty, dobou trvání, geografickým rozsahem, kritičností a ekonomickým dopadem. Podle GDPR může neoprávněné zpřístupnění osobních údajů vyžadovat posouzení porušení zabezpečení a při splnění prahových hodnot oznámení.

Upozornění DLP proto není jen bezpečnostní událost. Může se stát posouzením porušení ochrany osobních údajů, pracovním postupem incidentu podle NIS2, klasifikací ICT incidentu podle DORA, spouštěčem oznámení zákazníkům a balíčkem auditních důkazů.

Opatření DLP pro GDPR Article 32

GDPR Article 32 se často převádí na seznam opatření: šifrování, důvěrnost, integrita, dostupnost, odolnost, testování a obnova. U DLP je klíčová ochrana v celém životním cyklu.

Osobní údaje se pohybují přes shromažďování, ukládání, používání, přenos, zpřístupnění, uchovávání a výmaz. GDPR Article 5 vyžaduje minimalizaci údajů, omezení účelu, omezení uložení, integritu, důvěrnost a odpovědnost. GDPR Article 6 vyžaduje právní základ a slučitelnost účelu. GDPR Article 9 vyžaduje přísnější ochranná opatření pro zvláštní kategorie osobních údajů.

DLP tyto povinnosti podporuje, pokud je propojeno s klasifikací dat, záznamy o zákonném zpracování a schválenými přenosovými cestami.

Clarysec Politika maskování dat a pseudonymizace pro malé a střední podniky, sekce „Účel“, kapitola 1.2, podporuje tento přístup založený na životním cyklu:

Tyto techniky jsou povinné tam, kde nejsou vyžadována produkční data, včetně vývoje, analytiky a scénářů služeb třetích stran, aby se snížilo riziko expozice, zneužití nebo porušení zabezpečení. Politika maskování dat a pseudonymizace pro malé a střední podniky

To je praktické opatření pro GDPR Article 32. Pokud vývojáři, analytici nebo dodavatelé nepotřebují produkční osobní údaje, DLP nemá být jedinou bariérou. Maskování a pseudonymizace snižují rozsah dopadu dříve, než se data vůbec začnou pohybovat.

Silná DLP matice sladěná s ochranou osobních údajů má mapovat typy osobních údajů na klasifikační štítky, právní základ, schválené systémy, schválené metody exportu, požadavky na šifrování, pravidla DLP, pravidla uchovávání a spouštěče incidentů. Tato matice se stává mostem mezi správou ochrany osobních údajů a bezpečnostním provozem.

Kybernetická hygiena podle NIS2 a DLP mimo tým ochrany soukromí

NIS2 mění diskusi o DLP, protože rámuje úniky jako součást kybernetické hygieny a odolnosti, nikoli pouze ochrany soukromí.

Article 20 vyžaduje, aby řídicí orgány základních a důležitých subjektů schvalovaly opatření k řízení kyberbezpečnostních rizik, dohlížely na jejich implementaci a absolvovaly školení v oblasti kybernetické bezpečnosti. Article 21 vyžaduje vhodná a přiměřená opatření napříč politikami, zvládáním incidentů, kontinuitou, dodavatelským řetězcem, bezpečným vývojem, testováním účinnosti, kybernetickou hygienou, školením, kryptografií, personální bezpečností, řízením přístupu a správou aktiv. Article 25 podporuje používání příslušných evropských a mezinárodních norem a technických specifikací.

DLP k těmto oblastem přispívá přímo:

Politika zabezpečení sítí pro malé a střední podniky, sekce „Cíle“, kapitola 3.4, výslovně stanoví cíl exfiltrace:

Zabránit šíření malwaru a exfiltraci dat přes síťové kanály Politika zabezpečení sítí pro malé a střední podniky

Pro NIS2 dává tento typ cíle auditorům přímou testovací cestu: ukažte filtrování odchozího provozu, monitorování DNS, proxy logy, upozornění z koncových zařízení, zablokované pokusy o nahrání a vyšetřovací tikety.

Zenith Blueprint, krok 23, přidává cloudově specifické opatření, které je nyní nezbytné pro digitální poskytovatele a poskytovatele ICT spadající pod NIS2:

Uveďte všechny cloudové služby, které se aktuálně používají (5.23), včetně známého shadow IT. Identifikujte, kdo je schválil a zda byla provedena náležitá péče. Vytvořte jednoduchý hodnoticí kontrolní seznam, který pokryje umístění dat, model přístupu, protokolování a šifrování. U budoucích služeb zajistěte, aby byl kontrolní seznam začleněn do procesu pořizování nebo onboardingu IT.

Mnoho organizací zde selhává. Mají rozsah ISMS a registr dodavatelů, ale nemají skutečný seznam SaaS nástrojů, v nichž zaměstnanci přesouvají regulovaná nebo zákaznická data. DLP bez cloud discovery je slepé.

Riziko ICT podle DORA: DLP pro finanční subjekty a poskytovatele

U finančních subjektů musí DLP zapadat do rámce řízení rizik v oblasti ICT podle DORA.

DORA Article 5 vyžaduje interní rámec správy a kontroly pro řízení rizik v oblasti ICT. Řídicí orgán zůstává odpovědný za rizika v oblasti ICT, politiky zachovávající dostupnost, autenticitu, integritu a důvěrnost dat, jasné role v oblasti ICT, strategii digitální provozní odolnosti, toleranci rizika v oblasti ICT, plány kontinuity a reakce/obnovy, plány auditů, zdroje, politiku třetích stran a kanály pro hlášení.

Article 6 vyžaduje dokumentovaný rámec řízení rizik v oblasti ICT zahrnující strategie, politiky, postupy, ICT protokoly a nástroje k ochraně informací a ICT aktiv. Article 9 se zabývá ochranou a prevencí. Articles 11 to 14 doplňují kontinuitu, reakci, obnovu, zálohování, obnovení, kontroly integrity dat, získané poznatky, školení povědomí a krizovou komunikaci.

DLP do tohoto rámce zapadá jako schopnost ochrany, detekce, reakce a testování.

DORA také činí riziko třetích stran nevyhnutelným. Articles 28 to 30 vyžadují řízení rizik třetích stran v oblasti ICT, registry smluv o ICT službách, předsmluvní náležitou péči, smluvní požadavky, práva na audit a kontrolu, práva na ukončení, strategie ukončení, popisy služeb, umístění zpracování a ukládání dat, přístup k datům, obnovu a vrácení, podporu při incidentech, spolupráci s orgány, bezpečnostní opatření a podmínky subdodávek.

U fintechu nebo banky nemůže DLP končit na hranici Microsoft 365 nebo Google Workspace. Musí zahrnovat zpracovatele plateb, poskytovatele ověření identity, CRM platformy, datové sklady, cloudovou infrastrukturu, outsourcovaná servisní pracoviště, poskytovatele řízených služeb a kritické SaaS integrace.

To je obzvlášť důležité tam, kde DORA působí jako sektorově specifický právní akt Unie pro překrývající se povinnosti podle NIS2. Opatření stále musí existovat. Cesta hlášení a dohledu se může lišit.

90minutový sprint DLP pravidla

Clarysec používá praktický sprint s klienty, kteří potřebují rychlý pokrok, aniž by předstírali, že celý program DLP lze vybudovat na jedné schůzce. Cílem je implementovat jedno vysoce hodnotné opatření DLP od politiky až po důkazy.

Krok 1: Vyberte jeden typ dat a jednu přenosovou trasu

Zvolte „osobní údaje zákazníků exportované z CRM a odeslané externě e-mailem“. Nezačínejte všemi repozitáři, zeměmi a typy dat.

Krok 2: Potvrďte klasifikaci a štítek

Použijte klasifikační politiku k potvrzení, že tento export je Důvěrný. U malých a středních podniků vyžaduje kapitola 6.3.3 šifrování, omezený přístup, výslovné schválení sdílení a bezpečné zničení. V podniku Politika klasifikace dat a označování podporuje blokování přenosu u nesprávně označených citlivých dat a automatizované ověření pomocí DLP a nástrojů pro vyhledávání dat.

Krok 3: Definujte povolený přenosový vzor

Povoleno: export z CRM odeslaný na schválenou zákaznickou doménu pomocí šifrovaného e-mailu nebo schválené platformy pro bezpečný přenos souborů, s obchodním odůvodněním.

Nepovoleno: osobní e-mail, veřejné odkazy pro sdílení souborů, neschválené AI nástroje a nespravovaná cloudová úložiště.

To je v souladu se Zenith Blueprint, krok 22, který uvádí:

Pokud „Důvěrné“ informace nesmí opustit společnost bez šifrování, musí e-mailové systémy vynucovat politiky šifrování nebo blokovat externí přenos.

Krok 4: Nakonfigurujte minimální pravidlo DLP

Nakonfigurujte e-mailovou nebo kolaborační platformu tak, aby detekovala důvěrný štítek, vzor osobních údajů nebo konvenci pojmenování exportního souboru. Pokud se očekávají falešně pozitivní výsledky, začněte monitorováním a poté přejděte k blokování osobních domén a neschválených příjemců.

Krok 5: Zapněte protokolování a směrování upozornění

Zajistěte, aby logy zachycovaly přístup k souborům, změny oprávnění a používání sdílených zdrojů, jak vyžaduje Politika protokolování a monitorování pro malé a střední podniky. Směrujte upozornění do fronty tiketů se závažností, typem dat, odesílatelem, příjemcem, názvem souboru, provedenou akcí a přezkoumávající osobou.

Krok 6: Otestujte tři scénáře

Otestujte schválený šifrovaný přenos zákazníkovi, zablokovaný přenos na osobní e-mail a pokus o nahrání do neschválené cloudové domény pouze s upozorněním.

Krok 7: Uchovejte důkazy

Uložte odkaz na ustanovení politiky, snímek obrazovky pravidla DLP, výsledky testů, tiket upozornění, rozhodnutí přezkoumávající osoby a schválení vedením. Přidejte opatření do plánu ošetření rizik a Prohlášení o použitelnosti.

V pojmech ISO/IEC 27001:2022 toto cvičení propojuje Clause 6.1.2 posouzení rizik, Clause 6.1.3 ošetření rizik, Clause 8 operativní plánování a řízení, Annex A přenos informací, prevenci úniku dat, protokolování, monitorování, opatření pro dodavatele a cloud a Clause 9 hodnocení výkonnosti.

Mapování napříč souladem: jeden program DLP, více povinností

Síla přístupu Clarysec spočívá v tom, že se vyhýbá budování samostatných sad opatření pro GDPR, NIS2, DORA, NIST a COBIT. Jeden dobře navržený program DLP může splnit více očekávání, pokud jsou důkazy správně strukturovány.

NIST CSF 2.0 je užitečný jako komunikační vrstva. Jeho funkce GOVERN podporuje sledování právních, regulatorních a smluvních požadavků, ochoty podstupovat riziko, uplatňování politiky, rolí a dohledu. Metoda Profiles pomáhá organizacím vymezit aktuální a cílový stav, dokumentovat mezery a implementovat akční plán. Funkce RESPOND a RECOVER podporují zamezení šíření DLP incidentu, analýzu kořenové příčiny, uchování důkazů a obnovu.

COBIT 2019 přidává pohled správy a řízení. Auditor orientovaný na COBIT se zeptá, zda jsou cíle DLP sladěny s cíli podniku, zda je jasné vlastnictví, zda existují ukazatele výkonnosti, zda je definována ochota podstupovat riziko a zda vedení dostává smysluplné reportování.

Jak budou auditoři testovat váš program DLP

Audity DLP zřídka stojí na jednom snímku obrazovky. Různá auditní východiska vytvářejí různá očekávání na důkazy.

Silný auditní balíček DLP obsahuje prohlášení o rozsahu a riziku, schéma klasifikace, schválené metody přenosu, pravidla DLP, schválení výjimek, návrh protokolování, postup třídění upozornění, rozhodovací strom hlášení incidentů, evidenci dodavatelů a cloudu, výsledky testů a záznamy nápravy.

Běžná selhání DLP v roce 2026

Nejčastější selhání DLP jsou provozní, nikoli exotická.

Za prvé, klasifikace je volitelná nebo nekonzistentní. Štítky existují v politice, ale uživatelé je nepoužívají, systémy je nevynucují a repozitáře obsahují roky neoznačených citlivých souborů.

Za druhé, DLP je trvale nasazeno pouze v režimu upozornění. Tento režim je užitečný během ladění, ale vysoce rizikový přenos důvěrných zákaznických dat na osobní e-mail má být nakonec zablokován, pokud neexistuje schválená výjimka.

Za třetí, shadow IT je považováno za provozní potíž IT, nikoli za riziko ochrany údajů. Politika používání cloudových služeb a Politika používání cloudových služeb pro malé a střední podniky jsou navrženy tak, aby neschválené cloudové nástroje byly viditelné, přezkoumatelné a napravitelné.

Za čtvrté, logy nejsou dostatečné pro vyšetřování. Pokud bezpečnostní tým nedokáže zrekonstruovat, kdo přistoupil, sdílel, stáhl, nahrál nebo změnil oprávnění, organizace nemůže spolehlivě posoudit oznamovací povinnosti podle GDPR, NIS2 nebo DORA.

Za páté, dodavatelé stojí mimo model DLP. DORA Articles 28 to 30 z toho činí obzvlášť nebezpečný problém pro finanční subjekty, ale týká se všech sektorů. Smlouvy mají definovat umístění dat, přístup, obnovu, vrácení, podporu při incidentech, bezpečnostní opatření, subdodávky a práva na audit.

Za šesté, reakce na incidenty nezahrnuje scénáře DLP. Nesprávně adresovaný e-mail, neoprávněné nahrání do SaaS nebo hromadný export z CRM mají mít playbook, kritéria závažnosti a rozhodovací cestu pro oznámení.

Nakonec organizace zapomínají na fyzické a lidské kanály. Zenith Blueprint připomíná, že DLP zahrnuje zásady čistého stolu, bezpečnou skartaci, uzamčené tiskové fronty, auditní logy tiskáren a povědomí zaměstnanců. Program DLP, který ignoruje papír, snímky obrazovky a rozhovory, je neúplný.

Vybudujte program DLP, kterému mohou auditoři důvěřovat

Pokud je váš program DLP v současnosti konfigurací nástroje, rok 2026 je časem, kdy jej převést na řízený systém opatření podložený důkazy.

Začněte třemi praktickými kroky:

1. Vyberte tři nejvýznamnější typy citlivých dat, například osobní údaje zákazníků, platební údaje a zdrojový kód.
2. Zmapujte, kudy se pohybují, včetně e-mailu, SaaS, cloudového úložiště, koncových zařízení, rozhraní API, dodavatelů a vývojových prostředí.
3. Vytvořte jedno vynutitelné pravidlo DLP pro každý typ dat, propojené s politikou, protokolováním, reakcí na incidenty a uchováváním důkazů.

Clarysec vám s tím může pomoci prostřednictvím Zenith Blueprint: 30krokový plán auditora Zenith Blueprint, Zenith Controls: Průvodce napříč souladem Zenith Controls a připravených přizpůsobitelných politik, jako jsou Politika klasifikace dat a označování Politika klasifikace dat a označování, Politika práce na dálku Politika práce na dálku, Politika používání cloudových služeb Politika používání cloudových služeb, Politika protokolování a monitorování pro malé a střední podniky Politika protokolování a monitorování pro malé a střední podniky a Politika mobilních zařízení a používání vlastních zařízení (BYOD) Politika mobilních zařízení a používání vlastních zařízení (BYOD).

Cílem není zastavit pohyb každého souboru. Cílem je, aby bezpečný pohyb byl výchozím stavem, rizikový pohyb byl viditelný, zakázaný pohyb byl blokován a každá výjimka byla odpovědně evidována.

Stáhněte si nástroje Clarysec, přezkoumejte svůj balíček důkazů k DLP a objednejte si posouzení připravenosti, abyste zjistili, zda vaše současná opatření obstojí při kontrole GDPR Article 32, očekáváních kybernetické hygieny podle NIS2 a přezkumu rizik v oblasti ICT podle DORA.