Közös adatkezelői irányítás: GDPR Article 26 szerinti auditútmutató
A hívás kedd reggel érkezett. A CareConnect, egy gyorsan növekvő egészségtechnológiai SaaS-szolgáltató CISO-ja számára ez volt az a pillanat, amikor megváltozott a helyzet.
A vonal másik végén a MetroHealth, a kiemelt kórházi partner megfelelési vezetője volt. A közösen kezelt távoli monitorozási platformot használó egyik beteg egy hónappal korábban érintetti hozzáférési kérelmet nyújtott be. Egyik szervezet sem válaszolt teljes körűen. Mindkettő úgy vélte, hogy a másik fél felelős.
Ezután a jogi osztály továbbított egy második üzenetet. A CareConnect egyik junior fejlesztője véletlenül elérhetővé tett egy nem kritikus API-végpontot, amely korlátozott betegazonosítókat tartalmazott. A probléma kezelhetőnek tűnt, és a GDPR szerinti 72 órás személyesadat-sértési bejelentési időablak még nem zárult le. Ugyanaz a kérdés azonban mindkét csapat munkáját megakasztotta.
Ki értesíti a felügyeleti hatóságot? Ki kommunikál a betegekkel? Ki felel az adatvédelmi tájékoztatóért? Ki ellenőrzi az érintetti hozzáférési kérelmet? Ki rögzíti a döntést?
A kereskedelmi megállapodás részletesen szabályozta a szolgáltatási jóváírásokat, a számlázást, a felelősségi korlátokat és a termékütemterv mérföldköveit. A GDPR Article 26 szerinti közös adatkezelői irányítás operatív működéséről azonban szinte semmit nem mondott.
Sok partnerség ezen a ponton bukik el. Nem az a probléma, hogy az adatvédelmi, jogi, biztonsági és beszerzési csapatok soha nem hallották a „közös adatkezelői megállapodás” kifejezést. A probléma az, hogy az adatkezelés megkezdése előtt senki nem tudja bizonyítani, ki felel az átláthatóságért, a jogalapért, az érintetti jogokért, az adatsértési eszkalációért, a beszállítókra továbbhárított követelményekért, az adattovábbításokért, a megőrzésért, a bizonyítékokért és a hatósági kommunikációért.
A GDPR meghatározza a kötelezettséget. Az ISO/IEC 27701:2025 irányítási rendszer szintű struktúrát ad az adatvédelmi csapatoknak. A Clarysec PIMS-szabályzatai, a Zenith Blueprint: egy auditor 30 lépéses ütemterve és a Zenith Controls: megfelelőségi keretrendszerek közötti útmutató az Article 26 követelményeit auditkész operatív bizonyítékokká alakítják.
Miért bukik el a közös adatkezelői irányítás, mielőtt bárki észrevenné
Közös adatkezelői viszony akkor áll fenn, ha két vagy több fél közösen határozza meg a személyes adatok kezelésének céljait és eszközeit. A kiváltó tényező nem a szerződés szövegezése, hanem a döntési befolyás.
A CareConnect és a MetroHealth példájában a CareConnect biztosítja a platformot, az analitikát, a műszaki architektúrát, a felhasználói felületet és az adatáramlásokat. A MetroHealth biztosítja a betegkapcsolatot, a klinikai kontextust, az ellátási modellt és a betegadatokat. Mindkét fél befolyásolja, miért történik a személyes adatok kezelése, és hogyan működik az adatkezelés. Ez lényegesen eltér attól, amikor egy beszállító pusztán adatbázist hosztol, vagy dokumentált utasítások alapján üzeneteket küld.
Ugyanez a minta jelenik meg pénzügyi jólléti kampányokban, beágyazott biztosítási partnerségekben, online piactereken, csalásészlelési konzorciumokban, összekapcsolt egészségügyi platformokon, hűségprogramokban, személyazonosság-ellenőrzési ökoszisztémákban és analitikai együttműködésekben. Egy bank, biztosító és SaaS-platform közösen dönthet célcsoportokról, profilalkotási szabályokról, konverziós mutatókról és marketingcsatornákról. Egy adatfeldolgozási szerződés ezt nem oldja meg, ha a felek ténylegesen közös adatkezelők.
A gyakorlati hibák előre láthatók:
- Az adatvédelmi tájékoztató alig mond többet annál, hogy „adatokat oszthatunk meg partnerekkel”.
- Az adatkezelési tevékenységek nyilvántartása azonosítja a feleket, de nem tartalmazza a kötelezettségek megosztását.
- Az érintetti jogokhoz kapcsolódó munkafolyamat nem tartalmaz útvonalat a kérelmek továbbítására, ellenőrzésére vagy megválaszolására.
- Az incidenskezelési terv azt mondja, hogy „értesíteni kell a jogi osztályt”, de nem jelöli meg, melyik közös adatkezelő vezeti a külső kommunikációt.
- A szerződést kereskedelmi adminisztrációnak tekintik, nem pedig elszámoltathatósági bizonyítéknak.
- A megszüntetési rendelkezések nem fedik le az adatok visszaadását, törlését, anonimizálását, a hozzáférések megszüntetését vagy a bizonyítékok megőrzését.
A GDPR Article 5 ezeket a hibákat audit szempontból érzékennyé teszi, mert az adatkezelőknek nemcsak meg kell felelniük az olyan elveknek, mint a jogszerűség, tisztességesség, átláthatóság, célhoz kötöttség, adattakarékosság, pontosság, tárolási korlátozás, integritás, bizalmas jelleg és elszámoltathatóság. A megfelelést bizonyítaniuk is tudniuk kell. Az Article 6 hozzáadja a jogalap követelményét. Az Article 3 hatály alá vonhat nem EU-s SaaS-, fintech-, egészségtechnológiai és analitikai szolgáltatókat is, ha az EU-ban tartózkodó személyeknek kínálnak szolgáltatásokat, vagy megfigyelik a viselkedésüket.
A tanulság a CISO-k és megfelelési vezetők számára egyértelmű: a közös adatkezelői irányítás nem „csak jogi kérdés”. Ez szervezeti funkciókon átívelő kontrollrendszer, amelyben részt vesz az adatvédelem, a biztonság, a beszerzés, a termékfejlesztés, a mérnöki terület, az ügyféltámogatás, az incidenskezelés, a marketing és a felső vezetői felügyelet.
Az ISO/IEC 27701:2025 PIMS alapelve: döntés az adatkezelés megkezdése előtt
Az ISO/IEC 27701:2025 szerinti adatvédelmi információkezelési rendszer csak akkor működik, ha az adatvédelmi szerepköröket az adatkezelés megkezdése előtt meghatározzák. Ez az az operatív fegyelem, amely megakadályozza, hogy az Article 26 incidens utáni rekonstrukciós gyakorlattá váljon.
A Clarysec Privacy Information Management System Policy 4.2.2 pontja kimondja:
[Közös adatkezelő] A beszállítói/beszerzési felelősnek dokumentálnia KELL a közös adatkezelői felelősségmegosztást a REG08-ban, mielőtt a közös adatkezelés megkezdődik.
A „mielőtt a közös adatkezelés megkezdődik” kifejezés a kontrollpont. Ez azt jelenti: a platformintegráció éles indulása előtt, a megosztott irányítópult engedélyezése előtt, a CRM-szinkronizálás megkezdése előtt, a kampánycélközönségek aktiválása előtt, valamint azelőtt, hogy az érintetti kérelmek beérkeznének.
A támogató nyilvántartási kötelezettség a PII Processing Inventory and Lawful Basis Policy 4.3.5 pontjában jelenik meg:
[Közös adatkezelő] A beszállítói/beszerzési felelősnek rögzítenie KELL a közös adatkezelés keretében végzett adatkezelés célját és a felelősségmegosztási hivatkozást a REG02-ben és a REG08-ban, mielőtt a közös adatkezelés keretében végzett adatkezelés megkezdődik.
Ezek a pontok együtt létrehozzák az auditorok által elvárt bizonyítékláncot:
- A REG02 rögzíti az adatkezelési tevékenységet, a célt, az adatkategóriákat, a jogalapot, a megőrzést, a rendszereket, a címzetteket, az adattovábbításokat és a közös adatkezelői hivatkozást.
- A REG08 rögzíti a közös adatkezelői megállapodást és a felelősségmegosztást.
- A REG07 rögzíti a nyilvánosan elérhető átláthatósági összefoglalót.
- A REG06 rögzítheti a joggyakorlási kérelmek beérkezését, útvonalát, ellenőrzését, határidejét és válaszbizonyítékait.
- A REG10 rögzíti az incidens- és adatsértési értékelési döntéseket.
Ez a lánc az Article 26 követelményeit jogi kijelentésből irányítási rendszer szintű folyamattá alakítja.
Kezdje a hatállyal, az érdekelt felekkel és a RACI-val
A Zenith Blueprint a hatállyal és az érdekelt felekkel kezd, mert a közös adatkezelői irányítás akkor bukik el, ha az érdekelt feleket és a követelményeket túl későn azonosítják.
Az IBIR alapozási és vezetési szakaszának 2. lépésében, az Érdekelt felek igényei és az IBIR alkalmazási területe részben a Zenith Blueprint olyan érintetti elemzést javasol, amely rögzíti a kifejezett és implicit követelményeket:
Az igények és elvárások azonosítása: Minden azonosított érintetti csoport esetében sorolja fel, hogy mit
várnak el az információbiztonsággal kapcsolatban. Egyes követelmények kifejezettek (jogszabályok, szerződések,
SLA-k), míg mások implicitek (elvárások vagy általánosan elfogadott jó gyakorlatok). Ebben segít:✓ Tekintse át az Ön környezetére alkalmazandó jogi és szabályozói követelményeket (az 1. lépésben végzett
kontextuselemzés alapján). Készítsen listát az információbiztonsághoz vagy adatvédelemhez kapcsolódó konkrét pontokról vagy kötelezettségekről.
✓ Tekintse át a szerződéseket és megállapodásokat: sok üzleti szerződés tartalmaz titoktartási vagy
biztonsági mellékleteket. Emelje ki ezekből a követelményeket.
✓ Tartson érintetti interjúkat vagy workshopokat: vonjon be képviselőket
minden csoportból (például HR-vezetőt a munkavállalói nézőpont, értékesítési vezetőt az ügyfélelvárások
megértéséhez), hogy feltárja aggályaikat vagy igényeiket.
✓ Vegye figyelembe azokat az iparági szabványokat vagy gyakorlati kódexeket, amelyek követését az érintettek elvárják.
Egy auditálható, GDPR Article 26 szerinti közös adatkezelői megállapodás esetében az érdekelt felek elemzésének ki kell terjednie az ügyfelekre, betegekre, felhasználókra, felügyeleti hatóságokra, a többi adatkezelő félre, adatfeldolgozókra, al-adatfeldolgozókra, biztosítókra, felhőszolgáltatókra, belső szervezeti egységekre, szabályozó hatóságokra és vezető testületekre.
A 4. lépés, Szerepkörök és felelősségek az IBIR-ben, ezt az elemzést felelősségi körökké alakítja. A Zenith Blueprint kiemeli a RACI-modell értékét:
✓ Elszámoltathatóság és felelősség: hasznos eszköz a RACI-mátrix (Responsible,
Accountable, Consulted, Informed). Minden jelentős IBIR-folyamat vagy kontroll esetében azonosítsa,
ki a végrehajtásért felelős (elvégzi a munkát), ki a végső felelős (végső soron számon kérhető, gyakran
vezető), kit kell bevonni konzultációra (véleményt ad), és kit kell tájékoztatni.
Közös adatkezelők esetében a RACI a gyakorlatban nem opcionális. Enélkül a jogi osztály azt feltételezi, hogy az adatvédelmi terület válaszol a kérelemre, az adatvédelmi terület azt feltételezi, hogy az ügyféltámogatás kezeli a beérkezési sort, az ügyféltámogatás azt feltételezi, hogy a partner válaszol, a jogszabályi határidő pedig közben telik.
A Clarysec közös adatkezelői bizonyítékmodellje
Egy érett közös adatkezelői megállapodásnak egy oldalon érthetőnek és tíz perc alatt bizonyíthatónak kell lennie. A cél nem az, hogy a csapatokat jogi dokumentáció alá temessük. A cél az, hogy a felelősségek láthatók, elfogadottak és tesztelhetők legyenek.
| Bizonyítékobjektum | Mit bizonyít | Helye a Clarysec eszköztárban | Felelős |
|---|---|---|---|
| Szerepkör-meghatározási feljegyzés | Miért közös adatkezelők a felek, nem pedig adatfeldolgozók vagy önálló adatkezelők | PIMS-szerepkör meghatározása, REG08 | adatvédelmi vezető vagy beszállítói felelős |
| Adatkezelési nyilvántartási bejegyzés | Cél, PII-kategóriák, jogalap, megőrzés, rendszerek, címzettek és adattovábbítások | REG02 | adatvédelmi vezető vagy jogi terület |
| Felelősségmegosztás | Ki kezeli a tájékoztatókat, jogokat, adatsértési koordinációt, megőrzést, adattovábbításokat, biztonsági kapcsolattartókat és audittámogatást | REG08 | beszállítói vagy beszerzési felelős |
| Nyilvános összefoglaló | Hogyan kapnak tájékoztatást az érintettek a megállapodás lényegéről és a kapcsolattartási pontról | REG07 | adatvédelmi vezető vagy PIMS-vezető |
| Joggyakorlási munkafolyamat | Beérkezés, ellenőrzés, továbbítás, partneri támogatás, válaszfelelős, határidők és bizonyítékok | REG06 vagy joggyakorlási nyilvántartás | adatvédelmi vezető és ügyféltámogatás |
| Adatsértési koordinációs feljegyzés | Vezető bejelentő, kommunikációs felelős, döntési napló, incidensbesorolás és bizonyítékok | REG10 | incidenskezelési vezető és adatvédelmi vezető |
| Szerződéses pontok | Adatmegosztás, felelősség, audit, titoktartás, biztonság, adattovábbítások, megszüntetés és alvállalkozói szabályok | szerződés-nyilvántartás | jogi és beszerzési terület |
A Clarysec adatvédelmi szabályzatai minden réteget megerősítenek.
A Privacy Notice and Transparency Policy 4.1.5 pontja kimondja:
[Közös adatkezelő] Az adatvédelmi vezetőnek/PIMS-vezetőnek rögzítenie KELL a nyilvánosan elérhető közös adatkezelői felelősségi összefoglalót és kapcsolattartási pontot a REG07-ben, mielőtt a közös adatkezelés keretében végzett adatkezelés elindul vagy lényegesen megváltozik.
A PII Principal Rights Management Policy 6.1.5 pontja kimondja:
[Közös adatkezelő] Az adatvédelmi vezetőnek/PIMS-vezetőnek dokumentálnia KELL a joggyakorlási kérelmek kezeléséhez kapcsolódó felelősségeket és kapcsolattartási útvonalakat a REG02-ben, REG06-ban vagy REG08-ban, mielőtt a közös adatkezelés keretében végzett adatkezelés megkezdődik.
A PII Incident and Breach Management Policy 4.2.5 pontja hozzáteszi:
[Közös adatkezelő] Az adatvédelmi vezetőnek/PIMS-vezetőnek ellenőriznie KELL a megállapodott adatsértési felelősséget, a vezető kommunikációs felelősséget és a koordinációs megállapodást bármely közös adatkezelő általi külső bejelentés vagy kommunikáció előtt, és a döntést rögzítenie KELL a REG08-ban és a REG10-ben.
Ezen a ponton válik az ISO/IEC 27701:2025 és a GDPR működőképessé. A szervezet nem pusztán kijelenti, hogy a felelősségek ki vannak osztva. Megmutatja, hol vannak rögzítve, ki hagyta jóvá őket, mikor tesztelték őket, és hogyan használják őket.
Gyakorlati példa: REG08 egy távoli monitorozási platform esetében
Tegyük fel, hogy a CareConnect és a MetroHealth közösen működtet egy távoli monitorozási platformot. Mindkét fél dönt arról, miért kezelnek betegadatokat, milyen adatokat gyűjtenek, hogyan konfigurálják a monitorozási riasztásokat, hogyan használják az analitikát, és hogyan lépnek kapcsolatba a betegek a szolgáltatással.
Először a REG02-nek rögzítenie kell az adatkezelési tevékenységet:
- Adatkezelés megnevezése: távoli betegmonitorozási szolgáltatás
- Adatkezelői szerep: közös adatkezelő
- Felek: CareConnect és MetroHealth
- Cél: betegmonitorozás, ellátáskoordináció, szolgáltatásfejlesztés, platformanalitika
- PII-kategóriák: elérhetőségi adatok, fiókazonosítók, klinikai megfigyelések, eszközesemények, támogatási interakciók
- Különleges adatkategória ellenőrzése: egészségügyi adatok kezelése történik, ezért fokozott védelmi intézkedések szükségesek
- Jogalap: fél és cél szerint dokumentálva
- Megőrzés: klinikai, platform-, jogi és működési követelmények alapján meghatározva
- Rendszerek: mobilalkalmazás, monitorozási platform, támogatási eszköz, analitikai adattárház, identitásszolgáltató
- Címzettek: közös adatkezelő felek, tárhelyszolgáltató, támogatási beszállítók, értesítési szolgáltatók
- Adattovábbítások: távoli hozzáférés és EGT-n kívüli adatkezelés értékelve
- REG08-hivatkozás: JC-2026-004
Másodszor a REG08-nak úgy kell kiosztania a felelősségeket, hogy azt az üzemeltetők követni tudják.
| Felelősségi terület | CareConnect | MetroHealth | Bizonyíték |
|---|---|---|---|
| Adatvédelmi tájékoztató kidolgozása | Biztosítja a műszaki adatkezelési részleteket | Vezeti a betegoldali szövegezést és közzétételt | REG07 tájékoztató-bejegyzés |
| Jogalap nyilvántartása | Dokumentálja a platformanalitika jogalapját | Dokumentálja az ellátásnyújtás és a betegkapcsolat jogalapját | REG02 jogalap-bejegyzés |
| Érintetti hozzáférési kérelmek | Megállapodott SLA szerint biztosítja a platformadat-exportokat | Vezeti a beérkeztetést, ellenőrzést, személyazonosság-ellenőrzést és választ | REG06 munkafolyamat |
| Helyesbítési és törlési kérelmek | Végrehajtja a jóváhagyott módosításokat a platformrendszerekben | Meghatározza a klinikai nyilvántartások kezelését és a betegkommunikációt | Joggyakorlási bizonyítéknapló |
| Adatsértési értékelés | Észleli, elszigeteli és besorolja a platformincidenseket | Értékeli a betegre gyakorolt hatást és a hatósági kommunikációt | REG10 adatsértési feljegyzés |
| Külső bejelentés | Megállapodás szerint vezeti a platformból eredő incidenseket | Megállapodás szerint vezeti a beteg- és hatósági kapcsolattartást | REG08 és incidenskezelési forgatókönyv |
| Biztonsági védelmi intézkedések | Fenntartja a platform kontrolljait, naplózását, hozzáféréseit és felhőbiztonságát | Fenntartja a kórházi oldali hozzáféréseket és operatív kontrollokat | SoA és kontrollbizonyíték |
| Adatfeldolgozók kezelése | Kezeli a felhő- és SaaS-al-adatfeldolgozókat | Kezeli a kórházi adatfeldolgozókat és további címzetteket | beszállítói nyilvántartás |
| Megőrzés és törlés | Ütemezés szerint törli vagy anonimizálja a platformrekordokat | Megerősíti a klinikai megőrzési és további törlési szabályokat | megőrzési nyilvántartás |
| Auditbizonyíték | Biztosítja a naplókat, szabályzatokat, teszteredményeket és nyilatkozatokat | Biztosítja az irányítási jóváhagyásokat és a joggyakorlási feljegyzéseket | auditkérelem-követő |
Harmadszor a REG07-nek rögzítenie kell a nyilvánosan elérhető összefoglalót. A tájékoztatónak közérthetően el kell magyaráznia a közös megállapodás lényegét, azonosítania kell a közös adatkezelőket, le kell írnia, melyik fél miért felel, és használható kapcsolattartási pontot kell biztosítania. Nem kényszerítheti a betegeket vagy felhasználókat arra, hogy belső működési összetettséget fejtsenek vissza.
Negyedszer az indulás előtt tesztelni kell a munkafolyamatot. Küldjön szimulált hozzáférési kérelmet a közzétett kapcsolattartási pontra. Ellenőrizze, hogy az ügyféltámogatás érintetti joggyakorlási kérelemként azonosítja-e, továbbítja-e az adatvédelmi területnek, ellenőrzi-e a REG08-at, bekéri-e a partneri információkat, rögzíti-e a műveleteket a REG06-ban, és előállít-e válaszcsomagot. Ezután hajtson végre adatsértési asztali gyakorlatot például „API-végpont betegazonosítókat tesz hozzáférhetővé jogosulatlan felhasználók számára” vagy „törlés alól kivett felhasználók véletlenül bekerülnek egy kapcsolattartási kampányba” forgatókönyvvel.
Ezek a tesztek feltárják a valódi hiányosságokat: gazdátlan postafiókok, tisztázatlan partneri SLA-k, jóvá nem hagyott tájékoztatószöveg, hiányos jogalap-nyilvántartások, hiányzó különleges adatkategóriákra vonatkozó ellenőrzések, valamint olyan incidenskezelési forgatókönyvek, amelyek nem nevezik meg a külső kommunikáció vezetőjét.
Az Article 26 megfeleltetése ISO/IEC 27002:2022 kontrolloknak a Zenith Controls segítségével
A közös adatkezelői megállapodás nem pusztán jogi artefaktum. Technikai és szervezeti kontrollokkal kell alátámasztani. A Zenith Controls segít a csapatoknak az ISO/IEC 27001:2022 és ISO/IEC 27002:2022 kontroll-elvárások adatvédelmi, beszállítói, incidenskezelési, felhő- és irányítási bizonyítékokhoz való megfeleltetésében.
Három ISO/IEC 27002:2022 kontroll különösen releváns.
5.2 kontroll, Információbiztonsági szerepkörök és felelősségek támogatja az operatív modellt. Kapcsolódik az ISO/IEC 27001:2022 Clause 5.3, szervezeti szerepkörök, felelősségek és hatáskörök követelményéhez. Az incidenskezelésre való felkészültséget is támogatja, mert a tisztázatlan szerepkörök aláássák az ISO/IEC 27002:2022 5.24 kontroll, információbiztonsági incidenskezelés tervezése és előkészítése követelményeit. A közös adatkezelői irányításban az 5.2 kontroll az a pont, ahol a RACI, a REG08 felelősei, az érintetti joggyakorlási kérelmek kezelői, az adatsértési vezetők és az eszkalációs kapcsolattartók auditbizonyítékká válnak.
5.31 kontroll, Jogi, jogszabályi, szabályozói és szerződéses követelmények az a terület, ahol a GDPR Article 26 az IBIR részévé válik, nem pedig csak jogi kérdés marad. Támogatja a GDPR Article 5 szerinti elszámoltathatóság, az Article 6 szerinti jogalap, az Article 26 szerinti felelősségmegosztás, az Article 32 szerinti biztonság, az Article 33 szerinti felügyeleti hatósági bejelentés és az Article 34 szerinti érintetti kommunikáció azonosítását és kezelését. Kapcsolódik továbbá az ISO/IEC 27001:2022 Clause 4.2, az érdekelt felek igényeinek és elvárásainak megértése, valamint a Clause 6.1.3, információbiztonsági kockázatkezelés követelményeihez.
5.34 kontroll, Adatvédelem és a PII védelme a PII védelmét beemeli a biztonsági működési modellbe. Különösen fontos akkor, ha a megállapodás felhőalapú analitikát, megosztott irányítópultokat, adattisztaszobákat, monitorozási platformokat, marketingautomatizálást vagy támogatási eszközöket használ. Kapcsolódó védelmi intézkedések lehetnek az ISO/IEC 27002:2022 5.23 kontroll, információbiztonság felhőszolgáltatások használata esetén, és a 8.11 kontroll, adatmaszkolás.
A támogató ISO-ökoszisztéma szintén fontos. Az ISO/IEC 27018 ott segít, ahol nyilvános felhőszolgáltatások kezelnek PII-t. Az ISO/IEC 29100 olyan adatvédelmi elveket ad, mint az átláthatóság, hozzájárulás, jogszerű cél, adatgyűjtési korlátozás, adattakarékosság, felhasználási korlátozás, pontosság, biztonsági védelmi intézkedések és elszámoltathatóság. Az ISO/IEC 27001:2022 az irányítási rendszer gerincét biztosítja a kontextus, érdekelt felek, hatály, vezetés, kockázatértékelés, kockázatkezelés, alkalmazhatósági nyilatkozat, belső audit, vezetőségi átvizsgálás és folyamatos fejlesztés révén.
A szerződéseknek illeszkedniük kell a működési modellhez
A közös adatkezelői megállapodás nem élhet kizárólag az adatvédelmi tájékoztatóban. Tükröződnie kell a szerződésekben, mellékletekben, működési eljárásokban, incidenskezelési forgatókönyvekben, eszkalációs útvonalakban és megszüntetési rendelkezésekben.
A Clarysec Legal and Regulatory Compliance Policy 5.3.1.2 pontja kifejezetten bevonja a szerződéstípusokat az irányításba, többek között:
Adatmegosztást, szellemitulajdon-jogokat, felelősségkorlátozásokat vagy auditálási záradékokat tartalmazó szerződések
A Data Protection and Privacy Policy 5.1 pontja meghatározza a vállalati alapot:
A szervezetnek formális adatvédelmi irányítási keretrendszert kell fenntartania, amely az információbiztonsági irányítási rendszerbe (ISMS) integrálva biztosítja e szabályzat alkalmazását.
KKV-k esetében ugyanez az elv a működési realitásokhoz igazodik. A Data Protection and Privacy Policy-sme - SME 5.2.1 pontja kimondja:
Az adatvédelmi koordinátornak nyilvántartást kell vezetnie 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őket.
Az 5.2.2 pont hozzáteszi:
A személyes adatokat kezelő harmadik felekkel kötött szerződéseknek adatvédelmi záradékokat kell tartalmazniuk, és azokat az ügyvezetőnek vagy jogi tanácsadónak felül kell vizsgálnia.
Ez arányos irányítás. Egy multinacionális szervezetnek lehetnek külön jogi, adatvédelmi, beszerzési, biztonsági, kockázatkezelési és megfelelési csapatai. Egy KKV támaszkodhat adatvédelmi koordinátorra, ügyvezetőre és külső jogi tanácsadóra. A bizonyítékokkal szembeni elvárás ugyanaz marad: az adatkezelési tevékenységeket, felelősségeket, jogalapot, tájékoztatókat, joggyakorlási kérelmek kezelését, incidenseszkalációt és megszüntetési kötelezettségeket dokumentálni kell, és felülvizsgálhatónak kell lenniük.
A Zenith Blueprint 23. lépése, Szervezeti kontrollok, támogatja a beszállítói megállapodások fegyelmét a titoktartás, hozzáférés-szabályozási felelősségek, technikai és szervezési intézkedések (TOM), incidensjelentési határidők, auditálási jogok, alvállalkozói kontrollok és szerződéslezárási rendelkezések útján. Közös adatkezelői viszonyokban ezeket a záradékokat az adatmegosztáshoz és a felelősségmegosztáshoz kell igazítani, nem pedig adatfeldolgozói sablonból kell átmásolni.
Incidens- és adatsértési irányítás: a vezető szerepet az adatsértés előtt kell kijelölni
A közös adatkezelői adatsértések kaotikussá válnak, ha a csapatok az incidensig várnak annak eldöntésével, ki kommunikál külső felekkel.
A GDPR szerint a személyesadat-sértés olyan biztonsági sérülés, amely a személyes adatok véletlen vagy jogellenes megsemmisítéséhez, elvesztéséhez, megváltoztatásához, jogosulatlan közléséhez vagy az azokhoz való jogosulatlan hozzáféréshez vezet. Ha szükséges, a felügyeleti hatóságot indokolatlan késedelem nélkül, és amennyiben lehetséges, az adatsértésről való tudomásszerzést követő 72 órán belül értesíteni kell. A NIS2 és a DORA további kiberincidens-jelentési és ügyfélkommunikációs elvárásokat írhat elő.
A Clarysec Incident Response Policy-sme - SME 5.3.2 pontja rögzíti az időzítési fegyelmet:
A reagálási határidőket, beleértve az adat-helyreállítást és a bejelentési kötelezettségeket, dokumentálni kell, és összhangba kell hozni a jogi követelményekkel, például a GDPR szerinti 72 órás személyesadat-sértési bejelentési követelménnyel.
A Zenith Blueprint 5. lépése, Kommunikáció, tudatosság és kompetencia, hangsúlyozza a külső kommunikáció tervezését, beleértve az ügyfeleket, szabályozó hatóságokat, partnereket és a nyilvánosságot. Közös adatkezelők esetében az incidensmátrixnak azonosítania kell, ki végzi az elsődleges adatsértési besorolást, ki lép kapcsolatba a másik adatkezelővel, ki állapítja meg, érintett-e PII, ki értékeli a bejelentési küszöbértékeket, ki készíti elő a hatósági bejelentéseket, ki kommunikál az érintettekkel, ki koordinálja a NIS2 vagy DORA szerinti jelentéstételt, ki hagyja jóvá a nyilvános nyilatkozatokat, és ki rögzíti a bizonyítékokat a REG10-ben.
Ha a megállapodás DORA hatálya alá tartozó pénzügyi szervezetet érint, az incidensfolyamatnak támogatnia kell a súlyos IKT-vonatkozású incidensek besorolását, a felső vezetés felé történő eszkalációt, a köztes frissítéseket, a végső jelentéstételt és az ügyfélkommunikációt, ha a pénzügyi érdekek érintettek. Ha a szervezet a NIS2 hatálya alá tartozik, a jelentős incidensek jelentése szakaszos értesítést és a szolgáltatás igénybe vevőinek tájékoztatását igényelheti.
A legbiztonságosabb gyakorlat az indulás előtti közös asztali gyakorlat. Egy jó forgatókönyv időnyomás alatt kényszeríti a csapatokat a REG08, REG10, az incidenskezelési forgatókönyv, a partneri kapcsolattartók, a bejelentési sablonok, az eszkalációs fák és a bizonyítéknaplók használatára.
Megfelelőségi keretrendszerek közötti összhang: az Article 26 ritkán áll önmagában
A közös adatkezelői megállapodások gyakran tágabb szabályozott ökoszisztémákban helyezkednek el. Egy fintech kampány, összekapcsolt egészségügyi platform, menedzselt szolgáltatási kapcsolat, felhőpiactéri integráció vagy digitális infrastruktúra-partnerség a GDPR-on túli kötelezettségeket is kiválthat.
A NIS2 alkalmazandó lehet közepes és nagy méretű alapvető vagy fontos szervezetekre olyan ágazatokban, mint a digitális infrastruktúra, felhőszolgáltatások, adatközpontok, menedzselt szolgáltatók, menedzselt biztonsági szolgáltatók, online piacterek, keresőmotorok és közösségi hálózati platformok. A NIS2 Article 20 a kiberbiztonsági kockázatkezelés felügyeletét a vezető testületekre helyezi. Az Article 21 technikai, operatív és szervezeti intézkedéseket ír elő, beleértve a kockázatelemzést, 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égek kezelését, a képzést, a titkosítást, a HR-biztonságot, a hozzáférés-szabályozást, az eszközkezelést és a hitelesítést. Az Article 23 szakaszos jelentéstételt vezet be jelentős incidensek esetére.
A DORA 2025. január 17-től sok pénzügyi szervezetre alkalmazandó. Lefedi az IKT-kockázatkezelést, a súlyos IKT-vonatkozású incidensek jelentését, a digitális működési reziliencia tesztelését, az IKT-harmadikfél-kockázatot, az IKT-szolgáltatókkal kötött szerződéses megállapodásokat és a kritikus IKT-harmadikfél-szolgáltatók felügyeletét. A DORA Article 5 az IKT-kockázati irányítást vezető testületi szintre helyezi. Az Articles 8 to 14 lefedik az eszközazonosítást, védelmet, észlelést, folytonosságot, biztonsági mentést, helyreállítást, tanulságok levonását, képzést és válságkommunikációt. Az Articles 17 to 20 meghatározzák az incidens életciklusát és jelentését. Az Articles 28 to 30 az IKT-harmadikfél-kockázatot, szerződéses feltételeket, nyilvántartásokat, koncentrációs kockázatot, auditálási jogokat és kilépési tervezést központi kötelezettséggé teszik.
A NIST CSF 2.0 gyakorlati integrációs réteget biztosít. GOVERN funkciója magában foglalja a jogi, szabályozói, szerződéses, adatvédelmi és polgári szabadságjogi kötelezettségeket, a vezetői elszámoltathatóságot, a kockázatvállalási hajlandóságot, a szabályzatokat, a felügyeletet és a beszállítói kockázatot. Az olyan kimenetek, mint a GV.OC-03 és a GV.SC-02 természetesen illeszkednek az Article 26 bizonyítékaihoz, mert megkövetelik, hogy a jogi kötelezettségek és partneri szerepek ismertek, kezeltek, kommunikáltak és koordináltak legyenek.
| Megfelelőségi nézőpont | Mit kérdez egy közös adatkezelői megállapodásban | Clarysec bizonyíték |
|---|---|---|
| GDPR | Ki határozza meg a célokat és eszközöket, hogyan osztják ki a felelősségeket, hogyan tájékoztatják az érintetteket, és hogyan kezelik a jogokat és adatsértéseket | REG02, REG07, REG08, REG10, joggyakorlási naplók |
| ISO/IEC 27701:2025 PIMS | Az adatvédelmi szerepkörök, adatkezelési nyilvántartások, jogalap, átláthatóság, joggyakorlási munkafolyamatok, incidenskezelés és elszámoltathatósági bizonyítékok rendszerszerűen kezeltek-e | PIMS-szabályzatok, nyilvántartások, vezetőségi átvizsgálási bizonyítékok |
| ISO/IEC 27001:2022 | A jogi követelmények, adatvédelmi kötelezettségek, beszállítói függőségek, felhőhasználat, incidensszerepek és kockázatkezelés az IBIR-en belül vannak-e | Hatály, érdekelt felek nyilvántartása, kockázati nyilvántartás, SoA, Annex A bizonyítékok |
| NIS2 | Az irányítás, incidenskezelés, ellátási lánc, hozzáférés-szabályozás, folytonosság, képzés és jelentéstétel integrált-e | Incidenskezelési terv, beszállítói nyilvántartás, képzési nyilvántartások, folytonossági tesztek |
| DORA | Az IKT-harmadikfél-kockázat, incidensjelentés, rezilienciatesztelés, adatvédelem és szerződéses kontrollok irányítottak-e pénzügyi szolgáltatások esetén | IKT-nyilvántartás, szerződéses záradékok, incidensbesorolás, kilépési tervek |
| NIST CSF 2.0 | A jelenlegi és célzott irányítási kimenetek, beszállítói kockázat, incidensreagálás és helyreállítás meghatározottak és mérhetők-e | CSF-profil, hiányosságkezelési terv, POA&M, kockázati nyilvántartás |
| COBIT 2019 | Az irányítási célkitűzések, elszámoltathatóság, teljesítménymérés és bizonyossági bizonyítékok visszakövethetők-e a vállalati célokig | RACI, kontrollmutatók, vezetői jelentések, auditbizonyíték-csomag |
A Clarysec modelljének előnye a bizonyítékok újrahasznosítása. A REG08 nem csupán GDPR-nyilvántartás. Támogatja az ISO/IEC 27701:2025 szerinti elszámoltathatóságot, az ISO/IEC 27001:2022 szerinti irányítást, a NIST CSF 2.0 szerinti beszállítói szereptisztázást, a DORA szerinti harmadikfél-irányítást pénzügyi szolgáltatások esetén, valamint a NIS2 szerinti vezetői felügyeletet, ha a szervezet hatály alá tartozik.
Mit fognak tesztelni az auditorok és szabályozó hatóságok
A különböző felülvizsgálók eltérő nézőpontból közelítik meg a közös adatkezelői irányítást, de ugyanarra az alapvető kérdésre jutnak: képes-e a szervezet bizonyítani, hogy az elszámoltathatóság működik?
| Auditori nézőpont | Várható auditkérdés | Előkészítendő bizonyíték |
|---|---|---|
| ISO/IEC 27001:2022 auditor | A jogi, szabályozói, szerződéses, adatvédelmi, beszállítói, incidenskezelési és felhőkövetelmények azonosítottak-e, és szerepelnek-e az IBIR hatályában és a kockázatkezelésben? | Hatály, érdekelt felek nyilvántartása, megfelelési kötelezettségek nyilvántartása, kockázatértékelés, SoA, beszállítói kontrollok |
| ISO/IEC 27701:2025 PIMS auditor | Meghatározták-e a PIMS-szerepköröket, és dokumentálták-e a közös adatkezelői felelősségeket az adatkezelés megkezdése előtt? | REG02, REG07, REG08, joggyakorlási munkafolyamat, adatsértési feljegyzések, vezetőségi átvizsgálás |
| GDPR-fókuszú auditor vagy DPO-felülvizsgáló | Tudja-e a szervezet bizonyítani az Article 5 szerinti elszámoltathatóságot és az Article 26 szerinti felelősségmegosztást? | Közös adatkezelői megállapodás, tájékoztató-összefoglaló, jogalap-nyilvántartások, joggyakorlási naplók, adatsértési döntési naplók |
| NIST CSF 2.0 értékelő | Az adatvédelmi, jogi, beszállítói, incidenskezelési és helyreállítási kimenetek szerepelnek-e a jelenlegi és célprofilokban, helyesbítő intézkedési tervvel? | CSF-profil, hiányelemzés, kockázati nyilvántartás, POA&M, beszállítói monitorozás |
| DORA-felülvizsgáló | Irányítottak-e az IKT-harmadikfél-függőségek, incidensjelentés, reziliencia, szerződéses jogok és kilépési tervek pénzügyi szolgáltatások esetén? | IKT-szerződésnyilvántartás, incidensbesorolás, rezilienciatesztek, auditálási jogok, kilépési stratégia |
| NIS2-felügyelő | A vezetés jóváhagyta és felügyelte-e a kockázatkezelési intézkedéseket, beszállítói biztonságot, incidenskezelést, folytonosságot, hozzáférés-szabályozást és képzést? | Igazgatósági jegyzőkönyvek, szabályzatok, incidenskezelési terv, folytonossági tesztek, képzési nyilvántartások, beszállítói kockázat-felülvizsgálatok |
| COBIT 2019 vagy ISACA auditor | Az elszámoltathatóság irányítási struktúrákon keresztül kijelölt, nyomon követett, mért és jelentett-e? | RACI, KPI-k, kontrolltesztelés, vezetői jelentések, problémák helyesbítő intézkedései |
A legerősebb audithelyzet a visszakövethetőség. Induljon a jogi követelménytől, kapcsolja azt a PIMS-szabályzathoz, mutasson a nyilvántartási bejegyzésre, mutassa be a munkafolyamatot, majd mutasson tesztbizonyítékot vagy valós ügyiratot.
Például a GDPR Article 26 megköveteli a közös adatkezelői felelősségek kiosztását. A Privacy Information Management System Policy előírja a REG08-at az adatkezelés megkezdése előtt. A REG08 megmutatja a felelősségmegosztást a tájékoztatók, jogok, adatsértés, megőrzés, beszállítókezelés és kapcsolattartók tekintetében. A REG07 megmutatja a nyilvánosan elérhető összefoglalót. Egy érintetti joggyakorlási szimuláció bizonyítja, hogy a munkafolyamat működik. A vezetőségi átvizsgálási jegyzőkönyvek megmutatják a kivételeket, döntéseket és fejlesztéseket.
Ez az auditálható irányítás.
A vezetőségi átvizsgálás az adatvédelmi kockázatot vezetői elszámoltathatósággá alakítja
A közös adatkezelői irányítást nem szabad adatvédelmi mappába rejteni. Helye van a vezetőségi átvizsgálásban, mert hatással van a szabályozói kitettségre, az ügyfélbizalomra, a betegbizalomra, az incidenskezelésre való felkészültségre, a beszállítói kockázatra, a szerződéses felelősségre és az operatív rezilienciára.
Az ISO/IEC 27001:2022 vezetői elkötelezettséget, szerepköröket, erőforrásokat, szabályzati összhangot, kockázatalapú tervezést, teljesítményértékelést és folyamatos fejlesztést követel meg. A NIS2 kiberbiztonsági felügyeleti kötelezettségeket helyez a vezető testületekre. A DORA a pénzügyi szervezeteknél az IKT-kockázatért viselt végső felelősséget a vezető testületre helyezi.
A Clarysec Governance Roles and Responsibilities Policy-sme - SME 5.5 pontja kimondja:
Minden jelentős biztonsági döntést, kivételt és eszkalációt rögzíteni kell, és visszakövethetőnek kell lennie.
Vállalati szervezetek esetében a Governance Roles and Responsibilities Policy 5.2 pontja előírja:
Szerepkör- és felelősségi nyilvántartást kell fenntartani, amelynek tartalmaznia kell:
Ennek a nyilvántartásnak tartalmaznia kell az adatvédelmi irányítási szerepköröket is, ha azok érintik a biztonságot, az incidenskezelést, a beszállítói bizonyosságot, az operatív rezilienciát és a vezetői jelentéstételt. A közös adatkezelői kivételeket az indulás előtt kell eszkalálni, nem pedig egy panasz után felfedezni.
Egy gyakorlati vezetőségi átvizsgálási csomagnak tartalmaznia kell:
- Új és módosított közös adatkezelői megállapodások
- REG08 teljesítési státusz
- Magas kockázatú adatkezelési tevékenységek és adott esetben DPIA-státusz
- Nyitott jogalap- vagy átláthatósági problémák
- Joggyakorlási teljesítmény és lejárt partneri intézkedések
- Adatsértési asztali gyakorlat eredményei és megoldatlan hiányosságok
- Beszállítói, al-adatfeldolgozói, felhő- és adattovábbítási függőségek
- Megőrzési és megszüntetési kivételek
- Auditmegállapítások és helyesbítő intézkedések státusza
- GDPR, NIS2, DORA, NIST CSF 2.0 és COBIT 2019 szerinti jelentéstételi hatás
Ötlépéses Clarysec-megközelítés az Article 26 auditálhatóvá tételéhez
Ha szervezete egy másik féllel közösen dönt a PII kezeléséről, ne várjon panaszra, auditra, adatsértésre vagy partneri vitára a felelősségek tisztázásával.
Alkalmazza ezt az ötlépéses megközelítést:
- Használja a Zenith Blueprint 2. lépését az érdekelt felek, jogi követelmények, partneri elvárások, adatvédelmi kötelezettségek és szabályozási hatály azonosítására.
- Használja a Zenith Blueprint 4. lépését RACI kialakítására a tájékoztatók, jogalap, jogok, adatsértési kommunikáció, megőrzés, adattovábbítások, beszállítók, auditbizonyítékok és megszüntetés tekintetében.
- Rögzítse az adatkezelési tevékenységet a REG02-ben, a közös adatkezelői felelősségmegosztást pedig a REG08-ban a Clarysec PIMS-szabályzatkészletének használatával.
- Feleltesse meg a megállapodást a Zenith Controls segítségével, különösen az ISO/IEC 27002:2022 5.2, 5.31 és 5.34 kontrolloknak.
- Tesztelje a megállapodást érintetti joggyakorlási szimulációval és adatsértési asztali gyakorlattal az adatkezelés megkezdése előtt.
A CareConnectnek és a MetroHealthnek nem több informális egyeztetésre volt szüksége. Dokumentált felelősségmegosztásra, nyilvánosan elérhető összefoglalóra, joggyakorlási munkafolyamatra, adatsértési koordinációs feljegyzésre, szerződéses záradékokra és vezetőségi átvizsgálási bizonyítékokra volt szükségük.
Ez a különbség aközött, hogy „úgy gondoltuk, a partner kezeli”, és aközött, hogy „itt van a jóváhagyott megállapodás, tájékoztató, munkafolyamat, tesztbizonyíték és adatsértési döntési feljegyzés”.
A Clarysec segít az ISO/IEC 27701:2025 szerinti PIMS-irányítás bevezetésében, annak GDPR Article 26 szerinti összehangolásában, az ISO/IEC 27001:2022 szerinti IBIR-be integrálásában, valamint auditkész bizonyítékok előállításában a GDPR, NIS2, DORA, NIST CSF 2.0 és COBIT 2019 elvárásai mentén.
Készen áll arra, hogy a közös adatkezelői bizonytalanságot auditálható bizonyítékokra cserélje? Ismerje meg a Zenith Blueprint: egy auditor 30 lépéses ütemterve anyagot, használja a Zenith Controls: megfelelőségi keretrendszerek közötti útmutató megoldást, vagy lépjen kapcsolatba a Clarysec csapatával egy PIMS- és IBIR-értékelésért, amely az Article 26 követelményeit működő kontrollrendszerré alakítja, mielőtt a következő partnerség élesbe áll.
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
