Audyt RODO w 2026 r.: jak sprawdzić zgodność, a nie tylko dokumentację

Rozliczalność jako podstawowa zasada audytu

Art. 5 ust. 2 RODO wprowadza zasadę rozliczalności: administrator odpowiada za przestrzeganie zasad przetwarzania i musi być w stanie to wykazać. Art. 24 wymaga wdrożenia odpowiednich środków technicznych i organizacyjnych, ich przeglądu oraz aktualizacji, gdy jest to potrzebne.^[1] Audyt jest jednym ze sposobów zdobywania dowodów, ale pozytywny raport nie tworzy zgodności sam z siebie.

Nie istnieje jeden uniwersalny "certyfikat zgodności z RODO". Mechanizmy certyfikacji z art. 42 są dobrowolne i nie ograniczają odpowiedzialności administratora ani podmiotu przetwarzającego. Również audyt powinien jasno określać zakres: wniosek dotyczący procesu rekrutacji nie mówi nic o zgodności monitoringu, marketingu czy systemu medycznego, jeśli ich nie zbadano.

W dobrym raporcie warto rozdzielić co najmniej cztery rodzaje problemów:

• naruszenie konkretnego obowiązku prawnego, na przykład brak podstawy przetwarzania albo niewykonanie obowiązku informacyjnego;
• ryzyko dla praw i wolności osób, na przykład nadmiernie szeroki dostęp do danych wrażliwych;
• słabość zabezpieczenia, na przykład konto administracyjne bez odpowiedniej ochrony;
• brak dowodu skuteczności, gdy organizacja deklaruje środek, ale nie ma testu, zapisu, właściciela ani wyniku pozwalającego go zweryfikować.

Najpierw mapa przetwarzania

Audyt powinien zacząć się od rzeczywistej mapy procesów, systemów, zbiorów, przepływów i odbiorców danych. Rejestr czynności przetwarzania z art. 30 jest ważnym źródłem, lecz nie powinien być traktowany jako automatycznie prawdziwy opis organizacji. Audytor porównuje go z konfiguracją aplikacji, umowami, logami, formularzami, kontami, integracjami, kopiami roboczymi i praktyką pracowników.

Trzeba także prawidłowo przypisać role. Administrator określa cele i sposoby przetwarzania. Podmiot przetwarzający przetwarza dane w imieniu administratora. Współadministratorzy wspólnie ustalają cele i sposoby w zakresie objętym wspólną decyzją. Sama etykieta wpisana do umowy nie przesądza roli, jeśli fakty pokazują coś innego.^[3]

Wyjątek z art. 30 dla podmiotów zatrudniających mniej niż 250 osób jest wąski. Nie działa, gdy przetwarzanie może powodować ryzyko, nie ma charakteru sporadycznego albo obejmuje szczególne kategorie danych lub dane o wyrokach skazujących i naruszeniach prawa. Stałe procesy kadrowe, obsługa klientów lub użytkowników zwykle wymagają więc bardziej szczegółowej oceny niż proste powołanie się na liczbę pracowników.

Cele, podstawy prawne i zasady z art. 5

Każdy cel przetwarzania powinien mieć właściwą podstawę z art. 6. Zgoda jest tylko jedną z możliwych podstaw i nie należy wybierać jej automatycznie. Dla szczególnych kategorii danych trzeba dodatkowo znaleźć właściwą przesłankę z art. 9. Audyt prowadzi tę analizę dla konkretnych operacji i celów, a nie dla całego systemu jednym zdaniem.^[1]

Równolegle bada się zasady z art. 5: zgodność z prawem, rzetelność i przejrzystość, ograniczenie celu, minimalizację, prawidłowość, ograniczenie przechowywania oraz integralność i poufność. Przykładowo pole z datą urodzenia może być uzasadnione w jednym procesie, a nieproporcjonalne w zwykłym formularzu kontaktowym.

Retencja również nie powinna być jedną liczbą dla całej organizacji. Trzeba powiązać ją z celem, przepisami szczególnymi, roszczeniami i zdarzeniem rozpoczynającym bieg okresu przechowywania. Zapis "dane przechowujemy przez 5 lat" bez wskazania, od czego liczony jest ten okres, nie jest regułą retencji, lecz jej pozorem.

Privacy by design i privacy by default

Art. 25 wymaga ochrony danych w fazie projektowania oraz domyślnej ochrony danych.^[1] Audyt powinien więc sprawdzić proces zmian i zakupów: czy przed uruchomieniem nowego systemu ktoś ocenia cel, zakres danych, uprawnienia, retencję, interfejsy, logowanie, dostawców, transfery i ryzyko.

Domyślna konfiguracja ma ograniczać przetwarzanie do tego, co potrzebne w danym celu. Nie oznacza to jednej obowiązkowej konfiguracji dla wszystkich systemów. Chodzi o świadomy projekt, w którym użytkownik nie musi sam wyłączać nadmiarowego zbierania albo publikowania danych. Jeżeli w organizacji nie istnieje moment, w którym ktoś zadaje te pytania przed wdrożeniem, art. 25 pozostaje deklaracją w polityce.

Prawa osób: procedura musi działać w systemach

Audyt wykonywania praw nie kończy się na instrukcji. Najlepszym testem jest przejście przez rzeczywiste lub kontrolowane żądanie: od identyfikacji osoby, przez wyszukanie danych w systemach i u podmiotów przetwarzających, po decyzję, przygotowanie odpowiedzi i zachowanie dowodu terminu.

Co do zasady administrator odpowiada bez zbędnej zwłoki, najpóźniej w ciągu miesiąca. Termin może zostać przedłużony o dwa kolejne miesiące ze względu na złożony charakter żądania lub liczbę żądań, ale osoba musi zostać poinformowana o przedłużeniu i jego przyczynach w ciągu pierwszego miesiąca.^[1]

Prawo dostępu nie oznacza automatycznie obowiązku wydania każdego dokumentu w jego pierwotnej formie. Administrator ma przekazać kopię danych osobowych podlegających przetwarzaniu w sposób pozwalający osobie skutecznie korzystać z praw, z uwzględnieniem praw i wolności innych osób. Orzecznictwo TSUE doprecyzowuje znaczenie pojęcia kopii oraz obowiązek zapewnienia wiernego i zrozumiałego odwzorowania danych.^[4]

Dostawcy, podmioty przetwarzające i shadow IT

Umowa z art. 28 jest potrzebna wtedy, gdy dostawca przetwarza dane w imieniu administratora. Audyt sprawdza nie tylko, czy dokument istnieje, ale czy odpowiada rzeczywistej usłudze: przedmiot i czas przetwarzania, cel, kategorie danych i osób, poufność, bezpieczeństwo, podprocesorów, pomoc przy prawach i naruszeniach, zwrot lub usunięcie danych oraz możliwość audytu.^[1]

Lista dostawców powinna obejmować również narzędzia uruchamiane samodzielnie przez działy i pracowników: darmowe aplikacje, konta testowe, integracje OAuth, usługi analityczne, systemy ticketowe, repozytoria, narzędzia do transkrypcji i generatywnej AI. Sam napis "GDPR compliant" na stronie producenta nie jest dowodem, że konkretne użycie przez organizację jest zgodne.

Komisja Europejska opublikowała standardowe klauzule administrator-podmiot przetwarzający dla art. 28.^[5] Nie należy mylić ich ze standardowymi klauzulami umownymi używanymi jako jeden z mechanizmów transferu do państw trzecich na podstawie rozdziału V.^[6] To dwa różne dokumenty o różnym przeznaczeniu i regularnie występuje ich zamiana w dokumentacji.

Art. 32: bezpieczeństwo adekwatne do ryzyka

RODO nie narzuca jednej listy produktów bezpieczeństwa. Administrator i podmiot przetwarzający uwzględniają stan wiedzy technicznej, koszt wdrożenia, charakter, zakres, kontekst i cele przetwarzania oraz ryzyko dla praw i wolności osób. Pseudonimizacja, szyfrowanie, zdolność do zapewnienia poufności, integralności, dostępności i odporności, odtwarzanie dostępności oraz regularne testowanie i ocenianie skuteczności są środkami wskazanymi w art. 32, ale ich dobór ma być oparty na ryzyku.^[1]

Audyt techniczny może obejmować:

• zarządzanie tożsamością i cyklem życia kont;
• dostęp uprzywilejowany i uwierzytelnianie wieloskładnikowe tam, gdzie jest uzasadnione;
• szyfrowanie transmisji i danych oraz zarządzanie kluczami;
• kopie zapasowe, odtwarzanie i odporność;
• aktualizacje, zarządzanie podatnościami i hardening;
• segmentację i ograniczanie ruchu;
• rejestrowanie zdarzeń i wykrywanie incydentów;
• ochronę stacji roboczych, urządzeń mobilnych i poczty;
• bezpieczeństwo dostawców i dostępów zdalnych;
• bezpieczne usuwanie danych i nośników.

Szyfrowanie nie naprawia nadmiernego zbierania danych ani nadużycia przez użytkownika mającego prawidłowe uprawnienia. Kopia zapasowa nie dowodzi odporności, jeśli nikt nie potrafi jej odtworzyć. Z tego powodu w audycie ważniejszy jest dowód działania niż nazwa zakupionego narzędzia.

Art. 32 nie ustanawia obowiązkowego corocznego pentestu ani skanowania w jednym interwale dla wszystkich organizacji. Wymaga regularnego testowania, mierzenia i oceniania skuteczności odpowiednio do ryzyka. Częstotliwość trzeba więc uzasadnić charakterem systemu, zmianami, historią incydentów, ekspozycją oraz innymi mającymi zastosowanie regulacjami.

Naruszenia ochrony danych

Nie każdy incydent cyberbezpieczeństwa jest naruszeniem ochrony danych osobowych i nie każde naruszenie trzeba zgłaszać Prezesowi UODO. Najpierw trzeba ustalić, czy doszło do naruszenia bezpieczeństwa prowadzącego do przypadkowego lub niezgodnego z prawem zniszczenia, utraty, zmodyfikowania, nieuprawnionego ujawnienia albo dostępu do danych osobowych. Następnie administrator ocenia ryzyko dla praw i wolności osób.^[1]

Jeżeli naruszenie może powodować ryzyko, zgłoszenie do organu nadzorczego następuje bez zbędnej zwłoki, w miarę możliwości nie później niż 72 godziny po stwierdzeniu naruszenia. Jeżeli ryzyko jest wysokie, może powstać także obowiązek zawiadomienia osób. Podmiot przetwarzający zawiadamia administratora bez zbędnej zwłoki po stwierdzeniu naruszenia.

Audyt powinien zbadać próbę incydentów, również tych niezgłoszonych organowi. Najważniejszym dowodem jest udokumentowane rozumowanie: co się wydarzyło, jakie dane i osoby objęto, jakie zabezpieczenia działały, jak oceniono prawdopodobieństwo i wagę skutków oraz kto zatwierdził decyzję. Brak zgłoszenia jest w porządku, jeśli da się go uzasadnić; problemem jest brak śladu decyzji.

DPIA: kiedy trzeba ocenić wysokie ryzyko

Ocena skutków dla ochrony danych jest wymagana, gdy dany rodzaj przetwarzania, w szczególności z użyciem nowych technologii, może powodować wysokie ryzyko dla praw i wolności osób. Art. 35 wskazuje przykłady, a organ nadzorczy publikuje wykaz rodzajów operacji wymagających DPIA.^[1][7]

Audyt nie powinien pytać wyłącznie "czy jest DPIA". Trzeba sprawdzić, czy organizacja ma mechanizm rozpoznawania projektów, które jej wymagają, czy ocena została wykonana przed rozpoczęciem ryzykownego przetwarzania, czy uwzględnia środki ograniczające ryzyko i czy jest aktualizowana, gdy zmienia się ryzyko.

Monitoring pracowników, profilowanie, dane biometryczne, nowe systemy analityczne czy rozwiązania AI mogą zwiększać prawdopodobieństwo wysokiego ryzyka, ale nie każda implementacja automatycznie wymaga DPIA. Decydują konkretne cechy procesu i kryteria z art. 35 oraz właściwych wytycznych.

Transfery poza EOG

Najczęstszy błąd audytowy polega na utożsamieniu lokalizacji serwera z brakiem transferu. Dane mogą być przechowywane we Frankfurcie, a jednocześnie dostęp administracyjny, wsparcie, telemetryka, kopia zapasowa albo podprocesor może znajdować się poza EOG. Trzeba przeanalizować cały łańcuch przetwarzania.

Transfer może opierać się między innymi na decyzji stwierdzającej odpowiedni stopień ochrony albo na odpowiednich zabezpieczeniach, takich jak standardowe klauzule umowne.^[6] Po wyroku Schrems II samo podpisanie klauzul nie kończy analizy: eksporter powinien ocenić, czy w konkretnych okolicznościach można zapewnić poziom ochrony zasadniczo równoważny, i w razie potrzeby zastosować środki uzupełniające. EROD wydała w tym zakresie szczegółowe rekomendacje.^[8][9]

EU-US Data Privacy Framework nadal jest 29 sierpnia 2026 r. podstawą transferu do amerykańskich organizacji, które rzeczywiście uczestniczą w tym programie i są objęte właściwym zakresem certyfikacji. Decyzja Komisji z 2023 r. nie obejmuje automatycznie każdej firmy w USA.^[10]

W 2025 r. Sąd UE oddalił skargę w sprawie T-553/23 Latombe przeciwko Komisji. Od tego wyroku wniesiono jednak odwołanie C-703/25 P, które 29 sierpnia 2026 r. pozostaje w toku.^[11] Audyt powinien zatem opisywać ten mechanizm jako obowiązujący, a nie jako ostatecznie potwierdzony na zawsze.

RODO i sztuczna inteligencja

Wdrożenie generatywnej AI tworzy kilka równoległych pytań: czy istnieje podstawa do przekazania danych do modelu, czy zakres danych jest minimalny, kto jest administratorem lub podmiotem przetwarzającym, gdzie dane trafiają, czy są używane do dalszego trenowania, jaki jest okres retencji, kto ma dostęp do historii i jak realizuje się prawa osób.

EROD w opinii 28/2024 dotyczącej modeli AI wskazała między innymi, że anonimowość modelu musi być oceniana indywidualnie, a możliwość oparcia przetwarzania na prawnie uzasadnionym interesie wymaga pełnego testu niezbędności i równowagi. Opinia omawia również wpływ niezgodnego z prawem wykorzystania danych na późniejsze operacje z modelem.^[12]

AI Act nie zastępuje RODO. Oba akty mogą mieć zastosowanie równolegle do tego samego systemu. W 2026 r. zmieniono część harmonogramu: wymagania z sekcji 1-3 rozdziału III dla systemów wysokiego ryzyka z art. 6 ust. 2 i załącznika III mają być stosowane od 2 grudnia 2027 r., a dla systemów z art. 6 ust. 1 i załącznika I od 2 sierpnia 2028 r. Obowiązek zapewnienia odpowiedniego poziomu kompetencji w zakresie AI z art. 4 należy natomiast do rozdziału I i stosuje się od 2 lutego 2025 r.^[13][14]

IOD: niezależność i konflikt interesów

Inspektor ochrony danych może wykonywać inne zadania, jeśli nie prowadzą one do konfliktu interesów. Audyt powinien zbadać rzeczywistą pozycję IOD: dostęp do najwyższego kierownictwa, wczesne angażowanie w projekty, zasoby, możliwość działania niezależnie oraz to, czy inne funkcje nie wymagają od niego określania celów i sposobów przetwarzania, które później ma kontrolować.^[1][15]

Brak konfliktu nie wynika z nazwy stanowiska. Osoba, która samodzielnie decyduje o architekturze i celach systemu przetwarzającego dane, może znaleźć się w konflikcie, jeśli równocześnie ma niezależnie nadzorować zgodność tego samego rozwiązania.

ISO/IEC 27701:2025

ISO/IEC 27701:2025 jest aktualnym wydaniem normy dotyczącej systemu zarządzania informacjami o prywatności i zastąpiła wydanie z 2019 r. Może pomóc organizacji uporządkować role, ryzyka, procesy i dowody dotyczące prywatności, ale norma nie jest polskim prawem, a certyfikacja nie zastępuje analizy zgodności z RODO.^[16]

Praktycznie najwięcej daje potraktowanie jej jako szkieletu dokumentacyjnego dla SZBI rozszerzonego o prywatność, a nie jako zamiennika oceny prawnej konkretnych operacji przetwarzania.

Jak prowadzić audyt oparty na dowodach

Dla każdego obszaru warto stosować prostą triangulację:

1. Co organizacja deklaruje w polityce, rejestrze albo umowie?
2. Co pokazuje konfiguracja systemu, log, formularz, rekord bazy albo próbka spraw?
3. Co robi pracownik, właściciel procesu i dostawca w rzeczywistej sytuacji?

Jeżeli te trzy obrazy się różnią, audyt znalazł ważniejszy problem niż brak kolejnego dokumentu.

Przykładowe próby audytowe obejmują nowo zatrudnionych i osoby, które zakończyły pracę, wraz z nadaniem i odebraniem dostępów; żądania osób i terminy ich obsługi; przypadki usunięcia danych po upływie retencji; zgody i dowody ich wycofania; umowy z podmiotami przetwarzającymi oraz ich podprocesorów; transfery zdalnego wsparcia poza EOG; incydenty i decyzje o zgłoszeniu lub niezgłoszeniu; testy odtworzenia kopii zapasowej; nowe projekty IT i decyzje o DPIA; wykorzystanie narzędzi generatywnej AI przez pracowników.

W audytach 4crypto część prawna może być połączona z techniczną weryfikacją konfiguracji, bezpieczeństwa poczty, hardeningu, podatności i logowania. Warunkiem jest jednak zachowanie osobnych kryteriów: brak technicznej podatności nie dowodzi zgodności z zasadą minimalizacji, a kompletna klauzula informacyjna nie dowodzi skutecznego uwierzytelniania.

Najczęstsze błędy

1. Audyt wyłącznie dokumentów. RODO dotyczy rzeczywistego przetwarzania, a nie segregatora.
2. Traktowanie zgody jako podstawy domyślnej. Często właściwą podstawą jest umowa, obowiązek prawny, zadanie publiczne albo prawnie uzasadniony interes, zależnie od procesu.
3. Przechowywanie danych "na wszelki wypadek" bez reguł retencji i mechanizmu usuwania.
4. Przyjmowanie deklaracji dostawcy o zgodności jako substytutu oceny roli, umowy, bezpieczeństwa i transferów.
5. Utożsamianie centrum danych w UE z brakiem transferu poza EOG.
6. Wykonywanie DPIA po uruchomieniu systemu tylko po to, aby uzupełnić teczkę projektu.
7. Przekonanie, że wersja enterprise usługi AI rozwiązuje sama podstawę prawną, minimalizację, retencję i obowiązki informacyjne. Może poprawić warunki bezpieczeństwa i przetwarzania, ale nie usuwa obowiązków administratora.

Co powinien zawierać raport

Raport powinien wskazywać:

• zakres podmiotowy, procesowy i systemowy;
• kryteria i datę stanu prawnego;
• wykorzystane rodzaje dowodów i sposób doboru próby;
• ustalenia powiązane z konkretnym przepisem;
• oddzielnie ryzyko dla osób i słabości bezpieczeństwa;
• zalecenia możliwe do wykonania oraz ich właścicieli;
• termin i dowód potrzebny do zamknięcia ustalenia;
• ograniczenia badania, w tym brak dostępu do systemu lub niewystarczające dane.

Raport nie powinien obiecywać "100% zgodności" w oderwaniu od zakresu i czasu. Przetwarzanie zmienia się wraz z systemami, dostawcami, personelem i celami. Audyt jest zdjęciem stanu oraz testem mechanizmu zarządzania, a nie trwałą gwarancją.