Rejestr ryzyka ISO 27001: struktura i przykładowe wpisy
Rejestr ryzyka ISO 27001 to udokumentowany wynik procesu szacowania ryzyka wymaganego przez punkt 6.1.2: ryzyka dla poufności, integralności i dostępności informacji w zakresie Twojego SZBI, każde z imiennie wskazanym właścicielem ryzyka, przeanalizowanym skutkiem i prawdopodobieństwem oraz oceną wobec Twoich własnych kryteriów ryzyka. Liczą się te kolumny, które wynikają z normy: opis ryzyka powiązany z aktywem i zagrożeniem, właściciel, skutek, prawdopodobieństwo, wynikowy poziom ryzyka, opcja postępowania, wybrane zabezpieczenia oraz ryzyko szczątkowe zaakceptowane przez właściciela. Dziesięć konkretnych wpisów, które naprawdę przeglądasz, bije sto ogólnikowych wierszy z pobranego szablonu.
Rejestr ryzyka ISO 27001 to udokumentowany wynik procesu szacowania ryzyka wymaganego przez punkt 6.1.2. Zapisuje ryzyka dla poufności, integralności i dostępności informacji wewnątrz zakresu Twojego SZBI – każde z imiennie wskazanym właścicielem, przeanalizowanym skutkiem i prawdopodobieństwem oraz oceną wobec kryteriów ryzyka, które zdefiniowałeś wcześniej.
Jeśli najpierw chcesz ogólną, nie-ISO wersję tego pojęcia, mamy wprowadzenie do tego, czym jest rejestr ryzyka i dlaczego korzysta na nim każda rosnąca firma. Ten artykuł jest węższy: chodzi o strukturę, która przetrwa audyt certyfikacyjny, i pięć opracowanych wpisów, które możesz zaadaptować.
Czego naprawdę wymaga punkt 6.1.2
Norma nie narzuca formatu, ale narzuca proces – a proces implikuje kolumny. Punkt 6.1.2 wymaga, żebyś zdefiniował i stosował proces szacowania ryzyka, który:
- Ustanawia i utrzymuje kryteria ryzyka, w tym kryteria akceptacji ryzyka i kryteria przeprowadzania szacowania. Zdecyduj, co znaczy „wysokie" i z czym jesteś w stanie żyć, zanim zaczniesz punktować, a nie potem.
- Daje spójne, wiarygodne i porównywalne wyniki przy powtórzeniu. Dwie osoby szacujące to samo ryzyko powinny wylądować mniej więcej w tym samym miejscu, a tegoroczne szacowanie powinno być porównywalne z zeszłorocznym.
- Identyfikuje ryzyka związane z utratą poufności, integralności i dostępności informacji w zakresie systemu.
- Identyfikuje właścicieli ryzyka – konkretne osoby, nie działy.
- Analizuje ryzyka – ocenia realistyczne skutki i prawdopodobieństwo oraz wyznacza wynikowy poziom ryzyka.
- Ocenia ryzyka – porównuje je z Twoimi kryteriami i priorytetyzuje do postępowania.
Punkt 6.1.2 wymaga też, żebyś zachował udokumentowane informacje o tym procesie. Rejestr to sposób, w jaki większość organizacji to realizuje.
Minimalny zestaw kolumn
Każda kolumna poniżej odpowiada czemuś, czego wymaga norma. Jeśli kolumna w Twoim szablonie tego nie robi, jest ozdobnikiem – a ozdobniki zamieniają rejestr w obowiązek, którego nikt nie aktualizuje.
| Kolumna | Po co istnieje |
|---|---|
| ID | Stabilny odnośnik, żeby plany postępowania i ustalenia z audytu mogły na niego wskazywać |
| Opis ryzyka | Aktywo + zagrożenie + skutek, w jednym konkretnym zdaniu |
| Aktywo lub proces, którego dotyczy | Wiąże ryzyko z Twoją inwentaryzacją aktywów |
| Wpływ na PID | Które z trzech – poufność, integralność, dostępność – jest zagrożone |
| Właściciel ryzyka | Punkt 6.1.2 c) 2 – konkretna osoba, która faktycznie może decydować |
| Skutek | Przeanalizowany wpływ, oceniony wobec Twoich kryteriów |
| Prawdopodobieństwo | Realistyczne prawdopodobieństwo, ocenione wobec Twoich kryteriów |
| Poziom ryzyka | Wynikowy poziom, oceniony wobec kryteriów akceptacji |
| Opcja postępowania | Modyfikacja, zachowanie, unikanie lub dzielenie |
| Wybrane zabezpieczenia | Zabezpieczenia, które je obsługują, z odniesieniem do Twojej SoA |
| Ryzyko szczątkowe | Poziom po postępowaniu – i czy właściciel je zaakceptował |
| Data przeglądu | Kiedy ostatnio na nie patrzono, żeby było widać, co się zestarzało |
Pięć opracowanych wpisów
Napisane dla startupu działającego w chmurze. Punktacja używa prostej skali 1–5 dla skutku i prawdopodobieństwa, a poziom ryzyka to ich iloczyn – dla małego zespołu w zupełności wystarczy. Normie zależy na tym, żeby Twoja metoda była spójna, a nie wyrafinowana.
R-01 — Odchodzący pracownik zachowuje dostęp do SaaS
Opis: Pracownik odchodzi, a dostęp do narzędzia SaaS spoza SSO nie zostaje odebrany, co pozwala mu dalej sięgać po dane klientów. Aktywo: platforma obsługi klienta. PID: poufność. Właściciel: szef operacji. Skutek 4, Prawdopodobieństwo 3, Poziom 12. Postępowanie: modyfikacja – lista kontrolna offboardingu obejmująca narzędzia spoza SSO oraz kwartalne przeglądy uprawnień użytkowników. Szczątkowe: 4, zaakceptowane.
R-02 — Awaria regionu chmurowego przekracza cel odtworzeniowy
Opis: Długotrwała awaria strefy dostępności u dostawcy hostingu wyłącza platformę na dłużej niż docelowy czas odtworzenia zapisany w umowach z klientami. Aktywo: platforma produkcyjna. PID: dostępność. Właściciel: CTO. Skutek 4, Prawdopodobieństwo 2, Poziom 8. Postępowanie: modyfikacja – wdrożenie multi-AZ, udokumentowany runbook odtworzeniowy, testowany corocznie. Szczątkowe: 4, zaakceptowane.
R-03 — Ekstremalna pogoda zakłóca pracę kluczowego dostawcy
Opis: Powódź albo obciążenie sieci energetycznej wywołane upałem w obiekcie dostawcy przerywa usługę, od której zależy platforma. Aktywo: usługa świadczona przez dostawcę. PID: dostępność. Właściciel: CTO. Skutek 3, Prawdopodobieństwo 2, Poziom 6. Postępowanie: zachowanie, z monitorowaniem – zobowiązania dostawcy dotyczące ciągłości przeglądane raz w roku. Warto ująć to wprost, bo zmiana z 2024 roku wprowadziła kwestie klimatyczne do punktów 4.1 i 4.2 – zobacz zmianę, o której nikt Ci nie powiedział. Szczątkowe: 6, zaakceptowane.
R-04 — Sekrety trafiają do repozytorium kodu
Opis: Klucze API lub dane uwierzytelniające trafiają do repozytorium i są widoczne dla każdego, kto ma do niego dostęp – albo publicznie, jeśli repozytorium kiedykolwiek zostanie otwarte. Aktywo: repozytoria kodu źródłowego. PID: poufność. Właściciel: lider zespołu inżynierskiego. Skutek 5, Prawdopodobieństwo 3, Poziom 15. Postępowanie: modyfikacja – automatyczne skanowanie sekretów w CI, zarządzany magazyn sekretów, procedura rotacji. Zobacz zabezpieczenia bezpiecznego wytwarzania oprogramowania. Szczątkowe: 5, zaakceptowane.
R-05 — Zależność od jednej osoby przy wdrożeniach produkcyjnych
Opis: Tylko jeden inżynier ma wiedzę i dostępy potrzebne do wdrożenia i odtworzenia produkcji, co tworzy ryzyko dostępności, gdy jest niedostępny. Aktywo: pipeline wdrożeniowy. PID: dostępność. Właściciel: CTO. Skutek 4, Prawdopodobieństwo 3, Poziom 12. Postępowanie: modyfikacja – udokumentowane runbooki, druga przeszkolona osoba, procedura dostępu awaryjnego. Szczątkowe: 6, zaakceptowane.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
Właściciele ryzyka to ludzie, nie działy
„IT" nie może zaakceptować ryzyka. „Inżynieria" nie może zatwierdzić planu postępowania. Punkt 6.1.2 każe Ci wskazać właścicieli ryzyka, bo punkt 6.1.3 wymaga później, żeby ci właściciele zatwierdzili plan postępowania z ryzykiem i zaakceptowali ryzyka szczątkowe – a to potrafi zrobić tylko człowiek.
W małej firmie te same dwa czy trzy nazwiska będą się powtarzać i to jest w porządku. Liczy się to, żeby wskazany właściciel miał realną władzę, by sfinansować rozwiązanie albo zaakceptować życie bez niego. Jeśli Twój rejestr wskazuje właściciela, który nie może ani jednego, ani drugiego, wpis jest ozdobnikiem.
Jak rejestr zasila SoA
Rejestr nie jest końcem łańcucha. Zgodnie z punktem 6.1.3 bierzesz ocenione ryzyka i:
- Wybierasz opcje postępowania – modyfikacja, zachowanie, unikanie lub dzielenie.
- Określasz zabezpieczenia niezbędne do wdrożenia tych opcji.
- Porównujesz określone zabezpieczenia z Załącznikiem A, żeby sprawdzić, czy nie pominąłeś żadnego niezbędnego. Załącznik A to lista kontrolna do weryfikacji, a nie lista zakupów.
- Tworzysz Deklarację Stosowania, która zapisuje, które zabezpieczenia mają zastosowanie, dlaczego i czy są wdrożone.
- Formułujesz plan postępowania z ryzykiem i uzyskujesz zatwierdzenie planu przez właścicieli ryzyka oraz ich akceptację ryzyk szczątkowych.
Audytor prześledzi ten łańcuch w obie strony. Wybierze zabezpieczenie oznaczone w Twojej SoA jako „mające zastosowanie" i zapyta, jakie ryzyko za nim stoi. Potem wybierze wysoko punktowane ryzyko z Twojego rejestru i zapyta, jakie zabezpieczenia je obsługują. Rejestr, który nie zgadza się z SoA, to jedno z bardziej nieprzyjemnych ustaleń, bo sugeruje, że oba dokumenty powstały niezależnie od siebie – a zwykle dokładnie tak było.
Antywzorce
- Pobrane sto wierszy. Ogólny szablon wypełniony ryzykami, które nie mają nic wspólnego z Twoim biznesem. Wygląda solidnie, a przegląda się fatalnie, bo nikt nie rozpoznaje w nim niczego swojego.
- Ryzyka zapisane jako kategorie. „Ryzyko cybernetyczne" to nie ryzyko. „Wyciek danych klientów przez przejęte konto administratora" – to już tak.
- Teatr punktacji. Rozbudowane wzory bez udokumentowanych kryteriów. Norma chce spójności i porównywalności, a to lepiej daje prosta, spisana skala niż niewyjaśniony algorytm.
- Brak ryzyka szczątkowego. Jeśli nigdy nie zapisujesz, co zostaje po postępowaniu, właściciel nie ma czego akceptować – a punkt 6.1.3 każe mu to zaakceptować.
- Zamrożony rejestr. Te same dwanaście wierszy, te same oceny, te same daty, rok po roku. To najczęstsze ustalenie na audytach nadzoru, bo widać je od razu.
Wniosek
Zbuduj rejestr wokół tego, czego wymaga punkt 6.1.2: konkretne ryzyka powiązane z realnymi aktywami, wskazani właściciele z realną władzą, kryteria spisane przed punktowaniem i ryzyko szczątkowe, które ktoś naprawdę zaakceptował. Potem przeglądaj go w stałym rytmie i niech ten przegląd widać po datach. Dziesięć wpisów, które faktycznie utrzymujesz, przejdzie audyt, którego sto odziedziczonych wierszy nie przejdzie.
Dalej: punkt 6 w całości, metodyki szacowania ryzyka, jeśli wciąż wybierasz podejście, albo zobacz, jak ocena ryzyka w AuditBadger sprawia, że rejestr, plan postępowania i SoA wskazują na siebie nawzajem.
