Lokalne Centrum Cyberbezpieczeństwa (LCC) dla samorządów: jak zbudować je wspólnie i utrzymać po dotacji?
Czym jest LCC, kto może je utworzyć i jak zaplanować SOC, finansowanie oraz utrzymanie centrum przez 5 lat po zakończeniu projektu?
Gmina ma już firewall, EDR, system backupowy, a czasem także SIEM. Mimo to nocny alert może czekać do rana, reguły detekcji nie są regularnie rozwijane, a podczas incydentu nie wiadomo, kto może odizolować urządzenie albo zablokować konto administratora. Problemem nie zawsze jest brak technologii. Często brakuje zdolności operacyjnej, która zamienia sygnał w decyzję i reakcję.
Lokalne Centrum Cyberbezpieczeństwa ma pomóc kilku jednostkom samorządu terytorialnego zbudować taką zdolność wspólnie. Nie powinno być rozumiane jako wspólna serwerownia, katalog zakupów ani zewnętrzna usługa pod nową nazwą. To model współpracy JST obejmujący ludzi, procesy, narzędzia, odpowiedzialność i finansowanie bezpieczeństwa również po zakończeniu dotacji.
Ten materiał można potraktować jako wprowadzenie przed rozmową o projekcie LCC. Wyjaśnia, kto może w nim uczestniczyć, jakie są kluczowe warunki, na czym polega wartość wspólnego centrum i dlaczego architekturę trzeba od początku projektować z myślą o pięcioletnim okresie trwałości.
Poniższe informacje uwzględniają dokumentację naboru FERC 4.1 oraz pytania i odpowiedzi CPPC zaktualizowane 20 sierpnia 2026 r. Warunki formalne odróżniamy od rekomendacji technicznych. Przed złożeniem wniosku należy ponownie sprawdzić aktualną dokumentację na stronie naboru CPPC.
Najważniejsze informacje
- Partnerstwo: projekt realizują wspólnie co najmniej dwie JST; jedna z nich jest Liderem i Wnioskodawcą.
- Skala: LCC musi objąć łącznie co najmniej 1000 endpointów pozostających w odpowiedzialności JST.
- Finansowanie: do 100% wydatków kwalifikowanych; limit projektu wynosi od 6 mln zł dla dwóch JST do 15 mln zł dla co najmniej 20 JST.
- Zakres: centrum realizuje siedem obowiązkowych grup zadań z obszaru cyberbezpieczeństwa.
- Trwałość: skuteczne funkcjonowanie LCC i odpowiednie zasoby trzeba zapewnić przez 5 lat po zakończeniu projektu.
- Termin: zgodnie z aktualnym harmonogramem nabór kończy się 30 października 2026 r.
Co warto wiedzieć
- LCC jest wspólną zdolnością operacyjną JST, a nie katalogiem produktów. Ma zapewniać usługi cyberbezpieczeństwa uczestniczącym samorządom i wskazanym jednostkom organizacyjnym.
- Projekt składa JST działająca jako Lider wraz z co najmniej jedną partnerską JST. Stowarzyszenie JST, związek międzygminny, szkoła ani spółka nie mogą zastąpić Partnera.
- Partnerstwo musi objąć łącznie co najmniej 1000 endpointów. Urządzenia muszą pozostawać w odpowiedzialności JST i faktycznie zostać objęte wsparciem LCC.
- Program obejmuje siedem obowiązkowych grup zadań i pięcioletni okres trwałości. Nie narzuca konkretnego SIEM, XDR, producenta ani jednego modelu SOC.
- Najważniejsze pytanie brzmi nie „co kupimy?”, lecz „jak centrum będzie działać po dotacji?”. TCO powinien pozostawić środki na analityków, monitoring, reakcję, rozwój reguł, playbooków, automatyzacji oraz testy.
- Efekt skali powstaje przede wszystkim we wspólnych kompetencjach i procesach. Więcej JST nie gwarantuje niższej ceny każdej licencji.
Czym jest Lokalne Centrum Cyberbezpieczeństwa?
W dokumentacji naboru LCC jest przedstawiane jako sposób wspólnej realizacji zadań cyberbezpieczeństwa przez samorządy. Centrum ma świadczyć usługi na rzecz uczestniczących JST i wskazanych instytucji należących do ich struktur organizacyjnych. Podstawą współpracy jest umowa lub porozumienie między JST.
W praktyce LCC powinno działać jak wspólny system operacyjny bezpieczeństwa. Jedna gmina może wnosić doświadczenie administratorów, druga istniejące narzędzia, trzecia infrastrukturę, a wszystkie korzystają ze wspólnych zasad, kompetencji i mechanizmów obsługi zagrożeń.
Nie oznacza to, że środowiska wszystkich uczestników mają stać się identyczne. Wspólne powinny być przede wszystkim:
- minimalne standardy bezpieczeństwa;
- sposób monitorowania i obsługi incydentów;
- zasady eskalacji oraz podejmowania decyzji;
- playbooki, raportowanie i dokumentowanie działań;
- rozwój reguł detekcji, automatyzacji i kompetencji;
- model utrzymania usług po zakończeniu finansowania.
Taki model odpowiada na problem skali. Pojedynczej gminie trudno samodzielnie utrzymać specjalistów od monitoringu, Incident Response, podatności, tożsamości, backupu i ciągłości działania. Wspólne centrum pozwala wykorzystywać te kompetencje dla wielu JST bez budowania pełnego zespołu od początku w każdej z nich.
LCC nie jest nazwą produktu. Dokumentacja nie narzuca jednego SIEM, XDR, SOAR ani producenta. Nie wymaga również utworzenia jednej wspólnej serwerowni. Wymaga osiągnięcia określonego zakresu usług i utrzymania zdolności do ich realizacji.
Kto może utworzyć LCC?
Nabór jest skierowany wyłącznie do jednostek samorządu terytorialnego realizujących projekt w partnerstwie. Jedna JST zostaje Wnioskodawcą i Partnerem Wiodącym, składa wniosek oraz reprezentuje pozostałe jednostki. Co najmniej jedna kolejna JST uczestniczy jako Partner.
Stowarzyszenie JST, związek międzygminny, szkoła, jednostka organizacyjna ani spółka nie mogą być Wnioskodawcą lub Partnerem w tym naborze. Szkoły i inne jednostki organizacyjne mogą natomiast zostać objęte wsparciem LCC, jeżeli zostaną prawidłowo wskazane w dokumentacji projektu.
VigilHorizon nie „zakłada własnego LCC” i nie zastępuje samorządów w roli beneficjenta. Firma może wspierać zaprojektowanie i dostarczenie warstwy technologicznej oraz operacyjnej, jeżeli zostanie wybrana zgodnie z właściwymi procedurami. Liderem, właścicielem modelu i podmiotem odpowiedzialnym za projekt pozostaje JST.
FAQ CPPC dopuszcza korzystanie z usług podmiotów zewnętrznych przy realizacji zadań LCC. Wykonawca zewnętrzny nie przejmuje jednak odpowiedzialności JST za model organizacyjny centrum, jego trwałość ani zarządzanie ryzykiem. Partnerstwo nadal musi wykazać, że LCC realizuje minimalny zakres zadań oraz ma odpowiednie kompetencje i zasoby.
Jakie są kluczowe warunki wejścia?
| Warunek | Co oznacza w praktyce |
|---|---|
| Co najmniej dwie JST | Jedna JST pełni rolę Lidera i Wnioskodawcy, a co najmniej jedna jest Partnerem. |
| Umowa lub porozumienie przed złożeniem wniosku | Dokument określa role, zadania, finansowanie, rozliczenia i odpowiedzialność. Musi obowiązywać podczas projektu i przez wymagany okres trwałości. |
| Minimum 1000 endpointów | Próg dotyczy całego partnerstwa, a nie każdej JST osobno. Urządzenia muszą pozostawać w odpowiedzialności JST i zostać objęte ochroną LCC. |
| Minimalny potencjał kadrowy Wnioskodawcy | W dniu złożenia wniosku Wnioskodawca zatrudnia na umowę o pracę co najmniej jedną osobę z certyfikatem wskazanym przez CPPC albo właściwym dyplomem z zakresu cyberbezpieczeństwa. |
| Pełny minimalny zakres zadań | Projekt musi wykazać realizację wszystkich siedmiu grup zadań LCC. |
| Utrzymanie przez 5 lat | Trzeba przedstawić model organizacyjny oraz zasoby kadrowe, techniczne, organizacyjne i finansowe na okres trwałości. |
Do puli endpointów można wliczyć urządzenia używane w szkołach i innych jednostkach organizacyjnych, w tym komputery w pracowniach dydaktycznych, jeżeli spełniają definicję z naboru, JST odpowiada za ich bezpieczeństwo, łączą się z siecią, a LCC rzeczywiście obejmie je ochroną.
Każdą wspieraną instytucję oraz liczbę endpointów należy wskazać w wymaganym załączniku. Samo wymienienie jednostki w opisie projektu nie wystarcza.
Nie należy również zakładać, że cały SOC musi zostać zatrudniony bezpośrednio przez urząd. Kryterium kadrowe określa minimalny potencjał Wnioskodawcy, a dokumentacja dopuszcza udział podmiotów zewnętrznych pod warunkiem zachowania rzeczywistego modelu LCC.
Udział w projekcie „Cyberbezpieczny Samorząd” nie wyklucza udziału w LCC. Trzeba jednak wyraźnie rozdzielić zakres rzeczowy i finansowy, aby nie rozliczyć ponownie tych samych wydatków.
Jakie zadania LCC są obowiązkowe?
Załącznik do kryteriów wskazuje siedem obszarów, w których LCC ma wdrożyć jednolite mechanizmy i świadczyć oparte na nich usługi. Jest to formalny minimalny zakres, a nie lista fakultatywnych modułów.
| Obowiązkowy obszar | Praktyczne znaczenie dla JST |
|---|---|
| Obsługa cyberzagrożeń i incydentów | Procedury, analiza zdarzeń, reakcja, ograniczanie skutków i dokumentowanie działań. |
| Zarządzanie aktywami i wsparcie SZBI | Inwentaryzacja produktów, usług i procesów ICT oraz powiązanie ich z zarządzaniem bezpieczeństwem informacji. |
| Bezpieczne wersje i aktualizacje oprogramowania | Kontrola wersji, cyklu życia, podatności i procesu aktualizacji, również na urządzeniach mobilnych. |
| Zarządzanie uprawnieniami | Minimalne uprawnienia, nadawanie, modyfikowanie i szybkie odbieranie dostępu. |
| Ochrona danych, w tym kopie zapasowe | Kopie logicznie i fizycznie odseparowane od danych produkcyjnych oraz testy kompletności i możliwości odtworzenia. |
| Bezpieczeństwo komunikacji i poczty | Ochrona kanałów komunikacji, poczty i uwierzytelniania adekwatna do ryzyka. |
| Kompetencje i cyberhigiena | Szkolenia, rozwój wiedzy oraz przygotowanie pracowników i kierownictwa do reagowania na incydenty. |
Lista pokazuje, dlaczego LCC nie może zostać zredukowane do monitoringu logów. SOC może być ważnym elementem centrum, ale nie wyczerpuje całego obowiązkowego zakresu.
Ile wynosi dofinansowanie i jakie są terminy?
Budżet całego naboru wynosi 269 649 295,75 zł, a maksymalny poziom dofinansowania to 100% wydatków kwalifikowanych. Nabór jest konkurencyjny: spełnienie warunków nie oznacza automatycznego przyznania środków. Projekty są oceniane i układane na liście rankingowej.
Maksymalna kwota dla projektu rośnie wraz z liczbą JST:
| Liczba JST w partnerstwie | Maksymalna kwota dofinansowania projektu |
|---|---|
| 2 | 6 mln zł |
| 3 | 6,5 mln zł |
| 4 | 7 mln zł |
| 5 | 7,5 mln zł |
| 6 | 8 mln zł |
| 10 | 10 mln zł |
| 20 lub więcej | 15 mln zł |
Pomiędzy wskazanymi progami limit rośnie o 0,5 mln zł za każdą kolejną JST, aż do 15 mln zł. Roboty budowlane nie mogą przekroczyć 20% kwalifikowanych wydatków projektu.
Nabór rozpoczął się 31 lipca 2026 r. i zgodnie z dokumentacją ma zakończyć się 30 października 2026 r. Projekt można realizować najpóźniej do 31 grudnia 2030 r., a po jego zakończeniu obowiązuje pięcioletni okres trwałości.
Duży limit nie jest celem samym w sobie. Wniosek ma przejść ocenę efektywności kosztowej, która obejmuje m.in. analizę finansową, ekonomiczną i trwałości, koszty eksploatacji, racjonalność cen oraz analizę opcji technicznych. Dostępny budżet nie jest argumentem, aby większość środków przeznaczyć na technologię.
Jak punktowane są projekty LCC?
Nabór jest konkurencyjny, dlatego na wynik wpływa nie tylko spełnienie warunków wejścia, lecz także punktacja projektu. Z perspektywy budowania partnerstwa szczególnie ważne są cztery kryteria:
- liczba JST: dwie JST otrzymują w tym kryterium 0 punktów, a każda kolejna zwiększa wynik o 1 punkt, aż do maksymalnych 10 punktów dla partnerstwa obejmującego co najmniej 12 JST;
- pełny układ powiatowy: dodatkowe 10 punktów można uzyskać, jeżeli partnerstwo obejmuje co najmniej jeden powiat i wszystkie gminy z jego terenu;
- potencjał kadrowy Wnioskodawcy: poza minimalnym warunkiem zatrudniania jednej wykwalifikowanej osoby punktowane jest posiadanie większego zespołu z wymaganymi kwalifikacjami — od 2 punktów za dwie osoby do 5 punktów za co najmniej pięć osób;
- potencjał instytucjonalny Wnioskodawcy: od 0 do 10 punktów zależy od tego, czy istniejący zespół wspólnie obsługuje zadania cyberbezpieczeństwa dla jednostek organizacyjnych JST i jaką część tych jednostek obejmuje.
Sama maksymalizacja liczby Partnerów nie zastąpi wiarygodnego modelu działania. Punktacja powinna wspierać partnerstwo, które ma realne kompetencje, zdolność zarządzania i plan finansowania LCC przez cały okres trwałości.
Gminy mają już SIEM, XDR i firewalle. Co daje LCC?
Wiele samorządów wdrożyło już SIEM, EDR/XDR, firewalle, systemy backupowe, rozwiązania do zarządzania siecią, szkolenia i audyty. Te inwestycje mogą być wartościowym punktem wyjścia. Problem pojawia się wtedy, gdy narzędzia nie tworzą jednego procesu operacyjnego.
Posiadanie SIEM nie oznacza posiadania SOC. SIEM może zbierać miliony zdarzeń, ale ktoś musi:
- analizować alerty;
- odróżniać false positive od rzeczywistych zagrożeń;
- korelować zdarzenia z różnych źródeł;
- oceniać wpływ na usługi publiczne;
- eskalować incydenty;
- uruchamiać uzgodnione procedury;
- reagować i dokumentować decyzje;
- wyciągać wnioski;
- aktualizować reguły detekcji, automatyzacje i playbooki.
| Narzędzie lub zasób | Co zapewnia | Czego nadal potrzebuje JST |
|---|---|---|
| SIEM | Centralizacja logów, korelacja i alerty | Danych dobrej jakości, reguł detekcji, triage’u, właściciela alertu i reakcji |
| EDR/XDR | Telemetria i działania na endpointach | Poprawnej konfiguracji, analizy kontekstu, uprawnień do izolacji i obsługi wyjątków |
| Firewall | Kontrola ruchu i segmentacja | Aktualnych reguł, monitoringu, decyzji o blokadach i oceny wpływu na usługi |
| Backup | Kopia danych | Separacji, ochrony tożsamości, planu DR i potwierdzonego testami odtworzenia |
| Audyt | Obraz stanu w określonym momencie | Właścicieli działań, terminów, monitorowania realizacji i ponownej weryfikacji |
LCC powinno przekształcić istniejącą technologię w działający system cyberbezpieczeństwa: z całodobową lub adekwatną do ryzyka obsługą, ustalonymi odpowiedzialnościami, wspólnymi procedurami i mierzalnym czasem reakcji.
„Najdroższy SIEM nie tworzy wspólnej zdolności bezpieczeństwa. Tworzą ją dopiero dane dobrej jakości, ludzie rozumiejący kontekst oraz uzgodnione decyzje podejmowane pod presją czasu.”
Różnicę między monitoringiem a dojrzałym procesem operacyjnym szerzej wyjaśnia artykuł Czym jest SOC 24/7 i dlaczego monitoring nie wystarcza.
Model VigilHorizon: technologia, automatyzacja i człowiek
Model VigilHorizon zakłada, że technologia ma wspierać analityków i procesy, a nie konsumować większość budżetu utrzymaniowego. Architektura nie powinna zależeć od kilkudziesięciu drogich licencji, których po zakończeniu finansowania nie będzie można racjonalnie przedłużyć.
Open source tam, gdzie ma to uzasadnienie
Dojrzałe rozwiązania open source mogą ograniczać koszt i zależność od jednego producenta, ale nie są automatycznie bezpłatne ani bezobsługowe. Wymagają aktualizacji, kompetencji, integracji, testów i odpowiedzialności za utrzymanie.
Decyzję należy podejmować na podstawie bezpieczeństwa, funkcjonalności, kosztu całego cyklu życia, dostępności kompetencji, możliwości integracji i ryzyka vendor lock-in. Właściwy model nie brzmi „wszystko open source”, lecz „najniższy uzasadniony TCO przy wymaganym poziomie bezpieczeństwa”.
Automatyzacja rutyny, nie odpowiedzialności
Automatyzacja może wzbogacić alert o dane o urządzeniu, użytkowniku i podatności, zebrać artefakty, utworzyć sprawę, wysłać powiadomienie albo wykonać wcześniej zatwierdzoną blokadę. Każdy mechanizm powinien mieć właściciela, kontrolę uprawnień, rejestr działań, obsługę wyjątków i możliwość bezpiecznego zatrzymania.
Nieodwracalne działania oraz decyzje o dużym wpływie na zadania urzędu powinny pozostawać pod kontrolą człowieka. Automatyzacja ma oszczędzać czas analityków, a nie zacierać odpowiedzialność.
Wspólna biblioteka playbooków
Playbook opisuje drogę od sygnału do zamknięcia sprawy:
zdarzenie → analiza → decyzja → reakcja → eskalacja → dokumentacja → wnioski.
Wspólna biblioteka może obejmować ransomware, phishing, przejęcie konta, nietypowe logowanie, brute force, malware, eskalację uprawnień, komunikację z C2, naruszenie konta administratora, anomalie Active Directory i krytyczne podatności.
Wspólny SOC może wykorzystywać te same procedury i wiedzę w wielu JST, z zachowaniem separacji danych, właściwych uprawnień i lokalnych wyjątków. Dzięki temu wniosek z incydentu w jednej jednostce może poprawić detekcję oraz gotowość pozostałych uczestników.
Najważniejsze: koszt po zakończeniu dotacji
LCC trzeba projektować od pierwszego dnia z myślą o tym, co wydarzy się po zakończeniu finansowania. Pięcioletnia trwałość nie jest dodatkiem do projektu, lecz formalnym zobowiązaniem, które trzeba wykazać we wniosku.
Model ryzykowny:
dotacja → duży zakup licencji → wysokie koszty odnowień → ograniczenie zakresu usługi → brak środków na ludzi, tuning, reakcję i testy.
Model trwały:
inwentaryzacja → racjonalna technologia → standaryzacja → automatyzacja → wspólne playbooki → działający SOC → przewidywalny koszt utrzymania.
TCO powinien obejmować nie tylko zakup, ale także:
- odnowienia licencji i subskrypcji;
- przechowywanie oraz przetwarzanie logów;
- infrastrukturę, łącza, energię i serwis;
- integracje oraz utrzymanie konektorów;
- personel, dyżury i zastępstwa;
- monitoring, analizę zdarzeń i Incident Response;
- rozwój reguł detekcji, playbooków i automatyzacji;
- threat hunting, raportowanie i zarządzanie podatnościami;
- testy, ćwiczenia i audyty;
- backup, Disaster Recovery i ciągłość działania;
- migrację lub wyjście od dostawcy po zakończeniu umowy.
Po zakończeniu projektu największą wartością utrzymania powinny być kompetencje analityków, wykrywanie, reakcja i ciągłe doskonalenie. Budżet operacyjny powinien finansować bezpieczeństwo, a nie tylko prawo do dalszego używania narzędzi.
Porozumienie między JST musi określać sposób finansowania utrzymania, zasady zmiany liczby uczestników, odpowiedzialność za wspólne zasoby i postępowanie w razie wyjścia Partnera. Bez tego pięcioletni plan może pozostać deklaracją.
Gdzie powstaje efekt skali?
Partnerstwo jest formalnym warunkiem naboru, ale nie powinno być wyłącznie konstrukcją potrzebną do złożenia wniosku. Jego sens polega na połączeniu zasobów, których pojedyncza gmina często nie jest w stanie samodzielnie zbudować i utrzymać.
Prawdziwy efekt skali powstaje przede wszystkim we wspólnych:
- zespole SOC i dostępie do rzadkich kompetencji;
- procedurach, playbookach i materiałach szkoleniowych;
- regułach detekcji i automatyzacjach;
- standardach konfiguracji i baseline’ach;
- ćwiczeniach, testach i raportowaniu;
- analizie incydentów i wykorzystywaniu wniosków w wielu JST;
- procesach zarządzania podatnościami i doskonalenia zabezpieczeń.
Nie należy twierdzić, że każda licencja będzie tańsza tylko dlatego, że projekt obejmie więcej gmin. Korzyść polega przede wszystkim na tym, że każda JST nie musi osobno tworzyć pełnego zespołu, procesu i biblioteki wiedzy.
Większa liczba uczestników zwiększa jednocześnie liczbę systemów, wyjątków, właścicieli procesów i uzgodnień. Partnerstwo powinno być więc budowane wokół realnej gotowości do wspólnego działania i finansowania LCC, a nie wyłącznie maksymalizacji punktacji lub budżetu.
Dlaczego projekt trzeba zacząć od audytu i analizy luk?
LCC powinno rozpocząć się od dokładnej analizy obecnego stanu każdego uczestnika. Trzeba sprawdzić m.in.:
- wcześniejsze projekty cyberbezpieczeństwa i ich zakres finansowy;
- SIEM, EDR/XDR, firewalle i narzędzia sieciowe;
- Active Directory, uprawnienia i tożsamości uprzywilejowane;
- backup, retencję, separację i ostatnie testy odtworzeniowe;
- konfiguracje, integracje i jakość telemetrii;
- monitoring, procedury i sposób obsługi alertów;
- kompetencje oraz dostępność personelu;
- podatności i proces aktualizacji;
- systemy dziedzinowe, ich właścicieli i zależności;
- umowy, daty odnowień i ograniczenia licencyjne.
Następnie należy wykonać GAP Analysis wobec siedmiu obowiązkowych obszarów. Luka może oznaczać brak produktu, ale równie często brak konfiguracji, procesu, odpowiedzialności, kompetencji albo testu.
Nie wymieniamy działających technologii tylko dlatego, że pojawiło się nowe finansowanie. Najpierw wykorzystujemy to, co spełnia potrzeby, a dopiero później uzupełniamy potwierdzone braki. Ogranicza to koszt, czas wdrożenia oraz ryzyko powielania zakresów finansowanych wcześniej.
Co warto standaryzować między samorządami?
Tam, gdzie środowiska są podobne, partnerstwo może budować wspólne:
- polityki i minimalne wymagania bezpieczeństwa;
- baseline’y konfiguracji;
- standardy zbierania logów i integracji;
- reguły firewall oraz reguły detekcji;
- klasyfikację incydentów i zasady eskalacji;
- playbooki i procedury reagowania;
- raporty zarządcze i mierniki jakości usługi;
- scenariusze ćwiczeń oraz testów.
Standaryzacja nie oznacza ignorowania lokalnego kontekstu. Konkretna JST może mieć inne systemy dziedzinowe, umowy, poziomy ryzyka i ograniczenia organizacyjne. Dlatego model powinien przewidywać udokumentowane wyjątki, ich właścicieli i terminy ponownego przeglądu.
Przykładowo cztery JST mogą wspólnie objąć ochroną 1260 endpointów, wykorzystać istniejące firewalle, EDR-y i systemy backupowe, a następnie zbudować jeden proces obsługi alertów, wspólną bibliotekę playbooków i uzgodniony model reakcji. Rezultatem nie będzie identyczna infrastruktura w każdej gminie, lecz jeden mierzalny sposób wykrywania, eskalacji i obsługi zagrożeń.
Dlaczego wykrycie ataku nie wystarcza?
Nawet dobrze działający SOC nie gwarantuje, że każdy atak zostanie zatrzymany przed wpływem na systemy. Dlatego dojrzały model LCC nie powinien kończyć się na wykryciu zagrożenia i ograniczeniu incydentu. Powinien również uwzględniać bezpieczne odtworzenie środowiska oraz utrzymanie najważniejszych zadań urzędu do czasu powrotu systemów.
Oba obszary tworzą jeden proces. Analiza incydentu pomaga określić zakres kompromitacji i wybrać bezpieczny punkt odtworzenia. Z kolei problemy ujawnione podczas recovery powinny prowadzić do aktualizacji reguł detekcji, procedur i playbooków.
Minimalny zakres zadań LCC obejmuje ochronę danych poprzez kopie zapasowe, ich logiczne i fizyczne odseparowanie oraz testowanie kompletności i możliwości odtworzenia. Sam komunikat „backup wykonany poprawnie” nie potwierdza, że urząd wróci do pracy w akceptowalnym czasie.
Warstwa odporności powinna uwzględniać backup off-site, ochronę kopii przed ransomware, RPO, RTO, Disaster Recovery, testy odtworzeniowe i Business Continuity. Temat rozwija uzupełniający materiał SecureVault: LCC wykryje cyberatak. Czy urząd potrafi po nim wznowić działanie?
Jak utrzymać LCC przez 5 lat?
Projekt nie kończy się wraz z rozliczeniem finansowania. Przez pięcioletni okres trwałości LCC ma skutecznie funkcjonować i dysponować odpowiednimi zasobami kadrowymi, organizacyjnymi, technicznymi oraz finansowymi.
Model utrzymania powinien określać:
- odpowiedzialności Lidera, Partnerów i dostawców;
- minimalny skład personelu, dyżury i zastępstwa;
- właścicieli usług, systemów i ryzyk;
- sposób finansowania wspólnych i lokalnych kosztów;
- aktualizację procedur, reguł i narzędzi;
- rozwój kompetencji, playbooków i automatyzacji;
- reagowanie na nowe zagrożenia oraz podatności;
- testy, ćwiczenia, audyty i raportowanie;
- plan wyjścia z umów i migracji między rozwiązaniami;
- zasady dołączania, występowania lub niewywiązywania się Partnerów.
Niski i przewidywalny TCO powinien być jednym z kryteriów projektowania architektury, ale nie jedynym. Rozwiązanie musi być również bezpieczne, możliwe do obsługi, udokumentowane i odporne na odejście pojedynczej osoby lub dostawcy.
Jak rozpocząć przygotowanie projektu LCC?
1. Zbuduj partnerstwo JST. Znajdź samorządy zainteresowane wspólnym świadczeniem usług bezpieczeństwa, a nie tylko wspólnym złożeniem wniosku.
2. Zweryfikuj warunki wejścia. Sprawdź status Partnerów, liczbę endpointów, kwalifikowalność, potencjał kadrowy Wnioskodawcy, terminy i wymagane załączniki.
3. Wskaż wspierane instytucje. Przypisz je do właściwych JST, określ ich rolę i policz endpointy zgodnie z definicją naboru.
4. Zinwentaryzuj wcześniejsze inwestycje. Zbierz narzędzia, licencje, umowy, projekty publiczne, integracje, procedury i rzeczywiste kompetencje.
5. Wykonaj audyt i GAP Analysis. Sprawdź, co faktycznie działa, a czego brakuje w każdym z siedmiu obszarów.
6. Zaprojektuj architekturę LCC. Ustal technologię, SOC, procesy, odpowiedzialności, playbooki, automatyzację, raportowanie i ciągłość działania.
7. Policz TCO na okres trwałości. Porównaj warianty i sprawdź, czy po dotacji budżet wystarczy na działającą usługę, ludzi, testy i rozwój.
8. Dopiero wtedy dobierz technologię i przygotuj projekt. Każdy wydatek powinien odpowiadać potwierdzonej luce i mieć właściciela po zakończeniu wdrożenia.
Podstawa formalna i źródła
Warunki programu i daty w tym artykule zweryfikowano na podstawie materiałów dostępnych 20 sierpnia 2026 r.:
- CPPC – Działanie 4.1 FERC, trzeci nabór: Lokalne Centra Cyberbezpieczeństwa – status, cel, beneficjenci, budżet, terminy i komplet dokumentacji;
- Pytania i odpowiedzi CPPC – aktualizacja 20.08.2026 – partnerzy, endpointy, personel, udział dostawców zewnętrznych, trwałość i kwalifikowalność;
- „Kryteria wyboru projektu” oraz „Minimalny zakres zadań LCC” opublikowane w pakiecie Zasady naboru na stronie CPPC;
- „Minimalny zakres Umowy/Porozumienia o partnerstwie” opublikowany w pakiecie Pozostałe na stronie CPPC.
Wniosek i umowa powinny zawsze opierać się na najnowszej wersji dokumentów Instytucji Organizującej Nabór. Artykuł ma charakter edukacyjny i nie zastępuje analizy prawnej, finansowej ani dokumentacji aplikacyjnej.
Podsumowanie
Lokalne Centrum Cyberbezpieczeństwa daje samorządom szansę na zbudowanie wspólnej zdolności, której pojedyncza gmina często nie jest w stanie utrzymać samodzielnie. Warunkiem powodzenia jest właściwa kolejność: partnerstwo, weryfikacja warunków, inwentaryzacja, analiza luk, model operacyjny, TCO, a dopiero później technologia.
Program wymaga minimum dwóch JST, 1000 endpointów, odpowiedniego potencjału kadrowego Wnioskodawcy, realizacji siedmiu grup zadań i pięcioletniej trwałości. Nie wymaga kupowania wszystkiego od początku ani uzależnienia centrum od jednego producenta. Pozostawia przestrzeń na wykorzystanie istniejących systemów, uzasadniony open source, standaryzację, automatyzację i wspólną pracę SOC.
Rozważacie wspólne LCC z innymi samorządami? Pierwszym krokiem nie musi być wybór technologii. VigilHorizon może pomóc zweryfikować warunki wejścia, liczbę endpointów, istniejące zabezpieczenia, luki operacyjne, możliwą architekturę oraz szacunkowy koszt utrzymania. Porozmawiajmy o modelu LCC, zanim lista zakupów przesłoni usługę, którą samorządy mają wspólnie utrzymywać.
Najczęściej zadawane pytania (FAQ)
Dowiedz się więcej
Zobacz również
Nie wiesz który pakiet jest odpowiedni dla twojej firmy?
Wypełnij krótką ankietę
Wypełnij krótki formularz, a pomożemy Ci wybrać rozwiązanie, które realnie
ochroni Twoją firmę i zapewni jej ciągłość działania nawet w przypadku awarii.