Privacy by design to zasada, według której ochronę danych osobowych projektuje się razem z produktem, a nie dopisuje po wdrożeniu. W Unii Europejskiej jest to obowiązek administratora danych zapisany w art. 25 RODO, a za jego naruszenie grozi kara do 10 mln euro albo 2% rocznego światowego obrotu. O tym, czy produkt spełnia zasadę, decydują konkretne ekrany: formularz rejestracji, zgody, ustawienia domyślne i sposób usuwania danych.

Privacy by design powstało jako koncepcja, a w art. 25 RODO stało się obowiązkiem

Koncepcję sformułowała w latach 90. Ann Cavoukian, ówczesna komisarz ds. informacji i prywatności prowincji Ontario. Spisała ją w dokumencie „Privacy by Design: The 7 Foundational Principles”. Przez lata była to dobra praktyka. RODO zmieniło jej status: art. 25 nakłada na administratora dwa obowiązki.

Ochrona danych w fazie projektowania (ust. 1). Środki techniczne i organizacyjne, na przykład pseudonimizację i minimalizację danych, administrator wdraża już przy określaniu sposobów przetwarzania, a potem utrzymuje je w czasie samego przetwarzania.
Domyślna ochrona danych (ust. 2). Bez żadnej akcji użytkownika przetwarzane są tylko dane niezbędne do konkretnego celu. Dotyczy to ilości danych, zakresu przetwarzania, okresu przechowywania i dostępności. Domyślnie dane nie mogą być udostępniane nieokreślonej liczbie osób bez działania osoby, której dotyczą.

Jak te przepisy stosować, opisują wytyczne 4/2019 Europejskiej Rady Ochrony Danych, przyjęte w wersji ostatecznej 20 października 2020 r. Obowiązek ciąży na administratorze, czyli firmie, która decyduje o celach przetwarzania. Wykonawca oprogramowania nie jest adresatem art. 25, a motyw 78 RODO jedynie zachęca wytwórców do uwzględniania ochrony danych. Skutek jest prosty: za decyzje projektowe wykonawcy odpowiada przed organem nadzorczym firma, która zamówiła produkt.

Siedem zasad widać w decyzjach projektowych

Zasady Cavoukian są ogólne, dlatego przy każdej podajemy decyzję, w której zespół produktowy ją rozstrzyga.

Zasada	Co oznacza	Przykład w produkcie
1. Zapobieganie zamiast naprawiania	Ryzyko dla prywatności ocenia się przed budową funkcji, a nie po incydencie.	Ocena skutków dla ochrony danych (art. 35 RODO) powstaje przed projektem modułu z danymi o zdrowiu.
2. Prywatność jako ustawienie domyślne	Użytkownik, który niczego nie zmienia, jest chroniony najmocniej.	Zgody marketingowe są odznaczone, profil nie jest publiczny, lokalizacja pozostaje wyłączona.
3. Prywatność wbudowana w projekt	Ochrona danych jest częścią architektury, a nie nakładką.	Analityka dostaje identyfikatory pseudonimowe, a dane medyczne są oddzielone od danych konta.
4. Pełna funkcjonalność: suma dodatnia, nie zerowa	Prywatności nie wymienia się na użyteczność. Projekt ma zapewnić jedno i drugie.	Produkt działa po odmowie zgody na analitykę. Rejestracja nie wymaga numeru telefonu, jeśli żadna funkcja go nie potrzebuje.
5. Bezpieczeństwo w całym cyklu życia danych	Dane są chronione od zebrania do usunięcia.	Szyfrowanie, termin retencji dla każdej kategorii danych, automatyczne usuwanie nieaktywnych kont.
6. Widoczność i przejrzystość	Użytkownik i audytor mogą sprawdzić, co jest zbierane i po co.	Przy polu formularza jest wyjaśnienie celu, a w ustawieniach ekran z historią zgód.
7. Szacunek dla prywatności użytkownika	Interes osoby, której dane dotyczą, ma pierwszeństwo przed wygodą systemu.	Wycofanie zgody jest równie łatwe jak jej udzielenie. Eksport danych i usunięcie konta są dostępne w ustawieniach.

Czwarta zasada bywa tłumaczona błędnie jako „suma zerowa”. W oryginale brzmi „Positive-Sum, not Zero-Sum”, czyli odwrotnie: Cavoukian odrzuca założenie, że więcej prywatności oznacza mniej funkcji.

Pięć miejsc w interfejsie, w których zasada jest sprawdzana

Formularz rejestracji

Każde pole wymaga uzasadnienia celem. Data urodzenia, płeć i numer telefonu zbierane „na przyszłość” łamią zasadę minimalizacji i wydłużają formularz, więc szkodzą również konwersji. Dobre pytanie kontrolne dla zespołu: która funkcja przestanie działać, gdy tego pola zabraknie.

Zgody

Zgoda jest osobna dla każdego celu, domyślnie nieudzielona i opisana językiem zrozumiałym bez prawnika. Przycisk odmowy ma tę samą wagę wizualną co przycisk akceptacji. Wycofanie zgody nie może wymagać kontaktu z działem obsługi.

Ustawienia domyślne

To tutaj art. 25 ust. 2 jest najbardziej dosłowny. Widoczność profilu, udostępnianie danych innym użytkownikom organizacji, powiadomienia e-mail i integracje z zewnętrznymi narzędziami startują w wariancie najbardziej oszczędnym. Szerszy zakres włącza sam użytkownik albo administrator konta firmowego.

Retencja i usuwanie danych

Okres przechowywania jest decyzją produktową, a nie ustawieniem bazy danych. Zespół ustala, po jakim czasie znika konto nieaktywne, co dzieje się z danymi po zakończeniu subskrypcji i czy usunięcie konta obejmuje kopie zapasowe oraz logi. Użytkownik widzi te terminy w produkcie.

Analityka i narzędzia zewnętrzne

Nagrania sesji i mapy kliknięć pomagają poprawiać produkt, ale rejestrują to, co użytkownik wpisuje. Pola formularzy i ekrany z danymi osobowymi wymagają maskowania, a lista narzędzi zewnętrznych powinna być krótka i udokumentowana. Każdy kolejny skrypt to kolejny podmiot przetwarzający dane. Dotyczy to także skryptów CAPTCHA, a alternatywy dla nich zestawia wpis ochrona formularzy przed spamem.

Aplikacja medyczna wymaga więcej niż typowy SaaS

Dane o zdrowiu należą do szczególnych kategorii danych z art. 9 RODO, więc te same decyzje projektowe mają wyższą stawkę. W produkcie medycznym do listy dochodzą trzy rzeczy. Dostęp do dokumentacji jest przyznawany według roli i zapisywany w dzienniku, który da się przejrzeć. Powiadomienia push nie pokazują treści medycznych na zablokowanym ekranie telefonu. Dane do badań i statystyk są pseudonimizowane przed opuszczeniem systemu. Te wymagania uwzględniamy, projektując aplikacje dla sektora medycznego. Szersze tło regulacyjne opisujemy we wpisie o trendach w aplikacjach medycznych. Terminy przepisów zestawia kalendarz regulacji dla rynku medtech.

Pominięcie zasady kosztuje na trzy sposoby

Kara administracyjna. Art. 83 ust. 4 RODO przewiduje za naruszenie art. 25 karę do 10 mln euro, a w przypadku przedsiębiorstwa do 2% całkowitego rocznego światowego obrotu, zależnie od tego, która kwota jest wyższa.
Przebudowa. Rozdzielenie danych, dodanie retencji albo przeprojektowanie zgód w działającym produkcie oznacza zmianę modelu danych, migrację i ponowne testy. Te same decyzje podjęte na etapie makiet kosztują kilka godzin rozmowy.
Sprzedaż. Duży klient B2B przed podpisaniem umowy pyta o retencję, podmioty przetwarzające i ustawienia domyślne. Brak odpowiedzi wydłuża proces zakupowy albo go kończy.

Odpowiedzialność rozkłada się na cały zespół produktowy

Inspektor ochrony danych opiniuje, ale nie projektuje ekranów. Product Owner decyduje, jakie dane są potrzebne do celu biznesowego. Projektant odpowiada za formularze, zgody i ustawienia. Zespół techniczny odpowiada za model danych, szyfrowanie i retencję. Zasada działa wtedy, gdy pytanie o dane pada na tym samym spotkaniu co pytanie o funkcję, a jego wynik trafia do kryteriów akceptacji. Podobnie jest z dostępnością, która od 28 czerwca 2025 r. także jest wymogiem prawnym projektowanym w interfejsie. Opisujemy ją we wpisie o tym, kogo dotyczy EAA.

Prywatność w istniejącym produkcie sprawdza audyt UX

W Squares oceniamy ścieżki, na których zapadają opisane decyzje: rejestrację, formularze, zgody i ustawienia. Audyt UX kosztuje od 4 500 zł netto i kończy się listą zmian uszeregowanych według wpływu na użytkownika i biznes. Nie zastępuje opinii prawnej ani oceny skutków dla ochrony danych, pokazuje natomiast, które ekrany wymagają poprawy w pierwszej kolejności.

Najczęstsze pytania

Czy privacy by design jest obowiązkowe?

Tak. Art. 25 RODO nakłada na administratora danych obowiązek uwzględniania ochrony danych w fazie projektowania oraz obowiązek domyślnej ochrony danych. Dotyczy to każdej firmy, która przetwarza dane osobowe w produkcie cyfrowym. Za naruszenie grozi kara do 10 mln euro albo 2% rocznego światowego obrotu przedsiębiorstwa.

Czym privacy by design różni się od privacy by default?

Privacy by design dotyczy całego procesu: ochronę danych planuje się od pierwszych decyzji o produkcie i utrzymuje przez cały czas przetwarzania. Privacy by default jest węższe i dotyczy ustawień początkowych. Użytkownik, który niczego nie zmienia, ma mieć przetwarzane wyłącznie dane niezbędne do danego celu, przez niezbędny czas.

Kto odpowiada za privacy by design, gdy produkt buduje zewnętrzny wykonawca?

Odpowiada administrator danych, czyli firma, która decyduje o celach i sposobach przetwarzania. Wykonawca oprogramowania nie jest adresatem art. 25 RODO. Dlatego wymagania dotyczące minimalizacji danych, ustawień domyślnych i retencji powinny znaleźć się w zakresie prac i kryteriach akceptacji, zanim zacznie się projektowanie.

Privacy by design: 7 zasad i przykłady w produkcie cyfrowym