Analiza wpływu na biznes dla ISO 27001, NIS2 i DORA

Pytanie audytowe, które ujawnia rzeczywistą lukę w ciągłości działania

Jest poniedziałkowy poranek, a Maria, CISO szybko rozwijającej się firmy fintech, przygotowuje się do posiedzenia komitetu ds. ryzyka rady dyrektorów. Temat wiadomości jest krótki: „Gotowość na DORA i NIS2: przegląd BIA”.

Jej zespół przygotował to, czego oczekuje większość członków kierownictwa. Istnieje certyfikowany SZBI zgodny z ISO/IEC 27001:2022, procedury reagowania na incydenty, zrzuty ekranu z kopii zapasowych, raporty z podatności, kwestionariusze dostawców, diagramy architektury chmurowej oraz odświeżony rejestr ryzyka. Klienci korporacyjni przesyłają kwestionariusze NIS2. Klienci z sektora finansowego wprowadzają klauzule DORA do umów. Audyt nadzoru ISO/IEC 27001:2022 odbędzie się za miesiąc.

Następnie audytor zewnętrzny zadaje pytanie, które zmienia atmosferę w sali:

„Jeżeli platforma onboardingu klientów będzie niedostępna przez 18 godzin, których usług regulowanych to dotyczy, którzy dostawcy są zaangażowani, jaki jest zatwierdzony priorytet odtwarzania i gdzie znajduje się dowód, że biznes zaakceptował RTO oraz RPO?”

W sali zapada cisza.

Harmonogram kopii zapasowych mówi jedno. Plan odtwarzania po awarii mówi co innego. Umowa z dostawcą zawiera SLA dostępności, ale nie zawiera dowodów testów odtwarzania. Rejestr ryzyka wspomina o dostępności, ale nie wyjaśnia, dlaczego jedna usługa musi zostać odtworzona szybciej niż inna. Kierownictwo zatwierdziło politykę bezpieczeństwa, ale nie zatwierdziło biznesowego wpływu przestoju.

To jest problem analizy wpływu na biznes w 2026 r.

Analiza wpływu na biznes, czyli BIA, nie jest już arkuszem kalkulacyjnym dołączonym do planu ciągłości działania. Jest pomostem dowodowym między usługami biznesowymi, aktywami ICT, dostawcami, priorytetami odtwarzania, RTO/RPO, progami incydentów, testowaniem odporności oraz rozliczalnością kierownictwa. Dla organizacji dostosowujących ISO/IEC 27001:2022 do ciągłości działania według NIS2 oraz odporności ICT według DORA, BIA jest miejscem, w którym zgodność staje się operacyjna.

Najsilniejsze organizacje mają już wiele właściwych zabezpieczeń. Ich słabością jest identyfikowalność. BIA przekształca rozproszone dowody w historię gotową do audytu: co jest istotne, dlaczego jest istotne, jak szybko musi zostać odtworzone, które zależności to wspierają, co zostało przetestowane, co zawiodło, co poprawiono oraz kto zatwierdził ryzyko szczątkowe.

Dlaczego stare arkusze BIA stały się obciążeniem

NIS2 i DORA zmieniły charakter zgodności w obszarze ciągłości działania. Nie traktują ciągłości działania, odtwarzania po awarii, reagowania na incydenty, odporności dostawców i ładu organizacyjnego jako odrębnych dokumentów. Oczekują, że będą działać jako jeden system.

W przypadku podmiotów objętych NIS2 Article 21 wymaga technicznych, operacyjnych i organizacyjnych środków zarządzania ryzykiem dla sieci i systemów informatycznych oraz zapobiegania wpływowi incydentów na odbiorców usług i inne usługi albo minimalizowania tego wpływu. Minimalne środki obejmują analizę ryzyka, obsługę incydentów, ciągłość działania, w tym zarządzanie kopiami zapasowymi, odtwarzanie po awarii i zarządzanie kryzysowe, bezpieczeństwo łańcucha dostaw, obsługę podatności, ocenę skuteczności zabezpieczeń, szkolenia, kryptografię, bezpieczeństwo HR, kontrolę dostępu, zarządzanie aktywami, MFA oraz bezpieczną komunikację.

NIS2 Article 20 przenosi ten temat do sali zarządu. Organy zarządzające muszą zatwierdzać środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorować ich wdrożenie i mogą ponosić odpowiedzialność za naruszenia. Oznacza to, że niepoparty dowodami czterogodzinny RTO nie jest wyłącznie niespójnością techniczną. Jest słabością ładu organizacyjnego.

DORA obowiązuje od 17 stycznia 2025 r. i tworzy jednolite ramy UE dla zarządzania ryzykiem ICT, zgłaszania incydentów, testowania cyfrowej odporności operacyjnej, zarządzania ryzykiem ICT stron trzecich, wymogów umownych oraz nadzoru nad krytycznymi zewnętrznymi dostawcami usług ICT. Dla podmiotów finansowych oraz dostawców technologii wspierających je umownie DORA przekształca odporność operacyjną w ustrukturyzowany wymóg dowodowy.

DORA Articles 5 i 6 wymagają ładu organizacyjnego oraz udokumentowanych ram zarządzania ryzykiem ICT. Articles 7 do 14 obejmują niezawodne i odporne systemy ICT, identyfikację aktywów i zależności, ochronę, wykrywanie, ciągłość działania ICT, kopie zapasowe, odtwarzanie, odzyskiwanie, uczenie się po incydentach, świadomość, szkolenia oraz komunikację kryzysową. Articles 24 do 26 wymagają testowania cyfrowej odporności operacyjnej dla podmiotów finansowych niebędących mikroprzedsiębiorstwami. Articles 28 do 30 formalizują ryzyko ICT stron trzecich, rejestry umów dotyczących usług ICT, strategie wyjścia, poziomy usług, prawa do audytu oraz wymagania awaryjne.

ISO/IEC 27001:2022 zapewnia fundament systemu zarządzania. Jego klauzule wymagają, aby organizacja określiła kontekst, strony zainteresowane, obowiązki prawne i umowne, zakres, przywództwo, politykę, role, ocenę ryzyka, postępowanie z ryzykiem, Deklarację stosowania, planowanie operacyjne, ocenę wyników oraz ciągłe doskonalenie.

Brakującym ogniwem jest często BIA. Bez niej plany ciągłości działania nie są jednoznacznie oparte na ryzyku, cele kopii zapasowych nie są zatwierdzone biznesowo, dostawcy nie są mapowani do usług krytycznych, a kierownictwo nie może wiarygodnie wykazać, że decyzje dotyczące odporności były podejmowane na podstawie wpływu biznesowego.

BIA jako warstwa sterowania dowodami odporności

Możliwa do obrony BIA odpowiada na siedem pytań, które audytorzy, regulatorzy, klienci i rady nadzorcze zadają coraz częściej:

1. Które usługi biznesowe są krytyczne?
2. Które aktywa ICT, repozytoria danych, osoby, dostawcy oraz zasoby techniczne wspierają każdą usługę?
3. Jaki jest operacyjny, finansowy, prawny, umowny, kliencki, reputacyjny oraz związany z bezpieczeństwem fizycznym wpływ zakłócenia w czasie?
4. Jaki jest maksymalny tolerowany czas niedostępności, czyli MTD?
5. Jakie są zatwierdzone: docelowy czas odtworzenia, czyli RTO, oraz docelowy punkt odtworzenia, czyli RPO?
6. Czy ustalenia dotyczące kopii zapasowych, redundancji, chmury, dostawców, obsady oraz komunikacji pozwalają osiągnąć te cele?
7. Czy organizacja przetestowała ścieżkę odtwarzania i dokonała przeglądu wyników?

Korporacyjna Polityka ciągłości działania i odtwarzania po awarii Clarysec P32 Polityka ciągłości działania i odtwarzania po awarii formułuje wymaganie wprost:

Analiza wpływu na biznes (BIA) musi być przeprowadzana co najmniej raz w roku dla wszystkich krytycznych jednostek biznesowych oraz poddawana przeglądowi po istotnych zmianach w systemach, procesach lub zależnościach. Wyniki BIA muszą określać: 5.2.1. Maksymalny tolerowany czas niedostępności (MTD) 5.2.2. Docelowe czasy odtworzenia (RTO) 5.2.3. Docelowe punkty odtworzenia (RPO) 5.2.4. Krytyczne zależności (systemy, dostawcy, personel)

Ta klauzula daje audytorom praktyczny punkt wyjścia. Zapobiega również częstej sytuacji, w której plan ciągłości działania, plan odtwarzania po awarii, harmonogram kopii zapasowych, rejestr dostawców i proces reagowania na incydenty posługują się różnymi definicjami „krytyczności”.

Ta sama polityka wymaga zintegrowanego podejścia zarządczego:

Organizacja musi utrzymywać zintegrowany system zarządzania ciągłością działania (BCMS) zgodny z ISO 22301 i ISO/IEC 27001, zapewniający integrację następujących elementów: 5.1.1. Analiza wpływu na biznes (BIA) 5.1.2. Ocena ryzyka bezpieczeństwa dla zagrożeń ciągłości działania 5.1.3. Plany ciągłości działania (BCP) 5.1.4. Plany odtwarzania po awarii ICT (DRP) 5.1.5. Programy testów i ćwiczeń 5.1.6. Dokumentacja i ciągłe doskonalenie

Na tym polega różnica między zgodnością opartą na liście kontrolnej a odpornością gotową do audytu. BIA nie jest jednorazowym dokumentem. Staje się częścią łańcucha dowodowego SZBI i BCMS.

Jak ISO/IEC 27001:2022 przekształca BIA w dowody podlegające audytowi

ISO/IEC 27001:2022 nie wymaga od każdej organizacji używania terminu „analiza wpływu na biznes” w każdej klauzuli, ale jego wymagania sprawiają, że dowody BIA są wyjątkowo wartościowe.

Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała kwestie wewnętrzne i zewnętrzne, strony zainteresowane, obowiązki prawne i regulacyjne, wymogi umowne, interfejsy, zależności oraz zakres SZBI. BIA jest często najbardziej praktycznym dowodem dla tych interfejsów i zależności. Pokazuje, która usługa chmurowa, operator płatności, dostawca tożsamości, operator telekomunikacyjny, zarządzana usługa bezpieczeństwa, centrum danych lub zewnętrzny zespół wsparcia umożliwia świadczenie usługi krytycznej.

Klauzule 5.1 do 5.3 wymagają przywództwa najwyższego kierownictwa, zapewnienia zasobów, komunikacji, przypisania ról oraz raportowania. BIA daje kierownictwu biznesowe uzasadnienie dla inwestycji w ciągłość działania. Bez niej cele RTO i RPO są technicznymi życzeniami, a nie zatwierdzonymi wymaganiami biznesowymi.

Klauzule 6.1.1 do 6.1.3 wymagają powtarzalnej oceny ryzyka bezpieczeństwa informacji i postępowania z ryzykiem. Organizacja musi identyfikować ryzyka dla poufności, integralności i dostępności, analizować konsekwencje i prawdopodobieństwo, określać poziomy ryzyka, priorytetyzować postępowanie z ryzykiem, dobierać zabezpieczenia, porównywać wybrane zabezpieczenia z Załącznikiem A, przygotować Deklarację stosowania, utworzyć plan postępowania z ryzykiem oraz uzyskać zatwierdzenie właściciela ryzyka. BIA wzmacnia stronę „konsekwencji” w ocenie ryzyka. Wyjaśnia, dlaczego dwugodzinna niedostępność jednego systemu jest tolerowana, podczas gdy dwugodzinna niedostępność innego powoduje szkodę dla klientów, ekspozycję regulacyjną, naruszenie umowy lub istotny wpływ na przychody.

Załącznik A zawiera katalog zabezpieczeń. Dla BIA i ciągłości działania najbardziej istotne zabezpieczenia Załącznika A ISO/IEC 27001:2022 obejmują:

W Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec opisuje zabezpieczenie ISO/IEC 27002:2022 5.30, gotowość ICT do zapewnienia ciągłości działania, jako zabezpieczenie korygujące ukierunkowane na dostępność, zmapowane do koncepcji cyberbezpieczeństwa Respond, operacyjnej zdolności ciągłości działania oraz domeny bezpieczeństwa odporności. Zabezpieczenie 5.29, bezpieczeństwo informacji podczas zakłócenia, jest opisane jako zapobiegawcze i korygujące, chroniące poufność, integralność i dostępność. Zabezpieczenie 8.13, kopie zapasowe informacji, jest opisane jako korygujące, wspierające integralność i dostępność przez odtwarzanie.

To rozróżnienie ma znaczenie. BIA nie może pytać wyłącznie: „Czy możemy odtworzyć?”. Musi również pytać: „Czy możemy zachować bezpieczeństwo podczas zakłócenia?”. Podczas zdarzenia ransomware, awarii chmury, awarii dostawcy lub incydentu w centrum danych organizacja nadal potrzebuje kontroli dostępu, rejestrowania, monitorowania, zabezpieczenia dowodów, bezpiecznej komunikacji oraz środków ochrony prywatności.

Praktyczny model dowodowy BIA

Silna BIA łączy język biznesowy z dowodami technicznymi. Clarysec zwykle strukturyzuje model dowodowy w pięciu warstwach.

Ten model dowodowy działa, ponieważ odzwierciedla sposób myślenia audytorów. Najpierw pytają, co jest krytyczne. Następnie pytają, co to wspiera. Potem pytają, kto zatwierdził cel odtwarzania. Następnie sprawdzają, czy rozwiązania techniczne i dostawcy mogą spełnić cel. Na końcu pytają, czy organizacja przetestowała i poprawiła tę zdolność.

NIST CSF 2.0 jest przydatny jako warstwa komunikacyjna. Jego metoda CSF Profiles zachęca organizacje do definiowania zakresu, gromadzenia danych wejściowych, takich jak polityki, priorytety ryzyka przedsiębiorstwa, rejestry BIA, wymagania cyberbezpieczeństwa, normy, procedury, środki ochrony i role stanowiskowe, tworzenia profili bieżących i docelowych, analizy luk, przygotowania priorytetowego planu działań, wdrożenia tego planu oraz aktualizacji profilu. To niemal dokładnie sposób, w jaki BIA powinna zasilać mapę drogową zgodności przekrojowej.

Tygodniowe ćwiczenie BIA, które tworzy rzeczywiste dowody

Załóżmy, że dostawca SaaS wspiera klientów z sektora usług finansowych. Jego platforma obsługuje onboarding klientów, weryfikację dokumentów i powiadomienia klientów. Sam nie jest bankiem, ale jego klienci przekazują wymogi umowne wynikające z DORA oraz kwestionariusze dostawców NIS2.

Skoncentrowane tygodniowe ćwiczenie może szybko wytworzyć użyteczne dowody.

Dzień 1: Identyfikacja usług krytycznych i okien wpływu

Zacznij od usług, nie od serwerów. Zaangażuj właścicieli biznesowych, IT, bezpieczeństwo, dział prawny, wsparcie, ochronę prywatności i zarządzanie dostawcami.

Takie ujęcie jest istotne. Regulatorzy i klienci rozpoznają usługi oraz funkcje. Aplikacje mają znaczenie, ponieważ wspierają te usługi.

Dzień 2: Mapowanie zależności

Dla każdej usługi zmapuj aplikacje, bazy danych, infrastrukturę, usługi chmurowe, dostawców tożsamości, monitorowanie, narzędzia kopii zapasowych, ludzi, dostawców oraz wspierające zasoby techniczne.

W tym miejscu BIA zaczyna tworzyć wartość. Ujawnia niewidoczną ścieżkę odtwarzania, w tym zależności często pomijane w technicznym planie DR.

Dzień 3: Zatwierdzenie MTD, RTO i RPO

Właściciel biznesowy proponuje MTD. IT i bezpieczeństwo weryfikują, czy proponowane RTO i RPO są technicznie osiągalne. Kierownictwo zatwierdza cele końcowe.

Dla mniejszych organizacji Polityka ciągłości działania i odtwarzania po awarii — MŚP Clarysec P32S Polityka ciągłości działania i odtwarzania po awarii - MŚP wprowadza tę samą dyscyplinę prostszym językiem. Wymaga planów BCP/DR określających podejście do odtwarzania funkcji kluczowych:

Dyrektor Generalny (GM) musi zatwierdzać i utrzymywać plany ciągłości działania i odtwarzania po awarii (BCP/DRP), które jasno określają podejście organizacji do odtwarzania funkcji kluczowych.

Wymaga również, aby plan obejmował:

priorytetowe usługi i systemy (krytyczne funkcje biznesowe)

Oraz:

Docelowe czasy odtworzenia (RTO) i docelowe punkty odtworzenia (RPO) dla każdego systemu

Kluczem nie jest nadmierna dokumentacja. Kluczem są identyfikowalność, zatwierdzenie oraz dowód, że cele odtwarzania wynikają z rzeczywistego wpływu biznesowego.

Dzień 4: Uzgodnienie kopii zapasowych z wpływem biznesowym

Wiele organizacji ponosi porażkę właśnie tutaj. BIA może określać czterogodzinny RPO, podczas gdy kopie zapasowe są wykonywane co 24 godziny. Albo narzędzie kopii zapasowych chroni produkcyjne bazy danych, ale nie konfigurację, sekrety, repozytoria infrastruktury jako kodu, obiektową pamięć masową, rekordy DNS, ustawienia tożsamości ani konfigurację bramy API.

Polityka tworzenia kopii zapasowych i odtwarzania Clarysec P15 Polityka tworzenia kopii zapasowych i odtwarzania wymaga głównego harmonogramu kopii zapasowych powiązanego z wynikami BIA:

Główny harmonogram kopii zapasowych musi być utrzymywany i poddawany przeglądowi raz w roku. Musi określać: 5.1.1 Częstotliwość kopii zapasowych (na przykład codzienne kopie przyrostowe i cotygodniowe pełne kopie zapasowe) 5.1.2 Okresy przechowywania według systemu lub typu danych 5.1.3 Wymagania dotyczące szyfrowania i szczegóły lokalizacji przechowywania 5.1.4 Cele RTO/RPO powiązane z wynikami oceny wpływu na biznes

Ta klauzula jest bardzo wartościowa audytowo. Wymusza, aby projekt kopii zapasowych odzwierciedlał wpływ biznesowy, a nie wygodę przechowywania.

Dzień 5: Przetestowanie jednej ścieżki odtwarzania i otwarcie działań korygujących

Nie testuj wszystkiego naraz. Wybierz jedną usługę krytyczną i przeprowadź ukierunkowany test odtwarzania. Odtwórz bazę danych. Odbuduj konfigurację aplikacji. Zweryfikuj uwierzytelnianie. Potwierdź dostępność logów. Sprawdź zdolność powiadamiania klientów. Zapisz czas wykonania, utratę danych, defekty, decyzje i działania korygujące.

W Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, w fazie Controls in Action, krok 23, dotyczy zabezpieczeń organizacyjnych, w tym gotowości ICT do zapewnienia ciągłości działania. Zadaje pytanie, które powinien zadać każdy zespół audytowy:

Czy Twoje systemy mogą wspierać cele ciągłości działania, gdy światło miga, sieci przestają działać, a dochodzi do awarii?

Ten sam krok daje praktyczną instrukcję:

Zweryfikuj, czy docelowe czasy odtworzenia (RTO) i docelowe punkty odtworzenia (RPO) dla systemów krytycznych są zgodne z oczekiwaniami dotyczącymi ciągłości działania (5.30). Przeprowadź co najmniej jeden techniczny test odtwarzania albo symulację przełączenia awaryjnego i udokumentuj wyniki.

Na tym polega różnica między posiadaniem BIA a posiadaniem możliwych do obrony dowodów BIA. Cel nie jest tylko udokumentowany. Jest przetestowany.

Mapowanie dowodów BIA na NIS2, DORA, GDPR, NIST i COBIT 2019

Dobrze zbudowana BIA staje się aktywem zgodności przekrojowej. Jeden zestaw dowodów może odpowiedzieć na wiele pytań.

GDPR jest często pomijany w dyskusjach o BIA. Jednak GDPR Article 5 wymaga, aby dane osobowe były przetwarzane z zachowaniem integralności i poufności, w tym ochrony przed przypadkową utratą, zniszczeniem lub uszkodzeniem przy użyciu odpowiednich środków technicznych lub organizacyjnych. Rozliczalność wymaga, aby administrator mógł wykazać zgodność. Jeżeli platforma danych osobowych nie może zostać odtworzona w zatwierdzonym i przetestowanym czasie, ryzyko prywatności wpływa na dostępność, integralność, ocenę naruszenia oraz zaufanie klientów.

Raportowanie incydentów według NIS2 dodaje kolejny wymiar. Article 23 wymaga, aby istotne incydenty były zgłaszane bez zbędnej zwłoki, w tym wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie incydentu w ciągu 72 godzin oraz raport końcowy w ciągu jednego miesiąca. BIA pomaga klasyfikować wagę, ponieważ definiuje usługi dotknięte zdarzeniem, odbiorców usług, zakłócenie operacyjne oraz potencjalny wpływ transgraniczny.

Klasyfikacja incydentów DORA również uwzględnia dotkniętych klientów lub transakcje, czas trwania, zasięg geograficzny, utraty danych, krytyczność dotkniętych usług oraz wpływ ekonomiczny. Są to pola BIA. Jeżeli BIA jest słaba, klasyfikacja incydentu staje się subiektywna w najgorszym możliwym momencie.

Ciągłość działania dostawców: miejsce, w którym BIA spotyka rzeczywistość umowną

Dla NIS2 i DORA ciągłość działania dostawców nie jest już opcjonalna. NIS2 Article 21 obejmuje bezpieczeństwo łańcucha dostaw i wymaga zwrócenia uwagi na podatności dostawców, jakość i odporność produktów, praktyki cyberbezpieczeństwa dostawców oraz procedury bezpiecznego rozwoju oprogramowania. DORA wymaga zarządzania ryzykiem ICT stron trzecich w ramach ryzyka ICT, w tym rejestrów umów dotyczących usług ICT, due diligence, ryzyka koncentracji, strategii wyjścia, praw do audytu i dostępu, wsparcia w przypadku incydentu, poziomów usług oraz wymagań awaryjnych.

Korporacyjna Polityka ciągłości działania i odtwarzania po awarii wymaga:

Zależności od stron trzecich i łańcucha dostaw 6.5.1. Umowy z dostawcami krytycznymi muszą zawierać obowiązki w zakresie ciągłości działania oraz zobowiązania dotyczące czasu odtwarzania. 6.5.2. Kluczowi dostawcy usług muszą, na żądanie, wykazać okresowe testowanie ciągłości działania oraz udział w ćwiczeniach incydentowych.

Wersja dla MŚP wymaga również:

punkty kontaktowe ds. ciągłości działania po stronie dostawcy

To niewielkie pole może mieć decydujące znaczenie w rzeczywistym incydencie. Jeżeli plan odtwarzania mówi „skontaktuj się ze wsparciem dostawcy usług chmurowych”, ale nikt nie zna ścieżki eskalacji, numeru umowy, procesu obsługi według wagi ani kontaktu poza godzinami pracy, RTO jest fikcją.

Ta tabela nie zastępuje zarządzania ryzykiem dostawców. Sprawia, że ryzyko dostawcy staje się operacyjne.

Jak audytorzy będą testować Twoją BIA

Audytor ISO/IEC 27001:2022 zwykle zacznie od zakresu, kontekstu, oceny ryzyka, postępowania z ryzykiem, Deklaracji stosowania, zabezpieczeń Załącznika A, udokumentowanych informacji, planowania operacyjnego, oceny wyników i doskonalenia. Porówna BIA z oceną ryzyka i SoA. Jeżeli A.5.30, A.5.29 lub A.8.13 są uwzględnione, poprosi o dowody wdrożenia i testowania.

Recenzent DORA skoncentruje się na funkcjach krytycznych lub ważnych, aktywach ICT, zależnościach ICT od stron trzecich, testowaniu odporności, klasyfikacji incydentów, wymaganiach umownych, strategiach wyjścia oraz nadzorze organu zarządzającego. Będzie oczekiwał, że BIA jest zgodna z ramami zarządzania ryzykiem ICT, strategią cyfrowej odporności operacyjnej, planami ciągłości działania ICT, planami reagowania i odtwarzania oraz programem testów.

Organ nadzorczy NIS2 zapyta o środki ciągłości działania, zarządzanie kopiami zapasowymi, odtwarzanie po awarii, zarządzanie kryzysowe, bezpieczeństwo łańcucha dostaw, zatwierdzenie w ramach ładu organizacyjnego oraz zdolność zgłaszania istotnych incydentów. BIA powinna wykazać, że te środki są oparte na wpływie na usługę i zatwierdzonych priorytetach.

Asesor NIST CSF 2.0 zapyta, w jaki sposób BIA zasila Current Profile, Target Profile, analizę luk i plan działań. Przyjrzy się wynikom Govern dotyczącym decyzji prawnych, regulacyjnych, umownych, ryzyka, ról, polityk, nadzoru oraz ryzyka dostawców. Zbada również wyniki Identify, Protect, Detect, Respond i Recover.

Audytor COBIT 2019 lub audytor stosujący podejście ISACA zwykle skupi się na ładzie organizacyjnym. Kto jest właścicielem usługi? Kto zaakceptował ryzyko? Czy cele są zgodne z celami przedsiębiorstwa? Czy dostawcy są monitorowani? Czy korzyści, ryzyko i zasoby są równoważone? Czy działania korygujące są śledzone do zamknięcia?

Polityka audytu i monitorowania zgodności Clarysec Polityka audytu i monitorowania zgodności włącza BIA do cyklu planowania audytu:

Plan audytów oparty na ryzyku musi być opracowywany i zatwierdzany raz w roku, z uwzględnieniem: 5.2.1 Wyników najnowszych ocen ryzyka i analizy wpływu na biznes (BIA) 5.2.2 Poprzednich ustaleń z audytu i statusu działań korygujących 5.2.3 Zmian w procesach, infrastrukturze IT, systemach lub dostawcach 5.2.4 Obowiązków zewnętrznych, takich jak DORA Article 25 lub umowy z klientami

To krok dojrzałości, którego wiele organizacji nie wykonuje. BIA nie powinna pozostawać poza zapewnieniem. Powinna sterować planem audytów.

Typowe niepowodzenia BIA wykrywane w rzeczywistych ocenach

Te same słabości pojawiają się regularnie.

Po pierwsze, BIA wymienia aplikacje, a nie usługi. Klientów i regulatorów interesuje zakłócenie usług. Aplikacje mają znaczenie, ponieważ wspierają te usługi.

Po drugie, cele RTO i RPO są kopiowane z szablonów. Czterogodzinny RTO może brzmieć rozsądnie, dopóki test odtwarzania nie pokaże, że odbudowa integracji tożsamości, odzyskanie konfiguracji, odtworzenie danych, walidacja integralności i ponowne uruchomienie monitorowania zajmują dziewięć godzin.

Po trzecie, kopie zapasowe nie są powiązane z wpływem biznesowym. Częstotliwość, okres przechowywania, szyfrowanie, lokalizacja przechowywania, priorytet odtwarzania i testowanie muszą odzwierciedlać zatwierdzone cele odtwarzania.

Po czwarte, dostawcy są traktowani jako pozycje kwestionariusza, a nie jako zależności odtwarzania. Zobowiązania dostawców dotyczące ciągłości działania, kontakty eskalacyjne, dowody odtwarzania oraz udział w ćwiczeniach incydentowych powinny być powiązane z usługami krytycznymi.

Po piąte, brakuje zatwierdzenia przez kierownictwo. W ramach NIS2 i DORA rozliczalność kierownictwa jest wyraźna. W ISO/IEC 27001:2022 przywództwo, role, zatwierdzenie przez właściciela ryzyka oraz raportowanie wyników są wymaganiami podstawowymi.

Po szóste, testowanie jest zbyt wąskie. Odtworzenie jednego pliku jest użyteczne, ale nie dowodzi odtworzenia usługi. Ścieżka odtwarzania usługi krytycznej może obejmować DNS, tożsamość, sekrety, infrastrukturę jako kod, bramy API, monitorowanie, rejestrowanie, eskalację do dostawcy, komunikację z klientem oraz przegląd prywatności.

Zenith Blueprint, w fazie Controls in Action, krok 19, ujmuje oczekiwanie audytowe wobec kopii zapasowych:

Czy testujesz swoje kopie zapasowe?

Odpowiedź musi brzmieć: „tak, z dowodami”, a dowody muszą łączyć się z BIA.

Pakiet dowodów BIA gotowy do audytu

Praktyczny program BIA powinien tworzyć zwięzły pakiet dowodów, który można wykorzystać podczas audytów, due diligence klientów, raportowania dla zarządu oraz doskonalenia odporności.

Ten pakiet przedstawia spójną historię. Sprawia również, że odporność staje się mierzalna.

Następny krok: przekształć BIA w dowody zgodności

Maria nie potrzebuje większego arkusza kalkulacyjnego. Potrzebuje żywego łańcucha dowodowego.

Zacznij od jednej usługi krytycznej. Zmapuj jej aktywa ICT, dane, ludzi, dostawców i zasoby techniczne. Zatwierdź MTD, RTO i RPO. Uzgodnij harmonogram kopii zapasowych. Sprawdź zobowiązania dostawców dotyczące odtwarzania. Przeprowadź jeden test odtwarzania. Zapisz luki. Zaktualizuj plan postępowania z ryzykiem. Przedstaw wynik kierownictwu.

Następnie powtórz ten proces.

Clarysec może pomóc przyspieszyć ten proces, wykorzystując Politykę ciągłości działania i odtwarzania po awarii, Politykę ciągłości działania i odtwarzania po awarii — MŚP, Politykę tworzenia kopii zapasowych i odtwarzania, Politykę audytu i monitorowania zgodności, Zenith Blueprint oraz Zenith Controls.

Twoja BIA nie powinna być dokumentem półkowym utworzonym na potrzeby audytu. Powinna być operacyjnym dowodem, że najważniejsze usługi mogą przetrwać zakłócenie, spełnić oczekiwania klientów i regulatorów oraz odzyskać sprawność w granicach faktycznie zatwierdzonych przez kierownictwo.

Jeżeli Twoja organizacja przygotowuje się do audytu nadzoru ISO/IEC 27001:2022, zapewnienia dla klientów w zakresie NIS2, przeglądów ICT stron trzecich według DORA lub raportowania odporności na poziomie zarządu, zacznij od uczynienia BIA możliwą do obrony. Pobierz polityki Clarysec dotyczące ciągłości działania i audytu, przejrzyj mapę drogową wdrożenia Zenith albo zamów ocenę dowodów odporności, aby przekształcić rozproszone zabezpieczenia w jedną historię gotową do audytu.