⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

PII-irányítás ISO 27701:2025 és GDPR szerint

Igor Petreski

A kérés megtévesztően egyszerű formában érkezett az információbiztonsági vezető postaládájába: „Project Wellness”. Egy gyorsan növekvő fintech vállalat a meglévő ügyféltranzakciós adatokat szerette volna elemezni, hogy személyre szabott megtakarítási tippeket, termékajánlásokat és lemorzsolódási kockázatra vonatkozó elemzéseket nyújtson. A marketing ügyfél-elköteleződést látott benne. A termékcsapat innovációt. A felső vezetés versenyelőnyt.

Az információbiztonsági vezető irányítási aknamezőt látott.

A tranzakciós adatokat fizetésfeldolgozás céljából, meghatározott cél és jogalap mellett gyűjtötték. Az üzleti terület most pénzügyi jólléti analitikára, kampányszemélyre szabásra és prediktív pontozásra kívánta újrafelhasználni azokat. A megvalósítás felgyorsítása érdekében a csapat egy álnevesített adatkészletet is el akart küldeni egy harmadik fél mesterségesintelligencia-alapú analitikai beszállítónak.

Nem volt támadó a hálózatban. Nem szivárgott ki adatbázis. Nem villogott pirosan incidensjegy.

Mégis pontosan itt kezdődik sok GDPR szerinti elszámoltathatósági hiba.

A kérdés nem az, hogy a szervezet rendelkezik-e adatvédelmi tájékoztatóval, adatvédelmi tisztviselővel, jogalap-nyilvántartással vagy megőrzési ütemtervvel. A mélyebb kérdés működési jellegű: ki hagyja jóvá az új PII-gyűjtést, ki erősíti meg a szükségességet, ki határozza meg az engedélyezett belső felhasználást, ki dönt arról, hogy a másodlagos felhasználás összeegyeztethető-e, ki engedélyezi a beszállító felé történő adatközlést, és ki tudja később bizonyítani a döntést?

Ezt a kontrollhiányosságot kell megszüntetniük az ISO/IEC 27701:2025 szerinti adatvédelmi információmenedzsment-rendszer, azaz PIMS bevezetéseinek. A GDPR 5. cikke előírja, hogy a személyes adatokat jogszerűen, tisztességesen és átláthatóan kell kezelni; meghatározott, egyértelmű és jogszerű célokból kell gyűjteni; a szükséges mértékre kell korlátozni; pontosan kell tartani; csak a szükséges ideig lehet megőrizni; megfelelően kell védeni; és az adatkezelő elszámoltathatósága mellett kell kezelni. A GDPR 6. cikke ehhez hozzáadja a további adatkezelés jogalapra és összeegyeztethetőségre vonatkozó logikáját. Ezek az elvek azonban csak akkor válnak védhetővé, ha munkafolyamatokká, nyilvántartásokká, jóváhagyásokká, hozzáférési szabályokká, beszállítói kontrollokká, felügyeletté és bizonyítékokká fordítják le őket.

A Clarysec megközelítése egyszerű: a PII gyűjtésének, felhasználásának és közlésének irányítását szabályozott működési modellként kell kezelni, nem jogi feljegyzésként. A modell az ISO/IEC 27001:2022 ISMS gerincére épül, kiterjed az ISO/IEC 27701:2025 PIMS szerepekre, és Clarysec szabályzatokkal, nyilvántartásokkal, a Zenith Blueprint: auditori 30 lépéses ütemtervvel és a Zenith Controls: megfelelőségi keretrendszereken átívelő útmutatóval igazolható.

Miért bukik el a PII-irányítás akkor is, ha vannak adatvédelmi dokumentumok

A legtöbb adatvédelmi program nem azért bukik el, mert senki sem tud a GDPR létezéséről. Azért buknak el, mert az adatvédelmi döntések termékfejlesztési jegyekben, beszállítói beléptetési e-mailekben, táblázatexportokban, irányítópult-kísérletekben és AI-pilotprojektekben születnek meg, ismételhető kontrollkapu nélkül.

A tipikus minta ismerős:

  1. Egy csapat új mezőt ad hozzá a regisztrációs űrlaphoz, mert az javítja a szegmentálást.
  2. Senki nem rögzíti, miért szükséges pontosan az adott mező.
  3. Egy másik csapat később más célra használja fel az adatot.
  4. Egy beszállító széles körű szolgáltatási szerződés alapján exportot kap.
  5. Az adatkezelési nyilvántartás az éles indulás után frissül, ha egyáltalán frissül.
  6. Audit során a szervezet be tud mutatni adatvédelmi tájékoztatót, de döntési bizonyítékot nem.

A GDPR 4. és 5. cikke tágan határozza meg az adatkezelést. A gyűjtés, rögzítés, tárolás, felhasználás, adatközlés, törlés és megsemmisítés egyaránt ide tartozik. Az 5. cikk az elszámoltathatóságot is kifejezetté teszi. Az adatkezelőknek képesnek kell lenniük igazolni az elveknek való megfelelést.

Ez azt jelenti, hogy az auditkérdés nem csupán az: „Van szabályzatuk?” Hanem az: „Mutassa be, hogyan hagyták jóvá ezt a konkrét adatelemet, miért volt szükség rá, hogyan használták fel, ki kapta meg, és milyen kontrollok akadályozták meg a visszaélést.”

A Clarysec P17 Adatvédelmi és magánszféra-védelmi szabályzat egyértelműen meghatározza az életciklusra vonatkozó elvárást:

Formalizálja a vállalat felelősségeit a nemzetközi szabványok és szabályozási keretrendszerek alapján, biztosítva, hogy a személyes adatok (PII) gyűjtése, kezelése, megőrzése, megosztása és megsemmisítése jogszerűen, biztonságosan és átláthatóan történjen.

KKV-k számára a Clarysec Adatvédelmi és magánszféra-védelmi szabályzat – KKV ugyanezt az elvet gyakorlati működési szabállyá alakítja:

Személyes adat csak akkor gyűjthető, ha az jogszerű, legitim vagy szerződéses célhoz szükséges.

Az adattakarékosságra vonatkozóan pedig:

Csak a szükséges minimális személyes adat gyűjthető és őrizhető meg.

Ezek a kijelentések csak akkor erősek, ha az adatkezelés megkezdése előtt érvényesítik őket. Ellenkező esetben operatív bizonyíték nélküli adatvédelmi megfogalmazások maradnak.

A kontrollcél: a szabályozatlan adatkezelés megállítása három kapunál

Egy erős PIMS-nek három ponton kell kontrollálnia a PII-vel kapcsolatos döntéseket: gyűjtés előtt, felhasználás előtt és adatközlés előtt.

Gyűjtés előtt a szervezetnek tudnia kell, mit kíván gyűjteni, kitől, mely csatornán keresztül, milyen célból, milyen jogalapon, és miért szükséges az egyes mezők gyűjtése.

Felhasználás előtt a szervezetnek meg kell határoznia az engedélyezett belső felhasználási szabályokat. A támogatás, az ügyfélsiker, a marketing, a csalásmegelőzés, a pénzügy és a fejlesztés ritkán igényel azonos láthatóságot vagy azonos jogosultságot a PII alapján történő intézkedéshez.

Adatközlés előtt a szervezetnek tudnia kell, ki a címzett, milyen szerepet tölt be, miért szükséges az adatközlés, hol történik az adatkezelés, milyen PII-kategóriák kerülnek megosztásra, milyen gyakran történik a megosztás, és milyen felhatalmazás alapján engedélyezett.

A Clarysec PII09 PII gyűjtésére, felhasználására, közlésére és megosztására vonatkozó szabályzat erre az irányítási rétegre készült. PIMS szerepmegjelölést használ, különösen az adatkezelői szerepet, mert a gyűjtésre, felhasználásra és adatközlésre vonatkozó döntések jellemzően annál a szervezetnél vannak, amely meghatározza a célokat és eszközöket.

A gyűjtés korlátozására a PII09 PII gyűjtésére, felhasználására, közlésére és megosztására vonatkozó szabályzat előírja:

[Adatkezelő] A folyamatgazda/üzleti felelős köteles rögzíteni a gyűjtés célját, forrását vagy csatornáját, a PII-kategóriákat, az érintetti kategóriákat és a minimális adatelemeket a REG02-ben, mielőtt bármely új gyűjtési tevékenység vagy lényeges gyűjtési változás megkezdődik.

Ezután ellenőrizhetővé teszi az adattakarékosságot:

[Adatkezelő] A folyamatgazda/üzleti felelős köteles minden PII-adatelemre vonatkozóan szükségességi indokolást rögzíteni a REG02-ben, mielőtt az adott elemet gyűjtik.

A „minden PII-adatelemre” vonatkozó követelmény jelenti a különbséget az általános adatkezelési tevékenységek nyilvántartása és a mezőszintű elszámoltathatósági bizonyíték között.

A belső felhasználásra ugyanez a szabályzat előírja:

[Adatkezelő] A folyamatgazda/üzleti felelős köteles minden adatkezelési tevékenységhez jóváhagyott belső felhasználási szabályokat rögzíteni a REG02-ben, mielőtt a felhasználás megkezdődik.

A másodlagos felhasználásra:

[Adatkezelő] A folyamatgazda/üzleti felelős köteles másodlagos felhasználásra vonatkozó összeegyeztethetőségi vizsgálatot rögzíteni a REG02-ben, mielőtt a PII-t olyan célra használják fel, amelyet az adott adatkezelési tevékenységhez korábban nem hagytak jóvá.

A külső adatközlésre pedig:

[Adatkezelő] A beszállítói/beszerzési felelős köteles rögzíteni a címzett azonosítóját, a címzett szerepét, az adatközlés célját, a PII-kategóriákat, a megosztás gyakoriságát, az adatkezelés helyét és a felhatalmazás forrását a REG08-ban, mielőtt a rendszeres külső megosztás megkezdődik.

Ezek a pontok egyértelmű választ adnak, amikor a felső vezetés azt kérdezi, hogy az üzlet gyorsan tud-e innoválni: igen, ha a döntés dokumentált irányítási munkafolyamaton megy keresztül, és a kontrollok megfelelnek a jóváhagyásnak.

REG02 és REG08: a Clarysec szabályzattól kontrollig tartó lánca

A Clarysec bevezetésekben a REG02 nem passzív adatkezelési tevékenységi nyilvántartás. Ez a gyűjtési cél, a jogalap, a PII-kategóriák, a szükségesség, a belső felhasználási szabályok, a megőrzéssel való összhang és a másodlagos felhasználás összeegyeztethetőségének döntési nyilvántartása.

A REG08 az adatközlési és adatmegosztási kontrollnyilvántartás. Különösen fontos beszállítók, partnerek, vállalatcsoporton belüli társaságok, hatóságok, al-adatfeldolgozók, integrációk és rendszeres exportok esetén.

Együttesen olyan szabályzattól kontrollig tartó láncot hoznak létre, amelyet az adatvédelmi, biztonsági, beszerzési és auditcsapatok tesztelni tudnak.

Irányítási kérdésBizonyítékClarysec szabályzati kiváltó okGyakorlati kontrolleredmény
Milyen PII-t gyűjtünk?REG02 adatkezelési bejegyzésPII09 4.1.1 pontA gyűjtés az éles indulás előtt meghatározott
Miért szükséges minden mező?REG02 adatelem-szintű szükségességi indokolásPII09 4.1.3 pontAz adattakarékosság bizonyított
Hogyan használhatják a csapatok a PII-t?REG02 belső felhasználási szabályokPII09 4.2.1 pontA hozzáférés és a felhasználás célhoz kötött
Új célra újrafelhasználhatjuk a PII-t?REG02 összeegyeztethetőségi vizsgálatPII09 4.3.1 pontA másodlagos felhasználás jóváhagyott, feltételekhez kötött vagy tiltott
Ki kap PII-t külső félként?REG08 adatközlési bejegyzésPII09 4.4.2 pontAz adatközlés visszakövethető és engedélyezett
A beszállítók a szükséges ismeret elve alapján korlátozottak?Beszállítói hozzáférési felülvizsgálatHarmadik félre vonatkozó szabályzat 6.2.1 pontA beszállítói hozzáférés minimálisra korlátozott

Ez a modell természetesen illeszkedik az ISO/IEC 27001:2022 szabványhoz. A 4–10. pontok megkövetelik, hogy a szervezet értse a kontextust, az érdekelt felek követelményeit, a hatályt, a vezetői felelősségeket, a kockázatértékelést, a kockázatkezelést, az operatív kontrollt, a teljesítményértékelést és a fejlesztést. A GDPR és az ISO/IEC 27701:2025 szerinti adatvédelmi kötelezettségek így az irányítási rendszer részévé válnak, nem külön adatvédelmi szigetként működnek.

Az ISO/IEC 27002:2022 szintén támogatja a működési modellt. Az 5.31 Jogi, jogszabályi, szabályozói és szerződéses követelmények kontroll a GDPR és az ágazati kötelezettségek alapja. Az 5.34 Adatvédelem és a PII védelme kontroll az adatvédelem-specifikus védelmet kezeli. Az 5.9 Információk és kapcsolódó vagyonelemek leltára kontroll az adatvagyon átláthatóságát támogatja. Az 5.12 és 5.13 kontroll az osztályozást és a jelölést támogatja. Az 5.14 kontroll az információátadást szabályozza. Az 5.19–5.23 kontrollok a beszállítói kapcsolatokat, beszállítói megállapodásokat, IKT-ellátási láncot, beszállítói szolgáltatások felügyeletét és felhőszolgáltatásokat fedik le. A 8.11 kontroll az adatmaszkolást, a 8.12 az adatszivárgás-megelőzést, a 8.15 a naplózást, a 8.16 a felügyeleti tevékenységeket, a 8.24 pedig a kriptográfia használatát támogatja.

A Zenith Blueprint ezeket a kontrollokat bevezetési útvonalba rendezi. A „Kontrollok működésben” szakaszban a 23. lépés az 5.19–5.37 szervezeti kontrollokat fedi le, beleértve az 5.34 kontrollt a PII adatvédelmére és védelmére. A Blueprint így fogalmaz:

A mai adatvezérelt világban a személyazonosításra alkalmas információ nem csupán egy újabb adattípus, hanem a bizalom rendkívül érzékeny leképezése. Nevek, címek, azonosítók, egészségügyi nyilvántartások, pénzügyi adatok – ezek az adatok valós emberekről szólnak.

Ezután megadja a működési alapot:

Ennek a kontrollnak az alapja az adatok ismerete. A szervezetnek tudnia kell, milyen PII-t gyűjt, hol található, miért kezelik, és ki férhet hozzá.

Ezt biztosítja a REG02 és a REG08, ha élő irányítási nyilvántartásként kezelik őket.

Gyakorlati példa: a Project Wellness jóváhagyása kontrollvesztés nélkül

Térjünk vissza a fintech forgatókönyvhöz. Az üzlet személyre szabott pénzügyi jólléti ajánlások céljából szeretné elemezni az ügyféltranzakciós adatokat. A marketing kampányokhoz kívánja használni az eredményeket. A termékcsapat lemorzsolódási és elköteleződési pontszámokat akar kialakítani. Egy harmadik fél AI-analitikai platform az adatkészlet egy részét fogja kezelni.

A Clarysec így irányítaná a kérelmet.

1. lépés: A REG02 adatkezelési tevékenység létrehozása vagy frissítése

A folyamatgazda megnyitja a REG02-t, és a munka megkezdése előtt rögzíti az adatkezelési tevékenységet.

REG02 mezőProject Wellness példa
Adatkezelési tevékenységPénzügyi jólléti analitika és ajánlási funkció
Elsődleges célSzemélyre szabott megtakarítási elemzések és termékirányítás nyújtása az ügyfeleknek
Érintetti kategóriákLakossági ügyfelek, számlatulajdonosok, meghatalmazott felhasználók
PII-kategóriákTranzakciókategória, tranzakcióösszeg, tranzakciódátum, számlaállapot, termékportfólió
Forrás vagy csatornaFizetési platform, ügyfélszámla-nyilvántartások, termékhasználati rendszerek
JogalapAdatvédelmi jogtanácsos vagy adatvédelmi felelős határozza meg az adatkezelői kontextus alapján
MegőrzésA jóváhagyott megőrzési ütemtervhez kapcsolódik
Belső felhasználási szabályokA termékcsapat aggregált elemzéseket használhat; a marketinghez másodlagos felhasználási jóváhagyás szükséges; a fejlesztésnek maszkolt adatkészleteket kell használnia

A lényeg az időzítés. A REG02 frissítése az új adatkezelés megkezdése előtt történik, nem azután, hogy a funkció már élesben működik.

2. lépés: Mezőszintű szükségességi indokolások rögzítése

A marketing kezdetben öt év teljes tranzakciós előzményt kér, beleértve a kereskedőneveket, pontos időbélyegeket, kártyametaadatokat és ügyfélprofil-attribútumokat. Az irányítási csapat minden mezőt megkérdőjelez.

PII-elemSzükségességi indokolásDöntés
TranzakciókategóriaSzükséges a költési minták azonosításához a megtakarítási tippekhezJóváhagyva
TranzakcióösszegSzükséges a trendtartományok és az ajánlási relevancia kiszámításáhozAggregálási küszöbértékekkel jóváhagyva
TranzakciódátumSzükséges a trendelemzéshezLehetőség szerint havi szinten jóváhagyva
Kereskedő neveAz első kiadáshoz nem szükséges, és növeli az újraazonosítási kockázatotElutasítva
Pontos időbélyegPénzügyi jólléti ajánlásokhoz nem szükségesElutasítva
Ügyfél e-mail-címeCsak fiókhoz rendeléshez szükséges, modelltréninghez nemKorlátozva
TermékportfólióSzükséges az irreleváns ajánlások elkerüléséhezHozzáférési korlátozásokkal jóváhagyva

Ez az adattakarékosság bizonyítékként, nem törekvésként. Az üzlet továbbra is hasznos analitikát kap, de az adatkészlet az elfogadott célhoz szükséges adatokra szűkül.

3. lépés: Az adatkészlet osztályozása és címkézése

Az adatkészletet a Clarysec Adatosztályozási és címkézési szabályzat alapján kell osztályozni. A KKV-verzió előírja:

A külső megosztást kifejezetten engedélyezni és naplózni kell.

A vállalati Adatosztályozási és címkézési szabályzat további védelmi intézkedést ír elő az érzékeny információkra:

Külső féllel csak titoktartási megállapodás vagy azzal egyenértékű szerződéses védelmi intézkedések mellett osztható meg.

A gyakorlatban a Project Wellness adatkészlet nem exportálható alkalomszerűen egy AI-platformra. Jóváhagyott adatközlési bejegyzésre, szerződéses védelmi intézkedésekre, technikai átviteli kontrollokra és naplókra van szükség.

A Zenith Blueprint az 5.12 Információk osztályozása kontrollhoz kapcsolódó 22. lépésben elmagyarázza, miért fontos ez:

Minden valaha megírt információbiztonsági kontroll – hozzáféréskorlátozás, titkosítás, biztonsági mentés, felügyelet vagy megsemmisítés – egyetlen dolgot feltételez: hogy a szervezet tudja, mit véd.

Osztályozás nélkül a hozzáféréskorlátozások, a titkosítás, a DLP és a megőrzési szabályok találgatássá válnak.

4. lépés: Belső felhasználási szabályok meghatározása az éles kiadás előtt

A folyamatgazda jóváhagyott belső felhasználási szabályokat rögzít a REG02-ben. Itt állítható meg gyakran a célok ellenőrizetlen bővülése.

Egy védhető szabálykészlet például így rendelkezhet:

  • A termékcsapat aggregált ajánlási teljesítménymutatókat használhat.
  • Az ügyféltámogatás láthatja, hogy egy ügyfélnek megjelent-e ajánlás, amikor támogatási kérelmet kezel.
  • A marketing nem használhat egyéni szintű jólléti pontszámokat kampányszegmentáláshoz, kivéve, ha a másodlagos felhasználásra vonatkozó összeegyeztethetőségi vizsgálat lezárult.
  • A pénzügy nem férhet hozzá részletes jólléti analitikához, kivéve, ha külön jóváhagyott cél áll fenn.
  • A fejlesztők nem használhatnak éles PII-t tesztkörnyezetekben.
  • Az AI-modellértékeléshez lehetőség szerint maszkolt, álnevesített vagy aggregált adatkészleteket kell használni.

Az utolsó két szabály az ISO/IEC 27002:2022 8.11 Adatmaszkolás kontrollhoz kapcsolódik. A Zenith Blueprint 19. lépése az adatmaszkolást gyakorlati módszerként írja le a szükségtelen kitettség megelőzésére tesztkörnyezetekben, képzési adatkészletekben, analitikai platformokon, harmadik fél integrációkban és CI/CD tesztfolyamatokban.

5. lépés: A másodlagos felhasználás összeegyeztethetőségi vizsgálatának elvégzése

A marketing később azt kéri, hogy a jólléti pontszámokat célzott kampányokhoz használhassa. Ez új cél. A PII09 PII gyűjtésére, felhasználására, közlésére és megosztására vonatkozó szabályzat 4.3.1 pontja alapján az üzleti felelősnek összeegyeztethetőségi vizsgálatot kell rögzítenie a REG02-ben, mielőtt az új felhasználás megkezdődik.

A vizsgálatnak értékelnie kell:

  • Összeegyeztethető-e a pénzügyi jólléti marketing az eredeti adatkezelési céllal.
  • Mit közöltek az ügyfelekkel a gyűjtéskor és az adatvédelmi tájékoztatóban.
  • Lehetnek-e a tranzakciókból származtatott következtetések érzékenyek vagy váratlanok.
  • Okozhat-e az új felhasználás nyomást, kizárást vagy tisztességtelen profilalkotást.
  • Csökkentik-e a kockázatot olyan védelmi intézkedések, mint az aggregálás, a leiratkozás, az álnevesítés vagy a fiókszintű szegmentálás.
  • Továbbra is érvényes-e a jogalap.
  • Szükséges-e az átlátható tájékoztatás frissítése vagy hozzájárulási mechanizmus bevezetése.

Az eredmény lehet jóváhagyás, védelmi intézkedésekhez kötött jóváhagyás vagy elutasítás. Az érték abban áll, hogy a döntés a felhasználás megkezdése előtt dokumentált.

6. lépés: Külső adatközlés jóváhagyása a REG08-on keresztül

Ha az AI-analitikai beszállító adatot kap, a beszállítói vagy beszerzési felelős a REG08-ban rögzíti:

REG08 mezőSzükséges döntési bizonyíték
Címzett azonosítójaJogi személy neve, szolgáltatásgazda és beszállítói kapcsolattartó
Címzett szerepeAdatfeldolgozó, al-adatfeldolgozó, önálló adatkezelő vagy közös adatkezelő
Adatközlés céljaA Project Wellnesshez kapcsolódó meghatározott analitikai cél
PII-kategóriákCsak jóváhagyott mezők, az elutasított adatelemek kizárásával
Megosztás gyakoriságaEgyszeri továbbítás, kötegelt gyakoriság vagy API-adatfolyam
Adatkezelés helyeOrszágok és hosztolási régiók
Felhatalmazás forrásaSzerződés, adatfeldolgozási szerződés, dokumentált utasítás vagy más jóváhagyott alap
Biztonsági követelményekTitkosítás, hozzáféréskorlátozás, naplózás, törlés és incidensbejelentés
Kilépési követelményekVisszaszolgáltatás, törlés, átállási támogatás és auditbizonyíték

A Clarysec Harmadik felekre és beszállítói biztonságra vonatkozó szabályzat – KKV megerősíti a beszállítói hozzáférés minimalizálását:

A beszállítók csak azokhoz a minimálisan szükséges rendszerekhez és adatokhoz kaphatnak hozzáférést, amelyek a feladatuk ellátásához szükségesek.

Ez az adatvédelmi adattakarékosság alkalmazása a beszállítói hozzáférésre és adatközlésre.

7. lépés: Technikai kikényszerítés hozzáadása

Az irányítási nyilvántartásokat technikai kontrollokkal kell alátámasztani. A Project Wellness esetében a Clarysec jellemzően DLP-szabályokat javasol exportokra, szerepköralapú hozzáféréskorlátozásokat, hozzáférési és átviteli események naplózását, maszkolt adatkészleteket fejlesztéshez, titkosítást átvitelhez és tároláshoz, beszállítói hozzáférés-felülvizsgálatokat, felhőbiztonsági átvilágítást, valamint a REG02 és REG08 időszakos mintavételes összevetését a tényleges rendszerműködéssel.

Így válik az ISO/IEC 27701:2025 és a GDPR szerinti elszámoltathatóság operatív bizonyítékká.

Kontrollmegfeleltetés: az adatvédelmi döntéstől a biztonsági kikényszerítésig

A PII-irányítás nem egyetlen elszigetelt kontroll. Az adatvédelmi követelmények, biztonsági kontrollok, beszállítói irányítás és auditbizonyíték közötti kapcsolat.

A Zenith Controls az ISO/IEC 27002:2022 5.34 Adatvédelem és a PII védelme kontrollt megelőző kontrollként kezeli, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást, az Identify és Protect kiberbiztonsági koncepciókkal, valamint az információvédelemhez, továbbá a jogi és megfelelési területhez kapcsolódó működési képességekkel.

Az 5.34 kontrollhoz a Zenith Controls feltérképezi a kapcsolódó kontroll-ökoszisztémát, beleértve a nyilvántartást, osztályozást, továbbítást, hozzáférést, identitást, felhőt, beszállítói biztonságot, maszkolást, adatszivárgás-megelőzést, naplózást, felügyeletet és kriptográfiát.

ISO/IEC 27002:2022 kontrollKontroll neveMiért fontos a PII-irányítás szempontjából
5.9Információk és kapcsolódó vagyonelemek leltáraA PII-állományokat ismerni kell, mielőtt védeni lehet őket
5.12Információk osztályozásaA PII-t érzékenység és kezelési követelmények szerint kell osztályozni
5.13Információk címkézéseA címkék segítik a kezelési, megosztási és megőrzési szabályok érvényesítését
5.14InformációtovábbításA PII mozgásának engedélyezettnek, védettnek és visszakövethetőnek kell lennie
5.15Hozzáférés-szabályozásA PII-hozzáférést jóváhagyott szerepekre és célokra kell korlátozni
5.16IdentitáskezelésA PII-hez hozzáférő felhasználókat és szolgáltatásidentitásokat irányítás alá kell vonni
5.19Információbiztonság a beszállítói kapcsolatokbanA beszállítói PII-kockázatot azonosítani és kontrollálni kell
5.20Információbiztonság kezelése a beszállítói megállapodásokbanA szerződéseknek biztonsági és adatvédelmi követelményeket kell tartalmazniuk
5.21Információbiztonság kezelése az IKT-ellátási láncbanA downstream IKT- és al-adatfeldolgozói kockázatokat kezelni kell
5.22Beszállítói szolgáltatások felügyelete, felülvizsgálata és változáskezeléseA beszállítói szolgáltatásokat felül kell vizsgálni, a változásokat pedig értékelni kell
5.23Információbiztonság felhőszolgáltatások használatáhozA SaaS- és felhőalapú PII-adatkezelést irányítás alá kell vonni
5.31Jogi, jogszabályi, szabályozói és szerződéses követelményekA GDPR, DORA, NIS2 és ügyfélkötelezettségeket azonosítani kell
5.34Adatvédelem és a PII védelmeA PII védelmét az adatvédelmi követelmények szerint kell megvalósítani
8.11AdatmaszkolásA valós PII-t el kell rejteni ott, ahol a teljes adat nem szükséges
8.12Adatszivárgás-megelőzésA jogosulatlan PII-mozgást észlelni és megakadályozni kell
8.15NaplózásA hozzáféréseket, változásokat és továbbításokat bizonyítékokkal kell alátámasztani
8.16Felügyeleti tevékenységekA gyanús vagy jogosulatlan tevékenységet észlelni kell
8.24Kriptográfia használataA PII-t szükség szerint tárolás és továbbítás során védeni kell

A maszkolásról a Zenith Controls így fogalmaz:

Az adatmaszkolás (8.11) olyan technika, amelyet gyakran használnak a PII védelmére nem éles környezetekben vagy adatmegosztáskor. Közvetlenül támogatja az 5.34 kontrollt azáltal, hogy csökkenti a valós személyes adatok kitettségét, ezáltal mérsékli az adatvédelmi kockázatot.

Az adatszivárgás-megelőzésről az útmutató a gyakorlati határt magyarázza:

A DLP közvetlen szerepet játszik a személyes adatok védelmében. A 8.12 kontroll korlátokat érvényesít arra vonatkozóan, hogyan lehet a PII-hez hozzáférni, azt megosztani vagy mozgatni, biztosítva, hogy a személyes adatok jogosulatlan csatornákon keresztül ne szivároghassanak ki.

Az adatközlési irányítást tesztelő auditor ezért nemcsak a REG08-at kérheti, hanem DLP-szabályzatokat, blokkolt továbbítási naplókat, kimenő e-mail kontrollokat, felhőmegosztási korlátozásokat, titkosítási követelményeket, beszállítói hozzáférési nyilvántartásokat és jóváhagyott kivételek bizonyítékait is.

Megfelelőségi keretrendszereken átívelő érték: GDPR, ISO 27701, NIS2, DORA, NIST és COBIT

A PII gyűjtésének, felhasználásának és közlésének irányítása adatvédelem-vezérelt, de bizonyítékai szélesebb kiberbiztonsági, reziliencia- és irányítási kötelezettségeket is támogatnak.

A GDPR 2. és 3. cikke széles tárgyi és területi hatályt határoz meg, amely az EU-n kívüli SaaS-, fintech- és digitális szolgáltatókra is kiterjedhet, ha EU-s érintetteket szolgálnak ki vagy figyelnek meg. Az 5. cikk célhoz kötöttséget, adattakarékosságot, pontosságot, tárolási korlátozást, sértetlenséget, bizalmasságot és elszámoltathatóságot ír elő. A 6. cikk jogalapot és összeegyeztethetőségi értékelést követel meg a további adatkezeléshez. A 9. cikk szigorúbb feltételeket ad a különleges kategóriájú személyes adatokra, ami releváns profilalkotás, egészséghez kapcsolódó adatok, biometrikus beléptetés vagy érzékeny attribútumok esetén.

A NIS2 21. cikke megköveteli, hogy az alapvető és fontos szervezetek arányos technikai, operatív és szervezeti kockázatkezelési intézkedéseket vezessenek be. Minimális területei közé tartozik a kockázatelemzés, az információs rendszerek biztonsági szabályzatai, az incidenskezelés, az üzletmenet-folytonosság, az ellátási lánc biztonsága, a biztonságos fejlesztés, a kontrollhatékonyság, a képzés, a kriptográfia, a humánerőforrás-biztonság, a hozzáférés-szabályozás, az eszközkezelés és a hitelesítés.

A DORA megköveteli, hogy a pénzügyi szervezetek IKT-kockázatkezelési keretrendszert, vezető testületi elszámoltathatóságot, IKT-eszközök és függőségek azonosítását, védelmi és megelőző kontrollokat, észlelést, reagálást, helyreállítást, biztonsági mentést, tanulást, incidenskezelést, tesztelést és IKT harmadik fél kockázatkezelést tartsanak fenn. Megköveteli továbbá az IKT-szolgáltatási szerződésekre vonatkozó információs nyilvántartásokat, a kellő gondosságot, az auditálási jogokat, a biztonsági követelményeket és a kilépési stratégiákat.

A NIST Cybersecurity Framework 2.0 integráló irányítási nyelvet ad. GOVERN funkciója elvárja, hogy a jogi, szabályozási és szerződéses követelményeket, beleértve az adatvédelmi kötelezettségeket is, megértsék és kezeljék. Lefedi továbbá a kockázati stratégiát, szerepeket, szabályzatokat, felügyeletet és beszállítói kockázatkezelést.

A COBIT 2019 auditorai irányítási célkitűzéseket, döntési jogosultságokat, elszámoltathatóságot, folyamatgazdai felelősséget, teljesítménymutatókat és bizonyossági bizonyítékokat keresnek. A PII-irányításnál ez azt jelenti, hogy az adatvédelmi követelményeket be kell építeni a vállalatirányításba, nem mellékfolyamatként kell kezelni őket.

Keretrendszer vagy rezsimMit vár elClarysec bizonyíték, amely segít
ISO/IEC 27701:2025 PIMSSzerepalapú adatvédelmi irányítás adatkezelői és adatfeldolgozói kötelezettségekhezPII09 pontok, REG02, REG08, adatvédelmi szerepek, összeegyeztethetőségi vizsgálatok
GDPRCélhoz kötöttség, adattakarékosság, jogalap, elszámoltathatóság és biztonságos adatkezelésSzükségességi indokolások, belső felhasználási szabályok, adatközlési jóváhagyások, DLP, hozzáférési naplók
ISO/IEC 27001:2022 és ISO/IEC 27002:2022Kockázatalapú ISMS-kontrollok PII-re, beszállítókra, továbbításokra, hozzáférésre, maszkolásra és felügyeletreAlkalmazhatósági nyilatkozat, kockázatkezelési terv, 5.34, 5.12, 5.14, 8.11, 8.12
NIS2Operatív és szervezeti kiberbiztonsági kockázatkezelési intézkedések, beszállítói biztonság és vezetői elszámoltathatóságEszköznyilvántartás, beszállítói kontrollok, incidens- és felügyeleti kontrollok, igazgatósági jelentés
DORAIKT-kockázatkezelés, adatvédelem, harmadik fél kockázat, rezilienciatesztelés és auditálási jogBeszállítói nyilvántartások, szerződéses záradékok, hozzáférés-szabályozás, tesztelési bizonyítékok, adatközlési naplók
NIST CSF 2.0Irányítás, jogi követelmények, kockázatkezelés és adatvédelmi eredményekAktuális profil, célprofil, szabályzat-megfeleltetés, kockázati nyilvántartás, kontrollintézkedési terv
COBIT 2019Irányítási elszámoltathatóság, folyamatgazdai felelősség, bizonyosság és teljesítményfelügyeletRACI, kontroll-KPI-k, auditminták, vezetőségi felülvizsgálati jegyzőkönyvek, kivételkövetés

Hogyan tesztelik az auditorok ugyanazt az irányítási réteget

Egy erős PIMS-bevezetésnek különböző auditmegközelítéseket is ki kell állnia.

Egy ISO/IEC 27001:2022 és ISO/IEC 27701:2025 auditor a hatállyal, az érdekelt felekkel, a jogi és szerződéses követelményekkel, a kockázatértékeléssel, az alkalmazhatósági nyilatkozattal, az operatív tervezéssel és a dokumentált bizonyítékokkal kezdi. Mintát vehet a REG02 adatkezelési tevékenységeiből, és tesztelheti, hogy az 5.34, 5.12, 5.14, 5.19–5.23, 8.11, 8.12, 8.15, 8.16 és 8.24 kontrollok be vannak-e vezetve és felügyelet alatt állnak-e.

Egy GDPR-központú auditor vagy szabályozó hatóság az elszámoltathatóságot teszteli. Kiindulhat adatvédelmi tájékoztatóból, panaszbeadványból, érintetti kérelemből vagy beszállítói adatközlésből, majd visszafelé követi a nyomot. Miért gyűjtötték ezt az adatot? Milyen jogalap alkalmazandó? Meg volt határozva a cél? Összeegyeztethető volt a későbbi felhasználás? Engedélyezett volt a címzett? Tájékoztatták az érintetteket? Frissítették a nyilvántartásokat az adatkezelés megkezdése előtt?

A DORA-felügyelet – ahol alkalmazandó – az IKT által támogatott üzleti funkciókra, harmadik fél IKT-szolgáltatókra, szerződéses záradékokra, auditálási jogokra, adatvédelemre, incidenskommunikációra, rezilienciatesztelésre és kilépési tervezésre összpontosít. Ha ügyfél-PII kerül megosztásra kritikus analitikai vagy felhőszolgáltatóval, a REG08, a beszállítói átvilágítás és a szerződéses kontrollok központi bizonyítékká válnak.

Egy NIST CSF értékelő az ügyet irányítási eredményeken keresztül keretezi. Kezelik-e a jogi és szabályozási követelményeket? Egyértelműek-e a szerepek és felelősségek? Karbantartják és alkalmazzák-e a szabályzatokat? Irányítás alatt vannak-e a beszállítói kockázatok? Működnek-e az adatvédelmi, felügyeleti és reagálási eredmények?

Egy COBIT- vagy ISACA-stílusú auditor azt kérdezi, meghatározták-e a döntési jogosultságokat, az üzleti felelősök elfogadják-e az adatvédelmi kockázatot, mérik-e a kontrollteljesítményt, követik-e a kivételeket, és kap-e a vezetés érdemi jelentést.

Auditori szerepFő fókuszterületekKövetelt bizonyítékok
ISO 27001 és ISO 27701 auditorISMS- és PIMS-integráció, kontrollhatékonyság, dokumentált bizonyítékokREG02, REG08, alkalmazhatósági nyilatkozat, kockázatkezelés, 5.34 bizonyíték, maszkolási nyilvántartások
GDPR szabályozó hatóságJogalap, célhoz kötöttség, adattakarékosság, átláthatóság, elszámoltathatóságÖsszeegyeztethetőségi vizsgálatok, szükségességi indokolások, adatvédelmi tájékoztatók, adatközlési jóváhagyások
DORA-felügyeletIKT-kockázat, harmadik fél reziliencia, igazgatósági felügyelet, szerződéses kontrollokBeszállítói átvilágítás, IKT-szerződés-nyilvántartás, auditálási jogok, kilépési terv, incidenskezelési eljárások
NIS2 értékelőKiberbiztonsági kockázati intézkedések, ellátási lánc, incidenskezelésre való felkészültség, vezetői elszámoltathatóságBeszállítói felülvizsgálatok, felügyeleti bizonyítékok, hozzáférés-szabályozás, eszköznyilvántartás, incidenskezelési forgatókönyvek
COBIT vagy ISACA auditorIrányítási érettség, szerepek, folyamatgazdai felelősség, mutatók, bizonyosságRACI, irányítási jegyzőkönyvek, KPI-k, kivételkövetés, vezetőségi felülvizsgálati feljegyzések

Gyakori buktatók, amelyeket a Clarysec a bevezetések során talál

Az első buktató az, amikor az adatkezelési tevékenységek nyilvántartását dokumentációs gyakorlatként kezelik jóváhagyási kapu helyett. Ha a REG02 az éles indulás után frissül, nem tudja bizonyítani az előzetes irányítást.

A második a homályos célmegfogalmazás. Az „analitika”, a „szolgáltatásfejlesztés” vagy az „ügyfélismeret” ritkán elég konkrét a belső felhasználás vagy a másodlagos felhasználás kontrollálásához.

A harmadik a mezőszintű szükségesség hiánya. Az adattakarékosság nem bizonyítható azzal, hogy minden mező hasznos. Az üzletnek meg kell magyaráznia, hogy az egyes mezők miért szükségesek a jóváhagyott célhoz.

A negyedik az ellenőrizetlen másodlagos felhasználás. A számlakezeléshez gyűjtött adat csendben értékesítési intelligenciává, majd marketingszegmentálássá, végül AI-tréninggé válik. Minden célváltozás összeegyeztethetőségi elemzést igényel, egyes esetekben pedig új jogalapot vagy az átlátható tájékoztatás frissítését.

Az ötödik a gyenge adatközlési irányítás. A beszállítói listák nem azonosak az adatközlési nyilvántartásokkal. A REG08 a címzettet, szerepet, célt, PII-kategóriákat, helyszínt, gyakoriságot és felhatalmazási forrást egyetlen jóváhagyási nyomvonalba kapcsolja.

A hatodik a technikai kikényszerítés hiánya. A szabályzatok kimondhatják, hogy a PII nem hagyhatja el a jóváhagyott csatornákat, de az e-mail, az exportok, a megosztott meghajtók és az analitikai eszközök ezt gyakran lehetővé teszik. Itt válnak elengedhetetlenné az ISO/IEC 27002:2022 5.14, 8.12, 8.15, 8.16 és 8.24 kontrolljai.

Gyakorlati 30 napos kezdési terv

A szervezeteknek nem kell mindent egyszerre megoldaniuk. Egyetlen magas kockázatú adatkezelési tevékenységgel érdemes kezdeni, lehetőleg olyannal, amely ügyfélprofilalkotást, AI-analitikát, érzékeny attribútumokat, határokon átnyúló adattovábbítást vagy harmadik fél platformot érint.

Az első héten azonosítsák az adatkezelési tevékenységet, a felelőst, a PII-kategóriákat, rendszereket, beszállítókat és az aktuális célt. Erősítsék meg, hogy a tevékenység már szerepel-e a REG02-ben, és az adatközlés szerepel-e a REG08-ban.

A második héten készítsék el a mezőszintű szükségességi indokolásokat. Kérdőjelezzék meg a túlzott adatelemeket. Erősítsék meg az osztályozást és a címkézést. Azonosítsák, hogy a maszkolás, aggregálás vagy álnevesítés csökkentheti-e a kockázatot.

A harmadik héten határozzák meg a belső felhasználási szabályokat, és végezzék el a szükséges másodlagos felhasználási összeegyeztethetőségi vizsgálatokat. Döntsék el, hogy szükséges-e az adatvédelmi tájékoztatók, jogalap-értékelések vagy érintetti kontrollok frissítése.

A negyedik héten ellenőrizzék a külső adatközlési nyilvántartásokat, a beszállítói hozzáférést, a szerződéses védelmi intézkedéseket, az adatfeldolgozási szerződés feltételeit, az adattovábbítási kontrollokat, a naplózást, a DLP-t és a törlési kötelezettségeket. Ezután mintavétellel vessék össze a tényleges rendszerműködést a jóváhagyásokkal.

A 30 nap végére a vezetésnek konkrét bizonyítékcsomaggal kell rendelkeznie: REG02, REG08, osztályozási nyilvántartások, hozzáférési mátrixok, DLP- és naplózási bizonyítékok, beszállítói átvilágítás, szerződéses védelmi intézkedések, összeegyeztethetőségi vizsgálatok és nyitott helyesbítő intézkedések.

A szabályzattól a bizonyítékig

A PII gyűjtésének, felhasználásának és közlésének irányítása az a pont, ahol az adatvédelem valósággá válik. Ez jelenti a különbséget aközött, hogy „megfelelünk a GDPR-nak”, és aközött, hogy bizonyítani tudjuk: minden gyűjtési, felhasználási, újrafelhasználási és adatközlési döntést az adatkezelés megkezdése előtt kontrolláltak.

A Clarysec eszközkészlete gyakorlati utat ad az adatvédelmi, biztonsági és megfelelési csapatoknak:

Ha a következő audit, ügyfélátvilágítási kérelem vagy vezető testületi felülvizsgálat azt kérdezi, hogyan kontrollálják, milyen PII-t gyűjtenek, hogyan használják fel, és mikor közlik, ne támaszkodjanak kizárólag szabályzati kijelentésekre.

Kezdjenek egy magas kockázatú tevékenységgel. Hozzák létre a REG02 bejegyzést. Indokoljanak meg minden adatelemet. Határozzák meg a belső felhasználási szabályokat. Végezzék el a másodlagos felhasználási összeegyeztethetőségi vizsgálatot. Hozzák létre a REG08 adatközlési bejegyzést. Ezután teszteljék, hogy a hozzáférés, a DLP, a maszkolás, a naplózás, a titkosítás és a beszállítói kontrollok megfelelnek-e a döntésnek.

Így válik az ISO/IEC 27701:2025 és a GDPR szerinti elszámoltathatóság bizonyítékká.

Fedezze fel a Clarysec PIMS eszközkészletet, kezdje a PII09 PII gyűjtésére, felhasználására, közlésére és megosztására vonatkozó szabályzattal, és használja a Zenith Blueprint megoldást, hogy az adatvédelmi irányítást szabályzati szándékból auditkész bizonyítékká alakítsa.

About the Author

Igor Petreski

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

Share this article