DLP 2026-ban: ISO 27001 a GDPR, NIS2 és DORA megfeleléshez
Egy táblázattal kezdődik.
Hétfőn 08:17-kor egy ügyfélsiker-menedzser 14 000 vállalati kapcsolattartót exportál a CRM-ből egy megújítási kampány előkészítéséhez. 08:24-kor a táblázat e-mail-mellékletként jelenik meg. 08:26-kor az e-mail egy személyes Gmail-fiókba kerül, mert a munkavállaló a vonatúton szeretne dolgozni. 08:31-kor ugyanazt a fájlt feltölti egy nem engedélyezett AI-alapú jegyzetelő szolgáltatásba, hogy „eltávolítsa a duplikációkat”.
Még semmi sem tűnik incidensnek. Nincs zsarolóvírus-üzenet, nincs kártevőhöz kapcsolódó beacon-forgalom, nincs kompromittálódott rendszergazdai fiók, és nincs nyilvános kiszivárgás. A CISO, a megfelelőségi vezető és az adatvédelmi tisztviselő (DPO) számára azonban a valódi kérdés már felmerült: igazolni tudja-e a szervezet, hogy ez az adatmozgás engedélyezett, osztályozott, naplózott, titkosított, indokolt és visszafordítható volt?
Ugyanez a forgatókönyv hetente lejátszódik a pénzügyi szolgáltatásokban. Egy fejlesztő megpróbálja feltölteni a Q1_Investor_Projections_DRAFT.xlsx fájlt egy személyes felhőmeghajtóra, mert a VPN lassú. Egy értékesítési vezető ügyféllistát exportál egy fogyasztói együttműködési alkalmazásba. Egy támogatási elemző ügyfélnyilvántartásokat illeszt be egy nem engedélyezett AI-eszközbe. A szándék minden esetben lehet kényelem, nem rosszindulat, de a kockázat ugyanaz. Az érzékeny adatok átléptek, vagy majdnem átléptek egy olyan határt, amelyet a szervezet nem felügyel.
Ez a modern adatvesztés-megelőzési probléma. A DLP már nem csupán egy e-mail-átjárószabály vagy egy végponti ügynök. 2026-ban a hatékony adatvesztés-megelőzés irányított, bizonyítékokkal alátámasztott kontrollrendszer a SaaS, a felhőalapú tárhelyek, a végpontok, a mobileszközök, a beszállítók, az API-k, a fejlesztési környezetek, a biztonságimentés-exportok, az együttműködési eszközök és az emberi kerülőutak között.
A GDPR Article 32 megfelelő technikai és szervezési intézkedéseket vár el az adatkezelés biztonsága érdekében. A NIS2 Article 21 kockázatalapú kiberbiztonsági intézkedéseket vár el, beleértve a kiberhigiéniát, a hozzáférés-szabályozást, az eszközkezelést, az ellátásilánc-biztonságot, az incidenskezelést, a titkosítást és az eredményességi tesztelést. A DORA elvárja, hogy a pénzügyi szervezetek az IKT-kockázatot irányítással, észleléssel, reagálással, helyreállítással, teszteléssel, harmadik felek felügyeletével és ellenőrizhetőséggel kezeljék. Az ISO/IEC 27001:2022 biztosítja azt az irányítási rendszerbeli gerincet, amely ezeket a kötelezettségeket működtethetővé, mérhetővé és auditálhatóvá teszi.
Sok szervezet ott hibázik, hogy DLP-eszközt vásárol, mielőtt meghatározná, mit jelent a „veszteség”. A Clarysec megközelítése korábban kezdődik: az adatok osztályozásával, az engedélyezett adattovábbítások meghatározásával, a szabályzat érvényesítésével, a kivételek nyomon követésével, a reagálási bizonyítékok előkészítésével, és mindezek IBIR-hez kapcsolásával.
Ahogy a Zenith Blueprint: An Auditor’s 30-Step Roadmap a Controls in Action szakasz Step 19, Technological Controls I részében fogalmaz:
Az adatszivárgás-megelőzés célja az érzékeny információk jogosulatlan vagy véletlen kiadásának megakadályozása, akár e-mailen, felhőfeltöltésen, hordozható adathordozón vagy akár egy ottfelejtett nyomtatványon keresztül történik. A 8.12 kontroll azt az igényt kezeli, hogy meg kell figyelni, korlátozni kell és reagálni kell minden olyan adatra, amely elhagyja a szervezet megbízható határait, függetlenül attól, hogy digitális, fizikai vagy emberi folyamatból ered. Zenith Blueprint
Ez a mondat a 2026-os DLP lényege: megfigyelés, korlátozás és reagálás.
Miért lett a DLP igazgatósági szintű megfelelőségi kérdés?
Az igazgatóság általában nem azt kérdezi, hogy egy DLP reguláris kifejezés felismeri-e a nemzeti azonosítószámokat. Azt kérdezi, hogy a szervezet képes-e megvédeni az ügyfélbizalmat, fenntartani a működést, elkerülni a szabályozói kitettséget, és igazolni az észszerű biztonságot, ha valami félremegy.
Itt ér össze a GDPR, a NIS2 és a DORA.
A GDPR széles körben alkalmazandó az automatizált személyesadat-kezelésre, beleértve az EU-ban letelepedett adatkezelőket és adatfeldolgozókat, valamint azokat a nem EU-s szervezeteket, amelyek árukat vagy szolgáltatásokat kínálnak az EU-ban tartózkodó személyeknek, vagy megfigyelik a viselkedésüket. A személyes adat fogalmát szélesen határozza meg, és lefedi többek között a gyűjtést, tárolást, felhasználást, közlést, törlést és megsemmisítést. A személyes adatok jogosulatlan közlése vagy az azokhoz való hozzáférés személyesadat-sértésnek minősülhet. A GDPR Article 5 az elszámoltathatóságot is kifejezetten rögzíti: a szervezeteknek nemcsak olyan elveket kell követniük, mint az adattakarékosság, a tárolási korlátozás, a sértetlenség és a bizalmasság, hanem a megfelelést igazolniuk is kell.
A NIS2 a nyomást az adatvédelemnél szélesebb körre terjeszti ki. Számos alapvető és fontos szervezetre vonatkozik, többek között olyan ágazatokra, mint a banki szolgáltatások, a pénzügyi piaci infrastruktúrák, a felhőszolgáltatók, az adatközpont-szolgáltatók, a menedzselt szolgáltatók, a menedzselt biztonsági szolgáltatók, az online piacterek, a keresőmotorok és a közösségi hálózati platformok. Az Article 21 megfelelő és arányos technikai, működési és szervezési intézkedéseket követel meg, ideértve a kockázatelemzést, az információs rendszerek biztonsági szabályzatait, az incidenskezelést, az üzletmenet-folytonosságot, az ellátásilánc-biztonságot, a biztonságos fejlesztést, az eredményességi tesztelést, a kiberhigiéniát, a képzést, a kriptográfiát, a hozzáférés-szabályozást, az eszközkezelést és a hitelesítést.
A DORA 2025. január 17-től alkalmazandó, és a pénzügyi szektor dedikált IKT-reziliencia szabálykönyveként működik. A hatálya alá tartozó pénzügyi szervezeteknél a NIS2-vel átfedő célok tekintetében ágazatspecifikus uniós jogi aktusnak minősül. A DORA a DLP-t beemeli az IKT-kockázatkezelésbe, az incidensbesorolásba, a rendelkezésre állást, hitelességet, sértetlenséget vagy bizalmasságot érintő adatvesztés kezelésébe, a digitális működési reziliencia tesztelésébe, az IKT harmadik felek kezelésébe és a szerződéses kontrollokba.
A 2026-os DLP-kérdés nem az, hogy „van-e eszközünk?”. Hanem ez:
- Tudjuk-e, mely információk érzékenyek?
- Tudjuk-e, hol tároljuk, kezeljük és továbbítjuk őket?
- Meghatároztuk-e az engedélyezett és tiltott továbbítási útvonalakat?
- A felhasználók képzettek-e, és technikailag korlátozottak-e?
- A felhő- és SaaS-útvonalak irányítás alatt állnak-e?
- A naplók elegendők-e a kivizsgáláshoz?
- A riasztások triázsa és az incidensek besorolása gyorsan megtörténik-e?
- A beszállítókat és a kiszervezett IKT-szolgáltatásokat szerződés kötelezi-e?
- Tudjuk-e igazolni, hogy a kontrollok működnek?
Az ISO/IEC 27001:2022 alkalmas e kérdések megválaszolására, mert megköveteli a kontextust, az érdekelt felek követelményeit, a kockázatértékelést, a kockázatkezelést, a mérhető célkitűzéseket, az operatív kontrollt, a dokumentált bizonyítékokat, a beszállítói kontrollt, a belső auditot, a vezetőségi átvizsgálást és a folyamatos fejlesztést. Nem DLP-szabvány, de a DLP-t elszigetelt technológiai konfigurációból szabályozott irányítási rendszerfolyamattá alakítja.
Az ISO 27001 kontroll-lánc a hatékony DLP mögött
Egy hiteles DLP-program nem egyetlen kontrollra épül. Kontroll-láncra épül.
A Clarysec Zenith Controls: The Cross-Compliance Guide az ISO/IEC 27002:2022 8.12, adatszivárgás-megelőzés kontrollját bizalmasságra fókuszáló megelőző és észlelő kontrollként térképezi fel, amely a Protect és Detect kiberbiztonsági koncepciókhoz illeszkedik; működési képességként az információvédelemhez, biztonsági területként pedig a védelemhez kapcsolódik. Zenith Controls
Ez azért lényeges, mert az auditorok blokkolást és láthatóságot egyaránt elvárnak. Egy megelőző DLP-szabály riasztásfelülvizsgálat nélkül hiányos. Egy kizárólag naplózásra épülő megközelítés, amely a magas kockázatú adattovábbításokat nem kényszeríti ki, szintén gyenge.
Ugyanez az útmutató az ISO/IEC 27002:2022 5.12, információk osztályozása kontrollját megelőző kontrollként térképezi fel, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, és az Identify funkcióhoz illeszkedik. Az 5.14, információátvitel kontrollt megelőző kontrollként azonosítja, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, és a Protect, az eszközkezelés és az információvédelem területéhez illeszkedik.
Gyakorlati értelemben a DLP kontroll-lánc így néz ki:
| ISO/IEC 27002:2022 kontrollterület | DLP-szerep | Mi romlik el, ha hiányzik |
|---|---|---|
| 5.9 Információk és egyéb kapcsolódó eszközök nyilvántartása | Azonosítja az eszközöket, tulajdonosokat és adathelyeket | Az érzékeny adattárak a DLP-hatókörön kívül maradnak |
| 5.12 Információk osztályozása | Meghatározza az érzékenységet és a kezelési követelményeket | A DLP-szabályok véletlenszerűen blokkolnak, vagy nem veszik észre a kritikus adatokat |
| 5.13 Információk jelölése | Láthatóvá és gépileg feldolgozhatóvá teszi az osztályozást | A felhasználók és az eszközök nem tudják megkülönböztetni a nyilvános adatot a bizalmastól |
| 5.14 Információátvitel | Meghatározza a jóváhagyott átviteli útvonalakat és feltételeket | A munkatársak személyes e-mailt, fogyasztói felhőmeghajtót vagy nem felügyelt üzenetküldést használnak |
| 5.15–5.18 Hozzáférés-szabályozás, identitás, hitelesítés és hozzáférési jogosultságok | Korlátozza, ki férhet hozzá és exportálhat adatokat | A túlzott jogosultságok belső fenyegetési kockázatot és tömeges kinyerést tesznek lehetővé |
| 5.19–5.23 Beszállítói és felhőkontrollok | Irányítja a SaaS, a felhő és a kiszervezett adatkezelés használatát | Az adatok nem értékelt beszállítókon vagy árnyék-IT-n keresztül szivárognak |
| 5.24–5.28 Incidenskezelés | A DLP-riasztásokat reagálási intézkedésekké és bizonyítékokká alakítja | A riasztásokat figyelmen kívül hagyják, nem triázsolják, vagy nem jelenthetők időben |
| 5.31 és 5.34 Jogi, szabályozói, szerződéses és adatvédelmi kontrollok | A DLP-t a GDPR-hoz, szerződésekhez és ágazati szabályokhoz kapcsolja | A kontrollok nem fedik a valós kötelezettségeket |
| 8.12 Adatszivárgás-megelőzés | Megfigyeli, korlátozza és kezeli a kifelé irányuló adatmozgást | Az érzékeny információ észlelés vagy kontroll nélkül távozik |
| 8.15 Naplózás és 8.16 megfigyelési tevékenységek | Bizonyítékot és forenzikus láthatóságot biztosít | A szervezet nem tudja igazolni, mi történt |
| 8.24 Kriptográfia alkalmazása | Védi a továbbított és tárolt adatokat | A jóváhagyott adattovábbítások is olvasható adatokat tesznek ki |
A Zenith Blueprint Step 22 ismerteti az eszköznyilvántartás, az osztályozás és a DLP közötti függőséget:
Tekintse át a jelenlegi eszköznyilvántartást (5.9), hogy az tartalmazza mind a fizikai, mind a logikai eszközöket, a tulajdonosokat és az osztályozásokat. Kapcsolja ezt a nyilvántartást az osztályozási rendszerhez (5.12), biztosítva, hogy az érzékeny eszközök megfelelő címkézést és védelmet kapjanak. Szükség esetén határozza meg a megőrzést, a biztonsági mentést vagy az elkülönítést az osztályozás alapján.
Ezért a Clarysec ritkán kezdi a DLP-megbízást szabályhangolással. Az eszközök, tulajdonosok, adattípusok, osztályozási címkék, átviteli útvonalak és bizonyítéknyilvántartások összehangolásával kezdünk. Ha a szervezet nem tudja megmondani, mely adatkészletek bizalmasak, szabályozottak, ügyféltulajdonúak, fizetéshez kapcsolódók vagy üzletmenet-kritikusak, akkor egy DLP-eszköz legfeljebb találgatni tud.
A modern DLP-program három pillére
A modern DLP-program három egymást erősítő pilléren áll: az adatok ismerete, az adatáramlás irányítása és a határok védelme. Ezek a pillérek teszik az ISO/IEC 27001:2022 szabványt gyakorlati eszközzé a GDPR, NIS2 és DORA megfeleléshez.
1. pillér: ismerje az adatait osztályozással és jelöléssel
Nem lehet megvédeni azt, amit nem értünk. Az ISO/IEC 27002:2022 5.12 és 5.13 kontrolljai előírják, hogy a szervezetek az információkat érzékenységük és kezelési igényük szerint osztályozzák és jelöljék. Ez nem adminisztratív gyakorlat. Ez az automatizált betartatás alapja.
KKV-k esetében az Adatosztályozási és címkézési szabályzat kimondja:
Bizalmas: továbbítás és tárolás közben titkosítást, korlátozott hozzáférést, a megosztáshoz kifejezett jóváhagyást, valamint selejtezéskor biztonságos megsemmisítést igényel. Adatosztályozási és címkézési szabályzat – KKV
Ez az idézet a „Szabályzat végrehajtási követelményei” szakasz 6.3.3 pontjából négy kikényszeríthető feltételt ad a DLP-programnak: titkosítás, korlátozott hozzáférés, megosztási jóváhagyás és biztonságos megsemmisítés.
Vállalati környezetben az Adatosztályozási és címkézési szabályzat még közvetlenebb. A „Szabályzat végrehajtási követelményei” szakasz 6.2.6.2 pontja szerint:
Átvitel blokkolása (pl. külső e-mail) nem megfelelően jelölt érzékeny adatok esetén Adatosztályozási és címkézési szabályzat
A „Betartatás és megfelelés” szakasz 8.3.2 pontja pedig így rendelkezik:
Automatizált osztályozás-ellenőrzés adatvesztés-megelőzési (DLP) és feltáró eszközök használatával
Ezek a pontok az osztályozást kontrollá alakítják. Egy Bizalmas jelölésű fájl titkosítást indíthat, blokkolhatja a külső továbbítást, jóváhagyást követelhet meg, vagy biztonsági riasztást generálhat. Így a DLP egy olyan szabályzat érvényesítési rétegévé válik, amelyet a felhasználók, a rendszerek és az auditorok is értenek.
2. pillér: az adatáramlás irányítása biztonságos információátvitellel
Miután az adatok osztályozása megtörtént, a szervezetnek irányítania kell, hogyan mozognak. Az ISO/IEC 27002:2022 5.14, információátvitel kontrollját gyakran alulértékelik, pedig sok DLP-hiba itt kezdődik.
A Zenith Blueprint az 5.14 kontrollt úgy keretezi, mint az információáramlás irányításának szükségességét annak érdekében, hogy az átvitel biztonságos, szándékos, valamint az osztályozással és az üzleti céllal összhangban legyen. Ez vonatkozik az e-mailre, a biztonságos fájlmegosztásra, az API-kra, a SaaS-integrációkra, a cserélhető adathordozókra, a nyomtatott jelentésekre és a beszállítói portálokra.
A távmunka ezt különösen fontossá teszi. A Távmunka-szabályzat „Szabályzat végrehajtási követelményei” szakaszának 6.3.1.3 pontja előírja a munkavállalóknak, hogy:
Csak jóváhagyott fájlmegosztási megoldásokat használjanak (pl. M365, Google Workspace adatvesztés-megelőzési (DLP) kontrollokkal) Távmunka-szabályzat
Mobil és BYOD esetében a Mobileszköz- és BYOD-szabályzat „Szabályzat végrehajtási követelményei” szakaszának 6.6.4 pontja konkrét végponti betartatást ad:
Az adatvesztés-megelőzési (DLP) szabályzatoknak blokkolniuk kell a jogosulatlan feltöltéseket, képernyőképeket, vágólap-hozzáférést vagy adatmegosztást a felügyelt alkalmazásokból személyes területekre. Mobileszköz- és BYOD-szabályzat
Ez azért fontos, mert az adat nem csak e-mailen keresztül távozik. Távozik képernyőképeken, vágólap-szinkronizáción, nem felügyelt böngészőprofilokon, személyes meghajtókon, mobil megosztási funkciókon, együttműködési bővítményeken és AI-eszközökön keresztül is.
A felhőirányítás ugyanilyen fontos. A KKV-k számára készült Felhőszolgáltatások használatára vonatkozó szabályzat – KKV „Irányítási követelmények” szakaszának 5.5 pontja szerint:
Az árnyék-IT, azaz a nem engedélyezett felhőeszközök használata szabályzatsértésnek minősül, és az ügyvezetőnek, valamint az IT-szolgáltatónak felül kell vizsgálnia a kockázat és a szükséges helyesbítő intézkedés meghatározása érdekében. Felhőszolgáltatások használatára vonatkozó szabályzat – KKV
Vállalati szervezeteknél a Felhőszolgáltatások használatára vonatkozó szabályzat „Irányítási követelmények” szakaszának 5.5 pontja magasabbra teszi a felügyeleti elvárást:
Az információbiztonsági csapatnak rendszeresen értékelnie kell a hálózati forgalmat, a DNS-tevékenységet és a naplókat a jogosulatlan felhőhasználat (árnyék-IT) észlelése érdekében. Az észlelt szabálysértéseket haladéktalanul ki kell vizsgálni. Felhőszolgáltatások használatára vonatkozó szabályzat
Az árnyék-IT nem pusztán informatikai kellemetlenség. A GDPR alapján jogellenes közléssé vagy ellenőrizetlen adatkezeléssé válhat. A NIS2 alapján kiberhigiéniai és ellátásilánc-beli gyengeség. A DORA alapján IKT harmadik fél kockázattá és incidensbesorolási kérdéssé válhat.
3. pillér: a határ védelme DLP-technológiával, szabályzattal és tudatossággal
Az ISO/IEC 27002:2022 8.12, adatszivárgás-megelőzés az a kontroll, amelyet a legtöbben a DLP-vel azonosítanak. Egy érett programban azonban ez az utolsó védelmi vonal, nem az első.
A Zenith Blueprint szerint a DLP háromrétegű megközelítést igényel: technológia, szabályzat és tudatosság. A technológia magában foglalja a végponti DLP-t, az e-mail-biztonságot, a tartalomvizsgálatot, a felhőhozzáférés-biztonságot, a SaaS-kontrollokat, a böngészőkontrollokat, a hálózati kimenő forgalom szűrését és a riasztások továbbítását. A szabályzat határozza meg, mit érvényesítenek az eszközök. A tudatosság biztosítja, hogy a munkavállalók értsék, miért nem elfogadható kezelési mód a személyes e-mail, a fogyasztói felhőalapú tárhely és a nem engedélyezett AI-eszközök használata szabályozott vagy bizalmas információkhoz.
A reagálási komponens ugyanolyan fontos, mint a megelőzés. A Zenith Blueprint Step 19 kimondja:
A DLP azonban nem csak megelőzés, hanem reagálás is. Ha potenciális szivárgást észlelnek:
✓ A riasztásokat gyorsan triázsolni kell, ✓ A naplózásnak támogatnia kell a forenzikus elemzést, ✓ Az incidensreagálási tervet késedelem nélkül aktiválni kell.
Az a DLP-program, amely blokkol eseményeket, de nem triázsolja, nem vizsgálja ki és nem épít be tanulságokat, nem auditra felkészített. Csak részlegesen bevezetett.
Táblázatszivárgástól az auditra felkészített reagálásig
Térjünk vissza a hétfő reggeli táblázathoz.
Gyenge program esetén a szervezet három héttel később, egy adatvédelmi felülvizsgálat során fedezi fel a feltöltést. Senki sem tudja, ki hagyta jóvá az exportot, személyes adat volt-e benne, szerepelt-e benne különleges kategóriájú adat, megtartotta-e az AI-eszköz a fájlt, vagy értesíteni kell-e az ügyfeleket.
Egy Clarysec által tervezett programban a folyamat másképp néz ki.
Először a CRM-export Bizalmas címkét kap, mert személyes adatokat és ügyfélhez kapcsolódó kereskedelmi információkat tartalmaz. Másodszor az exportesemény naplózásra kerül. Harmadszor az e-mail-átjáró észleli, hogy bizalmas mellékletet küldenek személyes e-mail-domainre, és blokkolja azt, hacsak nincs jóváhagyott kivétel. Negyedszer a nem engedélyezett felhőszolgáltatásba történő feltöltési kísérlet felhőhasználati riasztást vált ki. Ötödször a riasztást az incidensreagálási eljárás alapján triázsolják. Hatodszor a biztonsági csapat megállapítja, történt-e tényleges közlés, titkosítva voltak-e az adatok, a szolgáltató kezelte-e vagy megtartotta-e azokat, teljesülnek-e a GDPR szerinti incidenskritériumok, és alkalmazandók-e NIS2 vagy DORA incidensküszöbök.
A KKV-k számára készült Naplózási és felügyeleti szabályzat „Irányítási követelmények” szakaszának 5.4.3 pontja pontosan meghatározza, minek kell láthatónak lennie:
Hozzáférési naplók: fájlhozzáférés (különösen érzékeny vagy személyes adatok esetén), jogosultságváltozások, megosztott erőforrások használata Naplózási és felügyeleti szabályzat – KKV
Ez a pont rövid, de döntő. Ha a fájlhozzáférés, a jogosultságváltozások és a megosztott erőforrások használata nincs naplózva, a DLP-vizsgálat találgatássá válik.
A NIS2 Article 23 alapján a jelentős incidensek szakaszos jelentést igényelnek: korai figyelmeztetést a tudomásszerzéstől számított 24 órán belül, incidensbejelentést 72 órán belül, és zárójelentést legkésőbb az incidensbejelentést követő egy hónapon belül. A DORA Articles 17 to 19 előírja a pénzügyi szervezeteknek a jelentős IKT-vonatkozású incidensek észlelését, kezelését, osztályozását, rögzítését, eszkalálását és jelentését. Az osztályozás kiterjed a rendelkezésre állást, hitelességet, sértetlenséget vagy bizalmasságot érintő adatvesztésre, valamint az érintett ügyfelekre, az időtartamra, a földrajzi kiterjedésre, a kritikusságra és a gazdasági hatásra. A GDPR alapján a személyes adatok jogosulatlan közlése incidensértékelést, a küszöbök teljesülése esetén pedig bejelentést igényelhet.
Egy DLP-riasztás ezért nem pusztán biztonsági esemény. Adatvédelmi incidensértékeléssé, NIS2 incidensmunkafolyamattá, DORA IKT-incidensbesorolássá, ügyfélértesítési kiváltó mechanizmussá és auditbizonyíték-csomaggá válhat.
DLP-kontrollok a GDPR Article 32 teljesítéséhez
A GDPR Article 32 gyakran intézkedéslistára fordítódik le: titkosítás, bizalmasság, sértetlenség, rendelkezésre állás, reziliencia, tesztelés és helyreállítás. A DLP szempontjából a kulcs az életciklus-szintű védelem.
A személyes adatok a gyűjtés, tárolás, felhasználás, továbbítás, közlés, megőrzés és törlés során mozognak. A GDPR Article 5 adattakarékosságot, célhoz kötöttséget, tárolási korlátozást, sértetlenséget, bizalmasságot és elszámoltathatóságot ír elő. A GDPR Article 6 jogalapot és célkompatibilitást követel meg. A GDPR Article 9 szigorúbb védelmi intézkedéseket vár el a személyes adatok különleges kategóriái esetében.
A DLP akkor támogatja ezeket a kötelezettségeket, ha kapcsolódik az adatosztályozáshoz, a jogszerű adatkezelési nyilvántartásokhoz és a jóváhagyott továbbítási útvonalakhoz.
| GDPR-szempont | DLP-megvalósítás | Megőrzendő bizonyíték |
|---|---|---|
| Személyes adatok adattakarékossága | Tömeges exportok vagy szükségtelen replikáció észlelése | Export-riasztások és kivételi indoklások |
| Sértetlenség és bizalmasság | Titkosítatlan bizalmas adatok külső megosztásának blokkolása | DLP-szabály, titkosítási követelmény és blokkolt esemény naplója |
| Célhoz kötöttség | Továbbítások korlátozása nem jóváhagyott elemző- vagy AI-eszközök felé | SaaS engedélyezési lista, DPIA vagy kockázati felülvizsgálati bejegyzés |
| Különleges kategóriájú adatok | Szigorúbb címkék és blokkolási szabályok alkalmazása | Osztályozási szabályok, hozzáférési felülvizsgálat és jóváhagyási munkafolyamat |
| Elszámoltathatóság | Bizonyítékok fenntartása riasztásokról, döntésekről és helyesbítő intézkedésekről | Incidensjegyek, auditnyom és vezetőségi átvizsgálási bejegyzések |
A Clarysec Adatmaszkolási és álnevesítési szabályzat – KKV „Cél” szakaszának 1.2 pontja támogatja ezt az életciklus-megközelítést:
Ezek a technikák kötelezőek, ahol éles adatokra nincs szükség, ideértve a fejlesztési, elemzési és harmadik fél szolgáltatási forgatókönyveket is, az adatkitettség, a visszaélés vagy az incidens kockázatának csökkentése érdekében. Adatmaszkolási és álnevesítési szabályzat – KKV
Ez gyakorlati GDPR Article 32 kontroll. Ha a fejlesztőknek, elemzőknek vagy beszállítóknak nincs szükségük éles személyes adatokra, a DLP nem lehet az egyetlen akadály. A maszkolás és az álnevesítés már az adatmozgás előtt csökkenti a kitettséget.
Egy erős, adatvédelemhez igazított DLP-mátrixnak a személyes adattípusokat osztályozási címkékhez, jogalaphoz, jóváhagyott rendszerekhez, jóváhagyott exportmódszerekhez, titkosítási követelményekhez, DLP-szabályokhoz, megőrzési szabályokhoz és incidensindítókhoz kell rendelnie. Ez a mátrix teremti meg a hidat az adatvédelmi irányítás és a biztonsági üzemeltetés között.
NIS2 kiberhigiénia és DLP az adatvédelmi csapaton túl
A NIS2 megváltoztatja a DLP-ről szóló párbeszédet, mert a szivárgást nem kizárólag adatvédelmi kérdésként, hanem a kiberhigiénia és a reziliencia részeként kezeli.
Az Article 20 előírja, hogy az alapvető és fontos szervezetek vezető testületei jóváhagyják a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék a bevezetést, és kiberbiztonsági képzésben részesüljenek. Az Article 21 megfelelő és arányos intézkedéseket ír elő a szabályzatok, incidenskezelés, folytonosság, ellátási lánc, biztonságos fejlesztés, eredményességi tesztelés, kiberhigiénia, képzés, kriptográfia, HR-biztonság, hozzáférés-szabályozás és eszközkezelés területén. Az Article 25 ösztönzi a releváns európai és nemzetközi szabványok és műszaki specifikációk alkalmazását.
A DLP közvetlenül hozzájárul ezekhez a területekhez:
| NIS2 Article 21 terület | DLP-hozzájárulás |
|---|---|
| Kockázatelemzés és információs rendszerek biztonsági szabályzatai | Azonosítja az adatszivárgási forgatókönyveket és meghatározza a kezelési követelményeket |
| Incidenskezelés | A feltételezett adatkiviteli eseményeket triázs-, eszkalációs és értesítési munkafolyamatokba irányítja |
| Üzletmenet-folytonosság | Védi a kritikus működési és ügyfélinformációkat |
| Ellátásilánc-biztonság | Irányítja a harmadik felek felé történő adattovábbítást és beszállítói hozzáférést |
| Biztonságos fejlesztés | Megakadályozza a forráskód, titkos adatok és éles tesztadatok kiszivárgását |
| Eredményességi tesztelés | Lehetővé teszi a DLP-szimulációkat, asztali gyakorlatokat és helyesbítő intézkedések követését |
| Kiberhigiénia és képzés | Megtanítja a felhasználóknak a biztonságos átviteli gyakorlatokat és az árnyék-IT kockázatait |
| Kriptográfia | Kikényszeríti a titkosítást a bizalmas adattovábbításoknál |
| Hozzáférés-szabályozás és eszközkezelés | Korlátozza, ki exportálhat érzékeny vagyonelemeket, és naplózza a tevékenységet |
A Hálózatbiztonsági szabályzat – KKV „Célkitűzések” szakaszának 3.4 pontja kifejezetten rögzíti az adatkivitel megakadályozására vonatkozó célt:
A kártevők terjedésének és az adatkivitelnek a megelőzése hálózati csatornákon keresztül Hálózatbiztonsági szabályzat – KKV
A NIS2 szempontjából az ilyen cél közvetlen tesztelési útvonalat ad az auditoroknak: mutassák be a kimenő forgalom szűrését, a DNS-megfigyelést, a proxynaplókat, a végponti riasztásokat, a blokkolt feltöltési kísérleteket és a vizsgálati jegyeket.
A Zenith Blueprint Step 23 egy felhőspecifikus intézkedést is hozzáad, amely ma már nélkülözhetetlen a NIS2 hatálya alá tartozó digitális és IKT-szolgáltatók számára:
Sorolja fel az összes jelenleg használt felhőszolgáltatást (5.23), beleértve az ismert árnyék-IT-t is. Azonosítsa, ki hagyta jóvá ezeket, és történt-e kellő gondosság szerinti vizsgálat. Dolgozzon ki egyszerű értékelési ellenőrzőlistát, amely lefedi az adatok helyét, a hozzáférési modellt, a naplózást és a titkosítást. A jövőbeni szolgáltatásoknál biztosítsa, hogy az ellenőrzőlista beépüljön a beszerzési vagy informatikai beléptetési folyamatba.
Sok szervezet itt hibázik. Van IBIR alkalmazási területük és beszállítói nyilvántartásuk, de nincs valós listájuk azokról a SaaS-eszközökről, amelyekben a munkavállalók szabályozott vagy ügyféladatokat mozgatnak. A felhőfelderítés nélküli DLP vak.
DORA IKT-kockázat: DLP pénzügyi szervezeteknek és szolgáltatóknak
Pénzügyi szervezetek esetében a DLP-nek illeszkednie kell a DORA IKT-kockázatkezelési keretrendszerébe.
A DORA Article 5 belső irányítási és kontrollkeretrendszert ír elő az IKT-kockázatkezeléshez. A vezető testület felelős marad az IKT-kockázatért, az adatok rendelkezésre állását, hitelességét, sértetlenségét és bizalmasságát megőrző szabályzatokért, az egyértelmű IKT-szerepkörökért, a digitális működési reziliencia stratégiáért, az IKT-kockázattűrésért, a folytonossági és reagálási/helyreállítási tervekért, az audittervekért, az erőforrásokért, a harmadik felekre vonatkozó szabályzatért és a jelentési csatornákért.
Az Article 6 dokumentált IKT-kockázatkezelési keretrendszert követel meg, amely stratégiákat, szabályzatokat, eljárásokat, IKT-protokollokat és eszközöket foglal magában az információk és IKT-vagyonelemek védelmére. Az Article 9 a védelemre és megelőzésre vonatkozik. Az Articles 11 to 14 a folytonosságot, reagálást, helyreállítást, biztonsági mentést, visszaállítást, adatsértetlenségi ellenőrzéseket, tanulságokat, tudatossági képzést és válságkommunikációt adják hozzá.
A DLP ebbe a keretrendszerbe védelmi, észlelési, reagálási és tesztelési képességként illeszkedik.
A DORA a harmadik fél kockázatot is megkerülhetetlenné teszi. Az Articles 28 to 30 IKT harmadik fél kockázatkezelést, IKT-szolgáltatási szerződések nyilvántartását, szerződéskötés előtti kellő gondosságot, szerződéses követelményeket, auditálási és ellenőrzési jogokat, felmondási jogokat, kilépési stratégiákat, szolgáltatásleírásokat, adatkezelési és adattárolási helyeket, adathozzáférést, helyreállítást és visszaszolgáltatást, incidenssegítségnyújtást, hatósági együttműködést, biztonsági intézkedéseket és alvállalkozói feltételeket követelnek meg.
Egy fintech vagy bank esetében a DLP nem állhat meg a Microsoft 365 vagy a Google Workspace határán. Ki kell terjednie a fizetésfeldolgozókra, identitásellenőrzési szolgáltatókra, CRM-platformokra, adattárházakra, felhőinfrastruktúrára, kiszervezett támogatási pultokra, menedzselt szolgáltatókra és kritikus SaaS-integrációkra.
| DORA-elvárás | DLP-bizonyíték |
|---|---|
| Vezető testület által felügyelt IKT-irányítás | Vezetés által elfogadott DLP-kockázat, kijelölt szerepkörök és jóváhagyott költségvetés |
| Adatok rendelkezésre állása, hitelessége, sértetlensége és bizalmassága | Osztályozás, titkosítás, DLP-szabályok és hozzáférési korlátozások |
| Incidens-életciklus | DLP-riasztások triázsa, besorolása, gyökérok-elemzése és eszkalációja |
| Rezilienciatesztelés | DLP-szimulációk, adatkiviteli forgatókönyvek és helyesbítő intézkedések követése |
| IKT harmadik fél kockázat | Beszállítói átvilágítás, szerződéses DLP-záradékok és adatlokációs bizonyítékok |
| Ellenőrizhetőség | Naplók, szabályváltozási előzmények, kivétel-jóváhagyások és vezetőségi átvizsgálás |
Ez különösen fontos ott, ahol a DORA a NIS2-vel átfedő kötelezettségek esetében ágazatspecifikus uniós jogi aktusként működik. A kontrolloknak továbbra is létezniük kell. A jelentési és felügyeleti útvonal eltérhet.
90 perces DLP-szabály sprint
A Clarysec gyakorlati sprintet alkalmaz azoknál az ügyfeleknél, akik gyors előrelépést igényelnek anélkül, hogy úgy tennénk, mintha egy teljes DLP-program egyetlen megbeszélésen felépíthető lenne. A cél egy nagy értékű DLP-kontroll bevezetése a szabályzattól a bizonyítékig.
1. lépés: válasszon egy adattípust és egy átviteli útvonalat
Válassza ezt: „CRM-ből exportált és e-mailben külső címzettnek elküldött ügyfél személyes adat”. Ne kezdje az összes adattárral, országgal és adattípussal.
2. lépés: erősítse meg az osztályozást és a címkét
Használja az osztályozási szabályzatot annak megerősítésére, hogy ez az export Bizalmas. KKV esetében a 6.3.3 pont titkosítást, korlátozott hozzáférést, a megosztáshoz kifejezett jóváhagyást és biztonságos megsemmisítést ír elő. Vállalati környezetben az Adatosztályozási és címkézési szabályzat támogatja a nem megfelelően jelölt érzékeny adatok átvitelének blokkolását, valamint a DLP- és feltáró eszközökkel végzett automatizált ellenőrzést.
3. lépés: határozza meg az engedélyezett átviteli mintát
Engedélyezett: CRM-export jóváhagyott ügyféldomainre küldve titkosított e-maillel vagy jóváhagyott biztonságos fájlmegosztási platformon, üzleti indoklással.
Nem engedélyezett: személyes e-mail, nyilvános fájlmegosztási hivatkozások, nem engedélyezett AI-eszközök és nem felügyelt felhőmeghajtók.
Ez összhangban van a Zenith Blueprint Step 22 megállapításával:
Ha a „Bizalmas” információ nem hagyhatja el a vállalatot titkosítás nélkül, akkor az e-mail rendszereknek érvényesíteniük kell a titkosítási szabályzatokat, vagy blokkolniuk kell a külső továbbítást.
4. lépés: konfigurálja a minimális DLP-szabályt
Konfigurálja az e-mail- vagy együttműködési platformot úgy, hogy felismerje a bizalmas címkét, a személyes adatra utaló mintát vagy az exportfájl elnevezési konvencióját. Ha várhatók téves pozitív találatok, kezdjen megfigyeléssel, majd térjen át blokkolásra személyes domainek és nem engedélyezett címzettek esetén.
5. lépés: engedélyezze a naplózást és a riasztások továbbítását
Biztosítsa, hogy a naplók rögzítsék a fájlhozzáférést, a jogosultságváltozásokat és a megosztott erőforrások használatát a Naplózási és felügyeleti szabályzat – KKV szerint. A riasztásokat irányítsa a jegykezelési sorba súlyossággal, adattípussal, feladóval, címzettel, fájlnévvel, megtett intézkedéssel és felülvizsgálóval.
6. lépés: teszteljen három forgatókönyvet
Teszteljen egy jóváhagyott, titkosított ügyfélnek történő továbbítást, egy blokkolt személyes e-mailes továbbítást és egy csak riasztást kiváltó feltöltési kísérletet nem engedélyezett felhődomainre.
7. lépés: őrizze meg a bizonyítékokat
Mentse el a szabályzati pont hivatkozását, a DLP-szabály képernyőképét, a teszteredményeket, a riasztási jegyet, a felülvizsgálói döntést és a vezetői jóváhagyást. Adja hozzá a kontrollt a kockázatkezelési tervhez és az alkalmazhatósági nyilatkozathoz.
ISO/IEC 27001:2022 szempontból ez a gyakorlat összekapcsolja a 6.1.2. szakasz szerinti kockázatértékelést, a 6.1.3. szakasz szerinti kockázatkezelést, a 8. szakasz szerinti működéstervezést és -szabályozást, az A melléklet információátviteli, adatszivárgás-megelőzési, naplózási, felügyeleti, beszállítói és felhőkontrolljait, valamint a 9. szakasz szerinti teljesítményértékelést.
Keresztmegfelelési megfeleltetés: egy DLP-program, több kötelezettség
A Clarysec megközelítésének erőssége, hogy nem épít külön kontrollrendszereket a GDPR, NIS2, DORA, NIST és COBIT számára. Egy jól megtervezett DLP-program többféle elvárást is kielégíthet, ha a bizonyítékok megfelelően strukturáltak.
| Keretrendszer | Mit vár el a DLP-től | Clarysec bizonyítékminta |
|---|---|---|
| ISO/IEC 27001:2022 | Kockázatalapú kontrollok, alkalmazhatósági nyilatkozat (SoA), tulajdonosi felelősség, működési bizonyítékok és folyamatos fejlesztés | Kockázati nyilvántartás, SoA, szabályzatmegfeleltetés, DLP-szabályok, naplók és vezetőségi átvizsgálás |
| GDPR Article 32 | Megfelelő technikai és szervezési intézkedések a személyes adatok biztonságához | Osztályozás, titkosítás, hozzáférés-szabályozás, maszkolás, DLP-riasztások és incidensértékelés |
| NIS2 | Kiberhigiénia, hozzáférés-szabályozás, eszközkezelés, titkosítás, incidenskezelés és ellátásilánc-biztonság | Jóváhagyott szabályzatok, képzés, beszállítói felülvizsgálatok, incidensmunkafolyamat és 24/72 órás jelentési felkészültség |
| DORA | IKT-kockázatirányítás, incidenskezelés, rezilienciatesztelés és harmadik felek felügyelete | IKT-kockázati keretrendszer, DLP-tesztelés, incidensbesorolás, beszállítói szerződések és auditnyom |
| NIST CSF 2.0 | Irányítás, profilok, ellátásilánc-kockázat, reagálási és helyreállítási eredmények | Jelenlegi és célprofil, hiányossági terv, beszállítói kritikusság és reagálási nyilvántartások |
| COBIT 2019 | Irányítási célkitűzések, kontrolltulajdonosi felelősség, folyamatképesség és bizonyossági bizonyítékok | RACI, folyamatmutatók, kontrollteljesítmény-jelentés és belső auditmegállapítások |
A NIST CSF 2.0 hasznos kommunikációs réteg. GOVERN funkciója támogatja a jogi, szabályozói és szerződéses követelmények követését, a kockázatvállalási hajlandóságot, a szabályzatbetartatást, a szerepköröket és a felügyeletet. Profil módszere segíti a szervezeteket a jelenlegi és célállapot meghatározásában, a hiányosságok dokumentálásában és intézkedési terv végrehajtásában. RESPOND és RECOVER funkciói támogatják a DLP-incidensek elszigetelését, a gyökérok-elemzést, a bizonyítékmegőrzést és a helyreállítást.
A COBIT 2019 irányítási nézőpontot ad. A COBIT-orientált auditor azt fogja kérdezni, hogy a DLP-célok összhangban vannak-e a vállalati célokkal, egyértelmű-e a tulajdonosi felelősség, léteznek-e teljesítménymutatók, meghatározták-e a kockázatvállalási hajlandóságot, és kap-e a vezetés érdemi jelentést.
Hogyan tesztelik az auditorok a DLP-programot?
A DLP-auditok ritkán szólnak egyetlen képernyőképről. A különböző auditnézőpontok eltérő bizonyítékelvárásokat eredményeznek.
| Auditori nézőpont | Valószínű auditkérdés | Működő bizonyíték |
|---|---|---|
| ISO/IEC 27001:2022 auditor | A DLP-kockázat azonosított, kezelt, bevezetett és az IBIR-en keresztül bizonyított-e? | Kockázatértékelés, SoA, kockázatkezelési terv, szabályzatok, DLP-konfiguráció és működési nyilvántartások |
| GDPR- vagy adatvédelmi auditor | Igazolható-e, hogy a személyes adatok védettek, adattakarékosan kezeltek, jogszerűen továbbítottak és incidens szempontjából értékeltek? | Adatnyilvántartás, RoPA-összhang, osztályozás, átviteli naplók, DPIA-kimenetek és incidensdöntési bejegyzés |
| NIS2-értékelő | A DLP-hez kapcsolódó kiberhigiéniai, hozzáférési, incidens-, beszállítói és titkosítási intézkedések jóváhagyottak és teszteltek-e? | Vezetői jóváhagyás, képzési nyilvántartások, incidens-forgatókönyvek, beszállítói ellenőrzések és jelentési idővonalgyakorlat |
| DORA-felügyelet vagy belső audit | Támogatja-e a DLP az IKT-kockázatot, az adatok bizalmasságát, az incidensbesorolást, a rezilienciatesztelést és a harmadik felek felügyeletét? | IKT-kockázati keretrendszer, tesztprogram, incidensbesorolási nyilvántartások, szolgáltatói szerződések és kilépési tervek |
| NIST-értékelő | A DLP-eredmények irányítottak, profilozottak, priorizáltak, felügyeltek és fejlesztettek-e? | Jelenlegi és célprofil, POA&M, irányítási nyilvántartások és reagálási bizonyítékok |
| COBIT 2019 vagy ISACA auditor | A DLP elszámoltatható tulajdonosokkal, mutatókkal és bizonyossággal rendelkező folyamatként irányított-e? | RACI, KPI-k, KRI-k, folyamatleírások, kontrolltesztelés és helyesbítő intézkedések követése |
Egy erős DLP-auditcsomag tartalmazza a hatókör- és kockázati nyilatkozatot, az osztályozási rendszert, a jóváhagyott átviteli módszereket, a DLP-szabályokat, a kivétel-jóváhagyásokat, a naplózási tervet, a riasztástriázs-eljárást, az incidensjelentési döntési fát, a beszállítói és felhőnyilvántartást, a teszteredményeket és a helyesbítő intézkedések nyilvántartásait.
Gyakori DLP-hibák 2026-ban
A leggyakoribb DLP-hibák működési jellegűek, nem egzotikusak.
Először: az osztályozás opcionális vagy következetlen. A címkék léteznek a szabályzatban, de a felhasználók nem alkalmazzák őket, a rendszerek nem érvényesítik őket, és az adattárak évekre visszamenőleg tartalmaznak jelöletlen érzékeny fájlokat.
Másodszor: a DLP örökre csak riasztási módban marad. A csak riasztás hasznos a hangolás során, de a bizalmas ügyféladatok magas kockázatú, személyes e-mailre történő továbbítását végül blokkolni kell, kivéve, ha jóváhagyott kivétel áll fenn.
Harmadszor: az árnyék-IT-t informatikai kellemetlenségként, nem adatvédelmi kockázatként kezelik. A Felhőszolgáltatások használatára vonatkozó szabályzat és a Felhőszolgáltatások használatára vonatkozó szabályzat – KKV célja, hogy a nem engedélyezett felhőeszközök láthatók, felülvizsgálhatók és helyesbíthetők legyenek.
Negyedszer: a naplók nem elegendők a kivizsgáláshoz. Ha a biztonsági csapat nem tudja rekonstruálni, ki fért hozzá, ki osztotta meg, ki töltötte le, ki töltötte fel vagy ki módosított jogosultságokat, a szervezet nem tudja magabiztosan értékelni a GDPR, NIS2 vagy DORA szerinti jelentéstételi kötelezettségeket.
Ötödször: a beszállítók a DLP-modellen kívül maradnak. A DORA Articles 28 to 30 ezt különösen veszélyessé teszi a pénzügyi szervezetek számára, de a probléma minden ágazatot érint. A szerződéseknek meg kell határozniuk az adatok helyét, a hozzáférést, a helyreállítást, a visszaszolgáltatást, az incidenssegítségnyújtást, a biztonsági intézkedéseket, az alvállalkozást és az auditálási jogokat.
Hatodszor: az incidensreagálás nem tartalmaz DLP-forgatókönyveket. Egy téves címre küldött e-mailhez, jogosulatlan SaaS-feltöltéshez vagy tömeges CRM-exporthoz forgatókönyvnek, súlyossági szempontoknak és értesítési döntési útvonalnak kell tartoznia.
Végül: a szervezetek megfeledkeznek a fizikai és emberi csatornákról. A Zenith Blueprint emlékeztet rá, hogy a DLP magában foglalja a tiszta asztal magatartást, a biztonságos iratmegsemmisítést, a zárolt nyomtatási sorokat, a nyomtató auditnaplókat és a munkavállalói tudatosságot. Az a DLP-program, amely figyelmen kívül hagyja a papírt, a képernyőképeket és a beszélgetéseket, hiányos.
Építsen olyan DLP-programot, amelyben az auditorok megbízhatnak
Ha a DLP-programja jelenleg eszközkonfiguráció, 2026 az az év, amikor irányított, bizonyítékokkal alátámasztott kontrollrendszerré kell alakítani.
Kezdje három gyakorlati lépéssel:
- Válassza ki a három legfontosabb érzékeny adattípust, például ügyfél személyes adatai, fizetési adatok és forráskód.
- Térképezze fel, hol mozognak ezek, beleértve az e-mailt, SaaS-t, felhőalapú tárhelyet, végpontokat, API-kat, beszállítókat és fejlesztési környezeteket.
- Építsen adattípusonként egy kikényszeríthető DLP-szabályt, amely kapcsolódik a szabályzathoz, a naplózáshoz, az incidensreagáláshoz és a bizonyítékmegőrzéshez.
A Clarysec segíthet ezt felgyorsítani a Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, a Zenith Controls: The Cross-Compliance Guide Zenith Controls, valamint az adaptálható szabályzatok révén, például az Adatosztályozási és címkézési szabályzat Adatosztályozási és címkézési szabályzat, a Távmunka-szabályzat Távmunka-szabályzat, a Felhőszolgáltatások használatára vonatkozó szabályzat Felhőszolgáltatások használatára vonatkozó szabályzat, a Naplózási és felügyeleti szabályzat – KKV Naplózási és felügyeleti szabályzat – KKV, valamint a Mobileszköz- és BYOD-szabályzat Mobileszköz- és BYOD-szabályzat használatával.
A cél nem az, hogy minden fájlmozgást megállítsunk. A cél az, hogy a biztonságos mozgás legyen az alapértelmezett, a kockázatos mozgás látható legyen, a tiltott mozgás blokkolásra kerüljön, és minden kivétel elszámoltatható legyen.
Töltse le a Clarysec eszközkészleteit, vizsgálja felül DLP-bizonyítékcsomagját, és foglaljon felkészültségi értékelést annak megállapítására, hogy jelenlegi kontrolljai kiállják-e a GDPR Article 32 vizsgálatát, a NIS2 kiberhigiéniai elvárásait és a DORA IKT-kockázati felülvizsgálatát.
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
