Privacy by design i privacy by default — art. 25 RODO i projektowanie aplikacji

Stan prawny: 17 października 2026 r. WILIŃSKI LEGAL — analiza ochrony danych osobowych.

Odpowiedź w skrócie

Art. 25 RODO wymaga uwzględniania ochrony danych już przy określaniu sposobów przetwarzania oraz w jego trakcie. Domyślnie przetwarzać należy tylko dane niezbędne dla konkretnego celu, z ograniczeniem ilości, zakresu, czasu przechowywania i dostępności. Środki dobiera się z uwzględnieniem ryzyka, kosztów i stanu wiedzy technicznej.

Ochrona prywatności zaczyna się od projektu

Prawidłowe wdrożenie RODO nie polega na doklejeniu polityki prywatności do już uruchomionego systemu. Architektura bazy danych, rodzaje formularzy, uprawnienia pracowników i okresy retencji powinny zostać ocenione przed wdrożeniem. W przeciwnym razie może się okazać, że aplikacja nie potrafi ograniczyć dostępu do dokumentów albo usunąć danych po upływie właściwego okresu. Projektowanie wymaga określenia celu każdej operacji i identyfikacji ryzyka dla praw osób, nie tylko audytu zgodności treści komunikatów.

Minimalizacja: pytaj tylko o to, co jest niezbędne

Formularz do umówienia pierwszej konsultacji prawnej nie powinien bez uzasadnienia wymagać numeru PESEL, skanu dowodu i historii medycznej. Dane szczegółowe można zbierać w późniejszym etapie, jeśli są rzeczywiście potrzebne do obsługi sprawy. Każde wymagane pole powinno mieć uzasadniony związek z celem. Rozbudowane formularze, które żądają wielu informacji »na wszelki wypadek«, zwiększają zagrożenie incydentem i komplikują retencję. Dobra praktyka polega na ocenie pola podczas projektowania i jego regularnym przeglądzie.

Domyślna prywatność ustawień

Privacy by default zakłada, że użytkownik nie musi samodzielnie wyłączać zbędnej publicznej ekspozycji swoich informacji. Profil lub dokumentacja klienta nie powinny być dostępne nieograniczonemu gronu osób jedynie z powodu domyślnej konfiguracji. W firmie należy stosować role i zasadę najmniejszych uprawnień. Administrator systemu technicznego nie musi mieć stałego dostępu do każdej treści, jeżeli zadanie można wykonać bez niego. Ustawienia należy testować także po aktualizacjach platformy i zmianach członków zespołu.

Pseudonimizacja a anonimowość

Pseudonimizacja może zmniejszać ryzyko przez oddzielenie bezpośrednich identyfikatorów od pozostałych informacji. Nie oznacza to jednak automatycznego wyłączenia stosowania RODO, jeśli możliwe jest ponowne przypisanie danych określonej osobie. Szyfrowanie chroni poufność, ale nie naprawi przetwarzania danych, które w ogóle nie są potrzebne. Dobór środków musi być oparty na ocenie ryzyka i celu. Sam slogan »wszystko jest szyfrowane« nie jest wystarczającym dowodem stosowania zasad projektowania ochrony danych.

Retencja i możliwość wykonania praw osoby

System powinien umożliwiać odnalezienie informacji odnoszących się do określonej osoby, ich sprostowanie, ograniczenie i — kiedy jest to wymagane — usunięcie. Jeżeli architektura bezterminowo kopiuje pliki do wielu magazynów bez kontroli, powstaje problem rozliczalności. Należy ustalić okresy przechowywania odrębnie dla kategorii danych i podstaw prawnych, a także przetestować procedury obsługi kopii zapasowych. Nie wolno bezrefleksyjnie usuwać dokumentów, których zachowanie nakazuje ustawa lub wymaga obrona roszczeń.

Ocena skutków DPIA nie zastępuje art. 25

Art. 35 przewiduje odrębną ocenę skutków dla ochrony danych w przypadkach prawdopodobnego wysokiego ryzyka. Nie każda mała aplikacja wymaga formalnej DPIA, ale każda podlegająca RODO powinna uwzględniać ochronę danych w odpowiednim zakresie. Z drugiej strony sporządzenie samego raportu DPIA nie zapewnia zgodności architektury, jeśli firma nie wdrożyła zaleceń. Ochrona danych w fazie projektowania ma charakter ciągły i musi być aktualizowana przy nowych funkcjach oraz zmianach dostawców.

Umowa z dostawcą SaaS nie przenosi całej odpowiedzialności

Korzystanie z CRM, chmury lub systemu do zarządzania dokumentami wymaga oceny ról administratora i podmiotu przetwarzającego. Przy zawieraniu umowy warto sprawdzić podwykonawców, uprawnienia wsparcia technicznego, lokalizację danych, eksport i sposób usuwania informacji. Sama deklaracja dostawcy, że produkt jest zgodny z RODO, nie zastępuje własnej analizy. Administrator powinien dysponować dokumentami potwierdzającymi środki techniczne i organizacyjne oraz testować ich funkcjonowanie, szczególnie gdy przetwarzane są informacje chronione tajemnicą zawodową.

Przykład portalu kancelarii

Nowy portal dla klientów umożliwia przesyłanie dokumentów procesowych. Projekt powinien ograniczać dostęp do właściwych spraw, stosować adekwatne uwierzytelnianie, logowanie działań oraz zasady wygasania linków. Formularz nie powinien wymagać pełnej historii sprawy, jeżeli wystarczy krótki opis i kontakt. Trzeba także sprawdzić treść wiadomości e-mail, bo nawet bezpieczny portal nie zapobiegnie naruszeniu, jeśli powiadomienie ujawnia treść dokumentu niewłaściwemu odbiorcy. Testy powinny objąć komputery i urządzenia mobilne.

Dowody, że projekt działa zgodnie z zasadami

W audycie przydatna jest macierz celów i kategorii danych, lista dostępów, schemat przepływów, harmonogram retencji i rejestr testów. Należy sprawdzić rzeczywiste zachowanie systemu w scenariuszach: użytkownik wycofuje zgodę, klient kończy współpracę, pracownik zmienia rolę albo firma otrzymuje żądanie dostępu. Tylko takie testy pokazują, czy ochrona istnieje poza dokumentacją. Zarząd powinien mieć możliwość nadzoru nad istotnymi ryzykami, a dział IT jasną procedurę zgłaszania odstępstw i incydentów.

Materiał dowodowy i dokumenty

Przy ocenie sytuacji należy zachować dokumenty źródłowe, daty wpływu żądania albo wykrycia incydentu, rejestry systemowe oraz korespondencję z dostawcami. Trzeba osobno ustalić, które fakty są pewne, a które pozostają hipotezami wymagającymi weryfikacji. Raport powinien identyfikować osobę odpowiedzialną za wykonanie decyzji, termin i zastosowane środki. Taki ślad umożliwia wykazanie rozliczalności zgodnie z art. 5 ust. 2 RODO i ogranicza ryzyko niespójnych informacji przekazywanych organowi oraz osobom zainteresowanym.

Możliwe kontrargumenty i wyjątki

Administrator może wskazywać, że określona kategoria danych jest objęta wyjątkiem, żądanie wykracza poza zakres danego uprawnienia albo ryzyko ma inny poziom niż twierdzi zainteresowany. Nie wystarczy jednak standardowa formuła bez wskazania faktów i przepisu. Osoba może z kolei kwestionować jakość analizy, brak terminowej odpowiedzi albo niedostateczne środki ochronne. Skuteczny spór wymaga wskazania konkretnej operacji przetwarzania, możliwych skutków i dowodów, nie ogólnego stwierdzenia, że przetwarzanie jest »niezgodne z RODO«.

Rola IOD i odpowiedzialność administratora

Inspektor ochrony danych może wspierać ocenę prawną i organizację odpowiedzi, ale jego udział nie znosi odpowiedzialności administratora za podejmowane decyzje. Przy współpracy z zewnętrznym dostawcą trzeba ustalić rzeczywiste role stron, zakres upoważnień i kanały wymiany informacji. Dobrą praktyką jest zachowanie spójności między polityką ochrony danych, umowami powierzenia i działającymi systemami. W dużych organizacjach przydatna jest procedura eskalacji, dzięki której pilne sprawy nie pozostają bez decyzji w okresie nieobecności jednej osoby.

Praktyczna checklista decyzji

W pierwszej kolejności należy ustalić stan faktyczny i rodzaj przetwarzanych danych. Następnie trzeba wskazać właściwy przepis, jego przesłanki oraz możliwe wyjątki. Trzeci etap obejmuje dokumentowanie oceny i wykonanie środków technicznych. Wreszcie konieczne jest przekazanie odpowiedniej informacji osobie albo organowi, jeżeli wymagają tego przepisy. Kontrola końcowa powinna sprawdzić zgodność deklaracji z rzeczywistym funkcjonowaniem systemów, a także odnotować działania zapobiegające ponownemu problemowi.

Lista kontrolna

1. Ustal stan faktyczny, zakres danych i odpowiedzialny podmiot.
2. Zweryfikuj przesłanki prawne oraz wyjątki.
3. Zabezpiecz dokumentację i ślad czynności.
4. Dobierz odpowiednie środki ochrony i komunikacji.
5. Udokumentuj ostateczną decyzję i dalszy monitoring.

Źródła pierwotne

Art. 25 RODO oraz art. 5, 24, 28, 32 i 35 RODO.. Rozporządzenie (UE) 2016/679 — EUR-Lex. Wytyczne Europejskiej Rady Ochrony Danych dotyczące naruszeń.

Materiał edukacyjny; nie stanowi indywidualnej opinii prawnej.