Wróć do artykułów

Jak prawidłowo wdrażać zmiany w systemach informatycznych, czyli privacy by design and privacy by default

Autor

Adwokat Piotr Pałucki
25.08.2023

Zasada privacy by design oraz privacy by default to zasady, które powinny stanowić swoiste przykazania dla osób, które zajmują się projektowaniem systemów informatycznych. Każdy przedsiębiorca powinien tak planować swoją działalność, aby już na etapie tego planowania zastanawiać się, czy w przypadku danego projektu mamy do czynienia z danymi osobowymi oraz w jaki sposób prawidłowo je chronić. Zasada ta wynika z art. 25 RODO, w którym mowa jest o uwzględnianiu ochrony danych w fazie projektowania oraz domyślnej ochronie danych. 20 października 2020 r. EROD przyjęła szczegółowe wytyczne[1] określające, czym powinni kierować się administratorzy danych osobowych przy stosowaniu tych zasad. Zagadnienia te są szczególnie istotne dla firm informatycznych, które w sposób ciągły pracują nad innowacyjnymi rozwiązaniami. Jakimi zasadami takie firmy powinny się kierować? Na czym w praktyce polega zastosowanie tych zasad? Poniżej podejmę próbę odpowiedzi na wszystkie te pytania.

Privacy be design a privacy by default

Ochrona danych w fazie projektowania, czyli privacy by design, polega na tym, że administrator – zarówno przy określaniu sposobów przetwarzania, jak i w czasie samego przetwarzania – wdraża odpowiednie środki techniczne i organizacyjne, takie jak pseudonimizacja, zaprojektowane w celu skutecznej realizacji zasad ochrony danych, takich jak minimalizacja danych, oraz w celu nadania przetwarzaniu niezbędnych zabezpieczeń, tak by spełnić wymogi RODO oraz chronić prawa osób, których dane dotyczą (zob. art. 25 ust. 1 RODO). Innymi słowy, administrator planując i wdrażając określony proces dba o odpowiedni poziom zabezpieczenia danych osobowych już od samego początku każdego procesu oraz w czasie, gdy został on już wdrożony.

Natomiast privacy by default oznacza, że administrator ma zapewnić, aby istniał domyślny standard ochrony danych osobowych. Domyślnie przetwarzane miałyby być wyłącznie te dane osobowe, które są niezbędne dla osiągnięcia każdego konkretnego celu przetwarzania. W szczególności środki te zapewniają, żeby domyślnie dane osobowe nie były udostępniane bez interwencji danej osoby nieokreślonej liczbie osób fizycznych[2]. Domyślna ochrona danych ma działać w trakcie przetwarzania i skutecznie chronić dane osobowe, pomagając przestrzegać administratorowi obowiązki określone w art. 25. RODO.   

Ochrona danych w fazie projektowania – o co tak naprawdę chodzi?

Aby ochrona była skuteczna wszelkie środki i zabezpieczenia należy skonstruować i przygotować jeszcze przed podjęciem procesu przetwarzania. Co to oznacza? Jeżeli planujesz wdrożyć nowe rozwiązanie informatyczne albo masz pomysł na całkiem nowy program informatyczny lub zmiany w już istniejącym to zanim przystąpisz do jego realizacji najpierw zastanów się czy i jak będzie się on wiązał z przetwarzaniem danych osobowych. Następnie tak zaplanuj i zorganizuj swoje działania, aby we właściwy sposób zabezpieczyć to przetwarzanie. Organizacja działań powinna dać możliwość utworzenia solidnych zabezpieczeń, a także analizę potencjalnych zagrożeń oraz zmian, które umożliwiłyby wdrożenie dodatkowych środków w celu zminimalizowania ryzyka.

Co należy wziąć pod uwagę przy planowaniu odpowiednich zabezpieczeń?

W art. 25 ust. 1 RODO zostały wymienione elementy, które administrator musi uwzględnić przy określaniu środków dotyczących konkretnej operacji przetwarzania. Wszystkie te elementy pomagają ustalić czy wybrany środek będzie odpowiedni dla  skutecznego wdrożenia zasad. Z tego względu każdy z tych elementów nie stanowi celu samego w sobie, ale jest jednym z czynników, które należy uwzględnić łącznie, aby osiągnąć cel[3]. Spróbujemy zatem przyjrzeć się im bliżej. Będą to:

– stan wiedzy technicznej;

– koszt wdrażania;

– charakter, zakres, kontekst i cele przetwarzania;

– ryzyko naruszenia praw i wolności osób fizycznych.

Typowo, powyższe czynniki, będą przedmiotem analizy ryzyka, która pozwoli ustalić, które środki techniczne i organizacyjne faktycznie powinny zostać wdrożone.

Stan wiedzy technicznej, czyli musisz trzymać rękę na pulsie

Przepis art. 25 RODO nakłada obowiązek na administratorów, aby śledzili oni postęp w zakresie technologii, jakie znajdują się na rynku. Powinni śledzić zmiany i dostosowywać zaprojektowaną już ochronę, aktualizować zabezpieczenia i dokonywać ponownej analizy ryzyka. Jak zauważa EROD, pojęcie „stanu wiedzy technicznej” jest pojęciem dynamicznym, więc przygotowanie zabezpieczeń przez administratora nie może mieć charakteru jednorazowego w określonym czasie, ale poprzez śledzenie zmian powinien on stale dostosowywać zastosowane środki technologiczne. Mówiąc wprost – brak śledzenia zmian może skutkować brakiem zgodności z art. 25 RODO. Ponadto warto zauważyć, że termin ten nie wiąże się jedynie ze środkami technologicznymi, ale również może znaleźć zastosowanie w środkach organizacyjnych, jak np. organizacji szkoleń w zakresie technologii, bezpieczeństwa i ochrony dla pracowników zaangażowanych w ochronę danych osobowych.

Przykład:

Software House zaprojektowało aplikację, w której wykorzystywana jest technologia oparta o szyfrowanie. Po pewnym czasie okazało się, że zastosowane szyfrowanie stało się przestarzałe i jest łatwe do obejścia. W tej sytuacji SH ponownie przeprowadza analizę ryzyka i wdraża nowy rodzaj szyfrowania, oparty o najnowszy stan wiedzy technicznej.

Koszty wdrożenia proponowanych rozwiązań

Wymieniona w art. 25 przesłanka kosztów wdrażania nie zmusza administratora do wydatkowania nieproporcjonalnie dużych zasobów, o ile tylko istnieją jakiekolwiek inne, bardziej ekonomiczne, które zapewnią równie skuteczne środki. Jednak wybrane środki muszą zapewniać, aby czynność przetwarzania danych przewidziana przez administratora nie odbyła się z naruszeniem zasad, niezależnie od kosztów[4]. Powinien on zarządzać kosztami w taki sposób, żeby skutecznie dobrać środki zapobiegające utraty ochrony danych osobowych.

Charakter, zakres, kontekst i cele przetwarzania

     Podczas projektowania ochrony danych administrator powinien brać pod uwagę charakter, zakres, kontekst i cele przetwarzania danych. Wiążą się one nie tylko z art. 25 RODO, ale również art. 24 – obowiązkami administratora, art. 32 – bezpieczeństwem przetwarzania oraz art. 35 – przeprowadzeniem kwalifikowanej analizy ryzyka, czyli oceny skutków dla ochrony danych. Ww. czynniki to cechy, które wiążą się z danym przetwarzaniem danych osobowych. Charakter przetwarzania oznacza jego cechy, takie jak np. ciągłość, powtarzalność, albo przeciwnie – incydentalność. Zakres oznacza wielkość i zasięg przetwarzania danych, natomiast kontekst to dodatkowe okoliczności, które mogą mieć wpływ na ocenę danej operacji przetwarzania. Cele przetwarzania danych również powinny mieć wpływa na to, w jaki sposób będziemy projektować ochronę tych danych.

Przykład

Inaczej będziemy projektować zasady ochrony danych osobowych w przypadku aplikacji służącej do przetwarzania badań diagnostycznych pacjentów, gdzie pacjent będzie mógł mieć dostęp do wszystkich swoich aktualnych i archiwalnych wyników badań, a inaczej w przypadku tworzenia aplikacji zwykłego sklepu internetowego, gdzie sprzedawana jest przykładowo odzież. W pierwszym przypadku mamy do czynienia z przetwarzaniem w sposób ciągły (charakter przetwarzania) danych osobowych wrażliwych – dotyczących zdrowia (kontekst przetwarzania), w szerokim zakresie (potencjalnie wszystkie badania diagnostyczne pacjenta) w celu zapewnienia pacjentowi dostępu do wyników (cel przetwarzania). Natomiast w przypadku przetwarzania danych w sklepie internetowym celem przetwarzania będzie umożliwienie zakupów, dane będą przetwarzane w zakresie wąskim i będą miały zwykły charakter. W związku z powyższym nie ulega wątpliwości, że administrator, który projektuje i wdraża aplikację zawierającą wyniki badań będzie zobowiązany do zaplanowania i wdrożenia wyższego poziomu zabezpieczeń niż administrator, który zakłada sklep internetowy.

Analiza ryzyka to podstawa

Pomimo że administratorzy korzystają z powyższych narzędzi, to muszą oni za każdym razem przeprowadzać indywidualną analizę ryzyka w zakresie ochrony danych w odniesieniu do każdorazowej operacji przetwarzania, a ocena ta powinna podlegać okresowym aktualizacjom. Powinno się również zwracać szczególną uwagę na zagrożenie związane z brakiem dobrowolnej zgody związanej z przetwarzaniem danych osobowych dzieci i młodzieży poniżej 18. roku życia. Bardzo istotne jest, aby wdrażać odpowiednie środki w celu ograniczenia i skutecznego zminimalizowania określonych zagrożeń związanych z grupą osób, których dane dotyczą.

Przy ochronie danych osobowych kluczowe są działania zapobiegawcze oraz aspekt czasu, w którym dochodzi do reakcji administratora. Zdaniem EROD w interesie administratora leży jak najszybsze wdrożenie zasad privacy by design oraz privacy by default, albowiem późniejsze ich wdrożenie, w ramach gotowego już procesu, może być znacznie droższe.

Domyślna ochrona danych

Termin „domyślnej” ochrony danych będzie tu odnosić się do podejmowanych decyzji dotyczących wartości konfigurujących lub opcji przetwarzania, które są zapisane w systemie przetwarzania (np. aplikacja, usługa, urządzenie) mających wpływ na ilość zgromadzonych danych, zakres, w jakim są przetwarzane, okres ich przechowywania oraz ich dostępność. Kluczowa w wyborze przez administratora odpowiednich środków będzie ocena konieczności (niezbędności), która powiązana jest z art. 6 ust.1 RODO, gdzie opisane są prawne podstawy przetwarzania. Wiąże się to, mówiąc krótko, z tym, że administrator nie będzie gromadził większej ilości danych, niż jest to niezbędne, ani też przechowywał ich dłużej niż jest to niezbędne.

Wymiary obowiązku privacy by default

Warto opisać tu wymiary obowiązku wdrożenia privacy by default opisane w art. 25 ust. 2 RODO. Administrator powinien określić i porównać ryzyko; większe ryzyko wiąże się z sytuacją, gdy gromadzone są duże ilości szczegółowych danych, podczas gdy ryzyko będzie mniejsze podczas gromadzenia mniejszych ilości danych lub mniej szczegółowych danych. Jeżeli tylko w wystarczającym stopniu dla celu przetwarzania mniej szczegółowe dane osobowe są wystarczające, to należy dokonać minimalizacji ilości zbieranych danych. To samo będzie dotyczyć zakresu ich przetwarzania – powinno uważać się, aby nie przetwarzać danych w celach innych niż pierwotnie zakładane (art. 6 ust. 4 RODO) i nie wykroczyć poza zakres przetwarzania, który jest zgodny z uzasadnionymi oczekiwaniami osób, których dane dotyczą.

Taka zasada będzie dotyczyć także okresu przechowywania danych. Każdorazowe przetwarzanie danych przez dłuższy okres powinno zostać obiektywnie uzasadnione przez administratora zgodnie z zasadą rozliczalności. W wypadku, gdy uzna się, że dane osobowe nie są już  potrzebne w procesie przetwarzania należy je usunąć lub poddać procesowi anonimizowania. Długość czasu, w jakim dane są przetwarzane, zgodnie z zasadą ograniczenia przetwarzania (art. 5 ust. 1 lit. e), będzie zależeć od celu przetwarzania. Proces usuwania niepotrzebnych już danych osobowych powinien zostać, w ramach domyślnej ochrony, zautomatyzowany.

Przykład

Administrator danych osobowych stosuje program, gdzie archiwizuje wszystkie umowy, które wiążą go z kontrahentami. W ramach programu administrator posiada część archiwalną, gdzie ustawia okresy, po jakich dane klienta są automatycznie usuwane z systemu.

Minimalizacji podlega wreszcie udostępnianie danych – ich treść oraz liczba osób, którym są udostępniane dane osobowe. Administrator domyślnie ogranicza dostępność danych, a także zapewnia osobie, której dane dotyczą, możliwość interwencji przed ich opublikowaniem lub udostępnieniem. Wydaje się to bardzo istotne w kontekście internetu, gdzie łatwo mogłoby to skutkować o wiele szerszemu udostępnianiu danych niż pierwotnie było to zamierzone. Wreszcie konieczne jest podkreślenie, że nawet jeśli dane osobowe będą udostępniane za zgodą i wiedzą osoby, której dane dotyczą, nie będzie to oznaczać, iż każdy inny administrator posiadający dostęp do tych danych mógłby je swobodnie przetwarzać do własnych celów. Musiałby wtedy dysponować odrębną podstawą prawną[5].

Wdrażanie zasad ochrony w praktyce firmy IT

W całym procesie ochrony danych osobowych bardzo istotnym elementem, który umożliwia realizację tej ochrony w fazie projektowania oraz domyślnej ochrony danych, będzie wdrożenie zasad, jakie zostały wymienione w art. 5 oraz motywie 39 RODO. Będą to: przejrzystość, zgodność z prawem, rzetelność, ograniczenie celu, minimalizacja danych, prawidłowość, ograniczenie przechowywania, integralność i poufność oraz rozliczalność. Choć wydaje się, że te rozważania są teoretyczne to zasady te będą miały bardzo duże znaczenie praktyczne w przypadku wdrażania zmian w istniejących systemach informatycznych albo projektowaniu nowych systemów, aplikacji lub programów.

Przejrzystość oraz zgodność z prawem

Administrator, który projektuje politykę prywatności na swojej stronie internetowej w celu spełnienia wymogów przejrzystości, musi zawrzeć w niej informacje sformułowane w jasnym i zwięzłym języku, aby osoby, których dane dotyczą nie miały problemu ze zrozumieniem (przede wszystkim, kiedy są to dzieci lub członkowie innych grup szczególnie uprzywilejowanych). Muszą być one łatwo dostępne i nie nazbyt dużej ilości, żeby najważniejsze punkty były łatwe do znalezienia. W związku z tym administrator dostarcza informacji w sposób wielowarstwowy – szczegółowe, podstawowe dane są łatwo dostępne, a rozwijane menu, linki do innych stron służą dalszemu wyjaśnieniu. Muszą być przekazywane w odpowiednim kontekście (odpowiednim czasie oraz formie) i w stosowny sposób (mają zastosowanie do osób, których dane dotyczą).

Przykład

Dostawca oprogramowania udostępnia na swojej stronie politykę prywatności i cookies. Polityki są łatwo dostępne, napisane są przejrzystym językiem.

Niezbędne jest, aby została określona podstawa prawna przetwarzania danych osobowych. Kluczowe elementy w fazie projektowania i domyślnej ochrony danych mogą obejmować:

–  stosowność (podstawy prawne mają stosowne zastosowanie);

zróżnicowanie podstaw prawnych co do każdej czynności przetwarzania;

– konkretny cel (właściwa podstawa musi być powiązana z konkretnym celem);

konieczność, to znaczy przetwarzanie musi być niezbędne i bezwarunkowe, żeby jego cel był zgodny z prawem.

Innymi ważnymi elementami są: autonomia przyznana osobie, której dane dotyczą w odniesieniu do kontroli nad tymi danymi, uzyskanie zgody, a także możliwość wycofania zgody, która powinna być równie prosta, jak jej udzielenie. Bardzo ważne jest przeprowadzenie przez administratora testu równowagi interesów, kiedy podstawą prawną są prawnie uzasadnione interesy. Niezbędne jest, aby istniały środki i zabezpieczenia, jakie mają na celu złagodzenie negatywnego wpływu na osoby, których dane dotyczą. Ponadto podstawa prawna musi być ustalona przed rozpoczęciem jakiegokolwiek przetwarzania danych, a w wypadku, gdy przestaną one mieć zastosowanie, należy odpowiednio przerwać przetwarzanie. Jeśli występuje współadministrowanie, to strony muszą wyraźnie rozdzielić swoje obowiązki w stosunku do osoby, której dane dotyczą[6].

Rzetelność

Rzetelność stanowi nadrzędną zasadę, która wymaga, aby dane osobowe nie zostały przetwarzane w sposób, który byłby bezzasadnie szkodliwy, nieoczekiwany, dyskryminujący lub też wprowadzający w błąd względem osoby, której dane dotyczą. Środki i zabezpieczenia, jakie są podstawą realizowania zasady rzetelności, wspierają także prawa i wolności osób, których dane dotyczą, a w szczególności prawo do informacji (przejrzystości), do interwencji (dostępu, usuwania, przenoszenia, prostowania danych), oraz prawo do ograniczenia przetwarzania. Osobom tym przyznaje się najwyższy zakres autonomii, żeby mogły swobodnie decydować o sposobie wykorzystania ich danych. Przykład:

Administrator nie może stosować algorytmów, które mogłyby prowadzić do dyskryminacji użytkowników danego systemu lub oprogramowania.

Ograniczenie celu oraz minimalizacja danych

Obydwie zasady są ściśle powiązane z wykorzystaniem jedynie niezbędnych danych, które zapewnią osiągnięcie celu. Są jednak dwoma przeciwnymi końcami tego samego procesu – środkami prowadzącymi do celu oraz samym celem. Administrator jest zatem zobowiązany do zebrania danych w konkretnych, wyraźnych i prawnie uzasadnionych celach. W wypadku dalszego przetwarzania należy upewnić się czy cele tego przetwarzania będą zgodne z celami pierwotnymi – administrator powinien zastosować środki techniczne (haszowanie i szyfrowanie) w celu ograniczenia ponownego wykorzystania danych osobowych. Pomocne będą również środki organizacyjne, jak np. strategie i zobowiązania umowne.  

W wypadku zasady minimalizacji danych kluczowe będzie na początek ustalenie przez administratora czy w ogóle dane osobowe muszą być przetwarzane do osiągnięcia odpowiednich celów. Ewentualnie powinien sprawdzić, na ile może przetwarzać mniej danych osobowych lub posiadać mniej szczegółowe lub zagregowane dane. Musi on z góry określić, które cechy parametrów systemów przetwarzania oraz ich funkcje będą dopuszczalne. Powinny być przetwarzane jedynie adekwatne, stosowne, a także ograniczone do tego, co niezbędne do osiągnięcia celu dane osobowe.

Kwestia minimalizacji wiąże się również ze stopniem identyfikacji osoby, której dane dotyczą. W wypadku, gdy cel nie wymaga, żeby ostateczny zbiór danych odnosił się do zidentyfikowanej osoby fizycznej, administrator powinien usunąć lub poddać anonimizacji dane osobowe, gdy identyfikacja nie będzie już konieczna. Natomiast, gdy dalsza identyfikacja będzie konieczna w odniesieniu do innych czynności przetwarzania, dane należy spseudonimizować. W ten sposób zminimalizuje się ryzyko naruszenia praw osób. Podobnie minimalizacji będzie podlegać liczba kopii, czyli nie wytwarzania ich, o ile nie wymaga tego skuteczność przepływu danych. W osiągnięciu tych obowiązku ma pomagać administratorowi aktualny stan wiedzy technicznej, której rozwój powinien on aktywnie śledzić.

Przykład:

Fiński organ nadzorczy wydał decyzję, zgodnie z którą pracodawca, zbierający na potrzeby rekrutacji m.in. takie dane jak dane dot. wyznania kandydata, stanu zdrowia, możliwej ciąży oraz dane dot. członków rodziny, stanowiło naruszenie zasady minimalizacji danych osobowych i nie było niezbędne z punktu widzenia celu przetwarzania danych osobowych[7].

Prawidłowość oraz ograniczenie przechowywania

Przetwarzane dane osobowe powinny pochodzić z wiarygodnych źródeł, a administrator musi usuwać lub też sprostować wszystkie błędne dane bez zbędnej zwłoki. Powinien on dokonać weryfikacji danych przed rozpoczęciem procesu przetwarzania, jak również na różnych jego etapach. W wypadku zautomatyzowanych decyzji opartych na sztucznej inteligencji, administrator musi ograniczyć w miarę możliwości skutki powielanych błędów oraz zmniejszyć liczby fałszywych wyników dodatnich/ujemnych. Natomiast osoby, których dane dotyczą powinny otrzymywać informacje na temat danych osobowych i otrzymać skuteczny dostęp do nich, by mieć możliwość kontroli poprawności czy też sprostowania (zgodnie z art. 12-15 RODO). W tym kontekście administrator powinien także zadbać o odpowiednie okresy retencji.

Integralność i poufność

Zasada integralności i poufności wydaje się kluczowa w ochronie danych osobowych, a w szczególności w przypadku wdrażania zmian w systemach informatycznych. Dotyczy ochrony przed nieuprawnionym lub niezgodnym z prawem przetwarzaniem, przed przypadkową utratą, zniszczeniem albo uszkodzeniem. Służą temu odpowiednie środki techniczne i organizacyjne, które administrator powinien wykorzystywać w tworzeniu doskonalszych zabezpieczeń[8]. W gestii administratora leży przeprowadzanie regularnych przeglądów i zarządzania reagowaniem na incydenty naruszające bezpieczeństwo. Powinien on tez dysponować odpowiednimi procesami, które umożliwiałyby reagowanie na naruszenia i incydenty, aby system przetwarzania był bardziej niezawodny, a zatem w obowiązku administratora jest doskonalenie go. Ochrona powinna być zależna od stopnia obarczenia ryzykiem – im dane bardziej podatne na ryzyko, tym powinny być lepiej chronione, oddzielone od reszty danych osobowych.

Administrator powinien również stosownie zarządzać kontrolą dostępu. Do zadań powiązanych z przetwarzaniem muszą być wyznaczeni jedynie upoważnieni pracownicy, a żaden z nich nie posiadał pełnego dostępu do danych na temat osoby, której dane dotyczą. Należy też, w miarę możliwości zminimalizować liczbę osób zaangażowanych w ochronę. Wreszcie dane osobowe oraz kopie mają być pseudonomizowane w ramach środków bezpieczeństwa.

Przykład:

W 2020 r. doszło do sytuacji, w której pewna spółka działając w branży energetycznej zgłosiła swojemu dostawcy oprogramowania, że działa ono zbyt wolno.  W związku z tym dostawca ten dokonał zmiany systemu w celu poprawy jego wydajności i szybkości działania. Zmiana polegała na stworzeniu i instalacji nowej bazy klientów administratora. Niestety, baza ta została skopiowana przez nieuprawnione podmioty. W bazie nie było danych „wrażliwych”, ale były tam takie dane jak PESEL, rodzaj, seria i numer dokumentu tożsamości, adres e-mail, numer telefonu, numer i adres punktu poboru oraz dane dotyczące umowy zawartej z administratorem.

Podmiot przetwarzający (dostawca oprogramowania) wskazał, iż na etapie, w którym doszło do wycieku danych osobowych, nie zostały jeszcze wdrożone zabezpieczenia systemu. Etap wdrożenia produkcyjnego i zakończenie wdrażania zabezpieczeń był planowany właśnie w kwietniu 2020 r. W czasie, w którym doszło do wycieku, trwał proces testów, a także zasilanie bazy danymi.

W opisywanej sprawie PUODO wydał decyzję[9], w której wskazał szereg błędów, jakie zostały popełnione przez dostawcę oprogramowania w opisywanym przypadku. Przede wszystkim podmiot przetwarzający już na etapie testowania bazy wprowadził prawdziwe dane osobowe, nie zapewniając w tym zakresie poufności. Skoro jednak takie dane zostały wprowadzone to należało zastosować taki poziom zabezpieczeń jak w systemach produkcyjnych. PUODO wskazał także, że dostawca oprogramowania powinien wdrożyć realnie działające polityki i procedury, które opisywałyby w jaki sposób prawidłowo wdrażać zmiany w systemie informatycznym, określające:

 – sposób dokonywania zmian w systemach informatycznych służących do przetwarzania danych osobowych;

–  konieczność utworzenia środowiska testowego;

– odpowiedniego zabezpieczenia rzeczywistych danych klientów administratora, w przypadku ich wykorzystania do testowania wprowadzanych zmian;

–  zasad kontroli poprawności realizacji poszczególnych etapów projektu;

– zdefiniowanie wymaganych zabezpieczeń.

Rozliczalność

To administrator jest odpowiedzialny za przestrzeganie wszystkich tych zasad i powinien umieć wykazać ich przestrzeganie, o czym stanowi zasada rozliczalności. Ewentualne sankcje pieniężne określają organy nadzorcze, a ochrona danych w fazie projektowania, a także domyślna ochrona danych są również czynnikiem, który określa wysokość kar za naruszenie przepisów RODO[10].

Podsumowanie

Zastosowanie zasad privacy by design i privacy by default  ma charakter wielowątkowy, jednak nie jest skomplikowane. Każdy podmiot, który przetwarza dane osobowe powinien w każdym momencie prowadzonych przez siebie działań mieć na uwadze ochronę danych osobowych oraz wdrożyć takie rozwiązania, które zapewnią, że ta ochrona będzie faktycznie stosowana. Zasady te mają bardzo duże znaczenie w przypadku tworzenia nowych środowisk informatycznych, a także wprowadzania zmian w już istniejących. Dostawca usług informatycznych powinien w związku z tym wdrożyć odpowiednie procedury i polityki, określające sposób postępowania zarówno w nowych projektach, jak i w przypadku wprowadzania zmian w już istniejących systemach. Ważnym elementem będzie tutaj także analiza ryzyka, w wyniku której możliwe będzie określenie, jakie zabezpieczenia powinny być wdrożone. Pamiętajmy, że brak stosowania ww. zasad w praktyce może prowadzić do poważnych konsekwencji, takich jak wyciek danych osobowych, co może się wiązać z konsekwencjami dla przedsiębiorcy. 


[1] Wytyczne nr 4/2019 dotyczące artykułu 25 Uwzględnianie ochrony danych w fazie projektowania oraz domyślna ochrona danych, dostęp online: https://edpb.europa.eu/system/files/2021-04/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_pl.pdf

[2] Porównaj art. 25 RODO.

[3] Wytyczne EROD, https://edpb.europa.eu/system/files/2021-04/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_pl.pdf.

[4] Wytyczne EROD, 2.1.3.2 „koszt wdrażania”, tamże.

[5] Wytyczne EROD, 2.2.2 Wymiary obowiązku minimalizacji danych, tamże.

[6] Porównaj: Wytyczne EROD 3.1-3.2, tamże.

[7] Decyzja Tietosuojavaltuutetun toimisto – 137/161/20, skrócona wersja dostępna tutaj: https://gdprhub.eu/index.php?title=Tietosuojavaltuutetun_toimisto_-_137/161/20

[8] Porównaj: Motyw 78 RODO.

[9] Decyzja z dnia 19 stycznia 2022 r., DKN.5130.2215.2020, dostęp online: https://uodo.gov.pl/decyzje/DKN.5130.2215.2020

[10] Porównaj art. 83 ust.4 RODO.