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

Nadzór nad zmianami dalszych podmiotów przetwarzających w SaaS i u MSP

Igor Petreski

Sarah, CISO szybko rosnącego dostawcy FinTech SaaS, otworzyła wiadomość, która wyglądała jak rutynowa aktualizacja usługi od dostawcy krytycznej infrastruktury. Pod hasłem „optymalizacje usług” ukryto jedno zdanie, które zmieniło jej cały tydzień:

„W celu zwiększenia wydajności analityki obciążenia związane z przetwarzaniem danych zostaną przeniesione do naszego nowego partnera, DataCrunch Analytics, ze skutkiem za 30 dni”.

Trzydzieści dni. Nowy partner analityczny. Szybka weryfikacja wykazała, że dostawca ma siedzibę poza UE.

Zespół inżynieryjny uznał to za rutynowe usprawnienie po stronie dostawcy. Zakupy przyjęły, że obejmuje je istniejąca umowa. Zespół ds. relacji z klientami nie zaplanował żadnej kampanii powiadomień. Dział prawny nie przeanalizował konsekwencji transferu. Sarah natychmiast zobaczyła rzeczywisty problem: jej firma działała jako podmiot przetwarzający dla setek instytucji finansowych w Europie. Ci klienci byli administratorami w rozumieniu GDPR. Część z nich wynegocjowała uprzednie powiadomienie o nowych dalszych podmiotach przetwarzających. Część miała prawo sprzeciwu. Kilku klientów miało obowiązki outsourcingowe i obowiązki zarządzania ryzykiem związanym z ICT ze strony zewnętrznych dostawców usług wynikające z DORA. Niektórzy mieli ścisłe deklaracje lokalizacyjne, których nie można było zmienić po cichu.

To moment, w którym wielu dostawców SaaS, MSP, MSSP i dostawców usług chmurowych odkrywa, że nadzór nad dalszymi podmiotami przetwarzającymi nie jest administracyjnym zadaniem z obszaru prywatności. To zarządzanie ryzykiem dostawców, zgodność z wymaganiami umownymi, odporność operacyjna, komunikacja z klientem i dowody audytowe w jednym procesie.

Publiczna strona z listą dalszych podmiotów przetwarzających nie wystarczy. Przypis w wiadomości od dostawcy nie wystarczy. Kwestionariusz bezpieczeństwa nie wystarczy. Możliwy do obrony proces musi pokazywać, kto ocenił dalszy podmiot przetwarzający, jakie dane są przetwarzane, których klientów to dotyczy, które umowy wymagają powiadomienia, czy sprzeciwy obsłużono przed rozpoczęciem korzystania z usługi, jak powiązano dowody transferu międzynarodowego oraz gdzie przechowywany jest końcowy pakiet dowodowy.

Clarysec traktuje to jako objęty nadzorem wzorzec kontroli, a nie doraźny łańcuch wiadomości e-mail. Proces łączy zarządzanie prywatnością, zapewnienie dostawców, przegląd prawny, ryzyko łańcucha dostaw ICT, powiadomienie klienta oraz dowody audytowe poprzez polityki Clarysec, Zenith Blueprint: 30-etapowa mapa drogowa audytora oraz Zenith Controls: przewodnik po zgodności między ramami.

Dlaczego zmiany dalszych podmiotów przetwarzających są zdarzeniami wysokiego ryzyka u dostawców

Zmiana dalszego podmiotu przetwarzającego może z dnia na dzień zmienić profil ryzyka usługi. Może zmienić miejsce hostowania danych osobowych klientów, lokalizację dostępu do nich, to, kto ma uprzywilejowany dostęp w ramach wsparcia, jak długo przechowywane są logi, jak eskalowane są incydenty, jakie obowiązki dotyczące szyfrowania mają zastosowanie oraz czy wymagany jest nowy mechanizm transferu międzynarodowego.

W przypadku dostawców SaaS i dostawców usług zarządzanych dalsze podmioty przetwarzające często są częścią łańcucha dostarczania produktu. Mogą obejmować dostawców hostingu w chmurze, platformy zgłoszeniowe, usługi dostarczania poczty elektronicznej, narzędzia analityczne AI, platformy zadań w tle, dostawców obserwowalności, narzędzia wsparcia, podmioty obsługujące płatności, dostawców zarządzanych usług bezpieczeństwa oraz usługi wzbogacania danych. Wielu z tych dostawców ma kontakt z danymi osobowymi klientów nawet wtedy, gdy zespoły opisują ich jako narzędzia „infrastrukturalne” lub „operacyjne”.

W świetle GDPR ma to znaczenie, ponieważ Article 28 wymaga, aby podmioty przetwarzające zarządzały dalszymi podmiotami przetwarzającymi na podstawie zgody administratora. Jeżeli stosowana jest ogólna pisemna zgoda, podmiot przetwarzający musi poinformować administratora o planowanych dodaniach lub zastąpieniach oraz zapewnić administratorowi możliwość wniesienia sprzeciwu. Article 28(4) wymaga również nałożenia na dalszy podmiot przetwarzający równoważnych obowiązków w zakresie ochrony danych. Article 5(2) dodaje zasadę rozliczalności, co oznacza, że organizacja musi być w stanie wykazać zgodność, a nie jedynie ją zadeklarować.

DORA podnosi stawkę dla usług finansowych. Podmioty finansowe muszą zarządzać ryzykiem związanym z ICT ze strony zewnętrznych dostawców usług jako integralną częścią zarządzania ryzykiem ICT. Muszą utrzymywać rejestry uzgodnień umownych, oceniać ryzyko koncentracji, rozumieć łańcuchy podwykonawstwa, definiować zabezpieczenia umowne, zapewniać prawa audytu i dostępu, wspierać współpracę przy incydentach oraz planować wyjście. Nawet jeżeli dostawca SaaS nie jest bezpośrednio podmiotem finansowym, jego klienci z sektora finansowego będą oczekiwać dowodów, ponieważ sami muszą spełnić wymagania DORA.

NIS2 rozszerza perspektywę na bezpieczeństwo łańcucha dostaw i rozliczalność organu zarządzającego. Article 21 wymaga odpowiednich środków technicznych, operacyjnych i organizacyjnych, w tym bezpieczeństwa łańcucha dostaw, obsługi incydentów, ciągłości działania, kontroli dostępu, zarządzania aktywami, bezpiecznego nabywania i utrzymania oraz oceny skuteczności. Article 20 nakłada odpowiedzialność nadzorczą na organy zarządzające. W przypadku dostawców chmury obliczeniowej, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, dostawców usług centrów danych, dostawców usług zaufania, internetowych platform handlowych, wyszukiwarek i określonych usług łączności widoczność dalszych podmiotów przetwarzających staje się częścią ładu cyberbezpieczeństwa.

ISO/IEC 27001:2022 i ISO/IEC 27701:2025 nadają temu wymiar operacyjny. ISO/IEC 27001:2022 wymaga, aby SZBI uwzględniał kontekst, wymagania stron zainteresowanych, ryzyka, plany postępowania z ryzykiem, kontrole operacyjne oraz udokumentowaną informację. ISO/IEC 27701:2025 rozszerza tę dyscyplinę systemu zarządzania na system zarządzania informacjami o prywatności. PIMS ukierunkowany na podmiot przetwarzający musi wykazywać, że dalsze przetwarzanie PII klientów jest zrozumiane, kontrolowane, uregulowane umownie, monitorowane i udokumentowane dowodowo.

Wzorzec Clarysec: zinwentaryzuj, oceń, powiadom, obsłuż sprzeciw, ureguluj umownie, powiąż transfer, zachowaj dowody

Najsilniejszy model nadzoru nad dalszymi podmiotami przetwarzającymi jest wystarczająco prosty, aby mogły go stosować zespoły operacyjne, i wystarczająco rygorystyczny, aby mogli go testować audytorzy. Clarysec stosuje siedem działań:

  1. Zinwentaryzuj każdy obecny i proponowany dalszy podmiot przetwarzający.
  2. Oceń prywatność, bezpieczeństwo, odporność i ryzyko zależności przed rozpoczęciem korzystania.
  3. Powiadom klientów zgodnie z właściwą umową.
  4. Obsłuż sprzeciwy w uzgodnionym oknie czasowym.
  5. Zaktualizuj DPA, załącznik bezpieczeństwa i obowiązki przenoszone na dalsze podmioty.
  6. Powiąż dowody hostingu, lokalizacji przetwarzania i transferu międzynarodowego.
  7. Zachowaj dowody w rejestrach prywatności i dostawców.

Pierwszym operacyjnym punktem odniesienia jest Polityka zarządzania prywatnością dla podmiotów przetwarzających, dalszych podmiotów przetwarzających i stron trzecich. Stanowi ona:

[Podmiot przetwarzający] Właściciel relacji z dostawcą / właściciel procesu zakupowego musi utrzymywać w REG08 listę dalszych podmiotów przetwarzających i podwykonawców wykorzystywanych do przetwarzania PII klientów przed rozpoczęciem korzystania z nich oraz aktualizować REG08 w ciągu 10 dni roboczych po zatwierdzonej zmianie.

Ta klauzula przekształca listę dalszych podmiotów przetwarzających w kontrolowany rejestr. Określa też wyraźnie terminy: REG08 jest aktualizowany przed rozpoczęciem korzystania, a następnie odświeżany w ciągu 10 dni roboczych po zatwierdzonej zmianie.

Ta sama polityka sprawia, że powiadomienie klienta jest możliwe do zweryfikowania podczas audytu:

[Podmiot przetwarzający] Właściciel relacji z dostawcą / właściciel procesu zakupowego musi powiadomić klienta o planowanych nowych lub zastępczych dalszych podmiotach przetwarzających zgodnie z właściwą umową z klientem przed rozpoczęciem korzystania z nich oraz zarejestrować powiadomienie, okres na wniesienie sprzeciwu i wynik w REG08.

To właśnie tego szczegółu brakuje w wielu programach. Pytanie nie dotyczy wyłącznie tego, czy zaktualizowano publiczną stronę. Pytanie brzmi, czy właściwi klienci zostali powiadomieni w wymagany sposób, zanim dalszy podmiot przetwarzający zaczął przetwarzać ich PII, z zachowaniem okresu na wniesienie sprzeciwu i wyniku jako dowodu.

Polityka łączy również nadzór nad zmianami z due diligence:

[Wszyscy] Właściciel relacji z dostawcą / właściciel procesu zakupowego musi uzupełnić w REG08 dowody due diligence w zakresie prywatności przed wyborem, odnowieniem albo istotną zmianą każdej relacji z podmiotem przetwarzającym, dalszym podmiotem przetwarzającym lub stroną trzecią, która przetwarza PII albo ma do nich dostęp.

Istotna zmiana może obejmować zastąpienie infrastruktury, dodanie dalszego dostawcy analityki, przeniesienie regionów hostingu, umożliwienie dostępu personelu wsparcia z nowego kraju, rozszerzenie kategorii danych albo zmianę sposobu działania usługi w zakresie okresu przechowywania.

Na koniec polityka zamyka lukę w przenoszeniu obowiązków umownych:

[Podmiot przetwarzający] Właściciel relacji z dostawcą / właściciel procesu zakupowego musi zapewnić, aby każda umowa z dalszym podmiotem przetwarzającym zawierała obowiązki przenoszone na dalsze podmioty dotyczące prywatności, bezpieczeństwa, pomocy, zwrotu, usunięcia, interfejsu incydentowego oraz powiązania transferu, zanim dalszy podmiot przetwarzający zacznie przetwarzać PII.

Ma to znaczenie, ponieważ ogólny załącznik dotyczący bezpieczeństwa nie zawsze wystarcza. Obowiązki właściwe dla podmiotu przetwarzającego muszą zostać przeniesione dalej przed rozpoczęciem przetwarzania.

Gdzie polityki Clarysec łączą prywatność, dostawców i transfery

Nadzór nad dalszymi podmiotami przetwarzającymi działa tylko wtedy, gdy prywatność, dział prawny, bezpieczeństwo dostawców i operacyjne zarządzanie zmianą korzystają z tego samego łańcucha dowodów.

Polityka zgodności prawnej i regulacyjnej - SME ustanawia zasadę obowiązującą przed udostępnieniem danych:

Klauzule umowy powierzenia przetwarzania danych (DPA) lub równoważne postanowienia umowne muszą zostać uzgodnione przed udostępnieniem jakichkolwiek danych osobowych lub wrażliwych.

W środowiskach enterprise Polityka zgodności prawnej i regulacyjnej doprecyzowuje oczekiwania dowodowe, wymagając:

ujawnień dotyczących dalszych podmiotów przetwarzających oraz geograficznych deklaracji transferu danych

Identyfikuje również przesłanki nadzoru obejmujące:

zmiany mechanizmów transferu danych, dalszych podmiotów przetwarzających lub transgranicznych przepływów danych

Polityka bezpieczeństwa dostawców i stron trzecich stanowi:

korzystanie z podwykonawców wymaga uprzedniej pisemnej zgody

Dla mniejszych organizacji Polityka bezpieczeństwa dostawców i stron trzecich - SME zapewnia skalowalną wersję:

ograniczenia dalszego podwykonawstwa bez zatwierdzenia

Polityka wyraźnie wymaga również ponownej oceny zmian u dostawców:

Wszystkie zmiany dotyczące dostawców — w tym własności, rodzaju usługi, lokalizacji hostingu lub podwykonawstwa — muszą zostać ponownie ocenione pod kątem wpływu na ryzyko i adekwatności umowy.

Polityka ochrony danych i prywatności obejmuje:

wymagania dotyczące zatwierdzania dalszych podmiotów przetwarzających

Polityka zarządzania ryzykiem zależności od dostawców dodaje perspektywę odporności:

Ujawnianie podwykonawców: dostawca musi informować nas o kluczowych podwykonawcach oraz wszelkich ich zmianach, zwłaszcza gdy tworzą one dodatkowe warstwy zależności.

Łącznie polityki te tworzą pełną regułę operacyjną: brak udostępnienia danych osobowych bez postanowień umownych, brak ukrytych dalszych podmiotów przetwarzających, brak niezarządzanego podwykonawstwa, brak nieocenionej zmiany hostingu lub lokalizacji oraz brak zatwierdzenia bez dowodów transferu tam, gdzie są one istotne.

Jak Zenith Controls ujmuje zestaw kontroli dostawców

W Zenith Controls Clarysec mapuje nadzór nad zmianami dalszych podmiotów przetwarzających przede wszystkim do kontroli dostawców i kontroli prawnych ISO/IEC 27002:2022. Jest to istotne, ponieważ pokazuje, że nadzór nad dalszymi podmiotami przetwarzającymi nie jest wyłącznie procesem prywatności. Jest także kontrolą bezpieczeństwa informacji, zarządzania dostawcami, prawną i odpornościową.

Środek kontrolny ISO/IEC 27002:2022Nazwa środka kontrolnegoRola w nadzorze nad dalszymi podmiotami przetwarzającymi
5.19Bezpieczeństwo informacji w relacjach z dostawcamiUstanawia podstawę zarządzania ryzykiem dostawców do identyfikowania i zarządzania dostawcami mającymi dostęp do informacji lub systemów
5.20Uwzględnianie bezpieczeństwa informacji w umowach z dostawcamiZapewnia, aby umowy obejmowały obowiązki dotyczące bezpieczeństwa, prywatności, podwykonawstwa, incydentów, audytu, usuwania i transferu
5.21Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICTWspiera widoczność dalszych zależności ICT oraz ryzyk łańcucha dostaw
5.22Monitorowanie, przegląd i zarządzanie zmianami usług dostawcówZapewnia kontrolę operacyjną do ponownej oceny zmian u dostawców, w tym nowych dalszych podmiotów przetwarzających i zmian hostingu
5.23Bezpieczeństwo informacji przy korzystaniu z usług chmurowychMa zastosowanie, gdy dalsze podmioty przetwarzające zapewniają hosting w chmurze, platformy chmurowe, SaaS lub przetwarzanie oparte na chmurze
5.31Wymagania prawne, ustawowe, regulacyjne i umowneŁączy proces z GDPR, DORA, NIS2, DPA klientów, obowiązkami transferowymi oraz umownymi obowiązkami powiadamiania

Zenith Controls opisuje środek kontrolny 5.22, „Monitorowanie, przegląd i zarządzanie zmianami usług dostawców”, jako kontrolę zapobiegawczą wspierającą poufność, integralność i dostępność, dostosowaną do koncepcji cyberbezpieczeństwa Identify oraz zdolności operacyjnych w zakresie bezpieczeństwa relacji z dostawcami i zapewnienia bezpieczeństwa informacji. Dokładnie tego wymaga zmiana dalszego podmiotu przetwarzającego: zidentyfikowania zmiany, ponownej oceny ryzyka, potwierdzenia pokrycia umownego i zachowania dowodów zapewnienia.

W przypadku środka kontrolnego 5.20 Zenith Controls ujmuje umowy z dostawcami jako kontrole zapobiegawcze obejmujące poufność, integralność i dostępność. To tutaj należą postanowienia DPA, załączniki bezpieczeństwa, klauzule podwykonawstwa, prawa audytu, pomoc w obsłudze incydentów, zwrot i usunięcie danych oraz obowiązki dotyczące powiązania transferu.

W przypadku środka kontrolnego 5.21 perspektywa łańcucha dostaw ma znaczenie, ponieważ dalszy podmiot przetwarzający może tworzyć zależność czwartej strony. Dostawca SaaS może polegać na dostawcy infrastruktury, który korzysta z dostawcy analityki danych, który z kolei korzysta z innego regionu chmurowego lub partnera wsparcia. Organizacja musi rozumieć ten łańcuch na tyle dobrze, aby zarządzać ryzykiem, zobowiązaniami wobec klientów i opcjami wyjścia.

30-etapowa mapa drogowa: przekształcenie polityki w procedurę operacyjną

Zenith Blueprint umieszcza ryzyko dostawców i dalszego przetwarzania w kroku 23, Zabezpieczenia organizacyjne. Wyjaśnia, że umowy z dostawcami zazwyczaj obejmują poufność, kontrolę dostępu, środki techniczne i organizacyjne, terminy zgłaszania incydentów, postanowienia dotyczące prawa do audytu, kontrole podwykonawców oraz postanowienia końcowe umowy. Blueprint podkreśla kluczową kwestię:

Struktura umowy ma znaczenie. Klauzule te mogą znajdować się w głównej umowie o świadczenie usług, dedykowanej umowie powierzenia przetwarzania danych (DPA) albo samodzielnym załączniku bezpieczeństwa. Ważne jest to, że istnieją oraz że są zrozumiane i zaakceptowane przez obie strony.

Blueprint wskazuje również zespołom, co zrobić z podwykonawcami:

Dla każdego dostawcy krytycznego ustal, czy korzysta z podwykonawców (dalszych podmiotów przetwarzających), którzy mogą mieć dostęp do Twoich danych lub systemów. Udokumentuj, w jaki sposób Twoje wymagania bezpieczeństwa informacji są przenoszone na te podmioty — przez warunki umowne Twojego dostawcy albo przez Twoje własne bezpośrednie klauzule.

W przypadku nadzoru nad zmianami u dostawców właściwym operacyjnym dopasowaniem jest środek kontrolny ISO/IEC 27002:2022 5.22:

Ustanów prostą, skalowalną procedurę oceny zmian w usługach dostawców (5.22), takich jak migracja do chmury, nowi dalsi podmioty przetwarzające lub przebudowa infrastruktury. Zdefiniuj przesłanki wymagające ponownej oceny bezpieczeństwa.

Daje to CISO i IOD praktyczną ścieżkę działania. Krok 23 definiuje intencję kontroli. REG08 przechowuje dowody dotyczące prywatności dla podmiotu przetwarzającego, dalszego podmiotu przetwarzającego i strony trzeciej. REG09 przechowuje dowody transferu. Umowy z dostawcami, DPA i zgłoszenia zmian łączą proces z rzeczywistością operacyjną.

Praktyczny proces powiadamiania o zmianie dalszego podmiotu przetwarzającego

Proces zmiany dalszego podmiotu przetwarzającego powinien być przewidywalny w dobrym tego słowa znaczeniu. Każdy etap powinien mieć właściciela, dowody i bramkę kontrolną zapobiegającą przedwczesnemu użyciu produkcyjnemu.

Etap procesuWłaścicielDowodyBramka zatwierdzenia
Przyjęcie proponowanego dalszego podmiotu przetwarzającegoWłaściciel relacji z dostawcą lub właściciel procesu zakupowegoWniosek o zmianę, opis usługi, kategorie danych, cel przetwarzaniaTriaż prywatności i bezpieczeństwa
Due diligence w zakresie prywatności i bezpieczeństwaIOD, Bezpieczeństwo, ZakupyDue diligence REG08, certyfikaty, kwestionariusz, historia incydentów, środki techniczne i organizacyjne (TOM)Zatwierdzenie przez właściciela ryzyka
Przegląd umowy i DPADział prawny, ZakupyMapowanie klauzul DPA, warunki podwykonawstwa, prawa audytu, pomoc w obsłudze incydentów, warunki usuwaniaZatwierdzenie prawne
Przegląd lokalizacji i transferuPrywatność, Dział prawny, BezpieczeństwoLokalizacje przetwarzania, lokalizacje hostingu, mechanizm transferu, powiązanie z REG09Zatwierdzenie transferu
Powiadomienie klientaZespół ds. relacji z klientami, Dział prawny, PrywatnośćTreść powiadomienia, klienci objęci zmianą, podstawa umowna, data powiadomienia, okno na sprzeciwPowiadomienie wysłane przed rozpoczęciem korzystania
Obsługa sprzeciwówDział prawny, właściciel klienta, właściciel ryzykaRejestr sprzeciwów, reakcja na ryzyko, decyzja klienta, blokada techniczna, jeżeli potrzebnaSprzeciw rozwiązany albo zatwierdzone odstępstwo
Uruchomienie produkcyjneInżynieria, menedżer zmianyZgłoszenie zmiany, odwołania do zatwierdzeń, data uruchomienia produkcyjnegoBrak przetwarzania przed zatwierdzeniem
Aktualizacja po zmianieWłaściciel relacji z dostawcąZaktualizowany REG08, publiczna lista, jeżeli jest stosowana, repozytorium umów, częstotliwość monitorowaniaPrzegląd dowodów w zdefiniowanym SLA

Kluczowa zasada jest prosta: powiadomienie klienta musi nastąpić przed rozpoczęciem korzystania z dalszego podmiotu przetwarzającego tam, gdzie wymaga tego umowa. Aktualizacja publicznej strony internetowej po wdrożeniu może wspierać przejrzystość, ale nie dowodzi powiadomienia konkretnego klienta, autoryzacji umownej ani obsługi sprzeciwu.

Zastosowanie procesu do kryzysu Sarah

Powiadomienie od dostawcy Sarah dotyczące DataCrunch Analytics uruchamia pełny proces.

Po pierwsze, właściciel relacji z dostawcą otwiera zapis zmiany REG08. Zapis identyfikuje CoreStack, DataCrunch Analytics, cel usługi, wpływ na tenantów klientów, rolę w przetwarzaniu, kategorie danych, lokalizacje przetwarzania, model dostępu personelu wsparcia, okres przechowywania oraz to, czy mogą występować szczególne kategorie danych osobowych lub regulowane dane klientów finansowych.

Po drugie, Prywatność i Bezpieczeństwo wykonują due diligence. Przeglądają środki techniczne i organizacyjne DataCrunch Analytics, szyfrowanie, kontrolę dostępu, rejestrowanie, zgłaszanie incydentów, możliwości usuwania, zapewnienie audytowe, listę dalszych podmiotów przetwarzających i certyfikaty bezpieczeństwa. Ponieważ dostawca znajduje się poza UE, przegląd lokalizacji i transferu jest obowiązkowy.

Po trzecie, dział prawny sprawdza, czy DPA klientów stosują szczegółową zgodę, czy ogólną zgodę z powiadomieniem. Klienci są segmentowani na grupy powiadomień: standardowi klienci z 30-dniowym powiadomieniem, klienci enterprise z 45-dniowymi oknami na sprzeciw, klienci wymagający szczegółowego zatwierdzenia, klienci ograniczeni deklaracjami lokalizacyjnymi oraz klienci nieobjęci zmianą, których dane nie są przetwarzane w ramach obciążenia analitycznego.

Po czwarte, powiązywane są dowody transferu. Polityka zarządzania prywatnością dla podmiotów przetwarzających, dalszych podmiotów przetwarzających i stron trzecich wymaga:

[Obie strony] Właściciel relacji z dostawcą / właściciel procesu zakupowego musi zarejestrować lokalizacje przetwarzania, lokalizacje hostingu oraz wskaźniki transferu międzynarodowego w REG08 i powiązać właściwe dowody transferu z REG09 przed zatwierdzeniem podmiotu przetwarzającego, dalszego podmiotu przetwarzającego, zmiany lokalizacji albo zmiany usługi istotnej dla transferu.

Po piąte, zespół ds. relacji z klientami wysyła formalne powiadomienia zatwierdzonymi kanałami. Każde powiadomienie obejmuje planowany dalszy podmiot przetwarzający, cel, kategorie danych, podsumowanie lokalizacji, datę wejścia w życie, termin na wniesienie sprzeciwu i kanał kontaktu.

Po szóste, sprzeciwy są obsługiwane. Jeżeli instytucja finansowa wnosi sprzeciw, ponieważ zmiana wpływa na funkcję krytyczną albo transfer do państwa trzeciego, zespół Sarah ocenia alternatywy: wyłączenie tenanta, utrzymanie dotychczasowej ścieżki przetwarzania, wymaganie wsparcia wyłącznie z UE, zmianę zabezpieczeń umownych albo opóźnienie zmiany do czasu rozwiązania sprzeciwu.

Po siódme, Inżynieria otrzymuje zatwierdzenie wyłącznie dla tenantów i obciążeń, które przeszły bramkę kontrolną. Zgłoszenie zmiany produkcyjnej odsyła do REG08, REG09, zatwierdzenia prawnego, dowodów powiadomienia oraz wszelkich wyłączeń specyficznych dla klientów. Po uruchomieniu produkcyjnym aktualizowane są rejestr wewnętrzny, publiczna strona z dalszymi podmiotami przetwarzającymi oraz repozytorium umów.

Na tym polega różnica między reaktywnym gaszeniem pożaru a możliwym do obrony nadzorem.

Mapowanie zgodności między ramami w jednym łańcuchu dowodów

Przewaga Clarysec polega na tym, że jeden proces może spełniać wymagania wielu ram, jeżeli dowody są zaprojektowane prawidłowo od początku.

Obszar wymagańJak proces go adresuje
GDPR Article 28 i rozliczalnośćUtrzymuje dowody autoryzacji dalszych podmiotów przetwarzających, powiadomienia klientów, wyniki sprzeciwów, przenoszenie obowiązków DPA i powiązanie transferu
ISO/IEC 27701:2025 PIMSWykazuje ład prywatności uwzględniający role, kontrolę dalszego przetwarzania, retencję dowodów i monitorowanie
ISO/IEC 27001:2022 SZBIWspiera wymagania stron zainteresowanych, ocenę ryzyka, kontrolę operacyjną, kontrole dostawców, wymagania prawne i udokumentowaną informację
Środki kontrolne ISO/IEC 27002:2022Wdraża kontrole relacji z dostawcami, umów z dostawcami, łańcucha dostaw ICT, zmian u dostawców, usług chmurowych i wymagań prawnych
Ryzyko związane z ICT ze strony zewnętrznych dostawców usług według DORAWspiera rejestry, due diligence, widoczność łańcuchów podwykonawstwa, świadomość lokalizacji, ryzyko koncentracji, prawa audytu, pomoc w obsłudze incydentów i planowanie wyjścia
Bezpieczeństwo łańcucha dostaw według NIS2Wspiera bezpieczeństwo łańcucha dostaw z Article 21, analizę ryzyka dostawców, obsługę incydentów, ciągłość działania i nadzór organu zarządzającego
NIST CSF 2.0 GOVERN i GV.SCDostosowuje proces do strategii ryzyka dostawców, krytyczności dostawców, wymagań umownych w zakresie cyberbezpieczeństwa, due diligence, monitorowania, udziału w incydentach i planowania zakończenia relacji
Perspektywa ładu COBIT 2019Wspiera potrzeby interesariuszy, optymalizację ryzyka, rozliczalność dostawców, raportowanie zarządcze i dowody zapewnienia

NIST CSF 2.0 jest użyteczny jako neutralna warstwa porządkująca. Funkcja GOVERN obejmuje zrozumienie obowiązków prawnych, regulacyjnych, umownych, prywatnościowych i związanych ze swobodami obywatelskimi, przypisanie ról, ustanowienie polityk, przegląd wyników oraz zarządzanie ryzykiem cyberbezpieczeństwa w łańcuchu dostaw. Kategoria GV.SC oczekuje procesów zarządzania ryzykiem dostawców, określenia krytyczności dostawców, umownych wymagań cyberbezpieczeństwa, due diligence, monitorowania w cyklu życia, planowania incydentowego oraz działań po zakończeniu relacji.

DORA jest bardziej preskryptywne wobec podmiotów finansowych. Articles 28 to 30 wymagają zarządzania ryzykiem związanym z ICT ze strony zewnętrznych dostawców usług, rejestrów umownych, klasyfikacji funkcji krytycznych lub ważnych, widoczności łańcucha podwykonawstwa, świadomości lokalizacji, zabezpieczeń umownych, praw audytu, współpracy przy incydentach oraz planowania wyjścia. Jeżeli Twoja platforma SaaS obsługuje klientów finansowych, dowody dotyczące dalszych podmiotów przetwarzających stają się częścią ich pakietu dowodowego DORA.

NIS2 dodaje rozliczalność organu zarządzającego. Article 20 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa i nadzorowały ich wdrożenie. Article 21 wymaga bezpieczeństwa łańcucha dostaw oraz oceny praktyk cyberbezpieczeństwa dostawców. Istotna zmiana dalszego podmiotu przetwarzającego powinna zatem być widoczna w raportowaniu ryzyka, a nie ukryta w folderze zakupowym.

Co będą testować audytorzy

Dojrzały proces obsługi dalszych podmiotów przetwarzających tworzy prostą linię od polityki do dowodów.

Audytor ISO/IEC 27001:2022 rozpocznie od zakresu SZBI, wymagań stron zainteresowanych, ryzyk, Deklaracji stosowania i kontroli operacyjnych. Prawdopodobnie przetestuje relacje z dostawcami, umowy z dostawcami, łańcuch dostaw ICT, monitorowanie dostawców i zarządzanie zmianą, wymagania prawne, usługi chmurowe, ochronę prywatności, rejestrowanie oraz operacyjną kontrolę zmian.

Audytor ISO/IEC 27701:2025 PIMS skupi się na jasności ról. Czy jesteś podmiotem przetwarzającym, administratorem, współadministratorem, czy pełnisz różne role w różnych usługach? W przypadku czynności podmiotu przetwarzającego poprosi o listę dalszych podmiotów przetwarzających, podstawę autoryzacji, dowody powiadomienia, obsługę sprzeciwów, umowy z dalszymi podmiotami, dowody transferu, wsparcie usuwania, interfejs incydentowy i zapisy monitorowania.

Przeglądający prywatność pod kątem GDPR będzie testować rozliczalność. Zapyta, kto przetwarza dane osobowe, w jakim celu, na podstawie której umowy, w jakiej lokalizacji, przy jakich zabezpieczeniach i z jaką przejrzystością wobec klienta. Jeżeli klient wniósł sprzeciw, zapyta, co wydarzyło się przed rozpoczęciem przetwarzania.

Audytor klienta w zakresie DORA zapyta, czy dalszy podmiot przetwarzający wspiera funkcję krytyczną lub ważną, czy łańcuchy podwykonawstwa są widoczne, czy lokalizacje danych są udokumentowane, czy pomoc w obsłudze incydentów jest zagwarantowana umownie, czy prawa audytu są przeniesione dalej, czy uwzględniono ryzyko koncentracji oraz czy wyjście jest możliwe.

Asesor NIS2 skupi się na bezpieczeństwie łańcucha dostaw, nadzorze organu zarządzającego, gotowości incydentowej i proporcjonalnych kontrolach. Może zapytać, jak wykrywane są zmiany u dostawców, jak oceniani są bezpośredni dostawcy, jak uwzględniane są podatności dostawców oraz jak eskalowane są incydenty dotyczące odbiorców usług.

Zestaw dowodów powinien być łatwy do odtworzenia:

  • Zatwierdzony wniosek o zmianę dalszego podmiotu przetwarzającego.
  • Zapis due diligence REG08.
  • Ocena kategorii danych i celu przetwarzania.
  • Dowody lokalizacji przetwarzania i hostingu.
  • Dowody transferu REG09, jeżeli są istotne.
  • Przegląd DPA i umów pod kątem obowiązków przenoszonych na dalsze podmioty.
  • Lista powiadomień klientów, daty, treść i dowody doręczenia.
  • Rejestr sprzeciwów i dowody ich rozwiązania.
  • Zgłoszenie zmiany produkcyjnej powiązane z zatwierdzeniem.
  • Zaktualizowana lista dalszych podmiotów przetwarzających i harmonogram monitorowania.
  • Akceptacja ryzyka albo zatwierdzenie odstępstwa, jeżeli jest wymagane.

Typowe wzorce nieskuteczności

Pierwszy wzorzec nieskuteczności to traktowanie strony z dalszymi podmiotami przetwarzającymi jako całego procesu. Publiczna strona wspiera przejrzystość, ale nie dowodzi powiadomienia konkretnego klienta, obsługi sprzeciwu ani autoryzacji.

Drugi wzorzec nieskuteczności to rozdzielenie dowodów prywatności, bezpieczeństwa i zakupów. Prywatność może zatwierdzić DPA, Bezpieczeństwo może przejrzeć raport SOC 2, a Zakupy mogą zarchiwizować umowę, ale żaden pojedynczy zapis nie łączy decyzji.

Trzeci wzorzec nieskuteczności to brak powiązania transferu. Zespoły zapisują nazwę dostawcy, ale nie lokalizacje przetwarzania, lokalizacje hostingu, lokalizacje wsparcia, wskaźniki transferu międzynarodowego ani dowody REG09.

Czwarty wzorzec nieskuteczności to uruchomienie produkcyjne przed zamknięciem okien na sprzeciw. Gdy PII klienta zostaną przetworzone przez nowy dalszy podmiot przetwarzający, organizacja mogła już naruszyć umowę.

Piąty wzorzec nieskuteczności to słabe przenoszenie obowiązków. Bezpośredni dostawca przyjmuje silne postanowienia, ale jego dalsi dostawcy nie są związani równoważnymi obowiązkami dotyczącymi prywatności, bezpieczeństwa, pomocy, zwrotu, usunięcia, incydentów, audytu i transferu.

Szósty wzorzec nieskuteczności to słabe wykrywanie zmian. Dostawca zmienia własność, lokalizację hostingu, rodzaj usługi, model wsparcia albo łańcuch podwykonawstwa, a nikt nie ocenia ponownie ryzyka.

Siódmy wzorzec nieskuteczności to brak ścieżki audytowej. Zespoły pamiętają decyzję, ale nie potrafią udowodnić, kiedy zapadła, kto ją zatwierdził, których klientów powiadomiono i jak rozwiązano sprzeciwy.

Raportowanie zarządcze dla CISO i IOD

Nadzór nad dalszymi podmiotami przetwarzającymi powinien dostarczać informacji zarządczej, a nie tylko artefaktów zgodności.

MetrykaDlaczego ma znaczenie
Aktywne dalsze podmioty przetwarzające według usługi i kategorii danychPokazuje zakres przetwarzania i ekspozycję prywatności
Dalsze podmioty przetwarzające wspierające usługi krytyczneWspiera planowanie odporności, zapewnienie DORA i priorytetyzację dostawców
Dalsze podmioty przetwarzające z dostępem lub hostingiem w państwach trzecichWspiera przeglądy transferów i deklaracje dla klientów
Nadchodzące okna na sprzeciwZapobiega przedwczesnemu uruchomieniu produkcyjnemu
Dalsze podmioty przetwarzające bez aktualnego due diligenceIdentyfikuje luki w zapewnieniu
Umowy bez klauzul przenoszących obowiązki na dalsze podmiotyWskazuje ryzyko prawne i operacyjne
Zmiany u dostawców oczekujące na ponowną ocenęPokazuje obciążenie nadzorcze i zaległości
Sprzeciwy klientów otwarte po SLAWskazuje nierozwiązane blokery komercyjne, prawne lub techniczne

Takie raportowanie pasuje do modelu systemu zarządzania. ISO/IEC 27001:2022 oczekuje przywództwa, kontroli operacyjnej, oceny wyników i ciągłego doskonalenia. DORA i NIS2 wzmacniają rozliczalność organu zarządzającego. Nadzór nad dalszymi podmiotami przetwarzającymi powinien pojawiać się na spotkaniach komitetu sterującego ds. prywatności, przeglądach ryzyka dostawców, przeglądzie zarządzania SZBI oraz w raportowaniu ryzyka ICT tam, gdzie jest to istotne.

Zbuduj pakiet dowodów dla zmian dalszych podmiotów przetwarzających

Zacznij od jednej niedawnej zmiany dostawcy i sprawdź, czy Twoja organizacja potrafi odpowiedzieć na te pytania:

  • Czy dostawca został zidentyfikowany jako podmiot przetwarzający, dalszy podmiot przetwarzający, dostawca, dostawca ICT albo wszystkie te role jednocześnie?
  • Czy REG08 albo równoważny rejestr został zaktualizowany przed rozpoczęciem korzystania?
  • Czy zarejestrowano lokalizacje przetwarzania i lokalizacje hostingu?
  • Czy oceniono wskaźniki transferu międzynarodowego?
  • Czy dowody transferu powiązano z REG09 albo równoważnym plikiem?
  • Czy umowa obejmowała obowiązki przenoszone na dalsze podmioty dotyczące prywatności, bezpieczeństwa, pomocy, zwrotu, usunięcia, incydentów, audytu i transferu?
  • Czy klienci zostali powiadomieni zgodnie z ich umowami przed rozpoczęciem przetwarzania?
  • Czy okna na sprzeciw były śledzone i zamknięte?
  • Czy uruchomienie produkcyjne było zablokowane do czasu zatwierdzenia?
  • Czy audytor mógłby odtworzyć ślad decyzyjny w mniej niż 30 minut?

Jeżeli odpowiedź brzmi „nie”, luka nie jest wyłącznie prawna. Jest operacyjna, umowna, związana z ryzykiem dostawców, prywatnością i gotowością do audytu.

Clarysec pomaga zespołom szybko zamknąć tę lukę. Użyj Zenith Blueprint, aby umieścić nadzór nad dalszymi podmiotami przetwarzającymi w mapie drogowej wdrożenia SZBI i PIMS. Użyj Zenith Controls, aby mapować kontrole relacji z dostawcami, umów z dostawcami, łańcucha dostaw ICT, zmian u dostawców, usług chmurowych i wymagań prawnych między ISO/IEC 27001:2022, ISO/IEC 27701:2025, GDPR, DORA, NIS2, NIST CSF 2.0 i COBIT 2019. Użyj Polityki zarządzania prywatnością dla podmiotów przetwarzających, dalszych podmiotów przetwarzających i stron trzecich, Polityki bezpieczeństwa dostawców i stron trzecich, Polityki zgodności prawnej i regulacyjnej, Polityki ochrony danych i prywatności oraz Polityki zarządzania ryzykiem zależności od dostawców, aby przełożyć mapowanie na codzienne wykonanie.

Nie czekaj na zaskakujący przypis w wiadomości od dostawcy. Zbuduj proces, pakiet dowodowy i mapę kontroli już teraz, aby każda zmiana dalszego podmiotu przetwarzającego stała się dowodem dojrzałego nadzoru, a nie kryzysem zgodności.

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

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

Share this article