Zakres SZBI ISO 27001 dla NIS2, DORA i GDPR

Maria, dyrektor ds. bezpieczeństwa informacji w szybko rosnącym europejskim fintechu, była przekonana, że audyt nadzoru ISO 27001 jest pod kontrolą.

Certyfikat był świeży. Deklaracja stosowania wyglądała dojrzale. Deklaracja zakresu obejmowała „korporacyjny system zarządzania bezpieczeństwem informacji wspierający operacje platformy SaaS”. Produkcyjne środowisko chmurowe było udokumentowane. Procedura reagowania na incydenty istniała. Rejestr ryzyka zawierał właścicieli, daty i oceny ryzyka szczątkowego.

Następnie audytor zadał jedno proste pytanie:

„Które części tej platformy SaaS są również objęte zakresem rejestracji NIS2, które usługi outsourcingowe wspierają krytyczne lub istotne funkcje DORA dla Państwa klientów finansowych i gdzie dokładnie przetwarzane są dane osobowe objęte GDPR?”

W sali zapadła cisza.

Dział prawny otworzył arkusz kalkulacyjny z obowiązkami regulacyjnymi. Zespół produktu otworzył diagram architektury. Inspektor ochrony danych otworzył rejestr czynności przetwarzania. Dział zakupów otworzył listę dostawców. Zespół operacyjny otworzył plan odtwarzania po awarii. Żaden z tych dokumentów nie był ze sobą spójny.

Zakres SZBI mówił: „platforma SaaS”. Ocena NIS2 wskazywała usługi infrastruktury cyfrowej w kilku państwach członkowskich. Umowy z klientami opisywały platformę jako wspierającą regulowane operacje finansowe. Rejestry GDPR obejmowały dane tożsamości, telemetrię, adresy IP, metadane płatności, zgłoszenia wsparcia i analitykę podzleconą podmiotom trzecim. Plan odtwarzania po awarii obejmował środowisko produkcyjne, ale nie platformę obsługi klienta wykorzystywaną do komunikacji dotyczącej naruszeń. Due diligence dostawców obejmowało dostawcę hostingu, ale nie zarządzaną usługę wykrywania podłączoną do logów produkcyjnych.

Na tym polega problem definiowania zakresu SZBI w 2026 r. Certyfikacja ISO 27001 nadal ma wartość, ale wąski „minimalny wykonalny zakres” może stać się obciążeniem dla organizacji, gdy organy nadzoru, klienci i audytorzy oczekują, że ten sam system zarządzania wyjaśni usługi kluczowe NIS2, krytyczne lub istotne funkcje DORA oraz granice przetwarzania GDPR.

W przypadku ISO/IEC 27001:2022, NIS2, DORA i GDPR słaby zakres nie jest usterką administracyjną. To pierwszy element domina. Jeżeli zakres jest błędny, ocena ryzyka jest niepełna, SoA wprowadza w błąd, zabezpieczenia dotyczące dostawców pomijają krytycznych dostawców, terminy zgłaszania incydentów stają się niepewne, a rozliczalność w obszarze prywatności rozpada się pomiędzy zespołami.

Dlaczego zakres SZBI ISO 27001 jest obecnie granicą regulacyjną

ISO/IEC 27001:2022 klauzula 4.3 wymaga, aby organizacja określiła granice i stosowalność SZBI, uwzględniając czynniki wewnętrzne i zewnętrzne, wymagania zainteresowanych stron oraz interfejsy i zależności z innymi organizacjami ISO/IEC 27001:2022.

To sformułowanie ma w 2026 r. większe znaczenie niż we wcześniejszych cyklach certyfikacyjnych. NIS2, DORA, GDPR, outsourcing usług chmurowych, umowy z klientami, usługi technologiczne grupy kapitałowej i dostawcy usług zarządzanych nie są kwestiami pobocznymi. Są danymi wejściowymi do wyznaczenia granicy SZBI.

NIS2 podnosi wymagania dotyczące ładu zarządczego wobec podmiotów kluczowych i ważnych. Wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie i odbywały szkolenia. NIS2 Article 21 wymaga 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 nabywania i rozwoju, oceny skuteczności, cyberhigieny, kryptografii, bezpieczeństwa HR, kontroli dostępu, zarządzania aktywami oraz uwierzytelniania wieloskładnikowego tam, gdzie jest to właściwe.

DORA zmienia rozmowę o zakresie dla podmiotów finansowych. Ma zastosowanie od 17 stycznia 2025 r. i ustanawia jednolite wymagania dotyczące zarządzania ryzykiem ICT, zgłaszania incydentów związanych z ICT, testowania cyfrowej odporności operacyjnej, wymiany informacji oraz zarządzania ryzykiem ICT stron trzecich. DORA Article 6 wymaga udokumentowanych ram zarządzania ryzykiem ICT. DORA Article 8 wymaga identyfikacji, klasyfikacji i dokumentowania funkcji biznesowych wspieranych przez ICT, aktywów informacyjnych i aktywów ICT, w tym zależności. DORA Article 28 wymaga zarządzania ryzykiem ICT stron trzecich.

GDPR dodaje oś danych osobowych. Ma zastosowanie do zautomatyzowanego lub ustrukturyzowanego przetwarzania danych osobowych, w tym przetwarzania przez jednostki organizacyjne w UE oraz niektórych administratorów lub podmioty przetwarzające spoza UE oferujących towary lub usługi osobom w Unii albo monitorujących ich zachowanie. GDPR Article 30 wymaga rejestru czynności przetwarzania, Article 32 wymaga bezpieczeństwa przetwarzania, a Article 33 określa oczekiwania dotyczące zgłaszania naruszeń.

Możliwy do obrony zakres SZBI nie jest więc pisany wokół działów. Jest definiowany wokół regulowanych usług, krytycznych lub istotnych funkcji, przetwarzania danych osobowych, aktywów wspierających i zależności od stron trzecich.

Błąd: traktowanie ISO 27001, NIS2, DORA i GDPR jako odrębnych programów

W wielu organizacjach występuje typowy schemat:

• Zespół bezpieczeństwa przygotowuje zakres ISO 27001.
• Dział prawny ocenia stosowalność NIS2.
• Ryzyko lub compliance zarządza obowiązkami DORA.
• Zespół prywatności utrzymuje rejestr czynności przetwarzania GDPR.
• Dział zakupów odpowiada za listę dostawców.
• Zespół operacyjny odpowiada za ciągłość działania i odtwarzanie po awarii.

Każdy zespół może wykonywać swoją pracę rzetelnie. Problem polega na tym, że regulowana rzeczywistość przecina wszystkie te obszary.

Hostowana w chmurze usługa tożsamości klientów może jednocześnie wspierać świadczenie usług NIS2, regulowane przez DORA operacje klientów oraz przetwarzanie danych osobowych objęte GDPR. Dostawca zarządzanego wykrywania może być dostawcą bezpieczeństwa, zależnością procesu reagowania na incydenty, podmiotem przetwarzającym lub podwykonawcą przetwarzania danych logowania oraz kluczowym źródłem decyzji o zgłoszeniach regulacyjnych. Platforma wsparcia może być uznawana za „nieprodukcyjną”, a jednocześnie obsługiwać komunikację dotyczącą naruszeń ochrony danych osobowych i wnioski klientów o dowody.

SZBI jest najlepszym miejscem do integracji tych obowiązków, ponieważ ISO 27001 wymusza jedno zdyscyplinowane pytanie: co znajduje się wewnątrz granicy, co jest poza nią i dlaczego?

Zenith Blueprint: 30-krokowa mapa drogowa audytora Clarysec Zenith Blueprint omawia to w fazie fundamentów i przywództwa SZBI, krok 2: potrzeby interesariuszy i zakres SZBI:

„Po zrozumieniu kontekstu i zidentyfikowaniu wymagań interesariuszy klauzula 4.3 wymaga określenia granic i stosowalności SZBI w celu ustanowienia jego zakresu. Zakres SZBI jest kluczową definicją, która określa, co jest objęte programem zarządzania bezpieczeństwem (a co nie jest).”

Zenith Blueprint podkreśla również punkt, którego nadal brakuje w wielu deklaracjach zakresu:

„Jeżeli zlecasz swoją infrastrukturę IT dostawcy chmury obliczeniowej, nie wyłącza jej to z zakresu; przeciwnie, należy objąć zakresem zarządzanie tą relacją oraz aktywami chmurowymi.”

Outsourcing przenosi wykonanie. Nie znosi rozliczalności.

Model czterech granic dla zakresu ISO 27001 w 2026 r.

Dla organizacji objętych NIS2, DORA i GDPR Clarysec zaleca definiowanie zakresu SZBI ISO 27001 poprzez cztery powiązane granice.

Słaba deklaracja zakresu mówi tylko „platforma SaaS”. Silniejsza deklaracja wskazuje, które usługi biznesowe, systemy, środowiska, lokalizacje, czynności przetwarzania danych, grupy personelu, relacje z dostawcami i procesy zarządcze są objęte zakresem.

Bardziej możliwa do obrony wersja może brzmieć następująco:

„SZBI obejmuje ład zarządczy, zarządzanie ryzykiem, operacje i ciągłe doskonalenie bezpieczeństwa informacji dla unijnej platformy SaaS spółki do analityki płatności, w tym produkcyjne i nieprodukcyjne środowiska chmurowe, usługi tożsamości klientów, interfejsy administracyjne, operacje wsparcia, platformy rejestrowania i monitorowania, reagowanie na incydenty, ciągłość działania, zarządzanie dostawcami oraz wszystkie czynności przetwarzania danych osobowych wspierające usługę. SZBI obejmuje zarządzanie outsourcingowym hostingiem w chmurze, zarządzanym wykrywaniem oraz narzędziami obsługi klienta wykorzystywanymi do świadczenia usług, zapewnienia odporności, monitorowania bezpieczeństwa lub komunikacji związanej z GDPR.”

Taki zakres nie jest jedynie dłuższy. Jest bardziej audytowalny, ponieważ łączy usługi, aktywa, przetwarzanie i zależności.

Jak polityki Clarysec przekładają zakres na język ładu zarządczego

Zakres nie powinien istnieć w samodzielnym dokumencie. Musi być spójny z polityką bezpieczeństwa informacji, zgodnością prawną i regulacyjną, zarządzaniem ryzykiem, prywatnością, nadzorem nad dostawcami, kryteriami audytu i planowaniem ciągłości działania.

Korporacyjna Polityka bezpieczeństwa informacji Polityka bezpieczeństwa informacji eliminuje niejednoznaczność dotyczącą wyłączeń:

„Wszelkie wyłączenia lub ograniczenia tego zakresu należy udokumentować w deklaracji zakresu SZBI i uzasadnić formalnym zatwierdzeniem przez najwyższe kierownictwo.”

Ta klauzula ma znaczenie, gdy jednostka biznesowa twierdzi, że obsługa klienta jest poza platformą, mimo że agenci wsparcia mają dostęp do identyfikatorów klientów i obsługują komunikację dotyczącą naruszeń. Wyłączenie jest dopuszczalne tylko wtedy, gdy jest udokumentowane, uzasadnione i zatwierdzone.

Korporacyjna Polityka zgodności prawnej i regulacyjnej Polityka zgodności prawnej i regulacyjnej operacjonalizuje mapowanie prawne:

„Wszystkie obowiązki prawne i regulacyjne muszą być mapowane do konkretnych polityk, środków kontrolnych i właścicieli w ramach Systemu Zarządzania Bezpieczeństwem Informacji (SZBI).”

To pomost między stosowalnością prawną a Deklaracją stosowania. NIS2 Article 21 nie powinien pozostawać w notatce prawnej. Obowiązki DORA dotyczące ICT stron trzecich nie powinny pozostawać wyłącznie w wytycznych zakupowych. Obowiązki GDPR Article 30 i Article 32 nie powinny znajdować się wyłącznie w rejestrze prywatności. Wymagają przypisanych właścicieli, zabezpieczeń i dowodów.

Korporacyjna Polityka zarządzania ryzykiem Polityka zarządzania ryzykiem rozszerza zakres na strony trzecie:

„Niniejsza polityka ma zastosowanie do wszystkich jednostek organizacyjnych, procesów biznesowych, systemów, personelu i relacji ze stronami trzecimi zaangażowanych w postępowanie z aktywami informacyjnymi, ich rozwój, przechowywanie lub zarządzanie nimi.”

Takie brzmienie jest zgodne z bezpieczeństwem łańcucha dostaw NIS2, ryzykiem ICT stron trzecich DORA oraz rozliczalnością administratora lub podmiotu przetwarzającego w ramach GDPR.

Korporacyjna Polityka ochrony danych i prywatności Polityka ochrony danych i prywatności zakotwicza zakres prywatności w przetwarzaniu:

„Niniejsza polityka ma zastosowanie do wszystkich jednostek organizacyjnych, personelu i systemów uczestniczących w przetwarzaniu danych osobowych umożliwiających identyfikację osoby (PII), w tym:”

Zasada jest rozstrzygająca. Jeżeli system przetwarza PII, nie może być niewidoczny dla SZBI tylko dlatego, że jest „wyłącznie wsparciem”, „nieprodukcyjny” lub „należy do marketingu”.

Korporacyjna Polityka ciągłości działania i odtwarzania po awarii Polityka ciągłości działania i odtwarzania po awarii wiąże zakres z wynikami BIA:

„Niniejsza polityka ma zastosowanie do wszystkich jednostek organizacyjnych, systemów informatycznych, procesów biznesowych, personelu i usług stron trzecich sklasyfikowanych jako krytyczne lub kluczowe na podstawie wyników analizy wpływu na biznes (BIA).”

Ta klauzula naturalnie współgra z krytycznymi lub istotnymi funkcjami DORA oraz ciągłością usług NIS2.

W przypadku mniejszych organizacji polityki Clarysec dla MŚP zachowują zwięzłość, utrzymując tę samą logikę. Polityka MŚP Polityka audytu i monitorowania zgodności-sme Polityka audytu i monitorowania zgodności-sme - MŚP definiuje zakres audytu jako:

„Wszystkie środki kontrolne i systemy w zakresie Systemu Zarządzania Bezpieczeństwem Informacji (SZBI)”

Polityka MŚP Polityka ochrony danych i prywatności-sme Polityka ochrony danych i prywatności-sme - MŚP definiuje zakres prywatności jako:

„Każdy system, aplikacja lub lokalizacja, w której dane osobowe są przechowywane lub przesyłane”

Polityka MŚP Polityka zarządzania ryzykiem-sme Polityka zarządzania ryzykiem-sme - MŚP utrzymuje widoczność usług outsourcingowych:

„Wszystkie informacje, usługi i aktywa zarządzane wewnętrznie lub za pośrednictwem stron trzecich”

Tak krótkie klauzule są skuteczne, ponieważ uniemożliwiają granicy certyfikacyjnej wyłączenie danych regulowanych, usług chmurowych lub aktywów zarządzanych przez dostawców.

Inwentarz aktywów to miejsce, w którym zakres staje się rzeczywisty

Deklaracja zakresu jest wiarygodna tylko wtedy, gdy można ją prześledzić do aktywów, właścicieli, dostawców, przepływów danych i dowodów.

Zenith Blueprint, w fazie zarządzania ryzykiem, krok 9: identyfikacja aktywów, zagrożeń i podatności, instruuje organizacje, aby sporządziły wykaz aktywów w zakresie SZBI oraz ujęły właściciela, lokalizację i klasyfikację. Podaje praktyczny przykład:

„Baza danych klientów – własność działu IT – hostowana na AWS – zawiera dane osobowe i finansowe (wysoka wrażliwość).”

Ten sam krok dodaje przypomnienie dotyczące zakresu, bezpośrednio istotne dla NIS2 i GDPR:

„Upewnij się, że aktywa zawierające dane osobowe są oznaczone (ze względu na znaczenie dla GDPR), a aktywa usług krytycznych są odnotowane (ze względu na potencjalną stosowalność NIS2, jeśli działasz w sektorze regulowanym).”

Zenith Controls: przewodnik po zgodności krzyżowej Clarysec Zenith Controls traktuje zabezpieczenie ISO/IEC 27002:2022 5.9, Inwentarz informacji i innych powiązanych aktywów, jako fundamentalne zabezpieczenie zgodności krzyżowej. Jego atrybuty klasyfikują zabezpieczenie jako zapobiegawcze, wspierające poufność, integralność i dostępność, zgodne z koncepcją cyberbezpieczeństwa Identify, zdolnością operacyjną zarządzania aktywami oraz domenami ładu zarządczego, ekosystemu i ochrony.

Zenith Controls jasno wyjaśnia znaczenie dla GDPR i NIS2:

„Bez dokładnego i aktualnego inwentarza aktywów organizacje nie mogą ocenić ani wdrożyć odpowiednich zabezpieczeń.”

W przypadku NIS2 inwentarz aktywów wspiera identyfikację systemów i komponentów krytycznych stanowiących podstawę usług kluczowych lub ważnych. W przypadku DORA DORA Article 8 czyni identyfikację aktywów ICT i aktywów informacyjnych centralnym elementem odporności operacyjnej. W przypadku GDPR inwentarz aktywów wspiera mapowanie przepływów danych, jakość RoPA i reakcję na naruszenie.

Wspierające normy ISO wzmacniają tę samą logikę. ISO/IEC 27005:2024 wzmacnia identyfikację aktywów w ocenie ryzyka bezpieczeństwa informacji. ISO 22301:2019 wspiera identyfikację zasobów potrzebnych do zapewnienia ciągłości działania. ISO/IEC 19770-1:2017 wspiera dojrzałość zarządzania aktywami IT. ISO/IEC 27017:2015 i ISO/IEC 27018:2019 wspierają zabezpieczenia specyficzne dla chmury oraz ochronę PII w chmurach publicznych. ISO/IEC 27701:2019 rozszerza zarządzanie informacjami o prywatności. ISO/IEC 29100:2011 wnosi zasady prywatności, takie jak przejrzystość, minimalizacja i środki bezpieczeństwa.

Praktyczne ćwiczenie definiowania zakresu dla zespołów SaaS i fintech

Zacznij od jednej usługi regulowanej, a nie od całej spółki. Na przykład: „unijna usługa SaaS analityki płatności dla instytucji finansowych”.

Następnie zbuduj mapę od usługi do aktywów i przetwarzania.

Bardziej szczegółowa próbka aktywów może wyglądać następująco.

Następnie użyj Zenith Blueprint krok 13: planowanie postępowania z ryzykiem i Deklaracja stosowania. Przewodnik instruuje użytkowników, aby zbudowali SoA z użyciem szablonu, który wymienia wszystkie zabezpieczenia załącznika A, oraz zdecydowali o stosowalności na podstawie postępowania z ryzykiem, wymagań prawnych lub umownych, znaczenia dla zakresu i kontekstu organizacji. Wskazuje:

„Dla każdego środka kontrolnego (wiersza) w arkuszu SoA zdecyduj, czy jest on stosowalny do Twojego SZBI.”

Dla powyższego przykładu SoA powinna uwzględniać zabezpieczenia dotyczące bezpieczeństwa dostawców, usług chmurowych, zarządzania incydentami, ciągłości działania, wymagań prawnych i regulacyjnych, prywatności, zarządzania podatnościami, kopii zapasowych, rejestrowania, monitorowania, kryptografii, bezpiecznego rozwoju oprogramowania, testów bezpieczeństwa i zarządzania zmianami.

Praktyczny przepływ pracy wygląda następująco:

1. Utwórz kartę „Mapowanie zakresu SZBI” w rejestrze ryzyka i kreatorze SoA.
2. Dodaj jeden wiersz dla każdej regulowanej usługi lub linii produktowej.
3. Powiąż każdą usługę z aktywami, typami danych, dostawcami, lokalizacjami i właścicielami biznesowymi.
4. Oznacz znaczenie dla NIS2, znaczenie dla DORA i znaczenie przetwarzania dla GDPR.
5. Dodaj scenariusze ryzyka dotyczące niedostępności usługi, naruszenia ochrony danych osobowych, awarii dostawcy, błędnej konfiguracji chmury, krytycznej podatności i nieskuteczności zgłaszania incydentów.
6. Wybierz zabezpieczenia SoA na podstawie tych ryzyk i obowiązków.
7. Udokumentuj wyłączenia, środki kompensujące i akceptację ryzyka.
8. Uzyskaj zatwierdzenie najwyższego kierownictwa dla końcowych granic i wyłączeń.
9. Przekaż ostateczną granicę do audytu wewnętrznego, przeglądu zarządzania i monitorowania dostawców.

Wynikiem nie jest tylko lepsza deklaracja zakresu. Jest nim możliwy do obrony łańcuch od usługi regulowanej do aktywa, dostawcy, danych, zabezpieczenia, właściciela i dowodu.

Mapowanie zgodności krzyżowej: jeden zakres, wiele obowiązków

Dobrze określony zakres SZBI ISO 27001 staje się warstwą operacyjną, w której można uzgodnić oczekiwania NIS2, DORA, GDPR, NIST CSF i COBIT.

W przypadku zabezpieczenia ISO/IEC 27002:2022 5.31, Wymagania prawne, ustawowe, regulacyjne i umowne, Zenith Controls wiąże obowiązki zgodności z prywatnością, ochroną PII, okresami przechowywania zapisów, niezależnym przeglądem i zgodnością z politykami wewnętrznymi. Naturalnie mapuje się to na rozliczalność GDPR, zgodność łańcucha dostaw NIS2, zarządzanie ryzykiem ICT i zgodność DORA, ład zarządczy NIST CSF oraz monitorowanie zgodności zewnętrznej COBIT 2019.

W przypadku zabezpieczenia ISO/IEC 27002:2022 5.34, Prywatność i ochrona PII, Zenith Controls łączy prywatność z inwentarzem aktywów, usługami chmurowymi, klasyfikacją, transferem informacji, kontrolą dostępu, zarządzaniem tożsamością i przeglądami zmian projektowych. Jego mapowanie GDPR obejmuje bezpieczeństwo przetwarzania i ochronę danych w fazie projektowania. Jego mapowanie DORA wspiera integralność, bezpieczeństwo i poufność danych, w tym danych osobowych obsługiwanych w usługach ICT.

Zasada jest prosta: nie twórz czterech odłączonych programów zgodności. Utwórz jeden SZBI o określonym zakresie, który potrafi wyjaśnić, jak obowiązki są spełniane, dokumentowane dowodami i audytowane.

Zakres zgłaszania incydentów: gdzie granice wpływają na terminy regulacyjne

Nieprawidłowy zakres staje się boleśnie widoczny podczas incydentów.

NIS2 Article 23 wymaga etapowego zgłaszania istotnych incydentów, w tym wczesnego ostrzeżenia w ciągu 24 godzin, zgłoszenia incydentu w ciągu 72 godzin, raportów pośrednich na żądanie oraz raportu końcowego w ciągu jednego miesiąca. Może być również wymagana komunikacja do dotkniętych odbiorców.

DORA wymaga od podmiotów finansowych wykrywania, zarządzania, klasyfikowania i zgłaszania poważnych incydentów związanych z ICT z wykorzystaniem kryteriów takich jak dotknięci klienci lub kontrahenci, czas trwania, przestój, zasięg geograficzny, utrata danych, krytyczność dotkniętych usług i wpływ ekonomiczny. Klienci muszą zostać poinformowani bez zbędnej zwłoki, gdy poważny incydent ICT wpływa na ich interesy finansowe.

Zgłoszenie naruszenia ochrony danych osobowych w ramach GDPR zależy od tego, czy naruszenie prowadzi do przypadkowego lub niezgodnego z prawem zniszczenia, utraty, zmiany, nieuprawnionego ujawnienia danych osobowych lub dostępu do nich.

Jeżeli platforma wsparcia, środowisko logów, usługa tożsamości, kanał powiadamiania klientów lub dostawca zarządzanego wykrywania znajdują się poza zakresem SZBI, zespoły incydentowe mogą nie wiedzieć, czy zdarzenie uruchamia obowiązki raportowania NIS2, DORA, GDPR, umów z klientami, czy wszystkich tych reżimów jednocześnie. Ta niepewność zużywa czas przewidziany na zgłoszenie.

Dojrzały zakres obejmuje zależności istotne dla incydentów: narzędzia wykrywania, magazyny logów, repozytoria materiału dowodowego, kanały komunikacji z klientami, narzędzia wsparcia, środowiska kopii zapasowych, mostki incydentowe oraz dostawców zaangażowanych w triage lub odtwarzanie.

Jak audytorzy i organy nadzoru będą testować zakres SZBI

Silny zakres wytrzymuje próbkowanie. Słaby zakres załamuje się, gdy audytorzy porównują dokumenty z rzeczywistością.

Zenith Controls dostarcza użytecznych oczekiwań audytowych dla zabezpieczenia ISO/IEC 27002:2022 5.9. Audytorzy stosujący podejście ISO/IEC 19011 proszą o inwentarz na wczesnym etapie, aby określić zakres innych ocen i wyrywkowo sprawdzić aktywa fizyczne, programowe i chmurowe. Audytorzy stosujący podejście ISO/IEC 27007 pytają, jak i kiedy inwentarz jest aktualizowany, szukając powiązań z zakupami, zarządzaniem zmianami i wycofaniem z eksploatacji. Audytorzy stosujący podejście NIST SP 800-53A weryfikują, czy szczegóły inwentarza obejmują typ aktywa, właściciela, lokalizację, adres sieciowy tam, gdzie ma to zastosowanie, oraz status, a także czy uwzględniono aktywa chmurowe, wirtualne i mobilne.

W przypadku zabezpieczenia 5.31 Zenith Controls wskazuje, że audytorzy certyfikacyjni oczekują rejestru zgodności albo listy przepisów i umów, wskazanych w SoA i planach postępowania z ryzykiem. Audytorzy COBIT szukają właścicieli zgodności, ocen i raportowania do kierownictwa wyższego szczebla. Audytorzy ISACA ITAF próbkują dowody, aby potwierdzić, że organizacja nie tylko zna swoje obowiązki, ale aktywnie zapewnia ich spełnianie.

W przypadku zabezpieczenia 5.34 audytorzy przeglądają polityki prywatności, inwentarze danych, DPIA, dzienniki szkoleń, dowody szyfrowania, środki kontroli dostępu, próbki DSAR, dowody privacy-by-design oraz zapisy incydentów obejmujących PII. Deklaracja zakresu, która wyłącza system przetwarzający dane osobowe, zostanie szybko zakwestionowana.

Pytanie zarządu: czego nie można wyłączyć?

Najwyższe kierownictwo często pyta, czy jednostka biznesowa, lokalizacja, dostawca lub system mogą pozostać poza zakresem SZBI. Czasami odpowiedź brzmi: tak. Ale nie wtedy, gdy wyłączenie uniemożliwia organizacji spełnienie obowiązków prawnych, regulacyjnych, umownych lub dotyczących bezpieczeństwa usługi.

Przed zatwierdzeniem jakiegokolwiek ograniczenia granicy zastosuj ten test wyłączenia:

• Czy jednostka, system lub dostawca wspiera usługę regulowaną przez NIS2?
• Czy wspiera krytyczną lub istotną funkcję DORA dla organizacji albo jej regulowanych klientów?
• Czy zbiera, przechowuje, przesyła, rejestruje, wspiera lub usuwa dane osobowe?
• Czy zapewnia monitorowanie bezpieczeństwa, tożsamość, kopie zapasowe, reagowanie na incydenty lub odtwarzanie dla usługi objętej zakresem?
• Czy dostarcza dowody potrzebne do klasyfikacji incydentu lub zgłoszenia regulacyjnego?
• Czy umowa z klientem wymaga objęcia go SZBI?
• Czy jego naruszenie bezpieczeństwa wpłynęłoby na poufność, integralność, dostępność, zgodność prawną lub ciągłość usługi w zadeklarowanym zakresie?

Jeżeli odpowiedź brzmi tak, wyłączenie wymaga mocnych dowodów, kompensacyjnego ładu zarządczego, akceptacji ryzyka i formalnego zatwierdzenia przez najwyższe kierownictwo. W wielu przypadkach nie powinno zostać wyłączone.

Nowoczesny zakres SZBI ISO 27001 powinien obejmować:

1. Objęte usługi biznesowe i linie produktowe.
2. Objęte osoby prawne, jednostki organizacyjne i lokalizacje.
3. Segmenty klientów i jurysdykcje generujące obowiązki.
4. Krytyczne lub istotne funkcje oraz usługi kluczowe oparte na BIA.
5. Aktywa informacyjne, aktywa ICT i środowiska chmurowe.
6. Czynności przetwarzania danych osobowych i repozytoria PII.
7. Procesy rozwoju, testowania, wsparcia, monitorowania i obsługi incydentów.
8. Dostawców i usługi outsourcingowe wspierające usługi objęte zakresem.
9. Interfejsy i zależności ze spółkami grupy lub podmiotami zewnętrznymi.
10. Jawne wyłączenia wraz z uzasadnieniem, akceptacją ryzyka i zatwierdzeniem przez najwyższe kierownictwo.

W ten sposób zakres ISO 27001 staje się stanowiskiem ładu zarządczego na poziomie zarządu, a nie skrótem certyfikacyjnym.

Przygotuj zakres SZBI do audytu, zanim audytor zdefiniuje go za Ciebie

Najgorszym momentem na odkrycie problemu z zakresem jest certyfikacja, audyt nadzoru, due diligence klienta albo aktywny incydent.

Wąski certyfikat może spełnić wymóg w formularzu zakupowym, ale nie wytrzyma poważnej kontroli, jeśli wyłącza usługi, funkcje ICT, dostawców i przetwarzanie danych osobowych, które tworzą ekspozycję regulacyjną. W 2026 r. organizacje, które będą przechodzić audyty z pewnością, to te, które potrafią pokazać jedną spójną mapę od usługi regulowanej do aktywa, dostawcy, danych osobowych, zabezpieczenia, właściciela i dowodu.

Zacznij od trzech konkretnych działań:

1. Użyj Zenith Blueprint Zenith Blueprint, faza: fundamenty i przywództwo SZBI, krok 2, aby przeformułować zakres SZBI wokół usług, funkcji, przetwarzania i zależności.
2. Użyj Zenith Controls Zenith Controls, aby mapować inwentarz aktywów, obowiązki prawne i ochronę PII względem oczekiwań audytowych ISO 27001, NIS2, DORA, GDPR, NIST i COBIT 2019.
3. Uzgodnij zakres polityk, korzystając z Polityki bezpieczeństwa informacji Clarysec Polityka bezpieczeństwa informacji, Polityki zgodności prawnej i regulacyjnej Polityka zgodności prawnej i regulacyjnej, Polityki zarządzania ryzykiem Polityka zarządzania ryzykiem, Polityki ochrony danych i prywatności Polityka ochrony danych i prywatności oraz Polityki ciągłości działania i odtwarzania po awarii Polityka ciągłości działania i odtwarzania po awarii.

Jeżeli Twój obecny zakres SZBI nadal brzmi jak etykieta działu, przebuduj go jako granicę zgodności. Pobierz zestawy narzędzi Clarysec, zmapuj jedną usługę regulowaną od początku do końca i przekształć swój zakres ISO 27001 w dowody gotowe do audytu dla NIS2, DORA i GDPR.