Macierz współodpowiedzialności w chmurze dla ISO, NIS2 i DORA

COO firmy fintech dzwoni do CISO w poniedziałek o 07:15.

Europejski klient bankowy prosi o dowody, że platforma SaaS spółki spełnia wymagania DORA dotyczące ryzyka ICT związanego z zewnętrznymi dostawcami. Zespół sprzedaży wysłał już standardowy pakiet bezpieczeństwa dostawcy: certyfikat ISO, podsumowanie zarządcze z testów penetracyjnych, certyfikat ubezpieczenia cybernetycznego, klauzulę informacyjną oraz raport zapewniający dostawcy usług chmurowych.

Bank wraca z bardziej precyzyjnym pytaniem:

„Pokażcie, kto jest właścicielem każdego środka kontrolnego w waszym środowisku chmurowym. Wy, wasz dostawca usług chmurowych, dostawca zarządzanej bazy danych, dostawca usług tożsamości, dostawca rejestrowania zdarzeń oraz wszystkie dalsze podmioty przetwarzające. A następnie pokażcie dowody”.

Tego samego poranka CISO ma posiedzenie zarządu. CEO zada to samo pytanie językiem biznesowym: „Czy mamy pewność, że ta platforma jest bezpieczna, i kto odpowiada, jeśli coś pójdzie nie tak?”

W tym miejscu zatrzymuje się wiele programów zgodności chmury obliczeniowej.

Organizacja może mieć silnego dostawcę usług chmurowych, dobre narzędzia, rozsądne polityki i rejestr ryzyk. Jednak gdy trzeba wykazać granice odpowiedzialności, dowody są rozproszone. Zakupy mają umowy. Dział prawny ma umowę powierzenia przetwarzania danych (DPA). Inżynieria ma diagramy architektury. Bezpieczeństwo ma logi i konfiguracje chmury. Prywatność ma wykaz dalszych podmiotów przetwarzających. Zgodność ma Deklarację stosowania. Nikt nie ma jednego kontrolowanego artefaktu, który — środek kontrolny po środku kontrolnym — wskazuje, co robi dostawca, co musi skonfigurować klient, który dalszy podmiot przetwarzający jest zaangażowany, która klauzula czyni obowiązek egzekwowalnym i jakich dowodów powinien oczekiwać audytor.

Tym artefaktem jest macierz współodpowiedzialności w chmurze.

Nie chodzi o ogólny slajd hiperskalera mówiący, że dostawca zabezpiecza chmurę, a klient zabezpiecza to, co znajduje się w chmurze. Rzeczywista macierz współodpowiedzialności w chmurze dla ISO/IEC 27001:2022, NIS2, DORA i GDPR jest zapisem ładu zarządczego. Wytrzymuje due diligence klienta, audyt ISO, przegląd DORA, wyzwanie w zakresie rozliczalności GDPR i dochodzenie incydentu.

Dlaczego współodpowiedzialność w chmurze staje się problemem audytowym

Model współodpowiedzialności jest zwykle przedstawiany jako granica techniczna. W IaaS dostawca zarządza obiektami fizycznymi, sprzętem, wirtualizacją i podstawową infrastrukturą. Klient zarządza tożsamościami, danymi, obciążeniami, regułami sieciowymi, decyzjami dotyczącymi szyfrowania i konfiguracjami. W SaaS dostawca przejmuje większą odpowiedzialność operacyjną, ale klient nadal odpowiada za dostęp użytkowników, ład nad danymi, podstawę prawną, konfigurację, oczekiwania dotyczące monitorowania i eskalację incydentów.

To wyjaśnienie jest użyteczne, ale niepełne.

Audytorzy, organy regulacyjne i klienci korporacyjni pytają o więcej niż „kto obsługuje środek kontrolny?”. Chcą wiedzieć:

• Kto odpowiada za ryzyko?
• Która klauzula umowna czyni tę odpowiedzialność egzekwowalną?
• Która polityka wymaga danego środka kontrolnego?
• Która usługa chmury obliczeniowej, platforma SaaS lub dalszy podmiot przetwarzający jest objęty zakresem?
• Które dowody potwierdzają działanie środka kontrolnego w okresie objętym przeglądem?
• Który wymóg ram zgodności jest spełniany przez dowody?
• Co się dzieje, jeśli dostawca zmienia usługę, lokalizację, dalszy podmiot przetwarzający lub profil kontroli?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 czyni z tego zagadnienie systemu zarządzania. Klauzule 4.1 do 4.4 wymagają od organizacji zrozumienia kwestii wewnętrznych i zewnętrznych, stron zainteresowanych, obowiązków prawnych i umownych, zakresu SZBI, interfejsów i zależności. Klauzule 6.1.1 do 6.1.3 wymagają oceny ryzyka, postępowania z ryzykiem, zatwierdzenia przez właściciela ryzyka, akceptacji ryzyka rezydualnego i Deklaracji stosowania. Klauzula 8.1 wymaga planowania i nadzoru operacyjnego, w tym kontroli procesów, produktów i usług dostarczanych z zewnątrz, które są istotne dla SZBI.

Mówiąc wprost, jeśli dostawca usług chmurowych, dostawca SaaS lub dalszy podmiot przetwarzający wspiera proces biznesowy objęty zakresem, nie może pozostawać poza SZBI. Musi być widoczny w zakresie, ryzyku, postępowaniu z ryzykiem, nadzorze umownym i dowodach.

NIS2 podnosi stawkę. Article 21 wymaga od podmiotów kluczowych i ważnych wdrożenia odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego pozyskiwania, bezpiecznego rozwoju oprogramowania, obsługi podatności, oceny skuteczności, cyberhigieny, kryptografii, bezpieczeństwa HR, kontroli dostępu, zarządzania aktywami oraz uwierzytelniania wieloskładnikowego lub ciągłego uwierzytelniania tam, gdzie jest to właściwe. Article 20 nakłada odpowiedzialność za ład zarządczy na organy zarządzające.

DORA jest jeszcze bardziej jednoznaczne w odniesieniu do podmiotów finansowych. Ma zastosowanie od 17 stycznia 2025 r. i wymaga od podmiotów finansowych zarządzania ryzykiem ICT, zgłaszania poważnych incydentów związanych z ICT, testowania cyfrowej odporności operacyjnej oraz zarządzania ryzykiem ICT związanym z zewnętrznymi dostawcami. Articles 28 do 30 wymagają zarządzania ryzykiem ICT związanym z zewnętrznymi dostawcami, wstępnej oceny ryzyka koncentracji, zabezpieczeń umownych, praw audytu i dostępu, widoczności podwykonawstwa, praw rozwiązania umowy i strategii wyjścia.

GDPR dodaje test rozliczalności. Article 5 wymaga przetwarzania danych osobowych z zachowaniem integralności i poufności, a Article 5(2) wymaga, aby administrator był w stanie wykazać zgodność. Article 28 reguluje umowy z podmiotami przetwarzającymi i dalsze podmioty przetwarzające. Article 32 wymaga bezpieczeństwa przetwarzania. Articles 33 i 34 wymagają zgłoszenia naruszenia ochrony danych osobowych, gdy ma to zastosowanie.

Macierz współodpowiedzialności w chmurze staje się pomostem między tymi obowiązkami.

Definicja Clarysec: artefakt ładu zarządczego, a nie diagram

W projektach Clarysec macierz współodpowiedzialności w chmurze jest kontrolowanym zapisem SZBI, który łączy usługi chmurowe, dostawców, dalsze podmioty przetwarzające, środki kontrolne, polityki, obowiązki umowne, dowody i oczekiwania audytowe.

Najmocniejsze wyjaśnienie znajduje się w Zenith Blueprint Zenith Blueprint, w fazie Controls in Action, Step 23:

„Dostawcy usług chmurowych zabezpieczają infrastrukturę, ale to wy nadal odpowiadacie za swoje dane, konfiguracje, polityki dostępu i gotowość do reagowania na incydenty”.

Ten sam krok wyjaśnia, że korzystanie z chmury obliczeniowej należy traktować jako część SZBI, obejmując klasyfikację usług chmurowych, zrozumienie przetwarzanych lub przechowywanych danych, ocenę dostawcy, klauzule umowne i zarządzanie zmianami usług. To przekształca współodpowiedzialność z koncepcji w możliwą do prześledzenia strukturę kontroli.

Zenith Controls Zenith Controls traktuje środki kontrolne załącznika A ISO/IEC 27001:2022 oraz wytyczne ISO/IEC 27002:2022 5.20, 5.21 i 5.23 jako centralne punkty odniesienia:

• 5.20, uwzględnianie bezpieczeństwa informacji w umowach z dostawcami.
• 5.21, zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT.
• 5.23, bezpieczeństwo informacji przy korzystaniu z usług w chmurze obliczeniowej.

Nie są to odrębne pozycje listy kontrolnej. One definiują kręgosłup macierzy.

Normy wspierające mogą wzmocnić macierz. ISO/IEC 27017 pomaga w praktykach bezpieczeństwa specyficznych dla chmury. ISO/IEC 27018 i ISO/IEC 27701 wspierają PII i ład prywatności. ISO/IEC 27005 wspiera ocenę ryzyka. ISO 22301 wspiera ciągłość działania i odporność. ISO/IEC 27035 wspiera zarządzanie incydentami. ISO/IEC 20000-1 może pomóc tam, gdzie usługi chmurowe są częścią zarządzanego świadczenia usług.

Minimalna użyteczna macierz współodpowiedzialności

Dojrzała macierz nie zaczyna się od 200 wierszy. Zaczyna się od usług w chmurze obliczeniowej, które mają największe znaczenie.

Dla SaaS, fintechu lub regulowanego MŚP Clarysec zwykle zaczyna od:

1. Produkcyjnego środowiska chmurowego dostępnego dla klientów.
2. Dostawcy usług tożsamości.
3. Zarządzanej bazy danych lub usługi przechowywania danych.
4. Platformy rejestrowania, monitorowania i SIEM.
5. SaaS do płatności, KYC, analityki lub obsługi klienta.
6. Usługi tworzenia kopii zapasowych i odtwarzania po awarii.
7. Dostawcy usług zarządzanych lub dostawcy zarządzanych usług bezpieczeństwa.
8. Dalszych podmiotów przetwarzających, które uzyskują dostęp do danych klientów, przechowują je lub przetwarzają.

Pierwsza macierz powinna obejmować następujące kolumny.

Praktyczny wiersz dotyczący rejestrowania może wyglądać następująco.

Ten wiersz nie jest tylko dokumentacją. Wskazuje zespołowi bezpieczeństwa, co skonfigurować, zakupom, jaki język umowny sprawdzić, prywatności, jaki przepływ danych zarejestrować, a audytorom, o jakie dowody poprosić.

Podstawa polityk: przekształcenie macierzy w egzekwowalny wymóg

Macierz współodpowiedzialności w chmurze bez oparcia w politykach jest tylko arkuszem kalkulacyjnym. Polityki Clarysec czynią ją egzekwowalną.

Dla MŚP Cloud Usage Policy - SME Cloud Usage Policy - SME, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula 5.3 wymaga:

„Rejestr usług chmurowych musi być utrzymywany przez dostawcę IT lub dyrektora generalnego. Musi zawierać:”.

Ta sama polityka dla MŚP, klauzula 5.2.3, łączy nadzór nad chmurą z ryzykiem prywatności i lokalizacji:

„Rezydencja danych i praktyki prywatności muszą być zgodne z mającymi zastosowanie wymogami prawnymi (np. GDPR)”.

Dla środowisk korporacyjnych Cloud Usage Policy Cloud Usage Policy, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula 5.1 stanowi:

„Organizacja musi utrzymywać scentralizowany Rejestr usług chmurowych, którego właścicielem jest CISO, obejmujący:”.

Następnie klauzula 5.4 czyni odpowiedzialności w chmurze egzekwowalnymi umownie:

„Wszystkie umowy z CSP (Cloud Service Provider) muszą zawierać egzekwowalne postanowienia dotyczące:”.

Nadzór nad dostawcami rozszerza macierz poza bezpośredniego dostawcę. Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula 5.3.5 wymaga:

„Ograniczeń dalszego podwykonawstwa bez zatwierdzenia”.

Ta sama polityka bezpieczeństwa dostawców dla MŚP, sekcja „Wymagania wdrożeniowe polityki”, klauzula 6.3.1 dodaje okresowy przegląd:

„Dostawcy krytyczni lub wysokiego ryzyka muszą być przeglądani co najmniej raz w roku. Przegląd musi zweryfikować:”.

Na poziomie korporacyjnym Third party and supplier security policy Third party and supplier security policy, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula 5.3 stanowi:

„Umowy z dostawcami muszą obejmować:”.

W odniesieniu do danych osobowych Data Protection and Privacy Policy Data Protection and Privacy Policy, sekcja „Egzekwowanie i zgodność”, klauzula 8.5.1 wymaga:

„Umowy z podmiotami przetwarzającymi muszą obejmować:”.

Dla widoczności zależności Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy, klauzula 6.5.4 wymaga:

„Wykorzystania relacji z dostawcą do uzyskiwania aktualizacji dotyczących podwykonawców lub zależności w łańcuchu dostaw o jeden poziom niżej, jeżeli mogą one mieć na nas wpływ (na przykład, jeśli krytyczny dostawca oprogramowania w dużym stopniu polega na bibliotece strony trzeciej, należy to zarejestrować)”.

Dla logów Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME, sekcja „Wymagania dotyczące ładu zarządczego”, klauzula 5.5.1.3 zapewnia konkretny wymóg umowny:

„Umowy muszą wymagać od dostawców przechowywania logów przez co najmniej 12 miesięcy oraz zapewnienia dostępu na żądanie”.

Łącznie polityki te czynią z macierzy wymagany zapis ładu zarządczego, który wspiera zatwierdzanie dostawców, wdrażanie usług chmurowych, rozliczalność prywatności, coroczny przegląd i dowody audytowe.

Mapowanie macierzy na ISO/IEC 27001:2022, NIS2, DORA i GDPR

Klasycznym błędem jest tworzenie czterech oddzielnych skoroszytów zgodności. Jeden środek kontrolny może spełniać kilka obowiązków, jeśli odpowiedzialność i dowody są możliwe do prześledzenia.

ISO/IEC 27001:2022 zapewnia silnik SZBI: kontekst, strony zainteresowane, zakres, przywództwo, postępowanie z ryzykiem, cele, nadzór operacyjny, ocenę wyników i doskonalenie. Załącznik A zapewnia praktyczną strukturę środków kontrolnych.

NIS2 Article 21 naturalnie mapuje się na tę samą macierz przez bezpieczeństwo łańcucha dostaw, obsługę incydentów, ciągłość działania, kontrolę dostępu, zarządzanie aktywami i bezpieczne pozyskiwanie. Article 20 czyni macierz istotną dla zarządu, ponieważ organy zarządzające muszą zatwierdzać i nadzorować środki zarządzania ryzykiem cyberbezpieczeństwa.

DORA przekształca macierz w narzędzie zarządzania ryzykiem ICT związanym z zewnętrznymi dostawcami. Articles 5, 6 i 8 wymagają ładu zarządczego, udokumentowanego zarządzania ryzykiem ICT oraz identyfikacji aktywów, funkcji i zależności. Articles 17 do 19 wymagają wykrywania incydentów, klasyfikacji, eskalacji, komunikacji i raportowania. Articles 28 do 30 wymagają zarządzania ryzykiem stron trzecich, analizy ryzyka koncentracji, klauzul umownych, kontroli podwykonawstwa, praw audytu, praw rozwiązania umowy i strategii wyjścia.

GDPR wnosi perspektywę danych osobowych. Każdy wiersz usługi chmurowej powinien wskazywać, czy przetwarzane są dane osobowe, czy dostawca jest podmiotem przetwarzającym lub dalszym podmiotem przetwarzającym, czy lokalizacja danych ma znaczenie oraz jakie istnieją dowody umowne lub DPA.

NIST CSF 2.0 pomaga komunikować tę samą macierz językiem wyników. Funkcja GOVERN obejmuje kontekst organizacyjny, wymogi prawne i regulacyjne, zależności, zarządzanie ryzykiem, role, polityki i nadzór. Wyniki GV.SC są szczególnie przydatne dla ryzyka cyberbezpieczeństwa dostawców, w tym ról dostawców, krytyczności, wymagań umownych, due diligence, monitorowania, koordynacji incydentów i planowania zakończenia współpracy.

COBIT 2019 dodaje perspektywę zapewnienia i ładu zarządczego. Pyta, czy rozliczalność, praktyki zarządzania, własność, monitorowanie i usuwanie problemów są powtarzalne oraz poparte dowodami.

Budowanie macierzy od rejestru do dowodu

Wyobraźmy sobie spółkę SaaS korzystającą z hiperskalowej platformy IaaS, zarządzanej bazy danych, zewnętrznego dostawcy usług tożsamości, platformy SaaS do obsługi klienta i zewnętrznego SIEM. Przebieg wdrożenia jest prosty.

Krok 1: Zacznij od Rejestru usług chmurowych

Użyj Cloud Usage Policy lub Cloud Usage Policy - SME jako wyzwalacza. Zarejestruj każdą usługę chmurową, właściciela, cel, kategorie danych, lokalizację, funkcję biznesową, poziom dostawcy, właściciela umowy i datę przeglądu.

Jeśli usługa przechowuje rejestry klientów, logi uwierzytelniania lub zgłoszenia wsparcia, oznacz ją jako istotną z punktu widzenia prywatności. Jeśli wspiera dostępność produkcyjną, oznacz ją jako krytyczną operacyjnie. Jeśli wspiera krytyczną lub ważną funkcję klienta finansowego, oznacz ją jako istotną dla DORA.

Krok 2: Dodaj domeny współodpowiedzialności

Dla każdej usługi określ odpowiedzialności w kluczowych domenach.

Krok 3: Połącz środki kontrolne z ryzykiem i Deklaracją stosowania

Zenith Blueprint, faza Risk Management, Step 13, wyjaśnia wymóg identyfikowalności:

„Odnieś się krzyżowo do regulacji: jeśli określone środki kontrolne są wdrożone specjalnie w celu spełnienia wymagań GDPR, NIS2 lub DORA, możesz odnotować to w Rejestrze ryzyk (jako część uzasadnienia wpływu ryzyka) albo w notatkach SoA”.

Na przykład ryzyko „nieuprawniony dostęp do produkcyjnych danych klienta przez błędną konfigurację chmury” może mapować się na kontrolę dostępu, korzystanie z chmury, rejestrowanie, kryptografię, zarządzanie podatnościami i umowy z dostawcami. SoA może odwoływać się do załącznika A ISO/IEC 27001:2022 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 i 8.24, z notatkami dotyczącymi GDPR Article 32, NIS2 Article 21 oraz zarządzania ryzykiem ICT w DORA, tam gdzie ma to zastosowanie.

Krok 4: Dołącz dowody przed sezonem audytowym

Dowody należy zaprojektować w macierzy, a nie zbierać w panice.

Lista dowodów przekształca odpowiedzialność w materiał audytowy. Pomaga również zespołom komercyjnym szybciej odpowiadać na korporacyjne due diligence, ponieważ mogą pokazać nie tylko certyfikaty, ale także własność kontroli i dowody działania.

Dalsze podmioty przetwarzające: martwy punkt większości macierzy

Dalsze podmioty przetwarzające to miejsce, w którym współodpowiedzialność staje się rzeczywistym ryzykiem łańcucha dostaw.

Dostawca SaaS może być podmiotem przetwarzającym w rozumieniu GDPR. Ten dostawca może polegać na dostawcy hostingu chmurowego, CDN, usłudze analitycznej, platformie wsparcia, usłudze dostarczania poczty elektronicznej, zarządzanej bazie danych, dostawcy obserwowalności i podmiocie obsługującym płatności. Niektórzy mogą uzyskiwać dostęp do danych osobowych. Niektórzy mogą wspierać krytyczny sposób świadczenia usługi bez bezpośredniego wglądu w dane. Niektórzy mogą znajdować się poza UE. Niektórzy mogą być zastępowalni. Inni mogą tworzyć ryzyko koncentracji.

DORA Article 29 wymaga oceny ryzyka koncentracji dla krytycznych lub ważnych usług ICT, w tym możliwości zastąpienia, wielu uzgodnień z tymi samymi lub powiązanymi dostawcami, łańcuchów podwykonawstwa, podwykonawców z państw trzecich, prawa upadłościowego, ograniczeń odzyskiwania danych oraz wykonalności unijnej ochrony danych. DORA Article 30 wymaga postanowień umownych dotyczących warunków podwykonawstwa, lokalizacji, przetwarzania i przechowywania danych, dostępu i odzyskiwania, wsparcia incydentowego, współpracy z organami, prawa do audytu, rozwiązania umowy i wyjścia.

NIS2 Article 21 podobnie wymaga bezpieczeństwa łańcucha dostaw dla bezpośrednich dostawców i dostawców usług, a także uwzględnienia podatności specyficznych dla dostawcy, praktyk cyberbezpieczeństwa dostawcy i procedur bezpiecznego rozwoju oprogramowania.

Dlatego Clarysec traktuje mapowanie dalszych podmiotów przetwarzających jako wymagane rozszerzenie nadzoru nad dostawcami, a nie listę utrzymywaną wyłącznie na potrzeby prywatności. Rejestr dalszych podmiotów przetwarzających powinien pokazywać, który dostawca korzysta z dalszego podmiotu przetwarzającego, od której usługi zależy, czy przetwarzane są dane osobowe, czy wspiera funkcję krytyczną, region przetwarzania tam, gdzie ma to znaczenie, obowiązki przenoszone na dalsze podmioty, prawa zatwierdzenia lub sprzeciwu, dostępne zapewnienie, metodę monitorowania i opcję wyjścia.

Zenith Blueprint, faza Controls in Action, Step 23 stanowi:

„Dla każdego krytycznego dostawcy ustal, czy korzysta z podwykonawców (dalszych podmiotów przetwarzających), którzy mogą uzyskiwać dostęp do twoich danych lub systemów. Udokumentuj, w jaki sposób twoje wymagania bezpieczeństwa informacji są przenoszone na te strony — przez warunki umowy twojego dostawcy albo przez twoje własne bezpośrednie klauzule”.

To jest poziom dowodów, jakiego oczekują audytorzy, gdy pytają, czy odpowiedzialności w chmurze są kontrolowane na dalszych poziomach łańcucha.

Jak audytorzy testują tę samą macierz

Silna macierz współodpowiedzialności w chmurze wytrzymuje różne style audytu, ponieważ jest zbudowana wokół własności, egzekwowalności i dowodów.

Macierz nie jest celem końcowym. Jest mapą, której audytorzy używają do sprawdzenia, czy system ładu zarządczego działa naprawdę.

Audytor ISO może wybrać ryzyko dostępu do chmury o wysokim wpływie i prześledzić je od rejestru ryzyk do SoA, a następnie do przeglądów dostępu, dowodów MFA i alertów monitorowania. Asesor DORA może wybrać krytycznego dostawcę ICT i poprosić o test wyjścia, analizę podwykonawstwa oraz umowne prawo do audytu. Przeglądający GDPR może skupić się na usuwaniu, rezydencji danych, zgłaszaniu naruszeń i przejrzystości dalszych podmiotów przetwarzających.

Typowe wzorce niepowodzeń

Najczęstsze niepowodzenia związane ze współodpowiedzialnością nie są egzotyczne.

Po pierwsze, organizacje polegają na raportach zapewniających dostawcy bez mapowania ich na odpowiedzialności klienta. Dostawca usług chmurowych może wykazać bezpieczeństwo fizyczne, odporność infrastruktury i kontrole platformowe, ale nie to, czy zasobnik pamięci masowej był prywatny, role IAM były zgodne z zasadą najmniejszych uprawnień albo logi były włączone.

Po drugie, umowy zawierają ogólny język bezpieczeństwa, ale nie zawierają terminów powiadamiania o incydentach, praw dostępu do logów, praw audytu, ograniczeń podwykonawstwa, postanowień dotyczących zwrotu danych ani wsparcia wyjścia. Zenith Blueprint, faza Controls in Action, Step 23 wskazuje typowe obszary umów z dostawcami, takie jak poufność, kontrola dostępu, środki techniczne i organizacyjne, terminy incydentów, prawo do audytu, kontrole podwykonawców i postanowienia dotyczące zakończenia umowy.

Po trzecie, dalsze podmioty przetwarzające są wymienione na potrzeby prywatności, ale nie są powiązane z bezpieczeństwem, ciągłością działania ani ryzykiem koncentracji. Dostawca obserwowalności lub wsparcia dalszego poziomu może nigdy nie pojawić się w rejestrze ryzyk, mimo że jego niedostępność lub naruszenie może wpłynąć na sposób świadczenia usługi klientowi.

Po czwarte, SoA wskazuje, że środek kontrolny ma zastosowanie, ale nikt nie potrafi przedstawić dowodów działania. Rejestrowanie w chmurze może być oznaczone jako wdrożone, ale organizacja nie potrafi wykazać ustawień retencji, przeglądów dostępu, obsługi alertów ani zobowiązań dostawcy dotyczących dostępu do logów.

Po piąte, plany reagowania na incydenty nie odzwierciedlają zależności od dostawcy. Jeśli dostawca powiadamia o incydencie platformowym, kto ocenia wpływ na klientów? Kto ustala, czy wymagane jest powiadomienie na podstawie NIS2, DORA lub GDPR? Kto kontaktuje się z dotkniętymi klientami? Co, jeśli przyczyna źródłowa leży po stronie dalszego podmiotu przetwarzającego?

Rozliczalność kierownictwa: dlaczego zarząd powinien się tym interesować

NIS2 Article 20 wymaga od organów zarządzających zatwierdzania środków zarządzania ryzykiem cyberbezpieczeństwa, nadzorowania wdrożenia i odbywania szkoleń. DORA Article 5 wymaga od organu zarządzającego zdefiniowania, zatwierdzenia i nadzorowania uzgodnień dotyczących zarządzania ryzykiem ICT oraz ponoszenia za nie odpowiedzialności, w tym za polityki ICT dotyczące stron trzecich, plany ciągłości i odzyskiwania, plany audytów, szkolenia i kanały raportowania.

To zmienia cel macierzy. Nie jest już tylko arkuszem bezpieczeństwa. Staje się dowodem, że kierownictwo wie:

• Które usługi chmurowe wspierają krytyczne operacje.
• Które strony trzecie i dalsze podmioty przetwarzające są istotne.
• Jakie obowiązki wynikają z umów z klientami, GDPR, NIS2 i DORA.
• Które odpowiedzialności pozostają po stronie organizacji.
• Które zobowiązania dostawcy są egzekwowalne umownie.
• Które luki wymagają finansowania, działań naprawczych lub akceptacji ryzyka.

Dla MŚP znaczenie ma proporcjonalność. Mniejszy podmiot nie potrzebuje rozbudowanej biurokracji, ale nadal potrzebuje dokumentacji, monitorowania, odpornych systemów, wykrywania źródeł ryzyka ICT, identyfikacji kluczowych zależności od stron trzecich, środków ciągłości działania, testowania, wniosków z incydentów i okresowego przeglądu tam, gdzie jest objęty zakresem.

Macierz jest jednym z najbardziej efektywnych proporcjonalnych narzędzi, ponieważ konsoliduje obowiązki zamiast je mnożyć.

30-dniowy sprint, aby przygotować model chmurowy do audytu

Jeśli nie potrafisz odpowiedzieć, kto jest właścicielem każdego środka kontrolnego w chmurze, jakie dowody to potwierdzają i który dalszy podmiot przetwarzający może na niego wpływać, twój model współodpowiedzialności nadal jest diagramem, a nie artefaktem ładu zarządczego.

Praktyczny 30-dniowy sprint wygląda następująco:

1. Utwórz lub zaktualizuj Rejestr usług chmurowych, korzystając z Cloud Usage Policy lub Cloud Usage Policy - SME.
2. Zidentyfikuj usługi krytyczne, przetwarzanie danych osobowych, systemy dostępne dla klientów oraz znaczenie dla DORA lub NIS2.
3. Zbuduj pierwszą macierz wokół środków kontrolnych załącznika A ISO/IEC 27001:2022 5.20, 5.21 i 5.23, korzystając z Zenith Controls.
4. Połącz każdy wiersz z rejestrem ryzyk i Deklaracją stosowania, korzystając ze Step 13 Zenith Blueprint.
5. Zweryfikuj klauzule dostawców i podmiotów przetwarzających, korzystając z Third party and supplier security policy, Third-Party and Supplier Security Policy - SME oraz Data Protection and Privacy Policy.
6. Dodaj dowody dotyczące retencji logów, eskalacji incydentów, zatwierdzania dalszych podmiotów przetwarzających, prawa do audytu i wyjścia.
7. Przeglądaj dostawców krytycznych corocznie oraz po istotnych zmianach, incydentach, nowych dalszych podmiotach przetwarzających lub ustaleniach z audytu.

Cel jest prosty. Gdy klient, audytor, regulator lub zarząd pyta „kto jest właścicielem tego środka kontrolnego?”, nie przeszukujesz umów, zgłoszeń i folderów. Otwierasz macierz, pokazujesz właściciela, pokazujesz klauzulę, pokazujesz dowody i pokazujesz ścieżkę w dół łańcucha.

Clarysec może pomóc przekształcić pakiety zapewnienia dostawców usług chmurowych w zintegrowaną macierz współodpowiedzialności dla audytów ISO/IEC 27001:2022, gotowości NIS2, ryzyka ICT związanego z zewnętrznymi dostawcami w DORA, rozliczalności GDPR i due diligence klientów korporacyjnych.

Zacznij od rejestru. Zbuduj macierz. Dołącz dowody. Następnie używaj jej jako gotowego dla zarządu dowodu, że ryzyko chmurowe nie jest outsourcowane — jest objęte ładem zarządczym.