KSC i NIS2 w umowie z software house’em. Jakie wymagania klient przeniesie na dostawcę IT?

Software house utrzymuje system obsługujący zamówienia, dokumentację medyczną, logistykę albo produkcję. Sam nie uważa się za podmiot kluczowy lub ważny. Dostaje jednak od klienta nową ankietę bezpieczeństwa i projekt aneksu: zgłoszenie każdego incydentu w ciągu dwóch godzin, coroczny audyt na koszt dostawcy, zgoda na wszystkich podwykonawców i odpowiedzialność za „pełną zgodność z KSC”.

Takie oczekiwania mogą wynikać z przygotowań klienta do nowych obowiązków. Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, wdrażająca NIS2, weszła w życie 3 kwietnia 2026 r. Przewiduje jednak okresy dostosowawcze. Samo wejście przepisów w życie nie oznacza, że każdy nowy podmiot od tego dnia miał już wykonywać wszystkie obowiązki.

Bezpieczeństwo dostawców ma w tych przepisach konkretne miejsce. Jeżeli usługa klienta zależy od zewnętrznego systemu, wewnętrzna polityka bezpieczeństwa nie wystarczy. Klient potrzebuje informacji i współpracy software house’u. Umowa powinna przypisać zadania, terminy i odpowiedzialność do usługi, którą dostawca rzeczywiście kontroluje.

Aktualizacja i weryfikacja prawna: 18 września 2026 r. Podstawą są ustawa KSC z nowelizacją opublikowaną w Dz.U. z 2026 r. poz. 252 oraz wskazane niżej źródła urzędowe.

Czego dowiesz się z tego tekstu?

W skrócie

• KSC obejmuje bezpieczeństwo łańcucha dostaw ICT. Klient może więc potrzebować dodatkowych zobowiązań od software house’u, SaaS, dostawcy chmury i maintenance.
• Pisanie kodu dla podmiotu objętego KSC samo w sobie nie nadaje dostawcy statusu podmiotu kluczowego lub ważnego. Osobnej oceny wymaga np. świadczenie usług zarządzanych.
• Termin alertu w godzinę lub dwie jest ustaleniem umownym. Nie istnieje jeden taki termin ustawowy dla każdego dostawcy IT.
• Coroczny audyt na koszt software house’u i gwarancja zgodności całego klienta z KSC nie wynikają automatycznie z ustawy.
• Harmonogram wdrożenia zależy od statusu podmiotu. Dotychczasowi operatorzy usług kluczowych wymagają osobnego sprawdzenia.

Czy KSC obejmuje software house?

Software house nie staje się podmiotem kluczowym lub ważnym tylko dlatego, że ma klienta objętego KSC. Może jednak sam podlegać ustawie, jeżeli jego usługi, skala i pozostałe okoliczności odpowiadają ustawowym kryteriom. Nazwa firmy ani określenie „software house” na stronie nie rozstrzygają tej kwalifikacji.

Ustawa definiuje dostawcę usług zarządzanych przez odwołanie do instalacji, eksploatacji lub konserwacji produktów, usług, procesów ICT albo systemów informacyjnych, realizowanych przez wsparcie lub aktywną administrację na miejscu bądź zdalnie. Punkt wyjścia stanowią art. 2, art. 5 i załączniki do ustawy KSC.

Analizy wymagają zwłaszcza usługi obejmujące:

• stałe utrzymanie systemów lub infrastruktury klienta;
• aktywną administrację środowiskiem;
• zarządzanie dostępami, konfiguracją i aktualizacjami;
• monitoring systemów;
• zarządzaną chmurę lub hosting;
• zarządzane usługi cyberbezpieczeństwa, które mają własną kategorię ustawową.

Samo wytworzenie aplikacji i przekazanie jej klientowi nie przesądza jeszcze o podleganiu KSC. Trzeba sprawdzić rzeczywistą usługę, kryteria wielkości, szczególne przypadki ustawowe i właściwość jurysdykcyjną. Nie każdy SaaS jest też automatycznie tą samą kategorią dostawcy. W ankiecie klienta warto podać wynik własnej kwalifikacji i jej podstawę, zamiast zaznaczać „nie dotyczy” wyłącznie na podstawie profilu działalności.

Dla objętych jego zakresem dostawców, m.in. chmury, usług zarządzanych i zarządzanych usług bezpieczeństwa, znaczenie ma również rozporządzenie wykonawcze UE 2024/2690. Doprecyzowuje wymagania zarządzania ryzykiem i przypadki incydentów poważnych. Nie należy utożsamiać go z dobrowolną checklistą ani automatycznie rozszerzać na każdy software house.

Dlaczego klient przenosi wymagania NIS2 na dostawcę IT?

Art. 21 ust. 2 lit. d dyrektywy NIS2 obejmuje bezpieczeństwo łańcucha dostaw, w tym relacje z bezpośrednimi dostawcami i usługodawcami. W Polsce art. 8 KSC uwzględnia bezpieczeństwo i ciągłość dostaw ICT w systemie zarządzania bezpieczeństwem informacji, czyli SZBI.

Klient potrzebuje zatem odpowiedzi na pytania:

• które jego usługi zależą od dostawcy;
• jaki dostęp dostawca ma do systemów i danych;
• z jakich podwykonawców i usług chmurowych korzysta;
• jak obsługuje podatności i incydenty;
• jak odtwarza usługę po zakłóceniu;
• jakie dowody działania zabezpieczeń potrafi przedstawić.

W ochronie zdrowia Centrum e-Zdrowia publikuje materiały pomagające ustalić zakres nowych obowiązków KSC. Nie oznacza to, że każda placówka medyczna ma identyczny status. Przed narzuceniem dostawcy gotowego aneksu trzeba ustalić sytuację konkretnego klienta i znaczenie systemu dla jego usług.

Pomocniczo można wykorzystać unijny zestaw narzędzi bezpieczeństwa łańcuchów dostaw ICT. To materiał do oceny ryzyka, a nie ustawa nakazująca wpisanie do każdej umowy tych samych klauzul.

Co powinien zawierać aneks cyberbezpieczeństwa?

Dobry aneks łączy wymagania klienta z zakresem usług i ryzykiem systemu. Strona wydarzenia firmowego i platforma obsługująca dokumentację medyczną mogą wymagać zupełnie innego poziomu kontroli. W praktyce sprawdziłbym sześć obszarów:

• Incydenty: jakie zdarzenia dotyczą usługi, kiedy wysłać alert i jak aktualizować informacje.
• Podatności: jak określić pilność poprawki, kto ją wdraża i co zrobić przed jej udostępnieniem.
• Audyt: jakie dowody otrzyma klient, kiedy może przeprowadzić kontrolę i kto pokrywa jej koszty.
• Podwykonawcy: których trzeba ujawnić, jak informować o zmianie i rozpatrywać sprzeciw.
• Ciągłość: jakie są czasy odtworzenia, zasady backupu i zależności od innych usług.
• Odpowiedzialność: które naruszenie obciąża dostawcę i jakie działania pozostają po stronie klienta.

Zanim zaakceptujesz „pełną zgodność z KSC”, poproś o wskazanie systemu, obowiązku i procesu, za który masz odpowiadać. Dopiero wtedy można ocenić koszt, termin i ryzyko.

Ile czasu dostawca ma na zgłoszenie incydentu?

Umowny alert do klienta i ustawowe zgłoszenie do CSIRT to dwa różne obowiązki. W modelu wynikającym z art. 11 KSC wczesne ostrzeżenie o incydencie poważnym przekazuje się niezwłocznie, najpóźniej w ciągu 24 godzin od wykrycia, a zgłoszenie najpóźniej w ciągu 72 godzin. Sprawozdanie końcowe co do zasady następuje w ciągu miesiąca od zgłoszenia. Ustawa przewiduje wyjątki, m.in. dla dostawców usług zaufania, oraz odrębne zasady przy trwającej obsłudze incydentu.

To opis docelowej procedury. Moment, od którego konkretny podmiot musi ją wykonywać, trzeba sprawdzić razem z przepisami przejściowymi, opisanymi w dalszej części tekstu. Termin maksymalny nie oznacza przy tym prawa do czekania, jeżeli zgłoszenie można przekazać wcześniej.

Klient potrzebuje danych od dostawcy odpowiednio szybko, żeby ocenić skutki i wykonać własne obowiązki. Można więc uzgodnić alert np. w godzinę lub dwie, ale trzeba wskazać:

• jakie zdarzenia uruchamiają ten termin, w tym uzasadnione podejrzenia istotnego wpływu na usługę;
• od jakiego momentu termin jest liczony;
• czy obsługa działa całodobowo, także w weekendy;
• jakie informacje wystarczą w pierwszej wiadomości;
• co zrobić, gdy zwykły kanał komunikacji nie działa;
• kto odbiera i potwierdza zgłoszenie.

Pierwszy alert nie powinien czekać na zakończenie analizy przyczyny. Przy dużym zdarzeniu dostawca zwykle zna najpierw objawy i dotknięte środowisko. Te informacje trzeba przekazać, a resztę uzupełniać według ustalonego rytmu.

Czy każda awaria jest incydentem i kto zgłasza ją do CSIRT?

Nie każde zdarzenie techniczne jest incydentem poważnym. Nie można jednak uznać, że awaria bez ataku z definicji pozostaje poza cyberbezpieczeństwem. Przypadkowe usunięcie danych albo przerwa w zasilaniu również mogą naruszyć dostępność lub integralność systemu. Kwalifikacja zależy od zdarzenia, skutków i właściwych kryteriów, a nie tylko od obecności napastnika.

Umowa powinna rozróżniać potencjalne zdarzenie, podatność, incydent i incydent mogący spełnić kryteria poważnego. Dostawca przekazuje fakty techniczne; klient ocenia ich wpływ na własne usługi i obowiązki. Software house nie zawsze zna liczbę dotkniętych użytkowników, zależności między systemami i pełne straty biznesowe.

Przykładowy podział pracy może wyglądać tak:

• dostawca wykrywa zdarzenie w objętym usługą środowisku, zabezpiecza logi i wysyła alert;
• klient przekazuje informacje o wpływie na działalność;
• strony uzupełniają opis techniczny i skutki;
• podmiot zobowiązany dokonuje kwalifikacji oraz zgłoszenia do właściwego CSIRT, sam lub przez upoważnioną osobę;
• dostawca wspiera obsługę, aktualizacje i raport końcowy.

Powierzenie obsługi zgłoszeń dostawcy nie zwalnia klienta z jego ustawowej odpowiedzialności. Jeżeli software house sam podlega KSC, może mieć równoległy obowiązek dotyczący własnej usługi. Nie powinien zakładać, że zgłoszenie klienta zawsze załatwia również jego sprawę.

Przy danych osobowych działa dodatkowo RODO. Procesor po stwierdzeniu naruszenia informuje administratora bez zbędnej zwłoki, co przypomina UODO w wyjaśnieniach o zgłaszaniu naruszeń. Zgłoszenie do CSIRT nie zastępuje oceny obowiązków wobec Prezesa UODO. W aneksie trzeba zsynchronizować oba procesy, a nie zostawić sprzeczne terminy w umowie głównej i umowie powierzenia.

Jak ustalić terminy usuwania podatności?

Termin poprawki warto powiązać z krytycznością, możliwością wykorzystania podatności, ekspozycją systemu i dostępnymi środkami ograniczającymi ryzyko. CVSS może być jednym z kryteriów, ale wynik punktowy nie mówi wszystkiego. Znaczenie ma też to, czy:

• podatność jest już wykorzystywana w atakach;
• podatny komponent jest rzeczywiście używany u klienta;
• system jest dostępny z Internetu;
• wykorzystanie luki wymaga wcześniejszego dostępu;
• istnieje poprawka lub skuteczne obejście;
• aktualizacja może zakłócić działanie usługi.

W umowie opisałbym źródła informacji, klasyfikację, termin alertu, plan naprawczy, docelowy czas wdrożenia oraz środki awaryjne. Osobno trzeba ustalić testy, akceptację zmiany i obowiązki klienta związane z oknem serwisowym. Odłożenie instalacji przez klienta powinno mieć udokumentowane skutki i uzgodnione zabezpieczenia zastępcze.

Nie wpisywałbym gwarancji usunięcia każdej luki w tym samym czasie, jeżeli część poprawek zależy od producenta biblioteki lub chmury. Dostawca nadal może odpowiadać za ocenę ryzyka, powiadomienie, obejście i wdrożenie poprawki po jej udostępnieniu. Przykład takiego procesu opisuję w artykule o CVE, PAC4J i odpowiedzialności za obsługę podatności.

Jak uregulować audyt dostawcy?

Prawo klienta do audytu powinno mieć zakres odpowiadający usłudze. Nie daje mu automatycznie dostępu do całej infrastruktury, kodu i danych innych klientów. Rozsądnym punktem wyjścia jest model stopniowy: dokumenty i istniejące raporty, potem wyjaśnienia, a kontrola techniczna, gdy wcześniejsze dowody nie wystarczają.

Dostawca może przedstawić:

• opis zarządzania bezpieczeństwem i zakres certyfikacji;
• odpowiednio ograniczone wyniki testów penetracyjnych oraz audytów;
• procedurę obsługi incydentów;
• plan ciągłości i dowody testów odtworzeniowych;
• plan usunięcia stwierdzonych niezgodności.

Umowa powinna określać częstotliwość, wyprzedzenie, poufność, kwalifikacje audytora, koszty i zasady dostępu. Przy poważnym incydencie lub uzasadnionym podejrzeniu naruszenia można przewidzieć tryb nadzwyczajny. Te uzgodnienia nie ograniczą ustawowych uprawnień organu nadzoru.

Trzeba też odróżnić audyt podmiotu kluczowego wymagany przez KSC od audytu jego dostawcy wynikającego z umowy. Coroczna kontrola software house’u na jego koszt jest postulatem negocjacyjnym, a nie uniwersalnym wymogiem KSC. Przy powierzeniu danych zakres współpracy audytowej musi dodatkowo uwzględniać art. 28 RODO.

Którzy podwykonawcy wymagają kontroli klienta?

Lista istotnych podwykonawców powinna odpowiadać ryzyku usługi. Zwykle trzeba przyjrzeć się podmiotom, które hostują system, monitorują go, wykonują backup, utrzymują ważny komponent albo mają dostęp do danych i kont uprzywilejowanych. Firma dostarczająca papier do biura nie wymaga takiej samej procedury jak operator środowiska produkcyjnego.

Można ustalić listę podwykonawców, sposób informowania o zmianie, termin na uzasadniony sprzeciw i dostępne rozwiązania, jeżeli klient zmiany nie akceptuje. W standardowym SaaS zobowiązanie do uzyskiwania indywidualnej zgody każdego klienta na każdą zmianę narzędzia bywa operacyjnie niewykonalne.

Przy dalszym powierzeniu danych osobowych swoboda kontraktowa ma granice. Art. 28 ust. 2 RODO wymaga uprzedniej szczegółowej lub ogólnej pisemnej zgody administratora. Przy zgodzie ogólnej trzeba informować o zamierzonych zmianach i umożliwić sprzeciw. Klauzula KSC nie zastępuje tej procedury.

Dostawca powinien też zadbać o adekwatne wymagania wobec własnych istotnych podwykonawców. Obietnica wysłania alertu w godzinę jest mało wiarygodna, jeżeli operator hostingu zobowiązał się poinformować software house dopiero następnego dnia roboczego.

Jak połączyć ciągłość działania z SLA?

SLA określa oczekiwany poziom usługi, a plan ciągłości opisuje działania przy poważnym zakłóceniu. Umowa powinna łączyć dostępność, kopie zapasowe, odtwarzanie i komunikację. Sama kara za niedostępność nie przywróci systemu.

Dwa parametry warto wyjaśnić biznesowi wprost:

• RTO określa docelowy czas przywrócenia działania;
• RPO określa akceptowalną utratę danych wyrażoną w czasie, czyli jak daleko wstecz może sięgać punkt odtworzenia.

Klient powinien powiedzieć, jak długo może działać bez systemu i jaką utratę danych potrafi obsłużyć. Dostawca powinien pokazać, jakie parametry osiągnie za uzgodnioną cenę, jak je testuje oraz od jakich usług zewnętrznych zależy. Trzeba uwzględnić zwykłą awarię, incydent, utratę danych, niedostępność chmury i ewentualną pracę ręczną.

Maintenance może obejmować aktualizacje i bezpieczeństwo przez cały okres wsparcia. Szerszy kontekst produktowy opisuję w artykule o Cyber Resilience Act i aktualizacjach bezpieczeństwa. CRA i KSC mają różne zakresy oraz harmonogramy, więc sam plan zgodności z jedną regulacją nie wystarcza do oceny drugiej.

Czy software house może odpowiadać za „pełną zgodność klienta z KSC”?

Taki zapis jest zwykle zbyt szeroki względem usługi. Software house kontroluje własne działania i zadeklarowane zabezpieczenia, ale nie zarządza całą organizacją klienta, wszystkimi dostawcami i decyzjami kierownictwa. W negocjacjach zastąpiłbym ogólną gwarancję listą konkretnych obowiązków.

Po stronie dostawcy mogą znaleźć się:

• uzgodnione zabezpieczenia i ochrona dostępów uprzywilejowanych;
• obsługa incydentów, alerty i aktualizacje informacji;
• zarządzanie podatnościami i poprawkami;
• kopie oraz odtwarzanie w objętym usługą zakresie;
• współpraca przy audycie i kontrola istotnych podwykonawców.

Klient pozostaje adresatem własnych obowiązków ustawowych: kwalifikacji, rejestracji, zarządzania bezpieczeństwem organizacji, zgłoszeń i decyzji zarządczych. Może korzystać z pomocy zewnętrznej, ale umowa nie przepisuje jego statusu ani odpowiedzialności publicznoprawnej na software house.

Osobno trzeba negocjować limit odpowiedzialności, szkody objęte umową i wyjątki. Zobowiązanie do zwrotu „wszystkich kar nałożonych na klienta” wymaga analizy związku z naruszeniem dostawcy i dopuszczalności takiego rozliczenia. Nie usuwa kary administracyjnej ani odpowiedzialności jej adresata. Limit nie może też wyłączać odpowiedzialności za szkodę wyrządzoną wierzycielowi umyślnie, zgodnie z art. 473 § 2 Kodeksu cywilnego.

Kazus modelowy: utrzymanie systemu placówki medycznej

Przyjmijmy przykład prywatnej sieci medycznej, którą po analizie zakwalifikowano jako podmiot objęty KSC. To modelowa sytuacja negocjacyjna, a nie opis klienta. Software house odpowiada za aplikację, aktualizacje, monitoring i drugą linię wsparcia. Chmurę kupuje bezpośrednio klient, a jego dział IT prowadzi pierwszą linię wsparcia i zarządza kontami.

Klient wysyła aneks, według którego dostawca:

• odpowiada za zgodność całego systemu z KSC;
• zgłasza każdy incydent w godzinę;
• gwarantuje dostępność 100%;
• pokrywa wszystkie kary nałożone na klienta;
• pozwala na audyt dowolnych systemów bez zawiadomienia;
• nie zmienia żadnego podwykonawcy bez zgody klienta.

Zakres obietnic wykracza poza to, czym software house zarządza. Załącznik warto przebudować tak, żeby wskazywał aplikację, odpowiedzialność każdej strony i zależności od chmury. Do tego potrzebne są kategorie pilnych zdarzeń, kanały całodobowe, przekazywanie logów, terminy reakcji na podatności, RTO, RPO, zasady audytu i odpowiedzialność za naruszenie konkretnych zadań.

Załóżmy, że w sobotę o 22:15 monitoring wykrywa masowe błędy logowania i próby pobrania dokumentów. Software house nie wie jeszcze, czy doszło do ujawnienia danych. Jeżeli umowa przewiduje alert o takim podejrzeniu w godzinę, nie powinien czekać na poniedziałek ani na końcowy raport. Wysyła dostępne fakty, zabezpiecza logi i uruchamia uzgodnioną eskalację. Przykładowy termin godziny jest założeniem tej umowy, nie terminem narzuconym każdemu dostawcy przez KSC.

Klient sprawdza skalę wpływu i konta użytkowników; dostawca chmury dostarcza informacje ze swojej warstwy. Sieć medyczna ocenia zgłoszenia według właściwego reżimu KSC i RODO. Jeśli ograniczenie dostępu wymaga decyzji po stronie klienta, procedura wskazuje osobę dyżurną i uprawnienia awaryjne. Taki podział daje zespołom zadania, które mogą wykonać podczas incydentu.

Jakie terminy KSC trzeba uwzględnić w negocjacjach?

Ministerstwo Cyfryzacji wskazuje następujący harmonogram dla podmiotów spełniających kryteria w dniu wejścia nowelizacji w życie:

• 3 października 2026 r.: termin dotyczący wpisu do Wykazu KSC; trzeba sprawdzić obowiązek złożenia wniosku oraz przypadki wpisu z urzędu;
• 3 kwietnia 2027 r.: wdrożenie obowiązków nowych podmiotów, w tym SZBI, oraz podłączenie do S46;
• 3 kwietnia 2028 r.: pierwszy obowiązkowy audyt dla wskazanych nowych podmiotów kluczowych. Nie jest to termin corocznego audytu każdego ich dostawcy.

Dotychczasowych operatorów usług kluczowych nie można potraktować jak firm zaczynających od zera. Art. 33 ust. 4 ustawy nowelizującej przewiduje dla nich sześć miesięcy na przejście na nowe zasady zgłaszania incydentów poważnych. Nie daje im rocznego zwolnienia z bezpieczeństwa i raportowania. Obowiązują także przepisy o zachowaniu dotychczasowego SZBI do wdrożenia nowego.

Dla podmiotów, które spełnią przesłanki później, trzeba obliczyć terminy od właściwego zdarzenia, zamiast kopiować powyższe daty. Odrębnej analizy wymagają też przepisy sektorowe. Aneks klienta może natomiast zobowiązywać do określonych zabezpieczeń wcześniej niż kończy się jego okres dostosowawczy. Wcześniejszy termin umowny trzeba świadomie uzgodnić i wycenić.

Checklista KSC i NIS2 dla umowy z dostawcą ICT

Przed podpisaniem sprawdźcie:

• czy klient i dostawca sami podlegają KSC oraz od kiedy wykonują poszczególne obowiązki;
• jaką usługę klienta wspiera system i jakie środowiska obejmuje umowa;
• do jakich danych i kont dostawca ma dostęp;
• które zdarzenia uruchamiają alert i od kiedy biegnie termin;
• czy są osoby dyżurne, kanał awaryjny i harmonogram aktualizacji;
• kto kwalifikuje incydent, zgłasza go do CSIRT i ocenia obowiązki z RODO;
• jak zabezpieczane i przekazywane są logi;
• jak klasyfikowane są podatności i ustalane terminy poprawek;
• kto udostępnia okno serwisowe i akceptuje zabezpieczenia zastępcze;
• jakie zabezpieczenia i dowody ma zapewniać dostawca;
• kiedy można przeprowadzić audyt, w jakim zakresie i na czyj koszt;
• którzy podwykonawcy są istotni i jak zatwierdza się zmiany;
• jakie są RTO, RPO, testy odtworzenia i zależności od innych usług;
• gdzie kończy się odpowiedzialność dostawcy i jakie ma wyjątki;
• jak rozliczana jest dodatkowa praca przy incydencie;
• jak wygląda przekazanie usługi, eksport i usunięcie danych po zakończeniu umowy.

Przygotuj własny standard, zanim przyjdzie kolejny aneks

Software house może wcześniej zebrać opis zabezpieczeń, listę istotnych podwykonawców, procedurę incydentową i proponowany załącznik bezpieczeństwa. Dzięki temu negocjacje zaczynają się od konkretnego sposobu świadczenia usługi. Łatwiej wtedy wskazać, które wymaganie jest już spełnione, które wymaga dodatkowej pracy, a którego firma nie może uczciwie zagwarantować.

Jeżeli przygotowujesz lub negocjujesz taki kontrakt, pomagam w ramach wsparcia prawnego przy umowach IT i wdrożeniach oraz obsługi produktów SaaS. Możemy przejść przez aneks razem z zakresem usług, SLA i procedurą incydentową, żeby zobowiązania odpowiadały temu, jak pracuje zespół.

Umów 30-minutową konsultację

Źródła i dalsza lektura

• Ustawa o krajowym systemie cyberbezpieczeństwa, tekst ujednolicony, w szczególności art. 2, 5, 8, 11 i 16;
• Ustawa nowelizująca z 23 stycznia 2026 r., Dz.U. poz. 252, w szczególności przepisy przejściowe art. 33 i 34;
• Dyrektywa NIS2, 2022/2555, w szczególności art. 21 i 23;
• Ministerstwo Cyfryzacji: obowiązki podmiotów kluczowych i ważnych;
• Centrum e-Zdrowia: nowe przepisy KSC, materiał z 3 kwietnia 2026 r.;
• Komisja Europejska: zestaw narzędzi bezpieczeństwa łańcuchów dostaw ICT;
• UODO: zgłaszanie naruszeń ochrony danych osobowych i tekst RODO.