Adatvédelmi kockázatértékelés ISO 27701 és GDPR alapján

A hétfő reggeli értekezlet ismerős helyzet volt Maria számára, aki egy gyorsan növekvő egészségügyi technológiai vállalat információbiztonsági vezetője (CISO) volt.

A vezérigazgató egy egyszerű irányítópultot kért, amely megmutatja a GDPR szerinti kockázati kitettséget, mielőtt a vállalat elindítja MI-alapú beteganalitikai platformját. Az új adatvédelmi vezetőnek, Davidnek, volt egy 50 munkalapból álló adatkezelési tevékenységek nyilvántartása, vagyis RoPA-ja. A mérnöki csapat biztonságossá tette a felhőkörnyezetet. A termék készen állt a kiadásra. A beszállító a további adatfeldolgozói környezetét „vállalati szintűként” jellemezte.

Egy kérdés azonban megakasztotta a megbeszélést.

„Mi a tényleges kockázatunk, és tudjuk-e igazolni a nagyvállalati ügyfelek felé, hogy kontroll alatt tartjuk?”

A RoPA megmutatta, mit kezel a vállalat. A biztonsági kockázati nyilvántartás az infrastruktúra-kockázatokat tartalmazta. Néhány DPIA külön dokumentumban szerepelt. A beszállítói felülvizsgálatok beszerzési mappákban voltak. Senki sem tudott bemutatni egyetlen visszakövethető döntési láncot az adatkezelési tevékenységtől az adatvédelmi kockázaton, a DPIA-döntésen, a kockázatkezelési terven, a kontrollmegfeleltetésen és a maradványkockázat jóváhagyásán át a felülvizsgálati dátumig.

Ez az a hiányosság, amellyel sok szervezet szembesül, amikor az ISO/IEC 27701:2025 és a GDPR szerinti elszámoltathatóság felé halad. Vannak adatvédelmi tájékoztatóik, beszállítói kérdőíveik, RoPA-bejegyzéseik, adatáramlási térképeik, DPIA-sablonjaik és ISO/IEC 27001:2022 kontrolljaik. Ami gyakran hiányzik, az a működési réteg, amely ezeket összekapcsolja.

Egy érett adatvédelmi információirányítási rendszer, vagyis PIMS, az adatvédelmi kockázatértékelést nem jogi mellékletként kezeli. Ismételhető döntési munkafolyamatként működteti: az adatkezelés azonosítása, kockázati előszűrés, döntés arról, hogy szükséges-e DPIA, kontrollok kiválasztása, felelősök kijelölése, maradványkockázat jóváhagyása, kiváltó események nyomon követése és bizonyítékok megőrzése.

Ebben segítenek a Clarysec szabályzatcsomagjai, a Zenith Blueprint és a Zenith Controls: a csapatok elszigetelt táblázatok helyett igazolható adatvédelmi kockázatkezelési rendszert alakíthatnak ki.

Az adatvédelmi kockázatértékelés a hiányzó működési réteg

A GDPR szerinti elszámoltathatóságot gyakran arra egyszerűsítik le, hogy „legyen dokumentáció”. A dokumentáció fontos, de az Article 5(2) ennél tovább megy. Az adatkezelő felelős az Article 5(1) szerinti elveknek való megfelelésért, és képesnek kell lennie annak igazolására, beleértve a jogszerűséget, a tisztességességet, az átláthatóságot, a célhoz kötöttséget, az adattakarékosságot, a pontosságot, a tárolási korlátozást, az integritást és a bizalmas jelleget.

Ehhez nem elegendő egy RoPA. A szervezetnek meg kell tudnia indokolni, miért elfogadható egy adatkezelési tevékenység, milyen kockázatokat hoz létre az érintettek számára, mely kontrollok csökkentik ezeket a kockázatokat, ki a döntés felelőse, és mikor kell azt felülvizsgálni.

Az ISO/IEC 27701:2025 ezt az elvárást azzal erősíti, hogy az adatvédelmi irányítást egy irányított PIMS-be építi be. A gyakorlatban az adatvédelmi kockázatértékelésnek hat működési objektumot kell összekapcsolnia:

1. A személyes adatok kezelésére vonatkozó tevékenységek nyilvántartását, vagyis a RoPA-t.
2. A jogalapra és a célra vonatkozó dokumentációt.
3. Az adatvédelmi kockázat-előszűrést és a DPIA-döntést.
4. A kockázatkezelést és a kontrollkiválasztást.
5. A beszállítói, adatfeldolgozói és további adatfeldolgozói irányítást.
6. Az IBIR-ben és a PIMS-ben megőrzött bizonyítékokat.

A Clarysec ezt a kapcsolatot egyértelművé teszi. Az Enterprise Adatvédelmi kockázatértékelési és DPIA szabályzatban a kiváltó esemény még az adatkezelés megkezdése előtt következik be:

[Mindkettő] A folyamatgazda / üzleti felelős KÖTELES adatvédelmi kockázat-előszűrést kezdeményezni a REG04-ben, mielőtt a REG02-ben rögzített új vagy lényegesen módosított személyesadat-kezelés megkezdődik.

Ugyanez az előzetes fegyelem jelenik meg az Enterprise Személyesadat-kezelési tevékenységek nyilvántartása és jogalap szabályzatban:

[Mindkettő] A folyamatgazda / üzleti felelős KÖTELES adatvédelmi kockázat- és DPIA-előszűrést kezdeményezni a REG04-ben, mielőtt az új vagy lényegesen módosított személyesadat-kezelés folytatódik.

Ez megelőzi a gyakori hibamintázatot: a termék elindul, a RoPA később frissül, a DPIA-kérdés túl későn merül fel, és a kockázati nyilvántartásba soha nem kerül be az adatvédelmi forgatókönyv.

Az adatkezelők esetében ez támogatja a GDPR Article 6 szerinti jogalap-fegyelmet, az Article 25 szerinti beépített és alapértelmezett adatvédelmet, az Article 32 szerinti adatkezelés biztonságát és az Article 5 szerinti elszámoltathatóságot. Az adatfeldolgozók esetében támogatja a dokumentált utasításokat, az ügyfélbizonyosságot, a szerződéses határokat és a további adatfeldolgozói átláthatóságot.

A tényleges adatkezelésből induljon ki, ne egy üres sablonból

Az adatvédelmi kockázatértékelés sikertelen lesz, ha üres űrlappal és működési kontextus nélkül kezdődik. Az első kérdés ne az legyen, hogy „Szükségünk van DPIA-ra?”, hanem az, hogy „Milyen adatkezelés változik ténylegesen?”

Egy SaaS-, fintech- vagy egészségügyi technológiai szervezetnél a változás érintheti például:

• Új adatkategória bevezetését, például viselkedési használati adatokat, egészségügyi adatokat, biometrikus jeleket vagy fizetési metaadatokat.
• Új célt, például csaláspontozást, beteganalitikát, MI-támogatott ügyféltámogatást, lemorzsolódás-előrejelzést vagy személyre szabást.
• Új címzettet, adatfeldolgozót vagy további adatfeldolgozót.
• Új támogatási munkafolyamatot vagy határokon átnyúló hozzáférési útvonalat.
• Új megőrzési időtartamot.
• Új modellt, algoritmust vagy automatizált ajánlást.
• Új érintetti csoportot, például kiskorúakat, munkavállalókat, betegeket vagy pénzügyileg kiszolgáltatott személyeket.

A GDPR fogalommeghatározásai széles körűek. A személyes adat magában foglalja az azonosítókat, az online azonosítókat, a helymeghatározási adatokat és az identitáshoz kapcsolódó tényezőket. Az adatkezelés magában foglalja a gyűjtést, tárolást, lekérdezést, felhasználást, közlést, korlátozást, törlést és megsemmisítést. A személyesadat-sértés magában foglalja a véletlen vagy jogellenes megsemmisítést, elvesztést, megváltoztatást, jogosulatlan közlést vagy hozzáférést.

Ez azt jelenti, hogy az adatvédelmi kockázati munkafolyamatnak többet kell rögzítenie annál, hogy az adatbázis titkosított-e. Rögzítenie kell, miért létezik az adatkezelés, a cél összeegyeztethető-e, a jogalap érvényes-e, érintett-e különleges adatkategória, az érintettek megérthetik-e az adatkezelést, és az alkalmazott védelmi intézkedések arányosak-e.

Kisebb csapatok számára a kkv Adatvédelmi és magánélet-védelmi szabályzat adja a kiindulópontot az 5.2.1. pontban:

Az adatvédelmi koordinátor köteles nyilvántartást vezetni minden 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őtartamokat.

Ez a nyilvántartás nem adminisztratív papírmunka. Ez az adatvédelmi kockázatértékelés bemeneti modellje. Adatkategóriák, cél, jogalap és megőrzési időtartamok nélkül az értékelés nem tudja megbízhatóan vizsgálni a célhoz kötöttséget, az adattakarékosságot, a tárolási korlátozást, az átláthatóságot vagy a tisztességességet.

Ugyanez a kkv-szabályzat a kockázati felülvizsgálatot visszatérő kötelezettséggé teszi a 7.1.1. pontban:

Az adatvédelmi koordinátor köteles évente, valamint jelentős rendszerváltozások esetén értékelni az adatvédelmi kockázatokat.

Nagyvállalatoknál az irányítási gyakoriság szigorúbb. Az Enterprise Adatvédelmi és magánélet-védelmi szabályzat kimondja:

Az adatvédelmi kockázati nyilvántartásokat az IBIR-en belül kell fenntartani, és az adatvédelmi tisztviselő (DPO), valamint a CISO legalább negyedévente köteles felülvizsgálni azokat.

Itt válik gyakorlativá az ISO/IEC 27701:2025 és az ISO/IEC 27001:2022 integrációja. Az adatvédelmi kockázatok nem jogi mappákban rejtőznek. A biztonsági kockázatokkal, beszállítói kockázatokkal, incidensekkel, auditmegállapításokkal, kockázatkezelési tervekkel és vezetői jelentésekkel együtt kerülnek felülvizsgálatra.

A Clarysec REG02–REG04 munkafolyamat

A leghatékonyabb adatvédelmi kockázatértékelési folyamat elég egyszerű az üzleti felelősök számára, és elég szigorú az auditorok számára. A Clarysec modellje a REG02-t személyesadat-kezelési tevékenységek nyilvántartásaként, a REG04-et pedig adatvédelmi kockázatértékelési és DPIA-feljegyzésként használja.

Az Adatvédelmi kockázatértékelési és DPIA szabályzat meghatározza, milyen minimális bizonyíték szükséges a REG04 lezárása előtt:

[Mindkettő] Az adatvédelmi vezető / PIMS-vezető KÖTELES biztosítani, hogy minden REG04 értékelés a lezárás előtt rögzítse a kockázati besorolást, a kockázatkezelési döntést, a felelőst, a határidőt, a maradványkockázatot, a jóváhagyási státuszt és a felülvizsgálati dátumot.

Ez a mondat adja a működés gerincét. Egy adatvédelmi kockázatértékelés nem azért zárható le, mert valaki beírta egy megjegyzésmezőbe, hogy „alacsony kockázat”. Akkor zárható le, ha a bejegyzés tartalmazza a besorolást, a kockázatkezelési döntést, a felelőst, a határidőt, a maradványkockázatot, a jóváhagyási státuszt és a felülvizsgálati dátumot.

Kkv-k esetében ugyanez a fegyelem egyszerűsített formában alkalmazandó. A kkv Kockázatkezelési szabályzat kimondja:

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

Az alapelv az arányosság, nem az informalitás. A kisebb szervezetek használhatnak egyszerűbb nyilvántartást, de minden kockázathoz továbbra is szükséges leírás, pontszám, felelős és kockázatkezelési terv.

Használja az ISO/IEC 27001:2022 kockázatkezelési motorját az adatvédelemhez

Az adatvédelmi kockázat nem élhet a szervezet kockázatkezelési módszerén kívül. Az ISO/IEC 27001:2022 már biztosítja az irányítási rendszerszintű motort: kontextus, érdekelt felek, hatókör, vezetői szerepvállalás, kockázatértékelés, kockázatkezelés, operatív kontroll, dokumentált információ, teljesítményértékelés és folyamatos fejlesztés.

A 4.1–4.4. pontok előírják, hogy a szervezet értse meg a belső és külső tényezőket, az érdekelt felek követelményeit, az IBIR alkalmazási területét és az IBIR-folyamatokat. Adatvédelmi szempontból az érdekelt felek közé tartoznak az ügyfelek, az érintettek, a munkavállalók, a szabályozó hatóságok, az adatfeldolgozók, a további adatfeldolgozók, a felügyeleti hatóságok, adott esetben a pénzügyi szektorbeli felügyeletek és a szerződéses ügyfelek.

A 6.1.2. pont információbiztonsági kockázatértékelési folyamatot ír elő. A 6.1.3. pont információbiztonsági kockázatkezelést ír elő, beleértve a kontrollok kiválasztását, az alkalmazhatósági nyilatkozat elkészítését, a kockázatkezelési terv megfogalmazását, valamint a terv és a maradványkockázatok kockázatgazdai jóváhagyását. A 8.2. és 8.3. pontok előírják az információbiztonsági kockázatértékelések és kockázatkezelések elvégzését tervezett időközönként vagy jelentős változások esetén, a dokumentált eredmények megőrzése mellett.

A Clarysec Enterprise Kockázatkezelési szabályzat az 5.1. pontban ehhez a struktúrához igazodik:

Formális kockázatkezelési folyamatot kell fenntartani az ISO/IEC 27005 és az ISO 31000 szerint, amely kiterjed a kockázatazonosításra, -elemzésre, -értékelésre, -kezelésre, nyomon követésre és kommunikációra.

Adatvédelmi területen a kockázati kritériumoknak nemcsak az üzleti hatást, hanem az érintettekre gyakorolt hatást is tartalmazniuk kell. Az alacsony pénzügyi veszteség is jelenthet magas adatvédelmi hatást, ha az adatkezelés különleges adatkategóriákat, kiszolgáltatott érintetteket, profilalkotást, átláthatatlanságot, jogellenes megőrzést, joggyakorlási akadályokat vagy nem vagyoni sérelmet érint.

A Clarysec Zenith Blueprint: auditori 30 lépéses ütemterv ezt a Kockázatkezelés fázis 10. lépésében magyarázza:

A hatás meghatározásakor érdemes a szinteket az adott üzleti mérethez igazítani. Például: „Jelentős pénzügyi hatás = veszteség > 100 000 USD” (a saját környezethez igazítva). Vegye figyelembe a szabályozási hatást is: például egy személyes adatokat érintő adatsértés a GDPR bírságai és bejelentési követelményei miatt automatikusan „Jelentős” vagy „Súlyos” lehet, még akkor is, ha a közvetlen pénzügyi veszteség nem egyértelmű.

Ez az iránymutatás különösen fontos MI-analitika, egészségügyi adatok, pénzügyi profilalkotás, munkavállalói megfigyelés és ügyfélpontozás esetén. A kár lehet jogi, reputációs, diszkriminatív, működési, szerződéses vagy személyes jellegű.

Gyakorlati példa: MI-alapú beteganalitika

Térjünk vissza Mariához és Davidhez. Egészségügyi technológiai platformjuk a GDPR Article 9 szerinti különleges kategóriájú egészségügyi adatokat fog kezelni. Betegelőzményeket, időpontadatokat, klinikusi jegyzeteket és modellkimeneteket használ majd kockázati betekintések előállítására.

A Zenith Blueprint használatával a 9. lépéssel kezdenek: az eszközök, fenyegetések és sérülékenységek azonosításával:

Minden eszközhöz 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 informatikai osztály tulajdonában – AWS-en üzemeltetve – személyes és pénzügyi adatokat tartalmaz (magas érzékenység).”

Ugyanez a lépés hozzáadja az adatvédelmi nézőpontot:

Gondoskodjon arról, hogy a személyes adatokat tartalmazó eszközök meg legyenek jelölve (GDPR relevancia miatt), és a kritikus szolgáltatási eszközök is szerepeljenek (potenciális NIS2 alkalmazhatóság miatt, ha szabályozott ágazatban működik).

Maria csapata azonosítja az MI-alapú beteganalitikai platformot, a betegadatbázist, az adattárházat, a modellképzési folyamatláncot, a klinikusi irányítópultot, a felhőalapú tárolást, az identitásszolgáltatót, az auditnaplókat, a támogatási jegykezelő platformot és a harmadik féltől származó analitikai eszközt. Minden eszköz tulajdonost, helyet, osztályozást és személyesadat-kapcsolatot kap.

Ezután kockázati forgatókönyveket határoznak meg. Az egyik az egészségügyi nyilvántartásokhoz való jogosulatlan hozzáférés. Egy másik az analitikai exportokon keresztüli véletlen közlés. A harmadik az MI-modell torzítása, amelyet torz képzési adatok okoznak, és amely tisztességtelen vagy diszkriminatív betegkockázati pontozást eredményezhet.

A Zenith Blueprint 11. lépése ismerteti a kockázati nyilvántartás szerepét:

A kockázati nyilvántartás jellemzően táblázat (a „Risk Register and SoA Builder.xlsx” sablonunk ehhez külön munkalapot tartalmaz). Ez szolgál a kockázatok fő nyilvántartásaként.

Az MI-modell torzítási forgatókönyvéhez tartozó adatvédelmi kockázati bejegyzés például így nézhet ki:

Ez a bejegyzés megteszi azt, amire a régi táblázat nem volt képes. Összekapcsol egy adatkezelési tevékenységet egy eszközzel, fenyegetéssel, sérülékenységgel, az érintetteket érintő kockázattal, felelőssel, pontszámmal, kockázatkezelési tervvel és bizonyítéknyommal.

Mivel az adatkezelés magas kockázatú és különleges adatkategóriát érint, a DPIA nem különálló utólagos feladat. Egy már rendszerben rögzített kockázat mélyebb értékelési szakaszává válik. Az Enterprise Adatvédelmi és magánélet-védelmi szabályzat kimondja:

A személyes adatokat érintő rendszerek vagy folyamatok minden jelentős változásához dokumentált adatvédelmi hatásvizsgálatot (DPIA) kell készíteni, amelyet az adatvédelmi tisztviselőnek (DPO) felül kell vizsgálnia.

Magas maradványkockázatú adatkezelői kockázat esetén az Adatvédelmi kockázatértékelési és DPIA szabályzat hozzáteszi:

[Adatkezelő] A felső vezetés KÖTELES jóváhagyni a magas adatvédelmi maradványkockázat elfogadását a REG04-ben, mielőtt a magas kockázatú adatkezelői adatkezelés megkezdődik vagy folytatódik.

Az indulási döntés így visszakövethetővé válik: mi változott, mit értékeltek, milyen kockázatokat azonosítottak, milyen kontrollokat választottak ki, ki felel a kezelésért, ki hagyta jóvá a maradványkockázatot, és mikor kerül sor a döntés felülvizsgálatára.

A kockázatoktól a kontrollokig a Zenith Controls segítségével

Az adatvédelmi kockázatértékelésnek csak akkor van értelme, ha kontrollokkal kapcsolatos döntésekhez vezet. A Clarysec Zenith Controls: megfelelőségi keretrendszerek közötti útmutatója olyan több megfelelőségi keretrendszert átfogó útmutató, amely az ISO/IEC 27001:2022 és az ISO/IEC 27002:2022 kontrolljait kapcsolódó követelményekhez rendeli más keretrendszerekben. Nem külön kontrollkészlet. Segít a csapatoknak megérteni, hogyan támogatja ugyanaz a kontrollbizonyíték több kötelezettség teljesítését.

Az adatvédelmi kockázatértékelés szempontjából a Zenith Controls három központi ISO/IEC 27002:2022 kontrollt emel ki:

Az 5.34 kontroll támogatja továbbá a GDPR Article 25 és Article 32 követelményeit, a NIS2 Article 21 szerinti kiberbiztonsági kockázatkezelési intézkedéseket, a DORA IKT-kockázatkezelési elvárásait, valamint a NIST CSF 2.0 kimeneteit, például a GV.OC-03-at a jogi, szabályozási, szerződéses, adatvédelmi és polgári szabadságjogi kötelezettségekre, továbbá a PR.DS-01-et a tárolt adatok védelmére.

A Zenith Blueprint 13. lépése ezeket a döntéseket az alkalmazhatósági nyilatkozathoz kapcsolja:

Hivatkozza kereszthivatkozással a jogszabályokat: ha bizonyos kontrollokat kifejezetten a GDPR, NIS2 vagy DORA szerinti megfelelés érdekében vezettek be, ezt meg lehet jegyezni a kockázati nyilvántartásban (a kockázati hatás indokolásának részeként) vagy az SoA megjegyzéseiben.

Így válik egy adatvédelmi megállapítás IBIR- és PIMS-kontrolldöntéssé, nem pusztán jogi megjegyzéssé.

A beszállítói és adatfeldolgozói kockázatot jóváhagyás előtt kell értékelni

Sok adatvédelmi hiba a beszállítói irányításban kezdődik. Egy adatfeldolgozó új további adatfeldolgozót vesz igénybe. Egy támogatási beszállító éles rendszerhez való hozzáférést kap. Egy analitikai platform eseményadatokat tárol egy új régióban. A beszerzés aláírja a szerződést, mielőtt az adatvédelem látná a kockázatot.

A Clarysec Enterprise Adatfeldolgozói, további adatfeldolgozói és harmadik felek adatvédelmi kezelésére vonatkozó szabályzat ezt azzal előzi meg, hogy összekapcsolja a beszállítói felülvizsgálatot, a REG04-et és a harmadik fél nyilvántartást:

[Mindkettő] Az adatvédelmi vezető / PIMS-vezető KÖTELES adatvédelmi kockázat- és DPIA-előszűrést indítani a REG04-ben a magas kockázatú adatfeldolgozói kapcsolatok és a harmadik féllel fennálló adatvédelmi kapcsolat lényeges változásai esetén, még a jóváhagyás előtt, a REG04-hivatkozás REG08-ban történő rögzítésével.

Kkv-k esetében a Harmadik felekre és beszállítókra vonatkozó biztonsági szabályzat határozza meg az együttműködés előtti felülvizsgálati követelményt:

Az együttműködés megkezdése előtt minden beszállítót felül kell vizsgálni a lehetséges kockázatok szempontjából. Ennek a felülvizsgálatnak tartalmaznia kell:

Az operatív üzenet egyértelmű. A beszállítói kockázatot jóváhagyás előtt kell értékelni, nem az aláírás után.

Ez a NIS2-t és a DORA-t is támogatja. A NIS2 Article 21 az ellátási lánc biztonságát a kiberbiztonsági kockázatkezelési intézkedések részeként írja elő. A DORA Articles 28 to 30 előírja a pénzügyi szervezetek számára az IKT-harmadikfél-kockázat kezelését, a szerződéskötést megelőző értékelések elvégzését, a szerződéses védelmi intézkedések fenntartását, az alvállalkozói kockázat megértését, a függőségek nyomon követését és a kilépések megtervezését a kritikus vagy fontos funkciók esetében.

Ha egy beszállító személyes adatokhoz fér hozzá vagy adatvédelmi szempontból kritikus adatkezelést támogat, az adatvédelmi kockázati bejegyzésnek tartalmaznia kell a beszállítót, az adatkezelési szerepkört, az adatok helyét, a további adatfeldolgozói függőséget, a szerződéses védelmi intézkedéseket, az incidensvállalásokat, a megőrzési szabályokat, a nyomon követési megközelítést és a kilépési tervet.

Egy munkafolyamat, több megfelelőségi eredmény

Az integrált PIMS-munkafolyamat előnye, hogy ugyanaz a bizonyíték több keretrendszert is támogat, párhuzamos munkavégzés nélkül.

A NIST CSF 2.0 különösen hasznos a felsővezetői kommunikációban. GOVERN funkciója lefedi a szervezeti kontextust, a kockázatkezelési stratégiát, a szabályzatot, a szerepköröket, a felügyeletet és az ellátási lánc kockázatát. Szervezeti profiljai segítenek az aktuális és célkimeneteket priorizált intézkedési tervvé alakítani, például kockázati nyilvántartássá vagy intézkedési és mérföldkőtervvé.

A NIS2, DORA vagy ágazatspecifikus szabályok hatálya alá tartozó szervezeteknél az adatvédelmi kockázati bizonyíték a kiberbiztonsági irányítást, a beszállítói felügyeletet, az incidenskezelésre való felkészültséget és a reziliencia-jelentéstételt is támogatja.

Az adatvédelmi kockázatkezelés több, mint titkosítás

A titkosítás fontos, de nem tud kijavítani érvénytelen jogalapot, túlzott adatgyűjtést, nem közölt profilalkotást, tisztességtelen adatkezelést, jogellenes megőrzést vagy olyan adatfeldolgozót, amely az utasításokon kívül jár el.

A kkv Adatvédelmi és magánélet-védelmi szabályzat kimondja:

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

Ezek erős példák, de a kockázatkezelésnek illeszkednie kell a forgatókönyvhöz. Egy adatvédelmi kockázatkezelési terv tartalmazhatja az adatkezelési cél szűkítését, a szükségtelen adatkategóriák eltávolítását, az adatok aggregálását vagy álnevesítését, a tájékoztatók frissítését, a jogalap megfelelő esetben történő módosítását, a megőrzés korlátozását, a hozzáférés korlátozását, naplózás hozzáadását, a szerződések frissítését, DPIA elvégzését, az indulás elhalasztását vagy az elfogadhatatlanul kockázatos adatkezelés elutasítását.

Az Enterprise Kockázatkezelési szabályzat megerősíti a kockázattűrés feletti kockázatok kezelési tervezését:

A kockázattűrési szint felett besorolt valamennyi kockázathoz kapcsolódó kockázatkezelési tervet kell készíteni, amely meghatározza:

A gyakorlatban ez azt jelenti, hogy magas adatvédelmi kockázatot nem lehet hallgatólagosan elfogadni. Kezelni kell, adott esetben át kell ruházni, el kell kerülni, vagy a megfelelő végső felelős kontrollgazdának formálisan el kell fogadnia.

A felülvizsgálati kiváltó események életben tartják az értékelést

Az adatvédelmi kockázatértékelés, amelyet soha nem vizsgálnak felül, elavult bizonyítékká válik. Az ISO/IEC 27001:2022 8.2. és 8.3. pontjai előírják a kockázatértékelést és kockázatkezelést tervezett időközönként vagy jelentős változások esetén. A GDPR szerinti elszámoltathatóság aktuális döntéseket vár el. Az ISO/IEC 27701:2025 a nyomon követésre és a folyamatos fejlesztésre támaszkodik.

A REG04 értékelést újra kell nyitni, ha a cél megváltozik, új adatkategóriákat adnak hozzá, különleges adatkategória válik érintetté, megváltozik a jogalap, adatfeldolgozó vagy további adatfeldolgozó változik, a tárolás új régióba kerül, megváltoznak a megőrzési időtartamok, módosul a profilalkotási logika, adatsértés vagy majdnem bekövetkezett esemény történik, megváltoznak az ügyfélszerződések, vagy új NIS2, DORA vagy ágazatspecifikus kötelezettség alkalmazandó.

Az incidensfolyamatoknak vissza kell csatolniuk az adatvédelmi kockázati munkafolyamatba. A NIS2 Article 23 szakaszos jelentős incidensjelentést állapít meg. A DORA Articles 17 to 20 előírja az IKT-vonatkozású incidensek rögzítését, besorolását, eszkalációját, kommunikációját, gyökérok-elemzését és a fejlesztést. A GDPR szerinti személyesadat-sértési kötelezettségek is kiváltódhatnak. Ha egy incidens gyenge hozzáférés-szabályozást, túlzott megőrzést, nem egyértelmű beszállítói értesítést vagy hiányos ügyfélutasításokat tár fel, a REG04-et frissíteni kell.

Mit várnak el az auditorok

Egy erős adatvédelmi kockázati munkafolyamatnak több bizonyossági nézőpontból is helyt kell állnia.

Az Enterprise Adatvédelmi és magánélet-védelmi szabályzat belső audit tevékenységet is előír:

Évente, illetve jelentős szervezeti vagy szabályozási változás esetén belső adatvédelmi megfelelőségi auditot kell végezni. Az audit hatókörének tartalmaznia kell:

Ez vezetői visszacsatolási kört hoz létre. Teljesek-e a REG02 bejegyzések? Időben történnek-e a REG04 előszűrések? Elvégzik-e a DPIA-kat, amikor szükséges? Jóváhagyják-e a magas maradványkockázatokat? Rögzítik-e a beszállítói változásokat? Lezárják-e a kockázatkezelési terveket? Összhangban vannak-e a tájékoztatók a tényleges adatkezeléssel?

Ellenőrzőlista a következő adatvédelmi változtatási megbeszéléshez

Használja ezt az ellenőrzőlistát, mielőtt egy új adatkezelési tevékenység, termékfunkció, beszállító, modell vagy támogatási munkafolyamat éles indulása megtörténik.

Ez az ellenőrzőlista nem helyettesíti a szabályzatot. Gyakorlati módot ad a szabályzat operatív alkalmazására termék-, beszerzési, mérnöki, megfelelőségi, jogi és vezetői megbeszéléseken.

Alakítsa az adatvédelmi elszámoltathatóságot működő rendszerré

Az ISO/IEC 27701:2025 és a GDPR szerinti elszámoltathatóság többet igényel dokumentumoknál. Olyan működő rendszerre van szükség, amely összekapcsolja az adatkezelési nyilvántartásokat, a jogalapot, az adatvédelmi kockázatot, a DPIA-döntéseket, a beszállítókat, a kontrollokat, a felelősöket, a jóváhagyásokat és a bizonyítékokat.

Kezdje a Zenith Blueprint Kockázatkezelés fázisával, különösen a 9–13. lépéssel. Használja a Risk Register and SoA Builder eszközt az eszközök, fenyegetések, sérülékenységek, adatvédelmi kockázatok, kockázatkezelési döntések és kontrollhivatkozások összekapcsolására. Ezután használja a Zenith Controls útmutatót a személyes adatok védelme, az eszköznyilvántartás és a beszállítói biztonság megfeleltetésére a GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 és COBIT 19 bizonyossági elvárásainak.

Hangolja össze azokat a működési szabályzatokat, amelyek kikényszeríthetővé teszik a munkafolyamatot: Adatvédelmi kockázatértékelési és DPIA szabályzat, Személyesadat-kezelési tevékenységek nyilvántartása és jogalap szabályzat, Adatfeldolgozói, további adatfeldolgozói és harmadik felek adatvédelmi kezelésére vonatkozó szabályzat, Kockázatkezelési szabályzat és Adatvédelmi és magánélet-védelmi szabályzat. A kisebb csapatok használhatják a Clarysec kkv-szabályzatait, míg a nagyobb szervezetek az irányítást Enterprise szabályzatokkal strukturálhatják.

Ha a csapata új adatkezelést indít, beszállítót vált, ISO/IEC 27701:2025-re készül, vagy ismételhetővé szeretné tenni a GDPR szerinti elszámoltathatósági bizonyítékokat, kezdje egy élő adatkezelési tevékenységgel. Nyissa meg a REG02-t, végezze el a REG04 előszűrést, feleltesse meg a kockázatokat a kontrolloknak, jelölje ki a kockázatkezelési felelősöket, és a megfelelő döntéshozóval vizsgálja felül a maradványkockázatot.

Ez az egyetlen munkafolyamat az a pont, ahol az adatvédelmi irányítás operatív működéssé válik.