Ankieta bezpieczeństwa klienta Enterprise — co sprawdzają i jak się przygotować

Skąd bierze się ta ankieta

Dostałeś wiadomość od potencjalnego klienta Enterprise: zainteresowani, ale zanim podpiszemy — musimy przeprowadzić Vendor Risk Assessment. Do załącznika jest Excel z 150 pytaniami.

To nie jest formalność. To jest filtr. Enterprise kupuje od dostawców których ryzyko rozumie i akceptuje. Twoje odpowiedzi na tę ankietę albo otworzą drzwi, albo zakończą rozmowy na tym etapie — niezależnie od jakości Twojego produktu.

Poniżej wyjaśniamy co ankieta faktycznie sprawdza, których odpowiedzi szukają analitycy i jak przygotować się żeby ta rozmowa przebiegła sprawnie.

Czego ankieta faktycznie szuka — nie pytania, ale sygnały

Doświadczony analityk bezpieczeństwa nie czyta każdego z 150 pytań z jednakową uwagą. Szuka sygnałów dojrzałości organizacyjnej w kilku kluczowych obszarach. Ankieta jest narzędziem — nie celem samym w sobie.

Pierwsze co sprawdza: czy odpowiedzi są spójne wewnętrznie. Firma która twierdzi że “stosuje rotację sekretów co 90 dni” ale nie ma odpowiedzi na pytanie “kto jest właścicielem procesu rotacji” — wysyła sygnał że odpowiedź była aspiracyjna, nie opisowa.

Drugi sygnał: czy firma rozumie własne środowisko. Pytanie o podprocesorów danych lub dostawców ICT nie powinno powodować konsultacji z całym zespołem. Organizacja która nie ma inwentaryzacji własnych narzędzi prawdopodobnie nie zarządza też ryzykiem z nimi związanym.

Trzeci sygnał: jak firma opisuje incydenty i luki. “Nie mieliśmy żadnych incydentów” jest czerwoną flagą — bo oznacza albo że firma nie ma systemu wykrywania (i dlatego nie wie), albo że nie jest szczera. Organizacje dojrzałe opisują incydenty które miały, jak je obsłużyły i co zmieniły.

Obszar 1 — Zarządzanie dostępem (pytania 1–30 typowo)

To najczęściej weryfikowany obszar, bo jest konkretny i można go sprawdzić. Pytania dotyczą: czy stosowane jest MFA dla wszystkich kont, jak wygląda onboarding i offboarding (szczególnie odbieranie dostępów przy odejściu), jak zarządzany jest dostęp uprzywilejowany do produkcji.

Odpowiedzi których szukają analitycy: MFA wymagane dla wszystkich, nie tylko “zachęcane”. Offboarding w ciągu 24 godzin, nie “w ciągu tygodnia”. Dostęp do produkcji przez PAM lub wymaga zatwierdzenia, nie przez wspólne hasło.

Odpowiedzi które budzą pytania: “MFA jest opcjonalne ale zachęcamy”. “Dostęp jest odbierany przy zakończeniu umowy”. “Używamy współdzielonych kont dla środowisk testowych”. Każda z tych odpowiedzi to element do dalszej weryfikacji.

Obszar 2 — Bezpieczeństwo procesu wytwórczego (CI/CD)

Ten obszar rośnie w każdej iteracji ankiet bezpieczeństwa po incydentach SolarWinds i XZ Utils. Pytania dotyczą: jak zarządzane są sekrety i klucze w pipeline, czy przeprowadzane są automatyczne testy bezpieczeństwa (SAST, SCA), jak wygląda code review, jak przebiega deployment na produkcję.

Dla firm technologicznych sprzedających oprogramowanie ten obszar jest często weryfikowany najgłębiej — bo pipeline jest miejscem gdzie powstaje produkt który kupujący będzie uruchamiał we własnej infrastrukturze.

Konkretne pytania które pojawiają się coraz częściej: “Czy generujecie SBOM dla każdego wydania?”, “Czy artefakty są podpisywane kryptograficznie przed deploymentem?”, “Jak weryfikujecie integralność zewnętrznych zależności?”. Trzy lata temu to były pytania tylko w ankietach największych firm. Dziś pojawiają się w standardowych kwestionariuszach mid-market Enterprise.

Obszar 3 — Zarządzanie incydentami

Pytania w tym obszarze weryfikują czy firma ma plan na sytuację kryzysową — nie tylko czy potrafi jej zapobiec. Obejmują: czy istnieje udokumentowany proces IR (Incident Response), jak wygląda komunikacja z klientami przy incydencie naruszenia danych, jakie są określone czasy powiadomienia.

DORA nakłada konkretne wymogi czasowe na instytucje finansowe — a te wymagania spływają do dostawców ICT jako klauzule kontraktowe. Jeśli sprzedajesz do banku lub fintecha, spodziewaj się pytania: “Czy możecie zagwarantować powiadomienie o incydencie w ciągu 4 godzin od wykrycia?”.

Odpowiedź “powiadomimy niezwłocznie” jest niewystarczająca. Analitycy szukają: zdefiniowanego progu (co to jest incydent wymagający powiadomienia), zdefiniowanych ról (kto podejmuje decyzję o powiadomieniu), zdefiniowanego kanału (jak powiadomienie dotrze do właściwej osoby po stronie klienta).

Obszar 4 — Certyfikacje jako skrót

SOC 2 Type II i ISO 27001 działają w procesie VRA jak paszport — zastępują dziesiątki pytań. Firma która dostarcza aktualny raport SOC 2 lub certyfikat ISO 27001 odpowiada na pytania o kontrole dostępu, zarządzanie podatnościami, monitoring i reagowanie na incydenty jednym dokumentem.

Dla firm które planują sprzedaż do wielu klientów Enterprise, koszt certyfikacji zwraca się szybciej niż koszt czasu spędzonego na wypełnianiu kolejnych ankiet. Każda ankieta bez certyfikacji to 2-5 godzin pracy kogoś z zespołu technicznego — i potencjalnie kolejne rundy pytań dodatkowych.

Certyfikacja nie eliminuje procesu VRA — ale znacznie go skraca. I daje analitykowi bezpieczeństwa to czego potrzebuje: potwierdzenie przez niezależną trzecią stronę że kontrole rzeczywiście istnieją i działają.

Dlaczego przygotowanie ad hoc nie działa

Najgorszy moment na zebranie dokumentacji do VRA to tydzień po tym jak ankietę dostałeś. Pod presją czasu, zbierając dowody ad hoc, produkujesz niespójne odpowiedzi — i analityk to widzi.

Firmy które przez to przeszły mówią podobnie: pierwsze VRA zajęło 3 tygodnie i skończyło się „wyślemy odpowiedzi za miesiąc”. Drugie — z gotową dokumentacją — zajęło 2 dni. Różnica nie leżała w tym że ktoś lepiej wypełnił Excela. Leżała w tym że przy pierwszym VRA dokumentacja nie istniała i trzeba ją było tworzyć pod każde pytanie od zera.

Dokumentacja audytowa generowana automatycznie przez pipeline — logi, SBOM, podpisy artefaktów, provenance, mapowanie na konkretne wymagania regulacyjne — to coś czego nie da się zastąpić dobrą wolą i bieganiem po organizacji pod presją terminu odpowiedzi.