DLP 2026 m.: ISO 27001 programa GDPR, NIS2 ir DORA reikalavimams

Viskas prasideda nuo skaičiuoklės.

Pirmadienį 08:17 klientų sėkmės vadybininkas iš CRM eksportuoja 14 000 įmonių kontaktų, kad parengtų sutarčių atnaujinimo kampaniją. 08:24 skaičiuoklė prisegama prie el. laiško. 08:26 el. laiškas išsiunčiamas į asmeninę „Gmail“ paskyrą, nes darbuotojas nori dirbti kelionės traukiniu metu. 08:31 tas pats failas įkeliamas į nepatvirtintą AI užrašų paslaugą, kad būtų „pašalinti dublikatai“.

Kol kas tai neatrodo kaip pažeidimas. Nėra išpirkos reikalaujančios programinės įrangos pranešimo, nėra kenkimo programos ryšio signalo, nėra kompromituotos administratoriaus lygmens paskyros ir nėra viešo nutekėjimo. Tačiau CISO, atitikties vadovui ir duomenų apsaugos pareigūnui tikrasis klausimas jau kilo: ar organizacija gali įrodyti, kad toks judėjimas buvo leidžiamas, klasifikuotas, užregistruotas žurnaluose, šifruotas, pagrįstas ir atšaukiamas?

Tas pats scenarijus finansinių paslaugų sektoriuje kartojasi kiekvieną savaitę. Kūrėjas bando įkelti Q1_Investor_Projections_DRAFT.xlsx į asmeninį debesijos diską, nes VPN veikia lėtai. Pardavimų vadovas eksportuoja klientų sąrašą į vartotojams skirtą bendradarbiavimo programą. Pagalbos tarnybos analitikas įklijuoja klientų įrašus į nepatvirtintą AI įrankį. Kiekvienu atveju motyvas gali būti patogumas, o ne piktavališkumas, tačiau rizika ta pati. Jautrūs duomenys peržengė arba beveik peržengė ribą, kurios organizacija nekontroliuoja.

Tai ir yra šiuolaikinė duomenų praradimo prevencijos problema. DLP nebėra tik el. pašto šliuzo taisyklė ar galinio įrenginio agentas. 2026 m. veiksminga duomenų praradimo prevencija yra valdoma, įrodymais pagrįsta kontrolės sistema, apimanti SaaS, debesijos saugyklas, galinius įrenginius, mobiliuosius įrenginius, tiekėjus, taikomųjų programų sąsajas, kūrimo aplinkas, atsarginių kopijų eksportą, bendradarbiavimo priemones ir žmogiškuosius apėjimus.

GDPR Article 32 reikalauja tinkamų techninių ir organizacinių priemonių tvarkymo saugumui užtikrinti. NIS2 Article 21 reikalauja rizika grindžiamų kibernetinio saugumo priemonių, įskaitant kibernetinę higieną, prieigos kontrolę, turto valdymą, tiekimo grandinės saugumą, incidentų valdymą, šifravimą ir veiksmingumo testavimą. DORA reikalauja, kad finansų subjektai valdytų IRT riziką per valdyseną, aptikimą, reagavimą, atkūrimą, testavimą, trečiųjų šalių priežiūrą ir audituojamumą. ISO/IEC 27001:2022 suteikia valdymo sistemos pagrindą, kad šie įpareigojimai taptų įgyvendinami, išmatuojami ir audituojami.

Dažna organizacijų klaida – DLP įrankį įsigyti dar neapibrėžus, ką reiškia „praradimas“. Clarysec požiūris prasideda anksčiau: klasifikuoti duomenis, apibrėžti leidžiamus perdavimus, įgyvendinti politiką, stebėti išimtis, parengti reagavimo įrodymus ir viską susieti su ISVS.

Kaip Zenith Blueprint: auditoriaus 30 žingsnių veiksmų plane nurodoma „Kontrolės priemonės praktikoje“ etapo 19 žingsnyje „Technologinės kontrolės priemonės I“:

Duomenų nutekėjimo prevencija skirta sustabdyti neautorizuotą arba atsitiktinį jautrios informacijos atskleidimą, nesvarbu, ar ji iškeliauja el. paštu, per debesijos įkėlimus, nešiojamąsias laikmenas, ar net per pamirštą spaudinį. Kontrolė 8.12 numato poreikį stebėti, riboti ir reaguoti į bet kokius duomenis, paliekančius patikimas organizacijos ribas, nepriklausomai nuo to, ar tai skaitmeninis, fizinis, ar žmogaus inicijuotas veiksmas. Zenith Blueprint

Šis sakinys yra 2026 m. DLP esmė: stebėti, riboti ir reaguoti.

Kodėl DLP dabar yra valdybos lygmens atitikties klausimas

Valdyba paprastai neklausia, ar DLP reguliarioji išraiška aptinka nacionalinius asmens tapatybės numerius. Ji klausia, ar organizacija gali apsaugoti klientų pasitikėjimą, tęsti veiklą, išvengti reguliacinės rizikos ir įrodyti pagrįstą saugumą, kai kas nors įvyksta ne taip.

Būtent čia susikerta GDPR, NIS2 ir DORA.

GDPR plačiai taikomas automatizuotam asmens duomenų tvarkymui, įskaitant ES įsisteigusius duomenų valdytojus ir tvarkytojus, taip pat ne ES organizacijas, siūlančias prekes ar paslaugas ES esantiems asmenims arba stebinčias jų elgseną. Reglamentas plačiai apibrėžia asmens duomenis ir apima tokias operacijas kaip rinkimas, saugojimas, naudojimas, atskleidimas, ištrynimas ir sunaikinimas. Neautorizuotas asmens duomenų atskleidimas arba prieiga prie jų gali būti asmens duomenų saugumo pažeidimas. GDPR Article 5 taip pat aiškiai įtvirtina atskaitomybę: organizacijos turi ne tik laikytis tokių principų kaip duomenų kiekio mažinimas, saugojimo trukmės ribojimas, vientisumas ir konfidencialumas, bet ir gebėti įrodyti atitiktį.

NIS2 spaudimą išplečia už privatumo ribų. Ji taikoma daugeliui esminių ir svarbių subjektų, įskaitant tokius sektorius kaip bankininkystė, finansų rinkų infrastruktūros, debesijos paslaugų teikėjai, duomenų centrų paslaugų teikėjai, valdomų paslaugų teikėjai, valdomų saugumo paslaugų teikėjai, internetinės prekyvietės, paieškos sistemos ir socialinių tinklų platformos. Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, informacinių sistemų saugumo politikas, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų kūrimą, veiksmingumo testavimą, kibernetinę higieną, mokymus, kriptografiją, prieigos kontrolę, turto valdymą ir autentifikavimą.

DORA taikomas nuo 2025 m. sausio 17 d. ir veikia kaip finansų sektoriui skirtas IRT atsparumo taisyklių rinkinys. Į taikymo sritį patenkantiems finansų subjektams jis laikomas sektoriui skirtu Sąjungos teisės aktu, kai NIS2 reikalavimai persidengia. DORA įtraukia DLP į IRT rizikos valdymą, incidentų klasifikavimą, duomenų praradimą, darantį poveikį prieinamumui, autentiškumui, vientisumui ar konfidencialumui, skaitmeninio operacinio atsparumo testavimą, IRT trečiųjų šalių valdymą ir sutartines kontrolės priemones.

2026 m. DLP klausimas nėra „Ar turime įrankį?“ Jis skamba taip:

1. Ar žinome, kuri informacija yra jautri?
2. Ar žinome, kur ji saugoma, tvarkoma ir perduodama?
3. Ar apibrėžti leidžiami ir draudžiami perdavimo maršrutai?
4. Ar naudotojai apmokyti ir techniškai apriboti?
5. Ar debesijos ir SaaS maršrutams taikoma valdysena?
6. Ar žurnalų pakanka tyrimui?
7. Ar įspėjimai greitai įvertinami ir incidentai klasifikuojami?
8. Ar tiekėjai ir išorinės IRT paslaugos sutartimis įpareigoti?
9. Ar galime įrodyti, kad kontrolės priemonės veikia?

ISO/IEC 27001:2022 yra tinkamas atsakyti į šiuos klausimus, nes jis reikalauja konteksto, suinteresuotųjų šalių reikalavimų, rizikos vertinimo, rizikos tvarkymo, išmatuojamų tikslų, operacinės kontrolės, dokumentuotų įrodymų, tiekėjų kontrolės, vidaus audito, vadovybės peržiūros ir nuolatinio tobulinimo. Tai nėra DLP standartas, tačiau jis DLP paverčia iš izoliuotos technologinės konfigūracijos į kontroliuojamą valdymo sistemos procesą.

ISO 27001 kontrolės priemonių grandinė, lemianti veiksmingą DLP

Patikima DLP programa nėra kuriama iš vienos kontrolės priemonės. Ji kuriama kaip grandinė.

Clarysec Zenith Controls: kryžminės atitikties vadovas ISO/IEC 27002:2022 kontrolę 8.12, duomenų nutekėjimo prevenciją, susieja kaip prevencinę ir nustatomąją kontrolės priemonę, orientuotą į konfidencialumą, suderintą su „Protect“ ir „Detect“ kibernetinio saugumo koncepcijomis, kur informacijos apsauga yra operacinis gebėjimas, o apsauga ir gynyba – saugumo sritis. Zenith Controls

Tai svarbu, nes auditoriai tikisi ir blokavimo, ir matomumo. Prevencinė DLP taisyklė be įspėjimų peržiūros yra neišsami. Tik žurnalais pagrįstas požiūris be aukštos rizikos perdavimų ribojimo taip pat yra silpnas.

Tas pats vadovas ISO/IEC 27002:2022 kontrolę 5.12, informacijos klasifikavimą, susieja kaip prevencinę priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą bei suderintą su „Identify“. Kontrolę 5.14, informacijos perdavimą, jis susieja kaip prevencinę priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą bei suderintą su „Protect“, turto valdymu ir informacijos apsauga.

Praktiškai DLP kontrolės priemonių grandinė atrodo taip:

Zenith Blueprint, 22 žingsnyje, paaiškina turto apskaitos, klasifikavimo ir DLP tarpusavio priklausomybę:

Peržiūrėkite dabartinę turto apskaitą (5.9), kad įsitikintumėte, jog ji apima fizinį ir loginį turtą, savininkus ir klasifikacijas. Susiekite šią apskaitą su klasifikavimo schema (5.12), užtikrindami, kad jautrus turtas būtų paženklintas ir tinkamai apsaugotas. Jei reikia, pagal klasifikaciją apibrėžkite saugojimą, atsarginių kopijų kūrimą arba izoliavimą.

Todėl Clarysec retai pradeda DLP projektą nuo taisyklių derinimo. Pradedame nuo turto, savininkų, duomenų tipų, klasifikavimo žymų, perdavimo maršrutų ir įrodymų įrašų suderinimo. Jei organizacija negali pasakyti, kurie duomenų rinkiniai yra konfidencialūs, reglamentuojami, priklausantys klientams, susiję su mokėjimais ar verslui kritiniai, DLP įrankis gali tik spėlioti.

Trys modernios DLP programos ramsčiai

Moderni DLP programa remiasi trimis vienas kitą stiprinančiais ramsčiais: pažinti duomenis, valdyti srautą ir ginti ribą. Šie ramsčiai padaro ISO/IEC 27001:2022 praktiškai pritaikomą GDPR, NIS2 ir DORA atitikčiai.

1 ramstis: pažinkite savo duomenis taikydami klasifikavimą ir ženklinimą

Negalite apsaugoti to, ko nesuprantate. ISO/IEC 27002:2022 kontrolės 5.12 ir 5.13 reikalauja, kad organizacijos klasifikuotų informaciją ir ją ženklintų pagal jautrumą bei tvarkymo reikalavimus. Tai nėra dokumentacijos formalumas. Tai automatinio įgyvendinimo pagrindas.

MVĮ skirta Duomenų klasifikavimo ir ženklinimo politika nustato:

Konfidencialus: reikalingas perduodamų ir saugomų duomenų šifravimas, ribota prieiga, aiškus patvirtinimas dalijimuisi ir saugus sunaikinimas šalinimo metu. Duomenų klasifikavimo ir ženklinimo politika - MVĮ

Ši citata iš skyriaus „Politikos įgyvendinimo reikalavimai“, 6.3.3 punkto, DLP programai suteikia keturias įgyvendinamas sąlygas: šifravimą, ribotą prieigą, dalijimosi patvirtinimą ir saugų sunaikinimą.

Įmonių aplinkose Duomenų klasifikavimo ir ženklinimo politika yra dar tiesesnė. Iš skyriaus „Politikos įgyvendinimo reikalavimai“, 6.2.6.2 punkto:

Perdavimo blokavimas (pvz., išoriniu el. paštu), kai jautrūs duomenys netinkamai paženklinti Duomenų klasifikavimo ir ženklinimo politika

Ir iš skyriaus „Įgyvendinimas ir atitiktis“, 8.3.2 punkto:

Automatizuotas klasifikacijos tikrinimas naudojant duomenų praradimo prevencijos (DLP) ir aptikimo priemones

Šios nuostatos klasifikavimą paverčia kontrolės priemone. Failas, pažymėtas kaip Konfidencialus, gali inicijuoti šifravimą, blokuoti išorinį perdavimą, reikalauti patvirtinimo arba sugeneruoti saugumo įspėjimą. Tuomet DLP tampa politikos įgyvendinimo sluoksniu, kurį supranta naudotojai, sistemos ir auditoriai.

2 ramstis: valdykite srautą saugiu informacijos perdavimu

Kai duomenys klasifikuoti, organizacija turi valdyti, kaip jie juda. ISO/IEC 27002:2022 kontrolė 5.14, informacijos perdavimas, dažnai nuvertinama, tačiau būtent čia prasideda daug DLP nesėkmių.

Zenith Blueprint kontrolę 5.14 apibrėžia kaip poreikį valdyti informacijos srautą taip, kad perdavimas būtų saugus, sąmoningas ir atitiktų klasifikaciją bei veiklos tikslą. Tai taikoma el. paštui, saugiam failų dalijimuisi, taikomųjų programų sąsajoms, SaaS integracijoms, keičiamajai laikmenai, spausdintoms ataskaitoms ir tiekėjų portalams.

Nuotolinis darbas tai dar labiau sustiprina. Nuotolinio darbo politika, skyriaus „Politikos įgyvendinimo reikalavimai“ 6.3.1.3 punktas, reikalauja, kad darbuotojai:

Naudotų tik patvirtintus failų dalijimosi sprendimus (pvz., M365, Google Workspace su duomenų praradimo prevencijos (DLP) kontrolės priemonėmis) Nuotolinio darbo politika

Mobiliesiems įrenginiams ir BYOD Mobiliųjų įrenginių ir BYOD politika, skyriaus „Politikos įgyvendinimo reikalavimai“ 6.6.4 punktas, nustato konkrečias galinių įrenginių įgyvendinimo priemones:

Duomenų praradimo prevencijos (DLP) politikos turi blokuoti neautorizuotus įkėlimus, ekrano kopijų darymą, iškarpinės prieigą arba duomenų dalijimąsi iš valdomų taikomųjų programų į asmenines sritis. Mobiliųjų įrenginių ir BYOD politika

Tai svarbu, nes duomenys palieka organizaciją ne tik el. paštu. Jie išeina per ekrano kopijas, iškarpinės sinchronizavimą, nevaldomus naršyklės profilius, asmeninius diskus, mobiliųjų įrenginių dalijimosi meniu, bendradarbiavimo papildinius ir AI įrankius.

Debesijos valdysena ne mažiau svarbi. MVĮ skirtoje Debesijos paslaugų naudojimo politika-sme, skyriaus „Valdysenos reikalavimai“ 5.5 punktas, nustato:

Šešėlinė IT, apibrėžiama kaip nepatvirtintų debesijos įrankių naudojimas, turi būti laikoma politikos pažeidimu ir peržiūrima generalinio direktoriaus bei IT paslaugų teikėjo, siekiant nustatyti riziką ir reikalingus taisomuosius veiksmus. Debesijos paslaugų naudojimo politika-sme - MVĮ

Įmonių organizacijoms Debesijos paslaugų naudojimo politika, skyriaus „Valdysenos reikalavimai“ 5.5 punktas, kelia aukštesnį stebėsenos reikalavimą:

Informacijos saugos komanda turi reguliariai vertinti tinklo srautą, DNS veiklą ir žurnalus, kad aptiktų neautorizuotą debesijos naudojimą (šešėlinę IT). Aptikti pažeidimai turi būti nedelsiant ištirti. Debesijos paslaugų naudojimo politika

Šešėlinė IT nėra tik IT nepatogumas. Pagal GDPR tai gali tapti neteisėtu atskleidimu arba nekontroliuojamu tvarkymu. Pagal NIS2 tai yra kibernetinės higienos ir tiekimo grandinės silpnoji vieta. Pagal DORA tai gali tapti IRT trečiosios šalies rizika ir incidentų klasifikavimo klausimu.

3 ramstis: ginkite ribą DLP technologijomis, politika ir sąmoningumu

ISO/IEC 27002:2022 kontrolė 8.12, duomenų nutekėjimo prevencija, yra kontrolė, kurią dauguma sieja su DLP. Tačiau brandžioje programoje tai yra paskutinė gynybos linija, o ne pirmoji.

Zenith Blueprint paaiškina, kad DLP reikia trijų sluoksnių požiūrio: technologijų, politikos ir sąmoningumo. Technologijos apima galinių įrenginių DLP, el. pašto saugumą, turinio tikrinimą, debesijos prieigos saugumą, SaaS kontrolės priemones, naršyklės kontrolės priemones, tinklo išeinančio srauto filtravimą ir įspėjimų nukreipimą. Politika apibrėžia, ką įrankiai įgyvendina. Sąmoningumas užtikrina, kad darbuotojai suprastų, kodėl asmeninis el. paštas, vartotojams skirta debesijos saugykla ir nepatvirtinti AI įrankiai nėra priimtini reglamentuojamos arba konfidencialios informacijos tvarkymo būdai.

Reagavimo komponentas yra toks pat svarbus kaip prevencija. Zenith Blueprint, 19 žingsnyje, nurodoma:

Tačiau DLP nėra vien prevencija – tai taip pat reagavimas. Aptikus galimą nutekėjimą:

✓ Įspėjimai turi būti greitai įvertinti, ✓ Žurnalų tvarkymas turi palaikyti kriminalistinę analizę, ✓ Reagavimo į incidentus planas turi būti aktyvuotas nedelsiant.

DLP programa, kuri blokuoja įvykius, bet jų neįvertina, netiria ir iš jų nesimoko, nėra tinkama auditui. Ji tik iš dalies įdiegta.

Nuo skaičiuoklės nutekėjimo iki auditui tinkamo reagavimo

Grįžkime prie pirmadienio ryto skaičiuoklės.

Silpnoje programoje organizacija apie įkėlimą sužino po trijų savaičių per privatumo peržiūrą. Niekas nežino, kas patvirtino eksportą, ar duomenys buvo asmens duomenys, ar buvo specialių kategorijų duomenų, ar AI įrankis išlaikė failą, ir ar klientams reikia pranešti.

Clarysec sukurtoje programoje seka atrodo kitaip.

Pirma, CRM eksportas pažymimas kaip Konfidencialus, nes jame yra asmens duomenų ir klientų komercinės informacijos. Antra, eksporto įvykis užregistruojamas žurnale. Trečia, el. pašto šliuzas aptinka konfidencialų priedą, siunčiamą į asmeninį el. pašto domeną, ir jį blokuoja, nebent yra patvirtinta išimtis. Ketvirta, bandymas įkelti į nepatvirtintą debesijos paslaugą sukelia debesijos naudojimo įspėjimą. Penkta, įspėjimas įvertinamas pagal reagavimo į incidentus procedūrą. Šešta, saugumo komanda nustato, ar buvo faktinis atskleidimas, ar duomenys buvo šifruoti, ar teikėjas juos tvarkė arba išsaugojo, ar tenkinami GDPR pažeidimo kriterijai ir ar taikomi NIS2 arba DORA incidentų slenksčiai.

MVĮ skirta Žurnalų tvarkymo ir stebėsenos politika, skyriaus „Valdysenos reikalavimai“ 5.4.3 punktas, komandai tiksliai nurodo, kas turi būti matoma:

Prieigos žurnalai: prieiga prie failų (ypač jautrių arba asmens duomenų), leidimų pakeitimai, bendrinamų išteklių naudojimas Žurnalų tvarkymo ir stebėsenos politika - MVĮ

Ši nuostata nedidelė, bet lemiama. Jei prieiga prie failų, leidimų pakeitimai ir bendrinamų išteklių naudojimas nėra registruojami žurnaluose, DLP tyrimas tampa spėlionėmis.

Pagal NIS2 Article 23 reikšmingiems incidentams taikomas etapinis pranešimas: ankstyvas įspėjimas per 24 valandas nuo sužinojimo, incidento pranešimas per 72 valandas ir galutinė ataskaita ne vėliau kaip per vieną mėnesį po incidento pranešimo. Pagal DORA, Articles 17 to 19 reikalauja, kad finansų subjektai aptiktų, valdytų, klasifikuotų, registruotų, eskaluotų ir praneštų apie reikšmingus su IRT susijusius incidentus. Klasifikavimas apima duomenų praradimą, veikiantį prieinamumą, autentiškumą, vientisumą ar konfidencialumą, taip pat paveiktus klientus, trukmę, geografinį paplitimą, kritiškumą ir ekonominį poveikį. Pagal GDPR neautorizuotas asmens duomenų atskleidimas gali pareikalauti pažeidimo vertinimo ir, kai slenksčiai pasiekti, pranešimo.

Todėl DLP įspėjimas nėra vien saugumo įvykis. Jis gali tapti privatumo pažeidimo vertinimu, NIS2 incidento darbo eiga, DORA IRT incidento klasifikavimu, kliento informavimo paleidikliu ir audito įrodymų paketu.

DLP kontrolės priemonės GDPR Article 32 įgyvendinti

GDPR Article 32 dažnai paverčiamas priemonių sąrašu: šifravimas, konfidencialumas, vientisumas, prieinamumas, atsparumas, testavimas ir atkūrimas. DLP atveju svarbiausia yra apsauga per visą gyvavimo ciklą.

Asmens duomenys juda per rinkimą, saugojimą, naudojimą, perdavimą, atskleidimą, saugojimo terminą ir ištrynimą. GDPR Article 5 reikalauja duomenų kiekio mažinimo, tikslo apribojimo, saugojimo trukmės ribojimo, vientisumo, konfidencialumo ir atskaitomybės. GDPR Article 6 reikalauja teisinio pagrindo ir tikslo suderinamumo. GDPR Article 9 reikalauja griežtesnių apsaugos priemonių specialių kategorijų asmens duomenims.

DLP padeda vykdyti šiuos įpareigojimus, kai ji susieta su duomenų klasifikavimu, teisėto tvarkymo įrašais ir patvirtintais perdavimo keliais.

Clarysec Duomenų maskavimo ir pseudonimizavimo politika-sme, skyriaus „Tikslas“ 1.2 punktas, palaiko šį gyvavimo ciklo požiūrį:

Šie metodai yra privalomi tais atvejais, kai realūs duomenys nereikalingi, įskaitant kūrimo, analitikos ir trečiųjų šalių paslaugų scenarijus, siekiant sumažinti atskleidimo, netinkamo naudojimo arba pažeidimo riziką. Duomenų maskavimo ir pseudonimizavimo politika-sme - MVĮ

Tai praktinė GDPR Article 32 kontrolės priemonė. Jei kūrėjams, analitikams ar tiekėjams nereikia realių asmens duomenų, DLP neturėtų būti vienintelė kliūtis. Maskavimas ir pseudonimizavimas sumažina poveikio mastą dar prieš duomenims pajudant.

Stipri su privatumu suderinta DLP matrica turėtų susieti asmens duomenų tipus su klasifikavimo žymomis, teisiniu pagrindu, patvirtintomis sistemomis, patvirtintais eksporto metodais, šifravimo reikalavimais, DLP taisyklėmis, saugojimo taisyklėmis ir incidentų paleidikliais. Tokia matrica tampa tiltu tarp privatumo valdysenos ir saugumo operacijų.

NIS2 kibernetinė higiena ir DLP už privatumo komandos ribų

NIS2 keičia DLP diskusiją, nes nutekėjimą apibrėžia kaip kibernetinės higienos ir atsparumo dalį, o ne vien privatumo klausimą.

Article 20 reikalauja, kad esminių ir svarbių subjektų valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir gautų kibernetinio saugumo mokymus. Article 21 reikalauja tinkamų ir proporcingų priemonių politikų, incidentų valdymo, tęstinumo, tiekimo grandinės, saugaus kūrimo, veiksmingumo testavimo, kibernetinės higienos, mokymų, kriptografijos, HR saugumo, prieigos kontrolės ir turto valdymo srityse. Article 25 skatina naudoti atitinkamus Europos ir tarptautinius standartus bei technines specifikacijas.

DLP tiesiogiai prisideda prie šių sričių:

Tinklo saugumo politika-sme, skyriaus „Tikslai“ 3.4 punktas, aiškiai įvardija duomenų iškėlimo tikslą:

Užkirsti kelią kenkimo programinės įrangos plitimui ir duomenų iškėlimui tinklo kanalais Tinklo saugumo politika-sme - MVĮ

NIS2 kontekste toks tikslas auditoriams suteikia tiesioginį testavimo kelią: parodyti išeinančio srauto filtravimą, DNS stebėseną, tarpinio serverio žurnalus, galinių įrenginių įspėjimus, užblokuotus įkėlimo bandymus ir tyrimo bilietus.

Zenith Blueprint, 23 žingsnyje, prideda debesijai skirtą veiksmą, kuris dabar būtinas NIS2 taikymo sričiai priklausantiems skaitmeninių ir IRT paslaugų teikėjams:

Išvardykite visas šiuo metu naudojamas debesijos paslaugas (5.23), įskaitant žinomą šešėlinę IT. Nustatykite, kas jas patvirtino ir ar buvo atliktas deramas rūpestingumas. Parenkite lengvą vertinimo kontrolinį sąrašą, apimantį duomenų vietą, prieigos modelį, žurnalų tvarkymą ir šifravimą. Būsimoms paslaugoms užtikrinkite, kad kontrolinis sąrašas būtų integruotas į pirkimų arba IT įtraukimo procesą.

Daugelis organizacijų čia suklumpa. Jos turi ISVS taikymo sritį ir tiekėjų registrą, bet neturi tikro SaaS įrankių sąrašo, kuriuose darbuotojai perkelia reglamentuojamus arba klientų duomenis. DLP be debesijos aptikimo yra akla.

DORA IRT rizika: DLP finansų subjektams ir paslaugų teikėjams

Finansų subjektams DLP turi derėti su DORA IRT rizikos valdymo sistema.

DORA Article 5 reikalauja vidaus valdysenos ir kontrolės sistemos IRT rizikos valdymui. Valdymo organas lieka atsakingas už IRT riziką, politikas, saugančias duomenų prieinamumą, autentiškumą, vientisumą ir konfidencialumą, aiškius IRT vaidmenis, skaitmeninio operacinio atsparumo strategiją, IRT rizikos toleranciją, tęstinumo ir reagavimo / atkūrimo planus, audito planus, išteklius, trečiųjų šalių politiką ir ataskaitų teikimo kanalus.

Article 6 reikalauja dokumentuotos IRT rizikos valdymo sistemos, apimančios strategijas, politikas, procedūras, IRT protokolus ir įrankius informacijai bei IRT turtui apsaugoti. Article 9 reglamentuoja apsaugą ir prevenciją. Articles 11 to 14 papildo tęstinumo, reagavimo, atkūrimo, atsarginių kopijų, atstatymo, duomenų vientisumo patikrų, įgytos patirties, informuotumo mokymų ir krizių komunikacijos reikalavimais.

DLP į šią sistemą įsilieja kaip apsaugos, aptikimo, reagavimo ir testavimo gebėjimas.

DORA taip pat padaro trečiųjų šalių riziką neišvengiamą. Articles 28 to 30 reikalauja IRT trečiųjų šalių rizikos valdymo, IRT paslaugų sutarčių registrų, ikisutartinio deramo rūpestingumo, sutartinių reikalavimų, audito ir patikrinimo teisių, nutraukimo teisių, pasitraukimo strategijų, paslaugų aprašymų, duomenų tvarkymo ir saugojimo vietų, prieigos prie duomenų, atkūrimo ir grąžinimo, pagalbos incidentų atveju, bendradarbiavimo su institucijomis, saugumo priemonių ir subtiekimo sąlygų.

Fintech įmonei ar bankui DLP negali baigtis ties Microsoft 365 ar Google Workspace riba. Ji turi apimti mokėjimų tvarkytojus, tapatybės tikrinimo teikėjus, CRM platformas, duomenų saugyklas, debesijos infrastruktūrą, išorines pagalbos tarnybas, valdomų paslaugų teikėjus ir kritines SaaS integracijas.

Tai ypač svarbu ten, kur DORA veikia kaip sektoriui skirtas Sąjungos teisės aktas persidengiantiems NIS2 įpareigojimams. Kontrolės priemonės vis tiek turi egzistuoti. Gali skirtis pranešimo ir priežiūros kelias.

90 minučių DLP taisyklės sprintas

Clarysec su klientais taiko praktinį sprintą, kai reikia greitos pažangos, neapsimetant, kad visa DLP programa gali būti sukurta per vieną susitikimą. Tikslas – įgyvendinti vieną didelės vertės DLP kontrolės priemonę nuo politikos iki įrodymų.

1 žingsnis: pasirinkite vieną duomenų tipą ir vieną perdavimo maršrutą

Pasirinkite „klientų asmens duomenys, eksportuojami iš CRM ir siunčiami išoriškai el. paštu“. Nepradėkite nuo visų saugyklų, šalių ir duomenų tipų.

2 žingsnis: patvirtinkite klasifikaciją ir žymą

Naudokite klasifikavimo politiką, kad patvirtintumėte, jog šis eksportas yra Konfidencialus. MVĮ atveju 6.3.3 punktas reikalauja šifravimo, ribotos prieigos, aiškaus patvirtinimo dalijimuisi ir saugaus sunaikinimo. Įmonėje Duomenų klasifikavimo ir ženklinimo politika palaiko netinkamai paženklintų jautrių duomenų perdavimo blokavimą ir automatizuotą tikrinimą naudojant DLP bei aptikimo priemones.

3 žingsnis: apibrėžkite leidžiamą perdavimo modelį

Leidžiama: CRM eksportas siunčiamas į patvirtintą kliento domeną naudojant šifruotą el. paštą arba patvirtintą saugaus failų dalijimosi platformą, pateikus veiklos pagrindimą.

Neleidžiama: asmeninis el. paštas, viešos failų dalijimosi nuorodos, nepatvirtinti AI įrankiai ir nevaldomi debesijos diskai.

Tai dera su Zenith Blueprint, 22 žingsniu, kuriame teigiama:

Jei „Konfidencialiai“ informacijai neleidžiama palikti įmonės be šifravimo, el. pašto sistemos turi įgyvendinti šifravimo politikas arba blokuoti išorinį perdavimą.

4 žingsnis: sukonfigūruokite minimalią DLP taisyklę

Sukonfigūruokite el. pašto arba bendradarbiavimo platformą taip, kad ji aptiktų konfidencialumo žymą, asmens duomenų modelį arba eksporto failo pavadinimo konvenciją. Jei tikėtini klaidingi teigiami rezultatai, pradėkite nuo stebėsenos, tada pereikite prie blokavimo asmeniniams domenams ir nepatvirtintiems gavėjams.

5 žingsnis: įjunkite žurnalų tvarkymą ir įspėjimų nukreipimą

Užtikrinkite, kad žurnalai fiksuotų prieigą prie failų, leidimų pakeitimus ir bendrinamų išteklių naudojimą, kaip reikalaujama Žurnalų tvarkymo ir stebėsenos politika - MVĮ. Nukreipkite įspėjimus į užduočių eilę, nurodydami sunkumą, duomenų tipą, siuntėją, gavėją, failo pavadinimą, atliktą veiksmą ir peržiūrėtoją.

6 žingsnis: patikrinkite tris scenarijus

Patikrinkite patvirtintą šifruotą perdavimą klientui, užblokuotą perdavimą į asmeninį el. paštą ir tik įspėjimą sukeliantį bandymą įkelti į nepatvirtintą debesijos domeną.

7 žingsnis: išsaugokite įrodymus

Išsaugokite politikos punkto nuorodą, DLP taisyklės ekrano kopiją, testavimo rezultatus, įspėjimo užduotį, peržiūrėtojo sprendimą ir vadovybės patvirtinimą. Įtraukite kontrolės priemonę į rizikos tvarkymo planą ir Taikomumo pareiškimą.

ISO/IEC 27001:2022 požiūriu šis pratimas sujungia 6.1.2 punktą dėl rizikos vertinimo, 6.1.3 punktą dėl rizikos tvarkymo, 8 punktą dėl operacinio planavimo ir kontrolės, Annex A informacijos perdavimą, duomenų nutekėjimo prevenciją, žurnalų tvarkymą, stebėseną, tiekėjų ir debesijos kontrolės priemones bei 9 punktą dėl veiklos vertinimo.

Kryžminės atitikties susiejimas: viena DLP programa, keli įpareigojimai

Clarysec požiūrio stiprybė yra ta, kad jis vengia kurti atskirus kontrolės rinkinius GDPR, NIS2, DORA, NIST ir COBIT reikalavimams. Viena gerai suprojektuota DLP programa gali patenkinti kelis lūkesčius, jei įrodymai struktūruojami tinkamai.

NIST CSF 2.0 yra naudingas kaip komunikacijos sluoksnis. Jo GOVERN funkcija palaiko teisinių, reguliacinių ir sutartinių reikalavimų sekimą, rizikos apetitą, politikos taikymą, vaidmenis ir priežiūrą. Jo profilių metodas padeda organizacijoms apibrėžti dabartinę ir tikslinę saugumo būklę, dokumentuoti spragas ir įgyvendinti veiksmų planą. RESPOND ir RECOVER funkcijos palaiko DLP incidentų lokalizavimą, pagrindinės priežasties analizę, įrodymų išsaugojimą ir atkūrimą.

COBIT 2019 prideda valdysenos perspektyvą. COBIT taikantis auditorius klausia, ar DLP tikslai suderinti su įmonės tikslais, ar aiški savininkystė, ar yra veiklos rodikliai, ar apibrėžtas rizikos apetitas ir ar vadovybė gauna prasmingas ataskaitas.

Kaip auditoriai testuos jūsų DLP programą

DLP auditai retai apsiriboja viena ekrano kopija. Skirtingos audito patirtys lemia skirtingus įrodymų lūkesčius.

Stiprus DLP audito paketas apima taikymo sritį ir rizikos pareiškimą, klasifikavimo schemą, patvirtintus perdavimo metodus, DLP taisykles, išimčių patvirtinimus, žurnalų tvarkymo projektą, įspėjimų pirminio vertinimo procedūrą, incidentų pranešimo sprendimų medį, tiekėjų ir debesijos apskaitą, testavimo rezultatus ir taisomųjų veiksmų įrašus.

Dažnos DLP nesėkmės 2026 m.

Dažniausios DLP nesėkmės yra operacinės, o ne egzotiškos.

Pirma, klasifikavimas yra neprivalomas arba nenuoseklus. Žymos egzistuoja politikoje, tačiau naudotojai jų netaiko, sistemos jų neįgyvendina, o saugyklose yra metų metais kauptų nepaženklintų jautrių failų.

Antra, DLP amžinai veikia tik įspėjimų režimu. Tik įspėjimų režimas naudingas derinimo metu, tačiau aukštos rizikos konfidencialių klientų duomenų perdavimas į asmeninį el. paštą galiausiai turi būti blokuojamas, nebent yra patvirtinta išimtis.

Trečia, šešėlinė IT laikoma IT nepatogumu, o ne duomenų apsaugos rizika. Debesijos paslaugų naudojimo politika ir Debesijos paslaugų naudojimo politika-sme sukurtos tam, kad nepatvirtinti debesijos įrankiai būtų matomi, peržiūrimi ir taisomi.

Ketvirta, žurnalų nepakanka tyrimui. Jei saugumo komanda negali atkurti, kas pasiekė, bendrino, atsisiuntė, įkėlė ar pakeitė leidimus, organizacija negali patikimai įvertinti GDPR, NIS2 ar DORA pranešimo įpareigojimų.

Penkta, tiekėjai lieka už DLP modelio ribų. DORA Articles 28 to 30 finansų subjektams tai daro ypač pavojinga, tačiau problema paveikia kiekvieną sektorių. Sutartyse turi būti apibrėžtos duomenų vietos, prieiga, atkūrimas, grąžinimas, pagalba incidentų atveju, saugumo priemonės, subtiekimas ir audito teisės.

Šešta, reagavimas į incidentus neapima DLP scenarijų. Klaidingai nukreiptas el. laiškas, neautorizuotas SaaS įkėlimas arba masinis CRM eksportas turi turėti veiksmų planą, sunkumo kriterijus ir pranešimo sprendimo kelią.

Galiausiai organizacijos pamiršta fizinius ir žmogiškuosius kanalus. Zenith Blueprint primena, kad DLP apima švaraus darbo stalo elgseną, saugų dokumentų naikinimą, užrakintas spausdinimo eiles, spausdintuvų audito žurnalus ir darbuotojų sąmoningumą. DLP programa, ignoruojanti popierių, ekrano kopijas ir pokalbius, yra neišsami.

Sukurkite DLP programą, kuria auditoriai gali pasitikėti

Jei jūsų DLP programa šiuo metu yra tik įrankio konfigūracija, 2026 m. yra laikas ją paversti valdoma, įrodymais pagrįsta kontrolės sistema.

Pradėkite nuo trijų praktinių veiksmų:

1. Pasirinkite tris svarbiausius jautrių duomenų tipus, pavyzdžiui, klientų asmens duomenis, mokėjimų duomenis ir pirminį kodą.
2. Sužymėkite, kur jie juda, įskaitant el. paštą, SaaS, debesijos saugyklas, galinius įrenginius, taikomųjų programų sąsajas, tiekėjus ir kūrimo aplinkas.
3. Sukurkite po vieną įgyvendinamą DLP taisyklę kiekvienam duomenų tipui, susietą su politika, žurnalų tvarkymu, reagavimu į incidentus ir įrodymų saugojimu.

Clarysec gali padėti tai paspartinti naudojant Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planą Zenith Blueprint, Zenith Controls: kryžminės atitikties vadovą Zenith Controls ir pritaikymui parengtas politikas, tokias kaip Duomenų klasifikavimo ir ženklinimo politika Duomenų klasifikavimo ir ženklinimo politika, Nuotolinio darbo politika Nuotolinio darbo politika, Debesijos paslaugų naudojimo politika Debesijos paslaugų naudojimo politika, Žurnalų tvarkymo ir stebėsenos politika-sme Žurnalų tvarkymo ir stebėsenos politika - MVĮ ir Mobiliųjų įrenginių ir BYOD politika Mobiliųjų įrenginių ir BYOD politika.

Tikslas nėra sustabdyti kiekvieną failo judėjimą. Tikslas – kad saugus judėjimas būtų numatytasis, rizikingas judėjimas būtų matomas, draudžiamas judėjimas būtų blokuojamas, o kiekviena išimtis būtų atskaitinga.

Atsisiųskite Clarysec įrankių rinkinius, peržiūrėkite savo DLP įrodymų paketą ir rezervuokite pasirengimo vertinimą, kad nustatytumėte, ar dabartinės jūsų kontrolės priemonės gali atlaikyti GDPR Article 32 patikrą, NIS2 kibernetinės higienos lūkesčius ir DORA IRT rizikos peržiūrą.