Łańcuch dostaw w ustawie o KSC: czego wymagać od dostawców i co wpisać do umowy?

Twoi dostawcy nie muszą spełniać ustawy o KSCUstawa o KSC Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych. tylko dlatego, że Ty jej podlegasz. Ustawa nakłada obowiązek na Ciebie: masz zapewnić bezpieczeństwo i ciągłość łańcucha dostawŁańcuch dostaw Dostawcy sprzętu, oprogramowania i usług ICT, od których zależy świadczenie usługi. Ich bezpieczeństwo podmiot uwzględnia w swoim zarządzaniu ryzykiem., od którego zależy Twoja usługa. O umowach nie mówi ani słowa, ale bez postanowień w umowie trudno ten obowiązek wykonać i jeszcze trudniej wykazać, że się go wykonało. Umowy z dostawcami, od których usługa naprawdę zależy, trzeba więc przejrzeć i część z nich uzupełnić.

Wymagania wobec dostawcy, który sam nie jest podmiotem kluczowym ani ważnym, istnieją tylko w takim zakresie, w jakim wpisałeś je do umowy.

Czego ustawa o KSC wymaga w sprawie dostawców?

Art. 8 ust. 1 pkt 2 lit. e ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (ustawy o KSC) wymienia wśród środków technicznych i organizacyjnych, które podmiot kluczowyPodmiot kluczowy Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata. lub podmiot ważnyPodmiot ważny Podmiot z sektorów ustawy o KSC, który spełnia jej kryteria, ale nie jest podmiotem kluczowym. Wdraża SZBI i zgłasza incydenty poważne tak jak podmiot kluczowy. wdraża w ramach systemu zarządzania bezpieczeństwem informacjiSystem zarządzania bezpieczeństwem informacji Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów. (SZBI):

bezpieczeństwo i ciągłość łańcucha dostaw produktów ICT, usług ICT i procesów ICT, od których zależy świadczenie usługi, z uwzględnieniem związków pomiędzy bezpośrednim dostawcą sprzętu lub oprogramowania a podmiotem kluczowym lub podmiotem ważnym

W tym zdaniu są trzy rzeczy, które wyznaczają zakres pracy. Przepis mówi o ciągłości obok bezpieczeństwa, czyli pyta także o to, co się stanie, gdy dostawca przestanie działać. Ogranicza się do dostaw, „od których zależy świadczenie usługi”, więc firma sprzątająca i dostawca kawy zostają poza nim, o ile nie mają dostępu do systemów. Wskazuje wreszcie dostawcę bezpośredniego, tego, z którym masz umowę.

Art. 8 ust. 2 dodaje listę tego, co podmiot uwzględnia, wdrażając te środki:

1. podatnościPodatność Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV. związane z dostawcą sprzętu lub oprogramowania;
2. ogólną jakość produktów ICT, usług ICT i procesów ICT pochodzących od tego dostawcy;
3. wyniki skoordynowanej oceny bezpieczeństwa przeprowadzonej przez Grupę Współpracy z art. 22 ust. 1 dyrektywy NIS2Dyrektywa NIS2 Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. o cyberbezpieczeństwie w Unii. W Polsce wdraża ją ustawa o KSC po nowelizacji z 2026 r.;
4. wyniki postępowania w sprawie uznania za dostawcę wysokiego ryzyka z art. 67b ustawy o KSC.

Obok stoi art. 8 ust. 1 pkt 2 lit. b, czyli bezpieczeństwo w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego. Zakup nowego systemu podlega więc tym samym pytaniom co umowa serwisowa na stary.

Na tym ustawa kończy. Nie nakazuje aneksować umów, nie podaje listy klauzul ani nie mówi, jak często oceniać dostawcę. Kara pieniężna grozi za to, że SZBI „nie spełnia wymogów, o których mowa w art. 8 ust. 1” (art. 73 ust. 1 pkt 3), a jej górna granica to 10 000 000 euro albo 2 % przychodów dla podmiotu kluczowego i 7 000 000 euro albo 1,4 % przychodów dla podmiotu ważnego (art. 73 ust. 3 i 4). Od podmiotu kluczowego organ właściwy może w ramach nadzoru zażądać dowodów realizacji wymogów z art. 8 ust. 1 (art. 53 ust. 2 pkt 6), więc pytanie „co zrobiliście z dostawcami?” padnie prędzej czy później.

Podmioty, które 3 kwietnia 2026 r. spełniały przesłanki podmiotu kluczowego albo ważnego, mają na obowiązki z rozdziału 3 ustawy 12 miesięcy od tego dnia (art. 33 ust. 1 ustawy nowelizującej). Ministerstwo Cyfryzacji podaje datę 3 kwietnia 2027 r. Aneks wymaga zgody drugiej strony i na jej odpowiedź się czeka, dlatego umowy biorę na początek wdrożenia.

Są dwa wyjątki. Podmiot ważny będący podmiotem publicznymPodmiot publiczny Podmiot z sektora „podmioty publiczne” w załączniku nr 1 lub 2 do ustawy o KSC. Podmiot publiczny, który jest podmiotem ważnym, wdraża SZBI według załącznika nr 4 do ustawy. nie stosuje art. 8 ust. 1, tylko załącznik nr 4 (art. 8 ust. 3). W części obowiązkowej załącznik wymaga udokumentowania mechanizmów ochrony informacji przy korzystaniu z usług dostawcy chmury obliczeniowej lub centrum przetwarzania danych (część I pkt 3 lit. c). Postanowienia umowne są dopiero w części II, wśród środków, które system „może dodatkowo obejmować”: „zawieranie w umowach serwisowych podpisanych ze stronami trzecimi zapisów gwarantujących odpowiedni poziom bezpieczeństwa systemów informacyjnych” (pkt 7).

Drugi wyjątek to sektor bankowości i infrastruktury rynków finansowych, do którego art. 8 ust. 1 pkt 2 lit. e się nie stosuje (art. 8i ust. 1); Ministerstwo Cyfryzacji wyjaśnia, że pierwszeństwo ma tam unijne rozporządzenie DORA o odporności cyfrowej sektora finansowego.

Czy dostawca też musi spełniać ustawę?

Sam fakt, że firma dostarcza coś podmiotowi kluczowemu, nie czyni jej adresatem ustawy. Dyrektywa NIS2 odsyła w tej sprawie do umowy. Motyw 85 mówi:

Podmioty kluczowe i ważne należy w szczególności zachęcać, aby włączały środki zarządzania ryzykiem w cyberbezpieczeństwie do ustaleń umownych z bezpośrednimi dostawcami i usługodawcami. Podmioty te mogłyby rozważyć ryzyko pochodzące od dostawców i usługodawców z innych poziomów.

Część dostawców podlega ustawie z własnego tytułu. Załącznik nr 1 zawiera sektor „Zarządzanie usługami ICT” z dostawcami usług zarządzanych i dostawcami usług zarządzanych w zakresie cyberbezpieczeństwa, a ci drudzy są podmiotami kluczowymi już od wielkości małego przedsiębiorcy (art. 5 ust. 1 pkt 3). Firma, która administruje Twoimi serwerami albo prowadzi dla Ciebie monitoring bezpieczeństwa, może więc mieć własne obowiązki z art. 8 i art. 11. Jeśli ma, art. 11 ust. 2b nakazuje jej informować użytkowników swoich usług o incydencie poważnym, który ma niekorzystny wpływ na świadczenie tych usług.

Producent oprogramowania zwykle w tej grupie nie jest. Ministerstwo Cyfryzacji na pytanie, czy dostawcy oprogramowania mieszczą się w definicji dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa, odpowiada: „Nie, nie wchodzą. Dostawcy oprogramowania co do zasady są regulowani przez Cyber Resilience Act”. Kilkunastoosobowa firma, która napisała i utrzymuje Twój system dziedzinowy, najczęściej nie ma więc wobec Ciebie żadnych obowiązków z ustawy o KSC.

To, że dostawca jest w wykazie podmiotów kluczowych i ważnych, niczego po Twojej stronie nie załatwia. Art. 8 ust. 2 nakazuje Ci uwzględnić podatności i jakość jego produktów niezależnie od jego statusu, a jego SZBI obejmuje jego usługę, nie Twoją. Wytyczne ENISA do rozporządzenia 2024/2690 traktują status dostawcy tylko jako jedno z kryteriów wyboru: czy podlega NIS2 albo Cyber Resilience Act i czy ma oświadczenie o zgodności.

Osobną sprawą jest dostawca wysokiego ryzyka. Minister właściwy do spraw informatyzacji może w decyzji uznać dostawcę sprzętu lub oprogramowania za dostawcę wysokiego ryzyka (art. 67b ust. 15), a decyzja wskazuje typy produktów ICT, rodzaje usług ICT lub konkretne procesy ICT, których dotyczy (ust. 16). Podmioty wskazane w art. 67b ust. 1, wśród nich podmioty kluczowe i ważne spoza podsektora komunikacji elektronicznej, nie wprowadzają ich wtedy do użytkowania, a posiadane wycofują nie później niż w ciągu 7 lat od ogłoszenia decyzji w Monitorze Polskim (art. 67c ust. 1). Za niewykonanie tego obowiązku grozi kara (art. 73 ust. 1 pkt 18). Dla umów oznacza to jedno praktyczne pytanie przy każdym większym zakupie: co się dzieje z kontraktem, jeśli taka decyzja obejmie kupowany produkt.

Skąd wiadomo, co wpisać do umowy?

Skoro ustawa milczy, zostają trzy źródła, na które można się powołać przed audytorem i organem.

Pierwszym są odpowiedzi Ministerstwa Cyfryzacji. W pkt 3.9 ministerstwo pisze, że podmioty powinny m.in. znać swój łańcuch dostaw i związane z nim ryzyka oraz:

dbać o odpowiednie wymagania z zakresu cyberbezpieczeństwa w umowach, a w przypadku umów adhezyjnych z globalnymi dostawcami wybierać tych, którzy posiadają certyfikację z zakresu cyberbezpieczeństwa własnych produktów i usług

W pkt 6.5, o momencie wykrycia incydentu, dodaje: „W umowach z dostawcami należy zawrzeć obowiązek dostawcy o niezwłocznym informowaniu o incydencie związanym z usługą dostawcy”. W liście kroków wdrożenia SZBI wymienia też „Przegląd dotychczasowych dostawców sprzętu i oprogramowania, przegląd umów zawartych z tymi dostawcami”. To nie jest prawo, ale to stanowisko urzędu, który ustawę przygotował.

Drugim jest rozporządzenie wykonawcze Komisji 2024/2690. Wiąże wprost tylko wybranych dostawców usług cyfrowych i infrastruktury cyfrowej, na przykład dostawców chmury, centrów danych i usług zarządzanych. Dla pozostałych jest najbardziej konkretnym opisem tego, co w prawie unijnym znaczy „bezpieczeństwo łańcucha dostaw”. Pkt 5.1 załącznika wymaga polityki bezpieczeństwa łańcucha dostaw z kryteriami wyboru dostawców, pkt 5.1.4 wymienia osiem elementów umowy, a pkt 5.2 nakazuje prowadzić rejestr bezpośrednich dostawców i usługodawców. Wytyczne ENISA z czerwca 2025 r. dopisują do każdego punktu przykłady dowodów.

Trzecim jest norma PN-EN ISO/IEC 27001. Zabezpieczenia 5.19 do 5.23 z załącznika A dotyczą relacji z dostawcami, łańcucha dostaw ICT, monitorowania usług dostawców i usług w chmurze, a 5.20 mówi wprost: „Należy ustanowić istotne wymagania dotyczące bezpieczeństwa informacji i uzgodnić je z każdym dostawcą, w zależności od typu relacji z dostawcą”. Kto ma SZBI według tej normy, ma już miejsce na te wymagania. O różnicach między normą a ustawą piszę w tekście SZBI według ustawy o KSC i NIS2.

Co wpisać do umowy z dostawcą?

Biorę listę z pkt 5.1.4 załącznika do rozporządzenia 2024/2690 i dla każdej pozycji piszę postanowienie, które da się sprawdzić. Rozporządzenie zastrzega, że elementy wpisuje się „w stosownych przypadkach” i z uwzględnieniem wyników oceny ryzyka, więc nie każda umowa potrzebuje wszystkich ośmiu.

Do tej listy dodaję dwie pozycje, których w pkt 5.1.4 nie ma, a które wynikają z samej ustawy i z praktyki incydentów.

Pierwsza to ciągłość. Art. 8 ust. 1 pkt 2 lit. e wymienia ją obok bezpieczeństwa, a rozporządzenie mówi o umowach o gwarantowanym poziomie usług. Czas reakcji i czas przywrócenia usługi w umowie muszą się zgadzać z czasami, które zarząd zaakceptował w planie ciągłości działania. Jeśli plan zakłada odtworzenie systemu w 24 godziny, a umowa serwisowa daje dostawcy trzy dni robocze na reakcję, to jedna z tych liczb jest nieprawdziwa. Więcej o tych czasach jest w tekście o planie ciągłości działania.

Druga to zasady dostępu. Dostawca z szerokim, stałym dostępem do sieci klienta bywa najkrótszą drogą do jego systemów. ENISA w raporcie o zagrożeniach za 2025 r. pisze, że przestępcy coraz częściej biorą na cel zewnętrznych usługodawców, najpewniej dlatego, że tak atakuje się wydajniej. W umowie zapisuję więc, że dostęp zdalny odbywa się wyłącznie przez wskazany kanał, na imienne konta, na czas zlecenia i z rejestrowaniem sesji, a po stronie podmiotu ktoś ten dostęp włącza i wyłącza.

Dobra klauzula bezpieczeństwa to taka, przy której po roku potrafisz pokazać zapis, że ktoś sprawdził jej wykonanie.

Jeśli dostawca przetwarza dla Ciebie dane osobowe, część tych postanowień już masz w umowie powierzenia. Art. 28 ust. 3 RODO wymaga m.in. środków bezpieczeństwa z art. 32, zasad korzystania z dalszych podmiotów przetwarzających, zwrotu lub usunięcia danych po zakończeniu usługi oraz umożliwienia audytów.

Umowa powierzenia chroni jednak dane osobowe, a ustawa o KSC pyta o usługę. Sterownik w przepompowni nie przetwarza danych osobowych i żadna umowa powierzenia go nie obejmuje. Nie tworzę dwóch równoległych zestawów klauzul: wymagania bezpieczeństwa i zgłaszanie zdarzeń opisuję raz, w jednym załączniku, do którego odsyłają obie umowy.

Jak napisać klauzulę o incydencie?

To postanowienie decyduje o tym, czy zdążysz z własnym zgłoszeniem. Podmiot kluczowy lub ważny zgłasza wczesne ostrzeżenie o incydencie poważnym do CSIRT sektorowego niezwłocznie, najpóźniej w ciągu 24 godzin od momentu jego wykrycia (art. 11 ust. 1 pkt 4). Ministerstwo Cyfryzacji wyjaśnia, że wykrycie to moment, w którym podmiot uzyskał informację o zdarzeniu, i że może ją uzyskać także od dostawcy usługi.

Zegar ustawowy rusza więc, gdy się dowiesz, ale szkoda biegnie od chwili zdarzenia. Każda godzina, przez którą dostawca ustala u siebie, co się stało, i nie mówi nic klientom, to godzina, w której nie zmieniasz haseł, nie odcinasz integracji i nie ostrzegasz użytkowników. Dwa polskie przykłady z ostatnich dni opisałem w aktualnościach: włamanie do Fakturowni i incydent w FELG Dent. Fakturownia wykryła nieuprawniony dostęp 28 września 2026 r., a imienne zawiadomienia do właścicieli kont zaczęła wysyłać 1 października. FELG Software dowiedziała się o incydencie 28 września i zawiadomiła klientów 1 października, prosząc ich zarazem, żeby wstrzymali się ze zgłoszeniem do Prezesa UODO do jej potwierdzenia.

Nie oceniam tu tych firm, bo ustalenie zakresu wycieku naprawdę trwa. Zwracam uwagę na to, co wynika z tych spraw dla umowy:

1. Termin w godzinach, liczony od wykrycia zdarzenia przez dostawcę, a nie od zakończenia jego analizy. „Niezwłocznie” każda strona rozumie inaczej. Rozporządzenie 2024/2690 mówi o zgłaszaniu „bez zbędnej zwłoki”; ja wpisuję liczbę wyraźnie krótszą niż 24 godziny dla dostawców, którzy mają dostęp do moich systemów albo przechowują moje dane.
2. Zgłoszenie wstępne z tym, co wiadomo, i obowiązek uzupełniania. Dostawca nie czeka z pierwszą informacją, aż będzie znał listę rekordów.
3. Kanał i adresat: numer telefonu i adres, które działają także wtedy, gdy nie działa poczta jednej ze stron, oraz osoba po mojej stronie, która wie, co z taką wiadomością zrobić.
4. Minimalna treść: co się stało, od kiedy, których usług i danych dotyczy, co dostawca już zrobił i co ja mam zrobić u siebie.
5. Współpraca przy obsłudze: dostęp do logów dotyczących mojej usługi i zakaz ich kasowania do zakończenia sprawy, bo sprawozdanie końcowe z art. 11 ust. 1 pkt 4c będę pisał ja, a nie dostawca.
6. Zakres zdarzeń: także incydent, który u dostawcy nie dotknął moich danych, ale dotknął środowiska, z którego dostawca łączy się z moją siecią.

Przy danych osobowych działa równolegle art. 33 ust. 2 RODO: podmiot przetwarzający zgłasza naruszenie administratorowi „bez zbędnej zwłoki”. Od chwili, gdy administrator stwierdzi naruszenie, biegną jego 72 godziny na zgłoszenie do Prezesa UODO (art. 33 ust. 1 RODO), niezależnie od terminów z ustawy o KSC. Jeden kanał i jeden termin w umowie obsługują oba obowiązki; dwa różne tryby powiadamiania kończą się tym, że w nocy nikt nie wie, którego użyć.

Czy trzeba aneksować umowy już zawarte?

Ustawa nowelizująca nie ma przepisu przejściowego o umowach i nie nakazuje ich zmieniać. Obowiązek z art. 8 ust. 1 pkt 2 lit. e dotyczy jednak wszystkich dostaw, od których zależy usługa, także tych zakontraktowanych pięć lat temu. Wytyczne ENISA mówią o wpisywaniu wymagań do wszystkich istotnych umów nowych i odnawianych, a Ministerstwo Cyfryzacji o przeglądzie umów już zawartych. Układam to w cztery grupy.

Podział bierze się z szacowania ryzyka i z analizy wpływu na działalność, a nie z wartości umowy. Najgroźniejszy bywa serwisant z umową na kilka tysięcy złotych rocznie i hasłem administratora do stacji operatorskiej.

Z dostawcą, którego nie da się negocjować, postępuję tak, jak radzą ministerstwo i ENISA. Wybieram takiego, który ma certyfikację i publikuje swoje zobowiązania dotyczące bezpieczeństwa, pilnuję łatwego eksportu danych i krótkich okresów rozliczeniowych oraz trzymam krótką listę alternatyw. Mniejszym podmiotom ENISA podpowiada jeszcze wspólne negocjacje w grupie podobnych organizacji albo przez stowarzyszenie, co w branży wodociągowej czy wśród gmin korzystających z tego samego systemu dziedzinowego jest realne.

Podmioty, które kupują w trybie ustawy - Prawo zamówień publicznych, mają dodatkowe ograniczenie. Istotna zmiana zawartej umowy wymaga nowego postępowania (art. 454 ust. 1 Pzp), a art. 455 wylicza zmiany dopuszczalne bez niego, w tym przewidziane w dokumentach zamówienia jasnymi postanowieniami umownymi (ust. 1 pkt 1) i zmiany o niewielkiej wartości (ust. 2). Czy dopisanie wymagań bezpieczeństwa do konkretnej umowy mieści się w tych wyjątkach, ocenia prawnik od zamówień, nie pełnomocnik. Na pewno mogę zrobić dwie rzeczy: wpisać wymagania do dokumentów każdego nowego postępowania i dodać do wzoru umowy klauzulę, która pozwoli je aktualizować.

Zostaje przypadek, w którym dostawca odmawia. Nie mam na to eleganckiej odpowiedzi. Ryzyko zostaje wtedy po stronie podmiotu, a ENISA przypomina w wytycznych, że podmiot pozostaje w pełni odpowiedzialny za integralność, dostępność i poufność usług świadczonych przez dostawców. Zapisuję odmowę w rejestrze ryzyka, proponuję środki po własnej stronie (ograniczenie dostępu, własne kopie danych, monitoring połączeń) i przedstawiam kierownikowi podmiotu decyzję: akceptujemy, zmieniamy dostawcę w określonym terminie albo dokładamy zabezpieczeń. To jego decyzja z art. 8d pkt 1, a odpowiedzialność z art. 8c zostaje przy nim także wtedy, gdy zadania powierzył komuś innemu. Piszę o tym w tekście Co kierownik podmiotu może powierzyć pełnomocnikowi?.

Odmowa dostawcy nie zwalnia z obowiązku, tylko zamienia punkt w umowie na pozycję w rejestrze ryzyka z podpisem kierownika.

Co oprócz umowy?

Umowa jest jednym środkiem z kilku. ENISA przebadała w 2022 r. 1 081 organizacji z 27 państw członkowskich: 86 % miało politykę bezpieczeństwa łańcucha dostaw, 47 % miało na ten cel budżet, a 76 % nie miało wyznaczonych ról i odpowiedzialności. Dokument jest więc prawie wszędzie, a człowieka, który by go wykonywał, w trzech organizacjach na cztery brakuje. W podmiocie, w którym pracuję, pilnuję czterech rzeczy.

Rejestr dostawców. Pkt 5.2 załącznika do rozporządzenia 2024/2690 wymaga dwóch pól: punktu kontaktowego dla każdego bezpośredniego dostawcy i wykazu produktów, usług i procesów ICT, które dostarcza. Dopisuję grupę z tabeli wyżej, rodzaj dostępu, datę końca umowy i datę ostatniej oceny. Rejestr powstaje z inwentaryzacji aktywów (art. 8 ust. 1 pkt 2 lit. m), bo przy każdym systemie i tak pytam, kto go dostarczył i kto go serwisuje.

Kryteria wyboru przed zakupem. Rozporządzenie wymienia w pkt 5.1.2 praktyki cyberbezpieczeństwa dostawcy, w tym procedury bezpiecznego wytwarzania, zdolność do spełnienia wymagań zamawiającego, jakość i odporność produktu oraz możliwość dywersyfikacji źródeł dostaw. ENISA dodaje historię incydentów dostawcy i ryzyko uzależnienia od niego. Kryteria działają tylko wtedy, gdy dział zakupów pyta o nie przed wyborem oferty, a nie po podpisaniu umowy.

Ocena w trakcie umowy. Art. 8 ust. 2 pkt 1 nakazuje uwzględniać podatności związane z dostawcą, więc śledzę komunikaty o podatnościach w produktach z rejestru i zapisuję, co z nimi zrobiono. Rozporządzenie wymaga w pkt 5.1.6 i 5.1.7 przeglądu w zaplanowanych odstępach i po poważnym incydencie u dostawcy, a ENISA radzi przegląd polityki co najmniej raz w roku. Dla pierwszej grupy z tabeli robię raz w roku krótką ocenę: ankieta albo sprawozdanie z audytu, przegląd listy osób z dostępem, przegląd incydentów i dotrzymania czasów z umowy.

Zapisy. Dokumentacja operacyjna z art. 10 ust. 4 ustawy o KSC to „zapisy poświadczające wykonywanie czynności” opisanych w dokumentacji normatywnej. Jeśli polityka mówi, że dostawców krytycznych oceniam raz w roku, audytor poprosi o oceny z dwóch lat, a nie o politykę. To samo pokazuję zarządowi; jak taki ciąg dowodów wygląda w całości, opisałem w tekście Skąd zarząd ma wiedzieć, że jego firma ma odpowiednie zabezpieczenia?.

Od czego zacząć?

Gdybym wchodził dziś do podmiotu, który ma segregator umów i nikogo, kto czytał je pod tym kątem, zrobiłbym do końca roku pięć rzeczy:

1. Spisał bezpośrednich dostawców systemów, od których zależy usługa, z osobą kontaktową i rodzajem dostępu.
2. Podzielił ich na cztery grupy i uzgodnił ten podział z kierownikiem podmiotu.
3. Przeczytał umowy z pierwszej grupy pod kątem ośmiu elementów z pkt 5.1.4 oraz czasów reakcji i zasad dostępu, i zapisał braki.
4. Wysłał do tych dostawców projekt aneksu albo załącznika z wymaganiami, zaczynając od klauzuli o incydencie i zasad zdalnego dostępu.
5. Przygotował z prawnikiem wzór wymagań bezpieczeństwa do nowych umów i zamówień, żeby lista braków przestała rosnąć.

Po tych pięciu krokach umowy z drugiej i trzeciej grupy nadal czekają na swoją kolej, a część dostawców jeszcze nie odpowiedziała. W rejestrze jest za to przy każdym nazwisko, numer telefonu i termin, w którym mają zadzwonić, gdy coś się u nich stanie.

Stan prawny na dzień publikacji: 05.10.2026. Wpis nie był od tego czasu weryfikowany pod kątem zmian w przepisach. Wpis jest informacją ogólną, nie poradą prawną (zasady publikacji).