DLP u 2026.: ISO 27001 za GDPR, NIS2 i DORA

Počinje proračunskom tablicom.
U ponedjeljak u 08:17 voditelj korisničkog uspjeha izvozi 14.000 kontakata poslovnih korisnika iz CRM-a radi pripreme kampanje obnove ugovora. U 08:24 proračunska tablica prilaže se e-poruci. U 08:26 e-poruka se šalje na osobni Gmail račun jer zaposlenik želi raditi tijekom putovanja vlakom. U 08:31 ista se datoteka učitava u neodobrenu AI uslugu za bilješke radi „čišćenja duplikata”.
Ništa još ne izgleda kao povreda. Nema poruke ransomwarea, nema signalizacije zlonamjernog softvera, nema kompromitiranog administratorskog računa i nema javnog curenja. No za CISO-a, voditelja usklađenosti i službenika za zaštitu podataka (DPO) ključno pitanje već postoji: može li organizacija dokazati da je ovo kretanje podataka bilo dopušteno, klasificirano, evidentirano u dnevniku, šifrirano, opravdano i reverzibilno?
Isti se scenarij svakog tjedna događa u financijskim uslugama. Razvojni inženjer pokušava učitati Q1_Investor_Projections_DRAFT.xlsx na osobni disk u oblaku jer je VPN spor. Voditelj prodaje izvozi popis korisnika u potrošačku aplikaciju za suradnju. Analitičar podrške lijepi evidencije klijenata u neodobreni AI alat. U svakom slučaju namjera može biti praktičnost, a ne zlonamjernost, ali rizik je isti. Osjetljivi podaci prešli su, ili su gotovo prešli, granicu koju organizacija ne kontrolira.
To je suvremeni problem sprječavanja gubitka podataka. DLP više nije samo pravilo na pristupniku e-pošte ili agent na krajnjem uređaju. U 2026. učinkovito sprječavanje gubitka podataka znači upravljan kontrolni sustav potkrijepljen dokazima, koji obuhvaća SaaS, pohranu u oblaku, krajnje uređaje, mobilne uređaje, dobavljače, API-je, razvojna okruženja, izvoze sigurnosnih kopija, alate za suradnju i ljudske prečace.
GDPR Article 32 očekuje odgovarajuće tehničke i organizacijske mjere za sigurnost obrade. NIS2 Article 21 očekuje mjere kibernetičke sigurnosti temeljene na riziku, uključujući kibernetičku higijenu, kontrolu pristupa, upravljanje imovinom, sigurnost opskrbnog lanca, postupanje s incidentima, šifriranje i testiranje učinkovitosti. DORA očekuje da financijski subjekti upravljaju IKT rizikom kroz upravljanje, otkrivanje, odgovor, oporavak, testiranje, nadzor nad trećim stranama i revizibilnost. ISO/IEC 27001:2022 pruža okosnicu sustava upravljanja kojom se te obveze pretvaraju u operativne, mjerljive i revizijski provjerljive aktivnosti.
Pogreška koju mnoge organizacije čine jest kupnja DLP alata prije nego što definiraju što „gubitak” znači. Pristup Claryseca počinje ranije: klasificirati podatke, definirati dopuštene prijenose, provesti politiku, pratiti iznimke, pripremiti dokaze za odgovor i sve povezati s ISMS-om.
Kako navodi Zenith Blueprint: An Auditor’s 30-Step Roadmap u fazi Controls in Action, korak 19, Technological Controls I:
Sprječavanje curenja podataka odnosi se na zaustavljanje neovlaštenog ili slučajnog otkrivanja osjetljivih informacija, bilo da one izađu putem e-pošte, učitavanja u oblak, prijenosnih medija ili čak zaboravljenog ispisa. Kontrola 8.12 odnosi se na potrebu da se prati, ograniči i odgovori na svako kretanje podataka izvan pouzdanih granica organizacije, neovisno o tome je li ono digitalno, fizičko ili potaknuto ljudskim postupkom. Zenith Blueprint
Ta je rečenica srž DLP-a u 2026.: pratiti, ograničiti i odgovoriti.
Zašto je DLP sada pitanje usklađenosti na razini uprave
Uprava obično ne pita otkriva li DLP regularnim izrazom nacionalne identifikacijske brojeve. Pita može li organizacija zaštititi povjerenje klijenata, nastaviti poslovati, izbjeći regulatornu izloženost i dokazati razumnu razinu sigurnosti kada nešto pođe po zlu.
Tu se GDPR, NIS2 i DORA preklapaju.
GDPR se široko primjenjuje na automatiziranu obradu osobnih podataka, uključujući voditelje obrade i izvršitelje obrade s poslovnim nastanom u EU-u te organizacije izvan EU-a koje osobama u EU-u nude robu ili usluge ili prate njihovo ponašanje. Široko definira osobne podatke i obuhvaća radnje kao što su prikupljanje, pohrana, uporaba, otkrivanje, brisanje i uništavanje. Neovlašteno otkrivanje osobnih podataka ili pristup osobnim podacima može predstavljati povredu osobnih podataka. GDPR Article 5 također izričito uvodi načelo odgovornosti: organizacije ne moraju samo poštovati načela kao što su minimizacija podataka, ograničenje pohrane, cjelovitost i povjerljivost, nego moraju moći dokazati usklađenost.
NIS2 proširuje pritisak izvan privatnosti. Primjenjuje se na mnoge ključne i važne subjekte, uključujući sektore kao što su bankarstvo, infrastrukture financijskog tržišta, pružatelji usluga računalstva u oblaku, pružatelji podatkovnih centara, pružatelji upravljanih usluga, pružatelji upravljanih sigurnosnih usluga, internetska tržišta, tražilice i platforme društvenih mreža. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, politike sigurnosti informacijskih sustava, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, siguran razvoj, testiranje učinkovitosti, kibernetičku higijenu, osposobljavanje, kriptografiju, kontrolu pristupa, upravljanje imovinom i autentifikaciju.
DORA se primjenjuje od 17. siječnja 2025. i djeluje kao posebni pravilnik o IKT otpornosti za financijski sektor. Za financijske subjekte u opsegu primjene tretira se kao sektorski pravni akt Unije za potrebe preklapanja s NIS2. DORA uvodi DLP u upravljanje IKT rizicima, klasifikaciju incidenata, gubitak podataka koji utječe na dostupnost, autentičnost, cjelovitost ili povjerljivost, testiranje digitalne operativne otpornosti, upravljanje rizicima trećih strana u području IKT-a i ugovorne kontrole.
DLP pitanje u 2026. nije „Imamo li alat?” Ono glasi:
- Znamo li koje su informacije osjetljive?
- Znamo li gdje se pohranjuju, obrađuju i prenose?
- Jesu li dopuštene i zabranjene rute prijenosa definirane?
- Jesu li korisnici osposobljeni i tehnički ograničeni?
- Jesu li rute kroz oblak i SaaS pod upravljanjem?
- Jesu li dnevnički zapisi dovoljni za istragu?
- Trijažiraju li se upozorenja i klasificiraju li se incidenti brzo?
- Jesu li dobavljači i eksternalizirane IKT usluge ugovorno obvezani?
- Možemo li dokazati da kontrole djeluju?
ISO/IEC 27001:2022 prikladan je za odgovaranje na ova pitanja jer zahtijeva kontekst, zahtjeve zainteresiranih strana, procjenu rizika, obradu rizika, mjerljive ciljeve, operativnu kontrolu, dokumentirane dokaze, kontrolu dobavljača, internu reviziju, preispitivanje od strane uprave i kontinuirano poboljšanje. To nije DLP standard, ali DLP pretvara iz izolirane tehnološke konfiguracije u kontrolirani proces sustava upravljanja.
Lanac kontrola ISO 27001 iza učinkovitog DLP-a
Vjerodostojan DLP program ne gradi se na jednoj kontroli. Gradi se na lancu.
Clarysecov Zenith Controls: The Cross-Compliance Guide mapira kontrolu ISO/IEC 27002:2022 8.12, sprječavanje curenja podataka, kao preventivnu i detektivnu kontrolu usmjerenu na povjerljivost, usklađenu s konceptima kibernetičke sigurnosti Protect i Detect, pri čemu je zaštita informacija operativna sposobnost, a zaštita/obrana sigurnosna domena. Zenith Controls
To je važno jer revizori očekuju i blokiranje i vidljivost. Preventivno DLP pravilo bez pregleda upozorenja nije potpuno. Pristup koji se oslanja samo na zapisivanje događaja, bez provedbe za visokorizične prijenose, također je slab.
Isti vodič mapira kontrolu ISO/IEC 27002:2022 5.12, klasifikacija informacija, kao preventivnu kontrolu koja podržava povjerljivost, cjelovitost i dostupnost te je usklađena s Identify. Kontrolu 5.14, prijenos informacija, mapira kao preventivnu kontrolu koja podržava povjerljivost, cjelovitost i dostupnost te je usklađena s Protect, Asset Management i Information Protection.
U praktičnom smislu, DLP lanac kontrola izgleda ovako:
| Područje kontrole ISO/IEC 27002:2022 | Uloga DLP-a | Što pođe po zlu ako nedostaje |
|---|---|---|
| 5.9 Popis informacija i druge povezane imovine | Identificira imovinu, vlasnike i lokacije podataka | Osjetljivi repozitoriji ostaju izvan opsega DLP-a |
| 5.12 Klasifikacija informacija | Definira osjetljivost i zahtjeve postupanja | DLP pravila blokiraju nasumično ili propuštaju kritične podatke |
| 5.13 Označavanje informacija | Čini klasifikaciju vidljivom i strojno obradivom | Korisnici i alati ne mogu razlikovati javne od povjerljivih podataka |
| 5.14 Prijenos informacija | Definira odobrene rute i uvjete prijenosa | Osoblje koristi osobnu e-poštu, potrošačke diskove u oblaku ili neupravljanu razmjenu poruka |
| 5.15 do 5.18 Kontrola pristupa, identitet, autentifikacija i prava pristupa | Ograničava tko može pristupiti podacima i izvoziti ih | Prekomjerna ovlaštenja omogućuju insajderski rizik i masovno izvlačenje podataka |
| 5.19 do 5.23 Kontrole dobavljača i oblaka | Upravlja SaaS-om, oblakom i eksternaliziranom obradom | Podaci cure kroz neprocijenjene dobavljače ili shadow IT |
| 5.24 do 5.28 Upravljanje incidentima | Pretvara DLP upozorenja u radnje odgovora i dokaze | Upozorenja se ignoriraju, ne trijažiraju ili se ne prijavljuju na vrijeme |
| 5.31 i 5.34 Pravne, regulatorne, ugovorne i kontrole privatnosti | Povezuje DLP s GDPR-om, ugovorima i sektorskim pravilima | Kontrole ne odgovaraju stvarnim obvezama |
| 8.12 Sprječavanje curenja podataka | Prati, ograničava i omogućuje odgovor na izlazno kretanje podataka | Osjetljive informacije izlaze bez otkrivanja ili kontrole |
| 8.15 Zapisivanje i 8.16 Aktivnosti praćenja | Pruža dokaze i forenzičku vidljivost | Organizacija ne može dokazati što se dogodilo |
| 8.24 Uporaba kriptografije | Štiti podatke u prijenosu i u mirovanju | Odobreni prijenosi i dalje izlažu čitljive podatke |
Zenith Blueprint, korak 22, objašnjava ovisnost između popisa imovine, klasifikacije i DLP-a:
Pregledajte postojeći popis imovine (5.9) kako biste osigurali da uključuje fizičku i logičku imovinu, vlasnike i klasifikacije. Povežite taj popis s klasifikacijskom shemom (5.12) te osigurajte da je osjetljiva imovina odgovarajuće označena i zaštićena. Prema potrebi definirajte zadržavanje, sigurnosno kopiranje ili izolaciju na temelju klasifikacije.
Zato Clarysec rijetko započinje DLP angažman podešavanjem pravila. Počinjemo usklađivanjem imovine, vlasnika, vrsta podataka, klasifikacijskih oznaka, ruta prijenosa i evidencijskih zapisa. Ako organizacija ne može reći koji su skupovi podataka povjerljivi, regulirani, u vlasništvu klijenata, povezani s plaćanjima ili poslovno kritični, DLP alat može samo nagađati.
Tri stupa modernog DLP programa
Moderni DLP program počiva na tri međusobno povezana stupa: poznavati podatke, upravljati njihovim tokom i braniti granicu. Ti stupovi čine ISO/IEC 27001:2022 praktično primjenjivim za usklađenost s GDPR-om, NIS2 i DORA.
Stup 1: Poznavanje podataka kroz klasifikaciju i označavanje
Ne možete zaštititi ono što ne razumijete. Kontrole ISO/IEC 27002:2022 5.12 i 5.13 zahtijevaju da organizacije klasificiraju informacije i označavaju ih prema osjetljivosti i zahtjevima postupanja. To nije administrativna vježba. To je temelj automatizirane provedbe.
Za MSP, Politika klasifikacije podataka i označavanja navodi:
Povjerljivo: zahtijeva šifriranje u prijenosu i u mirovanju, ograničeni pristup, izričito odobrenje za dijeljenje i sigurno uništenje pri zbrinjavanju. Politika klasifikacije podataka i označavanja - MSP
Ovaj citat, iz odjeljka „Zahtjevi za provedbu politike”, točka 6.3.3, daje DLP programu četiri provediva uvjeta: šifriranje, ograničeni pristup, odobrenje dijeljenja i sigurno zbrinjavanje.
U poslovnim okruženjima Politika klasifikacije podataka i označavanja još je izravnija. Iz odjeljka „Zahtjevi za provedbu politike”, točka 6.2.6.2:
Blokiranje prijenosa (npr. vanjske e-pošte) za neispravno označene osjetljive podatke Politika klasifikacije podataka i označavanja
A iz odjeljka „Provedba i usklađenost”, točka 8.3.2:
Automatizirana provjera klasifikacije korištenjem sprječavanja gubitka podataka (DLP) i alata za otkrivanje podataka
Ove točke pretvaraju klasifikaciju u kontrolu. Datoteka označena kao Povjerljivo može pokrenuti šifriranje, blokirati vanjski prijenos, zahtijevati odobrenje ili generirati sigurnosno upozorenje. DLP tada postaje sloj provedbe za politiku koju korisnici, sustavi i revizori mogu razumjeti.
Stup 2: Upravljanje tokom podataka kroz siguran prijenos informacija
Nakon što su podaci klasificirani, organizacija mora upravljati njihovim kretanjem. Kontrola ISO/IEC 27002:2022 5.14, prijenos informacija, često se zanemaruje, ali upravo ondje počinju mnogi DLP neuspjesi.
Zenith Blueprint opisuje kontrolu 5.14 kao potrebu za upravljanjem tokom informacija tako da prijenos bude siguran, namjeran i usklađen s klasifikacijom i poslovnom svrhom. To se primjenjuje na e-poštu, sigurno dijeljenje datoteka, API-je, SaaS integracije, prijenosne medije, tiskana izvješća i portale dobavljača.
Rad na daljinu čini to posebno važnim. Politika rada na daljinu, odjeljak „Zahtjevi za provedbu politike”, točka 6.3.1.3, zahtijeva od zaposlenika da:
Koriste samo odobrena rješenja za dijeljenje datoteka (npr. M365, Google Workspace s kontrolama sprječavanja gubitka podataka (DLP)) Politika rada na daljinu
Za mobilne uređaje i BYOD, Politika mobilnih uređaja i korištenja vlastitih uređaja (BYOD), odjeljak „Zahtjevi za provedbu politike”, točka 6.6.4, pruža konkretnu provedbu na krajnjim uređajima:
Politike sprječavanja gubitka podataka (DLP) moraju blokirati neovlaštena učitavanja, snimke zaslona, pristup međuspremniku ili dijeljenje podataka iz upravljanih aplikacija u osobne prostore. Politika mobilnih uređaja i korištenja vlastitih uređaja (BYOD)
To je važno jer podaci ne izlaze samo e-poštom. Izlaze putem snimki zaslona, sinkronizacije međuspremnika, neupravljanih profila preglednika, osobnih diskova, mobilnih izbornika za dijeljenje, dodataka za suradnju i AI alata.
Upravljanje oblakom jednako je važno. U Politici korištenja usluga u oblaku - MSP, odjeljak „Zahtjevi upravljanja”, točka 5.5:
Shadow IT, definiran kao uporaba neodobrenih alata u oblaku, mora se tretirati kao kršenje politike i pregledati od strane glavnog direktora i pružatelja IT usluga radi utvrđivanja rizika i potrebnih korektivnih radnji. Politika korištenja usluga u oblaku - MSP
Za poslovne organizacije Politika korištenja usluga u oblaku, odjeljak „Zahtjevi upravljanja”, točka 5.5, podiže razinu praćenja:
Tim za informacijsku sigurnost mora redovito procjenjivati mrežni promet, DNS aktivnost i zapise dnevnika radi otkrivanja neovlaštene uporabe oblaka (shadow IT). Otkrivena kršenja moraju se bez odgode istražiti. Politika korištenja usluga u oblaku
Shadow IT nije samo IT smetnja. Prema GDPR-u može postati nezakonito otkrivanje ili nekontrolirana obrada. Prema NIS2 to je slabost kibernetičke higijene i opskrbnog lanca. Prema DORA može postati rizik treće strane u području IKT-a i pitanje klasifikacije incidenta.
Stup 3: Obrana granice DLP tehnologijom, politikom i sviješću
Kontrola ISO/IEC 27002:2022 8.12, sprječavanje curenja podataka, kontrola je koju većina ljudi povezuje s DLP-om. No u zrelom programu ona je posljednja linija obrane, a ne prva.
Zenith Blueprint objašnjava da DLP zahtijeva troslojni pristup: tehnologiju, politiku i svijest. Tehnologija uključuje DLP na krajnjim uređajima, sigurnost e-pošte, pregled sadržaja, sigurnost pristupa oblaku, SaaS kontrole, kontrole preglednika, filtriranje izlaznog mrežnog prometa i usmjeravanje upozorenja. Politika definira što alati provode. Svijest osigurava da zaposlenici razumiju zašto osobna e-pošta, potrošačka pohrana u oblaku i neodobreni AI alati nisu prihvatljivi načini postupanja s reguliranim ili povjerljivim informacijama.
Komponenta odgovora jednako je važna kao i prevencija. Zenith Blueprint, korak 19, navodi:
No DLP nije samo prevencija, nego i odgovor. Ako se otkrije moguće curenje:
✓ upozorenja treba brzo trijažirati, ✓ zapisivanje događaja mora podržavati forenzičku analizu, ✓ plan odgovora na incidente mora se aktivirati bez odgode.
DLP program koji blokira događaje, ali ih ne trijažira, ne istražuje i ne izvlači naučene lekcije, nije spreman za reviziju. Samo je djelomično implementiran.
Od curenja proračunske tablice do odgovora spremnog za reviziju
Vratimo se na proračunsku tablicu od ponedjeljka ujutro.
U slabom programu organizacija otkriva učitavanje tri tjedna kasnije tijekom pregleda privatnosti. Nitko ne zna tko je odobrio izvoz, jesu li podaci bili osobni podaci, jesu li uključene posebne kategorije podataka, je li AI alat zadržao datoteku ili treba li obavijestiti klijente.
U programu koji je osmislio Clarysec slijed izgleda drukčije.
Prvo, izvoz iz CRM-a označava se kao Povjerljivo jer sadržava osobne podatke i komercijalne informacije o klijentima. Drugo, događaj izvoza bilježi se u dnevniku. Treće, pristupnik e-pošte otkriva povjerljivi privitak koji se šalje na osobnu domenu e-pošte i blokira ga ako ne postoji odobrena iznimka. Četvrto, pokušaj učitavanja u neodobrenu uslugu u oblaku pokreće upozorenje o uporabi oblaka. Peto, upozorenje se trijažira prema postupku odgovora na incidente. Šesto, sigurnosni tim utvrđuje je li došlo do stvarnog otkrivanja, jesu li podaci bili šifrirani, je li pružatelj obradio ili zadržao podatke, jesu li ispunjeni kriteriji povrede prema GDPR-u te primjenjuju li se pragovi za incidente prema NIS2 ili DORA.
Politika zapisivanja događaja i praćenja - MSP, odjeljak „Zahtjevi upravljanja”, točka 5.4.3, točno navodi što mora biti vidljivo:
Zapisi pristupa: pristup datotekama (osobito za osjetljive ili osobne podatke), promjene ovlaštenja, uporaba dijeljenih resursa Politika zapisivanja događaja i praćenja - MSP
Ta je točka kratka, ali presudna. Ako se pristup datotekama, promjene ovlaštenja i uporaba dijeljenih resursa ne bilježe, DLP istraga postaje nagađanje.
Prema NIS2 Article 23, značajni incidenti zahtijevaju fazno izvješćivanje: rano upozorenje u roku od 24 sata od saznanja, obavijest o incidentu u roku od 72 sata i završno izvješće najkasnije mjesec dana nakon obavijesti o incidentu. Prema DORA, Articles 17 to 19 zahtijevaju da financijski subjekti otkrivaju, upravljaju, klasificiraju, evidentiraju, eskaliraju i prijavljuju veće incidente povezane s IKT-om. Klasifikacija uključuje gubitak podataka koji utječe na dostupnost, autentičnost, cjelovitost ili povjerljivost, zajedno s pogođenim klijentima, trajanjem, geografskom rasprostranjenošću, kritičnošću i ekonomskim utjecajem. Prema GDPR-u, neovlašteno otkrivanje osobnih podataka može zahtijevati procjenu povrede i, ako su pragovi ispunjeni, obavješćivanje.
DLP upozorenje stoga nije tek sigurnosni događaj. Može postati procjena povrede privatnosti, NIS2 tijek rada za incident, DORA klasifikacija IKT incidenta, okidač za obavješćivanje klijenata i paket revizijskih dokaza.
DLP kontrole za GDPR Article 32
GDPR Article 32 često se prevodi u popis mjera: šifriranje, povjerljivost, cjelovitost, dostupnost, otpornost, testiranje i obnova. Za DLP je ključno zaštititi podatke tijekom cijelog životnog ciklusa.
Osobni podaci kreću se kroz prikupljanje, pohranu, uporabu, prijenos, otkrivanje, zadržavanje i brisanje. GDPR Article 5 zahtijeva minimizaciju podataka, ograničenje svrhe, ograničenje pohrane, cjelovitost, povjerljivost i odgovornost. GDPR Article 6 zahtijeva pravnu osnovu i usklađenost sa svrhom. GDPR Article 9 zahtijeva strože zaštitne mjere za posebne kategorije osobnih podataka.
DLP podržava te obveze kada je povezan s klasifikacijom podataka, evidencijama zakonite obrade i odobrenim putovima prijenosa.
| Pitanje prema GDPR-u | DLP implementacija | Dokazi koje treba zadržati |
|---|---|---|
| Minimizacija osobnih podataka | Otkrivanje masovnih izvoza ili nepotrebne replikacije | Upozorenja o izvozu i obrazloženja iznimaka |
| Cjelovitost i povjerljivost | Blokiranje vanjskog dijeljenja nešifriranih povjerljivih podataka | DLP pravilo, zahtjev za šifriranje i dnevnički zapis blokiranog događaja |
| Ograničenje svrhe | Ograničavanje prijenosa prema neodobrenim analitičkim ili AI alatima | Popis dopuštenih SaaS usluga, DPIA ili zapis pregleda rizika |
| Posebne kategorije podataka | Primjena strožih oznaka i pravila blokiranja | Pravila klasifikacije, pregled pristupa i tijek odobravanja |
| Odgovornost | Održavanje dokaza o upozorenjima, odlukama i korektivnim radnjama | Prijave incidenata, revizijski trag i zapisi preispitivanja od strane uprave |
Clarysecova Politika maskiranja podataka i pseudonimizacije - MSP, odjeljak „Svrha”, točka 1.2, podržava ovaj pristup životnog ciklusa:
Te su tehnike obvezne kada produkcijski podaci nisu potrebni, uključujući razvoj, analitiku i scenarije usluga trećih strana, radi smanjenja rizika od izloženosti, zlouporabe ili povrede. Politika maskiranja podataka i pseudonimizacije - MSP
To je praktična kontrola za GDPR Article 32. Ako razvojni inženjeri, analitičari ili dobavljači ne trebaju produkcijske osobne podatke, DLP ne smije biti jedina prepreka. Maskiranje i pseudonimizacija smanjuju opseg mogućeg utjecaja prije nego što se podaci uopće pomaknu.
Snažna DLP matrica usklađena s privatnošću trebala bi mapirati vrste osobnih podataka na klasifikacijske oznake, pravnu osnovu, odobrene sustave, odobrene metode izvoza, zahtjeve za šifriranje, DLP pravila, pravila zadržavanja i okidače za incidente. Ta matrica postaje most između upravljanja privatnošću i sigurnosnih operacija.
Kibernetička higijena prema NIS2 i DLP izvan tima za privatnost
NIS2 mijenja razgovor o DLP-u jer curenje podataka promatra kao dio kibernetičke higijene i otpornosti, a ne samo privatnosti.
Article 20 zahtijeva da upravljačka tijela ključnih i važnih subjekata odobre mjere upravljanja rizicima kibernetičke sigurnosti, nadziru implementaciju i pohađaju osposobljavanje o kibernetičkoj sigurnosti. Article 21 zahtijeva odgovarajuće i razmjerne mjere u području politika, postupanja s incidentima, neprekidnosti, opskrbnog lanca, sigurnog razvoja, testiranja učinkovitosti, kibernetičke higijene, osposobljavanja, kriptografije, sigurnosti ljudskih resursa, kontrole pristupa i upravljanja imovinom. Article 25 potiče uporabu relevantnih europskih i međunarodnih standarda i tehničkih specifikacija.
DLP izravno doprinosi tim područjima:
| Područje NIS2 Article 21 | Doprinos DLP-a |
|---|---|
| Analiza rizika i politike sigurnosti informacijskih sustava | Identificira scenarije curenja podataka i definira zahtjeve postupanja |
| Postupanje s incidentima | Usmjerava sumnju na iznošenje podataka u trijažu, eskalaciju i tijekove obavješćivanja |
| Neprekidnost poslovanja | Štiti kritične operativne informacije i informacije o klijentima |
| Sigurnost opskrbnog lanca | Upravlja prijenosima podataka trećim stranama i pristupom dobavljača |
| Siguran razvoj | Sprječava curenje izvornog koda, tajnih vrijednosti i produkcijskih testnih podataka |
| Testiranje učinkovitosti | Omogućuje DLP simulacije, stolne vježbe i praćenje korektivnih radnji |
| Kibernetička higijena i osposobljavanje | Uči korisnike sigurnim praksama prijenosa i rizicima shadow IT-a |
| Kriptografija | Provodi šifriranje za povjerljive prijenose |
| Kontrola pristupa i upravljanje imovinom | Ograničava tko može izvoziti osjetljivu imovinu i bilježi aktivnost |
Politika sigurnosti mreže - MSP, odjeljak „Ciljevi”, točka 3.4, izričito navodi cilj sprječavanja iznošenja podataka:
Spriječiti širenje zlonamjernog softvera i iznošenje podataka kroz mrežne kanale Politika sigurnosti mreže - MSP
Za NIS2, ova vrsta cilja revizorima daje izravan put testiranja: prikazati filtriranje izlaznog prometa, DNS praćenje, zapise proxy poslužitelja, upozorenja krajnjih uređaja, blokirane pokušaje učitavanja i prijave istraga.
Zenith Blueprint, korak 23, dodaje radnju specifičnu za oblak koja je sada ključna za digitalne pružatelje i pružatelje IKT usluga obuhvaćene NIS2:
Navedite sve usluge u oblaku koje su trenutačno u uporabi (5.23), uključujući poznati shadow IT. Utvrdite tko ih je odobrio i je li provedena dubinska analiza dobavljača. Izradite jednostavan kontrolni popis za procjenu koji obuhvaća lokaciju podataka, model pristupa, zapisivanje događaja i šifriranje. Za buduće usluge osigurajte da je kontrolni popis integriran u postupak nabave ili IT uvođenja.
Mnoge organizacije ovdje posrću. Imaju opseg ISMS-a i registar dobavljača, ali nemaju stvaran popis SaaS alata u koje zaposlenici premještaju regulirane podatke ili podatke klijenata. DLP bez otkrivanja uporabe oblaka je slijep.
DORA IKT rizik: DLP za financijske subjekte i pružatelje usluga
Za financijske subjekte DLP se mora uklopiti u okvir upravljanja IKT rizicima prema DORA.
DORA Article 5 zahtijeva interni okvir upravljanja i kontrole za upravljanje IKT rizicima. Upravljačko tijelo ostaje odgovorno za IKT rizik, politike koje čuvaju dostupnost, autentičnost, cjelovitost i povjerljivost podataka, jasne IKT uloge, strategiju digitalne operativne otpornosti, toleranciju IKT rizika, planove neprekidnosti i odgovora/oporavka, planove revizije, resurse, politiku trećih strana i kanale izvješćivanja.
Article 6 zahtijeva dokumentirani okvir upravljanja IKT rizicima koji obuhvaća strategije, politike, postupke, IKT protokole i alate za zaštitu informacija i IKT imovine. Article 9 bavi se zaštitom i prevencijom. Articles 11 to 14 dodaju neprekidnost, odgovor, oporavak, sigurnosno kopiranje, vraćanje podataka, provjere cjelovitosti podataka, naučene lekcije, osposobljavanje za podizanje svijesti i krizne komunikacije.
DLP se uklapa u taj okvir kao sposobnost zaštite, otkrivanja, odgovora i testiranja.
DORA također čini rizik trećih strana neizbježnim. Articles 28 to 30 zahtijevaju upravljanje IKT rizicima trećih strana, registre ugovora o IKT uslugama, dubinsku analizu prije sklapanja ugovora, ugovorne zahtjeve, prava na reviziju i inspekciju, prava raskida, izlazne strategije, opise usluga, lokacije obrade i pohrane podataka, pristup podacima, oporavak i povrat podataka, pomoć u slučaju incidenata, suradnju s nadležnim tijelima, sigurnosne mjere i uvjete podugovaranja.
Za fintech ili banku DLP ne može stati na granici Microsoft 365 ili Google Workspace. Mora obuhvatiti procesore plaćanja, pružatelje provjere identiteta, CRM platforme, skladišta podataka, infrastrukturu oblaka, eksternalizirane službe podrške, pružatelje upravljanih usluga i kritične SaaS integracije.
| Očekivanje DORA | DLP dokazi |
|---|---|
| IKT upravljanje u vlasništvu uprave | DLP rizik prihvaćen od strane uprave, dodijeljene uloge i odobren proračun |
| Dostupnost, autentičnost, cjelovitost i povjerljivost podataka | Klasifikacija, šifriranje, DLP pravila i ograničenja pristupa |
| Životni ciklus incidenta | Trijaža DLP upozorenja, klasifikacija, analiza temeljnog uzroka i eskalacija |
| Testiranje otpornosti | DLP simulacije, scenariji iznošenja podataka i praćenje korektivnih radnji |
| IKT rizik trećih strana | Dubinska analiza dobavljača, ugovorne DLP odredbe i dokazi o lokaciji podataka |
| Revizibilnost | Dnevnički zapisi, povijest izmjena pravila, odobrenja iznimaka i preispitivanje od strane uprave |
To je posebno važno ondje gdje DORA djeluje kao sektorski pravni akt Unije za obveze koje se preklapaju s NIS2. Kontrole i dalje moraju postojati. Put izvješćivanja i nadzora može se razlikovati.
DLP sprint za pravilo u 90 minuta
Clarysec s klijentima koji trebaju brz napredak koristi praktičan sprint, bez pretvaranja da se cjelovit DLP program može izgraditi u jednom sastanku. Cilj je implementirati jednu visokovrijednu DLP kontrolu od politike do dokaza.
Korak 1: Odaberite jednu vrstu podataka i jednu rutu prijenosa
Odaberite „osobni podaci klijenata izvezeni iz CRM-a i poslani vanjskim putem e-pošte”. Nemojte početi sa svakim repozitorijem, državom i vrstom podataka.
Korak 2: Potvrdite klasifikaciju i oznaku
Upotrijebite politiku klasifikacije kako biste potvrdili da je ovaj izvoz Povjerljivo. U MSP okruženju točka 6.3.3 zahtijeva šifriranje, ograničeni pristup, izričito odobrenje za dijeljenje i sigurno uništenje. U poslovnom okruženju Politika klasifikacije podataka i označavanja podržava blokiranje prijenosa neispravno označenih osjetljivih podataka i automatiziranu provjeru pomoću DLP-a i alata za otkrivanje podataka.
Korak 3: Definirajte dopušteni obrazac prijenosa
Dopušteno: izvoz iz CRM-a poslan na odobrenu korisničku domenu putem šifrirane e-pošte ili odobrene sigurne platforme za dijeljenje datoteka, uz poslovno obrazloženje.
Nije dopušteno: osobna e-pošta, javne poveznice za dijeljenje datoteka, neodobreni AI alati i neupravljani diskovi u oblaku.
To je usklađeno s Zenith Blueprint, korak 22, koji navodi:
Ako informacijama „Povjerljivo” nije dopušteno napustiti društvo bez šifriranja, tada sustavi e-pošte moraju provoditi politike šifriranja ili blokirati vanjski prijenos.
Korak 4: Konfigurirajte minimalno DLP pravilo
Konfigurirajte platformu e-pošte ili suradnje da otkriva oznaku povjerljivosti, obrazac osobnih podataka ili konvenciju imenovanja izvoznih datoteka. Počnite s praćenjem ako se očekuju lažno pozitivni rezultati, zatim prijeđite na blokiranje za osobne domene i neodobrene primatelje.
Korak 5: Omogućite zapisivanje događaja i usmjeravanje upozorenja
Osigurajte da zapisi dnevnika obuhvaćaju pristup datotekama, promjene ovlaštenja i uporabu dijeljenih resursa, kako zahtijeva Politika zapisivanja događaja i praćenja - MSP. Usmjerite upozorenja u red prijava sa ozbiljnošću, vrstom podataka, pošiljateljem, primateljem, nazivom datoteke, poduzetom radnjom i osobom koja provodi pregled.
Korak 6: Testirajte tri scenarija
Testirajte odobreni šifrirani prijenos klijentu, blokirani prijenos na osobnu e-poštu i pokušaj učitavanja u neodobrenu domenu u oblaku u načinu samo upozorenja.
Korak 7: Sačuvajte dokaze
Sačuvajte referencu na točku politike, snimku zaslona DLP pravila, rezultate testiranja, prijavu upozorenja, odluku pregledavatelja i odobrenje uprave. Dodajte kontrolu u plan obrade rizika i Izjavu o primjenjivosti.
U terminima ISO/IEC 27001:2022, ova vježba povezuje Clause 6.1.2 procjena rizika, Clause 6.1.3 obrada rizika, Clause 8 operativno planiranje i kontrola, Annex A prijenos informacija, sprječavanje curenja podataka, zapisivanje događaja, praćenje, kontrole dobavljača i oblaka te Clause 9 vrednovanje uspješnosti.
Mapiranje višestruke usklađenosti: jedan DLP program, više obveza
Snaga pristupa Claryseca jest u tome što izbjegava izgradnju odvojenih skupova kontrola za GDPR, NIS2, DORA, NIST i COBIT. Jedan dobro osmišljen DLP program može zadovoljiti više očekivanja ako su dokazi pravilno strukturirani.
| Okvir | Što očekuje od DLP-a | Clarysecov obrazac dokaza |
|---|---|---|
| ISO/IEC 27001:2022 | Kontrole temeljene na riziku, SoA, vlasništvo, operativni dokazi i kontinuirano poboljšanje | Registar rizika, SoA, mapiranje politika, DLP pravila, dnevnički zapisi i preispitivanje od strane uprave |
| GDPR Article 32 | Odgovarajuće tehničke i organizacijske mjere za sigurnost osobnih podataka | Klasifikacija, šifriranje, kontrola pristupa, maskiranje, DLP upozorenja i procjena povrede |
| NIS2 | Kibernetička higijena, kontrola pristupa, upravljanje imovinom, šifriranje, postupanje s incidentima i sigurnost opskrbnog lanca | Odobrene politike, zapisi o osposobljavanju, pregledi dobavljača, tijek rada za incidente i spremnost za izvješćivanje u rokovima 24/72 sata |
| DORA | Upravljanje IKT rizicima, upravljanje incidentima, testiranje otpornosti i nadzor nad trećim stranama | Okvir IKT rizika, DLP testiranje, klasifikacija incidenata, ugovori s dobavljačima i revizijski trag |
| NIST CSF 2.0 | Upravljanje, profili, rizik opskrbnog lanca, ishodi odgovora i oporavka | Trenutačni i ciljni profil, plan zatvaranja praznina, kritičnost dobavljača i zapisi odgovora |
| COBIT 2019 | Upravljački ciljevi, vlasništvo nad kontrolama, sposobnost procesa i dokazi osiguranja | RACI, metrike procesa, izvješćivanje o učinkovitosti kontrola i nalazi unutarnje revizije |
NIST CSF 2.0 koristan je kao komunikacijski sloj. Njegova funkcija GOVERN podržava praćenje pravnih, regulatornih i ugovornih zahtjeva, apetit za rizik, provedbu politike, uloge i nadzor. Metoda Profiles pomaže organizacijama odrediti trenutačni i ciljni sigurnosni profil, dokumentirati praznine i provesti akcijski plan. Funkcije RESPOND i RECOVER podržavaju ograničavanje DLP incidenata, analizu temeljnog uzroka, očuvanje dokaza i vraćanje podataka.
COBIT 2019 dodaje upravljačku perspektivu. Revizor usmjeren na COBIT pitat će jesu li ciljevi DLP-a usklađeni s ciljevima organizacije, je li vlasništvo jasno, postoje li pokazatelji uspješnosti, je li apetit za rizik definiran i prima li uprava smisleno izvješćivanje.
Kako će revizori testirati vaš DLP program
DLP revizije rijetko se svode na jednu snimku zaslona. Različite revizorske perspektive stvaraju različita očekivanja u pogledu dokaza.
| Revizorska perspektiva | Vjerojatno revizijsko pitanje | Dokazi koji funkcioniraju |
|---|---|---|
| Revizor ISO/IEC 27001:2022 | Je li DLP rizik identificiran, obrađen, implementiran i dokazan kroz ISMS? | Procjena rizika, SoA, plan obrade rizika, politike, DLP konfiguracija i operativni zapisi |
| GDPR ili revizor privatnosti | Možete li dokazati da su osobni podaci zaštićeni, minimizirani, zakonito preneseni i procijenjeni u slučaju povrede? | Popis podataka, usklađenost s RoPA, klasifikacija, zapisi prijenosa, DPIA izlazni rezultati i zapis odluke o povredi |
| Procjenitelj NIS2 | Jesu li mjere povezane s DLP-om za kibernetičku higijenu, pristup, incidente, dobavljače i šifriranje odobrene i testirane? | Odobrenje uprave, zapisi o osposobljavanju, operativne upute za incidente, provjere dobavljača i vježba vremenskog slijeda izvješćivanja |
| Nadzorno tijelo DORA ili interna revizija | Podržava li DLP IKT rizik, povjerljivost podataka, klasifikaciju incidenata, testiranje otpornosti i nadzor nad trećim stranama? | Okvir IKT rizika, program testiranja, zapisi klasifikacije incidenata, ugovori s pružateljima usluga i izlazni planovi |
| Procjenitelj NIST | Jesu li DLP ishodi upravljani, profilirani, prioritizirani, praćeni i poboljšavani? | Trenutačni i ciljni profil, POA&M, zapisi upravljanja i dokazi odgovora |
| Revizor COBIT 2019 ili ISACA | Upravlja li se DLP-om kao procesom s odgovornim vlasnicima, metrikama i osiguranjem? | RACI, KPI-jevi, KRI-jevi, opisi procesa, testiranje kontrola i praćenje korektivnih radnji |
Snažan DLP revizijski paket uključuje izjavu o opsegu i riziku, klasifikacijsku shemu, odobrene metode prijenosa, DLP pravila, odobrenja iznimaka, dizajn zapisivanja događaja, postupak trijaže upozorenja, stablo odlučivanja za prijavljivanje incidenata, popis dobavljača i usluga u oblaku, rezultate testiranja i zapise korektivnih radnji.
Uobičajeni DLP neuspjesi u 2026.
Najčešći DLP neuspjesi operativne su prirode, a ne egzotični.
Prvo, klasifikacija je neobvezna ili nedosljedna. Oznake postoje u politici, ali ih korisnici ne primjenjuju, sustavi ih ne provode, a repozitoriji sadržavaju godine neoznačenih osjetljivih datoteka.
Drugo, DLP je zauvijek implementiran u načinu samo upozorenja. Način samo upozorenja koristan je tijekom podešavanja, ali visokorizični prijenos povjerljivih podataka klijenata na osobnu e-poštu na kraju treba biti blokiran osim ako postoji odobrena iznimka.
Treće, shadow IT tretira se kao IT smetnja umjesto kao rizik zaštite podataka. Politika korištenja usluga u oblaku i Politika korištenja usluga u oblaku - MSP osmišljene su kako bi neodobreni alati u oblaku bili vidljivi, podložni pregledu i korektivnim radnjama.
Četvrto, dnevnički zapisi nisu dovoljni za istragu. Ako sigurnosni tim ne može rekonstruirati tko je pristupio, podijelio, preuzeo, učitao ili promijenio ovlaštenja, organizacija ne može pouzdano procijeniti obveze izvješćivanja prema GDPR-u, NIS2 ili DORA.
Peto, dobavljači su izvan DLP modela. DORA Articles 28 to 30 to čine posebno opasnim za financijske subjekte, ali problem pogađa svaki sektor. Ugovori trebaju definirati lokacije podataka, pristup, oporavak, povrat podataka, pomoć u slučaju incidenata, sigurnosne mjere, podugovaranje i prava na reviziju.
Šesto, odgovor na incidente ne uključuje DLP scenarije. Pogrešno usmjerena e-pošta, neovlašteno SaaS učitavanje ili masovni izvoz iz CRM-a trebaju imati operativne upute, kriterije ozbiljnosti i put odlučivanja o obavješćivanju.
Naposljetku, organizacije zaboravljaju fizičke i ljudske kanale. Zenith Blueprint podsjeća da DLP uključuje ponašanje čistog radnog stola, sigurno usitnjavanje, zaključane redove ispisa, revizijske zapise pisača i svijest zaposlenika. DLP program koji zanemaruje papir, snimke zaslona i razgovore nepotpun je.
Izgradite DLP program kojem revizori mogu vjerovati
Ako je vaš DLP program trenutačno konfiguracija alata, 2026. je godina u kojoj ga trebate pretvoriti u upravljan kontrolni sustav potkrijepljen dokazima.
Počnite s tri praktične radnje:
- Odaberite tri najvažnije vrste osjetljivih podataka, kao što su osobni podaci klijenata, podaci o plaćanju i izvorni kod.
- Mapirajte gdje se kreću, uključujući e-poštu, SaaS, pohranu u oblaku, krajnje uređaje, API-je, dobavljače i razvojna okruženja.
- Izgradite jedno provedivo DLP pravilo po vrsti podataka, povezano s politikom, zapisivanjem događaja, odgovorom na incidente i zadržavanjem dokaza.
Clarysec vam može pomoći ubrzati taj proces kroz Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls i politike spremne za prilagodbu, kao što su Politika klasifikacije podataka i označavanja Politika klasifikacije podataka i označavanja, Politika rada na daljinu Politika rada na daljinu, Politika korištenja usluga u oblaku Politika korištenja usluga u oblaku, Politika zapisivanja događaja i praćenja - MSP Politika zapisivanja događaja i praćenja - MSP i Politika mobilnih uređaja i korištenja vlastitih uređaja (BYOD) Politika mobilnih uređaja i korištenja vlastitih uređaja (BYOD).
Cilj nije zaustaviti svaku datoteku u kretanju. Cilj je učiniti sigurno kretanje zadanim, rizično kretanje vidljivim, zabranjeno kretanje blokiranim, a svaku iznimku odgovorno evidentiranom.
Preuzmite Clarysec alate, pregledajte svoj paket DLP dokaza i rezervirajte procjenu spremnosti kako biste provjerili mogu li vaše trenutačne kontrole izdržati provjeru prema GDPR Article 32, očekivanja kibernetičke higijene prema NIS2 i pregled IKT rizika prema DORA.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


