Pierwsze pytanie kontrolującego brzmi zwykle tak samo: proszę pokazać, że ta kontrola działała w badanym okresie. Organizacja, która trzyma dokumentację w katalogach nazwanych według działów, spędza wtedy dwa dni na przeszukiwaniu dysku i kończy z plikami, których daty nie pokrywają badanego okresu.

Platforma odwraca punkt wyjścia. Nie jest magazynem dokumentów z wyszukiwarką, lecz rejestrem relacji: wymaganie wskazuje kontrolę z właścicielem i częstotliwością, a każde jej wystąpienie oczekuje dowodu z datą.

Według tego samego modelu platforma obsługuje zgodność projektów IT. O zgodności z przepisami przesądzają decyzje podjęte na długo przed wdrożeniem, na przykład o polach formularza albo o okresie przechowywania rekordu w bazie. Wymagania RODO i DORA trafiają więc do rejestru razem z kontrolami, które da się sprawdzić w kodzie i w konfiguracji systemu.

Zasada modelu. Dokument sam z siebie nie jest dowodem zgodności. Dowodem staje się dopiero wtedy, gdy wiadomo, którego cyklu kontroli dotyczy i kto go wystawił.

Problem, który rozwiązuje platforma

Dokumentacja zgodności rozsypuje się w przewidywalny sposób. Każdy dział prowadzi własny wykaz, więc ten sam mechanizm zabezpieczający opisany jest w kilku miejscach różnymi słowami. Po roku nikt już nie wie, która wersja polityki obowiązuje.

ObjawPrzyczyna w organizacji danychSkutek podczas kontroli
Kilka wykazów opisujących to samo zabezpieczeniebrak wspólnego identyfikatora kontrolisprzeczne odpowiedzi z różnych działów
Dokument bez informacji, czego dowodziplik odłączony od wymaganiadowód odrzucony jako nieprzypisany
Wpis rejestru sprzed dwóch latbrak wymuszonego przeglądu okresowegorejestr niezgodny ze stanem faktycznym
Kontrola bez wykonawcyprzypisanie do komórki zamiast do osobycykl niewykonany, nikt nie odpowiada

Model danych rejestru

Struktura opiera się na czterech encjach powiązanych relacjami wiele do wielu. Prostota tego modelu ma znaczenie praktyczne - każde dodatkowe pojęcie wprowadzone do rejestru zwiększa liczbę miejsc wymagających aktualizacji.

Powiązanie wymagania z kontrolą

Jedno zabezpieczenie zwykle odpowiada na kilka wymagań jednocześnie. Rozdzielenie ewidencji kontroli od ewidencji wymagań pozwala opisać mechanizm raz i podpiąć go pod wszystkie obowiązki, których dotyczy.

  • Wymaganie - przepis albo zapis normy wraz z odesłaniem do źródła oraz datą stanu prawnego.
  • Kontrola - opis czynności ograniczającej ryzyko wraz z częstotliwością wykonania.
  • Właściciel - osoba imiennie odpowiedzialna za wykonanie oraz dostarczenie dowodu.
  • Dowód - artefakt z datą powiązany z konkretnym cyklem kontroli, nie z kontrolą w ogóle.

Odwzorowanie wiele do wielu oznacza, że przegląd uprawnień wykonywany raz na kwartał zamyka jednocześnie obowiązek wynikający z rozporządzenia o ochronie danych oraz wymaganie normy zarządzania bezpieczeństwem informacji. Bez tego powiązania powstają dwa równoległe przeglądy o identycznej treści.

Dowód wykonania i jego retencja

Dowód musi przetrwać do momentu, w którym staje się potrzebny. Kontrola zewnętrzna bada zwykle okres zamknięty, odległy o kilkanaście miesięcy, więc retencja krótsza niż ten okres czyni cały mechanizm bezużytecznym.

Rodzaj dowoduŹródło artefaktuMinimalna retencja
Zestawienie kont z uprawnieniamisystem produkcyjny, eksport z datąokres badany przez audyt zewnętrzny
Rejestr zatwierdzeń zmiannarzędzie obsługi zgłoszeńokres badany, powiększony o czas do raportu
Protokół odtworzenia kopiiprocedura testowego odtworzeniado kolejnego udanego testu, nie krócej niż rok
Potwierdzenie szkolenialista uczestników z datąokres zatrudnienia osoby szkolonej

Ostrzeżenie techniczne. Dowód wygenerowany w dniu spotkania z audytorem opisuje stan bieżący, nie stan z badanego okresu. Eksport listy kont musi powstawać cyklicznie i trafiać do rejestru od razu, ponieważ odtworzenie historycznego stanu uprawnień z systemu produkcyjnego bywa niewykonalne.

Wymagania RODO i DORA w projektach IT

Projekt IT wnosi do rejestru wymagania, które trzeba spełnić, zanim system trafi do użytkowników. Tabela zestawia wymagania, od których zwykle zaczyna się rejestr projektu. Podstawą każdego z nich jest RODO albo rozporządzenie DORA, a ostatnia kolumna mówi, co musi wykazać dowód.

WymaganiePodstawaCo musi wykazać dowód
Ochrona danych w fazie projektowaniaart. 25 ust. 1 RODOśrodki ochrony zaplanowane przed wdrożeniem, a nie dopisane później
Domyślna ochrona danychart. 25 ust. 2 RODOustawienia domyślne ograniczające zakres danych i ich dostępność
Rejestr czynności przetwarzaniaart. 30 RODOzgodność rejestru z rzeczywistymi tabelami i przepływami danych
Bezpieczeństwo przetwarzaniaart. 32 RODOszyfrowanie oraz zdolność przywrócenia dostępu do danych po incydencie
Ocena skutków dla ochrony danychart. 35 RODOprzeprowadzona ocena dla przetwarzania wysokiego ryzyka
Umowy powierzeniaart. 28 ust. 3 RODOkompletne postanowienia w umowach z dostawcami przetwarzającymi dane
Umowy z podmiotami finansowymiart. 30 DORApostanowienia wymagane w umowach o usługi ICT
Naruszenia ochrony danychart. 33-34 RODOocena ryzyka i zgłoszenie w terminie

Privacy by design sprawdzane w kodzie i schemacie

Art. 25 RODO wymaga uwzględnienia ochrony danych już przy określaniu sposobów przetwarzania. Kontrola wpisana do rejestru ma wtedy postać reguły, którą da się sprawdzić w kodzie albo w schemacie bazy.

  • Minimalizacja pól - formularz zbiera tylko dane potrzebne do celu, zgodnie z art. 5 ust. 1 lit. c; pole „na wszelki wypadek” jest ustaleniem audytu.
  • Retencja w schemacie - okres przechowywania z art. 5 ust. 1 lit. e ma odpowiednik w zadaniu, które usuwa albo anonimizuje rekordy po terminie, a nie tylko zapis w polityce.
  • Dane testowe - środowiska deweloperskie korzystają z danych pseudonimizowanych albo syntetycznych, bo kopia produkcji w środowisku testowym powiela ryzyko bez korzyści.
  • Ustawienia domyślne - nowe konto użytkownika ma najmniejszy potrzebny zakres uprawnień, a profil publiczny jest domyślnie niewidoczny, co odpowiada art. 25 ust. 2.

Rejestry prowadzone w platformie

Zakres obejmuje obowiązki, które w większości organizacji prowadzone są osobno, mimo że opisują te same procesy.

  • Rejestr czynności przetwarzania - wpisy z art. 30 rozporządzenia 2016/679, z podpięciem do systemu utrwalającego dane oraz do właściciela procesu. Budowę wpisu opisuje materiał o inspektorze ochrony danych osobowych.
  • Rejestr naruszeń ochrony danych - zdarzenia wraz z oceną ryzyka, również te ocenione jako niepodlegające zgłoszeniu, z uzasadnieniem takiej oceny.
  • Wykaz zabezpieczeń - mechanizmy odnoszone do wymagań normy zarządzania bezpieczeństwem informacji, ze wskazaniem właściciela oraz dowodu.
  • Wskaźniki ryzyka - wartości mierzone okresowo, pokazujące narastanie zagrożenia przed jego zmaterializowaniem.

Rejestr naruszeń pracuje pod presją terminu. Administrator zgłasza naruszenie Prezesowi UODO bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od jego stwierdzenia, chyba że naruszenie nie skutkuje ryzykiem dla praw lub wolności osób (art. 33 ust. 1 RODO). Podmiot przetwarzający informuje administratora bez zbędnej zwłoki (art. 33 ust. 2), więc termin w umowie powierzenia powinien zostawiać administratorowi czas na ocenę ryzyka.

Wpis powstaje także dla naruszenia, którego administrator nie zgłosił, bo art. 33 ust. 5 wymaga dokumentacji pozwalającej organowi nadzorczemu zweryfikować przestrzeganie przepisu. Art. 32 ust. 1 lit. d wymaga z kolei regularnego testowania skuteczności zabezpieczeń, dlatego przegląd po incydencie sprawdza, czy zabezpieczenie zadziałało, a nie tylko czy istniało. Zasady zgłaszania podatności przez osoby spoza organizacji opisuje polityka ujawniania podatności.

Umowy z dostawcami i kontrahentami

Dostawca, który przetwarza dane osobowe w imieniu klienta, podpisuje umowę powierzenia z elementami wymienionymi w art. 28 ust. 3 RODO. Każde postanowienie trafia do rejestru jako wymaganie z własnym dowodem, bo zapis o pomocy administratorowi albo o usunięciu danych po zakończeniu usługi musi mieć odpowiednik w procedurze i w systemie.

Postanowienie umowy powierzeniaArt. 28 ust. 3 RODODowód w praktyce
przetwarzanie wyłącznie na udokumentowane polecenielit. azlecenia zmian w rejestrze zgłoszeń
poufność osób upoważnionychlit. boświadczenia o zachowaniu poufności
środki bezpieczeństwa z art. 32lit. cwyniki testów i konfiguracji
zasady korzystania z dalszych podmiotów przetwarzającychlit. dlista podwykonawców z datami zgody
usunięcie albo zwrot danych po zakończeniu usługlit. gprotokół usunięcia danych z kopii zapasowych
udostępnienie informacji i umożliwienie audytówlit. hraporty z przeprowadzonych audytów

Klient z sektora finansowego stawia dodatkowe wymagania. Rozporządzenie DORA, stosowane od 17 stycznia 2025 r., wymienia w art. 30 postanowienia, które muszą znaleźć się w umowach o usługi ICT, więc dostawca takiego klienta powinien przygotować się na negocjację umowy według tej listy.

Cykl kontroli i powiadomienia

Harmonogram powstaje z częstotliwości przypisanej kontroli. Platforma tworzy kolejne cykle z wyprzedzeniem i oczekuje dowodu do wyznaczonej daty.

Stan cykluWarunek przejściaWidoczność
Zaplanowanydata wykonania w przyszłościlista zadań właściciela
Wymagający dowodutermin minął, brak artefaktupowiadomienie do właściciela
Zaległyupłynął okres karencjilista odchyleń dla kierownictwa
Zamkniętydowód dodany i powiązany z cyklemhistoria kontroli

Powiadomienia trafiają do właściciela imiennie. Wysyłka do adresu grupowego wygląda na rozwiązanie wygodne, natomiast w praktyce prowadzi do sytuacji, w której zadanie nie ma wykonawcy, bo każdy zakłada, że zajmie się nim ktoś inny.

Zasilanie danymi z systemów źródłowych

Ręczne wprowadzanie dowodów działa przy kilkunastu kontrolach. Przy kilkudziesięciu zaczyna się osypywać, ponieważ czynność administracyjna konkuruje z bieżącą pracą właściciela.

Część artefaktów daje się pobierać automatycznie. Zestawienie kont z systemu katalogowego albo wykaz wdrożeń z narzędzia obsługi zgłoszeń trafiają do rejestru bez udziału człowieka, wraz ze znacznikiem czasu pochodzącym z systemu źródłowego.

  • Import zaplanowany - zadanie pobierające artefakt w ustalonym cyklu, z zapisem wyniku również przy niepowodzeniu.
  • Przyjęcie przez interfejs programistyczny - system źródłowy sam przekazuje artefakt po wykonaniu operacji, z identyfikatorem chroniącym przed duplikatem.

Niepowodzenie importu musi być widoczne. Cichy brak artefaktu wygląda w rejestrze identycznie jak niewykonana kontrola, więc rozróżnienie tych przypadków wymaga zapisu próby wraz z jej wynikiem.

Dowody z konfiguracji bazy danych

Konfigurację serwera bazy danych polityki bezpieczeństwa zwykle opisują, ale rzadko weryfikują. Zapytania kontrolne uruchamiane w cyklu kontroli zamieniają ją w dowód: wynik z datą trafia do rejestru, a różnica względem poprzedniego wyniku jest ustaleniem. Poniższe zapytania dotyczą SQL Server.

-- Loginy SQL bez polityki haseł albo bez wymuszania wygasania
SELECT name, is_policy_checked, is_expiration_checked, is_disabled
  FROM sys.sql_logins
 WHERE is_policy_checked = 0
    OR is_expiration_checked = 0;

-- Członkowie roli sysadmin
SELECT m.name, m.type_desc, m.is_disabled
  FROM sys.server_role_members AS rm
  JOIN sys.server_principals AS r ON r.principal_id = rm.role_principal_id
  JOIN sys.server_principals AS m ON m.principal_id = rm.member_principal_id
 WHERE r.name = N'sysadmin';

-- Bazy użytkowników bez zakończonego szyfrowania TDE
SELECT d.name, e.encryption_state
  FROM sys.databases AS d
  LEFT JOIN sys.dm_database_encryption_keys AS e ON e.database_id = d.database_id
 WHERE d.database_id > 4
   AND ISNULL(e.encryption_state, 0) <> 3;

Widok sys.sql_logins pokazuje, które loginy omijają politykę haseł systemu Windows. Lista członków roli sysadmin powinna zgadzać się z listą administratorów w dokumentacji, a każda różnica jest ustaleniem. Wartość 3 w kolumnie encryption_state widoku sys.dm_database_encryption_keys oznacza bazę zaszyfrowaną, a warunek database_id > 4 pomija bazy systemowe. Szyfrowanie TDE chroni pliki danych i kopie zapasowe, ale nie ogranicza dostępu użytkownika, który ma uprawnienia w bazie.

Inwentaryzacja danych osobowych w schemacie

Rejestr czynności przetwarzania z art. 30 RODO powinien odpowiadać temu, co naprawdę jest w bazie. Wyszukiwanie kolumn po nazwach daje listę kandydatów do przeglądu, a wynik przeglądu zapisuje się w bazie jako klasyfikację wrażliwości.

SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
  FROM INFORMATION_SCHEMA.COLUMNS
 WHERE COLUMN_NAME LIKE N'%pesel%'
    OR COLUMN_NAME LIKE N'%email%'
    OR COLUMN_NAME LIKE N'%telefon%'
    OR COLUMN_NAME LIKE N'%nazwisko%';

ADD SENSITIVITY CLASSIFICATION TO dbo.Osoba.Pesel
    WITH (LABEL = 'Confidential - GDPR', INFORMATION_TYPE = 'National ID', RANK = HIGH);

Wyszukiwanie po nazwach nie znajdzie numeru PESEL zapisanego w kolumnie Uwagi, dlatego wyniki traktuje się jako punkt wyjścia, a nie pełną inwentaryzację. Polecenie ADD SENSITIVITY CLASSIFICATION zapisuje etykietę w metadanych bazy, więc klasyfikacja przetrwa zmianę dokumentacji i jest widoczna w widoku sys.sensitivity_classifications.

Przebieg wdrożenia

Największy koszt leży po stronie uporządkowania wymagań, nie konfiguracji narzędzia. Organizacje zwykle mają kilka nakładających się wykazów obowiązków powstałych przy różnych okazjach.

  • Konsolidacja wymagań - scalenie wykazów, usunięcie wpisów opisujących ten sam obowiązek różnymi słowami.
  • Przypisanie właścicieli - imienne wskazanie osób odpowiedzialnych, z rozstrzygnięciem przypadków spornych na poziomie kierownictwa.
  • Ustalenie częstotliwości oraz retencji - dobór cyklu do rzeczywistego ryzyka, nie do kalendarza sprawozdawczego.
  • Uruchomienie pierwszego cyklu na próbie - start z kilkunastoma kontrolami o najwyższym ryzyku, rozszerzenie po pierwszym pełnym obiegu.

Zakres badania poprzedzającego wdrożenie opisuje materiał o ogólnych mechanizmach kontrolnych IT, a pozostałe usługi spółki - strona o firmie Audit GRC. Kompetencje potrzebne w zespole wdrożeniowym opisuje artykuł o kompetencjach w ochronie danych osobowych i bezpieczeństwie IT. Kanał zgłaszania nieprawidłowości, który również wymaga rejestru oraz terminów, opisuje artykuł o ochronie sygnalistów.

Kontakt w sprawie zakresu wdrożenia: biuro@audit-grc.pl albo +48 730 007 587.

Pytania i odpowiedzi

Czym platforma różni się od katalogu plików na dysku współdzielonym?

Katalog przechowuje dokumenty, natomiast nie wie, którego wymagania dotyczą ani czy są aktualne. Platforma prowadzi relacje: wymaganie wskazuje kontrolę z właścicielem i częstotliwością, a każdy cykl oczekuje dowodu z datą. Pytanie kontrolującego o dowód dla konkretnego obowiązku daje się wtedy odpowiedzieć zapytaniem, nie przeszukiwaniem folderów.

Co jest przechowywane jako dowód wykonania kontroli?

Artefakt pochodzący z systemu, w którym kontrola faktycznie zadziałała, na przykład zrzut listy kont z datą albo protokół odtworzenia kopii zapasowej. Platforma zapisuje plik wraz z metadanymi: kto go dodał, kiedy, którego cyklu dotyczy oraz z jakiego systemu pochodzi. Oświadczenie osoby odpowiedzialnej rejestrowane jest osobno i nie zamyka cyklu.

Czy platforma zastępuje inspektora ochrony danych?

Narzędzie prowadzi rejestry oraz pilnuje terminów, natomiast ocena ryzyka i rozstrzyganie wątpliwości interpretacyjnych pozostają czynnościami człowieka. Platforma skraca czas potrzebny inspektorowi na ustalenie stanu faktycznego, ponieważ wpisy rejestru wskazują systemy oraz właścicieli procesów, a nie same nazwy działów.

Jak platforma radzi sobie z rozjazdem rejestru i stanu faktycznego?

Rozjazd powstaje wtedy, gdy zmiana w systemie nie wywołuje aktualizacji wpisu. Platforma ogranicza go dwoma mechanizmami: wpis wskazuje konkretny system oraz osobę odpowiedzialną za proces, a przegląd okresowy wymusza potwierdzenie aktualności z datą. Wpis bez potwierdzenia w przyjętym okresie oznaczany jest jako wymagający weryfikacji.

Ile czasu ma administrator na zgłoszenie naruszenia do UODO?

Bez zbędnej zwłoki, w miarę możliwości nie później niż w terminie 72 godzin po stwierdzeniu naruszenia, chyba że naruszenie nie skutkuje ryzykiem naruszenia praw lub wolności osób fizycznych (art. 33 ust. 1 RODO).

Czy każdy dostawca IT wymaga umowy powierzenia?

Tylko dostawca, który przetwarza dane osobowe w imieniu administratora, na przykład utrzymuje bazę z danymi klientów. Umowa musi zawierać elementy wymienione w art. 28 ust. 3 RODO.

Słownik pojęć

Wymaganie
Pojedynczy obowiązek wynikający z przepisu prawa albo z przyjętej normy, zapisany w rejestrze wraz z odesłaniem do źródła. Stanowi punkt zaczepienia dla kontroli oraz dowodów jej wykonania.
Kontrola
Czynność ograniczająca ryzyko niespełnienia wymagania, opisana częstotliwością oraz sposobem wykonania. Jedna kontrola może odnosić się do wielu wymagań jednocześnie.
Cykl kontroli
Pojedyncze wystąpienie kontroli w harmonogramie, oczekujące dowodu wykonania. Cykl bez dowodu po upływie terminu oznaczany jest jako zaległy i trafia na listę odchyleń.
Właściciel kontroli
Osoba odpowiedzialna za wykonanie kontroli oraz dostarczenie dowodu. Przypisanie imienne, nie do komórki organizacyjnej, ponieważ rozproszona odpowiedzialność prowadzi do cykli bez wykonawcy.
Retencja dowodu
Okres przechowywania artefaktu potwierdzającego wykonanie kontroli. Musi pokrywać okres badany przez kontrolę zewnętrzną, w przeciwnym razie dowód znika przed momentem, w którym staje się potrzebny.
KRI
Key Risk Indicators - wskaźniki ryzyka mierzone okresowo, pokazujące narastanie zagrożenia przed jego zmaterializowaniem. Przykładem jest liczba kont bez przypisanego właściciela albo odsetek zmian wdrożonych z pominięciem ścieżki zatwierdzania.
Privacy by design
Uwzględnianie ochrony danych w projekcie systemu od etapu określania sposobów przetwarzania, przez wdrożenie odpowiednich środków technicznych i organizacyjnych (art. 25 ust. 1 RODO).
Umowa powierzenia
Umowa między administratorem a podmiotem przetwarzającym, której obowiązkowe elementy wymienia art. 28 ust. 3 RODO, w tym przedmiot i czas trwania przetwarzania.
Klasyfikacja wrażliwości
Etykiety przypisywane kolumnom bazy SQL Server poleceniem ADD SENSITIVITY CLASSIFICATION, opisujące rodzaj informacji i poziom poufności.