GDPR 32. cikk szerinti TOM-bizonyítékok ISO, NIS2 és DORA megfeleltetéssel

Az e-mail az információbiztonsági vezető (CISO) beérkező üzenetei között landol, egy olyan üzleti lehetőség ismerős súlyával, amely akár a vállalat negyedéves eredményét is megváltoztathatja.

Egy nagyvállalati potenciális ügyfél bizonyítékot kér a „GDPR 32. cikk szerinti technikai és szervezési intézkedésekről, ISO 27001:2022, NIS2 és DORA szerinti megfeleltetéssel, amennyiben alkalmazandó”. Ezzel egy időben a jogi terület tájékoztatta az igazgatóságot a NIS2 szerinti vezetői felelősségről és a DORA operatív rezilienciára vonatkozó elvárásairól. Az igazgatóság utasítása egyszerűnek hangzik: igazolni kell a megfelelést, el kell kerülni a párhuzamos munkát, és mindez nem válhat három külön projektté.

A vállalatnak vannak kontrolljai. Az MFA be van kapcsolva. A biztonsági mentések futnak. A fejlesztők kódfelülvizsgálatot végeznek. Az adatvédelmi csapat vezeti az adatkezelési tevékenységek nyilvántartását. Az infrastruktúra-csapat sérülékenységvizsgálatokat végez. A beszállítókat a beszerzési folyamat során felülvizsgálják. Amikor azonban a potenciális ügyfél bizonyítékot kér, a válasz szétesik.

Az identitásszolgáltató jelentése az egyik helyen van. A biztonsági mentési naplók máshol. A kockázati nyilvántartást a legutóbbi termékkiadás óta nem frissítették. A beszállítói biztonsági bizonyítékok beszerzési e-mailekben találhatók. Léteznek incidensreagálási asztali gyakorlatok jegyzetei, de senki nem tudja bizonyítani, hogy a tanulságokat visszavezették a kockázatkezelésbe. Az igazgatóság jóváhagyta a biztonsági ráfordításokat, de a jóváhagyás nincs összekapcsolva IKT-kockázattal vagy dokumentált kontrolldöntéssel.

Ez a GDPR 32. cikk szerinti technikai és szervezési intézkedések, közkeletű nevükön TOM-ok valódi problémája. A legtöbb szervezet nem azért bukik el, mert nincsenek kontrolljai. Azért bukik el, mert nem tudja bizonyítani, hogy a kontrollok kockázatalapúak, jóváhagyottak, bevezetettek, felügyeltek és fejlesztettek.

A GDPR szerinti elszámoltathatóság ezt az elvárást egyértelművé teszi. A GDPR 5. cikk előírja, hogy a személyes adatokat megfelelő biztonsággal kell védeni a jogosulatlan vagy jogellenes adatkezeléssel, valamint a véletlen elvesztéssel, megsemmisítéssel vagy károsodással szemben. Az 5(2). cikk az adatkezelőt teszi felelőssé a megfelelés igazolásáért. A GDPR fogalommeghatározásai szintén számítanak. A személyes adat fogalma tág, az adatkezelés szinte minden adaton végzett műveletet lefed, az álnevesítés elismert védelmi intézkedés, a személyesadat-sértés pedig magában foglalja a véletlen vagy jogellenes megsemmisítést, elvesztést, megváltoztatást, jogosulatlan közlést vagy hozzáférést.

Egy 32. cikk szerinti bizonyítékfájl ezért nem lehet véletlenszerű képernyőképek mappája. Élő kontrollrendszernek kell lennie.

A Clarysec megközelítése szerint a GDPR 32. cikk szerinti TOM-okat nyomon követhető bizonyítékmotorrá kell alakítani, amely az ISO/IEC 27001:2022-re ISO/IEC 27001:2022 épül, az ISO/IEC 27005:2022 kockázatkezelés erősíti, és ahol alkalmazandó, NIS2 és DORA kötelezettségekkel van kereszt-hivatkozva. A cél nem az öncélú papírmunka. A cél az, hogy a szervezet auditra kész állapotban legyen még azelőtt, hogy egy ügyfél, auditor, felügyeleti hatóság vagy igazgatósági tag feltenné a nehéz kérdést.

Miért buknak el a GDPR 32. cikk szerinti TOM-ok a gyakorlatban

A 32. cikket gyakran biztonsági eszközök listájaként értelmezik félre: titkosítás, biztonsági mentések, naplózás, hozzáférés-szabályozás és incidenskezelés. Ezek az intézkedések fontosak, de csak akkor igazolhatók, ha arányosak a kockázattal és kapcsolódnak a személyes adatok életciklusához.

Egy ügyfél- és munkavállalói adatokat kezelő SaaS-vállalatnál nem elég azt mondani, hogy „titkosítást használunk”. Egy auditor megkérdezheti, milyen adatokat véd a titkosítás, hol kötelező a titkosítás, hogyan kezelik a kulcsokat, titkosítva vannak-e a biztonsági mentések, maszkolják-e az éles adatokat tesztelés során, ki kerülheti meg a kontrollokat, és hogyan hagyják jóvá a kivételeket.

A Clarysec vállalati Adatvédelmi és magánszféra-védelmi szabályzata így fogalmazza meg a működési alapelvet:

„Olyan technikai és szervezési intézkedéseket (TOM) kell bevezetni, amelyek a személyazonosításra alkalmas információk (PII) teljes életciklusa során védik azok bizalmasságát, sértetlenségét és rendelkezésre állását.”

Forrás: Adatvédelmi és magánszféra-védelmi szabályzat, célkitűzések, 3.3. szabályzati pont. Adatvédelmi és magánszféra-védelmi szabályzat

A „teljes életciklusa során” kifejezés az a pont, ahol sok TOM-program meggyengül. A személyes adatok védettek lehetnek az éles környezetben, de átmásolhatják őket analitikai rendszerekbe, naplókba, támogatási exportokba, tesztkörnyezetekbe, biztonsági mentésekbe, beszállítói platformokra és munkavállalói eszközökre. Minden ilyen hely biztonsági és adatvédelmi kockázatot teremt.

A GDPR 6. cikk jogalapot ír elő az adatkezeléshez, beleértve a hozzájárulást, a szerződést, a jogi kötelezettséget, a létfontosságú érdeket, a közérdekű feladatot vagy a jogos érdeket. Ha az adatokat további célra használják fel újra, mérlegelni kell az összeegyeztethetőséget és az olyan védelmi intézkedéseket, mint a titkosítás vagy az álnevesítés. Magasabb kockázatú adatok esetén nő a bizonyítási teher. A GDPR 9. cikk szigorú korlátokat állít a személyes adatok különleges kategóriáira, például az egészségügyi adatokra, az azonosításra használt biometrikus adatokra és más érzékeny információkra. A 10. cikk korlátozza a büntetőjogi felelősség megállapítására és bűncselekményekre vonatkozó adatok kezelését.

KKV-k számára a Clarysec gyakorlatiasan fogalmazza meg a kockázatkezelést:

„Kontrollokat kell bevezetni az azonosított kockázatok csökkentésére, beleértve a titkosítást, anonimizálást, biztonságos megsemmisítést és hozzáférési korlátozásokat.”

Forrás: Adatvédelmi és magánszféra-védelmi szabályzat - KKV, kockázatkezelés és kivételek, 7.2.1. szabályzati pont. Adatvédelmi és magánszféra-védelmi szabályzat - KKV

Ez erős TOM-alapvonal. Ahhoz, hogy auditra kész legyen, minden kontrollt kockázathoz, felelőshöz, szabályzati követelményhez, bizonyító elemhez és felülvizsgálati ütemezéshez kell rendelni.

Az ISO 27001:2022 a 32. cikk szerinti bizonyítékok gerince

Az ISO 27001:2022 jól használható a GDPR 32. cikkhez, mert a biztonságot irányítási rendszerként, nem pedig különálló kontroll-ellenőrzőlistaként kezeli. Információbiztonság-irányítási rendszert (IBIR) követel meg, amelynek célja a bizalmasság, sértetlenség és rendelkezésre állás megőrzése kockázatkezelés útján.

Az első kritikus lépés a hatály meghatározása. Az ISO 27001:2022 4.1–4.4. pontjai előírják, hogy a szervezet értse meg a belső és külső tényezőket, azonosítsa az érdekelt feleket és követelményeiket, határozza meg, mely követelményekkel foglalkozik az IBIR, és definiálja az IBIR alkalmazási területét, beleértve a külső szervezetekkel fennálló interfészeket és függőségeket. A 32. cikk szerinti TOM-oknál az IBIR alkalmazási területének tükröznie kell a személyesadat-kezelést, az ügyfélkötelezettségeket, az adatfeldolgozókat, al-adatfeldolgozókat, felhőplatformokat, távmunkát, támogatási funkciókat és termékkörnyezeteket.

A második lépés a vezetői elkötelezettség. Az 5.1–5.3. pontok felső vezetői elkötelezettséget, információbiztonsági szabályzatot, erőforrásokat, szerepköröket és felelősségeket, valamint teljesítményjelentést írnak elő. Ez azért fontos, mert a GDPR 32. cikk, a NIS2 és a DORA egyaránt irányításra épül. A felelős, finanszírozás vagy felülvizsgálat nélküli kontroll gyenge bizonyíték.

A Clarysec vállalati Információbiztonsági szabályzata ezt egyértelművé teszi:

„Az IBIR-nek tartalmaznia kell meghatározott határokat, kockázatértékelési módszertant, mérhető célkitűzéseket és dokumentált kontrollokat, amelyeket az alkalmazhatósági nyilatkozat (SoA) indokol.”

Forrás: Információbiztonsági szabályzat, a szabályzat végrehajtásának követelményei, 6.1.2. szabályzati pont. Információbiztonsági szabályzat

Ugyanez a szabályzat rögzíti a bizonyítékokra vonatkozó elvárást:

„Minden bevezetett kontrollnak auditra alkalmasnak kell lennie, dokumentált eljárásokkal és a működés megőrzött bizonyítékaival alátámasztva.”

Forrás: Információbiztonsági szabályzat, a szabályzat végrehajtásának követelményei, 6.6.1. szabályzati pont.

Az ISO 27001:2022 6.1.1–6.1.3. pontjai ezt követően kockázatértékelést, kockázatkezelést, alkalmazhatósági nyilatkozatot, maradványkockázat-jóváhagyást és kockázatgazdai felelősséget írnak elő. A 6.2. pont mérhető célkitűzéseket követel meg. A 7.5., 9.1., 9.2., 9.3. és 10.2. pontok dokumentált információt, felügyeletet, belső auditot, vezetőségi átvizsgálást és helyesbítő intézkedést írnak elő.

A GDPR 32. cikk esetében ez igazolható struktúrát hoz létre.

Az ISO/IEC 27005:2022 tovább erősíti ezt a struktúrát. Azt javasolja, hogy a szervezetek azonosítsák az ISO 27001:2022 A mellékletéből, jogszabályokból, szerződésekből, ágazati szabványokból, belső szabályokból és meglévő kontrollokból eredő követelményeket, majd építsék be azokat a kockázatértékelésbe és kockázatkezelésbe. Kockázati szempontokat és elfogadási kritériumokat is előír, amelyek figyelembe veszik a jogi, szabályozási, működési, beszállítói, technológiai és emberi tényezőket, beleértve az adatvédelmet.

A Clarysec Kockázatkezelési szabályzata közvetlenül ehhez igazodik:

„Formális kockázatkezelési folyamatot kell fenntartani az ISO/IEC 27005 és az ISO 31000 szerint, amely lefedi a kockázatazonosítást, -elemzést, -értékelést, -kezelést, a kockázatok nyomon követését és a kockázatkommunikációt.”

Forrás: Kockázatkezelési szabályzat, irányítási követelmények, 5.1. szabályzati pont. Kockázatkezelési szabályzat

KKV-k számára ugyanez a követelmény egyszerű és végrehajtható:

„Minden kockázati bejegyzésnek tartalmaznia kell: leírást, valószínűséget, hatást, pontszámot, felelőst és kezelési tervet.”

Forrás: Kockázatkezelési szabályzat - KKV, irányítási követelmények, 5.1.2. szabályzati pont. Kockázatkezelési szabályzat - KKV

Ez a mondat gyors auditra készségi teszt. Ha egy kockázatnak nincs felelőse vagy kezelési terve, akkor még nem bizonyítékérett kockázat.

A Clarysec híd: kockázat, SoA, kontrollok és jogszabályok

A Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint a megfelelést visszakövethetőségi feladatként kezeli. A kockázatkezelési szakaszban a 13. lépés a kockázatkezelési tervezésre és az alkalmazhatósági nyilatkozatra összpontosít. Kifejti, hogy a szervezeteknek a kontrollokat kockázatokhoz kell rendelniük, az A melléklet kontrollhivatkozásait hozzá kell adniuk a kockázatkezelési bejegyzésekhez, kereszt-hivatkozniuk kell a külső jogszabályokra, és be kell szerezniük a vezetői jóváhagyást.

A Zenith Blueprint közvetlenül fogalmaz a SoA szerepéről:

„A SoA ténylegesen összekötő dokumentum: összekapcsolja a kockázatértékelést/-kezelést a ténylegesen meglévő kontrollokkal. Kitöltésével azt is kétszeresen ellenőrizheti, hogy kimaradt-e bármely kontroll.”

Forrás: Zenith Blueprint: An Auditor’s 30-Step Roadmap, kockázatkezelési szakasz, 13. lépés: kockázatkezelési tervezés és alkalmazhatósági nyilatkozat (SoA). Zenith Blueprint

A Zenith Blueprint 14. lépése hozzáadja a szabályozási kereszt-hivatkozási réteget. Azt javasolja, hogy a szervezetek dokumentálják, hogyan fedik le a GDPR, NIS2 és DORA követelményeket a szabályzatok és kontrollok. A GDPR esetében hangsúlyozza a személyes adatok védelmét a kockázatértékelésekben és kezelésekben, beleértve a titkosítást mint technikai intézkedést és az adatsértések kezelését mint a kontrollkörnyezet részét. A NIS2 esetében a kockázatértékelést, a hálózatbiztonságot, a hozzáférés-szabályozást, az incidenskezelést és az üzletmenet-folytonosságot emeli ki. A DORA esetében az IKT-kockázatkezelésre, az incidenskezelésre, a jelentéstételre és az IKT harmadik felek felügyeletére mutat rá.

Ez a Clarysec módszerének lényege: egy IBIR, egy kockázati nyilvántartás, egy SoA, egy bizonyítéktár, több megfelelési eredmény.

A Zenith Controls: The Cross-Compliance Guide Zenith Controls ezt azzal támogatja, hogy segít a szervezeteknek az ISO/IEC 27002:2022 ISO/IEC 27002:2022 kontrolltémáit keresztmegfelelési hivatkozási pontként használni. A GDPR 32. cikk esetében a legfontosabb hivatkozási pontok gyakran a Privacy and Protection of PII, 5.34 kontroll; az Independent Review of Information Security, 5.35 kontroll; valamint a Use of Cryptography, 8.24 kontroll.

A NIS2 igazgatósági szintű kiberbiztonsági kérdéssé teszi a TOM-okat

Sok szervezet a GDPR TOM-okat az adatvédelmi csapat felelősségének tekinti. A NIS2 megváltoztatja ezt a beszélgetést.

A NIS2 számos közepes és nagy szervezetre alkalmazandó a felsorolt ágazatokban, egyes esetekben mérettől függetlenül. A lefedett digitális és technológiai ágazatok közé tartoznak a felhőszolgáltatók, adatközpont-szolgáltatók, tartalomszolgáltató hálózatok, DNS-szolgáltatók, TLD-nyilvántartók, bizalmi szolgáltatók, nyilvános elektronikus hírközlési szolgáltatók, menedzselt szolgáltatók, menedzselt biztonsági szolgáltatók, online piacterek, keresőmotorok és közösségi hálózati platformok. A SaaS- és technológiai KKV-k alkalmazhatósága az ágazattól, mérettől, tagállami kijelöléstől, valamint a rendszerszintű vagy határokon átnyúló hatástól függ.

A NIS2 20. cikk a kiberbiztonsági felelősséget a vezető testületekre helyezi. Jóvá kell hagyniuk a kiberbiztonsági kockázatkezelési intézkedéseket, felügyelniük kell a végrehajtást és képzésen kell részt venniük. Az alapvető szervezetek legalább 10 millió EUR vagy a globális éves árbevétel legalább 2 százaléka összegű közigazgatási bírsággal szembesülhetnek. A fontos szervezetek legalább 7 millió EUR vagy legalább 1,4 százalékos bírsággal szembesülhetnek.

A NIS2 21. cikk közvetlenül releváns a 32. cikk szerinti TOM-ok szempontjából, mert megfelelő és arányos technikai, működési és szervezési intézkedéseket ír elő. Ezeknek az intézkedéseknek figyelembe kell venniük a technika állását, az európai és nemzetközi szabványokat, a költségeket, a kitettséget, a méretet, a valószínűséget, a súlyosságot és a társadalmi vagy gazdasági hatást. Az előírt területek közé tartozik a kockázatelemzés, a biztonsági szabályzatok, az incidenskezelés, az üzletmenet-folytonosság, az ellátási lánc biztonsága, a biztonságos beszerzés és fejlesztés, a sérülékenységek kezelése, az eredményesség értékelése, a kiberhigiénia, a képzés, a kriptográfia, a HR-biztonság, a hozzáférés-szabályozás, az eszközkezelés, az MFA vagy a folyamatos hitelesítés, valamint adott esetben a biztonságos kommunikáció.

A NIS2 23. cikk szakaszos incidensjelentést ad hozzá: korai figyelmeztetés 24 órán belül, incidensbejelentés 72 órán belül, köztes frissítések kérésre, valamint zárójelentés legkésőbb a 72 órás bejelentést követő egy hónapon belül. Ha egy személyesadat-sértés NIS2 szerinti jelentős incidensnek is minősül, a bizonyítékfájlnak támogatnia kell mind az adatvédelmi, mind a kiberbiztonsági jelentéstételi döntéseket.

A DORA magasabbra teszi a mércét a pénzügyi reziliencia és az IKT-szolgáltatók számára

A DORA 2025. január 17-től alkalmazandó, és a digitális operatív rezilienciára vonatkozó pénzügyi ágazati szabálykönyvet hoz létre. Lefedi az IKT-kockázatkezelést, a jelentős IKT-vonatkozású incidensek bejelentését, az operatív reziliencia tesztelését, a kiberfenyegetésekre és sérülékenységekre vonatkozó információmegosztást, az IKT harmadik felek kockázatát, az IKT-szolgáltatókra vonatkozó szerződéses követelményeket, a kritikus IKT harmadik fél szolgáltatók felügyeletét és a felügyeleti tevékenységet.

Azoknál a pénzügyi szervezeteknél, amelyeket nemzeti NIS2 szabályok alapján is azonosítottak, a DORA ágazatspecifikus uniós jogi aktusként működik az átfedő kiberbiztonsági kockázatkezelési és incidensjelentési kötelezettségek tekintetében. A gyakorlatban az érintett pénzügyi szervezeteknek ezekben az átfedő területekben a DORA-t kell elsődlegesen alkalmazniuk, miközben szükség szerint fenntartják az együttműködést a NIS2 szerinti illetékes hatóságokkal és CSIRT-ekkel.

A GDPR 32. cikk szerinti bizonyítékok szempontjából a DORA két okból fontos. Először, a fintech cégek közvetlenül hatály alá tartozhatnak pénzügyi szervezetként, ideértve a hitelintézeteket, pénzforgalmi intézményeket, számlainformációs szolgáltatókat, elektronikus pénzintézeteket, befektetési vállalkozásokat, kriptoeszköz-szolgáltatókat, kereskedési helyszíneket és közösségi finanszírozási szolgáltatókat. Másodszor, a SaaS-, felhő-, adat-, szoftver- és menedzselt szolgáltatók a pénzügyi ügyfelek szempontjából IKT harmadik fél szolgáltatóknak minősülhetnek, mert a DORA szélesen határozza meg az IKT-szolgáltatásokat.

A DORA 5. cikk irányítást és belső kontrollokat ír elő az IKT-kockázatkezeléshez, ahol a vezető testület határozza meg, hagyja jóvá, felügyeli az IKT-kockázati megoldásokat, és azokért továbbra is felelős. A 6. cikk dokumentált IKT-kockázatkezelési keretrendszert ír elő, beleértve stratégiákat, szabályzatokat, eljárásokat, IKT-protokollokat és eszközöket az információk és IKT-eszközök védelmére. A 17. cikk IKT-vonatkozású incidenskezelési folyamatot követel meg, amely lefedi az észlelést, kezelést, bejelentést, rögzítést, gyökérok-elemzést, korai figyelmeztető indikátorokat, besorolást, szerepköröket, kommunikációt, eszkalációt és reagálást. A 19. cikk előírja a jelentős IKT-vonatkozású incidensek bejelentését az illetékes hatóságoknak.

A DORA 28. és 30. cikk az IKT harmadik fél kockázatát szabályozott kontrollterületté teszi. A pénzügyi szervezetek az IKT-szolgáltatások igénybevételekor is felelősek maradnak a megfelelésért. Harmadikfél-kockázati stratégiára, szerződéses nyilvántartásokra, kritikussági értékelésekre, kellő gondosságra, koncentrációs kockázat felülvizsgálatára, auditálási és ellenőrzési jogokra, megszüntetési kiváltó okokra, kilépési stratégiákra és olyan szerződéses rendelkezésekre van szükségük, amelyek lefedik az adatok helyét, rendelkezésre állását, hitelességét, sértetlenségét, bizalmasságát, az incidenskezelési segítségnyújtást, helyreállítást, szolgáltatási szinteket és a hatóságokkal való együttműködést.

A 32. cikk esetében ez azt jelenti, hogy a beszállítók a TOM-fájl részét képezik. Nem lehet igazolni az adatkezelés biztonságát, ha a kritikus adatfeldolgozók, felhőplatformok, analitikai szolgáltatók, támogatási eszközök és IKT-szolgáltatók nincsenek kontroll alatt.

Gyakorlati, egyhetes 32. cikk szerinti bizonyítéképítés

Egy erős bizonyítékfájl egyértelmű kockázati forgatókönyvvel kezdődik.

Használja ezt a példát: „Jogosulatlan hozzáférés ügyfél személyes adataihoz az éles alkalmazásban.”

Hozza létre vagy frissítse a kockázati bejegyzést. Tartalmazza a leírást, valószínűséget, hatást, pontszámot, felelőst és kezelési tervet. A felelőst rendelje a mérnöki vezetőhöz, a biztonsági vezetőhöz vagy egyenértékű elszámoltatható szerepkörhöz. A valószínűséget a hozzáférési modell, a kitett támadási felület, az ismert sérülékenységek és korábbi incidensek alapján értékelje. A hatást a személyes adatok mennyisége, érzékenysége, ügyfélszerződések, GDPR-következmények és lehetséges NIS2 vagy DORA szolgáltatási hatás alapján értékelje.

Válasszon kezeléseket, például MFA-t a privilegizált hozzáféréshez, szerepköralapú hozzáférés-szabályozást, negyedéves hozzáférés-felülvizsgálatokat, tárolt adatok titkosítását, TLS-t, sérülékenységvizsgálatot, naplózást, riasztást, biztonságos biztonsági mentést, incidenskezelési eljárásokat és adatmaszkolást nem éles környezetekben.

Ezután rendelje hozzá a kockázatot a SoA-hoz. Adjon hozzá ISO/IEC 27002:2022 hivatkozásokat, például 5.34 Privacy and Protection of PII, 8.24 Use of Cryptography, 5.15 Access Control, 5.18 Access Rights, 8.13 Information Backup, 8.15 Logging, 8.16 Monitoring Activities, 8.8 Management of Technical Vulnerabilities, 8.25 Secure Development Life Cycle és 8.10 Information Deletion, ahol alkalmazandó. Adjon hozzá megjegyzéseket arról, hogy ezek a kontrollok hogyan támogatják a GDPR 32. cikket, a NIS2 21. cikket és adott esetben a DORA IKT-kockázatkezelést.

A szabályozási megfeleltetésnél tartsa pontosan a kontrollneveket, és kerülje a hamis egyenértékűség erőltetését.

Most építse fel a bizonyítékmappát. A Clarysec KKV Audit- és megfelelésfelügyeleti szabályzata egyszerű szabályt ad:

„Minden bizonyítékot központi auditmappában kell tárolni.”

Forrás: Audit- és megfelelésfelügyeleti szabályzat - KKV, a szabályzat végrehajtásának követelményei, 6.2.1. szabályzati pont. Audit- és megfelelésfelügyeleti szabályzat - KKV

Ehhez az egy kockázati forgatókönyvhöz a mappának a következőket kell tartalmaznia:

A hozzáférési bizonyítékok nem állhatnak meg a képernyőképeknél. A Hozzáférés-szabályozási szabályzat - KKV hasznos működési követelményt ad hozzá:

„Az informatikai vezetőnek dokumentálnia kell a felülvizsgálati eredményeket és a helyesbítő intézkedéseket.”

Forrás: Hozzáférés-szabályozási szabályzat - KKV, irányítási követelmények, 5.5.3. szabályzati pont. Hozzáférés-szabályozási szabályzat - KKV

A biztonsági mentési bizonyítékoknak a helyreállíthatóságot kell bizonyítaniuk, nem csupán a sikeres futásokat. A Biztonsági mentési és helyreállítási szabályzat - KKV kimondja:

„A helyreállítási teszteket legalább negyedévente el kell végezni, és az eredményeket dokumentálni kell a helyreállíthatóság ellenőrzésére.”

Forrás: Biztonsági mentési és helyreállítási szabályzat - KKV, irányítási követelmények, 5.3.3. szabályzati pont. Biztonsági mentési és helyreállítási szabályzat - KKV

Ez teljes bizonyítékláncot ad: a jogszabály létrehozza a követelményt, a kockázat megmagyarázza, miért fontos, a SoA kiválasztja a kontrollt, a szabályzat meghatározza a működést, a megőrzött bizonyíték pedig igazolja, hogy a kontroll működik.

Kontrollok működés közben: a szabályzat működési bizonyítékká alakítása

A Zenith Blueprint Kontrollok működés közben szakaszának 19. lépése a technikai ellenőrzésre összpontosít. Javasolja a végpontbiztonsági megfelelés, az identitás- és hozzáférés-kezelés, a hitelesítési konfigurációk, a forráskód-kezelés biztonsága, a kapacitás és rendelkezésre állás, a sérülékenység- és javításkezelés, a biztonságos alapbeállítások, a kártékony kód elleni védelem, a törlés és adattakarékosság, a maszkolás és tesztadatok, a DLP, a biztonsági mentés és helyreállítás, a redundancia, a naplózás és felügyelet, valamint az időszinkronizálás felülvizsgálatát.

A GDPR 32. cikk szerinti TOM-ok esetében a 19. lépés az a pont, ahol az absztrakt kontrollnyelv bizonyítékká válik. Egy erős bizonyítékfájlnak igazolnia kell, hogy:

• A végponti titkosítás be van kapcsolva és felügyelet alatt áll.
• A privilegizált felhasználók MFA-t használnak.
• A belépési, áthelyezési és kilépési folyamatokat egyeztetik a HR-nyilvántartásokkal.
• A szolgáltatásfiókok dokumentáltak és korlátozottak.
• A kódtárak hozzáférés-szabályozottak, és titokvizsgálat történik.
• A sérülékenységvizsgálatokat elvégzik, és a javító intézkedésekig nyomon követik.
• Az éles adatokat nem másolják rutinszerűen tesztkörnyezetekbe.
• A biztonságos törlésre és adatmegőrzésre vonatkozó szabályzatokat betartatják.
• A DLP-riasztásokat felülvizsgálják.
• A biztonsági mentések helyreállítási tesztjei igazolják a helyreállíthatóságot.
• A naplókat központosítják, megőrzik és felülvizsgálhatóvá teszik.
• Az időszinkronizálás támogatja a megbízható incidenskivizsgálást.

A kulcs az összekapcsolás. Egy javítási jelentés kockázat-, szabályzat- és SoA-hivatkozás nélkül informatikai artefaktum. Egy GDPR 32. cikkhez, NIS2 21. cikkhez, DORA IKT-kockázatkezeléshez és ISO 27001:2022 kockázatkezelési tervhez kapcsolt javítási jelentés auditra kész bizonyíték.

Egy bizonyítékfájl, több auditnézőpont

Ugyanazt a TOM-bizonyítékot a különböző érdekelt felek eltérően olvassák. Egy adatvédelmi felülvizsgáló a személyes adatokra, szükségességre, arányosságra és elszámoltathatóságra fókuszálhat. Egy ISO 27001 auditor a hatályra, kockázatkezelésre, SoA-ra és a működés bizonyítékaira fókuszálhat. Egy NIS2 hatóság a vezetői felügyeletre, a 21. cikk szerinti intézkedésekre és a 23. cikk szerinti jelentéstételi felkészültségre fókuszálhat. Egy DORA-felügyelet vagy pénzügyi ügyfél az IKT-kockázatirányításra, a rezilienciatesztelésre és a harmadik felektől való függőségekre fókuszálhat.

A Clarysec a Zenith Controls-t használja keresztmegfelelési útmutatóként ehhez a megfeleltetéshez.

Ez megelőzi a párhuzamos megfelelési munkát. A GDPR, NIS2 és DORA számára külön bizonyítékcsomagok építése helyett egy kontrollbizonyíték-fájlt kell kialakítani, és minden elemet meg kell címkézni az általa támogatott kötelezettségek szerint.

Gyakori hiányosságok a 32. cikk szerinti TOM-programokban

A leggyakoribb hiányosság az árva kontroll. A vállalatnak van kontrollja, például titkosítás, de nem tudja megmagyarázni, mely kockázatot kezeli, mely szabályzat írja elő, ki a felelőse, vagy hogyan vizsgálják felül.

A második hiányosság a gyenge beszállítói bizonyíték. A GDPR alatt az adatfeldolgozók és al-adatfeldolgozók számítanak. A NIS2 alatt az ellátási lánc biztonsága a kiberbiztonsági kockázatkezelés része. A DORA alatt az IKT harmadik fél kockázata szabályozott terület, amely nyilvántartásokat, kellő gondosságot, szerződéses védelmi intézkedéseket, auditálási jogokat és kilépési tervezést foglal magában. Egy beszállítói táblázat nem elegendő, ha a kritikus függőségek nincsenek kockázatértékelve és kontroll alatt.

A harmadik hiányosság az incidensbizonyíték. A szervezeteknek gyakran van incidenskezelési tervük, de nincs bizonyítékuk arra, hogy a besorolást, eszkalációt, hatósági jelentéstételt és ügyfélkommunikációt tesztelték. A NIS2 és a DORA ezen a területen magasabb elvárásokat támaszt, és a GDPR szerinti személyesadat-sértés értékelését ugyanabba a munkafolyamatba kell integrálni.

A negyedik hiányosság a biztonsági mentési bizonyíték. Egy sikeres biztonsági mentési feladat nem bizonyítja a helyreállíthatóságot. Egy dokumentált helyreállítási teszt igen.

Az ötödik hiányosság a vezetőségi átvizsgálás. A 32. cikk szerinti TOM-oknak arányosnak kell lenniük a kockázattal. Ha a vezetőség soha nem vizsgálja felül a kockázatokat, incidenseket, beszállítói problémákat, költségvetést, auditmegállapításokat és maradványkockázatot, az arányosság nehezen igazolhatóvá válik.

A végleges, auditra kész eszközkészlet

A Zenith Blueprint Audit, felülvizsgálat és fejlesztés szakaszának 30. lépése adja a végleges felkészültségi ellenőrzőlistát. Tartalmazza az IBIR hatályát és kontextusát, az aláírt információbiztonsági szabályzatot, a kockázatértékelési és kockázatkezelési dokumentumokat, a SoA-t, az A melléklet szerinti szabályzatokat és eljárásokat, képzési nyilvántartásokat, működési nyilvántartásokat, belső audit jelentést, helyesbítő intézkedési naplót, vezetőségi átvizsgálási jegyzőkönyveket, folyamatos fejlesztési bizonyítékokat és megfelelési kötelezettségek nyilvántartásait.

A Clarysec vállalati Audit- és megfelelésfelügyeleti szabályzata így határozza meg e fegyelem célját:

„Igazolható bizonyítékok és auditnyom előállítása szabályozó hatósági megkeresések, jogi eljárások vagy ügyfélbizonyossági igények támogatására.”

Forrás: Audit- és megfelelésfelügyeleti szabályzat, célkitűzések, 3.4. szabályzati pont. Audit- és megfelelésfelügyeleti szabályzat

Egy érett, 32. cikk szerinti TOM-bizonyítékfájlnak tartalmaznia kell:

Következő lépések: 32. cikk szerinti TOM-bizonyítékok építése a Clarysec segítségével

Ha igazolnia kell a GDPR 32. cikk szerinti technikai és szervezési intézkedéseket, ne véletlenszerű képernyőképek gyűjtésével kezdje. Kezdje a visszakövethetőséggel.

1. Határozza meg az IBIR alkalmazási területét és a személyesadat-kezelés határait.
2. Azonosítsa a GDPR, NIS2, DORA, szerződéses és ügyfélkövetelményeket.
3. Alakítson ki kockázati szempontokat az ISO/IEC 27005:2022 és a vezetés által jóváhagyott kockázatvállalási hajlandóság alapján.
4. Hozza létre vagy frissítse a kockázati nyilvántartást.
5. Rendeljen minden kezelést ISO 27001:2022 kontrollokhoz és a SoA-hoz.
6. Használja a Zenith Controls-t az adatvédelmi, kriptográfiai, beszállítói, incidens- és független felülvizsgálati kontrollok kereszt-hivatkozására a megfelelési elvárások között.
7. Kövesse a Zenith Blueprint 13. és 14. lépését a kockázatok, kontrollok és szabályozási kötelezettségek összekapcsolásához.
8. Használja a Zenith Blueprint 19. lépését a technikai kontrollok működésének ellenőrzésére.
9. Használja a Zenith Blueprint 30. lépését a végleges, auditra kész bizonyítékfájl összeállításához.
10. Minden bizonyítékot központilag tároljon, címkézze kockázat és kontrolltéma szerint, és tegye láthatóvá a helyesbítő intézkedéseket.

A Clarysec segíthet abban, hogy a GDPR 32. cikket homályos megfelelési kötelezettségből igazolható, kockázatalapú bizonyítékrendszerré alakítsa, amely összhangban áll az ISO 27001:2022, NIS2 és DORA követelményekkel.

Kezdje a Zenith Blueprint használatával, erősítse meg Clarysec szabályzatokkal, és használja a Zenith Controls megoldást annak érdekében, hogy minden TOM visszakövethető, tesztelhető és auditra kész legyen.