Zaproponowany do konsultacji (konsultacje mają trwać do 9 czerwca 2026 r.) przez Europejską Radę Ochrony Danych (EROD/EDPB) szablon oceny skutków dla ochrony danych (DPIA) z dnia 10 marca 2026 r. ma służyć jako ujednolicony format wprowadzania danych, dokumentowania i raportowania wyników DPIA. Jego deklarowanym celem jest zapewnienie struktury, oszczędność czasu oraz ułatwienie akceptacji dokumentu przez wszystkie organy nadzorcze (PUODO) w UE.

Szablon (obejmujący także plik objaśnień - template explainer) składa się z następujących głównych sekcji:

• Sekcja 0: Przegląd przetwarzania – identyfikacja administratora, współadministratorów, podmiotów przetwarzających, planowany czas trwania oraz przyczyny przeprowadzenia DPIA.
• Sekcja 1: Systematyczny opis przetwarzania – szczegółowe określenie kategorii danych, celów, charakteru, kontekstu oraz architektury technicznej i przepływu danych (cyklu życia danych).
• Sekcja 2: Analiza przetwarzania – ocena podstaw prawnych, minimalizacji danych, okresów retencji, jakości danych oraz wdrożonych środków wspierających realizację praw osób, których dane dotyczą.
• Sekcja 3: Niezbędność i proporcjonalność – ocena, czy przetwarzanie jest skuteczne i najmniej inwazyjne z punktu widzenia praw i wolności obywateli.
• Sekcja 4: Ocena i zarządzanie ryzykiem – analiza podatności, zagrożeń wynikających zarówno z samej konstrukcji systemu, jak i zdarzeń losowych/ataków, ocena ryzyka inherentnego oraz rezydualnego po zastosowaniu dodatkowych zabezpieczeń.
• Sekcja 5: Zaangażowanie stron – udokumentowanie opinii inspektora ochrony danych (IOD/DPO) oraz ewentualnych konsultacji z osobami, których dane dotyczą.
• Sekcja 6: Wnioski i decyzja – ostateczne rozstrzygnięcie dotyczące dopuszczalności przetwarzania (zatwierdzenie, warunkowe zatwierdzenie, odrzucenie lub konieczność konsultacji z organem nadzorczym).

Odzwierciedlenie przepisów

Szablon EROD w swoim fundamencie odzwierciedla minimalne wymagania stawiane przez art. 35 ust. 7 RODO oraz wymagania dotyczące uprzednich konsultacji z art. 36 RODO:

• art. 35 ust. 7 lit. a (systematyczny opis planowanych operacji i celów przetwarzania): sekcja 1 szablonu wprost realizuje ten wymóg, nakazując opisanie operacji, celów oraz prawnie uzasadnionych interesów;
• art. 35 ust. 7 lit. b (ocena niezbędności i proporcjonalności): sekcja 3 szablonu jest bezpośrednią realizacją tego przepisu, wymagając przedstawienia dowodów na to, że cele nie mogą być osiągnięte w inny, mniej inwazyjny sposób;
• art. 35 ust. 7 lit. c (ocena ryzyka naruszenia praw lub wolności osób, których dane dotyczą): sekcja 4.1 szablonu pokrywa ten obowiązek poprzez identyfikację źródeł ryzyka i potencjalnych negatywnych skutków dla osób fizycznych;
• art. 35 ust. 7 lit. d (środki planowane w celu zaradzenia ryzyku): sekcja 2.3 (środki wspierające zgodność) oraz sekcja 4.2 (plan działania i dodatkowe środki łagodzące) bezpośrednio realizują wymóg wykazania zabezpieczeń i mechanizmów bezpieczeństwa;
• konsultacje z IOD (art. 35 ust. 2): Sekcja 5.1 wymaga podania opinii i rekomendacji inspektora ochrony danych oraz sposobu ich wdrożenia przez administratora;
• opinia osób, których dane dotyczą (art. 35 ust. 9): sekcja 5.2 implementuje ten przepis, dając przestrzeń na udokumentowanie głosu przedstawicieli lub samych osób fizycznych (bądź wyjaśnienie, dlaczego takich konsultacji nie przeprowadzono);
• uprzednie konsultacje z organem nadzorczym (art. 36 ust. 1): końcowa sekcja 6 (decyzja) przewiduje wariant skierowania sprawy do urzędu, jeśli ryzyko rezydualne pozostaje wysokie, co jest odwzorowaniem procedury z art. 36.

Dobre praktyki (soft law)

Choć EROD zaznacza, że dokument ma charakter pomocniczy i nie narzuca jednej metodologii, to sama struktura szablonu nakłada na administratorów obowiązki dokumentacyjne i analityczne, których przepisy RODO wprost nie wymagają. Mamy tu więc do czynienia z rozszerzeniem standardu prawnego w kierunku dobrych praktyk zarządczych:

• zarządzanie zespołem i macierz RACI (Sekcja 0.5): szablon wymaga zidentyfikowania zespołu przeprowadzającego DPIA i sugeruje użycie formalnej macierzy RACI (odpowiedzialny, rozliczany, konsultowany, informowany). RODO w art. 35 nie nakłada obowiązku formalnego mapowania ról projektowych w zespole ds. DPIA;
• metryki i progi jakości danych (Sekcja 2.2.2): EROD wymaga zdefiniowania konkretnych "metryk jakości danych, wymagań lub progów". RODO w art. 5 ust. 1 lit. d mówi jedynie o zasadzie prawidłowości danych (ich uaktualnianiu), jednak żądanie liczbowych lub technicznych mierników jakości wykracza poza literalny tekst ustawy;
• szczegółowa inwentaryzacja aktywów wspierających (Sekcja 1.3): szablon wymaga stworzenia rejestru/inwentarza "istotnych aktywów wspierających" (tangible and intangible assets) takich jak konkretne bazy danych, sprzęt, API, personel, a nawet lokalizacje fizyczne (serwerownie). RODO wymaga "systematycznego opisu planowanych operacji" – rozbijanie opisu na warstwy technologiczne i mapowanie podatności każdego zasobu z osobna to standard zapożyczony z norm ISO (np. ISO 27005) czy francuskiej metodologii EBIOS, a nie bezpośredni wymóg RODO;
• podział na ryzyko strukturalne i anomalie: EROD rozbija analizę ryzyka na dwa zupełnie osobne procesy:

1. ryzyko wynikające z samej, prawidłowej i zgodnej z założeniami konstrukcji systemu (wszystko działa jak zaprojektowano, ale sam cel generuje zagrożenia – Sekcja 3.1);
2. ryzyko wynikające z awarii, błędów software'owych, konfiguracji lub ataków (anomalie i odchylenia – Sekcja 4.1.1). RODO w art. 35 ust. 7 lit. c mówi ogólnie o „ocenie ryzyka”. Tak głęboka konceptualizacja i separacja typów ryzyka jest zdecydowanie (nad)interpretacją rozszerzającą ze strony EROD.

• zarządzanie wersjami (wersjonowanie dokumentu): wymóg prowadzenia szczegółowej historii zmian (logu wersji) dla samej dokumentacji DPIA w celu zapewnienia mierzalności (Sekcja 0.5);
• deklaracja intencji publikacji (Sekcja 0.5): szablon wymaga jednoznacznego zadeklarowania, czy i w jakiej części DPIA zostanie opublikowane lub udostępnione zewnętrznie. Przepisy RODO nie nakazują publikacji dokumentu DPIA, ani formalnego raportowania o intencji jego upublicznienia.

Podsumowanie

Propozycja EROD to niewątpliwie przydatne narzędzie standaryzujące, które w warstwie merytorycznej zarówno odzwierciedla przepisy RODO, jak i obudowuje je wymaganiami o charakterze techniczno-zarządczym (zaczerpniętymi z norm bezpieczeństwa informacji). Dla administratorów oznacza to, że wypełnienie szablonu zgodnie z projektem EROD (po przyjęciu jego wersji ostatecznej) gwarantuje pełną zgodność prawną, ale wymaga włożenia znacznie większego wysiłku analitycznego, niż wynikałoby to z samej, ogólnej lektury artykułu 35 RODO.