DLP v roku 2026: ISO 27001 pre GDPR, NIS2 a DORA

Začína sa to tabuľkou.

V pondelok o 08:17 exportuje manažér zákazníckej starostlivosti 14 000 firemných kontaktov z CRM, aby pripravil kampaň na obnovu zmlúv. O 08:24 je tabuľka priložená k e-mailu. O 08:26 je e-mail odoslaný na osobný účet Gmail, pretože zamestnanec chce pracovať počas cesty vlakom. O 08:31 je ten istý súbor nahraný do neschválenej AI služby na tvorbu poznámok s cieľom „vyčistiť duplicity“.

Na prvý pohľad to ešte nevyzerá ako porušenie ochrany osobných údajov. Neexistuje výkupná správa, malvérový beacon, kompromitovaný administrátorský účet ani verejný únik. Pre CISO, manažéra súladu a DPO však už vzniká zásadná otázka: dokáže organizácia preukázať, že tento pohyb údajov bol povolený, klasifikovaný, zalogovaný, šifrovaný, odôvodnený a reverzibilný?

Rovnaký scenár sa vo finančných službách odohráva každý týždeň. Vývojár sa pokúsi nahrať Q1_Investor_Projections_DRAFT.xlsx na osobné cloudové úložisko, pretože VPN je pomalá. Obchodný manažér exportuje zoznam zákazníkov do spotrebiteľskej aplikácie na spoluprácu. Analytik podpory vloží záznamy zákazníkov do neschváleného AI nástroja. V každom prípade môže byť zámerom pohodlie, nie škodlivé konanie, ale riziko je rovnaké. Citlivé údaje prekročili alebo takmer prekročili hranicu, ktorú organizácia nekontroluje.

Toto je moderný problém prevencie úniku údajov. DLP už nie je iba pravidlom e-mailovej brány alebo agentom na koncovom bode. V roku 2026 je účinná prevencia úniku údajov riadeným kontrolným systémom podloženým dôkazmi naprieč SaaS, cloudovým úložiskom, koncovými bodmi, mobilnými zariadeniami, dodávateľmi, rozhraniami API, vývojovými prostrediami, exportmi zo záloh, nástrojmi na spoluprácu a ľudskými skratkami.

GDPR Article 32 očakáva primerané technické a organizačné opatrenia na bezpečnosť spracúvania. NIS2 Article 21 očakáva rizikovo orientované opatrenia kybernetickej bezpečnosti vrátane kybernetickej hygieny, riadenia prístupu, správy aktív, bezpečnosti dodávateľského reťazca, riešenia incidentov, šifrovania a testovania účinnosti. DORA očakáva, že finančné subjekty budú riadiť riziká IKT prostredníctvom správy a riadenia, detekcie, reakcie, obnovy, testovania, dohľadu nad tretími stranami a auditovateľnosti. ISO/IEC 27001:2022 poskytuje základ systému manažérstva, vďaka ktorému možno tieto povinnosti prevádzkovo uplatniť, merať a auditovať.

Chybou mnohých organizácií je, že si kúpia nástroj DLP skôr, než definujú, čo znamená „únik“. Prístup Clarysec začína skôr: klasifikovať údaje, definovať povolené prenosy, uplatniť politiku, monitorovať výnimky, pripraviť dôkazy pre reakciu a prepojiť všetko s ISMS.

Ako uvádza Zenith Blueprint: 30-kroková cestovná mapa audítora vo fáze Kontroly v praxi, Step 19, Technologické kontrolné opatrenia I:

Prevencia úniku údajov je o zabránení neoprávnenému alebo náhodnému zverejneniu citlivých informácií, či už uniknú cez e-mail, cloudové nahrávanie, prenosné médiá alebo dokonca zabudnutý výtlačok. Control 8.12 rieši potrebu monitorovať, obmedzovať a reagovať na akékoľvek údaje, ktoré opustia dôveryhodné hranice organizácie, bez ohľadu na to, či ide o digitálny, fyzický alebo ľudským konaním spôsobený únik. Zenith Blueprint

Táto veta vystihuje podstatu DLP v roku 2026: monitorovať, obmedzovať a reagovať.

Prečo je DLP dnes otázkou súladu na úrovni riadiaceho orgánu

Riadiaci orgán sa zvyčajne nepýta, či regulárny výraz v DLP deteguje národné identifikačné čísla. Pýta sa, či organizácia dokáže chrániť dôveru zákazníkov, pokračovať v prevádzke, vyhnúť sa regulačnej expozícii a preukázať primeranú bezpečnosť, keď sa niečo pokazí.

Práve tu sa stretávajú GDPR, NIS2 a DORA.

GDPR sa široko vzťahuje na automatizované spracúvanie osobných údajov vrátane prevádzkovateľov a sprostredkovateľov usadených v EÚ, ako aj organizácií mimo EÚ, ktoré ponúkajú tovar alebo služby osobám v EÚ alebo monitorujú ich správanie. Osobné údaje definuje široko a zahŕňa operácie ako zber, uchovávanie, používanie, sprístupnenie, výmaz a zničenie. Neoprávnené sprístupnenie osobných údajov alebo neoprávnený prístup k nim môže predstavovať porušenie ochrany osobných údajov. GDPR Article 5 zároveň výslovne stanovuje zásadu zodpovednosti: organizácie musia nielen dodržiavať zásady, ako sú minimalizácia údajov, obmedzenie uchovávania, integrita a dôvernosť, ale musia vedieť preukázať súlad.

NIS2 rozširuje tlak nad rámec ochrany súkromia. Vzťahuje sa na mnohé základné a dôležité subjekty vrátane sektorov, ako sú bankovníctvo, infraštruktúry finančných trhov, poskytovatelia služieb cloud computingu, poskytovatelia služieb dátových centier, poskytovatelia riadených služieb, poskytovatelia riadených bezpečnostných služieb, online trhoviská, internetové vyhľadávače a platformy sociálnych sietí. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, politík bezpečnosti informačných systémov, riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, bezpečného vývoja, testovania účinnosti, kybernetickej hygieny, školení, kryptografie, riadenia prístupu, správy aktív a autentifikácie.

DORA sa uplatňuje od 17. januára 2025 a slúži ako sektorovo špecifický súbor pravidiel digitálnej prevádzkovej odolnosti pre finančný sektor. Pre finančné subjekty v rozsahu pôsobnosti sa považuje za sektorovo špecifický právny akt Únie na účely prekrývajúcich sa povinností podľa NIS2. DORA začleňuje DLP do riadenia rizík IKT, klasifikácie incidentov, straty údajov ovplyvňujúcej dostupnosť, autentickosť, integritu alebo dôvernosť, testovania digitálnej prevádzkovej odolnosti, riadenia externých poskytovateľov IKT a zmluvných kontrol.

Otázka DLP v roku 2026 neznie: „Máme nástroj?“ Znie:

1. Vieme, ktoré informácie sú citlivé?
2. Vieme, kde sa uchovávajú, spracúvajú a prenášajú?
3. Sú definované povolené a zakázané trasy prenosu?
4. Sú používatelia vyškolení a technicky obmedzení?
5. Sú cloudové a SaaS trasy riadené?
6. Sú logy dostatočné na vyšetrovanie?
7. Sú upozornenia rýchlo triedené a incidenty rýchlo klasifikované?
8. Sú dodávatelia a outsourcované služby IKT zmluvne viazaní?
9. Vieme preukázať, že kontroly fungujú?

ISO/IEC 27001:2022 je na zodpovedanie týchto otázok vhodná, pretože vyžaduje kontext, požiadavky zainteresovaných strán, posúdenie rizík, ošetrenie rizík, merateľné ciele, prevádzkové riadenie, zdokumentované dôkazy, kontrolu dodávateľov, interný audit, preskúmanie manažmentom a neustále zlepšovanie. Nie je to štandard DLP, ale mení DLP z izolovanej technologickej konfigurácie na riadený proces systému manažérstva.

Reťazec kontrol ISO 27001 za účinným DLP

Dôveryhodný program DLP nestojí na jednej kontrole. Stojí na reťazci kontrol.

Zenith Controls: The Cross-Compliance Guide od Clarysec mapuje kontrolu ISO/IEC 27002:2022 8.12, Prevencia úniku údajov, ako preventívnu a detekčnú kontrolu zameranú na dôvernosť, zosúladenú s konceptmi kybernetickej bezpečnosti Protect a Detect, pričom ochrana informácií je prevádzkovou schopnosťou a ochrana/obrana je bezpečnostnou doménou. Zenith Controls

Je to dôležité, pretože audítori očakávajú blokovanie aj viditeľnosť. Preventívne pravidlo DLP bez preskúmania upozornení je neúplné. Rovnako slabý je prístup založený iba na logovaní bez vynucovania kontrol pri vysokorizikových prenosoch.

Ten istý sprievodca mapuje kontrolu ISO/IEC 27002:2022 5.12, Klasifikácia informácií, ako preventívnu kontrolu podporujúcu dôvernosť, integritu a dostupnosť a zosúladenú s Identify. Kontrolu 5.14, Prenos informácií, mapuje ako preventívnu kontrolu podporujúcu dôvernosť, integritu a dostupnosť a zosúladenú s Protect, Asset Management a Information Protection.

V praxi vyzerá reťazec kontrol DLP takto:

Zenith Blueprint, Step 22, vysvetľuje závislosť medzi inventarizáciou aktív, klasifikáciou a DLP:

Preskúmajte aktuálnu evidenciu aktív (5.9), aby ste sa uistili, že zahŕňa fyzické aj logické aktíva, vlastníkov a klasifikácie. Prepojte túto evidenciu s klasifikačnou schémou (5.12) a zabezpečte, aby boli citlivé aktíva vhodne označené a chránené. V prípade potreby definujte uchovávanie, zálohovanie alebo izoláciu na základe klasifikácie.

Preto Clarysec zriedkavo začína projekt DLP ladením pravidiel. Začíname zosúladením aktív, vlastníkov, typov údajov, klasifikačných označení, trás prenosu a dôkazových záznamov. Ak organizácia nevie povedať, ktoré súbory údajov sú dôverné, regulované, vlastnené zákazníkom, súvisiace s platbami alebo kritické pre činnosť organizácie, nástroj DLP môže iba hádať.

Tri piliere moderného programu DLP

Moderný program DLP stojí na troch vzájomne sa posilňujúcich pilieroch: poznať údaje, riadiť tok a brániť hranicu. Tieto piliere robia ISO/IEC 27001:2022 prakticky použiteľnou pre súlad s GDPR, NIS2 a DORA.

Pilier 1: Poznajte svoje údaje pomocou klasifikácie a označovania

Nemôžete chrániť to, čomu nerozumiete. Kontroly ISO/IEC 27002:2022 5.12 a 5.13 vyžadujú, aby organizácie klasifikovali informácie a označovali ich podľa citlivosti a požiadaviek na zaobchádzanie. Nie je to administratívne cvičenie. Je to základ automatizovaného vynucovania kontrol.

Pre MSP uvádza Politika klasifikácie a označovania údajov:

Dôverné: Vyžaduje šifrovanie pri prenose aj v pokoji, obmedzený prístup, výslovné schválenie zdieľania a bezpečné zničenie pri likvidácii. Data Classification and Labeling Policy - SME

Tento citát zo sekcie „Požiadavky na implementáciu politiky“, bod 6.3.3, dáva programu DLP štyri vynútiteľné podmienky: šifrovanie, obmedzený prístup, schválenie zdieľania a bezpečnú likvidáciu.

V podnikových prostrediach je Politika klasifikácie a označovania údajov ešte priamejšia. Zo sekcie „Požiadavky na implementáciu politiky“, bod 6.2.6.2:

Blokovanie prenosu (napr. externého e-mailu) pri nesprávne označených citlivých údajoch Data Classification and Labeling Policy

A zo sekcie „Vynucovanie politiky a súlad“, bod 8.3.2:

Automatizované overovanie klasifikácie pomocou Data Loss Prevention (DLP) a nástrojov na vyhľadávanie údajov

Tieto ustanovenia menia klasifikáciu na kontrolu. Súbor označený ako Dôverné môže spustiť šifrovanie, zablokovať externý prenos, vyžadovať schválenie alebo vygenerovať bezpečnostné upozornenie. DLP sa potom stáva vrstvou vynucovania politiky, ktorej rozumejú používatelia, systémy aj audítori.

Pilier 2: Riaďte tok pomocou bezpečného prenosu informácií

Po klasifikácii údajov musí organizácia riadiť ich pohyb. Kontrola ISO/IEC 27002:2022 5.14, Prenos informácií, sa často prehliada, ale práve tu sa začína mnoho zlyhaní DLP.

Zenith Blueprint rámcuje kontrolu 5.14 ako potrebu riadiť tok informácií tak, aby bol prenos bezpečný, úmyselný a v súlade s klasifikáciou a účelom organizácie. Platí to pre e-mail, bezpečné zdieľanie súborov, rozhrania API, integrácie SaaS, prenosné médiá, tlačené reporty a portály dodávateľov.

Práca na diaľku robí túto oblasť mimoriadne dôležitou. Politika práce na diaľku, sekcia „Požiadavky na implementáciu politiky“, bod 6.3.1.3, vyžaduje od zamestnancov:

Používať iba schválené riešenia na zdieľanie súborov (napr. M365, Google Workspace s kontrolami prevencie úniku údajov (DLP)) Remote Work Policy

Pre mobilné zariadenia a BYOD poskytuje Politika mobilných zariadení a používania vlastných zariadení (BYOD), sekcia „Požiadavky na implementáciu politiky“, bod 6.6.4, konkrétne vynucovanie na koncových bodoch:

Politiky prevencie úniku údajov (DLP) musia blokovať neoprávnené nahrávania, vytváranie snímok obrazovky, prístup do schránky alebo zdieľanie údajov zo spravovaných aplikácií do osobných priestorov. Mobile device and byod policy

Je to dôležité, pretože údaje neodchádzajú iba cez e-mail. Odchádzajú cez snímky obrazovky, synchronizáciu schránky, nespravované profily prehliadača, osobné úložiská, mobilné ponuky zdieľania, pluginy na spoluprácu a AI nástroje.

Rovnako dôležitá je správa a riadenie cloudu. V MSP Cloud Usage Policy-sme, sekcia „Požiadavky na správu a riadenie“, bod 5.5:

Shadow IT, definované ako používanie neschválených cloudových nástrojov, sa musí považovať za porušenie politiky a musí ho preskúmať GM a poskytovateľ IT služieb s cieľom určiť riziko a potrebné nápravné opatrenia. Cloud Usage Policy-sme - SME

Pre podnikové organizácie Politika používania cloudových služieb, sekcia „Požiadavky na správu a riadenie“, bod 5.5, zvyšuje latku monitorovania:

Tím informačnej bezpečnosti musí pravidelne posudzovať sieťovú prevádzku, aktivitu DNS a logy s cieľom detegovať neoprávnené používanie cloudu (shadow IT). Zistené porušenia musia byť bezodkladne vyšetrené. Cloud Usage Policy

Shadow IT nie je iba prevádzková nepríjemnosť pre IT. Podľa GDPR sa môže stať nezákonným sprístupnením alebo nekontrolovaným spracúvaním. Podľa NIS2 je slabinou kybernetickej hygieny a dodávateľského reťazca. Podľa DORA sa môže stať rizikom externého poskytovateľa IKT a otázkou klasifikácie incidentu.

Pilier 3: Bráňte hranicu technológiou DLP, politikou a povedomím

Kontrola ISO/IEC 27002:2022 8.12, Prevencia úniku údajov, je kontrola, ktorú si väčšina ľudí spája s DLP. V zrelom programe je však poslednou líniou obrany, nie prvou.

Zenith Blueprint vysvetľuje, že DLP vyžaduje trojvrstvový prístup: technológiu, politiku a povedomie. Technológia zahŕňa endpoint DLP, bezpečnosť elektronickej pošty, kontrolu obsahu, bezpečnosť cloudového prístupu, kontroly SaaS, kontroly prehliadača, filtrovanie odchádzajúcej sieťovej prevádzky a smerovanie upozornení. Politika definuje, čo nástroje vynucujú. Povedomie zabezpečuje, aby zamestnanci rozumeli, prečo osobný e-mail, spotrebiteľské cloudové úložisko a neschválené AI nástroje nie sú prípustnými spôsobmi zaobchádzania s regulovanými alebo dôvernými informáciami.

Zložka reakcie je rovnako dôležitá ako prevencia. Zenith Blueprint, Step 19, uvádza:

DLP však nie je iba prevencia, je to aj reakcia. Ak sa zistí potenciálny únik:

✓ Upozornenia by sa mali rýchlo triediť, ✓ Logovanie by malo podporovať forenznú analýzu, ✓ Plán reakcie na incidenty sa musí spustiť bezodkladne.

Program DLP, ktorý blokuje udalosti, ale netriedi ich, nevyšetruje a nepoučí sa z nich, nie je pripravený na audit. Je iba čiastočne nasadený.

Od úniku tabuľky po reakciu pripravenú na audit

Vráťme sa k pondelkovej rannej tabuľke.

V slabom programe organizácia objaví nahratie o tri týždne neskôr počas preskúmania ochrany súkromia. Nikto nevie, kto schválil export, či išlo o osobné údaje, či boli zahrnuté osobitné kategórie údajov, či si AI nástroj súbor ponechal alebo či musia byť informovaní zákazníci.

V programe navrhnutom spoločnosťou Clarysec vyzerá postup inak.

Po prvé, export z CRM je označený ako Dôverné, pretože obsahuje osobné údaje a obchodné informácie zákazníkov. Po druhé, udalosť exportu je zalogovaná. Po tretie, e-mailová brána zistí dôvernú prílohu smerujúcu na osobnú e-mailovú doménu a zablokuje ju, pokiaľ neexistuje schválená výnimka. Po štvrté, pokus o nahratie do neschválenej cloudovej služby spustí upozornenie na používanie cloudových služieb. Po piate, upozornenie sa triedi podľa postupu reakcie na incidenty. Po šieste, bezpečnostný tím určí, či došlo k skutočnému sprístupneniu, či boli údaje šifrované, či ich poskytovateľ spracúval alebo uchoval, či sú splnené kritériá porušenia ochrany osobných údajov podľa GDPR a či sa uplatňujú prahové hodnoty incidentov podľa NIS2 alebo DORA.

MSP Politika logovania a monitorovania, sekcia „Požiadavky na správu a riadenie“, bod 5.4.3, tímu presne hovorí, čo má byť viditeľné:

Prístupové logy: prístup k súborom (najmä k citlivým alebo osobným údajom), zmeny oprávnení, používanie zdieľaných zdrojov Logging and Monitoring Policy - SME

Tento bod je krátky, ale rozhodujúci. Ak sa prístup k súborom, zmeny oprávnení a používanie zdieľaných zdrojov nelogujú, vyšetrovanie DLP sa mení na odhadovanie.

Podľa NIS2 Article 23 si významné incidenty vyžadujú postupné hlásenie: včasné varovanie do 24 hodín od získania vedomosti, oznámenie incidentu do 72 hodín a záverečnú správu najneskôr jeden mesiac po oznámení incidentu. Podľa DORA Articles 17 až 19 musia finančné subjekty detegovať, riadiť, klasifikovať, zaznamenávať, eskalovať a hlásiť závažné incidenty súvisiace s IKT. Klasifikácia zahŕňa stratu údajov ovplyvňujúcu dostupnosť, autentickosť, integritu alebo dôvernosť spolu s dotknutými klientmi, trvaním, geografickým rozsahom, kritickosťou a ekonomickým dopadom. Podľa GDPR môže neoprávnené sprístupnenie osobných údajov vyžadovať posúdenie porušenia ochrany údajov a pri splnení prahových hodnôt aj oznámenie.

Upozornenie DLP teda nie je iba bezpečnostná udalosť. Môže sa stať posúdením porušenia ochrany súkromia, pracovným tokom incidentu podľa NIS2, klasifikáciou incidentu IKT podľa DORA, spúšťačom oznámenia zákazníkovi a balíkom auditných dôkazov.

Kontroly DLP pre GDPR Article 32

GDPR Article 32 sa často prevádza do zoznamu opatrení: šifrovanie, dôvernosť, integrita, dostupnosť, odolnosť, testovanie a obnova. Pre DLP je kľúčová ochrana počas celého životného cyklu.

Osobné údaje sa pohybujú cez zber, uchovávanie, používanie, prenos, sprístupnenie, uchovávanie a výmaz. GDPR Article 5 vyžaduje minimalizáciu údajov, obmedzenie účelu, obmedzenie uchovávania, integritu, dôvernosť a zásadu zodpovednosti. GDPR Article 6 vyžaduje právny základ a zlučiteľnosť účelu. GDPR Article 9 požaduje prísnejšie ochranné opatrenia pre osobitné kategórie osobných údajov.

DLP podporuje tieto povinnosti vtedy, keď je prepojené s klasifikáciou údajov, záznamami o zákonnom spracúvaní a schválenými trasami prenosu.

Data Masking and Pseudonymization Policy-sme od Clarysec, sekcia „Účel“, bod 1.2, podporuje tento prístup životného cyklu:

Tieto techniky sú povinné tam, kde sa nevyžadujú živé údaje, vrátane vývoja, analytiky a scenárov služieb tretích strán, s cieľom znížiť riziko sprístupnenia, zneužitia alebo porušenia ochrany údajov. Data Masking and Pseudonymization Policy-sme - SME

Ide o praktickú kontrolu GDPR Article 32. Ak vývojári, analytici alebo dodávatelia nepotrebujú živé osobné údaje, DLP by nemalo byť jedinou bariérou. Maskovanie a pseudonymizácia znižujú rozsah dopadu ešte predtým, ako sa údaje pohnú.

Silná matica DLP zosúladená s ochranou súkromia by mala mapovať typy osobných údajov na klasifikačné označenia, právny základ, schválené systémy, schválené metódy exportu, požiadavky na šifrovanie, pravidlá DLP, pravidlá uchovávania a spúšťače incidentov. Táto matica sa stáva mostom medzi správou ochrany súkromia a bezpečnostnou prevádzkou.

Kybernetická hygiena podľa NIS2 a DLP mimo tímu ochrany súkromia

NIS2 mení diskusiu o DLP, pretože únik rámcuje ako súčasť kybernetickej hygieny a odolnosti, nielen ochrany súkromia.

Article 20 vyžaduje, aby riadiace orgány základných a dôležitých subjektov schvaľovali opatrenia riadenia rizík kybernetickej bezpečnosti, dohliadali na ich implementáciu a absolvovali školenie v oblasti kybernetickej bezpečnosti. Article 21 vyžaduje primerané a proporcionálne opatrenia v oblasti politík, riešenia incidentov, kontinuity, dodávateľského reťazca, bezpečného vývoja, testovania účinnosti, kybernetickej hygieny, školení, kryptografie, bezpečnosti ľudských zdrojov, riadenia prístupu a správy aktív. Article 25 podporuje používanie relevantných európskych a medzinárodných noriem a technických špecifikácií.

DLP priamo prispieva k týmto oblastiam:

Network Security Policy-sme, sekcia „Ciele“, bod 3.4, výslovne stanovuje cieľ exfiltrácie:

Zabrániť šíreniu malvéru a exfiltrácii údajov prostredníctvom sieťových kanálov Network Security Policy-sme - SME

Pre NIS2 dáva tento typ cieľa audítorom priamu testovaciu cestu: ukážte filtrovanie odchádzajúcej prevádzky, monitorovanie DNS, proxy logy, upozornenia z koncových bodov, zablokované pokusy o nahratie a vyšetrovacie tickety.

Zenith Blueprint, Step 23, pridáva cloudovo špecifické opatrenie, ktoré je dnes nevyhnutné pre digitálnych a IKT poskytovateľov spadajúcich pod NIS2:

Uveďte všetky cloudové služby, ktoré sa aktuálne používajú (5.23), vrátane známeho shadow IT. Identifikujte, kto ich schválil a či bola vykonaná náležitá starostlivosť. Vypracujte jednoduchý hodnotiaci kontrolný zoznam, ktorý pokrýva lokalizáciu údajov, prístupový model, logovanie a šifrovanie. Pri budúcich službách zabezpečte, aby bol kontrolný zoznam integrovaný do procesu obstarávania alebo IT onboardingu.

Mnohé organizácie tu zlyhávajú. Majú rozsah ISMS a register dodávateľov, ale nie skutočný zoznam nástrojov SaaS, cez ktoré zamestnanci presúvajú regulované alebo zákaznícke údaje. DLP bez zisťovania používania cloudu je slepé.

Riziko IKT podľa DORA: DLP pre finančné subjekty a poskytovateľov

Pre finančné subjekty musí DLP zapadať do rámca riadenia rizík IKT podľa DORA.

DORA Article 5 vyžaduje interný rámec správy, riadenia a kontrol na riadenie rizík IKT. Riadiaci orgán zostáva zodpovedný za riziko IKT, politiky zachovávajúce dostupnosť, autentickosť, integritu a dôvernosť údajov, jasné roly IKT, stratégiu digitálnej prevádzkovej odolnosti, toleranciu rizika IKT, plány kontinuity a reakcie/obnovy, plány auditov, zdroje, politiku tretích strán a oznamovacie kanály.

Article 6 vyžaduje zdokumentovaný rámec riadenia rizík IKT zahŕňajúci stratégie, politiky, postupy, protokoly IKT a nástroje na ochranu informácií a aktív IKT. Article 9 sa zaoberá ochranou a prevenciou. Articles 11 až 14 pridávajú kontinuitu, reakciu, obnovu, zálohovanie, rekonštrukciu, kontroly integrity údajov, získané poučenia, školenia povedomia a krízovú komunikáciu.

DLP do tohto rámca zapadá ako schopnosť ochrany, detekcie, reakcie a testovania.

DORA zároveň robí riziko tretích strán nevyhnutným. Articles 28 až 30 vyžadujú riadenie rizík externých poskytovateľov IKT, registre zmlúv o službách IKT, predzmluvnú náležitú starostlivosť, zmluvné požiadavky, práva na audit a kontrolu, práva na ukončenie, stratégie ukončenia, opisy služieb, miesta spracúvania a uchovávania údajov, prístup k údajom, obnovu a vrátenie, pomoc pri incidentoch, spoluprácu s orgánmi, bezpečnostné opatrenia a podmienky subdodávok.

Pre fintech alebo banku sa DLP nemôže zastaviť na hranici Microsoft 365 alebo Google Workspace. Musí pokrývať spracovateľov platieb, poskytovateľov overovania identity, platformy CRM, dátové sklady, cloudovú infraštruktúru, outsourcované tímy podpory, poskytovateľov riadených služieb a kritické integrácie SaaS.

Je to mimoriadne dôležité tam, kde DORA slúži ako sektorovo špecifický právny akt Únie pre prekrývajúce sa povinnosti podľa NIS2. Kontroly musia stále existovať. Líšiť sa môže trasa hlásenia a dohľadu.

90-minútový sprint pravidla DLP

Clarysec používa praktický sprint s klientmi, ktorí potrebujú rýchly pokrok bez predstierania, že úplný program DLP možno vybudovať na jednom stretnutí. Cieľom je implementovať jednu vysokohodnotnú kontrolu DLP od politiky až po dôkazy.

Krok 1: Vyberte jeden typ údajov a jednu trasu prenosu

Vyberte „osobné údaje zákazníkov exportované z CRM a odoslané externe e-mailom“. Nezačínajte všetkými úložiskami, krajinami a typmi údajov.

Krok 2: Potvrďte klasifikáciu a označenie

Použite politiku klasifikácie na potvrdenie, že tento export je Dôverný. V MSP bod 6.3.3 vyžaduje šifrovanie, obmedzený prístup, výslovné schválenie zdieľania a bezpečné zničenie. V podnikovom prostredí Politika klasifikácie a označovania údajov podporuje blokovanie prenosu nesprávne označených citlivých údajov a automatizované overovanie pomocou DLP a nástrojov na vyhľadávanie údajov.

Krok 3: Definujte povolený vzor prenosu

Povolené: export z CRM odoslaný na schválenú zákaznícku doménu pomocou šifrovaného e-mailu alebo schválenej platformy na bezpečný prenos súborov s obchodným odôvodnením.

Nepovolené: osobný e-mail, verejné odkazy na zdieľanie súborov, neschválené AI nástroje a nespravované cloudové úložiská.

To je v súlade so Zenith Blueprint, Step 22, kde sa uvádza:

Ak informácie klasifikované ako „Dôverné“ nesmú opustiť spoločnosť bez šifrovania, e-mailové systémy musia vynucovať politiky šifrovania alebo blokovať externý prenos.

Krok 4: Nakonfigurujte minimálne pravidlo DLP

Nakonfigurujte e-mailovú platformu alebo platformu na spoluprácu tak, aby detegovala dôverné označenie, vzor osobných údajov alebo konvenciu pomenovania exportného súboru. Ak sa očakávajú falošné pozitíva, začnite monitorovaním, potom prejdite na blokovanie pri osobných doménach a neschválených príjemcoch.

Krok 5: Zapnite logovanie a smerovanie upozornení

Zabezpečte, aby logy zachytávali prístup k súborom, zmeny oprávnení a používanie zdieľaných zdrojov, ako vyžaduje Logging and Monitoring Policy - SME. Smerujte upozornenia do tiketovacieho frontu so závažnosťou, typom údajov, odosielateľom, príjemcom, názvom súboru, vykonanou akciou a preskúmavateľom.

Krok 6: Otestujte tri scenáre

Otestujte schválený šifrovaný prenos zákazníkovi, zablokovaný prenos na osobný e-mail a pokus o nahratie do neschválenej cloudovej domény iba s upozornením.

Krok 7: Uchovajte dôkazy

Uložte odkaz na bod politiky, snímku obrazovky pravidla DLP, výsledky testov, ticket upozornenia, rozhodnutie preskúmavateľa a schválenie manažmentom. Pridajte kontrolu do plánu ošetrenia rizík a Vyhlásenia o uplatniteľnosti.

V terminológii ISO/IEC 27001:2022 toto cvičenie prepája Clause 6.1.2 posúdenie rizík, Clause 6.1.3 ošetrenie rizík, Clause 8 prevádzkové plánovanie a riadenie, Annex A prenos informácií, prevenciu úniku údajov, logovanie, monitorovanie, kontroly dodávateľov a cloudu a Clause 9 hodnotenie výkonnosti.

Mapovanie naprieč rámcami súladu: jeden program DLP, viacero povinností

Silou prístupu Clarysec je, že sa vyhýba budovaniu samostatných kontrolných vrstiev pre GDPR, NIS2, DORA, NIST a COBIT. Jeden dobre navrhnutý program DLP môže splniť viaceré očakávania, ak sú dôkazy správne štruktúrované.

NIST CSF 2.0 je užitočný ako komunikačná vrstva. Jeho funkcia GOVERN podporuje sledovanie právnych, regulačných a zmluvných požiadaviek, apetítu na riziko, uplatňovania politík, rolí a dohľadu. Metóda Profiles pomáha organizáciám vymedziť aktuálny a cieľový stav, zdokumentovať medzery a implementovať akčný plán. Funkcie RESPOND a RECOVER podporujú zamedzenie incidentov DLP, analýzu koreňovej príčiny, uchovanie dôkazov a obnovu.

COBIT 2019 pridáva pohľad správy a riadenia. Audítor orientovaný na COBIT sa bude pýtať, či sú ciele DLP zosúladené s cieľmi organizácie, či je vlastníctvo jasné, či existujú ukazovatele výkonnosti, či je definovaný apetít na riziko a či manažment dostáva zmysluplné reportovanie.

Ako budú audítori testovať váš program DLP

Audity DLP sa zriedkavo týkajú jednej snímky obrazovky. Rôzne audítorské pozadia vytvárajú rôzne očakávania voči dôkazom.

Silný auditný balík DLP zahŕňa vyhlásenie o rozsahu a riziku, klasifikačnú schému, schválené metódy prenosu, pravidlá DLP, schválenia výnimiek, návrh logovania, postup triáže upozornení, rozhodovací strom hlásenia incidentov, inventár dodávateľov a cloudu, výsledky testov a záznamy nápravy.

Bežné zlyhania DLP v roku 2026

Najčastejšie zlyhania DLP sú prevádzkové, nie exotické.

Po prvé, klasifikácia je voliteľná alebo nekonzistentná. Označenia existujú v politike, ale používatelia ich neuplatňujú, systémy ich nevynucujú a úložiská obsahujú roky neoznačených citlivých súborov.

Po druhé, DLP je navždy nasadené v režime iba upozornení. Režim iba upozornení je užitočný počas ladenia, ale vysokorizikový prenos dôverných zákazníckych údajov na osobný e-mail sa má napokon blokovať, pokiaľ neexistuje schválená výnimka.

Po tretie, shadow IT sa považuje za nepríjemnosť pre IT namiesto rizika ochrany údajov. Politika používania cloudových služieb a Cloud Usage Policy-sme sú navrhnuté tak, aby neschválené cloudové nástroje boli viditeľné, preskúmateľné a napraviteľné.

Po štvrté, logy nie sú dostatočné na vyšetrovanie. Ak bezpečnostný tím nedokáže zrekonštruovať, kto pristúpil, zdieľal, stiahol, nahral alebo zmenil oprávnenia, organizácia nedokáže spoľahlivo posúdiť oznamovacie povinnosti podľa GDPR, NIS2 alebo DORA.

Po piate, dodávatelia sú mimo modelu DLP. DORA Articles 28 až 30 to robia mimoriadne nebezpečným pre finančné subjekty, ale problém sa týka každého sektora. Zmluvy by mali definovať lokalizáciu údajov, prístup, obnovu, vrátenie, pomoc pri incidentoch, bezpečnostné opatrenia, subdodávky a práva na audit.

Po šieste, reakcia na incidenty nezahŕňa scenáre DLP. Nesprávne adresovaný e-mail, neoprávnené nahratie do SaaS alebo hromadný export z CRM by mali mať playbook, kritériá závažnosti a rozhodovaciu cestu oznámenia.

Napokon, organizácie zabúdajú na fyzické a ľudské kanály. Zenith Blueprint pripomína, že DLP zahŕňa správanie podľa politiky čistého stola, bezpečnú skartáciu, uzamknuté tlačové fronty, auditné logy tlačiarní a povedomie zamestnancov. Program DLP, ktorý ignoruje papier, snímky obrazovky a rozhovory, je neúplný.

Vybudujte program DLP, ktorému audítori dôverujú

Ak je váš program DLP v súčasnosti konfiguráciou nástroja, rok 2026 je časom premeniť ho na riadený kontrolný systém podložený dôkazmi.

Začnite tromi praktickými krokmi:

1. Vyberte tri najcitlivejšie typy údajov, napríklad osobné údaje zákazníkov, platobné údaje a zdrojový kód.
2. Zmapujte, kadiaľ sa pohybujú, vrátane e-mailu, SaaS, cloudového úložiska, koncových bodov, rozhraní API, dodávateľov a vývojových prostredí.
3. Vybudujte jedno vynútiteľné pravidlo DLP pre každý typ údajov, prepojené s politikou, logovaním, reakciou na incidenty a uchovávaním dôkazov.

Clarysec vám môže pomôcť zrýchliť tento proces prostredníctvom Zenith Blueprint: 30-kroková cestovná mapa audítora Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls a politík pripravených na prispôsobenie, ako sú Politika klasifikácie a označovania údajov Data Classification and Labeling Policy, Politika práce na diaľku Remote Work Policy, Politika používania cloudových služieb Cloud Usage Policy, Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME a Politika mobilných zariadení a používania vlastných zariadení (BYOD) Mobile device and byod policy.

Cieľom nie je zastaviť pohyb každého súboru. Cieľom je, aby bol bezpečný pohyb predvolený, rizikový pohyb viditeľný, zakázaný pohyb blokovaný a každá výnimka preukázateľne zodpovedná.

Stiahnite si nástroje Clarysec, preskúmajte svoj balík dôkazov DLP a objednajte si posúdenie pripravenosti, aby ste zistili, či vaše aktuálne kontroly obstáli pri preskúmaní podľa GDPR Article 32, očakávaniach kybernetickej hygieny podľa NIS2 a preskúmaní rizík IKT podľa DORA.