Powierzenie danych zewnętrznemu dostawcy nie oznacza powierzenia mu odpowiedzialności administratora. To jedna z najważniejszych zasad, o której organizacje powinny pamiętać w przypadku incydentów bezpieczeństwa występujących u dostawców systemów IT, hostingu, chmury, usług kadrowych czy innych podmiotów przetwarzających.
Przypomniał o tym Prezes Urzędu Ochrony Danych Osobowych w związku z doniesieniami medialnymi dotyczącymi wycieku danych niemal 19 mln Polaków u dostawcy systemu Elektronicznej Dokumentacji Medycznej MyDr. UODO zwrócił się bezpośrednio do administratorów, którzy powierzyli tej firmie przetwarzanie danych, wskazując na konieczność przeprowadzenia analizy ryzyka i ustalenia, czy w konkretnym przypadku powstał obowiązek zgłoszenia naruszenia oraz zawiadomienia osób, których dane dotyczą.
Incydent jest u dostawcy. Czy to jego problem?
Nie, a właśnie tutaj w praktyce pojawia się jeden z najczęstszych błędów.
Administrator korzysta z systemu dostarczanego przez zewnętrzną firmę. Dane są przechowywane na infrastrukturze dostawcy. Atak następuje na system dostawcy, a nie bezpośrednio na infrastrukturę administratora. Może więc pojawić się przekonanie:
„To nie u nas doszło do wycieku, więc to dostawca powinien zgłosić naruszenie do UODO”.
Z punktu widzenia RODO sytuacja wygląda inaczej.
Podmiot przetwarzający po stwierdzeniu naruszenia ma obowiązek bez zbędnej zwłoki poinformować administratora. To jednak administrator dokonuje oceny ryzyka i podejmuje decyzję, czy naruszenie wymaga zgłoszenia organowi nadzorczemu oraz czy konieczne jest zawiadomienie osób, których dane dotyczą. Procesor ma więc obowiązek informacyjny wobec administratora. Nie przejmuje natomiast automatycznie jego obowiązków wynikających z art. 33 i 34 RODO.
Każdy administrator musi ocenić swoją sytuację
To szczególnie istotne w przypadku dużych dostawców obsługujących wielu klientów. Jeden incydent u procesora może oznaczać potencjalne naruszenie dotyczące danych powierzonych przez dziesiątki, setki, a nawet tysiące administratorów. Nie oznacza to jednak, że wszyscy administratorzy mają identyczną sytuację.
UODO wskazuje, że zanim administrator rozpocznie realizację obowiązków wynikających z art. 33 i 34 RODO, powinien otrzymać od procesora informację potwierdzającą, że incydent rzeczywiście obejmował dane przetwarzane w jego imieniu.
Następnie musi przeanalizować m.in.:
- jakie kategorie danych zostały objęte naruszeniem,
- ilu osób może ono dotyczyć,
- czy doszło do naruszenia poufności, integralności lub dostępności danych,
- czy osoby można łatwo zidentyfikować,
- jakie mogą być konsekwencje wykorzystania danych przez osoby nieuprawnione,
- czy zastosowane zabezpieczenia ograniczają ryzyko,
- jakie działania zostały już podjęte w celu ograniczenia skutków incydentu.
To nie procesor powinien ostatecznie odpowiedzieć za administratora na pytanie: „Czy nasze naruszenie podlega zgłoszeniu?” Ta odpowiedzialność pozostaje po stronie ADO.
Czy każde naruszenie trzeba zgłosić do UODO?
Nie — i to rozróżnienie jest bardzo ważne.
Art. 33 ust. 1 RODO przewiduje zgłoszenie naruszenia organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, aby naruszenie skutkowało ryzykiem dla praw lub wolności osób fizycznych. UODO również podkreśla, że obowiązek zgłoszenia nie ma charakteru bezwzględnego. W praktyce możemy więc mieć trzy sytuacje.
Brak prawdopodobnego ryzyka – administrator dokumentuje naruszenie i wynik przeprowadzonej analizy, ale nie musi zgłaszać go Prezesowi UODO.
Występuje ryzyko naruszenia praw lub wolności osób fizycznych – administrator zgłasza naruszenie Prezesowi UODO.
Występuje wysokie ryzyko – oprócz zgłoszenia do UODO administrator co do zasady musi również bez zbędnej zwłoki zawiadomić osoby, których dane dotyczą.
Dlatego sformułowanie „administrator zgłasza wyciek u procesora” należy rozumieć prawidłowo: to administrator odpowiada za realizację obowiązku zgłoszeniowego, jeżeli przeprowadzona przez niego analiza wykaże, że zachodzą przesłanki do zgłoszenia.
Przy danych o zdrowiu analiza ryzyka nabiera szczególnego znaczenia
Przypadek związany z systemem Elektronicznej Dokumentacji Medycznej bardzo dobrze pokazuje, dlaczego analiza nie może ograniczać się do prostego stwierdzenia: „doszło do wycieku”. Trzeba odpowiedzieć na pytanie, jakie realne konsekwencje naruszenie może mieć dla konkretnych osób.
UODO zwraca uwagę, że ujawnienie imienia, nazwiska i numeru PESEL może wiązać się m.in. z ryzykiem wykorzystania danych do wyłudzeń. W przypadku danych dotyczących zdrowia konsekwencje mogą obejmować również dyskryminację, ostracyzm społeczny czy naruszenie dóbr osobistych. Dlatego ocena ryzyka nie może być formalnością wykonaną jedynie po to, aby „mieć dokument w teczce”. Powinna odpowiadać na rzeczywiste pytanie:
Co może się wydarzyć osobie, której dane znalazły się w rękach nieuprawnionego podmiotu?
72 godziny to bardzo mało
Jeżeli analiza wykaże konieczność zgłoszenia naruszenia, administrator ma — w miarę możliwości — maksymalnie 72 godziny od jego stwierdzenia na przekazanie zgłoszenia do Prezesa UODO. Jeżeli zgłoszenie następuje później, trzeba wyjaśnić przyczyny opóźnienia. Dlatego procedura współpracy z procesorem w przypadku incydentu nie powinna być ustalana dopiero wtedy, gdy incydent już wystąpi. Umowy powierzenia i wewnętrzne procedury powinny umożliwiać administratorowi szybkie uzyskanie informacji potrzebnych do oceny zdarzenia. W praktyce znaczenie mają m.in. jasno określone kanały komunikacji, osoby kontaktowe oraz sposób przekazywania informacji o potencjalnych naruszeniach.
Jeżeli administrator dowiaduje się jedynie, że „doszło do incydentu”, ale przez kolejne godziny nie wie, czy jego dane zostały objęte zdarzeniem, ilu osób dotyczy problem i jaki zakres informacji został ujawniony, prawidłowa realizacja obowiązków wynikających z RODO staje się niezwykle trudna.
Co powinien zrobić administrator po informacji o incydencie u procesora?
Z perspektywy IOD rekomenduję przede wszystkim uporządkowane działanie:
- Nie opierać się wyłącznie na doniesieniach. Należy wystąpić do procesora o oficjalną informację dotyczącą incydentu.
- Ustalić, czy naruszenie obejmuje dane konkretnego administratora.
- Pozyskać możliwie pełne informacje o zdarzeniu – jego charakterze, zakresie danych, liczbie osób, czasie trwania, możliwym dostępie osób nieuprawnionych oraz zastosowanych środkach zaradczych.
- Przeprowadzić i udokumentować analizę ryzyka naruszenia praw lub wolności osób fizycznych.
- Ocenić obowiązek zgłoszenia do Prezesa UODO.
- Jeżeli występuje wysokie ryzyko – ocenić również obowiązek zawiadomienia osób, których dane dotyczą.
- Udokumentować cały proces decyzyjny, także wtedy, gdy ostatecznie administrator uzna, że zgłoszenie do organu nadzorczego nie jest wymagane.
IOD może doradzać. Odpowiedzialność pozostaje po stronie administratora
W sytuacji naruszenia rola Inspektora Ochrony Danych jest szczególnie istotna. IOD może wspierać administratora w pozyskaniu informacji od procesora, ocenie charakteru zdarzenia, analizie ryzyka, przygotowaniu zgłoszenia oraz opracowaniu komunikacji do osób, których dane dotyczą. Trzeba jednak pamiętać o podstawowej zasadzie: zewnętrzny dostawca systemu nie przejmuje odpowiedzialności administratora tylko dlatego, że to w jego infrastrukturze doszło do incydentu.
Procesor informuje – Administrator analizuje – Administrator ocenia ryzyko – Administrator realizuje obowiązek zgłoszeniowy, jeśli zachodzą przesłanki określone w RODO.
I właśnie dlatego incydenty u dostawców powinny być uwzględniane nie tylko w umowach powierzenia, ale również w procedurach reagowania na naruszenia i planach zarządzania kryzysowego organizacji.