Testowanie zabezpieczeń ISO 27701 dotyczących prywatności pod kątem rozliczalności GDPR

Piątkowy audyt prywatności, który ujawnił rzeczywisty problem
Jest piątek, godzina 15:40, gdy Maria, CISO szybko rosnącej spółki SaaS, dołącza do wideorozmowy z dyrektorem ds. zakupów dużego potencjalnego klienta korporacyjnego.
Jej zespół przez wiele miesięcy pracował nad systemem zarządzania informacjami o prywatności. Polityki zostały zatwierdzone. Rejestr czynności przetwarzania istnieje. Spółka ma plan gotowości do ISO 27701. IOD posiada procesy obsługi żądań osób, których dane dotyczą. Dział prawny zaktualizował umowy powierzenia przetwarzania danych. Zespół inżynieryjny deklaruje, że dostęp do środowiska produkcyjnego jest ograniczony.
Dyrektor ds. zakupów zaczyna uprzejmie, ale bezpośrednio.
„Dziękujemy za dokumentację, Mario. Certyfikat i pakiet polityk to dobry punkt wyjścia. Nasz zespół due diligence będzie u Państwa w przyszłym miesiącu. Będzie chciał zobaczyć proces DSAR w działaniu, zweryfikować kontrole minimalizacji danych na naszych kontach testowych, przejrzeć logi dostępu do środowiska produkcyjnego oraz sprawdzić dowody, że zabezpieczenia dotyczące prywatności są testowane, a nie tylko udokumentowane”.
W ciągu kilku minut Maria otrzymuje jeszcze dwie wiadomości.
IOD pyta, czy nowa funkcja analityczna jest objęta rejestrem czynności przetwarzania, oceną podstawy prawnej, harmonogramem retencji oraz obowiązkami przenoszonymi na podmiot przetwarzający.
Menedżer ds. zgodności pyta, czy przegląd gotowości do ISO 27701:2025 może wykazać, że zabezpieczenia PIMS działają skutecznie.
To moment, w którym wiele programów prywatności traci stabilność. Organizacja ma dokumenty dotyczące prywatności, ale nie ma dowodów prywatności. Ma procesy, ale nie ma dowodów opartych na próbkach. Ma umowy, ale słabe zapisy monitorowania. Ma wewnętrzne przekonanie o skuteczności, ale brakuje możliwej do obrony ścieżki audytowej.
Ta luka stanowi różnicę między papierową zgodnością a możliwą do wykazania rozliczalnością.
GDPR ujmuje problem wprost. Administrator odpowiada za zgodność z zasadami ochrony danych i musi być w stanie ją wykazać. Dane osobowe muszą być przetwarzane zgodnie z prawem, rzetelnie, przejrzyście, w określonych celach, w zakresie ograniczonym do tego, co niezbędne, prawidłowo, przechowywane tylko tak długo, jak jest to potrzebne, oraz zabezpieczone odpowiednimi środkami technicznymi i organizacyjnymi.
ISO 27701:2025 zapewnia organizacjom strukturę zarządzania prywatnością. ISO/IEC 27001:2022 zapewnia szkielet SZBI dla zakresu, postępowania z ryzykiem, kontroli operacyjnej, audytu wewnętrznego, przeglądu zarządzania i ciągłego doskonalenia. GDPR nakłada ciężar rozliczalności prawnej. NIS2, DORA, NIST CSF 2.0, zapewnienie w stylu COBIT 2019 oraz przeglądy bezpieczeństwa prowadzone przez klientów zwiększają presję, aby wykazać, że zabezpieczenia działają.
Stanowisko Clarysec jest proste: testowanie zabezpieczeń dotyczących prywatności nie powinno być coroczną gorączkową zbiórką zrzutów ekranu. Powinno być systemem dowodów PIMS, który łączy czynności przetwarzania, stosowalne zabezpieczenia, ryzyka, próbki, weryfikacje techniczne, ustalenia, CAPA i przegląd zarządzania w jeden identyfikowalny model.
W tym miejscu zestaw polityk PIMS Clarysec, Zenith Blueprint: 30-etapowa mapa drogowa audytora oraz Zenith Controls: przewodnik zgodności między ramami stają się narzędziami operacyjnymi, a nie materiałem na półkę.
Testowanie zabezpieczeń dotyczących prywatności jest pomostem między polityką a rozliczalnością
Test zabezpieczenia dotyczącego prywatności odpowiada na trzy praktyczne pytania:
- Czy zabezpieczenie zostało zaprojektowane tak, aby spełnić obowiązek w zakresie prywatności albo ograniczyć ryzyko dla prywatności?
- Czy zabezpieczenie zostało wdrożone w odpowiednim procesie, systemie, zespole, u dostawcy albo w procesie produktowym?
- Czy zabezpieczenie działa skutecznie w czasie, z dowodami, które zaakceptowałby audytor, klient, organ nadzorczy albo komitet rady ds. ryzyka?
Spółka SaaS może deklarować, że obsługuje żądania usunięcia danych. Test projektu sprawdza, czy zdefiniowano politykę usuwania, proces weryfikacji tożsamości, model odpowiedzialności, koordynację z podmiotem przetwarzającym, wyjątki od retencji oraz postępowanie z kopiami zapasowymi. Test skuteczności działania obejmuje próbki zakończonych żądań usunięcia, porównanie znaczników czasu, sprawdzenie zatwierdzeń, przegląd logów systemowych, weryfikację powiadomień do dalszych podmiotów przetwarzających oraz potwierdzenie dowodów zamknięcia.
PIMS Monitoring, Audit and Improvement Policy przekształca to w wymaganie podlegające kontroli audytowej:
[Obie wersje] Audytor wewnętrzny / osoba dokonująca przeglądu zgodności MUSI testować status wdrożenia stosowalnych zabezpieczeń PIMS względem REG03 podczas każdego audytu PIMS.
Z sekcji „Program audytów wewnętrznych PIMS”, klauzula polityki 4.2.5.
Sformułowanie „względem REG03” ma kluczowe znaczenie. Testowanie nie jest swobodnym wywiadem. REG03 stanowi punkt odniesienia dla stosowalności i wdrożenia zabezpieczeń PIMS. Pokazuje, co ma zastosowanie, dlaczego ma zastosowanie i jakie dowody powinny istnieć.
Ta sama polityka dodaje:
[Obie wersje] Audytor wewnętrzny / osoba dokonująca przeglądu zgodności MUSI zarejestrować wybraną próbkę dowodową przetwarzania PII w REG12 podczas każdego audytu PIMS.
Z sekcji „Program audytów wewnętrznych PIMS”, klauzula polityki 4.2.6.
To sedno testowania zabezpieczeń ISO 27701:2025 dotyczących prywatności. Audyt PIMS bez próbki jest rozmową. Audyt PIMS z wybranymi dowodami, mapowaniem zabezpieczeń, wyjątkami, działaniem korygującym i identyfikowalnością przeglądu zarządzania jest rozliczalnością.
Zacznij od zakresu, roli i rzeczywistego przetwarzania
Większość słabych audytów prywatności kończy się niepowodzeniem jeszcze przed rozpoczęciem testów. Wybierają ogólne zabezpieczenia bez potwierdzenia, jakie dane osobowe są przetwarzane, gdzie się znajdują, które systemy i dostawcy mają z nimi styczność oraz czy organizacja działa jako administrator, podmiot przetwarzający, współadministrator czy dalszy podmiot przetwarzający.
Obowiązki GDPR w dużym stopniu zależą od roli. Administrator decydujący, dlaczego i jak przetwarzane są dane osobowe, ma inne obowiązki niż podmiot przetwarzający działający na podstawie udokumentowanych poleceń klienta. Znaczenie ma również wrażliwość danych. Dane pracowników, dane kont klientów, dane telemetryczne, dane finansowe, weryfikacja biometryczna, dane dotyczące zdrowia, screening sankcyjny oraz dane dotyczące czynów zabronionych nie niosą takiego samego ryzyka.
Silny program testowania ISO 27701:2025 zaczyna się od dyscypliny zakresu.
| Pytanie dotyczące zakresu | Dowody do sprawdzenia | Dlaczego ma to znaczenie |
|---|---|---|
| Jakie czynności przetwarzania PII są objęte zakresem? | Rejestr czynności przetwarzania, mapa przepływu danych, inwentarz systemów, rejestr dostawców | Testowanie musi obejmować próbki rzeczywistego przetwarzania, a nie abstrakcyjne deklaracje z polityk |
| Jaka rola PIMS ma zastosowanie? | Mapowanie administratora, podmiotu przetwarzającego, współadministratora i dalszego podmiotu przetwarzającego | Obowiązki GDPR i zabezpieczenia PIMS różnią się w zależności od roli |
| Jakie obowiązki prawne, umowne i regulacyjne mają zastosowanie? | Ocena GDPR, DPA klientów, wymogi sektorowe, oceny transferów | Projekt zabezpieczenia musi odzwierciedlać rzeczywiste obowiązki |
| Które systemy i dostawcy przetwarzają PII? | Inwentarz aktywów, inwentarz chmurowy, wykaz podmiotów przetwarzających, macierz dostępu | Testy skuteczności działania wymagają dowodów technicznych i dowodów od stron trzecich |
| Które zmiany wpływają na przetwarzanie PII? | Zapisy zmian produktowych, kryteria obowiązku przeprowadzenia DPIA, informacje o wydaniu, przeglądy architektury | Privacy by design musi być testowane przed uruchomieniem, a nie po skargach |
ISO/IEC 27001:2022 wspiera takie zintegrowane podejście poprzez wymagania dotyczące kontekstu organizacji, wymagań stron zainteresowanych, obowiązków prawnych i umownych, zakresu systemu zarządzania, planowania operacyjnego oraz postępowania z ryzykiem. W obszarze prywatności oznacza to, że przetwarzanie PII nie może pozostawać w odizolowanym arkuszu kalkulacyjnym. Musi być częścią modelu operacyjnego SZBI i PIMS.
Privacy Information Management System Policy łączy testowanie prywatności bezpośrednio z ładem zarządczym:
[Wszystkie wersje] Najwyższe kierownictwo MUSI co roku przeglądać skuteczność PIMS, cele dotyczące prywatności, otwarte ryzyka, niezgodności, działania korygujące i decyzje doskonalące w REG12.
Z sekcji „Ład zarządczy PIMS”, klauzula polityki 6.1.1.
Jeżeli testowanie identyfikuje lukę w obszarze prywatności, nie jest to tylko notatka audytowa. To dane wejściowe do systemu zarządzania, które powinny wpływać na postępowanie z ryzykiem, priorytety, zasoby i decyzje kierownictwa.
Skuteczność projektu zabezpieczenia a skuteczność działania
Gdy klient pyta, czy zabezpieczenia dotyczące prywatności są testowane, zwykle ma na myśli skuteczność działania. Audytorzy zbadają jednak również skuteczność projektu zabezpieczenia.
Zabezpieczenie skuteczne projektowo jest zdolne spełnić wymaganie, jeżeli jest wykonywane zgodnie z założeniami. Zabezpieczenie skuteczne operacyjnie jest faktycznie wykonywane w sposób spójny i poparte dowodami.
| Obszar zabezpieczenia | Test skuteczności projektu zabezpieczenia | Test skuteczności działania |
|---|---|---|
| Uzyskiwanie zgody | Zweryfikuj politykę, treść zgody, reguły podstawy prawnej, wymagania UI, proces wycofania zgody | Pobierz próbki zapisów zgody i wycofań zgody, porównaj znaczniki czasu, zweryfikuj wyłączenie po wycofaniu zgody |
| Ograniczenie celu | Przejrzyj RoPA, klauzulę informacyjną, wymagania produktowe, rozdzielenie zgód, reguły wykorzystywania danych | Pobierz próbki rekordów użytkowników, logów, eksportów i przepływów analitycznych, aby potwierdzić, że PII nie jest ponownie wykorzystywane do nieuprawnionych celów |
| Dostęp do PII | Przejrzyj politykę dostępu, model ról, procedurę joiner-mover-leaver, proces zatwierdzania | Pobierz próbki użytkowników z dostępem do PII, zweryfikuj zatwierdzenie, potrzebę biznesową, MFA i ostatni przegląd dostępu |
| Onboarding podmiotu przetwarzającego | Przejrzyj kryteria due diligence, klauzule DPA, reguły dotyczące dalszych podmiotów przetwarzających, zabezpieczenia transferu | Pobierz próbkę podmiotu przetwarzającego, sprawdź ocenę, umowę, przegląd bezpieczeństwa i dowody monitorowania dalszych podmiotów przetwarzających |
| Retencja i usuwanie | Przejrzyj harmonogram retencji, reguły wyjątków, procedurę usuwania, możliwości systemu | Pobierz próbki usuniętych rekordów albo żądań usunięcia, sprawdź logi, zgłoszenia i potwierdzenia od podmiotów przetwarzających |
| Obsługa naruszeń | Przejrzyj klasyfikację incydentów, eskalację w zakresie prywatności, kryteria zgłoszenia do organu | Pobierz próbki rejestrów incydentów, zweryfikuj triage, uzasadnienie decyzji, zgłoszenia i wyciągnięte wnioski |
Audit and Compliance Monitoring Policy określa cel wprost:
Walidacja skuteczności zabezpieczeń bezpieczeństwa informacji i prywatności
Z sekcji „Cel”, klauzula polityki 1.1.1.
Wersja dla MŚP utrzymuje tę samą zasadę zapewnienia w języku operacyjnym. Audit and Compliance Monitoring Policy - SME stanowi:
Niniejsza polityka określa podejście organizacji do prowadzenia audytów wewnętrznych, przeglądów zabezpieczeń bezpieczeństwa i monitorowania zgodności. Zapewnia, że wszystkie zabezpieczenia, polityki, systemy i dostawcy usług podlegają regularnym i ustrukturyzowanym przeglądom.
Z sekcji „Cel”, klauzula polityki 1.1.
Gotowość do ISO 27701 nie zależy od wielkości spółki. Trzydziestoosobowy podmiot przetwarzający SaaS może nie potrzebować takich samych narzędzi audytowych jak globalny bank, ale nadal musi wykazać, że dostęp, usuwanie, eskalacja incydentów, nadzór nad dalszymi podmiotami przetwarzającymi i retencja dowodów są kontrolowane.
Łańcuch dowodowy Clarysec: REG03, REG12, CAPA i przegląd
Clarysec strukturyzuje testowanie zabezpieczeń dotyczących prywatności wokół prostego łańcucha dowodowego.
REG03 definiuje stosowalne zabezpieczenia PIMS i status wdrożenia. REG12 rejestruje próbki, dowody, ustalenia, luki identyfikowalności, weryfikację działań korygujących oraz dane wejściowe do przeglądu zarządzania. Zapisy CAPA przekształcają ustalenia w usprawnienia oparte na analizie przyczyny źródłowej. Najwyższe kierownictwo przegląda skuteczność PIMS, ryzyka, niezgodności, działania korygujące i decyzje doskonalące.
PIMS Documented Information and Evidence Management Policy wymaga rejestrowania problemów z jakością dowodów:
[Wszystkie wersje] Audytor wewnętrzny / osoba dokonująca przeglądu zgodności MUSI rejestrować kompletność, prawidłowość albo luki identyfikowalności dowodów w REG12 podczas każdego zaplanowanego audytu lub przeglądu zgodności.
Z sekcji „Tworzenie, nazewnictwo i jakość dowodów”, klauzula polityki 4.3.4.
Ma to znaczenie, ponieważ nie każde ustalenie oznacza całkowitą nieskuteczność zabezpieczenia. Czasami zabezpieczenie zadziałało, ale dowody są niekompletne. Czasami zgłoszenie usunięcia zostało zamknięte, ale żaden log systemowy nie potwierdza usunięcia. Czasami rejestr czynności przetwarzania wskazuje CRM, ale pomija eksport do hurtowni danych. Czasami umowa z dostawcą istnieje, ale brakuje bieżącego monitorowania.
Audit and Compliance Monitoring Policy wymaga także ustrukturyzowanych audytów wewnętrznych:
Audyty wewnętrzne należy prowadzić zgodnie z udokumentowaną procedurą obejmującą:
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.
A gdy wystąpią ustalenia:
Wszystkie ustalenia muszą skutkować udokumentowanym CAPA obejmującym:
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.
Risk Management Policy - SME wzmacnia dyscyplinę zamykania działań:
Zakończenie i skuteczność działań w zakresie postępowania z ryzykiem muszą zostać zweryfikowane.
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.3.2.
PIMS Monitoring, Audit and Improvement Policy zamyka pętlę:
[Wszystkie wersje] Audytor wewnętrzny / osoba dokonująca przeglądu zgodności MUSI zweryfikować skuteczność działań korygujących w REG12 w ciągu 30 dni od zgłoszonego zamknięcia działania korygującego.
Z sekcji „Niezgodność i działanie korygujące”, klauzula polityki 4.4.7.
To różnica między naprawieniem zgłoszenia a doskonaleniem systemu zarządzania.
Test praktyczny 1: żądania usunięcia danych i rozliczalność GDPR
Żądania usunięcia danych są jednym z najczytelniejszych sposobów testowania, czy rozliczalność w zakresie prywatności działa w praktyce.
Załóżmy, że średniej wielkości spółka SaaS działa zarówno jako administrator, jak i podmiot przetwarzający. Kontroluje dane pracowników, dane marketingowe i dane rozliczeniowe. Przetwarza dane użytkowników końcowych klientów w imieniu klientów korporacyjnych. Organizacja chce przetestować, czy zabezpieczenia dotyczące usuwania danych są gotowe do audytu ISO 27701:2025 oraz do zapewnienia dla klientów w zakresie GDPR.
Krok 1: Wybierz czynność przetwarzania z REG03
Wybierz czynność przetwarzania z rzeczywistym ryzykiem dla prywatności, na przykład „dane profilu użytkownika końcowego klienta przetwarzane na platformie SaaS”. Potwierdź, czy organizacja działa jako administrator, podmiot przetwarzający, czy w obu rolach. Zidentyfikuj powiązane zabezpieczenia dla obsługi praw, walidacji poleceń podmiotu przetwarzającego, retencji, usuwania, kontroli dostępu, rejestrowania, postępowania z kopiami zapasowymi i koordynacji z dostawcami.
Krok 2: Zdefiniuj precyzyjny cel testu
Użyteczny cel testu jest konkretny i oparty na dowodach:
„Zweryfikować, czy żądania usunięcia danych profilu użytkownika końcowego klienta są przyjmowane, uwierzytelniane albo walidowane względem polecenia, realizowane w zdefiniowanym procesie, rejestrowane, technicznie wykonywane w systemach produkcyjnych, kaskadowo przekazywane właściwym dalszym podmiotom przetwarzającym tam, gdzie jest to wymagane, oraz zamykane z dowodami”.
Krok 3: Pobierz reprezentatywną próbkę
Wybierz pięć żądań usunięcia z ostatniego kwartału. Uwzględnij jedno rutynowe żądanie, jedno żądanie obejmujące administratora klienta, jedno żądanie wynikające z polecenia podmiotu przetwarzającego, jedno żądanie z wyjątkiem od retencji oraz jedno żądanie obejmujące postępowanie z kopiami zapasowymi.
Zenith Blueprint, w fazie Audyt, przegląd i doskonalenie, Krok 26: Realizacja audytu, podkreśla znaczenie próbkowania i gromadzenia dowodów:
✓ Przeprowadź wywiady z właściwym personelem: poproś osoby odpowiedzialne za procesy, aby wyjaśniły, w jaki sposób spełniają wymagania. Na przykład zapytaj właściciela ryzyka o ostatnią ocenę ryzyka albo zapytaj HR, w jaki sposób nowi pracownicy są szkoleni z bezpieczeństwa (aby objąć zabezpieczenie 6.3 dotyczące świadomości).
✓ Przejrzyj dokumentację: sprawdź, czy dokumenty i zapisy istnieją oraz są aktualne.
✓ Obserwuj praktyki: jeżeli to możliwe, przeprowadź bezpośrednią obserwację.
✓ Pobierz próbki i przeprowadź wyrywkową kontrolę: nie da się sprawdzić wszystkiego, dlatego stosuj próbkowanie.
Z fazy Audyt, przegląd i doskonalenie, Krok 26: Realizacja audytu (prowadzenie audytu wewnętrznego).
Krok 4: Sprawdź dowody dla każdej próbki
Dla każdego próbkowanego żądania zgromadź zgłoszenie przyjęcia, klasyfikację roli, weryfikację tożsamości albo autoryzację klienta, systemowy log usunięcia, decyzję o wyjątku od retencji, wyjaśnienie dotyczące postępowania z kopiami zapasowymi, powiadomienie dalszego podmiotu przetwarzającego, komunikację zamykającą, znaczniki czasu oraz akceptację osoby dokonującej przeglądu.
Krok 5: Zarejestruj wyniki w REG12
Zarejestruj w REG12 próbkę, źródło dowodu, wynik kontroli, wyjątek i lukę identyfikowalności. Jeżeli usunięcie nastąpiło, ale nie istnieje log produkcyjny, zabezpieczenie mogło zadziałać, lecz dowody są słabe. Jeżeli żądanie było opóźnione, ponieważ odpowiedzialność dostawcy była niejasna, ustalenie może dotyczyć nadzoru nad stronami trzecimi i przenoszenia obowiązków umownych.
Krok 6: Utwórz CAPA i zweryfikuj skuteczność
Jeżeli przyczyną źródłową jest niejasny podział odpowiedzialności między wsparciem, działem prawnym i zespołem inżynieryjnym, CAPA może obejmować zmieniony proces, zaktualizowane RACI, obowiązkowe pola dowodowe oraz comiesięczne kontrole próbek usunięć.
Zenith Blueprint, w fazie Audyt, przegląd i doskonalenie, Krok 29, wyjaśnia oczekiwania dotyczące zamknięcia:
Zaplanuj, w jaki sposób będziesz weryfikować skuteczność każdego działania korygującego. Może to oznaczać zaplanowanie audytu następczego albo kontroli. Na przykład, jeżeli działaniem korygującym było przeszkolenie personelu IT z kontroli dostępu, możesz zaplanować przegląd nowych kont za miesiąc, aby sprawdzić, czy wszystkie mają właściwe zatwierdzenia (weryfikacja).
Z fazy Audyt, przegląd i doskonalenie, Krok 29: Ciągłe doskonalenie (działania korygujące i wyciągnięte wnioski).
W przypadku usuwania weryfikacja może oznaczać pobranie próbki kolejnych pięciu żądań usunięcia po uruchomieniu zmienionego procesu w środowisku produkcyjnym. Dopiero wtedy CAPA powinno zostać zamknięte.
Test praktyczny 2: ograniczenie celu i minimalizacja danych
Drugim testem o wysokiej wartości jest ograniczenie celu. Jest to szczególnie użyteczne przed due diligence klienta, uruchomieniem analityki, wzbogacaniem AI, rozbudową hurtowni danych albo zmianami w automatyzacji marketingu.
Platforma SaaS Marii gromadzi dane użytkowników klientów w celu świadczenia usługi. Celem zabezpieczenia jest zapewnienie, że PII jest wykorzystywane wyłącznie w określonych i zgodnych z prawem celach oraz nie jest ponownie wykorzystywane do analityki marketingowej, chyba że użytkownik udzielił odrębnej, wyraźnej zgody tam, gdzie jest to wymagane.
| Rodzaj dowodu | Konkretne artefakty |
|---|---|
| Dokumentacja | Polityka ochrony danych i prywatności, RoPA, DPA klienta, klauzule informacyjne, zapisy zarządzania zgodami |
| Konfiguracja techniczna | Reguły postępowania z danymi w aplikacji, schematy baz danych, konfiguracje API, ustawienia zadań ETL |
| Logi i zapisy | Logi dostępu aplikacji, logi zapytań do baz danych, historia zmian zgód, zapisy eksportów kampanii |
| Dowody osobowe | Wywiady z właścicielem produktu, głównym programistą, administratorem bazy danych, właścicielem obszaru prywatności |
Silny test skuteczności działania nie kończy się na polityce. Obejmuje próbki użytkowników, którzy wyrazili zgodę na marketing, oraz użytkowników, którzy jej nie wyrazili. Śledzi, czy status zgody jest prawidłowo odzwierciedlany w podstawowych bazach aplikacyjnych, tabelach hurtowni danych, narzędziach kampanijnych, pulpitach i eksportach. Jeżeli użytkownicy bez zgody pojawiają się w grupie odbiorców marketingowych, organizacja ma konkretną niezgodność.
Wersja MŚP Audit and Compliance Monitoring Policy pokazuje właściwe podejście przez przykład testowania technicznego:
Weryfikacja zabezpieczeń technicznych (np. status kopii zapasowych, konfiguracja kontroli dostępu, zapisy poprawek)
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.2.
W obszarze prywatności weryfikacja zabezpieczeń technicznych obejmuje kontrole synchronizacji zgód, eksporty kontroli dostępu, logi usuwania, ustawienia szyfrowania, testy maskowania danych, alerty DLP, ograniczenia dotyczące kopii zapasowych, zdarzenia monitorowania oraz dowody od dostawców.
Mapowanie testowania prywatności na ISO/IEC 27001:2022 i zgodność między ramami Clarysec
Zabezpieczenia dotyczące prywatności nie działają w izolacji. Ochrona PII zależy od inwentarza aktywów, klasyfikacji, kontroli dostępu, nadzoru nad chmurą obliczeniową, maskowania danych, przekazywania informacji, rejestrowania, monitorowania, usuwania, ochrony zapisów, nadzoru nad dostawcami i niezależnego przeglądu.
W Zenith Controls: przewodniku zgodności między ramami zabezpieczenie ISO/IEC 27001:2022 Annex A 5.34, Prywatność i ochrona PII, jest zmapowane jako zabezpieczenie zapobiegawcze dostosowane do poufności, integralności i dostępności, z koncepcjami cyberbezpieczeństwa Identify i Protect oraz zdolnościami operacyjnymi w obszarze ochrony informacji oraz prawa i zgodności.
Jego związek z inwentaryzacją jest bezpośredni:
Inwentarz aktywów informacyjnych (5.9) powinien obejmować zasoby danych PII (bazy klientów, akta HR). Wspiera to 5.34, zapewniając, że organizacja wie, jakie PII posiada i gdzie się ono znajduje, co jest pierwszym krokiem do jego ochrony.
Z Zenith Controls, Prywatność i ochrona PII, zabezpieczenie 5.34.
Dla testowania audytowego oznacza to, że audytor prywatności nie powinien zaczynać wyłącznie od klauzuli informacyjnej. Powinien zacząć od inwentarza PII, rejestru czynności przetwarzania, przepływów danych, inwentarza aktywów i inwentarza dostawców. Jeżeli inwentarz jest niekompletny, dalsze zabezpieczenia prywatności nie mogą być w pełni wiarygodne.
Przewodnik mapuje również zabezpieczenie ISO/IEC 27001:2022 Annex A 5.34 na powiązane zabezpieczenia, takie jak 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 5.14 Information transfer, 5.15 Access control, 5.16 Identity management, 5.23 Information security for use of cloud services, 5.33 Protection of records, 8.11 Data masking, 8.12 Data leakage prevention oraz 8.10 Information deletion.
Szczególnie istotne są dwa dodatkowe zabezpieczenia ISO/IEC 27001:2022 Annex A:
| Zabezpieczenie ISO/IEC 27001:2022 | Znaczenie dla testowania prywatności | Przykładowe dowody |
|---|---|---|
| 5.34 Privacy and protection of PII | Potwierdza, że wymagania dotyczące prywatności i ochrony PII są wdrożone na podstawie przepisów prawa, regulacji i umów | Rejestr czynności przetwarzania, DPIA, zapisy podstaw prawnych, dowody DSR, logi retencji |
| 5.35 Independent review of information security | Zapewnia obiektywną walidację, że rozwiązania bezpieczeństwa, w tym zabezpieczenia istotne dla prywatności, są niezależnie przeglądane | Raporty z audytu wewnętrznego, wyniki przeglądów zewnętrznych, próbki REG12, zapisy CAPA |
| 5.36 Compliance with policies, rules and standards for information security | Potwierdza bieżącą zgodność z wewnętrznymi zasadami i standardami | Przeglądy zgodności z politykami, kontrole dostępu, wyniki monitorowania, rejestry wyjątków |
Data Protection and Privacy Policy wymaga:
Wewnętrzny audyt zgodności w zakresie prywatności należy przeprowadzać co roku albo po istotnych zmianach organizacyjnych lub regulacyjnych. Zakres audytu powinien obejmować:
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.4.
Dalej obejmuje:
Skuteczność środków technicznych i organizacyjnych
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.4.1.
Data Protection and Privacy Policy - SME utrzymuje to samo oczekiwanie w praktycznej formie:
Regularne audyty prywatności lub kontrole zabezpieczeń muszą być wykonywane i rejestrowane
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.3.
Dlaczego rozliczalność GDPR jest obecnie kwestią ładu cyberbezpieczeństwa
Dowody dotyczące prywatności nie są już wymagane wyłącznie przez audytorów prywatności. Tych samych dowodów może zażądać audytor ISO 27701:2025, audytor ISO/IEC 27001:2022, osoba dokonująca przeglądu GDPR, właściwy organ NIS2, klient regulowany przez DORA, asesor NIST CSF albo komitet ds. ryzyka Rady Dyrektorów.
NIS2 Article 21 wymaga od podmiotów kluczowych i ważnych wdrożenia odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych do zarządzania ryzykiem cyberbezpieczeństwa. Article 21(2)(f) wprost obejmuje polityki i procedury służące ocenie skuteczności środków zarządzania ryzykiem cyberbezpieczeństwa. NIS2 przypisuje również organom zarządzającym odpowiedzialność za zatwierdzanie i nadzorowanie środków zarządzania ryzykiem cyberbezpieczeństwa.
DORA obowiązuje od 17 stycznia 2025 r. wobec podmiotów finansowych i ustanawia szczegółowy zestaw zasad cyfrowej odporności operacyjnej. Wymaga zarządzania ryzykiem ICT, nadzoru organu zarządzającego, audytu wewnętrznego, remediacji ustaleń krytycznych, klasyfikacji i zgłaszania incydentów, testowania odporności, zarządzania ryzykiem ICT stron trzecich, kontroli umownych, rejestrów uzgodnień dotyczących usług ICT oraz strategii wyjścia. Dostawcy ICT obsługujący podmioty finansowe powinni oczekiwać żądań dowodowych wynikających z DORA w ramach zapewnienia dla klientów.
NIST CSF 2.0 zapewnia użyteczną warstwę tłumaczącą. Funkcja GOVERN oczekuje, że organizacje rozumieją oczekiwania interesariuszy, zależności oraz obowiązki prawne, regulacyjne, umowne, dotyczące prywatności i wolności obywatelskich. Podejście Profiles pomaga porównać bieżące wyniki z wynikami docelowymi, zidentyfikować luki i priorytetyzować plany działań.
| Presja wymagań | Co powinno wytworzyć testowanie zabezpieczeń dotyczących prywatności | Punkt odniesienia Clarysec |
|---|---|---|
| Rozliczalność GDPR | Dowody, że zasady, podstawa prawna, prawa, bezpieczeństwo, retencja i obowiązki podmiotu przetwarzającego są możliwe do wykazania | Polityki PIMS, REG03, REG12, CAPA |
| Gotowość do ISO 27701:2025 | Przetestowane zabezpieczenia PIMS, stosowalność oparta na rolach, jakość dowodów, audyt wewnętrzny, przegląd zarządzania | PIMS Monitoring, Audit and Improvement Policy |
| Zapewnienie ISO/IEC 27001:2022 | Identyfikowalność postępowania z ryzykiem, uzasadnienie SoA, kontrola operacyjna, audyt, przegląd, doskonalenie | Zenith Blueprint, przewodnik zgodności między ramami Zenith Controls |
| Ład zarządczy NIS2 | Ocena skuteczności, gotowość do obsługi incydentów, kontrole dostawców, nadzór organu zarządzającego | Mapowanie zabezpieczeń ISO/IEC 27001:2022 Annex A 5.35 i 5.36 |
| Zapewnienie DORA | Testowanie zabezpieczeń ICT, testowanie odporności, dowody od stron trzecich, zapisy cyklu życia incydentów | Model dowodów audytowych mapowany między ramami |
| NIST CSF 2.0 | Profil bieżący, profil docelowy, analiza luk, priorytetyzowane doskonalenie | Zenith Blueprint kroki 24, 26, 29 |
Zenith Blueprint wzmacnia identyfikowalność w Kroku 24:
Twoja SoA powinna być spójna z rejestrem ryzyk i planem postępowania z ryzykiem. Sprawdź ponownie, czy każda kontrola wybrana jako działanie w ramach postępowania z ryzykiem jest oznaczona w SoA jako „Stosowalna”. Odwrotnie, jeżeli kontrola jest oznaczona w SoA jako „Stosowalna”, należy mieć dla niej uzasadnienie – zwykle zmapowane ryzyko, wymaganie prawne/regulacyjne albo potrzebę biznesową.
Z fazy Audyt, przegląd i doskonalenie, Krok 24: Audyt, przegląd i doskonalenie.
W przypadku testowania zabezpieczeń dotyczących prywatności ta sama zasada dotyczy stosowalności PIMS. Każde stosowalne zabezpieczenie prywatności powinno być powiązane z ryzykiem przetwarzania, obowiązkiem prawnym, wymaganiem klienta albo potrzebą biznesową. Każdy test powinien odwoływać się do tego zabezpieczenia.
Jak różni audytorzy ocenią to samo zabezpieczenie
Silny program testowania prywatności uwzględnia perspektywę audytora. To samo zabezpieczenie dotyczące usuwania, kontrola dostępu albo kontrola onboardingu podmiotu przetwarzającego będą interpretowane inaczej w zależności od kontekstu przeglądu.
| Perspektywa audytora | Prawdopodobne pytanie audytowe | Oczekiwane dowody |
|---|---|---|
| Audytor ISO 27701:2025 | Czy zabezpieczenia PIMS oparte na rolach są wdrożone, oceniane i doskonalone? | Stosowalność REG03, próbki REG12, rejestr czynności przetwarzania, mapowanie polityk, wyniki audytu |
| Audytor ISO/IEC 27001:2022 | Czy zabezpieczenie związane z prywatnością jest zintegrowane z postępowaniem z ryzykiem, SoA, kontrolą operacyjną, audytem wewnętrznym i przeglądem zarządzania? | Rejestr ryzyk, uzasadnienie SoA, plan postępowania z ryzykiem, dowody zabezpieczeń, protokoły przeglądu zarządzania |
| Osoba dokonująca przeglądu GDPR | Czy administrator może wykazać zgodność z zasadami i obowiązkami GDPR? | Podstawa prawna, klauzule informacyjne, logi DSR, DPIA, umowy, zapisy naruszeń, dowody retencji |
| Asesor NIST CSF | Czy organizacja zna obowiązki, definiuje wyniki docelowe, mierzy luki i doskonali działania? | Profil bieżący i docelowy, plan luk, priorytetyzacja ryzyka, zapisy ładu zarządczego |
| Klient lub regulator zorientowany na DORA | Czy zabezpieczenia ICT są testowane, incydenty klasyfikowane, dostawcy monitorowani, a usługi krytyczne odporne? | Program testowania, rejestry incydentów, rejestr dostawców, umowy, plany wyjścia |
| Audytor ISACA albo w stylu COBIT 2019 | Czy cele, odpowiedzialność, metryki, zamykanie zagadnień i nadzór zarządczy są skuteczne? | RACI, KPI, rejestry zagadnień, weryfikacja CAPA, raportowanie zarządcze |
Dlatego REG12 jest tak wartościowy. Przekształca zgodność w zakresie prywatności w dowody ładu zarządczego możliwe do sprawdzenia audytowo.
Typowe ustalenia w testowaniu zabezpieczeń PIMS
Clarysec wielokrotnie obserwuje te same ustalenia audytowe dotyczące prywatności w organizacjach przygotowujących się do certyfikacji ISO 27701:2025, zapewnienia dla klientów w zakresie GDPR albo korporacyjnego due diligence.
Rejestr czynności przetwarzania nie odpowiada rzeczywistości systemowej
Rejestr czynności przetwarzania wymienia CRM i platformy wsparcia, ale inżynierowie dodali eksporty analityczne, logi obserwowalności, narzędzia AI i tabele hurtowni danych.
Reakcja testowa: pobierz próbki systemów z inwentarza aktywów i inwentarza chmurowego, a następnie uzgodnij je z rejestrem czynności przetwarzania. Wykorzystaj relację między zabezpieczeniami ISO/IEC 27001:2022 Annex A 5.9 i 5.34 jako uzasadnienie audytowe.
Dostęp do PII jest zatwierdzony, ale nie jest okresowo przeglądany
Wstępne zatwierdzenia istnieją, ale przeglądy dostępu uprzywilejowanego nie obejmują narzędzi impersonacji wsparcia, produkcyjnych baz danych, pulpitów BI ani kont awaryjnych.
Reakcja testowa: pobierz próbki aktywnych użytkowników z dostępem do PII i porównaj rolę, potrzebę biznesową, zatwierdzenie, status MFA, ostatnie logowanie i dowody przeglądu.
Umowy z podmiotami przetwarzającymi istnieją, ale monitorowanie jest słabe
DPA jest podpisana, ale kwestionariusz dostawcy jest nieaktualny. Nikt nie przejrzał zmian dalszych podmiotów przetwarzających, lokalizacji danych, profilu ryzyka w obszarze bezpieczeństwa ani obowiązków dotyczących zgłoszenia incydentu.
Reakcja testowa: pobierz próbki krytycznych podmiotów przetwarzających i sprawdź due diligence, klauzule umowne, zmiany dalszych podmiotów przetwarzających, zabezpieczenia transferu oraz zapisy monitorowania. Wspiera to GDPR, oczekiwania NIS2 dotyczące łańcucha dostaw oraz oczekiwania DORA dotyczące ryzyka stron trzecich.
Reagowanie na incydenty istnieje, ale klasyfikacja prywatności jest niespójna
Incydenty bezpieczeństwa są rejestrowane, ale wpływ na prywatność nie zawsze jest oceniany. Kryteria naruszenia GDPR nie są konsekwentnie dokumentowane. Obowiązki powiadomienia klienta są obsługiwane nieformalnie.
Reakcja testowa: pobierz próbki incydentów obejmujących ekspozycję danych i sprawdź klasyfikację, eskalację w zakresie prywatności, przegląd prawny, decyzje dotyczące powiadomień, zachowanie dowodów, przyczynę źródłową i wyciągnięte wnioski.
CAPA jest zamykane bez weryfikacji skuteczności
Procedura zostaje zaktualizowana, a ustalenie zamknięte. Nikt nie testuje, czy kolejna próbka uległa poprawie.
Reakcja testowa: zweryfikuj skuteczność działań korygujących w REG12 w ciągu 30 dni od zgłoszonego zamknięcia, zgodnie z wymaganiem PIMS Monitoring, Audit and Improvement Policy.
90-dniowy sprint testowania zabezpieczeń dotyczących prywatności
Organizacjom zmierzającym do gotowości ISO 27701:2025, due diligence klienta albo przeglądu rozliczalności GDPR Clarysec rekomenduje skoncentrowany 90-dniowy sprint.
| Oś czasu | Obszar koncentracji | Rezultaty |
|---|---|---|
| Dni 1–15 | Zakres i model dowodowy | Role PIMS, rejestr czynności przetwarzania, stosowalność REG03, ryzyka priorytetowe, obowiązki prawne, zależności od dostawców, reguły nazewnictwa dowodów |
| Dni 16–35 | Testowanie projektu | Przegląd polityk, RACI, klauzule informacyjne, podstawa prawna, kryteria DPIA, procesy DSR, klasyfikacja incydentów, harmonogramy retencji, kontrole dostawców |
| Dni 36–65 | Testowanie skuteczności działania | Próbki dotyczące dostępu, usuwania, incydentów, podmiotów przetwarzających, transferów, retencji, szkoleń, monitorowania technicznego, dowody REG12 |
| Dni 66–80 | CAPA i postępowanie z ryzykiem | Przyczyna źródłowa, działanie korygujące, właściciel, termin realizacji, ryzyko szczątkowe, metoda weryfikacji |
| Dni 81–90 | Gotowość do przeglądu zarządzania | Pakiet skuteczności PIMS, cele, otwarte ryzyka, niezgodności, działania korygujące, problemy dostawców, decyzje doskonalące |
Do końca sprintu organizacja powinna być w stanie odpowiedzieć na pytania, które audytorzy faktycznie zadają:
- Jakie PII przetwarzacie?
- W jakiej roli?
- Które zabezpieczenia mają zastosowanie?
- Dlaczego są stosowalne?
- Jakie dowody potwierdzają ich wdrożenie?
- Jaka próbka potwierdza ich działanie?
- Jakie luki stwierdzono?
- Jakie działania korygujące podjęto?
- Kto zweryfikował skuteczność?
- Co najwyższe kierownictwo przeglądało i o czym zdecydowało?
Od papierowej prywatności do możliwej do wykazania rozliczalności
Certyfikat ISO 27701 ma wartość, ale nie jest celem końcowym. Klienci, organy nadzorcze, rady i audytorzy coraz częściej oczekują dowodów, że zabezpieczenia dotyczące prywatności są zaprojektowane, wdrożone, monitorowane, korygowane i objęte nadzorem zarządczym.
Zgodność w zakresie prywatności zawodzi, gdy jest traktowana jako projekt dokumentacyjny. Wytrzymuje weryfikację, gdy staje się przetestowanym systemem dowodów.
Clarysec pomaga organizacjom przejść od deklarowanej zgodności do możliwej do wykazania rozliczalności przez połączenie polityk PIMS, stosowalności REG03, próbek dowodowych REG12, weryfikacji CAPA, przeglądu zarządzania i mapowania między ramami za pomocą Zenith Blueprint: 30-etapowa mapa drogowa audytora oraz Zenith Controls: przewodnik zgodności między ramami.
Jeżeli Twoja organizacja przygotowuje się do certyfikacji ISO 27701:2025, przeglądu rozliczalności GDPR, zapewnienia dla klientów w zakresie prywatności, dowodów ładu zarządczego NIS2 albo due diligence dostawcy wynikającego z DORA, zacznij od skoncentrowanych warsztatów testowania zabezpieczeń dotyczących prywatności.
Clarysec może pomóc zmapować stosowalność REG03, zbudować próbki audytowe REG12, przetestować priorytetowe zabezpieczenia PIMS, powiązać ustalenia z CAPA oraz przygotować rezultaty przeglądu zarządzania, które wytrzymają weryfikację.
Następny audyt prywatności nie powinien być gorączkową zbiórką zrzutów ekranu. Powinien być pewnym wykazaniem, że prywatność działa, jest potwierdzona dowodami, przeglądana i stale doskonalona.
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council