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.
| Objaw | Przyczyna w organizacji danych | Skutek podczas kontroli |
|---|---|---|
| Kilka wykazów opisujących to samo zabezpieczenie | brak wspólnego identyfikatora kontroli | sprzeczne odpowiedzi z różnych działów |
| Dokument bez informacji, czego dowodzi | plik odłączony od wymagania | dowód odrzucony jako nieprzypisany |
| Wpis rejestru sprzed dwóch lat | brak wymuszonego przeglądu okresowego | rejestr niezgodny ze stanem faktycznym |
| Kontrola bez wykonawcy | przypisanie do komórki zamiast do osoby | cykl 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 artefaktu | Minimalna retencja |
|---|---|---|
| Zestawienie kont z uprawnieniami | system produkcyjny, eksport z datą | okres badany przez audyt zewnętrzny |
| Rejestr zatwierdzeń zmian | narzędzie obsługi zgłoszeń | okres badany, powiększony o czas do raportu |
| Protokół odtworzenia kopii | procedura testowego odtworzenia | do kolejnego udanego testu, nie krócej niż rok |
| Potwierdzenie szkolenia | lista 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.
| Wymaganie | Podstawa | Co musi wykazać dowód |
|---|---|---|
| Ochrona danych w fazie projektowania | art. 25 ust. 1 RODO | środki ochrony zaplanowane przed wdrożeniem, a nie dopisane później |
| Domyślna ochrona danych | art. 25 ust. 2 RODO | ustawienia domyślne ograniczające zakres danych i ich dostępność |
| Rejestr czynności przetwarzania | art. 30 RODO | zgodność rejestru z rzeczywistymi tabelami i przepływami danych |
| Bezpieczeństwo przetwarzania | art. 32 RODO | szyfrowanie oraz zdolność przywrócenia dostępu do danych po incydencie |
| Ocena skutków dla ochrony danych | art. 35 RODO | przeprowadzona ocena dla przetwarzania wysokiego ryzyka |
| Umowy powierzenia | art. 28 ust. 3 RODO | kompletne postanowienia w umowach z dostawcami przetwarzającymi dane |
| Umowy z podmiotami finansowymi | art. 30 DORA | postanowienia wymagane w umowach o usługi ICT |
| Naruszenia ochrony danych | art. 33-34 RODO | ocena 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 powierzenia | Art. 28 ust. 3 RODO | Dowód w praktyce |
|---|---|---|
| przetwarzanie wyłącznie na udokumentowane polecenie | lit. a | zlecenia zmian w rejestrze zgłoszeń |
| poufność osób upoważnionych | lit. b | oświadczenia o zachowaniu poufności |
| środki bezpieczeństwa z art. 32 | lit. c | wyniki testów i konfiguracji |
| zasady korzystania z dalszych podmiotów przetwarzających | lit. d | lista podwykonawców z datami zgody |
| usunięcie albo zwrot danych po zakończeniu usług | lit. g | protokół usunięcia danych z kopii zapasowych |
| udostępnienie informacji i umożliwienie audytów | lit. h | raporty 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 cyklu | Warunek przejścia | Widoczność |
|---|---|---|
| Zaplanowany | data wykonania w przyszłości | lista zadań właściciela |
| Wymagający dowodu | termin minął, brak artefaktu | powiadomienie do właściciela |
| Zaległy | upłynął okres karencji | lista odchyleń dla kierownictwa |
| Zamknięty | dowód dodany i powiązany z cyklem | historia 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.