Jedna fałszywa faktura potrafi być dla firmy groźniejsza niż kilkadziesiąt technicznych prób włamania. Nie dlatego, że phishing jest szczególnie skomplikowany. Problem polega na tym, że atakujący wykorzystuje proces, który pracownik wykonuje codziennie: otwiera dokument od kontrahenta, loguje się do Microsoft 365, zatwierdza płatność albo sprawdza wiadomość od przełożonego.
Skala zjawiska daje przestrzeń na wyspecjalizowaną usługę. CERT Polska zarejestrował w 2025 r. 260 783 incydenty bezpieczeństwa, z czego 78 391 stanowił phishing — około 30% wszystkich zdarzeń. Jeszcze szersza kategoria oszustw komputerowych odpowiadała za 253 238 incydentów, czyli ponad 97% całości. Do tej grupy należą jednak również fałszywe sklepy czy oszustwa inwestycyjne, więc nie można wyciągać z niej prostego wniosku, że rynek szkoleń phishingowych urósł dokładnie w takim samym tempie.
Jest za to inny, dużo bardziej praktyczny wniosek: firmy mają coraz więcej powodów, żeby sprawdzać nie tylko filtry antyspamowe, ale również sposób reagowania ludzi.
To zmienia sam pomysł na biznes. Nie chodzi o sprzedaż prezentacji „jak rozpoznać phishing”. Trudniejszym do skopiowania produktem jest kontrolowana symulacja, pomiar zachowania, szkolenie wynikające z zaobserwowanych błędów i drugi test pokazujący, czy coś się rzeczywiście zmieniło.
Nie sprzedajesz wykładu. Sprzedajesz pomiar i zmianę zachowania
Najprostsza wersja produktu to 60–90 minut szkolenia online. Jest łatwa do zorganizowania, ale również łatwa do porównania z dziesiątkami podobnych ofert. W publicznych polskich cennikach w 2026 r. można znaleźć takie szkolenia za około 2,5 tys. zł netto, podczas gdy pojedyncza profesjonalnie przygotowana kampania phishingowa z raportem pojawia się w ofertach za około 5 tys. zł netto. Pakiet łączący test, szkolenie i analizę dla kilkudziesięciu pracowników może wejść w zakres około 6–10 tys. zł netto, zależnie od liczby scenariuszy i stopnia personalizacji.
Nie są to jednak stawki, które należy kopiować bez zastanowienia. Firma zatrudniająca 40 osób, która potrzebuje jednego prostego testu, to inny projekt niż organizacja mająca 300 pracowników, kilka domen, oddziały zagraniczne i dział SOC oczekujący sprawdzenia własnej reakcji na zgłoszenie.
Dlatego usługę lepiej podzielić na cztery poziomy:
-
szkolenie — przekazanie wiedzy bez rzeczywistego pomiaru zachowania;
-
pojedyncza symulacja — sprawdzenie reakcji na konkretny scenariusz;
-
baseline + szkolenie + retest — pomiar początkowy, edukacja i drugi pomiar;
-
program security awareness — cykliczne scenariusze, analiza trendu i szkolenia dopasowane do wyników.
Dla nowej firmy usługowej najlepszym produktem startowym jest zwykle trzeci wariant. Jest jeszcze możliwy do ręcznego przygotowania, a jednocześnie daje klientowi coś więcej niż wykres pokazujący, kto kliknął.
Dobrym pierwszym segmentem mogą być firmy zatrudniające mniej więcej 30–150 osób, szczególnie te, w których dużą część pracy wykonuje się przez pocztę i systemy chmurowe. Liczba pracowników nie jest jednak najważniejsza. Ważniejsze są procesy.
Najbardziej podatne biznesowo są organizacje, w których występują:
-
faktury i zmiany numerów rachunków;
-
korespondencja z dużą liczbą kontrahentów;
-
dokumenty przesyłane przez Microsoft 365, SharePoint, OneDrive lub Google Workspace;
-
pracownicy sprzedaży regularnie otwierający wiadomości od nowych osób;
-
kadry obsługujące dokumenty i dane pracowników;
-
zarząd mogący stać się celem BEC, czyli podszywania się pod przełożonego lub partnera biznesowego.
Silnym impulsem zakupowym jest też wcześniejszy incydent. Firma, która właśnie odzyskała przejętą skrzynkę albo zatrzymała fałszywy przelew, zwykle nie potrzebuje tłumaczenia, dlaczego problem istnieje. Trzeba jej natomiast wyjaśnić, co dokładnie zostanie sprawdzone i co zrobi z wynikiem.
To pierwsze miejsce, w którym początkujący usługodawcy popełniają błąd. Obiecują „test podatności pracowników”, chociaż jeden e-mail nie jest w stanie zmierzyć całej odporności organizacji.
Symulacja może sprawdzić określone zachowanie.
Przykładowo:
Fałszywe powiadomienie o udostępnieniu pliku sprawdza reakcję na żądanie logowania.
Zmiana rachunku bankowego kontrahenta powinna sprawdzać przede wszystkim, czy pracownik uruchomi procedurę dodatkowej weryfikacji płatności. Samo kliknięcie nie musi być tutaj najważniejszym zdarzeniem.
BEC z poleceniem prezesa testuje reakcję na autorytet i presję czasu.
Wiadomość dotycząca dokumentu kandydata może być sensowna dla HR, ale praktycznie niczego nie powie o zachowaniu księgowości.
Spear phishing wymaga natomiast dużo większego dopasowania do konkretnej roli. Nie powinien być pierwszym testem firmy, w której podstawowa kampania nadal powoduje masowe kliknięcia.
Jeżeli pierwszy test kończy się 30-procentowym odsetkiem kliknięć i prawie nikt nie zgłasza podejrzanej wiadomości, budowanie skomplikowanego spear phishingu jest zwykle stratą czasu. Najpierw trzeba usunąć podstawowy problem.
Właśnie takie decyzje powinien sprzedawać usługodawca. Nie „zrobiliśmy phishing”, tylko: sprawdziliśmy określone zachowanie, znaleźliśmy problem i wiemy, jaki następny krok ma największy sens.
Dobra symulacja zaczyna się przed wysłaniem pierwszej wiadomości
Załóżmy modelową firmę handlową zatrudniającą 70 osób. Pracownicy używają Microsoft 365, handlowcy dostają dokumenty od klientów, a księgowość regularnie obsługuje faktury. Firma ma MFA, ale nie prowadziła wcześniej kontrolowanych symulacji.
Pierwszy etap nie powinien polegać na wybieraniu efektownego szablonu wiadomości.
Najpierw trzeba ustalić:
-
co test ma zmierzyć;
-
które grupy pracowników biorą udział;
-
jak pracownicy powinni prawidłowo zgłosić podejrzaną wiadomość;
-
kto po stronie klienta reaguje na zgłoszenia;
-
jakie dane zostaną zapisane;
-
kto będzie miał dostęp do wyników indywidualnych;
-
jak długo wyniki będą przechowywane;
-
kto może zatrzymać kampanię, jeżeli pojawi się problem.
Dopiero potem wybiera się scenariusz.
W firmie handlowej można rozpocząć od wiadomości imitującej udostępnienie dokumentu klienta. To scenariusz wystarczająco realistyczny, ale mniej drażliwy niż informacja o zwolnieniu, premii, problemie zdrowotnym czy zaległym wynagrodzeniu.
Takich tematów lepiej nie używać tylko dlatego, że zwiększają klikalność. Dobry test ma mierzyć zachowanie, a nie sprawdzać, jak silną emocję potrafisz wywołać. Kampania, która daje świetne statystyki kosztem zaufania pracowników, może być biznesowo nieudana.
Technicznie można wykorzystać własną platformę, narzędzie open source takie jak Gophish albo rozwiązanie już obecne u klienta. W środowisku Microsoft funkcja Attack Simulation Training jest dostępna dla organizacji korzystających z Microsoft Defender for Office 365 Plan 2 lub Microsoft 365 E5. Wybór narzędzia powinien wynikać z potrzeb projektu, a nie odwrotnie.
Najbardziej irytująca część realizacji zaczyna się właśnie tutaj. Samo przygotowanie wiadomości może zająć godzinę. Uzgodnienie dostarczalności, ustawień środowiska, zakresu testu i odpowiedzialności potrafi trwać dłużej niż stworzenie całej kampanii.
Trzeba też uważać z automatycznym „whitelistowaniem wszystkiego”.
Jeżeli celem jest czysty pomiar reakcji pracownika, kontrolowana konfiguracja zapewniająca dostarczenie wiadomości może być uzasadniona.
Jeżeli klient chce sprawdzić cały łańcuch ochrony — filtr pocztowy, użytkownika i reakcję IT lub SOC, szerokie ominięcie zabezpieczeń zafałszuje wynik. Kampania może wtedy odpowiedzieć na zupełnie inne pytanie niż to, które klient chciał zadać.
To samo dotyczy pomiaru.
Sam click rate jest zbyt ubogi.
Przy kampanii dobrze rozdzielić co najmniej:
-
delivery rate — ile wiadomości rzeczywiście dostarczono;
-
click rate — ile osób kliknęło;
-
unsafe-action rate — ile osób wykonało symulowaną niebezpieczną czynność;
-
report rate — ile osób prawidłowo zgłosiło wiadomość;
-
time-to-report — ile czasu minęło do pierwszego prawidłowego zgłoszenia;
-
repeat susceptibility — czy ta sama osoba lub grupa ponownie reaguje niebezpiecznie;
-
improvement rate — jak zmieniły się wyniki między baseline’em a retestem.
To ważne, ponieważ identyczny odsetek kliknięć może oznaczać dwie zupełnie różne sytuacje.
Przykład modelowy:
Do 70 pracowników wysłano kampanię, a 68 wiadomości zostało dostarczonych.
Pierwszy test daje:
-
12 kliknięć — 17,6% dostarczonych wiadomości;
-
5 symulowanych niebezpiecznych działań — 7,4%;
-
26 prawidłowych zgłoszeń — 38,2%;
-
pierwsze zgłoszenie po 4 minutach.
Sam wynik 17,6% kliknięć nie wygląda dobrze, ale organizacja ma już działający mechanizm wczesnego ostrzegania. 26 osób rozpoznało problem i zgłosiło go.
Inny klient może mieć tylko 10% kliknięć, ale ani jednego zgłoszenia przez sześć godzin. Na pierwszy rzut oka wynik jest lepszy. Operacyjnie sytuacja może być gorsza, bo nikt nie uruchamia reakcji.
Dlatego raport nie powinien kończyć się zdaniem: „12 pracowników kliknęło”.
Lepszy wniosek brzmi:
„Podatność na kliknięcie jest widoczna, ale organizacja ma stosunkowo aktywną grupę zgłaszającą. Priorytetem jest ograniczenie wykonywania niebezpiecznych działań i ujednolicenie sposobu raportowania, a nie samo zwiększanie liczby osób rozpoznających podejrzane wiadomości.”
Po szkoleniu można zrobić retest po około 30–60 dniach, jeżeli celem jest sprawdzenie krótkoterminowej zmiany zachowania. Nie jest to jednak magiczny termin obowiązujący każdą firmę.
W modelowym reteście znowu dostarczono 68 wiadomości:
-
5 osób kliknęło — 7,4%;
-
2 wykonały niebezpieczne działanie — 2,9%;
-
34 zgłosiły wiadomość — 50%;
-
pierwsze zgłoszenie pojawiło się po 2 minutach.
Teraz da się już pokazać zmianę. Odsetek kliknięć spadł o 10,2 punktu procentowego, a report rate wzrósł o 11,8 punktu procentowego.
To nadal nie dowodzi, że firma „jest odporna na phishing”. Druga kampania mogła być prostsza. Pracownicy mogli też spodziewać się kolejnego testu. Dlatego dobry raport powinien opisywać również trudność scenariusza i ograniczenia porównania.
NIST stosuje w tym celu m.in. podejście Phish Scale, które uwzględnia trudność rozpoznania wiadomości. To cenna wskazówka praktyczna: nie należy porównywać dwóch kampanii wyłącznie na podstawie procentu kliknięć, jeżeli jedna była oczywistą podróbką, a druga bardzo dobrze imitowała codzienną korespondencję.
Bezpieczeństwo samego testu ma jeszcze wyższy priorytet niż statystyki.
Strona symulacyjna nie powinna przechowywać prawdziwych haseł. Jeżeli celem jest sprawdzenie próby podania danych, wystarczy zarejestrować zdarzenie pozwalające stwierdzić, że użytkownik wykonał określoną akcję. Nie ma powodu tworzyć bazy rzeczywistych poświadczeń.
Tak samo nie powinno się zbierać danych „na wszelki wypadek”.
Przed kampanią trzeba określić:
-
minimalny zakres danych niezbędnych do raportu;
-
zasady dostępu do wyników indywidualnych;
-
czas retencji;
-
sposób usunięcia danych po projekcie;
-
role klienta i wykonawcy w przetwarzaniu danych;
-
procedurę na wypadek przypadkowego przesłania prawdziwych informacji;
-
kontakt alarmowy i możliwość przerwania testu.
Przy RODO nie ma sensu stosować jednego gotowego zdania do każdego wdrożenia. Inaczej wygląda projekt, w którym usługodawca otrzymuje tylko adresy służbowe i oddaje zagregowany raport, a inaczej system przechowujący historię zachowania konkretnego pracownika przez wiele miesięcy. Zakres i role stron trzeba ustalić przed testem, a nie dopisywać po fakcie do umowy.
Jest też jedna granica, której nie należy przekraczać: symulacja nie może stać się narzędziem do publicznego piętnowania ludzi.
Ranking „dziesięciu pracowników, którzy najłatwiej dali się nabrać” wygląda efektownie na spotkaniu zarządu, ale jest kiepskim mechanizmem bezpieczeństwa. Następnym razem pracownik może ukryć pomyłkę zamiast zgłosić ją w ciągu dwóch minut.
A szybkie zgłoszenie jest dokładnie tym zachowaniem, które firma powinna wzmacniać.
Jak wycenić usługę, żeby nie pracować za darmo
Najczęstszy błąd przy kalkulacji wygląda tak: usługodawca liczy godzinę szkolenia i czas wysłania kampanii, a pomija wszystko, co znajduje się pomiędzy.
Przy 70-osobowej firmie modelowy projekt może wyglądać następująco:
-
discovery i ustalenie zakresu — 1,5 godziny;
-
przygotowanie scenariusza — 2,5 godziny;
-
konfiguracja środowiska i test dostarczalności — 3 godziny;
-
uzgodnienia z klientem — 1,5 godziny;
-
monitoring kampanii — 1 godzina;
-
analiza i raport — 3 godziny;
-
przygotowanie i przeprowadzenie szkolenia — 2,5 godziny;
-
retest i porównanie wyników — 2 godziny;
-
administracja projektu — 1 godzina.
Łącznie: 18 godzin pracy.
Jeżeli wewnętrzny koszt godziny specjalisty wynosi w modelowej kalkulacji 180 zł, koszt pracy to:
18 × 180 zł = 3240 zł.
Dodajmy orientacyjnie 650 zł na narzędzia, infrastrukturę i pozostałe bezpośrednie koszty projektu.
Łączny koszt bezpośredni:
3240 + 650 = 3890 zł.
Przy cenie sprzedaży 7900 zł netto zostaje:
7900 – 3890 = 4010 zł.
To około 50,8% marży projektowej przed kosztami stałymi firmy, pozyskaniem klienta i podatkami.
Ta kalkulacja nie jest rynkowym cennikiem. Pokazuje metodę. Jeżeli realnie spędzasz nad projektem 30 godzin, a wpisujesz do wyceny 12, nawet pozornie wysoka cena szybko przestaje być atrakcyjna.
Na koszt najmocniej wpływają:
-
liczba pracowników;
-
liczba oddzielnych grup;
-
liczba scenariuszy;
-
stopień personalizacji wiadomości;
-
konieczność stworzenia własnych stron testowych;
-
liczba języków;
-
zakres raportowania;
-
szkolenie na żywo;
-
retest;
-
dodatkowe konsultacje;
-
sprawdzenie procesu zgłaszania i reakcji IT lub SOC;
-
cykliczność programu.
Dlatego ofertę dobrze budować pakietowo.
START — pojedyncza kampania
Dla firmy, która chce zobaczyć punkt wyjścia.
Zakres może obejmować:
-
jedną grupę;
-
jeden scenariusz;
-
kontrolowaną kampanię;
-
podstawowe metryki;
-
raport;
-
spotkanie omawiające.
Przy obecnych realiach rynkowych cena około 5 tys. zł netto za profesjonalnie przygotowaną kampanię z raportem nie jest oderwana od publicznych ofert, ale przy większej personalizacji szybko przestaje wystarczać.
ROZWÓJ — baseline + szkolenie + retest
To najbardziej sensowny pakiet dla firmy, która chce mierzyć zmianę.
Zakres:
-
kampania bazowa;
-
raport;
-
szkolenie 60–90 minut;
-
zalecenia dla wybranych działów;
-
retest;
-
porównanie wyników.
W przypadku kilkudziesięciu pracowników można orientacyjnie myśleć o poziomie 6–10 tys. zł netto, ale dopiero po policzeniu własnego nakładu pracy.
PROGRAM — cykliczne bezpieczeństwo
Tutaj klient kupuje kilka różnych scenariuszy w roku, analizę trendu, szkolenia i okresowe raportowanie.
Nie należy bezmyślnie wykonywać tej samej kampanii co dwa miesiące. Po kilku powtórzeniach pracownicy nauczą się rozpoznawać charakterystyczny styl testu, a nie rzeczywiste zagrożenia.
Scenariusze trzeba rotować. Księgowość może dostać próbę zmiany danych płatniczych, handlowcy wiadomość dotyczącą dokumentu klienta, a kadra zarządzająca scenariusz BEC.
Dobry raport zarządczy również nie powinien być automatycznym eksportem z platformy.
Powinien zawierać przynajmniej:
-
cel kampanii;
-
zakres i grupy uczestników;
-
opis scenariusza;
-
najważniejsze wyniki;
-
porównanie grup;
-
czas i liczbę zgłoszeń;
-
niebezpieczne działania;
-
ograniczenia testu;
-
priorytetowe rekomendacje;
-
zakres kolejnego testu.
Zamiast:
„17 osób kliknęło link.”
lepiej napisać:
„Największa podatność wystąpiła w dziale handlowym, gdzie pracownicy codziennie otrzymują dokumenty od nowych kontaktów. Kolejny etap powinien koncentrować się na weryfikacji nadawcy i sposobie zgłaszania podejrzanych dokumentów, a nie na ogólnym szkoleniu całej organizacji.”
To jest różnica między raportowaniem statystyki a sprzedażą wiedzy eksperckiej.
Są też sytuacje, w których odpowiedzialny wykonawca powinien powiedzieć klientowi: jeszcze nie róbmy kampanii.
Najpierw trzeba uporządkować podstawy, jeżeli:
-
pracownicy nie mają żadnego ustalonego sposobu zgłaszania podejrzanych wiadomości;
-
nikt po stronie klienta nie wie, kto ma reagować na zgłoszenia;
-
klient chce przechowywać prawdziwe hasła;
-
celem projektu jest „złapanie konkretnej osoby”;
-
oczekiwany jest publiczny ranking najgorszych pracowników;
-
nie uzgodniono zakresu danych;
-
nie ma osoby uprawnionej do zatrzymania kampanii;
-
infrastruktura nie została przetestowana przed wysyłką.
Profesjonalizm nie polega na wykonaniu każdego zamówienia. Czasem polega na przesunięciu testu o tydzień i usunięciu błędu, który mógłby zamienić ćwiczenie w prawdziwy incydent.
Początkujący dostawcy najczęściej psują projekty w bardziej prozaiczny sposób.
Pierwszy błąd: jeden scenariusz dla wszystkich.
Księgowość, HR i sprzedaż mają inne procesy, więc reagują na inne przynęty.
Drugi: mierzenie tylko kliknięć.
Kliknięcie bez informacji o zgłoszeniu i dalszym zachowaniu pokazuje tylko część obrazu.
Trzeci: przesadnie trudny pierwszy test.
Jeżeli podstawowe nawyki są słabe, perfekcyjnie przygotowany spear phishing daje mało użyteczną informację.
Czwarty: publiczne zawstydzanie.
To może poprawić statystyki kolejnego testu, ale pogorszyć kulturę zgłaszania rzeczywistych pomyłek.
Piąty: brak retestu.
Bez drugiego pomiaru szkolenie kończy się na deklaracji, że „pracownicy zostali przeszkoleni”.
Szósty: porównywanie nieporównywalnych kampanii.
Spadek kliknięć z 20% do 8% nie jest sukcesem, jeżeli drugi scenariusz był znacznie łatwiejszy do rozpoznania.
Siódmy: zbieranie zbyt dużej ilości danych.
Każda dodatkowa informacja przechowywana o użytkowniku tworzy obowiązek jej zabezpieczenia i uzasadnienia.
Ósmy: budowanie biznesu wyłącznie na narzędziu.
Platformę można zmienić. Wartością usługodawcy pozostają metodologia, projekt scenariusza, interpretacja wyników i rekomendacje.
Jeżeli miałbym wskazać tylko jedną rzecz, od której należy zacząć przed sprzedażą pierwszej usługi, nie byłaby to strona internetowa ani cennik.
Najpierw przygotuj własną bezpieczną procedurę kampanii i wzorcowy raport.
Procedura ma określać, czego nie zbierasz, kto zatwierdza test, kiedy kampania zostaje zatrzymana, jak reagujesz na przypadkowo podane prawdziwe dane i jak interpretujesz wynik. Raport powinien z kolei pokazywać nie tylko procent kliknięć, lecz również decyzję: co klient ma poprawić jako pierwsze i dlaczego właśnie to.
Dopiero wtedy masz produkt, który można powtarzać i wyceniać. Bez tego sprzedajesz wysyłkę fałszywych e-maili.
FAQ
Czy do prowadzenia szkoleń i symulacji phishingowych trzeba mieć specjalny certyfikat?
Nie istnieje jeden uniwersalny państwowy certyfikat, który sam w sobie uprawnia do prowadzenia każdej takiej usługi. Przy prostym szkoleniu potrzebne są inne kompetencje niż przy technicznej kampanii obejmującej środowisko pocztowe, dane użytkowników i reakcję SOC. Im bardziej zaawansowany zakres, tym ważniejsze stają się udokumentowana metodologia, bezpieczeństwo realizacji i doświadczenie techniczne.
Jak często wykonywać symulacje phishingowe?
Nie ma jednej częstotliwości właściwej dla każdej firmy. Test co 2–3 miesiące może być rozsądnym rytmem programu cyklicznego, ale przy dużej rotacji lub wysokim ryzyku kampanie mogą być potrzebne częściej. W małej stabilnej organizacji rzadszy test połączony z sensownym retestem może dać więcej niż comiesięczne powtarzanie podobnych wiadomości.
Czy jedno szkolenie rocznie wystarczy?
Może wystarczyć do realizacji podstawowego programu edukacyjnego, ale samo w sobie nie daje odpowiedzi, czy zachowanie pracowników się zmieniło. Jeżeli celem jest pomiar skuteczności, potrzebny jest baseline i późniejszy retest. Wynik trzeba interpretować razem z trudnością obu scenariuszy.
Czy pracownicy powinni wcześniej wiedzieć o symulacji?
Zależy od celu. Podanie dokładnej daty i scenariusza zniszczy wartość diagnostyczną testu. Nie oznacza to jednak, że organizacja musi działać bez żadnych zasad. Zakres programu, sposób przetwarzania danych i odpowiedzialność za realizację powinny być ustalone zgodnie z politykami firmy i przyjętym modelem organizacyjnym.
Czy niski click rate oznacza, że firma jest bezpieczna?
Nie. Firma może mieć niski poziom kliknięć i jednocześnie bardzo niski poziom zgłoszeń. Może też osiągnąć dobry wynik dlatego, że scenariusz był zbyt prosty. Click rate trzeba analizować razem z report rate, time-to-report, wykonanymi działaniami i trudnością wiadomości.
Od czego zacząć, jeśli chcę sprzedawać taką usługę?
Najpierw przygotuj metodologię, procedurę ochrony danych, jeden realistyczny scenariusz, sposób bezpiecznego mierzenia zachowania i wzorcowy raport. Następnie przeprowadź kontrolowany pilotaż. Cennik i abonament buduj dopiero wtedy, gdy wiesz, ile godzin naprawdę pochłania pełna realizacja. Pierwszy błąd do usunięcia to próba zbierania prawdziwych haseł albo innych danych, których test wcale nie potrzebuje.
Dodatkowe informacje na: https://hd-biznes.com/blog.
