Powierzenie danych dostawcy IT: odpowiedzialność nie kończy się na umowie

Najpierw rola podmiotów

Zanim podpisze się umowę, trzeba ustalić, kto określa cele i zasadnicze sposoby przetwarzania. Dostawca hostingu, systemu płacowego lub wsparcia technicznego może być podmiotem przetwarzającym, lecz kwalifikacja zależy od faktycznego modelu usługi. Sama nazwa kontraktu nie przesądza roli prawnej. Jeśli dostawca samodzielnie wykorzystuje dane we własnym celu, potrzebna może być odrębna analiza podstaw i odpowiedzialności, zamiast automatycznego przyjęcia modelu powierzenia.

Wybór wykonawcy jako decyzja o ryzyku

Art. 28 RODO wymaga korzystania z podmiotów dających wystarczające gwarancje wdrożenia odpowiednich środków. W praktyce warto sprawdzić architekturę dostępu, lokalizację zasobów, politykę kopii zapasowych, procedurę reagowania na incydenty i możliwość udokumentowania działań. Certyfikat może być użyteczną wskazówką, ale nie zastępuje badania zakresu, jakiego rzeczywiście dotyczy. Inne ryzyko niesie formularz kontaktowy, inne przetwarzanie dokumentacji zdrowotnej.

Instrukcje, poufność i środki bezpieczeństwa

Umowa z art. 28 powinna odpowiadać rzeczywistym operacjom przetwarzania i zawierać wymagane elementy, w tym przedmiot, czas trwania, cel, kategorie danych i osób oraz zobowiązania stron. Kluczowe są instrukcje administratora, zasady poufności i wymagania bezpieczeństwa. Szablon, którego dostawca operacyjnie nie przestrzega, daje słabą ochronę. Rzetelna umowa powinna również określać, jak strony dokumentują zgodność i komunikują zmiany w usłudze.

Podwykonawcy i łańcuch usług

Dostawca główny może korzystać z centrów danych, narzędzi analitycznych lub zewnętrznego wsparcia. Trzeba zidentyfikować dalszych przetwarzających oraz procedurę udzielania zgody i informowania o zmianach, zgodną z art. 28. Szczególnej uwagi wymaga dostęp z państw trzecich: sama lokalizacja serwera w Unii nie rozstrzyga wszystkich kwestii transferu. Każdy etap należy oceniać na podstawie faktów, a nie marketingowego opisu usługi.

Incydent nie kończy się na telefonie do IT

Zdarzenie bezpieczeństwa wymaga wyraźnego podziału odpowiedzialności za wykrycie, ograniczenie szkód, udokumentowanie zdarzenia i ocenę obowiązków informacyjnych. Dostawca powinien bez zbędnej zwłoki przekazywać administratorowi informacje o naruszeniu zgodnie z prawem i umową. Nie należy utożsamiać każdego alarmu technicznego z naruszeniem danych osobowych, ani odwrotnie — bagatelizować incydentu tylko dlatego, że system nadal działa.

Zakończenie współpracy i audyt

Bezpieczne rozwiązanie kontraktu obejmuje zwrot albo usunięcie danych w odpowiednim zakresie, kontrolę kopii, odebranie uprawnień i potwierdzenie wykonania obowiązków. Równie ważna jest możliwość audytu i uzyskania informacji koniecznych do wykazania zgodności. Administrator powinien zaplanować wyjście z usługi przed jej rozpoczęciem, inaczej przy awaryjnej zmianie dostawcy może stracić kontrolę nad danymi i ciągłością działania.

Podpisanie umowy nie zastępuje weryfikacji dostawcy

Art. 28 RODO wymaga odpowiedniego uregulowania relacji administratora i podmiotu przetwarzającego, ale sama klauzula powierzenia nie dowodzi, że dostawca faktycznie spełnia wymagania bezpieczeństwa. Warto ustalić zakres danych, lokalizacje ich przechowywania, dalszych podwykonawców, procedury reagowania na incydent i sposób zwracania lub usuwania informacji po zakończeniu usługi. Nie każdy dostawca automatycznie jest procesorem; jego rola zależy od rzeczywistego ustalania celów i środków przetwarzania.

Kontrola zmian w usłudze

W relacjach długoterminowych znaczenie mają zmiany infrastruktury, nowych podwykonawców i zakresu usług. Administrator powinien dysponować mechanizmem uzyskiwania informacji o istotnych zmianach i oceny związanego z nimi ryzyka. Audyt może obejmować dokumentację, testy bezpieczeństwa lub niezależne certyfikacje, ale jego forma powinna być proporcjonalna do rodzaju danych. Nie należy ujawniać nadmiernej liczby informacji technicznych, jeżeli cel weryfikacji można osiągnąć w bezpieczniejszy sposób.

Powierzenie a samodzielna rola dostawcy

Samo podpisanie umowy nazwanej „powierzeniem” nie przesądza, że dostawca IT rzeczywiście działa wyłącznie jako podmiot przetwarzający. Trzeba zbadać, kto określa cele i istotne sposoby przetwarzania, czy dostawca wykorzystuje dane dla własnych celów oraz jakie usługi faktycznie wykonuje. Art. 28 RODO wymaga konkretnych elementów umowy, w tym zasad korzystania z dalszych podmiotów przetwarzających, bezpieczeństwa i współpracy. Nie jest wystarczająca ogólna klauzula o „pełnej zgodności z RODO”.

Audyt rzeczywistych przepływów informacji

Administrator powinien wiedzieć, gdzie dane są przechowywane, kto ma uprawnienia administracyjne, jakie istnieją kopie zapasowe, przez jakie państwa odbywa się dostęp techniczny i jak kończy się współpraca. Istotne są procedury zgłaszania incydentu, usuwania danych i weryfikacji podwykonawców. Nie każde korzystanie z zagranicznej chmury oznacza niedozwolony transfer, ale ocena musi uwzględniać faktyczny dostęp oraz właściwe podstawy prawne. Kontrola nie powinna ograniczać się do zebrania certyfikatu od dostawcy.

Umowa nie wystarcza bez zgodności faktycznych działań

Administrator powinien ustalić, czy dostawca IT rzeczywiście przetwarza dane wyłącznie na udokumentowane polecenie, czy używa ich dla własnych celów. Od tego zależy właściwy podział ról i podstawy prawne. Art. 28 RODO wymaga określonej treści umowy, lecz formalne podpisanie dokumentu nie gwarantuje prawidłowego działania systemu. Należy zweryfikować podwykonawców, zakres dostępu, lokalizację danych i zasady zakończenia współpracy.

Zdarzenia bezpieczeństwa i audyt dostawcy

Ważne są terminy zgłaszania incydentów, możliwość pozyskania logów, procedury przywracania danych oraz sposób sprawdzenia skuteczności zabezpieczeń. Administrator powinien mieć plan reagowania na naruszenie dotyczące danych u dostawcy. Sam certyfikat bezpieczeństwa nie zastępuje oceny konkretnej usługi i rodzaju powierzonych informacji. Jeżeli dochodzi do przekazywania danych poza EOG, należy osobno przeanalizować odpowiednie mechanizmy prawne.

Źródła pierwotne

Art. 5, 28 i 32 RODO (rozporządzenie 2016/679). Urzędowy tekst aktu.