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

Správa a řízení změn dílčích zpracovatelů pro SaaS a MSP

Igor Petreski

Sarah, CISO rychle rostoucího fintechového poskytovatele SaaS, otevřela zprávu, která vypadala jako běžná servisní aktualizace od dodavatele kritické infrastruktury. Pod nadpisem „optimalizace služeb“ byla skrytá jedna věta, která jí změnila celý týden:

„Za účelem zvýšení výkonu analytiky budou pracovní zátěže zpracování dat do 30 dnů migrovány k našemu novému partnerovi, DataCrunch Analytics.“

Třicet dnů. Nový analytický partner. Rychlá kontrola ukázala, že poskytovatel sídlí mimo EU.

Vývojový tým v tom viděl běžné zlepšení ze strany dodavatele. Nákup předpokládal, že stávající smlouva tuto změnu pokrývá. Tým péče o zákazníky neplánoval žádnou oznamovací kampaň. Právní oddělení neposoudilo dopady na předávání údajů. Sarah okamžitě rozpoznala skutečný problém: její společnost vystupovala jako zpracovatel pro stovky finančních institucí po celé Evropě. Tito zákazníci byli podle GDPR správci. Někteří si vyjednali předchozí oznámení nových dílčích zpracovatelů. Někteří měli právo vznést námitku. Několik z nich mělo povinnosti v oblasti outsourcingu a řízení rizik třetích stran v oblasti ICT vyplývající z DORA. Několik zákazníků mělo přísná prohlášení o lokalitě zpracování, která nebylo možné potichu změnit.

Právě v takovém okamžiku mnoho poskytovatelů SaaS, MSP, MSSP a poskytovatelů cloudových služeb zjistí, že správa a řízení dílčích zpracovatelů není administrativní úkon v oblasti ochrany soukromí. Jde o řízení dodavatelských rizik, soulad se smluvními požadavky, provozní odolnost, komunikaci se zákazníky a auditní důkazy v jednom pracovním postupu.

Veřejná stránka se seznamem dílčích zpracovatelů nestačí. Poznámka pod čarou v e-mailu od dodavatele nestačí. Bezpečnostní dotazník nestačí. Obhajitelný proces musí ukázat, kdo dílčího zpracovatele posoudil, jaká data se zpracovávají, kterých zákazníků se změna týká, které smlouvy vyžadují oznámení, zda byly námitky vyřešeny před zahájením používání, jak byly navázány důkazy o mezinárodním předávání a kde jsou konečné důkazy uchovány.

Clarysec k tomu přistupuje jako k řízenému vzorci opatření, nikoli jako k ad hoc řetězci e-mailů. Pracovní postup propojuje správu ochrany soukromí, ujištění o dodavateli, právní přezkum, rizika dodavatelského řetězce ICT, oznámení zákazníkům a auditní důkazy prostřednictvím politik Clarysec, Zenith Blueprint: 30krokové vodítko auditora a Zenith Controls: příručka pro soulad napříč rámci.

Proč jsou změny dílčích zpracovatelů vysoce rizikové dodavatelské události

Změna dílčího zpracovatele může přes noc změnit rizikový profil služby. Může změnit, kde jsou hostovány osobní údaje zákazníků, odkud se k nim přistupuje, kdo má privilegovaný přístup v rámci podpory, jak dlouho se uchovávají logy, jak se eskalují incidenty, jaké povinnosti v oblasti šifrování se uplatní a zda je vyžadován nový mechanismus mezinárodního předávání.

U SaaS a poskytovatelů řízených služeb jsou dílčí zpracovatelé často součástí dodavatelského řetězce produktu. Mohou zahrnovat poskytovatele cloudového hostingu, systémy pro správu tiketů, služby pro doručování e-mailů, nástroje analytiky AI, platformy pro úlohy na pozadí, dodavatele observability, nástroje podpory, zpracovatele plateb, poskytovatele řízených bezpečnostních služeb a služby obohacování dat. Mnoho z těchto poskytovatelů se dotýká osobních údajů zákazníků i tehdy, když je týmy označují jako nástroje „infrastruktury“ nebo „provozu“.

Podle GDPR je to důležité, protože Article 28 vyžaduje, aby zpracovatelé řídili navazující zpracovatele na základě povolení správce. Pokud se používá obecné písemné povolení, musí zpracovatel informovat správce o zamýšleném zapojení nebo nahrazení dílčích zpracovatelů a dát správci možnost vznést námitku. Article 28(4) také vyžaduje, aby byly dílčímu zpracovateli uloženy rovnocenné povinnosti v oblasti ochrany osobních údajů. Article 5(2) doplňuje zásadu odpovědnosti, což znamená, že organizace musí být schopna soulad prokázat, nikoli jej pouze deklarovat.

DORA zvyšuje nároky u finančních služeb. Finanční subjekty musí řídit rizika třetích stran v oblasti ICT jako nedílnou součást řízení rizik v oblasti ICT. Musí vést registry smluvních ujednání, posuzovat riziko koncentrace, rozumět subdodavatelským řetězcům, definovat smluvní záruky, zajistit auditní a přístupová práva, podporovat spolupráci při incidentech a plánovat ukončení spolupráce. I když poskytovatel SaaS není přímo finančním subjektem, jeho finanční zákazníci budou důkazy očekávat, protože sami musí splnit požadavky DORA.

NIS2 rozšiřuje pohled na zabezpečení dodavatelského řetězce a odpovědnost vedení. Article 21 vyžaduje odpovídající technická, provozní a organizační opatření, včetně zabezpečení dodavatelského řetězce, zvládání incidentů, kontinuity činností, řízení přístupu, správy aktiv, bezpečného pořizování a údržby a posuzování účinnosti. Article 20 ukládá vedoucím orgánům dohledovou odpovědnost. U poskytovatelů cloudových služeb, poskytovatelů řízených služeb, poskytovatelů řízených bezpečnostních služeb, poskytovatelů služeb datových center, poskytovatelů služeb vytvářejících důvěru, online tržišť, vyhledávačů a některých komunikačních služeb se viditelnost dílčích zpracovatelů stává součástí správy a řízení kybernetické bezpečnosti.

ISO/IEC 27001:2022 a ISO/IEC 27701:2025 převádějí tento požadavek do provozu. ISO/IEC 27001:2022 vyžaduje, aby ISMS rozuměl kontextu, požadavkům zainteresovaných stran, rizikům, plánům ošetření rizik, provozním opatřením a dokumentovaným informacím. ISO/IEC 27701:2025 rozšiřuje tuto disciplínu systému řízení do systému řízení informací o soukromí. PIMS orientovaný na zpracovatele musí prokázat, že navazující zpracování zákaznických PII je pochopené, řízené, smluvně upravené, monitorované a doložené.

Vzor Clarysec: evidovat, posoudit, oznámit, řešit námitky, smluvně upravit, navázat předávání, uchovat důkazy

Nejsilnější model správy a řízení dílčích zpracovatelů je dostatečně jednoduchý pro provozní týmy a dostatečně důsledný pro auditní testování. Clarysec používá sedm sloves:

  1. Evidovat každého současného i navrhovaného dílčího zpracovatele.
  2. Před použitím posoudit rizika v oblasti ochrany soukromí, bezpečnosti, odolnosti a závislostí.
  3. Oznámit změnu zákazníkům podle příslušné smlouvy.
  4. Řídit námitky ve sjednané lhůtě.
  5. Aktualizovat DPA, bezpečnostní přílohu a přenesené povinnosti.
  6. Navázat důkazy o hostingu, lokalitě zpracování a mezinárodním předávání.
  7. Uchovat důkazy v registrech ochrany soukromí a dodavatelů.

Prvním provozním pilířem je Politika správy soukromí pro zpracovatele, dílčí zpracovatele a třetí strany. Stanoví:

[Zpracovatel] Vlastník dodavatele / nákup MUSÍ udržovat seznam dílčích zpracovatelů a subdodavatelů používaných ke zpracování zákaznických PII v REG08 před jejich použitím a aktualizovat REG08 do 10 pracovních dnů po schválené změně.

Toto ustanovení mění seznam dílčích zpracovatelů na řízený registr. Zároveň výslovně stanoví časování: REG08 se aktualizuje před použitím a následně se obnoví do 10 pracovních dnů po schválené změně.

Tatáž politika činí oznámení zákazníkům auditovatelným:

[Zpracovatel] Vlastník dodavatele / nákup MUSÍ před použitím oznámit zákazníkovi zamýšlené nové nebo náhradní dílčí zpracovatele podle příslušné zákaznické smlouvy a zaznamenat oznámení, lhůtu pro vznesení námitek a výsledek v REG08.

Právě tento detail v mnoha programech chybí. Otázkou není pouze to, zda byla aktualizována veřejná stránka. Otázkou je, zda byli správní zákazníci informováni požadovaným způsobem, předtím než dílčí zpracovatel zpracoval jejich PII, a zda byly lhůta pro vznesení námitek a výsledek uchovány jako důkazy.

Politika také propojuje řízení změn s náležitou péčí:

[Všichni] Vlastník dodavatele / nákup MUSÍ dokončit důkazy o náležité péči v oblasti ochrany soukromí v REG08 před výběrem, obnovením nebo významnou změnou jakéhokoli vztahu se zpracovatelem, dílčím zpracovatelem nebo třetí stranou, která zpracovává PII nebo k nim přistupuje.

Významná změna může zahrnovat nahrazení infrastruktury, zapojení navazujícího analytického poskytovatele, přesun hostingových regionů, povolení přístupu pracovníků podpory z nové země, rozšíření kategorií dat nebo změnu chování služby při uchovávání údajů.

Nakonec politika uzavírá mezeru v přenesení smluvních povinností:

[Zpracovatel] Vlastník dodavatele / nákup MUSÍ zajistit, aby každá smlouva s dílčím zpracovatelem obsahovala přenesené povinnosti v oblasti ochrany soukromí, bezpečnosti, součinnosti, vrácení, výmazu, rozhraní pro incidenty a vazby na předávání, a to předtím, než dílčí zpracovatel začne zpracovávat PII.

To je důležité, protože obecný bezpečnostní dodatek nemusí vždy stačit. Povinnosti specifické pro zpracovatele musí být přeneseny dále v řetězci před zahájením zpracování.

Kde politiky Clarysec propojují ochranu soukromí, dodavatele a předávání

Správa a řízení dílčích zpracovatelů funguje pouze tehdy, když ochrana soukromí, právní agenda, bezpečnost dodavatelů a provozní řízení změn používají stejný řetězec důkazů.

Politika právního a regulačního souladu - SME stanoví pravidlo před sdílením:

Ustanovení smlouvy o zpracování osobních údajů (DPA) nebo rovnocenné smluvní podmínky musí být sjednány před jakýmkoli sdílením osobních nebo citlivých údajů.

Pro podniková prostředí Politika právního a regulačního souladu zpřesňuje očekávání na důkazy tím, že vyžaduje:

Zpřístupnění dílčích zpracovatelů a geografická prohlášení o předávání dat

Identifikuje také spouštěcí události správy a řízení týkající se:

Změn mechanismů předávání dat, dílčích zpracovatelů nebo přeshraničních toků dat

Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran stanoví:

Využití subdodavatelů podléhá předchozímu písemnému souhlasu

Pro menší organizace poskytuje Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME škálovatelnou variantu:

Omezení dalšího subdodavatelství bez schválení

Zároveň výslovně vyžaduje opětovné posouzení změn dodavatelů:

Všechny změny dodavatelů — včetně vlastnictví, typu služby, lokality hostingu nebo subdodavatelství — musí být znovu posouzeny z hlediska dopadu na riziko a relevance smlouvy.

Politika ochrany dat a soukromí zahrnuje:

Požadavky na schvalování dílčích zpracovatelů

Politika řízení rizik závislostí na dodavatelích doplňuje pohled odolnosti:

Zpřístupnění subdodavatelů: dodavatel nás musí informovat o klíčových subdodavatelích a jakýchkoli změnách v této oblasti, zejména pokud vytvářejí další vrstvy závislosti.

Společně tyto politiky vytvářejí kompletní provozní pravidlo: žádné sdílení osobních údajů bez smluvních podmínek, žádní skrytí dílčí zpracovatelé, žádné neřízené subdodavatelství, žádná neposouzená změna hostingu nebo lokality a žádné schválení bez důkazů o předávání, pokud jsou relevantní.

Jak Zenith Controls vymezuje soubor dodavatelských opatření

V Zenith Controls mapuje Clarysec správu a řízení změn dílčích zpracovatelů primárně na dodavatelská a právní opatření ISO/IEC 27002:2022. Je to důležité, protože to ukazuje, že správa a řízení dílčích zpracovatelů není jen proces ochrany soukromí. Je to také opatření v oblasti bezpečnosti informací, řízení dodavatelů, právních požadavků a odolnosti.

Opatření ISO/IEC 27002:2022Název opatřeníRole ve správě a řízení dílčích zpracovatelů
5.19Bezpečnost informací ve vztazích s dodavateliZakládá rámec řízení dodavatelských rizik pro identifikaci a řízení poskytovatelů, kteří přistupují k informacím nebo systémům
5.20Řešení bezpečnosti informací ve smlouvách s dodavateliZajišťuje, aby smlouvy zahrnovaly povinnosti v oblasti bezpečnosti, ochrany soukromí, subdodavatelství, incidentů, auditu, výmazu a předávání
5.21Řízení bezpečnosti informací v dodavatelském řetězci ICTPodporuje viditelnost navazujících závislostí ICT a rizik dodavatelského řetězce
5.22Monitorování, přezkum a řízení změn služeb dodavatelůPoskytuje provozní opatření pro opětovné posouzení změn dodavatelů, včetně nových dílčích zpracovatelů a změn hostingu
5.23Bezpečnost informací při používání cloudových služebUplatní se, pokud dílčí zpracovatelé poskytují cloudový hosting, cloudové platformy, SaaS nebo zpracování v cloudu
5.31Právní, zákonné, regulační a smluvní požadavkyPropojuje pracovní postup s GDPR, DORA, NIS2, zákaznickými DPA, povinnostmi předávání a smluvními oznamovacími povinnostmi

Zenith Controls popisuje opatření 5.22, „Monitorování, přezkum a řízení změn služeb dodavatelů“, jako preventivní opatření podporující důvěrnost, integritu a dostupnost, sladěné s konceptem kybernetické bezpečnosti Identify a provozními schopnostmi pro bezpečnost dodavatelských vztahů a ujištění informační bezpečnosti. Přesně to změna dílčího zpracovatele vyžaduje: identifikovat změnu, znovu posoudit riziko, potvrdit smluvní pokrytí a uchovat důkazy pro ujištění.

U opatření 5.20 rámuje Zenith Controls smlouvy s dodavateli jako preventivní opatření pokrývající důvěrnost, integritu a dostupnost. Sem patří podmínky DPA, bezpečnostní přílohy, doložky o subdodavatelství, práva na audit, součinnost při incidentech, vrácení a výmaz a povinnosti vazby na předávání.

U opatření 5.21 je důležitý pohled dodavatelského řetězce, protože dílčí zpracovatel může vytvořit závislost na čtvrté straně. Dodavatel SaaS se může spoléhat na poskytovatele infrastruktury, který se spoléhá na poskytovatele datové analytiky, který se spoléhá na další cloudový region nebo partnera podpory. Organizace musí řetězci rozumět natolik, aby mohla řídit rizika, závazky vůči zákazníkům a možnosti ukončení spolupráce.

30krokové vodítko: převod politiky do provozního postupu

Zenith Blueprint zařazuje dodavatelská a navazující rizika do kroku 23, Organizační opatření. Vysvětluje, že smlouvy s dodavateli obvykle řeší důvěrnost, řízení přístupu, technická a organizační opatření, lhůty pro hlášení incidentů, právo na audit, opatření pro subdodavatele a ustanovení pro ukončení smlouvy. Blueprint zdůrazňuje zásadní bod:

Struktura smlouvy je důležitá. Tato ustanovení mohou být v rámcové smlouvě o poskytování služeb, ve vyhrazené smlouvě o zpracování osobních údajů (DPA) nebo v samostatné bezpečnostní příloze. Důležité je, že existují a že jim obě strany rozumí a přijaly je.

Blueprint týmům také říká, co dělat se subdodavateli:

U každého kritického dodavatele zjistěte, zda používá subdodavatele (dílčí zpracovatele), kteří mohou přistupovat k vašim datům nebo systémům. Dokumentujte, jak jsou vaše požadavky na bezpečnost informací přenášeny na tyto strany, ať už prostřednictvím smluvních podmínek vašeho dodavatele, nebo vašich vlastních přímých doložek.

Pro správu a řízení změn dodavatelů je správným provozním sladěním opatření ISO/IEC 27002:2022 5.22:

Zaveďte jednoduchý, škálovatelný postup pro posuzování změn služeb dodavatelů (5.22), jako je migrace do cloudu, noví dílčí zpracovatelé nebo přepracování infrastruktury. Definujte spouštěcí události, které vyžadují opětovné bezpečnostní posouzení.

To dává CISO a DPO praktickou cestu. Krok 23 vymezuje záměr opatření. REG08 zachycuje důkazy týkající se zpracovatelů, dílčích zpracovatelů a třetích stran v oblasti ochrany soukromí. REG09 zachycuje důkazy o předávání. Smlouvy s dodavateli, DPA a tikety změn propojují pracovní postup s provozní realitou.

Praktický pracovní postup pro oznámení změny dílčího zpracovatele

Pracovní postup změny dílčího zpracovatele má být rutinní kontrolovaným způsobem. Každá fáze musí mít vlastníka, důkazy a kontrolní bod, který zabrání předčasnému použití v produkci.

Fáze pracovního postupuVlastníkDůkazySchvalovací bod
Příjem návrhu dílčího zpracovateleVlastník dodavatele nebo nákupPožadavek na změnu, popis služby, kategorie dat, účel zpracováníTřídění z hlediska ochrany soukromí a bezpečnosti
Náležitá péče v oblasti ochrany soukromí a bezpečnostiDPO, bezpečnost, nákupNáležitá péče v REG08, certifikace, dotazník, historie incidentů, technická a organizační opatřeníSchválení vlastníkem rizika
Přezkum smlouvy a DPAPrávní oddělení, nákupMapování ustanovení DPA, podmínky subdodavatelství, práva na audit, součinnost při incidentech, podmínky výmazuPrávní schválení
Přezkum lokality a předáváníOchrana soukromí, právní oddělení, bezpečnostLokality zpracování, lokality hostingu, mechanismus předávání, vazba na REG09Schválení předávání
Oznámení zákazníkůmTým péče o zákazníky, právní oddělení, ochrana soukromíKopie oznámení, dotčení zákazníci, smluvní základ, datum oznámení, lhůta pro vznesení námitekOznámení odesláno před použitím
Vyřízení námitekPrávní oddělení, vlastník účtu, vlastník rizikaEvidence námitek, reakce na riziko, rozhodnutí zákazníka, technické zablokování, je-li potřebaNámitka vyřešena nebo výjimka schválena
Povolení produkčního nasazeníVývoj, manažer změnTiket změny, odkazy na schválení, datum spuštění do produkčního prostředíŽádné zpracování před schválením
Aktualizace po změněVlastník dodavateleAktualizovaný REG08, veřejný seznam, pokud se používá, repozitář smluv, periodicita monitorováníPřezkum důkazů v definované SLA

Klíčová zásada je jednoduchá: pokud to smlouva vyžaduje, oznámení zákazníkům musí proběhnout před použitím. Aktualizace veřejné webové stránky po implementaci může podpořit transparentnost, ale neprokazuje zákaznicky specifické oznámení, smluvní povolení ani vyřízení námitek.

Aplikace pracovního postupu na krizi Sarah

Oznámení dodavatele Sarah o DataCrunch Analytics spouští celý proces.

Nejprve vlastník dodavatele založí záznam změny v REG08. Záznam identifikuje CoreStack, DataCrunch Analytics, účel služby, dopad na zákaznické tenanty, roli při zpracování, kategorie dat, lokality zpracování, model přístupu pracovníků podpory, dobu uchovávání a to, zda mohou být přítomny zvláštní kategorie osobních údajů nebo regulovaná data finančních zákazníků.

Zadruhé ochrana soukromí a bezpečnost provedou náležitou péči. Přezkoumají technická a organizační opatření DataCrunch Analytics, šifrování, řízení přístupu, protokolování, oznamování incidentů, možnosti výmazu, auditní ujištění, seznam dílčích zpracovatelů a bezpečnostní certifikace. Protože se poskytovatel nachází mimo EU, je přezkum lokality a předávání povinný.

Zatřetí právní oddělení ověří, zda zákaznické DPA používají konkrétní povolení nebo obecné povolení s oznámením. Zákazníci jsou rozděleni do oznamovacích skupin: zákazníci se standardní 30denní lhůtou pro oznámení, podnikoví zákazníci se 45denní lhůtou pro vznesení námitek, zákazníci vyžadující konkrétní schválení, omezení zákazníci s lokalizačními omezeními a nedotčení zákazníci, jejichž data neprocházejí analytickou pracovní zátěží.

Začtvrté se navážou důkazy o předávání. Politika správy soukromí pro zpracovatele, dílčí zpracovatele a třetí strany vyžaduje:

[Obě role] Vlastník dodavatele / nákup MUSÍ zaznamenat lokality zpracování, lokality hostingu a indikátory mezinárodního předávání v REG08 a propojit příslušné důkazy o předávání s REG09 před schválením zpracovatele, dílčího zpracovatele, změny lokality nebo změny služby relevantní pro předávání.

Zapáté tým péče o zákazníky odešle formální oznámení schválenými kanály. Každé oznámení obsahuje zamýšleného dílčího zpracovatele, účel, kategorie dat, shrnutí lokality, datum účinnosti, lhůtu pro vznesení námitek a kontaktní cestu.

Zašesté se řídí námitky. Pokud finanční instituce vznese námitku, protože změna ovlivňuje kritickou funkci nebo předávání do třetí země, tým Sarah vyhodnotí alternativy: vyloučit tenant, zachovat původní cestu zpracování, vyžadovat podporu pouze z EU, upravit smluvní záruky nebo odložit změnu, dokud nebude námitka vyřešena.

Zasedmé vývojový tým obdrží schválení pouze pro tenanty a pracovní zátěže, které prošly kontrolním bodem. Tiket produkční změny odkazuje na REG08, REG09, právní schválení, důkazy o oznámení a případná zákaznicky specifická vyloučení. Po spuštění do produkčního prostředí se aktualizují interní registr, veřejná stránka dílčích zpracovatelů a repozitář smluv.

To je rozdíl mezi reaktivním hašením problémů a obhajitelnou správou a řízením.

Mapování souladu napříč rámci pro jeden řetězec důkazů

Výhodou Clarysec je, že jeden pracovní postup může splnit požadavky více rámců, pokud jsou důkazy správně navrženy od začátku.

Oblast požadavkůJak ji pracovní postup řeší
GDPR Article 28 a odpovědnostUdržuje důkazy o povolení dílčích zpracovatelů, oznámení zákazníkům, výsledcích námitek, přenesení povinností v DPA a vazbě na předávání
ISO/IEC 27701:2025 PIMSProkazuje správu a řízení ochrany soukromí podle rolí pro zpracovatele, kontrolu navazujícího zpracování, uchovávání důkazů a monitorování
ISO/IEC 27001:2022 ISMSPodporuje požadavky zainteresovaných stran, posouzení rizik, provozní řízení, dodavatelská opatření, právní požadavky a dokumentované informace
ISO/IEC 27002:2022 opatřeníImplementuje opatření pro dodavatelské vztahy, smlouvy s dodavateli, dodavatelský řetězec ICT, změny dodavatelů, cloudové služby a právní požadavky
DORA rizika třetích stran v oblasti ICTPodporuje registry, náležitou péči, viditelnost subdodavatelského řetězce, přehled o lokalitách, riziko koncentrace, práva na audit, součinnost při incidentech a plánování ukončení spolupráce
NIS2 zabezpečení dodavatelského řetězcePodporuje zabezpečení dodavatelského řetězce podle Article 21, analýzu dodavatelských rizik, zvládání incidentů, kontinuitu činností a dohled vedení
NIST CSF 2.0 GOVERN a GV.SCSladí se se strategií dodavatelských rizik, kritičností dodavatelů, smluvními požadavky na kybernetickou bezpečnost, náležitou péčí, monitorováním, zapojením při incidentech a plánováním ukončení vztahu
COBIT 2019 pohled správy a řízeníPodporuje potřeby zainteresovaných stran, optimalizaci rizik, odpovědnost dodavatelů, reporting vedení a důkazy pro ujištění

NIST CSF 2.0 je užitečný jako neutrální organizační vrstva. Jeho funkce GOVERN zahrnuje porozumění právním, regulačním, smluvním povinnostem, povinnostem v oblasti ochrany soukromí a občanskoprávním povinnostem, přiřazení rolí, zavedení politik, přezkum výkonnosti a řízení kybernetických rizik dodavatelského řetězce. Kategorie GV.SC očekává procesy dodavatelských rizik, kritičnost dodavatelů, smluvní požadavky na kybernetickou bezpečnost, náležitou péči, monitorování v rámci životního cyklu, plánování incidentů a činnosti po ukončení vztahu.

DORA je pro finanční subjekty preskriptivnější. Articles 28 to 30 vyžadují řízení rizik třetích stran v oblasti ICT, smluvní registry, klasifikaci kritických nebo důležitých funkcí, viditelnost subdodavatelského řetězce, přehled o lokalitách, smluvní záruky, práva na audit, spolupráci při incidentech a plánování ukončení spolupráce. Pokud vaše platforma SaaS podporuje finanční zákazníky, vaše důkazy o dílčích zpracovatelích se stávají součástí jejich balíčku důkazů podle DORA.

NIS2 doplňuje odpovědnost vedení. Article 20 vyžaduje, aby vedoucí orgány schvalovaly opatření pro řízení kybernetických rizik a dohlížely na jejich implementaci. Article 21 vyžaduje zabezpečení dodavatelského řetězce a posouzení postupů kybernetické bezpečnosti dodavatelů. Významná změna dílčího zpracovatele by proto měla být viditelná v reportingu rizik, nikoli skrytá ve složce nákupu.

Co budou auditoři testovat

Vyspělý proces pro dílčí zpracovatele vytváří přímou vazbu od politiky k důkazům.

Auditor ISO/IEC 27001:2022 začne rozsahem ISMS, požadavky zainteresovaných stran, riziky, Prohlášením o použitelnosti a provozními opatřeními. Pravděpodobně bude testovat dodavatelské vztahy, smlouvy s dodavateli, dodavatelský řetězec ICT, monitorování a řízení změn dodavatelů, právní požadavky, cloudové služby, ochranu soukromí, protokolování a provozní řízení změn.

Auditor ISO/IEC 27701:2025 PIMS se zaměří na jasnost rolí. Jste zpracovatel, správce, společný správce, nebo kombinace těchto rolí u různých služeb? U činností zpracovatele bude požadovat seznam dílčích zpracovatelů, základ povolení, důkazy o oznámení, vyřízení námitek, navazující smlouvy, důkazy o předávání, podporu výmazu, rozhraní pro incidenty a záznamy z monitorování.

Přezkoumávající osoba v oblasti ochrany soukromí podle GDPR bude testovat odpovědnost. Bude se ptát, kdo zpracovává osobní údaje, za jakým účelem, podle jaké smlouvy, v jaké lokalitě, s jakými zárukami a s jakou transparentností vůči zákazníkům. Pokud zákazník vznesl námitku, bude se ptát, co se stalo před zahájením zpracování.

Zákaznický auditor podle DORA se zeptá, zda dílčí zpracovatel podporuje kritickou nebo důležitou funkci, zda jsou viditelné subdodavatelské řetězce, zda jsou dokumentovány lokality dat, zda je smluvně garantována součinnost při incidentech, zda se práva na audit přenášejí dále, zda bylo zváženo riziko koncentrace a zda je možné ukončení spolupráce.

Hodnotitel podle NIS2 se zaměří na zabezpečení dodavatelského řetězce, dohled vedení, připravenost na incidenty a přiměřená opatření. Může se ptát, jak jsou zjišťovány změny dodavatelů, jak jsou posuzováni přímí dodavatelé, jak se zohledňují zranitelnosti dodavatelů a jak se eskalují incidenty týkající se příjemců služeb.

Soubor důkazů by měl být snadno rekonstruovatelný:

  • Schválený požadavek na změnu dílčího zpracovatele.
  • Záznam o náležité péči v REG08.
  • Posouzení kategorie dat a účelu zpracování.
  • Důkazy o lokalitách zpracování a hostingu.
  • Důkazy o předávání v REG09, pokud jsou relevantní.
  • Přezkum přenesení povinností v DPA a smlouvě.
  • Seznam oznámení zákazníkům, data, znění a doklad o doručení.
  • Evidence námitek a důkazy o jejich vyřešení.
  • Tiket produkční změny navázaný na schválení.
  • Aktualizovaný seznam dílčích zpracovatelů a harmonogram monitorování.
  • Přijetí rizika nebo schválení výjimky, pokud je potřeba.

Běžné vzorce selhání

Prvním selháním je považovat stránku se seznamem dílčích zpracovatelů za celý proces. Veřejná stránka podporuje transparentnost, ale neprokazuje zákaznicky specifické oznámení, vyřízení námitek ani povolení.

Druhým selháním je oddělení důkazů ochrany soukromí, bezpečnosti a nákupu. Ochrana soukromí může schválit DPA, bezpečnost může přezkoumat report SOC 2 a nákup může založit smlouvu, ale žádný jediný záznam nepropojuje rozhodnutí.

Třetím selháním je chybějící vazba na předávání. Týmy zaznamenají název dodavatele, ale nikoli lokality zpracování, lokality hostingu, lokality podpory, indikátory mezinárodního předávání nebo důkazy v REG09.

Čtvrtým selháním je povolení produkčního nasazení před uplynutím lhůt pro vznesení námitek. Jakmile nový dílčí zpracovatel zpracovává zákaznické PII, organizace již může porušovat smlouvu.

Pátým selháním je slabé přenesení povinností. Přímý dodavatel přijme silné podmínky, ale jeho navazující poskytovatelé nejsou vázáni rovnocennými povinnostmi v oblasti ochrany soukromí, bezpečnosti, součinnosti, vrácení, výmazu, incidentů, auditu a předávání.

Šestým selháním je slabá detekce změn. Dodavatel změní vlastnictví, lokalitu hostingu, typ služby, model podpory nebo subdodavatelský řetězec a nikdo znovu neposoudí riziko.

Sedmým selháním je absence auditní stopy. Týmy si rozhodnutí pamatují, ale nemohou prokázat, kdy nastalo, kdo jej schválil, kteří zákazníci byli informováni a jak byly vyřešeny námitky.

Reporting vedení pro CISO a DPO

Správa a řízení dílčích zpracovatelů má vytvářet informace pro vedení, nikoli jen artefakty souladu.

MetrikaProč je důležitá
Aktivní dílčí zpracovatelé podle služby a kategorie datUkazuje rozsah zpracování a expozici v oblasti ochrany soukromí
Dílčí zpracovatelé podporující kritické službyPodporuje plánování odolnosti, ujištění podle DORA a prioritizaci dodavatelů
Dílčí zpracovatelé s přístupem nebo hostingem ve třetí zemiPodporuje přezkumy předávání a prohlášení zákazníkům
Nadcházející lhůty pro vznesení námitekBrání předčasnému povolení produkčního nasazení
Dílčí zpracovatelé bez aktuální náležité péčeIdentifikuje mezery v ujištění
Smlouvy bez doložek o přenesení povinnostíZvýrazňuje právní a provozní riziko
Změny dodavatelů čekající na opětovné posouzeníUkazuje zátěž a nevyřízené položky správy a řízení
Námitky zákazníků otevřené nad rámec SLAIndikuje nevyřešené obchodní, právní nebo technické blokátory

Tento reporting odpovídá modelu systému řízení. ISO/IEC 27001:2022 očekává vedení, provozní řízení, hodnocení výkonnosti a neustálé zlepšování. DORA a NIS2 posilují odpovědnost vedení. Správa a řízení dílčích zpracovatelů by se měla objevovat na řídicích jednáních k ochraně soukromí, přezkumech dodavatelských rizik, přezkoumání ISMS vedením a v reportingu rizik ICT, pokud je to relevantní.

Vytvořte balíček důkazů ke změnám dílčích zpracovatelů

Začněte jednou nedávnou změnou dodavatele a ověřte, zda vaše organizace dokáže odpovědět na tyto otázky:

  • Byl poskytovatel identifikován jako zpracovatel, dílčí zpracovatel, dodavatel, poskytovatel ICT, nebo jako více těchto rolí současně?
  • Byl REG08 nebo rovnocenný registr aktualizován před použitím?
  • Byly zaznamenány lokality zpracování a lokality hostingu?
  • Byly posouzeny indikátory mezinárodního předávání?
  • Byly důkazy o předávání navázány na REG09 nebo rovnocennou složku?
  • Obsahovala smlouva přenesené povinnosti v oblasti ochrany soukromí, bezpečnosti, součinnosti, vrácení, výmazu, incidentů, auditu a předávání?
  • Byli zákazníci informováni podle svých smluv před zahájením zpracování?
  • Byly lhůty pro vznesení námitek sledovány a vyřešeny?
  • Bylo povolení produkčního nasazení zablokováno až do schválení?
  • Dokázal by auditor rekonstruovat rozhodovací stopu do 30 minut?

Pokud je odpověď záporná, mezera není pouze právní. Je provozní, smluvní, dodavatelsky riziková, související s ochranou soukromí a týkající se připravenosti na audit.

Clarysec pomáhá týmům tuto mezeru rychle uzavřít. Použijte Zenith Blueprint k začlenění správy a řízení dílčích zpracovatelů do roadmapy implementace ISMS a PIMS. Použijte Zenith Controls k mapování opatření pro dodavatelské vztahy, smlouvy s dodavateli, dodavatelský řetězec ICT, změny dodavatelů, cloudové služby a právní požadavky napříč ISO/IEC 27001:2022, ISO/IEC 27701:2025, GDPR, DORA, NIS2, NIST CSF 2.0 a COBIT 2019. Použijte Politiku správy soukromí pro zpracovatele, dílčí zpracovatele a třetí strany, Bezpečnostní politiku dodavatelů a poskytovatelů služeb třetích stran, Politiku právního a regulačního souladu, Politiku ochrany dat a soukromí a Politiku řízení rizik závislostí na dodavatelích k převedení mapování do každodenního provádění.

Nečekejte na překvapivou poznámku pod čarou v e-mailu od dodavatele. Vybudujte pracovní postup, balíček důkazů a mapu opatření nyní, aby se každá změna dílčího zpracovatele stala důkazem vyspělé správy a řízení, nikoli krizí souladu.

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article