3 kwietnia 2027 roku nie jest terminem na rozpoczęcie prac nad KSC. Do tego czasu organizacje objęte okresem dostosowawczym powinny mieć wdrożone wymagane obowiązki i rozpocząć korzystanie z Systemu S46.
Dla zarządu, CISO, IT i compliance oznacza to jedno: przepisy trzeba przełożyć na konkretny plan działania. Najpierw ustalić zakres projektu i sprawdzić stan obecny, potem zaplanować brakujące prace, wdrożyć je i zweryfikować w praktyce. Sam zestaw polityk i procedur nie wystarczy. Organizacja powinna umieć wykazać, że wymagane procesy działają, mają właścicieli i są faktycznie stosowane.
Największym ograniczeniem może być czas. Jeśli prace ruszają dopiero w drugiej połowie 2026 roku, prowadzenie wszystkich zadań po kolei może się po prostu nie zmieścić przed terminem. Część obszarów trzeba więc realizować równolegle, a zakończone wdrożenia testować od razu, bez czekania na zamknięcie całego projektu.
Do 3 kwietnia 2027 r. firma powinna być gotowa operacyjnie
Dla podmiotów objętych okresem dostosowawczym 3 kwietnia 2027 roku oznacza termin wdrożenia obowiązków wynikających z nowych przepisów KSC oraz rozpoczęcia korzystania z Systemu S46. Nie chodzi więc o to, żeby do tej daty mieć gotowy plan. Prace powinny być już wykonane.
Jest też wcześniejszy termin. Podmioty objęte obowiązkiem samodzielnej rejestracji powinny do 3 października 2026 roku złożyć wniosek o wpis do Wykazu KSC. Jeśli organizacja nie ustaliła jeszcze, czy podlega przepisom, nie powinna odkładać tego do czasu zakończenia analizy luk czy przygotowania pełnego harmonogramu.
W praktyce są to dwa równoległe tory. Rejestracja ma własny termin, a niezależnie od niej trzeba prowadzić projekt przygotowujący organizację do spełnienia wymagań do kwietnia 2027 roku.
Każdy obszar trzeba najpierw przeanalizować, potem wdrożyć i sprawdzić
Przygotowanie do KSC nie powinno wyglądać tak, że firma robi analizę luk, następnie przez kilka miesięcy wdraża wszystkie zmiany, a testy zostawia na sam koniec. Przy napiętym harmonogramie taki model jest po prostu zbyt wolny.
Lepiej pracować obszarami. Najpierw ustalić wymagania i sprawdzić stan obecny. Następnie wdrożyć potrzebne zmiany organizacyjne lub techniczne. Gdy dany obszar jest gotowy, od razu sprawdzić, czy przyjęte rozwiązania działają. Jeśli test ujawni braki, poprawki wracają do prac wdrożeniowych.
Ta zasada powinna obowiązywać w całym programie, nie tylko w części technicznej. Dotyczy zabezpieczeń, procesów, podziału odpowiedzialności i dokumentacji.
Przy ograniczonym czasie liczy się też kolejność. Najpierw trzeba zamknąć elementy wymagane przez ustawę o KSC. Dopiero później można rozszerzać program o wymagania wynikające wyłącznie z dobrych praktyk ISO/IEC 27001, jeśli organizacja rzeczywiście planuje certyfikację. Pozwala to skupić zasoby na zadaniach, które mają bezpośredni wpływ na gotowość przed 3 kwietnia 2027 roku.
Roadmapa KSC w sześciu etapach – od zakresu do utrzymania
Projekt wdrożenia KSC dobrze podzielić na sześć etapów. Nie powinny jednak działać jak osobne fazy zamykane jedna po drugiej. Część prac będzie się nakładać, a niektóre zadania ruszą dopiero wtedy, gdy inne dostarczą potrzebnych danych lub decyzji.
W każdym etapie trzeba określić, kto odpowiada za wykonanie prac, od czego dany obszar zależy i jaki rezultat ma powstać. Sam status „zrobione” niewiele mówi. Potrzebny jest także dowód, że zadanie zostało wykonane i można przejść dalej.
Etap
Główne role
Od czego zależy
Co musi się wydarzyć
Wynik / dowód
Ustalenie zakresu
zarząd, CISO, IT, compliance
decyzja, które systemy, usługi i procesy obejmuje projekt
potwierdzenie zakresu projektu i odpowiedzialności
zatwierdzony zakres, właściciel programu, mapa odpowiedzialności
Diagnoza
IT, CISO, zakupy, HR
zatwierdzony zakres
analiza stanu obecnego, luk i zależności
rejestr luk i materiał do ustalenia priorytetów
Plan
zarząd, CISO, compliance, IT
wyniki diagnozy i lista luk
ustalenie priorytetów, budżetu, właścicieli, kolejności prac i obszarów prowadzonych równolegle
zatwierdzony harmonogram i backlog wdrożeniowy
Wdrożenie
IT, CISO, HR, zakupy, zarząd
zatwierdzony plan i dostępność zasobów
realizacja wymaganych zmian organizacyjnych i technicznych
działające rozwiązania i dokumenty operacyjne
Testy
IT, CISO, zarząd, compliance
zakończenie prac w danym obszarze
sprawdzenie działania i skuteczności wdrożonych rozwiązań
wyniki testów, protokoły i lista poprawek
Utrzymanie
zarząd, CISO, IT, compliance
zakończone wdrożenie i testy
przejście z trybu projektowego do regularnego działania
właściciele procesów, harmonogram przeglądów i komplet dowodów
1. Ustal zakres
Na początku trzeba precyzyjnie określić, czego dotyczy projekt. Zarząd, CISO, IT i compliance powinni potwierdzić, jakie systemy, usługi, procesy i części organizacji wchodzą do zakresu prac.
Na tym etapie trzeba też przypisać odpowiedzialność za cały program i poszczególne obszary. Bez tego kolejne zadania szybko zaczynają się rozmywać między działami.
2. Zdiagnozuj stan obecny
Gdy zakres jest już znany, można przejść do analizy luk. Celem nie jest samo wskazanie braków, ale również wychwycenie zależności, które mogą później blokować wdrożenie.
W tę część prac, poza IT i CISO, często trzeba włączyć HR i zakupy. Wiele wymagań dotyczy przecież nie tylko technologii, ale także ludzi, dostawców i sposobu działania organizacji.
3. Zbuduj plan
Lista luk musi zostać przełożona na konkretne zadania. Trzeba ustalić priorytety, właścicieli, budżet oraz kolejność prac.
To również moment na określenie, które obszary można prowadzić równolegle, a które muszą poczekać na wcześniejsze decyzje lub wyniki innych prac. Harmonogram powinien pokazywać te zależności, a nie tylko daty rozpoczęcia i zakończenia.
4. Wdrażaj
Na tym etapie organizacja realizuje zaplanowane zmiany techniczne, organizacyjne i procesowe.
Wdrożenie nie kończy się na przygotowaniu dokumentu czy zakupie narzędzia. Liczy się to, czy rozwiązanie działa, zostało włączone do codziennej pracy i ma przypisanego właściciela.
5. Testuj
Gotowych obszarów nie trzeba odkładać do końca projektu. Jeśli dany proces lub zabezpieczenie zostało wdrożone wcześniej, można od razu sprawdzić jego działanie.
Wyniki testów powinny pokazać, co działa zgodnie z założeniem, a co wymaga poprawy. Dzięki temu błędy wychodzą na bieżąco, a nie dopiero pod koniec całego programu.
6. Przejdź do utrzymania
Po zakończeniu wdrożenia odpowiedzialność nie znika. Trzeba określić, kto utrzymuje dany proces, jak często jest on przeglądany i gdzie przechowywane są dowody wykonania.
W tym momencie projekt przestaje być jednorazowym wdrożeniem, a staje się stałym sposobem zarządzania bezpieczeństwem.
Pełny harmonogram z bardziej szczegółowymi zadaniami, zależnościami, wynikami i dowodami wykonania powinien być prowadzony w osobnym załączniku roboczym. W samym artykule najważniejsza jest logika projektu, którą później można przełożyć na plan dopasowany do konkretnej organizacji.
nasza usługa
Zacznij od analizy luk KSC
Jeśli organizacja nie ma jeszcze takiego obrazu, dobrym punktem wyjścia jest analiza luk KSC. To ona pokazuje, czego brakuje, które zadania są pilne i jak ułożyć harmonogram zgodny z rzeczywistym stanem firmy. Ustal, czego brakuje w Twojej organizacji, które działania są na ścieżce krytycznej i jak ułożyć harmonogram do 3 kwietnia 2027 roku.
Przy starcie w drugiej połowie 2026 roku projekt musi działać równolegle
Z doświadczenia projektowego Tenesys wynika, że pełne dojście do zgodności z KSC zajmuje zwykle około 30–50 tygodni. Jeśli prace ruszają dopiero w drugiej połowie 2026 roku, prowadzenie wszystkiego po kolei może nie wystarczyć, żeby zdążyć przed 3 kwietnia 2027 roku.
W praktyce oznacza to równoległe prowadzenie nawet kilkunastu obszarów. Nie wszystko da się jednak uruchomić w tym samym momencie. Najpierw trzeba rozpoznać zależności i wskazać zadania, których opóźnienie zatrzyma kolejne prace.
Jeden obszar może być już testowany, podczas gdy inny nadal pozostaje w trakcie wdrożenia. Dzięki temu problemy wychodzą wcześniej, a cała weryfikacja nie kumuluje się na końcu projektu.
Testy nie powinny czekać na zakończenie całego wdrożenia
Jeśli jeden z obszarów jest gotowy wcześniej, można sprawdzić go od razu. Nie ma potrzeby czekać, aż wszystkie pozostałe prace osiągną ten sam etap.
Ma to praktyczną zaletę. Jeśli test pokaże problem, zespół może wrócić do wdrożenia jeszcze wtedy, gdy inne strumienie są w toku. Przy napiętym harmonogramie zmniejsza to ryzyko, że poważne braki pojawią się dopiero kilka tygodni przed terminem ustawowym.
Jak sprawdzić, czy roadmapa prowadzi do realnej gotowości?
Zamknięcie zadania w harmonogramie nie oznacza jeszcze, że organizacja jest gotowa. Każdy etap powinien kończyć się konkretnym rezultatem, który można sprawdzić i udokumentować.
Przed oznaczeniem obszaru jako zakończonego trzeba sprawdzić, czy ma przypisanego właściciela, czy powstał zakładany rezultat i czy istnieje dowód wykonania. Ważne jest też potwierdzenie, że rozwiązanie działa w praktyce, a ewentualne poprawki zostały przypisane i zaplanowane.
Dla jednego obszaru takim dowodem będzie zatwierdzony dokument, dla innego wynik testu, działające zabezpieczenie albo rejestr pokazujący, że proces jest wykonywany zgodnie z przyjętymi zasadami.
Autor
Bartosz Pyrczak
Head of Growth
Head of Growth w Tenesys. Łączy ludzi, buduje relacje i dba o to, żeby firma rosła we właściwym kierunku. Przekonany, że w sprzedaży IT wygrywa ten, kto słucha lepiej niż mówi. Prywatnie podróżnik i rowerzysta.
