Plan przejścia na ISO/IEC 27701:2025 dla PIMS zgodnego z GDPR

Pytanie zarządu, które ujawnia lukę w dowodach dotyczących prywatności

Anya, dyrektor ds. bezpieczeństwa informacji w szybko rozwijającym się fintechu, patrzyła na agendę posiedzenia zarządu. Między prognozami przychodów a ekspansją rynkową znalazł się punkt, który zajmował jej cały tydzień: zgodność z GDPR i gotowość do ISO/IEC 27701:2025.

Spółka miała program GDPR. Był Inspektor Ochrony Danych (DPO), klauzule informacyjne, umowy powierzenia przetwarzania danych, szablon DPIA oraz proces obsługi żądań osób, których dane dotyczą. Dział sprzedaży poinformował już klientów korporacyjnych, że spółka zmierza w kierunku systemu zarządzania informacjami o prywatności ISO/IEC 27701:2025, czyli PIMS. Zespół produktowy przygotowywał funkcję analityczną wspieraną przez AI, która miała przetwarzać zachowania użytkowników klientów, zgłoszenia do wsparcia, metadane rozliczeniowe i aktywność kont. Duży klient z UE poprosił o dowody, że obowiązki administratora i podmiotu przetwarzającego są zarządzane oddzielnie.

Niewygodna prawda nie polegała na tym, że brakowało dokumentacji dotyczącej prywatności. Problemem były dowody.

Rejestr czynności przetwarzania nie pokazywał konsekwentnie podstawy prawnej, retencji, zależności od podwykonawców przetwarzania, transferów międzynarodowych ani tego, czy spółka działała jako administrator czy podmiot przetwarzający dla każdego celu przetwarzania. Przeglądy dostawców koncentrowały się na bezpieczeństwie, ale w niewystarczającym stopniu obejmowały polecenia dotyczące prywatności, usuwanie, wsparcie przy naruszeniach, prawo do audytu i obowiązki przenoszone na dalsze podmioty. Inżynieria prowadziła przeglądy bezpieczeństwa, jednak ochrona danych w fazie projektowania nie zawsze była uruchamiana, gdy funkcja zmieniała cel przetwarzania. Audyt wewnętrzny testował GDPR na wysokim poziomie, ale nie zawsze potrafił prześledzić obowiązek do właściciela, zabezpieczenia, rejestru, testu i decyzji z przeglądu zarządzania.

Na tym polega rzeczywiste wyzwanie związane z przejściem na ISO/IEC 27701:2025. Nie jest to wyłącznie projekt certyfikacyjny. To test dojrzałości: czy organizacja potrafi zarządzać prywatnością jako systemem, a nie jako folderem dokumentów prawnych?

Dla organizacji kierujących się wymaganiami GDPR właściwą odpowiedzią jest rozszerzenie systemu zarządzania bezpieczeństwem informacji ISO/IEC 27001:2022 na system zarządzania prywatnością, który integruje zakres PIMS, rejestry czynności przetwarzania, ocenę ryzyka dla prywatności, DPIA, nadzór nad dostawcami, obsługę naruszeń, mapowanie zabezpieczeń, audyt wewnętrzny i ciągłe doskonalenie.

Dlaczego rozproszona zgodność z GDPR załamuje się pod presją audytu

Wiele organizacji traktuje zgodność w obszarze prywatności jako osobny strumień prac, odłączony od bezpieczeństwa informacji. Dział prawny zarządza umowami. IT zarządza szyfrowaniem. Zakupy zarządzają dostawcami. DPO odpowiada na żądania dostępu osób, których dane dotyczą. Zespoły produktowe uruchamiają funkcje. Zespół bezpieczeństwa obsługuje incydenty. Każda funkcja może wykonywać wartościową pracę, ale bez jednego modelu operacyjnego dowody dotyczące prywatności stają się rozproszone.

Powoduje to cztery powtarzające się problemy.

Po pierwsze, zespoły dublują wysiłek. Oceny ryzyka bezpieczeństwa i prywatności mogą stosować różne metody, różne punktacje i różnych właścicieli.

Po drugie, luki pojawiają się w usługach stron trzecich, konfiguracjach chmury obliczeniowej, potokach analitycznych, narzędziach wsparcia i nowych projektach rozwojowych, ponieważ nikt nie ma pełnego obrazu przepływów PII.

Po trzecie, zapewnienie dla zarządu i klientów staje się trudne. Zbiór niepowiązanych polityk nie dowodzi, że obowiązki dotyczące prywatności są wdrożone, monitorowane i doskonalone.

Po czwarte, współczesne oczekiwania regulacyjne są coraz bardziej zbieżne. GDPR oczekuje rozliczalności i dowodów. NIS2 oczekuje ładu zarządczego, zarządzania ryzykiem, obsługi incydentów, kontroli dostępu, zarządzania aktywami i bezpieczeństwa łańcucha dostaw. DORA oczekuje, że podmioty finansowe będą zarządzać ryzykiem ICT, incydentami, testowaniem odporności, umowami z podmiotami trzecimi i strategiami wyjścia. Silosowy program prywatności nie jest w stanie efektywnie wspierać wszystkich tych wymagań.

Silniejsze podejście polega na zbudowaniu przejścia na ISO/IEC 27701:2025 na bazie SZBI ISO/IEC 27001:2022. ISO/IEC 27001:2022 zapewnia strukturę systemu zarządzania dla kontekstu, stron zainteresowanych, zakresu, oceny ryzyka, postępowania z ryzykiem, celów, planowania operacyjnego, audytu wewnętrznego, przeglądu zarządzania, działań korygujących i ciągłego doskonalenia. ISO/IEC 27002:2022 zapewnia podstawę zabezpieczeń dla obowiązków prawnych, inwentarza aktywów, relacji z dostawcami, usług w chmurze obliczeniowej, kontroli dostępu, rejestrowania, monitorowania, usuwania, maskowania oraz prywatności i ochrony PII.

Przejście powinno odpowiedzieć na pięć pytań:

1. Jaki jest zakres PIMS, w tym role administratora, podmiotu przetwarzającego, współadministratora i podwykonawcy przetwarzania?
2. Które czynności przetwarzania, kategorie danych, cele, podstawy prawne, odbiorcy, transfery i reguły retencji są objęte zakresem?
3. Które ryzyka dla prywatności wymagają DPIA, postępowania z ryzykiem, zatwierdzenia i akceptacji ryzyka rezydualnego?
4. Które polityki, zabezpieczenia, umowy, techniczne środki ochrony i zapisy potwierdzają rozliczalność w GDPR?
5. W jaki sposób audyt wewnętrzny i przegląd zarządzania potwierdzą, że PIMS działa i jest doskonalony?

Faza 1: zatwierdź zakres PIMS przed przepisywaniem polityk

Solidny plan przejścia na ISO/IEC 27701:2025 nie zaczyna się od przepisywania każdej polityki prywatności. Zaczyna się od ładu zarządczego i zakresu.

Punktem wyjścia jest istniejący zakres SZBI, ale zakres PIMS musi wprost identyfikować przetwarzanie PII, jednostki biznesowe, usługi, systemy, regiony, środowiska chmurowe, dostawców i role dotyczące prywatności. Zarząd albo najwyższe kierownictwo musi rozumieć, dlaczego przejście ma znaczenie, zwłaszcza tam, gdzie klienci, regulatorzy lub obowiązki sektorowe, takie jak DORA, zależą od możliwych do wykazania dowodów prywatności i odporności.

Polityka systemu zarządzania informacjami o prywatności Clarysec [Polityka PIMS] nakłada obowiązek zatwierdzenia zakresu:

[Oba] Najwyższe kierownictwo MUSI zatwierdzić zakres PIMS w REG01 przed początkowym wdrożeniem PIMS oraz w ciągu 30 dni od każdej istotnej zmiany.

Dla programów przejścia korzystających z numeracji klauzul biblioteki polityk Clarysec jest to podstawowe oczekiwanie w Klauzuli 4.1.1. Ma ono znaczenie, ponieważ dorozumiany zakres prywatności jest jedną z najczęstszych słabości audytowych. Jeżeli linia produktowa, jurysdykcja, rola w przetwarzaniu, dostawca, region chmurowy lub proces biznesowy zmienia się istotnie, zakres PIMS nie może pozostawać przedmiotem interpretacji.

Ta sama polityka przekształca również przejście w zarządzany program:

[Oba] Osoba odpowiedzialna za prywatność / Menedżer PIMS MUSI odnotować plan wdrożenia PIMS w REG12 przed uruchomieniem PIMS lub istotną zmianą PIMS.

REG12 nie jest obciążeniem administracyjnym. To komitet sterujący przejścia. Powinien wskazywać, co się zmienia, dlaczego ma to znaczenie, kto jest właścicielem, jakie dowody są wymagane, które ryzyka pozostają otwarte oraz kiedy zostanie przetestowana gotowość.

Faza 2: zbuduj inwentaryzację przejścia opartą na rejestrach

W systemach zarządzania prywatnością zgodnych z GDPR pierwszym praktycznym produktem prac powinien być inwentarz dowodów, a nie przepisana polityka. Clarysec stosuje podejście oparte na rejestrach, ponieważ rejestry przekształcają intencję dotyczącą prywatności w dowody możliwe do prześledzenia audytowo.

Zakres PIMS w REG01 łączy się z czynnościami przetwarzania w REG02, stosowalnością zabezpieczeń w REG03, ryzykiem dla prywatności i oceną potrzeby przeprowadzenia DPIA w REG04 oraz planowaniem wdrożenia w REG12.

Polityka ochrony danych i prywatności - MŚP [Polityka prywatności MŚP] ustanawia bazowe wymaganie:

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

Dla większych środowisk Polityka ochrony danych i prywatności [P17 Polityka ochrony danych i prywatności] podnosi oczekiwanie dotyczące ładu zarządczego:

Organizacja powinna utrzymywać formalne ramy ładu prywatności zintegrowane z systemem zarządzania bezpieczeństwem informacji (SZBI), aby egzekwować postanowienia tej polityki.

Ta integracja jest zasadą przejścia. Rejestr czynności przetwarzania bez postępowania z ryzykiem jest arkuszem kalkulacyjnym. DPIA bez właściciela zabezpieczenia jest notatką prawną. Umowa powierzenia przetwarzania danych z dostawcą bez monitorowania trafia do szuflady z umowami. Prace związane z przejściem na ISO/IEC 27701:2025 powinny włączyć te artefakty do jednego zarządzanego PIMS.

Ten inwentarz wspiera również podejście zgodne z NIST Cybersecurity Framework 2.0: profil bieżący i profil docelowy. Profil bieżący dokumentuje istniejące procesy, zabezpieczenia i dowody dotyczące prywatności. Profil docelowy definiuje pożądany PIMS zgodny z ISO/IEC 27701:2025. Różnica między nimi staje się rejestrem prac przejścia.

Faza 3: odwzoruj rozliczalność GDPR w PIMS

Rozliczalność GDPR jest kręgosłupem dowodów dotyczących prywatności. GDPR ma zastosowanie do przetwarzania w kontekście jednostki organizacyjnej w UE, a także może mieć zastosowanie do administratorów lub podmiotów przetwarzających spoza UE, którzy oferują towary lub usługi osobom w UE albo monitorują ich zachowanie. Szeroko definiuje dane osobowe, w tym identyfikatory bezpośrednie i pośrednie. Odróżnia administratorów od podmiotów przetwarzających i definiuje naruszenie ochrony danych osobowych jako naruszenie bezpieczeństwa prowadzące do przypadkowego lub niezgodnego z prawem zniszczenia, utraty, zmiany, nieuprawnionego ujawnienia danych osobowych lub dostępu do nich.

W planowaniu przejścia najważniejsze jest to, że GDPR nie spełnia się przez stwierdzenie „mamy środki bezpieczeństwa”. Article 5 wymaga zgodnego z prawem, rzetelnego i przejrzystego przetwarzania, ograniczenia celu, minimalizacji danych, prawidłowości, ograniczenia przechowywania, integralności i poufności oraz możliwej do wykazania rozliczalności. Article 6 wymaga podstawy prawnej. Article 9 dodaje surowsze warunki dla szczególnych kategorii danych osobowych. Article 25 wymaga ochrony danych w fazie projektowania i domyślnej ochrony danych. Article 28 wymaga nadzoru nad podmiotami przetwarzającymi. Article 32 wymaga bezpieczeństwa przetwarzania.

Polityka zgodności prawnej i regulacyjnej - MŚP Clarysec [Polityka zgodności prawnej i regulacyjnej MŚP] daje mniejszym organizacjom prosty punkt wyjścia:

GM musi utrzymywać prosty, uporządkowany Rejestr zgodności obejmujący:

Wersja korporacyjna Polityka zgodności prawnej i regulacyjnej [P37 Polityka zgodności prawnej i regulacyjnej] jest bardziej jednoznaczna:

Wszystkie obowiązki prawne i regulacyjne muszą być zmapowane do konkretnych polityk, zabezpieczeń i właścicieli w systemie zarządzania bezpieczeństwem informacji (SZBI).

To zdanie stanowi różnicę między nieformalną zgodnością z GDPR a gotowym do audytu zarządzaniem prywatnością. Każdy istotny obowiązek GDPR powinien być zmapowany do polityki, zabezpieczenia, właściciela, pola rejestru i źródła dowodów.

Dowody administratora i podmiotu przetwarzającego muszą być rozdzielone. Administrator musi wykazać podstawę prawną, przejrzystość, obsługę praw, decyzje dotyczące celów i retencję. Podmiot przetwarzający musi wykazać przetwarzanie na podstawie udokumentowanych poleceń, nadzór nad podwykonawcami przetwarzania, wsparcie dla administratora, środki bezpieczeństwa, wsparcie przy zgłaszaniu naruszeń oraz zwrot lub usunięcie danych po zakończeniu świadczenia usługi. Jeżeli organizacja działa w obu rolach, jeden ogólny model dowodów nie wystarczy.

Faza 4: wykorzystaj SoA jako pomost zabezpieczeń prywatności

Częstym błędem w przejściu jest utworzenie samodzielnego arkusza zabezpieczeń PIMS przy pozostawieniu Deklaracji stosowania SZBI bez zmian. Tworzy to dwa konkurujące ze sobą światy zabezpieczeń.

ISO/IEC 27001:2022 wymaga, aby decyzje dotyczące postępowania z ryzykiem były odzwierciedlone w Deklaracji stosowania. Polityka zarządzania ryzykiem Clarysec [Polityka zarządzania ryzykiem] stanowi:

Deklaracja stosowania (SoA) powinna odzwierciedlać wszystkie decyzje dotyczące postępowania z ryzykiem i powinna być aktualizowana każdorazowo, gdy zmienia się pokrycie zabezpieczeniami.

W przejściu na ISO/IEC 27701:2025 SoA staje się pomostem między SZBI i PIMS. Jeżeli DPIA lub postępowanie z ryzykiem dla prywatności dodaje szyfrowanie, maskowanie danych, kontrole usuwania, mechanizmy uzyskiwania zgody, due diligence podmiotu przetwarzającego, ograniczenia dostępu albo monitorowanie procesu DSAR, SoA i REG03 muszą odzwierciedlać tę decyzję.

Zenith Blueprint: 30-etapowa mapa drogowa audytora [Zenith Blueprint] wzmacnia to w kroku 6:

✓ Dodatkowe zabezpieczenia: czy istnieją zabezpieczenia spoza Annex A, które warto uwzględnić? ISO 27001
pozwala dodawać inne zabezpieczenia w SoA. Na przykład można uwzględnić
zgodność z NIST CSF albo konkretne zabezpieczenia prywatności z ISO 27701.

Nie należy wtłaczać obowiązków dotyczących prywatności w zabezpieczenia, do których nie pasują. W razie potrzeby należy dodać zabezpieczenia specyficzne dla prywatności, ale zarządzać nimi przez ten sam model postępowania z ryzykiem, własności, statusu wdrożenia, dowodów i audytu.

Zabezpieczenia ISO/IEC 27002:2022, które kotwiczą przejście

W Zenith Controls: przewodniku po mapowaniu zgodności [Zenith Controls] dwa zabezpieczenia ISO/IEC 27002:2022 mają kluczowe znaczenie dla przejścia na ISO/IEC 27701:2025: 5.31 Wymagania prawne, ustawowe, regulacyjne i umowne oraz 5.34 Prywatność i ochrona PII.

Zabezpieczenie 5.31 jest centrum zgodności. Wspiera identyfikację, dokumentowanie, własność i przegląd wymagań prawnych, regulacyjnych, ustawowych i umownych. Naturalnie łączy się z rozliczalnością GDPR, ładem zarządczym NIS2, obowiązkami DORA w zakresie ryzyka ICT, klauzulami prywatności klientów i zobowiązaniami dotyczącymi przetwarzania w chmurze obliczeniowej.

Zabezpieczenie 5.34 jest operacyjną kotwicą prywatności. Zenith Controls jasno wyjaśnia zależność:

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.

Macierz powiązań zabezpieczeń należy wykorzystywać jako praktyczną listę kontrolną projektowania.

Tu prywatność staje się operacyjna. Dla każdej czynności przetwarzania wysokiego ryzyka należy zapytać: które aktywa przechowują PII, jak jest ono sklasyfikowane, kto ma do niego dostęp, dokąd jest przekazywane, które usługi w chmurze obliczeniowej je przetwarzają, jaka reguła retencji ma zastosowanie, jakie monitorowanie wykrywa nadużycie oraz jakie dowody potwierdzają działanie tych zabezpieczeń?

Przykładowy proces: wdrożenie funkcji analitycznej wspieranej przez AI

Wróćmy do fintechu Anyi. Zespół produktowy chce uruchomić funkcję analityczną wspieraną przez AI, która przetwarza identyfikatory użytkowników, aktywność kont, metadane wsparcia, metadane rozliczeniowe i sygnały behawioralne. Niektórzy klienci korporacyjni mogą wykorzystywać wyniki do monitorowania pracowników, co zwiększa ryzyko dla prywatności.

Proces przejścia PIMS powinien obsłużyć takie uruchomienie jako kontrolowane zdarzenie dotyczące prywatności.

Krok 1: zaktualizuj REG02 w zakresie ról i celów przetwarzania

Właściciel procesu tworzy lub aktualizuje rekord przetwarzania. Wymagane pola obejmują cel, kategorie danych, kategorie osób, których dane dotyczą, podstawę prawną lub polecenie podmiotu przetwarzającego, okres przechowywania, systemy, dostawców, odbiorców, transfery i kontekst roli.

Jeżeli spółka jest podmiotem przetwarzającym dla analityki klientów, REG02 musi pokazywać przetwarzanie na podstawie poleceń klienta. Jeżeli wykorzystuje również dane zagregowane do ulepszania własnego produktu, ten odrębny cel może powodować, że staje się administratorem dla wtórnego przetwarzania. Rekord nie może zacierać ról.

Krok 2: wykonaj ocenę REG04

Polityka oceny ryzyka dla prywatności i DPIA Clarysec [Polityka oceny ryzyka dla prywatności i DPIA] wymaga:

[Oba] Właściciel procesu / właściciel biznesowy MUSI przeprowadzić bazową ocenę REG04 dla wszystkich aktywnych czynności przetwarzania REG02 objętych zakresem w ciągu 30 dni roboczych od zatwierdzenia zakresu PIMS lub rozszerzenia zakresu.

Ocena powinna identyfikować monitorowanie, profilowanie, szczególne kategorie danych, osoby wymagające szczególnej ochrony, nową technologię, przetwarzanie na dużą skalę, transfery transgraniczne lub zmianę celu. Jeżeli progi są spełnione, uruchamiana jest DPIA.

Krok 3: przeprowadź DPIA i zdefiniuj postępowanie z ryzykiem

P17 Polityka ochrony danych i prywatności wymaga:

Wszystkie istotne zmiany w systemach lub procesach obejmujących informacje osobowe (PII) powinny wymagać udokumentowanej oceny skutków dla ochrony danych (DPIA), zweryfikowanej przez Inspektora Ochrony Danych (DPO).

W bibliotece Clarysec jest to powiązane z Klauzulą 5.6. DPIA powinna ocenić ryzyka takie jak nadmierne zbieranie danych, niejasny cel, ponowna identyfikacja, nieuprawniony dostęp administratora po stronie klienta, niejasna retencja i ekspozycja na podwykonawców przetwarzania. Działania mogą obejmować minimalizację na poziomie pól, pseudonimizację, kontrolki konfiguracji po stronie klienta, domyślne ustawienia retencji, silniejsze rejestrowanie audytowe, aktualizacje DPA, informacje produktowe oraz ograniczenia dotyczące trenowania modelu.

Krok 4: zaktualizuj REG03 i SoA

Polityka PIMS wymaga:

[Oba] Osoba odpowiedzialna za prywatność / Menedżer PIMS MUSI utrzymywać REG03 z uwzględnionymi zabezpieczeniami, wyłączonymi zabezpieczeniami, statusem wdrożenia i uzasadnieniem corocznie oraz w ciągu 30 dni od każdej zmiany postępowania z ryzykiem dla prywatności.

Jeżeli DPIA dodaje maskowanie dla analityki nieprodukcyjnej, rejestrowanie dostępu administratorów, kontrole usuwania, klauzule dostawców lub zabezpieczenia konfiguracji po stronie klienta, REG03 i SoA muszą zostać zaktualizowane.

Krok 5: wykaż ochronę danych w fazie projektowania

Polityka prywatności MŚP ujmuje zasadę wprost:

Ochrona danych w fazie projektowania i domyślna ochrona danych muszą być egzekwowane we wszystkich nowych systemach i usługach

Dowody powinny obejmować DPIA, przegląd architektury, decyzję o minimalizacji danych, model dostępu, konfigurację rejestrowania, ustawienie retencji, wyniki testów, zatwierdzenie wydania i przegląd po uruchomieniu. Dzięki temu uruchomienie funkcji staje się dowodem PIMS możliwym do ponownego wykorzystania.

Nadzór nad prywatnością u dostawców w świecie DORA i NIS2

Nadzór nad prywatnością u dostawców jest obszarem, w którym wiele przejść kończy się niepowodzeniem. GDPR Article 28 wymaga, aby administratorzy korzystali z podmiotów przetwarzających zapewniających wystarczające gwarancje oraz aby obowiązki podmiotu przetwarzającego zostały ujęte w umowach pisemnych. DORA Articles 28 to 30 wymagają od podmiotów finansowych zarządzania ryzykiem ze strony zewnętrznych dostawców ICT, utrzymywania rejestrów uzgodnień umownych, prowadzenia due diligence, uwzględniania prawa do audytu i warunków wyjścia, zarządzania podwykonawstwem oraz adresowania krytycznych lub istotnych funkcji. NIS2 Article 21 wymaga środków bezpieczeństwa łańcucha dostaw, w tym uwzględnienia podatności dostawców, praktyk cyberbezpieczeństwa i procedur bezpiecznego rozwoju oprogramowania.

ISO/IEC 27002:2022 zabezpieczenie 5.19, Bezpieczeństwo informacji w relacjach z dostawcami, jest operacyjną kotwicą. Zenith Controls mapuje ten obszar do umów z dostawcami, bezpieczeństwa łańcucha dostaw ICT, przekazywania informacji, monitorowania zgodności, dopuszczalnego użytkowania, obowiązków podmiotów przetwarzających w GDPR, cyberbezpieczeństwa łańcucha dostaw w NIS2, ryzyka zewnętrznych dostawców ICT w DORA, nadzoru nad dostawcami według NIST oraz zarządzania dostawcami według COBIT.

Dla podmiotów finansowych regulowanych przez DORA dowody te muszą łączyć się z rejestrami zewnętrznych dostawców ICT oraz ocenami krytycznych lub istotnych funkcji. Dla podmiotów objętych NIS2 te same zapisy dostawców wspierają zarządzanie ryzykiem łańcucha dostaw. Dla NIST CSF 2.0 nadzór nad dostawcami jest zgodny z funkcją GOVERN, zwłaszcza z wynikami zarządzania ryzykiem łańcucha dostaw. Dla COBIT 2019 nadzór nad dostawcami odpowiada celom takim jak APO10 Managed Vendors oraz środkom operacyjnym DSS dotyczącym dostawców.

Gotowość na incydenty i naruszenia musi być zintegrowana

Plany przejścia w obszarze prywatności często nadmiernie koncentrują się na dokumentacji, a zbyt mało na obsłudze naruszeń. To niebezpieczne, ponieważ GDPR, NIS2 i DORA oczekują zdyscyplinowanych procesów incydentowych, mimo że progi i terminy zgłoszeń są różne.

GDPR wymaga oceny, czy zdarzenie bezpieczeństwa spowodowało naruszenie ochrony danych osobowych oraz czy wymagane jest zgłoszenie do organu nadzorczego lub zawiadomienie osób, których dane dotyczą. NIS2 ustanawia etapowe raportowanie znaczących incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin i raport końcowy w ciągu jednego miesiąca. DORA wymaga od podmiotów finansowych wykrywania, zarządzania, klasyfikowania, rejestrowania, zgłaszania, reagowania i wyciągania wniosków z incydentów związanych z ICT, z etapowym raportowaniem poważnych incydentów.

NIST CSF 2.0 wspiera ten cykl przez wyniki Detect, Respond, Recover i Govern. Zespół przejścia powinien zapewnić, aby decyzje dotyczące naruszeń prywatności były wbudowane w proces obsługi incydentów bezpieczeństwa, a nie obsługiwane jako odłączona prawna refleksja po fakcie.

Jedna mapa drogowa, wiele rezultatów zgodności

Przejście na ISO/IEC 27701:2025 zyskuje na wartości, gdy ogranicza dublowanie prac zgodnościowych. Zenith Blueprint, krok 14, zaleca krzyżowe odniesienie GDPR, NIS2 i DORA, aby organizacje mogły wykazać, że postępowanie z ryzykiem i zabezpieczenia spełniają wiele obowiązków:

Dla każdej regulacji, jeżeli ma zastosowanie, można utworzyć prostą tabelę mapowania (może być
załącznikiem do raportu), która wymienia kluczowe wymagania bezpieczeństwa danej regulacji oraz
odpowiadające im zabezpieczenia/polityki w SZBI.

W planowaniu przejścia w obszarze prywatności mapowanie powinno być praktyczne i oparte na dowodach.

W Zenith Controls zabezpieczenie ISO/IEC 27002:2022 5.31 wspiera identyfikowalność prawną i regulacyjną w obszarach rozliczalności GDPR, obowiązków zgodności DORA, oczekiwań ładu zarządczego NIS2, NIST CSF 2.0 GV.OC-03 oraz monitorowania zgodności zewnętrznej COBIT. Zabezpieczenie 5.34 wspiera GDPR Articles 25 and 32, ochronę cyklu życia PII, oczekiwania dotyczące przetwarzania PII w chmurze obliczeniowej oraz środki bezpieczeństwa uwzględniające prywatność.

Rezultatem nie jest uproszczony model „jedno zabezpieczenie równa się jedno prawo”. Jest nim możliwy do obrony model dowodowy, w którym jeden dobrze zaprojektowany zestaw zabezpieczeń wspiera wiele potrzeb zapewnienia.

Jak audytorzy przetestują przejście

Silny plan przejścia przewiduje techniki audytowe.

Audytor systemu zarządzania ISO rozpocznie od zakresu, stron zainteresowanych, wymagań prawnych, ryzyk, celów, środków operacyjnych, audytów wewnętrznych, przeglądów zarządzania, niezgodności i doskonalenia. Zweryfikuje, czy zakres PIMS został zatwierdzony, czy obowiązki dotyczące prywatności są ujęte w rejestrze zgodności, czy zabezpieczenia są uzasadnione w SoA oraz czy dowody wdrożenia odpowiadają deklarowanemu zakresowi.

Audytor prywatności dobierze próbki rekordów przetwarzania, DPIA, DSAR, decyzji dotyczących naruszeń, umów z podmiotami przetwarzającymi, kontroli retencji i onboardingu projektów. Nie zaakceptuje intencji zapisanej w polityce tam, gdzie brakuje dowodów działania.

Asesor pracujący według NIST będzie szukać ładu zarządczego, obowiązków prawnych i umownych, profili docelowych, ryzyka dostawców, monitorowania, reagowania i dowodów odzyskiwania.

Audytor COBIT 2019 skoncentruje się na nadzorze zarządu, raportowaniu zgodności, nadzorze nad dostawcami, rolach i odpowiedzialnościach oraz na tym, czy ryzyko dla prywatności jest zarządzane w całym cyklu życia informacji.

Polityka monitorowania, audytu i doskonalenia PIMS Clarysec [Polityka monitorowania, audytu i doskonalenia PIMS] nakłada obowiązek programu audytu:

[Wszyscy] Audyt wewnętrzny / weryfikator zgodności MUSI przygotować oparty na ryzyku program audytów wewnętrznych PIMS w REG12 corocznie przed pierwszym planowanym cyklem audytowym PIMS.

Polityka audytu i monitorowania zgodności [Polityka audytu i monitorowania zgodności] stosuje tę samą dyscyplinę na poziomie SZBI:

Oparty na ryzyku Plan audytów powinien być opracowywany i zatwierdzany corocznie, z uwzględnieniem:

Dla mniejszych organizacji Polityka audytu i monitorowania zgodności - MŚP [Polityka audytu i monitorowania zgodności MŚP] utrzymuje planowanie audytu w skoncentrowanej formie:

Plan musi identyfikować kluczowe systemy i polityki do przeglądu, ze szczególnym uwzględnieniem:

Podczas przejścia pierwszy audyt wewnętrzny nie powinien testować wszystkiego. Powinien testować najwyższe ryzyka przejścia: niekompletne rekordy przetwarzania, brakujące kryteria uruchomienia DPIA, słabe klauzule prywatności u dostawców, nieprzetestowane decyzje dotyczące naruszeń, niejasne role administratora i podmiotu przetwarzającego oraz niespójność z SoA.

Praktyczna 90-dniowa mapa drogowa przejścia na ISO/IEC 27701:2025

Realistyczna mapa drogowa powinna być na tyle krótka, aby można ją było wykonać, i na tyle uporządkowana, aby tworzyła dowody.

Cel 90 dni nie oznacza, że każdy element działań naprawczych zostanie zamknięty. Oznacza, że kierownictwo powinno dysponować zatwierdzonym zakresem, wiarygodną bazową linią dowodów, spriorytetyzowanym postępowaniem z ryzykiem, wynikami ukierunkowanego audytu oraz decyzją zarządczą dotyczącą gotowości.

Oprzyj przejście na dowodach

Organizacje, które odnoszą sukces w przejściu na ISO/IEC 27701:2025, nie są tymi, które mają najdłuższą politykę prywatności. Są nimi organizacje, które potrafią wykazać, jak obowiązki dotyczące prywatności przechodzą z prawa do zakresu, z zakresu do rekordów przetwarzania, z rekordów przetwarzania do oceny ryzyka, z oceny ryzyka do zabezpieczeń, z zabezpieczeń do dowodów oraz z dowodów do doskonalenia.

Clarysec pomaga zespołom uczynić to przejście praktycznym. Nasz zestaw polityk PIMS, mapowania GDPR, rejestry dowodów dla administratora i podmiotu przetwarzającego, procesy DPIA, szablony nadzoru nad prywatnością u dostawców, materiały do obsługi naruszeń, agendy przeglądu zarządzania, Zenith Blueprint i Zenith Controls dają CISO, DPO, menedżerom zgodności, audytorom i właścicielom biznesowym uporządkowaną ścieżkę od intencji dotyczącej prywatności do działania gotowego do audytu.

Jeżeli Twoja organizacja przygotowuje się do ISO/IEC 27701:2025, zacznij w tym tygodniu od trzech działań: zatwierdź zakres przejścia PIMS w REG01, uzupełnij REG02 dla usługi o najwyższym ryzyku i przeprowadź pierwszą ocenę REG04. Następnie wykorzystaj Clarysec, aby przekształcić ten zestaw dowodów w kompletną, zgodną z GDPR mapę drogową przejścia PIMS, gotową dla klientów, audytorów, regulatorów i zarządu.