testy phishingowesecurity awarenessphishingraportowanie

Testy phishingowe i odporność pracowników

2026-05-06

Jak mierzyć odporność pracowników w testach phishingowych: kliknięcia, zgłoszenia, podane dane, czas reakcji i trend po kampaniach.

Testy phishingowe i odporność pracowników

TL;DR

Test phishingowy dla firmy nie powinien kończyć się na prostym wyniku pokazującym, ilu pracowników kliknęło link. Kliknięcie jest ważnym sygnałem, ale samo w sobie mówi niewiele. Nie pokazuje, kto zatrzymał się przed podaniem hasła, kto zgłosił wiadomość, kto zeskanował kod QR, kto wszedł w fałszywy proces MFA ani jak szybko organizacja potrafiła zareagować po pierwszym zgłoszeniu. Dobrze zaprojektowany test phishingowy mierzy nie tylko błąd użytkownika, ale cały proces reakcji.

Największa wartość pojawia się wtedy, gdy organizacja traktuje testy phishingowe dla firm jako część cyklicznego programu security awareness, a nie jednorazową akcję kontrolną. Pojedyncza kampania daje obraz bazowy. Dopiero kilka kampanii pokazuje trend: czy spada liczba podanych danych, czy rośnie liczba zgłoszeń, czy skraca się czas reakcji i czy osoby, które wcześniej klikały, zmieniają zachowanie.

Dobry raport z testu nie służy do zawstydzania pracowników. Ma pomóc organizacji zrozumieć, gdzie proces jest odporny, gdzie wymaga korekty i które grupy potrzebują lepiej dopasowanej edukacji. W takim modelu zgłoszenie podejrzanej wiadomości jest pozytywnym zachowaniem, które trzeba wzmacniać, bo to ono uruchamia reakcję firmy, zanim incydent stanie się problemem technicznym, finansowym albo prawnym.

Dlaczego szkolenie raz w roku nie wystarcza

W wielu firmach cyberbezpieczeństwo użytkowników nadal sprowadza się do jednego szkolenia rocznie. Pracownik obejrzy prezentację, odpowie na kilka pytań, podpisze listę obecności i formalnie temat jest zamknięty. Problem polega na tym, że phishing nie działa w warunkach sali szkoleniowej. Działa wtedy, gdy ktoś się spieszy, ma otwarte kilka spraw naraz, czeka na fakturę, odpowiada klientowi, odbiera telefon albo próbuje szybko załatwić zadanie przed spotkaniem.

Wiedza deklaratywna jest potrzebna, ale sama nie wystarcza. Można wiedzieć, że nie wolno klikać w podejrzane linki, a mimo to kliknąć, gdy wiadomość wygląda znajomo, pasuje do kontekstu pracy i pojawia się w dobrym momencie. Właśnie dlatego testy phishingowe są tak cenne. Nie sprawdzają, czy pracownik pamięta definicję phishingu. Sprawdzają, co robi w codziennym środowisku pracy, gdy wiadomość wygląda na prawdziwą.

Dobry program awareness powinien łączyć szkolenie, symulacje i krótkie mikrolekcje po zdarzeniu. Szkolenie daje podstawy. Test pokazuje zachowanie. Mikrolekcja pomaga poprawić konkretny błąd w momencie, w którym użytkownik najlepiej rozumie, co się właśnie wydarzyło.

Phishing zmienił się szybciej niż wiele programów szkoleniowych

Przez lata phishing kojarzył się z prostym mailem pełnym błędów językowych, dziwną domeną i linkiem do fałszywego logowania. Takie kampanie nadal istnieją, ale nie opisują już całego problemu. Współczesny phishing coraz częściej korzysta z legalnych platform, poprawnego języka, znanych marek, wiadomości z systemów SaaS, kodów QR, SMS-ów, telefonów i fałszywych procesów logowania.

Microsoft w swoich analizach krajobrazu zagrożeń e-mailowych zwraca uwagę między innymi na QR phishing, kampanie ukryte za CAPTCHA, BEC oraz rosnącą złożoność łańcuchów ataku. Cisco Talos pokazał z kolei, że w pierwszym kwartale 2026 roku phishing pozostawał jednym z najważniejszych wektorów initial access, czyli pierwszego skutecznego wejścia do środowiska ofiary. To ważny sygnał dla firm: nie wystarczy sprawdzać, czy pracownik rozpozna bardzo oczywisty, podejrzany mail.

Jeśli test phishingowy ogranicza się do jednej wiadomości e-mail z linkiem, to mierzy tylko wycinek rzeczywistości. Nie pokazuje reakcji na SMS, kod QR, fałszywe powiadomienie SaaS, telefon od rzekomego wsparcia, prośbę o potwierdzenie MFA ani stronę logowania działającą w modelu AiTM. AiTM, czyli adversary-in-the-middle, to scenariusz, w którym fałszywa strona działa jak pośrednik między użytkownikiem a prawdziwą usługą i może próbować przechwycić nie tylko hasło, ale też kod lub sesję.

Test phishingowy jako punkt startowy programu security awareness

Test phishingowy jest dobrym punktem startowym programu security awareness, bo pokazuje realne zachowania, a nie tylko deklaracje po szkoleniu. Organizacja może zobaczyć, które scenariusze są najbardziej przekonujące, gdzie użytkownicy zatrzymują się samodzielnie, gdzie proszą o pomoc i gdzie proces zgłoszenia działa zbyt wolno.

Pierwsza kampania nie powinna być traktowana jak egzamin końcowy. To raczej pomiar bazowy, który pokazuje, od czego organizacja zaczyna. Jeżeli wynik jest słaby, nie oznacza to automatycznie, że ludzie są problemem. Może oznaczać, że dotychczasowe szkolenia były zbyt ogólne, procedura zgłaszania była niejasna, komunikaty bezpieczeństwa nie docierały do właściwych grup albo scenariusze phishingowe w realnym świecie zmieniły się szybciej niż program edukacji.

Z perspektywy PHISHLY ważne jest przejście od jednorazowego szkolenia do cyklicznego programu. Test pokazuje zachowanie. Mikrolekcja po kliknięciu wyjaśnia błąd w konkretnym momencie. Kolejna kampania sprawdza, czy zachowanie się zmieniło. Raport pozwala zarządowi, IT, compliance i HR zobaczyć trend, a nie tylko jeden procent z jednego dnia.

Taki model dobrze uzupełnia szerszą warstwę obrony przed phishingiem. Filtr poczty, MFA, monitoring, procedury SOC i ochrona endpointów są potrzebne, ale użytkownik nadal pozostaje miejscem decyzji. Testy pomagają sprawdzić, czy ta decyzja jest podejmowana świadomie i czy po błędzie organizacja potrafi szybko zareagować.

Co powinien mierzyć dobry test phishingowy

Najczęściej firmy zaczynają od kliknięć. To naturalne, bo kliknięcie jest łatwe do policzenia i dobrze wygląda w raporcie. Problem polega na tym, że kliknięcie nie jest jeszcze pełną historią. Jeden użytkownik może kliknąć, ale natychmiast zamknąć stronę. Drugi kliknie, wpisze login, poda hasło, potwierdzi MFA i dopiero wtedy zorientuje się, że coś jest nie tak. Z perspektywy ryzyka to są zupełnie różne sytuacje.

Otwarcie wiadomości pokazuje, czy temat i nadawca przyciągnęły uwagę. Kliknięcie pokazuje, czy przynęta zadziałała. Wejście w formularz mówi, czy użytkownik był gotów kontynuować proces. Podanie danych logowania pokazuje już realne ryzyko przejęcia konta. Skan kodu QR mówi, czy atak przeniósł się na telefon. Interakcja z MFA pokazuje, czy użytkownik rozumie, kiedy drugi składnik logowania może zostać nadużyty. Pobranie załącznika pokazuje ryzyko związane z plikami.

Zgłoszenie wiadomości pokazuje natomiast coś bardzo ważnego: czy użytkownik potrafi przerwać atak i uruchomić reakcję organizacji. W praktyce najbardziej wartościowy raport nie pokazuje jednego procentu. Pokazuje ścieżkę. Ilu pracowników otworzyło wiadomość, ilu kliknęło, ilu zatrzymało się przed formularzem, ilu podało dane, ilu zgłosiło incydent i po jakim czasie pojawiło się pierwsze zgłoszenie. Taka mapa zachowań mówi znacznie więcej niż sama klikalność.

Jakie metryki są naprawdę ważne

Metryki w kampanii phishingowej powinny odpowiadać na pytanie o ryzyko i zachowanie, a nie tylko produkować wykresy. Jeżeli raport pokazuje wyłącznie odsetek kliknięć, organizacja może wyciągnąć błędny wniosek. Ten sam click rate może oznaczać niewielkie ryzyko, jeśli większość osób szybko zgłasza wiadomość, albo duże ryzyko, jeśli po kliknięciu użytkownicy podają dane i nikt nie uruchamia reakcji.

Dobre metryki powinny pokazywać ścieżkę użytkownika i proces organizacji. Kto zauważył wiadomość. Kto kliknął. Kto podał dane. Kto pobrał plik. Kto zeskanował kod QR. Kto zgłosił wiadomość. Jak szybko pojawiło się pierwsze zgłoszenie. Czy zgłoszenie trafiło do właściwego miejsca. Czy zespół IT albo SOC wiedział, co zrobić. Czy w kolejnych kampaniach widać poprawę.

Click rate, czyli odsetek kliknięć

Click rate pokazuje, jaki odsetek odbiorców kliknął link lub wszedł w interakcję z przynętą. To użyteczna metryka startowa, ale nie wolno jej traktować jako pełnej miary odporności. Kliknięcie może być błędem, ciekawością, wejściem na stronę bez dalszej interakcji albo początkiem poważnego incydentu.

Click rate warto analizować w kontekście trudności scenariusza. Inny wynik będzie miała oczywista wiadomość z błędami, a inny dobrze dopasowany komunikat z systemu HR, finansów, Microsoft 365 albo dostawcy SaaS. NIST Phish Scale dobrze pokazuje, że trudność wiadomości i dopasowanie przynęty do pracy odbiorcy mają znaczenie dla interpretacji wyniku.

Credential submission rate, czyli odsetek podanych danych

Credential submission rate pokazuje, ilu użytkowników po kliknięciu podało dane logowania, numer telefonu, kod, hasło, dane karty albo inne informacje. To znacznie bliższa miara realnego ryzyka niż samo kliknięcie, bo wskazuje, czy użytkownik był gotów przejść dalej w procesie ataku.

W przypadku scenariuszy Microsoft 365, Google Workspace, OAuth albo AiTM ta metryka jest szczególnie ważna. Użytkownik może kliknąć link i dopiero na stronie logowania podjąć krytyczną decyzję. Jeżeli organizacja testuje scenariusze podobne do phishingu OAuth lub przejęcia sesji, warto powiązać wyniki z edukacją o MFA, tokenach, zgodach aplikacji i fałszywych procesach logowania. Dobrym uzupełnieniem jest analiza scenariuszy takich jak phishing OAuth w Microsoft Entra ID albo przejęcie sesji mimo MFA.

Reporting rate, czyli odsetek zgłoszeń

Reporting rate pokazuje, ilu użytkowników zgłosiło podejrzaną wiadomość. To jedna z najważniejszych pozytywnych metryk w programie awareness. Zgłoszenie oznacza, że pracownik nie tylko rozpoznał ryzyko, ale też uruchomił proces organizacji.

Wynik zgłoszeń trzeba wzmacniać, a nie traktować jako neutralny dodatek. Jeżeli ludzie zgłaszają podejrzane wiadomości, firma zyskuje wczesny sygnał. IT lub SOC może szybciej zablokować domenę, usunąć wiadomości z innych skrzynek, sprawdzić logi i ostrzec użytkowników. W wielu realnych incydentach pierwsze dobre zgłoszenie ma większą wartość niż idealny wynik testu bez zgłoszeń.

Time to report, czyli czas do zgłoszenia

Time to report pokazuje, ile czasu minęło od dostarczenia wiadomości do pierwszego zgłoszenia. Ta metryka jest szczególnie ważna, bo phishing jest wyścigiem z czasem. Jeżeli pierwsze zgłoszenie pojawia się po kilku minutach, organizacja może zareagować zanim wielu użytkowników poda dane. Jeżeli pojawia się po kilku godzinach, kampania mogła już zebrać hasła, kody albo sesje.

Warto mierzyć zarówno czas do pierwszego zgłoszenia, jak i czas do reakcji organizacji. Samo zgłoszenie nie wystarczy, jeśli trafia do skrzynki, której nikt nie monitoruje. Czas reakcji powinien obejmować triage, blokadę linku, sprawdzenie innych skrzynek, decyzję o komunikacie do użytkowników i ewentualne działania techniczne po kliknięciu.

Repeat clickers, czyli osoby powtarzające ryzykowne zachowania

Repeat clickers to osoby, które w kolejnych kampaniach powtarzają ryzykowne zachowania. Ta metryka wymaga ostrożności, bo łatwo zmienić ją w narzędzie stygmatyzowania pracowników. Nie o to chodzi. Powtarzalność powinna pokazać, gdzie potrzebna jest dodatkowa edukacja, prostsza procedura, wsparcie menedżera albo lepiej dopasowany scenariusz szkoleniowy.

Czasem powtarzające się kliknięcia wynikają nie z lekceważenia zasad, ale z charakteru pracy. Osoba w finansach stale obsługuje faktury. HR otwiera CV i dokumenty kandydatów. Administracja pracuje z formularzami i płatnościami. IT odbiera alerty techniczne. Pracownicy terenowi częściej korzystają z telefonu i kodów QR. Interpretacja wyników musi uwzględniać rolę, a nie tylko procent.

Wyniki według działów i ról

Raport powinien pokazywać wyniki według działów, ról i typów procesu. Zarząd może być narażony na wiadomości typu VIP phishing, fałszywe decyzje finansowe i podszycie pod partnerów. Finanse mierzą się z fakturami, numerami rachunków i BEC. HR pracuje z CV, dokumentami i benefitami. IT widzi alerty, reset hasła, MFA i komunikaty SaaS. Administracja obsługuje sprawy urzędowe, dostawców i płatności. Pracownicy terenowi częściej skanują QR, korzystają z telefonu i działają poza biurem.

Takie rozbicie pozwala budować mądrzejszy program. Nie każdy musi dostawać ten sam scenariusz. Test dopasowany do roli jest bardziej realistyczny, a raport staje się bardziej przydatny dla menedżerów, compliance i audytu. Właśnie wtedy testy phishingowe przestają być masową kampanią edukacyjną, a zaczynają być narzędziem zarządzania ryzykiem ludzkim.

Jak interpretować wyniki bez obwiniania pracowników

Najgorszy sposób wykorzystania testów phishingowych to publiczne zawstydzanie ludzi. Taki model może chwilowo obniżyć liczbę kliknięć, ale zwykle niszczy coś ważniejszego: zaufanie i gotowość do zgłaszania incydentów. Jeśli pracownik boi się konsekwencji, po prawdziwym kliknięciu może milczeć. Z punktu widzenia bezpieczeństwa to znacznie gorsze niż sam błąd.

Wyniki trzeba interpretować jak dane o procesie, nie jak ranking winnych. Jeżeli wiele osób kliknęło w wiadomość o fakturze, pytanie powinno brzmieć: czy proces obsługi faktur daje przestrzeń na weryfikację. Jeżeli wiele osób podało dane na fałszywej stronie Microsoft 365, trzeba zapytać, czy rozumieją różnicę między prawdziwym logowaniem a fałszywym formularzem. Jeżeli mało osób zgłasza wiadomości, problem może leżeć w kanale zgłoszeń, nie w złej woli użytkowników.

Dobra komunikacja po kampanii powinna pokazywać, czego organizacja się nauczyła i co zostanie poprawione. Warto podkreślać pozytywne zachowania: szybkie zgłoszenie, zatrzymanie się przed formularzem, przekazanie wiadomości do IT, niepodanie kodu, potwierdzenie sprawy innym kanałem. To buduje kulturę, w której użytkownik jest sensorem bezpieczeństwa, a nie najsłabszym ogniwem do wskazania palcem.

Jak raportować wyniki zarządowi

Zarząd nie potrzebuje długiej tabeli wszystkich kliknięć. Potrzebuje odpowiedzi na kilka pytań: jakie ryzyko mierzyliśmy, jaki był wynik bazowy, czy ryzyko spada, które procesy są najbardziej narażone, czy ludzie zgłaszają incydenty i czy organizacja reaguje szybciej niż wcześniej.

Raport dla zarządu powinien pokazywać trend, a nie tylko wynik jednej kampanii. Pojedynczy test mówi, gdzie firma była w konkretnym dniu i przy konkretnym scenariuszu. Seria testów mówi, czy program awareness działa. Jeżeli click rate spada, reporting rate rośnie, a time to report się skraca, to jest sygnał poprawy odporności. Jeżeli kliknięcia spadają, ale zgłoszenia nadal są niskie, organizacja może mieć problem z kulturą zgłaszania albo kanałem eskalacji.

Warto pokazywać wyniki językiem ryzyka. Dla zarządu istotne jest, czy scenariusz mógł prowadzić do przejęcia konta, fraudu płatniczego, wycieku danych, incydentu operacyjnego, naruszenia ciągłości działania albo problemu regulacyjnego. Dane z kampanii powinny więc łączyć zachowania użytkowników z możliwym skutkiem biznesowym.

Po publikacji osobnego materiału warto linkować z tego miejsca do przyszłego wpisu o raporcie z kampanii phishingowej dla zarządu, bo to naturalny temat wspierający ten klaster.

Jak wykorzystać raport jako dowód compliance

Raport z kampanii phishingowej nie zastępuje programu zgodności, analizy ryzyka, polityk ani procedur. Może jednak być bardzo użytecznym dowodem, że organizacja prowadzi działania awareness, mierzy ich skuteczność i doskonali proces w czasie. To ważne w kontekście NIS2/KSC, DORA, ISO 27001 i RODO.

W NIS2 i krajowych wdrożeniach, takich jak KSC, istotne są środki zarządzania ryzykiem, cyberhigiena, szkolenia i zdolność reagowania. W DORA nacisk pada na cyfrową odporność operacyjną podmiotów finansowych, w tym przygotowanie organizacji do incydentów ICT. W ISO 27001 ważne są świadomość, kompetencje, udokumentowane działania, doskonalenie i dowody funkcjonowania systemu zarządzania bezpieczeństwem informacji. RODO z kolei wymaga odpowiedniego podejścia do ochrony danych i rozliczalności.

Dobrze przygotowany raport może pokazać: zakres kampanii, grupy objęte testem, scenariusze, metryki, wyniki, trend, działania korygujące, komunikację po kampanii i plan kolejnych działań. Dla audytora lub compliance ważne jest nie tylko to, że test się odbył. Ważne jest, czy organizacja wyciągnęła wnioski i poprawiła proces.

To dlatego raport powinien pokazywać także poprawę. Jeżeli po pierwszej kampanii wiele osób kliknęło, a po trzeciej kampanii rośnie liczba zgłoszeń i spada liczba podanych danych, jest to dowód działania programu. Nie chodzi o idealny wynik. Chodzi o zarządzanie ryzykiem i ciągłe doskonalenie.

Jak często powtarzać testy phishingowe

Częstotliwość testów zależy od wielkości organizacji, profilu ryzyka, sektora, rotacji pracowników i dojrzałości programu awareness. Inaczej powinien działać bank, inaczej zakład produkcyjny, inaczej urząd, a inaczej mała firma usługowa. Ważniejsze od jednej uniwersalnej liczby jest to, aby testy były cykliczne i tematycznie zaplanowane.

Pojedynczy test daje obraz bazowy. Jest potrzebny, ale nie wystarcza. Jeżeli firma zrobi jedną kampanię raz na rok, może nie zobaczyć, czy zmiana wyniku wynika z edukacji, szczęścia, łatwiejszego scenariusza, sezonowości albo chwilowego nastroju w organizacji. Regularne kampanie pozwalają porównywać podobne typy ryzyka, sprawdzać różne role i oceniać trend.

Dobry rytm to taki, który nie zamienia programu w ciągłą pułapkę, ale utrzymuje nawyk uważności. Część organizacji będzie potrzebowała kampanii kwartalnych, część krótszych, częstszych ćwiczeń dla wybranych ról, a część kampanii połączonych z konkretnymi ryzykami: faktury, Microsoft 365, QR, SMS, płatności, HR, logistyka, zarząd, dostawcy albo nowe procedury wewnętrzne.

Ważne, aby po każdej kampanii pojawiła się informacja zwrotna. Bez omówienia wyników test staje się kontrolą. Z omówieniem, mikrolekcją i kolejnym pomiarem staje się częścią programu zmiany zachowań.

Jak PHISHLY wspiera cykliczne kampanie

PHISHLY pozwala traktować kampanie phishingowe jako powtarzalny proces mierzenia i wzmacniania odporności, a nie jednorazową akcję szkoleniową. Scenariusze mogą obejmować e-mail, SMS, kody QR, fałszywe logowania do Microsoft 365 lub Google Workspace, płatności, faktury, komunikaty od dostawców, załączniki, linki i scenariusze techniczne. Dzięki temu test można dopasować do realnych sytuacji, z którymi pracownicy spotykają się w pracy.

Platforma powinna pomagać w mierzeniu zachowań na kilku etapach: otwarcie, kliknięcie, podanie danych, pobranie pliku, skan kodu QR, zgłoszenie wiadomości, czas reakcji i powtarzalność zachowań. Taki raport jest przydatny nie tylko dla Security. Może wspierać zarząd, IT, compliance, HR i audyt, bo pokazuje zarówno ryzyko, jak i postęp.

Mikrolekcja po kliknięciu jest ważnym elementem tego modelu. Pracownik uczy się w momencie błędu, gdy kontekst jest świeży. Zamiast ogólnego szkolenia po kilku miesiącach dostaje krótkie wyjaśnienie: co było podejrzane, gdzie należało przerwać proces i jak zachować się następnym razem. To pomaga przejść od wiedzy do nawyku.

Jeżeli chcesz zacząć od prostego punktu wejścia dla pracowników, możesz połączyć kampanie z quizem czy rozpoznasz phishing. A jeśli odpowiadasz za program awareness, warto zaplanować test jako część szerszej ścieżki: testy phishingowe dla firm, program security awareness, raportowanie i powtarzalne kampanie.

Jak zacząć bez tworzenia atmosfery kontroli

Pierwszy test warto dobrze zakomunikować wewnętrznie, ale bez zdradzania konkretnego scenariusza. Pracownicy powinni wiedzieć, że organizacja buduje odporność, że celem nie jest karanie i że zgłaszanie podejrzanych wiadomości jest zachowaniem oczekiwanym oraz pozytywnym. To szczególnie ważne w firmach, które wcześniej nie prowadziły symulacji phishingu albo kojarzyły je z polowaniem na błędy.

Przed kampanią trzeba ustalić kanał zgłoszeń. Może to być przycisk w kliencie poczty, skrzynka bezpieczeństwa, helpdesk, SOC albo inny prosty mechanizm. Użytkownik nie powinien zgadywać, komu przekazać podejrzaną wiadomość. Jeżeli kanał jest niejasny, niski reporting rate może mówić więcej o procesie niż o świadomości pracowników.

Po kampanii warto pokazać wyniki zbiorczo, bez listy osób. Komunikat powinien zawierać najważniejsze wnioski, pozytywne zachowania i działania, które organizacja podejmie dalej. Jeżeli ktoś potrzebuje dodatkowego wsparcia, najlepiej prowadzić je dyskretnie i konstruktywnie. Test ma wzmacniać odporność, nie budować strach przed zgłaszaniem błędów.

Jeżeli chcesz sprawdzić, jak taki program może wyglądać w Twojej organizacji, przejdź do strony testy phishingowe dla firm albo umów rozmowę z PHISHLY.

Wniosek

Test phishingowy ma sens tylko wtedy, gdy mierzy zachowanie, uczy w odpowiednim momencie i prowadzi do kolejnych działań. Sam click rate może być wygodny, ale nie pokazuje pełnego ryzyka. Dopiero połączenie kliknięć, podanych danych, zgłoszeń, czasu reakcji, powtarzalnych zachowań i wyników według ról daje obraz odporności organizacji.

Najlepszy wynik kampanii to nie taki, w którym można wskazać, kto się pomylił. Najlepszy wynik to taki, który pokazuje, gdzie organizacja szybciej wykrywa zagrożenie, gdzie ludzie zgłaszają podejrzane wiadomości i gdzie kolejne kampanie potwierdzają poprawę. Odporność na phishing nie powstaje po jednym szkoleniu. Powstaje wtedy, gdy firma regularnie ćwiczy decyzje, mierzy reakcję i poprawia proces, zanim prawdziwy atak wykorzysta ten sam błąd.

Najczęstsze pytania

Czy test phishingowy w firmie powinien mierzyć tylko kliknięcia?

Nie. Kliknięcie jest tylko jedną z metryk. Dobry test mierzy także podanie danych, pobranie pliku, skan kodu QR, zgłoszenie wiadomości, czas reakcji i powtarzalność ryzykownych zachowań.

Jak często firma powinna powtarzać testy phishingowe?

Największą wartość daje cykliczny program, a nie jednorazowa kampania. Pojedynczy test pokazuje obraz bazowy, a dopiero kilka kampanii pozwala ocenić trend i skuteczność działań awareness.

Czy wyniki testów phishingowych można wykorzystać w compliance?

Tak, raporty z kampanii mogą wspierać dowodzenie działań awareness i doskonalenia procesów w kontekście NIS2/KSC, DORA, ISO 27001 i RODO, ale nie zastępują pełnej analizy zgodności.

Źródła

  1. Microsoft Security Blog - Email threat landscape: Q1 2026 trends and insightsKontekst dotyczący skali zagrożeń e-mailowych, QR phishingu, CAPTCHA-gated phishing, BEC i zmian w technikach phishingowych.
  2. Cisco Talos - IR Trends Q1 2026Kontekst dotyczący phishingu jako istotnego wektora initial access obserwowanego w incydentach reagowania.
  3. NIST - Phish Scale User GuideMetodyka oceny trudności wiadomości phishingowych i kontekstu odbiorcy w programach symulacji phishingu.
  4. NIST - Phishing Resistance: Protecting the Keys to Your KingdomKontekst dotyczący ograniczeń klasycznego uwierzytelniania oraz potrzeby ochrony przed phishingiem ukierunkowanym na poświadczenia.
  5. ENISA - NIS2 Technical Implementation GuidanceWytyczne techniczne wspierające wdrażanie środków zarządzania ryzykiem cyberbezpieczeństwa w kontekście NIS2.
  6. EUR-Lex - Directive (EU) 2022/2555, NIS2Źródło prawne dla dyrektywy NIS2, w tym kontekstu zarządzania ryzykiem, cyberhigieny i szkoleń.
  7. EUR-Lex - Regulation (EU) 2022/2554, DORAŹródło prawne DORA dotyczące cyfrowej odporności operacyjnej podmiotów finansowych.
  8. ISO - ISO/IEC 27001:2022Oficjalna strona normy ISO/IEC 27001:2022 dotyczącej systemu zarządzania bezpieczeństwem informacji.