RODO w praktyce IT: techniczne środki ochrony

RODO celowo nie zawiera listy wymaganych technologii — art. 32 mówi o środkach „odpowiednich” do ryzyka, uwzględniających stan wiedzy technicznej i koszty. Ta elastyczność bywa wygodna dla prawników, ale zostawia zespoły IT z pytaniem: co konkretnie mamy wdrożyć? Odpowiedź istnieje — składa się z orzecznictwa, kar UODO i europejskich organów, wytycznych EDPB oraz zdrowej praktyki bezpieczeństwa. Poniżej tłumaczymy ją na listę kontrolną.

Jak czytać art. 32: ryzyko, nie rytuał

Przepis wymienia wprost cztery kierunki: pseudonimizację i szyfrowanie, zdolność do zapewnienia poufności, integralności, dostępności i odporności systemów, zdolność szybkiego przywrócenia dostępności po incydencie oraz regularne testowanie i ocenę skuteczności środków. Klucz interpretacyjny: środki dobierasz do ryzyka dla osób, których dane dotyczą — nie dla firmy. Baza 100 tys. klientów z danymi finansowymi wymaga więcej niż lista mailingowa newslettera; ten sam sklep internetowy potrzebuje innych środków dla bazy zamówień niż dla systemu rekrutacji.

Praktyczna konsekwencja: zanim cokolwiek wdrożysz, potrzebujesz mapy przetwarzań (RCP zwykle już istnieje u IOD-a) połączonej z mapą systemów — które aplikacje, bazy i dyski trzymają jakie kategorie danych. Bez tego „odpowiedniość” środków jest zgadywaniem.

Lista kontrolna: 8 obszarów, o które zapyta UODO

1. Kontrola dostępu. Dostęp do danych osobowych na zasadzie niezbędnej wiedzy: konta imienne, role zamiast uprawnień „do wszystkiego”, przegląd uprawnień co kwartał, natychmiastowy off-boarding. MFA dla dostępu do systemów z danymi — po serii kar europejskich organów za przejęte konta bez MFA trudno dziś bronić jego braku „stanem wiedzy technicznej”.

2. Szyfrowanie. W spoczynku: pełne szyfrowanie dysków laptopów (zgubiony zaszyfrowany laptop to incydent bez obowiązku zawiadamiania osób — niezaszyfrowany potrafi skończyć się karą), szyfrowanie baz/kopii zapasowych. W tranzycie: TLS wszędzie, także wewnętrznie. Do tego zarządzanie kluczami — szyfrowanie kluczem leżącym obok danych to teatr.

3. Pseudonimizacja i minimalizacja. Środowiska testowe i deweloperskie bez produkcyjnych danych osobowych (to częsty punkt kar!) — anonimizacja lub dane syntetyczne. W analityce: identyfikatory zamiast danych wprost. Retencja wdrożona technicznie: automatyczne usuwanie/anonimizacja po upływie okresów, nie „polityka w segregatorze”.

4. Logowanie i rozliczalność. Kto, kiedy, do czyich danych sięgał — szczególnie w systemach kadrowych, medycznych, finansowych. Logi chronione przed modyfikacją, przechowywane z ustaloną retencją i faktycznie przeglądane (monitoring) — przy incydencie to one decydują, czy umiesz określić zakres naruszenia w 72 godziny.

5. Dostępność i odtwarzalność. Ransomware szyfrujący dane osobowe to naruszenie ich dostępności — czyli naruszenie RODO, nawet bez wycieku. Stąd wymóg kopii zapasowych z testami odtwarzania i planu ciągłości. „Szybkie przywrócenie dostępności” z art. 32 to properly przetestowane RTO, nie deklaracja.

6. Regularne testowanie. RODO wprost każe „regularnie testować, mierzyć i oceniać skuteczność” środków. W praktyce: skany podatności w rytmie ciągłym, testy penetracyjne okresowo dla systemów z danymi, audyty konfiguracji. Raport z testu to jednocześnie dowód zgodności — organy pytają o niego po incydentach.

7. Dostawcy (art. 28). Każdy podmiot przetwarzający dane w Twoim imieniu — hosting, SaaS, agencja, serwis IT — wymaga umowy powierzenia i weryfikacji, że sam spełnia art. 32. To ta sama praca co TPRM, tylko z sankcją prawną.

8. Domyślna ochrona (privacy by design/default). Nowe projekty i zmiany przechodzą przez pytania o dane już na etapie projektowania: czy musimy je zbierać, jak długo trzymać, kto będzie miał dostęp. Dla przetwarzań wysokiego ryzyka — DPIA przed startem (dotyczy to też wdrożeń AI).

Czego uczą kary

Wzorce z decyzji UODO i organów europejskich powtarzają się na tyle konsekwentnie, że działają jak nieoficjalna lista wymagań: brak MFA przy zdalnym dostępie do danych, brak szyfrowania nośników, dane produkcyjne w środowiskach testowych, brak testów bezpieczeństwa mimo deklarowania ich w politykach, zbyt szerokie uprawnienia i brak przeglądów, wreszcie — brak zdolności wykazania, że środki działały (brak logów, dokumentacji, wyników testów). Ten ostatni punkt jest kluczowy: zasada rozliczalności oznacza, że środki niezdokumentowane traktowane są jak nieistniejące.

Jak to poukładać: plan minimum

1. Zmapuj systemy przetwarzające dane osobowe i sklasyfikuj je po ryzyku (wolumen, kategorie danych, skutki naruszenia dla osób).
2. Dla systemów wysokiego ryzyka zamknij ósemkę wyżej w pierwszej kolejności; dla pozostałych — wersję proporcjonalną.
3. Udokumentuj stan: polityki + dowody techniczne (zrzuty konfiguracji, raporty testów, logi przeglądów uprawnień).
4. Przećwicz scenariusz naruszenia z zegarem 72 h — opisaliśmy go krok po kroku.
5. Powtarzaj testy i przeglądy w stałym rytmie; zmiany w systemach uruchamiają przegląd środków.

Najczęstsze pytania (FAQ)

Czy RODO wymaga konkretnie testów penetracyjnych? Nie wymienia ich z nazwy — wymaga „regularnego testowania i oceny skuteczności środków”. W praktyce dla systemów przetwarzających istotne dane trudno ten wymóg spełnić bez testów bezpieczeństwa, a organy po incydentach pytają wprost o ich wyniki. Test penetracyjny to najmocniejszy pojedynczy dowód, że środki działają — pomagamy go przeprowadzić wraz z raportem przydatnym dla IOD-a.

Mamy ISO 27001 — czy to załatwia art. 32? Bardzo pomaga (pokrywa systemowe zarządzanie ryzykiem i większość środków), ale nie zwalnia z myślenia: ISO chroni informacje organizacji, RODO — prawa osób. Trzeba zweryfikować, czy zakres certyfikacji obejmuje systemy z danymi osobowymi i czy analiza ryzyka uwzględnia perspektywę podmiotów danych.

Czy szyfrowanie jest obowiązkowe? Formalnie jest środkiem „przykładowym”, praktycznie — standardem oczekiwanym wszędzie tam, gdzie jego brak zwiększa ryzyko: laptopy, nośniki, transmisja, kopie zapasowe, dane wrażliwe w bazach. Bonus: wyciek danych poprawnie zaszyfrowanych (bez klucza) zwykle nie wymaga zawiadamiania osób, których dane dotyczą.

Kto odpowiada za środki techniczne — IOD czy IT? Administrator (czyli zarząd). IOD doradza i monitoruje, IT wdraża, ale decyzja o poziomie ryzyka i budżecie to odpowiedzialność kierownictwa — dokładnie jak w NIS2. Dobra praktyka: wspólna mapa ryzyk IT + IOD, przeglądana z zarządem co pół roku.

Od czego zacząć, jeśli dziś mamy tylko polityki na papierze? Od czterech rzeczy o największym efekcie: MFA na dostępach do danych, szyfrowanie laptopów, kopie z testem odtworzenia i logi dostępu do kluczowych baz. Potem audyt luk względem listy wyżej. Możemy przeprowadzić taki przegląd zgodności technicznej i zostawić Ci plan naprawczy z priorytetami.

Podsumowanie

Art. 32 RODO da się przełożyć na konkrety: kontrola dostępu z MFA, szyfrowanie, minimalizacja, logi, odtwarzalne kopie, regularne testy, nadzór nad dostawcami i dokumentacja, która to wszystko potwierdza. To ta sama higiena, która chroni przed ransomware i wyciekami — RODO tylko dodaje jej sankcję. Jeśli chcesz wiedzieć, jak Twoje środki techniczne wyglądają na tle wymagań i praktyki organów — zróbmy audyt.

Artykuł nie stanowi porady prawnej. Źródła: RODO (art. 5, 25, 28, 32–34), wytyczne EDPB, decyzje UODO.