RoPA és adatáramlás-feltérképezés GDPR-, NIS2- és DORA-megfeleléshez

Kedd reggel 09:10 van, és az információbiztonsági vezető (CISO), az adatvédelmi tisztviselő (DPO), a beszerzési vezető és az üzemeltetési igazgató ugyanabban a videóhívásban ülnek, de nem ugyanazokat a bizonyítékokat látják.

Az adatvédelmi tisztviselőnél van az adatkezelési tevékenységek nyilvántartása (RoPA), amely az ügyfélbeléptetést, a munkavállalói bérszámfejtést, a támogatási jegyeket és a marketinganalitikát sorolja fel. Az információbiztonsági vezetőnél van a felhőalapú eszköznyilvántartás. A beszerzésnél vannak a beszállítói szerződések. Az üzemeltetésnél van az üzletmenet-folytonossági táblázat. A pénzügy kezeli a DORA információs nyilvántartását. Senki nem tud válaszolni a szabályozó hatóság legalapvetőbb, összekapcsolt kérdésére:

Ha ez a fizetési ügyfélbeléptetési szolgáltatás kiesik, mely rendszerek, beszállítók, adatkategóriák, al-adatfeldolgozók, határokon átnyúló adattovábbítások és kritikus üzleti funkciók érintettek?

Ez a kérdés a 2026-os megfelelés valódi próbája.

A GDPR továbbra is elszámoltatható Article 30 nyilvántartásokat követel meg. A NIS2 a kiberbiztonságot az alapvető és fontos szervezetek vezető testületének elszámoltathatósági kérdésévé tette. A DORA megköveteli a pénzügyi szervezetektől az IKT-függőségek, a kritikus vagy fontos funkciók, az IKT harmadik féllel kötött megállapodások, az incidensbesorolás és a rezilienciatesztelés bizonyítékokkal való alátámasztását. Az ISO/IEC 27001:2022 biztosítja azt az irányítási rendszerstruktúrát, amely mindezt egyben tartja, de csak akkor, ha a RoPA-t és az adatáramlások feltérképezését nem adatvédelmi csapat által kezelt táblázatként, hanem élő irányítási bizonyítékként kezelik.

A Clarysec-nél ugyanezt a mintázatot látjuk a gyorsan növekvő SaaS-, fintech-, felhő-, MSP- és B2B technológiai vállalatoknál. Van elegendő dokumentációjuk egy kérdőív megválaszolásához, de nincs elegendő összekapcsolt bizonyítékuk egy felügyeleti felülvizsgálat, kiberbiztonsági incidens, beszállítói hiba vagy belső audit során. A probléma ritkán az információ hiánya. Sokkal inkább a kapcsolatok hiánya.

A megoldás az, hogy a RoPA-t és az adatáramlások feltérképezését közös bizonyítéki réteggé kell tenni az adatvédelem, a kiberreziliencia, a beszállító-kezelés, a felhőirányítás és az üzletmenet-folytonosság számára.

Miért vált a RoPA és az adatáramlások feltérképezése 2026-os irányítási kérdéssé

A RoPA-t korábban adatvédelmi artefaktumnak tekintették. Az adatáramlási térképek gyakran egy DPIA, felhőmigráció vagy biztonsági architektúra-felülvizsgálat során készültek el, majd elavultak. Ez a megközelítés már nem működik.

A GDPR széles körben alkalmazandó az EU-ban letelepedett szervezet tevékenységével összefüggő személyesadat-kezelésre, valamint számos EU-n kívüli adatkezelőre vagy adatfeldolgozóra is, ha árukat vagy szolgáltatásokat kínálnak az EU-ban tartózkodó személyeknek, vagy monitorozzák a viselkedésüket. A személyes adat az azonosított vagy azonosítható természetes személyre vonatkozó információt jelenti. Az adatkezelés magában foglalja a gyűjtést, tárolást, felhasználást, közlést, korlátozást, törlést és megsemmisítést. Az adatkezelő határozza meg a célokat és eszközöket, míg az adatfeldolgozó az adatkezelő nevében jár el.

A RoPA ezért nem csupán adatbázisok listája. Üzleti célok, adatkategóriák, szerepkörök, címzettek, megőrzési idők, védelmi intézkedések és nemzetközi függőségek nyilvántartása.

A NIS2 ehhez szolgáltatásreziliencia-szemléletet ad. Hatálya alá von számos közepes és nagyobb szervezetet a kiemelten kritikus és más kritikus ágazatokból, ideértve a digitális infrastruktúrát, a felhőszolgáltatásokat, az adatközponti szolgáltatókat, a tartalomelosztó hálózatokat, a bizalmi szolgáltatókat, a nyilvános elektronikus hírközlési szolgáltatókat, a menedzselt szolgáltatókat és a menedzselt biztonsági szolgáltatókat. Az Annex I a banki és pénzügyi piaci infrastruktúrákat is tartalmazza. Egyes szervezetek mérettől függetlenül is érintettek lehetnek, ideértve bizonyos DNS-, TLD-, bizalmi szolgáltatási és nyilvános hírközlési szolgáltatókat, valamint azokat a szervezeteket, amelyek zavara jelentősen érintheti a közbiztonságot, a közegészségügyet, a rendszerszintű kockázatot vagy a kritikus társadalmi és gazdasági tevékenységeket.

A NIS2 Article 21 arányos technikai, operatív és szervezeti intézkedéseket ír elő az üzemeltetéshez vagy szolgáltatásnyújtáshoz használt hálózati és információs rendszerekre. Minimumterületei 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 fejlesztés, az eredményesség értékelése, a kiberhigiénia, a kriptográfia, a HR-biztonság, a hozzáférés-szabályozás, az eszközkezelés és a hitelesítés.

Egy NIS2 hatálya alá tartozó szervezetnél a szolgáltatásfüggőségi nézet nélküli RoPA hiányos. Egy jelentős incidenst szolgáltatáshatás, működési zavar, érintett címzettek, beszállítók és határokon átnyúló következmények szerint kell értelmezni.

A DORA ugyanezt a szempontot élesíti a pénzügyi szervezeteknél. 2025. január 17-től alkalmazandó, és egységes követelményeket határoz meg az IKT-kockázatkezelésre, a jelentős IKT-val kapcsolatos incidensek bejelentésére, a digitális működési reziliencia tesztelésére, a kiberfenyegetésekre és sérülékenységekre vonatkozó információmegosztásra, az IKT harmadik fél kockázatra, valamint az IKT harmadik fél szolgáltatókkal kötött szerződéses megállapodásokra. A DORA az IKT-szolgáltatásokat tágan, IKT-rendszereken keresztül folyamatosan nyújtott digitális és adatszolgáltatásként határozza meg. A kritikus vagy fontos funkciót olyan funkcióként definiálja, amelynek zavara lényegesen rontaná a pénzügyi teljesítményt, a szolgáltatás-folytonosságot vagy a megfelelési kötelezettségek teljesítését.

Azoknál a pénzügyi szervezeteknél, amelyeket a NIS2 nemzeti átültetése is azonosít, a DORA az egyenértékű IKT-kockázati, incidensbejelentési, tesztelési, információmegosztási és harmadik fél kockázati követelmények ágazatspecifikus uniós jogi aktusának minősül. A gyakorlatban egy fintech nem építhet külön bizonyítékkészletet az adatvédelemhez, külön a DORA-hoz és külön a NIS2-höz. Egyetlen, függőségérzékeny adatirányítási rétegre van szüksége.

Ez a réteg a RoPA és az adatáramlások feltérképezése együtt.

Az ISO/IEC 27001:2022 a gerinc

Az ISO/IEC 27001:2022 pontosan ilyen integrációra készült. Skálázható információbiztonság-irányítási rendszert, azaz IBIR-t hoz létre, amelynek célja a bizalmasság, a sértetlenség és a rendelkezésre állás megőrzése kockázatkezelésen keresztül. A szabvány célja, hogy beépüljön a szervezeti folyamatokba, és a szervezet igényeihez, méretéhez és struktúrájához igazodjon.

A kiindulópont nem a diagramkészítő eszköz. A kiindulópont a hatály.

Az ISO/IEC 27001:2022 4.1–4.4 pontjai megkövetelik, hogy a szervezet meghatározza a környezetét, az érdekelt feleket, az IBIR alkalmazási területét és az egymással kölcsönhatásban álló folyamatokat. A hatálynak figyelembe kell vennie a jogi, szabályozási és szerződéses kötelezettségeket, valamint a belső tevékenységek és más szervezetek által végzett tevékenységek közötti interfészeket és függőségeket. A RoPA és az adatáramlások feltérképezése szempontjából ez azt jelenti, hogy az IBIR alkalmazási területének kifejezetten tartalmaznia kell a kiszervezett felhőplatformokat, fizetési feldolgozókat, identitásszolgáltatókat, támogatási eszközöket, menedzselt biztonsági szolgáltatókat és üzletmenet-kritikus SaaS-integrációkat.

Az 5.1–5.3 pontok a vezetést teszik elszámoltathatóvá a szabályzatért, az erőforrásokért, a szerepkör-hozzárendelésért és a jelentéstételért. Ez tükrözi a NIS2 Article 20 irányát, amely előírja, hogy a vezető testületek hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék a végrehajtást és képzésen vegyenek részt. Összhangban áll a DORA Article 5 rendelkezésével is, amely a vezető testület végső felelősségévé teszi az IKT-kockázatot, valamint a szabályzatok, rezilienciastratégia, folytonossági tervek, audittervek, IKT harmadik fél szolgáltatások és jelentős incidensbejelentési csatornák felügyeletét.

A 6.1.1–6.1.3 pontok adják a tervezési motort: a bizalmasságot, sértetlenséget és rendelkezésre állást érintő kockázatok azonosítása, kockázattulajdonosok kijelölése, következmények és valószínűség elemzése, kockázatkezelési opciók kiválasztása, kontrollok összevetése az A melléklettel, az alkalmazhatósági nyilatkozat elkészítése és a kockázatgazdai jóváhagyás megszerzése.

Itt válik a RoPA működési eszközzé. Minden adatkezelési tevékenységet és adatáramlást össze kell kapcsolni kockázatokkal, kontrollokkal, beszállítókkal, eszközökkel és kritikus szolgáltatásokkal. Ha ez nem történik meg, a RoPA adatvédelmi nyilvántartás marad, amely nem támogatja az incidensreagálást, a rezilienciatesztelést vagy a beszállítói kockázati döntéseket.

A Clarysec Zenith Blueprint: auditori 30 lépéses ütemterv ezt gyakorlativá teszi a kockázatkezelési szakasz 9. lépésében, az eszközök, fenyegetések és sérülékenységek azonosításánál:

Minden eszköznél rögzítse a fő adatokat: Név/leírás, Tulajdonos, Hely, és Osztályozás (érzékenység). Például egy eszköz lehet: „Ügyféladatbázis – az IT részleg tulajdonában – AWS-en üzemeltetve – személyes és pénzügyi adatokat tartalmaz (magas érzékenység)”.

Ugyanez a 9. lépés hozzáadja a kulcsfontosságú megfelelési felismerést: a személyesadat-eszközöket GDPR-relevancia szerint jelölni kell, a kritikus szolgáltatási eszközöket pedig potenciális NIS2 alkalmazhatóság szempontjából kell feltüntetni, ha a szervezet szabályozott ágazatban működik. Ez a híd a RoPA, az eszköznyilvántartás és a kritikus szolgáltatások függőségi feltérképezése között.

Mit kell tartalmaznia egy auditálható RoPA-nak

Egy erős RoPA-nak nem kell bonyolultnak lennie, de összekapcsoltnak kell lennie.

A GDPR Article 5 előírja, hogy a személyes adatokat jogszerűen, tisztességesen és átláthatóan kell kezelni, meghatározott és jogszerű célokra kell gyűjteni, a szükséges mértékre kell korlátozni, pontosan kell tartani, csak a szükséges ideig szabad megőrizni, és megfelelő technikai és szervezeti intézkedésekkel kell védeni. Az Article 5(2) előírja, hogy az adatkezelő felelős a megfelelésért, és képesnek kell lennie annak igazolására.

Az Article 6 jogalapot követel meg, például hozzájárulást, szerződés teljesítéséhez szükségességet, jogi kötelezettséget, létfontosságú érdeket, közérdekű feladatot vagy jogos érdeket. Ha az adatkezelés új célból történik, az összeegyeztethetőséget az eredeti és az új cél, az adatgyűjtés kontextusa, az érzékenység, az érintettekre gyakorolt következmények, valamint az olyan védelmi intézkedések figyelembevételével kell értékelni, mint a titkosítás vagy az álnevesítés. Az Article 9 szigorúbb szabályokat ad a személyes adatok különleges kategóriáira, ideértve az egészségügyi adatokat, az egyedi azonosításra használt biometrikus adatokat és más érzékeny kategóriákat.

A Clarysec KKV-szabályzatcsomagja ezt működési követelménnyé alakítja. A Adatvédelmi és magánszféra-védelmi szabályzat - KKV kimondja:

Az adatvédelmi koordinátornak nyilvántartást kell vezetnie valamennyi személyesadat-kezelési tevékenységről, beleértve az adatkategóriákat, a célt, a jogalapot és a megőrzési időket

Ez az Irányítási követelmények szakasz 5.2.1 pontjából származik. Nagyobb szervezeteknél a Clarysec Adatvédelmi és magánszféra-védelmi szabályzat közvetlenül kijelöli a felelősséget:

Fenntartja az adatkezelési tevékenységek nyilvántartását (RoPA) a GDPR Article 30 szerint.

Ez a megfogalmazás a Szerepkörök és felelősségek 4.2.2 pontjából származik. A gyakorlati üzenet egyszerű: a RoPA tulajdonosi felelősségét ki kell jelölni. Nem lehet gazdátlan megfelelőségi táblázat.

Egy 2026-ra felkészített RoPA-nak az alábbi mezőket kell tartalmaznia.

Az utolsó sorok emelik át a RoPA-t az adatvédelmi dokumentációból a kiberreziliencia bizonyítékai közé. Rendszerek, beszállítók, helyszínek, kritikusság és kontrollok nélkül a RoPA teljesíthet egy szűk Article 30 ellenőrzőlistát, de elbukik, amint egy incidens, szolgáltatáskimaradás vagy felügyeleti felülvizsgálat hatáselemzést igényel.

Az adatáramlások feltérképezése összekapcsolja az adatvédelmet, a felhőt és a kritikus szolgáltatásokat

Ha a RoPA arra válaszol, hogy „milyen adatkezelés létezik és miért”, akkor az adatáramlási térkép arra, hogy „hová mozognak az adatok, ki fér hozzájuk, mi védi őket, és mi sérül, ha a folyamat megáll”.

A Clarysec Adatmaszkolási és pszeudonimizálási szabályzat - KKV egyértelművé teszi a követelményt:

Adatáramlási térképet kell készíteni.

Ez az Irányítási követelmények 5.1.1.1 pontjából származik. A vállalati verzió, az Adatmaszkolási és pszeudonimizálási szabályzat, az 5.2.1 pontban bővíti az elvárást:

Naprakész nyilvántartást kell vezetni az érzékeny adatokat érintő rendszerekről és adatáramlásokról.

Az 5.2.2 pont hozzáteszi:

Fel kell térképezni, hol és hogyan történik az adatok átalakítása, megosztása vagy elérése a környezetek között.

Az auditorok és szabályozó hatóságok nem művészi diagramokat keresnek. Az átalakításokat, hozzáférési utakat, megosztást, környezeteket és védelmi intézkedéseket akarják megérteni.

A Zenith Blueprint Kontrollok működésben szakaszának 22. lépése, a 5.1–5.18 szervezeti kontrollok körében, az információtovábbítási útmutató kimondja, hogy a szervezeteknek meg kell határozniuk az engedélyezett továbbítási módszereket, azokat az osztályozással összhangba kell hozniuk, és biztosítaniuk kell, hogy a felek értsék szerepköreiket és kötelezettségeiket. Példaként titkosított e-mailt, biztonságos portálokat, SFTP-t, alkalmazásprogramozási interfészeket és titkosítással védett fizikai kézbesítést említ. Azt is rögzíti, hogy a határokon átnyúlóan továbbított személyes adatoknak meg kell felelniük az adatvédelmi és jogi kötelezettségeknek, nem csupán a belső preferenciáknak.

Ugyanez a lépés az információtovábbítást az osztályozáshoz és jelöléshez, az adatvesztés-megelőzéshez, a beszállítói kapcsolatokhoz és a kriptográfiához kapcsolja. Ez gyakorlati modellt ad az adatáramlások feltérképezéséhez:

1. Azonosítsa a forrásrendszert, például CRM-et, fizetési platformot, HRIS-t vagy támogatási ügyfélszolgálatot.
2. Azonosítsa az adatkategóriát, ideértve a személyes adatokat, pénzügyi adatokat, munkavállalói adatokat, különleges kategóriájú adatokat vagy hitelesítő adatokat.
3. Azonosítsa a továbbítási módszert, például API-t, SFTP-t, e-mailt, biztonságos portált, manuális exportot vagy biztonsági mentési replikációt.
4. Azonosítsa a célhelyet, ideértve a belső rendszert, felhőszolgáltatást, beszállítót, al-adatfeldolgozót, adattárházat vagy archívumot.
5. Azonosítsa a védelmet, például titkosítást, álnevesítést, hozzáférés-szabályozást, naplózást, DLP-t vagy szerződéses korlátozást.
6. Azonosítsa a függőséget, ideértve azt is, hogy az adatáramlás támogat-e kritikus üzleti funkciót, kritikus vagy fontos funkciót, alapvető szolgáltatást vagy incidensbejelentési kötelezettséget.

Három ISO/IEC 27001:2022 A melléklet szerinti kontroll különösen fontos itt. Az ISO/IEC 27002:2022 adja ezeknek a kontrolloknak a végrehajtási útmutatóját:

A Clarysec Zenith Controls: keresztmegfelelőségi útmutató a 5.9, 5.14 és 5.34 kontrollokat e témakörhöz kapcsolódó kontrollként azonosítja ehhez az irányítási réteghez. Kezelje őket horgonykontrollként, majd az alkalmazhatósági nyilatkozaton keresztül kapcsolja őket beszállítói, felhő-, incidens-, folytonossági, naplózási, hozzáférési és kriptográfiai kontrollokhoz.

Miért kell több a NIS2-nek és a DORA-nak egy adatvédelmi nyilvántartásnál

Gyakori hiba olyan RoPA-t építeni, amely a GDPR alapján technikailag helyes, de NIS2 vagy DORA szempontból használhatatlan. A különbség a szolgáltatás kritikussága.

A NIS2 Article 23 megköveteli, hogy az alapvető és fontos szervezetek indokolatlan késedelem nélkül bejelentsék a jelentős incidenseket. Jelentéstételi modellje 24 órán belüli korai figyelmeztetést, 72 órán belüli incidensbejelentést és egy hónapon belüli zárójelentést tartalmaz. A jelentős incidenseket súlyos működési zavar, pénzügyi veszteség, vagy más természetes vagy jogi személyeket érő vagyoni vagy nem vagyoni kár alapján kell értékelni. Ez az értékelés attól függ, hogy ismert-e, mely szolgáltatások, címzettek, országok, rendszerek és beszállítók érintettek.

A DORA Article 17 előírja, hogy a pénzügyi szervezetek határozzanak meg és vezessenek be IKT-val kapcsolatos incidenskezelési folyamatot, amely észleli, kezeli és bejelenti az incidenseket, rögzíti az incidenseket és a jelentős kiberfenyegetéseket, azonosítja a gyökérokokat, korai figyelmeztető indikátorokat határoz meg, az incidenseket az érintett szolgáltatások súlyossága és kritikussága szerint osztályozza, szerepköröket rendel hozzá, valamint kommunikációs és eszkalációs eljárásokat hoz létre. Az Article 18 a besorolást az érintett ügyfelek vagy partnerek és tranzakciók, az időtartam és szolgáltatáskiesés, a földrajzi kiterjedés, a rendelkezésre állást, hitelességet, sértetlenséget vagy bizalmasságot érintő adatvesztés, az érintett szolgáltatások kritikussága és a gazdasági hatás alapján írja elő.

Nem lehet gyorsan besorolni egy incidenst, ha nem ismert az adatáramlási és függőségi lánc.

A Clarysec Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat - KKV rámutat arra a bizonyítéki mezőre, amelyre a szervezeteknek szükségük van:

priorizált szolgáltatások és rendszerek (kritikus üzleti funkciók)

Ez az Irányítási követelmények 5.2.1.2 pontjából származik. A vállalati Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat az 5.2.4 pontban hozzáadja a függőségi dimenziót:

Kritikus függőségek (rendszerek, beszállítók, személyzet)

A DORA által szabályozott szervezeteknél ennek összhangban kell állnia a kritikus vagy fontos funkciókkal, az IKT-szolgáltatásokkal, a szerződéses megállapodásokkal és a kilépési stratégiákkal. A DORA Article 28 előírja, hogy az IKT harmadik fél kockázatot az IKT-kockázati keretrendszer részeként kell kezelni. Előírja az IKT-szolgáltatási szerződéses megállapodások nyilvántartását, megköveteli a szerződéskötést megelőző kellő gondosságot, a kritikusság, a koncentrációs kockázat, az alkalmasság és az összeférhetetlenség értékelését, valamint kilépési stratégiákat követel meg a kritikus vagy fontos funkciókat támogató IKT-szolgáltatásokra.

A DORA Article 30 meghatározza a minimális IKT-szerződéses feltételeket, ideértve a szolgáltatásleírásokat, az alvállalkozói feltételeket, az adatkezelési és adattárolási helyeket, az adatvédelmet, a hozzáférést, az adatok helyreállítását és visszaszolgáltatását, a szolgáltatási szinteket, az incidensekhez nyújtott támogatást, a hatóságokkal való együttműködést, a felmondási jogokat, az auditálási jogokat és az átmeneti vagy kilépési megállapodásokat.

Az a RoPA, amely nem azonosítja a beszállítókat, helyszíneket, továbbítási módszereket, kritikusságot és kilépési függőségeket, nem támogatja a DORA bizonyítékait.

A beszállítók, felhőszolgáltatások és al-adatfeldolgozók feltérképezésénél szokott szétesni a bizonyítéki lánc

Valós auditok során a RoPA-hibák gyakran beszállítói hibaként jelennek meg. Az adatkezelési tevékenység azt mondja: „ügyféltámogatás”. Az adatáramlási térkép azt mondja: „támogatási platform”. De senki nem tudja azonosítani a tárhelyrégiót, az AI-átírási kiegészítőt, az analitikai al-adatfeldolgozót, a jegycsatolmányok megőrzését, az adminisztrátori hozzáférési modellt vagy a kilépési eljárást.

A Clarysec KKV-beszállítói szabályzata létrehozza a minimális működési bizonyítékot. A Harmadik fél és beszállítói biztonsági szabályzat - KKV kimondja:

Beszállítói nyilvántartást kell fenntartani, és azt az adminisztratív vagy beszerzési kapcsolattartónak frissítenie kell. Tartalmaznia kell:

Ez az Irányítási követelmények 5.4 pontjából származik. A felhőszabályzat külön nyilvántartási követelményt ad hozzá. A Felhőszolgáltatások használatára vonatkozó szabályzat - KKV kimondja:

A felhőszolgáltatások nyilvántartását az IT-szolgáltatónak vagy az ügyvezetőnek kell fenntartania. Rögzítenie kell:

Ez az Irányítási követelmények 5.3 pontjából származik. Vállalati függőségi kockázat esetén a Clarysec Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat még egyértelműbb:

Beszállítói függőségi nyilvántartás: A VMO-nak naprakész nyilvántartást kell vezetnie valamennyi kritikus beszállítóról, beleértve többek között a nyújtott szolgáltatásokat/termékeket; azt, hogy a beszállító egyforrásos-e; az elérhető alternatív beszállítókat vagy helyettesíthetőséget; az aktuális szerződéses feltételeket; valamint annak hatásértékelését, ha a beszállító kiesne vagy kompromittálódna. A nyilvántartásnak egyértelműen azonosítania kell a magas függőségi kockázatú beszállítókat (pl. azokat, amelyekre nincs gyors alternatíva).

Ez a követelmény, amely a Végrehajtási követelmények 6.1 pontjából származik, pontosan az, ami összekapcsolja a RoPA-t a NIS2 ellátásilánc-biztonsággal és a DORA IKT harmadik fél kockázattal.

A Zenith Blueprint Kontrollok működésben szakaszának 23. lépése, az 5.19–5.37 szervezeti kontrollok körében azt javasolja, hogy készüljön teljes beszállítói lista, a beszállítókat a rendszerekhez, adatokhoz vagy operatív kontrollhoz való hozzáférésük alapján kell osztályozni, a szerződésekbe biztonsági elvárásokat kell beépíteni, az alvállalkozókat felül kell vizsgálni, beszállítói változásindítókat kell kialakítani, és olyan felhőszolgáltatás-értékelési folyamatot kell építeni, amely lefedi az adathelyet, a hozzáférési modellt, a naplózást és a titkosítást.

Ez teszi lehetővé, hogy az információbiztonsági vezető incidens közben választ adjon: „Melyik kritikus szolgáltatás használja ezt a beszállítót, milyen adat került kitettségbe, mely ügyfeleket kell értesíteni, mely szabályozó hatóságnak lehet szüksége jelentésre, és milyen alternatív beszállító vagy kilépési út áll rendelkezésre?”

Gyakorlati példa: ügyfélbeléptetés egy fintech vállalatnál

Vegyünk egy fintech vállalatot, amely digitális pénztárca ügyfélbeléptetést biztosít. Az ügyfelek személyazonosító okmányokat töltenek fel, egy beszállító biometrikus liveness-ellenőrzéseket végez, az eredményeket felhőadatbázisban tárolják, az ügyféltámogatás pedig egy jegykezelő eszközben megtekintheti az ellenőrzési státuszt.

Az ügyfélbeléptetési szolgáltatás a DORA szerint kritikus vagy fontos funkció lehet, mert zavara lényegesen érinti a szolgáltatás-folytonosságot és a szabályozási kötelezettségeket. Ha a vállalat NIS2-ágazatban működik vagy releváns IKT-szolgáltatásokat nyújt, ez a kritikus szolgáltatási bizonyítékok része is lehet.

Egy használható térkép egy összekapcsolt nyilvántartási bejegyzéssel kezdődik.

Most adja hozzá az ISO/IEC 27001:2022 kockázatkezelési visszakövethetőséget.

A Zenith Blueprint kockázatkezelési szakaszának 13. lépésében, a kockázatkezelési tervezés és alkalmazhatósági nyilatkozat résznél a Clarysec a SoA-t olyan híd-dokumentumként írja le, amely összekapcsolja a kockázatértékelést és a kockázatkezelést a tényleges kontrollokkal. Azt javasolja, hogy a kontrollokat kockázatokhoz kell rendelni, és ahol releváns, a kockázati nyilvántartásban vagy a SoA megjegyzéseiben kereszthivatkozni kell olyan szabályozásokra, mint a GDPR, a NIS2 vagy a DORA.

Az ügyfélbeléptetési példában a kockázati forgatókönyv ez lehet: „Az identitásellenőrző szolgáltató kiesése vagy kompromittálódása megzavarja az ügyfélbeléptetést, és biometrikus személyazonosító adatokat tesz ki.” A kockázatkezelési kontrollok közé tartozhat a beszállítói átvilágítás, a szerződéses incidensbejelentés, a titkosítás, a hozzáférés-szabályozás, a naplózás, a biztonsági mentés és helyreállítás, az adattakarékosság, az álnevesítés, a megfigyelés, a kilépési tervezés és az incidensreagálási forgatókönyvek.

A SoA-megjegyzés rögzítheti, hogy a kontrollkészlet támogatja a GDPR szerinti elszámoltathatóságot, a NIS2 Article 21 szerinti ellátási lánc és incidensfelkészültséget, valamint a DORA szerinti IKT harmadik fél kockázatot és a kritikus funkciók rezilienciáját.

Ezt várják az auditorok: visszakövethetőséget.

Keresztmegfelelőségi leképezés: egy bizonyítéki réteg, több kérdés

A RoPA és az adatáramlások feltérképezése nem különálló megfelelési siló. Közös kérdéskészletet támogat a GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 és COBIT 2019 területén.

A NIST CSF 2.0 hasznos rendszerező réteg. A CSF-profilok támogatják a jelenlegi és célállapot elemzését olyan inputok alapján, mint a szabályzatok, kockázati prioritások, üzleti hatásnyilvántartások, követelmények, szabványok, gyakorlatok, eszközök és munkaszerepkörök. A GOVERN funkció tartalmazza a jogi, szabályozási, szerződéses, adatvédelmi és polgári szabadságjogi kötelezettségeket, a kockázati célokat, a vezetői elszámoltathatóságot, a szerepköröket, a szabályzatot, a felügyeletet és a teljesítményfelülvizsgálatot. Ellátási láncra vonatkozó eredményei megkövetelik, hogy a beszállítók ismertek legyenek és kritikusság alapján priorizálják őket, a szerződéses kiberbiztonsági követelmények beépüljenek, a kellő gondosság a kapcsolat előtt megtörténjen, a beszállítói kockázatokat rögzítsék és nyomon kövessék, valamint a beszállítókat bevonják az incidensreagálási és helyreállítási tervezésbe.

Ez jól illeszkedik a Clarysec RoPA működési modelljéhez. A RoPA adja az adatvédelmi kontextust. Az eszköznyilvántartás adja a technikai kontextust. A beszállítói és felhőnyilvántartások adják a harmadik fél kontextust. A BIA adja a kritikussági kontextust. A SoA adja a kontrollkontextust.

Egyetlen ISO/IEC 27001:2022 A melléklet szerinti kontroll több keretrendszert is támogathat. A 5.14 kontroll, az Információtovábbítás jó példa erre.

Ez a Zenith Controls értéke keresztmegfelelőségi iránytűként. Segít a szervezeteknek elmagyarázni, hogy egyetlen kontrollgyakorlat miért támogat több szabályozói és audit elvárást.

Hogyan tesztelik különböző auditorok ugyanazt a térképet

Egy érett RoPA és adatáramlási térkép több auditort is ki tud szolgálni, de mindegyik más irányból közelíti meg.

Egy ISO/IEC 27001:2022 auditor a hatállyal, az érdekelt felekkel, a kockázatokkal, a dokumentált információkkal és a kontrollkiválasztással kezdi. Meg fogja kérdezni, hogy azonosították-e a jogi és szerződéses követelményeket, a személyes adatok és a kritikus szolgáltatások az IBIR alkalmazási területén belül vannak-e, az eszközöknek van-e tulajdonosuk és osztályozásuk, a kockázatértékelés figyelembe vette-e a bizalmasságot, sértetlenséget és rendelkezésre állást, valamint hogy a SoA indokolja-e az alkalmazandó kontrollokat.

Egy GDPR-auditor vagy adatvédelmi szabályozó hatóság az elszámoltathatósággal kezdi. Ellenőrzi, hogy a RoPA tükrözi-e a valós adatkezelést, dokumentáltak-e a célok és jogalapok, azonosították-e a különleges kategóriájú adatokat, alkalmazzák-e a megőrzési időket, pontosak-e a címzettek és adatfeldolgozók, és léteznek-e megfelelő védelmi intézkedések az adattovábbításokra és a biztonságra.

Egy NIS2-fókuszú auditor a szolgáltatáshatást vizsgálja. Megkérdezi, hogyan határozza meg a szervezet a kritikus vagy fontos szolgáltatásokat, hogyan hagyta jóvá és felügyeli a vezetés a kockázati intézkedéseket, hogyan veszik figyelembe a beszállítói sérülékenységeket és szolgáltatói kockázatokat, hogyan kapcsolódik a folytonosság és az incidenskezelés, és hogy a szervezet képes-e megbízható bizonyítékokkal támogatni a 24 órás, 72 órás és zárójelentési határidőket.

Egy DORA-auditor az IKT-kockázatirányítást és a kritikus vagy fontos funkciókat vizsgálja. Teszteli, hogy a vezető testület jóváhagyta-e az IKT-kockázati keretrendszert és a rezilienciastratégiát, nyilvántartják-e az IKT harmadik fél megállapodásokat, értékelik-e a kritikusságot és a koncentrációs kockázatot, tartalmazzák-e a szerződések az előírt feltételeket, a tesztelés lefedi-e a kritikus vagy fontos funkciókat támogató rendszereket, és az incidenseket az érintett ügyfelek, tranzakciók, kiesési idő, földrajzi kiterjedés, adatvesztés, szolgáltatáskritikusság és gazdasági hatás alapján osztályozzák-e.

Egy NIST CSF 2.0 értékelő gyakran profilokat használ. Összeveti a jelenlegi és célállapotú eredményeket a GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER funkciókban. A RoPA és az adatáramlási térképek bemenetekké válnak a jogi kötelezettségek kezeléséhez, az eszköznyilvántartásokhoz, a beszállítói kockázathoz, az adatvédelemhez, a megfigyeléshez, az incidenskommunikációhoz és a helyreállítási tervezéshez.

Egy COBIT 2019 vagy ISACA-stílusú auditor az irányításra, a tulajdonosi felelősségre és a folyamatképességre fókuszál. Teszteli, hogy az információáramlásoknak van-e tulajdonosuk, egyértelműek-e a döntési jogosultságok, alkalmazzák-e a kockázatvállalási hajlandóságot, monitorozzák-e a kontrollokat, eszkalálják-e a kivételeket, és a bizonyítékok elég megbízhatóak-e a vezetői bizonyossághoz.

Gyakori hibaminták

A RoPA és az adatáramlás-feltérképezés leggyakoribb hibái előre jelezhetők.

Először: a RoPA adatkezelési tevékenységeket sorol fel, de rendszereket nem. Ez lehetetlenné teszi a GDPR szerinti elszámoltathatóság összekapcsolását a sérülékenységkezeléssel, hozzáférési felülvizsgálattal, biztonsági mentéssel, naplózással vagy incidensreagálással.

Másodszor: az adatáramlási térképek megállnak az első beszállítónál. Nem mutatják az al-adatfeldolgozókat, felhőrégiókat, támogatási hozzáférést, analitikai eszközöket, monitorozási platformokat vagy biztonsági mentési helyeket.

Harmadszor: az üzletmenet-folytonossági tervek rendszereket azonosítanak, de személyes adatokat nem. Egy szolgáltatáskimaradás során a szervezet érti a helyreállítási prioritást, de nem érti az adatvédelmi hatást.

Negyedszer: a beszállítói nyilvántartások szerződésgazdákat rögzítenek, de kritikusságot, helyettesíthetőséget, adatkategóriákat, incidensbejelentési kötelezettségeket vagy kilépési lehetőségeket nem.

Ötödször: a SoA tanúsítási dokumentumként készül, nem kontrollhídként. Azt mondja, hogy a kontrollok alkalmazandók, de nem magyarázza el, hogy mely GDPR-, NIS2- vagy DORA-bizonyítéki problémát segítik megoldani.

Végül: a tulajdonosi felelősség széttöredezett. A DPO birtokolja a RoPA-t, az IT az eszközöket, a beszerzés a beszállítókat, az üzemeltetés a BIA-t, a pénzügy a DORA-nyilvántartásokat, és senki nem birtokolja az integrált függőségi térképet.

A Clarysec megközelítése ezt úgy javítja, hogy a bizonyítékobjektumokat szabályzatgazdákhoz rendeli, majd a Zenith Blueprint lépéseivel összekapcsolja az eszközöket, kockázatokat, kontrollokat és SoA-visszakövethetőséget.

30 napos végrehajtási terv

Nem kell mindent egyszerre megoldani. Kezdje a legfontosabb szolgáltatásokkal.

1. hét: Válasszon ki három kritikus vagy magas kockázatú adatkezelési tevékenységet. Jó jelöltek az ügyfélbeléptetés, a fizetésfeldolgozás, a munkavállalói HR-adminisztráció, a támogatási jegykezelés vagy a biztonsági monitorozás. Mindegyiknél ellenőrizze a RoPA-bejegyzést a tényleges rendszerek, adatkategóriák, célok, jogalapok és megőrzési szabályok alapján.

2. hét: Készítsen adatáramlási térképeket ezekhez a tevékenységekhez. Azonosítsa a forrást, a célhelyet, a továbbítási módszert, a környezetet, a beszállítót, az al-adatfeldolgozót, az adathelyet, a hozzáférési utat, az átalakítást és a megőrzési pontot. Használja a Clarysec Adatmaszkolási és pszeudonimizálási szabályzat azon követelményét, hogy nyilvántartást kell vezetni az érzékeny adatokat érintő rendszerekről és adatáramlásokról.

3. hét: Kapcsolja össze az egyes adatáramlásokat eszközökkel, beszállítókkal, felhőszolgáltatásokkal és kritikus üzleti funkciókkal. Használja a Zenith Blueprint 9. lépését az eszköztulajdonosi felelősséghez és osztályozáshoz. Használja a beszállítói és felhőnyilvántartási szabályzati követelményeket a harmadik fél bizonyítékok rögzítéséhez. Használja az üzletmenet-folytonossági szabályzatot a priorizált szolgáltatások és kritikus függőségek azonosításához.

4. hét: Adja hozzá a kockázati és kontroll-visszakövethetőséget. Minden adatáramláshoz hozzon létre vagy frissítsen kockázati forgatókönyveket. A kontrollokat a Zenith Blueprint 13. lépése alapján képezze le a SoA-ban. Ahol alkalmazandó, adjon hozzá megjegyzéseket a GDPR Article 30 szerinti elszámoltathatósághoz, a NIS2 Article 21 szerinti kockázati intézkedésekhez és a DORA IKT-függőségi bizonyítékaihoz.

Ezután futtasson le egy asztali gyakorlatot: „Beszállítói kiesés és adatkitettség egy kritikus szolgáltatásban.” Tesztelje, hogy a bizonyítékok támogatják-e az incidensbesorolást, az értesítési döntéseket, az ügyfélkommunikációt, a szabályozó hatósági kommunikációt és a helyreállítási prioritások meghatározását.

30 nap végére megismételhető modellje lesz a szervezet többi részére.

A Clarysec-megközelítés: a RoPA élő rezilienciabizonyítékká alakítása

A RoPA és az adatáramlások feltérképezése már nem pusztán adatvédelmi adminisztráció. Ezek jelentik a kötőszövetet a GDPR szerinti elszámoltathatóság, a NIS2 kritikus szolgáltatási irányítás és a DORA IKT-függőségi bizonyítékai között.

Azok a szervezetek fognak a legjobban teljesíteni 2026-ban, amelyek nem a legtöbb dokumentummal rendelkeznek. Hanem azok, amelyek vissza tudnak követni egy üzleti szolgáltatást az adatkezelési tevékenységeihez, adatáramlásaihoz, rendszereihez, beszállítóihoz, felhőrégióihoz, szerződéseihez, kontrolljaihoz, kockázataihoz, incidensküszöbeihez és helyreállítási terveihez.

A Clarysec segít a csapatoknak ezt a visszakövethetőséget szükségtelen bürokrácia nélkül felépíteni. Szabályzatcsomagunk tulajdonosi felelősséget és bizonyítéki követelményeket rendel hozzá. A Zenith Blueprint biztosítja a végrehajtási ütemtervet, beleértve az eszközazonosítást, a beszállítói és felhőkontrollok bevezetését, valamint a SoA-visszakövethetőséget. A Zenith Controls keresztmegfelelőségi iránytűt ad az ISO/IEC 27001:2022 A melléklet szerinti kontrollok adatvédelmi, reziliencia-, beszállítói, felhő- és audit elvárásokhoz történő leképezéséhez.

A következő lépés egyszerű: válasszon ki egy kritikus szolgáltatást, egy RoPA-bejegyzést és egy beszállító által támogatott adatáramlást. Térképezze fel végponttól végpontig. Ha egy oldalon nem tudja elmagyarázni az adatot, a függőséget, a kontrollt és az incidenshatást, akkor a bizonyítéki rétege nem áll készen 2026-ra.

A Clarysec segíthet felkészíteni. Ismerje meg a Zenith Blueprint megoldást, erősítse irányítását az Adatvédelmi és magánszféra-védelmi szabályzat és a Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat segítségével, és használja a Zenith Controls útmutatót, hogy a széttöredezett megfelelési bizonyítékokat egyetlen, auditálható működési modellé alakítsa.