KSC i NIS2

Środki techniczne w projekcie IT

Wymagania KSC i NIS2 wpisane w zakres i odbiór systemu, który budujesz albo zamawiasz, z dowodami dla audytu zbieranymi w trakcie projektu.

Porozmawiajmy o projekcie Zobacz zakres

Sytuacje

Z czym przychodzą do nas klienci

Twoja firma zamawia nowy system albo przebudowuje ten, na którym pracuje na co dzień. Osobno prawnik i dział IT zajmują się ustawą o krajowym systemie cyberbezpieczeństwa (KSC), polskimi przepisami o zabezpieczaniu systemów i zgłaszaniu incydentów. Te dwa wątki spotykają się zwykle dopiero po odbiorze. Tu wymagania bezpieczeństwa wchodzą do zakresu i kryteriów odbioru od pierwszego dnia projektu, a każdy etap zostawia dowód dla audytu.

Wykonawca buduje według listy funkcji

Umowa z wykonawcą opisuje, co system ma robić: zamówienia, magazyn, portal dla klientów. O dostępach, dzienniku i kopiach nie ma w niej słowa, bo nikt tego nie wpisał do zapytania ofertowego. Wykonawca dodaje je na końcu, za dodatkową wycenę, albo wcale.

System odebrany, zabezpieczeń nikt nie sprawdził

Przy odbiorze przetestowano funkcje; nikt nie sprawdził, czy da się odebrać dostęp, co zapisuje dziennik i czy kopię można odtworzyć. Klient przysyła ankietę bezpieczeństwa albo zbliża się audyt, a jedynym dokumentem jest protokół odbioru funkcji.

Zakres

Co robimy

  1. Środki techniczne to zabezpieczenia, które działają w samym systemie, w odróżnieniu od polityk i procedur, które je opisują. NIS2 to unijna dyrektywa 2022/2555 o cyberbezpieczeństwie, którą ustawa o KSC wdraża od 3 kwietnia 2026 (stan prawny na 20 września 2026). Dyrektywa wymienia wśród środków zarządzania ryzykiem między innymi kontrolę dostępu, kopie zapasowe i przywracanie działania, szyfrowanie i obsługę incydentów. Wymienia też bezpieczeństwo przy nabywaniu, rozwoju i utrzymaniu systemów, w tym postępowanie z podatnościami, czyli lukami w zabezpieczeniach. Czy i od kiedy dotyczy to Twojej firmy, rozstrzyga osobny zakres: analiza wpływu i luk.

  2. Kryteria odbioru to lista warunków, które system musi spełnić, żebyś odebrał etap i za niego zapłacił. Wpisujemy do nich wymagania bezpieczeństwa obok funkcji. Dostępy: własne konto z rolą dla każdej osoby, nadawane i odbierane przez wskazaną osobę, zamykane przy odejściu pracownika. Dziennik zdarzeń: prowadzony przez system zapis, kto, kiedy i co w nim zrobił, łącznie ze zmianami danych i uprawnień, nie do zmiany przez użytkownika. Kopie i odtwarzanie: system robi kopie sam, a odbiór obejmuje uruchomienie go z kopii. Aktualizacje: opisana droga poprawek bezpieczeństwa do systemu po uruchomieniu i ślad każdego wgrania. Oddzielenie środowisk: środowisko testowe, czyli osobna kopia systemu do prób, pracuje na danych testowych. Szyfrowanie: dane zapisane i przesyłane w postaci nieczytelnej bez klucza. Obsługa incydentów: system pokazuje, co się stało, kiedy i kogo dotyczy, i pozwala zapisać to do zgłoszenia. Wczesne ostrzeżenie o incydencie poważnym idzie do CSIRT sektorowego, zespołu przyjmującego zgłoszenia w Twoim sektorze, w 24 godziny od wykrycia.

  3. Dowody dla audytu powstają w trakcie projektu. Podmiot kluczowy objęty ustawą od dnia jej wejścia w życie przechodzi pierwszy audyt bezpieczeństwa systemu informacyjnego do 3 kwietnia 2028. Kolejne przypadają co najmniej raz na trzy lata; podmiot ważny przechodzi audyt na nakaz organu po incydencie poważnym albo innym naruszeniu ustawy. Z każdego etapu odkładamy do jednej teczki: wymagania z przepisem, projekt, wyniki testów z protokołem odtworzenia, protokoły odbioru, listę kont z dnia uruchomienia i spis aktualizacji.

  4. Gdy system buduje inny wykonawca, pracujemy po Twojej stronie: wpisujemy wymagania do zapytania ofertowego albo umowy, czytamy projekt wykonawcy pod ich kątem, uczestniczymy w odbiorach i zbieramy dowody. Zapisy umowy z wykonawcą, polityki i procedury to osobne zakresy; tu pracujemy na ich podstawie. Zabezpieczenie serwerów i sieci firmy niezależnie od przepisów to zakres „Bezpieczeństwo infrastruktury” w usłudze „Chmura i infrastruktura”.

Wynik

Co dostajesz

  • Lista wymagań bezpieczeństwa dla Twojego systemu, z przepisem przy każdej pozycji, gotowa do zakresu projektu albo zapytania ofertowego.
  • Kryteria odbioru dla każdego wymagania: co wykonawca pokazuje, na jakiej próbie i kto po Twojej stronie potwierdza wynik.
  • Protokół odbioru zabezpieczeń podpisany z wykonawcą, z listą braków i osobą odpowiedzialną za ich usunięcie.
  • Teczka dowodów dla audytu, ułożona według wymagań, z zasadami dopisywania kolejnych dowodów po uruchomieniu.

Przebieg

Jak przebiega praca

  1. Spisujemy wymagania.

    Z polityk firmy, wyniku analizy luk, jeśli jest, i zakresu systemu wybieramy, co go dotyczy. Wynik: lista wymagań z kryteriami odbioru.

  2. Pilnujemy budowy.

    Sprawdzamy w projekcie wykonawcy, jak spełni każde wymaganie, i na każdym etapie odkładamy dowody. Wynik: teczka zapełniana etap po etapie.

  3. Odbieramy zabezpieczenia na próbach.

    Zamykamy dostęp próbnemu użytkownikowi, uruchamiamy system z kopii, czytamy dziennik, przechodzimy przez próbne zgłoszenie incydentu. Wynik: protokół odbioru zabezpieczeń.

  4. Przekazujemy teczkę wskazanej osobie razem z zasadami jej prowadzenia.

    Wynik: teczka dowodów u Ciebie, prowadzona dalej przez Twój zespół albo przez nas.

Doświadczenie

Doświadczenie zespołu

Osoby z zespołu budowały w ochronie zdrowia platformę AI prowadzoną jako wyrób medyczny według FDA, CE i MDR. Platforma powstała na rynki Unii Europejskiej i USA.

Umów spotkanie

Umów rozmowę o problemie

Opisujesz proces albo system, który przestał wystarczać, i mówisz, co ma się zmienić. Rozmowa nic nie kosztuje.

Wybierz termin

Telefon: +48 455 406 404

Przed umową

Pytania, które zarząd powinien zadać wykonawcy systemu

  1. Które wymagania bezpieczeństwa są w zakresie i kryteriach odbioru, a które zostają po naszej stronie?
  2. Co zapisuje dziennik zdarzeń, jak długo to przechowuje i kto może go zmienić?
  3. Jak przy odbiorze sprawdzimy, że odejście pracownika kończy jego dostęp?
  4. Kiedy kopia zostanie odtworzona na próbę i kto podpisze protokół?
  5. Jak poprawki bezpieczeństwa trafiają do systemu po uruchomieniu i kto je wgrywa?
  6. Jakie dokumenty dostaniemy przy odbiorze i czy audytor zrozumie je bez wykonawcy?

Terminy powyżej opisują stan prawny na 20 września 2026; przed decyzją o zakresie sprawdzamy je ponownie. Zakres wymagań zależy od statusu firmy w ustawie i od tego, co system robi, dlatego zaczynamy od analizy.

KSC i NIS2

Inne zakresy tej usługi

Zobacz usługę: KSC i NIS2

Umowy z dostawcami

Lista dostawców, od których zależy działanie firmy, ocena każdego z nich i wymagania do umów i zapytań ofertowych odpowiadające obowiązkom z ustawy o KSC.

Zobacz zakres

Jak zaczynamy

  1. Rozmowa o problemie

    Opisujesz proces albo system, który przestał wystarczać, i mówisz, co ma się zmienić. Rozmowa nic nie kosztuje.

  2. Analiza pod NDA

    Badamy proces i systemy i oddajemy rekomendację z zakresem prac. Zakres, termin i cenę analizy znasz przed jej startem.

  3. Oferta

    Dostajesz zakres, zespół, harmonogram i cenę wdrożenia. Decydujesz, czy ruszamy.

Koszt analizy zaliczamy na poczet wdrożenia, jeśli je zamówisz.

Porozmawiajmy o projekcie

Telefon: +48 455 406 404 E-mail: contact@aliaxit.com

© 2026 ALIAX IT sp. z o.o. · ul. Boczna 28, 64-115 Wilkowice · KRS 0001102190 · NIP 6972399808 Polityka prywatności ·