Dowody audytowe ISO 27001 dla NIS2 i DORA

Jest wtorek, 08:17, a CISO szybko rosnącej spółki fintech SaaS ma trzy oczekujące wiadomości.

Pierwsza pochodzi od dużego klienta bankowego: „Prosimy o przesłanie najnowszego raportu z audytu wewnętrznego, protokołu z przeglądu zarządzania, statusu działań korygujących, procedury zgłaszania incydentów, rejestru dostawców oraz dowodów nadzoru zarządu”.

Druga jest od CFO: „Czy podlegamy NIS2 lub DORA i jakie dowody już mamy?”.

Trzecia jest od CEO: „Czy możemy powiedzieć, że jesteśmy gotowi do audytu?”.

Niewygodna odpowiedź w wielu organizacjach nie brzmi: „nic się nie dzieje”. Jest gorzej. Prace w obszarze bezpieczeństwa prowadzone są wszędzie, ale dowodów nie ma prawie nigdzie. Istnieją środki kontrolne, ale brakuje ścieżki audytowej. Są zgłoszenia, ale nie ma jasnego powiązania z ryzykami. Są aktualizacje dla kierownictwa, ale brakuje formalnych wyników przeglądu zarządzania. Są rozmowy z dostawcami, ale nie ma możliwego do obrony rejestru dostawców, przeglądu umów ani strategii wyjścia.

Właśnie w tej luce audyt wewnętrzny i przegląd zarządzania ISO/IEC 27001:2022 stają się czymś więcej niż działaniami certyfikacyjnymi. Stają się rytmem operacyjnym dla NIS2, DORA, GDPR, zapewnienia dla klientów, ubezpieczenia cybernetycznego i odpowiedzialności rozliczeniowej zarządu.

Zespoły SaaS, chmurowe, MSP, MSSP i fintech rzadko ponoszą porażkę dlatego, że brakuje im działań w zakresie bezpieczeństwa. Ponoszą ją dlatego, że działania są rozproszone między Slackiem, Jira, arkuszami kalkulacyjnymi, portalami dostawców, zgłoszeniami SOC, dokumentacją zakupową i materiałami dla zarządu. Regulator, audytor zewnętrzny lub klient korporacyjny nie oczekuje bohaterskiego wyjaśnienia. Oczekuje obiektywnych dowodów.

Praktycznym rozwiązaniem nie jest prowadzenie odrębnych programów audytowych dla każdej struktury wymagań. Rozwiązaniem jest wykorzystanie SZBI ISO 27001 jako centralnego mechanizmu dowodowego, a następnie oznaczanie dowodów pod kątem NIS2, DORA, GDPR i wymagań umownych. Dobrze zaprojektowany jeden cykl audytu wewnętrznego i jeden cykl przeglądu zarządzania mogą odpowiedzieć na wiele pytań dotyczących zgodności.

Od zmęczenia ramami wymagań do jednolitego modelu dowodowego SZBI

Wielu CISO mierzy się z wariantem problemu Marii. Maria odpowiada za bezpieczeństwo w spółce B2B SaaS obsługującej klientów z sektora finansowego. Jej zespół sześć miesięcy temu przeszedł audyt certyfikacyjny ISO/IEC 27001:2022. SZBI dojrzewa, polityki są stosowane, a właściciele środków kontrolnych rozumieją swoje obowiązki. Następnie CEO przesyła dwa artykuły, jeden o Dyrektywie NIS2 i drugi o DORA, z krótkim pytaniem: „Czy jesteśmy objęci?”.

Odpowiedź zależy od zakresu, usług, klientów i podmiotów prawnych. Odpowiedź operacyjna jest jednak jasna: jeżeli Maria potraktuje NIS2 i DORA jako odrębne projekty zgodności, stworzy zduplikowaną pracę, niespójne dowody i narastające zmęczenie audytami. Jeżeli potraktuje je jako wymagania zainteresowanych stron w ramach SZBI, może wykorzystać ISO 27001 do ich uwzględnienia, przetestowania i wykazania gotowości.

ISO/IEC 27001:2022 jest do tego zaprojektowana. Klauzula 4 wymaga, aby organizacja rozumiała swój kontekst i wymagania zainteresowanych stron, w tym obowiązki prawne, regulacyjne, umowne oraz wynikające z zależności. Klauzula 5 wymaga przywództwa i integracji z procesami biznesowymi. Klauzula 6 wymaga oceny ryzyka i postępowania z ryzykiem. Klauzula 9 wymaga oceny efektów działania poprzez monitorowanie, audyt wewnętrzny i przegląd zarządzania. Klauzula 10 wymaga doskonalenia i działań korygujących.

NIS2 i DORA naturalnie wpisują się w tę strukturę.

NIS2 wymaga, aby podmioty kluczowe i ważne wdrożyły odpowiednie i proporcjonalne techniczne, operacyjne i organizacyjne środki zarządzania ryzykiem cyberbezpieczeństwa. Nakłada również odpowiedzialność na organy zarządzające za zatwierdzanie tych środków, nadzorowanie ich wdrożenia oraz możliwość pociągnięcia do odpowiedzialności za naruszenia. Minimalne środki obejmują analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczny rozwój oprogramowania, obsługę podatności, ocenę skuteczności, szkolenia, kryptografię, bezpieczeństwo HR, kontrolę dostępu, zarządzanie aktywami oraz, w stosownych przypadkach, uwierzytelnianie wieloskładnikowe lub ciągłe uwierzytelnianie.

DORA obowiązuje od 17 stycznia 2025 r. i ustanawia sektorowy reżim cyfrowej odporności operacyjnej dla podmiotów finansowych. Wymaga odpowiedzialności organu zarządzającego za zarządzanie ryzykiem ICT, udokumentowanych ram zarządzania ryzykiem ICT, strategii cyfrowej odporności operacyjnej, planów ciągłości ICT i odtwarzania, testowania odporności, ładu w zakresie incydentów ICT oraz zarządzania ryzykiem ICT stron trzecich. W przypadku dostawców SaaS i chmury obsługujących podmioty finansowe DORA może pojawić się poprzez obowiązki umowne, audyty klientów oraz oczekiwania związane z zarządzaniem ryzykiem ICT stron trzecich, nawet gdy sam dostawca nie jest podmiotem finansowym.

GDPR dodaje warstwę rozliczalności. Jeżeli dane osobowe są przetwarzane w zakresie GDPR, organizacje muszą być w stanie wykazać zgodność z zasadami ochrony danych oraz odpowiednimi środkami technicznymi i organizacyjnymi.

ISO 27001 nie jest magicznym certyfikatem zgodności dla tych obowiązków. Jest systemem zarządzania, który może je uporządkować, udowodnić i doskonalić.

Pytanie o zakres: co udowadniasz i dla kogo?

Przed zbudowaniem pakietu dowodów gotowego do audytu kierownictwo musi odpowiedzieć na podstawowe pytanie: które obowiązki są w zakresie?

W przypadku firm SaaS i chmurowych zakres NIS2 może być szerszy, niż oczekiwano. NIS2 ma zastosowanie do podmiotów publicznych lub prywatnych w wymienionych sektorach, które spełniają progi wielkości, oraz do określonych podmiotów o dużym znaczeniu niezależnie od wielkości. Istotne sektory mogą obejmować infrastrukturę cyfrową, dostawców usług chmurowych, dostawców centrów danych, sieci dostarczania treści, dostawców usług zaufania, publicznych dostawców usług łączności elektronicznej oraz dostawców zarządzanych usług ICT w modelu B2B, takich jak dostawcy usług zarządzanych i dostawcy zarządzanych usług bezpieczeństwa. Dostawcy SaaS powinni szczególnie przeanalizować, jak świadczone są usługi, jakie sektory wspierają oraz czy umożliwiają administrację na żądanie i szeroki dostęp zdalny do skalowalnych współdzielonych zasobów obliczeniowych.

W przypadku dostawców fintech i dostawców usług dla sektora finansowego DORA należy przeanalizować odrębnie. DORA bezpośrednio obejmuje szeroki zakres podmiotów finansowych, w tym instytucje kredytowe, instytucje płatnicze, dostawców świadczących usługę dostępu do informacji o rachunku, instytucje pieniądza elektronicznego, firmy inwestycyjne, dostawców usług w zakresie kryptoaktywów, systemy obrotu, zarządzających funduszami, zakłady ubezpieczeń i reasekuracji oraz dostawców usług finansowania społecznościowego. Zewnętrzni dostawcy usług ICT również są częścią ekosystemu DORA, ponieważ podmioty finansowe muszą zarządzać swoimi zależnościami ICT, prowadzić rejestry uzgodnień umownych oraz uwzględniać konkretne postanowienia umowne dla usług ICT wspierających funkcje krytyczne lub ważne.

NIS2 i DORA również wchodzą ze sobą w interakcję. Jeżeli sektorowy akt prawny UE nakłada równoważne wymagania dotyczące zarządzania ryzykiem cyberbezpieczeństwa lub zgłaszania incydentów, odpowiednie przepisy NIS2 mogą nie mieć zastosowania do tych podmiotów w tych obszarach. DORA jest sektorowym reżimem odporności operacyjnej dla podmiotów finansowych. Nie czyni to NIS2 nieistotną dla wszystkich otaczających dostawców. Oznacza to, że model dowodowy musi rozróżniać, czy organizacja jest podmiotem finansowym bezpośrednio podlegającym DORA, zewnętrznym dostawcą usług ICT wspierającym podmioty finansowe, dostawcą SaaS objętym zakresem NIS2, czy grupą z wieloma podmiotami prawnymi i liniami usług.

Taka analiza zakresu powinna znaleźć się w kontekście SZBI i rejestrze zainteresowanych stron. Bez niej plan audytów będzie testował niewłaściwe obszary.

Jedna ścieżka audytowa, wiele pytań o zgodność

Częstym błędem jest tworzenie odrębnych pakietów dowodowych dla ISO 27001, NIS2, DORA, GDPR, ubezpieczenia cybernetycznego i audytów klientów. Takie podejście tworzy duplikację i sprzeczne odpowiedzi. Lepszym podejściem jest jeden model dowodowy z wieloma perspektywami.

W centrum znajduje się SZBI. Wokół niego funkcjonuje pięć rodzin dowodów.

Ta struktura jest spójna z Zenith Blueprint: 30-etapowa mapa drogowa audytora Zenith Blueprint. W fazie audytu, przeglądu i doskonalenia krok 25 koncentruje się na programie audytu wewnętrznego, krok 26 na realizacji audytu, krok 28 na przeglądzie zarządzania, a krok 29 na ciągłym doskonaleniu.

Wytyczne kroku 25 w Blueprint są celowo praktyczne:

„Opracuj harmonogram określający, kiedy odbędą się audyty i co będą obejmować”.

„Użyj szablonu planu audytu wewnętrznego, jeśli został dostarczony; może to być prosty dokument lub arkusz kalkulacyjny z datami audytów, zakresem i przypisanymi audytorami”.

Z Zenith Blueprint, faza audytu, przeglądu i doskonalenia, krok 25: Program audytu wewnętrznego Zenith Blueprint

Ten prosty plan audytów staje się skutecznym narzędziem, gdy jest oparty na ryzyku i oznaczony względem obowiązków NIS2, DORA i GDPR.

Środki kontrolne ISO 27001 stanowiące podstawę gotowości do audytu

Dla gotowości do audytu szczególnie istotne są trzy środki kontrolne ISO/IEC 27002:2022, interpretowane przez Zenith Controls: przewodnik zgodności przekrojowej Zenith Controls:

• 5.4 Odpowiedzialności kierownictwa
• 5.35 Niezależny przegląd bezpieczeństwa informacji
• 5.36 Zgodność z politykami, zasadami i normami bezpieczeństwa informacji

Nie są to odrębne „kontrole Zenith”. Są to środki kontrolne ISO/IEC 27002:2022, które Zenith Controls pomaga mapować, audytować i interpretować w różnych ramach wymagań.

Środek kontrolny 5.4 sprawdza, czy odpowiedzialności za bezpieczeństwo informacji są przypisane i rozumiane. Środek kontrolny 5.35 sprawdza, czy bezpieczeństwo informacji jest poddawane niezależnemu przeglądowi. Środek kontrolny 5.36 sprawdza, czy organizacja przestrzega swoich polityk, zasad i norm.

Zenith Controls klasyfikuje środek kontrolny 5.35 z perspektywy zapewnienia:

Środek kontrolny ISO/IEC 27002:2022 5.35, „Niezależny przegląd bezpieczeństwa informacji”, jest traktowany w Zenith Controls jako „zapobiegawczy, korygujący”, wspierający poufność, integralność i dostępność poprzez koncepcje cyberbezpieczeństwa „Identyfikuj” i „Chroń”, z operacyjną zdolnością w obszarze „Zapewnienie bezpieczeństwa informacji”. Zenith Controls

Ma to znaczenie, ponieważ audyt wewnętrzny jest jednocześnie zapobiegawczy i korygujący. Zapobiega martwym punktom przez testowanie SZBI przed kontrolą zewnętrzną i koryguje słabości poprzez udokumentowane działania.

Szersze mapowanie zaczyna się od wymagań NIS2 i DORA, a następnie identyfikuje dowody ISO 27001, które mogą je potwierdzić.

Mapowanie środków kontrolnych jest użyteczne tylko wtedy, gdy dowody są mocne. Jeśli zapis jest słaby, żadne mapowanie go nie uratuje. Jeśli zapis jest kompletny, ten sam materiał dowodowy może odpowiedzieć na pytania w stylu ISO, NIS2, DORA, GDPR, NIST Cybersecurity Framework 2.0 i COBIT 2019.

Dowody polityk, których przechowywania oczekuje Clarysec

Polityki Clarysec przekładają teorię SZBI na oczekiwania dowodowe.

Dla MŚP Polityka audytu i monitorowania zgodności dla MŚP Polityka audytu i monitorowania zgodności dla MŚP wymaga zatwierdzenia przez kierownictwo i dyscypliny audytowej:

„Dyrektor Generalny (GM) musi zatwierdzić roczny plan audytów”.

Z Polityka audytu i monitorowania zgodności dla MŚP, wymagania ładu zarządczego, klauzula 5.1.1 Polityka audytu i monitorowania zgodności dla MŚP

Ustanawia również minimalną częstotliwość:

„Audyty wewnętrzne lub przeglądy zgodności muszą być przeprowadzane co najmniej raz w roku”.

Z Polityka audytu i monitorowania zgodności dla MŚP, wymagania ładu zarządczego, klauzula 5.2.1

Łączy też ustalenia z korektą i przeglądem zarządzania:

„GM musi zatwierdzić plan działań korygujących i śledzić jego wdrożenie”.

Z Polityka audytu i monitorowania zgodności dla MŚP, wymagania ładu zarządczego, klauzula 5.4.2

„Ustalenia z audytu i aktualizacje statusu muszą być uwzględniane w procesie przeglądu zarządzania SZBI”.

Z Polityka audytu i monitorowania zgodności dla MŚP, wymagania ładu zarządczego, klauzula 5.4.3

Wymóg przechowywania dowodów jest również jednoznaczny:

„Dowody muszą być przechowywane przez co najmniej dwa lata lub dłużej, jeżeli wymagają tego certyfikacja albo umowy z klientami”.

Z Polityka audytu i monitorowania zgodności dla MŚP, wymagania dotyczące wdrożenia polityki, klauzula 6.2.4

Dla większych organizacji Polityka audytu i monitorowania zgodności Polityka audytu i monitorowania zgodności, określana także w niektórych materiałach Clarysec jako P33 Polityka audytu i monitorowania zgodności, rozbudowuje tę strukturę:

„Plan audytów oparty na ryzyku powinien być opracowywany i zatwierdzany corocznie, z uwzględnieniem:”.

Z Polityka audytu i monitorowania zgodności, wymagania ładu zarządczego, klauzula 5.2 Polityka audytu i monitorowania zgodności

„Organizacja powinna prowadzić Rejestr audytów zawierający:”.

Z Polityka audytu i monitorowania zgodności, wymagania ładu zarządczego, klauzula 5.4

„Audyty wewnętrzne powinny przebiegać zgodnie z udokumentowaną procedurą obejmującą:”.

Z Polityka audytu i monitorowania zgodności, wymagania dotyczące wdrożenia polityki, klauzula 6.1.1

„Wszystkie ustalenia powinny skutkować udokumentowanym CAPA obejmującym:”.

Z Polityka audytu i monitorowania zgodności, wymagania dotyczące wdrożenia polityki, klauzula 6.2.1

Przegląd zarządzania jest osadzony w Polityka bezpieczeństwa informacji Polityka bezpieczeństwa informacji, określanej również w niektórych materiałach Clarysec jako P01 Polityka bezpieczeństwa informacji:

„Działania przeglądu zarządzania (zgodnie z ISO/IEC 27001 Clause 9.3) powinny być prowadzone co najmniej raz w roku i powinny obejmować:”.

Z Polityka bezpieczeństwa informacji, wymagania ładu zarządczego, klauzula 5.3 Polityka bezpieczeństwa informacji

Te wymagania tworzą łańcuch dowodowy oczekiwany przez audytorów: zatwierdzony plan, zdefiniowana procedura, rejestr audytów, ustalenia, CAPA, przechowywanie oraz przegląd przez kierownictwo.

Budowanie pakietu dowodowego gotowego do audytu

Pakiet dowodowy gotowy do audytu nie jest ogromnym folderem tworzonym dwa dni przed audytem. Jest żywą strukturą utrzymywaną przez cały rok.

Pakiet dowodowy powinien być zmapowany do klauzul ISO/IEC 27001:2022 i środków kontrolnych z Annex A, ale oznaczony pod kątem znaczenia regulacyjnego. Na przykład zapis audytu dostawcy może wspierać środki kontrolne Annex A dotyczące dostawców, bezpieczeństwo łańcucha dostaw NIS2 oraz zarządzanie ryzykiem ICT stron trzecich w DORA. Zapis ćwiczenia typu tabletop dotyczącego incydentu może wspierać zarządzanie incydentami ISO 27001, gotowość do etapowego zgłaszania w NIS2 oraz ład w zakresie poważnych incydentów związanych z ICT w DORA.

Jak przeprowadzić zintegrowany audyt wewnętrzny

Krok 26 Zenith Blueprint podkreśla znaczenie obiektywnych dowodów:

„Przeprowadź audyt, gromadząc obiektywne dowody dla każdego elementu na liście kontrolnej”.

„Przeprowadź wywiady z właściwym personelem”.

„Przejrzyj dokumentację”.

„Obserwuj praktyki”.

„Pobieraj próbki i wykonuj wyrywkowe kontrole”.

Z Zenith Blueprint, faza audytu, przeglądu i doskonalenia, krok 26: Realizacja audytu Zenith Blueprint

Dokładnie tego wymaga gotowość do NIS2 i DORA. Regulatorzy i klienci nie zaakceptują stwierdzenia „uważamy, że to działa”. Zapytają, skąd to wiadomo.

Dobrze przeprowadzony audyt testuje cztery wymiary dowodów.

Rozważmy symulowane zdarzenie ransomware na serwerze stagingowym. Audytor sprawdza, czy proces reagowania na incydenty może spełnić wymagania ISO 27001, oczekiwania NIS2 dotyczące etapowego raportowania oraz zobowiązania wobec klientów wynikające z DORA.

NIS2 przewiduje etapową strukturę raportowania istotnych incydentów, obejmującą wczesne ostrzeżenie w ciągu 24 godzin od uzyskania świadomości, zgłoszenie incydentu w ciągu 72 godzin oraz raport końcowy w ciągu jednego miesiąca od zgłoszenia incydentu. DORA ma własne ramy klasyfikacji i raportowania incydentów związanych z ICT dla podmiotów finansowych. Audyt wewnętrzny powinien weryfikować, czy podręczniki postępowania obejmują czas uzyskania świadomości, kryteria wagi, dotknięte usługi, wskaźniki naruszenia, działania łagodzące, przyczynę źródłową, obowiązki powiadamiania klientów oraz dane do raportu końcowego.

Przekształcenie jednego ustalenia audytowego w dowody dla NIS2 i DORA

Realistyczne ustalenie dotyczące dostawcy pokazuje, jak powinien przebiegać przepływ dowodów.

Podczas audytu wewnętrznego audytor pobiera próbkę pięciu dostawców krytycznych. Jeden dostawca logowania w chmurze wspiera monitorowanie oszustw i alertowanie bezpieczeństwa dla platformy fintech. Dostawca znajduje się w inwentarzu, ale brakuje udokumentowanego planu wyjścia, dowodu corocznego przeglądu bezpieczeństwa oraz potwierdzenia, że umowa obejmuje wsparcie przy incydentach lub prawo do audytu.

Audytor rejestruje niezgodność dotyczącą bezpieczeństwa dostawcy i wymagań wyjścia z chmury. Słaba odpowiedź brzmiałaby: „brak przeglądu dostawcy”. Silna odpowiedź tworzy łańcuch dowodowy zgodności przekrojowej:

1. Zarejestruj ustalenie w raporcie z audytu, w tym wielkość próbki, nazwę dostawcy, odniesienie do umowy i brakujące dowody.
2. Dodaj wpis CAPA z przyczyną źródłową, na przykład: „lista kontrolna onboardingu dostawcy nie obejmowała klasyfikacji krytyczności ani wyzwalacza planu wyjścia”.
3. Przypisz właściciela dostawcy i właściciela ryzyka.
4. Zaktualizuj rejestr dostawców, oznaczając usługę jako wspierającą funkcję krytyczną lub ważną.
5. Przeprowadź ocenę ryzyka obejmującą przerwę w świadczeniu usługi, dostęp do danych, ryzyko koncentracji, zależność w zakresie zgłaszania incydentów i luki umowne.
6. Zaktualizuj plan postępowania z ryzykiem oraz Deklarację stosowania tam, gdzie ma to znaczenie.
7. Uzyskaj zaktualizowany aneks do umowy albo udokumentowaną akceptację ryzyka.
8. Utwórz lub przetestuj plan wyjścia.
9. Ponownie zaudytuj dowody dostawcy po remediacji.
10. Zaraportuj ustalenie, ryzyko i potrzeby zasobowe w przeglądzie zarządzania.

Ten pojedynczy łańcuch wspiera wiele obowiązków. NIS2 oczekuje bezpieczeństwa łańcucha dostaw oraz uwzględniania podatności dostawców, praktyk cyberbezpieczeństwa i procedur bezpiecznego rozwoju oprogramowania. DORA wymaga od podmiotów finansowych zarządzania ryzykiem ICT stron trzecich, prowadzenia rejestrów uzgodnień umownych, oceny dostawców przed zawarciem umowy, uwzględniania praw do audytu i inspekcji tam, gdzie to właściwe, utrzymywania praw do rozwiązania umowy oraz dokumentowania strategii wyjścia dla usług ICT wspierających funkcje krytyczne lub ważne. GDPR może również mieć znaczenie, jeżeli dostawca przetwarza dane osobowe.

Zapis audytowy nie jest już tylko dowodem zgodności. Jest dowodem odporności.

Przegląd zarządzania: gdzie dowody stają się rozliczalnością

Audyt wewnętrzny ustala stan faktyczny. Przegląd zarządzania decyduje, co z nim zrobić.

Krok 28 Zenith Blueprint opisuje pakiet danych wejściowych do przeglądu zarządzania:

„ISO 27001 określa kilka wymaganych danych wejściowych do przeglądu zarządzania. Przygotuj krótki raport lub prezentację obejmującą te punkty”.

Blueprint wymienia status wcześniejszych działań, zmiany kwestii zewnętrznych i wewnętrznych, wyniki i skuteczność SZBI, incydenty lub niezgodności, możliwości doskonalenia oraz potrzeby zasobowe.

Z Zenith Blueprint, faza audytu, przeglądu i doskonalenia, krok 28: Przegląd zarządzania Zenith Blueprint

W przypadku NIS2 i DORA przegląd zarządzania jest miejscem, w którym widoczna staje się odpowiedzialność rozliczeniowa na poziomie zarządu. Przegląd nie powinien ograniczać się do stwierdzenia „omówiono bezpieczeństwo”. Powinien wykazywać, że kierownictwo przeanalizowało:

• Zmiany wymagań NIS2, DORA, GDPR, klientów i umów.
• Zmiany zakresu, w tym nowe kraje, produkty, klientów regulowanych lub zależności ICT.
• Wyniki audytu wewnętrznego, w tym większe i mniejsze niezgodności.
• Status CAPA i działań przeterminowanych.
• Cele i metryki bezpieczeństwa.
• Trendy incydentów, sytuacje bliskie incydentowi i wnioski z doświadczeń.
• Ryzyka koncentracji dostawców i chmury.
• Wyniki testów ciągłości działania i kopii zapasowych.
• Wyniki w zakresie podatności i wdrażania poprawek.
• Potrzeby zasobowe, w tym ludzi, narzędzia, szkolenia i budżet.
• Ryzyka szczątkowe wymagające formalnej akceptacji.
• Decyzje doskonalące i odpowiedzialnych właścicieli.

To tutaj Maria może przekształcić raport techniczny w strategiczne zapewnienie. Zamiast powiedzieć „znaleźliśmy jedną lukę w procesie incydentowym”, może powiedzieć: „Audyt zidentyfikował jedną mniejszą niezgodność w kryteriach decyzyjnych dotyczących zgłaszania incydentów w NIS2. CAPA aktualizuje procedurę, dodaje macierz decyzyjną i wymaga ćwiczenia typu tabletop w ciągu 30 dni. Potrzebujemy zatwierdzenia kierownictwa na przegląd prawny i czas szkoleniowy”.

Taki zapis wspiera ład zarządczy, nadzór i możliwe do obrony podejmowanie decyzji.

Działanie korygujące: różnica między ustaleniem a dojrzałością

Audyt wewnętrzny bez działania korygującego jest tylko diagnozą.

Krok 29 Zenith Blueprint zaleca organizacjom korzystanie z rejestru CAPA:

„Uzupełnij go dla każdego problemu: opis problemu, przyczyna źródłowa, działanie korygujące, odpowiedzialny właściciel, docelowa data zakończenia, status”.

Z Zenith Blueprint, faza audytu, przeglądu i doskonalenia, krok 29: Ciągłe doskonalenie Zenith Blueprint

Wskazuje też istotne rozróżnienie:

„W terminologii audytowej: korekta usuwa objaw, działanie korygujące usuwa przyczynę. Oba są ważne”.

Z Zenith Blueprint, faza audytu, przeglądu i doskonalenia, krok 29: Ciągłe doskonalenie

Jeżeli brakuje dowodu odtworzenia kopii zapasowej, korektą może być wykonanie i udokumentowanie testu odtworzenia w tym tygodniu. Działaniem korygującym jest zmiana procedury kopii zapasowych tak, aby testy odtworzenia były planowane kwartalnie, automatycznie obsługiwane zgłoszeniem, przeglądane przez właściciela usługi i uwzględniane w metrykach przeglądu zarządzania.

Audytorzy szukają właśnie tej dojrzałości. Audytor ISO 27001 testuje zgodność z SZBI i wybranymi środkami kontrolnymi. Recenzent NIS2 pyta, czy środki zarządzania ryzykiem są skuteczne i nadzorowane. Recenzent DORA szuka integracji ram ryzyka ICT, testowania odporności, zarządzania zależnościami od stron trzecich i remediacji. Asesor NIST Cybersecurity Framework 2.0 może pytać, czy funkcjonują wyniki w obszarach ładu, identyfikacji, ochrony, wykrywania, reagowania i odzyskiwania. Audytor COBIT 2019 może koncentrować się na celach ładu zarządczego, własności, wskaźnikach skuteczności działania i zapewnieniu.

Ten sam zapis CAPA może spełnić oczekiwania tych perspektyw, jeśli obejmuje przyczynę źródłową, właściciela, wpływ na ryzyko, działanie korygujące, termin realizacji, dowód wdrożenia, przegląd skuteczności i widoczność dla kierownictwa.

Wiele perspektyw audytora

Różni audytorzy inaczej odczytują te same dowody. Zenith Controls pomaga przewidzieć te pytania, działając jako przewodnik zgodności przekrojowej dla środków kontrolnych ISO/IEC 27002:2022 i powiązanych ram.

Środek kontrolny 5.36 jest dobrym przykładem. Audytor ISO 27001 może skupić się na tym, czy przeglądy zgodności są prowadzone i zasilają działania korygujące. Recenzent NIS2 może zapytać, czy te przeglądy testują prawne środki cyberbezpieczeństwa, a nie tylko zasady wewnętrzne. Recenzent DORA może skoncentrować się na tym, czy przeglądy zgodności obejmują krytycznych dostawców ICT i egzekwowanie postanowień umownych.

Dlatego dowody muszą być od początku projektowane z myślą o wielu odbiorcach.

Praktyczny 30-dniowy sprint gotowości do audytu

Jeżeli CEO pyta, czy organizacja może być gotowa do audytu w 30 dni, uczciwa odpowiedź brzmi: można zbudować wiarygodną bazę dowodową, jeżeli kierownictwo wesprze sprint, a zakres będzie realistyczny.

Ten sprint nie zastępuje długoterminowej dojrzałości. Tworzy możliwą do obrony bazę operacyjną. Rzeczywista wartość pojawia się wtedy, gdy organizacja powtarza cykl kwartalnie lub półrocznie, a nie tylko raz w roku.

Typowe braki dowodowe identyfikowane przez Clarysec

Te same słabości pojawiają się w audytach SaaS, chmury i fintech:

• Plan audytów istnieje, ale nie jest oparty na ryzyku.
• Lista kontrolna audytu testuje klauzule ISO, ale pomija NIS2, DORA, GDPR i obowiązki wobec klientów.
• Protokoły z przeglądów zarządzania istnieją, ale nie pokazują decyzji, alokacji zasobów ani akceptacji ryzyka.
• Zapisy CAPA wymieniają działania, ale nie zawierają przyczyny źródłowej.
• Ustalenia są zamykane bez weryfikacji skuteczności.
• Przeglądy dostawców są wykonywane, ale dostawcy krytyczni nie są odróżniani od dostawców niskiego ryzyka.
• Podręczniki postępowania dotyczące incydentów istnieją, ale nikt nie potrafi wykazać, że 24- lub 72-godzinny przepływ raportowania zadziała.
• Zadania kopii zapasowych są zielone, ale testy odtworzenia nie są udokumentowane dowodowo.
• Przeglądy dostępu są eksportowane, ale wyjątki nie są śledzone do zamknięcia.
• Logi są zbierane, ale nikt nie potrafi pokazać monitorowania, eskalacji ani reakcji.
• Dowody są przechowywane w folderach osobistych zamiast w kontrolowanym repozytorium.
• Wymagania dotyczące okresu przechowywania są niejasne lub niespójne z umowami z klientami.

Te braki można naprawić. Wymagają ustrukturyzowanej architektury dowodowej SZBI, a nie gorączkowego zbierania dokumentów w ostatniej chwili.

Jak wygląda dobry stan z perspektywy zarządu

Gdy CISO wraca do CEO i CFO, najsilniejsza odpowiedź nie brzmi: „przeszliśmy listę kontrolną audytu”. Brzmi ona:

„Mamy zatwierdzony plan audytów. Przeprowadziliśmy audyt wewnętrzny oparty na ryzyku. Zidentyfikowaliśmy ustalenia na podstawie obiektywnych dowodów. Zatwierdziliśmy CAPA z właścicielami i terminami. Istotne ryzyka, incydenty, zależności od dostawców i potrzeby zasobowe eskalowaliśmy do przeglądu zarządzania. Zmapowaliśmy dowody do ISO/IEC 27001:2022, NIS2, DORA i GDPR. Możemy pokazać ścieżkę audytową”.

Taka odpowiedź zmienia rozmowę. Daje CEO pewność w kontaktach z klientami. Daje CFO jasność co do ekspozycji regulacyjnej. Daje zarządowi możliwy do obrony zapis nadzoru. Daje CISO priorytetyzowaną mapę drogową zamiast stosu niepowiązanych żądań.

Co najważniejsze, przenosi organizację z teatru zgodności do odporności operacyjnej.

Kolejne kroki z Clarysec

Twój kolejny audyt nie powinien być chaotycznym zrywem. Powinien być widocznym dowodem, że SZBI działa, kierownictwo jest zaangażowane, a organizacja jest gotowa na ISO 27001, NIS2, DORA, GDPR i zapewnienie dla klientów.

Clarysec może pomóc Ci:

• Zbudować plan audytu wewnętrznego oparty na ryzyku z wykorzystaniem Zenith Blueprint: 30-etapowa mapa drogowa audytora Zenith Blueprint.
• Mapować dowody z audytu przy użyciu Zenith Controls: przewodnik zgodności przekrojowej Zenith Controls.
• Wdrożyć ład audytowy dla MŚP lub przedsiębiorstw, korzystając z Polityka audytu i monitorowania zgodności dla MŚP Polityka audytu i monitorowania zgodności dla MŚP lub Polityka audytu i monitorowania zgodności Polityka audytu i monitorowania zgodności.
• Przygotować pakiety przeglądu zarządzania zgodne z Polityka bezpieczeństwa informacji Polityka bezpieczeństwa informacji oraz oczekiwaniami ISO/IEC 27001:2022 Clause 9.3.
• Przekształcić ustalenia w zapisy CAPA, decyzje kierownictwa i mierzalne doskonalenie.

Pobierz zestawy narzędzi Clarysec, zarezerwuj ocenę gotowości lub poproś o demo, aby przekształcić kolejny audyt wewnętrzny w dowody dla ISO 27001, NIS2, DORA i kolejnych wymagań, gotowe do przedstawienia zarządowi.