Řízení vztahů společných správců: auditní průvodce k článku 26 GDPR

Telefonát přišel v úterý ráno. Pro CISO společnosti CareConnect, rychle rostoucího poskytovatele MedTech SaaS, to byl okamžik, kdy se situace zásadně změnila.
Na druhé straně byl vedoucí souladu z MetroHealth, jejich klíčového nemocničního partnera. Pacient využívající společně spravovanou platformu pro vzdálené monitorování podal před měsícem žádost subjektu údajů o přístup k osobním údajům. Ani jedna organizace neodpověděla v plném rozsahu. Každá předpokládala, že odpovědnost nese ta druhá.
Poté právní oddělení přeposlalo druhou zprávu. Juniorní vývojář ve společnosti CareConnect omylem zpřístupnil nekritický koncový bod API, který obsahoval omezené identifikátory pacientů. Problém vypadal zvládnutelně a 72hodinová lhůta pro oznámení porušení zabezpečení osobních údajů podle GDPR ještě neuplynula. Oba týmy však zastavila stejná otázka.
Kdo informuje dozorový úřad? Kdo komunikuje s pacienty? Kdo odpovídá za oznámení o ochraně osobních údajů? Kdo validuje žádost subjektu údajů? Kdo zaznamená rozhodnutí?
Obchodní smlouva podrobně upravovala servisní kredity, fakturaci, limity odpovědnosti a milníky produktové roadmapy. O provozní realitě řízení vztahu společných správců podle článku 26 GDPR však téměř mlčela.
Právě zde mnoho partnerství selhává. Problém není v tom, že by týmy ochrany soukromí, právní, bezpečnostní a nákupní týmy nikdy neslyšely pojem „ujednání společných správců“. Problém je v tom, že před zahájením zpracování nikdo nedokáže prokázat, kdo odpovídá za transparentnost, právní základ, práva subjektů údajů, eskalaci porušení zabezpečení osobních údajů, přenesené povinnosti vůči dodavatelům, předávání, uchovávání, důkazy a komunikaci s dozorovým úřadem.
GDPR definuje povinnost. ISO/IEC 27701:2025 poskytuje týmům ochrany soukromí strukturu systému řízení. Politiky PIMS společnosti Clarysec, Zenith Blueprint: Roadmapa auditora ve 30 krocích a Zenith Controls: Průvodce souladem napříč rámci převádějí článek 26 na provozní důkazy připravené pro audit.
Proč řízení vztahů společných správců selhává dříve, než si toho někdo všimne
Vztah společných správců vzniká tehdy, když dvě nebo více stran společně určují účely a prostředky zpracování osobních údajů. Spouštěčem není formulace smlouvy. Rozhodující je rozhodovací pravomoc.
V příkladu CareConnect a MetroHealth poskytuje CareConnect platformu, analytiku, technickou architekturu, uživatelské rozhraní a datové toky. MetroHealth poskytuje vztah s pacientem, klinický kontext, model služby a údaje pacientů. Obě strany ovlivňují, proč jsou osobní údaje zpracovávány a jak zpracování funguje. To je zásadně odlišné od dodavatele, který pouze hostuje databázi nebo odesílá zprávy podle dokumentovaných pokynů.
Stejný vzorec se objevuje u kampaní finančního zdraví, partnerství v oblasti embedded insurance, online tržišť, konsorcií pro detekci podvodů, propojených zdravotnických platforem, věrnostních programů, ekosystémů ověřování identity a analytických spoluprací. Banka, pojišťovna a SaaS platforma mohou společně rozhodovat o cílových segmentech, pravidlech profilování, metrikách konverze a marketingových kanálech. Smlouva o zpracování osobních údajů tento problém nevyřeší, pokud jsou strany ve skutečnosti společnými správci.
Praktická selhání jsou předvídatelná:
- Oznámení o ochraně osobních údajů říká jen o málo více než „můžeme sdílet údaje s partnery“.
- Evidence činností zpracování identifikuje strany, ale nikoli rozdělení odpovědností.
- Postup pro práva subjektů údajů neobsahuje trasu pro předání, validaci ani zodpovězení žádostí.
- Incidentní plán říká „informovat právní oddělení“, ale neurčuje, který společný správce vede externí komunikaci.
- Smlouva je považována za obchodní dokumentaci, nikoli za důkaz odpovědnosti.
- Ustanovení o ukončení spolupráce nepokrývají vrácení údajů, výmaz, anonymizaci, odebrání přístupu ani uchování důkazů.
Článek 5 GDPR činí tato selhání citlivými z pohledu auditu, protože správci musí nejen dodržovat zásady, jako jsou zákonnost, korektnost, transparentnost, omezení účelu, minimalizace údajů, přesnost, omezení uložení, integrita, důvěrnost a odpovědnost. Musí být také schopni soulad prokázat. Článek 6 doplňuje požadavek právního základu. Článek 3 může do působnosti zahrnout i mimoevropské poskytovatele SaaS, fintech, health-tech a analytiky, pokud nabízejí služby fyzickým osobám v EU nebo sledují jejich chování.
Poučení pro CISO a manažery souladu je přímé: řízení vztahů společných správců není „jen právní věc“. Jde o mezifunkční systém opatření zahrnující ochranu soukromí, bezpečnost, nákup, produkt, vývoj, podporu, reakci na incidenty, marketing a dohled vrcholového vedení.
Princip ISO/IEC 27701:2025 PIMS: rozhodnout před zahájením zpracování
Systém řízení informací o soukromí podle ISO/IEC 27701:2025 funguje pouze tehdy, pokud jsou role v oblasti ochrany soukromí určeny před zahájením zpracování. Právě tato provozní disciplína brání tomu, aby se článek 26 po incidentu zpětně rekonstruoval.
Politika systému řízení informací o soukromí společnosti Clarysec, kapitola 4.2.2, stanoví:
[Společný správce] Vlastník dodavatele / vlastník nákupu MUSÍ před zahájením společného zpracování zdokumentovat rozdělení odpovědností společných správců v REG08.
Formulace „před zahájením společného zpracování“ je kontrolním bodem. Znamená to před spuštěním integrace platformy do produkčního prostředí, před povolením sdíleného řídicího panelu, před zahájením synchronizace CRM, před aktivací publik kampaně a před tím, než začnou přicházet žádosti subjektů údajů.
Podpůrná povinnost evidence je uvedena v Politice evidence zpracování PII a právního základu, kapitola 4.3.5:
[Společný správce] Vlastník dodavatele / vlastník nákupu MUSÍ před zahájením zpracování společnými správci zaznamenat účel zpracování společnými správci a odkaz na rozdělení odpovědností v REG02 a REG08.
Tato ustanovení společně vytvářejí řetězec důkazů, který auditoři očekávají:
- REG02 zaznamenává činnost zpracování, účel, kategorie údajů, právní základ, uchovávání, systémy, příjemce, předávání a odkaz na společného správce.
- REG08 zaznamenává ujednání společných správců a rozdělení odpovědností.
- REG07 zaznamenává veřejně dostupné shrnutí transparentnosti.
- REG06 může zaznamenávat příjem žádostí o uplatnění práv, směrování, validaci, lhůty a důkazy o odpovědi.
- REG10 zaznamenává rozhodnutí o posouzení incidentů a porušení zabezpečení osobních údajů.
Tento řetězec převádí článek 26 z právního prohlášení na proces systému řízení.
Začněte rozsahem, zainteresovanými stranami a RACI
Zenith Blueprint začíná rozsahem a zainteresovanými stranami, protože řízení vztahů společných správců selhává, pokud jsou zainteresované strany a požadavky identifikovány příliš pozdě.
Ve fázi Základy a vedení ISMS, krok 2, Potřeby zainteresovaných stran a rozsah ISMS, doporučuje Zenith Blueprint analýzu zainteresovaných stran, která zachytí explicitní i implicitní požadavky:
Jak identifikovat potřeby a očekávání: U každé identifikované skupiny zainteresovaných stran uveďte, co
vyžaduje ve vztahu k bezpečnosti informací. Některé požadavky jsou explicitní (právní předpisy, smlouvy,
SLA), jiné jsou implicitní (očekávání nebo obecné osvědčené postupy). Pomáhá:✓ Přezkoumat právní a regulační požadavky vztahující se na váš kontext (z kontextové
analýzy v kroku 1). Vytvořte seznam konkrétních ustanovení nebo povinností souvisejících s bezpečností
informací nebo ochranou soukromí.
✓ Přezkoumat smlouvy a dohody: mnoho obchodních smluv obsahuje ustanovení o mlčenlivosti nebo
bezpečnostní dodatky. Tyto požadavky extrahujte.
✓ Provést rozhovory nebo workshopy se zainteresovanými stranami: zapojte zástupce
každé skupiny (např. HR manažera pro pohled zaměstnanců, manažera prodeje pro očekávání klientů),
abyste porozuměli jejich obavám nebo potřebám.
✓ Zvažte odvětvové normy nebo kodexy praxe, jejichž dodržování od vás zainteresované strany očekávají.
U auditovatelného ujednání společných správců podle článku 26 GDPR má analýza zainteresovaných stran zahrnovat zákazníky, pacienty, uživatele, dozorové úřady, ostatní strany v roli správce, zpracovatele, dílčí zpracovatele, pojišťovny, poskytovatele cloudových služeb, interní útvary, regulační orgány a vedoucí orgány.
Krok 4, Role a odpovědnosti v ISMS, následně převádí tuto analýzu na vlastnictví. Zenith Blueprint zdůrazňuje hodnotu modelu RACI:
✓ Odpovědnost za provedení vs. odpovědnost za výsledek: užitečným nástrojem je zde matice RACI (Responsible,
Accountable, Consulted, Informed). U každého hlavního procesu nebo opatření ISMS určete,
kdo je Responsible (provádí práci), kdo je Accountable (nese konečnou odpovědnost, často
manažer), kdo je Consulted (poskytuje vstupy) a kdo je Informed (je informován).
U společných správců není RACI v praxi volitelná. Bez ní právní oddělení předpokládá, že žádost vyřizuje tým ochrany soukromí, tým ochrany soukromí předpokládá, že příjem zajišťuje podpora, podpora předpokládá, že odpoví partner, a zákonná lhůta dál běží.
Důkazní model Clarysec pro společné správce
Vyspělé ujednání společných správců má být pochopitelné na jedné stránce a prokazatelné během deseti minut. Cílem není zahlcovat týmy právní dokumentací. Cílem je učinit odpovědnosti viditelnými, akceptovanými a testovatelnými.
| Důkazní objekt | Co prokazuje | Umístění v nástrojové sadě Clarysec | Vlastník |
|---|---|---|---|
| Záznam o určení role | Proč jsou strany společnými správci, a nikoli zpracovateli nebo samostatnými správci | Určení role PIMS, REG08 | Vedoucí pro ochranu soukromí nebo vlastník dodavatele |
| Záznam v evidenci činností zpracování | Účel, kategorie PII, právní základ, uchovávání, systémy, příjemci a předávání | REG02 | Vedoucí pro ochranu soukromí nebo právní oddělení |
| Rozdělení odpovědností | Kdo zajišťuje oznámení, práva, koordinaci porušení zabezpečení osobních údajů, uchovávání, předávání, bezpečnostní kontakty a podporu auditu | REG08 | Vlastník dodavatele nebo nákupu |
| Veřejné shrnutí | Jak jsou fyzické osoby informovány o podstatě ujednání a kontaktním místě | REG07 | Vedoucí pro ochranu soukromí nebo manažer PIMS |
| Postup pro práva | Příjem, validace, směrování, součinnost partnera, vlastník odpovědi, lhůty a důkazy | REG06 nebo registr DSR | Vedoucí pro ochranu soukromí a podpora |
| Záznam o koordinaci porušení zabezpečení osobních údajů | Vedoucí oznamovatel, vlastník komunikace, log rozhodnutí, klasifikace incidentu a důkazy | REG10 | Manažer incidentů a vedoucí pro ochranu soukromí |
| Smluvní ustanovení | Sdílení údajů, odpovědnost, audit, mlčenlivost, bezpečnost, předávání, ukončení a pravidla pro subdodavatele | Registr smluv | Právní oddělení a nákup |
Politiky ochrany soukromí Clarysec posilují každou vrstvu.
Politika oznámení o ochraně osobních údajů a transparentnosti, kapitola 4.1.5, stanoví:
[Společný správce] Vedoucí pro ochranu soukromí / manažer PIMS MUSÍ před spuštěním zpracování společnými správci nebo jeho významnou změnou zaznamenat veřejně dostupné shrnutí odpovědností společných správců a kontaktní místo v REG07.
Politika řízení práv subjektů PII, kapitola 6.1.5, stanoví:
[Společný správce] Vedoucí pro ochranu soukromí / manažer PIMS MUSÍ před zahájením zpracování společnými správci zdokumentovat odpovědnosti za vyřizování práv a kontaktní trasy v REG02, REG06 nebo REG08.
Politika řízení incidentů a porušení zabezpečení PII, kapitola 4.2.5, doplňuje:
[Společný správce] Vedoucí pro ochranu soukromí / manažer PIMS MUSÍ před jakýmkoli externím oznámením nebo komunikací ze strany společného správce ověřit dohodnutou odpovědnost za porušení zabezpečení, odpovědnost za vedení komunikace a koordinační ujednání a MUSÍ zaznamenat rozhodnutí v REG08 a REG10.
V tomto bodě se ISO/IEC 27701:2025 a GDPR stávají provozní realitou. Organizace pouze netvrdí, že odpovědnosti jsou rozděleny. Ukazuje, kde jsou zaznamenány, kdo je schválil, kdy byly otestovány a jak se používají.
Praktický příklad: REG08 pro platformu vzdáleného monitorování
Předpokládejme, že CareConnect a MetroHealth společně provozují platformu pro vzdálené monitorování. Obě strany rozhodují, proč jsou údaje pacientů zpracovávány, jaké údaje se shromažďují, jak jsou konfigurována monitorovací upozornění, jak se používá analytika a jak pacienti se službou interagují.
Nejprve má REG02 zaznamenat činnost zpracování:
- Název zpracování: služba vzdáleného monitorování pacientů
- Role správce: společný správce
- Strany: CareConnect a MetroHealth
- Účel: monitorování pacientů, koordinace péče, zlepšování služby, analytika platformy
- Kategorie PII: kontaktní údaje, identifikátory účtů, klinická pozorování, události zařízení, interakce s podporou
- Kontrola zvláštních kategorií: zpracovávají se údaje o zdraví a vyžadují zvýšená ochranná opatření
- Právní základ: zdokumentovaný podle strany a účelu
- Uchovávání: definované podle klinických, platformních, právních a provozních požadavků
- Systémy: mobilní aplikace, monitorovací platforma, nástroj podpory, analytický warehouse, poskytovatel identity
- Příjemci: strany v roli společných správců, poskytovatel hostingu, dodavatelé podpory, poskytovatelé oznámení
- Předávání: posouzen vzdálený přístup a zpracování mimo EHP
- Odkaz REG08: JC-2026-004
Dále má REG08 rozdělit odpovědnosti způsobem, podle kterého mohou operátoři postupovat.
| Oblast odpovědnosti | CareConnect | MetroHealth | Důkazy |
|---|---|---|---|
| Návrh oznámení o ochraně osobních údajů | Poskytuje technické podrobnosti zpracování | Vede textaci určenou pacientům a zveřejnění | Záznam o oznámení REG07 |
| Záznam právního základu | Dokumentuje základ pro analytiku platformy | Dokumentuje základ pro poskytování péče a vztah s pacientem | Záznam právního základu REG02 |
| Žádosti subjektů údajů o přístup k osobním údajům | Poskytuje exporty dat z platformy v dohodnutém SLA | Vede příjem, validaci, ověření identity a odpověď | Workflow REG06 |
| Žádosti o opravu a výmaz | Provádí schválené změny v systémech platformy | Určuje nakládání s klinickým záznamem a komunikaci s pacientem | Log důkazů DSR |
| Posouzení porušení zabezpečení osobních údajů | Detekuje, omezuje a klasifikuje incidenty platformy | Posuzuje dopad na pacienty a regulační komunikaci | Záznam o porušení zabezpečení REG10 |
| Externí oznámení | Vede komunikaci u incidentů pocházejících z platformy, pokud je tak dohodnuto | Vede kontakt s pacienty a orgány, pokud je tak dohodnuto | REG08 a incidentní playbook |
| Bezpečnostní ochranná opatření | Udržuje opatření platformy, protokolování, přístup a cloudovou bezpečnost | Udržuje přístup a provozní opatření na straně nemocnice | SoA a důkazy o opatřeních |
| Řízení zpracovatelů | Řídí cloudové a SaaS dílčí zpracovatele | Řídí nemocniční zpracovatele a navazující příjemce | Registr dodavatelů |
| Uchovávání a výmaz | Maže nebo anonymizuje záznamy platformy podle harmonogramu | Potvrzuje pravidla klinického uchovávání a navazujícího výmazu | Registr uchovávání |
| Auditní důkazy | Poskytuje logy, politiky, výsledky testů a osvědčení | Poskytuje schválení v oblasti řízení a právní záznamy | Tracker auditních požadavků |
Následně má REG07 zaznamenat veřejně dostupné shrnutí. Oznámení má srozumitelně vysvětlit podstatu společného ujednání, identifikovat společné správce, popsat odpovědnosti každého z nich a poskytnout použitelné kontaktní místo. Nemá pacienty ani uživatele nutit dekódovat interní provozní složitost.
Nakonec workflow před spuštěním otestujte. Odešlete simulovanou žádost o přístup na zveřejněné kontaktní místo. Ověřte, že podpora ji identifikuje jako žádost o uplatnění práv subjektu údajů, předá ji týmu ochrany soukromí, zkontroluje REG08, vyžádá vstup partnera, zaznamená úkony v REG06 a vytvoří balíček odpovědi. Poté proveďte tabletop cvičení k porušení zabezpečení osobních údajů se scénářem, jako je „koncový bod API zpřístupní identifikátory pacientů neoprávněným uživatelům“ nebo „uživatelé s potlačením výmazu jsou omylem zahrnuti do engagement kampaně“.
Tyto testy odhalují skutečné mezery: nevlastněné poštovní schránky, nejasná SLA partnerů, neschválený text oznámení, neúplné záznamy právního základu, chybějící kontroly zvláštních kategorií a incidentní playbooky, které neurčují vedoucí osobu pro externí komunikaci.
Namapujte článek 26 na opatření ISO/IEC 27002:2022 prostřednictvím Zenith Controls
Ujednání společných správců není pouze právní artefakt. Musí být podpořeno technickými a organizačními opatřeními. Zenith Controls pomáhá týmům mapovat očekávání opatření ISO/IEC 27001:2022 a ISO/IEC 27002:2022 na důkazy v oblasti ochrany soukromí, dodavatelů, incidentů, cloudu a řízení.
Zvláště relevantní jsou tři opatření ISO/IEC 27002:2022.
Opatření 5.2, Role a odpovědnosti v oblasti bezpečnosti informací, podporuje provozní model. Navazuje na ISO/IEC 27001:2022 kapitola 5.3, Organizační role, odpovědnosti a pravomoci. Podporuje také připravenost na incidenty, protože nejasné role oslabují ISO/IEC 27002:2022 opatření 5.24, plánování a přípravu řízení incidentů informační bezpečnosti. V řízení vztahů společných správců je opatření 5.2 místem, kde se RACI, vlastníci REG08, osoby vyřizující DSR, vedoucí pro porušení zabezpečení osobních údajů a eskalační kontakty stávají auditními důkazy.
Opatření 5.31, Právní, zákonné, regulační a smluvní požadavky, je místem, kde se článek 26 GDPR stává součástí ISMS, nikoli pouze právním tématem. Podporuje identifikaci a řízení odpovědnosti podle článku 5 GDPR, právního základu podle článku 6, rozdělení odpovědností podle článku 26, zabezpečení podle článku 32, oznámení dozorovému úřadu podle článku 33 a komunikaci s dotčenými fyzickými osobami podle článku 34. Navazuje také na ISO/IEC 27001:2022 kapitola 4.2, porozumění potřebám a očekáváním zainteresovaných stran, a kapitola 6.1.3, ošetření rizik bezpečnosti informací.
Opatření 5.34, Ochrana soukromí a ochrana PII, začleňuje ochranu PII do provozního modelu bezpečnosti. Je obzvlášť důležité tam, kde ujednání využívá cloudovou analytiku, sdílené řídicí panely, data clean rooms, monitorovací platformy, marketingovou automatizaci nebo nástroje podpory. Související ochranná opatření mohou zahrnovat ISO/IEC 27002:2022 opatření 5.23, bezpečnost informací při používání cloudových služeb, a opatření 8.11, maskování dat.
Důležitý je i podpůrný ekosystém ISO. ISO/IEC 27018 pomáhá tam, kde veřejné cloudové služby zpracovávají PII. ISO/IEC 29100 poskytuje zásady ochrany soukromí, jako jsou transparentnost, souhlas, legitimní účel, omezení shromažďování, minimalizace dat, omezení použití, přesnost, bezpečnostní ochranná opatření a odpovědnost. ISO/IEC 27001:2022 poskytuje páteř systému řízení prostřednictvím kontextu, zainteresovaných stran, rozsahu, vedení, posouzení rizik, ošetření rizik, Prohlášení o použitelnosti, interního auditu, přezkoumání vedením a neustálého zlepšování.
Smlouvy musí odpovídat provoznímu modelu
Ujednání společných správců nemůže existovat pouze v oznámení o ochraně osobních údajů. Musí se promítnout do smluv, příloh, provozních postupů, incidentních playbooků, eskalačních tras a ustanovení o ukončení spolupráce.
Politika právního a regulačního souladu společnosti Clarysec, kapitola 5.3.1.2, výslovně zahrnuje do řízení typy smluv, včetně:
Smluv zahrnujících sdílení údajů, práva duševního vlastnictví, omezení odpovědnosti nebo auditní doložky
Politika ochrany dat a soukromí, kapitola 5.1, stanoví podnikový základ:
Organizace musí udržovat formální rámec řízení ochrany soukromí integrovaný do systému řízení bezpečnosti informací (ISMS), aby prosazovala tuto politiku.
U SME je stejný princip přizpůsoben provozní realitě. Politika ochrany dat a soukromí – SME, kapitola 5.2.1, stanoví:
Koordinátor ochrany soukromí musí udržovat registr všech činností zpracování osobních údajů, včetně kategorií údajů, účelu, právního základu a dob uchovávání
Kapitola 5.2.2 doplňuje:
Smlouvy s třetími stranami nakládajícími s osobními údaji musí obsahovat ustanovení o ochraně údajů a musí být přezkoumány generálním ředitelem nebo právním poradcem
To je přiměřené řízení. Nadnárodní společnost může mít samostatné právní týmy, týmy ochrany soukromí, nákupu, bezpečnosti, rizik a souladu. SME se může spoléhat na koordinátora ochrany soukromí, generálního ředitele a externího právního poradce. Očekávání týkající se důkazů zůstává stejné: činnosti zpracování, odpovědnosti, právní základ, oznámení, vyřizování práv, eskalace incidentů a povinnosti při ukončení musí být zdokumentované a přezkoumatelné.
Zenith Blueprint, krok 23, Organizační opatření, podporuje disciplínu ve smlouvách s dodavateli prostřednictvím mlčenlivosti, odpovědností za řízení přístupu, technických a organizačních opatření, lhůt pro hlášení incidentů, práv na audit, kontrol subdodavatelů a ustanovení při ukončení smlouvy. Ve vztazích společných správců mají být tato ustanovení přizpůsobena sdílení údajů a rozdělení odpovědností, nikoli zkopírována ze šablony pro zpracovatele.
Řízení incidentů a porušení zabezpečení osobních údajů: určete vedoucí roli před porušením
Porušení zabezpečení osobních údajů u společných správců se stává chaotickým, pokud týmy čekají až na incident, aby rozhodly, kdo komunikuje navenek.
GDPR definuje porušení zabezpečení osobních údajů jako porušení zabezpečení, které vede k náhodnému nebo protiprávnímu zničení, ztrátě, změně, neoprávněnému zpřístupnění osobních údajů nebo přístupu k nim. Je-li to vyžadováno, oznámení dozorovému úřadu musí proběhnout bez zbytečného odkladu a, je-li to možné, do 72 hodin od okamžiku zjištění porušení. NIS2 a DORA mohou přidat další očekávání pro oznamování kybernetických incidentů a komunikaci s klienty.
Politika reakce na incidenty – SME společnosti Clarysec, kapitola 5.3.2, zachycuje disciplínu lhůt:
Lhůty reakce, včetně obnovy dat a oznamovacích povinností, musí být zdokumentovány a sladěny s právními požadavky, například s 72hodinovým požadavkem GDPR na oznámení porušení zabezpečení osobních údajů.
Zenith Blueprint, krok 5, Komunikace, povědomí a kompetence, zdůrazňuje plánování externí komunikace, včetně zákazníků, regulačních orgánů, partnerů a veřejnosti. U společných správců má incidentní matice určit, kdo provádí počáteční klasifikaci porušení zabezpečení, kdo kontaktuje druhého správce, kdo určuje, zda je dotčeno PII, kdo posuzuje prahové hodnoty pro oznámení, kdo připravuje oznámení orgánům, kdo komunikuje s fyzickými osobami, kdo koordinuje hlášení podle NIS2 nebo DORA, kdo schvaluje veřejná vyjádření a kdo zaznamenává důkazy v REG10.
Pokud ujednání zahrnuje finanční subjekt podle DORA, incidentní proces má podporovat také klasifikaci závažného incidentu souvisejícího s IKT, eskalaci k vrcholovému vedení, průběžné aktualizace, závěrečné hlášení a komunikaci s klienty tam, kde jsou dotčeny finanční zájmy. Pokud organizace spadá do působnosti NIS2, hlášení významného incidentu může vyžadovat postupné oznámení a komunikaci s příjemci služby.
Nejbezpečnější praxí je společné tabletop cvičení před spuštěním. Dobrý scénář donutí týmy používat REG08, REG10, incidentní playbook, kontakty partnerů, šablony oznámení, eskalační stromy a logy důkazů pod časovým tlakem.
Soulad napříč rámci: článek 26 málokdy stojí samostatně
Ujednání společných správců často existují v širších regulovaných ekosystémech. Fintech kampaň, propojená zdravotnická platforma, vztah řízených služeb, integrace cloudového tržiště nebo partnerství v digitální infrastruktuře mohou spustit povinnosti nad rámec GDPR.
NIS2 se může vztahovat na střední a velké základní nebo důležité subjekty v odvětvích, jako jsou digitální infrastruktura, cloud computing, datová centra, poskytovatelé řízených služeb, poskytovatelé řízených bezpečnostních služeb, online tržiště, vyhledávače a platformy sociálních sítí. NIS2 Article 20 ukládá vedoucím orgánům dohled nad řízením rizik kybernetické bezpečnosti. Article 21 vyžaduje technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného vývoje, řešení zranitelností, školení, šifrování, bezpečnosti HR, řízení přístupu, správy aktiv a autentizace. Article 23 zavádí postupné hlášení významných incidentů.
DORA se od 17. ledna 2025 vztahuje na mnoho finančních subjektů. Pokrývá řízení rizik v oblasti ICT, hlášení závažných incidentů souvisejících s IKT, testování digitální provozní odolnosti, rizika ICT třetích stran, smluvní ujednání s poskytovateli ICT a dohled nad kritickými poskytovateli služeb ICT z řad třetích stran. DORA Article 5 ukládá správu a řízení rizik ICT na úrovni vedoucího orgánu. Articles 8 to 14 pokrývají identifikaci aktiv, ochranu, detekci, kontinuitu, zálohování, obnovu, získané poznatky, školení a krizovou komunikaci. Articles 17 to 20 definují životní cyklus incidentu a hlášení. Articles 28 to 30 činí z rizik ICT třetích stran, smluvních podmínek, registrů, rizika koncentrace, práv na audit a plánování ukončení spolupráce centrální povinnosti.
NIST CSF 2.0 poskytuje praktickou integrační vrstvu. Jeho funkce GOVERN zahrnuje právní, regulační, smluvní povinnosti i povinnosti v oblasti ochrany soukromí a občanských svobod, odpovědnost vedení, ochotu podstupovat riziko, politiku, dohled a dodavatelské riziko. Výstupy jako GV.OC-03 a GV.SC-02 přirozeně ladí s důkazy k článku 26, protože vyžadují, aby právní povinnosti a role partnerů byly pochopeny, řízeny, komunikovány a koordinovány.
| Perspektiva souladu | Na co se ptá u ujednání společných správců | Důkazy Clarysec |
|---|---|---|
| GDPR | Kdo určuje účely a prostředky, jak jsou rozděleny odpovědnosti, jak jsou informovány fyzické osoby a jak jsou řešena práva a porušení zabezpečení osobních údajů | REG02, REG07, REG08, REG10, logy DSR |
| ISO/IEC 27701:2025 PIMS | Zda jsou role v ochraně soukromí, záznamy o zpracování, právní základ, transparentnost, postupy pro práva, zvládání incidentů a důkazy odpovědnosti řízeny systematicky | Politiky PIMS, registry, důkazy z přezkoumání vedením |
| ISO/IEC 27001:2022 | Zda jsou právní požadavky, povinnosti ochrany soukromí, závislosti na dodavatelích, používání cloudu, role při incidentech a ošetření rizik zahrnuty v ISMS | Rozsah, registr zainteresovaných stran, registr rizik, SoA, důkazy k Annex A |
| NIS2 | Zda jsou správa a řízení, zvládání incidentů, dodavatelský řetězec, řízení přístupu, kontinuita, školení a hlášení integrovány | Incidentní plán, registr dodavatelů, záznamy o školení, testy kontinuity |
| DORA | Zda jsou pro finanční služby řízena rizika ICT třetích stran, hlášení incidentů, testování odolnosti, ochrana údajů a smluvní opatření | Registr ICT, smluvní ustanovení, klasifikace incidentů, plány ukončení |
| NIST CSF 2.0 | Zda jsou aktuální a cílové výsledky správy a řízení, dodavatelské riziko, reakce na incidenty a obnova definovány a měřitelné | Profil CSF, plán odstranění mezer, POA&M, registr rizik |
| COBIT 2019 | Zda jsou cíle správy a řízení, odpovědnost, měření výkonnosti a důkazy ujištění dohledatelné k podnikovým cílům | RACI, metriky opatření, reporting vedení, balíček auditních důkazů |
Výhodou modelu Clarysec je opakované použití důkazů. REG08 není pouze záznamem pro GDPR. Podporuje odpovědnost podle ISO/IEC 27701:2025, správu a řízení podle ISO/IEC 27001:2022, jasnost rolí dodavatelů podle NIST CSF 2.0, správu třetích stran podle DORA tam, kde se jedná o finanční služby, a dohled vedení podle NIS2 tam, kde je subjekt v působnosti.
Co budou auditoři a regulační orgány testovat
Různí hodnotitelé budou k řízení vztahů společných správců přistupovat z různých perspektiv, ale všichni se shodnou na stejné základní otázce: dokáže organizace prokázat, že odpovědnost funguje?
| Perspektiva auditora | Pravděpodobná auditní otázka | Důkazy, které mají být připraveny |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Jsou právní, regulační, smluvní požadavky a požadavky v oblasti ochrany soukromí, dodavatelů, incidentů a cloudu identifikovány a zahrnuty do rozsahu ISMS a ošetření rizik? | Rozsah, registr zainteresovaných stran, registr povinností v oblasti souladu, posouzení rizik, SoA, dodavatelská opatření |
| Auditor ISO/IEC 27701:2025 PIMS | Jsou určeny role PIMS a jsou odpovědnosti společných správců zdokumentovány před zahájením zpracování? | REG02, REG07, REG08, postup pro práva, záznamy o porušení zabezpečení, přezkoumání vedením |
| Auditor zaměřený na GDPR nebo přezkoumávající DPO | Dokáže organizace prokázat odpovědnost podle článku 5 a rozdělení odpovědností podle článku 26? | Ujednání společných správců, shrnutí oznámení, záznamy právního základu, logy DSR, logy rozhodnutí o porušení zabezpečení |
| Hodnotitel NIST CSF 2.0 | Jsou výsledky v oblasti ochrany soukromí, právních povinností, dodavatelů, incidentů a obnovy zastoupeny v aktuálním profilu a cílovém profilu s plánem nápravy? | Profil CSF, analýza mezer, registr rizik, POA&M, monitorování dodavatelů |
| Hodnotitel DORA | Jsou tam, kde jde o finanční služby, řízeny závislosti ICT třetích stran, hlášení incidentů, odolnost, smluvní práva a plány ukončení? | Registr smluv ICT, klasifikace incidentů, testy odolnosti, práva na audit, strategie ukončení |
| Orgán dohledu NIS2 | Schválilo a dohlíželo vedení na riziková opatření, bezpečnost dodavatelů, zvládání incidentů, kontinuitu, řízení přístupu a školení? | Zápisy ze správní rady, politiky, incidentní plán, testy kontinuity, záznamy o školení, přezkumy rizik dodavatelů |
| Auditor COBIT 2019 nebo ISACA | Je odpovědnost přiřazena, monitorována, měřena a reportována prostřednictvím struktur správy a řízení? | RACI, KPI, testování kontrol, reporting vedení, náprava problémů |
Nejsilnější auditní postoj je založen na dohledatelnosti. Začněte právním požadavkem, propojte jej s politikou PIMS, ukažte na záznam v registru, předveďte workflow a poté ukažte důkazy z testu nebo záznam reálného případu.
Například článek 26 GDPR vyžaduje rozdělení odpovědností společných správců. Politika systému řízení informací o soukromí vyžaduje REG08 před zahájením zpracování. REG08 ukazuje rozdělení odpovědností za oznámení, práva, porušení zabezpečení, uchovávání, řízení dodavatelů a kontakty. REG07 ukazuje veřejně dostupné shrnutí. Simulace DSR prokazuje, že workflow funguje. Zápis z přezkoumání vedením ukazuje výjimky, rozhodnutí a zlepšení.
To je auditovatelné řízení.
Přezkoumání vedením převádí riziko pro soukromí na odpovědnost vedení
Řízení vztahů společných správců nemá být skryto ve složce ochrany soukromí. Patří do přezkoumání vedením, protože ovlivňuje regulační expozici, důvěru zákazníků, důvěru pacientů, připravenost na incidenty, dodavatelské riziko, smluvní odpovědnost a provozní odolnost.
ISO/IEC 27001:2022 vyžaduje závazek vedení, role, zdroje, sladění politik, plánování na základě rizik, hodnocení výkonnosti a neustálé zlepšování. NIS2 ukládá vedoucím orgánům povinnosti dohledu nad kybernetickou bezpečností. DORA ukládá konečnou odpovědnost za rizika ICT vedoucímu orgánu finančních subjektů.
Politika rolí a odpovědností v oblasti správy a řízení – SME společnosti Clarysec, kapitola 5.5, stanoví:
Všechna významná bezpečnostní rozhodnutí, výjimky a eskalace musí být zaznamenány a dohledatelné.
Pro podnikové organizace Politika rolí a odpovědností v oblasti správy a řízení, kapitola 5.2, vyžaduje:
Registr rolí a odpovědností musí být udržován a musí zahrnovat:
Tento registr má zahrnovat role řízení ochrany soukromí tam, kde ovlivňují bezpečnost, reakci na incidenty, ujištění o dodavateli, provozní odolnost a reporting vedení. Výjimky společných správců mají být eskalovány před spuštěním, nikoli odhaleny až po stížnosti.
Praktický balíček pro přezkoumání vedením má zahrnovat:
- Nová a změněná ujednání společných správců
- Stav dokončení REG08
- Vysoce rizikové činnosti zpracování a stav DPIA, pokud je relevantní
- Otevřené otázky právního základu nebo transparentnosti
- Výkonnost DSR a opožděné úkony partnerů
- Výsledky tabletop cvičení k porušení zabezpečení osobních údajů a nevyřešené mezery
- Závislosti na dodavatelích, dílčích zpracovatelích, cloudu a předávání
- Výjimky z uchovávání a ukončení
- Zjištění auditu a stav nápravy
- Dopad reportingu podle GDPR, NIS2, DORA, NIST CSF 2.0 a COBIT 2019
Pětikrokový přístup Clarysec k auditovatelnosti článku 26
Pokud vaše organizace sdílí rozhodování o zpracování PII s jinou stranou, nečekejte na stížnost, audit, porušení zabezpečení osobních údajů nebo spor s partnerem, abyste vyjasnili odpovědnosti.
Použijte tento pětikrokový přístup:
- Použijte Zenith Blueprint krok 2 k identifikaci zainteresovaných stran, právních požadavků, očekávání partnerů, povinností ochrany soukromí a regulačního rozsahu.
- Použijte Zenith Blueprint krok 4 k vytvoření RACI pro oznámení, právní základ, práva, komunikaci při porušení zabezpečení osobních údajů, uchovávání, předávání, dodavatele, auditní důkazy a ukončení.
- Zaznamenejte činnost zpracování v REG02 a rozdělení odpovědností společných správců v REG08 pomocí sady politik Clarysec PIMS.
- Namapujte ujednání prostřednictvím Zenith Controls, zejména ISO/IEC 27002:2022 opatření 5.2, opatření 5.31 a opatření 5.34.
- Před zahájením zpracování otestujte ujednání simulací DSR a tabletop cvičením k porušení zabezpečení osobních údajů.
CareConnect a MetroHealth nepotřebovaly další neformální sladění. Potřebovaly zdokumentované rozdělení odpovědností, veřejně dostupné shrnutí, postup pro práva, záznam o koordinaci porušení zabezpečení osobních údajů, smluvní ustanovení a důkazy z přezkoumání vedením.
To je rozdíl mezi „mysleli jsme, že to řeší partner“ a „zde je schválené ujednání, oznámení, workflow, důkazy z testu a záznam o rozhodnutí k porušení zabezpečení osobních údajů“.
Clarysec vám může pomoci implementovat řízení ISO/IEC 27701:2025 PIMS, sladit je s článkem 26 GDPR, integrovat je do vašeho ISO/IEC 27001:2022 ISMS a vytvářet důkazy připravené pro audit napříč očekáváními GDPR, NIS2, DORA, NIST CSF 2.0 a COBIT 2019.
Jste připraveni nahradit nejasnosti kolem společných správců důkazy připravenými pro audit? Projděte si Zenith Blueprint: Roadmapa auditora ve 30 krocích, použijte Zenith Controls: Průvodce souladem napříč rámci nebo kontaktujte Clarysec kvůli posouzení PIMS a ISMS, které převede článek 26 na provozní systém opatření dříve, než vaše další partnerství přejde do produkčního provozu.
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


