DPIA-irányítás ISO 27001, NIS2 és DORA környezetben
Csütörtök 17:40 van, és Máriát, egy gyorsan növekvő fintech vállalat információbiztonsági vezetőjét arra kérik, hogy még a negyedév vége előtt hagyjon jóvá egy kiadást.
A termékcsapat áttörésként hivatkozik rá: biometrikus fizetési hitelesítési és viselkedéselemzési funkció, amely zökkenőmentesebbé teszi az ügyfélhozzáférést és csökkenti a csalásokat. A fejlesztés szerint nem jön létre új központi adatbázis. Az értékesítés szerint egy szabályozott pénzügyi ügyfél már várja. A kiadásmenedzser a jegyet már standard változásként jelölte meg.
Ekkor a DPO három kérdést tesz fel.
Összekapcsolja-e a funkció a biometrikus vagy viselkedési adatokat fiókattribútumokkal? Kap-e egy felhőalapú al-adatfeldolgozó telemetriai adatokat vagy hitelesítési jelzéseket? Felmérte-e bárki, hogy a változás magas kockázatot jelent-e az érintettek jogaira és szabadságaira nézve?
A terem elcsendesedik.
Máriának van ISO/IEC 27001:2022 szerinti kockázati nyilvántartása. A jogi területnek van GDPR szerinti adatkezelési tevékenységek nyilvántartása. A beszerzésnek van beszállítói kérdőíve. A felhőcsapatnak van szolgáltatói biztonsági felülvizsgálata. A változásmenedzsernek van jegye. Az igazgatóságot éppen tájékoztatták a NIS2 szerinti elszámoltathatóságról és a DORA operatív rezilienciára vonatkozó elvárásairól.
Ezek közül egyik nyilvántartás sem mutatja önmagában a teljes képet.
Ez a DPIA-irányítás problémája 2026-ban. Az adatvédelmi hatásvizsgálatok nem maradhatnak egy adatvédelmi mappában arra várva, hogy a felügyeleti hatóság bekérje őket. Olyan döntési nyilvántartásokká kell válniuk, amelyek összekapcsolják a GDPR 25., 30., 32., 35. és 36. cikkének követelményeit az ISO/IEC 27001:2022 szerinti kockázati bizonyítékokkal, a NIS2 kiberbiztonsági kockázatkezelési intézkedéseivel, a DORA IKT-változáskezelési irányításával, a beszállítói bizonyossággal és az igazgatósági szintű elszámoltathatósággal.
A nehézségekkel küzdő szervezetek jellemzően nem hagyják figyelmen kívül a megfelelést. Külön végzik az adatvédelmi felülvizsgálatot, a biztonsági felülvizsgálatot, a felhőfelülvizsgálatot és a változás-felülvizsgálatot. A sikeres szervezetek egyetlen visszakövethető irányítási munkafolyamatot alakítanak ki, amelyben a DPIA-kiváltó tényezők, a kockázatértékelés, a beszállítói átvilágítás, a kontrollok megfeleltetése, a tesztelés és a maradványkockázat jóváhagyása egyetlen bizonyítékláncot alkot.
Miért vallanak kudarcot az elszigetelt DPIA-k 2026-ban
A GDPR a DPIA-t formális mechanizmusként vezette be az olyan adatkezelések értékelésére, amelyek valószínűsíthetően magas kockázattal járnak az érintettek jogaira és szabadságaira nézve. Sok vállalatnál ez jogi vagy adatvédelmi feladattá vált: egy űrlappá, amelyet akkor töltenek ki, amikor egy projekt érzékenynek tűnik.
Ez a modell már nem védhető.
A személyes adatok kezelését érintő változás ritkán csupán adatvédelmi esemény. Egyben:
- információbiztonsági kockázati esemény az ISO/IEC 27001:2022 szerint;
- kiberbiztonsági irányítási esemény a NIS2 szerint, ha hálózati és információs rendszereket, beszállítókat vagy biztonsági kontrollokat érint;
- IKT-változási és rezilienciaesemény a DORA szerint pénzügyi szervezetek és érintett IKT-szolgáltatók esetében;
- beszállítói és felhőkockázati esemény, ha adatfeldolgozók, al-adatfeldolgozók, API-k, SDK-k vagy hosztolt szolgáltatások érintettek.
Amikor ezek az értékelések külön-külön történnek, a hiányosságok veszélyessé válnak. Az adatvédelmi csapat jóváhagyhat egy DPIA-t anélkül, hogy értené egy biometrikus SDK sérülékenységeit. Az IT-csapat kiadhat egy változást anélkül, hogy felismerné: az különleges kategóriájú adatokat vagy viselkedésalapú megfigyelést érint. A biztonsági csapat felülvizsgálhat egy felhőszolgáltatást anélkül, hogy összekapcsolná azt a DPIA-ban azonosított, jogokat és szabadságokat érintő konkrét kockázatokkal.
A válasz nem a több papírmunka. A válasz az integrált irányítás.
A DPIA-t olyan kiváltó pontként kell kezelni, amely összehangolt kockázati munkafolyamatot indít el az adatvédelem, a biztonság, a felhő, a beszállítók, a fejlesztés, a jogi terület és a vezetés között.
A GDPR-alap: a DPIA-irányítás az adatkezelési tudatossággal kezdődik
A DPIA nem lehet hiteles, ha a szervezet nem tudja megmagyarázni, mit kezel, miért kezeli, ki kapja meg, és mennyi ideig őrzi meg.
A GDPR szerinti elszámoltathatóság többet követel meg egy szándéknyilatkozatnál. Az 5. cikk olyan alapelveket rögzít, mint a jogszerűség, tisztességes eljárás és átláthatóság, célhoz kötöttség, adattakarékosság, pontosság, korlátozott tárolhatóság, integritás és bizalmas jelleg. Azt is előírja, hogy az adatkezelőnek igazolnia kell a megfelelést. A 25. cikk előírja a beépített és alapértelmezett adatvédelmet. A 30. cikk előírja az adatkezelési tevékenységek nyilvántartását. A 32. cikk előírja az adatkezelés biztonságát. A 35. cikk DPIA-t ír elő, ha az adatkezelés valószínűsíthetően magas kockázattal jár. A 36. cikk előzetes konzultációt ír elő, ha megfelelő kockázatcsökkentés nélkül magas kockázat marad fenn.
SaaS-, fintech-, felhő- és menedzselt szolgáltató szervezetek esetében ez azt jelenti, hogy minden lényeges változást adatvédelmi hatás szempontjából elő kell szűrni. A kiváltó tényező nem az, hogy a projektet „adatvédelminek” címkézték-e. A kiváltó tényező az, hogy a változás érint-e személyes adatokat, adatkezelési célt, jogalapot, címzetteket, megőrzést, hozzáférési jogosultságokat, beszállítókat, felhőhelyszíneket vagy maradványkockázatot.
A Clarysec Adatvédelmi és magánszféra-védelmi szabályzat – KKV ezt működési követelménnyé alakítja:
„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.”
Az „Irányítási követelmények” szakasz 5.2.1 szabályzati pontjából.
Ugyanez a KKV-szabályzat beépíti az adatvédelmet a megvalósításba:
„A beépített és alapértelmezett adatvédelmet minden új rendszerben és szolgáltatásban érvényesíteni kell.”
Az „Irányítási követelmények” szakasz 5.3.1 szabályzati pontjából.
Nagyvállalati környezetek esetében a Clarysec Adatvédelmi és magánszféra-védelmi szabályzat egyértelművé teszi a DPIA-kaput:
„A személyes adatokat (PII) érintő rendszerek vagy folyamatok valamennyi jelentős változásához dokumentált adatvédelmi hatásvizsgálatot (DPIA) kell készíteni, amelyet az adatvédelmi tisztviselő (DPO) felülvizsgál.”
Az „Irányítási követelmények” szakasz 5.6 szabályzati pontjából.
Ez a pont képezi a hidat a GDPR szerinti elszámoltathatóság és az operatív kontroll között. A DPIA-t jogi utólagos feladatból projektirányítási és változás-jóváhagyási elemmé emeli.
A DPIA összekapcsolása az ISO/IEC 27001:2022 szerinti kockázati bizonyítékokkal
Az ISO/IEC 27001:2022 biztosítja azt az irányítási rendszerstruktúrát, amelyre a DPIA-irányításnak szüksége van.
A 4.1–4.4 pontok előírják, hogy a szervezet értse meg a környezetét, az érdekelt feleket, a követelményeket, az IBIR alkalmazási területét és az egymással kölcsönhatásban álló folyamatokat. Az adatvédelmi jogszabályok, ügyfélszerződések, NIS2-kötelezettségek, DORA-követelmények, adatfeldolgozói kötelezettségek és beszállítói függőségek mind ebbe a kontextusba tartoznak.
Az 5.1–5.3 pontok vezetői elkötelezettséget, szabályzati összhangot, erőforrásokat, szerepköröket és felelősségeket írnak elő. Sok DPIA itt bukik el. A DPO azonosíthat magas kockázatot, de kockázatgazdák, eszkalációs szabályok és vezetés által támogatott elfogadási kritériumok nélkül a DPIA döntés helyett puszta dokumentummá válik.
A 6.1.1–6.1.3 pontok kockázatalapú tervezést, dokumentált információbiztonsági kockázatértékelési folyamatot, kockázatelfogadási kritériumokat, kockázatgazdákat, kockázatkezelési tervezést, kontrollkiválasztást, alkalmazhatósági nyilatkozatot és a maradványkockázat jóváhagyását írják elő. Ezt a struktúrát kell a DPIA-nak használnia.
A DPIA olyan károkat azonosíthat, mint a profilalkotási kockázat, a jogosulatlan közzététel, a jogellenes másodlagos felhasználás, az identitáscsalás, a diszkrimináció vagy a túlzott megőrzés. Az IBIR ezeket a károkat kockázati forgatókönyvekké, valószínűség- és hatáselemzéssé, kockázatkezelési intézkedésekké, Annex A kontrollokká és maradványkockázat-jóváhagyásokká alakítja.
A Clarysec Kockázatkezelési szabályzat – KKV meghatározza a minimális fegyelmet:
„Minden kockázati bejegyzésnek tartalmaznia kell a leírást, a valószínűséget, a hatást, a pontszámot, a tulajdonost és a kockázatkezelési tervet.”
Az „Irányítási követelmények” szakasz 5.1.2 szabályzati pontjából.
Nagyvállalati környezetek esetében a Clarysec Kockázatkezelési szabályzat összekapcsolja a kockázatkezelési tervezést az ISO/IEC 27001:2022 bizonyítékaival:
„A kockázatkezelési felelősnek biztosítania kell, hogy a kezelések reálisak, időhöz kötöttek és az ISO/IEC 27001 Annex A kontrolljaihoz vannak rendelve.”
A „Szabályzat végrehajtásának követelményei” szakasz 6.4.2 szabályzati pontjából.
A Zenith Blueprint: az auditor 30 lépéses ütemterve Kockázatkezelés fázisának 13. lépése, a Kockázatkezelési tervezés és alkalmazhatósági nyilatkozat, világosan magyarázza az SoA szerepét:
„Az SoA valójában összekötő dokumentum: összekapcsolja a kockázatértékelést/kockázatkezelést a ténylegesen meglévő kontrollokkal.”
Ez az auditra felkészített DPIA-modell. Egy DPIA-megállapítás nem zárulhat annyival, hogy „a kockázat elfogadva”. Kapcsolódnia kell a kockázati nyilvántartáshoz, a kockázatkezelési tervhez, az alkalmazhatósági nyilatkozathoz, a beszállítói felülvizsgálathoz, a felhőalapú átvilágításhoz, a változásjegyhez, a tesztelési bizonyítékokhoz és a vezetői döntéshez.
Egy döntési nyilvántartás, több megfelelőségi kimenet
Az érett DPIA-irányítási munkafolyamat nem duplikál minden jogszabályt. Egyszer gyűjt bizonyítékot, és azt célzottan újrahasznosítja.
| DPIA-irányítási kérdés | Létrehozott bizonyíték | ISO/IEC 27001:2022 bizonyíték | GDPR szerinti elszámoltathatósági érték | NIS2- vagy DORA-érték |
|---|---|---|---|---|
| Milyen adatkezelés változik? | Az adatkezelési nyilvántartás frissítése és DPIA-befogadás | Alkalmazási területre, kontextusra, vagyonelemekre és folyamatokra vonatkozó bizonyíték | Támogatja az adatkezelési nyilvántartásokat és a beépített adatvédelmet | Igazolja az operatív kockázattudatosságot |
| Mi okozhat kárt az érintetteknek? | Adatvédelmi kockázati forgatókönyv és hatásvizsgálat | Kockázatértékelési eredmény és kockázatgazda | Támogatja a DPIA indokolását és az elszámoltathatóságot | Összhangban van a kockázatalapú kiberbiztonsági irányítással |
| Mely kontrollok csökkentik a kockázatot? | Védelmi intézkedések, TOM-ok és kockázatkezelési terv | SoA, kockázatkezelési terv és Annex A bevezetési állapot | Támogatja az adatkezelés biztonságát és az alapértelmezett adatvédelmet | Támogatja a kiberbiztonsági és IKT-kockázati intézkedéseket |
| Ki más kezeli az adatokat vagy fér hozzájuk? | Beszállítói, adatfeldolgozói és felhőfelülvizsgálat | Beszállítói és felhőkontroll-bizonyíték | Támogatja az adatfeldolgozói felügyeletet és az adattovábbítások irányítását | Támogatja az ellátási lánccal és harmadik fél által nyújtott IKT-szolgáltatásokkal kapcsolatos kockázatkezelést |
| Mi változott az éles környezetben? | Változásnyilvántartás, tesztelési bizonyítékok és jóváhagyás | Változáskezelési és operatív kontrollbizonyíték | Igazolja, hogy a kontrollokat a kiadás előtt figyelembe vették | Támogatja a változáskockázati és rezilienciaelvárásokat |
| Ki fogadta el a maradványkockázatot? | DPO, kockázatgazda és vezetői jóváhagyás | Maradványkockázat-elfogadás és vezetőségi átvizsgálási input | Igazolja az elszámoltatható döntéshozatalt | Támogatja az igazgatósági vagy vezető testületi felügyeletet |
Ez a bizonyítéklánc közvetlenül illeszkedik az ISO/IEC 27001:2022 8.1 pontjához, amely tervezett és szabályozott működési folyamatokat, dokumentált bizonyítékokat, a tervezett változtatások kontrollját és a nem szándékolt változtatások felülvizsgálatát írja elő. A 8.2 pont kockázatértékeléseket ír elő tervezett időközönként vagy jelentős változások javaslata, illetve bekövetkezése esetén. A 8.3 pont előírja a kockázatkezelési terv végrehajtását. A 9. pont ezt követően a bizonyítékokat monitorozás, mérés, belső audit és vezetőségi átvizsgálás útján bizonyossággá alakítja.
Az Adatvédelmi és magánszféra-védelmi szabályzat – KKV egyértelművé teszi az időzítést:
„Az adatvédelmi koordinátornak évente és jelentős rendszerváltozások során értékelnie kell az adatvédelmi kockázatokat.”
A „Kockázatkezelés és kivételek” szakasz 7.1.1 szabályzati pontjából.
Ha egy jelentős személyesadat-változás nem vált ki DPIA-előszűrést és IBIR-újraértékelést, az irányítási folyamat hiányos.
NIS2: a DPIA-irányítás vezetői elszámoltathatósággá válik
A NIS2 növeli az irányítási nyomást az alapvető és fontos ágazatokban működő szervezeteken. Számos, felsorolt ágazatban működő köz- és magánszervezetre alkalmazandó, ha azok megfelelnek a releváns méretküszöböknek, és bizonyos esetekben mérettől függetlenül is alkalmazható, például bizalmi szolgáltatások, DNS, TLD-nyilvántartók, nyilvános elektronikus hírközlési szolgáltatások, egyedüli alapvetőszolgáltatás-nyújtók vagy rendszerszintű kockázati szereppel rendelkező szervezetek esetében.
A DPIA-irányítás szempontjából a kulcspont nem csupán az alkalmazási kör. Hanem a vezetői felelősség.
A NIS2 20. cikke előírja, hogy az alapvető és fontos szervezetek vezető testületei hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék azok végrehajtását és vegyenek részt képzésben. A 21. cikk megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő a kockázati kitettség, a méret, a valószínűség, a súlyosság, a társadalmi és gazdasági hatás, a technika állása és a releváns szabványok alapján.
A 21(2) cikk olyan területeket tartalmaz, amelyek gyakran átfednek a DPIA-kimenetekkel, többek között:
- kockázatelemzés és információsrendszer-biztonsági szabályzatok;
- incidenskezelés;
- üzletmenet-folytonosság és válságkezelés;
- ellátásilánc-biztonság;
- biztonság a hálózati és információs rendszerek beszerzésében, fejlesztésében és karbantartásában;
- sérülékenységkezelés és sérülékenység-feltárás;
- a kiberbiztonsági kockázatkezelési intézkedések hatékonyságának értékelésére szolgáló szabályzatok;
- kiberhigiénia és képzés;
- kriptográfia és titkosítás;
- HR-biztonság, hozzáférés-szabályozás és eszközkezelés;
- többtényezős hitelesítés, folyamatos hitelesítés, biztonságos kommunikáció és biztonságos vészhelyzeti kommunikáció.
Egy új biometrikus, viselkedéselemzési vagy felhőalapú adatkezelési tevékenységre vonatkozó DPIA-nak ezért NIS2-releváns kérdéseket is fel kell tennie. Függ-e az adatkezelés új beszállítótól? Bevezet-e új API-t, SDK-t, identitásfolyamatot vagy hozzáférési modellt? Megváltoztatja-e az incidens hatását? Szükségessé tesz-e titkosítást, erősebb naplózást, biztonságos fejlesztési ellenőrzéseket vagy vezetői jóváhagyást?
A gyakorlati vezetői kérdés egyszerűvé válik: tudja-e a szervezet igazolni, hogy egy adatvédelmi hatással járó változást a bevezetés előtt a kiberbiztonsági kockázatkezelés részeként értékelt?
Ennek a bizonyítéknak láthatónak kell lennie a DPIA-befogadásban, a frissített adatkezelési nyilvántartásban, a kockázati nyilvántartásban, a kockázatkezelési tervben, az alkalmazhatósági nyilatkozatban, a beszállítói átvilágításban, a biztonsági tesztelési bizonyítékokban, a változás-jóváhagyásban és a maradványkockázat elfogadásában.
DORA: az IKT-változás és a harmadik félre vonatkozó bizonyítékok elkerülhetetlenek
A DORA 2025. január 17-től alkalmazandó, és egységes uniós keretrendszert hoz létre az IKT-kockázatkezelésre, a jelentős IKT-vonatkozású incidensek bejelentésére, a digitális operatív reziliencia tesztelésére, a kiberfenyegetésekkel és sérülékenységekkel kapcsolatos információmegosztásra, a harmadik fél által nyújtott IKT-szolgáltatások kockázatkezelésére és a kritikus harmadik fél IKT-szolgáltatók felügyeletére.
Pénzügyi szervezetek esetében a DORA általában ágazatspecifikus uniós jogi aktusként működik az IKT-kockázatkezelési és incidensbejelentési kötelezettségek tekintetében, miközben a NIS2 továbbra is releváns a szélesebb ökoszisztéma-koordináció és a DORA hatálya alá nem tartozó szervezetek számára.
A DPIA-irányítás azért fontos a DORA alapján, mert a személyes adatok kezelése jellemzően IKT-rendszerekben, harmadik fél által nyújtott szolgáltatásokban, felhőkörnyezetekben és működési munkafolyamatokban történik.
A DORA 5. cikke belső irányítási és kontrollkeretrendszereket ír elő az IKT-kockázatkezeléshez, vezető testületi felelősséggel. A 6. cikk dokumentált, az általános kockázatkezelésbe integrált IKT-kockázatkezelési keretrendszert ír elő. A 8–14. cikkek a vagyonelemek és függőségek azonosítását, a védelmet és megelőzést, az észlelést, a folytonosságot, a biztonsági mentést, a helyreállítást, a tanulságok levonását és a válságkommunikációt fedik le.
A DORA 28. cikke előírja, hogy a pénzügyi szervezetek a harmadik fél által nyújtott IKT-szolgáltatások kockázatát az IKT-kockázatkezelés szerves részeként kezeljék, és IKT-szolgáltatások igénybevétele esetén is felelősek maradjanak. Előírja az IKT-szolgáltatási szerződések nyilvántartását, a szerződéskötés előtti értékeléseket, a kellő gondosságot, a koncentrációs kockázat értékelését, az audit- és vizsgálati tervezést, a felmondási jogokat és a kilépési stratégiákat. A 30. cikk írásbeli szerződéseket ír elő egyértelmű szolgáltatásleírásokkal, adat-helyszínekkel, bizalmassági, sértetlenségi és rendelkezésre állási védelmi intézkedésekkel, az adatok helyreállításával és visszaadásával, incidensekben nyújtott segítséggel, hatósági együttműködéssel, felmondási jogokkal, valamint a kritikus vagy fontos funkciókra vonatkozó további védelmi intézkedésekkel.
A DPIA szempontjából ez megváltoztatja a beszállítói kérdést. A „van-e DPA-nk?” nem elég. A jobb kérdés: tudjuk-e igazolni, hogy az IKT-függőséget, az adattárolás földrajzi helyét, az alvállalkozásba adást, a biztonsági szabványokat, a rezilienciát, az auditálási jogokat, az incidens-támogatást és a kilépési stratégiát az adatkezelés jóváhagyása előtt értékeltük?
A Clarysec Felhőszolgáltatások használatára vonatkozó szabályzat ezt az aktiválás előtti kontrollt egyértelművé teszi:
„Minden felhőhasználatot az aktiválás előtt kockázatalapú kellő gondossági vizsgálatnak kell alávetni, beleértve a szolgáltató értékelését, a jogi megfelelőség ellenőrzését és a kontrollok ellenőrzésére irányuló felülvizsgálatokat.”
Az „Irányítási követelmények” szakasz 5.2 szabályzati pontjából.
A DPIA nem hagyhat jóvá új analitikai adatfeldolgozót, identitásszolgáltatót, biometrikus SDK-t vagy felhőalapú telemetriai platformot, amíg a felhőalapú átvilágítás, a jogi ellenőrzés és a kontrollok ellenőrzése nem fejeződött be, vagy amíg ezeket kifejezett kockázatkezelési intézkedésként nem követik nyomon.
Az ISO/IEC 27002:2022 horgonyai: adatvédelem, projektek és változás
A Clarysec Zenith Controls: a keresztmegfelelési útmutató az ISO/IEC 27002:2022 kontrollokat keresztmegfelelési horgonyként kezeli. A DPIA-irányítás szempontjából három kontroll különösen fontos.
| ISO/IEC 27002:2022 kontroll | Miért fontos a DPIA-irányítás szempontjából | Keresztmegfelelési érték |
|---|---|---|
| 5.34 A PII adatvédelme és védelme | Tudatosságot és védelmet követel meg a személyes adatok teljes életciklusa során | Támogatja a GDPR szerinti elszámoltathatóságot, az ISO/IEC 27001:2022 Annex A-t, a NIS2 kockázati intézkedéseket és a DORA adatvédelmi elvárásait |
| 5.8 Információbiztonság a projektmenedzsmentben | Beépíti a biztonsági és adatvédelmi hatás szerinti gondolkodást a projekttervezésbe | Támogatja a beépített adatvédelmet, a biztonságos fejlesztést, valamint a NIS2 beszerzési és fejlesztési intézkedéseit |
| 8.32 Változáskezelés | Biztosítja, hogy a változtatásokat értékeljék, engedélyezzék, teszteljék, bevezessék és felülvizsgálják | Támogatja az ISO szerinti operatív kontrollt, a DORA IKT-változáskezelési irányítását és az audit-visszakövethetőséget |
A Zenith Controls 5.34, A PII adatvédelme és védelme kontrollhoz tartozó bejegyzése megelőző kontrollként osztályozza azt, a bizalmassággal, sértetlenséggel és rendelkezésre állással hozza kapcsolatba, az Identify és Protect kiberbiztonsági fogalmakhoz igazítja, és az információvédelemhez, valamint a jogi és megfelelési képességekhez köti.
A Zenith Blueprint Kontrollok a gyakorlatban fázisának 23. lépése gyakorlati szempontból fogalmaz:
„Ennek a kontrollnak az alapja az adattudatosság. A szervezetnek tudnia kell, milyen PII-t gyűjt, hol található, miért kezelik, és ki férhet hozzá.”
A Zenith Controls 5.8, Információbiztonság a projektmenedzsmentben kontrollhoz tartozó bejegyzése megelőző kontrollként osztályozza azt, a bizalmassággal, sértetlenséggel és rendelkezésre állással hozza kapcsolatba, az Identify és Protect fogalmakhoz igazítja, és az irányítási, ökoszisztéma- és védelmi területeken helyezi el.
A Zenith Blueprint Kontrollok a gyakorlatban fázisának 22. lépése így fogalmaz:
„Ennek a kontrollnak nem az a célja, hogy bürokráciával terhelje a projekteket. A cél az, hogy a biztonságot tervezési bemenetként, ne tesztelési fázisként kezeljék.”
Az adatvédelmet ugyanígy kell kezelni. Az éles indulás utáni DPIA gyakran kárjelentés. A tervezés során végzett DPIA kockázatmegelőzés.
A Zenith Controls 8.32, Változáskezelés kontrollhoz tartozó bejegyzése megelőző kontrollként osztályozza azt, a bizalmassággal, sértetlenséggel és rendelkezésre állással hozza kapcsolatba, a Protect fogalomhoz igazítja, és az alkalmazásbiztonsági, valamint rendszer- és hálózatbiztonsági képességekhez köti.
A Zenith Blueprint Kontrollok a gyakorlatban fázisának 21. lépése egyértelmű:
„A változás elkerülhetetlen, de a kiberbiztonságban a kontrollálatlan változás veszélyes.”
A Clarysec Változáskezelési szabályzat – KKV rögzíti a kiváltó tényezőt:
„Ha egy változás érzékeny adatokat, rendszer-hozzáférési jogosultságokat vagy külső integrációkat érint, biztonsági hatásvizsgálat szükséges. A kijelölt biztonsági vagy megfelelési kapcsolattartónak értékelnie kell, hogy a változás további kockázatokat vezet-e be, és javasolnia kell a további védelmi intézkedéseket.”
A „Kockázatkezelés és kivételek” szakasz 7.5.1 szabályzati pontjából.
Nagyvállalati környezetek esetében a Clarysec Változáskezelési szabályzat meghatározza a Változáskezelési Tanácsadó Testület elvárását:
„A változásokat a Változáskezelési Tanácsadó Testület jóváhagyása előtt biztonsági és megfelelési kockázatok szempontjából értékelni kell.”
A „Szerepkörök és felelősségek” szakasz 4.6.1 szabályzati pontjából.
Gyakorlati példa: biometrikus analitikai funkció jóváhagyása
Máriának nincs szüksége három külön irányítási projektre. Egy integrált projektbefogadási és kockázati munkafolyamatra van szüksége.
A termékcsapat biometrikus fizetési hitelesítést javasol viselkedéselemzéssel. A funkció biometrikus sablonokat, eszközmetaadatokat, fiókattribútumokat, IP-címeket, hitelesítési eseményeket és csalásjelzéseket gyűjt. Felhőalapú analitikai szolgáltatót és harmadik féltől származó biometrikus SDK-t használ. Az ügyfélsiker-csapatok összesített irányítópult-hozzáférést kapnak.
A változásjegynek a ráfordítások allokálása vagy a Változáskezelési Tanácsadó Testület jóváhagyása előtt DPIA-előszűrést és kockázatértékelést kell kiváltania.
| Befogadási mező | Példaválasz |
|---|---|
| Érintett személyes adatok | Biometrikus sablon, felhasználói azonosító, IP-cím, eszközmetaadatok, fiókszerepkör, hitelesítési események |
| Adatkezelési cél | Fizetési hitelesítés, csalásfelderítés és ügyfélsiker-analitika |
| Megerősítendő jogalap | Szerződés teljesítéséhez szükséges adatkezelés, jogos érdek vagy kifejezett hozzájárulás, a DPO felülvizsgálatának függvényében |
| Új beszállító vagy felhőszolgáltatás | Biometrikus SDK-szolgáltató és EU-régiós felhőalapú analitikai adatfeldolgozó |
| Érzékeny vagy különleges kategóriájú adatok | A biometrikus adatok magas kockázatú felülvizsgálatot igényelnek, ha egyedi azonosításra használják őket |
| Hozzáférési modell változása | Az ügyfélsiker-csapat összesített irányítópult-hozzáférést kap |
| Megőrzési változás | Az eseménynaplókat 180 napig őrzik meg, a biometrikus sablonokat a szolgáltatási feltételek szerint |
| DPIA szükséges | Igen, a biometrikus adatkezelés, a megfigyelés és az új beszállítói függőség felülvizsgálatot igényel |
Az integrált értékelésnek ezután egyetlen kockázati dossziét kell létrehoznia.
| Értékelési szakasz | Elsődleges keretrendszer | Megválaszolandó kérdések | Bizonyíték vagy kimenet |
|---|---|---|---|
| Adatkezelés leírása | GDPR 35. cikk | Milyen adatot kezelnek, miért, ki által és mennyi ideig? | Adatáramlás, RoPA-frissítés, DPIA-befogadás |
| Szükségesség és arányosság | GDPR 35. cikk | Szükséges-e az adatkezelés, és ez-e a legkevésbé beavatkozó életképes megközelítés? | DPO-felülvizsgálat és indokolás |
| Az érintetteket fenyegető kockázat | GDPR 35. cikk | Érheti-e az érintetteket személyazonosság-lopás, diszkrimináció, profilalkotás, kizárás vagy pénzügyi kár? | DPIA-kockázatelemzés és ISO kockázati nyilvántartási bejegyzés |
| Biztonsági kockázatértékelés | ISO/IEC 27001:2022 6.1.2 pont | Milyen bizalmassági, sértetlenségi és rendelkezésre állási fenyegetések állnak fenn? | Kockázati nyilvántartási bejegyzések valószínűséggel, hatással, tulajdonossal és kezeléssel |
| NIS2 hatáselemzés | NIS2 21. cikk | Érinti-e a változás a beszállítókat, a biztonságos fejlesztést, a hozzáférés-szabályozást, az incidenskezelést vagy a folytonosságot? | Beszállítóértékelés, biztonságos fejlesztési ellenőrzőlista, vezetői bizonyíték |
| DORA rezilienciaelemzés | DORA 8., 9., 24. és 30. cikk | Olyan IKT-változásról van-e szó, amely rezilienciát, tesztelést vagy szerződéses kötelezettségeket érint? | Változásnyilvántartás, tesztterv, szerződés-felülvizsgálat és kilépési bizonyíték |
| Kockázatkezelés és kontrollok | ISO/IEC 27001:2022 6.1.3 pont | Mely TOM-ok és Annex A kontrollok csökkentik a kockázatot? | Kockázatkezelési terv és frissített alkalmazhatósági nyilatkozat |
A kockázati bejegyzések például így nézhetnek ki:
| Kockázati forgatókönyv | Valószínűség | Hatás | Kezelési példák | Kontrollmegfeleltetés |
|---|---|---|---|---|
| A meghatározott célon túlmutató túlzott adatgyűjtés | Közepes | Magas | Adattakarékossági felülvizsgálat, eseményséma jóváhagyása, megőrzési korlát | 5.34, 5.31, 8.10 |
| Jogosulatlan hozzáférés biometrikus vagy viselkedési irányítópulthoz | Közepes | Magas | Szerepköralapú hozzáférés, többtényezős hitelesítés, naplózás, negyedéves hozzáférési felülvizsgálat | 5.15, 5.18, 8.15, 8.16 |
| Felhőalapú adatfeldolgozó hibás konfigurációja telemetriai adatokat tesz hozzáférhetővé | Alacsony | Magas | Felhőalapú átvilágítás, titkosítás, konfigurációs alapbeállítás, monitorozás | 5.23, 8.9, 8.24, 8.16 |
| Biometrikus SDK sérülékenysége kompromittálja a hitelesítési adatokat | Közepes | Magas | Beszállítói átvilágítás, biztonságos fejlesztési felülvizsgálat, biztonsági tesztelés | 5.21, 8.25, 8.28, 8.29 |
| A profilalkotás méltánytalan ügyfélhatást okoz | Közepes | Magas | DPO-felülvizsgálat, átláthatósági szöveg, tiltakozáskezelés, ahol alkalmazandó | 5.34, 5.8 |
A kiadás előtt a változásnyilvántartásnak tartalmaznia kell a DPIA lezárását vagy a DPO által jóváhagyott kockázatkezelési tervet, a frissített adatkezelési nyilvántartást, a beszállítói és felhőalapú átvilágítást, a biztonsági hatásvizsgálatot, a teszteredményeket, a visszaállítási tervet, a monitorozási tervet és a maradványkockázat jóváhagyását.
A kiadás után a tulajdonosnak ellenőriznie kell a naplókat, riasztásokat, hozzáférési szerepköröket, irányítópultokat, megőrzési szabályokat és törlési munkafolyamatokat. Ez lezárja az ISO/IEC 27001:2022 8.1 pontja szerinti tervezett változási ciklust, és támogatja a DORA-típusú operatív rezilienciafegyelmet.
Mit fognak kérdezni az auditorok
Az egységes DPIA különböző auditorok számára egyetlen koherens bizonyítéknyomot ad.
| Auditori nézőpont | Várható auditfókusz | Meglévő bizonyíték |
|---|---|---|
| ISO/IEC 27001:2022 auditor | Kiváltottak-e a jelentős változások kockázatértékelést, kockázatkezelést, SoA-frissítést és operatív kontrollt | DPIA-befogadás, kockázati nyilvántartás, kockázatkezelési terv, SoA-megjegyzések, változásnyilvántartás, belső auditnyom |
| GDPR adatvédelmi felülvizsgáló | Értékelték-e a magas kockázatú adatkezelést a bevezetés előtt, és dokumentálták-e a védelmi intézkedéseket | DPIA, adatkezelési nyilvántartás, jogalapelemzés, DPO-felülvizsgálat, átláthatósági és megőrzési bizonyíték |
| NIS2-orientált auditor | Lefedik-e a vezetés által jóváhagyott kockázati intézkedések a biztonsági szabályzatokat, az ellátási láncot, az incidenskezelést, a folytonosságot, a hozzáférést, a titkosítást és a sérülékenységkezelést | Igazgatósági vagy vezetőségi átvizsgálási bejegyzések, kontrollmegfeleltetés, beszállítói felülvizsgálat, incidens- és folytonossági kapcsolódások |
| DORA-orientált auditor | Integrálódnak-e az IKT-változásra, harmadik fél függőségre, rezilienciára, tesztelésre és szerződésre vonatkozó bizonyítékok az IKT-kockázatirányításba | IKT-kockázatértékelés, szolgáltatói nyilvántartás, szerződéses kikötések, tesztelési bizonyítékok, kilépési terv, incidens-támogatási bizonyíték |
| NIST CSF értékelő | Összekapcsolódnak-e az irányítási, kockázati, vagyonelem-, beszállítói, védelmi, észlelési, reagálási és helyreállítási kimenetek | Jelenlegi és célprofil, hiányossági terv, eszköznyilvántartás, beszállítói kockázati nyilvántartások, monitorozási és reagálási bizonyíték |
| COBIT 2019 vagy ISACA auditor | Kontrolláltak-e a változásengedélyezési, kockázatkezelési, biztonsági szolgáltatási és bizonyossági gyakorlatok | Változáskezelési Tanácsadó Testületi bejegyzések, hatáselemzés, jóváhagyások, tesztelés, feladatkörök szétválasztása, változás utáni felülvizsgálat |
A NIST CSF 2.0 kommunikációs rétegként hasznos, mert GOVERN funkciója a stratégiát, elvárásokat, szabályzatot, szerepköröket, felügyeletet és ellátásilánc-kockázatkezelést helyezi középpontba. A COBIT 2019 folyamatbizonyosságot ad hozzá, különösen a strukturált változásengedélyezés, hatáselemzés, jóváhagyások, tesztelés és változás utáni értékelés körül.
Egy GDPR felügyeleti hatóság az érintetti jogokkal és szabadságokkal kezdhet. Egy ISO-auditor a dokumentált kockázatértékeléssel és a kontrollok bevezetésével. Egy DORA-felülvizsgáló az IKT-függőséggel és rezilienciával. Egy NIS2-felülvizsgáló a vezetői felügyelettel és az arányos kiberbiztonsági intézkedésekkel.
Ugyanennek a DPIA-bizonyítékláncnak mindegyiküket ki kell szolgálnia.
A DPIA-döntéseknek incidensek során is meg kell állniuk
A DPIA nem csak kiadás előtti jóváhagyási artefaktum. Javítania kell az adatsértésre és incidensekre való felkészültséget is.
A GDPR a személyesadat-sértést olyan biztonsági incidensként határozza meg, amely a személyes adatok véletlen vagy jogellenes megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közzétételét vagy az azokhoz való hozzáférést okozza. A NIS2 indokolatlan késedelem nélküli bejelentést ír elő jelentős incidensek esetén, beleértve a 24 órán belüli korai figyelmeztetést, a 72 órán belüli bejelentést és az incidensbejelentést követő legkésőbb egy hónapon belüli zárójelentést. A DORA előírja a pénzügyi szervezetek számára a jelentős IKT-vonatkozású incidensek észlelését, kezelését, naplózását, osztályozását, eszkalációját és bejelentését kezdeti, közbenső és záró jelentés útján, valamint az ügyfelek értesítését, ha pénzügyi érdekeik érintettek.
Ha a DPIA rögzítette az adatáramlásokat, adatfeldolgozókat, hozzáférés-szabályozási kontrollokat, megőrzést, naplózást, titkosítást, álnevesítést és incidensfelelősségeket, az incidenskezelő csapat gyorsabban tud válaszolni a kritikus kérdésekre. Milyen személyes adatok voltak érintettek? Mely rendszerek és beszállítók érintettek? Mely érintettekre vagy ügyfelekre lehet hatás? Volt-e titkosítás? Mely naplók állnak rendelkezésre? Mely jelentéstételi határidők alkalmazandók? Milyen ügyfél- vagy hatósági kommunikáció szükséges?
Ezért a DPIA-irányítást össze kell kapcsolni az ISO/IEC 27001:2022 incidenskezelési kontrolljaival, üzletmenet-folytonossági kontrolljaival és IKT-felkészültségi kontrolljaival, valamint a NIS2 és DORA incidenséletciklus-elvárásaival.
Gyakori DPIA-irányítási hibák
A hibákat általában az elszakított munkafolyamatok okozzák, nem az erőfeszítés hiánya.
| Hiba | Miért teremt kockázatot | Jobb gyakorlat |
|---|---|---|
| Az adatkezelési nyilvántartást az éles indulás után frissítik | A nyilvántartás tervezési kontroll helyett történeti leltárrá válik | A RoPA frissítése jóváhagyás előtt |
| Hiányzik a DPIA-előszűrés a változásbefogadásból | Az adatvédelmi kockázat túl későn derül ki | Kötelező személyesadat-, beszállítói, hozzáférési és megőrzési kérdések hozzáadása |
| A DPIA-kockázatok adatvédelmi mappában maradnak | A biztonsági kockázatkezelés és a maradványkockázat jóváhagyása nem visszakövethető | A DPIA-megállapítások átalakítása IBIR kockázati nyilvántartási bejegyzésekké |
| A beszállítói felülvizsgálatok csak kérdőívekre fókuszálnak | Kimaradhat az adatkezelési cél, az adattárolás földrajzi helye, az al-adatfeldolgozók, az auditálási jogok és a kilépés | Biztonsági, adatvédelmi, jogi és rezilienciaalapú átvilágítás kombinálása |
| Az SoA-ból hiányzik az adatvédelmi és felhőalapú indokolás | Az auditorok látják a kontrollokat, de nem látják a kockázati logikát | Kontrollok megfeleltetése DPIA-megállapításokhoz, GDPR-, NIS2- és DORA-kötelezettségekhez |
| A maradványkockázatot informálisan fogadják el | A vezetői elszámoltathatóság nem igazolható | DPO-, kockázatgazdai és vezetői jóváhagyás rögzítése feltételekkel |
A DPIA-irányítási ellenőrzőlista
Használja ezt az ellenőrzőlistát a DPIA-k IBIR-be, NIS2-felkészültségbe és DORA szerinti IKT-változáskezelési irányításba történő integrálásához.
| Irányítási tevékenység | Tulajdonos | Minimális bizonyíték |
|---|---|---|
| DPIA-előszűrés beépítve a projekt- és változásbefogadásba | Változásmenedzser és DPO | Befogadási űrlap, kiváltó döntés és indokolás |
| Adatkezelési nyilvántartás frissítése jóváhagyás előtt | Adatvédelmi koordinátor vagy DPO | Cél, jogalap, adatkategóriák, megőrzés és címzettek |
| Adatvédelmi kockázatok átalakítása IBIR-kockázatokká | Kockázatkezelési felelős és rendszergazda | Kockázati bejegyzések valószínűséggel, hatással, tulajdonossal és kockázatkezelési tervvel |
| Kontrollok megfeleltetése az SoA-hoz | IBIR-vezető | Alkalmazandó Annex A kontrollok, indokolás és bevezetési állapot |
| Beszállítói és felhőalapú átvilágítás elvégzése | Beszerzés, biztonság és jogi terület | Szolgáltató értékelése, szerződéses kikötések, adat-helyszín és kilépési bizonyíték |
| Biztonsági és adatvédelmi tesztelés elvégzése | Fejlesztés és biztonság | Teszteredmények, hozzáférési felülvizsgálat, naplózás ellenőrzése és sérülékenységi bizonyíték |
| Maradványkockázat elfogadása | Kockázatgazda, DPO és szükség szerint vezetés | Jóváhagyási bejegyzés, feltételek és felülvizsgálati dátum |
| Változás utáni felülvizsgálat elvégzése | Változásgazda és szolgáltatásgazda | Felülvizsgálati megjegyzések, incidensek, mutatók és helyesbítő intézkedések |
Ez nem bürokrácia. Ez operatív elszámoltathatóság. Segít a CISO-nak igazolni, hogy a biztonságot figyelembe vették, a DPO-nak igazolni, hogy az adatvédelmi kockázatot értékelték, a megfelelőségi vezetőnek igazolni, hogy a kontrollok több keretrendszerhez is megfeleltethetők, az üzleti tulajdonosnak pedig igazolni, hogy az innovációt felelősen irányították.
Hogyan segít a Clarysec
A Clarysec megközelítését olyan szervezetek számára alakították ki, amelyek egymást átfedő 2026-os kötelezettségekkel és töredezett bizonyítékokkal szembesülnek.
A szabályzati eszköztár megadja az irányítási nyelvezetet. Az Adatvédelmi és magánszféra-védelmi szabályzat meghatározza, mikor szükséges DPIA, és ki vizsgálja felül. A Kockázatkezelési szabályzat meghatározza, hogyan kell strukturálni és megfeleltetni a kockázati bejegyzéseket. A Változáskezelési szabályzat biztosítja, hogy az adatvédelmi és biztonsági hatásokat jóváhagyás előtt értékeljék. A Felhőszolgáltatások használatára vonatkozó szabályzat felhőaktiválás előtt kellő gondossági vizsgálatot ír elő.
A Zenith Blueprint adja a bevezetési ütemtervet. A 13. lépés a kockázatkezelést és az alkalmazhatósági nyilatkozatot keresztmegfelelési híddá alakítja. A 22. lépés beépíti a biztonságot a projektmenedzsmentbe. A 21. lépés a változást szándékossá, indokolttá és auditálhatóvá teszi. A 23. lépés a PII-védelmet adattudatosságon, jogszerű használaton, hozzáférés-korlátozáson, beszállítói felügyeleten és operatív adatvédelmi folyamatokon alapuló életcikluskontrollá alakítja.
A Zenith Controls útmutató adja a keresztmegfelelési iránytűt. A DPIA-irányítás szempontjából az ISO/IEC 27002:2022 5.34, 5.8 és 8.32 kontrolljai összekapcsolják az adatvédelmet, a projektirányítást és a változáskontrollt a GDPR szerinti elszámoltathatósággal, a NIS2 kiberbiztonsági intézkedéseivel, a DORA IKT-kockázatirányításával, a NIST CSF kimeneteivel és a COBIT 2019 bizonyossággal.
Ha szervezete GDPR szerinti elszámoltathatósági felülvizsgálatokra, ISO/IEC 27001:2022 tanúsításra, NIS2-felkészültségre vagy DORA szerinti operatív rezilienciára készül, kezdje azzal, hogy a DPIA-kiváltó tényezőket beépíti a projekt- és változásbefogadásba. Kapcsolja a DPIA-megállapításokat a kockázati nyilvántartáshoz. Térképezze fel a kezeléseket az SoA-ban. Aktiválás előtt ellenőrizze a beszállítókat és a felhőszolgáltatásokat. Őrizzen meg egyetlen döntési nyilvántartást, amelyet a vezetés, az auditorok és a felügyeleti hatóságok követni tudnak.
A legjobb DPIA nem az, amelyet azután írnak meg, hogy a felügyeleti hatóság bekérte. Hanem az, amely formálta a rendszert, mielőtt az ügyfelek, auditorok vagy incidensek próbára tették volna.
Vizsgálja felül jelenlegi DPIA-folyamatát a Clarysec szabályzati eszköztárához képest, használja a Zenith Blueprint útmutatót auditra alkalmas visszakövethetőség kialakításához, és használja a Zenith Controls útmutatót egyetlen kontrollkeretrendszer GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF és COBIT 2019 szerinti megfeleltetéséhez. Így a következő adatvédelmi hatással járó változást az utolsó pillanatos megfelelési kapkodás helyett irányított, bizonyítékokkal alátámasztott kiadási döntéssé alakíthatja.
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
