Privacy by design — art. 25 RODO, minimalizacja i ochrona domyślna

Stan prawny na 17 października 2026 r. WILIŃSKI LEGAL — analiza RODO.

Odpowiedź w skrócie

Art. 25 nakazuje uwzględniać ochronę danych na etapie projektowania oraz podczas przetwarzania. Domyślnie organizacja powinna zbierać, wykorzystywać i udostępniać jedynie dane niezbędne do konkretnego celu.

Ochrona przed uruchomieniem usługi

Privacy by design nie polega na publikowaniu polityki prywatności po uruchomieniu aplikacji. Już podczas ustalania funkcji systemu należy określić cele, podstawy, zakres danych i okres retencji. Trzeba zaprojektować obsługę prawa dostępu, korekty i usunięcia, a także mechanizmy ograniczania uprawnień. Odkładanie tych kwestii na później może oznaczać konieczność przebudowy całej architektury i zwiększone ryzyko incydentów.

Minimalizacja pól i danych

Nie należy domyślnie zbierać skanu dowodu osobistego, historii medycznej i innych informacji wykraczających poza cel prostego formularza kontaktowego. Każde pole obowiązkowe powinno mieć uzasadnienie. Dane potrzebne przy właściwej obsłudze sprawy można zebrać na późniejszym etapie za pośrednictwem bezpiecznego kanału. Nadmierne gromadzenie informacji zwiększa zakres odpowiedzialności administratora, nie dając automatycznie żadnej korzyści prawnej.

Dostępność danych i role

Art. 25 ust. 2 obejmuje ilość danych, zakres ich wykorzystania, czas przechowywania i dostępność. Domyślnie dane nie powinny być publiczne ani dostępne całemu zespołowi bez uzasadnionej potrzeby. W systemie kancelarii warto testować rolę pracownika przypisanego do określonej sprawy, logi dostępu oraz procedurę cofania uprawnień. Samo posiadanie hasła administratora nie jest wystarczającą gwarancją ochrony przed przypadkowym ujawnieniem.

Pseudonimizacja, szyfrowanie i DPIA

Pseudonimizowane dane nadal mogą być osobowe. Szyfrowanie poprawia poufność, lecz nie uzasadnia gromadzenia informacji bez potrzebnej podstawy. Projekt wymaga oceny ryzyka i adekwatnych środków. W razie wysokiego ryzyka należy osobno przeanalizować obowiązek oceny skutków na podstawie art. 35. Nie każda mała aplikacja wymaga formalnej DPIA, ale każda powinna zapewniać wykonalną retencję, kontrolę dostępu i poprawne zasady udostępniania informacji.

Ocena roli podmiotów

W odniesieniu do ochrony danych w fazie projektowania należy najpierw ustalić administratora, ewentualnych współadministratorów i podmioty przetwarzające. Nazwa umowy nie zawsze przesądza rzeczywistą rolę. Istotne są faktyczne decyzje o celach i sposobach wykorzystania danych. Warto przygotować mapę przepływów informacji oraz odpowiedzialnych osób. Bez tej analizy trudno stwierdzić, który podmiot ma udzielić odpowiedzi, przeprowadzić korektę systemu albo poinformować odbiorców. Dobre procedury rozdzielają zadania prawne, techniczne i organizacyjne.

Przesłanki i wyjątki

Nie każda operacja z danymi może zostać uzasadniona ogólnym interesem biznesowym. Administrator powinien wskazać właściwą podstawę z rozporządzenia i szczegółowo ustalić jej zakres. Wyjątki nie mogą być używane automatycznie do odmowy żądań. Nie należy też pomijać innych obowiązków ustawowych, w szczególności dotyczących przechowywania dokumentów lub ochrony praw osób trzecich. Rozstrzygnięcie powinno być uzasadnione na tle rzeczywistych faktów, a nie tylko wewnętrznego regulaminu.

Rejestr działań i terminy

Rozpoznanie sprawy dotyczącej ochrony danych w fazie projektowania wymaga dokumentacji dat, źródeł informacji, ustaleń prawnych i wykonanych czynności. Jeżeli osoba korzysta z prawa przewidzianego w rozdziale III RODO, trzeba uwzględnić zasady art. 12 dotyczące terminów odpowiedzi i komunikacji. Warto monitorować, czy zlecona operacja została rzeczywiście wykonana w systemie głównym i integracjach. Udokumentowana odmowa powinna zawierać konkretną podstawę, a nie szablonowy komunikat pozostawiający osobę bez wyjaśnienia.

Zabezpieczenie praw innych osób

Czynności przetwarzania mogą dotyczyć danych kilku użytkowników, członków rodziny albo kontrahentów. Administrator musi uwzględnić ich prawa i wolności, lecz nie powinien traktować tego jako uniwersalnej podstawy odmowy wykonania każdego żądania. Potrzebna jest proporcjonalna identyfikacja danych podlegających działaniu. Szczególne znaczenie ma weryfikacja odbiorcy informacji oraz minimalizacja ujawnianych pól. Nieprawidłowo wykonana operacja może stworzyć nowe naruszenie nawet wtedy, gdy pierwotne żądanie było zasadne.

Wewnętrzny audyt techniczny

W procesie obejmującym ochrony danych w fazie projektowania ważne są testy systemowe, kontrola logów i sprawdzenie uprawnień dostępu. Deklaracja dostawcy SaaS, że produkt jest zgodny z RODO, nie zastępuje własnej oceny administratora. Należy też ustalić, co dzieje się z danymi w kopiach zapasowych i po migracji usług. Organizacja musi umieć odtworzyć zakres czynności w razie skargi lub kontroli nadzorczej. Nie zawsze trzeba przebudowywać system, ale powinno się znać realne ograniczenia techniczne.

Środki ochrony prawnej

Osoba, której prawa nie zostały należycie zrealizowane, może w odpowiednich warunkach zwrócić się do organu nadzorczego oraz skorzystać z przewidzianych prawem środków sądowych. Nie oznacza to automatycznego przyznania określonej kwoty odszkodowania po samym stwierdzeniu nieprawidłowości. Trzeba odrębnie wykazać właściwe przesłanki roszczenia. Skuteczna skarga wskazuje konkretne dane, czynności, daty i treść korespondencji z administratorem, zamiast poprzestawać na ogólnym oskarżeniu o naruszanie rozporządzenia.

Przykład kontroli przy zmianie systemu

Przedsiębiorca przenosi portal klientów do nowego dostawcy i otrzymuje żądanie dotyczące ochrony danych w fazie projektowania. Powinien ustalić, czy w obu środowiskach znajduje się ta sama informacja oraz jak zrealizować obowiązek prawny bez przypadkowego ujawnienia danych innym osobom. Rzetelna kontrola obejmuje datę migracji, zakres uprawnień, kopie danych i decyzje podjęte w związku z żądaniem. Nie wystarczy samo wyłączenie starego portalu, jeśli problem przetrwał w nowym systemie.

Konkluzja dla administratora

Prawidłowe stosowanie ochrony danych w fazie projektowania wymaga połączenia ścisłej analizy normy z rzeczywistymi operacjami technicznymi. Proces powinien być jasny dla osoby, rozliczalny i możliwy do sprawdzenia także po kilku miesiącach. Najczęstszym ryzykiem jest mylenie sąsiednich uprawnień albo przyjmowanie, że ogólna polityka prywatności pozwala na wszystkie operacje. Starannie zaprojektowane role, procedury i komunikaty chronią zarówno prawa jednostki, jak i interes organizacji.

Lista kontrolna

1. Ustal podstawę prawną i cel.
2. Zidentyfikuj dane oraz właściwy podmiot.
3. Oceń przesłanki i wyjątki.
4. Udokumentuj działania.
5. Zweryfikuj odpowiedź i skutki.

Źródła

Art. 25 rozporządzenia (UE) 2016/679. RODO — tekst urzędowy EUR-Lex.

Artykuł ma charakter informacyjny.

Testy mobilne jako element prywatności

Projektanci portali powinni sprawdzić nie tylko estetykę wersji mobilnej, ale również to, czy formularze i elementy potwierdzające nie ujawniają danych na ekranach publicznie dostępnych. Na telefonie przypadkowe autouzupełnienie, niewłaściwy podgląd załącznika albo skopiowanie danych do logów analitycznych może stworzyć ryzyko dla użytkownika. Przed wdrożeniem warto przeprowadzić test scenariuszy związanych z logowaniem, zakończeniem sesji, błędnym przesłaniem formularza i utratą urządzenia. Ochrona domyślna obejmuje realną obsługę, nie tylko dokumentację systemu.

Dostawca chmurowy i konfiguracja

Przeniesienie danych do chmury nie znosi obowiązku administratora wyboru właściwych środków i oceny podwykonawców. Należy sprawdzić lokalizację, dostęp administracyjny, okres retencji, możliwość eksportu i usuwania danych oraz zasady logowania czynności. Umowa powierzenia stanowi ważny element, ale nie wystarcza bez odpowiedniej konfiguracji. Warto żądać potwierdzeń testów oraz przeprowadzać własne kontrole. Samo zapewnienie o certyfikacji dostawcy nie oznacza, że każdy sposób użycia systemu jest automatycznie zgodny z art. 25.

Koncepcja projektu a rzeczywista minimalizacja

Na etapie analizy wymagań warto sporządzić tabelę pól danych, ich celu, podstawy prawnej i okresu przechowywania. Jeśli informacja jest przydatna wyłącznie w rzadkim przypadku, można przewidzieć jej zebranie później zamiast wymagać jej od każdego użytkownika. Należy ograniczyć automatyczne udostępnianie danych i projektować uprawnienia według ról. Taka dokumentacja pozwala wykazać, że minimalizacja została rzeczywiście przeanalizowana. W przeciwnym razie określenie privacy by design pozostaje tylko hasłem marketingowym.