Wycofanie dostawcy wysokiego ryzyka w telekomunikacji — jak spełnić art. 67c UKSC krok po kroku
Przedsiębiorca telekomunikacyjny objęty decyzją o dostawcy wysokiego ryzyka wycofuje w ciągu 4 lat produkty, usługi i procesy ICT tego dostawcy wskazane w decyzji i objęte wykazem kategorii funkcji krytycznych z załącznika nr 3. Poniżej ta norma rozłożona na warstwy: wymagania → kontrole standardów → rozwiązania. Zacznijcie od pytania, czy ten obowiązek Was wiąże — odpowiedź jest pierwszą sekcją pod spodem.
Kogo wiąże ten obowiązek?
Zanim przeczytacie choć jedno wymaganie — sprawdźcie, czy ta ścieżka jest Wasza. Odpowiedź nie jest pisana ręcznie: wynika z zakresu obowiązku zapisanego w modelu prawnym.
Podmioty kluczowe i Podmioty ważne
Ten obowiązek wiąże podmioty kluczowe i podmioty ważne. Jeśli jesteście w wykazie w tej klasie, ta ścieżka jest Waszą listą zadań.
Podmioty ważne — sektor publiczny
Ten obowiązek nie wiąże podmioty ważne z sektora publicznego — model nie wskazuje dla tej klasy odpowiednika w tym samym artykule.
Sprawdźcie swój rodzaj podmiotu
Klasa podmiotu to nie wszystko — decyduje rodzaj podmiotu, sektor i wielkość. Kwalifikator KSC wskaże Wasz rodzaj, a wynik powie wprost, czy ten obowiązek jest w Waszym katalogu.
Ten blok wygląda tak samo na każdej ścieżce: obowiązek z UKSC pokaże tu klasy podmiotów (kluczowy / ważny / publiczny), obowiązek z CIR — dostawców cyfrowych. Dyrektywa NIS2 nie ma własnych ścieżek — pokazujemy ją niżej, jako źródło obowiązku.
Przepis krajowy — dyrektywa NIS2 tego nie wymaga
Na innych ścieżkach ta sekcja pokazuje zdanie dyrektywy, z którego wynika obowiązek. Tu takiego zdania nie ma: ten obowiązek ustanowił polski ustawodawca.
Nie wynika z dyrektywy NIS2
Ten obowiązek ustanowił polski ustawodawca — w analizowanym zakresie NIS2 (18 jednostek w modelu: art. 2, art. 3, art. 20, art. 21 ust. 1, art. 21 ust. 2, art. 21 ust. 3, art. 21 ust. 4, art. 23 ust. 1, art. 23 ust. 2, art. 23 ust. 3, art. 23 ust. 4, art. 23 ust. 5–11, art. 26, art. 29, art. 30, art. 32 ust. 6, załącznik I, załącznik II) nie ma jego odpowiednika.
Obowiązuje, bo tak stanowi ustawa. Dyrektywa określa wspólne minimum dla całej Unii, a państwo członkowskie może wymagać więcej — i Polska tu wymaga więcej.
Art. 67c UKSC
„wycofują w ciągu 4 lat od dnia ogłoszenia decyzji, o której mowa w art. 67b ust. 15, typy produktów ICT, rodzaje usług ICT, konkretne procesy ICT wskazane w decyzji i określone w wykazie kategorii funkcji krytycznych dla bezpieczeństwa sieci i usług w załączniku nr 3 do ustawy"
W modelu jest osobnym obowiązkiem bez relacji „transponuje" — dzięki temu widzicie wprost, co jest transpozycją, a co polskim dodatkiem. Treść cytowana z modelu, nie pisana.
Od ustawy do narzędzia i szablonu
Diagram pokazuje jedną nitkę ścieżki — jedyne wymaganie wiążące tego obowiązku — w komplecie warstw.
Wymaganie tego obowiązku i jego odpowiedniki w standardach
Jeden wiersz — dokładnie w brzmieniu z modelu, o które zapyta audytor — z kontrolami, na które mapuje je model.
| Wymaganie (brzmienie z modelu) | Charakter | Kontrole standardów |
|---|---|---|
| Organizacja i politykiwymagania wiążące — organizacyjne | ||
| Przedsiębiorca telekomunikacyjny objęty decyzją o dostawcy wysokiego ryzyka wycofuje w ciągu 4 lat od dnia ogłoszenia decyzji produkty, usługi i procesy ICT tego dostawcy wskazane w decyzji i objęte wykazem kategorii funkcji krytycznych z załącznika nr 3 do ustawy. | organizacyjne | ISO 27001 · A.5.21 NIST CSF · GV.SC-07 |
Kolumna „kontrole" mówi Wam, gdzie tę samą rzecz mierzy Wasz certyfikat ISO albo profil NIST — jeśli kontrolę już macie wdrożoną i udokumentowaną, ta część ścieżki jest do reużycia, nie do budowy od zera.
Czym to zrealizować — rekomendacje referencyjne
Kontrole prowadzą do 3 kategorii rozwiązań (taksonomia ECSO); model wskazuje dla nich 5 rozwiązań referencyjnych; dla 1 kategorii — żadnego, i strona mówi to wprost. Wasze własne narzędzie tej samej kategorii też domyka ścieżkę.
CISO Assistant
Narzędzie open source do prowadzenia SZBI: rejestr ryzyk, plan postępowania, dowody skuteczności środków — z gotowymi ramami ISO 27001 i NIST CSF, na które mapuje ta ścieżka.
Probo
Narzędzie open source do oceny i monitorowania dostawców: rejestr dostawców, oceny ryzyka, śledzenie zobowiązań umownych — operacyjna strona łańcucha dostaw.
Szablon: Polityka bezpieczeństwa łańcucha dostaw
Autorski szablon polityki domykający wymagania organizacyjne łańcucha dostaw — rola w łańcuchu, kryteria wyboru dostawców, blok klauzul umownych do wpięcia w umowy.
Szablon: Polityka bezpieczeństwa zasobów ludzkich
Autorski szablon polityki bezpieczeństwa zasobów ludzkich — obowiązki przed zatrudnieniem, w trakcie i po jego zakończeniu, weryfikacja, szkolenia, sankcje.
Szablon: Polityka nadrzędna bezpieczeństwa informacji
Dokument, od którego zaczyna się SZBI: ramy systemu, polityki tematyczne, role i przeglądy — autorski szablon polityki nadrzędnej bezpieczeństwa informacji.
Software & Security Lifecycle Management — bez rekomendacji w modelu
Kontrole prowadzą też do tej kategorii, ale model nie wskazuje dla niej rozwiązania referencyjnego. Wasze własne narzędzie tej kategorii domyka ścieżkę tak samo.
Czego ta ścieżka nie zrobi za Was
Nie zastąpi dowodów operacyjnych
Ścieżka daje strukturę i uzasadnienia — mapę tego, co wykazać. Zapisy, decyzje, logi i podpisane dokumenty musicie wytworzyć u siebie; o oczekiwaniach audytora więcej na stronie audyt KSC/NIS2.
Inne obowiązki z tego samego przepisu (art. 67c UKSC)
Ten przepis rozpada się w modelu na osobne obowiązki — każdy z własną ścieżką. Ta strona to jeden z nich; pozostałe:
- Dostawca wysokiego ryzyka (art. 67c UKSC)
- Zakaz zamówień dostawcy wysokiego ryzyka (art. 67c UKSC)
Chcecie przejść tę ścieżkę z przewodnikiem?
Inteca poprowadzi wdrożenie warstwa po warstwie: od wymagań przepisu, przez kontrole standardów, po narzędzia i bazę dowodową pod audyt.