Ryzyko związane z podmiotami trzecimi w RODO, NIS2 i DORA

Ten sam dostawca może rodzić obowiązki w zakresie ochrony danych, cyberbezpieczeństwa i odporności operacyjnej. Dostawca usług płacowych przetwarza dane osobowe; dostawca usług zarządzanych ma dostęp uprzywilejowany; platforma chmurowa obsługuje aplikacje o krytycznym znaczeniu dla działalności. Czasem jeden dostawca robi wszystkie trzy rzeczy naraz.

Wspólny zapis dotyczący dostawcy pomaga zespołom koordynować ocenę, o ile każdy obowiązek pozostaje rozpoznawalny. Dla CTO praktycznym wyzwaniem jest powiązanie zobowiązań umownych z rzeczywistością techniczną: do czego dostawca ma dostęp, jak rozprzestrzeniają się awarie, które zabezpieczenia są poparte dowodami i czy organizacja może odtworzyć działanie lub odejść.

Ustal zakres stosowania przed połączeniem ocen

Te akty prawne częściowo się pokrywają, ale nie mają zastosowania do każdej organizacji ani do każdego dostawcy w ten sam sposób.

Art. 28 RODO zobowiązuje administratorów do korzystania z podmiotów przetwarzających, które zapewniają wystarczające gwarancje. Umowa na podstawie art. 28 nie jest właściwa tylko dlatego, że dostawca otrzymuje dane: najpierw ustal faktyczną rolę w przetwarzaniu.

Art. 20–23 NIS2 dotyczą nadzoru kierownictwa, środków zarządzania ryzykiem i zgłaszania poważnych incydentów. NIS2 jest dyrektywą wdrażaną przez prawo krajowe, dlatego zakres i procedury wymagają sprawdzenia w konkretnej jurysdykcji.

DORA jest stosowane od 17 stycznia 2025 r. Obejmuje przede wszystkim określone podmioty finansowe; zwykli dostawcy ICT mogą spotkać się z wymogami umownymi ze strony klientów, a wyznaczeni kluczowi dostawcy usług ICT podlegają odrębnemu reżimowi nadzoru. W przypadku objętych podmiotów finansowych DORA działa jako sektorowe prawo UE w odpowiednich obszarach NIS2. Nie dubluj automatycznie obu zestawów zabezpieczeń.

Zbuduj zapis wokół zależności

Zacznij od usługi, a nie od kwestionariusza dla dostawcy. Jeden dostawca może świadczyć kilka usług, które różnią się danymi, dostępem i znaczeniem operacyjnym.

Jako praktyczne minimum zapisz:

• Usługę, podmiot prawny dostawcy, właściciela biznesowego, właściciela technicznego i weryfikujących.
• Wspierane funkcje, systemy, integracje i dostęp uprzywilejowany.
• Kategorie danych osobowych, cele przetwarzania, lokalizacje i podprocesorów.
• Wymagania dotyczące dostępności, cele odtwarzania i dopuszczalny poziom zakłóceń.
• Dostawców bazowych, zależności umowne i realistyczne alternatywy.
• Mające zastosowanie obowiązki, daty dowodów, nierozwiązane luki i decyzje.

Ustal, które funkcje przestałyby działać lub działałyby gorzej po przejęciu lub awarii. Dostawca przechowujący niewiele danych wrażliwych może nadal kontrolować uwierzytelnianie lub potoki wdrożeniowe. Z kolei usługa o niskim ryzyku w zakresie dostępności może narażać bardzo wrażliwe dane osobowe.

Utrzymuj te wymiary oddzielnie, zamiast łączyć je w jedną niewyjaśnioną ocenę „wysokiego ryzyka”. W przypadku podmiotów finansowych objętych DORA powiąż ten inwentarz operacyjny z wymaganym rejestrem informacji dotyczących ustaleń umownych w zakresie usług ICT; ogólna lista dostawców niekoniecznie wystarcza.

Wykorzystuj dowody ponownie, nie powielając bezrefleksyjnie wniosków

Raport bezpieczeństwa, mapa przepływu danych lub test odtwarzania mogą wspierać kilka przeglądów. Zanim na nich polegasz, sprawdź zakres usługi, okres sprawozdawczy, wyłączenia, wyjątki i obowiązki po stronie klienta.

Na przykład raport obejmujący infrastrukturę dostawcy niekoniecznie obejmuje dostęp jego personelu wsparcia do danych klientów. Udokumentowana polityka kopii zapasowych nie pokazuje, że odtwarzanie spełnia wymagania dotyczące odtwarzania Twojej aplikacji.

Prowadź macierz powiązań dowodów z pytaniami:

Certyfikat ISO lub raport SOC 2 wspiera zapewnienie w swoim zakresie; żaden z nich nie dowodzi zgodności z RODO ani z NIS2. Zachowuj uzasadnienie weryfikującego, a nie tylko przesłany dokument. Ocena zapewnień dotyczących bezpieczeństwa powinna być powtarzalnym przeglądem technicznym, a nie sprawdzaniem odznak.

Przekładaj wymogi na umowy i zabezpieczenia

Zgodnie z art. 28 RODO warunki powierzenia muszą określać przedmiot i czas trwania przetwarzania, jego charakter i cel, rodzaj danych oraz kategorie osób, których dane dotyczą. Obejmują też udokumentowane polecenia, poufność, bezpieczeństwo, warunki korzystania z podprocesorów, pomoc, usunięcie lub zwrot danych oraz obowiązki informacyjne i audytowe. Przekazywanie danych do państw trzecich wymaga odrębnej oceny na podstawie rozdziału V; sam hosting w UE nie rozstrzyga kwestii dostępu ani dalszego przekazywania.

Art. 21 NIS2 obejmuje bezpieczeństwo łańcucha dostaw oraz uwzględnianie podatności i praktyk w zakresie cyberbezpieczeństwa bezpośrednich dostawców. Praktyczne oczekiwania umowne mogą obejmować ograniczenia dostępu, obsługę podatności, współpracę przy incydentach i dostarczanie dowodów. Dostosuj je do usługi i wymogów krajowych, zamiast traktować jeden uniwersalny pakiet klauzul jako prawnie wystarczający.

Art. 30 DORA określa postanowienia umowne dotyczące usług ICT, z dodatkowymi wymogami dla usług wspierających funkcje krytyczne lub istotne. Przeanalizuj opisy usług, lokalizacje, ochronę i odzyskiwanie danych, pomoc, wypowiedzenie i odpowiednie uprawnienia nadzorcze. Funkcje krytyczne lub istotne wymagają szczególnej uwagi w zakresie poziomów usług, sprawozdawczości, planów awaryjnych, współpracy przy testach, prawa do audytu i ustaleń dotyczących okresu przejściowego.

Następnie zweryfikuj wdrożenie. Jeżeli umowa obiecuje ograniczony dostęp administracyjny, uzyskaj dowody rozdziału ról, uwierzytelniania, zatwierdzania i logowania. Jeżeli obiecuje usunięcie danych, ustal, co dzieje się z kopiami zapasowymi i przechowywanymi zapisami. Przypisz luki prawne i techniczne właściwym weryfikującym.

Zaprojektuj przekazania w razie incydentu, zanim do niego dojdzie

Polityka reagowania na incydenty dostawcy może wspierać ocenę bezpieczeństwa, pozostawiając nierozstrzygnięte obowiązki dotyczące zgłaszania. Określ kanały kontaktu, dostępność eskalacji, informacje wstępne, oczekiwania dotyczące aktualizacji i odpowiedzialność za zabezpieczenie dowodów.

Zgodnie z art. 33–34 RODO podmiot przetwarzający zgłasza naruszenie administratorowi bez zbędnej zwłoki. Administrator ocenia potrzebę zgłoszenia organowi nadzorczemu bez zbędnej zwłoki i, jeśli to wykonalne, w ciągu 72 godzin po stwierdzeniu naruszenia, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych. Wysokie ryzyko może wymagać zawiadomienia osób, których dane dotyczą, z zastrzeżeniem wyjątków. Zapisz uzasadnienie, jeśli zgłoszenie nie jest wymagane.

Unijne etapy zgłaszania poważnych incydentów na podstawie NIS2 obejmują wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin i co do zasady sprawozdanie końcowe w ciągu miesiąca od zgłoszenia; sprawdź przepisy krajowe i sektorowe. DORA ma własne ramy zgłaszania poważnych incydentów związanych z ICT. Nie zastępuj tych ocen jednym znacznikiem „naruszenia” u dostawcy.

W praktyce zalecamy przećwiczenie incydentu u dostawcy na podstawie niepełnych informacji. Sprawdź, czy zespoły potrafią ustalić usługi, których dotyczy incydent, ekspozycję, wpływ operacyjny i decyzje dotyczące zgłoszeń bez czekania na końcowy raport z analizy przyczyn.

Przykład: jedna usługa, trzy ścieżki przeglądu

Załóżmy przykładowo, że objęty podmiot finansowy korzysta z hostowanej platformy obsługi klienta, która przetwarza dane osobowe i wspiera funkcję sklasyfikowaną przez niego jako krytyczna lub istotna w rozumieniu DORA.

Dostawca przedstawia raport zapewnienia, politykę dotyczącą incydentów i podsumowanie testu odtwarzania. Zespół bezpieczeństwa stwierdza, że kontrola dostępu administracyjnego jest poparta dowodami, ale test odtwarzania nie obejmuje integracji klienta.

Zespół ochrony danych odrębnie identyfikuje niejasny proces zmiany podprocesorów i nierozstrzygnięte kwestie przekazywania danych w związku z dostępem zdalnym. Przegląd pod kątem DORA wykazuje, że uwagi wymagają pomoc w okresie przejściowym i odpowiednie postanowienia dotyczące audytu.

Wynikowy plan działań jest konkretny:

• Właściciel techniczny testuje odtwarzanie integracji i dokumentuje wynik.
• Osoba weryfikująca kwestie ochrony danych rozstrzyga kwestie podprocesorów i przekazywania danych.
• Dział prawny i dział zakupów zajmują się lukami w umowie.
• Odpowiedzialny właściciel decyduje, czy tymczasowe korzystanie z usługi jest akceptowalne, określając warunki i datę przeglądu.

Dowody są wykorzystywane ponownie, ale żaden z trzech wniosków nie jest wyprowadzany z innego. Pozytywny przegląd bezpieczeństwa nie zamyka luk w zakresie ochrony danych ani odporności.

Monitoruj zmiany, koncentrację i wykonalność wyjścia

Ustal częstotliwość przeglądów stosownie do zależności i ryzyka. Uruchamiaj dodatkowy przegląd po incydentach, istotnych zmianach usługi, pojawieniu się nowych podprocesorów, zmianach lokalizacji danych, zmianach właścicielskich lub przy odnowieniu umowy.

Patrz głębiej niż na nazwy dostawców: kilka usług może zależeć od tego samego regionu chmury, dostawcy tożsamości lub podwykonawcy. Oceń skorelowane zakłócenia i to, czy proponowana alternatywa nie ma tej samej zależności. Art. 29 DORA wprost dotyczy oceny ryzyka koncentracji ICT.

Utrzymuj proporcjonalny plan wyjścia obejmujący eksport danych, migrację, ciągłość, odebranie dostępu i dowody usunięcia danych. Testuj użyteczność eksportu i ustal, kto może obsługiwać rozwiązanie zastępcze. Prawo do wypowiedzenia umowy jest bardziej użyteczne, gdy organizacja jest w stanie z niego skorzystać.

Różnią się także konsekwencje. RODO przewiduje progi kar zależne od rodzaju naruszenia; NIS2 wymaga krajowych systemów sankcji z różnymi górnymi granicami dla podmiotów kluczowych i ważnych. Sankcje DORA wobec podmiotów finansowych zależą od mających zastosowanie rozwiązań, a kary w ramach nadzoru nad kluczowymi dostawcami są odrębne. Nie modeluj ekspozycji, opierając się na jednej rzekomo uniwersalnej karze.

Zacznij od jednej zależności o istotnych skutkach

Wybierz jednego dostawcę wspierającego ważną funkcję. Uzgodnij jego inwentarz usług, umowy, dowody, otwarte ryzyka i założenia dotyczące wyjścia. Zakończ pracę wskazaniem właścicieli oraz odrębnymi, datowanymi wnioskami dla każdego mającego zastosowanie obowiązku.

W Secani zespoły mogą zamodelować usługę i zewnętrznego dostawcę, powiązać wymagania i zabezpieczenia z dowodami oraz śledzić luki jako zadania z przypisanymi właścicielami. Decyzje zweryfikowane przez człowieka, linki do źródeł, komentarze i znaczniki czasu zachowują uzasadnienie. Wspiera to wspólny kontekst dotyczący dostawcy, nie ukrywając odrębnych ocen w zakresie ochrony danych, bezpieczeństwa i odporności.