Rizika třetích stran napříč GDPR, NIS2 a DORA

Tentýž dodavatel může vyvolat povinnosti v oblasti ochrany osobních údajů, kybernetické bezpečnosti i provozní odolnosti. Poskytovatel mzdových služeb zpracovává osobní údaje; poskytovatel řízených služeb má privilegovaný přístup; cloudová platforma podporuje obchodně kritické aplikace. Někdy jeden dodavatel dělá všechno tři.

Sdílený záznam o dodavateli pomáhá týmům koordinovat posouzení, pokud každá povinnost zůstane identifikovatelná. Pro CTO je praktickou výzvou propojit smluvní závazky s technickou realitou: k čemu má dodavatel přístup, jak se šíří selhání, která opatření jsou doložena a zda se organizace dokáže zotavit nebo odejít.

Před spojením posouzení určete použitelnost

Tyto předpisy se překrývají, nevztahují se však na každou organizaci nebo dodavatele stejným způsobem.

Článek 28 GDPR vyžaduje, aby správci využívali zpracovatele, kteří poskytují dostatečné záruky. Smlouva podle článku 28 není namístě jen proto, že dodavatel přijímá údaje: nejprve určete skutečnou roli při zpracování.

Články 20–23 NIS2 upravují dohled vedení, opatření k řízení rizik a hlášení významných incidentů. NIS2 je směrnice prováděná vnitrostátním právem, takže působnost a postupy vyžadují ověření pro konkrétní jurisdikci.

DORA se použije od 17. ledna 2025. Vztahuje se především na vymezené finanční subjekty; běžní dodavatelé IKT mohou čelit smluvním požadavkům zákazníků, zatímco určení kritičtí poskytovatelé IKT podléhají samostatnému režimu dozoru. Pro dotčené finanční subjekty působí DORA v příslušných oblastech NIS2 jako odvětvově specifické právo EU. Nezdvojujte automaticky obě sady opatření.

Záznam budujte kolem závislosti

Začněte službou, ne dotazníkem pro dodavatele. Jeden dodavatel může poskytovat několik služeb s odlišnými daty, přístupy a provozním významem.

Jako praktický základ zaznamenejte:

• Službu, právnickou osobu dodavatele, vlastníka v byznysu, technického vlastníka a posuzovatele.
• Podporované funkce, systémy, integrace a privilegované přístupy.
• Kategorie osobních údajů, účely zpracování, lokality a další zpracovatele.
• Požadavky na dostupnost, cíle obnovy a přijatelné narušení.
• Podkladové poskytovatele, smluvní závislosti a realistické alternativy.
• Použitelné povinnosti, data důkazů, nevyřešené mezery a rozhodnutí.

Určete, které funkce by po kompromitaci nebo výpadku selhaly nebo se zhoršily. Dodavatel, který ukládá málo citlivých dat, může přesto řídit autentizaci nebo pipeline nasazení. Naopak služba s nízkým rizikem pro dostupnost může vystavovat vysoce citlivé osobní údaje.

Tyto rozměry držte odděleně, místo abyste je slučovali do jednoho nevysvětleného skóre „vysoké riziko“. U finančních subjektů v působnosti DORA propojte tento provozní inventář s povinným registrem informací o smluvních ujednáních týkajících se IKT; obecný seznam dodavatelů nemusí stačit.

Důkazy využívejte opakovaně, závěry však ne naslepo

Bezpečnostní zpráva, mapa datových toků nebo test obnovy mohou podpořit několik přezkumů. Než se na ně spolehnete, ověřte rozsah služby, sledované období, vyloučení, výjimky a odpovědnosti zákazníka.

Například zpráva pokrývající infrastrukturu dodavatele nemusí pokrývat přístup jeho pracovníků podpory k záznamům zákazníků. Zdokumentovaná politika zálohování neukazuje, že obnova splňuje požadavky na obnovu vaší aplikace.

Udržujte matici důkazů a otázek:

Certifikát ISO nebo zpráva SOC 2 podporuje ujištění v rámci svého rozsahu; ani jedno neprokazuje soulad s GDPR nebo NIS2. Uchovávejte zdůvodnění posuzovatele, nejen nahraný dokument. Hodnocení bezpečnostních záruk by mělo být opakovatelným technickým přezkumem, nikoli kontrolou odznaků.

Převeďte požadavky na smlouvy a opatření

Podle článku 28 GDPR musí podmínky pro zpracovatele upravovat předmět, dobu trvání, povahu a účel zpracování, typ údajů a kategorie subjektů údajů. Pokrývají také doložené pokyny, mlčenlivost, zabezpečení, podmínky pro další zpracovatele, součinnost, výmaz nebo vrácení a informační a auditní povinnosti. Mezinárodní předávání vyžaduje samostatné posouzení podle kapitoly V; samotný hosting v EU otázky přístupu ani dalšího předávání neřeší.

Článek 21 NIS2 zahrnuje bezpečnost dodavatelského řetězce a zohlednění zranitelností a postupů kybernetické bezpečnosti přímých dodavatelů. Praktická smluvní očekávání mohou zahrnovat omezení přístupu, řešení zranitelností, součinnost při incidentech a poskytování důkazů. Přizpůsobte je službě a vnitrostátním požadavkům, místo abyste jeden univerzální balík ustanovení považovali za právně dostatečný.

Článek 30 DORA stanoví smluvní ustanovení týkající se IKT s dodatečnými požadavky pro služby podporující kritické nebo důležité funkce. Přezkoumejte popisy služeb, lokality, ochranu a obnovu údajů, pomoc, ukončení a příslušná práva dohledu. U kritických nebo důležitých funkcí je třeba věnovat zvláštní pozornost úrovním služeb, reportingu, pohotovostním opatřením, součinnosti při testování, právům na audit a ujednáním o přechodu.

Poté ověřte implementaci. Pokud smlouva slibuje omezený administrativní přístup, získejte důkazy o oddělení rolí, autentizaci, schvalování a logování. Pokud slibuje výmaz, zjistěte, co se stane se zálohami a uchovávanými záznamy. Právní a technické mezery přidělte příslušným posuzovatelům.

Předávání při incidentech navrhněte dříve, než k incidentu dojde

Politika reakce na incidenty dodavatele může podpořit bezpečnostní posouzení, a přitom ponechat oznamovací povinnosti nevyřešené. Stanovte kontaktní kanály, pokrytí eskalace, úvodní informace, očekávání ohledně aktualizací a odpovědnost za zajištění důkazů.

Podle článků 33–34 GDPR informuje zpracovatel správce bez zbytečného odkladu. Správce posoudí ohlášení dozorovému úřadu bez zbytečného odkladu, a pokud je to možné, do 72 hodin od okamžiku, kdy se o porušení dozvěděl, ledaže je nepravděpodobné, že by porušení představovalo riziko pro práva a svobody osob. Vysoké riziko může vyžadovat oznámení dotčeným osobám, s výhradou výjimek. Pokud ohlášení není nutné, zaznamenejte zdůvodnění.

Fáze hlášení významných incidentů podle NIS2 na úrovni EU zahrnují včasné varování do 24 hodin, oznámení do 72 hodin a zpravidla závěrečnou zprávu do jednoho měsíce od oznámení; ověřte vnitrostátní a odvětvová pravidla. DORA má vlastní rámec hlášení závažných incidentů souvisejících s IKT. Nenahrazujte tato posouzení jediným příznakem „porušení“ u dodavatele.

Jako praktické doporučení procvičte incident u dodavatele s neúplnými informacemi. Otestujte, zda týmy dokážou určit dotčené služby, expozici, provozní dopad a rozhodnutí o hlášení, aniž by čekaly na konečnou zprávu o hlavní příčině.

Modelový příklad: jedna služba, tři cesty přezkumu

Pro ilustraci předpokládejme, že dotčený finanční subjekt využívá hostovanou platformu zákaznické podpory, která zpracovává osobní údaje a podporuje funkci, kterou podle DORA klasifikoval jako kritickou nebo důležitou.

Dodavatel poskytne zprávu o ujištění, politiku pro incidenty a shrnutí testu obnovy. Bezpečnost zjistí, že opatření pro administrativní přístup jsou doložena, test obnovy však nezahrnuje integraci zákazníka.

Ochrana osobních údajů samostatně identifikuje nejasný proces změn dalších zpracovatelů a nevyřešená ujednání o předávání při vzdáleném přístupu. Přezkum podle DORA zjistí, že pozornost vyžaduje pomoc při přechodu a příslušná ustanovení o auditu.

Výsledný akční plán je konkrétní:

• Technický vlastník otestuje obnovu integrace a zdokumentuje výsledek.
• Posuzovatel za ochranu osobních údajů vyřeší otázky dalších zpracovatelů a předávání.
• Právní oddělení a nákup řeší smluvní mezery.
• Odpovědný vlastník rozhodne, zda je dočasné používání přijatelné, s podmínkami a datem přezkumu.

Důkazy se využívají opakovaně, žádný ze tří závěrů však není odvozen od jiného. Úspěšný bezpečnostní přezkum neuzavírá mezery v ochraně osobních údajů ani v odolnosti.

Sledujte změny, koncentraci a proveditelný odchod

Četnost přezkumů nastavte podle závislosti a rizika. Dodatečný přezkum spusťte po incidentech, zásadních změnách služby, nových dalších zpracovatelích, změnách umístění dat, změnách vlastnictví nebo při obnovení smlouvy.

Dívejte se pod názvy dodavatelů: několik služeb může záviset na stejném cloudovém regionu, poskytovateli identit nebo subdodavateli. Posuďte korelované narušení a to, zda navrhovaná alternativa tuto závislost nesdílí. Článek 29 DORA výslovně upravuje posouzení koncentračního rizika v oblasti IKT.

Udržujte přiměřený plán odchodu pokrývající export dat, migraci, kontinuitu, odvolání přístupů a doklady o výmazu. Otestujte použitelnost exportu a určete, kdo dokáže provozovat náhradu. Právo na ukončení je užitečnější, když jej organizace dokáže skutečně uplatnit.

Liší se i důsledky. GDPR má úrovně sankcí podle druhu porušení; NIS2 vyžaduje vnitrostátní úpravu sankcí s odlišnými horními hranicemi pro základní a důležité subjekty. Sankce podle DORA pro finanční subjekty závisejí na příslušné úpravě, zatímco sankce v rámci dozoru nad kritickými poskytovateli jsou samostatné. Nemodelujte expozici pomocí jedné údajné univerzální pokuty.

Začněte jednou závislostí s významnými důsledky

Vyberte jednoho dodavatele, který podporuje důležitou funkci. Sjednoťte jeho inventář služeb, smlouvy, důkazy, otevřená rizika a předpoklady odchodu. Zakončete to jmenovitými vlastníky a samostatnými, datovanými závěry pro každou použitelnou povinnost.

V Secani mohou týmy modelovat službu a externího poskytovatele, propojovat požadavky a opatření s důkazy a sledovat mezery jako úkoly s vlastníky. Rozhodnutí přezkoumaná lidmi, odkazy na zdroje, komentáře a časová razítka zachovávají zdůvodnění. To podporuje sdílený kontext dodavatelů, aniž by se skrývaly odlišné úsudky o ochraně osobních údajů, bezpečnosti a odolnosti.