Dział prawny prowadzi listę wymogów NIS2. Zespół bezpieczeństwa utrzymuje rejestr ryzyk, a dział IT katalog polityk i procedur. Każda tabela jest kompletna i aktualna. Kiedy zarząd pyta, które zabezpieczenia spełniają obowiązki z dyrektywy i jakie ryzyko mimo nich zostaje, odpowiedź wymaga ręcznego zestawiania trzech arkuszy, z których żaden nie odwołuje się do pozostałych.
Odpowiedź na ten problem ma w branży nazwę: GRC, czyli governance, risk and compliance. W cyberbezpieczeństwie oznacza połączenie ładu, ryzyka i zgodności w jeden proces decyzyjny, a nie zakup kolejnego narzędzia. Taki proces opiera się na wspólnym rejestrze wymagań, ryzyk i zabezpieczeń, w którym każda decyzja ma właściciela.
Co to jest GRC w cyberbezpieczeństwie?
GRC (governance, risk and compliance, po polsku ład, ryzyko i zgodność) to zestaw zdolności, które pozwalają organizacji osiągać cele, radzić sobie z niepewnością i działać uczciwie. Tak definiuje GRC OCEG (Open Compliance and Ethics Group): „integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty, and act with integrity”.
W cyberbezpieczeństwie definicję łatwo przełożyć na praktykę. Cele to ciągłość usług i ochrona danych, niepewność to ryzyko incydentu, a uczciwe działanie to przestrzeganie przepisów i zobowiązań wobec klientów. GRC łączy te trzy perspektywy tak, żeby jedna decyzja o zabezpieczeniu odpowiadała jednocześnie na pytanie o ryzyko i o wymóg.
OCEG zastrzega przy tym wprost: „GRC is not a technology. GRC is not a department”. GRC opisuje ludzi, procesy, technologię i informacje, które razem prowadzą do celu. Firma może więc kupić platformę z „GRC” w nazwie i nadal nie mieć GRC, a może też mieć dobrze działający proces w arkuszu kalkulacyjnym.
Czym różnią się ład, ryzyko i zgodność?
Ład odpowiada na pytanie, kto decyduje i kto odpowiada za skutki, ryzyko na pytanie, co może przeszkodzić w osiągnięciu celów, a zgodność na pytanie, czego firma musi przestrzegać i co potrafi udowodnić. Każdy z tych obszarów ma własne narzędzia i własnych specjalistów, dlatego tak łatwo je rozdzielić.
Ład to struktura decyzji: kto zatwierdza strategię bezpieczeństwa, kto przyjmuje ryzyko, kto przydziela budżet i jak zarząd dowiaduje się, czy plan działa. Zarządzanie ryzykiem to systematyczna identyfikacja, analiza, ocena i kontrola zagrożeń. Compliance to zapewnienie, że organizacja przestrzega przepisów prawa, regulacji branżowych, standardów i wewnętrznych polityk.
Różnicę dobrze widać na przykładzie kopii zapasowych. Z perspektywy zgodności liczy się, czy procedura istnieje i czy spełnia wymóg ciągłości działania. Z perspektywy ryzyka — czy kopie pozwolą odtworzyć system w czasie, który firma uznaje za akceptowalny. Z perspektywy ładu — kto podpisał ten akceptowalny czas i kto sprawdza, czy test odtworzenia się odbył.
Dlaczego osobne procesy ładu, ryzyka i zgodności zawodzą?
Osobne procesy zawodzą zwykle z jednego powodu: każdy optymalizuje własną miarę. Zgodność liczy spełnione wymogi, zarządzanie ryzykiem ocenia zagrożenia, a ład rozlicza budżet, i żadna z tych miar nie pokazuje, czy firma jest bezpieczna. Skutki widać w trzech miejscach.
Pierwsze to zdublowana praca. Ta sama kontrola dostępu bywa opisywana osobno pod NIS2, pod ISO 27001 i pod wymagania klienta, a każdy opis ma innego autora i inną datę przeglądu. Drugie to sprzeczne priorytety. Lista zgodności każe zamknąć brak formalny, rejestr ryzyk wskazuje poważniejszą lukę techniczną, a budżet wystarcza na jedno z nich, choć nikt nie ma mandatu, żeby wybrać.
Trzecie to rozproszone dowody. Kiedy audytor albo organ nadzoru prosi o wykazanie, że zabezpieczenie działa, firma szuka zrzutów ekranu w skrzynkach kilku osób. Tymczasem RODO w art. 24 wymaga od administratora nie tylko wdrożenia środków, ale też możliwości wykazania zgodności, a NIS2 w art. 21 ust. 2 lit. f — polityk i procedur oceny skuteczności środków zarządzania ryzykiem (stan na 15 listopada 2026 r.).
Jak NIST CSF 2.0 opisuje ład w cyberbezpieczeństwie?
NIST Cybersecurity Framework 2.0 z 26 lutego 2024 r. opisuje ład jako osobną funkcję GOVERN, w której strategia zarządzania ryzykiem cyberbezpieczeństwa, oczekiwania i polityka są ustalane, komunikowane i monitorowane. Obok niej framework wymienia pięć pozostałych funkcji: identyfikację, ochronę, wykrywanie, reagowanie i odtwarzanie.
Dokument wprost łączy ład z ryzykiem korporacyjnym. Według NIST działania w ramach GOVERN są kluczowe dla włączenia cyberbezpieczeństwa do szerszej strategii zarządzania ryzykiem korporacyjnym (ERM). Funkcja obejmuje kontekst organizacji, strategię zarządzania ryzykiem, role i odpowiedzialności, politykę, nadzór oraz zarządzanie ryzykiem łańcucha dostaw.
Trzy rezultaty z tej funkcji dobrze pokazują, czym w praktyce jest GRC. GV.OC-03 wymaga, żeby wymogi prawne, regulacyjne i umowne dotyczące cyberbezpieczeństwa były rozumiane i zarządzane. GV.RM-03 włącza działania zarządzania ryzykiem cyberbezpieczeństwa do procesów zarządzania ryzykiem korporacyjnym. GV.RR-01 wskazuje, że kierownictwo odpowiada i rozlicza się za ryzyko cyberbezpieczeństwa.
CSF nie narzuca, jak te rezultaty osiągnąć, i nie jest przepisem. Daje jednak wspólny język, którym zespół bezpieczeństwa, dział zgodności i zarząd mogą opisać ten sam proces.
Czego od zarządu wymagają NIS2, ustawa o KSC i DORA?
Wszystkie trzy akty przypisują odpowiedzialność za zarządzanie ryzykiem w cyberbezpieczeństwie najwyższemu kierownictwu, a nie działowi IT (stan na 15 listopada 2026 r.). Zarząd, który odpowiada osobiście, potrzebuje jednego obrazu, a nie trzech niepowiązanych arkuszy.
Dyrektywa NIS2 w art. 20 ust. 1 wymaga, by organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem w cyberbezpieczeństwie, nadzorowały ich wdrażanie i mogły odpowiadać za naruszenia art. 21. Art. 20 ust. 2 zobowiązuje członków tych organów do regularnych szkoleń, które pozwolą im rozpoznać ryzyko i ocenić praktyki zarządzania nim.
W Polsce NIS2 wdraża ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252), obowiązująca od 3 kwietnia 2026 r. Dodany nią art. 8c stanowi, że kierownik podmiotu kluczowego lub ważnego ponosi odpowiedzialność za wykonywanie obowiązków w zakresie cyberbezpieczeństwa, także gdy powierzył je innej osobie za jej zgodą, a przy organie wieloosobowym bez wskazanej osoby odpowiadają wszyscy jego członkowie. Art. 8d wymienia, co kierownik robi: decyduje o systemie zarządzania bezpieczeństwem informacji, planuje środki finansowe, przydziela zadania i nadzoruje ich wykonanie, dba o świadomość personelu i zapewnia zgodność z przepisami. Art. 8e nakłada na niego coroczne, udokumentowane szkolenie.
Rozporządzenie DORA w art. 5 ust. 2 wymaga od organu zarządzającego podmiotu finansowego, by określał, zatwierdzał i nadzorował ramy zarządzania ryzykiem związanym z ICT, i przypisuje mu ostateczną odpowiedzialność za to ryzyko. Wspólny mianownik jest prosty: decyzja o ryzyku ma właściciela na poziomie zarządu.
Najważniejsze:
- NIS2 (art. 20), ustawa o KSC (art. 8c–8e) i DORA (art. 5 ust. 2) przypisują odpowiedzialność kierownictwu.
- Powierzenie zadań innej osobie nie zdejmuje odpowiedzialności z kierownika podmiotu (art. 8c ust. 3 ustawy o KSC).
- Zarząd potrzebuje wspólnego raportu o wymogach, ryzykach i zabezpieczeniach, a nie trzech osobnych.
Jak ryzyko łączy ład ze zgodnością?
Ryzyko łączy ład ze zgodnością, bo to decyzja o ryzyku przekłada ogólny wymóg na konkretne zabezpieczenie. Przepisy rzadko mówią, jakie narzędzie wdrożyć. W brzmieniu obowiązującym 15 listopada 2026 r. ustawa o KSC w art. 8 ust. 1 wymaga systemu zarządzania bezpieczeństwem informacji, który zapewnia systematyczne szacowanie ryzyka i środki proporcjonalne do oszacowanego ryzyka.
Wymóg mówi więc „odpowiednio do ryzyka”, a dopiero ocena ryzyka mówi, co to znaczy w danej firmie. Ład wskazuje, kto tę ocenę zatwierdza i kto podpisuje się pod ryzykiem, które zostaje. Bez tego ogniwa lista zgodności zamienia się w listę zakupów, a rejestr ryzyk w dokument, którego nikt nie czyta.
Sama decyzja o postępowaniu z ryzykiem, czyli wybór między akceptacją, unikaniem, ograniczeniem a przeniesieniem, to temat artykułu o tym, na czym polega mitygacja ryzyka. Z perspektywy GRC ważne jest, żeby każda taka decyzja była zapisana obok wymogu, którego dotyczy.
Jak zbudować jeden rejestr wymagań, ryzyk i zabezpieczeń?
Jeden rejestr buduje się od mapowania czterech elementów w jednym wierszu: wymóg, ryzyko, zabezpieczenie i dowód jego działania. Taki układ pozwala jednym spojrzeniem odpowiedzieć zarówno audytorowi, jak i zarządowi.
Pierwszy krok to lista wymogów, które firmę obowiązują: przepisy, normy, którym się podporządkowała, i umowy z klientami. Drugi to przypisanie do każdego wymogu ryzyk, których dotyczy. Trzeci to wskazanie zabezpieczeń, które te ryzyka ograniczają, i właścicieli tych zabezpieczeń. Czwarty to dowód: wynik testu, raport, zapis przeglądu z datą.
Największa korzyść pojawia się przy zabezpieczeniach, które spełniają wiele wymogów naraz. Uwierzytelnianie wieloskładnikowe, postępowanie z podatnościami i kopie zapasowe NIS2 wymienia wprost w art. 21 ust. 2 (lit. j, e i c), a te same zabezpieczenia mogą jednocześnie spełniać wymagania RODO i umów z klientami. Opisane raz, z jednym właścicielem i jednym dowodem, przestają generować trzy osobne zadania.
Rejestr nie musi być idealny od pierwszego dnia. Lepiej zacząć od wymogów jednej regulacji i najważniejszych ryzyk, a potem dopisywać kolejne źródła wymogów do istniejących zabezpieczeń, niż budować pełną mapę, która nigdy nie zostanie skończona.
Kto odpowiada za GRC w organizacji?
Za GRC odpowiada kierownictwo, zgodnie z przepisami opisanymi w sekcji o wymaganiach wobec zarządu (w NIST CSF 2.0 to rezultat GV.RR-01), a pozostałe role wykonują i sprawdzają decyzje, które ono zatwierdza.
W praktyce role układają się w kilka grup. Zarząd zatwierdza strategię, akceptuje ryzyko wysokie i przydziela zasoby. Właściciele ryzyk po stronie biznesu decydują o postępowaniu z ryzykiem w swoich procesach. Zespół bezpieczeństwa projektuje i utrzymuje zabezpieczenia. Dział zgodności śledzi wymogi i zbiera dowody, a audyt wewnętrzny niezależnie sprawdza, czy całość działa.
Same role nie wystarczą, bo ktoś musi je spinać. Zwykle robi to CISO albo osoba pełniąca tę funkcję zewnętrznie: pilnuje, żeby rejestr był wspólny, przeglądy odbywały się w terminie, a zarząd dostawał raport, z którego da się podjąć decyzję.
Czy do GRC potrzebna jest platforma?
Platforma nie jest warunkiem GRC, bo podstawą jest proces z właścicielami decyzji, a nie narzędzie. Narzędzie staje się potrzebne dopiero wtedy, gdy arkusz przestaje nadążać za liczbą powiązań.
Sygnały, że ten moment nadszedł, są dość wyraźne. Jedno zabezpieczenie trzeba przypisać do kilkunastu wymogów z różnych źródeł. Dowody zbiera kilka zespołów i giną między wersjami plików. Firma ma kilka spółek albo lokalizacji z różnymi obowiązkami. Raport dla zarządu wymaga każdorazowo ręcznego składania danych.
Kolejność ma jednak znaczenie. Najpierw ustala się, kto decyduje, jak wygląda przegląd ryzyka i jakie dowody są wymagane, a dopiero potem wybiera narzędzie, które ten proces odwzoruje. Platforma wdrożona przed ustaleniem procesu utrwala bałagan w droższej formie.
Jak ocenić dojrzałość procesu GRC?
Dojrzałość procesu GRC ocenia się, sprawdzając, czy w każdym obszarze decyzje, ryzyka i wymogi są ze sobą powiązane i czy istnieje na to dowód. Poniższa tabela pomaga znaleźć miejsca, w których ład, ryzyko i zgodność wciąż działają osobno.
| Obszar | Objaw rozłączenia | Stan docelowy | Dowód dla audytora | Pierwszy krok |
|---|---|---|---|---|
| Odpowiedzialność | nikt nie podpisuje decyzji o ryzyku | wskazany kierownik i właściciele ryzyk | uchwała lub decyzja o podziale ról | przypisanie właściciela do każdego ryzyka wysokiego |
| Wymogi | lista wymogów żyje w dziale prawnym | jedna lista przepisów, norm i umów | rejestr wymogów z datą przeglądu | spisanie wymogów jednej regulacji |
| Ryzyko | rejestr ryzyk bez odwołań do wymogów | każde ryzyko powiązane z wymogiem i zabezpieczeniem | rejestr z kolumną wymogów | dopisanie kolumny wymogów do rejestru |
| Zabezpieczenia | ta sama kontrola opisana kilka razy | jedno zabezpieczenie, wiele wymogów | mapa zabezpieczeń do wymogów | wybór pięciu zabezpieczeń wspólnych dla regulacji |
| Dowody | zrzuty ekranu w skrzynkach | dowody przy zabezpieczeniu, z datą | repozytorium dowodów | ustalenie, jaki dowód potwierdza każde zabezpieczenie |
| Szkolenia zarządu | jednorazowa prezentacja | coroczne, udokumentowane szkolenie | lista obecności i program | zaplanowanie szkolenia w kalendarzu zarządu |
| Raportowanie | trzy raporty dla zarządu | jeden obraz wymogów, ryzyk i zabezpieczeń | protokoły posiedzeń z decyzjami | wspólny szablon raportu kwartalnego |
Tabela nie mierzy poziomu bezpieczeństwa, tylko spójność procesu. Firma z wieloma zabezpieczeniami może wypaść w niej słabo, jeśli nie potrafi wskazać, kto i dlaczego je wybrał.
Jak nFlo może pomóc w obszarze „Ład, ryzyko i zgodność”?
W obszarze „Ład, ryzyko i zgodność” nFlo pomaga połączyć ocenę ryzyka z decyzjami zarządu. Usługa przeglądy, audyty i doradztwo w obszarze analizy ryzyka kończy się rejestrem ryzyk z oceną prawdopodobieństwa i wpływu finansowego, planem postępowania z ryzykiem z analizą kosztów i korzyści oraz raportem dla zarządu.
Dla organizacji, które chcą uporządkować zarządzanie ryzykiem w całej firmie, nFlo prowadzi projekty zgodne z ISO 31000: od oceny dojrzałości i określenia apetytu na ryzyko, przez metodykę i role, po rejestr ryzyk korporacyjnych i wskaźniki dla zarządu. Jeśli chcesz sprawdzić, jak spójne są ład, ryzyko i zgodność w Twojej organizacji, skontaktuj się z nami.
Co jeszcze warto wiedzieć o GRC?
Czy GRC to to samo co compliance?
Nie. Compliance, czyli zgodność, to jeden z trzech elementów GRC. Ład określa, kto podejmuje decyzje i odpowiada za ich skutki, a zarządzanie ryzykiem wskazuje, co może przeszkodzić w osiągnięciu celów. GRC łączy te trzy obszary w jeden proces decyzyjny.
Czy GRC wymaga zakupu platformy?
Nie. Narzędzie ułatwia mapowanie wymogów, ryzyk i zabezpieczeń, gdy jest ich dużo, ale nie zastąpi decyzji o tym, kto odpowiada za ryzyko i jak wygląda proces.
Kto w firmie odpowiada za GRC?
Ostateczną odpowiedzialność ponosi kierownictwo. W podmiotach objętych NIS2 art. 20 dyrektywy nakłada na organy zarządzające obowiązek zatwierdzania środków zarządzania ryzykiem i nadzoru nad nimi, a w Polsce art. 8c ustawy o krajowym systemie cyberbezpieczeństwa wskazuje odpowiedzialność kierownika podmiotu.
Czym GRC różni się od zarządzania ryzykiem korporacyjnym?
Zarządzanie ryzykiem korporacyjnym obejmuje wszystkie rodzaje ryzyka firmy, a GRC w cyberbezpieczeństwie łączy ryzyko z ładem i zgodnością. NIST CSF 2.0 zaleca włączanie działań zarządzania ryzykiem cyberbezpieczeństwa do procesów zarządzania ryzykiem korporacyjnym.
Od czego zacząć porządkowanie GRC?
Od wskazania osoby, która podpisuje decyzje o ryzyku, i od jednej listy wymogów, które firmę obowiązują. Dopiero do tej listy warto przypisywać ryzyka, zabezpieczenia i dowody ich działania.
