Jak napisać zakres SZBI w ISO 27001 (z przykładami)
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:
- Objęte produkty i usługi. To, co faktycznie sprzedajesz, słowami, których używają Twoi klienci.
- 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.
- 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.
- Technologia i infrastruktura. Platforma, regiony chmury, wspierające IT korporacyjne.
- Powiązania i zależności. Gdzie przekazujesz pałeczkę dostawcy i co po Twojej stronie tej linii pozostaje Twoją odpowiedzialnością.
- 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ć.