Czym jest test penetracyjny i kiedy firma go potrzebuje

Skanowanie, audyt i test penetracyjny to trzy różne prace z trzema różnymi cenami. Która odpowiada na Państwa pytanie i czego polskie przepisy naprawdę wymagają.

Proszą Państwo o ofertę na bezpieczeństwo strony internetowej i otrzymują trzy, które różnią się dziesięciokrotnie: na jednej stoi „skanowanie bezpieczeństwa”, na drugiej „audyt bezpieczeństwa”, na trzeciej „test penetracyjny”, a we wszystkich trzech jest to samo słowo „bezpieczeństwo”, które nic z tego, co je różni, nie mówi. To nie jest jedna praca w trzech stopniach i nie trzy ceny za to samo, tylko trzy różne prace, które odpowiadają na trzy różne pytania, więc pierwszym krokiem nie jest porównywanie cen, lecz zrozumienie, na które z tych trzech pytań naprawdę chcą Państwo odpowiedzi.

Ten artykuł odpowiada na dwa: czym jest test penetracyjny i czy jest potrzebny właśnie Państwa firmie. Drugie pytanie jest ważniejsze, bo większości polskich małych i średnich przedsiębiorstw żaden przepis nie nakazuje testu penetracyjnego z nazwy, a oferta, która o tym milczy, sprzedaje Państwu właściwą usługę w niewłaściwym momencie.

Piszemy to, sprzedając audyt bezpieczeństwa, i nie ma w tym sprzeczności, bo audyt, w którym jest miejsce na ręczną kontrolę, i test penetracyjny, którego w określonych przypadkach wymaga przepis, to nie jest ta sama praca, a firma, która kupuje drugi, kiedy potrzebowała pierwszego, płaci więcej i dowiaduje się mniej.

Trzy prace sprzedawane pod podobnymi nazwami

Terminologia branży jest tu nieczysta, ale pod spodem leży wyraźna granica, którą najcelniej nazywa instytucja standaryzacyjna: NIST SP 800-115 definiuje test penetracyjny jako testowanie bezpieczeństwa, w którym oceniający naśladują rzeczywiste ataki, żeby znaleźć drogi wokół ochrony systemu, i wskazuje, że szuka kombinacji podatności, a nie pojedynczych znalezisk. Ta sama publikacja opisuje skanowanie podatności jako technikę, którą identyfikuje się zasoby i odpowiadające im znane podatności.

W praktyce oznacza to cztery różne prace, które warto nazwać każdą z osobna. Skanowanie jest automatyczne: narzędzie porównuje Państwa system z bazą znanych podatności i zwraca listę. Ocena podatności to ta sama lista, którą człowiek sprawdził i uszeregował, zwykle nie wykorzystując żadnej ze znalezionych podatności. Test penetracyjny to praca prowadzona przez człowieka, w której znalezione słabe punkty są wykorzystywane i łączone w łańcuch, żeby ustalić, jak daleko napastnik naprawdę dochodzi. Audyt zgodności odpowiada na zupełnie inne pytanie: czy system spełnia nazwany standard albo normę.

Granicę między pierwszymi trzema najczytelniej formułuje standard kart płatniczych, i robi to nie definicją, tylko celem: wytyczne Rady do spraw standardów bezpieczeństwa PCI odróżniają test penetracyjny od skanowania według celu: skanowanie identyfikuje, porządkuje i zgłasza podatności; test szuka sposobów, żeby je wykorzystać i obejść ochronę systemu. Ta sama rada w swoim standardzie dopowiada obie strony: samo skanowanie nie jest testem penetracyjnym, a test, który tylko próbuje wykorzystać znaleziska skanera, też nie jest wystarczający.

Dlatego pytanie „czy potrzebują Państwo testu penetracyjnego” nie jest pytaniem o budżet, tylko o to, na co chcą Państwo odpowiedzi: czy w Państwa systemie są znane słabe punkty, czy też ktoś naprawdę może z nimi coś zrobić.

Co każda z nich odpowiada, a czego nie mówi

Skanowanie odpowiada szybko i tanio, a jego słabym punktem jest kontekst, bo narzędzie nie wie, która ze stu zaznaczonych pozycji stoi na Państwa formularzu płatności, a która w środowisku testowym, do którego nikt nie dochodzi z internetu, i nie wie też, że dwa osobno nieszkodliwe błędy razem dają dostęp do bazy danych — dlatego lista jest początkiem pracy, nie jej wynikiem.

Test penetracyjny odpowiada wolniej i drożej, a jego wartość leży właśnie w łańcuchu, bo tester nie szuka odpowiedzi na pytanie „czy tu jest podatność”, tylko „co z nią mogę zrobić” — czy z publicznego formularza da się dojść do uprawnień administratora, czy z konta jednego klienta widać dane innego, czy ze środowiska testowego da się dosięgnąć produkcyjnej bazy danych. Odpowiedź na to pytanie jest tą, którą dyrektor rozumie bez tłumaczenia.

Audyt zgodności nie robi ani jednego, ani drugiego, bo sprawdza, czy system spełnia normę, a jego wynikiem jest wyrok o zgodności, nie lista technicznych słabości; właśnie dlatego firma może przejść audyt zgodności i w tym samym tygodniu zostać zhakowana, i nie ma w tym żadnej sprzeczności, bo dwa dokumenty odpowiadają na dwa różne pytania.

Żadna z tych prac nie zastępuje pozostałych i żadna nie jest „lepsza” od innych, więc jedyne sensowne pytanie brzmi, która z nich teraz odpowiada na to, co Państwo naprawdę muszą wiedzieć.

Nieprecyzyjne nazwy nie są wyłącznie polskim problemem, i widać to, porównując rynki: w Finlandii, Szwecji i Norwegii rynek sprzedaje dwie prace — skanowanie i test penetracyjny — a wariant środkowy nie ma nazwy; traktuje się go jako wynik skanowania, nie jako osobną usługę. W Niemczech jest odwrotnie, bo tam jedno słowo bywa oznaczeniem wszystkich trzech prac, łącznie z samym testem, i właśnie dlatego przy porównywaniu ofert nazwa jest najsłabszym możliwym drogowskazem, a jedyne pewne pytanie pozostaje to, czy znalezione podatności zostaną wykorzystane.

Czy prawo wymaga testu penetracyjnego właśnie od Państwa

Tu warto być precyzyjnym, bo to miejsce, w którym oferty najczęściej przesadzają: w Polsce żaden przepis nie nakłada z nazwy obowiązku testu penetracyjnego na każdą firmę, która ma stronę internetową.

Ustawa o krajowym systemie cyberbezpieczeństwa, w brzmieniu nadanym nowelizacją, która weszła w życie 3 kwietnia 2026 roku i wdraża dyrektywę Unii Europejskiej 2022/2555, nakłada obowiązki na podmioty kluczowe i podmioty ważne: samoocenę własnego statusu, osobę odpowiedzialną, zarządzanie ryzykiem i zgłaszanie incydentów. Testu penetracyjnego sama ustawa z nazwy nie wymienia w żadnym artykule.

Kalendarzowy obowiązek, który ustawa nazywa, to artykuł 15 ustawy o krajowym systemie cyberbezpieczeństwa: podmiot kluczowy przeprowadza, na własny koszt, co najmniej raz na trzy lata, audyt bezpieczeństwa systemu informacyjnego wykorzystywanego przy świadczeniu usługi — wyrok o zgodności, nie test penetracyjny. Art. 8 wymaga testowania systemu informacyjnego oraz polityk i procedur oceny skuteczności środków technicznych i organizacyjnych, nadal nie nazywając testu penetracyjnego. Ten sam artykuł 15 pozwala organowi właściwemu nakazać podmiotowi kluczowemu w każdym czasie, a podmiotowi ważnemu po incydencie poważnym, przeprowadzenie zewnętrznego audytu; zespoły CSIRT mogą ponadto przeprowadzić ocenę bezpieczeństwa składającą się z testów bezpieczeństwa w celu identyfikacji podatności.

To są dwa warunki łącznie, nie jeden: firma, która nie jest podmiotem ustawy, z tych artykułów obowiązku nie bierze, a podmiot ważny — kalendarzowego audytu z artykułu 15 też nie, więc pierwszym krokiem nie jest prośba o ofertę, tylko samoocena, czy w ogóle są Państwo podmiotem.

Jak zrozumieć, czy są Państwo podmiotem ustawy

Ustawa o krajowym systemie cyberbezpieczeństwa nie wylicza firm z nazwy, tylko opisuje sektory i wielkość, a obowiązek oceny własnego statusu spoczywa na samym podmiocie, co w praktyce oznacza dwa pytania: czy Państwa działalność mieści się w którejś z dziedzin wymienionych w załącznikach do ustawy, i czy wielkość przedsiębiorstwa osiąga określony próg. Na oba trzeba odpowiedzieć samemu, a odpowiedź trzeba udokumentować — właśnie dlatego pierwszym wydatkiem w tej dziedzinie bywa zwykle konsultacja prawna, nie usługa techniczna.

Jeśli odpowiedź brzmi „nie”, dalsze punkty o rodzajach podmiotów w ogóle Państwa nie dotyczą, a jeśli „tak”, przychodzi drugie pytanie: czy są Państwo podmiotem kluczowym, czy ważnym. Kalendarzowy obowiązek audytu jest związany ze statusem podmiotu kluczowego, nie z samym byciem w systemie, i można być podmiotem, którego ten obowiązek nie obejmuje.

Jest też trzecia droga, która nie wymaga kalendarzowego audytu z artykułu 15: organ właściwy do spraw cyberbezpieczeństwa może nakazać podmiotowi kluczowemu w każdym czasie, a podmiotowi ważnemu po incydencie poważnym, przeprowadzenie zewnętrznego audytu, a zespoły CSIRT mogą przeprowadzić ocenę bezpieczeństwa. To nie jest planowy obowiązek testu penetracyjnego, ale powód, by wiedzieć, kto po Państwa stronie odpowie na takie żądanie.

Pozostałe progi nazywają testowanie, nie test penetracyjny

Artykuł 32 RODO wymaga regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych, a zakres wymagania jest związany z ryzykiem. To nie jest to samo, co obowiązek raz w roku zamówienia testu penetracyjnego, a oferta, która artykuł 32 podaje jako taki, parafrazuje rozporządzenie swobodniej, niż zostało napisane. Obowiązek wykazania, że testowanie w ogóle się odbywa, jest rzeczywisty; obowiązek wyboru właśnie tego rodzaju testowania z artykułu 32 nie wynika.

Standard kart płatniczych PCI DSS w wymaganiu 11.4 nazywa test penetracyjny wprost, raz na dwanaście miesięcy i po istotnych zmianach, ale to obowiązek umowny i dotyczy tego, jak przyjmują Państwo karty. Sklep internetowy, który płatności w całości przekazuje dostawcy usług płatniczych i sam danych kart nie przetwarza, i pozostali, w których środowisku dane kart się pojawiają, odpowiadają na to wymaganie różnie. To pytanie, na które odpowiada Państwa agent rozliczeniowy, nie artykuł.

W sektorze finansowym rozporządzenie 2022/2554 wymaga regularnego testowania, a testy penetracyjne ukierunkowane przez analizę zagrożeń (TLPT) przewiduje tylko dla tych instytucji, które nadzorca szczególnie wskazał. Standard ISO/IEC 27001 wymaga zarządzania podatnościami i testowania bezpieczeństwa, nie wymagając testu penetracyjnego z nazwy; twierdzenie, że bez niego nie wydaje się certyfikacji, jest rozpowszechnione i w standardzie go nie ma.

Jeśli żaden z tych progów Państwa nie dotyczy, to ustawowego obowiązku zamówienia testu penetracyjnego Państwo nie mają, i to nie znaczy, że nie ma nic do zrobienia, tylko że do zrobienia jest coś innego.

Jeśli żaden próg nie został przekroczony

Dla firmy, która nie jest podmiotem ustawy, danych kart nie przetwarza i w sektorze finansowym nie działa, najsensowniejsza praca to zwykle ta, która dzieje się regularnie, a nie raz na trzy lata. To aktualizacje, które mają odpowiedzialnego i termin; kopie zapasowe, które ktoś raz odtworzył i upewnił się, że naprawdę się odtwarzają; uwierzytelnianie wieloskładnikowe (MFA) na kontach administratorów, które ustawa o krajowym systemie cyberbezpieczeństwa podmiotom wymienia osobno i które pozostałym firmom jest równie przydatne; oraz regularne skanowanie, którego wyniki ktoś naprawdę czyta.

To nie jest mniejszy wariant odpowiedzi, tylko inny rodzaj pracy. Większość włamań, z którymi pracujemy, zaczyna się nie od wyrafinowanego ataku, lecz od nieaktualizowanego komponentu albo od hasła, które pasowało także gdzie indziej, i test penetracyjny raz na trzy lata przed tym nie chroni. Jeśli Państwa witryna już ucierpiała, kolejność jest inna i opisuje ją osobny artykuł o tym, jak odzyskać zhakowaną stronę.

Test penetracyjny staje się uzasadniony wtedy, gdy jest coś, co można stracić, i gdy rozmiar straty jest większy od ceny testu: system, w którym są dane innych ludzi, integracja, która styka się z pieniędzmi, albo zamawiający, który wymaga dowodu. Do tamtej chwili jest to właściwa praca w niewłaściwej kolejności.

Co się dzieje podczas testu

Praca zaczyna się od ustalenia zakresu i kończy raportem, a między nimi są trzy etapy, które warto rozumieć przed porównywaniem ofert, bo właśnie one tłumaczą, dlaczego jeden test kosztuje tyle, ile kosztuje, i dlaczego drugi za ten sam system kosztuje dziesięć razy mniej.

Pierwszy etap to rozpoznanie, w którym tester zbiera wszystko, co o systemie da się wiedzieć z zewnątrz — które adresy są publiczne, które technologie i wersje widać, gdzie są formularze logowania, jakie pliki są dostępne bez autoryzacji. Na tym etapie jeszcze nic nie jest wykorzystywane, ale właśnie tu najczęściej leżą znaleziska, których nikt nie oczekiwał: zapomniane środowisko testowe, otwarty listing katalogu, kopia zapasowa leżąca pod przewidywalnym adresem.

Drugi etap to sama kontrola, w której uruchamia się narzędzia automatyczne, żeby nie pominąć tego, co już znane, ale decyzje podejmuje człowiek, który sprawdza, czy znalezisko jest prawdziwe, próbuje je wykorzystać i patrzy, co z tego wynika. Tu powstaje łańcuch — dostęp do jednego konta, z niego dostęp do funkcji, której nie powinno dać się dosięgnąć, z niej dostęp do danych. Osobno żaden z kroków nie jest dramatyczny; razem stanowią historię.

Trzeci etap to udowodnienie i zapis, bo przy każdym znalezisku musi zostać dowód, który da się powtórzyć: jakie żądanie wysłano, jaka była odpowiedź, co się zmieniło. Bez tego raport jest opinią, a programista, który go dostaje, spędza dzień, próbując zrozumieć, co dokładnie tester zobaczył.

Dlatego terminy są takie, jakie są: test jednej niewielkiej witryny to kilka dni, a system z wieloma rolami, integracjami i płatnościami to tygodnie, i oferta, która obiecuje pełny test penetracyjny w jeden dzień, opisuje nie test, tylko skanowanie.

Dlaczego oferty różnią się dziesięciokrotnie

Gdy dwie oferty na tę samą witrynę różnią się dziesięć razy, różnica prawie nigdy nie leży w marży, i prawie zawsze leży w zakresie i metodzie: jedna proponuje automatyczne skanowanie narzędziem, które odpala się w godzinę i którego raport generuje to samo narzędzie, a druga proponuje tygodniową pracę człowieka, w której narzędzia są tylko początkiem, i właśnie tę różnicę nazwa „kontrola bezpieczeństwa” w obu przypadkach ukrywa.

Drugi czynnik kształtujący cenę to złożoność systemu, i da się ją ocenić, zanim rozmowa się zacznie: jedna publiczna strona internetowa bez kont użytkowników to jedna praca, a system z wieloma rolami, płatnościami, zewnętrzną integracją i danymi, które należą do klientów, to zupełnie inna, bo każda rola jest osobną sprawdzaną granicą, a każda integracja jest miejscem, w którym dwa systemy ufają sobie bardziej, niż powinny.

Trzeci to to, co po teście Państwo otrzymują i jak długo wykonawca zostaje przy sprawie: raport bez priorytetów, bez dowodów i bez ponownej kontroli kosztuje mniej dlatego, że jest mniejszą pracą, a dla firmy, która potem ma poprawić znaleziska, właśnie te trzy rzeczy rozstrzygają, czy dokument staje się listą zadań, czy teczką, której nikt już nie otwiera.

Dlatego porównywać oferty po cenie da się tylko wtedy, gdy zakres jest zapisany tak samo, a najprostszy sposób, żeby to uzyskać, to zapisać zakres samemu i poprosić wszystkich, by oferowali na nim, a nie pozwalać każdemu wykonawcy definiować własnego.

Kiedy test się dezaktualizuje

Wynik testu penetracyjnego opisuje konkretny system w konkretnym dniu, co jest oczywiste, a jednak właśnie tu powstaje większość nieporozumień między wykonawcą a zamawiającym, bo raport sprzed roku opisuje kod, który od tamtej pory zmienił się dziesiątki razy.

Terminy w przepisach same to przyznają: tam, gdzie kalendarz dotyczy testu penetracyjnego — dwanaście miesięcy przy PCI DSS — obok niego stoi zmiana jako prawdziwy powód. W standardzie kart płatniczych obok rocznego interwału stoi „po istotnych zmianach”, więc kalendarz jest tylko minimum, a prawdziwym powodem testu jest zmiana.

W praktyce oznacza to, że nowym powodem testu jest zmiana, która zmienia zasięg ataku: nowa publiczna funkcja, nowa integracja z zewnętrznym systemem, zmiana uwierzytelniania, przejście na inny hosting, nowa rola użytkownika z szerszymi uprawnieniami. Zmiana kolorów albo poprawka tekstu takim powodem się nie staje, choćby była widoczna.

Drugi powód to to, że zmieniło się otoczenie, nie Państwa kod: podatność w frameworku, którego Państwo używają, ujawnia się po teście, a test, który o niej nie wspomniał, nie pomylił się, bo wtedy jej jeszcze nie było. Dlatego regularne skanowanie i proces aktualizacji to to, co dzieje się między testami, i test tego nie zastępuje.

Bez zgody właściciela te same czynności są bezprawne

Test penetracyjny nie różni się technicznie od ataku, a jedyne, co je różni, to dokument: zgoda właściciela, w której nazwano zakres, czas i granice, i którą warto sporządzić na piśmie nawet wtedy, gdy przepis tego wprost nie wymaga. Bez niej te same czynności są tymi samymi czynnościami, i ma to skutki prawne.

W praktyce oznacza to, że zgody udziela ten, do kogo system należy, nie ten, kto go utrzymuje. Jeśli Państwa witryna działa na usłudze hostingu, o teście musi wiedzieć także dostawca, bo w przeciwnym razie jego systemy ochrony go zatrzymają albo zablokują Państwa konto. Jeśli w systemie jest komponent strony trzeciej, którego Państwo nie kontrolują, nie wchodzi on w zakres.

Granice zakresu trzeba zapisać przed, nie po, i na tej liście jest to, które adresy są w zakresie, a które nie, czy testujemy środowisko produkcyjne, czy kopię, co się dzieje, jeśli test przerwie usługę, i kto po Państwa stronie jest osiągalny w nocy; ta rozmowa zajmuje jedną godzinę i rozwiązuje większość sporów, które inaczej powstają w środku testu.

Czym test penetracyjny nie jest: red team, bug bounty i kontrola zgodności

Obok testu penetracyjnego istnieją prace, które bywają nazywane tym samym, a różnice między nimi nie są akademickie, tylko praktyczne — rozstrzygają, co Państwo zamawiają i co dostają.

Zadanie red teamu sprawdza nie system, tylko obronę: czy Państwa ludzie i procesy atak zauważają i co robią. Zakres jest szerszy, czas dłuższy, a część wartości leży właśnie w tym, że strona broniąca nie wie, że trwają ćwiczenia. Dla firmy, której nie ma co zauważyć, bo nikt nie czyta dzienników, ta praca jest przedwczesna.

Bug bounty to model, nie test: publikują Państwo zasady i płacą za znaleziska tym, którzy je przysyłają. Może znaleźć to, czego jeden tester nie zauważył, ale nie daje ani gwarancji zakresu, ani terminu, ani raportu, który można dołączyć do dokumentów zamówienia.

Testy penetracyjne ukierunkowane przez analizę zagrożeń (TLPT) to osobna, regulowana praca w sektorze finansowym, i jest zdefiniowana w rozporządzeniu Unii Europejskiej. Jeśli Państwa firma nie jest wskazaną przez nadzorcę instytucją finansową, tego terminu w Państwa ofercie nie powinno być.

Kolejną granicą, którą często się zaciera, jest ta między „czarną”, „białą” i „szarą skrzynką” — ile tester wie o systemie już na początku. To porozumienie branży, nie wymóg przepisu, i ma bezpośredni wpływ na cenę i na to, co test znajdzie. Tester bez dostępu naśladuje obcego; tester z kontem i dokumentacją w tym samym czasie dosięga więcej. Żaden z wariantów nie jest tym właściwym; pytanie brzmi, czego się Państwo boją.

Co Państwo otrzymują i jak to czytać

Wynikiem testu jest raport, a jego wartość leży w priorytetach, nie w liczbie znalezisk, bo raport ze stu pozycjami, w którym nie powiedziano, od której zacząć, jest dokładnie tak samo nieużyteczny jak wydruk ze skanera. Dobry raport przy każdym znalezisku mówi, co napastnik może z nim zrobić, jak łatwo, i co konkretnie zmienić.

Drugie, czego trzeba żądać, to kontrola po poprawkach, bo znalezisko, które zostało poprawione, i znalezisko, o którym ktoś myśli, że zostało poprawione, różnią się od siebie, a jedyny sposób, żeby to ustalić, to sprawdzić jeszcze raz. Robimy to w ciągu trzydziestu dni po poprawkach, i tego terminu warto żądać od każdego wykonawcy.

Trzecie to to, co z raportem zrobi Państwa programista. Znalezisko opisane numerem CVE i bez kontekstu oznacza dla programisty szukanie; znalezisko, do którego dołączono konkretne żądanie i miejsce w kodzie, oznacza poprawkę. Jeśli wytwarzaniem zajmuje się jedna firma, a testem inna, właśnie ta różnica rozstrzyga, czy poprawki zostaną zrobione w tydzień, czy w kwartale.

Czwarte to to, czego w raporcie nie wolno: twierdzenia, że system jest teraz bezpieczny. Test pokazuje, co w danym zakresie w danym dniu udało się zrobić. Nie dowodzi, że nie ma niczego innego, a wykonawca, który to obiecuje, sprzedaje Państwu pocieszenie.

Jest jeszcze jeden powód, dla którego tę rozmowę warto zacząć wcześniej, niż się wydaje potrzebne: test, który odbywa się tydzień przed uruchomieniem systemu, znajduje to samo, co znalazłby trzy miesiące wcześniej, ale na poprawienie znalezisk nie ma już ani czasu, ani budżetu, i w praktyce kończy się listą przyjętą jako ryzyko, a nie poprawkami — dlatego test przed uruchomieniem ma być zrobiony wtedy, gdy na poprawki jeszcze jest czas, i ta sama logika jest coś warta także dla tych, których żaden kalendarz nie wiąże.

I ostatnie, co warto powiedzieć wprost: test penetracyjny nie jest poświadczeniem, że system jest bezpieczny, tylko poświadczeniem, że w konkretnym dniu w konkretnym zakresie znana umiejętność nie znalazła drogi dalej niż coś konkretnego, i dlatego najcenniejszą częścią raportu często bywa nie lista znalezisk, lecz opis tego, co próbowano i się nie udało, bo właśnie ta część następnemu testerowi za trzy lata mówi, gdzie nie warto zaczynać od zera.

Co przygotować przed rozmową

Żeby oferta w ogóle dała się porównać, wykonawca musi znać zakres, więc proszę przygotować listę adresów i systemów, które do niego wchodzą, wskazać, czy testujemy środowisko produkcyjne, czy kopię, powiedzieć, co w systemie jest takiego, czego nie wolno tknąć, i nazwać człowieka, który może zezwolić na przerwanie testu.

Środowisko produkcyjne czy kopia

To pytanie, które rozstrzyga i cenę, i ryzyko, bo test w środowisku produkcyjnym pokazuje to, co naprawdę jest dostępne, i właśnie dlatego może coś zepsuć: przeciążyć, wypełnić bazę danych wpisami testowymi, wysłać klientom prawdziwe e-maile albo utknąć w systemie ochrony, który blokuje testera, a potem blokuje także część Państwa użytkowników.

Test na kopii jest bezpieczniejszy i zarazem niepełny, bo kopia rzadko jest identyczna: bywa, że nie ma w niej rzeczywistych integracji, rzeczywistej skali danych i rzeczywistej konfiguracji, a właśnie w konfiguracji często leży problem. Jeśli wybierają Państwo kopię, proszę zapisać, czym różni się od środowiska produkcyjnego, bo ta lista jest także listą tego, czego test nie sprawdził.

Środek, którego używamy najczęściej: czynności odczytu w środowisku produkcyjnym, zapisu i potencjalnie niszczące — na kopii, z wcześniej uzgodnionym oknem i człowiekiem, który może przerwać. To nie jest kompromis dla ceny, tylko sposób, żeby dostać odpowiedzi obu wariantów, nie przerywając pracy.

Przydaje się też lista przeciwna, mianowicie to, czego nie ma w zakresie, bo granice przyjęte milczeniem to te, o które później się spiera. Usługi stron trzecich, których Państwo nie utrzymują, do niego nie wchodzą, a ich testowanie bez zgody tych stron to ten sam problem, o którym jest poprzedni rozdział. Jeśli Państwa witryna korzysta z zewnętrznego okna płatności, zewnętrznego okna rozmowy albo zewnętrznej analityki, to cudza własność, a oferta, która obiecuje je „także sprawdzić”, obiecuje to, czego nie wolno.

Wreszcie proszę powiedzieć, co stanie się ze znaleziskami potem: kto je poprawi, w jakim terminie, i czy wykonawca po poprawkach sprawdzi jeszcze raz. Test bez tego uzgodnienia często kończy się dokumentem, którego nikt nie otwiera, i to jest najdroższa możliwa wersja: zapłacone za wiedzę, której się nie używa.

Proszę też powiedzieć, na co szukają Państwo odpowiedzi, bo „musimy spełnić wymaganie” i „chcemy wiedzieć, czy ktoś może dostać się do danych klientów” to dwie różne prace z dwiema różnymi cenami, a wykonawca, który nie pyta, która z nich jest Państwa, zaoferuje tę, która jemu jest wygodniejsza.

Jeśli nie są Państwo pewni, po której stronie progu Państwo stoją, od tego warto zacząć. Audyt automatyczny zwykle odpowiada na pytanie o znane słabe punkty taniej i szybciej niż ręczna praca eksperta, a jego wynik mówi też, czy test penetracyjny jest następnym krokiem. Rozmowę o zakresie warto zacząć od opisu procesu, nie od listy technologii, bo zakres wyznacza to, co Państwo tracą, jeśli system zawiedzie.