RODO w aplikacji SaaS — administrator, procesor, DPA i polityka prywatności

Model Software as a Service stał się jednym z podstawowych sposobów dostarczania oprogramowania. Zamiast instalować program na własnych serwerach, klient uzyskuje dostęp do aplikacji przez przeglądarkę internetową lub interfejs API, a za utrzymanie infrastruktury, aktualizacje, bezpieczeństwo techniczne i dostępność rozwiązania odpowiada dostawca. W ten sposób oferowane są dziś systemy CRM, programy księgowe, narzędzia HR, platformy marketingowe, systemy obsługi klientów, aplikacje do zarządzania projektami, rozwiązania analityczne, systemy medyczne oraz narzędzia wykorzystujące sztuczną inteligencję.

Prostota biznesowa modelu SaaS nie oznacza jednak prostoty prawnej. Jedna aplikacja może przetwarzać dane użytkowników zakładających konta, pracowników klienta, kontrahentów, osób kontaktowych, kandydatów do pracy, klientów końcowych oraz osób, których dane zostały wprowadzone do systemu przez organizację korzystającą z usługi. W zależności od konkretnej operacji dostawca SaaS może występować jako administrator danych, podmiot przetwarzający, a niekiedy jako odrębny administrator w odniesieniu do części informacji.

Prawidłowe rozróżnienie tych ról jest kluczowe, ponieważ wpływa na zakres odpowiedzialności, podstawy prawne przetwarzania, obowiązki informacyjne, treść umowy powierzenia, zasady korzystania z podwykonawców, obsługę żądań osób oraz odpowiedzialność za naruszenia ochrony danych.

Jednym z najczęściej popełnianych błędów jest przyjęcie, że dostawca aplikacji SaaS zawsze jest wyłącznie procesorem. W praktyce może on być procesorem w odniesieniu do danych wprowadzonych przez klienta, a jednocześnie administratorem danych osób reprezentujących klienta, danych rozliczeniowych, informacji związanych z bezpieczeństwem konta, historii kontaktu z pomocą techniczną albo danych wykorzystywanych do dochodzenia roszczeń.

Drugim częstym błędem jest traktowanie polityki prywatności jako dokumentu, który zastępuje umowę powierzenia przetwarzania danych. Są to dwa odrębne instrumenty. Polityka prywatności służy przede wszystkim realizacji obowiązku informacyjnego wobec osób, których dane są przetwarzane. Umowa powierzenia, często określana jako DPA, reguluje natomiast relację pomiędzy administratorem a procesorem.

Dostawca SaaS powinien zatem uporządkować nie tylko treść dokumentów publikowanych na stronie, ale cały model przetwarzania danych. Konieczne jest ustalenie źródeł danych, celów ich wykorzystywania, relacji z klientami, lokalizacji infrastruktury, zasad korzystania z podwykonawców, okresów przechowywania, procedur bezpieczeństwa oraz sposobu zakończenia świadczenia usługi.

Czym jest aplikacja SaaS?

SaaS, czyli Software as a Service, jest modelem świadczenia usługi polegającym na udostępnieniu klientowi oprogramowania utrzymywanego przez dostawcę. Klient zazwyczaj nie otrzymuje kopii programu do samodzielnej instalacji, lecz dostęp do funkcjonalności aplikacji przez internet.

Dostawca odpowiada za utrzymanie infrastruktury, aktualizowanie oprogramowania, usuwanie błędów, wykonywanie kopii zapasowych, zarządzanie bezpieczeństwem technicznym oraz zapewnienie dostępności usługi. Klient natomiast tworzy konta użytkowników, konfiguruje aplikację i decyduje, jakie informacje będą w niej przechowywane.

W typowym modelu klient biznesowy może przykładowo korzystać z aplikacji CRM i wprowadzać do niej dane swoich klientów, potencjalnych klientów, kontrahentów i pracowników. Dostawca SaaS zapewnia infrastrukturę i funkcje systemu, ale nie decyduje, w jakim celu klient gromadzi dane poszczególnych osób ani jak długo powinien je przechowywać.

Już ten prosty przykład pokazuje, że jedna usługa może obejmować kilka odmiennych operacji przetwarzania. Dane klientów końcowych mogą być przetwarzane przez dostawcę na zlecenie klienta, natomiast dane osoby, która zawarła umowę SaaS, mogą być wykorzystywane przez dostawcę we własnych celach związanych z rozliczeniem usługi, obsługą konta i dochodzeniem należności.

Nie można zatem ustalić roli wyłącznie na podstawie nazwy strony umowy. Określenie „usługodawca”, „operator platformy” albo „dostawca systemu” nie rozstrzyga, czy podmiot jest administratorem, procesorem czy współadministratorem. Rola musi wynikać z rzeczywistego sposobu podejmowania decyzji o celach i zasadniczych sposobach przetwarzania.

Administrator danych w aplikacji SaaS

Administratorem jest podmiot, który samodzielnie albo wspólnie z innymi ustala cele i sposoby przetwarzania danych osobowych. Oznacza to, że administrator decyduje, dlaczego dane są potrzebne, do czego będą wykorzystywane oraz jakie podstawowe elementy procesu powinny zostać zastosowane.

Pojęcia administratora i procesora mają charakter funkcjonalny. Nie zależą wyłącznie od postanowień umowy ani od tego, jak strony postanowią się nazwać. Europejska Rada Ochrony Danych podkreśla, że role powinny być przypisywane zgodnie z rzeczywistymi działaniami stron i faktycznym wpływem na cele oraz zasadnicze środki przetwarzania. (Europejski Organ Ochrony Danych)

W przypadku aplikacji SaaS klient biznesowy jest zazwyczaj administratorem danych, które sam wprowadza do systemu w związku ze swoją działalnością. Jeżeli firma korzysta z systemu CRM i przechowuje w nim informacje o klientach, to właśnie ta firma ustala cel przetwarzania. Dane są gromadzone po to, aby prowadzić sprzedaż, realizować umowy, obsługiwać zgłoszenia, prowadzić marketing albo wykonywać obowiązki prawne.

Podobnie pracodawca korzystający z aplikacji kadrowej pozostaje administratorem danych pracowników. To on decyduje o zatrudnieniu, zakresie prowadzonej dokumentacji, naliczaniu wynagrodzeń i okresach przechowywania danych. Dostawca systemu zapewnia narzędzie techniczne, ale nie staje się przez to administratorem całej dokumentacji pracowniczej.

Klient jako administrator odpowiada między innymi za posiadanie właściwej podstawy prawnej, realizację obowiązku informacyjnego, przestrzeganie zasady minimalizacji, ustalenie okresów przechowywania oraz obsługę praw osób, których dane znajdują się w aplikacji.

Administrator nie może zatem uznać, że po wykupieniu dostępu do systemu cała odpowiedzialność za RODO przechodzi na dostawcę. Korzystanie z procesora nie pozbawia administratora odpowiedzialności za legalność operacji i wybór odpowiedniego usługodawcy.

Kiedy dostawca SaaS jest procesorem?

Podmiotem przetwarzającym, określanym również jako procesor, jest podmiot, który przetwarza dane osobowe w imieniu administratora.

W modelu SaaS procesorem będzie zazwyczaj dostawca w zakresie, w jakim przechowuje, porządkuje, udostępnia, zabezpiecza albo usuwa dane wprowadzone przez klienta. Dostawca nie realizuje wówczas własnego celu biznesowego dotyczącego osób, których dane znajdują się w systemie, lecz wykonuje usługę na rzecz klienta.

Do uznania podmiotu za procesora konieczne jest przede wszystkim to, aby był odrębnym podmiotem od administratora i przetwarzał dane na jego rzecz. Procesor nie powinien wykorzystywać danych w celach niezależnych od instrukcji klienta. Może natomiast samodzielnie dobierać część środków technicznych i organizacyjnych, jeżeli służą one prawidłowemu wykonaniu usługi. (Europejski Organ Ochrony Danych)

Przykładowo dostawca może decydować o rodzaju bazy danych, mechanizmie wykonywania kopii zapasowych, sposobie skalowania infrastruktury i szczegółach zabezpieczenia sieci. Nie oznacza to jeszcze, że staje się administratorem danych klienta. Są to techniczne sposoby wykonania usługi.

Sytuacja zmienia się jednak, gdy dostawca zaczyna wykorzystywać dane klienta dla własnych celów. Jeżeli analizuje treść rekordów w celu prowadzenia niezależnego marketingu, sprzedaży baz danych, tworzenia profili osób lub trenowania własnego modelu AI bez odpowiedniej podstawy i niezależnie od instrukcji klienta, może zostać uznany za administratora w odniesieniu do tych operacji.

Procesor, który sam zaczyna określać cele i zasadnicze sposoby przetwarzania, jest traktowany jako administrator w zakresie wykraczającym poza polecenia klienta. Może wówczas ponosić odpowiedzialność za naruszenie RODO jako odrębny administrator. (Europejski Organ Ochrony Danych)

Dostawca SaaS może pełnić różne role jednocześnie

Klasyfikowanie całej działalności dostawcy jako jednej roli często prowadzi do błędów. Rola powinna być oceniana osobno dla poszczególnych operacji i kategorii danych.

Dostawca może działać jako procesor w odniesieniu do danych przechowywanych przez klienta w systemie. Jednocześnie może być administratorem danych właściciela konta, użytkowników administracyjnych i osób kontaktujących się z pomocą techniczną.

Dane rozliczeniowe, informacje o płatnościach, dane reprezentantów klienta i historia wystawianych faktur są przetwarzane przez dostawcę we własnym celu. Celem jest zawarcie i wykonanie umowy, rozliczenie wynagrodzenia, realizacja obowiązków podatkowych oraz dochodzenie roszczeń. W tym zakresie klient nie wydaje dostawcy instrukcji przetwarzania.

Podobnie może być z danymi bezpieczeństwa. Dostawca może przetwarzać adresy IP, identyfikatory urządzeń, historię logowania i logi administracyjne w celu zabezpieczenia swojej infrastruktury, wykrywania nadużyć oraz ochrony pozostałych klientów. W zależności od konstrukcji usługi i zakresu niezależności może występować w tym zakresie jako administrator albo wykonywać część czynności również na rzecz klienta.

Prawidłowy model powinien zatem rozdzielać co najmniej dane konta klienta, dane użytkowników usługi, dane wprowadzone przez klienta oraz dane techniczne związane z bezpieczeństwem i utrzymaniem platformy.

Administrator, procesor czy współadministrator?

W niektórych projektach pojawia się pytanie o współadministrację. Współadministratorami są podmioty, które wspólnie ustalają cele i sposoby przetwarzania.

Nie oznacza to, że każdy dostawca SaaS i jego klient są automatycznie współadministratorami. Sam fakt współpracy, wymiany danych albo technicznego wpływu dostawcy na system nie wystarcza.

W typowym modelu dostawca nie uczestniczy w ustalaniu celu, dla którego klient gromadzi dane swoich klientów lub pracowników. W takim przypadku relacja administrator–procesor jest bardziej właściwa.

Współadministracja może jednak wystąpić, gdy dostawca i klient wspólnie projektują proces, określają cele analizy danych, wybierają grupę osób, której dane mają zostać wykorzystane, i wspólnie korzystają z wyników. Możliwe jest to przykładowo w przypadku platformy analitycznej, której operator nie ogranicza się do zapewnienia infrastruktury, lecz aktywnie współdecyduje o tworzeniu profili użytkowników i wykorzystuje je we własnej działalności.

Nie należy nadużywać konstrukcji współadministracji tylko dlatego, że prawidłowe rozdzielenie ról jest trudne. Współadministrowanie wiąże się z obowiązkiem dokonania uzgodnień określających zakres odpowiedzialności stron, w szczególności w zakresie realizacji obowiązku informacyjnego i praw osób.

Czy klient SaaS zawsze jest przedsiębiorcą?

Model SaaS może być kierowany zarówno do przedsiębiorców, jak i konsumentów. W usłudze B2B klientem jest zazwyczaj organizacja, która tworzy konta dla pracowników i wykorzystuje system w ramach własnej działalności. W usłudze B2C osoba zakładająca konto może być bezpośrednim użytkownikiem i osobą, której dane są przetwarzane.

W aplikacji oferowanej konsumentom dostawca zazwyczaj jest administratorem danych użytkownika, ponieważ sam określa cel i sposób działania usługi. Nie występuje wówczas odrębny klient biznesowy, w imieniu którego dane byłyby przetwarzane.

Możliwy jest także model mieszany. Platforma może oferować konta indywidualne i firmowe. W takim przypadku rola dostawcy będzie zależała od konkretnego rodzaju konta oraz operacji przetwarzania.

Dokumentacja prawna powinna odzwierciedlać te różnice. Jedna ogólna polityka prywatności może być niewystarczająca, jeżeli nie wyjaśnia, kiedy dostawca działa jako administrator, a kiedy jedynie przetwarza dane na rzecz klienta biznesowego.

Dlaczego prawidłowe określenie roli ma znaczenie?

Ustalenie roli wpływa przede wszystkim na to, kto powinien posiadać podstawę prawną przetwarzania.

Administrator musi wskazać, na jakiej podstawie zbiera i wykorzystuje dane. Może być nią wykonanie umowy, obowiązek prawny, uzasadniony interes, zgoda albo inna przesłanka przewidziana w RODO. Procesor nie ustala własnej podstawy prawnej dla operacji wykonywanych na zlecenie administratora. Podstawą jego działania jest relacja z administratorem i udokumentowane polecenia.

Rola wpływa również na treść informacji przekazywanych osobom. Jeżeli dostawca jest administratorem danych użytkownika konta, powinien zrealizować wobec niego obowiązek informacyjny. Jeżeli natomiast jest procesorem danych klientów końcowych wprowadzonych przez firmę korzystającą z aplikacji, zasadniczy obowiązek informacyjny spoczywa na tej firmie.

Nie oznacza to, że polityka prywatności dostawcy powinna przemilczeć przetwarzanie w roli procesora. Warto przejrzyście wyjaśnić model usługi, ale nie należy tworzyć wrażenia, że osoby, których dane wprowadził klient, mogą realizować wszystkie prawa bezpośrednio wobec dostawcy jak wobec administratora.

Czym jest DPA?

DPA, czyli Data Processing Agreement, to umowa regulująca powierzenie przetwarzania danych osobowych. Jej podstawą jest art. 28 RODO.

Umowa powierzenia może stanowić odrębny dokument albo część głównej umowy SaaS. Może zostać zawarta również elektronicznie. Ważne jest jednak, aby rzeczywiście regulowała wymagane kwestie i była wiążąca dla stron.

DPA nie powinno być traktowane jako krótki, formalny załącznik zawierający wyłącznie stwierdzenie, że dostawca zobowiązuje się przestrzegać RODO. Umowa powinna konkretnie określać zakres i zasady operacji wykonywanych przez procesora.

RODO wymaga, aby umowa określała przedmiot i czas trwania przetwarzania, jego charakter i cel, rodzaj danych osobowych, kategorie osób oraz prawa i obowiązki administratora. Powinna również regulować między innymi poufność, bezpieczeństwo, podprocesorów, pomoc administratorowi, usuwanie lub zwracanie danych oraz audyty. (EUR-Lex)

DPA pełni również funkcję praktyczną. Pozwala klientowi ustalić, gdzie znajdują się dane, kto ma do nich dostęp, jak szybko dostawca zgłosi incydent, co stanie się z danymi po rozwiązaniu umowy oraz jakie informacje zostaną przekazane podczas kontroli.

Przedmiot i czas trwania przetwarzania

DPA powinno jasno wskazywać, jaka usługa jest świadczona i jak długo dane będą przetwarzane.

Nie wystarczy stwierdzenie, że dostawca przetwarza dane w związku ze świadczeniem usług. Należy powiązać przetwarzanie z konkretną aplikacją, zakresem funkcjonalności oraz okresem obowiązywania umowy.

Warto uwzględnić również okres po zakończeniu współpracy. Dane mogą pozostawać przez określony czas w aktywnym systemie, kopiach zapasowych lub archiwach technicznych. Umowa powinna rozróżniać dostęp klienta do danych od przechowywania ich w kopiach bezpieczeństwa.

Jeżeli dostawca przechowuje kopie przez trzydzieści, dziewięćdziesiąt albo sto osiemdziesiąt dni po zamknięciu konta, klient powinien otrzymać tę informację. Należy również określić, czy dane w kopiach są aktywnie wykorzystywane, czy pozostają odizolowane i mogą zostać odtworzone wyłącznie w sytuacji awaryjnej.

Charakter i cel przetwarzania

W umowie należy wyjaśnić, jakie operacje dostawca wykonuje na danych. Może chodzić o przechowywanie, organizowanie, udostępnianie uprawnionym użytkownikom, wykonywanie kopii zapasowych, przesyłanie, usuwanie, szyfrowanie, indeksowanie lub generowanie raportów.

Celem przetwarzania powinno być świadczenie usługi na rzecz administratora zgodnie z umową i jego udokumentowanymi poleceniami.

Należy uważać na bardzo szerokie postanowienia pozwalające dostawcy wykorzystywać dane do „rozwoju usług”, „celów analitycznych” albo „poprawy produktów”. Takie sformułowania mogą prowadzić do niejasności, czy dostawca nadal działa jako procesor.

Poprawianie działania samej usługi może w określonym zakresie należeć do technicznych środków wybieranych przez procesora. Jeżeli jednak dane klientów są wykorzystywane do budowania nowych produktów, trenowania modeli, tworzenia niezależnych baz lub prowadzenia analiz komercyjnych, konieczne jest odrębne ustalenie roli, celu i podstawy prawnej.

Szczególnego znaczenia nabiera to w aplikacjach korzystających z generatywnej sztucznej inteligencji. Dostawca powinien jasno określić, czy treści wprowadzane przez klienta są używane do trenowania modeli, czy funkcja ta może zostać wyłączona oraz jacy zewnętrzni dostawcy modeli uczestniczą w przetwarzaniu.

Rodzaje danych i kategorie osób

DPA powinno wskazywać, jakie rodzaje danych mogą być przetwarzane oraz jakich osób dotyczą.

W przypadku uniwersalnej aplikacji SaaS katalog może być szeroki, ponieważ dostawca nie zawsze wie, jakie dane klient wprowadzi do pól tekstowych. Nie oznacza to jednak, że wystarczy ogólne określenie „wszelkie dane osobowe”.

Należy opisać typowe kategorie, takie jak dane identyfikacyjne, kontaktowe, zawodowe, rozliczeniowe, dane dotyczące aktywności w systemie, treść komunikacji oraz dane zawarte w dokumentach przesyłanych przez klienta.

Warto również wskazać, czy usługa jest przeznaczona do przetwarzania szczególnych kategorii danych, takich jak informacje o zdrowiu, poglądach, biometrii albo przynależności związkowej.

Jeżeli aplikacja nie została zaprojektowana do przechowywania danych wrażliwych, dokumentacja powinna to wyraźnie określać. Sam zakaz umowny nie zastąpi jednak zabezpieczeń technicznych, jeżeli charakter systemu sprawia, że użytkownicy mogą swobodnie przesyłać dowolne treści.

Kategoriami osób mogą być pracownicy klienta, jego klienci, kontrahenci, osoby reprezentujące partnerów, kandydaci do pracy, pacjenci, użytkownicy platformy lub inne osoby wskazane przez administratora.

Udokumentowane polecenia administratora

Procesor powinien przetwarzać dane wyłącznie na udokumentowane polecenie administratora, chyba że obowiązek przetwarzania wynika z prawa.

W usłudze SaaS polecenia nie muszą być każdorazowo wydawane w odrębnej wiadomości. Mogą wynikać z umowy, konfiguracji systemu, działań użytkowników oraz późniejszych instrukcji klienta.

Przykładowo dodanie danych do aplikacji, utworzenie konta pracownika, uruchomienie eksportu albo usunięcie rekordu może stanowić instrukcję wykonaną przez funkcje systemu.

DPA powinno określać sposób przekazywania dodatkowych poleceń oraz osoby uprawnione do ich wydawania. Dostawca nie powinien wykonywać instrukcji pochodzących od dowolnego pracownika klienta, jeżeli mogłoby to prowadzić do ujawnienia lub utraty danych.

Jeżeli procesor uzna, że polecenie narusza RODO lub inne przepisy, powinien niezwłocznie poinformować o tym administratora. Umowa może określać procedurę wstrzymania instrukcji i sposób rozstrzygnięcia sporu.

Obowiązek poufności

Dostawca powinien zapewnić, aby osoby upoważnione do przetwarzania danych zobowiązały się do zachowania poufności albo podlegały odpowiedniemu ustawowemu obowiązkowi tajemnicy.

Dotyczy to pracowników, współpracowników, administratorów systemu, zespołu wsparcia, osób obsługujących incydenty oraz innych osób, które mogą uzyskać dostęp do danych.

Dostęp powinien być ograniczony do zakresu niezbędnego do wykonywania obowiązków. Pracownik działu sprzedaży dostawcy nie powinien mieć dostępu do bazy danych klienta tylko dlatego, że pracuje w tej samej firmie.

Należy stosować zarządzanie rolami, rejestrowanie działań administracyjnych, okresowe przeglądy uprawnień oraz szybkie odbieranie dostępu osobom, które przestały uczestniczyć w obsłudze systemu.

DPA może odwoływać się do polityk bezpieczeństwa dostawcy, ale klient powinien mieć możliwość poznania podstawowych zasad kontroli dostępu.

Bezpieczeństwo przetwarzania

Procesor powinien wdrożyć odpowiednie środki techniczne i organizacyjne, uwzględniając ryzyko związane z przetwarzaniem. RODO nie wskazuje jednego zestawu zabezpieczeń odpowiedniego dla wszystkich aplikacji. Poziom ochrony powinien odpowiadać charakterowi danych, skali usługi, prawdopodobieństwu zagrożeń i możliwym skutkom dla osób. (EUR-Lex)

W praktyce dostawca SaaS powinien analizować między innymi kontrolę dostępu, szyfrowanie transmisji, szyfrowanie danych przechowywanych, izolację środowisk klientów, bezpieczeństwo procesu tworzenia oprogramowania, zarządzanie podatnościami, kopie zapasowe, monitoring, logowanie zdarzeń oraz ciągłość działania.

Szczególne znaczenie ma model wielodostępny, w którym dane wielu klientów znajdują się w jednej logicznej lub fizycznej infrastrukturze. Błąd w mechanizmie autoryzacji może doprowadzić do ujawnienia danych jednego klienta innemu.

DPA lub załącznik bezpieczeństwa powinny przedstawiać zabezpieczenia na tyle konkretnie, aby administrator mógł ocenić, czy dostawca daje wystarczające gwarancje. Ogólna deklaracja o stosowaniu najlepszych praktyk może być niewystarczająca.

Jednocześnie zbyt szczegółowe wpisanie konfiguracji technicznej bezpośrednio do umowy może utrudniać rozwój systemu. Rozwiązaniem może być załącznik opisujący minimalne standardy i mechanizm informowania o zmianach istotnie obniżających poziom ochrony.

Wybór procesora i wystarczające gwarancje

Administrator może korzystać wyłącznie z podmiotów zapewniających wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych. (EUR-Lex)

Klient przed wyborem aplikacji SaaS powinien zatem ocenić dostawcę. Zakres analizy zależy od ryzyka. Przy prostym narzędziu przechowującym służbowe adresy e-mail wymagania będą inne niż przy systemie obsługującym dokumentację medyczną albo dane finansowe.

Ocena może obejmować dokumentację bezpieczeństwa, certyfikaty, wyniki audytów, testy penetracyjne, procedury reagowania na incydenty, lokalizację serwerów, zasady podwykonawstwa, historię naruszeń oraz warunki usuwania danych.

Certyfikat bezpieczeństwa nie zwalnia klienta z odpowiedzialności za ocenę, ale może być jednym z dowodów potwierdzających poziom organizacyjny dostawcy.

Dostawca powinien być gotowy udzielić odpowiedzi na uzasadnione pytania klientów. Jednocześnie nie musi ujawniać informacji, których publikacja mogłaby obniżyć bezpieczeństwo infrastruktury albo naruszyć tajemnice innych klientów.

Podprocesorzy w usłudze SaaS

Dostawca SaaS rzadko realizuje całą usługę samodzielnie. Może korzystać z dostawcy chmury, systemu wysyłki poczty, narzędzia do monitorowania błędów, operatora płatności, systemu obsługi zgłoszeń, dostawcy modeli AI oraz zewnętrznego centrum wsparcia.

Jeżeli podmiot zewnętrzny przetwarza dane powierzone przez klienta w imieniu głównego dostawcy, jest dalszym podmiotem przetwarzającym, czyli podprocesorem.

Procesor nie może dowolnie angażować podprocesorów bez odpowiedniego upoważnienia administratora. Upoważnienie może mieć charakter szczegółowy albo ogólny. Przy upoważnieniu ogólnym procesor powinien informować administratora o planowanym dodaniu lub zastąpieniu podprocesora, dając mu możliwość zgłoszenia sprzeciwu. (EUR-Lex)

W modelu SaaS najczęściej stosuje się zgodę ogólną oraz aktualizowaną listę podprocesorów. Dostawca może publikować ją na stronie internetowej i wysyłać powiadomienia o zmianach.

Samo opublikowanie listy bez mechanizmu informowania o zmianie może być niewystarczające. Klient powinien mieć realną możliwość zapoznania się z planowaną zmianą i zgłoszenia zastrzeżeń przed rozpoczęciem przetwarzania przez nowy podmiot.

Umowa powinna określać konsekwencje sprzeciwu. Może przewidywać wspólne poszukiwanie rozwiązania, wyłączenie określonej funkcji albo możliwość zakończenia umowy, gdy ryzyka nie można ograniczyć.

Odpowiedzialność za podprocesorów

Główny procesor powinien nałożyć na podprocesora obowiązki ochrony danych odpowiadające tym, które wynikają z DPA z klientem.

Nie oznacza to konieczności dosłownego przekazania identycznego dokumentu. Warunki powinny jednak zapewniać odpowiedni poziom poufności, bezpieczeństwa, obsługi incydentów, realizacji praw osób, usuwania danych i współpracy podczas audytów.

Główny dostawca pozostaje wobec klienta odpowiedzialny za wykonanie obowiązków przez podprocesora. Nie powinien zasłaniać się tym, że awaria, naruszenie albo utrata danych nastąpiły po stronie operatora chmury.

DPA powinno zachować odpowiedzialność dostawcy za cały wykorzystywany przez niego łańcuch przetwarzania.

Transfer danych poza EOG

Jednym z kluczowych elementów oceny aplikacji SaaS jest ustalenie, gdzie dane są przetwarzane i z jakich państw mogą uzyskać do nich dostęp pracownicy lub podwykonawcy.

Przetwarzanie poza Europejskim Obszarem Gospodarczym nie jest automatycznie zabronione. Wymaga jednak zastosowania odpowiedniego mechanizmu zgodnego z rozdziałem V RODO.

Może nim być decyzja Komisji Europejskiej stwierdzająca odpowiedni stopień ochrony, standardowe klauzule umowne albo inna podstawa przewidziana w rozporządzeniu.

Samo wskazanie, że serwer znajduje się w Unii Europejskiej, nie zawsze kończy analizę. Dostęp administratorów systemu, wsparcia technicznego albo podprocesora z państwa trzeciego również może mieć znaczenie dla oceny transferu.

Dostawca powinien przekazać klientowi informacje o lokalizacjach, podstawach transferu i zastosowanych środkach uzupełniających. Administrator musi być w stanie uwzględnić te informacje w swojej analizie ryzyka.

Terytorialny zakres stosowania RODO może obejmować również podmioty spoza Unii, w szczególności gdy oferują towary lub usługi osobom znajdującym się w Unii albo monitorują ich zachowanie. Sam brak siedziby w EOG nie oznacza więc automatycznie, że dostawca pozostaje poza zakresem regulacji. (Europejski Organ Ochrony Danych)

Pomoc w realizacji praw osób

Administrator odpowiada za obsługę żądań dotyczących dostępu, sprostowania, usunięcia, ograniczenia przetwarzania, sprzeciwu i przenoszenia danych. Procesor powinien mu w tym pomagać w zakresie możliwym z uwagi na charakter usługi.

W aplikacji SaaS dostawca może zapewnić funkcje wyszukiwania, eksportowania, aktualizowania i usuwania danych. Im więcej czynności klient może wykonać samodzielnie, tym mniejsza potrzeba indywidualnej interwencji zespołu technicznego.

DPA powinno jednak regulować sytuacje, w których realizacja żądania wymaga pomocy dostawcy. Należy określić kanał zgłoszenia, zakres wsparcia, termin reakcji oraz ewentualne zasady rozliczenia niestandardowych prac.

Dostawca będący procesorem nie powinien samodzielnie odpowiadać osobie na żądanie dotyczące danych wprowadzonych przez klienta, chyba że został do tego upoważniony. Powinien przekazać żądanie właściwemu administratorowi.

Jednocześnie polityka prywatności dostawcy powinna wyjaśniać, że w przypadku danych przetwarzanych wyłącznie na rzecz klienta osoba może zostać skierowana do organizacji, która korzysta z systemu.

Naruszenie ochrony danych

Naruszeniem ochrony danych może być utrata dostępności, poufności lub integralności danych. Nie ogranicza się ono do kradzieży bazy przez cyberprzestępcę.

Naruszeniem może być również błędne udostępnienie danych innemu klientowi, usunięcie rekordów bez możliwości odtworzenia, wysłanie kopii danych do niewłaściwego odbiorcy, przejęcie konta administratora albo publiczne udostępnienie pliku.

Administrator może być zobowiązany do zgłoszenia naruszenia organowi nadzorczemu w terminie siedemdziesięciu dwóch godzin od jego stwierdzenia. Procesor powinien natomiast poinformować administratora bez zbędnej zwłoki po stwierdzeniu naruszenia. (EUR-Lex)

DPA powinno doprecyzować tę współpracę. Warto określić maksymalny termin pierwszej informacji, zakres danych przekazywanych w zgłoszeniu, osoby kontaktowe oraz obowiązek regularnego aktualizowania informacji.

Pierwsze zawiadomienie nie musi zawierać pełnej analizy. Dostawca nie powinien jednak zwlekać do zakończenia wewnętrznego dochodzenia, jeżeli klient potrzebuje informacji do wykonania własnego obowiązku.

Procesor powinien przekazać opis zdarzenia, przybliżoną liczbę osób i rekordów, możliwe konsekwencje, zastosowane zabezpieczenia i działania naprawcze. Powinien również zachować logi i inne dowody potrzebne do analizy.

Usunięcie lub zwrot danych po zakończeniu umowy

DPA powinno określać, czy po zakończeniu świadczenia usług procesor zwraca dane administratorowi, usuwa je czy wykonuje obie czynności w określonej kolejności.

W modelu SaaS najczęściej klient otrzymuje okres na eksport danych, po którym konto i dane produkcyjne są usuwane. Kopie zapasowe mogą być przechowywane przez dodatkowy okres wynikający z cyklu backupów.

Zasady powinny być jasne już przy zawieraniu umowy. Klient powinien wiedzieć, w jakim formacie może pobrać dane, jak długo będzie miał dostęp do systemu, czy eksport obejmuje załączniki i metadane oraz kiedy dane zostaną trwale usunięte.

Możliwość eksportu wyłącznie w nieczytelnym albo zamkniętym formacie może w praktyce utrudnić zmianę dostawcy. Warto więc powiązać wymagania RODO z postanowieniami dotyczącymi przenoszalności biznesowej danych i zakończenia usługi.

Jeżeli przepisy zobowiązują dostawcę do zachowania określonych informacji, powinien wyjaśnić podstawę i zakres dalszego przechowywania. Nie może powoływać się na ogólne potrzeby archiwalne bez ustalenia konkretnego celu.

Prawo audytu

Procesor powinien udostępniać administratorowi informacje niezbędne do wykazania spełnienia obowiązków wynikających z art. 28 RODO oraz umożliwiać audyty, w tym inspekcje. (EUR-Lex)

Nie oznacza to, że każdy klient może bez ograniczeń wejść do centrum danych i samodzielnie testować produkcyjną infrastrukturę. Sposób realizacji prawa audytu powinien uwzględniać ryzyko, skalę dostawcy, bezpieczeństwo pozostałych klientów i ochronę tajemnicy przedsiębiorstwa.

W dużych usługach chmurowych podstawowym źródłem informacji mogą być certyfikaty, raporty niezależnych audytorów, kwestionariusze bezpieczeństwa i dokumentacja techniczna. Nie powinny one jednak całkowicie wyłączać dodatkowej kontroli, gdy wystąpi poważny incydent, uzasadnione podejrzenie naruszenia albo żądanie organu.

DPA może określać częstotliwość standardowych audytów, terminy powiadomienia, zasady poufności i podział kosztów. Warunki nie mogą jednak powodować, że prawo audytu staje się wyłącznie teoretyczne.

Polityka prywatności aplikacji SaaS

Polityka prywatności jest dokumentem skierowanym przede wszystkim do osób, których dane są przetwarzane. Powinna w sposób przejrzysty wyjaśniać, kto jest administratorem, jakie dane zbiera, w jakich celach, na jakiej podstawie, jak długo je przechowuje, komu je ujawnia oraz jakie prawa przysługują osobie.

Polityka prywatności nie jest tym samym co DPA. Nie reguluje relacji pomiędzy klientem a dostawcą w zakresie powierzenia danych. Nie zastępuje również regulaminu świadczenia usług.

W aplikacji B2B polityka powinna obejmować przede wszystkim operacje, w których dostawca występuje jako administrator. Mogą to być dane osoby zakładającej konto, użytkowników zaproszonych przez klienta, przedstawicieli kontrahenta, osób kontaktujących się z pomocą techniczną, odbiorców newslettera oraz użytkowników strony internetowej.

Dokument powinien również wyjaśniać, że w odniesieniu do danych wprowadzanych przez klienta dostawca może działać jako procesor. Należy jednak zachować ostrożność, aby nie mieszać obowiązków obu ról.

Kto powinien być wskazany jako administrator?

Polityka powinna podawać pełną nazwę podmiotu, adres, dane rejestrowe i sposób kontaktu. Jeżeli został wyznaczony inspektor ochrony danych, należy wskazać możliwość kontaktu z nim.

W przypadku grupy kapitałowej nie powinno się używać niejasnego określenia „nasza grupa” bez wyjaśnienia, która spółka odpowiada za konkretną usługę.

Jeżeli różne spółki administrują danymi w różnych celach, polityka powinna to rozdzielać. Możliwe jest również wskazanie współadministratorów, jeżeli rzeczywiście wspólnie ustalają cele i sposoby przetwarzania.

Dane identyfikacyjne powinny być spójne z regulaminem, formularzem rejestracyjnym, umową i fakturami. Użytkownik nie powinien otrzymywać sprzecznych informacji o tym, z jakim podmiotem zawiera umowę i kto administruje jego danymi.

Kategorie zbieranych danych

Polityka powinna opisywać dane faktycznie zbierane przez aplikację. Kopiowanie rozbudowanego katalogu z przypadkowego wzoru może prowadzić do informowania o operacjach, których dostawca nie wykonuje, a jednocześnie pominięcia danych rzeczywiście przetwarzanych.

Typowa aplikacja SaaS może zbierać dane identyfikacyjne, służbowe dane kontaktowe, informacje o organizacji, dane rozliczeniowe, adres IP, identyfikatory urządzeń, informacje o przeglądarce, historię logowania, aktywność w aplikacji, treść zgłoszeń do pomocy technicznej oraz ustawienia konta.

Jeżeli aplikacja zapisuje treść wprowadzanych promptów, nagrania rozmów, lokalizację, dane biometryczne albo informacje zdrowotne, polityka powinna to jasno ujawniać.

Należy odróżnić dane podawane bezpośrednio przez osobę od danych otrzymywanych od administratora konta firmowego. Pracownik może zostać dodany do systemu przez pracodawcę, zanim sam po raz pierwszy zaloguje się do aplikacji.

Cele i podstawy prawne

Każdy cel powinien być przypisany do odpowiedniej podstawy prawnej. Nie należy wskazywać wszystkich przesłanek RODO jednocześnie bez wyjaśnienia, która dotyczy konkretnej operacji.

Przetwarzanie danych właściciela jednoosobowej działalności w celu zawarcia i wykonania umowy może opierać się na niezbędności do wykonania umowy. Dane pracownika reprezentującego klienta mogą być przetwarzane na podstawie prawnie uzasadnionego interesu polegającego na zawarciu i obsłudze relacji z organizacją.

Dokumentacja księgowa jest przechowywana w celu wykonania obowiązków prawnych. Dane dotyczące bezpieczeństwa mogą być przetwarzane w prawnie uzasadnionym interesie polegającym na ochronie usługi, klientów i systemów.

Wysyłka marketingu elektronicznego wymaga uwzględnienia nie tylko RODO, lecz również przepisów regulujących komunikację elektroniczną. Polityka nie powinna sugerować, że samo powołanie się na uzasadniony interes zawsze pozwala wysyłać wiadomości marketingowe.

Odbiorcy danych

Polityka powinna wskazywać odbiorców albo kategorie odbiorców. Mogą nimi być dostawcy hostingu, poczty, systemów analitycznych, obsługi klienta, księgowości, płatności i usług bezpieczeństwa.

Nie każdy procesor musi być wymieniony z nazwy w głównej polityce. W wielu przypadkach wystarczające mogą być kategorie odbiorców. W modelu SaaS warto jednak zapewnić łatwy dostęp do aktualnej listy podprocesorów, zwłaszcza klientom biznesowym.

Należy odróżnić podmioty przetwarzające od niezależnych administratorów, takich jak operator płatności, bank, kancelaria albo organ publiczny. Każda z tych relacji może mieć inny charakter.

Informacja nie powinna ograniczać się do stwierdzenia, że dane mogą być udostępniane „zaufanym partnerom”. Osoba powinna być w stanie zrozumieć, jakiego rodzaju podmioty uczestniczą w procesie.

Okresy przechowywania

Polityka powinna wskazywać okres przechowywania danych albo kryteria jego ustalania.

Ogólne stwierdzenie, że dane są przechowywane tak długo, jak jest to konieczne, zwykle nie daje osobie wystarczającej informacji. Warto wskazać konkretne okresy lub zdarzenia kończące przetwarzanie.

Dane konta mogą być przechowywane przez czas obowiązywania umowy, a następnie przez okres niezbędny do rozliczeń i dochodzenia roszczeń. Dokumentacja podatkowa podlega okresom wynikającym z przepisów. Dane marketingowe mogą być przetwarzane do cofnięcia zgody albo wniesienia skutecznego sprzeciwu.

Logi bezpieczeństwa mogą mieć odrębny okres, uzasadniony potrzebą wykrywania incydentów. Kopie zapasowe mogą być usuwane zgodnie z rotacją techniczną.

Okresy opisane w polityce powinny odpowiadać rzeczywistym ustawieniom systemu. Dokument deklarujący natychmiastowe usunięcie danych po zamknięciu konta będzie nieprawidłowy, jeżeli kopie pozostają przez kolejne miesiące bez odpowiedniego wyjaśnienia.

Prawa osoby

Polityka powinna informować o prawie dostępu do danych, sprostowania, usunięcia, ograniczenia, przenoszenia, sprzeciwu oraz cofnięcia zgody, gdy przetwarzanie opiera się na zgodzie.

Należy wyjaśnić, że zakres prawa zależy od podstawy prawnej i okoliczności. Prawo usunięcia nie oznacza bezwzględnego obowiązku skasowania każdego dokumentu, jeżeli jego dalsze przechowywanie wynika z prawa lub jest konieczne do obrony roszczeń.

Warto wskazać sposób złożenia żądania i adres kontaktowy. Proces nie powinien być nadmiernie skomplikowany.

Jeżeli dostawca działa jako procesor, powinien rozróżnić żądania dotyczące danych administrowanych przez niego od żądań odnoszących się do treści wprowadzonych przez klienta. W tym drugim przypadku konieczne może być skierowanie osoby do właściwego klienta.

Dane użytkowników zapraszanych przez klienta

W wielu aplikacjach administrator konta firmowego tworzy profile pracowników, wpisując ich imię, nazwisko i adres e-mail. Dostawca otrzymuje dane nie bezpośrednio od osoby, lecz od organizacji.

Należy ustalić, kto jest administratorem tych danych i kto realizuje obowiązek informacyjny.

W odniesieniu do zarządzania kontem pracowniczym klient może być administratorem, a dostawca procesorem. Jednocześnie dostawca może przetwarzać część informacji we własnych celach związanych z bezpieczeństwem i komunikacją operacyjną.

Dokumentacja powinna być zaprojektowana tak, aby pracownik otrzymywał jasną informację o obu rolach. Możliwe jest wyświetlenie informacji podczas pierwszego logowania oraz przekazanie odpowiednich klauzul przez pracodawcę.

Cookies, analityka i technologie śledzące

Aplikacja SaaS często korzysta z plików cookie, lokalnego przechowywania danych, narzędzi analitycznych, nagrywania sesji i systemów monitorujących błędy.

Należy odróżnić technologie niezbędne do działania konta i bezpieczeństwa od narzędzi analitycznych lub marketingowych.

Polityka prywatności powinna być spójna z banerem cookies i ustawieniami mechanizmu zgód. Nie wystarczy opisać narzędzia w dokumencie, jeżeli są uruchamiane przed dokonaniem właściwego wyboru przez użytkownika.

Szczególnej analizy wymagają narzędzia nagrywające zachowanie użytkownika, śledzące kliknięcia, ruch kursora albo zawartość formularzy. Niewłaściwa konfiguracja może prowadzić do przechwytywania danych wprowadzanych do aplikacji.

W panelu po zalogowaniu zakres analityki powinien być oceniany odrębnie od publicznej strony marketingowej. Użytkownik może zasadnie oczekiwać wyższego poziomu poufności podczas pracy z danymi klientów niż podczas przeglądania strony ofertowej.

Privacy by design i privacy by default

Ochrona danych nie powinna być dodawana dopiero przed publikacją aplikacji. Powinna stanowić element projektowania produktu.

Privacy by design oznacza uwzględnianie ochrony danych podczas planowania funkcji, architektury, integracji i procesów biznesowych. Privacy by default oznacza natomiast, że ustawienia domyślne powinny ograniczać przetwarzanie do zakresu niezbędnego.

W praktyce może to oznaczać domyślnie ograniczoną widoczność danych, minimalny zakres pól obowiązkowych, kontrolę uprawnień, możliwość ustawiania retencji, rejestrowanie działań administracyjnych oraz wyłączenie niepotrzebnego udostępniania danych.

Funkcja eksportu wszystkich rekordów nie powinna być dostępna dla każdego użytkownika. Integracja z zewnętrznym systemem nie powinna automatycznie przesyłać całej bazy, jeżeli wystarczy ograniczony zakres informacji.

Dostawca powinien również analizować nowe funkcje przed wdrożeniem. Dodanie automatycznego transkrybowania spotkań, analizy treści wiadomości lub rekomendacji AI może istotnie zmienić charakter przetwarzania.

Ocena skutków dla ochrony danych

Ocena skutków dla ochrony danych, czyli DPIA, może być konieczna, gdy przetwarzanie z dużym prawdopodobieństwem powoduje wysokie ryzyko dla praw i wolności osób.

Obowiązek przeprowadzenia DPIA spoczywa zasadniczo na administratorze. Dostawca SaaS powinien jednak pomagać klientowi, przekazując informacje o architekturze, zabezpieczeniach, podprocesorach, lokalizacjach, retencji i sposobie działania funkcji.

Dostawca może przygotować materiały ułatwiające klientom przeprowadzenie oceny, ale nie powinien automatycznie twierdzić, że jeden ogólny dokument zastępuje DPIA administratora. Ocena musi uwzględniać konkretny sposób używania systemu przez daną organizację.

Ta sama aplikacja może być wykorzystywana do zwykłego zarządzania kontaktami albo do profilowania osób w sposób wywierający istotne skutki. Ryzyko zależy od zastosowania, skali, danych i grup osób.

Rejestr czynności i rejestr kategorii czynności

Dostawca działający jako administrator powinien prowadzić rejestr swoich czynności przetwarzania, jeżeli obowiązek ma do niego zastosowanie. Jako procesor powinien natomiast prowadzić rejestr kategorii czynności wykonywanych w imieniu administratorów.

Rejestr procesora może obejmować kategorie klientów, rodzaje usług, kategorie przetwarzania, transfery i ogólny opis zabezpieczeń.

Nie musi zawierać szczegółowej listy każdego rekordu przechowywanego w systemie. Powinien jednak odzwierciedlać rzeczywiste modele usług i podprocesorów.

Rejestry są dokumentami wewnętrznymi i nie należy mylić ich z polityką prywatności ani listą podwykonawców.

Inspektor ochrony danych

Nie każda firma SaaS ma obowiązek wyznaczenia inspektora ochrony danych. Obowiązek zależy między innymi od rodzaju i skali przetwarzania.

Może wystąpić, gdy główna działalność polega na regularnym i systematycznym monitorowaniu osób na dużą skalę albo na przetwarzaniu na dużą skalę szczególnych kategorii danych.

Sama liczba klientów nie rozstrzyga automatycznie o obowiązku. Należy przeanalizować charakter usług, rodzaj danych, zakres monitorowania i znaczenie operacji dla działalności.

Nawet jeżeli formalny obowiązek nie występuje, firma powinna wyznaczyć osobę odpowiedzialną za koordynowanie ochrony danych. Nie należy jednak używać wobec niej tytułu inspektora ochrony danych, jeżeli nie ma pełnić funkcji zgodnie z wymaganiami RODO.

Odpowiedzialność administratora i procesora

RODO przewiduje odpowiedzialność zarówno administratorów, jak i procesorów. Zakres zależy od naruszonych obowiązków i roli w konkretnym procesie.

Administrator może odpowiadać za brak podstawy prawnej, nieprawidłową klauzulę informacyjną, nadmierny zakres danych, brak realizacji praw lub wybór dostawcy, który nie zapewniał wystarczających gwarancji.

Procesor może odpowiadać między innymi za przetwarzanie poza instrukcjami, brak odpowiedniego bezpieczeństwa, nieuprawnione korzystanie z podprocesora, brak zgłoszenia naruszenia administratorowi albo niezapewnienie wymaganej współpracy.

Umowa może określać zasady odpowiedzialności cywilnej pomiędzy stronami, limity i procedury dochodzenia roszczeń. Nie może jednak skutecznie wyłączyć obowiązków wynikających bezpośrednio z RODO ani ograniczyć uprawnień organu nadzorczego.

Dostawca nie powinien proponować klientowi postanowienia, zgodnie z którym wyłączną odpowiedzialność za wszystkie dane ponosi klient, niezależnie od przyczyny naruszenia. Z drugiej strony dostawca nie może odpowiadać za niezgodny z prawem cel, który samodzielnie ustalił klient, jeżeli usługa działała zgodnie z instrukcjami.

Regres i limity odpowiedzialności w umowie SaaS

Negocjacje dotyczące odpowiedzialności są szczególnie ważne w relacjach B2B. Dostawcy często ograniczają odpowiedzialność do wysokości opłat zapłaconych w okresie kilku miesięcy.

Przy aplikacji przetwarzającej niewielki zakres zwykłych danych taki limit może być ekonomicznie uzasadniony. Przy systemie przechowującym dokumentację medyczną, kadrową albo dane setek tysięcy osób może być rażąco niski.

Warto rozważyć odrębne limity dla zwykłych naruszeń i naruszeń dotyczących poufności, ochrony danych, bezpieczeństwa, własności intelektualnej oraz działania umyślnego.

Umowa powinna również regulować koszty obsługi incydentu, zawiadamiania osób, pomocy ekspertów, odzyskiwania danych oraz działań naprawczych.

Nie należy jednak utożsamiać odpowiedzialności kontraktowej z administracyjną karą pieniężną. Możliwość przeniesienia ekonomicznego ciężaru określonych kosztów pomiędzy stronami zależy od prawa właściwego, okoliczności i konstrukcji umowy.

Najczęstsze błędy w dokumentacji SaaS

Częstym błędem jest posługiwanie się jedną polityką prywatności, która jednocześnie ma pełnić funkcję regulaminu, umowy powierzenia i polityki cookies. Dokument staje się wówczas nieczytelny i nie realizuje prawidłowo żadnej z tych funkcji.

Innym problemem jest nazwanie dostawcy procesorem w odniesieniu do wszystkich danych, mimo że samodzielnie przetwarza dane rozliczeniowe, bezpieczeństwa i marketingowe.

Błędem jest także wykorzystanie bardzo szerokiej zgody na dowolne przetwarzanie. Zgoda nie powinna służyć do legalizowania wszystkich operacji, zwłaszcza jeżeli wykonanie umowy lub obowiązek prawny stanowią właściwszą podstawę.

Często spotykane są również nieaktualne listy podprocesorów, brak informacji o transferach, niejasne zasady korzystania z danych do trenowania AI, brak procedury eksportu i nieokreślone okresy przechowywania.

Problematyczne są DPA kopiujące treść art. 28 bez wskazania konkretnych terminów, środków bezpieczeństwa, kanałów zgłaszania naruszeń i zasad zakończenia usługi.

Kolejnym błędem jest sprzeczność dokumentów. DPA może obiecywać usunięcie danych natychmiast po rozwiązaniu umowy, podczas gdy regulamin przewiduje przechowywanie konta przez pół roku. Polityka prywatności może wskazywać serwery wyłącznie w EOG, a lista podprocesorów obejmować firmy zapewniające wsparcie z państw trzecich.

Jak uporządkować RODO w aplikacji SaaS?

Proces powinien rozpocząć się od mapowania danych. Dostawca powinien ustalić, jakie informacje trafiają do systemu, skąd pochodzą, gdzie są przechowywane, kto ma do nich dostęp i kiedy są usuwane.

Następnie należy przypisać role dla poszczególnych operacji. Nie powinno się odpowiadać na pytanie, czy firma jest administratorem czy procesorem w sposób ogólny dla całej działalności. Konieczna jest analiza konkretnych zbiorów i celów.

Kolejnym etapem jest weryfikacja podwykonawców, lokalizacji, transferów i zabezpieczeń. Dopiero na tej podstawie można przygotować spójne DPA, politykę prywatności, regulamin, politykę cookies i załącznik bezpieczeństwa.

Dokumenty powinny odpowiadać funkcjom aplikacji. Jeżeli system umożliwia nagrywanie rozmów, automatyczne profilowanie, generowanie treści przy użyciu zewnętrznego modelu AI albo import danych z serwisów społecznościowych, kwestie te muszą znaleźć odzwierciedlenie w analizie i dokumentacji.

Po wdrożeniu dokumentów konieczne są okresowe przeglądy. Zmiana dostawcy hostingu, wdrożenie nowej analityki, dodanie podprocesora lub uruchomienie aplikacji mobilnej mogą wymagać aktualizacji.

Podsumowanie

Zgodność aplikacji SaaS z RODO wymaga znacznie więcej niż opublikowania ogólnej polityki prywatności i dodania krótkiego załącznika o powierzeniu danych.

Podstawowym zadaniem jest prawidłowe określenie ról. Klient biznesowy zazwyczaj pozostaje administratorem danych wprowadzanych do systemu, a dostawca przetwarza je na jego zlecenie. Ten sam dostawca może jednak być administratorem danych rozliczeniowych, kontaktowych, marketingowych i bezpieczeństwa.

Relacja administrator–procesor powinna zostać uregulowana w DPA zgodnym z art. 28 RODO. Dokument musi odpowiadać rzeczywistemu sposobowi działania usługi, obejmować podprocesorów, bezpieczeństwo, transfery, naruszenia, audyty, prawa osób oraz zakończenie współpracy.

Polityka prywatności powinna natomiast przejrzyście opisywać operacje, w których dostawca jest administratorem. Powinna być zgodna z interfejsem aplikacji, formularzami, polityką cookies, listą podprocesorów i rzeczywistymi okresami przechowywania.

Szczególnej uwagi wymagają usługi korzystające z podmiotów spoza EOG, rozbudowanej analityki, nagrywania aktywności użytkownika albo funkcji sztucznej inteligencji. W takich przypadkach łatwo o niekontrolowane rozszerzenie celów przetwarzania i rozmycie odpowiedzialności stron.

Prawidłowo przygotowana dokumentacja powinna być efektem analizy produktu, a nie przypadkowym zestawem wzorów. Dopiero po zmapowaniu danych, przypisaniu ról, zweryfikowaniu infrastruktury i określeniu sposobu zakończenia usługi można przygotować DPA i politykę prywatności, które rzeczywiście odpowiadają modelowi SaaS.