Posouzení dopadů předávání údajů v cloudu v roce 2026

Maria, ředitelka informační bezpečnosti ve společnosti InnovatePay, zírala na stranu 12 dotazníku due diligence.
Její společnost, rychle rostoucí evropský fintechový poskytovatel SaaS, byla blízko podpisu dosud největší zákaznické smlouvy s významnou bankou s přísnými požadavky na provozní odolnost. Dotazník nepožadoval pouze certifikát ISO 27001, shrnutí penetračního testu nebo sadu bezpečnostních politik. Požadoval úplné posouzení dopadů předávání údajů pro primárního cloudového poskytovatele InnovatePay se sídlem v USA, rozpis dílčích zpracovatelů, použitelné standardní smluvní doložky, prohlášení o zeměpisném předávání údajů a důkaz, že doplňková opatření jsou mapována na ISO/IEC 27001:2022, NIS2 a DORA.
Právní oddělení mělo dodatek o zpracování údajů. Nákup měl dodavatelský portál. Technický tým měl nastavení cloudových regionů. Bezpečnostní tým měl diagramy šifrování. Tým péče o zákazníky při prodejním hovoru slíbil „hosting v EU“. Nikdo však nedokázal okamžitě doložit, zda do rozsahu spadá přístup podpory z Indie, zda analytický doplněk používá dílčího zpracovatele v USA, ani zda jsou chybové logy replikovány prostřednictvím globálního poskytovatele monitorování.
To je realita roku 2026 pro společnosti SaaS, poskytovatele cloudových služeb, fintechové dodavatele a poskytovatele řízených ICT služeb. Posouzení dopadů předávání údajů, tedy TIA, už není memorandem k ochraně soukromí vytvořeným na konci pořizování. Je to soubor důkazů pro více oblastí souladu, který musí vysvětlit, kam osobní údaje proudí, kdo k nim má přístup, jaký právní mechanismus předávání se použije, která doplňková opatření snižují riziko a jak organizace předávání průběžně monitoruje.
U mnoha týmů není problémem nedostatek úsilí. Problémem je roztříštěnost. SCC jsou v repozitáři smluv. Seznamy dílčích zpracovatelů jsou v portálech dodavatelů. Nastavení umístění dat je v cloudové konzoli. Rozhodnutí o rizicích jsou pohřbena v e-mailech. Důkazy o šifrování jsou v Confluence. Kvalitní cloudové posouzení dopadů předávání údajů propojuje tyto fragmenty do jednoho obhajitelného řetězce důkazů.
Proč se TIA pro cloud stala rizikem na úrovni řídicích orgánů
Posouzení dopadů předávání údajů hodnotí, zda osobní údaje předávané mimo Evropský hospodářský prostor zůstávají v praxi chráněny. Posouzení má určit údaje, strany, účely zpracování, místa uložení, místa přístupu, následná předání, právní mechanismus předávání, rizika země příjemce a doplňková opatření.
Podle GDPR je výchozí rozsah široký. Osobní údaje, zpracování, správce, zpracovatel, pseudonymizace a porušení zabezpečení osobních údajů jsou vymezeny široce. Do rozsahu mohou spadat cloudová telemetrie, tikety podpory, autentizační logy, fakturační záznamy, identifikátory uživatelů, IP adresy i produktová analytika. Odpovědnost podle GDPR dle Article 5 vyžaduje, aby organizace prokázaly soulad, zatímco povinnosti zpracovatele podle Article 28 a pravidla pro mezinárodní předávání podle Chapter V závisí na přesné znalosti toho, jaká data se přesouvají, kam se přesouvají a kdo k nim může přistupovat.
Rozsudek Schrems II praktickou zátěž zpřesnil. Samotný podpis SCC nestačí. Organizace musí zvážit, zda právní předpisy a praxe cílové země mohou oslabit ochranu slíbenou ve smlouvě, a tam, kde je to nutné, uplatnit doplňková opatření.
U cloudových podniků se situace rychle komplikuje. Produkt SaaS může používat jednoho poskytovatele infrastruktury, samostatnou platformu podpory, e-mailovou službu, nástroj pro monitorování chyb, CDN, datový sklad a analytickou funkci využívající AI. Každý poskytovatel může mít dílčí zpracovatele. Každý dílčí zpracovatel může zavést místo uložení, místo přístupu, provozní cestu podpory nebo následné předání.
Proto se ISO/IEC 27001:2022, NIS2, DORA a NIST CSF 2.0 staly součástí diskuse o TIA:
- GDPR se ptá, zda existuje zákonný mechanismus předávání, odpovídající podmínky pro zpracovatele, kontrola dílčích zpracovatelů a účinná doplňková opatření.
- ISO/IEC 27001:2022 se ptá, zda je riziko předávání identifikováno, ošetřeno, kontrolováno, monitorováno a zahrnuto v Prohlášení o použitelnosti.
- NIS2 se ptá, zda základní a důležité subjekty řídí kybernetické riziko dodavatelů a poskytovatelů služeb s dohledem vedení.
- DORA požaduje, aby finanční subjekty doložily řízení rizik třetích stran v ICT, smluvní doložky, viditelnost subdodávek, transparentnost lokalit, riziko koncentrace a připravenost na ukončení služby.
- NIST CSF 2.0 pomáhá převést tyto požadavky do výstupů v oblasti správy, dodavatelského rizika, ochrany, reakce a obnovy.
Praktický závěr je jednoduchý: TIA má být součástí ISMS, nikoli stát mimo něj.
Používejte ISMS jako centrum souladu
Snaha řídit TIA, GDPR, DORA a NIS2 v oddělených tabulkách vytváří duplicitní práci a auditní mezery. Škálovatelnějším přístupem je použít ISO/IEC 27001:2022 jako systém řízení, který propojuje povinnosti, rizika, opatření a důkazy.
ISO/IEC 27001:2022 vyžaduje, aby organizace porozuměly svému kontextu, požadavkům zainteresovaných stran, rozhraním a závislostem na jiných organizacích. Vyžaduje také opakovatelné posouzení rizik bezpečnosti informací, proces ošetření rizik, Prohlášení o použitelnosti a důkazy, že vybraná opatření fungují tak, jak bylo zamýšleno.
Tato struktura TIA přesně odpovídá. Riziko „osobní údaje z EU mohou být prostřednictvím cloudového poskytovatele nebo dílčího zpracovatele zpřístupněny ze třetí země bez účinných ochranných opatření“ patří do registru rizik. Ošetření patří do plánu ošetření rizik. Vybraná opatření patří do SoA. Podpůrné artefakty patří do indexu důkazů.
Clarysec Zenith Blueprint: 30krokový plán auditora zachycuje tento vztah ve fázi řízení rizik, kroku 13:
SoA je v praxi přemosťující dokument: propojuje vaše posouzení/ošetření rizik se skutečnými opatřeními, která máte zavedena. Jeho vyplněním zároveň znovu ověříte, zda vám žádná opatření nechybí.
Tato věta je pro připravenost TIA zásadní. TIA není opatření. Je to posouzení, které vysvětluje, proč jsou opatření potřebná a jak snižují zbytkové riziko předávání. SoA je most, který propojuje riziko se správou cloudu, smlouvami s dodavateli, kryptografií, řízením přístupu, monitorováním, reakcí na incidenty, kontinuitou a právním souladem.
Začněte mapou předávání, ne SCC
Mnoho organizací začíná TIA otázkou, zda smlouva obsahuje SCC. To je nezbytné, ale není to první otázka. SCC mají význam pouze tehdy, když organizace ví, jaká předávání pokrývají.
Praktické TIA pro cloud začíná pěti otázkami.
| Otázka TIA | Zdroj důkazů | Proč na tom auditorům záleží |
|---|---|---|
| Jaké osobní údaje se předávají? | Záznamy o zpracování, klasifikace dat, evidence cloudových aktiv, mapy toků dat | Odpovědnost podle GDPR a identifikace rizik podle ISO 27001 vyžadují definovaná aktiva a kontext zpracování |
| Kde jsou data uložena, zpřístupněna, podporována nebo replikována? | Registr cloudových služeb, nastavení umístění u poskytovatele, prohlášení dílčích zpracovatelů | Analýza mezinárodního předávání závisí jak na místech uložení, tak na místech přístupu |
| Kdo údaje přijímá nebo k nim může přistupovat? | Registr dodavatelů, DPA, seznam dílčích zpracovatelů, záznamy privilegovaného přístupu | Správa zpracovatelů a dílčích zpracovatelů musí být vymahatelná a monitorovaná |
| Jaký mechanismus předávání jej podporuje? | SCC, rozhodnutí o odpovídající ochraně, EU-US Data Privacy Framework, pokud je použitelný, závazná podniková pravidla (BCR) nebo jiný zdokumentovaný základ | GDPR Chapter V vyžaduje platný mechanismus předávání s kontrolami následného předávání |
| Jaká doplňková opatření snižují zbytkové riziko? | Návrh šifrování, vlastnictví klíčů, pseudonymizace, schválení přístupů, protokolování, DLP, incidentní proces | Posouzení musí ukázat praktickou ochranu, nikoli pouze papírové doložky |
SME politika Clarysec Politika používání cloudových služeb pro SME tento požadavek operacionalizuje prostřednictvím registru:
Registr cloudových služeb musí udržovat poskytovatel IT služeb nebo GM. Musí zaznamenávat:
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.
Stejná skupina ustanovení obsahuje požadavek na lokalitu, který je pro TIA zásadní:
Zemi nebo region, kde jsou data uložena
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.4.
Pro větší prostředí Clarysec Politika používání cloudových služeb výslovně propojuje správu cloudu s mechanismy předávání:
Přezkoumávat standardní smluvní doložky (SCC) a mechanismy předávání podle GDPR, pokud se použijí.
Ze sekce „Role a odpovědnosti“, ustanovení politiky 4.5.2.
Stejná politika doplňuje mezioborový regulační požadavek:
Přeshraniční přenosy dat musí být v souladu s GDPR Chapter V a, je-li to relevantní, DORA Article 28.
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.6.3.
Tím se diskuse o TIA mění. Otázka nezní „máme SCC?“ Otázka zní: „která cloudová služba, které osobní údaje, která země, která cesta přístupu, který dílčí zpracovatel, který mechanismus předávání, která doplňková opatření a jaké zbytkové riziko?“
Mapujte TIA pro cloud na důkazy podle ISO/IEC 27001:2022
ISO/IEC 27001:2022 poskytuje strukturu pro doložení, že TIA je součástí fungujícího prostředí opatření. Nejdůležitějšími oblastmi důkazů jsou řízení dodavatelů, správa cloudu, právní povinnosti, ochrana soukromí, kryptografie, řízení přístupu, monitorování, reakce na incidenty a kontinuita.
| Oblast důkazů podle ISO/IEC 27001:2022 | Co u TIA prokázat | Příklad artefaktu |
|---|---|---|
| Řízení dodavatelských rizik | Prověrka dodavatele zahrnuje mezinárodní předávání, umístění dat a riziko dílčích zpracovatelů | Posouzení rizik dodavatele se sekcí k předávání |
| Smlouvy s dodavateli | Jsou definovány bezpečnostní doložky, doložky ochrany soukromí, auditu, oznamování porušení zabezpečení, subdodavatelů a ukončení | DPA, SCC, harmonogram ICT smlouvy, bezpečnostní dodatek |
| Dodavatelský řetězec ICT | Navazující poskytovatelé a cloudové závislosti jsou identifikovány a řízeny | Registr dílčích zpracovatelů a důkazy o přenesení požadavků |
| Monitorování dodavatelů | Důkazy poskytovatele jsou pravidelně přezkoumávány a změny spouštějí opětovné posouzení | Přezkum zprávy SOC, přezkum certifikátu ISO, log změn dílčích zpracovatelů |
| Cloudové služby | Pořizování, používání, správa a ukončení cloudových služeb jsou řízeny | Registr cloudových služeb, matice sdílené odpovědnosti, plán ukončení cloudové služby |
| Právní povinnosti a povinnosti ochrany soukromí | GDPR Chapter V, povinnosti zpracovatele a závazky vůči zákazníkům jsou zdokumentovány | Registr právních povinností, TIA, záznamy o zpracování |
| Kryptografie a řízení přístupu | Doplňková opatření jsou zavedena a ověřena | Architektura šifrování, nastavení KMS, logy přezkumů přístupových práv |
| Incidenty a kontinuita | Cloudové a dodavatelské incidenty jsou detekovány, hlášeny, zvládány a promítány do zlepšování | Incidentní postup, oznamovací doložky, záznamy testů obnovy |
Clarysec Zenith Controls: průvodce mezioborovým souladem je zde obzvlášť užitečný. V Zenith Controls je opatření ISO/IEC 27002:2022 5.23, Bezpečnost informací pro používání cloudových služeb, pojato jako preventivní opatření podporující důvěrnost, integritu a dostupnost napříč doménami správy, ekosystému a ochrany. Propojuje používání cloudu se vztahy s dodavateli, zabezpečením koncových bodů, zabezpečením sítí, přenosem informací, maskováním dat, prevencí úniku dat, evidencí aktiv a životním cyklem bezpečného vývoje.
Toto mapování je důležité, protože TIA se zřídkakdy vyřeší jedinou právní doložkou. Často zahrnuje administrátorský přístup ke cloudu, rozhraní API přesouvající data mezi regiony, konzole podpory, logy, cloudová úložiště, monitorovací platformy a umístění záloh.
Zenith Controls také mapuje 5.23 na související normy, včetně ISO/IEC 27017 pro sdílenou odpovědnost v cloudu a auditní stopy, ISO/IEC 27018 pro ochranu osobně identifikovatelných údajů (PII) ve veřejném cloudu, ISO/IEC 27701 pro požadavky rozšíření ochrany soukromí, ISO/IEC 27036-4 pro monitorování cloudových služeb a ISO/IEC 27005 pro posouzení cloudových rizik.
Pro dodavatelské smlouvy Zenith Controls pokrývá opatření ISO/IEC 27002:2022 5.20, řešení bezpečnosti informací ve smlouvách s dodavateli. Toto opatření převádí požadavky na předávání do vymahatelných závazků. Podmínky pro zpracovatele podle GDPR Article 28, kontroly dílčích zpracovatelů, očekávání NIS2 pro dodavatelský řetězec a smluvní ustanovení DORA Article 30 se všechny stávají smluvními důkazy.
Pro průběžný dohled je klíčové opatření ISO/IEC 27002:2022 5.22, monitorování, přezkum a řízení změn služeb dodavatelů. TIA dokončené při onboardingu může zastarat, jakmile poskytovatel přidá dílčího zpracovatele, změní lokality podpory, upraví architekturu protokolování nebo spustí novou funkci.
Odstraňte slabé místo dílčích zpracovatelů
Nejčastějším selháním TIA není chybějící SCC. Je jím zastaralá znalost dílčích zpracovatelů.
Poskytovatelé cloudových služeb a platformy SaaS často mění regiony služeb, modely podpory, telemetrické pipeline, CDN a subdodavatele. Pokud TIA závisí na seznamu dílčích zpracovatelů staženém jednou při pořizování, rychle se stane nespolehlivým.
Clarysec Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran to řeší smluvním požadavkem:
Použití subdodavatelů podléhá předchozímu písemnému souhlasu
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.5.
Clarysec Politika právního a regulačního souladu určuje právní důkazy, které musí být udržovány:
Zpřístupnění informací o dílčích zpracovatelích a prohlášení o zeměpisném předávání údajů
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.3.1.2.
Tento požadavek je krátký, ale často tvoří rozdíl mezi věrohodným TIA a neúplným posouzením. Pokud organizace nedokáže předložit informace o dílčích zpracovatelích a prohlášení o zeměpisném předávání, nemůže spolehlivě vysvětlit následná předání.
Zenith Blueprint, fáze Controls in Action, krok 23, doplňuje provozní očekávání:
U každého kritického dodavatele určete, zda používá subdodavatele (dílčí zpracovatele), kteří mohou přistupovat k vašim datům nebo systémům. Zdokumentujte, jak jsou vaše požadavky na bezpečnost informací přenášeny na tyto strany, buď prostřednictvím smluvních podmínek vašeho dodavatele, nebo vašich vlastních přímých doložek.
V praxi to znamená, že vysoce rizikoví dodavatelé musí mít každoroční přezkum dílčích zpracovatelů, proces oznámení změn, zdokumentovaný schvalovací pracovní postup a spouštěč opětovného posouzení rizik. U služeb relevantních pro DORA tytéž důkazy podporují také analýzu subdodávek a rizika koncentrace.
Doplňková opatření musí být konkrétní a doložitelná
Doplňková opatření se nikdy nemají dokumentovat pouze jako „používáme šifrování“ bez podrobností. Auditoři a podnikoví zákazníci se budou ptát, co je šifrováno, kde se šifrování uplatňuje, kdo řídí klíče, zda pracovníci poskytovatele mohou přistupovat k prostému textu, zda logy obsahují osobní údaje a jak je schvalován privilegovaný přístup.
Silný balík doplňkových opatření kombinuje technická, smluvní, organizační a odolnostní ochranná opatření.
| Typ opatření | Příklad | Důkazy TIA |
|---|---|---|
| Technické | Šifrování při přenosu, šifrování v klidu, klíče spravované zákazníkem, pseudonymizace, tokenizace, DLP, protokolování přístupu | Architektonický diagram, konfigurace KMS, politika šifrování, vzorky logů |
| Smluvní | SCC, DPA, schválení dílčích zpracovatelů, oznamování porušení zabezpečení, práva na audit, vrácení a výmaz dat | Podepsané smlouvy, kontrolní seznam doložek, mapování smlouvy |
| Organizační | Pracovní postup přezkumu předávání, schvalování přístupů, školení zaměstnanců, frekvence přezkumu dodavatelů | Postup TIA, záznamy přezkumů přístupových práv, záznamy o školení |
| Odolnost | Zálohování, obnova, plán ukončení služby, strategie alternativního poskytovatele, krizová komunikace | Test obnovy, plán ukončení cloudové služby, plán krizové komunikace |
Clarysec Politika kryptografických opatření pro SME poskytuje kotvu:
Šifrování musí být uplatněno na:
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.
Pro TIA se má toto prohlášení politiky proměnit v explicitní důkaz. Šifrování má být popsáno pro osobní údaje při přenosu mezi systémy EU a cloudovými službami ve třetích zemích, v klidu v cloudovém úložišti a v zálohách. Vlastnictví klíčů musí být definováno. Pokud se používají klíče spravované zákazníkem, TIA má vysvětlit, zda poskytovatel může přistupovat k prostému textu, kdy je povolen přístup podpory a jak je administrátorský přístup protokolován.
Clarysec Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran pro SME posiluje ujištění o lokalitě:
Pokud mají dodavatelé ukládat data mimo pracoviště, společnost musí získat ujištění ohledně ochrany údajů, fyzické bezpečnosti a zeměpisného umístění úložiště (např. hosting pouze v EU, pokud to vyžaduje GDPR).
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.4.
Stejná SME politika také podporuje úplnost smluv:
Smlouvy musí obsahovat povinné doložky pokrývající:
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.
Pro TIA mají tyto povinné doložky pokrývat důvěrnost, bezpečnostní opatření, oznamování porušení zabezpečení, dílčí zpracovatele, práva na audit, vrácení dat, výmaz, mechanismy předávání a závazky k umístění.
Vytvořte balík důkazů TIA připravený na audit
Předpokládejme, že evropský poskytovatel B2B SaaS používá analytickou platformu se sídlem v USA. Platforma přijímá události používání zákazníky, uživatelská ID, IP adresy a metadata podpory. Nabízí hosting v EU a SCC, ale pracovníci podpory mimo EHP mohou přistupovat k tiketům a chybové logy mohou být zpracovávány dílčím zpracovatelem ve třetí zemi.
Praktický balík důkazů lze vytvořit v šesti krocích.
1. Vytvořte záznam o předávání
Začněte Registrem cloudových služeb požadovaným v Politice používání cloudových služeb pro SME. Přidejte vlastníka služby, obchodní účel, kategorie údajů, subjekty údajů, roli, region hostingu, země přístupu, lokality podpory, dílčí zpracovatele, mechanismus předávání, doplňková opatření, hodnocení rizika a datum příštího přezkumu.
U analytické platformy zaznamenejte, že události jsou hostovány v EU, přístup podpory může probíhat mimo EHP a monitorování chyb vytváří následné předání.
2. Připojte smluvní důkazy
Připojte DPA, SCC nebo jiné důkazy mechanismu předávání, bezpečnostní dodatek, podmínky oznamování incidentů a seznam dílčích zpracovatelů. Použijte ustanovení Politiky používání cloudových služeb 4.5.2 jako důkaz přezkumu SCC a mechanismů předávání. Použijte ustanovení Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran 5.3.5 jako důkaz schválení nebo souhlasu s dílčími zpracovateli.
Pokud se u poskytovatele spoléháte na EU-US Data Privacy Framework, zaznamenejte rozsah, stav certifikace, pokrytí služeb a záložní mechanismus. Nepředpokládejte, že pokrývá každé následné předání.
3. Vytvořte rizikový scénář
Přidejte riziko do registru rizik ISMS:
„Osobní údaje z EU zpracovávané prostřednictvím analytické platformy mohou být zpřístupněny ze třetí země podporou poskytovatele nebo dílčími zpracovateli, což vytváří riziko pro důvěrnost a právní a regulační soulad.“
Přiřaďte vlastníka, pravděpodobnost, dopad, inherentní hodnocení, plán ošetření rizik a zbytkové hodnocení. Propojte riziko s GDPR Chapter V, závazky vůči zákazníkům, cloudovými a dodavatelskými opatřeními ISO/IEC 27001:2022, NIS2 Article 21 tam, kde je použitelný, a DORA Articles 28, 29 a 30 pro kontext finančního sektoru.
Clarysec Politika řízení rizik nastavuje disciplínu ošetření:
Manažer rizik musí zajistit, aby ošetření rizik byla realistická, časově vymezená a mapovaná na opatření přílohy A ISO/IEC 27001.
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.4.2.
4. Vyberte doplňková opatření
U analytické platformy mohou opatření zahrnovat hosting v EU, minimalizované datové obsahy událostí, pseudonymní identifikátory, šifrování při přenosu, šifrování v klidu, omezený přístup podpory, MFA pro administrátory, protokolování privilegovaného přístupu, pravidla DLP bránící odesílání citlivých polí v analytických událostech, povinnost oznamovat dílčí zpracovatele a každoroční přezkum důkazů.
Mapujte tato opatření na opatření ISO/IEC 27002:2022, například 5.14 přenos informací, 5.15 řízení přístupu, 5.20 řešení bezpečnosti informací ve smlouvách s dodavateli, 5.22 monitorování, přezkum a řízení změn služeb dodavatelů, 5.23 bezpečnost informací pro používání cloudových služeb, 5.31 právní, zákonné, regulační a smluvní požadavky, 5.34 ochrana soukromí a ochrana PII, 8.11 maskování dat, 8.12 prevence úniku dat, 8.16 monitorovací činnosti a 8.24 používání kryptografie.
5. Definujte spouštěče přezkumu
TIA není úplné, dokud nejsou definovány spouštěče přezkumu. Spouštěče mají zahrnovat nového dílčího zpracovatele, novou zemi přístupu, novou kategorii údajů, změnu modelu podpory, bezpečnostní incident, obnovení smlouvy, nový kritický požadavek zákazníka, novou klasifikaci DORA nebo podstatnou změnu cloudové architektury.
Právě zde se opatření ISO/IEC 27002:2022 5.22 stává provozním. Přezkoumávejte zprávy SOC, certifikáty ISO, shrnutí penetračních testů, oznámení změn služeb, historii incidentů a aktualizace dílčích zpracovatelů. Sledujte výjimky až do uzavření.
6. Aktualizujte SoA a index důkazů
V Prohlášení o použitelnosti označte jako použitelné cloudové, dodavatelské, právní, soukromí, kryptografické, přístupové, monitorovací, incidentní a kontinuity opatření. Přidejte poznámky SoA, například „podporuje TIA podle GDPR Chapter V pro analytickou platformu“, „podporuje smluvní důkazy pro rizika třetích stran v ICT podle DORA“ nebo „podporuje důkazy zabezpečení dodavatelského řetězce podle NIS2“.
Tento závěrečný krok indexace převádí posouzení ochrany soukromí na auditně připravené důkazy souladu.
Mapujte stejné důkazy na GDPR, DORA, NIS2 a ISO 27001
Dobře vytvořený balík důkazů TIA má uspokojit více auditních pohledů bez tvorby duplicitní dokumentace.
| Oblast výzvy | Požadavek GDPR | Požadavek DORA | Požadavek NIS2 | Důkazy podle ISO/IEC 27001:2022 |
|---|---|---|---|---|
| Mezinárodní předávání údajů | Mechanismus předávání podle Chapter V a TIA | Articles 28 a 30 – důkazy o lokalitě a smlouvách | Article 21 zabezpečení dodavatelského řetězce | 5.23 registr cloudu, 5.14 přenos informací, 5.31 právní povinnosti |
| Řízení dílčích zpracovatelů | Article 28(2) předchozí konkrétní nebo obecné písemné povolení | Article 29 subdodávky a riziko koncentrace | Article 21 riziko dodavatelů a poskytovatelů služeb | 5.20 smluvní přenesení požadavků, 5.21 dodavatelský řetězec ICT, 5.22 monitorování |
| Doplňková opatření | Article 32 zabezpečení zpracování | Article 9 ochrana a prevence | Article 21 kryptografie, řízení přístupu a kybernetická hygiena | 8.24 používání kryptografie, 5.15 řízení přístupu, 8.16 monitorovací činnosti |
| Odpovědnost a správa | Article 5(2) prokázání souladu | Articles 5 a 6 správa a rámec řízení rizik v oblasti ICT | Article 20 dohled vedení | Kapitoly 5 a 6, registr rizik, plán ošetření rizik, SoA |
| Důkazy incidentů a odolnosti | Articles 33 a 34 oznamování porušení zabezpečení, pokud je relevantní | Očekávání v oblasti hlášení incidentů, reakce, obnovy a ukončení | Article 23 hlášení významných incidentů | Incidentní postupy, oznamovací doložky, testy obnovy, plány ukončení |
DORA je obzvlášť důležitá tam, kde je zákazníkem finanční subjekt nebo služba podporuje ICT řetězec finančního sektoru. DORA se použije od 17. ledna 2025 a stanoví požadavky na řízení rizik v oblasti ICT, hlášení incidentů, testování odolnosti, sdílení informací a rizika třetích stran v ICT. Article 8 vyžaduje identifikaci a klasifikaci ICT aktiv, informačních aktiv a závislostí. Article 28 vyžaduje správu rizik třetích stran v ICT, registry informací, náležitou péči a exit strategie. Article 29 řeší koncentraci ICT a riziko subdodávek. Article 30 vyžaduje písemné smlouvy s popisy služeb, místy zpracování, ochranou dat, přístupem, obnovou, vrácením dat, podporou při incidentech, spoluprací s orgány, právy na ukončení, právy na audit a přechodovými ujednáními.
NIS2 přidává odpovědnost vedení. Article 20 vyžaduje, aby řídicí orgány schvalovaly opatření řízení kybernetických rizik a dohlížely na ně. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně politik rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování a vývoje, posouzení účinnosti kontrol, kybernetické hygieny, kryptografie, bezpečnosti HR, řízení přístupu, správy aktiv a MFA tam, kde je vhodná.
Překryv je zřejmý. TIA, které identifikuje dílčí zpracovatele, lokality předávání, doplňková opatření, incidentní povinnosti a monitorování dodavatelů, je zároveň důkazem dodavatelské odolnosti.
Jak budou auditoři testovat vaše TIA
Různí auditoři kladou různé otázky, ale důkazy mají být opakovaně použitelné.
| Pohled auditora | Pravděpodobná auditní otázka | Silné důkazy |
|---|---|---|
| Audit ochrany soukromí podle GDPR | Dokážete prokázat mechanismus předávání, kontrolu dílčích zpracovatelů a doplňková opatření? | TIA, SCC, DPA, registr dílčích zpracovatelů, prohlášení o umístění dat, důkazy šifrování a přístupu |
| Audit ISO/IEC 27001:2022 | Je riziko předávání identifikováno, ošetřeno, kontrolováno a zahrnuto v SoA? | Registr rizik, plán ošetření rizik, poznámky SoA, registr cloudu, záznamy přezkumů dodavatelů |
| Audit ochrany soukromí podle ISO/IEC 27701 | Jsou povinnosti zpracovatele provozně uplatněny v cloudových službách zpracovávajících osobní údaje? | Doložky DPA, podpora žádostí subjektů údajů, pracovní postup výmazu, proces oznamování incidentů |
| Přezkum připravenosti na NIS2 | Jsou dodavatelská a cloudová rizika řízena opatřeními schválenými vedením? | Posouzení rizik dodavatele, přezkoumání vedením, politika kryptografie, incidentní záznamy a záznamy kontinuity |
| Přezkum třetích stran v ICT podle DORA | Jsou ICT smlouvy, subdodávky, lokality, monitorování a plány ukončení řízeny? | Registr ICT smluv, mapování doložek Article 30, přezkum subdodavatelů, test ukončení |
| Posouzení NIST CSF 2.0 | Jsou právní, regulační, smluvní a dodavatelská rizika řízena a zlepšována? | Aktuální a cílové profily, plán odstranění mezer, kritičnost dodavatelů, sledování reakce na rizika |
| Audit ve stylu COBIT 2019 nebo ISACA | Existuje jasné vlastnictví správy, výkonnost procesů a odpovědnost za kontroly? | RACI, vlastnictví politik, KPI, KRI, správa problémů, reporting řídicím orgánům |
Zenith Controls poskytuje pro tyto oblasti praktickou auditní metodiku. U cloudových služeb auditoři hledají registr schválených cloudových služeb a důkazy, že neoprávněné používání cloudu je monitorováno. U dodavatelských smluv auditoři provádějí vzorkování smluv u vysoce rizikových dodavatelů a ověřují důvěrnost, ochranu údajů, lhůty oznamování porušení zabezpečení, práva na audit, schválení dílčích zpracovatelů a vrácení nebo zničení dat. U monitorování dodavatelů auditoři zkoumají záznamy přezkumů, reporty KPI, certifikace dodavatelů, zprávy SOC, shrnutí penetračních testů, výjimky a nápravná opatření.
Auditní poučení je přímočaré: důkazy musí ukazovat fungování v čase. Jednou podepsané a nikdy nepřezkoumané TIA neuspokojí seriózní cloudový, dodavatelský ani odolnostní přezkum.
Použijte NIST CSF 2.0 k vysvětlení rizika TIA vedení
Řídicí orgány obvykle nechtějí podrobně diskutovat moduly SCC nebo lokality cloudové podpory. Chtějí vědět, zda je riziko řízeno, prioritizováno a zlepšuje se. NIST CSF 2.0 pomáhá převést TIA do jazyka vedení prostřednictvím funkcí GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER.
Pro TIA je obzvlášť užitečná funkce GOVERN. Zahrnuje právní, regulační a smluvní požadavky, ochotu podstupovat riziko, role, politiky, dohled a řízení kybernetických rizik dodavatelů. Vytvořte aktuální profil, který ukazuje dnešní stav, například částečný cloudový registr, repozitář SCC, omezený přezkum dílčích zpracovatelů a žádnou definovanou frekvenci přezkumu TIA. Poté definujte cílový profil, například úplnou evidenci předávání, dílčí zpracovatele ohodnocené podle rizika, ověřené mechanismy předávání, klíče spravované zákazníkem pro vysoce riziková data, čtvrtletní přezkumy kritických dodavatelů, mapování smluv připravené pro DORA a otestované plány ukončení cloudových služeb.
Plán odstranění mezer se stává praktickým plánem implementace, který může vedení financovat a sledovat.
Kontrolní seznam Clarysec pro TIA v cloudu v roce 2026
Použijte tento kontrolní seznam k ověření, zda je vaše posouzení dopadů předávání údajů připravené na audit:
- Udržujte registr cloudových služeb s vlastníkem, účelem, kategoriemi údajů, lokalitami, zeměmi přístupu a dílčími zpracovateli.
- Určete, zda je každá služba vztahem správce, zpracovatele, dílčího zpracovatele nebo nezávislého poskytovatele.
- Připojte DPA, SCC nebo jiné důkazy mechanismu předávání k záznamu dodavatele.
- Zaznamenávejte spoléhání na EU-US Data Privacy Framework pouze tehdy, když je ověřen rozsah a následná předání.
- Udržujte informace o dílčích zpracovatelích a prohlášení o zeměpisném předávání.
- Vyžadujte předchozí písemný souhlas nebo smluvní oznámení pro nové dílčí zpracovatele podle rizika.
- Mapujte doplňková opatření na konkrétní technická opatření, nikoli na obecná prohlášení.
- Doložte šifrování při přenosu, šifrování v klidu, vlastnictví správy klíčů a protokolování privilegovaného přístupu.
- Minimalizujte, pseudonymizujte nebo maskujte osobní údaje před předáním tam, kde je to možné.
- Definujte spouštěče přezkumu pro nové země, nové dílčí zpracovatele, nové kategorie údajů, incidenty a smluvní změny.
- Propojte každé riziko TIA s registrem rizik, plánem ošetření rizik a SoA.
- Pravidelně přezkoumávejte důkazy dodavatelů a sledujte výjimky až do uzavření.
- Zahrňte do smluv oznamování incidentů, práva na audit, vrácení dat, výmaz a povinnosti při ukončení.
- U služeb relevantních pro DORA mapujte smlouvy na požadavky třetích stran v ICT, subdodávky, lokality, riziko koncentrace a exit strategii.
- Oznamujte rozhodnutí o vysoce rizikových předáváních vedení jako součást správy ISMS.
Proměňte nejistotu při předávání v důkazy připravené na audit
InnovatePay získala bankovní zakázku, protože Maria přestala zacházet s TIA jako s právním dokumentem na poslední chvíli. Její tým vytvořil Registr cloudových služeb, připojil SCC a DPA, zdokumentoval dílčí zpracovatele, namapoval doplňková opatření na opatření ISO/IEC 27001:2022, aktualizoval registr rizik, doplnil poznámky SoA a vytvořil monitorovací spouštěče. Výsledkem nebyla jen lepší odpověď do dotazníku. Byl to opakovatelný proces řízení dodavatelských rizik.
Vaše organizace může postupovat stejně.
Začněte s Zenith Blueprint: 30krokový plán auditora, abyste propojili rizika předávání s registrem rizik, plánem ošetření rizik a Prohlášením o použitelnosti. Použijte Zenith Controls: průvodce mezioborovým souladem k mapování cloudových opatření ISO/IEC 27002:2022, opatření pro smlouvy s dodavateli a monitorování dodavatelů na GDPR, NIS2, DORA, NIST a auditní očekávání. Poté důkazy operacionalizujte prostřednictvím politik Clarysec, jako jsou Politika používání cloudových služeb, Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran, Politika právního a regulačního souladu, Politika řízení rizik a příslušné verze pro SME.
Cloudové posouzení dopadů předávání údajů nemá být prodejní krizí. V roce 2026 je součástí správy cloudu, ujištění dodavatelů, odpovědnosti za ochranu soukromí a provozní odolnosti. Důvěru získají organizace, které dokážou rychle doložit, kam data proudí, kdo se jich dotýká, co je chrání a jak je riziko v čase řízeno.
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


