Gotowa do audytu ochrona danych osobowych (PII) dla GDPR, NIS2 i DORA
Alert trafił do skrzynki Sarah we wtorek o 22:00.
Jako dyrektor ds. bezpieczeństwa informacji w szybko rosnącej spółce SaaS z sektora FinTech Sarah znała alerty przychodzące późnym wieczorem. Ten był inny. Młodszy programista udostępnił bazę danych środowiska przedprodukcyjnego publicznie podczas testowania nowej funkcji analitycznej. Baza miała zawierać dane testowe, ale niedawna synchronizacja ze środowiska produkcyjnego do środowiska przedprodukcyjnego wypełniła ją rzeczywistymi danymi osobowymi (PII) klientów.
Incydent został szybko opanowany. Potem pojawiło się drugie ustalenie. Arkusz migracyjny o nazwie customer_users_final_v7.xlsx został skopiowany z tego samego zbioru danych. Zawierał imiona i nazwiska, adresy e-mail, uprawnienia ról, logi użycia, pola kraju, notatki wsparcia oraz komentarze tekstowe, które nigdy nie powinny trafić do procesu testowego. Został skopiowany na dysk współdzielony, pobrany przez programistę, załączony do zgłoszenia i zapomniany.
O północy Sarah nie zarządzała już techniczną błędną konfiguracją. Zarządzała problemem audytowym.
Spółka była już certyfikowana zgodnie z ISO/IEC 27001:2022. Zarząd oczekiwał zapewnienia zgodności z GDPR przed wejściem na rynek UE. Klienci z sektora usług finansowych przesyłali kwestionariusze due diligence DORA. Relacje z dostawcami usług chmurowych i zarządzanych generowały pytania NIS2 dotyczące łańcucha dostaw. Dział prawny potrafił wyjaśnić obowiązki. Inżynieria wskazywała na szyfrowanie. Zespół produktu deklarował podejście privacy by design. Deklaracja stosowania wspominała o prywatności i ochronie danych osobowych (PII).
Nikt jednak nie potrafił pokazać, w jednym możliwym do prześledzenia łańcuchu, jakie dane osobowe (PII) istnieją, dlaczego są przetwarzane, kto ma do nich dostęp, gdzie są maskowane, którzy dostawcy mają z nimi styczność, jak długo są przechowywane oraz jak incydent zostałby sklasyfikowany według GDPR, NIS2 lub DORA.
Właśnie dlatego ISO/IEC 27701:2025 i ISO/IEC 29151:2022 mają znaczenie. Nie są wyłącznie etykietami prywatności. Pomagają organizacjom przekształcić deklaracje dotyczące prywatności w gotowe do audytu zabezpieczenia ochrony danych osobowych (PII). ISO/IEC 27701:2025 rozszerza system zarządzania bezpieczeństwem informacji ISO/IEC 27001:2022 o zarządzanie informacjami o prywatności. ISO/IEC 29151:2022 dodaje praktyczne wytyczne dotyczące ochrony danych osobowych w całym ich cyklu życia.
Podejście Clarysec polega na budowie jednego, opartego na dowodach modelu operacyjnego prywatności i bezpieczeństwa, a nie odrębnych silosów zgodności. Model ten łączy Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls oraz polityki Clarysec w jeden możliwy do prześledzenia system dla GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, modelu zapewnienia w stylu NIST oraz oczekiwań ładu COBIT 2019.
Dlaczego ochrona danych osobowych (PII) jest dziś kwestią audytową na poziomie zarządu
Ochrona danych osobowych (PII) była kiedyś traktowana jako odpowiedzialność zespołu ds. prywatności. Dziś jest kwestią zaufania, odporności i regulacji na poziomie zarządu.
GDPR pozostaje punktem odniesienia dla ochrony danych osobowych w Europie i poza nią. Definiuje dane osobowe, przetwarzanie, administratora, podmiot przetwarzający, odbiorcę, stronę trzecią, zgodę oraz naruszenie ochrony danych osobowych w sposób wpływający na umowy SaaS, operacje wsparcia, analitykę, telemetrię produktu, zarządzanie dostawcami i reagowanie na incydenty. Zasady GDPR wymagają zgodności z prawem, rzetelności, przejrzystości, ograniczenia celu, minimalizacji danych, prawidłowości, ograniczenia przechowywania, integralności, poufności i rozliczalności. W ujęciu audytowym GDPR nie pyta wyłącznie, czy dane są szyfrowane. Pyta, czy organizacja potrafi wykazać, dlaczego dane istnieją i w jaki sposób osiągana jest zgodność.
NIS2 podnosi poprzeczkę ładu cyberbezpieczeństwa dla podmiotów kluczowych i ważnych. Article 21 wymaga środków zarządzania ryzykiem cyberbezpieczeństwa, w tym analizy ryzyka, polityk bezpieczeństwa systemów informatycznych, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego rozwoju oprogramowania, obsługi podatności, oceny skuteczności kontroli, cyberhigieny, kryptografii, bezpieczeństwa HR, kontroli dostępu, zarządzania aktywami, uwierzytelniania oraz bezpiecznej komunikacji. Article 23 dodaje etapowe zgłaszanie incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin oraz raport końcowy w ciągu jednego miesiąca od zgłoszenia.
DORA zmienia sposób rozmowy o podmiotach finansowych i ich dostawcach ICT. Stosuje się od 17 stycznia 2025 r. i ustanawia zharmonizowany reżim cyfrowej odporności operacyjnej obejmujący zarządzanie ryzykiem ICT, zgłaszanie istotnych incydentów związanych z ICT, testowanie odporności, ryzyko stron trzecich ICT, wymogi umowne oraz nadzór nad krytycznymi zewnętrznymi dostawcami usług ICT. Dla wielu podmiotów finansowych DORA pełni funkcję sektorowego aktu prawnego Unii, w którym pokrywają się obowiązki równoważne NIS2. W przypadku dostawców SaaS i ICT obsługujących instytucje finansowe presja DORA często pojawia się poprzez klauzule umowne, audyty klientów, wymagania dotyczące planowania wyjścia, obowiązki wsparcia incydentowego i testy odporności.
ISO/IEC 27001:2022 zapewnia podstawę systemu zarządzania. Wymaga kontekstu, stron zainteresowanych, zakresu, rozliczalności kierownictwa, polityk, ról, oceny ryzyka, postępowania z ryzykiem, Deklaracji stosowania, audytu wewnętrznego, przeglądu zarządzania i ciągłego doskonalenia. Załącznik A obejmuje zabezpieczenia bezpośrednio istotne dla ochrony danych osobowych (PII), w tym 5.34 Prywatność i ochrona danych osobowych (PII), 5.18 Prawa dostępu, 8.11 Maskowanie danych, 5.23 Bezpieczeństwo informacji przy korzystaniu z usług chmurowych, 8.15 Rejestrowanie, 8.33 Informacje testowe, 8.24 Korzystanie z kryptografii oraz 8.10 Usuwanie informacji.
Problem nie polega na tym, że organizacje nie mają zabezpieczeń. Problem polega na ich fragmentacji. Zapisy dotyczące prywatności są w dziale prawnym. Przeglądy dostępu są w IT. Skrypty maskowania są w inżynierii. Umowy z dostawcami są w zakupach. Dowody znajdują się w zgłoszeniach, zrzutach ekranu, arkuszach kalkulacyjnych i wiadomościach e-mail.
ISO/IEC 27701:2025 i ISO/IEC 29151:2022 pomagają ujednolicić te dowody wokół zarządzania informacjami o prywatności oraz praktyk ochrony danych osobowych (PII). Clarysec przekształca tę strukturę w model operacyjny.
Od SZBI do PIMS: zintegrowany łańcuch kontroli prywatności
System zarządzania bezpieczeństwem informacji (SZBI) ISO/IEC 27001:2022 odpowiada na podstawowe pytanie: czy bezpieczeństwo informacji jest objęte ładem, oparte na ryzyku, wdrożone, monitorowane i doskonalone?
Privacy Information Management System, czyli PIMS, rozszerza to pytanie na dane osobowe: czy odpowiedzialności w zakresie prywatności, czynności przetwarzania danych osobowych (PII), ryzyka prywatności, obowiązki administratora i podmiotu przetwarzającego, prawa osób, których dane dotyczą, oraz dowody kontroli prywatności są zarządzane w tym samym systemie?
ISO/IEC 27701:2025 rozszerza SZBI o ład prywatności. ISO/IEC 29151:2022 uzupełnia je praktycznymi wytycznymi dotyczącymi ochrony danych osobowych (PII), w tym ograniczania zbierania, zarządzania ujawnianiem, stosowania maskowania lub pseudonimizacji, ochrony transferów, ograniczania dostępu i dostosowania zabezpieczeń do ryzyka prywatności.
| Warstwa | Główne pytanie | Typowe dowody audytowe |
|---|---|---|
| ISO/IEC 27001:2022 | Czy istnieje zarządzany, oparty na ryzyku SZBI z dobranymi i działającymi zabezpieczeniami? | Zakres, strony zainteresowane, ocena ryzyka, plan postępowania z ryzykiem, SoA, polityki, audyt wewnętrzny, przegląd zarządzania |
| ISO/IEC 27701:2025 | Czy odpowiedzialności w zakresie prywatności, ryzyka prywatności i czynności przetwarzania danych osobowych (PII) są zarządzane w ramach systemu zarządzania? | Role w obszarze prywatności, rejestr przetwarzania, procedury administratora i podmiotu przetwarzającego, oceny ryzyka prywatności, DPIA, proces obsługi żądań osób, których dane dotyczą |
| ISO/IEC 29151:2022 | Czy praktyczne zabezpieczenia ochrony danych osobowych (PII) są wdrożone w całym cyklu życia danych? | Klasyfikacja danych osobowych (PII), ograniczenia dostępu, maskowanie, pseudonimizacja, kontrole okresu przechowywania, zabezpieczenia transferu, dowody incydentowe |
| GDPR | Czy organizacja potrafi wykazać zgodne z prawem, rzetelne, przejrzyste, zminimalizowane, bezpieczne i rozliczalne przetwarzanie? | Zapisy podstaw prawnych, informacje o prywatności, DPIA, proces obsługi naruszeń, umowy powierzenia przetwarzania, obsługa praw |
| NIS2 i DORA | Czy organizacja potrafi zarządzać ryzykami cyberbezpieczeństwa i odporności, w tym incydentami i dostawcami? | Nadzór kierownictwa, ramy ryzyka ICT, klasyfikacja incydentów, podręczniki raportowania, rejestry dostawców, prawa do audytu, testy ciągłości |
Ten model warstwowy zapobiega najczęstszemu błędowi w zgodności prywatności: traktowaniu danych osobowych (PII) jak kolejnego rodzaju danych wrażliwych. Dane osobowe (PII) niosą obowiązki prawne, etyczne, operacyjne, umowne i reputacyjne. Wymagają łańcucha kontroli, który zaczyna się od świadomości danych, a kończy na dowodach.
Zacznij od świadomości danych, nie od diagramów szyfrowania
Najczęstszą słabością prywatności, którą obserwuje Clarysec, jest brak kontekstu. Spółka nie może chronić danych osobowych (PII), jeśli nie wie, jakie dane osobowe (PII) posiada, gdzie się znajdują, jakiemu celowi służą, jak długo są przechowywane lub kto może uzyskać do nich dostęp.
Zenith Blueprint rozpoczyna te prace wcześnie, w fazie zarządzania ryzykiem. W kroku 9, Identyfikacja aktywów, zagrożeń i podatności, nakazuje organizacjom zinwentaryzować aktywa informacyjne i wyraźnie oznaczyć dane osobowe:
„Dla każdego aktywa odnotuj kluczowe szczegóły: nazwa/opis, właściciel, lokalizacja i klasyfikacja (wrażliwość). Na przykład aktywem może być »Baza danych klientów – właściciel: dział IT – hostowana w AWS – zawiera dane osobowe i finansowe (wysoka wrażliwość)«.”
Dodaje również: „Upewnij się, że aktywa zawierające dane osobowe są oznaczone (ze względu na GDPR), a aktywa usług krytycznych są odnotowane (ze względu na potencjalne zastosowanie NIS2, jeśli działasz w sektorze regulowanym).”
To fundament przyjęcia ISO/IEC 27701:2025 i ISO/IEC 29151:2022. Praktyczna sekwencja jest prosta:
- Zidentyfikuj systemy, zbiory danych, repozytoria, logi, raporty, kopie zapasowe, narzędzia wsparcia, środowiska programistyczne i dostawców, którzy przetwarzają dane osobowe (PII).
- Przypisz właściciela do każdego aktywa zawierającego dane osobowe (PII).
- Klasyfikuj dane osobowe (PII) według wrażliwości, celu biznesowego, podstawy prawnej, roli w przetwarzaniu i wymaganego okresu przechowywania.
- Powiąż każde aktywo zawierające dane osobowe (PII) z zagrożeniami, podatnościami, scenariuszami ryzyka i obowiązkami regulacyjnymi.
- Dobierz zabezpieczenia, przypisz dowody i monitoruj ich działanie w czasie.
Polityki Clarysec czynią to wykonalnym. SME Data Protection and Privacy Policy-sme Polityka ochrony danych i prywatności - SME stanowi:
„Koordynator ds. prywatności musi utrzymywać rejestr wszystkich czynności przetwarzania danych osobowych, w tym kategorii danych, celu, podstawy prawnej oraz okresów przechowywania”
Z sekcji „Wymagania ładu”, klauzula polityki 5.2.1.
Dla organizacji klasy enterprise Data Protection and Privacy Policy Polityka ochrony danych i prywatności ustanawia rygorystyczną zasadę minimalizacji:
„Zbierane i przetwarzane mogą być wyłącznie dane niezbędne do konkretnego, prawnie uzasadnionego celu biznesowego.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.
Te klauzule przekształcają rozliczalność GDPR w codzienne operacje. Wspierają również zarządzanie informacjami o prywatności i ochronę danych osobowych (PII), ponieważ wymagają od organizacji określenia, jakie dane istnieją, dlaczego istnieją i czy są konieczne.
Trzy zabezpieczenia, które czynią ochronę danych osobowych (PII) rzeczywistą
Trzy zabezpieczenia z Załącznika A ISO/IEC 27001:2022 często decydują o tym, czy ochrony danych osobowych (PII) można skutecznie bronić podczas audytu: 5.34 Prywatność i ochrona danych osobowych (PII), 8.11 Maskowanie danych oraz 5.18 Prawa dostępu.
5.34 Prywatność i ochrona danych osobowych (PII)
Zabezpieczenie 5.34 jest centrum ładu. W Zenith Controls 5.34 jest traktowany jako zabezpieczenie prewencyjne wspierające poufność, integralność i dostępność, powiązane z funkcjami cyberbezpieczeństwa Identify i Protect oraz zdolnościami operacyjnymi w zakresie ochrony informacji i zgodności prawnej.
Zenith Controls jasno pokazuje zależność:
„Inwentarz aktywów informacyjnych (5.9) powinien obejmować zasoby danych osobowych (PII) (bazy danych klientów, pliki HR). Stanowi to podstawę 5.34, ponieważ zapewnia, że organizacja wie, jakie dane osobowe (PII) posiada i gdzie się znajdują, co jest pierwszym krokiem do ich ochrony.”
Zabezpieczenie 5.34 zależy od 5.9 Inwentarz informacji i innych powiązanych aktywów, ponieważ danych osobowych (PII) nie da się chronić, jeśli nie można ich znaleźć. Łączy się również z 5.23 Bezpieczeństwo informacji przy korzystaniu z usług chmurowych, ponieważ większość danych osobowych (PII) znajduje się dziś na platformach chmurowych, w narzędziach SaaS, środowiskach analitycznych i usługach zarządzanych.
W przypadku przetwarzania wysokiego ryzyka w organizacjach klasy enterprise Polityka ochrony danych i prywatności wymaga:
„Modelowanie zagrożeń i oceny skutków dla ochrony danych (DPIA) są obowiązkowe dla systemów przetwarzania wysokiego ryzyka.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.3.4.
Ta klauzula ma krytyczne znaczenie. Przekształca prywatność w działanie projektowe i element zarządzania ryzykiem, a nie w końcowy przegląd prawny.
8.11 Maskowanie danych
Zabezpieczenie 8.11 jest bezpośrednią odpowiedzią na ekspozycję bazy środowiska przedprodukcyjnego Sarah. Zenith Controls opisuje 8.11 jako prewencyjne zabezpieczenie poufności w obszarze ochrony informacji. Łączy 8.11 z 5.12 Klasyfikacja informacji, ponieważ decyzje o maskowaniu zależą od wrażliwości, z 5.34, ponieważ maskowanie wspiera ochronę prywatności, oraz z 8.33 Informacje testowe, ponieważ środowiska testowe nie powinny ujawniać rzeczywistych danych osobowych (PII).
Data Masking and Pseudonymization Policy Polityka maskowania danych i pseudonimizacji określa tę zasadę wprost:
„Rzeczywiste dane osobowe nie mogą być wykorzystywane w środowiskach programistycznych, testowych ani przedprodukcyjnych. Zamiast nich należy używać danych zamaskowanych lub spseudonimizowanych, generowanych na podstawie wstępnie zatwierdzonych szablonów transformacji.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.3.
W przypadku MŚP Data Masking and Pseudonymization Policy-sme Polityka maskowania danych i pseudonimizacji - SME dodaje kluczowe wymaganie bezpieczeństwa i dowodowe:
„Dostęp do kluczy musi być szyfrowany, kontrolowany dostępowo i rejestrowany.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.3.
Ma to znaczenie, ponieważ pseudonimizacja ogranicza ryzyko tylko wtedy, gdy logika transformacji, klucze i ścieżki ponownej identyfikacji są kontrolowane.
5.18 Prawa dostępu
Zabezpieczenie 5.18 jest operacyjnym rdzeniem zasady najmniejszych uprawnień. Zenith Controls traktuje je jako zabezpieczenie prewencyjne, powiązane z poufnością, integralnością i dostępnością oraz osadzone w zarządzaniu tożsamością i dostępem. Łączy 5.18 z 5.15 Kontrola dostępu, 5.16 Zarządzanie tożsamością oraz 8.2 Uprawnienia dostępu uprzywilejowanego.
SME Data Classification and Labeling Policy-sme Polityka klasyfikacji i oznaczania informacji - SME stanowi:
„Dostęp musi być ograniczony do konkretnie upoważnionych użytkowników zgodnie z zasadą wiedzy koniecznej.”
Z sekcji „Wymagania ładu”, klauzula polityki 5.2.1.
Enterprise Data Classification and Labeling Policy Polityka klasyfikacji i oznaczania informacji dodaje podstawową zasadę klasyfikacji:
„Wszystkie aktywa informacyjne muszą mieć jasno przypisaną klasyfikację w momencie utworzenia lub onboardingu. W przypadku braku jednoznacznej klasyfikacji aktywa muszą domyślnie otrzymać klasyfikację »Poufne« do czasu formalnego przeglądu.”
Z sekcji „Wymagania ładu”, klauzula polityki 5.4.
Łącznie środki te tworzą praktyczny łańcuch ochrony danych osobowych (PII): poznaj dane osobowe (PII), sklasyfikuj je, ogranicz dostęp, maskuj je tam, gdzie pełna tożsamość nie jest konieczna, chroń klucze, rejestruj dostęp i przechowuj dowody.
Buduj identyfikowalność przez Deklarację stosowania
System zarządzania prywatnością staje się gotowy do audytu, gdy potrafi wykazać identyfikowalność. Zenith Blueprint, faza zarządzania ryzykiem, krok 13, Planowanie postępowania z ryzykiem i Deklaracja stosowania, opisuje Deklarację stosowania jako dokument pomostowy:
„SoA jest w praktyce dokumentem pomostowym: łączy ocenę ryzyka/postępowanie z ryzykiem z faktycznymi środkami kontrolnymi, które posiadasz. Wypełniając go, dodatkowo sprawdzasz, czy nie pominięto żadnych środków kontrolnych.”
Ta koncepcja ma centralne znaczenie dla gotowości do ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2 i DORA. Każde zabezpieczenie dla danych osobowych (PII) powinno być możliwe do prześledzenia od wymagania do ryzyka, od ryzyka do zabezpieczenia, od zabezpieczenia do właściciela, od właściciela do dowodu oraz od dowodu do przeglądu.
| Element identyfikowalności | Przykład dla danych osobowych (PII) w obsłudze klienta | Oczekiwane dowody |
|---|---|---|
| Aktywo zawierające dane osobowe (PII) | Platforma zgłoszeń wsparcia z imionami i nazwiskami klientów, adresami e-mail, logami i załącznikami | Wpis w rejestrze aktywów, właściciel, lokalizacja w chmurze, klasyfikacja |
| Cel przetwarzania | Obsługa klienta i diagnostyka usług | Rejestr przetwarzania, podstawa prawna, okres przechowywania |
| Scenariusz ryzyka | Agent wsparcia lub programista uzyskuje dostęp do nadmiernego zakresu danych klienta | Wpis w rejestrze ryzyk, prawdopodobieństwo, wpływ, właściciel |
| Dobór zabezpieczeń | 5.34 ochrona danych osobowych (PII), 5.18 prawa dostępu, 8.11 maskowanie, 8.15 rejestrowanie, 5.23 ład chmurowy | SoA, polityka dostępu, standard maskowania, konfiguracja rejestrowania |
| Dowody operacyjne | Dostęp oparty na rolach, zamaskowane eksporty, kwartalny przegląd uprawnień, alertowanie o masowych pobraniach | Zapisy przeglądów dostępu, alerty DLP, logi, dowody ze zgłoszeń |
| Mapowanie regulacyjne | Rozliczalność i bezpieczeństwo według GDPR, zarządzanie ryzykiem NIS2, ryzyko ICT i wymagania dostawców według DORA | Macierz zgodności, podręcznik incydentowy, rejestr umów z dostawcami |
| Dowody przeglądu | Zamknięte ustalenie z audytu wewnętrznego, zaakceptowane działanie z przeglądu zarządzania | Raport z audytu, działanie korygujące, protokół z przeglądu zarządzania |
ISO/IEC 27005:2022 wspiera to podejście oparte na ryzyku, kładąc nacisk na wymagania stron zainteresowanych, wspólne kryteria ryzyka, odpowiedzialnych właścicieli ryzyka, powtarzalną ocenę ryzyka, postępowanie z ryzykiem, dobór zabezpieczeń, dostosowanie Deklaracji stosowania, zatwierdzenie ryzyka rezydualnego, monitorowanie i ciągłe doskonalenie. Ochrona danych osobowych (PII) powinna być żywym cyklem ryzyka, a nie jednorazowym ćwiczeniem dokumentacyjnym GDPR.
Napraw ryzykowny arkusz kalkulacyjny i bazę środowiska przedprodukcyjnego
Incydent Sarah można przekształcić w powtarzalny pakiet zabezpieczeń, jeżeli działania naprawcze zostaną przeprowadzone systematycznie.
| Krok | Działanie | Wynik dowodowy Clarysec |
|---|---|---|
| 1 | Zarejestruj bazę środowiska przedprodukcyjnego i arkusz kalkulacyjny jako aktywa zawierające dane osobowe (PII) | Wpisy w inwentarzu aktywów z właścicielem, lokalizacją, klasyfikacją, kategoriami danych osobowych (PII), celem i okresem przechowywania |
| 2 | Zaktualizuj czynność przetwarzania | Wpis w rejestrze pokazujący kategorie danych, podstawę prawną, cel i okres przechowywania |
| 3 | Sklasyfikuj pliki i zbiory danych | Domyślnie zastosowana klasyfikacja Poufne lub wyższa do czasu formalnego przeglądu |
| 4 | Usuń rzeczywiste dane osobowe (PII) ze środowisk nieprodukcyjnych | Zamaskowany lub spseudonimizowany zbiór danych wygenerowany z zatwierdzonych szablonów transformacji |
| 5 | Ogranicz i przejrzyj dostęp | Uprawnienia zgodne z zasadą wiedzy koniecznej, cofnięty nadmierny dostęp, zapis przeglądu dostępu |
| 6 | Chroń logikę transformacji i klucze | Zaszyfrowany, kontrolowany dostępowo i rejestrowany dostęp do kluczy |
| 7 | Gromadź dowody centralnie | Rekord aktywa, wpis ryzyka, przegląd dostępu, dowód usunięcia, zatwierdzenie maskowania i zamknięcie zgłoszenia |
| 8 | Zaktualizuj SoA i plan postępowania z ryzykiem | Scenariusz ryzyka powiązany z 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 oraz zabezpieczeniami dotyczącymi dostawców |
| 9 | Zdecyduj, czy wymagana jest DPIA | DPIA lub udokumentowane uzasadnienie decyzji dotyczących przetwarzania wysokiego ryzyka |
| 10 | Udokumentuj wnioski | Zaktualizowane szkolenia, zasady bezpiecznego rozwoju oprogramowania, kontrole eksportu, monitorowanie DLP oraz wytyczne dotyczące danych testowych |
Audit and Compliance Monitoring Policy-sme Polityka audytu i monitorowania zgodności - SME stanowi:
„Wszystkie dowody muszą być przechowywane w scentralizowanym folderze audytowym.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.
Information Security Policy Polityka bezpieczeństwa informacji jasno określa szersze oczekiwanie audytowe:
„Wszystkie wdrożone środki kontrolne muszą podlegać kontroli audytowej, być wspierane udokumentowanymi procedurami oraz zachowanymi dowodami działania.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.6.1.
Te dwie klauzule stanowią różnicę między posiadaniem zabezpieczenia a możliwością jego wykazania.
Mapowanie wymagań zgodności dla jednego zestawu zabezpieczeń ochrony danych osobowych (PII)
Ochrona danych osobowych (PII) jest łatwiejsza do obrony, gdy zostanie zmapowana między ramami i regulacjami, zanim poprosi o to audytor.
| Obszar ochrony danych osobowych (PII) | Znaczenie dla GDPR | Znaczenie dla ISO/IEC 27001:2022, ISO/IEC 27701:2025 i ISO/IEC 29151:2022 | Znaczenie dla NIS2 | Znaczenie dla DORA | Perspektywa audytowa NIST i COBIT 2019 |
|---|---|---|---|---|---|
| Inwentarz danych osobowych (PII) i rejestr przetwarzania | Rozliczalność, podstawa prawna, ograniczenie celu, ograniczenie przechowywania | Kontekst SZBI, 5.9 inwentarz aktywów, zarządzanie informacjami o prywatności, ochrona danych osobowych (PII) | Zarządzanie aktywami i analiza ryzyka | Świadomość zależności aktywów i usług ICT | Dowody funkcji Identify oraz ład nad aktywami informacyjnymi |
| Prawa dostępu i zasada najmniejszych uprawnień | Integralność i poufność, dostęp ograniczony rolą | 5.15 kontrola dostępu, 5.16 zarządzanie tożsamością, 5.18 prawa dostępu, 8.2 prawa dostępu uprzywilejowanego | Kontrola dostępu, bezpieczeństwo HR, uwierzytelnianie | Kontrole ryzyka ICT i nadzór nad dostępem uprzywilejowanym | Egzekwowanie dostępu, własność, odpowiedzialność i monitorowanie |
| Maskowanie i pseudonimizacja | Minimalizacja danych, ochrona danych w fazie projektowania, bezpieczeństwo przetwarzania | 5.12 klasyfikacja, 5.34 ochrona danych osobowych (PII), 8.11 maskowanie danych, 8.33 informacje testowe | Cyberhigiena i bezpieczny rozwój oprogramowania | Bezpieczne testowanie, redukcja utraty danych, odporność operacyjna | Testowanie technicznych środków ochrony i wiarygodne działanie kontroli |
| Klasyfikacja i zgłaszanie incydentów | Ocena i zgłoszenie naruszenia ochrony danych osobowych | Planowanie incydentowe, ocena zdarzeń, reakcja, zabezpieczanie materiału dowodowego | Wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin, raport końcowy | Klasyfikacja i zgłaszanie istotnych incydentów związanych z ICT | Kryteria eskalacji, dzienniki decyzji, analiza przyczyny źródłowej, działania naprawcze |
| Przetwarzanie przez dostawców i w chmurze | Obowiązki podmiotu przetwarzającego, transfery, umowy | 5.21 łańcuch dostaw ICT, 5.23 usługi chmurowe, 5.31 wymagania prawne i umowne | Bezpieczeństwo łańcucha dostaw | Ryzyko stron trzecich ICT, prawa do audytu, wyjście i przejście | Ład stron trzecich, zapewnienie i rozliczalność zarządzania |
Właśnie tu Zenith Controls jest szczególnie przydatny. Dla 5.34 mapuje ochronę danych osobowych (PII) do inwentarza aktywów, maskowania danych i ładu chmurowego. Dla 8.11 mapuje maskowanie do klasyfikacji, ochrony prywatności i informacji testowych. Dla 5.18 mapuje prawa dostępu do kontroli dostępu, zarządzania tożsamością i dostępu uprzywilejowanego. Te relacje pozwalają zespołowi wyjaśnić nie tylko, że zabezpieczenie istnieje, ale także dlaczego istnieje i które sąsiednie zabezpieczenia muszą działać razem z nim.
Jak różni audytorzy testują to samo zabezpieczenie dla danych osobowych (PII)
Pojedyncze zabezpieczenie, takie jak 8.11 Maskowanie danych, będzie badane inaczej w zależności od perspektywy audytowej.
| Typ audytora | Główny punkt zainteresowania | Oczekiwane dowody |
|---|---|---|
| Audytor ISO/IEC 27001:2022 i ISO/IEC 27701:2025 | Integracja SZBI i PIMS, postępowanie z ryzykiem, poprawność SoA | Ocena ryzyka, wpis SoA, polityka maskowania, zapisy zmian, wyniki audytu wewnętrznego |
| Recenzent GDPR lub organ ochrony danych | Ochrona danych w fazie projektowania, minimalizacja, rozliczalność | Rejestr przetwarzania, podstawa prawna, DPIA, dowody pseudonimizacji, logika okresu przechowywania |
| Oceniający NIS2 | Bezpieczny rozwój oprogramowania, zapobieganie incydentom, ład | Procedura bezpiecznego rozwoju oprogramowania, szkolenie programistów, dowody remediacji incydentów, przegląd skuteczności kontroli |
| Klient lub audytor DORA | Odporność operacyjna ICT i ryzyko stron trzecich | Dowody testów aplikacji krytycznych, klauzule umów z dostawcami, obowiązki wsparcia incydentowego, planowanie odzyskiwania i wyjścia |
| Recenzent w stylu NIST lub COBIT 2019 | Projekt, działanie, własność i monitorowanie zabezpieczenia | Właściciel kontroli, wskaźniki, repozytorium materiału dowodowego, raportowanie zarządcze, działania korygujące |
Audytor ISO/IEC 27001:2022 zaczyna od logiki systemu zarządzania. Czy dane osobowe (PII) znajdują się w zakresie? Czy wymagania stron zainteresowanych zostały zidentyfikowane? Czy ryzyka prywatności są oceniane według zdefiniowanych kryteriów? Czy zabezpieczenia są dobierane poprzez postępowanie z ryzykiem? Czy SoA jest poprawna? Czy audyty wewnętrzne i przeglądy zarządzania obejmują zabezpieczenia związane z danymi osobowymi (PII)?
Recenzent prywatności zaczyna od rozliczalności. Jakie dane osobowe są przetwarzane? Jaka jest podstawa prawna? Czy osoby, których dane dotyczą, są informowane? Czy przetwarzanie jest ograniczone do konkretnego celu? Czy działania wysokiego ryzyka zostały ocenione? Czy podmioty przetwarzające są nadzorowane?
Oceniający skoncentrowany na NIS2 zaczyna od ładu i zarządzania ryzykiem cyberbezpieczeństwa. Czy kierownictwo zatwierdza środki i sprawuje nad nimi nadzór? Czy obsługa incydentów, ciągłość, bezpieczeństwo dostawców, kontrola dostępu, zarządzanie aktywami, bezpieczny rozwój oprogramowania i ocena skuteczności kontroli są zintegrowane?
Klient lub audytor DORA pyta, czy zarządzanie ryzykiem ICT jest udokumentowane, objęte nadzorem zarządu, proporcjonalne i wspierane umowami. Jeżeli dane osobowe (PII) są przetwarzane w usługach wspierających podmioty finansowe, należy spodziewać się pytań o pomoc incydentową, lokalizacje przetwarzania danych, odzyskiwanie, prawa do audytu, poziomy usług, zakończenie współpracy i wyjście.
Recenzent COBIT 2019 lub w stylu ISACA testuje dostosowanie ładu. Kto jest właścicielem ryzyka dotyczącego danych osobowych (PII)? Który organ ładu otrzymuje raporty? Czy odpowiedzialności są przypisane? Czy dostawcy są monitorowani? Czy odchylenia są śledzone? Czy wskaźniki są wykorzystywane do podejmowania decyzji? Czy ryzyko rezydualne zostało formalnie zaakceptowane?
Jeden model dowodowy może zaspokoić wszystkie te perspektywy, ale tylko wtedy, gdy system zabezpieczeń jest od początku projektowany pod kątem identyfikowalności.
Typowe ustalenia audytowe w programach ochrony danych osobowych (PII)
Organizacje, które podchodzą do gotowości ISO/IEC 27701:2025 lub wdrożenia ISO/IEC 29151:2022 bez zintegrowanego zestawu narzędzi, często napotykają te same ustalenia.
| Ustalenie | Dlaczego ma znaczenie | Działanie naprawcze Clarysec |
|---|---|---|
| Inwentarz danych osobowych (PII) nie obejmuje logów, kopii zapasowych, eksportów analitycznych ani załączników wsparcia | Ukryte dane osobowe (PII) nie mogą być niezawodnie chronione ani usuwane | Rozszerz inwentarz aktywów z kroku 9 i rejestr przetwarzania o wszystkie lokalizacje danych osobowych (PII) |
| Środowiska testowe wykorzystują dane produkcyjne | Rzeczywiste dane osobowe (PII) są ujawniane tam, gdzie nie są potrzebne | Egzekwuj politykę maskowania i zatwierdzone szablony transformacji |
| Przeglądy dostępu są ogólne i nie koncentrują się na repozytoriach danych osobowych (PII) | Nadmierny dostęp pozostaje niewykryty | Mapuj 5.18 prawa dostępu do właścicieli aktywów zawierających dane osobowe (PII) i dowodów okresowych przeglądów |
| Podstawa prawna jest udokumentowana, ale niepowiązana z systemami ani okresem przechowywania | Nie można wykazać rozliczalności GDPR | Dodaj pola podstawy prawnej i okresu przechowywania do rejestru przetwarzania oraz inwentarza aktywów |
| Umowy z dostawcami nie obejmują lokalizacji danych, pomocy incydentowej, praw do audytu ani postanowień dotyczących wyjścia | Pozostają luki w zapewnieniu dostawców według DORA, NIS2 i GDPR | Dostosuj due diligence dostawców i umowy do wymagań stron trzecich ICT oraz ładu chmurowego |
| Podręczniki incydentowe nie odróżniają incydentów bezpieczeństwa od naruszeń ochrony danych osobowych | Terminy zgłaszania mogą zostać przekroczone | Zbuduj drzewa klasyfikacji dla wyzwalaczy raportowania GDPR, NIS2 i DORA |
| Dowody są rozproszone po zgłoszeniach, dyskach, zrzutach ekranu i e-mailach | Gotowość do audytu zawodzi nawet wtedy, gdy zabezpieczenia działają | Stosuj scentralizowane foldery audytowe i standardy nazewnictwa dowodów |
To nie są problemy dokumentacyjne. To problemy modelu operacyjnego. ISO/IEC 27701:2025 i ISO/IEC 29151:2022 ich nie rozwiążą, jeśli ład prywatności, zabezpieczenia bezpieczeństwa i zarządzanie dowodami nie zostaną osadzone w normalnych przepływach pracy.
O co kierownictwo powinno zapytać przed następnym audytem
Przed rozpoczęciem gotowości ISO/IEC 27701:2025, wdrożenia ISO/IEC 29151:2022 albo oceny klienta pod kątem GDPR, NIS2 lub DORA kierownictwo powinno zadać dziesięć bezpośrednich pytań:
- Czy posiadamy kompletny rejestr czynności przetwarzania danych osobowych (PII), obejmujący kategorie danych, cel, podstawę prawną i okres przechowywania?
- Czy aktywa zawierające dane osobowe (PII) są oznaczone w inwentarzu aktywów, w tym logi, kopie zapasowe, eksporty, narzędzia analityczne i załączniki wsparcia?
- Czy klasyfikacje danych są przypisywane przy utworzeniu lub onboardingu, a aktywa bez przeglądu domyślnie otrzymują klasyfikację Poufne?
- Czy potrafimy wykazać, że dostęp do danych osobowych (PII) jest ograniczony do upoważnionych użytkowników zgodnie z zasadą wiedzy koniecznej?
- Czy środowiska programistyczne, testowe i przedprodukcyjne używają danych zamaskowanych lub spseudonimizowanych zamiast rzeczywistych danych osobowych?
- Czy szablony maskowania są zatwierdzone, a klucze chronione, objęte kontrolą dostępu i rejestrowane?
- Czy SoA łączy ryzyka dotyczące danych osobowych (PII) z zabezpieczeniami i obowiązkami regulacyjnymi?
- Czy umowy chmurowe i umowy z dostawcami są przeglądane pod kątem lokalizacji danych, bezpieczeństwa, wsparcia incydentowego, praw do audytu, odzyskiwania i wyjścia?
- Czy nasz proces incydentowy potrafi klasyfikować naruszenia ochrony danych osobowych według GDPR, istotne incydenty według NIS2 oraz poważne incydenty związane z ICT według DORA?
- Czy dowody są przechowywane centralnie i utrzymywane w sposób, który audytor może prześledzić?
Jeśli odpowiedź na którekolwiek z tych pytań jest niejasna, organizacja nie jest jeszcze gotowa do audytu.
Uczyń ochronę danych osobowych (PII) możliwą do wykazania
Nocny incydent Sarah mógł przerodzić się w chaotyczne działania zgodności. Zamiast tego może stać się punktem wyjścia dla silniejszego modelu operacyjnego: SZBI ISO/IEC 27001:2022 rozszerzonego o prywatność przez ISO/IEC 27701:2025, wzmocnionego praktykami ISO/IEC 29151:2022 i zmapowanego do GDPR, NIS2, DORA, modelu zapewnienia w stylu NIST oraz oczekiwań ładu COBIT 2019.
Na tym polega rzeczywista wartość gotowej do audytu ochrony danych osobowych (PII). Nie zależy ona od znalezienia właściwego arkusza kalkulacyjnego tuż przed przyjściem audytora. Zależy od systemu, który już wie, gdzie znajdują się dane osobowe (PII), dlaczego istnieją, jak są chronione, kto jest rozliczalny, którzy dostawcy są zaangażowani i gdzie znajdują się dowody.
Zacznij od Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, aby uporządkować wdrożenie. Użyj Zenith Controls: The Cross-Compliance Guide Zenith Controls, aby mapować ochronę danych osobowych (PII) między ISO/IEC 27001:2022, GDPR, NIS2, DORA, modelem zapewnienia w stylu NIST i oczekiwaniami ładu COBIT 2019. Zoperacjonalizuj prace za pomocą polityk Clarysec, w tym Data Protection and Privacy Policy Polityka ochrony danych i prywatności, Data Masking and Pseudonymization Policy Polityka maskowania danych i pseudonimizacji, Data Classification and Labeling Policy Polityka klasyfikacji i oznaczania informacji, Audit and Compliance Monitoring Policy-sme Polityka audytu i monitorowania zgodności - SME oraz Information Security Policy Polityka bezpieczeństwa informacji.
Jeśli zbliża się kolejny audyt klienta, przegląd GDPR, projekt gotowości NIS2 albo ocena dostawcy według DORA, nie czekaj, aż naruszenie ujawni luki. Pobierz zestawy narzędzi Clarysec, poproś o demo albo zaplanuj ocenę ochrony danych osobowych (PII) i zbuduj program prywatności, który jest nie tylko zgodny, ale też możliwy do obrony.
Frequently Asked Questions
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
