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

W audycie ochrony danych w fazie projektowania należy sprawdzić domyślne uprawnienia użytkowników, minimalną ilość gromadzonych informacji i techniczne możliwości usuwania danych. Szeroki dostęp wszystkich pracowników nie staje się zgodny z RODO tylko dlatego, że został opisany w polityce bezpieczeństwa. Znaczenie mają realny podział ról, cykl życia konta i testowanie zmian w oprogramowaniu. Dokumentacja powinna pokazywać, jak oceniono ryzyko określonej funkcji jeszcze przed jej uruchomieniem, nie wyłącznie po wystąpieniu incydentu.

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.