ISO Compliance Governance

Jak napisać zakres SZBI w ISO 27001 (z przykładami)

Maciej
Jak napisać zakres SZBI w ISO 27001 (z przykładami)
TL;DR

Deklaracja zakresu SZBI określa granice i zastosowanie systemu zarządzania bezpieczeństwem informacji: które usługi, lokalizacje, podmioty i technologie są objęte oraz gdzie kończy się Twoja odpowiedzialność. Punkt 4.3 normy ISO/IEC 27001 wymaga, żebyś uwzględnił kwestie wewnętrzne i zewnętrzne z punktu 4.1, wymagania stron zainteresowanych z punktu 4.2 oraz powiązania i zależności z innymi organizacjami, a następnie utrzymywał wynik jako udokumentowaną informację. Zwykle to jeden akapit, drukuje się go na certyfikacie i jest pierwszą rzeczą, którą czyta audytor. Dwa typowe błędy to zakres tak szeroki, że musisz dowodzić zgodności systemów, o które nikt nie pytał, oraz tak wąski, że klienci nie uwierzą, iż certyfikat obejmuje to, co kupują.

Deklaracja zakresu SZBI określa granice i zastosowanie Twojego systemu zarządzania bezpieczeństwem informacji: które usługi, lokalizacje, podmioty prawne i technologie obejmuje — i, co równie ważne, gdzie kończy się Twoja odpowiedzialność. Zwykle ma długość jednego akapitu, drukuje się ją na certyfikacie ISO 27001 i jest pierwszą rzeczą, jaką audytor czyta o Twojej organizacji.

To połączenie — bardzo krótkie, bardzo brzemienne w skutki — sprawia, że tak wiele zespołów robi to źle. Ten przewodnik pokazuje, czego naprawdę wymaga punkt 4.3, co powinien wymieniać użyteczny zakres, trzy rozpisane przykłady do zaadaptowania oraz błędy w granicach, które utrudniają certyfikację bardziej, niż to konieczne.

Czego wymaga punkt 4.3 normy ISO 27001

Punkt 4.3, „Określenie zakresu systemu zarządzania bezpieczeństwem informacji”, wymaga wyznaczenia granic i zastosowania SZBI. Norma nakazuje przy tym uwzględnić trzy konkretne dane wejściowe:

  • Kwestie zewnętrzne i wewnętrzne z punktu 4.1 — kontekst, w którym działasz: Twój rynek, otoczenie regulacyjne, wybory technologiczne, Twoja wielkość.
  • Wymagania stron zainteresowanych z punktu 4.2 — czego oczekują od Ciebie klienci, regulatorzy, inwestorzy i pracownicy. (Od zmiany z 2024 roku obejmuje to wprost rozważenie, czy zmiana klimatu jest istotną kwestią — zobacz zmianę, o której nikt Ci nie powiedział.)
  • Powiązania i zależności między działaniami, które wykonujesz Ty, a działaniami wykonywanymi przez inne organizacje — Twoich dostawców chmury, podwykonawców przetwarzania, zewnętrzny help desk.

Dalej punkt wymaga, żeby zakres był „dostępny jako udokumentowana informacja”. To całe wymaganie. Nie ma narzuconego szablonu, minimalnej długości ani obowiązkowego formatu — i właśnie dlatego zespoły wpatrują się w pustą kartkę.

Trzecia dana wejściowa jest pomijana najczęściej. Zakres, który ani razu nie wspomina o Twoim dostawcy chmury czy zewnętrznym wsparciu, mówi audytorowi, że nie przemyślałeś, gdzie kończy się Twoja kontrola, a zaczyna cudza — i to jest pierwsza rzecz, którą audytor zacznie drążyć.

Co powinien wymieniać użyteczny zakres

Zakres, który przetrwa zderzenie z audytorem, wymienia sześć rzeczy. Nie wszystkie sześć muszą znaleźć się w zdaniu, które trafi na certyfikat, ale wszystkie sześć musi być określonych i gdzieś udokumentowanych:

  1. Objęte produkty i usługi. To, co faktycznie sprzedajesz, słowami, których używają Twoi klienci.
  2. Jednostki organizacyjne i podmioty prawne. Które spółki, które zespoły. Jeśli masz spółki zależne, wymień je albo wprost wyłącz.
  3. Lokalizacje. Biura, regiony centrów danych oraz — przy zespołach rozproszonych — fakt, że część ludzi pracuje zdalnie, co uruchamia zabezpieczenia dotyczące pracy z domu.
  4. Technologia i infrastruktura. Platforma, regiony chmury, wspierające IT korporacyjne.
  5. Powiązania i zależności. Gdzie przekazujesz pałeczkę dostawcy i co po Twojej stronie tej linii pozostaje Twoją odpowiedzialnością.
  6. Wyłączenia wraz z uzasadnieniem. Wszystko, co czytający rozsądnie uznałby za objęte zakresem, a co objęte nie jest.

Trzy rozpisane przykłady

Dostosuj je do własnych faktów, zamiast kopiować — audytor, który przeczyta zakres niepasujący do tego, co widzi w Twoich systemach, zacznie audyt sceptycznie nastawiony.

Przykład 1: SaaS z całą firmą w zakresie

SZBI obejmuje projektowanie, rozwój, utrzymanie i wsparcie platformy software-as-a-service [Produkt], łącznie z całym wspierającym IT korporacyjnym i procesami biznesowymi, świadczone przez [Spółka sp. z o.o.] z jej siedziby w [Miasto, Kraj] oraz przez personel pracujący zdalnie. Platforma jest hostowana na infrastrukturze [Dostawca chmury] w regionie [region]. Powiązania z [Dostawca chmury] i podwykonawcami przetwarzania wymienionymi w rejestrze dostawców SZBI oraz zależności od nich są zarządzane w ramach procesu zarządzania dostawcami; odpowiedzialność za leżącą u podstaw infrastrukturę fizyczną spoczywa na tych dostawcach.

To właściwy kształt dla większości startupów. Wszystko, co robi firma, jest w zakresie — brzmi to ekspansywnie, ale w praktyce jest najtańszą opcją, kiedy firma robi tylko jedną rzecz.

Przykład 2: Zakres ograniczony do jednostki biznesowej

SZBI obejmuje świadczenie usługi [Płatności] przez jednostkę biznesową [Płatności] w [Grupa sp. z o.o.], łącznie z funkcjami inżynierii, utrzymania i obsługi klienta wspierającymi tę usługę, w biurze w [Miasto] oraz na infrastrukturze [Dostawca chmury] w [region]. Pozostałe jednostki biznesowe [Grupa sp. z o.o.], w tym [Usługi marketingowe] i [Doradztwo], znajdują się poza zakresem SZBI. Współdzielone usługi korporacyjne (HR, finanse, IT korporacyjne) mieszczą się w zakresie w takim stopniu, w jakim wspierają usługę [Płatności].

To ostatnie zdanie Cię ratuje. Współdzielone usługi to miejsce, w którym zakres ograniczony do jednostki biznesowej zwykle się sypie: jeśli IT korporacyjne wydaje laptopy, których używają Twoi inżynierowie objęci zakresem, to IT korporacyjne jest w zakresie w tym celu — niezależnie od tego, czy tego chciałeś.

Przykład 3: Z wyłączonym podmiotem

SZBI obejmuje rozwój i utrzymanie platformy [Produkt] przez [Spółka sp. z o.o.] ([Miasto, Kraj]). [Spółka GmbH] ([Miasto, Kraj]), przejęta w [Miesiąc Rok], prowadząca odrębny produkt na odrębnym stosie infrastruktury bez przepływów danych do lub z platformy [Produkt], jest wyłączona z zakresu SZBI.

Wyłączenia są w porządku — ale uzasadnienie musi być faktem o izolacji, a nie deklaracją wygody. „Brak przepływów danych do lub z” to fakt, który audytor może sprawdzić. „Jeszcze niezintegrowana” to plan, a plan zaprasza do pytania uzupełniającego przy każdym audycie nadzoru.

Ready to Streamline Your Compliance?

Discover how AuditBadger can simplify your compliance management process.

Wyłączenia z zakresu to nie wyłączenia zabezpieczeń

To zdecydowanie najczęstsze pomieszanie pojęć i kosztuje zespoły czas podczas pierwszego audytu certyfikacyjnego.

Wyłączenia z zakresu to granice: podmioty, lokalizacje, usługi albo systemy, których SZBI nie obejmuje. Ich miejsce jest w deklaracji zakresu, zgodnie z punktem 4.3.

Wyłączenia zabezpieczeń to zabezpieczenia z Załącznika A, które uznałeś za niemające zastosowania — na przykład zabezpieczenia nośników fizycznych, gdy nie posiadasz żadnych nośników fizycznych. Ich miejsce jest w Deklaracji Stosowania, gdzie punkt 6.1.3 wymaga uzasadnienia dla każdego z nich.

Wpisywanie wyłączeń zabezpieczeń do deklaracji zakresu sprawia, że Twój certyfikat wygląda na węższy niż Twój faktyczny biznes — a to dokładnie ten efekt, który wychwyci dział zakupów klienta. Niech oba dokumenty robią swoją robotę.

Zbyt szeroko kontra zbyt wąsko

Oba błędy są kosztowne, tylko w innej walucie.

Zbyt szeroko kosztuje Cię nakład pracy audytowej. Każdy system wewnątrz granicy potrzebuje właściciela, oceny ryzyka, dowodów i pokrycia audytem wewnętrznym. Zespoły, które biorą w zakres „całą grupę”, zanim mają działające SZBI, kończą na dowodzeniu zgodności narzędzi marketingowych i uśpionych spółek zależnych, o które nigdy nie pytał żaden klient.

Zbyt wąsko kosztuje Cię sens całego ćwiczenia. Certyfikat o zakresie „funkcja bezpieczeństwa informacji w centrali” jest formalnie ważny i handlowo bezużyteczny — klient, który go czyta, nie jest w stanie stwierdzić, czy produkt, który kupuje, jest objęty. Jeśli Twój zakres nie nazywa tego, co sprzedajesz, spodziewaj się, że certyfikat dalej będzie oblewał weryfikacje zakupowe.

Test wart zastosowania: daj swoją deklarację zakresu komuś ze sprzedaży i zapytaj, czy klient po jej przeczytaniu uwierzyłby, że kupowany przez niego produkt jest objęty. Jeśli odpowiedź brzmi „nie”, granica jest w złym miejscu.

Rozjeżdżanie się zakresu i kiedy go przeglądać

Zakresu nie pisze się raz na zawsze. To udokumentowana informacja podlegająca nadzorowi nad zmianami i powinna być przeglądana, kiedy biznes zmienia kształt. Konkretne wyzwalacze, które warto wpisać do SZBI:

  • Nowa linia produktowa albo istotna zmiana w istniejącej
  • Przejęcie, nowy podmiot prawny albo nowe biuro
  • Nowy region chmury albo migracja między dostawcami
  • Nowa kategoria danych klientów albo nowy obowiązek regulacyjny
  • Oddanie na zewnątrz czegoś, co wcześniej robiliście sami — albo ściągnięcie tego z powrotem do siebie

Zmiany zakresu są też stałą daną wejściową przeglądu zarządzania według punktu 9.3. Jeśli Twoja deklaracja zakresu ma rok, a Twoja architektura nie, ta luka wyjdzie na kolejnym audycie nadzoru — a zakres, który nie odpowiada już rzeczywistości, to ustalenie z audytu, a nie formalność.

Wniosek

Napisz zakres, którego Twój biznes naprawdę potrafi obronić: nazwij usługi słowami klientów, nazwij podmioty i lokalizacje, jasno powiedz, gdzie zaczyna się odpowiedzialność Twoich dostawców, i uzasadnij wyłączenia faktami zamiast intencjami. A potem utrzymuj go aktualnym, bo to jedyny dokument SZBI, który przeczytają Twoi klienci.

Dalej: pełne omówienie punktów 4–10, żeby zobaczyć, jak zakres zasila resztę SZBI, jak napisać Deklarację Stosowania — dokument na poziomie zabezpieczeń, który przychodzi zaraz po nim, albo rejestr aktywów, który zamienia Twoją granicę w listę, którą naprawdę da się udowodnić.

Czytaj dalej

Więcej notatek wdrożeniowych i kontekstu operatora z tego samego obszaru.

Kontrole z Załącznika A ISO 27001: kompletny przewodnik 2022
ISO

Kontrole z Załącznika A ISO 27001: kompletny przewodnik 2022

Załącznik A do ISO 27001 zawiera 93 kontrole bezpieczeństwa ułożone w cztery kategorie, które tworzą kręgosłup Twojego systemu zarządzania bezpieczeństwem informacji. Wersja z 2013 roku oficjalnie wygasła w październiku 2025, więc każda organizacja dążąca do certyfikacji ISO 27001 lub ją utrzymująca pracuje dziś na rewizji z 2022 roku. Ten przewodnik tłumaczy, jak kontrole są ustrukturyzowane, co zmieniło się między 2013 a 2022, które 11 nowych kontroli dodano oraz jak wybierać, wdrażać i dokumentować kontrole na podstawie realnych ryzyk.

22/05/2025 · 13 min czytania
Zarządzanie politykami wewnętrznymi: kompletny praktyczny przewodnik
Compliance Governance

Zarządzanie politykami wewnętrznymi: kompletny praktyczny przewodnik

Zarządzanie politykami odróżnia firmy, które przechodzą audyty, od tych, które w ostatniej chwili gaszą pożary. Ten praktyczny przewodnik pokazuje, jak budować, wdrażać i utrzymywać polityki wewnętrzne, których zespół faktycznie przestrzega — od cyklu życia polityki i wymagań specyficznych dla compliance po generowanie polityk z pomocą AI i workflow potwierdzeń, których oczekują audytorzy.

13/06/2025 · 6 min czytania
Następny krok

Chcesz zastąpić rozproszoną pracę nad compliance?

Zobacz, jak AuditBadger zamienia polityki, dowody, ryzyka i przygotowanie do audytu w jeden system operacyjny dla małych zespołów.

Rozpocznij subskrypcję