Ręce układające blokady zabezpieczeń na biurku

Aby aplikacja webowa działała zgodnie z RODO, potrzebujesz pięciu rzeczy naraz: Privacy by Design wpisanego w architekturę (art. 25), rejestru czynności przetwarzania (art. 30), zabezpieczeń technicznych i organizacyjnych (art. 32), procedury zgłaszania naruszeń w ciągu 72 godzin oraz podpisanych umów powierzenia z każdym dostawcą (art. 28). Żaden z tych elementów nie działa w oderwaniu od pozostałych, a pominięcie jednego zwykle wychodzi na jaw dopiero przy kontroli lub incydencie.

Jeśli zarządzasz zespołem produktowym albo odpowiadasz za wdrożenie aplikacji, oto lista działań, które warto uruchomić w tym tygodniu:

Zrób inwentaryzację danych osobowych przetwarzanych w aplikacji i oceń, czy zbieranie każdego pola jest naprawdę potrzebne.
Sprawdź, czy masz aktualny rejestr czynności przetwarzania zgodny z art. 30.
Zweryfikuj, czy DPIA jest wymagana dla funkcji o wysokim ryzyku (np. profilowanie, dane zdrowotne).
Przetestuj mechanizmy szyfrowania, kontroli dostępu i pseudonimizacji zgodnie z art. 32.
Skompletuj umowy powierzenia z dostawcami SDK, hostingu i analityki (art. 28).
Przygotuj gotowy plan reagowania na incydenty z jasno przypisanymi rolami.
Wprowadź w UI mechanizmy realizacji praw osób: dostęp, sprostowanie, usunięcie, przenoszalność.

Na zgłoszenie naruszenia do PUODO masz maksymalnie 72 godziny od momentu jego wykrycia, jeśli istnieje ryzyko naruszenia praw lub wolności osób. Jeśli potrzebujesz wsparcia przy audycie, Paweł Styperek, CEO Studio201, i jego zespół prowadzą takie wdrożenia od strony technicznej i prawnej równocześnie.

Kluczowe wnioski

Zgodność aplikacji webowej z RODO wymaga jednoczesnego wdrożenia Privacy by Design, rejestrów czynności, zabezpieczeń technicznych, procedury zgłaszania naruszeń i umów powierzenia.

Punkt	Szczegóły
Projektuj prywatność od startu	Wpisz minimalizację danych i pseudonimizację do specyfikacji funkcji, zanim zaczniesz kodować.
Prowadź żywy rejestr czynności	Aktualizuj rejestr przy każdej nowej funkcji przetwarzającej dane osobowe, nie raz w roku.
Zgłoś naruszenie w 72 godziny	Miej gotowy playbook z przypisanymi rolami, żeby nie tracić czasu na ustalanie, kto działa.
Audytuj każdy SDK i API	Sprawdzaj, dokąd biblioteka wysyła dane, przed integracją, nie po wdrożeniu na produkcję.
Wdrażaj z audytem Studio201	Studio201 łączy audyt techniczny, DPIA i umowy powierzenia w jednym procesie przed wydaniem.

Spis treści

Role i odpowiedzialności: administrator, podmiot przetwarzający, IOD
Privacy by Design i Privacy by Default w architekturze aplikacji
Środki techniczne i organizacyjne z art. 32: lista kontrolna bezpieczeństwa
Rejestr czynności przetwarzania: co wpisać i jak go zorganizować
DPIA w aplikacji webowej: kiedy jest obowiązkowa i jak ją przeprowadzić
Umowy powierzenia i weryfikacja SDK: co musi się znaleźć w kontrakcie
Zgłaszanie naruszeń do PUODO: playbook krok po kroku
Realizacja praw osób: formularze, API i procesy w tle
Checklista wdrożeniowa Studio201 przed wydaniem funkcji
Plan działań na 30, 90 i 180 dni
Perspektywa autora: typowe pułapki i praktyczne rady
Audyt RODO i wsparcie wdrożeniowe od Studio201
Źródła

Role i odpowiedzialności: administrator, podmiot przetwarzający, IOD

Administrator danych to firma, która decyduje, po co i jak przetwarza dane. Podmiot przetwarzający, na przykład Studio201 realizujące projekt na zamówienie, przetwarza dane wyłącznie na polecenie administratora i na podstawie umowy powierzenia. To rozróżnienie ma konkretne konsekwencje dla zespołu deweloperskiego: administrator odpowiada za podstawę prawną przetwarzania, a wykonawca aplikacji za wdrożenie zabezpieczeń zgodnych z instrukcjami administratora.

Inspektora ochrony danych (IOD) trzeba wskazać, gdy główna działalność firmy polega na regularnym i systematycznym monitorowaniu osób w dużej skali albo na przetwarzaniu danych szczególnych kategorii. IOD nie projektuje kodu, ale powinien zatwierdzać decyzje wpływające na prywatność, jeszcze przed startem sprintu.

W praktyce współpraca między zespołami wygląda tak:

Dział prawny lub IOD definiuje wymogi i ryzyka na etapie specyfikacji.
Zespół deweloperski i DevOps wdrażają konkretne mechanizmy techniczne.
Product manager pilnuje, żeby wymogi prawne trafiły do backlogu jako zadania, nie jako notatka na marginesie.

Privacy by Design i Privacy by Default w architekturze aplikacji

Art. 25 RODO nie jest deklaracją intencji. To wymóg, żeby zabezpieczenia takie jak szyfrowanie, kontrola dostępu i pseudonimizacja były częścią architektury od pierwszego dnia projektu, nie łatką dodaną po testach penetracyjnych. Wytyczne EDPB podkreślają, że obowiązek ten dotyczy każdego administratora, niezależnie od wielkości firmy czy skali projektu.

W praktyce oznacza to konkretne decyzje projektowe, jeszcze przed napisaniem pierwszej linii kodu, zgodnie z zasadami projektowania stron internetowych.

Ogranicz zbierane pola do minimum. Jeśli formularz rejestracji nie potrzebuje numeru telefonu do działania funkcji, nie proś o niego „na wszelki wypadek”.
Oddziel identyfikatory od danych opisowych. Trzymaj dane wrażliwe i identyfikujące w osobnych tabelach lub mikroserwisach, żeby wyciek jednego zbioru nie odkrywał tożsamości użytkownika.
Zdecyduj, co zostaje na urządzeniu, a co trafia na serwer. Dane, które można przetwarzać lokalnie (np. wstępna walidacja formularza), nie powinny w ogóle wędrować do backendu.
Ustal domyślne ustawienia prywatności jako najbardziej restrykcyjne. Użytkownik musi świadomie włączyć udostępnianie danych, nigdy nie może być to ustawienie fabryczne.
Wpisz zadania „privacy” do definicji ukończenia (Definition of Done). Każda nowa funkcja przechodzi test: „czy zbieramy więcej danych, niż potrzeba do działania tej funkcji?”.

Porada profesjonalisty: Dodaj do szablonu user story osobne pole „wpływ na prywatność” — zespół wypełnia je obowiązkowo przed estymacją, nie po code review.

Takie podejście pasuje też do szerszych decyzji architektonicznych opisanych w kontekście skalowania rozwiązań webowych — im wcześniej ograniczysz zakres danych, tym łatwiej system rośnie bez narastającego długu związanego z prywatnością.

Środki techniczne i organizacyjne z art. 32: lista kontrolna bezpieczeństwa

Art. 32 RODO nie podaje zamkniętej listy zabezpieczeń, ale w praktyce dla aplikacji webowej i mobilnej sprawdza się konkretny zestaw mechanizmów. Poniższa lista to punkt wyjścia do audytu bezpieczeństwa, nie kompletna specyfikacja.

Szyfruj dane w tranzycie (TLS 1.2 lub wyżej) i w spoczynku, a klucze przechowuj w dedykowanym magazynie kluczy, nie w kodzie aplikacji.
Stosuj pinning certyfikatów w aplikacjach mobilnych, żeby ograniczyć ryzyko ataków typu man in the middle.
Wdróż uwierzytelnianie oparte na OAuth2 lub OIDC z krótkim czasem życia tokenów dostępu i bezpiecznym mechanizmem odświeżania.
Włącz dwuczynnikowe uwierzytelnianie (2FA) przynajmniej dla kont administracyjnych i uprzywilejowanych.
Prowadź logi audytowe operacji na danych osobowych i chroń je przed modyfikacją.
Wykonuj regularne backupy z testowanym procesem odtwarzania, nie tylko z samym zapisem kopii.
Włącz statyczną i dynamiczną analizę kodu (SAST/DAST) do procesu CI/CD, zanim funkcja trafi na produkcję.
Zamawiaj testy penetracyjne przed większymi wydaniami, zwłaszcza po zmianach w warstwie autoryzacji.

Dobre praktyki techniczne, takie jak regularne SAST/DAST i pentesty, realnie skracają czas wykrycia incydentu, co ułatwia dochowanie 72-godzinnego terminu zgłoszenia do organu nadzorczego, gdy coś już pójdzie nie tak.

Rejestr czynności przetwarzania: co wpisać i jak go zorganizować

Prowadzenie rejestru czynności przetwarzania wynika bezpośrednio z art. 30 RODO, a UODO opublikowało gotowe szablony, które warto wziąć jako punkt wyjścia, nie jako gotowy dokument do podpisania bez zmian.

Rejestr administratora i rejestr kategorii czynności przetwarzania to dwa różne dokumenty. Administrator opisuje wszystkie procesy, w których decyduje o celach i sposobach przetwarzania. Podmiot przetwarzający, na przykład firma realizująca aplikację na zlecenie, prowadzi rejestr kategorii czynności wykonywanych na polecenie administratora.

Poniższe pola powinny się znaleźć w każdym wpisie:

Cel przetwarzania i podstawa prawna (np. wykonanie umowy, zgoda, prawnie uzasadniony interes).
Kategorie danych osobowych i kategorie osób, których dane dotyczą.
Kategorie odbiorców, w tym dostawców zewnętrznych i procesorów.
Informacja o transferach danych poza Europejski Obszar Gospodarczy, jeśli występują.
Planowany okres przechowywania danych dla każdej kategorii.
Ogólny opis zastosowanych środków bezpieczeństwa.

Rejestr trzymaj w formacie, który można szybko wyeksportować i przedstawić UODO na żądanie, na przykład arkusz kalkulacyjny z kontrolą wersji albo dedykowany moduł w systemie wewnętrznym.

DPIA w aplikacji webowej: kiedy jest obowiązkowa i jak ją przeprowadzić

Ocena skutków dla ochrony danych staje się obowiązkowa, gdy funkcja aplikacji wiąże się z wysokim ryzykiem dla osób, których dane dotyczą. W praktyce dotyczy to najczęściej przetwarzania danych zdrowotnych, śledzenia lokalizacji w czasie rzeczywistym, profilowania użytkowników do celów marketingowych albo masowego monitorowania zachowań.

DPIA prowadzi się w czterech krokach:

Opisz proces przetwarzania: jakie dane, w jakim celu, jak długo, kto ma dostęp.
Oceń ryzyko dla praw i wolności osób, biorąc pod uwagę prawdopodobieństwo i skalę potencjalnej szkody.
Zaproponuj środki ograniczające ryzyko, na przykład dodatkową pseudonimizację albo ograniczenie retencji.
Zapisz wnioski w dokumencie DPIA i przypisz konkretne zadania do backlogu z terminem realizacji.

Rekomendacje z DPIA powinny mieć właściciela w zespole produktowym, inaczej zostają dokumentem, który nikt nie wdraża.

Umowy powierzenia i weryfikacja SDK: co musi się znaleźć w kontrakcie

Każdy dostawca zewnętrzny, który dotyka danych osobowych, czyli hosting, analityka, płatności czy SDK marketingowe, wymaga umowy powierzenia zgodnej z art. 28 RODO.

Umowa musi określać zakres i cel przetwarzania, czas trwania oraz kategorie danych i osób.
Musi zawierać prawo administratora do audytu u podmiotu przetwarzającego.
Musi regulować warunki podpowierzenia dalszym dostawcom, w tym wymóg zgody administratora.
Jeśli dane trafiają poza Europejski Obszar Gospodarczy, umowa musi wskazywać mechanizm transferu, na przykład standardowe klauzule umowne.

Kontrole prowadzone przez UODO w ostatnich latach coraz częściej koncentrują się na zabezpieczeniach danych przesyłanych do zewnętrznych systemów i na praktykach dostawców SDK. Warto trzymać się zasady minimalizacji SDK, czyli nie dodawać kolejnej biblioteki analitycznej tylko dlatego, że jest darmowa, oraz stosować restrykcyjne reguły CORS i ACL, żeby ograniczyć niekontrolowany dostęp do API. Więcej o bezpiecznym łączeniu systemów zewnętrznych znajdziesz w artykule o integracji API.

Porada profesjonalisty: Przed podpisaniem umowy z nowym dostawcą SDK poproś o dokument opisujący, jakie dane biblioteka wysyła i dokąd. Jeśli dostawca nie może na to szybko odpowiedzieć, to sam już jest sygnałem ostrzegawczym.

Ręce sprawdzające kabel sieciowy przy routerze

Zgłaszanie naruszeń do PUODO: playbook krok po kroku

Wykrycie incydentu to dopiero początek procedury. Zespół musi ocenić ryzyko, udokumentować przebieg zdarzenia i podjąć decyzję o zgłoszeniu w konkretnym oknie czasowym.

Wykryj i zabezpiecz. Odizoluj problem technicznie, zanim zaczniesz analizować przyczyny.
Oceń ryzyko dla osób. Sprawdź, jakie dane wyciekły i czy istnieje ryzyko naruszenia praw lub wolności.
Zgłoś do PUODO w ciągu 72 godzin od stwierdzenia naruszenia, jeśli ryzyko jest realne, zgodnie z wymogami dotyczącymi zgłaszania naruszeń.
Powiadom osoby, których dane dotyczą, jeśli ryzyko jest wysokie, używając zrozumiałego komunikatu bez żargonu prawnego.
Wdróż działania naprawcze i zaktualizuj dokumentację incydentu.

Zgłoszenie do organu nadzorczego musi zawierać charakter naruszenia, szacowaną liczbę osób i rekordów, konsekwencje oraz podjęte środki naprawcze. Brak jednego z tych elementów zwykle oznacza konieczność uzupełnienia zgłoszenia, co wydłuża cały proces.

Gotowy szablon komunikatu do użytkowników, przygotowany zanim wystąpi incydent, oszczędza godziny w sytuacji, gdy liczy się każda z nich.

Realizacja praw osób: formularze, API i procesy w tle

Prawa osób, których dane dotyczą, muszą działać w interfejsie, nie tylko istnieć w polityce prywatności. Formularz zgłoszenia żądania (dostęp, sprostowanie, usunięcie, przenoszalność) powinien mieć wbudowaną weryfikację tożsamości i widoczne dla użytkownika SLA odpowiedzi, zwykle do miesiąca.

Zapisuj każde żądanie i podjęte działanie w logu, który można pokazać podczas kontroli.
Zaplanuj automatyczną retencję danych, żeby usunięcie konta faktycznie kończyło się usunięciem danych, w tym z kopii zapasowych po ich rotacji.
Zasada rozliczalności wymaga dokumentu, nie tylko działania: zapisz, kto obsłużył żądanie, kiedy i jaką decyzję podjął.

Zgodność z platformowymi wymogami transparentności, na przykład deklarowaniem użycia danych w aplikacjach Android, ułatwia spełnienie obowiązku informacyjnego wobec użytkowników jednocześnie na dwóch frontach: prawnym i technicznym.

Checklista wdrożeniowa Studio201 przed wydaniem funkcji

Studio201 stosuje checklistę release’ową przed każdym większym wydaniem funkcji dotykającej danych osobowych:

Przegląd rejestru czynności przetwarzania pod kątem nowej funkcji.
Test SAST/DAST zintegrowany z pipeline CI/CD.
Pentest, jeśli zmiana dotyczy warstwy autoryzacji lub przechowywania danych.
Audyt każdego nowego SDK lub API pod kątem zakresu przesyłanych danych.
Weryfikacja, czy DPIA jest wymagana, i jej aktualizacja, jeśli funkcja zwiększa ryzyko.
Sprawdzenie, czy umowy powierzenia z dostawcami są aktualne.
Testy z użytkownikiem sprawdzające, czy formularze praw osób faktycznie działają.

Wypowiedź eksperta, Pawła Styperka, CEO Studio201: „Największym błędem, jaki widzimy w projektach, nie jest brak wiedzy o RODO, ale traktowanie zgodności jako dokumentu, a nie procesu wpisanego w cykl wydawniczy. Kiedy checklist bezpieczeństwa staje się naturalnym elementem release’u, a nie dodatkowym zadaniem na końcu, zespół przestaje się bać kontroli.”

Porada profesjonalisty: Jeśli Twój zespół nie ma jeszcze takiej checklisty, zacznij od trzech punktów: rejestr, SAST/DAST, audyt SDK. Resztę dobudujesz w kolejnych sprintach.

Jeśli potrzebujesz zewnętrznego audytu przed dużym wydaniem, warto skonsultować proces z zespołem, który regularnie przechodzi przez taki cykl w praktyce.

Plan działań na 30, 90 i 180 dni

Rozłożenie wdrożenia w czasie zapobiega przeciążeniu zespołu i pozwala śledzić postęp.

30 dni: uzupełnij rejestr czynności przetwarzania, wdróż podstawowe szyfrowanie i 2FA dla kont administracyjnych.
90 dni: przeprowadź DPIA dla funkcji wysokiego ryzyka, podpisz brakujące umowy powierzenia, zamów pierwszy pentest.
180 dni: wdróż pełny playbook incydentów, przetestuj go symulacją, zaktualizuj dokumentację rozliczalności.

Dowodem gotowości na kontrolę PUODO jest komplet: aktualny rejestr, raport z pentestu, podpisane umowy powierzenia i udokumentowana procedura zgłaszania naruszeń.

Perspektywa autora: typowe pułapki i praktyczne rady

Najczęściej widzę dwa błędy: rejestr czynności tworzony raz i nigdy niezaktualizowany, oraz SDK dodawane bez pytania, dokąd wysyłają dane. Oba wynikają z tego samego: zgodność traktowana jako projekt jednorazowy, nie jako część procesu wydawniczego.

RODO wdrożone dobrze nie jest tylko obowiązkiem prawnym. To przewaga rynkowa, bo klienci coraz częściej pytają o zabezpieczenia, zanim podpiszą umowę. Jaki błąd Twój zespół popełnia najczęściej? Napisz do nas, chętnie pomożemy go naprawić.

Audyt RODO i wsparcie wdrożeniowe od Studio201

Studio201 to alternatywa dla samodzielnego przeprowadzania audytu RODO metodą prób i błędów. Zamiast przechodzić przez cały proces od zera, dostajesz zespół, który już wcześniej łączył audyt logiki aplikacji, dokumentację i testy bezpieczeństwa w jednym projekcie.

Studio201

Zakres usługi obejmuje audyt istniejącej aplikacji, przeprowadzenie DPIA, implementację zabezpieczeń technicznych zgodnych z art. 32, przygotowanie umów powierzenia oraz testy penetracyjne przed wydaniem. Efekt to mniejsze ryzyko kary, gotowość na kontrolę PUODO i szybsze wydania nowych funkcji bez odkładania zgodności na później. To podejście sprawdza się szczególnie tam, gdzie prototyp budowany szybko, na przykład z użyciem narzędzi AI, wymaga domknięcia bezpieczeństwa przed trafieniem na produkcję, co opisujemy też w kontekście wdrażania rozwiązań AI w rozwoju oprogramowania.

Sprawdź szczegóły oferty na Studio201 i napisz do nas, żeby zaplanować audyt zgodności dla Twojej aplikacji.

Audyt RODO i wsparcie wdrożeniowe od Studio201 — overview diagram

Źródła

Warto trzymać w zakładkach kilka dokumentów podczas audytu. UODO publikuje poradniki i szablony rejestrów przydatne przy dokumentacji. EDPB wydało szczegółowe wytyczne dotyczące Privacy by Design, a Android Developers opisuje zasady deklarowania użycia danych w aplikacjach mobilnych. Każdy z nich pomaga wypełnić inną część obowiązku rozliczalności.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

RODO w aplikacjach webowych: przewodnik dla zespołów IT