W uproszczeniu mówiąc Polityka Bezpieczeństwa informacji to zestaw praw, reguł i praktycznych doświadczeń regulujących sposób zarządzania, ochrony i dystrybucji danych osobowych. Co powinien zawierać wzór dokumentu? Jakie są jego elementy? Cel tego tekstu jest prosty: dać Ci gotowy, aktualny i zrozumiały szkielet polityki bezpieczeństwa informacji – taki, który spełni wymagania norm i przepisów, ale będzie też realnym narzędziem do zarządzania ryzykiem w codziennej pracy.

polityka bezpieczenstwa informacji

elements.envato.com

Polityka bezpieczeństwa informacji

Informacja to jeden z najważniejszych zasobów przedsiębiorstwa. Żeby zrozumieć jak ważny, warto wiedzieć, że przez informację rozumiemy wszelkiego rodzaju treści wyrażone za pomocą mowy, pisma, obrazu, rysunku, kodu, dźwięku itd. Jednym słowem informacja to wszelkie dane przechowywane w firmie na różnego rodzaju nośnikach. Nic dziwnego, że firmy przykładają ogromną wagę do rzetelnie opracowanej polityki bezpieczeństwa informacji, której przestrzeganie wymaga wprowadzenia odpowiednich procedur oraz zapewnienia bezpieczeństwa systemów informacyjnych.

Sprawdź też:

Właściwie możemy przyjąć, że każda informacja w firmie czy instytucji powinna być chroniona. Z różnych względów! Część danych, takich jak bussines plany, informacje finansowe, plany inwestycyjne itd. podlegają ochronie przez wzgląd na interes danej firmy. Inne dane są chronione ze względu na określone przepisy prawa. Pozostałe informacje, mimo iż prawo tego nie wymaga, a ich wyciek nie stanowiłby zagrożenia dla firmy, są chronione przez zniszczeniem czy też niepożądanym modyfikowaniem, które mogłyby zakłócić pracę danej firmy. Nic więc dziwnego, że zarówno mniejsze, jak i większe przedsiębiorstwa kładą tak duży nacisk na opracowanie Polityki bezpieczeństwa informacji oraz przestrzeganie jej.

Jak czytamy w opracowaniu „Polityka bezpieczeństwa informacji instytucji na przykładzie Instytutu Łączności”:

Celem działań w zakresie ochrony i zapewnienia bezpieczeństwa informacji w instytucji jest osiągnięcie takiego poziomu organizacyjnego i technicznego, który:

  • zagwarantuje zachowanie poufności informacji chronionych;
  • zapewni integralność informacji chronionych i jawnych oraz dostępność do nich;
  • zagwarantuje wymagany poziom bezpieczeństwa przetwarzanych informacji;
  • maksymalnie ograniczy występowanie zagrożeń dla bezpieczeństwa informacji;
  • zapewni poprawne i bezpieczne funkcjonowanie systemów przetwarzania informacji;
  • zapewni gotowość do podejmowania działań w sytuacjach kryzysowych.

Czym właściwie jest PBI—i czym różni się od ISMS?

Polityka bezpieczeństwa informacji (PBI) to nadrzędny dokument organizacji, który opisuje zasady ochrony informacji: po co chronimy, co chronimy, kto odpowiada i jak mierzymy skuteczność. ISMS (Information Security Management System) to cały system zarządzania bezpieczeństwem: rola kierownictwa, ocena ryzyka, procedury, szkolenia, audyty i doskonalenie. PBI jest „konstytucją” ISMS—wyznacza kierunek i granice. W praktyce: PBI czyta zarząd i pracownicy, a ISMS „pracuje” na zapleczu dzięki standardom, procedurom i zapisom.

Polityka bezpieczeństwa informacji: wzór

Przejdźmy do konkretów i stwórzmy ogólny wzór tego, co powinna zawierać Polityka bezpieczeństwa informacji. W tym celu przyjrzymy się uchylonemu już  Rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 roku. Mimo, iż rozporządzenie nie obowiązuje, zapisy w nim zawarte mogą być wskazówką dla przedsiębiorców, którzy chcą dostosować Politykę bezpieczeństwa informacji w swojej firmie do opisanych w nim wymogów. Stworzony w ten sposób dokument będzie stanowił solidny argument podczas ewentualnej kontroli firmy pod kątem spełniania wymagań RODO.

Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 roku ten szczegółowo określało:

  • wszystkie elementy składające się na sposób prowadzenia i zakres dokumentacji opisującej sposób przetwarzania danych oraz środki techniczne i organizacyjne, które należy przedsięwziąć, by skutecznie chronić dane w organizacji. Dokumentacja ta musi mieć formę pisemną. Składa się na nią polityka bezpieczeństwa i instrukcja zarządzania systemem informatycznym służącym do przetwarzania danych osobowych, zwana dalej „instrukcją”.
  • podstawowe warunki techniczne i organizacyjne, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych
  • wymagania w zakresie odnotowywania udostępniania danych osobowych i bezpieczeństwa przetwarzania danych osobowych.

Co powinna zawierać polityka bezpieczeństwa informacji?

Polityka bezpieczeństwa informacji to zbiór dokumentów opisujących zasady, które mają zapewnić bezpieczeństwo danych oraz metody ich stosowania. Wszystkie te dokumenty powinny być zgodne z obowiązującym prawem oraz określać warunki, jakie muszą spełniać systemy informatyczne i system przechowywania dokumentów papierowych, przy czym informacje są podzielone na kilka grup. Zgodnie z Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji Polityka bezpieczeństwa informacji powinna zawierać:

  • wykaz pomieszczeń i budynków, w których są przetwarzane dane osobowe
  • opis sposoby, w jaki dane są przetwarzane między systemami
  • wykaz programów używanych do przetwarzania informacji
  • zestawienie zbiorów danych
  • opis budowy zbiorów danych
  • określenie środków, które są niezbędne dla zachowania integralności, rozliczalności i poufności danych

Co zmieniło wydanie ISO/IEC 27001:2022 i co z tego wynika dla PBI?

Aktualizacja normy ISO/IEC 27001 z 2022 roku uporządkowała kontrole bezpieczeństwa tak, aby łatwiej je było zrozumieć i wdrażać. Zmiany widać szczególnie w obszarach chmury, łańcucha dostaw, zapobiegania utracie danych, zarządzania konfiguracją, logowania oraz przygotowania na incydenty. Dla PBI to dobra wiadomość, bo pozwala naturalnie ująć wymagania chmurowe obok tradycyjnych elementów, bez poczucia, że „doklejamy” coś obcego do dokumentu. Jeśli Twoja organizacja ma starszą PBI, zamiast pisać wszystko od nowa, warto dopisać rozdział o dostawcach i usługach w modelu SaaS lub IaaS, wyjaśnić kiedy stosujemy uwierzytelnianie wieloskładnikowe i logowanie zdarzeń, a także krótko opisać podejście do informacji o zagrożeniach, czyli w jaki sposób śledzimy to, co dzieje się w świecie bezpieczeństwa i jak te sygnały przekładamy na własne decyzje.

NIS2 w praktyce i co z tego dodać do PBI

Nowa dyrektywa NIS2 szerzej obejmuje podmioty istotne i kluczowe z wielu sektorów. Nawet jeśli dziś nie masz pewności, czy formalnie wejdziesz w jej zakres, przygotowanie PBI według ducha NIS2 po prostu podnosi dojrzałość organizacji. W praktyce oznacza to, że polityka powinna wskazywać odpowiedzialność kierownictwa za bezpieczeństwo, w tym zatwierdzanie polityki, akceptację ryzyka rezydualnego i regularne przeglądy wyników. Dobrze, jeśli opiszesz w niej także ogólne zasady klasyfikowania i raportowania incydentów, tak aby zespół wiedział, co należy zgłaszać, komu i w jakim czasie. Warto również opisać zarządzanie łańcuchem dostaw: jak oceniamy dostawców, jakie minimum bezpieczeństwa musi być spełnione w umowach, jak podchodzimy do podwykonawców i w jaki sposób planujemy wyjście od dostawcy bez utraty danych i ciągłości działania.

Co powinna zawierać instrukcja zarządzania systemem informatycznym?

Zgodnie z rozporządzeniem z dnia 29 kwietnia 2004 roku instrukcja zarządzania systemem informatycznym powinna zawierać:

  1. procedury nadawania uprawnień do przetwarzania danych i rejestrowania tych uprawnień w systemie informatycznym oraz wskazanie osoby odpowiedzialnej za te czynności;
  2. stosowane metody i środki uwierzytelnienia oraz procedury związane z ich zarządzaniem i użytkowaniem;
  3. procedury rozpoczęcia, zawieszenia i zakończenia pracy przeznaczone dla użytkowników systemu;
  4. procedury tworzenia kopii zapasowych zbiorów danych oraz programów i narzędzi programowych służących do ich przetwarzania;
  5. sposób, miejsce i okres przechowywania:
    a) elektronicznych nośników informacji zawierających dane osobowe,
    b) kopii zapasowych, o których mowa w pkt 4,
  6. sposób zabezpieczenia systemu informatycznego przed działalnością oprogramowania, o którym mowa w pkt III ppkt 1 załącznika do rozporządzenia;
  7. sposób realizacji wymogów, o których mowa w § 7 ust. 1 pkt 4;
  8. procedury wykonywania przeglądów i konserwacji systemów oraz nośników informacji służących do przetwarzania danych.

Poziomy bezpieczeństwa w firmie

Ze względu na poziom zagrożenia związany z wyciekiem poszczególnego rodzaju danych prawodawca wprowadził trzy poziomy bezpieczeństwa przetwarzania danych osobowych w systemie informatycznym:

  • podstawowy poziom bezpieczeństwa, który stosuje się wtedy, gdy żadne z urządzeń służących do przetwarzania tych danych nie jest połączone z siecią publiczną lub też kiedy nie są przetwarzane dane wrażliwe określone w art. 27 Ustawy o ochronie danych osobowych;
  • podwyższony poziom bezpieczeństwa, który wprowadza się wówczas, gdy w systemie przetwarzane są dane wrażliwe, ale żadne urządzenie nie jest połączone z siecią publiczną;
  • wysoki poziom bezpieczeństwa stosowany wtedy, gdy przynajmniej jedno urządzenie w systemie informatycznym służacym do przetwarzania danych osobowych połączone jest z siecią publiczną.

Warto w tym miejscu wspomnieć dodatkowo, co uznaje się za dane wrażliwe. Otóż są to dane ujawniające pochodzenie rasowe lub etniczne, poglądy polityczne, przekonania religijne lub filozoficzne, przynależność wyznaniową, partyjną lub związkową, jak również dane o stanie zdrowia, kodzie genetycznym, nałogach lub życiu seksualnym oraz dane dotyczących skazań, orzeczeń o ukaraniu i mandatów karnych, a także innych orzeczeń wydanych w postępowaniu sądowym lub administracyjnym. Przetwarzanie danych wrażliwych jest dopuszczalne w kilku określonych w ustawie przypadkach, m.in. wtedy, gdy osoba, której te dane dotyczą wyrazi pisemną zgodę na ich przetwarzanie.

Systemy służące do przetwarzania danych powinny każdorazowo automatycznie odnotowywać:

  • daty pierwszego wprowadzenia danych do systemu;
  • identyfikator użytkownika wprowadzającego dane osobowe do systemu. Wyjątkiem jest sytuacja, gdy dostęp do tego systemu posiada tylko jedna osoba;
  • źródło danych, jeśli nie pochodzą one bezpośrednio od osoby, której dotyczą;
  • informację o odbiorcach, którym dane osobowe zostały udostępnione, a także o dacie i zakresie tego udostępnienia. Odstępstwem od zasady jest umieszczenie danych w zbiorach jawnych;
  • sprzeciw wobec przetwarzania danych lub przekazywania ich innym administratorom danych.

Co więcej każda osoba, której dane są przechowywane w systemie informatycznym powinna mieć możliwość otrzymania raportu zawierającego powyższe informacje.

Polityka bezpieczeństwa informacji a rodo

Jak się ma kwestia Polityki bezpieczeństwa informacji w odniesieniu do wprowadzonego 25 maja 2018 RODO? Czy Polityka bezpieczeństwa powinna być zgodna z RODO? Okazuje się, że odpowiedź na to pytanie trudno podeprzeć konkretnymi paragrafami ustaw.

Zobacz też: Co to jest RODO i jakie ma znaczenie dla działu IT firmy?

Artykuł 24 RODO wśród obowiązków administratora danych osobowych wskazuje wdrożenie odpowiednich środków technicznych i organizacyjnych, które zapewnią zgodność przetwarzania danych osobowych z rozporządzeniem oraz zapewnienie możliwości jej wykazania. W dalszej części ustawy mowa jest o tym, że jeśli sposób przetwarzania danych tego wymaga, administrator jest zobowiązany wprowadzić odpowiednie środki polityki ochrony danych. Nie jest to obowiązek formalny, jednak jak pokazuje praktyka w razie kontroli z Urzędu Ochrony Danych Osobowych każdy przedsiębiorca musi być w stanie udowodnić, że zapewnił skuteczną ochronę danych osobowych wdrażając właściwe środki techniczne i organizacyjne. I w tym momencie przedstawienie organowi nadzorczemu prawidłowo przygotowanej Polityki bezpieczeństwa informacji będzie bardzo dobrze widziane.

Zgodna z zasadami RODO Polityka bezpieczeństwa informacji powinna opierać się na czterech filarach:

  • zgodności z zasadą privacy by design – uwzględniania ochrony danych w fazie projektowania tj. wyboru technologii, dostawcy oraz zaplanowania procesu przetwarzania tak, by już na tym etapie wdrożyć środki techniczne i organizacyjne współmierne do ryzyka naruszenia praw i wolności osób, których dane są objete przetwarzaniem.
  • zgodności z zasadą privacy by default – która określa, że administrator danych powinen wdrożyć środki techniczne i organizacyje, które pozwolą na przetwarzanie jedynie tych danych, które są absolutnie niezbędne danej organizacji. Podanie dodatkowych danych jest zależne od osoby, której one dotyczą i nie może decydować o braku np. dostarczenia usługi.
  • proporcjonalności w stosunku do czynności przetwarzania danych,
  • przejrzystości języka, jakim zostanie napisana tak, by był on zrozumiały dla odbiorców nawet wtedy, gdy opisuje zawiłe sformułowania prawne czy dotyczące systemów informatycznych

Jak PBI spotyka się z RODO?

RODO nie jest instrukcją konfiguracji systemów, tylko zbiorem zasad i obowiązków. Mówi, że środki ochrony mają być adekwatne do ryzyka, a organizacja powinna umieć wykazać, że nad bezpieczeństwem panuje. To dokładnie miejsce dla PBI. W dokumencie po pierwsze opisuje się, jakie wartości są kluczowe: poufność, integralność i dostępność. Po drugie, deklaruje się, że ocena ryzyka odbywa się według przyjętej metody, a wyniki tej oceny prowadzą do wyboru środków technicznych i organizacyjnych, takich jak kontrola dostępu, szyfrowanie, przeglądy uprawnień czy szkolenia. Jeżeli w organizacji pojawia się wysokie ryzyko dla prywatności, PBI powinna wskazywać, że wykonuje się ocenę skutków, czyli DPIA, oraz kto ją zatwierdza. Wreszcie, polityka powinna uporządkować temat relacji z dostawcami: od zawierania umów powierzenia, przez kryteria bezpieczeństwa, po zasady audytowalności.

Jak ułożyć treść PBI, żeby miała sens?

Dobra PBI zaczyna się od zakresu i celu. Czy obejmuje wszystkie lokalizacje i systemy, czy także pracę zdalną, urządzenia mobilne i chmurę? Po ustaleniu tego naturalnie przechodzi się do ról i odpowiedzialności. Zarząd powinien nie tylko zatwierdzać dokument, ale też aktywnie nadzorować wyniki. Właściciele informacji muszą wiedzieć, jakie dane podlegają ich opiece i jak je klasyfikować. Dział bezpieczeństwa lub osoba pełniąca tę rolę powinna opisywać metodę oceny ryzyka i pilnować cyklu przeglądów. Zespół IT, DevOps czy dostawcy usług zarządzanych odpowiadają za konfigurację, logowanie, kopie zapasowe i odtwarzanie. Użytkownicy z kolei powinni rozumieć zasady korzystania z informacji i narzędzi.

Kolejnym ważnym elementem jest sama klasyfikacja informacji. Jeżeli organizacja stosuje poziomy wrażliwości, w PBI warto wyjaśnić, co odróżnia je od siebie i co z tego wynika w praktyce. Inaczej traktujemy dane publiczne, inaczej wewnętrzne, a jeszcze inaczej poufne i objęte tajemnicą przedsiębiorstwa. Zaraz po klasyfikacji zwykle pojawia się rozdział o tożsamości i dostępie. Tutaj dobrze jest opisać, kiedy stosujemy SSO, kiedy MFA, jak przyznajemy i odbieramy uprawnienia oraz w jakim rytmie dokonujemy przeglądów.

W nowoczesnej organizacji nie da się uciec od chmury. PBI powinna więc porządkować zasady doboru usług i dostawców, minimalne wymagania dla szyfrowania danych, logowania zdarzeń i konfiguracji, a także reguły dotyczące lokalizacji danych oraz retencji. To miejsce na wskazanie ogólnego standardu, do którego odsyłają później szczegółowe procedury. W podobny sposób warto ująć bezpieczeństwo techniczne: jak rozumie się bezpieczną konfigurację, jak często instaluje się poprawki i na jakiej podstawie, jak loguje się zdarzenia i kto ma do nich dostęp. Osobny rozdział poświęca się zarządzaniu incydentami, tak aby każdy wiedział, co jest incydentem, jak klasyfikuje się jego wagę, w jakim czasie powinno nastąpić pierwsze działanie i jakie są zasady komunikacji. Polityka powinna też wskazywać, w jaki sposób badamy, czy incydent był naruszeniem ochrony danych osobowych i kiedy w grę wchodzi zgłoszenie do właściwego organu.

Wreszcie, kluczowe są ciągłość działania i odtwarzanie. PBI nie musi być przewodnikiem technicznym po backupach, powinna jednak wprost mówić, jaki maksymalny ubytek danych jest akceptowalny oraz w jakim czasie usługa ma wrócić do działania po awarii. Dobrą praktyką jest związanie tych założeń z regularnymi testami, które potwierdzają, że scenariusze odtwarzania są realne, a nie tylko teoretyczne. Jeśli organizacja korzysta z pracy zdalnej lub dopuszcza używanie prywatnych urządzeń, warto w polityce uporządkować również te tematy: jakie wymagania stawiamy urządzeniom, w jaki sposób rozdzielamy kontekst prywatny i służbowy oraz jak zabezpieczamy transmisję danych.

MŚP i korporacja: dwa różne tempa, ta sama logika

Mniejsza firma zwykle lepiej funkcjonuje z polityką krótszą i bardziej konkretną, w której po każdym akapicie wiadomo, kto ma zrobić kolejny krok. Szczegóły techniczne opłaca się wtedy przenieść do zwięzłych standardów i checklist, które łatwo aktualizować. Duża organizacja z kolei powinna utrzymywać PBI raczej stabilną i nadrzędną, a złożoność rozdzielać na standardy tematyczne: tożsamość, sieć, chmura, systemy przemysłowe, a do tego procedury operacyjne. Chodzi o to, aby różne działy mogły działać spójnie, ale bez dławienia lokalnej elastyczności.

Uniwersalny wzór Polityki bezpieczeństwa informacji

Biorąc pod uwagę wymogi RODO i konieczność dostosowania sposobu oraz zakresu przetwarzania danych do konkretnej instytucji, trudno o stworzenie jednego, uniwersalnego wzoru takiego dokumentu. Można natomiast wymienić w niej określone elementy:

  1. Źródła prawa – po wejściu RODO należy wśród nich wymienić m.in. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE oraz Ustawa z dnia 10 maja 2018 r. o Ochronie Danych Osobowych;
  2. Cel powstania dokumentu, tj. określenie warunków technicznych, procedur, zasad i warunków organizacyjnych, które zapewniają bezpieczeństwo przetwarzania danych;
  3. Definicje pojęć stosowanych w Polityce bezpieczeństwa;
  4. Zakres odpowiedzialności organizacji w zakresie przetwarzania danych;
  5. Opis procesu gromadzenia danych oraz dokumentowania i przechowywania zgód na przetwarzanie danych osobowych;
  6. Prawa osób, których dane dotyczą;
  7. Opis środków technicznych i organizacyjnych niezbędnych do zapewnienia poufności i integralności danych;
  8. Opis sposobu reagowania w przypadku niepożądanych zdarzeń związanych z przetwarzaniem danych;
  9. Informacja o audytach systemów IT;
  10. Załączniki;
  11. Podsumowanie zawierające charakterystykę dostosowania Polityki bezpieczeństwa informacji do potrzeb konkretnej firmy czy organizacji.

Stworzenie Polityki bezpieczeństwa informacji, choć nieobowiązkowe w świetle aktualnych przepisów, będzie solidnym dowodem na to, iż przedsiębiorstwo dba o bezpieczeństwo danych w razie kontroli z Urzędu Ochrony Danych Osobowych.

Zobacz: Audyt informatyczny dla firm – oferta

Jak PBI łączy się z codziennością?

Najlepiej wyobrazić sobie prostą piramidę dokumentów. Na samym szczycie jest PBI, która wyznacza zasady i granice. Niżej znajdują się standardy, czyli jednolite wymagania dla danych obszarów, na przykład logowania i retencji albo zarządzania tożsamością. Jeszcze niżej są procedury i instrukcje, które mówią krok po kroku, jak coś zrobić: jak dodać użytkownika do systemu, jak przeprowadzić przegląd uprawnień, jak zareagować na podejrzenie incydentu. Podstawą piramidy są zapisy i metryki, dzięki którym wiemy, że wszystko naprawdę działa: dzienniki, raporty, wyniki testów, potwierdzenia szkoleń. Taka konstrukcja pomaga audytorom, ale również każdemu nowemu pracownikowi odnaleźć się w firmowej praktyce.

Chmura i dostawcy bez tajemnic

W świecie, w którym większość narzędzi staje się usługą, ważne jest kilka zasad, które polityka powinna wypowiedzieć wprost. Po pierwsze, tożsamość użytkownika i dostęp do zasobów powinny być spójne we wszystkich systemach, najlepiej z wykorzystaniem logowania jednokrotnego i silnego uwierzytelniania. Po drugie, dane powinny być chronione zarówno w spoczynku, jak i w tranzycie, zgodnie z jasnymi regułami retencji. Po trzecie, należy rejestrować zdarzenia w sposób, który pozwala zrozumieć, co wydarzyło się w przypadku incydentu, i który nie zamienia codzienności w zalew nieprzydatnych logów. Po czwarte, konfiguracja środowisk powinna mieć swój standard, a zmiany wprowadza się kontrolowanie, najlepiej automatyzując to, co się da. I wreszcie, współpraca z dostawcami musi zaczynać się od sensownych pytań o bezpieczeństwo i kończyć na możliwości wyjścia z usługi z zachowaniem integralności danych i ciągłości działania.

Polityka, która nie żyje, szybko traci sens…

Dlatego powinna mieć właściciela, kalendarz przeglądów oraz prosty zestaw miar, które pokazują, czy idziemy w dobrym kierunku. Organizacje często zaczynają od końca, czyli od narzędzi, a zapominają o mapie aktywów i procesów — bez niej trudno zrozumieć, co tak naprawdę trzeba chronić. Równie częstym problemem jest rozjazd między zapisem a praktyką: jeśli korzystamy z chmury, w polityce musi to być widoczne; jeżeli używamy pracy zdalnej, nie może to być jedynie wzmianka. I wreszcie, nawet najlepsza procedura incydentowa zawiedzie, jeśli nigdy nie była ćwiczona. Warto raz na jakiś czas przejść przez scenariusz „na sucho”, żeby sprawdzić, czy łańcuch komunikacji i odpowiedzialności rzeczywiście działa.

Jak mierzyć bezpieczeństwo z sensem?

Nie chodzi o to, aby mierzyć wszystko, tylko to, co mówi prawdę o stanie bezpieczeństwa. Organizacje najczęściej zaczynają od czasu wykrycia i czasu reakcji na incydent, regularności przeglądów uprawnień, odsetka systemów z aktualnymi poprawkami oraz skuteczności kopii zapasowych mierzonych realnymi testami odtwarzania. Do tego dochodzą szkolenia i testy socjotechniczne, które pokazują, czy świadomość użytkowników idzie w parze z techniką. Najważniejsze jest, aby wskaźniki były powtarzalne, zrozumiałe i naprawdę omawiane podczas przeglądów kierownictwa.

Dwa krótkie obrazy z życia

Wyobraźmy sobie średniej wielkości firmę, która właśnie decyduje się na nową usługę w modelu SaaS. PBI wskazuje, że przed wdrożeniem trzeba ocenić ryzyko i sprawdzić dostawcę. Właściciel informacji opisuje rodzaje danych, które trafią do systemu, a zespół techniczny ustala, czy możliwe jest logowanie jednokrotne i wieloskładnikowe uwierzytelnianie. Sprawdza się też, jak dostawca realizuje szyfrowanie, jakie prowadzi logi i gdzie przechowuje dane. Umowa precyzuje, czy może korzystać z podwykonawców, jak wygląda wsparcie w przypadku incydentu i w jaki sposób odzyskamy dane, jeśli kiedyś zdecydujemy się na zmianę usługodawcy. Dopiero kiedy wszystkie minimalne wymagania są spełnione, usługa trafia na produkcję.
Drugi obraz dotyczy incydentu phishingowego zakończonego przejęciem skrzynki. Dzięki PBI wiadomo, że użytkownik zgłasza podejrzenie przez jeden kanał, a zespół odpowiedzialny za bezpieczeństwo blokuje logowanie i wymusza zmianę hasła oraz unieważnienie aktywnych sesji. Następnie sprawdza się, czy doszło do naruszenia danych osobowych i czy należy powiadomić organ nadzorczy. Najważniejsze, że wszystko odbywa się według znanego scenariusza, a po zdarzeniu powstaje zwięzły raport z wnioskami, które trafiają na przegląd kierownictwa i przekładają się na konkretne poprawki w systemach lub szkoleniach.

Jak utrzymywać PBI w formie przez cały rok?

Najlepiej sprawdza się spokojny, rytmiczny cykl. Raz w roku przeglądasz, czy zakres dokumentu ciągle odpowiada rzeczywistości, a w międzyczasie każda istotna zmiana — nowa usługa, znaczący incydent, wejście w życie nowych wymagań — staje się impulsem do szybkiej korekty. To dobry moment, żeby ocenić, czy rejestr aktywów i klasyfikacja danych są kompletne, czy przeglądy uprawnień odbywają się w terminie, czy testy odtwarzania potwierdzają założone RPO i RTO, a logi rzeczywiście pomagają rozumieć incydenty. Warto spojrzeć także na współpracę z dostawcami: czy umowy pokrywają minimum bezpieczeństwa i czy wiemy, jak wycofać się z usługi, nie nadrywając ciągłości działania. I wreszcie, czy mierzymy to, co ma sens, i czy wyniki naprawdę omawiane są z kierownictwem, a nie tylko odkładane do szuflady.

Od czego zacząć w najbliższym miesiącu?

Jeżeli dopiero budujesz PBI, dobrym pierwszym krokiem jest spisanie najważniejszych aktywów i danych, a następnie doprecyzowanie ról i odpowiedzialności. Na tej podstawie łatwo zarysować szkic polityki i wybrać kilka podstawowych miar. Potem przychodzi czas na krótkie, praktyczne standardy dla tożsamości, logowania i kopii zapasowych. Na koniec warto wykonać choćby mini-ćwiczenie: przywrócić plik z kopii, sprawdzić reset konta czy przejść procedurę zgłoszenia incydentu. Taki cykl kończy się przeglądem u kierownictwa i publikacją dokumentu w organizacji.

Na koniec: o wiarygodności i aktualności

Dobra PBI to nie tylko treść, ale też kontekst. Nota o autorze lub zespole i ich doświadczeniu buduje zaufanie, podobnie jak krótka sekcja „ostatnia aktualizacja” z podaniem miesiąca i roku. Warto również wskazać kilka rzetelnych źródeł do dalszej lektury, tak aby osoby zainteresowane mogły łatwo pogłębić temat. Taki komplet pomaga nie tylko w audytach i rozmowach z kontrahentami, ale też w świecie wyszukiwarek — również tych opartych na sztucznej inteligencji — które coraz lepiej rozumieją uporządkowaną, opisową, a jednocześnie praktyczną treść.
Jeśli chcesz, mogę przygotować tę wersję w formacie gotowym do wklejenia do WordPressa, wraz z metadanymi, nagłówkami i krótkimi blokami „rozwiń” dla najważniejszych sekcji, aby tekst był przyjazny zarówno czytelnikom, jak i algorytmom.

FAQ – PBI w pytaniach i odpowiedziach

Czy PBI jest obowiązkowa?

Nie zawsze wprost z przepisów, ale to najprostszy sposób, by wykazać należytą staranność i zgodność z RODO/NIS2.

Czym PBI różni się od ISMS?

PBI to dokument z zasadami. ISMS to system, który te zasady wdraża, mierzy i doskonali.

Jak często aktualizować PBI?

Co najmniej raz w roku oraz po każdej istotnej zmianie: nowa usługa, incydent, zmiana prawa lub architektury.

Kto odpowiada za PBI?

Zarząd zatwierdza i nadzoruje, właściciele informacji i bezpieczeństwo utrzymują, wszyscy pracownicy stosują.

Jak długa powinna być PBI?

Tyle, ile potrzeba, by była zrozumiała i wykonalna. W MŚP często 8–15 stron, w korporacji krócej, ale z odwołaniami do standardów.

Czy PBI musi zawierać rozdział o chmurze?

Tak, jeśli korzystasz z SaaS/IaaS/PaaS. Opisz wymagania dot. tożsamości, szyfrowania, logowania i exit planu.

Co zmieniło ISO/IEC 27001:2022 dla PBI?

Wzmocniło wątki chmury, łańcucha dostaw, DLP, logowania i gotowości na incydenty. PBI powinna to odzwierciedlać.

Jak PBI wspiera zgodność z RODO?

Porządkuje środki techniczne i organizacyjne, role, ocenę ryzyka oraz zasady współpracy z podmiotami przetwarzającymi.

Czy muszę wykonywać DPIA?

Tak, gdy ryzyko dla prywatności jest wysokie. PBI powinna wskazywać kiedy i kto zatwierdza DPIA.

Jak PBI ma się do NIS2?

Wyznacza odpowiedzialność kierownictwa, zasady zarządzania incydentami i łańcuchem dostaw oraz podstawy ciągłości działania.

Jak klasyfikować informacje?

Ustal poziomy wrażliwości i proste kryteria. PBI opisuje zasady, a szczegóły trafiają do standardów/procedur.

Czy MFA/SSO powinny być w PBI?

Tak, jako zasady. Techniczne szczegóły konfiguracji i wyjątków trzymaj w standardach.

Jak reagować na incydenty?

Jednym kanałem zgłoszeń, z jasną klasyfikacją, czasami reakcji i odpowiedzialnościami. PBI wskazuje ramy, procedura opisuje kroki.

Jakie KPI mają sens?

Czas wykrycia i reakcji, terminowość łatek i przeglądów uprawnień, skuteczność backupów, wyniki szkoleń i testów phishingowych.

Co z backupem, RPO i RTO?

PBI definiuje cele (ile danych możemy stracić i w jakim czasie wracamy do działania). Testy potwierdzają realność tych celów.

Czy BYOD i praca zdalna wymagają zapisu w PBI?

Tak. Opisz wymagania dla urządzeń, rozdzielenie danych służbowych i prywatnych oraz zasady dostępu.

Jak włączać dostawców i podwykonawców?

Przez due diligence i wymagania umowne: bezpieczeństwo, lokalizacja danych, logowanie, testy, prawo do audytu i plan wyjścia.

Czy potrzebuję rejestru aktywów?

Tak. Bez niego nie wiadomo, co chronić i jak mierzyć postęp.

Jak uniknąć „martwej” polityki?

Nadaj właściciela, ustal cykl przeglądów, mierz kilka sensownych wskaźników i ćwicz procedury.

Ile to kosztuje i jak długo trwa?

Zależy od skali i dojrzałości. Najszybciej działa podejście iteracyjne: krótka PBI + minimum standardów, potem regularne ulepszenia.

Czy potrzebny jest Statement of Applicability (SoA)?

Tak, jeśli wdrażasz ISO 27001. SoA dokumentuje, które kontrole stosujesz i dlaczego.

Czy PBI powinna mieć „ostatnią aktualizację”?

Tak. Data aktualizacji zwiększa wiarygodność i pomaga w audytach oraz SEO/AI.

Czy mała firma naprawdę potrzebuje PBI?

Tak—zwięzłej i praktycznej. To kompas decyzji oraz punkt odniesienia przy insourcowaniu i outsourcowaniu usług.


Bibliografia:

  • Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych http://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20041001024
  • „Polityka bezpieczeństwa danych osobowych” Zespół LexDigital https://lexdigital.pl/polityka-bezpieczenstwa-danych-osobowych-rodo
  • „Polityka bezpieczeństwa informacji instytucji na przykładzie Instytutu Łączności – Państwowego Instytutu Badawczego”  Ołtarzewska A., Kowalewski M.
  • „Bezpieczeństwo systemów informatycznych zarządzania” Warszawa, BELLONA, 2003, Barczak A., Sydoruk T
  • „Podstawy bezpieczeństwa systemów teleinformatycznych” Gliwice, Wydawnictwo: Pracownia komputerowa Jacka Skalmierskiego, 2002, Białas A
  • „Bezpieczeństwo sieci. Biblia” Warszawa, Helion, 2005, Cole E., Krutz R. L., Conley J.
  • „Tworzenie bezpiecznych sieci” Warszawa, Mikom, 2000, Kaeo M.
  • „Polityka bezpieczeństwa i ochrony informacji” Gliwice, Helion, 1999, Kifner T.
  • „Aspekty bezpieczeństwa systemów teleinformatycznych” Warszawa, Instytut Łączności, 2005, Kowalewski M. i in.
  • „Elementarz bezpieczeństwa systemów informatycznych” Warszawa, Mikom, 2002, Molski M., Opala S.
  • „Bezpieczeństwo danych w systemach informatycznych” Warszawa-Poznań, PWN, 2001, Stokłosa J., Bilski T., Dankowski T.
  • „Podstawy bezpieczeństwa sieci” Warszawa, Mikom, 2005, Strebe M.