Privacy by design i privacy by default — jak wdrożyć art. 25 RODO w praktyce

Privacy by design (ochrona danych w fazie projektowania) i privacy by default (domyślna ochrona danych) to dwie zasady, które RODO wynosi do rangi obowiązku prawnego. Art. 25 RODO wymaga, aby administrator uwzględniał ochronę danych osobowych na każdym etapie projektowania systemów, produktów i procesów — nie jako dodatek na końcu, ale jako integralny element od samego początku.

W praktyce to jedna z najczęściej ignorowanych zasad RODO — i jednocześnie jedna z tych, które UODO coraz częściej bada podczas kontroli. Analiza decyzji UODO i europejskich organów nadzorczych pokazuje, że kary za naruszenie art. 25 RODO rosną, a organy sprawdzają nie tylko, czy organizacja „ma procedury”, ale czy rzeczywiście myślała o ochronie danych zanim uruchomiła nowy system czy proces.

W tym artykule wyjaśniam, czym dokładnie jest privacy by design i privacy by default, jak wdrożyć te zasady w praktyce i jakie błędy najczęściej popełniają organizacje.

Privacy by design — czym jest ochrona danych w fazie projektowania?

Art. 25 ust. 1 RODO stanowi, że administrator — uwzględniając stan wiedzy technicznej, koszt wdrażania, charakter, zakres, kontekst i cele przetwarzania oraz ryzyka o różnym prawdopodobieństwie wystąpienia i wadze — zarówno przy określaniu sposobów przetwarzania, jak i w czasie samego przetwarzania, wdraża odpowiednie środki techniczne i organizacyjne zaprojektowane w celu skutecznej realizacji zasad ochrony danych i w celu nadania przetwarzaniu niezbędnych zabezpieczeń.

Przekładając z języka prawniczego na praktyczny: zanim uruchomisz nowy system, produkt, usługę lub proces, który będzie przetwarzał dane osobowe, musisz od samego początku zaplanować, jak te dane będą chronione. Ochrona danych nie jest czymś, co „doda się później” — musi być częścią projektu od pierwszego dnia.

Kluczowe elementy art. 25 ust. 1:

„Uwzględniając stan wiedzy technicznej” — administrator musi stosować aktualne rozwiązania techniczne, nie przestarzałe. Nie może tłumaczyć się tym, że „tak zawsze robiliśmy”.

„Koszt wdrażania” — RODO nie wymaga ponoszenia nieograniczonych kosztów. Administrator musi uwzględnić proporcjonalność — ale niski budżet nie jest usprawiedliwieniem dla braku jakichkolwiek zabezpieczeń.

„Przy określaniu sposobów przetwarzania” — czyli na etapie projektowania, zanim przetwarzanie się rozpocznie.

„W czasie samego przetwarzania” — privacy by design to nie jednorazowe ćwiczenie. Administrator musi ciągle weryfikować, czy zastosowane środki są nadal adekwatne.

Privacy by default — czym jest domyślna ochrona danych?

Art. 25 ust. 2 RODO stanowi, że administrator wdraża odpowiednie środki techniczne i organizacyjne, aby domyślnie przetwarzane były wyłącznie te dane osobowe, które są niezbędne dla każdego konkretnego celu przetwarzania. Obowiązek ten dotyczy ilości zbieranych danych, zakresu ich przetwarzania, okresu ich przechowywania i ich dostępności.

Przekładając na praktykę: domyślne ustawienia systemu, usługi lub produktu powinny zapewniać maksymalną ochronę prywatności. Użytkownik nie powinien musieć aktywnie „włączać” prywatności — prywatność powinna być domyślna.

Praktyczne przykłady privacy by default:

Formularz rejestracji — domyślnie nie zaznaczone checkboxy zgód marketingowych. Użytkownik sam decyduje, czy chce newsletter — nie musi się aktywnie wypisywać.

Profil w mediach społecznościowych — domyślnie ustawiony jako prywatny (widoczny tylko dla znajomych), nie publiczny. Użytkownik sam decyduje, czy chce go upublicznić.

Aplikacja mobilna — domyślnie nie zbiera danych lokalizacyjnych. Prosi o dostęp do lokalizacji dopiero gdy użytkownik chce skorzystać z funkcji, która tego wymaga.

System CRM — domyślnie ograniczony dostęp do danych klientów (tylko dla osób, które faktycznie obsługują danego klienta), nie pełny dostęp dla wszystkich pracowników.

Newsletter — po wycofaniu zgody dane są automatycznie usuwane z listy mailingowej, bez konieczności dodatkowego działania użytkownika.

Konto użytkownika — domyślny okres przechowywania danych po usunięciu konta (np. 30 dni), nie przechowywanie w nieskończoność.

Przewodnik RODO dla sklepów internetowych znajdziesz tutaj.

7 zasad privacy by design wg Ann Cavoukian

Koncepcja privacy by design została sformułowana w latach 90. przez Ann Cavoukian, kanadyjską komisarz ds. informacji i prywatności. Choć RODO nie przejmuje wprost jej 7 zasad, stanowią one najlepszą ramę koncepcyjną dla wdrożenia art. 25:

1. Proaktywność, nie reaktywność — zapobieganie, nie naprawianie. Identyfikuj i eliminuj ryzyka dla prywatności zanim się zmaterializują. Nie czekaj na naruszenie, żeby poprawić system.

2. Prywatność jako ustawienie domyślne. Domyślne ustawienia powinny zapewniać maksymalną ochronę. Użytkownik nie musi podejmować działań, żeby chronić swoją prywatność — system robi to za niego.

3. Prywatność wbudowana w projekt. Ochrona prywatności jest integralną częścią architektury systemu, nie dodatkiem. Jest elementem wymagań funkcjonalnych, nie poprawką na końcu.

4. Pełna funkcjonalność — gra o sumie dodatniej. Privacy by design nie oznacza rezygnacji z funkcjonalności. Celem jest osiągnięcie zarówno pełnej funkcjonalności, jak i pełnej ochrony prywatności — nie wybieranie jednego kosztem drugiego.

5. Bezpieczeństwo od początku do końca — ochrona pełnego cyklu życia danych. Dane są chronione od momentu ich zebrania do momentu usunięcia. Obejmuje to bezpieczne zbieranie, przechowywanie, przetwarzanie i niszczenie.

6. Widoczność i przejrzystość. Polityki i praktyki ochrony danych są otwarte i przejrzyste. Osoby, których dane dotyczą, mogą zweryfikować, że ochrona działa zgodnie z deklaracjami.

7. Szacunek dla prywatności użytkownika — użytkownik w centrum. System stawia prywatność użytkownika na pierwszym miejscu — zapewnia mocne domyślne ustawienia, odpowiednie powiadomienia i przyjazne mechanizmy zarządzania prywatnością.

Jak wdrożyć privacy by design w praktyce — po etapach

Etap 1: Faza koncepcyjna

Zanim powstanie pierwsza linia kodu czy pierwszy proces zostanie uruchomiony, zadaj pytania:

Jakie dane osobowe będą przetwarzane? Czy wszystkie są niezbędne (minimalizacja)?

Kto będzie miał dostęp do danych? Czy można ograniczyć dostęp (zasada minimalnych uprawnień)?

Jak długo dane będą przechowywane? Czy można ustalić automatyczne usuwanie?

Czy dane będą przekazywane poza organizację? Poza EOG?

Jakie ryzyka dla osób niesie przetwarzanie? Czy potrzebna jest DPIA?

Czy system można zaprojektować tak, aby przetwarzał mniej danych lub dane zanonimizowane?

Etap 2: Projektowanie

Na etapie projektowania systemu, aplikacji lub procesu wdróż konkretne środki:

Minimalizacja danych — zbieraj tylko te dane, które są obiektywnie niezbędne. Jeśli formularz rejestracji wymaga imienia i e-maila, nie dodawaj pól na datę urodzenia, numer telefonu czy adres „bo mogą się przydać”.

Pseudonimizacja — tam, gdzie to możliwe, stosuj pseudonimizację — oddziel dane identyfikujące od danych merytorycznych. Zamiast przechowywać „Jan Kowalski, choroba X, lek Y” w jednej tabeli, rozdziel dane identyfikacyjne i dane medyczne, łącząc je kluczem.

Szyfrowanie — zaprojektuj szyfrowanie od początku (at rest i in transit), nie jako poprawkę po wdrożeniu.

Kontrola dostępu — zaprojektuj system uprawnień oparty na rolach (RBAC) od samego początku. Kto musi widzieć jakie dane? Zasada: nikt nie powinien mieć dostępu do danych, których nie potrzebuje do swojej pracy.

Retencja — zaprojektuj automatyczne mechanizmy usuwania danych po upływie okresu przechowywania. Nie polegaj na ręcznym usuwaniu — zawodzi.

Anonimizacja — jeśli dane są potrzebne do analityki lub statystyki, sprawdź, czy można je zanonimizować. Dane zanonimizowane nie podlegają RODO.

Mechanizmy realizacji praw osób — zaprojektuj system tak, aby umożliwiał łatwe realizowanie żądań dostępu, usunięcia, sprostowania i przenoszenia danych. Jeśli system nie pozwala na usunięcie danych konkretnego użytkownika, narusza RODO od momentu wdrożenia.

Etap 3: Wdrożenie

Podczas wdrożenia zweryfikuj, czy zaprojektowane środki zostały faktycznie zaimplementowane:

Czy szyfrowanie jest włączone?

Czy kontrola dostępu działa prawidłowo?

Czy domyślne ustawienia są „prywatne” (privacy by default)?

Czy mechanizm usuwania danych działa?

Czy klauzula informacyjna jest na miejscu?

Etap 4: Testowanie

Przed uruchomieniem przeprowadź testy bezpieczeństwa i prywatności:

Test penetracyjny — czy system jest odporny na ataki?

Test dostępu — czy użytkownicy widzą tylko dane, do których mają uprawnienia?

Test retencji — czy dane są faktycznie usuwane po upływie okresu?

Test praw osób — czy system umożliwia realizację żądań RODO (dostęp, usunięcie, eksport)?

Test domyślnych ustawień — czy nowe konto ma „prywatne” domyślne ustawienia?

Etap 5: Utrzymanie i przegląd

Privacy by design nie kończy się na wdrożeniu. Administrator musi regularnie weryfikować, czy zastosowane środki są nadal adekwatne — szczególnie gdy zmieniają się cele przetwarzania, dodawane są nowe funkcjonalności, zmieniają się technologie i zagrożenia lub pojawiają się nowe regulacje (AI Act, NIS2).

Privacy by design w konkretnych scenariuszach

Aplikacja mobilna

Zbieraj minimalne uprawnienia — nie proś o dostęp do kontaktów, aparatu, mikrofonu, jeśli funkcja tego nie wymaga.

Przechowuj dane lokalnie na urządzeniu, jeśli nie muszą być w chmurze.

Szyfruj dane przechowywane na urządzeniu.

Domyślnie nie śledź lokalizacji — proś o zgodę na lokalizację dopiero przy funkcji, która tego wymaga.

Wdróż mechanizm usunięcia konta — z faktycznym usunięciem danych z serwera.

Strona internetowa / sklep internetowy

Formularze — zbieraj minimum danych. Oznacz pola obowiązkowe i opcjonalne.

Cookies — domyślnie ładuj tylko cookies niezbędne (prior blocking).

Konto — oferuj zakupy bez rejestracji.

Newsletter — checkbox niezaznaczony domyślnie.

Hasła — wymuszaj silne hasła, hashuj je w bazie.

Retencja — automatyczne usuwanie porzuconych koszyków i nieaktywnych kont.

System HR

Dostęp do danych pracowników — ograniczony do osób, które muszą z nich korzystać (HR, przełożony — ale nie cały dział).

Dane z rekrutacji — automatyczne usuwanie danych kandydatów po zakończeniu rekrutacji (chyba że zgoda na przyszłe rekrutacje).

Monitoring — domyślnie wyłączony, włączany tylko po spełnieniu wszystkich wymogów prawnych.

Akta osobowe elektroniczne — szyfrowanie, kontrola dostępu, logowanie operacji.

System CRM

Dane klientów — dostęp ograniczony do opiekuna klienta i jego przełożonego, nie do całej firmy.

Segmentacja i profilowanie — domyślnie wyłączone, włączane po uzyskaniu podstawy prawnej.

Okres retencji — automatyczne usuwanie danych nieaktywnych klientów po określonym czasie.

Eksport danych — możliwość eksportu danych klienta w formacie maszynowym (realizacja prawa do przenoszenia).

Privacy by design a DPIA

Privacy by design i DPIA to dwa uzupełniające się narzędzia:

DPIA identyfikuje ryzyka związane z planowanym przetwarzaniem i proponuje środki zaradcze.

Privacy by design zapewnia, że te środki zaradcze są wbudowane w projekt od początku, a nie dodawane jako poprawki po wdrożeniu.

W praktyce DPIA powinna być przeprowadzana na etapie projektowania (nie po wdrożeniu) — a jej wyniki powinny bezpośrednio wpływać na architekturę systemu. Jeśli DPIA wykaże wysokie ryzyko profilowania, system powinien być zaprojektowany z mechanizmami ograniczającymi profilowanie (opt-out, transparentność algorytmu) — a nie z informacją „ryzyko jest wysokie, ale nic z tym nie robimy”. 

Jak przeprowadzić DPIA krok po kroku opisujemy w osobnym artykule.

Privacy by design a AI Act

AI Act (art. 9) wymaga, aby systemy AI wysokiego ryzyka były projektowane i rozwijane z uwzględnieniem zarządzania danymi — w tym jakości danych treningowych, minimalizacji danych i odpowiednich zabezpieczeń. To jest privacy by design w kontekście sztucznej inteligencji.

Połączenie art. 25 RODO z wymogami AI Act oznacza, że organizacje wdrażające systemy AI muszą od samego początku projektować je z uwzględnieniem ochrony danych osobowych (RODO) i zarządzania ryzykiem AI (AI Act).

O relacji AI Act i RODO piszemy w osobnym artykule.

Najczęstsze błędy — naruszenia art. 25 RODO

„RODO dodamy później” — najpowszechniejszy błąd. System jest projektowany, budowany i wdrażany, a dopiero na końcu ktoś pyta „a co z RODO?”. W tym momencie zmiany architekturalne są kosztowne lub niemożliwe.

Zbieranie danych „na zapas” — formularze z dziesiątkami pól, z których większość nie jest niezbędna. Narusza zarówno privacy by design, jak i zasadę minimalizacji danych.

Domyślnie „wszystko publiczne” — profile użytkowników domyślnie publiczne, checkboxy marketingowe domyślnie zaznaczone, dostęp do danych domyślnie dla wszystkich pracowników.

Brak mechanizmu usuwania danych — system nie przewiduje możliwości usunięcia danych konkretnego użytkownika (np. dane są rozsiane po wielu tabelach bez mechanizmu kaskadowego usuwania).

Brak retencji — system nie ma mechanizmu automatycznego usuwania danych po upływie okresu przechowywania. Dane gromadzą się w nieskończoność.

Brak szyfrowania na etapie projektowania — dodawanie szyfrowania po wdrożeniu jest znacznie trudniejsze i kosztowniejsze niż zaprojektowanie go od początku.

Ignorowanie zasady minimalnych uprawnień — wszyscy pracownicy mają dostęp do wszystkich danych. Brak systemu ról i uprawnień.

Brak udziału IOD w projektowaniu — IOD nie jest konsultowany na etapie projektowania nowych systemów i procesów. Dowiaduje się o nich dopiero po wdrożeniu.

Kary za naruszenie art. 25 RODO

Art. 25 RODO podlega karom z art. 83 ust. 4 — do 10 mln euro lub 2% rocznego światowego obrotu. UODO i europejskie organy nadzorcze coraz częściej nakładają kary za brak privacy by design — szczególnie gdy naruszenie danych było konsekwencją braku zabezpieczeń, które powinny być wbudowane od początku.

UODO nałożył kary m.in. na Morele.net (3,8 mln zł) za naruszenie art. 25 i 32 RODO — niewystarczające zabezpieczenia techniczne, które powinny być zaprojektowane od początku.

Przegląd najważniejszych kar UODO znajdziesz w naszym artykule.

Checklist — privacy by design i privacy by default

1. Włącz IOD i zespół ds. ochrony danych w proces projektowania nowych systemów i procesów — od samego początku.
2. Przeprowadź DPIA na etapie projektowania — nie po wdrożeniu.
3. Stosuj minimalizację danych — zbieraj tylko to, co niezbędne.
4. Zaprojektuj domyślne ustawienia jako „prywatne” — nie wymagaj od użytkownika aktywnego włączania prywatności.
5. Wdróż szyfrowanie od początku — at rest i in transit.
6. Zaprojektuj kontrolę dostępu opartą na rolach (RBAC) — zasada minimalnych uprawnień.
7. Zaplanuj automatyczną retencję — mechanizm usuwania danych po upływie okresu przechowywania.
8. Zaprojektuj mechanizmy realizacji praw osób — dostęp, usunięcie, eksport, sprostowanie.
9. Rozważ pseudonimizację i anonimizację — tam, gdzie to możliwe.
10. Testuj prywatność przed wdrożeniem — testy dostępu, retencji, domyślnych ustawień.
11. Dokumentuj decyzje projektowe — jakie środki zastosowano, dlaczego, jakie alternatywy rozważono.
12. Regularnie przeglądaj — czy środki są nadal adekwatne do ryzyk.

Potrzebujesz wsparcia z privacy by design?

Wdrożenie privacy by design wymaga udziału eksperta ds. ochrony danych na najwcześniejszym etapie projektu — zanim powstaną decyzje architekturalne, które trudno będzie zmienić. W Kancelarii Radcowskiej dr Joanny Maniszewskiej-Ejsmont doradzamy firmom przy projektowaniu systemów, aplikacji i procesów zgodnych z art. 25 RODO — od analizy wymagań, przez DPIA, po weryfikację wdrożenia.