Stosowalność zabezpieczeń ISO 27701 w zależności od ról GDPR

Jest wtorek, godzina 08:40. Maria, CISO szybko rosnącej spółki SaaS z sektora healthtech, patrzy na cztery wiadomości od klientów, które wyglądają niemal identycznie, ale oznaczają zupełnie różne rzeczy.

Jeden klient korporacyjny prosi o dowody, że spółka może działać jako podmiot przetwarzający w rozumieniu GDPR zgodnie z Article 28. Drugi pyta, czy platforma jest również administratorem dla telemetrii i analityki produktowej. Trzeci prosi o aktualną listę podwykonawców przetwarzania oraz dowód, że klauzule umowy powierzenia przetwarzania danych (DPA) są przenoszone na dalsze podmioty. Czwarty, klient fintech przygotowujący się do przeglądów dostawców DORA, pyta, czy te same zabezpieczenia w zakresie prywatności są zmapowane na odporność operacyjną, zgłaszanie incydentów i ryzyko ICT stron trzecich.

Spółka Marii nie działa niestarannie. Ma SZBI dostosowany do ISO/IEC 27001:2022, polityki prywatności, rejestr przetwarzania, MFA, szyfrowanie, przeglądy dostępu i szkolenia z uwzględniania ochrony danych w fazie projektowania. Wniosek klienta ujawnia jednak trudniejsze pytanie, które faktycznie weryfikują audytorzy i klienci:

Czy spółka potrafi wykazać, że właściwe zabezpieczenia ISO 27701 PIMS mają zastosowanie do właściwej roli GDPR, dla właściwej czynności przetwarzania, z właściwym właścicielem, dowodami i uzasadnieniem?

Właśnie w tym miejscu zawodzi wiele programów prywatności. Organizacje traktują ISO 27701 jak listę kontrolną, podczas gdy jednostki certyfikujące, audytorzy klientów i inspektorzy ochrony danych (DPO) oczekują uzasadnionej decyzji o stosowalności zabezpieczeń. Odpowiedź nie brzmi: „mamy zabezpieczenia prywatności”. Odpowiedź brzmi: „dla tej czynności przetwarzania jesteśmy administratorem, podmiotem przetwarzającym, współadministratorem albo podwykonawcą przetwarzania, a tutaj wskazujemy, dlaczego te zabezpieczenia mają albo nie mają zastosowania”.

Dlaczego stosowalność zabezpieczeń ISO 27701 jest brakującą warstwą PIMS

Role GDPR opierają się na uprawnieniach decyzyjnych. Administrator określa cele i sposoby przetwarzania. Podmiot przetwarzający działa w imieniu administratora. Współadministratorzy wspólnie określają cele i sposoby przetwarzania. Podwykonawca przetwarzania jest angażowany przez podmiot przetwarzający do dalszego przetwarzania danych osobowych w łańcuchu.

W rzeczywistych środowiskach SaaS role te rzadko pozostają jednoznaczne na poziomie całej spółki. Organizacja Marii jest podmiotem przetwarzającym, gdy hostuje dane wellness klientów, administratorem dla naliczania wynagrodzeń pracowników i kontaktów marketingowych, potencjalnym administratorem dla telemetrii produktu zależnie od celu i warunków umownych oraz współadministratorem w kampanii co-brandingowej. Jeżeli większy dostawca usług zarządzanych odsprzedaje jej platformę, spółka może również stać się podwykonawcą przetwarzania w tym łańcuchu.

Stosowalność zabezpieczeń ISO 27701 to dyscyplina, która zapobiega sprowadzeniu tych ról do ogólnikowych deklaracji. Wymaga odpowiedzi na pytania:

• Która czynność przetwarzania znajduje się w zakresie?
• Jaką rolę GDPR pełni organizacja dla tej czynności?
• Które zabezpieczenia PIMS mają zastosowanie z powodu tej roli?
• Które zabezpieczenia są wyłączone i dlaczego?
• Jakie dowody potwierdzają wdrożenie?
• Jaki wymóg prawny, umowny, związany z ryzykiem albo zakresem spowodował tę decyzję?

Polityka Privacy Information Management System Policy Clarysec ustanawia klasyfikację ról jako punkt wyjścia:

„[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 czynności przetwarzania”.

Z sekcji „Ustalenie roli PIMS”, klauzula polityki 4.2.1.

Ta sama polityka łączy decyzję o roli ze stosowalnością zabezpieczeń:

„[Both] 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”.

Z sekcji „Polityka prywatności, cele i stosowalność zabezpieczeń”, klauzula polityki 4.3.3.

REG02 odpowiada na pytanie, jakie przetwarzanie istnieje i jaka rola ma zastosowanie. REG03 odpowiada, które zabezpieczenia mają zastosowanie, co wyłączono, jakie dowody istnieją i dlaczego decyzja jest możliwa do obrony.

Buduj PIMS na logice SoA ISO/IEC 27001:2022

PIMS oparty na rolach działa najlepiej, gdy jest zbudowany na dojrzałym SZBI. ISO/IEC 27001:2022 wymaga już zdefiniowania zakresu, analizy stron zainteresowanych, oceny ryzyka, postępowania z ryzykiem, doboru zabezpieczeń i Deklaracji stosowania. ISO 27701 rozszerza tę logikę systemu zarządzania na prywatność.

Polityka Information Security Policy Clarysec stanowi:

„SZBI powinien obejmować zdefiniowane granice zakresu, metodykę oceny ryzyka, mierzalne cele oraz udokumentowane zabezpieczenia uzasadnione w Deklaracji stosowania (SoA)”.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.2.

Polityka Risk Management Policy wzmacnia tę samą dyscyplinę dowodową:

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

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.4.

Dla prywatności REG03 staje się rejestrem stosowalności zabezpieczeń PIMS, który odzwierciedla dyscyplinę SoA. Nie zastępuje SoA ISO/IEC 27001:2022. Wzbogaca ją o decyzje dotyczące prywatności specyficzne dla ról GDPR: administratorów, podmiotów przetwarzających, współadministratorów i podwykonawców przetwarzania.

Polityka PII Processing Inventory and Lawful Basis Policy wskazuje to powiązanie wprost:

„[Both] Osoba odpowiedzialna za prywatność / Menedżer PIMS MUSI powiązać mające zastosowanie czynności przetwarzania REG02 z zapisami stosowalności zabezpieczeń REG03 przed przeglądem gotowości do certyfikacji”.

Z sekcji „Prowadzenie inwentarza przetwarzania”, klauzula polityki 7.1.5.

Audytor powinien móc wybrać jedną czynność przetwarzania w REG02, ustalić rolę GDPR, prześledzić mające zastosowanie zabezpieczenia w REG03, zweryfikować odpowiednie zabezpieczenia ISO/IEC 27001:2022 w SoA oraz sprawdzić dowody, takie jak DPA, zapis podstawy prawnej, przegląd dostępu, zatwierdzenie podwykonawcy przetwarzania, procedura incydentowa albo log usuwania.

Model stosowalności zabezpieczeń oparty na rolach

Najszybszym sposobem na praktyczne wykorzystanie ISO 27701 jest ustalanie stosowalności na poziomie czynności przetwarzania, a nie na poziomie całej spółki.

Dostawca SaaS powinien unikać stwierdzenia: „jesteśmy podmiotem przetwarzającym”. Powinien wskazać: „dla rekordów użytkowników przesłanych przez klientów w platformie produkcyjnej jesteśmy podmiotem przetwarzającym. Dla naliczania wynagrodzeń jesteśmy administratorem. Dla analityki produktu nasza rola zależy od tego, czy analityka jest wykorzystywana wyłącznie do świadczenia zakontraktowanych usług, czy do naszych niezależnych celów. Dla dostawcy systemu zgłoszeniowego wspierającego dane klientów dostawca jest podwykonawcą przetwarzania”.

Taki widok oparty na rolach jest zgodny z rozliczalnością GDPR. Administratorzy muszą wykazywać zgodność z zasadami takimi jak zgodność z prawem, rzetelność, przejrzystość, ograniczenie celu, minimalizacja, prawidłowość, ograniczenie przechowywania, integralność, poufność i rozliczalność. Podmioty przetwarzające muszą przetwarzać dane wyłącznie na podstawie udokumentowanych poleceń, wdrażać odpowiednie zabezpieczenia, wspierać administratorów, zarządzać podwykonawcami przetwarzania oraz zapewniać zwrot lub usunięcie danych.

Ryzykownym skrótem jest założenie, że każde zabezpieczenie prywatności ma zastosowanie wszędzie. Podmiot przetwarzający zwykle nie ustala podstawy prawnej dla danych użytkowników końcowych klienta, ale musi wykazać, że przetwarza je wyłącznie na podstawie poleceń klienta. Administrator może nie potrzebować zatwierdzenia podwykonawców przetwarzania przez klienta dla wewnętrznego przetwarzania kadrowego, ale musi przeprowadzić due diligence podmiotu przetwarzającego dla dostawcy obsługi płac.

Klasyfikuj przed zatwierdzeniem umowy lub rozpoczęciem przetwarzania

Najczęstszym ustaleniem dotyczącym gotowości PIMS jest spóźniona klasyfikacja ról. Umowa jest podpisana, platforma działa w środowisku produkcyjnym, dostawcy są zintegrowani, a nikt nie ustalił, czy organizacja jest administratorem, podmiotem przetwarzającym, współadministratorem czy podwykonawcą przetwarzania dla każdego przepływu danych.

Takie opóźnienie powoduje problemy w dalszym łańcuchu. Używane jest niewłaściwe DPA. Podwykonawcy przetwarzania nie są ujawnieni. DPIA są pomijane. Retencja jest niejasna. Obsługa klienta nie wie, który termin zgłoszenia naruszenia ma zastosowanie. Zakupy traktują dostawcę wpływającego na prywatność jako „tylko narzędzie”.

Polityka Processor, Subprocessor and Third-Party Privacy Management Policy odnosi się bezpośrednio do momentu klasyfikacji:

„[Both] Osoba odpowiedzialna za prywatność / Menedżer PIMS MUSI sklasyfikować każdą relację dotyczącą prywatności ze stroną trzecią jako administrator, współadministrator, podmiot przetwarzający, podwykonawca przetwarzania albo inna relacja ze stroną trzecią w REG08 przed zatwierdzeniem umowy albo przed rozpoczęciem przetwarzania PII, w zależności od tego, co nastąpi wcześniej”.

Z sekcji „Identyfikacja i klasyfikacja relacji”, klauzula polityki 4.1.3.

Klasyfikacja dostawców i relacji ze stronami trzecimi w REG08 zasila REG03. Jeżeli dostawca jest podmiotem przetwarzającym, mające zastosowanie zabezpieczenia obejmują warunki DPA, poufność, środki bezpieczeństwa, prawa do audytu, wsparcie w obsłudze wniosków o realizację praw, wsparcie przy naruszeniach, zwrot lub usunięcie danych oraz zabezpieczenia dotyczące podwykonawców przetwarzania. Jeżeli dostawca jest niezależnym administratorem, punkt ciężkości przesuwa się na podstawę prawną, nadzór nad ujawnieniami, transfery, przejrzystość i rozliczalność.

W przypadku mniejszych organizacji polityka Third-Party and Supplier Security Policy - SME wymaga, aby zespoły uwzględniały:

„Ekspozycję regulacyjną (np. rola podmiotu przetwarzającego w rozumieniu GDPR, obowiązki sektora finansowego wynikające z DORA)”.

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.2.4.

Ustanawia również jednoznaczny wymóg przed udostępnieniem danych:

„Klauzule umowy powierzenia przetwarzania danych (DPA) albo równoważne warunki umowne muszą zostać uzgodnione przed udostępnieniem jakichkolwiek danych osobowych lub wrażliwych”.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.3.2.

Na tym polega różnica między posiadaniem umów z dostawcami a audytowalnym ładem ról w zakresie prywatności.

Mapuj zabezpieczenia na rolę, ryzyko, prawo i umowę

Zenith Blueprint, faza zarządzania ryzykiem, krok 13: planowanie postępowania z ryzykiem i Deklaracja stosowania, wyjaśnia podstawową logikę stosowalności. Zabezpieczenia mają zastosowanie z powodu decyzji dotyczących postępowania z ryzykiem, wymagań prawnych lub umownych, adekwatności do zakresu i kontekstu organizacji. Wyłączenia wymagają jasnych powodów, a mające zastosowanie zabezpieczenia powinny być możliwe do prześledzenia do ryzyka albo wymagania.

W kroku 13 Zenith Blueprint wskazuje:

„Zapewnij zgodność z rejestrem ryzyk: każde zabezpieczenie ograniczające ryzyko wskazane w planie postępowania z ryzykiem powinno odpowiadać zabezpieczeniu z Załącznika A oznaczonemu jako »mające zastosowanie«. Analogicznie, jeżeli zabezpieczenie oznaczono jako mające zastosowanie, powinno istnieć ryzyko albo wymaganie, które to uzasadnia”.

Dla ISO 27701 ta sama metoda ma zastosowanie do zabezpieczeń prywatności. Zabezpieczenie może mieć zastosowanie, ponieważ:

1. GDPR wymaga go dla roli organizacji.
2. Wymaga go umowa z klientem, DPA albo uzgodnienie między współadministratorami.
3. Wymaga go postępowanie z ryzykiem dla prywatności.
4. Przetwarzanie obejmuje szczególne kategorie danych, dane dzieci, monitorowanie na dużą skalę, wrażliwe profilowanie albo PII o istotnym wpływie.
5. Ryzyko związane z dostawcą, chmurą obliczeniową, podwykonawcą przetwarzania albo transferem transgranicznym powoduje, że zabezpieczenie jest konieczne.
6. Zabezpieczenie wspiera zakres certyfikacji, gotowość do audytu albo zatwierdzone cele prywatności.

Polityka Legal and Regulatory Compliance Policy wzmacnia tę dyscyplinę mapowania:

„Jeżeli regulacja ma zastosowanie w wielu obszarach (np. GDPR dotyczy retencji, bezpieczeństwa i prywatności), musi to zostać jasno zmapowane w Rejestrze zgodności i materiałach szkoleniowych”.

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.2.2.

Ta sama Legal and Regulatory Compliance Policy wprost odnosi się do integracji z korporacyjnym SZBI:

„Wszystkie obowiązki prawne i regulacyjne muszą zostać zmapowane do konkretnych polityk, zabezpieczeń i właścicieli w ramach systemu zarządzania bezpieczeństwem informacji (ISMS)”.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.

REG03 nie powinien więc nigdy być oderwanym arkuszem dotyczącym prywatności. Powinien łączyć czynności przetwarzania, obowiązki prawne, postępowanie z ryzykiem, umowy, zabezpieczenia ISO/IEC 27001:2022 i właścicieli dowodów.

Przykład praktyczny: proces obsługi zgłoszeń w SaaS

Rozważmy proces obsługi zgłoszeń w platformie SaaS Marii. Klienci przesyłają zgłoszenia, które mogą zawierać imiona i nazwiska, adresy e-mail, identyfikatory kont, zrzuty ekranu i sporadycznie wrażliwy kontekst biznesowy. Agenci wsparcia mają dostęp do ograniczonych rekordów. Chmurowy dostawca systemu zgłoszeniowego hostuje dane i korzysta z własnych podwykonawców przetwarzania.

Krok 1: Zarejestruj czynność w REG02

Osoba odpowiedzialna za prywatność rejestruje:

• Nazwa czynności: obsługa zgłoszeń wsparcia klienta
• Kategorie PII: identyfikatory użytkowników, dane kontaktowe, zrzuty ekranu, metadane konta
• Osoby, których dane dotyczą: administratorzy klientów i użytkownicy końcowi
• Cel: wsparcie i rozwiązywanie problemów dotyczących usługi
• Rola: podmiot przetwarzający dla PII użytkowników końcowych dostarczonych przez klienta; administrator dla bezpośredniego zarządzania kontaktami biznesowymi, jeżeli dane są wykorzystywane do komunikacji dotyczącej konta
• Retencja: zdefiniowany okres przechowywania dla wsparcia i audytu
• Odbiorcy: wewnętrzny personel wsparcia, dostawca systemu zgłoszeniowego, zatwierdzeni podwykonawcy przetwarzania
• Klasyfikacja bezpieczeństwa: poufne, PII

Polityka Data Protection and Privacy Policy - SME wspiera ten zestaw bazowy:

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

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.2.1.

Krok 2: Sklasyfikuj dostawcę w REG08

Jeżeli spółka Marii jest podmiotem przetwarzającym dla danych klienta, dostawca systemu zgłoszeniowego jest zwykle podwykonawcą przetwarzania dla tych danych klienta. REG08 powinien obejmować typ relacji, status umowy, kategorie danych, lokalizacje danych, dalszych podwykonawców przetwarzania oraz dowody zapewnienia.

Krok 3: Zarejestruj stosowalność w REG03

Korporacyjna Data Protection and Privacy Policy dodaje wyzwalacz wysokiego ryzyka:

„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.

Data Protection and Privacy Policy - SME wbudowuje oczekiwanie projektowe:

„Privacy by design and by default musi być egzekwowane we wszystkich nowych systemach i usługach”.

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.3.1.

Krok 4: Dostosuj do zabezpieczeń ISO/IEC 27001:2022

Jeżeli platforma wsparcia znajduje się w zakresie SZBI, SoA powinna obejmować wspierające zabezpieczenia ISO/IEC 27002:2022, takie jak relacje z dostawcami, umowy z dostawcami, zarządzanie łańcuchem dostaw ICT, kontrola dostępu, zarządzanie tożsamością, przekazywanie informacji, usługi w chmurze obliczeniowej, zarządzanie incydentami, rejestrowanie i monitorowanie, zarządzanie zmianami, zgodność prawna oraz ochrona prywatności.

Zenith Blueprint, faza zarządzania ryzykiem, krok 14: polityki postępowania z ryzykiem i odwołania regulacyjne, zaleca krzyżowe mapowanie GDPR, NIS2 i DORA względem polityk i zabezpieczeń, zwłaszcza w zakresie ochrony danych osobowych, reagowania na incydenty, kontroli dostępu, ciągłości działania i ryzyka ICT stron trzecich.

Rezultatem są dowody wielokrotnego użytku, a nie osobne arkusze dla GDPR, DORA, NIS2 i certyfikacji.

Co Zenith Controls wnosi do stosowalności PIMS

Zenith Controls to przewodnik Clarysec dotyczący zgodności przekrojowej, służący do zrozumienia relacji między zabezpieczeniami ISO/IEC 27001:2022 i ISO/IEC 27002:2022, metodami audytu oraz innymi ramami. Nie jest odrębnym zestawem zabezpieczeń. Dla tego tematu kluczowe zabezpieczenia ISO/IEC 27002:2022 to:

• 5.34 Privacy and protection of PII
• 5.19 Information security in supplier relationships
• 5.20 Addressing information security within supplier agreements
• 5.21 Managing information security in the ICT supply chain
• 5.22 Monitoring, review and change management of supplier services

Dla 5.34 Zenith Controls klasyfikuje zabezpieczenie jako zapobiegawcze, zmapowane na poufność, integralność i dostępność, dostosowane do Identify i Protect oraz powiązane ze zdolnościami ochrony informacji, prawnymi i zgodności.

Mapowanie GDPR wskazuje:

„Wdrożenie 5.34 jest bezpośrednim dowodem zdolności organizacji do spełnienia wymagań rozliczalności GDPR”.

Z Zenith Controls, Privacy and Protection of PII, mapowanie krzyżowe GDPR.

To zdanie ma znaczenie, ponieważ przekształca 5.34 z ogólnej deklaracji dotyczącej prywatności w dowód audytowy. Powinno być wspierane przez inwentarze PII, klasyfikację, kontrolę dostępu, maskowanie, bezpieczny transfer, nadzór nad chmurą obliczeniową, DPIA, klauzule informacyjne, procesy DSAR i obsługę naruszeń.

Zenith Controls łączy również prywatność i ochronę PII z powiązanymi normami, takimi jak ISO/IEC 27018 dla przetwarzania PII w chmurze publicznej, ISO/IEC 29100 dla zasad prywatności oraz ISO/IEC 29151 dla praktyk ochrony PII. Nadzór nad prywatnością dostawców wspiera rodzina ISO/IEC 27036 dotycząca relacji z dostawcami i bezpieczeństwa łańcucha dostaw ICT oraz ISO/IEC 27017 dla współdzielonej odpowiedzialności za bezpieczeństwo chmury.

Dowody dotyczące dostawców i podwykonawców przetwarzania to miejsce, w którym role się zbiegają

Obowiązki administratora i podmiotu przetwarzającego często spotykają się na granicy dostawcy.

Jeżeli spółka Marii jest administratorem, GDPR oczekuje, że będzie korzystać z podmiotów przetwarzających zapewniających wystarczające gwarancje. Jeżeli jest podmiotem przetwarzającym, klienci oczekują, że będzie zarządzać podwykonawcami przetwarzania, przenosić obowiązki na dalsze podmioty i dostarczać zapewnienie. Jeżeli jest podwykonawcą przetwarzania, dziedziczy obowiązki w łańcuchu.

Dlatego zabezpieczenia ISO/IEC 27002:2022 5.19 i 5.20 są kluczowe dla stosowalności zabezpieczeń ISO 27701.

Dla 5.19 Zenith Controls podkreśla bezpieczeństwo relacji z dostawcami w obszarach ładu zarządczego, ekosystemu i ochrony. Łączy je bezpośrednio z 5.20 dotyczącym umów z dostawcami, 5.21 dotyczącym bezpieczeństwa łańcucha dostaw ICT, 5.14 dotyczącym przekazywania informacji, 5.36 Compliance with policies, rules and standards for information security oraz 5.10 Acceptable use of information and other associated assets.

Dla 5.20 Zenith Controls podkreśla formalizację umowną. Umowy z dostawcami powinny określać poufność, zgłaszanie naruszeń, prawa do audytu, zatwierdzanie podwykonawców, bezpieczny transfer, zwrot lub zniszczenie danych, obowiązki zgodności oraz monitorowanie.

Zenith Blueprint, faza Controls in Action, krok 23: zabezpieczenia organizacyjne, podaje praktyczną instrukcję dotyczącą podwykonawców przetwarzania:

„Dla każdego krytycznego dostawcy ustal, czy korzysta z podwykonawców (podwykonawców przetwarzania), którzy mogą mieć dostęp do Twoich danych lub systemów. Udokumentuj, w jaki sposób Twoje wymagania bezpieczeństwa informacji są przenoszone na te podmioty — przez warunki umowne Twojego dostawcy albo przez Twoje własne bezpośrednie klauzule”.

Audytorzy nie poprzestaną na pytaniu: „czy macie DPA?”. Zapytają, czy dostawcy są podmiotami przetwarzającymi, podwykonawcami przetwarzania, niezależnymi administratorami czy współadministratorami; czy zatwierdzenia podwykonawców przetwarzania są udokumentowane; czy obowiązki są przenoszone na dalsze podmioty; czy terminy zgłaszania naruszeń są jasne; czy prowadzone jest monitorowanie; oraz czy można uzyskać dowody usunięcia albo zwrotu danych.

Zgodność przekrojowa bez zdublowanych systemów zabezpieczeń

Stosowalność zabezpieczeń ISO 27701 zyskuje na wartości, gdy wspiera rozmowy o zapewnieniu dla GDPR, NIS2, DORA, NIST CSF 2.0 i COBIT 2019 na podstawie tej samej bazy dowodowej.

GDPR wyznacza obowiązki prywatności oparte na rolach: rozliczalność administratora, obowiązki podmiotu przetwarzającego, podstawa prawna, prawa osób, których dane dotyczą, bezpieczeństwo, zarządzanie naruszeniami i umowy.

NIS2 dodaje zarządzanie ryzykiem cyberbezpieczeństwa, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczny rozwój oprogramowania, obsługę podatności, kontrolę dostępu, kryptografię, MFA i szkolenia dla podmiotów kluczowych i ważnych.

DORA ma zastosowanie od 17 stycznia 2025 r. do objętych zakresem podmiotów finansowych i wymaga zarządzania ryzykiem ICT, zgłaszania incydentów, testowania odporności oraz zarządzania ryzykiem ICT stron trzecich. Dostawcy SaaS i ICT obsługujący podmioty finansowe często są proszeni o przedstawienie dowodów dotyczących prywatności, bezpieczeństwa, odporności, praw do audytu i wyjścia w jednym pakiecie zapewnienia.

NIST CSF 2.0 zapewnia warstwę ładu zarządczego przez funkcję GOVERN, obejmującą obowiązki prawne, regulacyjne, umowne i dotyczące prywatności, role, apetyt na ryzyko, nadzór nad politykami i nadzór nad łańcuchem dostaw.

COBIT 2019 dodaje praktyki ładu zarządczego i zarządzania. Dla prywatności Zenith Controls mapuje 5.34 na COBIT DSS06.02, DSS06.08 i APO13.01. Dla dostawców 5.19 i 5.20 wspierają praktyki ryzyka dostawcy i umów z dostawcami.

Punkt strategiczny jest prosty. REG03 powinien być czymś więcej niż artefaktem ISO 27701. Powinien być mapą stosowalności zabezpieczeń wielokrotnego użytku dla audytów klientów, przeglądów regulacyjnych i zapewnienia na poziomie zarządu.

Jak audytorzy testują stosowalność zabezpieczeń ISO 27701

Różni audytorzy zaczynają od różnych punktów, ale zwykle dochodzą do tej samej ścieżki dowodowej.

Audytor systemu zarządzania ISO zaczyna od zakresu, stron zainteresowanych, obowiązków, oceny ryzyka, zgodności z SoA, audytu wewnętrznego, przeglądu zarządzania i ciągłego doskonalenia. Sprawdzi, czy REG02, REG03 i SoA ISO/IEC 27001:2022 są spójne.

Audytor skoncentrowany na GDPR albo osoba dokonująca przeglądu z perspektywy DPO testuje logikę ról. Pobierze próbki czynności, przejrzy podstawy prawne, klauzule informacyjne, DPA, podwykonawców przetwarzania, DPIA, obsługę DSAR, retencję i decyzje dotyczące naruszeń.

Asesor zorientowany na NIST szuka wyników ładu zarządczego, kategoryzacji ryzyka, inwentarzy danych, kontroli dostępu, ochrony danych w spoczynku i danych w tranzycie, monitorowania, reagowania na incydenty, ryzyka dostawców oraz planów doskonalenia.

Audytor COBIT 2019 albo ISACA patrzy na odpowiedzialność za ład zarządczy, zdolność procesu, skuteczność projektu kontroli i skuteczność działania. Sprawdzi, czy zabezpieczenia prywatności są wbudowane w zakupy, zarządzanie zmianami, zarządzanie incydentami i monitorowanie dostawców.

Dla 5.34 Zenith Controls opisuje, że audytorzy przeglądają polityki prywatności, inwentarze danych, DPIA, dzienniki szkoleń, techniczne środki ochrony, próbki DSAR, incydenty dotyczące PII i dowody privacy by design. Dla 5.19 i 5.20 audytorzy żądają inwentarzy dostawców, klasyfikacji ryzyka, zapisów due diligence, umów, warunków zgłaszania naruszeń, praw do audytu, zatwierdzania podwykonawców, dowodów wyjścia oraz potwierdzenia, że raporty dostawców są przeglądane.

To rozróżnienie jest krytyczne. Gotowość do audytu nie oznacza „mamy klauzulę”. Gotowość do audytu oznacza: „użyliśmy klauzuli, monitorowaliśmy ją, przejrzeliśmy dowody i zareagowaliśmy, gdy zmieniło się ryzyko”.

Typowe błędy w stosowalności dla administratorów i podmiotów przetwarzających

Clarysec regularnie obserwuje pięć możliwych do uniknięcia uchybień.

Po pierwsze, organizacje klasyfikują całą spółkę jako jedną rolę GDPR. To nie działa w przypadku SaaS, fintech, HR tech, healthtech, usług zarządzanych ani dostawców chmurowych z mieszanymi przepływami danych.

Po drugie, traktują zabezpieczenia ISO 27701 jako powszechnie stosowalne bez uzasadnienia wynikającego z roli. Tworzy to nadmierne wymagania dowodowe i słabe wyłączenia.

Po trzecie, wyłączają zabezpieczenia bez udokumentowania powodów. W logice SoA ISO/IEC 27001:2022 i logice stosowalności PIMS wyłączenia muszą być świadome, uzasadnione oraz wspierane analizą zakresu, roli, ryzyka albo wymagań prawnych.

Po czwarte, zapominają o podwykonawcach przetwarzania. Historia zapewnienia podmiotu przetwarzającego jest tak silna, jak jego dalszy łańcuch dostaw. Rejestry podwykonawców przetwarzania, mechanizmy zatwierdzania, klauzule przenoszące obowiązki na dalsze podmioty i dowody usuwania danych są niezbędne.

Po piąte, nie łączą zabezpieczeń prywatności z operacjami bezpieczeństwa. Privacy by design to nie tylko szablon DPIA. Powinna wpływać na kontrolę dostępu, rejestrowanie, bezpieczny rozwój oprogramowania, konfigurację chmury obliczeniowej, due diligence dostawców, automatyzację retencji i reagowanie na incydenty.

Lista kontrolna Clarysec dla stosowalności zabezpieczeń REG03

Użyj tej listy kontrolnej przed przeglądami gotowości ISO 27701, zapewnieniem dla klientów w zakresie GDPR albo ocenami dostawców wynikającymi z DORA:

• Utwórz albo zaktualizuj REG02 dla każdej czynności przetwarzania obejmującej PII.
• Sklasyfikuj rolę PIMS dla każdej czynności przed rozpoczęciem przetwarzania.
• Sklasyfikuj każdą relację ze stroną trzecią w REG08 przed zatwierdzeniem umowy albo przetwarzaniem PII.
• Ustal obowiązki na podstawie roli: administrator, podmiot przetwarzający, współadministrator albo podwykonawca przetwarzania.
• Zarejestruj mające zastosowanie zabezpieczenia PIMS w REG03 wraz z właścicielem, statusem wdrożenia i dowodami.
• Zarejestruj wyłączone zabezpieczenia z jasnym uzasadnieniem.
• Powiąż decyzje REG03 z ryzykami, obowiązkami prawnymi, umowami albo uzasadnieniem zakresu.
• Dostosuj REG03 do SoA ISO/IEC 27001:2022 tam, gdzie zabezpieczenia bezpieczeństwa wspierają prywatność.
• Zmapuj zabezpieczenia prywatności na ISO/IEC 27002:2022 5.34 tam, gdzie wymagana jest ochrona PII.
• Zmapuj wymagania dotyczące dostawców i podwykonawców przetwarzania na 5.19, 5.20, 5.21 i 5.22.
• Dodaj odniesienia do zgodności przekrojowej dla GDPR, NIS2, DORA, NIST CSF 2.0 i COBIT 2019 tam, gdzie jest to właściwe.
• Przetestuj ścieżkę dowodową na próbce audytu wewnętrznego przed przeglądem gotowości do certyfikacji.
• Uzyskaj zatwierdzenie najwyższego kierownictwa, gdy zmienia się zakres PIMS albo stosowalność zabezpieczeń.

Privacy Information Management System Policy domyka tę pętlę ładu zarządczego:

„[Both] Najwyższe kierownictwo MUSI zatwierdzić zmiany zakresu PIMS i stosowalności zabezpieczeń w REG01 oraz REG03 przed zgłoszeniem zmian zakresu certyfikacji”.

Z sekcji „Ład zarządczy PIMS”, klauzula polityki 6.1.3.

To jest rodzaj dowodów ładu zarządczego, któremu ufają audytorzy.

Przekształć decyzje o rolach GDPR w możliwe do obrony dowody

Stosowalność zabezpieczeń ISO 27701 to miejsce, w którym teoria ról GDPR staje się rzeczywistością operacyjną. Administrator potrzebuje dowodów dotyczących podstawy prawnej, przejrzystości, retencji, DPIA, obsługi praw osób i nadzoru nad podmiotami przetwarzającymi. Podmiot przetwarzający potrzebuje dowodów dotyczących udokumentowanych poleceń, poufności, bezpieczeństwa, wsparcia, podwykonawców przetwarzania, obsługi naruszeń i usuwania danych. Współadministrator potrzebuje przejrzystego uzgodnienia odpowiedzialności. Podwykonawca przetwarzania potrzebuje dowodów przeniesienia obowiązków na dalsze podmioty i wsparcia zapewnienia.

Clarysec pomaga organizacjom budować tę warstwę dowodową przez:

• Inwentarz przetwarzania REG02 i strukturę podstaw prawnych.
• Zapisy stosowalności zabezpieczeń REG03 PIMS.
• Klasyfikację relacji prywatności ze stronami trzecimi w REG08.
• Dostosowanie do SoA ISO/IEC 27001:2022.
• Klauzule polityk przypisujące właścicieli, terminy i wymagania zatwierdzania.
• Mapowanie zgodności przekrojowej przez Zenith Controls.
• Sekwencjonowanie wdrożenia przez Zenith Blueprint.

Jeżeli Twoja organizacja przygotowuje się do gotowości ISO 27701 PIMS, zapewnienia klientom zgodności z GDPR, przeglądów dostawców DORA albo ładu bezpieczeństwa dostosowanego do NIS2, zacznij od jednej czynności przetwarzania wysokiego ryzyka. Sklasyfikuj rolę. Zmapuj mające zastosowanie zabezpieczenia. Powiąż dowody. Następnie powtarzaj ten proces, aż program prywatności będzie nie tylko zgodny na papierze, lecz także możliwy do wyjaśnienia podczas audytu.

Pobierz pakiet polityk PIMS Clarysec, poznaj Zenith Blueprint albo zarezerwuj ocenę gotowości Clarysec, aby przekształcić decyzje dotyczące administratora, podmiotu przetwarzającego, współadministratora i podwykonawcy przetwarzania w rejestr dowodów prywatności gotowy do certyfikacji.