Správa a riadenie spoločných prevádzkovateľov: auditná príručka ku GDPR Article 26

Telefonát prišiel v utorok ráno. Pre CISO v CareConnect, rýchlo rastúcom poskytovateľovi MedTech SaaS, to bol okamih, keď sa situácia zásadne zmenila.

Na druhej strane linky bol vedúci súladu z MetroHealth, ich kľúčového nemocničného partnera. Pacient používajúci ich spoločne spravovanú platformu vzdialeného monitorovania podal mesiac predtým žiadosť dotknutej osoby o prístup k údajom. Ani jedna organizácia neodpovedala úplne. Každá sa domnievala, že zodpovednosť nesie tá druhá.

Potom právne oddelenie preposlalo druhú správu. Junior vývojár v CareConnect omylom sprístupnil nekritický API endpoint, ktorý obsahoval obmedzený rozsah identifikátorov pacientov. Problém sa zdal zvládnuteľný a 72-hodinová lehota GDPR na oznámenie porušenia ochrany údajov ešte neuplynula. Oba tímy však zastavila tá istá otázka.

Kto informuje dozorný orgán? Kto komunikuje s pacientmi? Kto zodpovedá za oznámenie o ochrane údajov? Kto overuje žiadosť dotknutej osoby? Kto zaznamenáva rozhodnutie?

Obchodná zmluva podrobne upravovala servisné kredity, fakturáciu, limity zodpovednosti a míľniky produktovej roadmapy. O prevádzkovej realite správy a riadenia spoločných prevádzkovateľov podľa GDPR Article 26 však takmer mlčala.

Práve tu zlyháva mnoho partnerstiev. Problém nie je v tom, že tímy ochrany súkromia, právneho oddelenia, bezpečnosti a obstarávania nikdy nepočuli pojem „dohoda spoločných prevádzkovateľov“. Problém je v tom, že pred začatím spracúvania nikto nevie preukázať, kto zodpovedá za transparentnosť, právny základ, práva dotknutých osôb, eskaláciu porušenia ochrany údajov, prenesené povinnosti dodávateľov, prenosy, uchovávanie, dôkazy a komunikáciu s regulátorom.

GDPR definuje povinnosť. ISO/IEC 27701:2025 poskytuje tímom ochrany súkromia štruktúru systému manažérstva. Politiky PIMS od Clarysec, Zenith Blueprint: 30-kroková roadmapa audítora a Zenith Controls: príručka súladu naprieč rámcami premieňajú Article 26 na prevádzkové dôkazy pripravené na audit.

Prečo správa a riadenie spoločných prevádzkovateľov zlyháva skôr, než si to niekto všimne

Vzťah spoločných prevádzkovateľov vzniká vtedy, keď dve alebo viaceré strany spoločne určujú účely a prostriedky spracúvania osobných údajov. Spúšťačom nie je formulácia v zmluve. Rozhodujúca je rozhodovacia právomoc.

V príklade CareConnect a MetroHealth poskytuje CareConnect platformu, analytiku, technickú architektúru, používateľské rozhranie a dátové toky. MetroHealth poskytuje vzťah s pacientom, klinický kontext, model služby a údaje pacientov. Obe strany ovplyvňujú, prečo sa osobné údaje spracúvajú a ako spracúvanie funguje. To je zásadne odlišné od dodávateľa, ktorý iba hostuje databázu alebo odosiela správy na základe zdokumentovaných pokynov.

Rovnaký vzorec sa objavuje v kampaniach finančného zdravia, partnerstvách so zabudovaným poistením, online trhoviskách, konzorciách na detekciu podvodov, prepojených zdravotníckych platformách, vernostných programoch, ekosystémoch overovania identity a analytických spoluprácach. Banka, poisťovňa a SaaS platforma môžu spoločne určovať cieľové segmenty, pravidlá profilovania, konverzné metriky a marketingové kanály. Zmluva o spracúvaní osobných údajov so sprostredkovateľom tento problém nevyrieši, ak sú strany v skutočnosti spoločnými prevádzkovateľmi.

Praktické zlyhania sú predvídateľné:

1. Oznámenie o ochrane údajov hovorí len o málo viac než „údaje môžeme zdieľať s partnermi“.
2. Evidencia spracúvania identifikuje strany, ale nie rozdelenie povinností.
3. Pracovný tok práv dotknutých osôb nemá určenú trasu na preposielanie, overovanie alebo vybavovanie žiadostí.
4. Plán reakcie na incidenty uvádza „informovať právne oddelenie“, ale neurčuje, ktorý spoločný prevádzkovateľ vedie externú komunikáciu.
5. Zmluva sa považuje za obchodnú dokumentáciu, nie za dôkaz preukázateľnej zodpovednosti.
6. Ustanovenia o ukončení nepokrývajú vrátenie údajov, výmaz, anonymizáciu, odobratie prístupu ani uchovanie dôkazov.

GDPR Article 5 robí tieto zlyhania citlivými z pohľadu auditu, pretože prevádzkovatelia musia nielen dodržiavať zásady, ako sú zákonnosť, spravodlivosť, transparentnosť, obmedzenie účelu, minimalizácia, presnosť, minimalizácia uchovávania, integrita, dôvernosť a preukázateľná zodpovednosť. Musia byť schopní súlad aj preukázať. Article 6 dopĺňa požiadavku právneho základu. Article 3 môže zahrnúť do rozsahu aj poskytovateľov SaaS, fintech, health-tech a analytiky mimo EÚ, ak ponúkajú služby fyzickým osobám v EÚ alebo monitorujú ich správanie.

Poučenie pre CISO a manažérov súladu je priame: správa a riadenie spoločných prevádzkovateľov nie je „len právna vec“. Ide o medzifunkčný kontrolný systém zahŕňajúci ochranu súkromia, bezpečnosť, obstarávanie, produkt, vývoj, podporu, reakciu na incidenty, marketing a dohľad vrcholového vedenia.

Princíp PIMS podľa ISO/IEC 27701:2025: rozhodnite pred začatím spracúvania

Systém manažérstva informácií o ochrane súkromia podľa ISO/IEC 27701:2025 funguje iba vtedy, ak sú roly v oblasti ochrany súkromia určené pred začatím spracúvania. Práve táto prevádzková disciplína zabraňuje tomu, aby sa Article 26 po incidente rekonštruoval dodatočne.

Politika systému manažérstva informácií o ochrane súkromia od Clarysec, bod 4.2.2, uvádza:

[Spoločný prevádzkovateľ] Vlastník vzťahu s dodávateľom / vlastník obstarávania MUSÍ zdokumentovať rozdelenie zodpovedností spoločných prevádzkovateľov v REG08 pred začatím spoločného spracúvania.

Formulácia „pred začatím spoločného spracúvania“ je kontrolným bodom. Znamená to pred spustením integrácie platformy do produkcie, pred povolením zdieľaného dashboardu, pred začatím synchronizácie CRM, pred aktiváciou cieľových skupín kampane a predtým, ako začnú prichádzať žiadosti dotknutých osôb.

Podporná povinnosť evidencie sa nachádza v Politike evidencie spracúvania PII a právneho základu, bod 4.3.5:

[Spoločný prevádzkovateľ] Vlastník vzťahu s dodávateľom / vlastník obstarávania MUSÍ zaznamenať účel spracúvania spoločnými prevádzkovateľmi a odkaz na rozdelenie zodpovedností v REG02 a REG08 pred začatím spracúvania spoločnými prevádzkovateľmi.

Spolu tieto body vytvárajú dôkazový reťazec, ktorý audítori očakávajú:

• REG02 zaznamenáva spracovateľskú činnosť, účel, kategórie údajov, právny základ, uchovávanie, systémy, príjemcov, prenosy a odkaz na spoločného prevádzkovateľa.
• REG08 zaznamenáva dohodu spoločných prevádzkovateľov a rozdelenie zodpovedností.
• REG07 zaznamenáva verejné zhrnutie transparentnosti.
• REG06 môže zaznamenávať prijatie žiadosti o uplatnenie práv, smerovanie, validáciu, lehoty a dôkazy o odpovedi.
• REG10 zaznamenáva rozhodnutia o posúdení incidentu a porušenia ochrany údajov.

Tento reťazec premieňa Article 26 z právneho vyhlásenia na proces systému manažérstva.

Začnite rozsahom, zainteresovanými stranami a RACI

Zenith Blueprint začína rozsahom a zainteresovanými stranami, pretože správa a riadenie spoločných prevádzkovateľov zlyháva vtedy, keď sa zainteresované strany a požiadavky identifikujú príliš neskoro.

Vo fáze základov a vedenia ISMS, krok 2, Potreby zainteresovaných strán a rozsah ISMS, Zenith Blueprint odporúča analýzu zainteresovaných strán, ktorá zachytáva explicitné aj implicitné požiadavky:

Ako identifikovať potreby a očakávania: Pre každú identifikovanú skupinu zainteresovaných strán uveďte, čo
požadujú vo vzťahu k informačnej bezpečnosti. Niektoré požiadavky sú explicitné (zákony, zmluvy,
SLA), iné sú implicitné (očakávania alebo všeobecné osvedčené postupy). Pomáha:

✓ Preskúmať právne a regulačné požiadavky uplatniteľné na váš kontext (z kontextovej
analýzy v kroku 1). Vypracujte zoznam konkrétnych bodov alebo povinností súvisiacich s informačnou
bezpečnosťou alebo ochranou súkromia.
✓ Preskúmať zmluvy a dohody: mnohé obchodné zmluvy obsahujú dodatky o dôvernosti alebo
bezpečnosti. Tieto požiadavky vyberte.
✓ Realizovať rozhovory alebo workshopy so zainteresovanými stranami: zapojte zástupcov
každej skupiny (napr. HR manažéra pre pohľad zamestnancov, manažéra predaja pre
očakávania klientov), aby ste porozumeli ich obavám alebo potrebám.
✓ Zohľadniť odvetvové normy alebo kódexy praxe, ktorých dodržiavanie zainteresované strany
očakávajú.

Pri auditovateľnej dohode spoločných prevádzkovateľov podľa GDPR Article 26 má analýza zainteresovaných strán zahŕňať zákazníkov, pacientov, používateľov, dozorné orgány, ostatné strany v roli prevádzkovateľa, sprostredkovateľov, ďalších sprostredkovateľov, poisťovne, poskytovateľov cloudu, interné útvary, regulátorov a riadiace orgány.

Krok 4, Roly a zodpovednosti v ISMS, následne premieňa túto analýzu na vlastníctvo. Zenith Blueprint zdôrazňuje hodnotu modelu RACI:

✓ Zodpovednosť za vykonanie vs. zodpovednosť za výsledok: užitočným nástrojom je matica RACI (Responsible,
Accountable, Consulted, Informed). Pre každý hlavný proces alebo kontrolu ISMS určite,
kto je Responsible (vykonáva prácu), kto je Accountable (nesie konečnú zodpovednosť, často
manažér), kto je Consulted (poskytuje vstupy) a kto je Informed.

Pre spoločných prevádzkovateľov nie je RACI v praxi voliteľné. Bez neho sa právne oddelenie domnieva, že žiadosť vybavuje tím ochrany súkromia, tím ochrany súkromia sa domnieva, že vstupný front spravuje podpora, podpora sa domnieva, že odpovie partner, a zákonná lehota ďalej plynie.

Dôkazový model Clarysec pre spoločných prevádzkovateľov

Zrelá dohoda spoločných prevádzkovateľov má byť pochopiteľná na jednej strane a preukázateľná za desať minút. Cieľom nie je zahltiť tímy právnou dokumentáciou. Cieľom je, aby boli zodpovednosti viditeľné, prijaté a testovateľné.

Politiky ochrany súkromia od Clarysec posilňujú každú vrstvu.

Politika oznámení o ochrane údajov a transparentnosti, bod 4.1.5, uvádza:

[Spoločný prevádzkovateľ] Vedúci oblasti ochrany súkromia / manažér PIMS MUSÍ zaznamenať verejné zhrnutie zodpovedností spoločných prevádzkovateľov a kontaktné miesto v REG07 pred spustením spracúvania spoločnými prevádzkovateľmi alebo jeho podstatnou zmenou.

Politika riadenia práv dotknutých osôb, bod 6.1.5, uvádza:

[Spoločný prevádzkovateľ] Vedúci oblasti ochrany súkromia / manažér PIMS MUSÍ zdokumentovať zodpovednosti za vybavovanie práv a kontaktné trasy v REG02, REG06 alebo REG08 pred začatím spracúvania spoločnými prevádzkovateľmi.

Politika riadenia incidentov a porušení ochrany PII, bod 4.2.5, dopĺňa:

[Spoločný prevádzkovateľ] Vedúci oblasti ochrany súkromia / manažér PIMS MUSÍ overiť dohodnutú zodpovednosť za porušenie ochrany údajov, vedúcu zodpovednosť za komunikáciu a koordinačné usporiadanie pred akýmkoľvek externým oznámením alebo komunikáciou spoločného prevádzkovateľa a MUSÍ zaznamenať rozhodnutie v REG08 a REG10.

Tu sa ISO/IEC 27701:2025 a GDPR stávajú prevádzkovými. Organizácia iba netvrdí, že zodpovednosti sú rozdelené. Ukazuje, kde sú zaznamenané, kto ich schválil, kedy boli otestované a ako sa používajú.

Praktický príklad: REG08 pre platformu vzdialeného monitorovania

Predpokladajme, že CareConnect a MetroHealth spoločne prevádzkujú platformu vzdialeného monitorovania. Obe strany rozhodujú, prečo sa údaje pacientov spracúvajú, ktoré údaje sa zhromažďujú, ako sú nakonfigurované monitorovacie upozornenia, ako sa používa analytika a ako pacienti so službou interagujú.

Po prvé, REG02 má zaznamenať spracovateľskú činnosť:

• Názov spracúvania: služba vzdialeného monitorovania pacientov
• Rola prevádzkovateľa: spoločný prevádzkovateľ
• Strany: CareConnect a MetroHealth
• Účel: monitorovanie pacientov, koordinácia starostlivosti, zlepšovanie služby, analytika platformy
• Kategórie PII: kontaktné údaje, identifikátory účtov, klinické pozorovania, udalosti zariadení, interakcie s podporou
• Kontrola osobitnej kategórie: spracúvajú sa údaje o zdraví a vyžadujú zvýšené ochranné opatrenia
• Právny základ: zdokumentovaný podľa strany a účelu
• Uchovávanie: definované podľa klinických, platformových, právnych a prevádzkových požiadaviek
• Systémy: mobilná aplikácia, monitorovacia platforma, nástroj podpory, analytický dátový sklad, poskytovateľ identít
• Príjemcovia: strany spoločného prevádzkovania, poskytovateľ hostingu, dodávatelia podpory, poskytovatelia notifikácií
• Prenosy: posúdený vzdialený prístup a spracúvanie mimo EHP
• Odkaz REG08: JC-2026-004

Po druhé, REG08 má rozdeliť zodpovednosti spôsobom, podľa ktorého sa prevádzkové tímy vedia riadiť.

Po tretie, REG07 má zaznamenať verejné zhrnutie. Oznámenie má jasným jazykom vysvetliť podstatu spoločného usporiadania, identifikovať spoločných prevádzkovateľov, opísať, za čo každý zodpovedá, a poskytnúť použiteľné kontaktné miesto. Nemá nútiť pacientov ani používateľov dekódovať internú prevádzkovú zložitosť.

Po štvrté, otestujte pracovný tok pred spustením. Odošlite simulovanú žiadosť o prístup na zverejnené kontaktné miesto. Potvrďte, že podpora ju identifikuje ako žiadosť dotknutej osoby o uplatnenie práv, smeruje ju tímu ochrany súkromia, skontroluje REG08, vyžiada si vstup partnera, zaznamená úkony v REG06 a vytvorí balík odpovede. Potom vykonajte stolové cvičenie k porušeniu ochrany údajov so scenárom, ako napríklad „API endpoint sprístupní identifikátory pacientov neoprávneným používateľom“ alebo „používatelia vylúčení z výmazu sú omylom zahrnutí do kampane na zapojenie“.

Tieto testy odhalia skutočné medzery: nevlastnené mailboxy, nejasné SLA partnerov, neschválený text oznámenia, neúplné záznamy právneho základu, chýbajúce kontroly osobitných kategórií a incidentné playbooky, ktoré neurčujú vedúcu osobu pre externú komunikáciu.

Mapujte Article 26 na opatrenia ISO/IEC 27002:2022 cez Zenith Controls

Dohoda spoločných prevádzkovateľov nie je len právnym artefaktom. Musí byť podporená technickými a organizačnými opatreniami. Zenith Controls pomáha tímom mapovať očakávania kontrol podľa ISO/IEC 27001:2022 a ISO/IEC 27002:2022 na dôkazy v oblasti ochrany súkromia, dodávateľov, incidentov, cloudu a správy a riadenia.

Mimoriadne relevantné sú tri opatrenia ISO/IEC 27002:2022.

Opatrenie 5.2, Roly a zodpovednosti v oblasti informačnej bezpečnosti, podporuje prevádzkový model. Nadväzuje na ISO/IEC 27001:2022 kapitolu 5.3, organizačné roly, zodpovednosti a právomoci. Podporuje aj pripravenosť na incidenty, pretože nejasné roly oslabujú ISO/IEC 27002:2022 Opatrenie 5.24, plánovanie a prípravu riadenia incidentov informačnej bezpečnosti. V správe a riadení spoločných prevádzkovateľov je Opatrenie 5.2 miestom, kde sa RACI, vlastníci REG08, osoby vybavujúce žiadosti dotknutých osôb, vedúce osoby pre porušenia ochrany údajov a eskalačné kontakty stávajú auditnými dôkazmi.

Opatrenie 5.31, Právne, zákonné, regulačné a zmluvné požiadavky, je miestom, kde sa GDPR Article 26 stáva súčasťou ISMS, a nie výlučne právnou témou. Podporuje identifikáciu a riadenie preukázateľnej zodpovednosti podľa GDPR Article 5, právneho základu podľa Article 6, rozdelenia zodpovedností podľa Article 26, bezpečnosti podľa Article 32, oznámenia dozornému orgánu podľa Article 33 a komunikácie s dotknutými osobami podľa Article 34. Nadväzuje aj na ISO/IEC 27001:2022 kapitolu 4.2, pochopenie potrieb a očakávaní zainteresovaných strán, a kapitolu 6.1.3, ošetrenie rizík informačnej bezpečnosti.

Opatrenie 5.34, Ochrana súkromia a ochrana PII, začleňuje ochranu PII do bezpečnostného prevádzkového modelu. Je mimoriadne dôležité tam, kde usporiadanie používa cloudovú analytiku, zdieľané dashboardy, data clean rooms, monitorovacie platformy, marketingovú automatizáciu alebo nástroje podpory. Súvisiace ochranné opatrenia môžu zahŕňať ISO/IEC 27002:2022 Opatrenie 5.23, informačná bezpečnosť pri používaní cloudových služieb, a Opatrenie 8.11, maskovanie údajov.

Dôležitý je aj podporný ekosystém ISO. ISO/IEC 27018 pomáha tam, kde verejné cloudové služby spracúvajú PII. ISO/IEC 29100 poskytuje princípy ochrany súkromia, ako sú transparentnosť, súhlas, oprávnený účel, obmedzenie zberu, minimalizácia údajov, obmedzenie použitia, presnosť, bezpečnostné ochranné opatrenia a preukázateľná zodpovednosť. ISO/IEC 27001:2022 poskytuje chrbticu systému manažérstva cez kontext, zainteresované strany, rozsah, vedenie, posúdenie rizík, ošetrenie rizík, Vyhlásenie o uplatniteľnosti, vnútorný audit, preskúmanie manažmentom a neustále zlepšovanie.

Zmluvy musia zodpovedať prevádzkovému modelu

Dohoda spoločných prevádzkovateľov nemôže existovať iba v oznámení o ochrane údajov. Musí sa premietnuť do zmlúv, príloh, prevádzkových postupov, incidentných playbookov, eskalačných trás a ustanovení o ukončení.

Politika právneho a regulačného súladu od Clarysec, bod 5.3.1.2, výslovne zahŕňa typy zmlúv do správy a riadenia vrátane:

Zmluvy zahŕňajúce zdieľanie údajov, práva duševného vlastníctva, obmedzenia zodpovednosti alebo auditné doložky

Politika ochrany údajov a súkromia, bod 5.1, stanovuje podnikový základ:

Organizácia musí udržiavať formálny rámec správy a riadenia ochrany súkromia integrovaný do systému manažérstva informačnej bezpečnosti (ISMS) na uplatňovanie tejto politiky.

Pre MSP sa ten istý princíp škáluje podľa prevádzkovej reality. Politika ochrany údajov a súkromia pre MSP, bod 5.2.1, uvádza:

Koordinátor ochrany súkromia musí viesť register všetkých činností spracúvania osobných údajov vrátane kategórií údajov, účelu, právneho základu a lehôt uchovávania

Bod 5.2.2 dopĺňa:

Zmluvy s tretími stranami nakladajúcimi s osobnými údajmi musia obsahovať ustanovenia o ochrane údajov a musí ich preskúmať generálny manažér alebo právny poradca

Toto je primeraná správa a riadenie. Nadnárodná organizácia môže mať samostatné tímy pre právne záležitosti, ochranu súkromia, obstarávanie, bezpečnosť, riziká a súlad. MSP sa môže spoliehať na koordinátora ochrany súkromia, generálneho manažéra a externého právneho poradcu. Očakávanie týkajúce sa dôkazov zostáva rovnaké: spracovateľské činnosti, zodpovednosti, právny základ, oznámenia, vybavovanie práv, eskalácia incidentov a povinnosti pri ukončení musia byť zdokumentované a preskúmateľné.

Zenith Blueprint, krok 23, Organizačné opatrenia, podporuje disciplínu dodávateľských dohôd prostredníctvom dôvernosti, zodpovedností za riadenie prístupu, technických a organizačných opatrení, lehôt nahlasovania incidentov, práv na audit, kontrol subdodávateľov a ustanovení na konci zmluvy. Vo vzťahoch spoločných prevádzkovateľov majú byť tieto ustanovenia prispôsobené zdieľaniu údajov a rozdeleniu zodpovedností, nie skopírované zo šablóny pre sprostredkovateľa.

Správa a riadenie incidentov a porušení ochrany údajov: určte vedúcu rolu ešte pred porušením

Porušenia ochrany údajov pri spoločných prevádzkovateľoch sa stávajú chaotickými, keď tímy čakajú až na incident, aby rozhodli, kto komunikuje navonok.

GDPR definuje porušenie ochrany osobných údajov ako porušenie bezpečnosti, ktoré vedie k náhodnému alebo nezákonnému zničeniu, strate, zmene, neoprávnenému poskytnutiu osobných údajov alebo prístupu k nim. Ak sa vyžaduje oznámenie dozornému orgánu, musí sa uskutočniť bez zbytočného odkladu a, ak je to možné, do 72 hodín od zistenia porušenia. NIS2 a DORA môžu pridať ďalšie očakávania týkajúce sa hlásenia kybernetických incidentov a komunikácie s klientmi.

Politika reakcie na incidenty pre MSP od Clarysec, bod 5.3.2, zachytáva disciplínu lehôt:

Lehoty reakcie vrátane obnovy údajov a oznamovacích povinností musia byť zdokumentované a zosúladené s právnymi požiadavkami, ako je 72-hodinová požiadavka GDPR na oznámenie porušenia ochrany osobných údajov.

Zenith Blueprint, krok 5, Komunikácia, povedomie a kompetentnosť, zdôrazňuje plánovanie externej komunikácie vrátane zákazníkov, regulátorov, partnerov a verejnosti. Pri spoločných prevádzkovateľoch má incidentná matica určiť, kto vykonáva počiatočnú klasifikáciu porušenia ochrany údajov, kto kontaktuje druhého prevádzkovateľa, kto určuje, či je dotknuté PII, kto posudzuje prahové hodnoty oznámenia, kto pripravuje oznámenia orgánu, kto komunikuje s fyzickými osobami, kto koordinuje hlásenia podľa NIS2 alebo DORA, kto schvaľuje verejné vyhlásenia a kto zaznamenáva dôkazy v REG10.

Ak usporiadanie zahŕňa finančný subjekt podľa DORA, proces incidentov má podporovať aj klasifikáciu závažného incidentu súvisiaceho s IKT, eskaláciu vrcholovému manažmentu, priebežné aktualizácie, záverečné hlásenie a komunikáciu s klientmi tam, kde sú dotknuté finančné záujmy. Ak organizácia patrí do rozsahu NIS2, hlásenie významného incidentu môže vyžadovať fázované oznámenie a komunikáciu s príjemcami služby.

Najbezpečnejším postupom je spoločné stolové cvičenie pred spustením. Dobrý scenár núti tímy používať REG08, REG10, incidentný playbook, kontakty partnerov, šablóny oznámení, eskalačné stromy a logy dôkazov pod časovým tlakom.

Súlad naprieč rámcami: Article 26 zriedka stojí osamote

Dohody spoločných prevádzkovateľov často existujú v širších regulovaných ekosystémoch. Fintech kampaň, prepojená zdravotnícka platforma, vzťah riadenej služby, integrácia cloudového trhoviska alebo partnerstvo digitálnej infraštruktúry môžu spustiť povinnosti nad rámec GDPR.

NIS2 sa môže uplatňovať na stredné a veľké základné alebo dôležité subjekty v odvetviach, ako sú digitálna infraštruktúra, cloud computing, dátové centrá, poskytovatelia riadených služieb, poskytovatelia riadených bezpečnostných služieb, online trhoviská, vyhľadávače a platformy sociálnych sietí. NIS2 Article 20 ukladá riadiacim orgánom dohľad nad riadením kybernetických rizík. Article 21 vyžaduje technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, bezpečného vývoja, riešenia zraniteľností, školení, šifrovania, bezpečnosti HR, riadenia prístupu, správy aktív a autentifikácie. Article 23 zavádza fázované hlásenie významných incidentov.

DORA sa od 17. januára 2025 uplatňuje na mnohé finančné subjekty. Pokrýva riadenie rizík IKT, hlásenie závažných incidentov súvisiacich s IKT, testovanie digitálnej prevádzkovej odolnosti, riziko IKT tretích strán, zmluvné dohody s poskytovateľmi IKT a dohľad nad kritickými externými poskytovateľmi IKT. DORA Article 5 kladie správu a riadenie rizík IKT na úroveň riadiaceho orgánu. Articles 8 to 14 pokrývajú identifikáciu aktív, ochranu, detekciu, kontinuitu, zálohovanie, obnovu, získané poučenia, školenia a krízovú komunikáciu. Articles 17 to 20 definujú životný cyklus incidentu a hlásenie. Articles 28 to 30 robia z rizika IKT tretích strán, zmluvných podmienok, registrov, rizika koncentrácie, práv na audit a plánovania ukončenia centrálne povinnosti.

NIST CSF 2.0 poskytuje praktickú integračnú vrstvu. Jeho funkcia GOVERN zahŕňa právne, regulačné, zmluvné povinnosti, povinnosti v oblasti ochrany súkromia a občianskych slobôd, zodpovednosť vedenia, apetít na riziko, politiku, dohľad a dodávateľské riziko. Výsledky ako GV.OC-03 a GV.SC-02 prirodzene nadväzujú na dôkazy podľa Article 26, pretože vyžadujú, aby boli právne povinnosti a roly partnerov pochopené, riadené, komunikované a koordinované.

Výhodou modelu Clarysec je opätovné použitie dôkazov. REG08 nie je iba záznam GDPR. Podporuje preukázateľnú zodpovednosť podľa ISO/IEC 27701:2025, správu a riadenie podľa ISO/IEC 27001:2022, jasnosť dodávateľských rolí podľa NIST CSF 2.0, správu a riadenie tretích strán podľa DORA tam, kde ide o finančné služby, a dohľad manažmentu podľa NIS2 tam, kde subjekt patrí do rozsahu.

Čo budú testovať audítori a regulátori

Rôzni posudzovatelia budú pristupovať k správe a riadeniu spoločných prevádzkovateľov z rôznych uhlov, ale zhodnú sa na rovnakej jadrovej otázke: vie organizácia preukázať, že preukázateľná zodpovednosť funguje?

Najsilnejší auditný stav poskytuje sledovateľnosť. Začnite právnou požiadavkou, prepojte ju s politikou PIMS, odkážte na záznam v registri, ukážte pracovný tok a následne ukážte dôkaz o teste alebo záznam reálneho prípadu.

Napríklad GDPR Article 26 vyžaduje rozdelenie zodpovedností spoločných prevádzkovateľov. Politika systému manažérstva informácií o ochrane súkromia vyžaduje REG08 pred začatím spracúvania. REG08 ukazuje rozdelenie zodpovedností za oznámenia, práva, porušenia ochrany údajov, uchovávanie, riadenie dodávateľov a kontakty. REG07 ukazuje verejné zhrnutie. Simulácia žiadosti dotknutej osoby preukazuje, že pracovný tok funguje. Zápisnice z preskúmania manažmentom ukazujú výnimky, rozhodnutia a zlepšenia.

Toto je auditovateľná správa a riadenie.

Preskúmanie manažmentom premieňa riziko ochrany súkromia na zodpovednosť vedenia

Správa a riadenie spoločných prevádzkovateľov nemá byť ukrytá v priečinku ochrany súkromia. Patrí do preskúmania manažmentom, pretože ovplyvňuje regulačnú expozíciu, dôveru zákazníkov, dôveru pacientov, pripravenosť na incidenty, dodávateľské riziko, zmluvnú zodpovednosť a prevádzkovú odolnosť.

ISO/IEC 27001:2022 vyžaduje záväzok vedenia, roly, zdroje, zosúladenie politík, plánovanie založené na riziku, hodnotenie výkonnosti a neustále zlepšovanie. NIS2 ukladá riadiacim orgánom povinnosti dohľadu nad kybernetickou bezpečnosťou. DORA kladie konečnú zodpovednosť za riziko IKT na riadiaci orgán finančných subjektov.

Politika rolí a zodpovedností v oblasti správy a riadenia pre MSP od Clarysec, bod 5.5, uvádza:

Všetky významné bezpečnostné rozhodnutia, výnimky a eskalácie musia byť zaznamenané a sledovateľné.

Pre podnikové organizácie Politika rolí a zodpovedností v oblasti správy a riadenia, bod 5.2, vyžaduje:

Register rolí a zodpovedností musí byť vedený a musí obsahovať:

Tento register má zahŕňať roly správy a riadenia ochrany súkromia tam, kde ovplyvňujú bezpečnosť, reakciu na incidenty, uistenie dodávateľov, prevádzkovú odolnosť a reportovanie vedeniu. Výnimky pri spoločných prevádzkovateľoch majú byť eskalované pred spustením, nie odhalené až po sťažnostiach.

Praktický balík pre preskúmanie manažmentom má obsahovať:

• Nové a zmenené dohody spoločných prevádzkovateľov
• Stav dokončenia REG08
• Vysokorizikové spracovateľské činnosti a stav DPIA, ak je uplatniteľné
• Otvorené otázky právneho základu alebo transparentnosti
• Výkonnosť pri vybavovaní žiadostí dotknutých osôb a oneskorené úkony partnerov
• Výsledky stolových cvičení k porušeniu ochrany údajov a nevyriešené medzery
• Závislosti od dodávateľov, ďalších sprostredkovateľov, cloudu a prenosov
• Výnimky z uchovávania a ukončenia
• Auditné zistenia a stav nápravy
• Dopad reportovania podľa GDPR, NIS2, DORA, NIST CSF 2.0 a COBIT 2019

Päťkrokový prístup Clarysec k auditovateľnosti Article 26

Ak vaša organizácia zdieľa rozhodovanie o spracúvaní PII s inou stranou, nečakajte na sťažnosť, audit, porušenie ochrany údajov alebo partnerský spor, aby ste vyjasnili zodpovednosti.

Použite tento päťkrokový prístup:

1. Použite Zenith Blueprint krok 2 na identifikáciu zainteresovaných strán, právnych požiadaviek, očakávaní partnerov, povinností ochrany súkromia a regulačného rozsahu.
2. Použite Zenith Blueprint krok 4 na vytvorenie RACI pre oznámenia, právny základ, práva, komunikáciu pri porušení ochrany údajov, uchovávanie, prenosy, dodávateľov, auditné dôkazy a ukončenie.
3. Zaznamenajte spracovateľskú činnosť v REG02 a rozdelenie zodpovedností spoločných prevádzkovateľov v REG08 pomocou súboru politík Clarysec PIMS.
4. Namapujte usporiadanie cez Zenith Controls, najmä ISO/IEC 27002:2022 Opatrenie 5.2, Opatrenie 5.31 a Opatrenie 5.34.
5. Otestujte usporiadanie simuláciou žiadosti dotknutej osoby a stolovým cvičením k porušeniu ochrany údajov pred začatím spracúvania.

CareConnect a MetroHealth nepotrebovali viac neformálneho zosúladenia. Potrebovali zdokumentované rozdelenie zodpovedností, verejné zhrnutie, pracovný tok práv, záznam o koordinácii pri porušení ochrany údajov, zmluvné ustanovenia a dôkazy z preskúmania manažmentom.

To je rozdiel medzi „mysleli sme si, že to rieši partner“ a „tu je schválená dohoda, oznámenie, pracovný tok, dôkazy z testovania a záznam rozhodnutia o porušení ochrany údajov“.

Clarysec vám môže pomôcť implementovať správu a riadenie PIMS podľa ISO/IEC 27701:2025, zosúladiť ju s GDPR Article 26, integrovať ju do vášho ISMS podľa ISO/IEC 27001:2022 a vytvárať dôkazy pripravené na audit naprieč očakávaniami GDPR, NIS2, DORA, NIST CSF 2.0 a COBIT 2019.

Ste pripravení nahradiť nejasnosti pri spoločných prevádzkovateľoch dôkazmi pripravenými na audit? Preskúmajte Zenith Blueprint: 30-kroková roadmapa audítora, použite Zenith Controls: príručka súladu naprieč rámcami alebo kontaktujte Clarysec pre posúdenie PIMS a ISMS, ktoré premení Article 26 na prevádzkový kontrolný systém ešte pred produkčným spustením vášho ďalšieho partnerstva.