Harmadik felekkel kapcsolatos kockázat a GDPR, a NIS2 és a DORA mentén

Ugyanaz a beszállító adatvédelmi, kiberbiztonsági és működési rezilienciával kapcsolatos kötelezettségeket is kelthet. Egy bérszámfejtő szolgáltató személyes adatokat kezel; egy menedzselt szolgáltató kiemelt hozzáféréssel rendelkezik; egy felhőplatform üzletkritikus alkalmazásokat támogat. Néha egyetlen beszállító mindhármat megteszi.

Egy közös beszállítói nyilvántartás segíti a csapatokat az értékelés összehangolásában, feltéve, hogy minden kötelezettség azonosítható marad. Egy CTO számára a gyakorlati kihívás a szerződéses kötelezettségvállalások összekapcsolása a műszaki valósággal: mihez fér hozzá a beszállító, hogyan terjednek tovább a hibák, mely kontrollokat támasztják alá bizonyítékok, és képes-e a szervezet helyreállni vagy kilépni.

Állapítsa meg az alkalmazhatóságot, mielőtt összevonja az értékeléseket

Ezek a jogi eszközök átfedik egymást, de nem minden szervezetre vagy beszállítóra vonatkoznak azonos módon.

A GDPR 28. cikke előírja, hogy az adatkezelők elegendő garanciát nyújtó adatfeldolgozókat vegyenek igénybe. Egy 28. cikk szerinti megállapodás nem pusztán azért megfelelő, mert egy beszállító adatokat kap: először a tényleges adatkezelési szerepet kell megállapítani.

A NIS2 irányelv 20–23. cikke a vezetői felügyelettel, a kockázatkezelési intézkedésekkel és a jelentős incidensek bejelentésével foglalkozik. A NIS2 a nemzeti jogon keresztül átültetett irányelv, ezért a hatály és az eljárások joghatóságonkénti ellenőrzést igényelnek.

A DORA 2025. január 17. óta alkalmazandó. Elsősorban meghatározott pénzügyi szervezetekre vonatkozik; a szokásos IKT-beszállítókkal szemben ügyféloldali szerződéses követelmények merülhetnek fel, míg a kijelölt kritikus IKT-szolgáltatókra külön felvigyázási rendszer vonatkozik. A hatály alá tartozó pénzügyi szervezetek esetében a DORA a NIS2 érintett területein ágazatspecifikus uniós jogként működik. Ne kettőzze meg automatikusan mindkét kontrollkészletet.

A nyilvántartást a függőség köré építse

A szolgáltatásból induljon ki, ne a beszállítói kérdőívből. Egy beszállító több szolgáltatást is nyújthat eltérő adatokkal, hozzáféréssel és operatív jelentőséggel.

Gyakorlati alapként rögzítse:

• A szolgáltatást, a beszállító jogi személyét, az üzleti gazdát, a műszaki gazdát és a felülvizsgálókat.
• A támogatott funkciókat, rendszereket, integrációkat és kiemelt hozzáféréseket.
• A személyes adatok kategóriáit, az adatkezelési célokat, a helyszíneket és a további adatfeldolgozókat.
• A rendelkezésre állási követelményeket, a helyreállítási célokat és a tolerálható fennakadást.
• A mögöttes szolgáltatókat, a szerződéses függőségeket és a reális alternatívákat.
• Az alkalmazandó kötelezettségeket, a bizonyítékok dátumait, a nyitott hiányosságokat és a döntéseket.

Azonosítsa, mely funkciók esnének ki vagy romlanának le egy kompromittálódás vagy kiesés után. Egy beszállító, amely kevés érzékeny adatot tárol, még irányíthatja a hitelesítést vagy a telepítési pipeline-okat. Fordítva: egy alacsony rendelkezésre állási kockázatú szolgáltatás is kitehet rendkívül érzékeny személyes adatokat.

Ezeket a dimenziókat tartsa külön, ahelyett hogy egyetlen megmagyarázatlan „magas kockázat” pontszámba olvasztaná őket. A DORA hatálya alá tartozó pénzügyi szervezeteknél kapcsolja ezt az operatív leltárt az IKT-szerződéses megállapodásokra vonatkozó információk kötelező nyilvántartásához; egy általános szállítói lista nem feltétlenül elegendő.

Használja újra a bizonyítékokat, de ne vegye át vakon a következtetéseket

Egy biztonsági jelentés, egy adatfolyam-térkép vagy egy helyreállítási teszt több felülvizsgálatot is alátámaszthat. Mielőtt támaszkodna rá, ellenőrizze a szolgáltatási hatókörét, a jelentési időszakát, a kizárásokat, a kivételeket és az ügyféloldali felelősségeket.

Egy, a beszállító infrastruktúrájára kiterjedő jelentés például nem feltétlenül fedi le a támogató személyzet ügyféladatokhoz való hozzáférését. Egy dokumentált mentési szabályzat nem mutatja meg, hogy a visszaállítás megfelel-e az alkalmazása helyreállítási követelményeinek.

Tartson fenn egy bizonyíték–kérdés mátrixot:

Egy ISO-tanúsítvány vagy egy SOC 2 jelentés a saját hatókörén belül támasztja alá a bizonyosságot; egyik sem bizonyítja a GDPR-nak vagy a NIS2-nek való megfelelést. A felülvizsgáló indoklását őrizze meg, ne csak a feltöltött dokumentumot. A biztonsági garanciák értékelése legyen megismételhető műszaki felülvizsgálat, ne egy jelvény ellenőrzése.

Fordítsa le a követelményeket szerződésekre és kontrollokra

A GDPR 28. cikke szerint az adatfeldolgozói feltételeknek ki kell terjedniük az adatkezelés tárgyára, időtartamára, jellegére és céljára, az adatok típusára és az érintettek kategóriáira. Ki kell terjedniük továbbá a dokumentált utasításokra, a titoktartásra, a biztonságra, a további adatfeldolgozókra vonatkozó feltételekre, a segítségnyújtásra, a törlésre vagy visszaszolgáltatásra, valamint a tájékoztatási és auditkötelezettségekre. A nemzetközi adattovábbítás külön, V. fejezet szerinti értékelést igényel; az uniós tárhely önmagában nem dönti el a hozzáférés vagy a továbbtovábbítás kérdéseit.

A NIS2 irányelv 21. cikke magában foglalja az ellátási lánc biztonságát, valamint a közvetlen beszállítók sérülékenységeinek és kiberbiztonsági gyakorlatainak figyelembevételét. A gyakorlati szerződéses elvárások közé tartozhatnak a hozzáférési korlátozások, a sérülékenységkezelés, az incidensek során való együttműködés és a bizonyítékok rendelkezésre bocsátása. Ezeket a szolgáltatáshoz és a nemzeti követelményekhez igazítsa, ahelyett hogy egyetlen általános kikötéscsomagot jogilag elegendőnek tekintene.

A DORA 30. cikke meghatározza az IKT-szerződéses rendelkezéseket, további követelményekkel a kritikus vagy fontos funkciókat támogató szolgáltatásokra. Vizsgálja felül a szolgáltatásleírásokat, a helyszíneket, az adatvédelmet és az adatok helyreállítását, a segítségnyújtást, a megszüntetést és a vonatkozó felügyeleti jogokat. A kritikus vagy fontos funkciók esetében különös figyelmet kell fordítani a szolgáltatási szintekre, a jelentéstételre, a vészhelyzeti intézkedésekre, a tesztelés során való együttműködésre, az auditjogokra és az átmeneti megoldásokra.

Ezután ellenőrizze a megvalósítást. Ha egy szerződés korlátozott adminisztratív hozzáférést ígér, szerezzen bizonyítékot a szerepkörök elkülönítéséről, a hitelesítésről, a jóváhagyásról és a naplózásról. Ha törlést ígér, állapítsa meg, mi történik a mentésekkel és a megőrzött nyilvántartásokkal. A jogi és a műszaki hiányosságokat a megfelelő felülvizsgálókhoz rendelje.

Tervezze meg az incidensek során történő átadásokat még az incidens előtt

Egy beszállító incidenskezelési szabályzata alátámaszthatja a biztonsági értékelést, miközben az értesítési kötelezettségek rendezetlenek maradnak. Határozza meg a kapcsolattartási csatornákat, az eszkalációs lefedettséget, a kezdeti információkat, a frissítésekre vonatkozó elvárásokat és a bizonyítékok megőrzéséért való felelősséget.

A GDPR 33–34. cikke szerint az adatfeldolgozó indokolatlan késedelem nélkül értesíti az adatkezelőt. Az adatkezelő indokolatlan késedelem nélkül és, ha lehetséges, a tudomásszerzéstől számított 72 órán belül értékeli a felügyeleti hatóság felé történő bejelentést, kivéve, ha az incidens valószínűsíthetően nem jár kockázattal az érintettek jogaira és szabadságaira nézve. Magas kockázat esetén az érintettek tájékoztatása is szükséges lehet, a kivételek figyelembevételével. Ha a bejelentés nem kötelező, rögzítse az indoklást.

A NIS2 jelentős incidensekre vonatkozó uniós bejelentési szakaszai között szerepel egy 24 órás korai figyelmeztetés, egy 72 órás bejelentés és főszabályként a bejelentéstől számított egy hónapon belüli zárójelentés; ellenőrizze a nemzeti és ágazati szabályokat. A DORA-nak saját bejelentési keretrendszere van a súlyos IKT-vonatkozású incidensekre. Ezeket az értékeléseket ne helyettesítse egyetlen beszállítói „incidens” jelzővel.

Gyakorlati ajánlásként gyakoroljon egy beszállítói incidenst hiányos információkkal. Tesztelje, hogy a csapatok meg tudják-e állapítani az érintett szolgáltatásokat, a kitettséget, az operatív hatást és a bejelentési döntéseket anélkül, hogy egy végleges kiváltóok-jelentésre várnának.

Kidolgozott példa: egy szolgáltatás, három felülvizsgálati útvonal

Tegyük fel szemléltetésként, hogy egy hatály alá tartozó pénzügyi szervezet hosztolt ügyfélszolgálati platformot használ, amely személyes adatokat kezel, és egy olyan funkciót támogat, amelyet a DORA szerint kritikusnak vagy fontosnak minősítettek.

A beszállító egy bizonyosságnyújtási jelentést, egy incidenskezelési szabályzatot és egy helyreállítási teszt összefoglalóját adja át. A biztonsági terület megállapítja, hogy az adminisztratív hozzáférés-szabályozás bizonyítékokkal alátámasztott, a helyreállítási teszt azonban nem terjed ki az ügyfél integrációjára.

Az adatvédelem ettől függetlenül egy tisztázatlan, a további adatfeldolgozók változására vonatkozó folyamatot és a távoli hozzáféréshez kapcsolódó rendezetlen adattovábbítási megoldásokat azonosít. A DORA szerinti felülvizsgálat megállapítja, hogy az átmeneti segítségnyújtás és a vonatkozó auditrendelkezések figyelmet igényelnek.

Az így kapott intézkedési terv konkrét:

• A műszaki gazda teszteli az integráció helyreállítását, és dokumentálja az eredményt.
• Az adatvédelmi felülvizsgáló rendezi a további adatfeldolgozókra és az adattovábbításra vonatkozó kérdéseket.
• A jogi terület és a beszerzés kezeli a szerződéses hiányosságokat.
• Az elszámoltatható gazda dönt arról, hogy az ideiglenes használat elfogadható-e, feltételekkel és felülvizsgálati dátummal.

A bizonyítékokat újrahasznosítják, de a három következtetés egyikét sem vezetik le a másikból. Egy sikeres biztonsági felülvizsgálat nem zárja le az adatvédelmi vagy a rezilienciával kapcsolatos hiányosságokat.

Kövesse nyomon a változásokat, a koncentrációt és a végrehajtható kilépést

A felülvizsgálat gyakoriságát a függőség és a kockázat alapján határozza meg. Incidensek, jelentős szolgáltatásváltozások, új további adatfeldolgozók, az adatok helyének változása, tulajdonosváltás vagy szerződésmegújítás után indítson további felülvizsgálatot.

Nézzen a beszállítói nevek mögé: több szolgáltatás is függhet ugyanattól a felhőrégiótól, identitásszolgáltatótól vagy alvállalkozótól. Értékelje az egymással összefüggő fennakadásokat, és azt, hogy a javasolt alternatíva osztozik-e ugyanebben a függőségben. A DORA 29. cikke kifejezetten foglalkozik az IKT-koncentrációs kockázat értékelésével.

Tartson fenn arányos kilépési tervet, amely kiterjed az adatexportra, a migrációra, a folytonosságra, a hozzáférések visszavonására és a törlés bizonyítékára. Tesztelje az export használhatóságát, és azonosítsa, ki tudja üzemeltetni a helyettesítő megoldást. Egy felmondási jog hasznosabb, ha a szervezet végre is tudja hajtani.

A következmények is eltérnek. A GDPR jogsértésspecifikus bírságszinteket alkalmaz; a NIS2 nemzeti szankciós szabályokat ír elő, eltérő felső határokkal az alapvető és a fontos szervezetek számára. A DORA szerinti, pénzügyi szervezetekre vonatkozó szankciók az alkalmazandó szabályoktól függenek, míg a kritikus szolgáltatók felvigyázásához kapcsolódó szankciók ezektől különböznek. Ne egyetlen, feltételezett általános bírság alapján modellezze a kitettséget.

Kezdjen egyetlen jelentős függőséggel

Válasszon ki egy fontos funkciót támogató beszállítót. Egyeztesse a szolgáltatásleltárát, a szerződéseit, a bizonyítékait, a nyitott kockázatait és a kilépési feltételezéseit. Zárja a munkát megnevezett felelősökkel és minden alkalmazandó kötelezettségre vonatkozó külön, dátummal ellátott következtetéssel.

A Secaniban a csapatok modellezhetik a szolgáltatást és a külső szolgáltatót, összekapcsolhatják a követelményeket és a kontrollokat a bizonyítékokkal, és a hiányosságokat felelősökhöz rendelt feladatokként követhetik. Az ember által felülvizsgált döntések, a forráshivatkozások, a megjegyzések és az időbélyegek megőrzik az indoklást. Ez közös beszállítói kontextust biztosít anélkül, hogy elrejtené a különálló adatvédelmi, biztonsági és rezilienciával kapcsolatos megítéléseket.