blog · bezpieczeństwo · 1 października 2026 · 9 min czytania

Klient objęty NIS2 przysłał ankietę bezpieczeństwa: co musi umieć Twoja firmowa aplikacja (i ile kosztuje dogonienie braków)

Mail przychodzi od działu zakupów albo bezpieczeństwa klienta, z którym pracujesz od lat. W załączniku arkusz „Ankieta bezpieczeństwa dostawcy”, prośba o wypełnienie w dwa tygodnie i zdanie, że od odpowiedzi zależy dalsza współpraca. Pytania brzmią obco: polityka bezpieczeństwa informacji, uwierzytelnianie wieloskładnikowe, test odtworzenia kopii, procedura zgłaszania incydentów. A Ty prowadzisz firmę serwisową, hurtownię albo biuro, które od kilku lat obsługuje tego klienta przez własny portal zleceń.

To nie pomyłka adresata. Od 3 kwietnia 2026 obowiązuje nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, która wdraża unijną dyrektywę NIS2. Firmy uznane za kluczowe i ważne, m.in. z energetyki, ochrony zdrowia, wodociągów, transportu i części produkcji, mają do 3 kwietnia 2027 wdrożyć system zarządzania bezpieczeństwem, a jego częścią jest ryzyko łańcucha dostaw. Najprostszy sposób, żeby to ryzyko udokumentować, to zapytać dostawców. Stąd ankiety i nowe klauzule w umowach, także u firm, które same ustawie nie podlegają.

Ten wpis jest pisany od strony właściciela aplikacji, nie kancelarii: które pytania dotyczą papierów po stronie firmy, a które tego, co potrafi sam system, jak odpowiadać, żeby nie podpisać nieprawdy, i ile godzin kosztuje dogonienie braków. Od razu zastrzeżenie: nie jesteśmy kancelarią i to nie jest porada prawna. Treść umowy i klauzul skonsultuj z prawnikiem, my zajmujemy się tym, co siedzi w aplikacji.

Najpewniej nie podlegasz ustawie. Twój klient podlega

Mała firma zwykle nie spełnia kryteriów podmiotu kluczowego ani ważnego, więc nie ma obowiązków wobec państwa. Termin złożenia wniosku o wpis do wykazu takich podmiotów mija 3 października 2026, więc w tych dniach Twoi klienci wiedzą już dokładnie, czy podlegają, i zabierają się za porządkowanie dostawców. Do Ciebie trafiają wtedy obowiązki przenoszone umową, w praktyce trzy rzeczy:

  • Ankieta bezpieczeństwa dostawcy – arkusz pytań o zasady, dostępy, kopie i incydenty. Wypełniasz ją raz, ale warto założyć, że wróci przy kolejnej umowie.
  • Klauzula o incydentach – obowiązek powiadomienia klienta o naruszeniu bezpieczeństwa w określonym czasie. Klient sam ma krótkie terminy zgłoszeń, więc od dostawcy oczekuje informacji jeszcze szybciej.
  • Prawo do audytu – zapis, że klient albo wskazana przez niego firma może sprawdzić, czy deklaracje z ankiety są prawdziwe.

Czy klient zapyta akurat Ciebie, zależy od tego, jak blisko jego danych i systemów jesteś. Dostawca papieru biurowego raczej nie dostanie pytań o kopie zapasowe. Firma, w której portalu pracownicy klienta zgłaszają awarie, a technicy wpisują raporty z jego obiektów, będzie na liście jako jedna z pierwszych.

Dwie kolumny: papier po stronie firmy i to, co musi umieć system

Ankieta wygląda jak jedna długa lista, ale pytania dzielą się na dwie grupy i ten podział to pierwszy krok do odpowiedzi bez paniki. Pierwsza grupa to dokumenty i zasady, które przygotowuje firma, niezależnie od tego, jakiej aplikacji używa:

  • Polityka bezpieczeństwa – kto w firmie za nie odpowiada, jakie są zasady haseł, urządzeń i pracy zdalnej.
  • Plan ciągłości działania – co robicie, gdy system albo kluczowy dostawca przestanie działać na dzień czy tydzień.
  • Procedura incydentów – kto zauważa, kto decyduje i kto, w jakim czasie, powiadamia klienta.
  • Lista podwykonawców – kto jeszcze ma dostęp do danych klienta: hosting, biuro rachunkowe, informatyk na telefon.

Tu aplikacja niewiele pomoże, a programista nie zastąpi prawnika ani doradcy. Druga grupa to pytania, na które odpowiada sam system, i tu każde „tak” powinno dać się pokazać na ekranie albo w dokumentacji.

Siedem pytań, na które odpowiada sama aplikacja

Sformułowania różnią się między ankietami, ale pytania o sam system krążą wokół siedmiu tematów. Przy każdym: co znaczy dobra odpowiedź.

  • Logowanie i hasła. Hasła nie są przechowywane w postaci jawnej, a logowanie opiera się na sprawdzonym mechanizmie, nie na własnym wynalazku. Dobra odpowiedź mówi też, co się dzieje po kilku nieudanych próbach.
  • Logowanie dwuetapowe (w ankietach: MFA albo 2FA). Przynajmniej dla kont administratorów i dla użytkowników po stronie klienta. Kod z aplikacji w telefonie przy logowaniu to pytanie, którego trudno dziś uniknąć.
  • Role i odbieranie dostępu. Kto co widzi i jak szybko konto znika po odejściu pracownika albo końcu współpracy. Jeśli dezaktywacja to minuta pracy w panelu, a nie zmiana wspólnego hasła, odpowiedź masz gotową.
  • Dziennik zdarzeń. Zapis logowań, nieudanych prób, zmian uprawnień i eksportów danych, z autorem i datą. Bez niego na pytanie „co się stało” po incydencie odpowiadasz domysłem.
  • Kopie zapasowe z testem odtworzenia. Dobra ankieta nie pyta, czy kopie są, tylko kiedy ostatnio ktoś coś z nich odtworzył. Kopia, której nikt nie sprawdził, jest hipotezą, nie zabezpieczeniem.
  • Aktualizacje i podatności. Jak często aktualizujecie biblioteki, z których zbudowana jest aplikacja, i kto o tym decyduje. System nieaktualizowany od dwóch lat tego pytania uczciwie nie przejdzie.
  • Dane klienta na żądanie. Czy umiecie wydać wszystkie dane klienta w czytelnym formacie i trwale je usunąć po końcu umowy. Do tego: gdzie fizycznie stoją serwery i kto ma do nich dostęp.
Nie wpisuj „tak” przy pytaniu, którego nie umiesz udowodnić. Ankieta z prawem do audytu to deklaracja, za którą odpowiadasz. Lepsza odpowiedź to „częściowo, wdrożenie do 15 grudnia” z krótkim planem: klient, który sam ma czas do kwietnia 2027, dostaje od Ciebie termin, który może wpisać do swojej dokumentacji. Nieprawda wykryta przy audycie kończy rozmowę o przedłużeniu umowy.

Kopie bazy danych i plików wykonujemy codziennie i przechowujemy przez 30 dni w innej lokalizacji niż serwer produkcyjny. Odtworzenie z kopii testujemy raz na kwartał na osobnym środowisku; ostatni test: 15.09.2026, pełne odtworzenie trwało 40 minut. Za kopie odpowiada [imię i nazwisko], a opis procedury jest w dokumentacji systemu.

Wzór odpowiedzi na pytanie o kopie zapasowe, z przykładowymi wartościami do podmiany na własne. Liczby, data i osoba odpowiedzialna robią różnicę: „tak, robimy kopie” niczego nie mówi, a taki akapit da się sprawdzić.

Ile kosztuje dogonienie braków: rachunek w godzinach

Stawka jest jedna i publiczna: 600 zł netto za godzinę, rozliczenie co kwadrans. Poniższe widełki są orientacyjne, dla typowej firmowej aplikacji webowej. Dokładną liczbę daje estymata po przeglądzie, którą akceptujesz, zanim cokolwiek ruszy.

  • Przegląd aplikacji pod ankietę: 3–5 h, czyli 1 800–3 000 zł netto. Inżynier przechodzi pytania o system, odpowiada na te, które da się zamknąć od ręki, i wypisuje braki z wyceną. Przy świeżej, utrzymywanej aplikacji bywa to jedyny wydatek.
  • Logowanie dwuetapowe: 3–6 h, czyli 1 800–3 600 zł netto. Dół widełek to kody z telefonu dla administratorów, góra to obowiązek dla wszystkich użytkowników razem z bezpiecznym odzyskiwaniem dostępu.
  • Dziennik zdarzeń z prostym podglądem: 4–8 h, czyli 2 400–4 800 zł netto. Zapis kluczowych akcji plus lista z filtrami, żeby dało się z niego cokolwiek wyczytać.
  • Kopie z testem odtworzenia: 2–4 h na ustawienie i opis procedury, potem około godziny na każdy kwartalny test.
  • Eksport i usuwanie danych klienta: 3–6 h, zależnie od tego, w ilu miejscach systemu leżą jego dane.
  • Zaległe aktualizacje: od kilku do kilkudziesięciu godzin. Najtrudniejsza pozycja do oszacowania z góry, bo zależy od tego, ile lat nikt ich nie robił. Bez przeglądu nikt uczciwy tej liczby nie poda.

Przykład: aplikacji brakuje logowania dwuetapowego, dziennika zdarzeń i opisanej procedury kopii. Przegląd plus trzy pozycje to 12–23 h, czyli 7 200–13 800 zł netto, jednorazowo. Przy zakupie pakietu saldo rośnie szybciej niż wpłata: za 20 opłaconych godzin masz na koncie 21 h, za 30 opłaconych 31,75 h. Godziny są ważne 18 miesięcy, więc reszta zostaje na kwartalne testy kopii i bieżące aktualizacje.

Zacznij od przeglądu, nie od budowy. Kilka godzin przeglądu rozdziela ankietę na trzy stosy: „tak, z dowodem”, „brak, wycena w godzinach” i „papier, nie system”. Z takim podziałem rozmawiasz z klientem o terminach zamiast o ogólnikach i nie płacisz za nic, czego ankieta nie wymaga.

Gdy aplikację zbudował ktoś inny

Najtrudniejsza ankieta trafia do firmy, której system postawił kiedyś freelancer albo agencja, a dziś nikt nie wie dokładnie, gdzie stoi serwer i kto ma do niego hasło. Pytanie „kto ma dostęp do systemu przetwarzającego nasze dane” nie ma wtedy uczciwej odpowiedzi, dopóki nie zrobisz inwentaryzacji:

  • Kod źródłowy – czy repozytorium jest na koncie Twojej firmy, czy tylko u wykonawcy.
  • Serwer i baza danych – na czyim koncie stoją, kto za nie płaci i kto ma hasła administratora.
  • Domena i poczta – czy są zarejestrowane na firmę, czy na prywatne dane kogoś, kto dawno odszedł.
  • Konta zewnętrznych usług – płatności, SMS-y, mapy: kto jest właścicielem i kto ma klucze dostępu.

Każdy punkt, przy którym odpowiedź brzmi „chyba ten dawny wykonawca”, to gotowe ryzyko łańcucha dostaw, dokładnie to, o które pyta Twój klient. Inwentaryzacja i przeniesienie dostępów na firmę to kilka godzin pracy, o ile dawny wykonawca współpracuje. Bez niej żadna odpowiedź w ankiecie nie jest prawdziwa.

Jak to wygląda u nas

Aplikacje, które budujemy, mają odpowiedzi na te pytania od pierwszego dnia. Za uncrn stoi aveneo, software house, który od 2008 roku robi projekty dla fintechu, healthtechu i korporacji, a te same standardy stosujemy niezależnie od wielkości projektu. Konkretnie:

  • Hasła i klucze. Hasła nie są przechowywane w postaci jawnej, logowanie opiera się na sprawdzonych mechanizmach, a klucze i hasła do baz trzymamy poza kodem, nie w repozytorium.
  • Podatności. Aplikacja stoi na własnych, utrzymywanych i łatanych komponentach aveneo zamiast na przypadkowych bibliotekach, a każdą linię kodu przegląda człowiek z co najmniej 5 latami doświadczenia, którego nazwisko widzisz w panelu.
  • Dane. Pokazy i piloty jadą na danych syntetycznych, umowę powierzenia (DPA) podpisujemy na życzenie, a serwer stoi tam, gdzie wybierzesz: u Ciebie, w Twojej chmurze albo w naszym hostingu zarządzanym.
  • Dokumentacja. Opis tego, co konkretnie robimy w zakresie bezpieczeństwa, dostajesz razem z kodem. To gotowy materiał do odpowiedzi w ankiecie.
  • Po wdrożeniu. W planie opieki: monitoring, aktualizacje bibliotek i łatki bezpieczeństwa, a czas reakcji na zgłoszenie jest umówiony z góry i zapisany. Bez planu masz repozytorium i dokumentację, więc aktualizacje zrobi każdy programista.

Prowadzimy serwis instalacji dla szpitala. Przyszła od nich ankieta bezpieczeństwa dostawcy w związku z NIS2, a nasz portal zleceń zbudował cztery lata temu freelancer, z którym nie mamy już kontaktu. Chcemy wiedzieć, na które pytania system odpowiada, czego brakuje i ile to kosztuje. Ankietę oddajemy do końca miesiąca.

Przykład wiadomości z formularza na /dla-firm. Tyle wystarczy, żeby zacząć od przeglądu: o szczegóły dopyta inżynier, ten sam, który potem uzupełni braki.

Formalności też da się wpisać do ankiety. Poufność obowiązuje od pierwszej wiadomości, wprost z regulaminu, a jeśli klient wymaga własnego wzoru NDA, sprawdzimy go w 1–3 dni. Kod i pełne prawa majątkowe są w 100% Twoje po każdym opłaconym etapie, fakturę VAT wystawia aveneo, a pracę bierze konkretny inżynier do 24 godzin od płatności. Budowa od zera: klikalna makieta to 10 h (6 000 zł netto), pierwsza działająca wersja to 30 h (18 000 zł netto), dojrzały produkt to 60 h (36 000 zł netto).

Ankieta NIS2 nie jest egzaminem z cyberbezpieczeństwa, tylko pytaniem klienta, czy może na Tobie polegać. Na część odpowiada papier, na część aplikacja, a różnica między „tak” a „tak, oto dowód” to policzalna liczba godzin, nie nowy system.

Wolisz liczby na własnym projekcie?

Przejdź ankietę z inżynierem (15 min)

← wszystkie wpisy