Jeżeli hashowany zasób zawiera numery PESEL lub inne dane osobowe, to nadal jest zestawem danych osobowych. Opinia 05/2014 w sprawie technik anonimizacji

Arwid Mednis: Z danymi osobowymi mamy do czynienia wszędzie tam gdzie można wskazać osobę, której dotyczą posiadane przez firmę/instytucję dane. PESEL może być daną osobową jeśli możemy (np. po połączeniu z innymi danymi) wskazać osobę której dotyczy. Jeśli zewnętrzny podmiot odpytuje bazę i ma dane wskazujące na konkretną osobę to odpowiedź TAK/NIE może dostarczyć mu dodatkowych informacji na temat zidentyfikowanej osoby. Dla podmiotu dysponującego bazą/zasobem dane są danymi osobowymi, jeśli – pomimo szyfrowania – może on wskazać kogo dotyczą. Szyfrowanie jest metodą zabezpieczenia danych, nie jest natomiast sposobem na niestosowanie RODO. Dopiero anonimizacja pozwala na niestosowanie Rozporządzenia.

Tak zgodnie z RODO „administrator” oznacza osobę fizyczną lub prawną, organ publiczny, jednostkę lub inny podmiot, który samodzielnie lub wspólnie z innymi ustala cele i sposoby przetwarzania danych osobowych; jeżeli cele i sposoby takiego przetwarzania są określone w prawie Unii lub w prawie państwa członkowskiego, to również w prawie Unii lub w prawie państwa członkowskiego może zostać wyznaczony administrator lub mogą zostać określone konkretne kryteria jego wyznaczania;

„przetwarzanie” oznacza operację lub zestaw operacji wykonywanych na danych osobowych lub zestawach danych osobowych w sposób zautomatyzowany lub niezautomatyzowany, taką jak zbieranie, utrwalanie, organizowanie, porządkowanie, przechowywanie, adaptowanie lub modyfikowanie, pobieranie, przeglądanie, wykorzystywanie, ujawnianie poprzez przesłanie, rozpowszechnianie lub innego rodzaju udostępnianie, dopasowywanie lub łączenie, ograniczanie, usuwanie lub niszczenie;

Arwid Mednis: „Interes biznesowy” może wystarczyć do uznania za ADO, jeśli podmiot przetwarzając dane realizuje własne potrzeby (np. reklamuje własne produkty). Jeśli wykonuje czynności wyłącznie na rzecz innego podmiotu (np. realizuje kampanię marketingową w imieniu innej firmy) i nie korzysta z danych dla własnych celów, wówczas jest w świetle RODO podmiotem przetwarzającym.

Zasada ograniczenia czasowego ma zastosowanie do zarchiwizowanych kopii zapasowych. Administrator powinien przewidzieć okres przechowywania zgodny z przyjętymi celami przetwarzania, np. archiwizacja w celu dokumentowania złożonych zamówień.

Usunięcie danych wprawdzie nie powinno oznaczać ich wtórnego przechowywania, jednak zasada rozliczalności (art. 5 ust. 2 RODO) może wymagać zachowania informacji czy dokumentów potwierdzających komunikację z osobą składającą żądanie usunięcia danych i fakt usunięcia takich informacji.

Obowiązki wynikające z art. 25 RODO ostatecznie leżą po stronie administratora danych, który będzie korzystał z rozwiązań dostarczanych w ramach przetargów publicznych. Może to być zamawiający albo podmiot, na którego rzecz on działa. Z taką sytuacją mieliśmy dotychczas do czynienia w przypadku instytucji Administratora Systemu Informatycznego, który odpowiadał za dostarczanie oprogramowania wielu administratorom danych (np. minister spraw wewnętrznych i administracji zapewniający rozwiązania techniczne dla centrów powiadamiania ratunkowego zgodnie z art. 10 ustawy o systemie powiadamiania ratunkowego).

Maciej Gawroński: W praktyce jednak zamawiający może oczekiwać, aby dostawca zapewnił obsługę wymogów składających się w jego ocenie na „Privacy by design”. Powinien jednak sformułować konkretne oczekiwania, jeżeli miałyby one stanowić warunki udziału lub kryteria oceny.

Ochrona danych osobowych jest wymagana nie tylko w cyklu życia danych ale także w całym cyklu życia systemu, w którym są one przetwarzane (zaczynając od jego projektowania, poprzez regularne testowanie i aktualizowanie w celu wyeliminowania zidentyfikowanych luk i podatności, aż po jego wycofywanie z eksploatacji). Wynika to z art. 25 RODO dot. wymogu ochrony danych w fazie projektowania (Privacy by Design).

Praktyka wykorzystywania takich samych identyfikatorów dla jednej osoby w różnych systemach, bez względu na to, czy są one tworzone z lub bez soli, powinno być uznana jako jeden z czynników zwiększających ryzyko dla prywatności i uwzględnione w analizie ryzyka.

Umowa powierzenia jest wymagana w przypadku powierzenia przetwarzania danych osobowych niepoddanych pseudonimizacji czy anonimizacji.

Arwid Mednis: Przekazanie danych spseudonimizowanych przez ADO innemu podmiotowi, dla którego są one de facto anonimowe, nie jest powierzeniem przetwarzania danych osobowych. ADO powinien jednak zwrócić uwagę czy odbiorca danych nie ma możliwości identyfikacji konkretnych osób.

Kurierzy mogą działać jako operatorzy pocztowi na podstawie umowy o świadczenie usług pocztowych, tzn. podmioty, którym powierzono przetwarzanie danych w zakresie dostarczania przesyłek. Warto porównać z analogiczną sytuacją pod rządami ustawy o ochronie danych osobowych z 1997 r.: https://www.giodo.gov.pl/file/12539[PDF]

Maciej Gawroński: W mojej ocenie operator pocztowy jest administratorem danych przetwarzanych w ramach wykonywania działalności regulowanej. Stąd z operatorem usługi kurierskiej nie ma potrzeby zawierać umowy powierzenia przetwarzania danych, skoro nie zawiera się takiej umowy z Pocztą Polską. Jeżeli jednak operator usługi kurierskiej lub innej pocztowej miałby świadczyć dodatkowe usługi (np. kopertowanie), wtedy umowa powierzenia byłaby potrzebna. Zakres dostępu do danych byłby bowiem większy niż potrzebny do wykonywania działalności regulowanej.

Administrator danych  może powierzyć dane osobowe innemu podmiotowi, w drodze umowy zawartej na piśmie lub w formie elektronicznej. Co do zasady praktyczniejszym podejściem może okazać się  zastosowanie aneksu do umowy z uwagi na to, że regulamin może wprowadzić w błąd a pamiętajmy że obie strony muszą zapewnić zgodność z art. 28 RODO. Jednakże zasady zawierania umów lub innych aktów prawnych, w tym w formie elektronicznej, nie są określone w RODO, ale w innych przepisach unijnych i / lub krajowych.Podpis elektroniczny jest jednym z kilku sposobów udowodnienia zawarcia umowy

Maciej Gawroński:Tak. umowa powierzenia przetwarzania danych osobowych może być załącznikiem do regulaminu i może podlegać zawarciu przez elektroniczną akceptację. Nie ma konieczności stosowania podpisu elektronicznego. Wyjaśniła to Komisja Europejska http://www.europarl.europa.eu/doceo/document/E-8-2018-003163-ASW_EN.html?redirect

Motyw ten należy czytać razem z motywem nr 28, zgodnie z którym pseudonimizacja nie powinna wykluczać stosowania innych środków ochrony danych osobowych. Ogólna analiza danych osobowych oznacza jedną z form przetwarzania danych osobowych.

Ponieważ przepisy o ograniczaniu przetwarzania danych są neutralne technologicznie, zastosowane metody są zależne od przyjętych procedur działania i stosowanego oprogramowania. Przykładowo, jeżeli flagowanie lub tagowanie rekordów, których dotyczy ograniczenie przetwarzania spełniają żądanie osoby, której dane dotyczą, to będą wystarczające. Takie oznaczanie powinno być jasnym sygnałem dla pracowników, że dane można przechowywać, ale nie należy ich tymczasowo używać w zwyczajnych procesach.

Sposób realizacji praw osób w tego typu systemach, zależy od jego implementacji, dlatego tego typu pytanie należy zadać jego producentowi. Trzeba jednak pamiętać, że nawet w systemach niestrukturalizowanych możliwe jest wyszukiwanie informacji wg pewnych kryteriów.

Maciej Gawroński:  Odpowiedź zależy od możliwości zautomatyzowanego przetwarzania takich nieustrukturyzowanych danych w konkretnym systemie, ponieważ RODO stosuje się zasadniczo do zautomatyzowanego przetwarzania danych (art. 2 RODO). Jednak możliwość zautomatyzowanego wyszukiwania danych, nie obliguje nas, zgodnie z art. 11 ust. 1 RODO, do korzystania z niej tylko po to, aby zastosować RODO w całości. Jeżeli natomiast osoba zgłosi się w celu wykonania swoich praw, należy wykorzystać istniejące możliwości technologiczne pod warunkiem, że poda ona potrzebne szczegóły (zgodnie z art. 11 ust. 2 RODO)

Podejście do projektowania systemów przed i po RODO nie powinny się w dużym stopniu różnić, bo wymagania bezpieczeństwa i prywatności danych istniały w polskim prawodawstwie przed rozpoczęciem stosowania RODO. Wymagania funkcjonalne systemów powinny oczywiście zapewnić przetwarzanie danych zgodnie z obowiązującymi przepisami, realizację praw osób fizycznych i rozliczalność administratora.

Maciej Gawroński: Ja się z tym mocno nie zgadzam 😊 Projektowanie systemów informatycznych przed RODO w praktyce pomijało zarówno aspekty prywatności jak i kwestie bezpieczeństwa, spychając te zagadnienia na nabywców systemów. RODO zmienia tę sytuację zdecydowanie. Dostawca systemu nie może już zasłaniać się wykrętem „zrobicie sobie bezpieczeństwo jakie chcecie” lub przemilczeć kwestii obsługi praw jednostki przez funkcjonalności natywne systemu i musi być gotowy na zmierzenie się z tymi wyzwaniami.

Arwid Mednis: Wymagania odnośnie do systemów były przed RODO w znacznym stopniu regulowane przepisami prawa. Pod rządami RODO, nie ma konkretnych wymagań w przepisach, natomiast istnieje ogólny obowiązek uwzględniania przy projektowaniu rozwiązań technicznych stanu wiedzy technicznej, kosztów wdrażania oraz charakteru, zakresu, kontekstu i celów przetwarzania oraz ryzyka naruszenia praw lub wolności osób fizycznych. Jest to tzw. risk-based approach.

Obowiązuje co do zasady risk-based approach. Zgodnie z Art. 32 ust. 1 lit. c) RODO administrator i podmiot przetwarzający wdraża odpowiednie środki techniczne takie jak regularne testowanie, mierzenie i ocenianie skuteczności środków technicznych i organizacyjnych mających zapewnić bezpieczeństwo przetwarzania danych osobowych.  Przykładowe zabezpieczenia można znaleźć np. w normach ISO z serii 27000 i można je użyć jako punkt wyjściowy.

Testy penetracyjne pozwalają zweryfikować, czy zdefiniowane w fazie projektowania wymagania bezpieczeństwa i prywatności są właściwie zaimplementowane (tzw. Privacy by Design). Testy penetracyjne powinny być wykonane przed wdrożeniem oraz powtarzane cyklicznie. Jeżeli testy takie miałby przeprowadzić podmiot zewnętrzny i doszłoby do dostępu do danych osobowych, konieczne jest zawarcie umowy powierzenia danych. W przypadku pracownika itp. podobnych osób wystarczające może być upoważnienie do dostępu.

Model pseudonimizacji oraz jego implementacja musi być stosowny do systemu i zakresu danych oraz celów i sposobów ich przetwarzania. Przykład zostanie opracowany i przedstawiony w terminie późniejszym.

W  JRWA odnajdujemy klasyfikację wskazującą okres przechowywania dokumentacji wynikającą np. z przepisów prawa pracy, rozliczeń finansowych, kodeksu postępowania administracyjnego itp. Wymogi te muszą być realizowane w systemach przetwarzających dane. Administrator danych wymaga od dostawców oprogramowania zapewniania zgodności z przepisami  w szczególności o ochronie danych i archiwizacji.

Maciej Gawroński: Zasadniczo aktualnie systemy IT obsługują proces archiwizacji i usuwania danych w szczątkowym stopniu.

Istotne warunki zamówienia powinny uwzględniać zasady Privacy by Design i Privacy by Default.

Arwid Mednis: Odpowiedź na to pytanie zależy od charakteru zamówienia. Jeśli istotą usługi jest przetwarzanie danych osobowych (np. zamówienie dotyczy budowy rejestru z danymi), wówczas zamawiający jako ADO powinien wykonać ocenę skutków przetwarzania (tzw. DPIA) i na tej podstawie określić w SIWZ środki, które jego zdaniem mitygują stwierdzone ryzyko.

Maciej Gawroński: Postulat uwzględniania obu zasad PbD w zamówieniach publicznych wymaga przemyślenia przez zamawiających, aby prawidłowo przekuć go w stosowne warunki udziału lub kryteria oceny. RODO nie daje w tym zakresie żadnych podpowiedzi. Idealnie należałoby zapewnić zamawiającemu wybór najlepszej jego zdaniem metody urzeczywistniającej te zasady spośród zaproponowanych przez oferentów. W świetle dotychczasowego orzecznictwa Krajowej Izby Odwoławczej będzie to zapewne niemożliwe.

Realizacja tego prawa powinna oprzeć się na możliwości wyłączenia pewnych rekordów z tymczasowego przetwarzania (z wyjątkiem przechowywania danych), ale nie jest możliwe podanie jednego zestawu wskazówek. Będzie to zależało od funkcjonalności każdego systemu / aplikacji. Dlatego administrator danych dokonując wyboru danego rozwiązania technicznego poddaje analizie wymagane funkcjonalności w procesie przetwarzania danych.

Maciej Gawroński: Co do przetwarzania w Excelu można rozważyć dodanie dwóch kolumn: Ograniczenie przetwarzania Toggle Y/N, Ograniczenie przetwarzania Explanation.

Wybór szczegółowych praktyk OWASP zależy od rodzaju aplikacji, jej funkcjonalności oraz specyfiki organizacji. Dlatego najlepiej jest na początku zapoznać się z nią w całości, a potem wspólnie ze specjalistami od cyberbezpieczeństwa ustalić, które jej elementy należy zastosować we wszystkich systemach, a które w konkretnych aplikacjach. Pełna informacja (w języku angielskim) jest dostępna tutaj: https://www.owasp.org