DLP 2026. gadā: ISO 27001, GDPR, NIS2 un DORA prasību izpildei

Viss sākas ar izklājlapu.

Pirmdien plkst. 08.17 klientu attiecību vadītājs eksportē 14 000 uzņēmuma kontaktpersonu no CRM, lai sagatavotu līguma atjaunošanas kampaņu. Plkst. 08.24 izklājlapa tiek pievienota e-pastam. Plkst. 08.26 e-pasts tiek nosūtīts uz personīgu Gmail kontu, jo darbinieks vēlas strādāt vilcienā. Plkst. 08.31 tā pati datne tiek augšupielādēta neapstiprinātā MI piezīmju veikšanas pakalpojumā, lai “iztīrītu dublikātus”.

Pagaidām tas neizskatās pēc pārkāpuma. Nav izspiedējprogrammatūras paziņojuma, nav ļaunatūras signāla, nav kompromitēta administratora konta un nav publiskas noplūdes. Taču CISO, atbilstības vadītājam un DPO īstais jautājums jau ir klāt: vai organizācija var pierādīt, ka šāda datu kustība bija atļauta, klasificēta, reģistrēta žurnālos, šifrēta, pamatota un atsaucama?

Finanšu pakalpojumu nozarē šāds scenārijs atkārtojas katru nedēļu. Izstrādātājs mēģina augšupielādēt Q1_Investor_Projections_DRAFT.xlsx personīgajā mākoņkrātuvē, jo VPN darbojas lēni. Pārdošanas vadītājs eksportē klientu sarakstu uz patērētāju līmeņa sadarbības lietotni. Atbalsta analītiķis ielīmē klientu ierakstus neapstiprinātā MI rīkā. Katrā gadījumā nolūks var būt ērtība, nevis ļaunprātība, taču risks ir vienāds. Sensitīvi dati ir šķērsojuši vai gandrīz šķērsojuši robežu, kuru organizācija nekontrolē.

Tā ir mūsdienu datu noplūdes novēršanas problēma. DLP vairs nav tikai e-pasta vārtejas noteikums vai galiekārtas aģents. 2026. gadā efektīva datu noplūdes novēršana ir pārvaldīta, pierādījumos balstīta kontroles sistēma SaaS, mākoņkrātuvēs, galiekārtās, mobilajās ierīcēs, piegādātāju vidēs, lietojumprogrammu saskarnēs, izstrādes vidēs, rezerves kopiju eksportos, sadarbības rīkos un cilvēku radītos apiešanas ceļos.

GDPR Article 32 paredz atbilstošus tehniskos un organizatoriskos pasākumus apstrādes drošībai. NIS2 Article 21 paredz uz risku balstītus kiberdrošības pasākumus, tostarp kiberdrošības higiēnu, piekļuves kontroli, aktīvu pārvaldību, piegādes ķēdes drošību, incidentu apstrādi, šifrēšanu un efektivitātes testēšanu. DORA paredz, ka finanšu subjekti pārvalda IKT risku, izmantojot pārvaldību, atklāšanu, reaģēšanu, atjaunošanu, testēšanu, trešo pušu pārraudzību un auditējamību. ISO/IEC 27001:2022 nodrošina pārvaldības sistēmas pamatu, lai šos pienākumus padarītu operacionālus, izmērāmus un auditējamus.

Daudzu organizāciju kļūda ir DLP rīka iegāde pirms ir definēts, ko nozīmē “noplūde”. Clarysec pieeja sākas agrāk: klasificēt datus, definēt atļautos pārsūtīšanas ceļus, piemērot politiku, uzraudzīt izņēmumus, sagatavot reaģēšanas pierādījumus un sasaistīt visu ar informācijas drošības pārvaldības sistēmu (IDPS).

Kā Zenith Blueprint: auditora 30 soļu ceļvedis norāda fāzē “Kontroles pasākumi darbībā”, 19. solī “Tehnoloģiskie kontroles pasākumi I”:

Datu noplūdes novēršanas mērķis ir apturēt nesankcionētu vai nejaušu sensitīvas informācijas izpaušanu neatkarīgi no tā, vai tā notiek pa e-pastu, mākoņaugšupielādēs, pārnēsājamos datu nesējos vai pat ar aizmirstu izdruku. Kontrole 8.12 risina nepieciešamību uzraudzīt, ierobežot un reaģēt uz jebkuriem datiem, kas atstāj organizācijas uzticamības robežas, neatkarīgi no tā, vai tas notiek digitāli, fiziski vai cilvēka darbības rezultātā. Zenith Blueprint

Šis teikums ir DLP būtība 2026. gadā: uzraudzīt, ierobežot un reaģēt.

Kāpēc DLP tagad ir valdes līmeņa atbilstības jautājums

Valde parasti nejautā, vai DLP regulārā izteiksme atpazīst personas kodus. Tā jautā, vai organizācija var aizsargāt klientu uzticēšanos, turpināt darbību, izvairīties no regulatīvām sekām un pierādīt pienācīgu drošības līmeni, ja kaut kas noiet greizi.

Tieši šeit satiekas GDPR, NIS2 un DORA.

GDPR plaši attiecas uz automatizētu personas datu apstrādi, tostarp uz ES reģistrētiem pārziņiem un apstrādātājiem, kā arī ārpus ES esošām organizācijām, kas piedāvā preces vai pakalpojumus personām ES vai uzrauga viņu uzvedību. Tas plaši definē personas datus un aptver tādas darbības kā vākšana, glabāšana, izmantošana, izpaušana, dzēšana un iznīcināšana. Nesankcionēta personas datu izpaušana vai piekļuve tiem var būt personas datu aizsardzības pārkāpums. GDPR Article 5 arī skaidri nosaka pārskatatbildību: organizācijām ir ne tikai jāievēro tādi principi kā datu minimizēšana, glabāšanas ierobežošana, integritāte un konfidencialitāte, bet arī jāspēj pierādīt atbilstību.

NIS2 paplašina spiedienu ārpus privātuma jomas. Tā attiecas uz daudzām būtiskām un svarīgām vienībām, tostarp tādām nozarēm kā banku darbība, finanšu tirgus infrastruktūras, mākoņpakalpojumu sniedzēji, datu centru pakalpojumu sniedzēji, pārvaldīto pakalpojumu sniedzēji, pārvaldīto drošības pakalpojumu sniedzēji, tiešsaistes tirdzniecības vietas, meklētājprogrammas un sociālo tīklu platformas. Article 21 prasa atbilstošus un samērīgus tehniskos, operacionālos un organizatoriskos pasākumus, tostarp riska analīzi, informācijas sistēmu drošības politikas, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu izstrādi, efektivitātes testēšanu, kiberdrošības higiēnu, apmācību, kriptogrāfiju, piekļuves kontroli, aktīvu pārvaldību un autentifikāciju.

DORA piemēro no 2025. gada 17. janvāra, un tā ir finanšu sektoram specifisks IKT noturības regulējums. Attiecībā uz finanšu subjektiem, kas ietilpst tās darbības jomā, DORA pārklāšanās gadījumos tiek uzskatīta par nozarei specifisku Savienības tiesību aktu NIS2 izpratnē. DORA iekļauj DLP IKT risku pārvaldībā, incidentu klasificēšanā, datu zudumā, kas ietekmē pieejamību, autentiskumu, integritāti vai konfidencialitāti, digitālās darbības noturības testēšanā, IKT trešo pušu pārvaldībā un līgumiskajos kontroles pasākumos.

2026. gada DLP jautājums nav “Vai mums ir rīks?”. Tas ir:

2027. Vai mēs zinām, kura informācija ir sensitīva?

2028. Vai mēs zinām, kur tā tiek glabāta, apstrādāta un pārsūtīta?

2029. Vai atļautie un aizliegtie pārsūtīšanas ceļi ir definēti?

2030. Vai lietotāji ir apmācīti un tehniski ierobežoti?

2031. Vai mākoņpakalpojumu un SaaS maršruti tiek pārvaldīti?

2032. Vai žurnāli ir pietiekami izmeklēšanai?

2033. Vai brīdinājumi tiek ātri sākotnēji izvērtēti un incidenti klasificēti?

2034. Vai piegādātājiem un ārpakalpojuma IKT pakalpojumiem ir saistošas līgumiskās prasības?

2035. Vai mēs varam pierādīt, ka kontroles pasākumi darbojas?

ISO/IEC 27001:2022 ir labi piemērots, lai atbildētu uz šiem jautājumiem, jo tas prasa kontekstu, ieinteresēto pušu prasības, risku izvērtēšanu, riska apstrādi, izmērāmus mērķus, darbības kontroles pasākumus, dokumentētus pierādījumus, piegādātāju kontroli, iekšējo auditu, vadības pārskatīšanu un nepārtrauktu uzlabošanu. Tas nav DLP standarts, taču tas pārvērš DLP no izolētas tehnoloģijas konfigurācijas par kontrolētu pārvaldības sistēmas procesu.

ISO 27001 kontroles pasākumu ķēde efektīvai DLP

Uzticama DLP programma netiek veidota uz viena kontroles pasākuma. Tā tiek veidota kā ķēde.

Clarysec Zenith Controls: starpatbilstības ceļvedis kartē ISO/IEC 27002:2022 kontroli 8.12, Datu noplūdes novēršana, kā preventīvu un atklājošu kontroles pasākumu, kas vērsts uz konfidencialitāti, saskaņots ar kiberdrošības jēdzieniem Protect un Detect, ar informācijas aizsardzību kā darbības spēju un aizsardzību/aizsargāšanos kā drošības jomu. Zenith Controls

Tas ir būtiski, jo auditori sagaida gan bloķēšanu, gan redzamību. Preventīvs DLP noteikums bez brīdinājumu pārskatīšanas ir nepilnīgs. Arī pieeja, kas balstīta tikai uz žurnalēšanu un neparedz piemērošanu augsta riska pārsūtījumiem, ir vāja.

Tas pats ceļvedis kartē ISO/IEC 27002:2022 kontroli 5.12, Informācijas klasificēšana, kā preventīvu, konfidencialitāti, integritāti un pieejamību atbalstošu un ar Identify saskaņotu kontroles pasākumu. Tas kartē kontroli 5.14, Informācijas pārsūtīšana, kā preventīvu, konfidencialitāti, integritāti un pieejamību atbalstošu un ar Protect, Aktīvu pārvaldību un Informācijas aizsardzību saskaņotu kontroles pasākumu.

Praksē DLP kontroles pasākumu ķēde izskatās šādi:

Zenith Blueprint, 22. solis, skaidro atkarību starp aktīvu uzskaiti, klasifikāciju un DLP:

Pārskatiet pašreizējo aktīvu uzskaiti (5.9), lai nodrošinātu, ka tajā ir iekļauti gan fiziskie, gan loģiskie aktīvi, īpašnieki un klasifikācijas. Sasaistiet šo uzskaiti ar klasificēšanas shēmu (5.12), nodrošinot, ka sensitīvie aktīvi ir marķēti un atbilstoši aizsargāti. Ja nepieciešams, definējiet glabāšanu, rezerves kopiju veidošanu vai izolāciju, balstoties uz klasifikāciju.

Tāpēc Clarysec reti sāk DLP projektu ar noteikumu pielāgošanu. Mēs sākam ar aktīvu, īpašnieku, datu tipu, klasifikācijas marķējumu, pārsūtīšanas ceļu un pierādījumu ierakstu saskaņošanu. Ja organizācija nevar pateikt, kuras datu kopas ir konfidenciālas, reglamentētas, klienta īpašumā, saistītas ar maksājumiem vai darbībai kritiskas, DLP rīks var tikai minēt.

Mūsdienīgas DLP programmas trīs pīlāri

Mūsdienīga DLP programma balstās uz trim savstarpēji pastiprinošiem pīlāriem: zināt datus, pārvaldīt plūsmu un aizsargāt robežu. Šie pīlāri padara ISO/IEC 27001:2022 praktiski izmantojamu GDPR, NIS2 un DORA atbilstībai.

1. pīlārs: ziniet savus datus, izmantojot klasifikāciju un marķēšanu

Nav iespējams aizsargāt to, ko nesaprotat. ISO/IEC 27002:2022 kontroles pasākumi 5.12 un 5.13 prasa organizācijām klasificēt informāciju un marķēt to atbilstoši sensitivitātei un apstrādes prasībām. Tas nav dokumentu sagatavošanas vingrinājums. Tas ir automatizētas piemērošanas pamats.

MVU vajadzībām Datu klasifikācijas un marķēšanas politika nosaka:

Konfidenciāls: nepieciešama šifrēšana pārsūtē un glabāšanā, ierobežota piekļuve, skaidrs apstiprinājums koplietošanai un droša iznīcināšana likvidēšanas brīdī. Datu klasifikācijas un marķēšanas politika - MVU

Šis citāts no sadaļas “Politikas ieviešanas prasības”, punkts 6.3.3, DLP programmai dod četrus piemērojamus nosacījumus: šifrēšana, ierobežota piekļuve, koplietošanas apstiprinājums un droša likvidēšana.

Uzņēmuma vidēs Datu klasifikācijas un marķēšanas politika ir vēl tiešāka. No sadaļas “Politikas ieviešanas prasības”, punkts 6.2.6.2:

Pārsūtīšanas bloķēšana (piemēram, ārējs e-pasts) neatbilstoši marķētiem sensitīviem datiem Datu klasifikācijas un marķēšanas politika

Un no sadaļas “Ievērošana un atbilstība”, punkts 8.3.2:

Automatizēta klasifikācijas validācija, izmantojot datu noplūdes novēršanu (DLP) un datu atklāšanas rīkus

Šie punkti pārvērš klasifikāciju par kontroles pasākumu. Datne, kas marķēta kā konfidenciāla, var ierosināt šifrēšanu, bloķēt ārēju pārsūtīšanu, pieprasīt apstiprinājumu vai ģenerēt drošības brīdinājumu. DLP tad kļūst par politikas piemērošanas slāni, ko saprot lietotāji, sistēmas un auditori.

2. pīlārs: pārvaldiet plūsmu ar drošu informācijas pārsūtīšanu

Kad dati ir klasificēti, organizācijai jāpārvalda, kā tie pārvietojas. ISO/IEC 27002:2022 kontrole 5.14, Informācijas pārsūtīšana, bieži tiek nepietiekami novērtēta, taču tieši tur sākas daudzas DLP neveiksmes.

Zenith Blueprint formulē kontroli 5.14 kā nepieciešamību pārvaldīt informācijas plūsmu tā, lai pārsūtīšana būtu droša, mērķtiecīga un atbilstu klasifikācijai un uzņēmējdarbības mērķim. Tas attiecas uz e-pastu, drošu failu koplietošanu, lietojumprogrammu saskarnēm, SaaS integrācijām, noņemamiem datu nesējiem, drukātām atskaitēm un piegādātāju portāliem.

Attālināts darbs to padara īpaši svarīgu. Attālinātā darba politika, sadaļa “Politikas ieviešanas prasības”, punkts 6.3.1.3, prasa darbiniekiem:

Izmantot tikai apstiprinātus failu koplietošanas risinājumus (piemēram, M365, Google Workspace ar datu noplūdes novēršanas (DLP) kontroles pasākumiem) Attālinātā darba politika

Mobilajām ierīcēm un BYOD Mobilo ierīču un BYOD politika, sadaļa “Politikas ieviešanas prasības”, punkts 6.6.4, sniedz konkrētu galiekārtu līmeņa piemērošanu:

Datu noplūdes novēršanas (DLP) politikām jābloķē nesankcionētas augšupielādes, ekrānuzņēmumi, starpliktuves piekļuve vai datu koplietošana no pārvaldītajām lietotnēm uz personīgajām zonām. Mobilo ierīču un BYOD politika

Tas ir būtiski, jo dati neatstāj vidi tikai pa e-pastu. Tie aizplūst caur ekrānuzņēmumiem, starpliktuves sinhronizāciju, nepārvaldītiem pārlūkprogrammu profiliem, personīgajām krātuvēm, mobilo koplietošanas izvēlnēm, sadarbības spraudņiem un MI rīkiem.

Tikpat svarīga ir mākoņpakalpojumu pārvaldība. MVU Mākoņpakalpojumu izmantošanas politika-sme, sadaļa “Pārvaldības prasības”, punkts 5.5:

Ēnu IT (Shadow IT), kas definēta kā neapstiprinātu mākoņrīku izmantošana, jāuzskata par politikas pārkāpumu, un GM un IT pakalpojumu sniedzējam tā jāpārskata, lai noteiktu risku un nepieciešamos trūkumu novēršanas pasākumus. Mākoņpakalpojumu izmantošanas politika-sme - MVU

Uzņēmuma organizācijām Mākoņpakalpojumu izmantošanas politika, sadaļa “Pārvaldības prasības”, punkts 5.5, paaugstina uzraudzības prasību līmeni:

Informācijas drošības komandai regulāri jāizvērtē tīkla datplūsma, DNS aktivitāte un žurnāli, lai atklātu nesankcionētu mākoņpakalpojumu izmantošanu (ēnu IT). Konstatētie pārkāpumi nekavējoties jāizmeklē. Mākoņpakalpojumu izmantošanas politika

Ēnu IT nav tikai IT neērtība. Saskaņā ar GDPR tā var kļūt par nelikumīgu izpaušanu vai nekontrolētu apstrādi. Saskaņā ar NIS2 tas ir kiberdrošības higiēnas un piegādes ķēdes vājums. Saskaņā ar DORA tas var kļūt par IKT trešo pušu risku un incidentu klasifikācijas jautājumu.

3. pīlārs: aizsargājiet robežu ar DLP tehnoloģiju, politiku un informētību

ISO/IEC 27002:2022 kontrole 8.12, Datu noplūdes novēršana, ir kontroles pasākums, ar kuru vairums cilvēku saista DLP. Taču nobriedušā programmā tā ir pēdējā aizsardzības līnija, nevis pirmā.

Zenith Blueprint skaidro, ka DLP prasa trīsslāņu pieeju: tehnoloģiju, politiku un informētību. Tehnoloģija ietver galiekārtu DLP, e-pasta drošību, satura pārbaudi, mākoņpiekļuves drošību, SaaS kontroles pasākumus, pārlūkprogrammu kontroles pasākumus, tīkla izejošās datplūsmas filtrēšanu un brīdinājumu maršrutēšanu. Politika nosaka, ko rīki piemēro. Informētība nodrošina, ka darbinieki saprot, kāpēc personīgais e-pasts, patērētāju mākoņkrātuves un neapstiprināti MI rīki nav pieņemamas apstrādes metodes reglamentētai vai konfidenciālai informācijai.

Reaģēšanas komponents ir tikpat svarīgs kā preventīvie pasākumi. Zenith Blueprint, 19. solis, nosaka:

Taču DLP nav tikai novēršana — tā ir arī reaģēšana. Ja tiek atklāta iespējama noplūde:

✓ brīdinājumi ātri jāizvērtē, ✓ žurnalēšanai jāatbalsta digitālā ekspertīze, ✓ incidentu reaģēšanas plāns jāaktivizē bez kavēšanās.

DLP programma, kas bloķē notikumus, bet tos sākotnēji neizvērtē, neizmeklē un no tiem nemācās, nav gatava auditam. Tā ir tikai daļēji ieviesta.

No izklājlapas noplūdes līdz auditam gatavai reaģēšanai

Atgriezīsimies pie pirmdienas rīta izklājlapas.

Vājā programmā organizācija augšupielādi atklāj trīs nedēļas vēlāk privātuma pārskatīšanas laikā. Neviens nezina, kurš apstiprināja eksportu, vai dati bija personas dati, vai bija iesaistīti īpašu kategoriju dati, vai MI rīks saglabāja datni un vai klienti ir jāinformē.

Clarysec izstrādātā programmā secība ir citāda.

Pirmkārt, CRM eksportam tiek piešķirts marķējums “Konfidenciāls”, jo tas satur personas datus un klientu komerciālo informāciju. Otrkārt, eksporta notikums tiek reģistrēts žurnālā. Treškārt, e-pasta vārteja atklāj konfidenciālu pielikumu, kas tiek sūtīts uz personīgu e-pasta domēnu, un bloķē to, ja nav apstiprināta izņēmuma. Ceturtkārt, mēģinājums augšupielādēt neapstiprinātā mākoņpakalpojumā ierosina mākoņpakalpojumu izmantošanas brīdinājumu. Piektkārt, brīdinājums tiek sākotnēji izvērtēts atbilstoši incidentu reaģēšanas procedūrai. Sestkārt, drošības komanda nosaka, vai bija faktiska izpaušana, vai dati bija šifrēti, vai pakalpojumu sniedzējs tos apstrādāja vai saglabāja, vai ir izpildīti GDPR pārkāpuma kritēriji un vai piemērojami NIS2 vai DORA incidenta sliekšņi.

MVU Žurnalēšanas un uzraudzības politika, sadaļa “Pārvaldības prasības”, punkts 5.4.3, komandai precīzi norāda, kam jābūt redzamam:

Piekļuves žurnāli: piekļuve datnēm (īpaši sensitīviem vai personas datiem), piekļuves tiesību izmaiņas, koplietoto resursu izmantošana Žurnalēšanas un uzraudzības politika - MVU

Šis punkts ir īss, bet izšķirošs. Ja piekļuve datnēm, piekļuves tiesību izmaiņas un koplietoto resursu izmantošana netiek reģistrēta žurnālos, DLP izmeklēšana kļūst par minēšanu.

Saskaņā ar NIS2 Article 23 būtiskiem incidentiem ir nepieciešama pakāpeniska ziņošana: agrīns brīdinājums 24 stundu laikā pēc informētības par incidentu, incidenta paziņojums 72 stundu laikā un galīgais ziņojums ne vēlāk kā vienu mēnesi pēc incidenta paziņojuma. Saskaņā ar DORA Articles 17 to 19 finanšu subjektiem jāatklāj, jāpārvalda, jāklasificē, jāreģistrē, jāeskalē un jāziņo par būtiskiem ar IKT saistītiem incidentiem. Klasifikācijā ietilpst datu zudums, kas ietekmē pieejamību, autentiskumu, integritāti vai konfidencialitāti, kā arī ietekmētie klienti, ilgums, ģeogrāfiskais tvērums, kritiskums un ekonomiskā ietekme. Saskaņā ar GDPR nesankcionēta personas datu izpaušana var prasīt pārkāpuma izvērtēšanu un, ja sliekšņi ir sasniegti, paziņošanu.

Tāpēc DLP brīdinājums nav tikai drošības notikums. Tas var kļūt par privātuma pārkāpuma izvērtēšanu, NIS2 incidenta darbplūsmu, DORA IKT incidenta klasifikāciju, klientu paziņošanas ierosinātāju un audita pierādījumu pakotni.

DLP kontroles pasākumi GDPR Article 32 vajadzībām

GDPR Article 32 bieži tiek pārvērsts pasākumu sarakstā: šifrēšana, konfidencialitāte, integritāte, pieejamība, noturība, testēšana un atjaunošana. DLP gadījumā būtiskākais ir aizsardzība visā dzīves ciklā.

Personas dati pārvietojas caur vākšanu, glabāšanu, izmantošanu, pārsūtīšanu, izpaušanu, glabāšanu un dzēšanu. GDPR Article 5 prasa datu minimizēšanu, nolūka ierobežošanu, glabāšanas ierobežošanu, integritāti, konfidencialitāti un pārskatatbildību. GDPR Article 6 prasa tiesisko pamatu un nolūka savietojamību. GDPR Article 9 prasa stingrākus drošības pasākumus īpašām personas datu kategorijām.

DLP atbalsta šos pienākumus, ja tā ir sasaistīta ar datu klasifikāciju, likumīgas apstrādes ierakstiem un apstiprinātiem pārsūtīšanas ceļiem.

Clarysec Datu maskēšanas un pseidonimizācijas politika-sme, sadaļa “Mērķis”, punkts 1.2, atbalsta šo dzīves cikla pieeju:

Šīs metodes ir obligātas, ja darbības vidē izmantotie dati nav nepieciešami, tostarp izstrādē, analītikā un trešo pušu pakalpojumu scenārijos, lai samazinātu ekspozīcijas, nepareizas lietošanas vai pārkāpuma risku. Datu maskēšanas un pseidonimizācijas politika-sme - MVU

Tas ir praktisks GDPR Article 32 kontroles pasākums. Ja izstrādātājiem, analītiķiem vai piegādātājiem nav nepieciešami darbības vidē izmantotie personas dati, DLP nedrīkst būt vienīgā barjera. Maskēšana un pseidonimizācija samazina ietekmes zonu vēl pirms datu pārvietošanas.

Spēcīgai ar privātumu saskaņotai DLP matricai jākartē personas datu tipi uz klasifikācijas marķējumiem, tiesisko pamatu, apstiprinātajām sistēmām, apstiprinātajām eksporta metodēm, šifrēšanas prasībām, DLP noteikumiem, glabāšanas noteikumiem un incidentu ierosinātājiem. Šī matrica kļūst par tiltu starp privātuma pārvaldību un drošības operācijām.

NIS2 kiberdrošības higiēna un DLP ārpus privātuma komandas

NIS2 maina DLP sarunu, jo tā uzskata noplūdi par kiberdrošības higiēnas un noturības daļu, nevis tikai par privātuma jautājumu.

Article 20 prasa būtisko un svarīgo vienību vadības struktūrām apstiprināt kiberdrošības risku pārvaldības pasākumus, pārraudzīt to ieviešanu un saņemt kiberdrošības apmācību. Article 21 prasa atbilstošus un samērīgus pasākumus politikās, incidentu apstrādē, nepārtrauktībā, piegādes ķēdē, drošā izstrādē, efektivitātes testēšanā, kiberdrošības higiēnā, apmācībā, kriptogrāfijā, personāla drošībā, piekļuves kontrolē un aktīvu pārvaldībā. Article 25 veicina attiecīgu Eiropas un starptautisko standartu un tehnisko specifikāciju izmantošanu.

DLP tieši veicina šīs jomas:

Tīkla drošības politika-sme, sadaļa “Mērķi”, punkts 3.4, skaidri nosaka datu neatļautas izneses mērķi:

Novērst ļaunatūras izplatīšanos un datu neatļautu iznesi caur tīkla kanāliem Tīkla drošības politika-sme - MVU

NIS2 kontekstā šāda veida mērķis auditoriem dod tiešu testēšanas ceļu: parādiet izejošās datplūsmas filtrēšanu, DNS uzraudzību, starpniekserveru žurnālus, galiekārtu brīdinājumus, bloķētus augšupielādes mēģinājumus un izmeklēšanas pieteikumus.

Zenith Blueprint, 23. solis, pievieno mākoņpakalpojumiem specifisku darbību, kas tagad ir būtiska NIS2 tvērumā esošiem digitālajiem un IKT pakalpojumu sniedzējiem:

Uzskaitiet visus pašlaik izmantotos mākoņpakalpojumus (5.23), tostarp zināmo ēnu IT. Nosakiet, kurš tos apstiprināja un vai tika veikta sākotnējā izpēte. Izstrādājiet vienkāršotu izvērtēšanas kontrolsarakstu, kas aptver datu atrašanās vietu, piekļuves modeli, žurnalēšanu un šifrēšanu. Nākamajiem pakalpojumiem nodrošiniet, ka kontrolsaraksts ir integrēts iepirkuma vai IT ieviešanas procesā.

Daudzas organizācijas šeit kļūdās. Tām ir IDPS darbības joma un piegādātāju reģistrs, bet nav īsta SaaS rīku saraksta, kur darbinieki pārvieto reglamentētus vai klientu datus. DLP bez mākoņpakalpojumu atklāšanas ir akla.

DORA IKT risks: DLP finanšu subjektiem un pakalpojumu sniedzējiem

Finanšu subjektiem DLP jāiekļaujas DORA IKT risku pārvaldības ietvarā.

DORA Article 5 prasa iekšēju pārvaldības un kontroles ietvaru IKT risku pārvaldībai. Vadības struktūra paliek atbildīga par IKT risku, politikām, kas saglabā datu pieejamību, autentiskumu, integritāti un konfidencialitāti, skaidrām IKT lomām, digitālās darbības noturības stratēģiju, IKT riska toleranci, nepārtrauktības un reaģēšanas/atjaunošanas plāniem, audita plāniem, resursiem, trešo pušu politiku un ziņošanas kanāliem.

Article 6 prasa dokumentētu IKT risku pārvaldības ietvaru, kas aptver stratēģijas, politikas, procedūras, IKT protokolus un rīkus informācijas un IKT aktīvu aizsardzībai. Article 9 attiecas uz aizsardzību un novēršanu. Articles 11 to 14 papildina prasības ar nepārtrauktību, reaģēšanu, atjaunošanu, rezerves kopiju veidošanu, atjaunošanu, datu integritātes pārbaudēm, gūtajām mācībām, informētības apmācību un krīzes komunikāciju.

DLP iekļaujas šajā ietvarā kā aizsardzības, atklāšanas, reaģēšanas un testēšanas spēja.

DORA arī padara trešo pušu risku neizbēgamu. Articles 28 to 30 prasa IKT trešo pušu risku pārvaldību, IKT pakalpojumu līgumu reģistrus, pirmslīguma sākotnējo izpēti, līgumiskās prasības, audita un pārbaudes tiesības, izbeigšanas tiesības, izstāšanās stratēģijas, pakalpojumu aprakstus, datu apstrādes un glabāšanas vietas, piekļuvi datiem, atjaunošanu un atdošanu, incidentu atbalstu, sadarbību ar iestādēm, drošības pasākumus un apakšuzņēmēju nosacījumus.

Fintech uzņēmumam vai bankai DLP nedrīkst apstāties pie Microsoft 365 vai Google Workspace robežas. Tai jāaptver maksājumu apstrādātāji, identitātes verifikācijas pakalpojumu sniedzēji, CRM platformas, datu noliktavas, mākoņinfrastruktūra, ārpakalpojuma atbalsta dienesti, pārvaldīto pakalpojumu sniedzēji un kritiskas SaaS integrācijas.

Tas ir īpaši svarīgi gadījumos, kad DORA darbojas kā nozarei specifisks Savienības tiesību akts pārklājošiem NIS2 pienākumiem. Kontroles pasākumiem joprojām jāpastāv. Ziņošanas un uzraudzības ceļš var atšķirties.

90 minūšu DLP noteikuma sprints

Clarysec izmanto praktisku sprintu ar klientiem, kuriem nepieciešams straujš progress, neradot ilūziju, ka pilnu DLP programmu var izveidot vienā sanāksmē. Mērķis ir ieviest vienu augstas vērtības DLP kontroles pasākumu no politikas līdz pierādījumiem.

1. solis: izvēlieties vienu datu tipu un vienu pārsūtīšanas ceļu

Izvēlieties “klienta personas dati, kas eksportēti no CRM un ārēji nosūtīti pa e-pastu”. Nesāciet ar katru repozitoriju, valsti un datu tipu.

2. solis: apstipriniet klasifikāciju un marķējumu

Izmantojiet klasifikācijas politiku, lai apstiprinātu, ka šis eksports ir konfidenciāls. MVU gadījumā punkts 6.3.3 prasa šifrēšanu, ierobežotu piekļuvi, skaidru apstiprinājumu koplietošanai un drošu iznīcināšanu. Uzņēmuma vidē Datu klasifikācijas un marķēšanas politika atbalsta pārsūtīšanas bloķēšanu neatbilstoši marķētiem sensitīviem datiem un automatizētu validāciju, izmantojot DLP un datu atklāšanas rīkus.

3. solis: definējiet atļauto pārsūtīšanas modeli

Atļauts: CRM eksports tiek nosūtīts uz apstiprinātu klienta domēnu, izmantojot šifrētu e-pastu vai apstiprinātu drošu failu pārsūtīšanas platformu, ar uzņēmējdarbības pamatojumu.

Nav atļauts: personīgais e-pasts, publiskas failu koplietošanas saites, neapstiprināti MI rīki un nepārvaldītas mākoņkrātuves.

Tas atbilst Zenith Blueprint, 22. solim, kurā teikts:

Ja “Konfidenciālai” informācijai nav atļauts atstāt uzņēmumu bez šifrēšanas, e-pasta sistēmām jāpiemēro šifrēšanas politikas vai jābloķē ārēja pārsūtīšana.

4. solis: konfigurējiet minimālo DLP noteikumu

Konfigurējiet e-pasta vai sadarbības platformu, lai tā atklātu konfidenciālo marķējumu, personas datu modeli vai eksporta datnes nosaukuma konvenciju. Sāciet ar uzraudzību, ja sagaidāmi kļūdaini pozitīvi gadījumi, pēc tam pārejiet uz bloķēšanu personīgajiem domēniem un neapstiprinātiem saņēmējiem.

5. solis: iespējojiet žurnalēšanu un brīdinājumu maršrutēšanu

Nodrošiniet, lai žurnāli fiksē piekļuvi datnēm, piekļuves tiesību izmaiņas un koplietoto resursu izmantošanu, kā to prasa Žurnalēšanas un uzraudzības politika - MVU. Maršrutējiet brīdinājumus uz pieteikumu rindu, norādot smaguma pakāpi, datu tipu, sūtītāju, saņēmēju, datnes nosaukumu, veikto darbību un pārskatītāju.

6. solis: testējiet trīs scenārijus

Testējiet apstiprinātu šifrētu pārsūtīšanu klientam, bloķētu pārsūtīšanu uz personīgo e-pastu un tikai brīdinājuma režīma augšupielādes mēģinājumu uz neapstiprinātu mākoņdomēnu.

7. solis: saglabājiet pierādījumus

Saglabājiet politikas punkta atsauci, DLP noteikuma ekrānuzņēmumu, testēšanas rezultātus, brīdinājuma pieteikumu, pārskatītāja lēmumu un vadības apstiprinājumu. Pievienojiet kontroles pasākumu risku apstrādes plānam un Piemērojamības paziņojumam.

ISO/IEC 27001:2022 izpratnē šis vingrinājums sasaista Clause 6.1.2 risku izvērtēšanu, Clause 6.1.3 riska apstrādi, Clause 8 darbības plānošanu un kontroli, Annex A informācijas pārsūtīšanu, datu noplūdes novēršanu, žurnalēšanu, uzraudzību, piegādātāju un mākoņpakalpojumu kontroles pasākumus un Clause 9 veiktspējas izvērtēšanu.

Starpatbilstības kartējums: viena DLP programma, vairāki pienākumi

Clarysec pieejas stiprā puse ir tā, ka tā izvairās no atsevišķu kontroles steku veidošanas GDPR, NIS2, DORA, NIST un COBIT vajadzībām. Viena labi izstrādāta DLP programma var apmierināt vairākas prasības, ja pierādījumi ir pareizi strukturēti.

NIST CSF 2.0 ir noderīgs kā komunikācijas slānis. Tā GOVERN funkcija atbalsta tiesisko, regulatīvo un līgumisko prasību izsekošanu, riska apetīti, politikas piemērošanu, lomas un pārraudzību. Tā profilu metode palīdz organizācijām noteikt pašreizējo un mērķa drošības stāvokļa tvērumu, dokumentēt trūkumus un ieviest rīcības plānu. Tā RESPOND un RECOVER funkcijas atbalsta DLP incidentu ierobežošanu, pamatcēloņa analīzi, pierādījumu saglabāšanu un atjaunošanu.

COBIT 2019 pievieno pārvaldības perspektīvu. COBIT orientēts auditors jautās, vai DLP mērķi ir saskaņoti ar uzņēmuma mērķiem, vai īpašumtiesības ir skaidras, vai ir veiktspējas rādītāji, vai ir definēta riska apetīte un vai vadība saņem jēgpilnus pārskatus.

Kā auditori testēs jūsu DLP programmu

DLP auditi reti ir par vienu ekrānuzņēmumu. Atšķirīga audita pieredze rada atšķirīgas pierādījumu gaidas.

Spēcīga DLP audita pakotne ietver tvērumu un riska paziņojumu, klasificēšanas shēmu, apstiprinātās pārsūtīšanas metodes, DLP noteikumus, izņēmumu apstiprinājumus, žurnalēšanas dizainu, brīdinājumu sākotnējās izvērtēšanas procedūru, incidentu ziņošanas lēmumu koku, piegādātāju un mākoņpakalpojumu uzskaiti, testēšanas rezultātus un trūkumu novēršanas ierakstus.

Biežākās DLP neveiksmes 2026. gadā

Biežākās DLP neveiksmes ir operacionālas, nevis eksotiskas.

Pirmkārt, klasifikācija ir fakultatīva vai nekonsekventa. Marķējumi pastāv politikā, bet lietotāji tos nepiemēro, sistēmas tos neizmanto piemērošanai, un repozitorijos ir gadiem uzkrātas nemarķētas sensitīvas datnes.

Otrkārt, DLP pastāvīgi paliek tikai brīdinājumu režīmā. Tikai brīdinājumu režīms ir noderīgs pielāgošanas laikā, taču augsta riska personīgā e-pasta pārsūtījums ar konfidenciāliem klientu datiem ar laiku jābloķē, ja vien nav apstiprināta izņēmuma.

Treškārt, ēnu IT tiek uzskatīta par IT neērtību, nevis par datu aizsardzības risku. Mākoņpakalpojumu izmantošanas politika un Mākoņpakalpojumu izmantošanas politika-sme ir veidotas tā, lai neapstiprināti mākoņrīki būtu redzami, pārskatāmi un labojami.

Ceturtkārt, žurnāli nav pietiekami izmeklēšanai. Ja drošības komanda nevar rekonstruēt, kurš piekļuva, koplietoja, lejupielādēja, augšupielādēja vai mainīja piekļuves tiesības, organizācija nevar pārliecinoši izvērtēt GDPR, NIS2 vai DORA ziņošanas pienākumus.

Piektkārt, piegādātāji atrodas ārpus DLP modeļa. DORA Articles 28 to 30 to padara īpaši bīstamu finanšu subjektiem, taču problēma skar katru nozari. Līgumos jādefinē datu atrašanās vietas, piekļuve, atjaunošana, atdošana, incidentu atbalsts, drošības pasākumi, apakšuzņēmēji un audita tiesības.

Sestkārt, reaģēšana uz incidentiem neietver DLP scenārijus. Nepareizi adresētam e-pastam, nesankcionētai SaaS augšupielādei vai masveida CRM eksportam ir nepieciešama rokasgrāmata, smaguma pakāpes kritēriji un paziņošanas lēmumu ceļš.

Visbeidzot, organizācijas aizmirst fiziskos un cilvēku kanālus. Zenith Blueprint atgādina, ka DLP ietver tīra galda praksi, drošu smalcināšanu, bloķētas drukas rindas, printeru audita žurnālus un darbinieku informētību. DLP programma, kas ignorē papīru, ekrānuzņēmumus un sarunas, ir nepilnīga.

Izveidojiet DLP programmu, kurai auditori var uzticēties

Ja jūsu DLP programma pašlaik ir rīka konfigurācija, 2026. gads ir laiks to pārvērst par pārvaldītu, pierādījumos balstītu kontroles sistēmu.

Sāciet ar trim praktiskām darbībām:

1. Izvēlieties trīs svarīgākos sensitīvo datu tipus, piemēram, klientu personas datus, maksājumu datus un pirmkodu.
2. Kartējiet, kur tie pārvietojas, tostarp e-pastā, SaaS, mākoņkrātuvēs, galiekārtās, lietojumprogrammu saskarnēs, piegādātāju vidēs un izstrādes vidēs.
3. Izveidojiet vienu piemērojamu DLP noteikumu katram datu tipam, sasaistot to ar politiku, žurnalēšanu, reaģēšanu uz incidentiem un pierādījumu glabāšanu.

Clarysec var palīdzēt to paātrināt ar Zenith Blueprint: auditora 30 soļu ceļvedi Zenith Blueprint, Zenith Controls: starpatbilstības ceļvedi Zenith Controls un pielāgošanai gatavām politikām, piemēram, Datu klasifikācijas un marķēšanas politiku Datu klasifikācijas un marķēšanas politika, Attālinātā darba politiku Attālinātā darba politika, Mākoņpakalpojumu izmantošanas politiku Mākoņpakalpojumu izmantošanas politika, Žurnalēšanas un uzraudzības politiku-sme Žurnalēšanas un uzraudzības politika - MVU un Mobilo ierīču un BYOD politiku Mobilo ierīču un BYOD politika.

Mērķis nav apturēt katras datnes pārvietošanu. Mērķis ir padarīt drošu pārvietošanu par noklusējumu, riskantu pārvietošanu — redzamu, aizliegtu pārvietošanu — bloķētu un katru izņēmumu — pārskatatbildīgu.

Lejupielādējiet Clarysec rīkkopas, pārskatiet savu DLP pierādījumu pakotni un rezervējiet gatavības izvērtēšanu, lai noskaidrotu, vai pašreizējie kontroles pasākumi spēj izturēt GDPR Article 32 pārbaudi, NIS2 kiberdrošības higiēnas prasības un DORA IKT riska pārskatīšanu.