Dowody dotyczące TOMs dla GDPR Article 32 z ISO, NIS2 i DORA

Wiadomość e-mail trafia do skrzynki dyrektora ds. bezpieczeństwa informacji z dobrze znanym ciężarem transakcji, która może przesądzić o wyniku kwartalnym spółki.

Duży potencjalny klient korporacyjny oczekuje dowodów „środków technicznych i organizacyjnych zgodnych z GDPR Article 32, zmapowanych do ISO 27001:2022, NIS2 i DORA tam, gdzie ma to zastosowanie”. Jednocześnie dział prawny przedstawił zarządowi informacje o odpowiedzialności kierownictwa w NIS2 oraz oczekiwaniach DORA dotyczących odporności operacyjnej. Polecenie zarządu brzmi prosto: wykazać zgodność, uniknąć dublowania pracy i nie przekształcać tego w trzy odrębne projekty.

Organizacja ma wdrożone zabezpieczenia. MFA jest włączone. Kopie zapasowe są wykonywane. Programiści prowadzą przeglądy kodu. Zespół ds. prywatności utrzymuje rejestr czynności przetwarzania. Zespół infrastruktury skanuje podatności. Dostawcy są oceniani w procesie zakupowym. Jednak gdy potencjalny klient prosi o dowody, odpowiedź rozpada się na fragmenty.

Raport dostawcy tożsamości znajduje się w jednym miejscu. Logi kopii zapasowych są gdzie indziej. Rejestr ryzyk nie był aktualizowany od ostatniego wydania produktu. Dowody bezpieczeństwa dostawców tkwią w korespondencji zakupowej. Istnieją notatki z ćwiczenia tabletop dotyczącego reagowania na incydenty, ale nikt nie potrafi wykazać, że wnioski zostały włączone do postępowania z ryzykiem. Zarząd zatwierdził wydatki na bezpieczeństwo, ale zatwierdzenie nie jest powiązane z ryzykiem ICT ani z udokumentowaną decyzją dotyczącą zabezpieczeń.

To jest rzeczywisty problem ze środkami technicznymi i organizacyjnymi zgodnymi z GDPR Article 32, powszechnie określanymi jako TOMs. Większość organizacji nie ponosi porażki dlatego, że nie ma zabezpieczeń. Ponoszą ją dlatego, że nie potrafią wykazać, iż zabezpieczenia są oparte na ryzyku, zatwierdzone, wdrożone, monitorowane i doskonalone.

Rozliczalność w GDPR czyni to oczekiwanie jednoznacznym. GDPR Article 5 wymaga, aby dane osobowe były chronione za pomocą odpowiedniego poziomu bezpieczeństwa przed nieuprawnionym lub niezgodnym z prawem przetwarzaniem oraz przypadkową utratą, zniszczeniem lub uszkodzeniem. Article 5(2) nakłada na administratora odpowiedzialność za wykazanie zgodności. Definicje GDPR również mają znaczenie. Dane osobowe są pojęciem szerokim, przetwarzanie obejmuje niemal każdą operację na danych, pseudonimizacja jest uznanym zabezpieczeniem, a naruszenie ochrony danych osobowych obejmuje przypadkowe lub niezgodne z prawem zniszczenie, utratę, zmianę, nieuprawnione ujawnienie lub dostęp.

Pakiet dowodowy dla Article 32 nie może więc być folderem przypadkowych zrzutów ekranu. Musi być żywym systemem kontroli.

Podejście Clarysec polega na przekształceniu TOMs zgodnych z GDPR Article 32 w audytowalny mechanizm dowodowy oparty na ISO/IEC 27001:2022 ISO/IEC 27001:2022, wzmocniony zarządzaniem ryzykiem według ISO/IEC 27005:2022 oraz powiązany z obowiązkami NIS2 i DORA tam, gdzie mają zastosowanie. Celem nie jest dokumentacja dla samej dokumentacji. Celem jest osiągnięcie gotowości audytowej, zanim klient, audytor, regulator lub członek zarządu zada trudne pytanie.

Dlaczego TOMs zgodne z GDPR Article 32 zawodzą w praktyce

Article 32 jest często błędnie rozumiany jako lista narzędzi bezpieczeństwa: szyfrowanie, kopie zapasowe, logowanie, kontrola dostępu i reagowanie na incydenty. Te środki są ważne, ale są możliwe do obrony tylko wtedy, gdy są odpowiednie do ryzyka i powiązane z cyklem życia danych osobowych.

Dla spółki SaaS przetwarzającej dane pracowników klientów stwierdzenie „stosujemy szyfrowanie” nie wystarcza. Audytor może zapytać, jakie dane chroni szyfrowanie, gdzie szyfrowanie jest wymagane, w jaki sposób zarządza się kluczami, czy kopie zapasowe są szyfrowane, czy dane produkcyjne są maskowane w testach, kto może obejść zabezpieczenia oraz jak zatwierdza się wyjątki.

Korporacyjna Polityka ochrony danych i prywatności Clarysec ujmuje zasadę operacyjną następująco:

„Wdrożyć środki techniczne i organizacyjne (TOMs), które chronią poufność, integralność i dostępność informacji osobowych (PII) przez cały ich cykl życia.”

Źródło: Polityka ochrony danych i prywatności, Cele, klauzula polityki 3.3. Polityka ochrony danych i prywatności

Sformułowanie „przez cały ich cykl życia” wskazuje miejsce, w którym wiele programów TOMs słabnie. Dane osobowe mogą być chronione w środowisku produkcyjnym, ale kopiowane do systemów analitycznych, logów, eksportów wsparcia, środowisk testowych, kopii zapasowych, platform dostawców i urządzeń pracowników. Każda taka lokalizacja tworzy ryzyko dla bezpieczeństwa i prywatności.

GDPR Article 6 wymaga podstawy prawnej przetwarzania, obejmującej zgodę, umowę, obowiązek prawny, żywotne interesy, zadanie publiczne lub prawnie uzasadnione interesy. Gdy dane są ponownie wykorzystywane w innym celu, należy rozważyć zgodność celu oraz zabezpieczenia, takie jak szyfrowanie lub pseudonimizacja. Dla danych wyższego ryzyka ciężar dowodowy rośnie. GDPR Article 9 nakłada ścisłe ograniczenia na szczególne kategorie danych osobowych, takie jak dane dotyczące zdrowia, dane biometryczne wykorzystywane do identyfikacji oraz inne informacje wrażliwe. Article 10 ogranicza przetwarzanie danych dotyczących wyroków skazujących i czynów zabronionych.

Dla MŚP Clarysec ujmuje postępowanie z ryzykiem w praktycznym języku:

„Kontrole muszą być wdrożone w celu ograniczenia zidentyfikowanych ryzyk, w tym szyfrowanie, anonimizacja, bezpieczna utylizacja oraz ograniczenia dostępu”

Źródło: Polityka ochrony danych i prywatności dla MŚP, Postępowanie z ryzykiem i wyjątki, klauzula polityki 7.2.1. Polityka ochrony danych i prywatności - MŚP

To solidna podstawa TOMs. Aby osiągnąć gotowość audytową, każde zabezpieczenie musi być również powiązane z ryzykiem, właścicielem, wymaganiem polityki, elementem dowodowym oraz cyklem przeglądu.

ISO 27001:2022 jest kręgosłupem dowodów dla Article 32

ISO 27001:2022 dobrze wspiera GDPR Article 32, ponieważ traktuje bezpieczeństwo jako system zarządzania, a nie oderwaną od procesów listę kontrolną. Wymaga systemu zarządzania bezpieczeństwem informacji, czyli SZBI, zaprojektowanego w celu zachowania poufności, integralności i dostępności poprzez zarządzanie ryzykiem.

Pierwszym krytycznym krokiem jest zakres. Klauzule ISO 27001:2022 od 4.1 do 4.4 wymagają, aby organizacja rozumiała czynniki wewnętrzne i zewnętrzne, identyfikowała zainteresowane strony i ich wymagania, określała, które wymagania zostaną uwzględnione w SZBI, oraz definiowała zakres SZBI, w tym interfejsy i zależności z organizacjami zewnętrznymi. W przypadku TOMs zgodnych z Article 32 zakres SZBI powinien odzwierciedlać przetwarzanie danych osobowych, zobowiązania wobec klientów, podmioty przetwarzające, podprzetwarzających, platformy chmurowe, pracę zdalną, funkcje wsparcia i środowiska produktowe.

Drugim krokiem jest przywództwo. Klauzule 5.1 do 5.3 wymagają zaangażowania najwyższego kierownictwa, polityki bezpieczeństwa informacji, zasobów, ról i odpowiedzialności oraz raportowania wyników. Ma to znaczenie, ponieważ GDPR Article 32, NIS2 i DORA opierają się na ładzie zarządczym. Zabezpieczenie bez właściciela, finansowania lub przeglądu stanowi słaby dowód.

Korporacyjna Polityka bezpieczeństwa informacji Clarysec stwierdza to wprost:

„SZBI musi obejmować określone granice zakresu, metodykę oceny ryzyka, mierzalne cele oraz udokumentowane kontrole uzasadnione w Deklaracji stosowania (SoA).”

Źródło: Polityka bezpieczeństwa informacji, Wymagania dotyczące wdrożenia polityki, klauzula polityki 6.1.2. Polityka bezpieczeństwa informacji

Ta sama polityka określa oczekiwania dowodowe:

„Wszystkie wdrożone kontrole muszą być audytowalne, wspierane udokumentowanymi procedurami oraz zachowanymi dowodami działania.”

Źródło: Polityka bezpieczeństwa informacji, Wymagania dotyczące wdrożenia polityki, klauzula polityki 6.6.1.

Klauzule ISO 27001:2022 od 6.1.1 do 6.1.3 wymagają następnie oceny ryzyka, postępowania z ryzykiem, Deklaracji stosowania, zatwierdzenia ryzyka szczątkowego oraz odpowiedzialności właściciela ryzyka. Klauzula 6.2 wymaga mierzalnych celów. Klauzule 7.5, 9.1, 9.2, 9.3 i 10.2 wymagają udokumentowanych informacji, monitorowania, audytu wewnętrznego, przeglądu zarządzania oraz działań korygujących.

Dla GDPR Article 32 tworzy to możliwą do obrony strukturę.

ISO/IEC 27005:2022 wzmacnia tę strukturę. Zaleca organizacjom identyfikowanie wymagań z załącznika A do ISO 27001:2022, regulacji, umów, norm sektorowych, zasad wewnętrznych i istniejących zabezpieczeń, a następnie włączanie ich do oceny ryzyka i postępowania z ryzykiem. Wymaga również kryteriów ryzyka i kryteriów akceptacji, które uwzględniają czynniki prawne, regulacyjne, operacyjne, dostawców, technologiczne i ludzkie, w tym prywatność.

Polityka zarządzania ryzykiem Clarysec jest z tym bezpośrednio zgodna:

„Należy utrzymywać formalny proces zarządzania ryzykiem zgodny z ISO/IEC 27005 i ISO 31000, obejmujący identyfikację ryzyka, analizę, ocenę, postępowanie, monitorowanie i komunikację.”

Źródło: Polityka zarządzania ryzykiem, Wymagania ładu zarządczego, klauzula polityki 5.1. Polityka zarządzania ryzykiem

Dla MŚP to samo wymaganie staje się proste i wykonalne:

„Każdy wpis ryzyka musi zawierać: opis, prawdopodobieństwo, wpływ, punktację, właściciela oraz plan postępowania z ryzykiem.”

Źródło: Polityka zarządzania ryzykiem dla MŚP, Wymagania ładu zarządczego, klauzula polityki 5.1.2. Polityka zarządzania ryzykiem - MŚP

To zdanie jest szybkim testem gotowości audytowej. Jeżeli ryzyko nie ma właściciela ani planu postępowania, nie jest jeszcze gotowe dowodowo.

Most Clarysec: ryzyko, SoA, zabezpieczenia i regulacje

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint traktuje zgodność jako pracę nad identyfikowalnością. W fazie zarządzania ryzykiem Step 13 koncentruje się na planowaniu postępowania z ryzykiem oraz Deklaracji stosowania. Wyjaśnia, że organizacje powinny mapować zabezpieczenia do ryzyk, dodawać odniesienia do zabezpieczeń z załącznika A do wpisów dotyczących postępowania z ryzykiem, tworzyć odniesienia krzyżowe do regulacji zewnętrznych oraz uzyskiwać zatwierdzenie kierownictwa.

Zenith Blueprint mówi wprost o roli SoA:

„SoA jest w praktyce dokumentem pomostowym: łączy ocenę/postępowanie z ryzykiem z faktycznymi kontrolami, które posiadacie. Wypełniając ją, dodatkowo sprawdzacie, czy nie pominęliście żadnych kontroli.”

Źródło: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza zarządzania ryzykiem, Step 13: planowanie postępowania z ryzykiem i Deklaracja stosowania (SoA). Zenith Blueprint

Step 14 w Zenith Blueprint dodaje warstwę odniesień krzyżowych do regulacji. Zaleca organizacjom dokumentowanie, w jaki sposób wymagania GDPR, NIS2 i DORA są pokrywane przez polityki i zabezpieczenia. W przypadku GDPR podkreśla ochronę danych osobowych w ocenach ryzyka i działaniach dotyczących postępowania z ryzykiem, w tym szyfrowanie jako środek techniczny oraz reakcję na naruszenie jako część środowiska kontroli. W przypadku NIS2 wskazuje ocenę ryzyka, bezpieczeństwo sieci, kontrolę dostępu, obsługę incydentów i ciągłość działania. W przypadku DORA odwołuje się do zarządzania ryzykiem ICT, reagowania na incydenty, raportowania oraz nadzoru nad zewnętrznymi dostawcami ICT.

To jest sedno metody Clarysec: jeden SZBI, jeden rejestr ryzyk, jedna SoA, jedna biblioteka dowodów, wiele rezultatów zgodności.

Zenith Controls: The Cross-Compliance Guide Zenith Controls wspiera to podejście, pomagając organizacjom używać tematów zabezpieczeń ISO/IEC 27002:2022 ISO/IEC 27002:2022 jako kotwic dla zgodności międzyramowej. Dla GDPR Article 32 najważniejsze kotwice często obejmują prywatność i ochronę PII, kontrolę 5.34; niezależny przegląd bezpieczeństwa informacji, kontrolę 5.35; oraz użycie kryptografii, kontrolę 8.24.

NIS2 przekształca TOMs w zagadnienie cyberbezpieczeństwa na poziomie zarządu

Wiele organizacji traktuje TOMs zgodne z GDPR jako odpowiedzialność zespołu ds. prywatności. NIS2 zmienia tę rozmowę.

NIS2 ma zastosowanie do wielu średnich i dużych podmiotów w wymienionych sektorach, a w niektórych przypadkach niezależnie od wielkości. Objęte sektory cyfrowe i technologiczne obejmują dostawców usług chmurowych, dostawców centrów danych, sieci dostarczania treści, dostawców usług DNS, rejestry TLD, dostawców usług zaufania, publicznych dostawców łączności elektronicznej, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, internetowe platformy handlowe, wyszukiwarki oraz platformy społecznościowe. Zastosowanie do SaaS i technologicznych MŚP zależy od sektora, wielkości, wyznaczenia przez państwo członkowskie oraz wpływu systemowego lub transgranicznego.

NIS2 Article 20 nakłada odpowiedzialność za cyberbezpieczeństwo na organy zarządzające. Muszą one zatwierdzać środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorować ich wdrożenie oraz odbywać szkolenia. Podmioty kluczowe mogą podlegać administracyjnym karom pieniężnym w wysokości co najmniej 10 mln EUR lub co najmniej 2 procent rocznego światowego obrotu. Podmioty ważne mogą podlegać karom w wysokości co najmniej 7 mln EUR lub co najmniej 1,4 procent.

NIS2 Article 21 jest bezpośrednio istotny dla TOMs zgodnych z Article 32, ponieważ wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych. Środki te muszą uwzględniać stan wiedzy technicznej, normy europejskie i międzynarodowe, koszt, ekspozycję, wielkość, prawdopodobieństwo, wagę oraz wpływ społeczny lub gospodarczy. Wymagane obszary obejmują analizę ryzyka, polityki bezpieczeństwa, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczne nabywanie i rozwój, obsługę podatności, ocenę skuteczności, cyberhigienę, szkolenia, kryptografię, bezpieczeństwo HR, kontrolę dostępu, zarządzanie aktywami, MFA lub ciągłe uwierzytelnianie oraz bezpieczną komunikację tam, gdzie jest to właściwe.

NIS2 Article 23 dodaje etapowe zgłaszanie incydentów: wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie incydentu w ciągu 72 godzin, aktualizacje pośrednie na żądanie oraz raport końcowy nie później niż miesiąc po zgłoszeniu w terminie 72 godzin. Jeżeli naruszenie ochrony danych osobowych kwalifikuje się również jako znaczący incydent NIS2, pakiet dowodowy musi wspierać zarówno decyzje dotyczące prywatności, jak i decyzje dotyczące raportowania cyberbezpieczeństwa.

DORA podnosi poprzeczkę dla odporności finansowej i dostawców ICT

DORA obowiązuje od 17 stycznia 2025 r. i tworzy sektorowy zestaw zasad dla cyfrowej odporności operacyjnej w sektorze finansowym. Obejmuje zarządzanie ryzykiem ICT, raportowanie poważnych incydentów związanych z ICT, testowanie odporności operacyjnej, wymianę informacji o cyberzagrożeniach i podatnościach, ryzyko stron trzecich ICT, wymagania umowne dla dostawców ICT, nadzór nad krytycznymi zewnętrznymi dostawcami usług ICT oraz nadzór regulacyjny.

Dla podmiotów finansowych zidentyfikowanych również na podstawie krajowych przepisów NIS2 DORA działa jako sektorowy akt prawa Unii dla nakładających się obowiązków zarządzania ryzykiem cyberbezpieczeństwa i raportowania incydentów. W praktyce objęte podmioty finansowe powinny priorytetowo stosować DORA w tych nakładających się obszarach, utrzymując koordynację z właściwymi organami NIS2 i CSIRT tam, gdzie ma to znaczenie.

Dla dowodów zgodnych z GDPR Article 32 DORA ma znaczenie na dwa sposoby. Po pierwsze, firmy fintech mogą bezpośrednio podlegać regulacji jako podmioty finansowe, w tym instytucje kredytowe, instytucje płatnicze, dostawcy usług dostępu do informacji o rachunku, instytucje pieniądza elektronicznego, firmy inwestycyjne, dostawcy usług w zakresie kryptoaktywów, systemy obrotu i dostawcy usług finansowania społecznościowego. Po drugie, dostawcy SaaS, usług chmurowych, danych, oprogramowania i usług zarządzanych mogą być traktowani przez klientów finansowych jako zewnętrzni dostawcy usług ICT, ponieważ DORA szeroko definiuje usługi ICT.

DORA Article 5 wymaga ładu zarządczego i kontroli wewnętrznych dla zarządzania ryzykiem ICT, przy czym organ zarządzający definiuje, zatwierdza, nadzoruje i pozostaje odpowiedzialny za ustalenia dotyczące ryzyka ICT. Article 6 wymaga udokumentowanych ram zarządzania ryzykiem ICT, obejmujących strategie, polityki, procedury, protokoły ICT i narzędzia służące ochronie informacji oraz aktywów ICT. Article 17 wymaga procesu zarządzania incydentami związanymi z ICT, obejmującego wykrywanie, zarządzanie, powiadamianie, rejestrowanie, analizę przyczyny źródłowej, wskaźniki wczesnego ostrzegania, klasyfikację, role, komunikację, eskalację i reakcję. Article 19 wymaga zgłaszania poważnych incydentów związanych z ICT właściwym organom.

DORA Articles 28 i 30 czynią ryzyko stron trzecich ICT regulowanym obszarem kontroli. Podmioty finansowe pozostają odpowiedzialne za zgodność podczas korzystania z usług ICT. Potrzebują strategii zarządzania ryzykiem stron trzecich, rejestrów umownych, ocen krytyczności, due diligence, przeglądu ryzyka koncentracji, praw audytu i inspekcji, przesłanek wypowiedzenia, strategii wyjścia oraz postanowień umownych obejmujących lokalizacje danych, dostępność, autentyczność, integralność, poufność, wsparcie przy incydentach, odzyskiwanie, poziomy usług oraz współpracę z organami.

Dla Article 32 oznacza to, że dostawcy są częścią pakietu TOMs. Nie można wykazać bezpieczeństwa przetwarzania, jeżeli krytyczne podmioty przetwarzające, platformy chmurowe, dostawcy analityki, narzędzia wsparcia i dostawcy ICT nie są kontrolowani.

Praktyczne zbudowanie dowodów dla Article 32 w jeden tydzień

Silny pakiet dowodowy zaczyna się od jednego jasnego scenariusza ryzyka.

Użyj tego przykładu: „Nieuprawniony dostęp do danych osobowych klientów w aplikacji produkcyjnej”.

Utwórz lub odśwież wpis ryzyka. Uwzględnij opis, prawdopodobieństwo, wpływ, punktację, właściciela i plan postępowania z ryzykiem. Przypisz właściciela do Head of Engineering, menedżera ds. bezpieczeństwa informacji lub równoważnej roli rozliczalnej. Oceń prawdopodobieństwo na podstawie modelu dostępu, eksponowanej powierzchni ataku, znanych podatności i wcześniejszych incydentów. Oceń wpływ na podstawie wolumenu danych osobowych, wrażliwości danych, umów z klientami, konsekwencji GDPR oraz możliwego wpływu na usługi w NIS2 lub DORA.

Wybierz sposoby postępowania, takie jak MFA dla dostępu uprzywilejowanego, kontrola dostępu oparta na rolach (RBAC), kwartalne przeglądy dostępu, szyfrowanie danych w spoczynku, TLS, skanowanie podatności, logowanie, alertowanie, bezpieczne kopie zapasowe, procedury reagowania na incydenty oraz maskowanie danych w środowiskach nieprodukcyjnych.

Następnie zmapuj ryzyko do SoA. Dodaj odniesienia ISO/IEC 27002:2022, takie jak 5.34 Prywatność i ochrona PII, 8.24 Użycie kryptografii, 5.15 Kontrola dostępu, 5.18 Prawa dostępu, 8.13 Kopia zapasowa informacji, 8.15 Logowanie, 8.16 Działania monitorujące, 8.8 Zarządzanie podatnościami technicznymi, 8.25 Bezpieczny cykl życia rozwoju oraz 8.10 Usuwanie informacji tam, gdzie ma to zastosowanie. Dodaj notatki pokazujące, w jaki sposób te zabezpieczenia wspierają GDPR Article 32, NIS2 Article 21 oraz zarządzanie ryzykiem ICT według DORA tam, gdzie jest to istotne.

W mapowaniu regulacyjnym zachowuj poprawne nazwy zabezpieczeń i unikaj wymuszania fałszywej równoważności.

Teraz zbuduj folder dowodowy. Polityka audytu i monitorowania zgodności dla MŚP Clarysec podaje prostą zasadę:

„Wszystkie dowody muszą być przechowywane w scentralizowanym folderze audytowym.”

Źródło: Polityka audytu i monitorowania zgodności dla MŚP, Wymagania dotyczące wdrożenia polityki, klauzula polityki 6.2.1. Polityka audytu i monitorowania zgodności - MŚP

Dla tego jednego scenariusza ryzyka folder powinien zawierać:

Dowody dostępu nie powinny kończyć się na zrzutach ekranu. Polityka kontroli dostępu dla MŚP dodaje przydatne wymaganie operacyjne:

„Menedżer IT musi dokumentować wyniki przeglądów oraz działania korygujące.”

Źródło: Polityka kontroli dostępu dla MŚP, Wymagania ładu zarządczego, klauzula polityki 5.5.3. Polityka kontroli dostępu - MŚP

Dowody kopii zapasowych muszą wykazywać możliwość odzyskania danych, a nie tylko udane zadania. Polityka tworzenia kopii zapasowych i odtwarzania dla MŚP stanowi:

„Testy odtworzeniowe są przeprowadzane co najmniej kwartalnie, a wyniki są dokumentowane w celu weryfikacji możliwości odzyskania danych”

Źródło: Polityka tworzenia kopii zapasowych i odtwarzania dla MŚP, Wymagania ładu zarządczego, klauzula polityki 5.3.3. Polityka tworzenia kopii zapasowych i odtwarzania - MŚP

Daje to pełną pętlę dowodową: regulacja tworzy wymaganie, ryzyko wyjaśnia, dlaczego ma ono znaczenie, SoA wybiera zabezpieczenie, polityka definiuje działanie, a zachowane dowody potwierdzają, że zabezpieczenie działa.

Kontrole w praktyce: przekształcanie polityki w dowód operacyjny

Faza Controls in Action w Zenith Blueprint, Step 19, koncentruje się na weryfikacji technicznej. Zaleca przegląd zgodności bezpieczeństwa punktów końcowych, zarządzania tożsamością i dostępem, konfiguracji uwierzytelniania, bezpieczeństwa kontroli kodu źródłowego, pojemności i dostępności, zarządzania podatnościami i poprawkami, bezpiecznych konfiguracji bazowych, ochrony przed złośliwym oprogramowaniem, usuwania i minimalizacji danych, maskowania i danych testowych, DLP, kopii zapasowych i odtwarzania, redundancji, logowania i monitorowania oraz synchronizacji czasu.

Dla TOMs zgodnych z GDPR Article 32 Step 19 jest miejscem, w którym abstrakcyjny język kontroli staje się dowodem. Silny pakiet dowodowy powinien pokazywać, że:

• Szyfrowanie punktów końcowych jest włączone i monitorowane.
• Użytkownicy uprzywilejowani mają MFA.
• Procesy przyjęcia, zmiany roli i odejścia są uzgadniane z zapisami HR.
• Konta serwisowe są udokumentowane i ograniczone.
• Repozytoria kodu są objęte kontrolą dostępu, a skanowanie sekretów jest wykonywane.
• Skany podatności są prowadzone i śledzone do działań naprawczych.
• Dane produkcyjne nie są swobodnie kopiowane do środowisk testowych.
• Bezpieczne usuwanie i polityki okresu przechowywania są egzekwowane.
• Alerty DLP są przeglądane.
• Testy odtwarzania kopii zapasowych potwierdzają możliwość odzyskania danych.
• Logi są centralizowane, przechowywane i możliwe do przeglądu.
• Synchronizacja czasu wspiera wiarygodne dochodzenie incydentów.

Kluczowe jest powiązanie. Raport poprawek bez odniesienia do ryzyka, polityki i SoA jest artefaktem IT. Raport poprawek powiązany z GDPR Article 32, NIS2 Article 21, zarządzaniem ryzykiem ICT według DORA oraz planem postępowania z ryzykiem ISO 27001:2022 jest dowodem gotowym do audytu.

Jeden pakiet dowodowy, wiele perspektyw audytowych

Te same dowody TOMs będą odczytywane inaczej przez różnych interesariuszy. Recenzent ds. prywatności może koncentrować się na danych osobowych, konieczności, proporcjonalności i rozliczalności. Audytor ISO 27001 może koncentrować się na zakresie, postępowaniu z ryzykiem, SoA i dowodach działania. Organ NIS2 może koncentrować się na nadzorze kierownictwa, środkach z Article 21 oraz gotowości raportowania z Article 23. Organ nadzoru DORA lub klient finansowy może koncentrować się na ładzie zarządczym ryzyka ICT, testowaniu odporności i zależnościach od stron trzecich.

Clarysec używa Zenith Controls jako przewodnika zgodności międzyramowej dla tego tłumaczenia wymagań.

To zapobiega dublowaniu prac zgodności. Zamiast budować oddzielne pakiety dowodowe dla GDPR, NIS2 i DORA, zbuduj jeden pakiet dowodów kontroli i oznacz każdy element obowiązkami, które wspiera.

Typowe luki w programach TOMs zgodnych z Article 32

Najczęstszą luką jest osierocenie zabezpieczenia. Organizacja ma zabezpieczenie, na przykład szyfrowanie, ale nie potrafi wyjaśnić, jakie ryzyko ono ogranicza, która polityka go wymaga, kto jest jego właścicielem ani jak jest przeglądane.

Drugą luką są słabe dowody dotyczące dostawców. W GDPR znaczenie mają podmioty przetwarzające i podprzetwarzający. W NIS2 bezpieczeństwo łańcucha dostaw jest częścią zarządzania ryzykiem cyberbezpieczeństwa. W DORA ryzyko stron trzecich ICT jest regulowanym obszarem z rejestrami, due diligence, zabezpieczeniami umownymi, prawami audytu i planowaniem wyjścia. Arkusz dostawców nie wystarcza, jeżeli krytyczne zależności nie są oceniane pod kątem ryzyka i kontrolowane.

Trzecią luką są dowody incydentowe. Organizacje często mają plan reagowania na incydenty, ale nie mają dowodu, że klasyfikacja, eskalacja, raportowanie do organów i komunikacja z klientami zostały przetestowane. NIS2 i DORA podnoszą tutaj oczekiwania, a ocena naruszenia ochrony danych osobowych w GDPR musi być zintegrowana z tym samym przepływem pracy.

Czwartą luką są dowody kopii zapasowych. Udane zadanie kopii zapasowej nie dowodzi możliwości odzyskania danych. Udokumentowany test odtworzeniowy — tak.

Piątą luką jest przegląd zarządzania. TOMs zgodne z Article 32 muszą być proporcjonalne do ryzyka. Jeżeli kierownictwo nigdy nie przegląda ryzyk, incydentów, problemów dostawców, budżetu, ustaleń z audytu i ryzyka szczątkowego, proporcjonalność staje się trudna do wykazania.

Końcowy zestaw narzędzi gotowy do audytu

Faza Audit, Review and Improvement w Zenith Blueprint, Step 30, zapewnia końcową listę kontrolną gotowości. Obejmuje zakres i kontekst SZBI, podpisaną politykę bezpieczeństwa informacji, dokumenty oceny i postępowania z ryzykiem, SoA, polityki i procedury załącznika A, zapisy szkoleń, zapisy operacyjne, raport audytu wewnętrznego, rejestr działań korygujących, protokoły przeglądu zarządzania, dowody ciągłego doskonalenia oraz zapisy obowiązków zgodności.

Korporacyjna Polityka audytu i monitorowania zgodności Clarysec określa cel tej dyscypliny:

„Generowanie możliwych do obrony dowodów i ścieżki audytowej wspierających zapytania regulacyjne, postępowania sądowe lub wnioski klientów o zapewnienie.”

Źródło: Polityka audytu i monitorowania zgodności, Cele, klauzula polityki 3.4. Polityka audytu i monitorowania zgodności

Dojrzały pakiet dowodowy TOMs dla Article 32 powinien obejmować:

Następne kroki: zbuduj dowody TOMs dla Article 32 z Clarysec

Jeżeli musisz wykazać środki techniczne i organizacyjne zgodne z GDPR Article 32, nie zaczynaj od zbierania przypadkowych zrzutów ekranu. Zacznij od identyfikowalności.

1. Zdefiniuj zakres SZBI oraz granice przetwarzania danych osobowych.
2. Zidentyfikuj wymagania GDPR, NIS2, DORA, wymagania umowne i wymagania klientów.
3. Zbuduj kryteria ryzyka z wykorzystaniem ISO/IEC 27005:2022 oraz zatwierdzonego przez kierownictwo apetytu na ryzyko.
4. Utwórz lub odśwież rejestr ryzyk.
5. Zmapuj każde postępowanie z ryzykiem do zabezpieczeń ISO 27001:2022 i SoA.
6. Użyj Zenith Controls, aby krzyżowo powiązać kontrole prywatności, kryptografii, dostawców, incydentów i niezależnego przeglądu z oczekiwaniami zgodności.
7. Postępuj zgodnie ze Zenith Blueprint Step 13 i Step 14, aby połączyć ryzyka, zabezpieczenia i obowiązki regulacyjne.
8. Użyj Zenith Blueprint Step 19, aby zweryfikować działanie zabezpieczeń technicznych.
9. Użyj Zenith Blueprint Step 30, aby złożyć końcowy pakiet dowodowy gotowy do audytu.
10. Przechowuj wszystkie dowody centralnie, oznaczaj je według ryzyka i tematu kontroli oraz utrzymuj widoczność działań korygujących.

Clarysec może pomóc przekształcić GDPR Article 32 z niejasnego obowiązku zgodności w możliwy do obrony, oparty na ryzyku system dowodowy zgodny z ISO 27001:2022, NIS2 i DORA.

Zacznij od Zenith Blueprint, wzmocnij go politykami Clarysec i użyj Zenith Controls, aby każdy TOM był identyfikowalny, testowalny i gotowy do audytu.