Otwarty standard

Kwestionariusz dla dostawców NIS 2

Pytania, które podmiot regulowany przez NIS 2 musi zadać swoim dostawcom. Zakotwiczone raz w prawie UE. Darmowe w użyciu.

Niemal każdy dział zakupów na europejskim rynku średnich przedsiębiorstw pisze obecnie własny kwestionariusz dla dostawców NIS 2. Te same około pięćdziesięciu zakotwiczonych w prawie UE pytań, w nieco różnych formach, wysyłane do dostawców, którzy ostatecznie wypełniają pięć wersji tego samego. Ten kwestionariusz jest wspólną podstawą.

Każde pole jest zakotwiczone w pierwotnym źródle na poziomie UE: NIS 2 Art. 21(2), CIR 2024/2690, ENISA Technical Implementation Guidance, GDPR Art. 28 lub Cyber Resilience Act. Nakładki sektorowe, takie jak TISAX, VDA ISA, BSI C5 czy katalogi audytowe KRITIS, leżą na tej podstawie, a nie zamiast niej.

Pobierz
Użyj w obecnej formie lub jako punktu wyjścia dla własnego szablonu zakupowego.
Wersja
3.1.0
Ostatnia aktualizacja
2026-05-15
Pola
59
Licencja
MIT (schemat) + CC BY 4.0 (treść)

Profil dostawcy

18 pola

Nazwa prawna

stringWymagane

Zarejestrowana nazwa Twojej firmy, taka jak widnieje w rejestrze handlowym. Przykład: Müller GmbH lub Acme Software Ltd.

Podstawa prawna: ENISA TIG §5.2

Adres siedziby

stringWymagane

Zarejestrowany adres prowadzenia działalności Twojej firmy. Wystarczy jeden adres, nawet jeśli masz kilka lokalizacji.

Podstawa prawna: ENISA TIG §5.2

Kraj

countryWymagane

Kraj, w którym Twoja firma ma siedzibę prawną. Dwie litery, np. DE dla Niemiec.

Podstawa prawna: ENISA TIG §5.2

Domena główna

urlOpcjonalne

Twoja domena główna, zwykle adres URL Twojej witryny. Przykład: acmesoftware.com.

Podstawa prawna: ENISA TIG §5.2(b)

Slogan (jedna linia, widoczny dla klientów)

stringOpcjonalne

Jedna linia podsumowująca Twoją ofertę. Klienci widzą ją w Twoim profilu dostawcy. Przykład: ERP dla produkcji w sektorze MŚP.

Podstawa prawna: ENISA TIG §5.2(b)

Opis publiczny (dłuższy)

textOpcjonalne

Dwa do trzech zdań o Twojej firmie i tym, czym się zajmuje. Pojawia się to w Twoim profilu dostawcy. Argumentacja sprzedażowa, postawa w zakresie bezpieczeństwa lub oba elementy.

Podstawa prawna: ENISA TIG §5.2(b)

Opis świadczonych usług

textWymagane

Jeden akapit o tym, co Twoja firma technicznie dostarcza klientom. Konkretne produkty, moduły lub usługi. Unikaj czysto marketingowego języka.

Podstawa prawna: ENISA TIG §5.2(b) + §5.1.4 TIPS

Kraje / regiony, w których przetwarzane są dane klientów

stringWymagane

Wszystkie kraje, w których przechowywane lub przetwarzane są dane Twoich klientów. Oddzielone przecinkami, kody krajów ISO. Przykład: DE, NL, US. Jeśli przetwarzasz dane wyłącznie w UE, wystarczy wymienić kraje UE.

Podstawa prawna: ENISA TIG §5.1.4 TIPS

Imię i nazwisko kontaktu ds. bezpieczeństwa

stringWymagane

Osoba, z którą klienci kontaktują się w przypadku incydentu bezpieczeństwa. W mniejszych firmach często dyrektor zarządzający lub kierownik IT. Wystarczy jedna osoba.

Podstawa prawna: CIR 2024/2690 §5.1.4(d)

E-mail kontaktowy do zgłaszania incydentów

emailWymagane

Adres e-mail, którego klienci używają do zgłaszania incydentu bezpieczeństwa. Najlepiej lista dystrybucyjna, taka jak security@example.com, która dociera do wielu osób.

Podstawa prawna: CIR 2024/2690 §5.1.4(d)

Telefon kontaktowy do zgłaszania incydentów (24/7)

phoneOpcjonalne

Numer telefonu do pilnych zgłoszeń incydentów. Jeśli nie prowadzisz dyżuru 24/7, podaj godziny pracy w nawiasie.

Podstawa prawna: CIR 2024/2690 §5.1.4(d)

SLA powiadamiania o incydentach (godziny)

integerOpcjonalne

Liczba godzin od wykrycia incydentu do powiadomienia klienta, najpóźniej. Realistyczna samoocena, a nie wartość docelowa. Typowe wartości: 24, 48 lub 72 godziny.

Podstawa prawna: NIS2 Art. 23

Identyfikator rejestracji BSI (tylko jeśli Twoja firma sama podlega NIS2)

stringOpcjonalne

Jeśli Twoja firma sama podlega NIS 2 i jest zarejestrowana w BSI, wpisz tutaj identyfikator rejestracji. Opcjonalne. Pozwala klientom od razu zobaczyć, że spełniasz ten sam obowiązek co podmiot regulowany.

Podstawa prawna: ENISA TIG §5.1.2

Świadczymy usługi SaaS / hostowane

booleanWymagane

Uruchamiasz oprogramowanie dla klientów na własnej infrastrukturze i dostarczasz je przez internet. Zaznacz więcej niż jedno pole, jeśli oferujesz kilka modeli.

Podstawa prawna: ENISA TIG §5.2(b)

Dostarczamy oprogramowanie on-premise

booleanWymagane

Dostarczasz oprogramowanie, które klienci instalują i uruchamiają na własnej infrastrukturze.

Podstawa prawna: ENISA TIG §5.2(b)

Świadczymy usługi profesjonalne / doradztwo

booleanWymagane

Twoim głównym produktem jest praca ludzka: doradztwo, wdrożenie, szkolenia, audyt lub dostosowanie.

Podstawa prawna: ENISA TIG §5.2(b)

Świadczymy usługi zarządzane / MSP

booleanWymagane

Obsługujesz dla klienta części jego infrastruktury IT, własnym personelem. Typowe dla modeli MSP i MSSP.

Podstawa prawna: ENISA TIG §5.2(b)

Używamy, integrujemy lub dostarczamy systemy SI

booleanWymagane

Czy Twoje produkty lub usługi przetwarzają dane klientów za pomocą modelu SI lub ML? Obejmuje to modele zewnętrzne wywoływane przez API, na przykład OpenAI lub Anthropic.

Podstawa prawna: NIS2 Art. 21(2)(d)

Praktyki bezpieczeństwa

26 pola

Udokumentowany system zarządzania bezpieczeństwem informacji (ISMS)

booleanWymagane

Zaznacz tak, jeśli masz pisemną politykę bezpieczeństwa informacji z przypisanymi rolami, regularnymi przeglądami i udokumentowaną obsługą incydentów. Certyfikacja ISO 27001 lub BSI Grundschutz oznacza tak.

Podstawa prawna: CIR 2024/2690 §5.1.2(a)

Posiadanie certyfikatu ISO 27001, BSI Grundschutz lub równoważnego

booleanWymagane

Zaznacz tak, jeśli Twoja firma posiada aktualnie certyfikat ISO 27001, BSI Grundschutz, SOC 2 Type II lub równoważny. Prześlij certyfikat w zakładce Certyfikaty.

Podstawa prawna: CIR 2024/2690 §5.1.2(b)

Coroczne szkolenie z zakresu świadomości bezpieczeństwa dla całego personelu

booleanWymagane

Zaznacz tak, jeśli każdy pracownik otrzymuje co najmniej jedno coroczne szkolenie z zakresu świadomości bezpieczeństwa informacji. E-learning się liczy; symulacje phishingu są uzupełnieniem.

Podstawa prawna: CIR 2024/2690 §5.1.4(b)

Weryfikacja przeszłości personelu z dostępem do danych klientów

booleanWymagane

Zaznacz tak, jeśli przeprowadzasz weryfikację przeszłości personelu z dostępem do danych klientów. Typowy poziom: wyciąg z rejestru karnego lub równoważny dokument przy zatrudnieniu.

Podstawa prawna: CIR 2024/2690 §5.1.4(c)

Udokumentowany proces obsługi podatności i instalowania poprawek

booleanWymagane

Zaznacz tak, jeśli masz pisemny proces obsługi podatności bezpieczeństwa: wykrywanie, ocena, priorytetyzacja, instalowanie poprawek lub łagodzenie. Monitorowanie CVE i instalowanie poprawek w oparciu o SLA są standardem.

Podstawa prawna: CIR 2024/2690 §5.1.4(f)

Akceptacja prawa klienta do audytu (lub udostępnianie raportów z audytu)

booleanWymagane

Zaznacz tak, jeśli przyznajesz klientom prawo do audytu na miejscu albo udostępniasz zastępcze raporty z audytu (na przykład SOC 2, ISAE 3402).

Podstawa prawna: CIR 2024/2690 §5.1.4(e)

Korzystanie z podwykonawców przetwarzania / poddostawców

booleanWymagane

Zaznacz tak, jeśli do świadczenia usługi korzystasz z innych firm, które mają dostęp do danych lub infrastruktury klientów. Typowe przykłady: AWS, Azure, Cloudflare, Stripe.

Podstawa prawna: CIR 2024/2690 §5.1.4(g)

Lista podwykonawców przetwarzania

textWarunkowe

Wymień każdego podwykonawcę przetwarzania z nazwą, miejscem przetwarzania i tym, co dla Ciebie robi. Wystarczy tabela lub lista punktowana. Aktualizuj ją za każdym razem, gdy dodajesz lub usuwasz podwykonawcę.

Podstawa prawna: CIR 2024/2690 §5.1.4(g)

Zobowiązanie do zwrotu / zniszczenia danych klientów po zakończeniu umowy

booleanWymagane

Zaznacz tak, jeśli zobowiązujesz się umownie do zwrotu lub zniszczenia danych klientów po zakończeniu umowy. Powszechna praktyka: eksport i zwrot, a następnie usunięcie w ciągu 30 dni.

Podstawa prawna: CIR 2024/2690 §5.1.4(h)

Dostępna standardowa umowa o przetwarzaniu danych (DPA)

booleanWymagane

Zaznacz tak, jeśli masz standardową umowę o przetwarzaniu danych zgodnie z artykułem 28 GDPR, którą klienci mogą podpisać. Wymagane, gdy tylko przetwarzasz dane osobowe.

Podstawa prawna: GDPR Art. 28

Polityki bezpieczeństwa są przeglądane co najmniej raz w roku

booleanWymagane

Zaznacz tak, jeśli Twoje polityki bezpieczeństwa są przeglądane co najmniej raz w roku i aktualizowane w razie potrzeby. Pisemna notatka w dokumencie jest wystarczającym dowodem.

Podstawa prawna: NIS2 Art. 21(2)(a) / ENISA TIG §1.1

Udokumentowany plan reagowania na incydenty

booleanWymagane

Zaznacz tak, jeśli masz pisemny plan obsługi incydentów bezpieczeństwa: kto decyduje, kto komunikuje, kto dokumentuje. Co najmniej jedno ćwiczenie sztabowe rocznie to dobra praktyka.

Podstawa prawna: NIS2 Art. 21(2)(b) / ENISA TIG §3

Udokumentowany plan ciągłości działania / odtwarzania po awarii

booleanWymagane

Zaznacz tak, jeśli masz plan wyjaśniający, jak utrzymujesz działanie lub szybko przywracasz je podczas awarii: systemy krytyczne, rozwiązania awaryjne, cele RTO i RPO.

Podstawa prawna: NIS2 Art. 21(2)(c) / ENISA TIG §4

Udokumentowana polityka kryptografii

booleanWymagane

Zaznacz tak, jeśli masz pisemnie określone, jaką kryptografię stosujesz i gdzie: dane w tranzycie (TLS 1.2+), dane w spoczynku (AES-256), zarządzanie kluczami, algorytmy haszujące.

Podstawa prawna: NIS2 Art. 21(2)(h) / ENISA TIG §9

Zarządzanie dostępem uprzywilejowanym (PAM) dla personelu wewnętrznego

booleanWymagane

Zaznacz tak, jeśli administratorzy i konta uprzywilejowane mają dodatkowe mechanizmy kontroli: osobne logowanie, MFA, rejestrowanie sesji lub dostęp just-in-time.

Podstawa prawna: NIS2 Art. 21(2)(i) / ENISA TIG §11.3

MFA wymuszone dla wszystkich wewnętrznych kont administracyjnych / uprzywilejowanych

booleanWymagane

Zaznacz tak, jeśli każde wewnętrzne konto administracyjne lub uprzywilejowane musi używać MFA. Tokeny sprzętowe lub aplikacje uwierzytelniające się liczą; SMS nie.

Podstawa prawna: NIS2 Art. 21(2)(j)

Prowadzenie inwentaryzacji zasobów informacyjnych

booleanWymagane

Zaznacz tak, jeśli prowadzisz aktualną listę każdego systemu informacyjnego używanego do świadczenia usługi: serwery, bazy danych, narzędzia SaaS, punkty końcowe. Wystarczy arkusz kalkulacyjny.

Podstawa prawna: NIS2 Art. 21(2)(i) / ENISA TIG §12.4

Program testów penetracyjnych co rok lub co dwa lata

booleanWymagane

Zaznacz tak, jeśli zlecasz zewnętrzny test penetracyjny co najmniej raz na jeden do dwóch lat. W przypadku mniejszych firm akceptowalnym minimalnym krokiem jest zewnętrzne skanowanie podatności.

Podstawa prawna: NIS2 Art. 21(2)(e) / ENISA TIG §6.5

Ujawniamy przeszłe podlegające zgłoszeniu zdarzenia cyberbezpieczeństwa na prośbę klientów

booleanWymagane

Zaznacz tak, jeśli na prośbę klienta otwarcie ujawniasz, czy i jakie podlegające zgłoszeniu incydenty bezpieczeństwa Twoja firma miała w przeszłości. Typowy okres: ostatnie od trzech do pięciu lat.

Podstawa prawna: ENISA TIG §5.1.2

Zapewniamy klientom pomoc w razie incydentu bez kosztów / po kosztach ustalonych z góry

booleanWymagane

Zaznacz tak, jeśli zobowiązujesz się pomagać klientom bez dodatkowych kosztów, gdy incydent jest spowodowany przez Twój produkt lub usługę. Jeśli zamiast tego z góry uzgadniasz wcześniej zdefiniowaną stawkę dzienną, również zaznacz tak.

Podstawa prawna: ENISA TIG §5.1.4 TIPS

Pełna współpraca z właściwymi organami (BSI, ENISA, krajowe CSIRT)

booleanWymagane

Zaznacz tak, jeśli zobowiązujesz się do pełnej współpracy z właściwymi organami, takimi jak BSI, ENISA lub krajowe CSIRT, podczas inspekcji, audytów i obsługi incydentów. Standard dla poważnych dostawców.

Podstawa prawna: ENISA TIG §5.1.4 TIPS

Powiadamiamy klientów o każdej istotnej zmianie wpływającej na świadczenie usługi

booleanWymagane

Zaznacz tak, jeśli zobowiązujesz się powiadamiać klientów o każdej istotnej zmianie wpływającej na Twoją zdolność do świadczenia usługi: przejęcia, zmiany podwykonawcy przetwarzania, poważne zmiany techniczne.

Podstawa prawna: ENISA TIG §5.1.4 TIPS

Powiadamiamy klientów z wyprzedzeniem, jeśli zmieniają się miejsca przetwarzania danych

booleanWymagane

Zaznacz tak, jeśli informujesz klientów z wyprzedzeniem, zanim zmieni się miejsce przetwarzania ich danych. Ważne dla ochrony danych i dla zgodnego z GDPR nadzoru nad łańcuchem dostaw.

Podstawa prawna: ENISA TIG §5.1.4 TIPS

Udokumentowana strategia wyjścia z obowiązkowym okresem przejściowym

booleanWymagane

Zaznacz tak, jeśli masz pisemną strategię wyjścia: jak długo trwa uporządkowane przekazanie, jakie dane i wiedza są przekazywane, do czego się zobowiązujesz w okresie przejściowym.

Podstawa prawna: ENISA TIG §5.1.4 TIPS

Dostarczamy SBOM-for-AI zgodnie z minimalnymi elementami G7

booleanWarunkowe

Opcjonalne. Zaznacz tak, jeśli możesz dostarczyć SBOM-for-AI zgodnie z minimalnymi elementami G7 (maj 2026). Dokumentuje metadane, modele, dane treningowe, infrastrukturę, właściwości bezpieczeństwa, KPI i zachowanie systemu. Standard dobrowolny.

Podstawa prawna: NIS2 Art. 21(2)(d) / ENISA TIG §5.1.2

URL dokumentu SBOM-for-AI

urlWarunkowe

Publiczny lub udostępniony URL do Twojego dokumentu SBOM-for-AI. Może to być plik PDF, plik JSON lub strona projektu.

Podstawa prawna: NIS2 Art. 21(2)(d) / ENISA TIG §5.1.2

Specyficzne dla SaaS

5 pola

Region hostingu

stringWarunkowe

Region chmury, w którym hostowane są dane klientów. Przykład: AWS eu-central-1, Azure West Europe. Podaj region główny; regiony zapasowe lub do tworzenia kopii zapasowych można dodać po przecinku.

Podstawa prawna: ENISA TIG §5.2

Szyfrowanie danych w spoczynku

booleanWarunkowe

Zaznacz tak, jeśli dane klientów na dysku są szyfrowane w spoczynku za pomocą AES-256 lub równoważnego standardu. Liczy się szyfrowanie dysków zarządzane przez chmurę (AWS EBS, Azure Disk Encryption).

Podstawa prawna: NIS2 Art. 21(2)(h) / ENISA TIG §9

Szyfrowanie podczas przesyłania (TLS ≥ 1.2)

booleanWarunkowe

Zaznacz tak, jeśli wszystkie punkty końcowe dostępne dla klientów wymuszają TLS 1.2 lub wyższy. Preferowany jest TLS 1.3. Zwykły HTTP musi przekierowywać na HTTPS.

Podstawa prawna: NIS2 Art. 21(2)(h) / ENISA TIG §9

MFA wymuszone dla wszystkich kont administracyjnych

booleanWarunkowe

Zaznacz tak, jeśli każde wewnętrzne konto administracyjne na platformie SaaS musi używać MFA. Ten sam standard co Twoja wewnętrzna polityka administracyjna.

Podstawa prawna: NIS2 Art. 21(2)(j) / ENISA TIG §11.3

Docelowy czas przywrócenia (RTO) w godzinach

integerWarunkowe

Maksymalna liczba godzin, przez które Twoja usługa może być niedostępna przed przywróceniem. Realistyczna wartość SLA, a nie wartość docelowa. Typowe wartości SaaS: 4, 8 lub 24 godziny.

Podstawa prawna: NIS2 Art. 21(2)(c) / ENISA TIG §4

Specyficzne dla on-premise

4 pola

Dostarczanie wykazu komponentów oprogramowania (SBOM)

booleanWarunkowe

Zaznacz tak, jeśli dostarczasz wykaz komponentów oprogramowania (SBOM) z każdym wydaniem. CycloneDX lub SPDX to formaty standardowe. Obowiązkowe na mocy Cyber Resilience Act dla produktów wprowadzanych na rynek UE od grudnia 2027 r.

Podstawa prawna: CRA / NIS2 Art. 21(2)(d)

Wydania są podpisane kryptograficznie

booleanWarunkowe

Zaznacz tak, jeśli każdy artefakt wydania ma podpis kryptograficzny, który klienci mogą zweryfikować. Klucze podpisujące są udokumentowane i podlegają rotacji. Liczą się zarówno podpisy Sigstore, jak i PGP.

Podstawa prawna: NIS2 Art. 21(2)(e) / ENISA TIG §6.5

Opublikowana polityka ujawniania podatności

booleanWarunkowe

Zaznacz tak, jeśli masz publicznie udokumentowany sposób zgłaszania podatności bezpieczeństwa. Wystarczy plik security.txt w Twojej domenie (zgodnie z RFC 9116) lub dedykowany adres e-mail, taki jak security@example.com.

Podstawa prawna: NIS2 Art. 21(2)(e) / ENISA TIG §3

SLA poprawek dla krytycznych CVE (godziny)

integerWarunkowe

Godziny od publicznego ujawnienia CVE do wydania z poprawką dla krytycznych podatności (CVSS 9.0+). Realistyczne zobowiązanie, a nie wartość docelowa. Typowe wartości: 24, 48 lub 72 godziny.

Podstawa prawna: CIR 2024/2690 §5.1.4(f)

Usługi profesjonalne

3 pola

Zakres weryfikacji przeszłości

stringWarunkowe

Opisz, w jaki sposób weryfikujesz konsultantów do stanowisk wrażliwych. Przykład: wyciąg z rejestru karnego dla wszystkich konsultantów oraz sprawdzenie referencji w przypadku zleceń obejmujących dane niejawne.

Podstawa prawna: NIS2 Art. 21(2)(i) / CIR 2024/2690 §5.1.4(c)

NDA zawarte ze wszystkimi konsultantami

booleanWarunkowe

Zaznacz tak, jeśli każdy konsultant podpisuje umowę o zachowaniu poufności przed przydzieleniem do pracy u klienta. Jako część umowy o pracę albo jako odrębne NDA.

Podstawa prawna: NIS2 Art. 21(2)(i) / ENISA TIG §11.4

Udokumentowana polityka zachowania w siedzibie klienta

booleanWarunkowe

Zaznacz tak, jeśli masz pisemny kodeks postępowania dla konsultantów pracujących w siedzibie klienta: obsługa identyfikatorów, obowiązek blokowania ekranu, postępowanie w przypadku wyniesienia danych z lokalizacji.

Podstawa prawna: NIS2 Art. 21(2)(i) / ENISA TIG §11.3

Usługi zarządzane

3 pola

Wdrożone zarządzanie dostępem uprzywilejowanym (PAM)

booleanWarunkowe

Zaznacz tak, jeśli używasz narzędzia do zarządzania dostępem uprzywilejowanym dla administracyjnych sesji zdalnych w systemach klientów. Przykłady: CyberArk, BeyondTrust, Teleport. Konfiguracja jump-host z rejestrowaniem logów się liczy.

Podstawa prawna: NIS2 Art. 21(2)(i) / ENISA TIG §11.3

Sesje administracyjne są rejestrowane

booleanWarunkowe

Zaznacz tak, jeśli sesje administracyjne w systemach klientów są rejestrowane i przechowywane do celów weryfikacji. Typowy okres przechowywania: od 90 dni do 1 roku. Niezbędne do rekonstrukcji forensycznej po incydentach.

Podstawa prawna: NIS2 Art. 21(2)(f) / ENISA TIG §10

Dyżur 24/7

booleanWarunkowe

Zaznacz tak, jeśli prowadzisz dyżur 24/7, który reaguje na incydenty bezpieczeństwa w systemach klientów. Wsparcie wyłącznie w godzinach pracy nie spełnia tego wymogu.

Podstawa prawna: NIS2 Art. 21(2)(b) / ENISA TIG §3

Jak go używać

Ten kwestionariusz obejmuje prawną treść UE dla należytej staranności wobec dostawców w ramach NIS 2. Jest pomyślany jako wspólna podstawa, a nie pełny szablon specyficzny dla sektora.

TISAX, VDA ISA, BSI C5, katalogi audytowe KRITIS oraz Twoje własne nakładki ryzyka leżą na wierzchu jako rozszerzenia. Rozwidl repozytorium, dodaj swoje pytania sektorowe lub użyj wspólnych pól jako fundamentu dla własnego szablonu.

Ocena dostawców z dziennikiem audytu
Na platformie nisd2.eu te pytania są wysyłane, otrzymują odpowiedzi, są podpisywane i przechowywane w sposób audytowalny od razu po uruchomieniu. Darmowe, open source, bez vendor lock-in.