Auditkész PII-védelem GDPR, NIS2 és DORA szerint
A riasztás kedden este 10 órakor érkezett Sarah postafiókjába.
Egy növekedési szakaszban lévő fintech SaaS vállalat információbiztonsági vezetőjeként (CISO) Sarah számára nem voltak ismeretlenek a késő esti riasztások. Ez azonban más volt. Egy junior fejlesztő egy új analitikai funkció tesztelése közben nyilvános végpontra tett ki egy előéles adatbázist. Az adatbázisnak tesztadatokat kellett volna tartalmaznia, de egy friss, éles rendszerből előéles környezetbe végzett szinkronizálás valódi ügyfél-PII-adatokkal töltötte fel.
Az incidenst gyorsan elszigetelték. Ezután érkezett a második megállapítás. Ugyanabból az adatkészletből kimásoltak egy customer_users_final_v7.xlsx nevű migrációs táblázatot. A fájl neveket, e-mail-címeket, szerepköralapú jogosultságokat, használati naplókat, országmezőket, támogatási megjegyzéseket és szabad szöveges kommenteket tartalmazott, amelyeknek soha nem lett volna szabad tesztelési munkafolyamatba kerülniük. A fájlt megosztott meghajtóra másolták, egy fejlesztő letöltötte, csatolta egy jegyhez, majd megfeledkeztek róla.
Éjfélre Sarah már nem technikai hibás konfigurációt kezelt. Auditproblémát kezelt.
A vállalat már rendelkezett ISO/IEC 27001:2022 tanúsítással. Az igazgatóság GDPR szerinti bizonyosságot kért az EU-piaci bevezetés előtt. A pénzügyi szolgáltatási ügyfelek DORA szerinti átvilágítási kérdőíveket küldtek. A felhő- és felügyelt szolgáltatási kapcsolatok NIS2 ellátásilánc-kérdéseket vetettek fel. A jogi terület el tudta magyarázni a kötelezettségeket. A mérnöki terület a titkosításra tudott hivatkozni. A termékcsapatnak beépített adatvédelmi szándékai voltak. Az alkalmazhatósági nyilatkozat említette az adatvédelmet és a PII védelmét.
De senki nem tudta egyetlen visszakövethető láncban bemutatni, milyen PII létezik, miért kezelik, ki férhet hozzá, hol maszkolják, mely beszállítók érintik, meddig őrzik meg, és hogyan kellene egy incidenst GDPR, NIS2 vagy DORA szerint besorolni.
Pontosan ezért fontos az ISO/IEC 27701:2025 és az ISO/IEC 29151:2022. Ezek nem pusztán adatvédelmi címkék. Segítenek a szervezeteknek abban, hogy az adatvédelmi ígéreteket auditkész PII-védelmi kontrollokká alakítsák. Az ISO/IEC 27701:2025 az ISO/IEC 27001:2022 szerinti információbiztonság-irányítási rendszert adatvédelmi információirányítási rendszerré terjeszti ki. Az ISO/IEC 29151:2022 gyakorlati útmutatást ad a személyazonosításra alkalmas információk teljes életcikluson átívelő védelméhez.
A Clarysec megközelítése egyetlen, bizonyítékokra épülő adatvédelmi és biztonsági működési modell kialakítása, nem pedig különálló megfelelési silók létrehozása. Ez a modell a Zenith Blueprint: Egy auditor 30 lépéses ütemterve Zenith Blueprint, a Zenith Controls: Keresztmegfelelőségi útmutató Zenith Controls és a Clarysec szabályzatok összekapcsolásával egyetlen visszakövethető rendszert hoz létre GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, NIST-jellegű bizonyossági és COBIT 2019 irányítási elvárásokhoz.
Miért lett a PII-védelem igazgatósági szintű auditkérdés?
A PII-védelmet korábban jellemzően az adatvédelmi csapat felelősségének tekintették. Ma már igazgatósági szintű bizalmi, reziliencia- és szabályozási kérdés.
A GDPR továbbra is a személyes adatok védelmének alapja Európában és azon túl. Olyan fogalmakat határoz meg, mint a személyes adat, adatkezelés, adatkezelő, adatfeldolgozó, címzett, harmadik fél, hozzájárulás és személyesadat-sértés, amelyek hatással vannak a SaaS-szerződésekre, a támogatási működésre, az analitikára, a terméktelemetriára, a beszállító-kezelésre és az incidensreagálásra. Alapelvei megkövetelik a jogszerűséget, tisztességességet, átláthatóságot, célhoz kötöttséget, adattakarékosságot, pontosságot, korlátozott tárolhatóságot, integritást, bizalmas jelleget és elszámoltathatóságot. Audit szempontból a GDPR nemcsak azt kérdezi, hogy az adatok titkosítottak-e. Azt is megköveteli, hogy a szervezet igazolni tudja, miért léteznek az adatok, és hogyan valósul meg a megfelelés.
A NIS2 magasabbra emeli a kiberbiztonsági irányítási elvárásokat az alapvető és fontos szervezetek számára. Article 21 kiberbiztonsági kockázatkezelési intézkedéseket ír elő, beleértve a kockázatelemzést, az információs rendszerek biztonsági szabályzatait, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a biztonságos fejlesztést, a sérülékenységkezelést, a kontrollhatékonyság értékelését, a kiberhigiéniát, a kriptográfiát, a HR-biztonságot, a hozzáférés-szabályozást, az eszközkezelést, a hitelesítést és a biztonságos kommunikációt. Article 23 szakaszos incidensjelentést vezet be, beleértve a 24 órán belüli korai figyelmeztetést, a 72 órán belüli bejelentést és a bejelentést követő egy hónapon belüli zárójelentést.
A DORA megváltoztatja a pénzügyi szervezetek és IKT-szolgáltatóik közötti párbeszédet. 2025. január 17-től alkalmazandó, és harmonizált digitális operatív reziliencia-rendszert hoz létre, amely lefedi az IKT-kockázatkezelést, a jelentős IKT-vonatkozású incidensek bejelentését, a rezilienciatesztelést, az IKT harmadik fél kockázatot, a szerződéses követelményeket és a kritikus IKT harmadik fél szolgáltatók felügyeletét. Sok pénzügyi szervezet esetében a DORA ágazatspecifikus uniós jogi aktusként működik ott, ahol a NIS2-vel egyenértékű kötelezettségek átfednek. A pénzügyi intézményeket kiszolgáló SaaS- és IKT-beszállítók számára a DORA-nyomás gyakran szerződéses záradékokon, ügyfélauditokon, kilépéstervezési követelményeken, incidens-támogatási kötelezettségeken és rezilienciateszteken keresztül jelenik meg.
Az ISO/IEC 27001:2022 adja az irányítási rendszer gerincét. Megköveteli a kontextus, az érdekelt felek, a hatály, a vezetői elszámoltathatóság, a szabályzatok, a szerepkörök, a kockázatértékelés, a kockázatkezelés, az alkalmazhatósági nyilatkozat, a belső audit, a vezetőségi átvizsgálás és a folyamatos fejlesztés kezelését. Az A melléklet közvetlenül PII-védelemhez kapcsolódó kontrollokat tartalmaz, beleértve az 5.34 adatvédelem és PII-védelem, az 5.18 hozzáférési jogosultságok, a 8.11 adatmaszkolás, az 5.23 információbiztonság felhőszolgáltatások használata esetén, a 8.15 naplózás, a 8.33 tesztadatok, a 8.24 kriptográfia használata és a 8.10 információtörlés kontrollokat.
A kihívás nem az, hogy a szervezeteknek nincsenek kontrolljaik. Hanem az, hogy a kontrollok széttöredezettek. Az adatvédelmi nyilvántartások a jogi területnél vannak. A hozzáférés-felülvizsgálatok az IT-nál. A maszkolási szkriptek a mérnöki területnél. A beszállítói szerződések a beszerzésnél. A bizonyítékok jegyekben, képernyőképekben, táblázatokban és e-mailekben találhatók.
Az ISO/IEC 27701:2025 és az ISO/IEC 29151:2022 segít egységesíteni ezeket a bizonyítékokat az adatvédelmi információirányítás és a PII-védelmi gyakorlatok köré. A Clarysec ezt a struktúrát működési modellé alakítja.
Az IBIR-től a PIMS-ig: az integrált adatvédelmi kontroll-lánc
Az ISO/IEC 27001:2022 szerinti IBIR egy alapvető kérdésre ad választ: az információbiztonság irányított, kockázatalapú, bevezetett, felügyelt és fejlesztett-e?
A Privacy Information Management System, vagyis PIMS ezt a kérdést a személyes adatokra terjeszti ki: az adatvédelmi felelősségek, a PII-kezelési tevékenységek, az adatvédelmi kockázatok, az adatkezelői és adatfeldolgozói kötelezettségek, az érintetti jogok és az adatvédelmi kontrollok bizonyítékai ugyanabban a rendszerben vannak-e kezelve?
Az ISO/IEC 27701:2025 az IBIR-t adatvédelmi irányítással egészíti ki. Az ISO/IEC 29151:2022 ezt gyakorlati PII-védelmi útmutatással támogatja, beleértve az adatgyűjtés korlátozását, a közlés kezelését, az adatmaszkolás vagy álnevesítés alkalmazását, az adattovábbítások védelmét, a hozzáférés korlátozását és a kontrollok adatvédelmi kockázatokkal való összhangját.
| Réteg | Elsődleges kérdés | Tipikus auditbizonyíték |
|---|---|---|
| ISO/IEC 27001:2022 | Létezik-e irányított, kockázatalapú IBIR kiválasztott és működő kontrollokkal? | Hatály, érdekelt felek, kockázatértékelés, kockázatkezelési terv, SoA, szabályzatok, belső audit, vezetőségi átvizsgálás |
| ISO/IEC 27701:2025 | Az adatvédelmi felelősségek, adatvédelmi kockázatok és PII-kezelési tevékenységek az irányítási rendszeren belül vannak-e kezelve? | Adatvédelmi szerepkörök, adatkezelési nyilvántartás, adatkezelői és adatfeldolgozói eljárások, adatvédelmi kockázatértékelések, DPIA-k, érintetti kérelmek folyamata |
| ISO/IEC 29151:2022 | Bevezették-e a gyakorlati PII-védelmi intézkedéseket az adatok életciklusa során? | PII-osztályozás, hozzáférési korlátozások, adatmaszkolás, álnevesítés, megőrzési kontrollok, adattovábbítási védelmi intézkedések, incidensbizonyítékok |
| GDPR | Tudja-e a szervezet igazolni a jogszerű, tisztességes, átlátható, adattakarékos, biztonságos és elszámoltatható adatkezelést? | Jogalap-nyilvántartások, adatvédelmi tájékoztatók, DPIA-k, incidensfolyamat, adatfeldolgozói megállapodások, érintetti joggyakorlás kezelése |
| NIS2 és DORA | Tudja-e a szervezet irányítani a kiberbiztonsági és rezilienciakockázatokat, beleértve az incidenseket és beszállítókat? | Vezetői felügyelet, IKT-kockázati keretrendszer, incidensbesorolás, jelentési forgatókönyvek, beszállítói nyilvántartások, auditálási jogok, folytonossági tesztek |
Ez a rétegzett modell megelőzi az adatvédelmi megfelelés leggyakoribb hibáját: azt, hogy a PII-t csupán egy újabb érzékeny adattípusként kezeljék. A PII jogi, etikai, működési, szerződéses és reputációs kötelezettségeket hordoz. Olyan kontroll-láncra van szüksége, amely a tudatossággal kezdődik és a bizonyítékokkal zárul.
Adattudatossággal kezdjen, ne titkosítási diagramokkal
A Clarysec által leggyakrabban látott adatvédelmi hiba a kontextus hiánya. Egy vállalat nem tudja védeni a PII-t, ha nem tudja, milyen PII-vel rendelkezik, hol található, milyen célt szolgál, meddig őrzi meg, vagy ki férhet hozzá.
A Zenith Blueprint ezt a munkát korán, a kockázatkezelési fázisban kezdi. A 9. lépésben, az eszközök, fenyegetések és sérülékenységek azonosításánál arra utasítja a szervezeteket, hogy vegyék nyilvántartásba az információs vagyonelemeket, és kifejezetten jelöljék a személyes adatokat:
„Minden eszköznél rögzítse a kulcsadatokat: név/leírás, tulajdonos, hely és osztályozás (érzékenység). Például egy eszköz lehet: ‘Ügyféladatbázis – az IT osztály tulajdonában – AWS-en üzemeltetve – személyes és pénzügyi adatokat tartalmaz (magas érzékenység).’”
Ezt is hozzáteszi: „Gondoskodjon arról, hogy a személyes adatokat tartalmazó vagyonelemek jelölve legyenek (GDPR-relevancia miatt), és a kritikus szolgáltatási vagyonelemek is feltüntetésre kerüljenek (potenciális NIS2-alkalmazhatóság miatt, ha szabályozott ágazatban működik).”
Ez az ISO/IEC 27701:2025 és az ISO/IEC 29151:2022 bevezetésének alapja. A gyakorlati sorrend egyszerű:
- Azonosítsa azokat a rendszereket, adatkészleteket, adattárakat, naplókat, jelentéseket, biztonsági mentéseket, támogatási eszközöket, fejlesztési környezeteket és beszállítókat, amelyek PII-t kezelnek.
- Rendeljen tulajdonost minden PII-vagyonelemhez.
- Osztályozza a PII-t érzékenység, üzleti cél, jogalap, adatkezelési szerep és megőrzési követelmény szerint.
- Kapcsolja össze az egyes PII-vagyonelemeket a fenyegetésekkel, sérülékenységekkel, kockázati forgatókönyvekkel és szabályozási kötelezettségekkel.
- Válassza ki a kontrollokat, rendeljen hozzá bizonyítékokat, és kövesse nyomon a működésüket az idő során.
A Clarysec szabályzatok ezt végrehajthatóvá teszik. A KKV-k számára készült Adatvédelmi és magánszféra-védelmi szabályzat Adatvédelmi és magánszféra-védelmi szabályzat – KKV kimondja:
„Az adatvédelmi koordinátor köteles nyilvántartást vezetni 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.
Nagyvállalati szervezetek esetében az Adatvédelmi és magánszféra-védelmi szabályzat Adatvédelmi és magánszféra-védelmi szabályzat szigorú adattakarékossági szabályt állapít meg:
„Csak meghatározott, jogszerű üzleti célhoz szükséges adatok gyűjthetők és kezelhetők.”
„A szabályzat végrehajtásának követelményei” szakasz 6.2.1 szabályzati pontjából.
Ezek a pontok a GDPR szerinti elszámoltathatóságot napi működéssé alakítják. Támogatják az adatvédelmi információirányítást és a PII-védelmet is, mert rákényszerítik a szervezetet annak meghatározására, milyen adatok léteznek, miért léteznek, és szükségesek-e.
A három kontroll, amely valóssá teszi a PII-védelmet
Három ISO/IEC 27001:2022 A melléklet szerinti kontroll gyakran eldönti, hogy a PII-védelem audit során igazolható-e: 5.34 adatvédelem és PII-védelem, 8.11 adatmaszkolás és 5.18 hozzáférési jogosultságok.
5.34 Adatvédelem és PII-védelem
Az 5.34 kontroll az irányítási központ. A Zenith Controls az 5.34-et megelőző kontrollként kezeli, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást, valamint az azonosítási és védelmi kiberbiztonsági koncepciókat, továbbá az információvédelem és a jogi megfelelés működési képességeit.
A Zenith Controls egyértelművé teszi a függőséget:
„Az információs vagyonelemek nyilvántartásának (5.9) tartalmaznia kell a PII-adatkészleteket (ügyféladatbázisok, HR-fájlok). Ez alátámasztja az 5.34-et azzal, hogy biztosítja: a szervezet tudja, milyen PII-vel rendelkezik és hol, ami a védelem első lépése.”
Az 5.34 kontroll az 5.9 információk és egyéb kapcsolódó vagyonelemek nyilvántartásától függ, mert a PII nem védhető, ha nem azonosították és nem lokalizálták. Kapcsolódik az 5.23 információbiztonság felhőszolgáltatások használata esetén kontrollhoz is, mert a PII jelentős része ma felhőplatformokban, SaaS-eszközökben, analitikai környezetekben és felügyelt szolgáltatásokban található.
Magas kockázatú adatkezelés esetén a nagyvállalati Adatvédelmi és magánszféra-védelmi szabályzat előírja:
„A fenyegetésmodellezés és az adatvédelmi hatásvizsgálatok (DPIA-k) kötelezőek a magas kockázatú adatkezelési rendszerek esetében.”
„A szabályzat végrehajtásának követelményei” szakasz 6.3.4 szabályzati pontjából.
Ez a pont kritikus. Az adatvédelmet tervezési és kockázatkezelési tevékenységgé teszi, nem pedig utolsó pillanatos jogi felülvizsgálattá.
8.11 Adatmaszkolás
A 8.11 kontroll közvetlen válasz Sarah előéles adatbázis-kitettségére. A Zenith Controls a 8.11-et megelőző bizalmassági kontrollként írja le az információvédelem területén. A 8.11-et összekapcsolja az 5.12 információosztályozással, mert a maszkolási döntések az érzékenységtől függenek; az 5.34-gyel, mert az adatmaszkolás támogatja az adatvédelmet; valamint a 8.33 tesztadatokkal, mert a tesztkörnyezeteknek nem szabad valódi PII-t felfedniük.
Az Adatmaszkolási és álnevesítési szabályzat Adatmaszkolási és álnevesítési szabályzat egyértelművé teszi a szabályt:
„Valódi személyes adat nem használható fejlesztési, teszt- vagy előéles környezetben. Helyette maszkolt vagy álnevesített adatokat kell használni, amelyeket előzetesen jóváhagyott átalakítási sablonokból kell előállítani.”
„A szabályzat végrehajtásának követelményei” szakasz 6.3 szabályzati pontjából.
KKV-k esetében az Adatmaszkolási és álnevesítési szabályzat Adatmaszkolási és álnevesítési szabályzat – KKV egy kulcsfontosságú biztonsági és bizonyítékképzési követelményt ad hozzá:
„A kulcsokhoz való hozzáférést titkosítani, hozzáférés-szabályozással védeni és naplózni kell.”
„A szabályzat végrehajtásának követelményei” szakasz 6.2.1.3 szabályzati pontjából.
Ez azért fontos, mert az álnevesítés csak akkor csökkenti a kockázatot, ha az átalakítási logika, a kulcsok és az újraazonosítási útvonalak kontroll alatt állnak.
5.18 Hozzáférési jogosultságok
Az 5.18 kontroll a legkisebb jogosultság elvének működési központja. A Zenith Controls megelőző kontrollként kezeli, amely a bizalmassághoz, sértetlenséghez és rendelkezésre álláshoz kapcsolódik, és az identitás- és hozzáférés-kezelés alá tartozik. Az 5.18-at az 5.15 hozzáférés-szabályozáshoz, az 5.16 identitáskezeléshez és a 8.2 emelt szintű hozzáférési jogosultságokhoz köti.
A KKV-k számára készült Adatosztályozási és címkézési szabályzat Adatosztályozási és címkézési szabályzat – KKV kimondja:
„A hozzáférést kizárólag kifejezetten engedélyezett, a szükséges ismeret elve alapján hozzáférésre jogosult felhasználókra kell korlátozni.”
Az „Irányítási követelmények” szakasz 5.2.1 szabályzati pontjából.
A nagyvállalati Adatosztályozási és címkézési szabályzat Adatosztályozási és címkézési szabályzat meghatározza az osztályozási alapot:
„Minden információs vagyonelemnek létrehozásakor vagy nyilvántartásba vételekor egyértelműen hozzárendelt osztályozással kell rendelkeznie. Kifejezett osztályozás hiányában a vagyonelemeket formális felülvizsgálatig alapértelmezetten ‘Bizalmas’ besorolásúnak kell tekinteni.”
Az „Irányítási követelmények” szakasz 5.4 szabályzati pontjából.
Ezek a kontrollok együtt alkotják a gyakorlati PII-védelmi láncot: ismerni kell a PII-t, osztályozni kell, korlátozni kell a hozzáférést, maszkolni kell ott, ahol a teljes identitás nem szükséges, védeni kell a kulcsokat, naplózni kell a hozzáférést, és meg kell őrizni a bizonyítékokat.
Visszakövethetőség kialakítása az alkalmazhatósági nyilatkozaton keresztül
Egy adatvédelmi irányítási rendszer akkor válik auditkésszé, ha igazolni tudja a visszakövethetőséget. A Zenith Blueprint kockázatkezelési fázisának 13. lépése, a kockázatkezelési tervezés és alkalmazhatósági nyilatkozat, az alkalmazhatósági nyilatkozatot összekötő dokumentumként írja le:
„A SoA gyakorlatilag összekötő dokumentum: összekapcsolja a kockázatértékelést/kockázatkezelést a tényleges kontrollokkal. A kitöltésével azt is ellenőrzi, hogy nem maradt-e ki kontroll.”
Ez a koncepció központi az ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2 és DORA szerinti felkészültségben. Minden PII-kontrollnak visszakövethetőnek kell lennie a követelménytől a kockázatig, a kockázattól a kontrollig, a kontrolltól a tulajdonosig, a tulajdonostól a bizonyítékig, és a bizonyítéktól a felülvizsgálatig.
| Visszakövethetőségi elem | Példa ügyféltámogatási PII-re | Elvárt bizonyíték |
|---|---|---|
| PII-vagyonelem | Ügyféltámogatási jegykezelő platform ügyfélnevekkel, e-mail-címekkel, naplókkal és csatolmányokkal | Eszköznyilvántartási bejegyzés, tulajdonos, felhőhelyszín, osztályozás |
| Adatkezelési cél | Ügyféltámogatás és szolgáltatásdiagnosztika | Adatkezelési nyilvántartás, jogalap, megőrzési idő |
| Kockázati forgatókönyv | Támogatási ügyintéző vagy fejlesztő túlzott mennyiségű ügyféladathoz fér hozzá | Kockázati nyilvántartási bejegyzés, valószínűség, hatás, tulajdonos |
| Kontrollkiválasztás | 5.34 PII-védelem, 5.18 hozzáférési jogosultságok, 8.11 maszkolás, 8.15 naplózás, 5.23 felhőirányítás | SoA, hozzáférési szabályzat, maszkolási szabvány, naplózási konfiguráció |
| Működési bizonyíték | Szerepköralapú hozzáférés, maszkolt exportok, negyedéves hozzáférési felülvizsgálat, riasztás tömeges letöltésekre | Hozzáférési felülvizsgálati feljegyzések, DLP-riasztások, naplók, jegyhez kapcsolódó bizonyítékok |
| Szabályozási megfeleltetés | GDPR szerinti elszámoltathatóság és biztonság, NIS2 kockázatkezelés, DORA IKT-kockázati és beszállítói követelmények | Megfelelési mátrix, incidens-forgatókönyv, beszállítói szerződésnyilvántartás |
| Felülvizsgálati bizonyíték | Belső auditmegállapítás lezárva, vezetőségi átvizsgálási intézkedés elfogadva | Auditjelentés, helyesbítő intézkedés, vezetőségi átvizsgálási jegyzőkönyvek |
Az ISO/IEC 27005:2022 támogatja ezt a kockázatalapú megközelítést az érdekelt felek követelményeinek, a közös kockázati kritériumoknak, az elszámoltatható kockázattulajdonosoknak, az ismételhető kockázatértékelésnek, a kockázatkezelésnek, a kontrollkiválasztásnak, az alkalmazhatósági nyilatkozattal való összhangnak, a maradványkockázat jóváhagyásának, a nyomon követésnek és a folyamatos fejlesztésnek a hangsúlyozásával. A PII-védelemnek élő kockázati ciklusnak kell lennie, nem egyszeri GDPR-dokumentációs gyakorlatnak.
A kockázatos táblázat és az előéles adatbázis rendbetétele
Sarah incidense ismételhető kontrollcsomaggá alakítható, ha a helyesbítő intézkedéseket rendszerezetten kezelik.
| Lépés | Művelet | Clarysec bizonyítékkimenet |
|---|---|---|
| 1 | Vegye nyilvántartásba az előéles adatbázist és a táblázatot PII-vagyonelemként | Eszköznyilvántartási bejegyzések tulajdonossal, hellyel, osztályozással, PII-kategóriákkal, céllal és megőrzéssel |
| 2 | Frissítse az adatkezelési tevékenységet | Nyilvántartási bejegyzés adatkategóriákkal, jogalappal, céllal és megőrzési idővel |
| 3 | Osztályozza a fájlokat és adatkészleteket | Alapértelmezés szerint Bizalmas vagy magasabb besorolás alkalmazása formális felülvizsgálatig |
| 4 | Távolítsa el a valódi PII-t a nem éles környezetből | Jóváhagyott átalakítási sablonokból előállított maszkolt vagy álnevesített adatkészlet |
| 5 | Korlátozza és vizsgálja felül a hozzáférést | A szükséges ismeret elvén alapuló jogosultságok, túlzott hozzáférések visszavonása, hozzáférési felülvizsgálati feljegyzés |
| 6 | Védje az átalakítási logikát és a kulcsokat | Titkosított, hozzáférés-szabályozott és naplózott kulcshozzáférés |
| 7 | Gyűjtse központilag a bizonyítékokat | Eszköznyilvántartási bejegyzés, kockázati bejegyzés, hozzáférési felülvizsgálat, törlési igazolás, maszkolási jóváhagyás és jegylezárás |
| 8 | Frissítse a SoA-t és a kockázatkezelési tervet | A kockázati forgatókönyv összekapcsolása az 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 és beszállítói kontrollokkal |
| 9 | Döntse el, szükséges-e DPIA | DPIA vagy dokumentált indokolás a magas kockázatú adatkezelési döntésekhez |
| 10 | Rögzítse a tanulságokat | Frissített képzés, biztonságos fejlesztési szabályok, exportkontrollok, DLP-felügyelet és tesztadat-útmutatás |
Az Audit- és megfelelésfelügyeleti szabályzat Audit- és megfelelésfelügyeleti szabályzat – KKV kimondja:
„Minden bizonyító anyagot központi auditmappában kell tárolni.”
„A szabályzat végrehajtásának követelményei” szakasz 6.2.1 szabályzati pontjából.
Az Információbiztonsági szabályzat Információbiztonsági szabályzat egyértelművé teszi a szélesebb auditelvárást:
„Minden bevezetett kontrollnak auditálhatónak kell lennie, dokumentált eljárásokkal és a működés megőrzött bizonyító anyagaival alátámasztva.”
„A szabályzat végrehajtásának követelményei” szakasz 6.6.1 szabályzati pontjából.
Ez a két pont jelenti a különbséget aközött, hogy van kontroll, illetve hogy az bizonyítható is.
Keresztmegfelelőségi megfeleltetés egyetlen PII-kontrollkészlethez
A PII-védelem könnyebben védhető, ha még az auditor kérdései előtt több keretrendszerre is megfeleltetik.
| PII-védelmi téma | GDPR-relevancia | ISO/IEC 27001:2022, ISO/IEC 27701:2025 és ISO/IEC 29151:2022 relevancia | NIS2-relevancia | DORA-relevancia | NIST és COBIT 2019 auditnézőpont |
|---|---|---|---|---|---|
| PII-eszköznyilvántartás és adatkezelési nyilvántartás | Elszámoltathatóság, jogalap, célhoz kötöttség, korlátozott tárolhatóság | IBIR-környezet, 5.9 eszköznyilvántartás, adatvédelmi információirányítás, PII-védelem | Eszközkezelés és kockázatelemzés | IKT-eszköz- és szolgáltatásfüggőségek ismerete | Azonosítási funkcióhoz kapcsolódó bizonyítékok és az információs vagyon irányítása |
| Hozzáférési jogosultságok és legkisebb jogosultság elve | Integritás és bizalmas jelleg, szerepkör szerinti hozzáféréskorlátozás | 5.15 hozzáférés-szabályozás, 5.16 identitáskezelés, 5.18 hozzáférési jogosultságok, 8.2 emelt szintű hozzáférési jogosultságok | Hozzáférés-szabályozás, HR-biztonság, hitelesítés | IKT-kockázati kontrollok és emelt szintű hozzáférések felügyelete | Hozzáférés kikényszerítése, tulajdonosi felelősség, felelősségi körök és nyomon követés |
| Maszkolás és álnevesítés | Adattakarékosság, beépített adatvédelem, az adatkezelés biztonsága | 5.12 osztályozás, 5.34 PII-védelem, 8.11 adatmaszkolás, 8.33 tesztadatok | Kiberhigiénia és biztonságos fejlesztés | Biztonságos tesztelés, adatvesztés csökkentése, operatív reziliencia | Technikai védelmi intézkedések tesztelése és megbízható kontrollműködés |
| Incidensbesorolás és jelentéstétel | Személyesadat-sértés értékelése és bejelentése | Incidenstervezés, eseményértékelés, reagálás, bizonyítékgyűjtés | 24 órás korai figyelmeztetés, 72 órás bejelentés, zárójelentés | Jelentős IKT-vonatkozású incidensek besorolása és jelentése | Eszkalációs kritériumok, döntési naplók, gyökérok, helyesbítő intézkedés |
| Beszállítói és felhőalapú adatkezelés | Adatfeldolgozói kötelezettségek, adattovábbítások, szerződések | 5.21 IKT-ellátási lánc, 5.23 felhőszolgáltatások, 5.31 jogi és szerződéses követelmények | Ellátási lánc biztonsága | IKT harmadik fél kockázat, auditálási jog, kilépés és átállás | Harmadik fél irányítás, bizonyosság és vezetői elszámoltathatóság |
Itt különösen hasznos a Zenith Controls. Az 5.34 esetében a PII-védelmet az eszköznyilvántartáshoz, az adatmaszkoláshoz és a felhőirányításhoz kapcsolja. A 8.11 esetében a maszkolást az osztályozáshoz, az adatvédelemhez és a tesztadatokhoz. Az 5.18 esetében a hozzáférési jogosultságokat a hozzáférés-szabályozáshoz, az identitáskezeléshez és az emelt szintű hozzáféréshez. Ezek a kapcsolatok lehetővé teszik, hogy a csapat ne csak azt magyarázza el, hogy létezik egy kontroll, hanem azt is, miért létezik, és mely kapcsolódó kontrolloknak kell vele együtt működniük.
Hogyan tesztelik különböző auditorok ugyanazt a PII-kontrollt?
Egyetlen kontrollt, például a 8.11 adatmaszkolást, az auditnézőponttól függően eltérően vizsgálnak.
| Auditor típusa | Elsődleges fókusz | Elvárt bizonyíték |
|---|---|---|
| ISO/IEC 27001:2022 és ISO/IEC 27701:2025 auditor | IBIR- és PIMS-integráció, kockázatkezelés, SoA pontossága | Kockázatértékelés, SoA-bejegyzés, maszkolási szabályzat, változásnyilvántartások, belső audit eredményei |
| GDPR- vagy adatvédelmi hatósági felülvizsgáló | Beépített adatvédelem, adattakarékosság, elszámoltathatóság | Adatkezelési nyilvántartás, jogalap, DPIA, álnevesítési bizonyítékok, megőrzési logika |
| NIS2-értékelő | Biztonságos fejlesztés, incidensmegelőzés, irányítás | Biztonságos fejlesztési eljárás, fejlesztői képzés, incidenskorrekciós bizonyíték, kontrollhatékonysági felülvizsgálat |
| DORA-ügyfél vagy auditor | IKT operatív reziliencia és harmadik fél kockázat | Kritikus alkalmazástesztelési bizonyíték, beszállítói szerződéses záradékok, incidens-támogatási kötelezettségek, helyreállítási és kilépési tervezés |
| NIST-jellegű vagy COBIT 2019 felülvizsgáló | Kontrollterv, működés, tulajdonosi felelősség, nyomon követés | Kontrollgazda, mutatók, bizonyítéktár, vezetői jelentéstétel, helyesbítő intézkedések |
Egy ISO/IEC 27001:2022 auditor az irányítási rendszer logikájával kezd. A PII a hatályon belül van? Azonosították az érdekelt felek követelményeit? Az adatvédelmi kockázatokat meghatározott kritériumok alapján értékelik? A kontrollokat kockázatkezelés útján választják ki? Pontos a SoA? A belső auditok és a vezetőségi átvizsgálások lefedik a PII-hez kapcsolódó kontrollokat?
Egy adatvédelmi felülvizsgáló az elszámoltathatósággal kezd. Milyen személyes adatokat kezelnek? Mi a jogalap? Tájékoztatták az érintetteket? Az adatkezelés meghatározott célra korlátozódik? Értékelték a magas kockázatú tevékenységeket? Az adatfeldolgozók irányítás alatt állnak?
Egy NIS2-fókuszú értékelő az irányítással és a kiberbiztonsági kockázatkezeléssel kezd. A vezetés jóváhagyja és felügyeli az intézkedéseket? Integrált az incidenskezelés, a folytonosság, a beszállítói biztonság, a hozzáférés-szabályozás, az eszközkezelés, a biztonságos fejlesztés és a kontrollhatékonyság értékelése?
Egy DORA-ügyfél vagy auditor azt kérdezi, hogy az IKT-kockázatkezelés dokumentált, igazgatósági irányítás alatt áll, arányos és szerződésekkel alátámasztott-e. Ha pénzügyi szervezeteket támogató szolgáltatásokban PII-t kezelnek, várhatók kérdések az incidensek támogatásáról, az adatkezelési helyszínekről, a helyreállításról, az auditálási jogokról, a szolgáltatási szintekről, a megszüntetésről és a kilépésről.
Egy COBIT 2019 vagy ISACA-jellegű felülvizsgáló az irányítási összhangot teszteli. Ki felel a PII-kockázatért? Mely irányítási testület kap jelentést? Kijelölték a felelősségeket? Felügyelik a beszállítókat? Nyomon követik az eltéréseket? Használnak mutatókat a döntéshozatalhoz? A maradványkockázatot formálisan elfogadták?
Egyetlen bizonyítékmodell képes kielégíteni ezeket a nézőpontokat, de csak akkor, ha a kontrollrendszert kezdettől fogva visszakövethetőségre tervezték.
Gyakori auditmegállapítások PII-védelmi programokban
Azok a szervezetek, amelyek integrált eszközkészlet nélkül készülnek az ISO/IEC 27701:2025 vagy ISO/IEC 29151:2022 szerinti felkészültségre, gyakran ugyanazokkal a megállapításokkal szembesülnek.
| Megállapítás | Miért fontos? | Clarysec helyesbítő intézkedés |
|---|---|---|
| A PII-nyilvántartás nem tartalmazza a naplókat, biztonsági mentéseket, analitikai exportokat vagy támogatási csatolmányokat | A rejtett PII nem védhető és nem törölhető megbízhatóan | Bővítse a 9. lépés szerinti eszköznyilvántartást és adatkezelési nyilvántartást minden PII-helyszínre |
| A tesztkörnyezetek éles adatokat használnak | Valódi PII kerül kitettségbe ott, ahol nincs rá szükség | Érvényesítse a maszkolási szabályzatot és a jóváhagyott átalakítási sablonokat |
| A hozzáférés-felülvizsgálatok általánosak, és nem fókuszálnak a PII-adattárakra | A túlzott hozzáférés észrevétlen marad | Térképezze fel az 5.18 hozzáférési jogosultságokat a PII-vagyonelemek tulajdonosaihoz és az időszakos felülvizsgálati bizonyítékokhoz |
| A jogalap dokumentált, de nincs rendszerekhez vagy megőrzéshez kapcsolva | A GDPR szerinti elszámoltathatóság nem igazolható | Adjon jogalap- és megőrzési mezőket az adatkezelési nyilvántartáshoz és az eszköznyilvántartáshoz |
| A beszállítói szerződésekből hiányzik az adatkezelési helyszín, az incidens-támogatás, az auditálási jog vagy a kilépési rendelkezés | DORA, NIS2 és GDPR szerinti beszállítói bizonyossági hiányosságok maradnak fenn | Hangolja össze a beszállítói átvilágítást és szerződéseket az IKT harmadik fél és felhőirányítási követelményekkel |
| Az incidens-forgatókönyvek nem különböztetik meg a biztonsági incidenseket a személyesadat-sértésektől | A jelentési határidők elmulaszthatók | Építsen besorolási fákat a GDPR, NIS2 és DORA szerinti jelentési kiváltó okokhoz |
| A bizonyítékok jegyekben, meghajtókon, képernyőképekben és e-mailekben szóródnak szét | Az auditkészség akkor is sérül, ha a kontrollok működnek | Használjon központi auditmappákat és bizonyítékelnevezési szabványokat |
Ezek a megállapítások nem adminisztratív papírproblémák. Működésimodell-problémák. Az ISO/IEC 27701:2025 és az ISO/IEC 29151:2022 nem fogja ezeket kijavítani, ha az adatvédelmi irányítás, a biztonsági kontrollok és a bizonyítékkezelés nem épül be a normál munkafolyamatokba.
Mit kérdezzen a vezetés a következő audit előtt?
Mielőtt a szervezet ISO/IEC 27701:2025 szerinti felkészültségre, ISO/IEC 29151:2022 bevezetésre vagy GDPR, NIS2, illetve DORA ügyfélértékelésre készül, a vezetésnek tíz közvetlen kérdést kell feltennie:
- Rendelkezünk-e teljes nyilvántartással a PII-kezelési tevékenységekről, beleértve az adatkategóriákat, a célt, a jogalapot és a megőrzést?
- Jelölve vannak-e a PII-vagyonelemek az eszköznyilvántartásban, beleértve a naplókat, biztonsági mentéseket, exportokat, analitikai eszközöket és támogatási csatolmányokat?
- Az adatosztályozás létrehozáskor vagy nyilvántartásba vételkor megtörténik-e, és a felül nem vizsgált vagyonelemek alapértelmezetten Bizalmas besorolást kapnak-e?
- Tudjuk-e bizonyítani, hogy a PII-hez való hozzáférés a szükséges ismeret elve alapján jogosult felhasználókra korlátozódik?
- A fejlesztési, teszt- és előéles környezetek valódi személyes adatok helyett maszkolt vagy álnevesített adatokat használnak-e?
- Jóváhagyottak-e a maszkolási sablonok, és védettek, hozzáférés-szabályozottak és naplózottak-e a kulcsok?
- A SoA összekapcsolja-e a PII-kockázatokat a kontrollokkal és a szabályozási kötelezettségekkel?
- A felhő- és beszállítói szerződéseket felülvizsgálják-e adatkezelési helyszín, biztonság, incidens-támogatás, auditálási jog, helyreállítás és kilépés szempontjából?
- Incidensfolyamatunk képes-e besorolni a GDPR szerinti személyesadat-sértéseket, a NIS2 szerinti jelentős incidenseket és a DORA szerinti jelentős IKT-vonatkozású incidenseket?
- A bizonyítékokat központilag tároljuk-e és úgy őrizzük-e meg, hogy az auditor követni tudja őket?
Ha bármelyik kérdésre nem egyértelmű a válasz, a szervezet még nem áll készen az auditra.
Tegye bizonyíthatóvá a PII-védelmet
Sarah késő esti incidense széttöredezett megfelelési kapkodássá is válhatott volna. Ehelyett egy erősebb működési modell kiindulópontja lehet: egy ISO/IEC 27001:2022 szerinti IBIR, amelyet az ISO/IEC 27701:2025 adatvédelmi irányba terjeszt ki, ISO/IEC 29151:2022 gyakorlatokkal erősít meg, és GDPR, NIS2, DORA, NIST-jellegű bizonyossági és COBIT 2019 irányítási elvárásokhoz feleltet meg.
Ez az auditkész PII-védelem valódi értéke. Nem azon múlik, hogy az auditor érkezése előtt sikerül-e megtalálni a megfelelő táblázatot. Egy olyan rendszeren múlik, amely már tudja, hol van PII, miért létezik, hogyan védik, ki számoltatható el érte, mely beszállítók érintettek, és hol vannak a bizonyítékok.
Kezdje a Zenith Blueprint: Egy auditor 30 lépéses ütemterve Zenith Blueprint használatával a bevezetés strukturálásához. Használja a Zenith Controls: Keresztmegfelelőségi útmutató Zenith Controls megoldást a PII-védelem megfeleltetéséhez ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST-jellegű bizonyossági és COBIT 2019 irányítási elvárások szerint. Tegye működőképessé a munkát Clarysec szabályzatokkal, beleértve az Adatvédelmi és magánszféra-védelmi szabályzatot Adatvédelmi és magánszféra-védelmi szabályzat, az Adatmaszkolási és álnevesítési szabályzatot Adatmaszkolási és álnevesítési szabályzat, az Adatosztályozási és címkézési szabályzatot Adatosztályozási és címkézési szabályzat, az Audit- és megfelelésfelügyeleti szabályzatot Audit- és megfelelésfelügyeleti szabályzat – KKV, valamint az Információbiztonsági szabályzatot Információbiztonsági szabályzat.
Ha közeledik a következő ügyfélaudit, GDPR-felülvizsgálat, NIS2 felkészültségi projekt vagy DORA beszállítói értékelés, ne várja meg, amíg egy incidens feltárja a hiányosságokat. Töltse le a Clarysec eszközkészleteket, kérjen demót, vagy ütemezzen PII-védelmi értékelést, és építsen olyan adatvédelmi programot, amely nemcsak megfelelő, hanem igazolható is.
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
