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.
Legyen PECB ISO/IEC 27001 Lead Implementer vagy Lead Auditor
- ✓ Hivatalos PECB tananyag és két vizsgalehetőség
- ✓ Tanúsítási díj és az első évi fenntartási díj (AMF) benne, ahol alkalmazandó
- ✓ Önálló tanulás vagy élő online képzés · a kurzus 1 munkanapon belül hozzárendelve
Frequently Asked Questions
A szerzőről
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
