RODO a systemy IT – wymagania wobec oprogramowania

Co RODO realnie narzuca na poziomie oprogramowania?

RODO (Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679) nie opisuje, jak ma wyglądać „interfejs” systemu. Zmusza jednak do osiągnięcia konkretnych efektów: zapewnienia bezpieczeństwa przetwarzania, rozliczalności działań oraz zgodności z prawami osób, których dane dotyczą. W praktyce to oznacza wymagania funkcjonalne i techniczne, które musi spełniać oprogramowanie — niezależnie czy to ERP, CRM, HRM, WMS, MES czy system do obiegu dokumentów.

→ Cookies i RODO – consent management i polityka prywatności

→ RODO w e-commerce – sklep internetowy a przepisy

→ Privacy by Design i Privacy by Default – zasady w praktyce

Najczęściej w kontekście systemów IT przewijają się następujące obszary:

• Bezpieczeństwo przetwarzania: mechanizmy kontroli dostępu, szyfrowanie, logowanie zdarzeń, odporność na błędy konfiguracji.
• Minimalizacja i retencja: możliwość ograniczania zakresu danych oraz ustawiania okresów przechowywania.
• Rozliczalność: rejestrowanie działań (kto i co zmienił), śledzenie dostępu, dowody realizacji uprawnień.
• Prawa osób: realizacja dostępu do danych, sprostowania, usunięcia, ograniczenia przetwarzania oraz przenoszenia danych (tam, gdzie ma zastosowanie).
• Współpraca z podmiotami: poprawne mechanizmy dla procesorów i usługodawców (np. outsourcing IT), w tym możliwość udostępnienia ustalonych dowodów.

Jakie wymagania funkcjonalne powinien mieć system, żeby przejść audyt RODO?

Gdy pytacie mnie w firmach o „checklistę RODO dla oprogramowania”, najczęściej dostajecie odpowiedź: mierzcie funkcje, które dostarczają dowody. RODO jest „proceduralne”, ale audytorzy w praktyce sprawdzają, czy system ma mechanizmy, które te procedury umożliwiają.

1) Kontrola dostępu i rozdział ról

System musi wspierać role (RBAC – role-based access control), a najlepiej także uprawnienia na poziomie obiektu/rekordu (np. użytkownik widzi dane tylko z przypisanej lokalizacji lub działu). W projektach, które analizowałem, największą awarią zgodności nie była brak logiki w regulaminie, tylko zbyt szerokie uprawnienia „dla wygody” w konfiguracji.

2) Rejestrowanie zdarzeń (logi) i ścieżka audytu

Wymagane są rejestry działań administracyjnych i dostępów do danych osobowych: logowanie logowania (kto się logował), zmiany w rekordach oraz eksporty/raporty zawierające dane. Logi muszą być chronione przed modyfikacją i przynajmniej w części retencjonowane zgodnie z polityką bezpieczeństwa.

3) Szyfrowanie danych i bezpieczne przechowywanie

Minimalnie: szyfrowanie transmisji (TLS) i możliwość szyfrowania danych w spoczynku (w bazie danych, w kopiach zapasowych). RODO mówi o „odpowiednich środkach technicznych i organizacyjnych” — dla systemów biznesowych standardem jest szyfrowanie i zarządzanie kluczami po stronie infrastruktury.

4) Retencja, anonimizacja i usuwanie

System powinien umożliwiać ustawienie okresów przechowywania danych (retencji) oraz, kiedy to ma sens, anonimizację lub pseudonimizację. Mechanizmy „ręcznego czyszczenia po stronie administratora” są obarczone ryzykiem błędu i brakiem dowodów. Szukaj funkcji: automatyczne usuwanie lub wygaszenie danych po czasie, blokady do dalszego przetwarzania, oraz eksport danych do procesu realizacji praw.

5) Obsługa praw osób – proces wbudowany w system

Nie chodzi tylko o to, że „dział prawny wie, co robić”. Oprogramowanie musi wspierać:

• zgłoszenia i weryfikację wniosków (kto składa, jakie dane wnioskował),
• zasięg danych (gdzie te dane występują: moduły, archiwa, integracje),
• kontrolę rezultatów (czy usunięto wszystkie kopie, czy zrobiono to w terminie),
• udokumentowanie działań dla audytu.

Konkretny wskaźnik: czas realizacji wniosku o usunięcie lub udostępnienie powinien być liczony w dniach, a nie tygodniach. W dojrzałych wdrożeniach organizacje schodzą do 3–10 dni w zależności od integracji i archiwów.

Cloud vs on-premise: gdzie RODO jest „łatwiejsze”, a gdzie trudniejsze?

To nie jest spór ideologiczny. RODO dotyczy efektów, więc różnice sprowadzają się do tego, kto i gdzie kontroluje środki techniczne. W cloudzie zwykle szybciej uzyskuje się pewne mechanizmy (np. standardowe logowanie, centralne kopie, łatwiejsze aktualizacje bezpieczeństwa), ale trudniejsze staje się wykazanie kompletności działań w środowiskach, które „w dużej części są po stronie dostawcy”. W on-premise masz więcej kontroli, ale też więcej odpowiedzialności: łatki, konfiguracja, kopie, testy przywracania.

Praktyczna zasada: bez względu na model wdrożenia, musisz mieć odpowiedź na pytanie: „jak system realizuje usunięcie danych w całym łańcuchu przetwarzania?”. Jeżeli Twoje dane przechodzą przez integracje (np. middleware, wymiany EDI, ekstrakcje do hurtowni), to RODO zaczyna się od architektury.

Jak ocenić zgodność oprogramowania przed zakupem lub wdrożeniem?

Największy błąd w projektach RODO to testowanie zgodności na końcu, kiedy jesteś już po podpisach i w połowie migracji danych. Prawidłowe podejście to analiza przedwdrożeniowa, która obejmuje: mapę danych, funkcje systemu, integracje oraz wymagania procesowe.

Minimalny plan w 10–15 dni

1. Inwentaryzacja danych osobowych w systemie i integracjach: jakie kategorie danych, kto ich używa, gdzie trafiają (moduły, raporty, archiwa, narzędzia BI).
2. Mapa przepływu: od momentu wprowadzenia danych (np. kadry, CRM, zamówienie) do ich „życia” w innych komponentach.
3. Warsztat wymagań: co musi umieć system, aby realizować prawa osób i środki bezpieczeństwa (retencja, eksport, usuwanie, logi, uprawnienia).
4. Testy funkcjonalne (PoC – proof of concept): scenariusze „wniosek o dostęp”, „wniosek o usunięcie”, „co dzieje się z kopiami w archiwum” oraz „jak działa eksport danych”.
5. Analiza umowna: role (administrator/processor), podprocesorzy, zakres odpowiedzialności oraz dostarczane dowody (raporty, logi, certyfikaty).

Jedna obserwacja z rozmów z dyrektorami IT wynika tak często, że warto to zapamiętać: zespoły kupują system, który „ma funkcje”, ale dopiero po wdrożeniu dowiadują się, że nie ma tych funkcji w trybie potrzebnym dla ich danych (np. usuwanie nie obejmuje logów, a eksport nie obejmuje danych w hurtowni).

Typowe błędy w projektach RODO przy systemach IT

W praktyce wciąż widzę te same pułapki. Uniknięcie ich zwykle kosztuje mniej niż „naprawianie” zgodności po go-live.

• Brak mapy danych i integracji: system spełnia wymagania w modułach własnych, ale dane osobowe są też w: kopiach, narzędziach ETL, logach aplikacji, backupach, archiwum plików, raportach użytkowników. Jeśli nie wiesz gdzie są dane, nie zrobisz kompletnego usuwania.
• Retencja „na papierze”: polityka retencji nie ma przełożenia na automatyczne mechanizmy systemu. Efekt: dane zalegają, a procedura staje się ręczna i niespójna.
• Uprawnienia zrobione „dla wygody”: brak zasady najmniejszych uprawnień (least privilege) prowadzi do nadmiarowego dostępu i trudnych do wyjaśnienia incydentów. Audyt dostaje nie tylko raport, ale też historię logowań.
• Brak planu obsługi praw osób: system nie ma workflow’u, nie potrafi wyszukać wszystkich wystąpień danych albo nie generuje dowodów. Wtedy wniosek o usunięcie staje się „projektem” dla administratora.

Kontrolowana niedoskonałość, która oddaje realia: w wielu firmach compliance zaczyna się od „ustawimy role i będzie ok”. Po wdrożeniu okazuje się, że to dopiero początek — bo prawdziwe ryzyko siedzi w danych poza ekranem systemu 😉

Ile to kosztuje i jak planować harmonogram: od audytu do go-live?

Koszty RODO w projektach IT rzadko są osobną pozycją w budżecie. Zwykle „wchodzą” w: analizę, konfigurację, testy bezpieczeństwa, modyfikacje integracji oraz przygotowanie dowodów audytowych. Dlatego warto planować je jako element programu wdrożeniowego.

Widełki kosztów i czasu

Jak zacząć, żeby nie utknąć na końcu projektu

1. Zaplanuj pracę na danych, nie na ekranach: zacznij od mapy danych osobowych i ich cyklu życia w całym ekosystemie.
2. Ustal wymagania testowe jeszcze zanim zrobisz migrację: scenariusze „dostęp”, „sprostowanie”, „usunięcie” oraz „ograniczenie przetwarzania” muszą przejść przez integracje.
3. Wymuś logowanie i dowody: zdefiniuj, jakie logi muszą istnieć i jak długo są przechowywane. Dowody to nie dokument PDF na ostatnią chwilę.
4. Sprawdź vendor lock-in na poziomie zgodności: jeśli system lub moduł jest jedynym miejscem realizacji retencji, audytu i eksportu, to wyjście z niego będzie droższe niż licencja. Zadbaj o eksporty i komplet danych w formatach, które da się wykorzystać w przyszłości.

Porównanie podejść: własne wdrożenie vs outsourcing

Jak przełożyć wymagania na specyfikację zakupową i wymagania dla dostawcy?

Jeżeli kupujesz oprogramowanie (lub rozszerzasz licencję), nie wystarczy poprosić o „zgodność z RODO”. W specyfikacji powinny znaleźć się wymagania, które da się zweryfikować. W szczególności warto wpisać:

• Mechanizmy realizacji praw osób: eksport danych, usuwanie/ograniczenie, workflow obsługi wniosku, dowody wykonania.
• Retencja i usuwanie w cyklu życia danych: zasady dla danych głównych, kopii, archiwów, dokumentów załączonych.
• Logi i audyt: zakres zdarzeń, integralność logów, możliwość odtworzenia historii zmian.
• Kontrola dostępu: role, polityka hasłowa, możliwość ograniczeń na obiektach, wykluczenie dostępu „dla każdego”.
• Bezpieczeństwo: szyfrowanie w transmisji i w spoczynku, zarządzanie kluczami, aktualizacje bezpieczeństwa.
• Zakres odpowiedzialności w umowie: procesor/podprocesor, obowiązki po stronie dostawcy, dostęp do dowodów, tryb incydentów.

W praktyce dobrze działa też prosty format: wymaganie + kryterium akceptacji + sposób weryfikacji. Przykład kryterium: „system usuwa dane osobowe powiązane z identyfikatorem pracownika w bazie i w archiwum dokumentów w czasie X dni oraz generuje raport audytowy dla administratora”. To są rzeczy, które da się przetestować.

Podsumowanie: co sprawdzić, zanim podpiszesz umowę lub ruszysz z migracją?

Z perspektywy zgodności RODO oprogramowanie nie jest „kwestią prawną” — jest elementem architektury i operacji. Jeśli system spełnia wymagania bezpieczeństwa i rozliczalności, ale nie potrafi zrealizować praw osób w całym łańcuchu danych (w tym w integracjach i kopiach), to ryzyko pozostaje.

Zanim zdecydujesz się na wdrożenie, sprawdź:

• czy system i integracje mają kompletne mechanizmy retencji i usuwania,
• czy istnieją logi audytowe z chronioną integralnością oraz czy da się je odtworzyć na potrzeby weryfikacji,
• czy da się szybko realizować prawa osób (eksport/usunięcie) bez pracy ręcznej,
• czy model cloud/on-prem i umowy procesorowe nie blokują Ci dowodów i odpowiedzialności.

Jeśli chcesz, mogę pomóc przygotować szablon wymagań RODO dla systemu IT (specyfikacja do dostawcy + scenariusze testowe) pod Twój typ środowiska: ERP/CRM/HRM oraz skalę (liczba użytkowników i integracji). Wystarczy, że opiszesz, czy celujesz w cloud czy on-prem oraz jakie dane osobowe dominują w procesach.