Zarządzanie ryzykiem cyberbezpieczeństwa w JSFP – praktyczny przewodnik

Zarządzanie ryzykiem cyberbezpieczeństwa w jednostce sektora finansów publicznych (JSFP) łatwo sprowadzić do arkusza zawierającego listę zagrożeń, ocenę od 1 do 5 i kolumnę „ryzyko akceptowalne”.

To za mało.

Prawidłowy proces powinien rozpoczynać się od ustalenia, jakie zadanie albo usługę realizuje jednostka, jakie procesy są do tego potrzebne, od jakich systemów, zasobów i dostawców zależą oraz jakie skutki może spowodować utrata ich bezpieczeństwa.

Dopiero później należy identyfikować scenariusze ryzyka, oceniać ryzyko bazowe, analizować skuteczność istniejących zabezpieczeń, wyznaczać ryzyko rezydualne i podejmować decyzje dotyczące dalszego postępowania.

Jednocześnie trzeba pamiętać, że ustawa o krajowym systemie cyberbezpieczeństwa (KSC) przewiduje różne modele systemu zarządzania bezpieczeństwem informacji (SZBI). Sam fakt bycia JSFP nie przesądza jeszcze, że jednostka podlega systematycznemu szacowaniu ryzyka z art. 8 ust. 1 KSC. Art. 8 ust. 1 wprost wymaga systematycznego szacowania ryzyka wystąpienia incydentu i zarządzania nim, ale art. 8 ust. 3 ustanawia odmienny model dla określonych podmiotów.

Najważniejsza zasada

Analizy ryzyka nie należy rozpoczynać od serwera, podatności czy listy cyberataków. Punktem wyjścia powinno być zadanie lub usługa, proces potrzebny do jego realizacji oraz systemy informacyjne, od których proces zależy.

Ryzyko cyberbezpieczeństwa jest ryzykiem dla działalności podmiotu, a nie wyłącznie problemem technicznym działu IT.

Najpierw ustal, jaki model SZBI stosuje jednostka

Art. 8 ust. 1 KSC wymaga od podmiotu objętego tym modelem prowadzenia systematycznego szacowania ryzyka wystąpienia incydentu i zarządzania nim. Zastosowane środki techniczne i organizacyjne mają być odpowiednie i proporcjonalne do oszacowanego ryzyka.

Nie jest to jednak model właściwy dla każdego podmiotu publicznego.

Podmiot ważny będący podmiotem publicznym nie stosuje art. 8 ust. 1 i wdraża SZBI zgodny z załącznikiem nr 4. Wskazane w art. 8 ust. 3 podmioty szkolnictwa wyższego i nauki stosują ten model w zakresie, w jakim realizują zadania publiczne z wykorzystaniem systemów informacyjnych.

Podmiot ważny publiczny – trzy konteksty prawne analizy ryzyka

W tym przypadku trzeba rozróżnić trzy zagadnienia.

Po pierwsze – art. 8 ust. 1. Podmiot ważny będący podmiotem publicznym, stosujący art. 8 ust. 3 i załącznik nr 4, nie ma w ramach obowiązku wdrożenia SZBI formalnego obowiązku prowadzenia systematycznego szacowania ryzyka z art. 8 ust. 1 pkt 1. Potwierdza to bezpośrednio pkt 3.15 Q&A Ministerstwa Cyfryzacji.

Po drugie – załącznik nr 4. Brak obowiązku z art. 8 ust. 1 nie oznacza zakazu prowadzenia analizy ryzyka. Załącznik pozwala stosować dodatkowe środki techniczne i organizacyjne, gdy jest to konieczne do zapewnienia odpowiedniego poziomu bezpieczeństwa, a także przewiduje zdarzeniowy przegląd SZBI w przypadku okoliczności mogących wpłynąć na ryzyko incydentu poważnego.

Po trzecie – art. 10 KSC. Niezależnie od powyższego dokumentacja ochrony infrastruktury obejmuje wprost szacowanie ryzyka dla obiektów infrastruktury oraz plan postępowania z ryzykiem. Jest to odrębny obowiązek dokumentacyjny i nie należy go utożsamiać z ogólną analizą ryzyka prowadzoną w SZBI.

Brak obowiązku z art. 8 ust. 1 nie wyłącza również wymagań dotyczących ryzyka wynikających z innych regulacji, np. RODO czy przepisów sektorowych. Także Q&A Ministerstwa wskazuje art. 32 RODO jako przykład odrębnej podstawy wymagającej podejścia opartego na ryzyku.

W praktyce

Dla podmiotu ważnego publicznego nie należy tworzyć fikcji, że pełna analiza ryzyka z art. 8 ust. 1 jest obowiązkowa. Jednocześnie całkowite pominięcie ryzyka również byłoby błędne – pozostają art. 10 KSC, wymagania załącznika nr 4, RODO oraz ewentualne regulacje sektorowe.

Sprawdź regulacje szczególne

Przed przyjęciem metodyki trzeba sprawdzić, czy do konkretnego podmiotu nie mają zastosowania dodatkowe wymagania.

Mogą to być w szczególności:

• rozporządzenia wydane na podstawie art. 8a;
• szczególne zasady wynikające z art. 8b;
• szczególna relacja KSC–DORA określona w art. 8i;
• właściwe, bezpośrednio stosowane akty prawa UE;
• inne wymagania sektorowe.

Art. 8a sam nie tworzy odrębnego modelu zarządzania ryzykiem – stanowi podstawę do określenia szczegółowych wymagań dotyczących SZBI dla wskazanych kategorii podmiotów.

Jak powinien przebiegać proces?

Praktyczny ciąg można przedstawić następująco:

zadanie lub usługa → proces → system i zasoby → zależności → scenariusz ryzyka → ryzyko bazowe → zabezpieczenia → ryzyko rezydualne → decyzja → plan działań wobec ryzyk → weryfikacja

Dzięki temu rejestr ryzyka pozostaje powiązany z rzeczywistą działalnością jednostki, a nie staje się listą ogólnych haseł typu „phishing”, „ransomware” i „awaria serwera”.

Krok 1. Zidentyfikuj zadania, usługi i procesy

Najpierw trzeba ustalić, jakie zadania albo usługi są objęte zakresem KSC i od jakich procesów zależy ich wykonanie.

Przykładem może być elektroniczna obsługa wniosków:

W modelu z art. 8 ust. 1 SZBI dotyczy systemu informacyjnego wykorzystywanego w procesach wpływających na świadczenie usługi. Dlatego punktem wyjścia powinien być proces i jego zależności.

Krok 2. Zidentyfikuj systemy, zasoby i zależności

Dla procesu trzeba ustalić, od czego faktycznie zależy jego realizacja.

Należy uwzględnić między innymi:

• aplikacje;
• bazy danych;
• infrastrukturę sieciową;
• urządzenia użytkowników;
• konta uprzywilejowane;
• usługi chmurowe;
• systemy dostarczane przez inne podmioty publiczne;
• dostawców utrzymaniowych;
• operatorów telekomunikacyjnych;
• usługi uwierzytelniania;
• infrastrukturę kopii zapasowych.

Praktycznym rezultatem jest mapa:

proces → system → zasób → dostawca → właściciel

W modelu art. 8 ust. 1 również bezpieczeństwo łańcucha dostaw należy do obszarów uwzględnianych w SZBI.

Krok 3. Określ kryteria wpływu

Bez jednoznacznych kryteriów dwie osoby mogą zupełnie inaczej ocenić ten sam scenariusz.

Warto uwzględnić zarówno klasyczne atrybuty bezpieczeństwa informacji, jak i skutki dla realizowanej działalności. KSC wprost posługuje się między innymi poufnością, integralnością, dostępnością i autentycznością.

Przykład mierzalnej skali dostępności

Progi są przykładowe i powinny zostać dostosowane do charakteru konkretnej usługi.

Jak ustalić końcową ocenę wpływu?

Metodyka powinna jednoznacznie określać sposób agregacji poszczególnych skutków.

Możliwe jest przykładowo stosowanie:

• najwyższej oceny spośród wszystkich kryteriów;
• średniej;
• średniej ważonej;
• odrębnej macierzy dla szczególnie istotnych skutków.

W sektorze publicznym praktyczne może być przyjęcie zasady ostrożnościowej, zgodnie z którą końcowy wpływ odpowiada najwyższej ocenie spośród kryteriów, zwłaszcza gdy wysoką ocenę powoduje zagrożenie dla życia lub zdrowia, niemożność realizacji zadania publicznego albo poważny skutek prawny.

Jest to jednak wybór metodologiczny jednostki, a nie zasada ustanowiona przez KSC.

Krok 4. Zbuduj scenariusz ryzyka

Samo hasło:

ransomware

jest zbyt ogólne.

Przez cały artykuł możemy posłużyć się jednym przykładem:

Wykorzystanie krytycznej podatności serwera dostępnego z Internetu prowadzi do przejęcia uprawnień administracyjnych, zaszyfrowania systemu obsługującego elektroniczne wnioski i niedostępności procesu przez dwa dni.

Zgodnie z przykładową skalą dostępności sam dwudniowy przestój oznaczałby wpływ 4, a nie 5.

Jeżeli jednak ten sam incydent powodowałby dodatkowo np. krytyczny skutek dla bezpieczeństwa ludzi albo całkowite uniemożliwienie wykonywania szczególnie istotnego zadania publicznego, końcowa ocena mogłaby wynieść 5 – jeżeli przyjęta metodyka stanowi, że wynik końcowy jest najwyższą oceną ze wszystkich kryteriów.

Krok 5. Przyjmij mierzalne kryteria prawdopodobieństwa

KSC nie ustanawia jednej obowiązkowej skali punktowej. Jeżeli jednostka stosuje ocenę od 1 do 5, powinna opisać ją w sposób pozwalający na powtarzalną ocenę.

W przypadku prawdopodobieństwa można uwzględniać:

• historię podobnych incydentów;
• częstość zdarzeń w sektorze;
• ekspozycję systemu;
• dostępność technik ataku;
• dostępność publicznego exploita;
• występowanie aktywnego wykorzystania podatności;
• atrakcyjność danego rodzaju celu;
• horyzont czasowy analizy.

Przykład:

Na tym etapie nie uwzględnia się jeszcze skuteczności istniejących zabezpieczeń, jeżeli celem jest wyznaczenie ryzyka bazowego.

Skuteczność zabezpieczeń należy uwzględnić dopiero przy ponownym określaniu prawdopodobieństwa – i ewentualnie wpływu – dla ryzyka rezydualnego.

Krok 6. Oceń ryzyko bazowe

Ryzyko bazowe pokazuje ekspozycję scenariusza przed uwzględnieniem istniejących zabezpieczeń.

W prostym modelu można stosować:

ryzyko = prawdopodobieństwo × wpływ

Nie jest to wzór wynikający z KSC, lecz przykład metody zarządczej.

Dla scenariusza ransomware można przyjąć przykładowo:

• prawdopodobieństwo bazowe: 4;
• wpływ wynikający z dwudniowego przestoju: 4;
• wynik bazowy: 16.

Jeżeli inne kryterium wpływu osiągnęłoby poziom 5, a metodyka stosowałaby maksymalną wartość wpływu, wynik bazowy wyniósłby 20.

Kluczowe jest nie to, czy jednostka użyje liczby 16 albo 20, ale czy potrafi wyjaśnić, z jakich kryteriów wynikają obie wartości.

Krok 7. Oceń zabezpieczenia i ich skuteczność

Dopiero po ustaleniu ryzyka bazowego należy przeanalizować istniejące zabezpieczenia.

Dla naszego przykładu:

Nie wystarczy ocena:

zabezpieczenie istnieje.

Należy sprawdzić:

• jaki zakres obejmuje;
• czy jest skonfigurowane prawidłowo;
• czy działa;
• czy jest monitorowane;
• czy było testowane;
• czy występują wyjątki;
• czy rzeczywiście wpływa na analizowany scenariusz.

Poszczególne środki mogą ograniczać:

• prawdopodobieństwo – np. MFA albo usunięcie podatności;
• wpływ – np. sprawnie działające kopie i krótki czas odtworzenia;
• oba parametry.

Krok 8. Wyznacz ryzyko rezydualne i podejmij decyzję

Po uwzględnieniu skuteczności zabezpieczeń należy ponownie ocenić prawdopodobieństwo oraz – jeżeli zastosowane środki ograniczają konsekwencje – również wpływ.

Przykład:

Zmniejszenie wpływu może wynikać np. z przetestowanego odtworzenia systemu, pozwalającego ograniczyć przewidywaną niedostępność z dwóch dni do kilku godzin.

Ryzyko pozostające po uwzględnieniu zabezpieczeń jest ryzykiem rezydualnym.

Dopiero ono powinno stanowić podstawę decyzji o dalszym działaniu.

W praktycznej metodyce można wyróżnić:

• ograniczenie;
• unikanie;
• współdzielenie lub przeniesienie części ryzyka;
• akceptację.

Są to kategorie metodologiczne. KSC nie ustanawia zamkniętego czteroelementowego katalogu sposobów postępowania.

Akceptacja ryzyka ma granice

Akceptacja nie może służyć do uchylenia jednoznacznego wymagania ustawowego.

Jeżeli załącznik nr 4 wymaga np. testowania możliwości odtworzenia danych z kopii, decyzja:

Nie testujemy odtwarzania, ponieważ akceptujemy ryzyko.

nie zastępuje realizacji wymagania. Załącznik wprost wymaga testowania kompletności i możliwości odtworzenia danych oraz przygotowania i testowania procedury na wypadek awarii lub incydentu.

Kto może zaakceptować ryzyko?

Właścicielem ryzyka może być właściciel procesu lub usługi, którego działalności dotyczą konsekwencje scenariusza.

Nie oznacza to jednak, że posiada on nieograniczone kompetencje do akceptacji ryzyka.

Właściciel ryzyka podejmuje decyzje w granicach nadanych kompetencji.

Metodyka powinna określić progi eskalacji, np.:

Do kierownika powinny być również eskalowane ryzyka:

• przekrojowe;
• wymagające istotnego finansowania;
• wpływające na wiele procesów;
• mogące skutkować niewykonaniem obowiązku prawnego.

Jest to zgodne z zarządczą rolą kierownika określoną w KSC – obejmującą decyzje dotyczące SZBI, finansowanie, przydzielanie zadań i nadzór.

Krok 9. Przygotuj plan działań wobec ryzyk

Dla ogólnego procesu zarządzania ryzykiem warto używać określenia plan działań wobec ryzyk.

Pozwala to odróżnić go od ustawowego „planu postępowania z ryzykiem” wymienionego w art. 10.

Dla naszego scenariusza ransomware plan może wyglądać tak:

Taki plan nie kończy się na stwierdzeniu:

Działanie zostało wykonane.

Po realizacji należy sprawdzić:

1. czy zabezpieczenie działa;
2. czy objęło zakładany zakres;
3. czy spełniono kryterium skuteczności;
4. czy zmieniło prawdopodobieństwo albo wpływ zgodnie z założeniami;
5. jaki jest rzeczywisty poziom ryzyka rezydualnego.

Dopiero wtedy można ocenić skuteczność działania.

Art. 10 – plan postępowania z ryzykiem w dokumentacji ochrony infrastruktury

Art. 10 KSC wymaga prowadzenia dokumentacji dotyczącej bezpieczeństwa systemu informacyjnego wykorzystywanego w procesie świadczenia usługi. Wśród dokumentacji normatywnej znajduje się dokumentacja ochrony infrastruktury.

Obejmuje ona:

• charakterystykę usługi i infrastruktury;
• ocenę aktualnego stanu ochrony infrastruktury;
• szacowanie ryzyka dla obiektów infrastruktury;
• plan postępowania z ryzykiem;
• opis zabezpieczeń technicznych;
• zasady organizacji i wykonywania ochrony fizycznej;
• wskazane informacje dotyczące specjalistycznej uzbrojonej formacji ochronnej – jeżeli występuje.

Dlatego ogólny rejestr ryzyka cyberbezpieczeństwa i plan działań wobec ryzyk nie muszą automatycznie spełniać wymagań dokumentacji z art. 10.

Mogą stanowić dla niej źródło danych, ale powinny zostać jednoznacznie powiązane z:

konkretnym obiektem infrastruktury → aktualnym stanem ochrony → ryzykiem dla obiektu → sposobem postępowania → zabezpieczeniami fizycznymi i technicznymi

Dokumenty mogą być prowadzone łącznie, jeżeli wszystkie elementy wymagane przez art. 10 pozostają jednoznacznie wyodrębnione i identyfikowalne.

Jak powinien wyglądać rejestr ryzyka?

Praktyczny rekord może zawierać:

Metodyka powinna również określić sposób postępowania wtedy, gdy jedno kryterium wpływu ma szczególnie wysoką ocenę. Przykładowo skutek dla życia lub zdrowia na poziomie 5 może przesądzać o wysokim wpływie całego scenariusza niezależnie od niewielkich skutków finansowych.

Ryzyko dostawcy

W modelu art. 8 ust. 1 bezpieczeństwo łańcucha dostaw jest jednym z obszarów SZBI. Analiza powinna więc uwzględniać zależności od produktów, usług, procesów ICT i podmiotów zewnętrznych.

W praktyce należy pytać między innymi:

Wynik takiej analizy powinien mieć przełożenie na wymagania zakupowe, treść umowy i sposób nadzorowania wykonawcy.

Kiedy ponownie oceniać ryzyko?

W modelu art. 8 ust. 1 szacowanie i zarządzanie ryzykiem mają charakter systematyczny, a więc nie mogą zakończyć się na jednorazowej analizie wykonanej podczas wdrożenia.

Ponowna ocena jest szczególnie zasadna po:

• istotnej zmianie procesu;
• wdrożeniu nowego systemu;
• zmianie dostawcy;
• wykryciu krytycznej podatności;
• poważnym incydencie;
• istotnej zmianie architektury;
• zmianie charakteru cyberzagrożeń;
• zakończeniu istotnego planu redukcji ryzyka.

W modelu podmiotu ważnego publicznego załącznik nr 4 przewiduje przegląd SZBI co najmniej raz w roku oraz bezzwłocznie w określonych przypadkach, w tym gdy pojawią się okoliczności mogące wpłynąć na ryzyko wystąpienia incydentu poważnego.

Nie zmienia to tego, że formalny obowiązek systematycznego szacowania ryzyka z art. 8 ust. 1 pkt 1 nie znajduje w tym modelu zastosowania.

Co powinien otrzymywać kierownik?

Raport zarządczy nie powinien być kopią całego technicznego rejestru.

Powinien wskazywać przede wszystkim:

• ryzyka krytyczne i wysokie;
• procesy najbardziej zagrożone;
• ryzyka przekrojowe;
• ryzyka wymagające decyzji kierownika;
• działania opóźnione;
• potrzeby finansowe;
• potrzebne zamówienia lub zmiany umów;
• ryzyka proponowane do akceptacji;
• skuteczność zakończonych działań;
• zmianę poziomu ryzyka rezydualnego.

Celem jest umożliwienie kierownikowi podejmowania decyzji dotyczących SZBI, finansowania, przydziału zadań i nadzoru, a nie przedstawienie mu kilkuset technicznych rekordów.

Najczęstsze błędy

Przypisanie wszystkim JSFP art. 8 ust. 1

Podmiot ważny będący podmiotem publicznym stosuje art. 8 ust. 3 i załącznik nr 4. Nie ma w ramach tego modelu formalnego obowiązku systematycznego szacowania ryzyka z art. 8 ust. 1 pkt 1.

Uznanie, że podmiot ważny publiczny w ogóle nie zajmuje się ryzykiem

Pozostają wymagania art. 10, innych regulacji oraz praktyczne wykorzystanie analizy ryzyka przy zarządzaniu bezpieczeństwem.

Ocena ryzyka bazowego po uwzględnieniu zabezpieczeń

Jeżeli metodyka rozróżnia ryzyko bazowe i rezydualne, istniejące zabezpieczenia powinny wpływać dopiero na ocenę ryzyka rezydualnego.

Niemierzalne skale

„Niskie”, „średnie” i „wysokie” bez określenia kryteriów prowadzą do ocen zależnych od osoby przeprowadzającej analizę.

Informatyk jako właściciel każdego ryzyka

IT może być właścicielem konkretnego zabezpieczenia. Skutki dla zadania powinny być oceniane przez właściciela procesu, a najważniejsze decyzje eskalowane zgodnie z kompetencjami.

Akceptacja zamiast wykonania obowiązku

Decyzja o akceptacji ryzyka nie uchyla jednoznacznego wymagania KSC.

Zakończenie działania bez ponownej oceny

„MFA wdrożone” albo „backup wykonany” nie dowodzi jeszcze, że ryzyko spadło do oczekiwanego poziomu. Potrzebna jest ocena skuteczności oraz ponowne wyznaczenie ryzyka rezydualnego.

Termin wdrożenia

Podmioty, które 3 kwietnia 2026 r. spełniały przesłanki uznania ich za podmiot kluczowy albo ważny, realizują obowiązki rozdziału 3 w terminie 12 miesięcy od wejścia nowelizacji w życie, czyli zasadniczo do 3 kwietnia 2027 r.

Dla podmiotu stosującego art. 8 ust. 1 oznacza to, że do tego czasu powinien funkcjonować rzeczywisty proces systematycznego szacowania i zarządzania ryzykiem, a nie jedynie zatwierdzony dokument opisujący przyszłą metodykę.

Podsumowanie

Prawidłowy proces można sprowadzić do sekwencji:

zadanie → proces → system → zależności → scenariusz → ryzyko bazowe → zabezpieczenia → ryzyko rezydualne → decyzja → działanie → weryfikacja

Kluczowe jest jednak wcześniejsze ustalenie właściwej podstawy prawnej.

Podmiot stosujący art. 8 ust. 1 ma formalny obowiązek systematycznego szacowania ryzyka wystąpienia incydentu i zarządzania nim.

Podmiot ważny będący podmiotem publicznym, stosujący art. 8 ust. 3, nie ma tego konkretnego obowiązku w ramach SZBI. Analiza ryzyka może być jednak użytecznym narzędziem zarządczym, a niezależnie od tego pozostają obowiązki wynikające z art. 10 KSC oraz – gdy mają zastosowanie – innych regulacji.

Dlatego w praktyce należy rozdzielić:

1. systematyczne szacowanie i zarządzanie ryzykiem z art. 8 ust. 1;
2. analizę ryzyka wykorzystywaną pomocniczo w modelu załącznika nr 4;
3. szacowanie ryzyka dla obiektów infrastruktury i plan postępowania z ryzykiem wymagane przez art. 10.

Dobrze zaprojektowany proces nie kończy się na nadaniu ryzyku wartości liczbowej. Powinien prowadzić do decyzji, działania i ponownej oceny, która pozwoli sprawdzić, czy rzeczywiście osiągnięto zakładany poziom bezpieczeństwa.

Zobacz także

• Analiza luk KSC/NIS2 – metodyka i checklista
• SZBI z art. 8 ust. 1 a model z art. 8 ust. 3
• Plan wdrożenia KSC w JSFP do 3 kwietnia 2027 r.
• Kto odpowiada za obowiązki KSC w jednostce? Macierz RACI+N

Podstawy prawne i źródła

• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa – tekst jednolity: Dz.U. z 2026 r. poz. 20, z późn. zm.; aktualny tekst ujednolicony
• Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw – Dz.U. z 2026 r. poz. 252
• Ustawa z dnia 29 maja 2026 r. o zmianie ustawy o zarządzaniu kryzysowym oraz niektórych innych ustaw – Dz.U. z 2026 r. poz. 815
• Q&A „Nowelizacja KSC” – Ministerstwo Cyfryzacji, aktualizacja czerwiec 2026 r.
• Ministerstwo Cyfryzacji – obowiązki podmiotów kluczowych i ważnych
• Ministerstwo Cyfryzacji – najważniejsze terminy nowelizacji KSC
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 – RODO

Aktualny tekst ujednolicony Kancelarii Sejmu ma charakter informacyjny. Podstawowymi źródłami prawa pozostają akty ogłoszone w Dzienniku Ustaw oraz ustawy zmieniające. Materiały Ministerstwa Cyfryzacji mają charakter informacyjny i pomocniczy.

Zastrzeżenie: Artykuł ma charakter informacyjny. Metodykę zarządzania ryzykiem należy dostosować do statusu podmiotu, podstawy kwalifikacji, właściwego modelu SZBI, realizowanych zadań i usług, wykorzystywanych systemów oraz regulacji sektorowych. Przedstawione skale, sposób agregacji wpływu, poziomy akceptacji i kategorie postępowania z ryzykiem są przykładową metodyką zarządczą, a nie skalą ustanowioną przez KSC.