Nadzór nad współadministratorami: przewodnik audytowy po GDPR Article 26

Telefon zadzwonił we wtorkowy poranek. Dla CISO w CareConnect, szybko rozwijającego się dostawcy MedTech SaaS, był to moment, w którym sytuacja zasadniczo się zmieniła.

Po drugiej stronie był kierownik ds. zgodności z MetroHealth, kluczowego partnera szpitalnego CareConnect. Pacjent korzystający ze wspólnie zarządzanej platformy zdalnego monitorowania złożył miesiąc wcześniej wniosek o dostęp do danych. Żadna z organizacji nie udzieliła pełnej odpowiedzi. Każda zakładała, że odpowiada za to druga strona.

Następnie dział prawny przekazał drugą wiadomość. Młodszy programista w CareConnect przypadkowo ujawnił niekrytyczny punkt końcowy API, który zawierał ograniczone identyfikatory pacjentów. Problem wyglądał na możliwy do opanowania, a 72-godzinne okno na zgłoszenie naruszenia zgodnie z GDPR jeszcze się nie zamknęło. Jednak to samo pytanie zatrzymało oba zespoły.

Kto informuje organ nadzorczy? Kto komunikuje się z pacjentami? Kto odpowiada za klauzulę informacyjną? Kto waliduje wniosek osoby, której dane dotyczą? Kto dokumentuje decyzję?

Umowa handlowa szczegółowo regulowała kredyty serwisowe, fakturowanie, limity odpowiedzialności i kamienie milowe roadmapy produktowej. Była niemal całkowicie milcząca w kwestii operacyjnej rzeczywistości nadzoru nad współadministratorami zgodnie z GDPR Article 26.

W tym miejscu wiele partnerstw zawodzi. Problem nie polega na tym, że zespoły ds. prywatności, prawne, bezpieczeństwa i zakupów nigdy nie słyszały określenia „uzgodnienie między współadministratorami”. Problem polega na tym, że przed rozpoczęciem przetwarzania nikt nie potrafi wykazać, kto odpowiada za przejrzystość, podstawę prawną, prawa osób, których dane dotyczą, eskalację naruszeń, obowiązki przenoszone na dalsze podmioty, transfery, okres przechowywania, dowody i komunikację z regulatorem.

GDPR definiuje obowiązek. ISO/IEC 27701:2025 daje zespołom ds. prywatności strukturę systemu zarządzania. Polityki PIMS Clarysec, Zenith Blueprint: 30-etapowa mapa drogowa audytora oraz Zenith Controls: przewodnik po zgodności przekrojowej przekształcają Article 26 w operacyjne dowody gotowe do audytu.

Dlaczego nadzór nad współadministratorami zawodzi, zanim ktokolwiek to zauważy

Relacja współadministratorów występuje wtedy, gdy co najmniej dwie strony wspólnie określają cele i sposoby przetwarzania danych osobowych. Wyzwalaczem nie jest brzmienie umowy. Jest nim rzeczywisty wpływ na decyzje dotyczące przetwarzania.

W przykładzie CareConnect i MetroHealth CareConnect zapewnia platformę, analitykę, architekturę techniczną, interfejs użytkownika i przepływy danych. MetroHealth zapewnia relację z pacjentem, kontekst kliniczny, model świadczenia usługi i dane pacjenta. Obie strony wpływają na to, dlaczego dane osobowe są przetwarzane i jak działa przetwarzanie. To sytuacja zasadniczo inna niż dostawca, który jedynie hostuje bazę danych albo wysyła wiadomości na podstawie udokumentowanych poleceń.

Ten sam wzorzec pojawia się w kampaniach dobrostanu finansowego, partnerstwach ubezpieczeń embedded, marketplace’ach internetowych, konsorcjach wykrywania oszustw, połączonych platformach zdrowotnych, programach lojalnościowych, ekosystemach weryfikacji tożsamości i współpracach analitycznych. Bank, ubezpieczyciel i platforma SaaS mogą wspólnie decydować o segmentach docelowych, regułach profilowania, metrykach konwersji i kanałach marketingowych. Umowa powierzenia przetwarzania danych nie rozwiąże tego problemu, jeżeli strony faktycznie są współadministratorami.

Typowe nieprawidłowości są przewidywalne:

1. Klauzula informacyjna mówi niewiele więcej niż „możemy udostępniać dane partnerom”.
2. Inwentarz przetwarzania identyfikuje strony, ale nie podział obowiązków.
3. Proces realizacji praw osób, których dane dotyczą, nie ma ścieżki przekazania, walidacji ani obsługi wniosków.
4. Plan reagowania na incydenty mówi „powiadomić dział prawny”, ale nie wskazuje, który współadministrator prowadzi komunikację zewnętrzną.
5. Umowa jest traktowana jako dokumentacja handlowa, a nie dowód rozliczalności.
6. Postanowienia dotyczące zakończenia współpracy nie obejmują zwrotu danych, usunięcia, anonimizacji, odebrania dostępu ani zachowania dowodów.

GDPR Article 5 sprawia, że te nieprawidłowości są istotne audytowo, ponieważ administratorzy muszą nie tylko przestrzegać zasad takich jak zgodność z prawem, rzetelność, przejrzystość, ograniczenie celu, minimalizacja, prawidłowość, ograniczenie przechowywania, integralność, poufność i rozliczalność. Muszą także być w stanie wykazać zgodność. Article 6 dodaje wymóg podstawy prawnej. Article 3 może objąć zakresem dostawców SaaS, fintech, health-tech i usług analitycznych spoza UE, jeżeli oferują usługi osobom w UE lub monitorują ich zachowanie.

Wniosek dla CISO i menedżerów zgodności jest bezpośredni: nadzór nad współadministratorami nie jest „wyłącznie sprawą działu prawnego”. To międzyfunkcyjny system kontroli obejmujący prywatność, bezpieczeństwo, zakupy, produkt, inżynierię, wsparcie, reagowanie na incydenty, marketing i nadzór kierownictwa.

Zasada PIMS ISO/IEC 27701:2025: decyzje przed rozpoczęciem przetwarzania

System zarządzania informacjami o prywatności ISO/IEC 27701:2025 działa tylko wtedy, gdy role w obszarze prywatności zostaną określone przed rozpoczęciem przetwarzania. To dyscyplina operacyjna, która zapobiega przekształceniu Article 26 w poincydentalne odtwarzanie ustaleń.

Polityka systemu zarządzania informacjami o prywatności Clarysec, klauzula 4.2.2, stanowi:

[Współadministrator] Właściciel dostawcy / właściciel zakupów MUSI udokumentować podział odpowiedzialności współadministratorów w REG08 przed rozpoczęciem wspólnego przetwarzania.

Fraza „przed rozpoczęciem wspólnego przetwarzania” jest punktem kontrolnym. Oznacza to: przed uruchomieniem integracji platformy w środowisku produkcyjnym, przed włączeniem współdzielonego pulpitu, przed rozpoczęciem synchronizacji CRM, przed aktywacją grup odbiorców kampanii i przed napływem wniosków osób, których dane dotyczą.

Wspierający obowiązek inwentaryzacyjny znajduje się w Polityce inwentarza przetwarzania PII i podstawy prawnej, klauzula 4.3.5:

[Współadministrator] Właściciel dostawcy / właściciel zakupów MUSI odnotować cel przetwarzania przez współadministratorów oraz odniesienie do podziału odpowiedzialności w REG02 i REG08 przed rozpoczęciem przetwarzania przez współadministratorów.

Łącznie klauzule te tworzą łańcuch dowodowy oczekiwany przez audytorów:

• REG02 dokumentuje czynność przetwarzania, cel, kategorie danych, podstawę prawną, okres przechowywania, systemy, odbiorców, transfery oraz odniesienie do współadministratorów.
• REG08 dokumentuje uzgodnienie między współadministratorami i podział odpowiedzialności.
• REG07 dokumentuje publiczne podsumowanie na potrzeby przejrzystości.
• REG06 może dokumentować przyjęcie wniosku o realizację praw, trasowanie, walidację, terminy i dowody odpowiedzi.
• REG10 dokumentuje decyzje dotyczące oceny incydentów i naruszeń.

Ten łańcuch przekształca Article 26 z oświadczenia prawnego w proces systemu zarządzania.

Zacznij od zakresu, interesariuszy i RACI

Zenith Blueprint rozpoczyna od zakresu i interesariuszy, ponieważ nadzór nad współadministratorami zawodzi, gdy zainteresowane strony i wymagania zostają zidentyfikowane zbyt późno.

W fazie podstaw SZBI i przywództwa, krok 2, Potrzeby interesariuszy i zakres SZBI, Zenith Blueprint rekomenduje analizę interesariuszy obejmującą wymagania wyraźne i dorozumiane:

Jak identyfikować potrzeby i oczekiwania: Dla każdej zidentyfikowanej grupy interesariuszy należy wskazać, czego
wymagają w odniesieniu do bezpieczeństwa informacji. Niektóre wymagania są wyraźne (przepisy prawa, umowy,
SLA), a inne dorozumiane (oczekiwania lub ogólne dobre praktyki). Pomocne jest:

✓ Przegląd wymagań prawnych i regulacyjnych mających zastosowanie do danego kontekstu (z analizy
kontekstu w kroku 1). Należy przygotować listę konkretnych klauzul lub obowiązków związanych z
bezpieczeństwem informacji lub prywatnością.
✓ Przegląd umów i porozumień: wiele umów biznesowych zawiera załączniki dotyczące poufności lub
bezpieczeństwa. Należy wyodrębnić te wymagania.
✓ Przeprowadzenie wywiadów lub warsztatów z interesariuszami: należy zaangażować przedstawicieli
każdej grupy (np. menedżera HR w zakresie perspektywy pracowników, menedżera sprzedaży w zakresie
oczekiwań klientów), aby zrozumieć ich obawy lub potrzeby.
✓ Uwzględnienie norm branżowych lub kodeksów postępowania, których stosowania oczekują interesariusze.

Dla audytowalnego uzgodnienia między współadministratorami zgodnie z GDPR Article 26 analiza zainteresowanych stron powinna obejmować klientów, pacjentów, użytkowników, organy nadzorcze, pozostałych administratorów, podmioty przetwarzające, podwykonawców przetwarzania, ubezpieczycieli, dostawców usług chmurowych, działy wewnętrzne, regulatorów i organy zarządzające.

Krok 4, Role i odpowiedzialności w SZBI, przekształca następnie tę analizę we własność odpowiedzialności. Zenith Blueprint podkreśla wartość modelu RACI:

✓ Rozliczalność a odpowiedzialność operacyjna: użytecznym narzędziem jest tu macierz RACI (Responsible,
Accountable, Consulted, Informed). Dla każdego głównego procesu lub środka kontrolnego SZBI należy wskazać,
kto jest Responsible (wykonuje pracę), kto jest Accountable (ponosi końcową odpowiedzialność, często
menedżer), kto jest Consulted (udziela wkładu), a kto jest Informed (otrzymuje informacje).

W przypadku współadministratorów RACI w praktyce nie jest opcjonalne. Bez niego dział prawny zakłada, że na wniosek odpowiada zespół ds. prywatności, zespół ds. prywatności zakłada, że kolejkę przyjęcia obsługuje wsparcie, wsparcie zakłada, że odpowie partner, a ustawowy termin nadal biegnie.

Model dowodowy Clarysec dla współadministratorów

Dojrzałe uzgodnienie między współadministratorami powinno być zrozumiałe na jednej stronie i możliwe do wykazania w dziesięć minut. Celem nie jest zasypanie zespołów dokumentacją prawną. Celem jest uczynienie odpowiedzialności widocznymi, zaakceptowanymi i testowalnymi.

Polityki prywatności Clarysec wzmacniają każdą warstwę.

Polityka klauzul informacyjnych i przejrzystości, klauzula 4.1.5, stanowi:

[Współadministrator] Kierownik ds. prywatności / Menedżer PIMS MUSI odnotować publiczne podsumowanie odpowiedzialności współadministratorów oraz punkt kontaktowy w REG07 przed uruchomieniem lub istotną zmianą przetwarzania przez współadministratorów.

Polityka zarządzania prawami osób, których dotyczą PII, klauzula 6.1.5, stanowi:

[Współadministrator] Kierownik ds. prywatności / Menedżer PIMS MUSI udokumentować odpowiedzialności za obsługę praw oraz ścieżki kontaktu w REG02, REG06 lub REG08 przed rozpoczęciem przetwarzania przez współadministratorów.

Polityka zarządzania incydentami i naruszeniami dotyczącymi PII, klauzula 4.2.5, dodaje:

[Współadministrator] Kierownik ds. prywatności / Menedżer PIMS MUSI zweryfikować uzgodnioną odpowiedzialność za naruszenie, wiodącą odpowiedzialność za komunikację oraz zasady koordynacji przed jakimkolwiek zewnętrznym zgłoszeniem lub komunikacją przez współadministratora oraz MUSI odnotować decyzję w REG08 i REG10.

W tym miejscu ISO/IEC 27701:2025 i GDPR stają się operacyjne. Organizacja nie tylko deklaruje, że odpowiedzialności zostały przydzielone. Pokazuje, gdzie zostały zapisane, kto je zatwierdził, kiedy je przetestowano i jak są stosowane.

Praktyczny przykład: REG08 dla platformy zdalnego monitorowania

Załóżmy, że CareConnect i MetroHealth wspólnie prowadzą platformę zdalnego monitorowania. Obie strony decydują, dlaczego dane pacjentów są przetwarzane, jakie dane są zbierane, jak konfigurowane są alerty monitorowania, jak wykorzystywana jest analityka i jak pacjenci korzystają z usługi.

Po pierwsze, REG02 powinien dokumentować czynność przetwarzania:

• Nazwa przetwarzania: usługa zdalnego monitorowania pacjentów
• Rola administratora: współadministrator
• Strony: CareConnect i MetroHealth
• Cel: monitorowanie pacjentów, koordynacja opieki, doskonalenie usługi, analityka platformy
• Kategorie PII: dane kontaktowe, identyfikatory kont, obserwacje kliniczne, zdarzenia urządzeń, interakcje ze wsparciem
• Kontrola szczególnej kategorii: przetwarzane są dane dotyczące zdrowia i wymagają podwyższonych zabezpieczeń
• Podstawa prawna: udokumentowana według strony i celu
• Okres przechowywania: określony przez wymagania kliniczne, platformowe, prawne i operacyjne
• Systemy: aplikacja mobilna, platforma monitorowania, narzędzie wsparcia, hurtownia analityczna, dostawca tożsamości
• Odbiorcy: strony będące współadministratorami, dostawca hostingu, dostawcy wsparcia, dostawcy powiadomień
• Transfery: oceniono dostęp zdalny i przetwarzanie poza EOG
• Odniesienie REG08: JC-2026-004

Po drugie, REG08 powinien przydzielać odpowiedzialność w sposób możliwy do zastosowania przez operatorów.

Po trzecie, REG07 powinien dokumentować publiczne podsumowanie. Klauzula informacyjna powinna wyjaśniać istotę wspólnego uzgodnienia prostym językiem, identyfikować współadministratorów, opisywać, za co odpowiada każda strona, i podawać użyteczny punkt kontaktowy. Nie powinna zmuszać pacjentów ani użytkowników do rozszyfrowywania złożoności wewnętrznego modelu operacyjnego.

Po czwarte, należy przetestować proces przed uruchomieniem. Wyślij symulowany wniosek o dostęp do opublikowanego punktu kontaktowego. Potwierdź, że wsparcie rozpoznaje go jako wniosek osoby, której dane dotyczą, kieruje do zespołu ds. prywatności, sprawdza REG08, żąda wkładu partnera, zapisuje działania w REG06 i przygotowuje pakiet odpowiedzi. Następnie przeprowadź ćwiczenie tabletop dotyczące naruszenia, wykorzystując scenariusz taki jak „punkt końcowy API ujawnia identyfikatory pacjentów nieuprawnionym użytkownikom” albo „użytkownicy wyłączeni z usuwania zostają przypadkowo uwzględnieni w kampanii angażującej”.

Takie testy ujawniają rzeczywiste luki: skrzynki pocztowe bez właściciela, niejasne SLA partnerów, niezatwierdzony tekst klauzuli informacyjnej, niekompletne zapisy podstawy prawnej, brak kontroli dla szczególnych kategorii danych oraz podręczniki reagowania na incydenty, które nie wskazują osoby odpowiedzialnej za komunikację zewnętrzną.

Mapuj Article 26 na środki kontrolne ISO/IEC 27002:2022 przez Zenith Controls

Uzgodnienie między współadministratorami nie jest wyłącznie artefaktem prawnym. Musi być wspierane przez środki techniczne i organizacyjne. Zenith Controls pomaga zespołom mapować oczekiwania dotyczące środków kontrolnych ISO/IEC 27001:2022 i ISO/IEC 27002:2022 na dowody dotyczące prywatności, dostawców, incydentów, chmury i ładu zarządczego.

Szczególne znaczenie mają trzy środki kontrolne ISO/IEC 27002:2022.

Środek kontrolny 5.2, Role i odpowiedzialności w bezpieczeństwie informacji, wspiera model operacyjny. Łączy się z ISO/IEC 27001:2022, klauzula 5.3, Role, odpowiedzialności i uprawnienia organizacyjne. Wspiera także gotowość do reagowania na incydenty, ponieważ niejasne role osłabiają ISO/IEC 27002:2022, środek kontrolny 5.24, Planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji. W nadzorze nad współadministratorami środek kontrolny 5.2 jest miejscem, w którym RACI, właściciele REG08, osoby obsługujące DSR, osoby odpowiedzialne za naruszenia i kontakty eskalacyjne stają się dowodami audytowymi.

Środek kontrolny 5.31, Wymagania prawne, ustawowe, regulacyjne i umowne, to miejsce, w którym GDPR Article 26 staje się częścią SZBI, a nie wyłącznie kwestią działu prawnego. Wspiera identyfikację i zarządzanie rozliczalnością z GDPR Article 5, podstawą prawną z Article 6, podziałem odpowiedzialności z Article 26, bezpieczeństwem z Article 32, zgłoszeniem do organu nadzorczego z Article 33 oraz komunikacją do osób, których dane dotyczą, z Article 34. Łączy się także z ISO/IEC 27001:2022, klauzula 4.2, zrozumienie potrzeb i oczekiwań zainteresowanych stron, oraz klauzula 6.1.3, postępowanie z ryzykiem bezpieczeństwa informacji.

Środek kontrolny 5.34, Prywatność i ochrona PII, wprowadza ochronę PII do operacyjnego modelu bezpieczeństwa. Jest szczególnie istotny, gdy uzgodnienie wykorzystuje analitykę w chmurze, współdzielone pulpity, data clean rooms, platformy monitorowania, automatyzację marketingu lub narzędzia wsparcia. Powiązane zabezpieczenia mogą obejmować ISO/IEC 27002:2022, środek kontrolny 5.23, Bezpieczeństwo informacji przy korzystaniu z usług chmurowych, oraz środek kontrolny 8.11, Maskowanie danych.

Znaczenie ma również wspierający ekosystem ISO. ISO/IEC 27018 pomaga tam, gdzie publiczne usługi chmurowe przetwarzają PII. ISO/IEC 29100 zapewnia zasady prywatności, takie jak przejrzystość, zgoda, prawnie uzasadniony cel, ograniczenie zbierania, minimalizacja danych, ograniczenie wykorzystania, prawidłowość, środki bezpieczeństwa i rozliczalność. ISO/IEC 27001:2022 zapewnia szkielet systemu zarządzania poprzez kontekst, zainteresowane strony, zakres, przywództwo, ocenę ryzyka, postępowanie z ryzykiem, Deklarację stosowania, audyt wewnętrzny, przegląd zarządzania i ciągłe doskonalenie.

Umowy muszą odpowiadać modelowi operacyjnemu

Uzgodnienie między współadministratorami nie może istnieć wyłącznie w klauzuli informacyjnej. Musi znajdować odzwierciedlenie w umowach, załącznikach, procedurach operacyjnych, podręcznikach reagowania na incydenty, ścieżkach eskalacji i postanowieniach dotyczących zakończenia współpracy.

Polityka zgodności prawnej i regulacyjnej Clarysec, klauzula 5.3.1.2, wyraźnie obejmuje nadzorem typy umów, w tym:

Umowy obejmujące udostępnianie danych, prawa własności intelektualnej, ograniczenia odpowiedzialności lub klauzule audytowe

Polityka ochrony danych i prywatności, klauzula 5.1, ustanawia fundament na poziomie przedsiębiorstwa:

Organizacja utrzymuje formalne ramy ładu prywatności zintegrowane z Systemem Zarządzania Bezpieczeństwem Informacji (SZBI) w celu egzekwowania niniejszej polityki.

W przypadku MŚP ta sama zasada jest skalowana do rzeczywistości operacyjnej. Polityka ochrony danych i prywatności dla MŚP, klauzula 5.2.1, stanowi:

Koordynator ds. prywatności musi utrzymywać rejestr wszystkich czynności przetwarzania danych osobowych, obejmujący kategorie danych, cel, podstawę prawną i okresy przechowywania

Klauzula 5.2.2 dodaje:

Umowy ze stronami trzecimi przetwarzającymi dane osobowe muszą zawierać klauzule ochrony danych i muszą być przeglądane przez GM lub doradcę prawnego

To proporcjonalny ład zarządczy. Organizacja międzynarodowa może mieć odrębne zespoły prawne, prywatności, zakupów, bezpieczeństwa, ryzyka i zgodności. MŚP może polegać na Koordynatorze ds. prywatności, Dyrektorze Generalnym i zewnętrznym doradcy prawnym. Oczekiwanie dowodowe pozostaje takie samo: czynności przetwarzania, odpowiedzialności, podstawa prawna, klauzule informacyjne, obsługa praw, eskalacja incydentów i obowiązki przy zakończeniu współpracy muszą być udokumentowane i możliwe do przeglądu.

Zenith Blueprint, krok 23, Kontrole organizacyjne, wspiera dyscyplinę umów z dostawcami poprzez poufność, odpowiedzialności za kontrolę dostępu, środki techniczne i organizacyjne, terminy zgłaszania incydentów, prawa audytu, kontrole podwykonawców i postanowienia końcowe. W relacjach współadministratorów klauzule te należy dostosować do udostępniania danych i podziału odpowiedzialności, a nie kopiować z szablonu dla podmiotu przetwarzającego.

Nadzór nad incydentami i naruszeniami: wskaż prowadzącego przed naruszeniem

Naruszenia u współadministratorów stają się chaotyczne, gdy zespoły czekają do incydentu, aby zdecydować, kto komunikuje się na zewnątrz.

GDPR definiuje naruszenie ochrony danych osobowych jako naruszenie bezpieczeństwa prowadzące do przypadkowego lub niezgodnego z prawem zniszczenia, utraty, zmiany, nieuprawnionego ujawnienia danych osobowych lub dostępu do nich. Jeżeli jest wymagane, zgłoszenie do organu nadzorczego musi nastąpić bez zbędnej zwłoki i, o ile jest to wykonalne, w ciągu 72 godzin od uzyskania wiedzy o naruszeniu. NIS2 i DORA mogą dodać dodatkowe oczekiwania dotyczące zgłaszania cyberincydentów i komunikacji z klientami.

Polityka reagowania na incydenty dla MŚP Clarysec, klauzula 5.3.2, ujmuje dyscyplinę czasową:

Harmonogramy reagowania, w tym odzyskiwanie danych i obowiązki zgłoszeniowe, muszą być udokumentowane i zgodne z wymaganiami prawnymi, takimi jak wymóg zgłoszenia naruszenia ochrony danych osobowych w ciągu 72 godzin zgodnie z GDPR.

Zenith Blueprint, krok 5, Komunikacja, świadomość i kompetencje, podkreśla planowanie komunikacji zewnętrznej, w tym z klientami, regulatorami, partnerami i opinią publiczną. W przypadku współadministratorów macierz incydentów powinna wskazywać, kto dokonuje wstępnej klasyfikacji naruszenia, kto kontaktuje się z drugim administratorem, kto ustala, czy dotyczy ono PII, kto ocenia progi zgłoszeniowe, kto przygotowuje zgłoszenia do organu, kto komunikuje się z osobami fizycznymi, kto koordynuje zgłoszenia NIS2 lub DORA, kto zatwierdza komunikaty publiczne i kto zapisuje dowody w REG10.

Jeżeli uzgodnienie dotyczy podmiotu finansowego objętego DORA, proces incydentowy powinien także wspierać klasyfikację poważnych incydentów związanych z ICT, eskalację do kierownictwa wyższego szczebla, aktualizacje pośrednie, raportowanie końcowe oraz komunikację z klientami, gdy dotknięte są ich interesy finansowe. Jeżeli organizacja podlega NIS2, zgłaszanie znaczących incydentów może wymagać etapowych zgłoszeń i komunikacji z odbiorcami usług.

Najbezpieczniejszą praktyką jest wspólne ćwiczenie tabletop przed uruchomieniem. Dobry scenariusz zmusza zespoły do użycia REG08, REG10, podręcznika reagowania na incydenty, kontaktów partnera, szablonów zgłoszeń, drzew eskalacji i rejestrów dowodów pod presją czasu.

Zgodność przekrojowa: Article 26 rzadko funkcjonuje samodzielnie

Uzgodnienia między współadministratorami często są osadzone w szerszych ekosystemach regulowanych. Kampania fintech, połączona platforma zdrowotna, relacja usług zarządzanych, integracja z marketplace’em chmurowym albo partnerstwo w zakresie infrastruktury cyfrowej mogą uruchamiać obowiązki wykraczające poza GDPR.

NIS2 może mieć zastosowanie do średnich i dużych podmiotów kluczowych lub ważnych w sektorach takich jak infrastruktura cyfrowa, przetwarzanie w chmurze, centra danych, dostawcy usług zarządzanych, dostawcy zarządzanych usług bezpieczeństwa, marketplace’y internetowe, wyszukiwarki i platformy sieci społecznościowych. NIS2 Article 20 nakłada nadzór nad zarządzaniem ryzykiem cyberbezpieczeństwa na organy zarządzające. Article 21 wymaga środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego rozwoju oprogramowania, obsługi podatności, szkoleń, szyfrowania, bezpieczeństwa HR, kontroli dostępu, zarządzania aktywami i uwierzytelniania. Article 23 wprowadza etapowe zgłaszanie znaczących incydentów.

DORA ma zastosowanie od 17 stycznia 2025 r. do wielu podmiotów finansowych. Obejmuje zarządzanie ryzykiem ICT, zgłaszanie poważnych incydentów związanych z ICT, testowanie cyfrowej odporności operacyjnej, ryzyko ICT związane ze stronami trzecimi, ustalenia umowne z dostawcami ICT oraz nadzór nad krytycznymi zewnętrznymi dostawcami usług ICT. DORA Article 5 lokuje ład w zakresie ryzyka ICT na poziomie organu zarządzającego. Articles 8 to 14 obejmują identyfikację aktywów, ochronę, wykrywanie, ciągłość, kopie zapasowe, odzyskiwanie, wyciągnięte wnioski, szkolenia i komunikację kryzysową. Articles 17 to 20 definiują cykl życia incydentu i raportowanie. Articles 28 to 30 czynią z ryzyka ICT stron trzecich, warunków umownych, rejestrów, ryzyka koncentracji, praw audytu i planowania wyjścia obowiązki centralne.

NIST CSF 2.0 zapewnia praktyczną warstwę integracji. Jego funkcja GOVERN obejmuje obowiązki prawne, regulacyjne, umowne, prywatnościowe i dotyczące swobód obywatelskich, odpowiedzialność kierownictwa, apetyt na ryzyko, politykę, nadzór i ryzyko dostawców. Wyniki takie jak GV.OC-03 i GV.SC-02 naturalnie wiążą się z dowodami z Article 26, ponieważ wymagają, aby obowiązki prawne i role partnerów były rozumiane, zarządzane, komunikowane i koordynowane.

Zaletą modelu Clarysec jest ponowne wykorzystanie dowodów. REG08 nie jest wyłącznie rekordem GDPR. Wspiera rozliczalność ISO/IEC 27701:2025, ład zarządczy ISO/IEC 27001:2022, jasność ról dostawców w NIST CSF 2.0, nadzór DORA nad stronami trzecimi, gdy zaangażowane są usługi finansowe, oraz nadzór organu zarządzającego w NIS2, jeżeli podmiot jest objęty zakresem.

Co będą testować audytorzy i regulatorzy

Różni weryfikujący podejdą do nadzoru nad współadministratorami z różnych perspektyw, ale zbiegną się wokół tego samego podstawowego pytania: czy organizacja potrafi wykazać, że rozliczalność działa?

Najsilniejsza pozycja audytowa opiera się na identyfikowalności. Zacznij od wymagania prawnego, powiąż je z polityką PIMS, wskaż wpis w rejestrze, pokaż proces, a następnie pokaż dowód testu lub zapis rzeczywistej sprawy.

Na przykład GDPR Article 26 wymaga podziału odpowiedzialności współadministratorów. Polityka systemu zarządzania informacjami o prywatności wymaga REG08 przed rozpoczęciem przetwarzania. REG08 pokazuje podział odpowiedzialności za klauzule informacyjne, prawa, naruszenia, okresy przechowywania, zarządzanie dostawcami i kontakty. REG07 pokazuje publiczne podsumowanie. Symulacja DSR potwierdza działanie procesu. Protokoły z przeglądu zarządzania pokazują odstępstwa, decyzje i doskonalenie.

To jest audytowalny ład zarządczy.

Przegląd zarządzania przekształca ryzyko prywatności w odpowiedzialność kierownictwa

Nadzór nad współadministratorami nie powinien być ukryty w folderze zespołu ds. prywatności. Należy go objąć przeglądem zarządzania, ponieważ wpływa na ekspozycję regulacyjną, zaufanie klientów, zaufanie pacjentów, gotowość do reagowania na incydenty, ryzyko dostawców, odpowiedzialność umowną i odporność operacyjną.

ISO/IEC 27001:2022 wymaga zaangażowania kierownictwa, ról, zasobów, spójności polityk, planowania opartego na ryzyku, oceny wyników i ciągłego doskonalenia. NIS2 nakłada obowiązki nadzoru nad cyberbezpieczeństwem na organy zarządzające. DORA nakłada ostateczną odpowiedzialność za ryzyko ICT na organ zarządzający podmiotów finansowych.

Polityka ról i odpowiedzialności w ładzie zarządczym dla MŚP Clarysec, klauzula 5.5, stanowi:

Wszystkie istotne decyzje, wyjątki i eskalacje dotyczące bezpieczeństwa muszą być rejestrowane i identyfikowalne.

Dla organizacji korporacyjnych Polityka ról i odpowiedzialności w ładzie zarządczym, klauzula 5.2, wymaga:

Rejestr ról i odpowiedzialności musi być utrzymywany i musi obejmować:

Ten rejestr powinien obejmować role ładu prywatności tam, gdzie wpływają one na bezpieczeństwo, reagowanie na incydenty, zapewnienie w zakresie dostawców, odporność operacyjną i raportowanie zarządcze. Odstępstwa dotyczące współadministratorów powinny być eskalowane przed uruchomieniem, a nie odkrywane po skardze.

Praktyczny pakiet na przegląd zarządzania powinien obejmować:

• Nowe i zmienione uzgodnienia między współadministratorami
• Status kompletności REG08
• Czynności przetwarzania wysokiego ryzyka i status DPIA, jeżeli dotyczy
• Otwarte kwestie podstawy prawnej lub przejrzystości
• Wyniki obsługi DSR i zaległe działania partnerów
• Wyniki ćwiczeń tabletop dotyczących naruszeń i nierozwiązane luki
• Zależności od dostawców, podwykonawców przetwarzania, chmury i transferów
• Odstępstwa dotyczące okresów przechowywania i zakończenia współpracy
• Ustalenia audytowe i status działań naprawczych
• Wpływ raportowania względem GDPR, NIS2, DORA, NIST CSF 2.0 i COBIT 2019

Pięcioetapowe podejście Clarysec do zapewnienia audytowalności Article 26

Jeżeli Twoja organizacja współdzieli z inną stroną decyzje dotyczące przetwarzania PII, nie czekaj na skargę, audyt, naruszenie lub spór z partnerem, aby wyjaśnić odpowiedzialności.

Zastosuj to pięcioetapowe podejście:

1. Wykorzystaj Zenith Blueprint, krok 2, aby zidentyfikować interesariuszy, wymagania prawne, oczekiwania partnerów, obowiązki prywatnościowe i zakres regulacyjny.
2. Wykorzystaj Zenith Blueprint, krok 4, aby zbudować RACI dla klauzul informacyjnych, podstawy prawnej, praw, komunikacji dotyczącej naruszeń, okresów przechowywania, transferów, dostawców, dowodów audytowych i zakończenia współpracy.
3. Udokumentuj czynność przetwarzania w REG02 oraz podział odpowiedzialności współadministratorów w REG08, korzystając z zestawu polityk PIMS Clarysec.
4. Zmapuj uzgodnienie przez Zenith Controls, szczególnie ISO/IEC 27002:2022, środek kontrolny 5.2, środek kontrolny 5.31 i środek kontrolny 5.34.
5. Przetestuj uzgodnienie przy użyciu symulacji DSR i ćwiczenia tabletop dotyczącego naruszenia przed rozpoczęciem przetwarzania.

CareConnect i MetroHealth nie potrzebowały kolejnego nieformalnego uzgodnienia. Potrzebowały udokumentowanego podziału odpowiedzialności, publicznego podsumowania, procesu realizacji praw, zapisu koordynacji naruszenia, klauzul umownych i dowodów z przeglądu zarządzania.

Na tym polega różnica między „myśleliśmy, że zajmie się tym partner” a „oto zatwierdzone uzgodnienie, klauzula informacyjna, proces, dowody testów i zapis decyzji dotyczącej naruszenia”.

Clarysec może pomóc wdrożyć ład PIMS zgodny z ISO/IEC 27701:2025, dostosować go do GDPR Article 26, zintegrować z SZBI ISO/IEC 27001:2022 oraz wytwarzać dowody gotowe do audytu względem oczekiwań GDPR, NIS2, DORA, NIST CSF 2.0 i COBIT 2019.

Chcesz zastąpić niejednoznaczność współadministratorów dowodami gotowymi do audytu? Poznaj Zenith Blueprint: 30-etapową mapę drogową audytora, skorzystaj z Zenith Controls: przewodnika po zgodności przekrojowej albo skontaktuj się z Clarysec w sprawie oceny PIMS i SZBI, która przekształca Article 26 w działający system kontroli operacyjnej, zanim kolejne partnerstwo zostanie uruchomione produkcyjnie.