ISO 27701:2025: dowody z PIMS na potrzeby audytów GDPR

Jest czwartek, 08:40. Ava, kierowniczka ds. zgodności w FinScale, właśnie otworzyła wiadomość e-mail, którą prędzej czy później otrzymuje każda szybko rosnąca spółka B2B SaaS.

Duży niemiecki klient korporacyjny przesłał kwestionariusz due diligence GDPR z terminem odpowiedzi 48 godzin. Nie prosi o politykę prywatności. Nie zadowala go certyfikat. Żąda dowodów.

Przedstawcie Record of Processing Activities dla naszych danych. Pokażcie dowody due diligence przy onboardingu dalszych podmiotów przetwarzających. Wyjaśnijcie, w jaki sposób dokumentujecie swoje obowiązki wynikające z GDPR Article 28. Wskażcie, czy wasza platforma działa jako administrator PII, podmiot przetwarzający, współadministrator albo dalszy podmiot przetwarzający dla każdego przepływu pracy. Udowodnijcie, że podstawa prawna została zwalidowana dla funkcji wsparcia wspomaganej AI. Pokażcie obowiązki usuwania, prawo do audytu, wsparcie w obsłudze incydentów oraz kontrole umowne.

Ava wie, że FinScale ma potrzebne elementy. Dział prawny ma umowę powierzenia przetwarzania danych (DPA). Zespół bezpieczeństwa ma ISO/IEC 27001:2022 Statement of Applicability. Produkt ma listy kontrolne uruchomienia. Zakupy mają umowy z dostawcami. Zespół zgodności ma rejestr przetwarzania, choć część wpisów jest nieaktualna. Problem nie polega na tym, że dowody nie istnieją. Problem polega na tym, że dowody są rozproszone, niejednoznaczność ról pozostaje nierozwiązana i nikt nie potrafi szybko prześledzić czynności przetwarzania od celu do podstawy prawnej, decyzji dotyczącej ryzyka, kontroli dostawcy, kontroli bezpieczeństwa, zapisu audytowego i przeglądu zarządzania.

To jest rzeczywista luka w rozliczalności.

ISO 27701:2025 zyskuje największą wartość wtedy, gdy tę lukę zamyka. Privacy Information Management System, czyli PIMS, nie jest tylko segregatorem polityk przygotowanym pod certyfikację prywatności. To model operacyjny wytwarzania wiarygodnych dowodów. Dla CISO, kierowników ds. zgodności, osób odpowiedzialnych za prywatność, audytorów i właścicieli biznesowych cel jest prosty: zbudować PIMS, który potwierdza rozliczalność GDPR dla administratorów i podmiotów przetwarzających PII, a jednocześnie wspiera oczekiwania ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 i COBIT 2019.

Rozliczalność GDPR jest problemem dowodowym

Rozliczalność GDPR bywa błędnie rozumiana jako wymóg dokumentacyjny. W praktyce wymaga znacznie więcej.

GDPR Article 5 definiuje podstawowe zasady przetwarzania danych osobowych, w tym zgodność z prawem, rzetelność, przejrzystość, ograniczenie celu, minimalizację danych, prawidłowość, ograniczenie przechowywania, integralność i poufność. Article 5(2) nakłada na administratora odpowiedzialność za możliwość wykazania zgodności. Article 4 definiuje pojęcia danych osobowych, przetwarzania, administratora, podmiotu przetwarzającego, pseudonimizacji i naruszenia ochrony danych osobowych. Article 6 wymaga podstawy prawnej dla każdej czynności przetwarzania wykonywanej przez administratora. Article 9 wprowadza surowsze warunki dla szczególnych kategorii danych osobowych. Article 28 reguluje obowiązki podmiotu przetwarzającego i postanowienia umowne.

Tych obowiązków nie spełnia sama publiczna klauzula informacyjna. Wymagają one dowodów na poziomie czynności przetwarzania.

Praktyczny model dowodowy PIMS ISO 27701:2025 musi odpowiadać na pytania:

• Jakie PII jest przetwarzane?
• Dlaczego jest przetwarzane?
• Czy organizacja działa jako administrator, podmiot przetwarzający, współadministrator czy dalszy podmiot przetwarzający?
• Jaka podstawa prawna ma zastosowanie, gdy organizacja jest administratorem?
• Jakie udokumentowane polecenie ma zastosowanie, gdy organizacja jest podmiotem przetwarzającym?
• Jakie systemy, dostawcy, dalsze podmioty przetwarzające i lokalizacje są zaangażowane?
• Jaka wstępna ocena ryzyka dla prywatności lub decyzja dotycząca DPIA została podjęta?
• Jakie kontrole bezpieczeństwa chronią PII?
• Jakie dowody potwierdzają, że kontrola zadziałała?
• Kto zatwierdził ryzyko szczątkowe, wyjątki i działania korygujące?

Podejście Clarysec przekształca te pytania w obowiązki wynikające z polityk, rejestry i identyfikowalne obiekty dowodowe. Rezultatem jest PIMS, który wytrzymuje due diligence klienta, przegląd organu nadzorczego, audyt wewnętrzny, audyt ISO, ocenę DORA i nadzór zarządu.

Zacznij od jednoznaczności ról: administrator, podmiot przetwarzający albo obie role

Najszybszym sposobem na niepowodzenie audytu PIMS jest traktowanie każdej czynności przetwarzania w ten sam sposób.

Zgodnie z GDPR administrator określa cele i sposoby przetwarzania. Podmiot przetwarzający przetwarza dane osobowe w imieniu administratora. Wiele spółek SaaS i technologicznych pełni obie role. FinScale jest podmiotem przetwarzającym, gdy hostuje dane użytkowników końcowych klientów na podstawie poleceń klienta. Jest administratorem w odniesieniu do rejestrów pracowników, leadów marketingowych, kontaktów rozliczeniowych, danych rekrutacyjnych i części analityki produktowej.

To rozróżnienie determinuje wymagania dowodowe.

Privacy Information Management System Policy Clarysec czyni klasyfikację ról wymaganiem operacyjnym:

[Both] Właściciel procesu / właściciel biznesowy MUSI sklasyfikować rolę PIMS organizacji dla każdej czynności przetwarzania PII w REG02 przed rozpoczęciem tej czynności przetwarzania.

Ten jeden obowiązek zmienia model operacyjny prywatności. Przegląd prawny nie jest już refleksją po uruchomieniu. Każdy właściciel procesu musi sklasyfikować rolę PIMS przed rozpoczęciem przetwarzania. Ta klasyfikacja określa dalszy łańcuch dowodowy.

W przypadku czynności administratora PII Processing Inventory and Lawful Basis Policy Clarysec wymaga walidacji podstawy prawnej:

[Controller] Osoba odpowiedzialna za prywatność / Menedżer PIMS MUSI zwalidować podstawę prawną zapisaną w REG02 przed rozpoczęciem przetwarzania przez administratora oraz przed wejściem w życie jakiejkolwiek zmiany celu.

Z sekcji „Zapisy celów administratora i podstaw prawnych”, klauzula polityki 4.2.2.

W przypadku czynności podmiotu przetwarzającego punkt ciężkości dowodów przesuwa się na udokumentowane polecenia, kontrole umowne, nadzór nad dalszymi podmiotami przetwarzającymi, środki bezpieczeństwa, obowiązki wsparcia, wsparcie w obsłudze incydentów oraz zwrot albo usunięcie danych po zakończeniu współpracy. Właśnie dlatego REG08 ma krytyczne znaczenie.

Processor, Subprocessor and Third-Party Privacy Management Policy Clarysec wymaga:

[Controller] Osoba odpowiedzialna za prywatność / Menedżer PIMS MUSI zweryfikować, że pola kontroli umownych dotyczących podmiotu przetwarzającego w REG08 obejmują zakres przetwarzania, czas trwania, cel, kategorie PII, kategorie osób, których dane dotyczą, poufność, bezpieczeństwo, autoryzację dalszych podmiotów przetwarzających, wsparcie, audyt lub zapewnienie, zwrot, usunięcie oraz zakończenie współpracy przed zatwierdzeniem.

Z sekcji „Kontrole umowne i udokumentowane polecenia”, klauzula polityki 4.3.2.

REG02 ustanawia czynność przetwarzania i rolę. REG04 obejmuje wstępną ocenę ryzyka dla prywatności. REG08 waliduje kontrole podmiotów przetwarzających, dalszych podmiotów przetwarzających i dostawców. REG12 indeksuje dowody. Razem tworzą łańcuch dowodowy PIMS.

Łańcuch dowodowy PIMS oczekiwany przez audytorów

Silny PIMS nie wymaga od zespołów utrzymywania odłączonych od siebie arkuszy kalkulacyjnych. Definiuje obiekty dowodowe, właścicieli, terminy, cykle przeglądu i ścieżki audytu.

PIMS Documented Information and Evidence Management Policy Clarysec stanowi:

[All] Osoba odpowiedzialna za prywatność / Menedżer PIMS MUSI utrzymywać indeks udokumentowanej informacji PIMS w REG12 przed pierwszą publikacją PIMS, a następnie kwartalnie.

REG12 zapobiega temu, by program prywatności stał się folderem nieaktualnych plików PDF. Informuje audytora, jakie dowody istnieją, gdzie są przechowywane, kto jest ich właścicielem, kiedy były ostatnio przeglądane oraz które czynności przetwarzania, ryzyka, obowiązki lub kontrole wspierają.

Ten łańcuch dowodowy naturalnie odpowiada wymaganiom ISO/IEC 27001:2022 dotyczącym kontekstu, zainteresowanych stron, planowania ryzyka, kontroli operacyjnej, udokumentowanej informacji, oceny wyników, audytu wewnętrznego, przeglądu zarządzania i ciągłego doskonalenia. Łączy się również ze środkami kontrolnymi ISO/IEC 27002:2022, takimi jak 5.2 Role i odpowiedzialności w bezpieczeństwie informacji, 5.20 Uwzględnianie bezpieczeństwa informacji w umowach z dostawcami, 5.21 Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT, 5.34 Prywatność i ochrona PII oraz 8.10 Usuwanie informacji.

Dowody administratora i podmiotu przetwarzającego nie są takie same

Niemiecki klient Avy nie pyta wyłącznie o to, czy FinScale ma polityki prywatności. Klient chce dowodu, że FinScale rozumie, jaką rolę pełni dla każdego przepływu danych.

Gdy FinScale działa jako administrator, musi uzasadnić, dlaczego przetwarza dane. Przykładowo przetwarzanie naliczania wynagrodzeń pracowników może opierać się na niezbędności umowy i obowiązku prawnym. Marketing może opierać się na zgodzie albo prawnie uzasadnionych interesach, zależnie od kontekstu i jurysdykcji. Rekrutacja może wymagać limitów przechowywania, przejrzystości i kontroli dostępu. Dowodem nie jest wyłącznie wybrana podstawa prawna. Jest nim zwalidowany zapis, klauzula informacyjna, reguła retencji, procedura obsługi praw i decyzja dotycząca ryzyka.

Gdy FinScale działa jako podmiot przetwarzający, musi udowodnić, że działa na podstawie udokumentowanych poleceń klienta. Dowody obejmują DPA, konfigurację produktu, logi systemowe, kontrole bezpieczeństwa, autoryzacje dalszych podmiotów przetwarzających, procedury wsparcia, proces wsparcia w przypadku naruszenia, prawo do audytu oraz dowody usunięcia albo zwrotu danych.

P17 Data Protection and Privacy Policy Clarysec wzmacnia wymaganie integracji prywatności z SZBI:

Organizacja powinna utrzymywać formalne ramy ładu prywatności zintegrowane z systemem zarządzania bezpieczeństwem informacji (ISMS) w celu egzekwowania niniejszej polityki.

Z sekcji „Wymagania dotyczące ładu”, klauzula polityki 5.1.

Wersja dla MŚP, Data Protection and Privacy Policy-sme, zachowuje tę samą dyscyplinę dowodową:

Koordynator ds. prywatności musi utrzymywać rejestr wszystkich czynności przetwarzania danych osobowych, obejmujący kategorie danych, cel, podstawę prawną i okresy przechowywania

Wymaga również:

Podstawa prawna (np. zgoda, umowa, obowiązek prawny) musi być udokumentowana w rejestrze przetwarzania

W programach korporacyjnych P17 Data Protection and Privacy Policy dodaje odpowiedzialność właścicielską:

Dział prawny powinien utrzymywać i aktualizować Lawful Basis Register.

Praktyczny przebieg: uruchomienie analityki produktowej

Rozważmy funkcję analityki produktowej, która śledzi nawigację użytkownika, wykorzystanie funkcji, metadane sesji, identyfikator organizacji, rolę użytkownika i informacje o urządzeniu. Produkt chce uzyskać wgląd w sposób używania systemu. Sprzedaż chce metryk adopcji. Customer success chce sygnałów ryzyka odejścia klienta. Dział prawny pyta, czy FinScale jest administratorem czy podmiotem przetwarzającym. Bezpieczeństwo pyta, czy logi zawierają dane osobowe. Zakupy wskazują, że dostawca analityki korzysta z dalszych podmiotów przetwarzających.

Silny PIMS przekształca to w powtarzalny przepływ pracy.

1. Utwórz lub zaktualizuj REG02 przed rozpoczęciem przetwarzania

Właściciel biznesowy zapisuje czynność w REG02. Zapis powinien obejmować cel, kategorie PII, kategorie osób, których dane dotyczą, systemy, okres przechowywania, transfery, środki bezpieczeństwa, klasyfikację roli oraz podstawę prawną albo udokumentowane polecenie.

Jeżeli analityka jest wykorzystywana do własnych celów FinScale związanych z doskonaleniem produktu, FinScale może być administratorem tej czynności. Jeżeli analityka jest wykonywana wyłącznie według ustawień konfigurowanych przez klienta w jego imieniu, FinScale może być podmiotem przetwarzającym. W wielu środowiskach SaaS obie role mogą występować w ramach jednej funkcji, zależnie od przepływu danych i celu.

2. Zwaliduj podstawę prawną albo udokumentowane polecenie

Jeżeli FinScale jest administratorem, osoba odpowiedzialna za prywatność lub dział prawny waliduje podstawę prawną w REG02 przed rozpoczęciem przetwarzania. Jeżeli zaangażowane są szczególne kategorie danych, zespół musi również wskazać odpowiedni warunek z GDPR Article 9 oraz dodatkowe zabezpieczenia.

Jeżeli FinScale jest podmiotem przetwarzającym, dowody muszą wskazywać polecenie klienta. Pytanie brzmi: gdzie znajduje się polecenie, jakie przetwarzanie jest dozwolone i w jaki sposób FinScale udowodni, że postąpił zgodnie z tym poleceniem?

3. Uruchom wstępną ocenę ryzyka dla prywatności w REG04

Privacy Risk Assessment and DPIA Policy Clarysec wymaga:

[Both] Właściciel procesu / właściciel biznesowy MUSI zainicjować wstępną ocenę ryzyka dla prywatności w REG04 przed rozpoczęciem nowego lub istotnie zmienionego przetwarzania PII zapisanego w REG02.

Z sekcji „Wstępna ocena ryzyka dla prywatności”, klauzula polityki 4.1.1.

Ocena powinna uwzględniać wrażliwość, skalę, skutki monitorowania, oczekiwania osób, których dane dotyczą, profilowanie, zautomatyzowane decyzje, transfery transgraniczne, dostęp dostawcy, retencję i skuteczność kontroli. Jeżeli ryzyko jest podwyższone, PIMS powinien uruchomić DPIA i zapisać decyzję.

4. Zaktualizuj REG08 dla dostawców i dalszych podmiotów przetwarzających

Jeżeli zewnętrzny dostawca analityki otrzymuje PII, zakupy, dział prawny i zespół prywatności aktualizują REG08. Pola umowne powinny obejmować zakres, czas trwania, cel, kategorie PII, poufność, bezpieczeństwo, autoryzację dalszych podmiotów przetwarzających, wsparcie, audyt lub zapewnienie, zwrot, usunięcie oraz zakończenie współpracy.

Third-Party and Supplier Security Policy-sme wspiera tę dyscyplinę operacyjną przez wymaganie:

Weryfikacji praktyk postępowania z danymi lub zgodności w zakresie prywatności danych, gdy zaangażowane są dane osobowe umożliwiające identyfikację osoby (PII)

P17 Data Protection and Privacy Policy wymaga również:

Zespoły zakupów, prawny i zgodności powinny weryfikować zgodność z Article 28 of the GDPR oraz wymagać corocznej ponownej oceny wszystkich dostawców wysokiego ryzyka.

5. Zindeksuj dowody w REG12

Na końcu Menedżer PIMS aktualizuje REG12, dodając łącza do REG02, walidacji podstawy prawnej, udokumentowanego polecenia, oceny REG04, DPIA, jeżeli jest wymagana, zapisu dostawcy w REG08, DPA, przeglądu bezpieczeństwa, decyzji retencyjnej, zatwierdzenia produktu i dowodów monitorowania.

Właśnie to przekształca privacy by design w dowody gotowe do audytu.

Wykorzystanie Zenith Blueprint do budowy identyfikowalności

Wiedza o tym, jakie dowody należy zebrać, to tylko połowa wyzwania. Trudniejszą częścią jest zbudowanie systemu, który wiarygodnie je wytwarza.

Zenith Blueprint: An Auditor’s 30-Step Roadmap ujmuje to w fazie ISMS Foundation & Leadership, Step 2: Stakeholder Needs and ISMS Scope. Przewodnik pokazuje, w jaki sposób oczekiwania interesariuszy stają się planowanymi kontrolami:

Klienci
(B2B SaaS)
Poufność danych, dostępność zgodnie z
SLA, zgłoszenie naruszenia w ciągu
24h
Wdrożenie kontroli dostępu, szyfrowania;
plan reagowania na incydenty obejmuje
procedury powiadamiania.

Zawiera również:

Działanie 4.2: Sporządź listę wszystkich istotnych zainteresowanych stron i odnotuj ich wymagania związane z bezpieczeństwem informacji.

Dla ISO 27701:2025 należy rozszerzyć to działanie na prywatność. Zainteresowane strony obejmują klientów, osoby, których dane dotyczą, regulatorów, podmioty przetwarzające, dalsze podmioty przetwarzające, pracowników, zespoły produktowe, audyt wewnętrzny, kierownictwo, klientów z sektora finansowego oraz regulatorów sektorowych tam, gdzie zastosowanie mają NIS2 lub DORA.

W fazie Risk Management, Step 13: Risk Treatment Planning and Statement of Applicability, Zenith Blueprint zaleca identyfikowalność:

Odniesienia krzyżowe do regulacji: jeżeli określone kontrole zostały wdrożone specjalnie w celu spełnienia wymagań GDPR, NIS2 lub DORA, można to odnotować albo w rejestrze ryzyk (jako element uzasadnienia wpływu ryzyka), albo w uwagach SoA.

Tworzy to złotą nić, której oczekują audytorzy: wymaganie, ryzyko, kontrola, właściciel, dowód, wynik testu i działanie doskonalące.

Miejsce Zenith Controls w modelu PIMS

Zenith Controls: The Cross-Compliance Guide Clarysec pomaga zespołom unikać duplikowania programów zgodności przez mapowanie tematów kontroli ISO/IEC 27001:2022 i ISO/IEC 27002:2022 na inne normy, oczekiwania audytowe i wzorce dowodowe.

Dla dowodów PIMS ISO 27701:2025 szczególnie istotne są cztery środki kontrolne ISO/IEC 27002:2022:

• 5.2 Role i odpowiedzialności w bezpieczeństwie informacji
• 5.20 Uwzględnianie bezpieczeństwa informacji w umowach z dostawcami
• 5.21 Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT
• 5.34 Prywatność i ochrona PII

Środek kontrolny 5.2 wspiera jednoznaczność ról. PIMS potrzebuje zdefiniowanej rozliczalności dla Menedżera PIMS, osoby odpowiedzialnej za prywatność, właściciela procesu, właściciela biznesowego, działu prawnego, zakupów, bezpieczeństwa, audytu wewnętrznego i najwyższego kierownictwa.

Środek kontrolny 5.34 wspiera podstawowy obowiązek prywatnościowy. Zenith Blueprint, faza Controls in Action, Step 23, wyjaśnia oczekiwanie audytowe:

Z perspektywy audytu kontrola ta znajduje się coraz częściej w centrum uwagi. Audytorzy, regulatorzy i klienci chcą widzieć:

✓ Gdzie znajduje się PII,
✓ Jaka podstawa prawna reguluje jego przetwarzanie,
✓ Jak ograniczany jest dostęp,
✓ Jak zgłaszane są incydenty,
✓ Oraz jak organizacja respektuje prawa i utrzymuje przejrzystość.

Zenith Blueprint kontynuuje:

Control 5.34 to nie tylko pozycja na liście kontrolnej. To deklaracja etycznej opieki nad danymi.

Środki kontrolne 5.20 i 5.21 łączą dowody PIMS z nadzorem nad dostawcami i łańcuchem dostaw ICT. Zenith Blueprint, faza Controls in Action, Step 23, wymienia tematy umów z dostawcami:

Kluczowe obszary zwykle ujęte w umowach z dostawcami obejmują:

✓ Obowiązki dotyczące poufności, w tym zakres, czas trwania i ograniczenia ujawniania stronom trzecim;
✓ Odpowiedzialności w zakresie kontroli dostępu, takie jak kto może uzyskać dostęp do danych, jak zarządzane są dane uwierzytelniające i jakie monitorowanie funkcjonuje;
✓ Środki techniczne i organizacyjne dotyczące ochrony danych, szyfrowania, bezpiecznej transmisji, kopii zapasowych i zobowiązań dostępnościowych;
✓ Terminy i protokoły zgłaszania incydentów, często z określonymi ramami czasowymi (np. „powiadomienie w ciągu 24 godzin”);
✓ Prawo do audytu, w tym częstotliwość, zakres i dostęp do odpowiednich dowodów (np. raportów z testów penetracyjnych, SoA, certyfikacji);
✓ Kontrole podwykonawców, wymagające od dostawcy przeniesienia równoważnych obowiązków bezpieczeństwa na dalszych partnerów;
✓ Postanowienia na koniec umowy, takie jak zwrot lub zniszczenie danych, odzyskanie aktywów i dezaktywacja kont.

To jest pomost między rozliczalnością GDPR a dowodami SZBI.

Mapowanie dowodów PIMS na GDPR, NIS2, DORA, NIST i COBIT 2019

Dowody dotyczące prywatności rzadko służą tylko jednemu frameworkowi. Dobrze zaprojektowany obiekt dowodowy PIMS może odpowiedzieć na kilka pytań audytowych.

GDPR osadza rozliczalność prywatności w podstawie prawnej, jednoznaczności ról, umowach z podmiotami przetwarzającymi, prawach, obsłudze naruszeń i możliwej do wykazania zgodności.

NIS2 ma znaczenie dla podmiotów kluczowych i ważnych, w tym niektórych dostawców usług chmurowych, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, dostawców centrów danych i organizacji infrastruktury cyfrowej. NIS2 Article 20 nakłada odpowiedzialność za ład cyberbezpieczeństwa na organy zarządzające. Article 21 wymaga odpowiednich środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego rozwoju oprogramowania, oceny skuteczności, szkoleń, kryptografii, bezpieczeństwa HR, kontroli dostępu, zarządzania aktywami oraz MFA albo ciągłego uwierzytelniania tam, gdzie jest to właściwe. Article 23 wprowadza oczekiwania dotyczące zgłaszania istotnych incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin i zgłoszenie incydentu w ciągu 72 godzin.

DORA ma znaczenie dla podmiotów finansowych oraz zewnętrznych dostawców usług ICT w ekosystemach finansowych. DORA Articles 5 i 6 wymagają ładu w zakresie ryzyka ICT, polityk, strategii, testowania i ciągłego doskonalenia. Articles 17 to 19 obejmują wykrywanie, klasyfikację, eskalację i zgłaszanie incydentów ICT, analizę przyczyny źródłowej oraz wyciągnięte wnioski. Articles 28 to 30 wymagają strategii zarządzania ryzykiem stron trzecich ICT, rejestrów, due diligence, postanowień umownych, prawa do audytu, wsparcia incydentowego, ochrony danych, planowania wyjścia i przeglądu ryzyka koncentracji.

NIST CSF 2.0 zapewnia język ładu i ryzyka przez GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND oraz RECOVER. COBIT 2019 dodaje cele ładu, praktyki zarządzania, własność, metryki, zapewnienie i zdolność procesową.

Korzyść zgodności jest oczywista. Jeden kontrolowany łańcuch dowodowy PIMS może wspierać GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0, COBIT 2019 i due diligence klientów.

Jak audytorzy będą testować twój PIMS

Audyt PIMS nie jest przeglądem dokumentów. To ćwiczenie z identyfikowalności dowodów.

P33 Audit and Compliance Monitoring Policy Clarysec wspiera model audytu:

Organizacja powinna utrzymywać Rejestr audytów zawierający:

Odpowiednik dla MŚP, Audit and Compliance Monitoring Policy-sme, dodaje ważny wymóg jakości dowodów:

Metadane (np. kto je zebrał, kiedy i z jakiego systemu) muszą być udokumentowane.

Ten wymóg dotyczący metadanych jest niewielki, ale bardzo istotny. Zrzuty ekranu bez źródła, daty, osoby zbierającej i kontekstu systemowego są słabym dowodem. Kontrolowany dowód z audytu potwierdza autentyczność, aktualność i identyfikowalność.

Jak wyglądają dobre dowody PIMS

Załóżmy, że audytor wybiera jedną czynność: analizę zgłoszeń obsługi klienta.

Słaba odpowiedź brzmi: „Mamy politykę prywatności, a nasza DPA to obejmuje”.

Silna odpowiedź PIMS wygląda następująco:

1. REG02 identyfikuje czynność, systemy, kategorie PII, osoby, których dane dotyczą, cel, klasyfikację roli, retencję, transfery, kontrole bezpieczeństwa i właściciela.
2. Klasyfikacja roli pokazuje, czy organizacja jest administratorem, podmiotem przetwarzającym, czy pełni obie role dla konkretnych części przepływu pracy.
3. Jeżeli jest administratorem, podstawa prawna jest zwalidowana i zapisana w Lawful Basis Register.
4. Jeżeli jest podmiotem przetwarzającym, powiązane są polecenie klienta i klauzula DPA.
5. REG04 pokazuje wstępną ocenę ryzyka dla prywatności przed uruchomieniem lub istotną zmianą.
6. REG08 identyfikuje platformę zgłoszeniową, dostawcę podsumowań AI, dalsze podmioty przetwarzające, kontrole umowne, prawo do audytu, zapewnienia bezpieczeństwa, warunki usuwania i wsparcie w obsłudze incydentów.
7. Dowody kontroli dostępu pokazują, że dostęp personelu wsparcia jest oparty na rolach i przeglądany.
8. Dowody rejestrowania i monitorowania pokazują, że dostęp do zgłoszeń wsparcia jest monitorowany.
9. Dowody retencji i usuwania pokazują, że zgłoszenia są usuwane albo anonimizowane zgodnie z zatwierdzonym okresem przechowywania.
10. REG12 indeksuje wszystkie dowody wspierające wraz z właścicielem i datą przeglądu.
11. Rejestr audytów pokazuje, czy czynność była testowana, jakie ustalenia zgłoszono i czy działania korygujące zostały zamknięte.

Tak ISO 27701:2025 staje się operacyjne. Tworzy powtarzalny łańcuch rozliczalności.

Typowe nieskuteczności dowodów PIMS

W środowiskach SaaS, fintech, usług zarządzanych i technologii B2B te same luki pojawiają się regularnie.

Po pierwsze, organizacje utrzymują RoPA lub rejestr przetwarzania, ale nie klasyfikują ról administratora i podmiotu przetwarzającego dla każdej czynności. Powoduje to niejasność co do podstawy prawnej, udokumentowanych poleceń i obowiązków dalszych podmiotów przetwarzających.

Po drugie, podstawa prawna jest zapisywana raz i nie jest ponownie walidowana przy zmianie celu. GDPR Article 6 wymaga dyscypliny w zakresie celu i podstawy prawnej. Dalsze przetwarzanie może wymagać oceny zgodności celów i zabezpieczeń.

Po trzecie, inwentarze dostawców wymieniają dostawców, ale nie pokazują pól kontroli umownych. Lista dostawców nie jest tym samym co nadzór nad podmiotami przetwarzającymi.

Po czwarte, decyzje DPIA są nieformalne. Zespoły mówią „to nie jest wysokie ryzyko”, ale nie potrafią pokazać kryteriów oceny, zatwierdzającego, daty ani dowodu.

Po piąte, dowody audytowe istnieją, ale nie są kontrolowane. Zrzuty ekranu nie mają metadanych. Polityki są aktualne, ale rejestry są nieaktualne. Umowy istnieją, ale ponowne oceny przy odnowieniu są pomijane.

Po szóste, procesy incydentowe koncentrują się na zdarzeniach cyberbezpieczeństwa, ale nie klasyfikują jednoznacznie naruszeń ochrony danych osobowych. Analiza naruszenia ochrony danych osobowych na potrzeby GDPR, zgłaszanie istotnych incydentów NIS2 i zgłaszanie incydentów ICT DORA muszą być skoordynowane, a nie zdublowane.

Clarysec adresuje te nieskuteczności, traktując dowody PIMS jako kontrolowany system zarządzania, a nie jako ostatni, awaryjny wysiłek przed audytem.

Lista kontrolna gotowości dowodowej PIMS ISO 27701:2025

Użyj tej listy kontrolnej podczas kolejnego wewnętrznego przeglądu gotowości.

• Zdefiniuj zakres PIMS i zainteresowane strony, w tym klientów, regulatorów, osoby, których dane dotyczą, dostawców, audyt wewnętrzny i kierownictwo.
• Przypisz role i odpowiedzialności PIMS, w tym Menedżera PIMS, osobę odpowiedzialną za prywatność, właściciela procesu, dział prawny, zakupy, bezpieczeństwo i audyt wewnętrzny.
• Utwórz wpisy REG02 dla każdej czynności przetwarzania PII.
• Sklasyfikuj rolę administratora, podmiotu przetwarzającego, współadministratora albo dalszego podmiotu przetwarzającego dla każdej czynności.
• Zwaliduj podstawę prawną dla przetwarzania przez administratora przed rozpoczęciem przetwarzania i przed zmianą celu.
• Zapisuj udokumentowane polecenia dla czynności podmiotu przetwarzającego.
• Uruchamiaj wstępną ocenę ryzyka dla prywatności w REG04 przed nowym lub istotnie zmienionym przetwarzaniem.
• Przeprowadź DPIA, gdy ocena wskazuje podwyższone ryzyko dla prywatności.
• Utrzymuj REG08 dla podmiotów przetwarzających, dalszych podmiotów przetwarzających, dostawców ICT i dostawców istotnych dla prywatności.
• Weryfikuj pola umowne dotyczące zakresu, czasu trwania, celu, kategorii PII, poufności, bezpieczeństwa, wsparcia, prawa do audytu, zwrotu, usunięcia i zakończenia współpracy.
• Utrzymuj REG12 jako indeks udokumentowanej informacji PIMS.
• Mapuj dowody PIMS na postępowanie z ryzykiem ISO/IEC 27001:2022 i uwagi SoA.
• Odnoś krzyżowo obowiązki GDPR, NIS2, DORA, NIST CSF 2.0 i COBIT 2019 tam, gdzie ma to zastosowanie.
• Przeprowadzaj coroczne wewnętrzne audyty zgodności prywatności i aktualizuj Rejestr audytów.
• Kwartalnie przeglądaj otwarte ustalenia, działania korygujące, decyzje dotyczące ryzyka i raportowanie zarządcze.

P17 Data Protection and Privacy Policy wzmacnia cykl audytu:

Wewnętrzny audyt zgodności prywatności powinien być przeprowadzany corocznie albo po istotnych zmianach organizacyjnych lub regulacyjnych. Zakres audytu powinien obejmować:

Przekaz jest prosty. Zgodność w zakresie prywatności jest monitorowana, a nie zakładana.

Zbuduj model dowodowy PIMS z Clarysec

ISO 27701:2025 ma największą wartość wtedy, gdy jest zintegrowane z ISO/IEC 27001:2022 i zaprojektowane tak, aby domyślnie wytwarzać dowody. W ten sposób prywatność staje się możliwym do obrony modelem operacyjnym, a nie projektem certyfikacyjnym.

Gdy klient pyta o zapewnienie w zakresie prywatności, możesz pokazać dowody. Gdy regulator pyta, dlaczego przetwarzaliście dane, możesz pokazać rolę, cel, podstawę prawną, zabezpieczenia i zatwierdzenia. Gdy audytor pyta, jak nadzorujecie dalsze podmioty przetwarzające, możesz pokazać REG08, kontrole umowne, ponowne oceny i prawo do audytu. Gdy zarząd pyta, czy ryzyko dla prywatności jest pod kontrolą, możesz pokazać metryki, otwarte działania, wyniki audytów i przegląd zarządzania.

Jeżeli twój PIMS nadal jest ciężki w politykach, a lekki w dowodach, zacznij od łańcucha, którym pójdą audytorzy:

inwentarz przetwarzania REG02, wstępna ocena ryzyka dla prywatności REG04, nadzór REG08 nad podmiotami przetwarzającymi i dalszymi podmiotami przetwarzającymi, indeks dowodów REG12, Lawful Basis Register, Rejestr audytów oraz mapowanie SoA.

Clarysec może pomóc zoperacjonalizować ten łańcuch przez:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap, zwłaszcza Step 2 dotyczący wymagań interesariuszy, Step 13 dotyczący postępowania z ryzykiem i identyfikowalności SoA oraz Step 23 dotyczący prywatności, dostawców i zabezpieczeń organizacyjnych.
• Zenith Controls: The Cross-Compliance Guide, wykorzystując środki kontrolne ISO/IEC 27002:2022 5.2, 5.20, 5.21 i 5.34 jako praktyczne kotwice rozliczalności prywatności.
• Zestaw polityk ISO 27701 PIMS Clarysec, w tym Privacy Information Management System Policy, PII Processing Inventory and Lawful Basis Policy, Privacy Risk Assessment and DPIA Policy, Processor, Subprocessor and Third-Party Privacy Management Policy oraz PIMS Documented Information and Evidence Management Policy.
• Wsparcie dla organizacji korporacyjnych i MŚP przez P17 Data Protection and Privacy Policy, Data Protection and Privacy Policy-sme, Third-Party and Supplier Security Policy-sme, P33 Audit and Compliance Monitoring Policy oraz Audit and Compliance Monitoring Policy-sme.

Twoje kolejne działanie jest proste: wybierz jedną czynność przetwarzania PII wysokiego ryzyka i przejdź łańcuch dowodowy od REG02 do REG12. Jeżeli łańcuch się urywa, to jest twój pierwszy projekt doskonalący. Jeżeli pozostaje spójny, rozszerz model na cały inwentarz przetwarzania.

Tak ISO 27701:2025 staje się czymś więcej niż certyfikatem. Staje się dowodem rozliczalności GDPR.