Jak zbudować program security awareness, który działa? Działający program łączy cztery elementy: treści dopasowane do aktualnych ataków (vishing, deepfake, scenariusze wielokanałowe – nie tylko e-mail), symulacje phishingowe prowadzone bez karania i „polowania na pracowników”, metryki mierzące raportowanie i czas reakcji zamiast samego odsetka kliknięć oraz rytm ciągły zamiast jednorazowego szkolenia rocznego.
Regulacje – NIS2 (art. 20-21), DORA (art. 13 ust. 6), ISO 27001 (A.6.3) i PCI DSS (12.6) – wymagają programu, ale nie mówią, jak sprawić, żeby zmieniał zachowania; ten artykuł wypełnia tę lukę. Kontekst zagrożeń – co dziś potrafi atakujący z AI i dlaczego stare szkolenia przestały działać – opisaliśmy w pierwszym aktywie klastra: Phishing w erze AI.
Definicja kanoniczna: Program security awareness to ciągły, mierzony proces budowania zachowań bezpieczeństwa u pracowników i kierownictwa, obejmujący szkolenia dopasowane do ról, kontrolowane symulacje ataków socjotechnicznych oraz metryki raportowania, wymagany w różnej formie przez NIS2, DORA, ISO 27001 i PCI DSS.
Program security awareness – w skrócie:
- Regulacje wymagają programu, nie szkolenia: NIS2 nakłada obowiązkowe szkolenia na zarząd (art. 20 ust. 2) pod rygorem osobistej odpowiedzialności, DORA czyni świadomość ICT obowiązkowym modułem szkoleń wszystkich pracowników i kadry (art. 13 ust. 6), PCI DSS wymaga treści o phishingu i socjotechnice (12.6.3.1) oraz przeglądu programu co 12 miesięcy (12.6.2).
- Jednorazowe szkolenie roczne nie zmienia zachowań – buduje dowód formalny, nie odporność; działa rytm: krótkie moduły, symulacje co 4-6 tygodni, komunikacja po realnych kampaniach.
- Najważniejszą metryką jest odsetek zgłoszeń i czas do pierwszego zgłoszenia, nie click-rate: kliknięcia zawsze będą, a o skali szkód decyduje, jak szybko SOC się dowie.
- Symulacja zaprojektowana jako pułapka na pracowników (karanie, zawstydzanie, „listy klikających” dla przełożonych) niszczy program: zabija zgłaszanie prawdziwych incydentów i zaufanie do bezpieczeństwa.
- Scenariusze muszą nadążać za atakującymi: symulacje głosowe i QR obok mailowych, poziomy trudności, pretexty budowane tak, jak buduje je dziś przeciwnik – z użyciem AI.
- Patronusec prowadzi szkolenia security awareness i testy phishingowe w modelu rozliczenia za rezultaty: uzgodniony program roczny ze stałą ceną, raporty z metrykami raportowania dla zarządu i treści aktualizowane wraz z technikami ataków.
Spis treści
Czego dokładnie wymagają NIS2, DORA, ISO 27001 i PCI DSS w obszarze szkoleń i świadomości?
Cztery reżimy wymagają czterech różnych rzeczy: NIS2 – szkoleń zarządu i oferowania ich pracownikom oraz cyberhigieny jako środka zarządzania ryzykiem; DORA – obowiązkowych modułów świadomości ICT dla wszystkich pracowników i kadry kierowniczej; ISO 27001 – uświadamiania, edukacji i szkoleń adekwatnych do ról wraz z oceną skuteczności; PCI DSS – formalnego programu z konkretną treścią (phishing, socjotechnika, akceptowalne użycie) i przeglądem co 12 miesięcy.
| Reżim | Przepis / kontrola | Wymóg | Kogo dotyczy | Dowód dla audytora |
|---|---|---|---|---|
| NIS2 | art. 20 ust. 2 | członkowie organów zarządzających mają obowiązek odbywać szkolenia z cyberbezpieczeństwa; podmiot ma oferować analogiczne szkolenia pracownikom | zarząd (obowiązek), pracownicy (oferta) | zaświadczenia/listy obecności zarządu, program szkoleń, cykliczność |
| NIS2 | art. 21 ust. 2 lit. g | podstawowe praktyki cyberhigieny i szkolenia w zakresie cyberbezpieczeństwa jako środek zarządzania ryzykiem | wszyscy | polityka, materiały, pokrycie populacji |
| DORA | art. 13 ust. 6 | programy budowania świadomości bezpieczeństwa ICT i szkolenia z operacyjnej odporności cyfrowej jako obowiązkowe moduły w systemach szkolenia pracowników; dotyczy też kadry kierowniczej; zakres proporcjonalny do funkcji | wszyscy pracownicy + kadra zarządzająca | program szkoleń z modułami ICT, zapisy ukończenia, proporcjonalność do ról |
| DORA | art. 5 ust. 4 | członkowie organu zarządzającego aktualizują wiedzę o ryzyku ICT, m.in. przez regularne szkolenia | zarząd | zapisy szkoleń zarządu |
| ISO/IEC 27001:2022 | A.6.3 | uświadamianie, edukacja i szkolenia adekwatne do funkcji, z aktualizacjami polityk; klauzula 7.2-7.3 – kompetencje i świadomość, z dowodami | wszyscy, per rola | plan szkoleń, materiały, ocena skuteczności, zapisy kompetencji |
| PCI DSS v4.0.1 | 12.6.1-12.6.2 | formalny program świadomości bezpieczeństwa, przeglądany co najmniej raz na 12 miesięcy i aktualizowany o nowe zagrożenia | personel w zakresie | dokument programu, daty przeglądów |
| PCI DSS v4.0.1 | 12.6.3, 12.6.3.1, 12.6.3.2 | szkolenie przy zatrudnieniu i co najmniej raz w roku; treść musi obejmować phishing i socjotechnikę (od 31 mar 2025) oraz akceptowalne użycie technologii | personel w zakresie | zapisy ukończenia, potwierdzenia zapoznania z polityką, treść modułów |
| PCI DSS v4.0.1 | 5.4.1 | mechanizmy wykrywania i ochrony personelu przed atakami phishingowymi (kontrola techniczna wspierająca program) | organizacja | konfiguracja ochrony poczty, DMARC |
Wspólnym mianownikiem czterech reżimów jest program ciągły z dowodami – a nie pojedyncze szkolenie: NIS2 i DORA obejmują obowiązkiem także zarząd, PCI DSS narzuca treść i rytm roczny, a ISO 27001 dodaje wymóg oceny skuteczności, czyli metryk.
Dwie konsekwencje praktyczne. Po pierwsze, zarząd jest uczestnikiem, nie sponsorem-obserwatorem: art. 20 NIS2 wiąże szkolenia członków organów z ich osobistą odpowiedzialnością za nadzór nad środkami, a art. 5 DORA – z odpowiedzialnością za ramy zarządzania ryzykiem ICT. Po drugie, wymóg „oceny skuteczności” z ISO 27001 (klauzula 9.1 w związku z 7.2) oznacza, że lista obecności nie wystarczy – potrzebne są metryki zachowań, o których niżej. Terminy i dowody z tej tabeli powinny trafić do kalendarza obowiązków – jeśli prowadzicie go w modelu opisanym przy usłudze IT Compliance Officera, program awareness jest jego naturalną pozycją.
Dlaczego klasyczne szkolenie roczne nie zmienia zachowań?
Szkolenie roczne nie działa z trzech powodów: wiedza deklaratywna nie przekłada się na zachowanie pod presją (pracownik „wie”, że ma weryfikować, ale o 16:50 w piątek klika), pojedynczy bodziec wygasa w tygodnie, a treść starzeje się szybciej niż cykl szkoleniowy – moduł nagrany rok temu nie zawiera vishingu z klonowaniem głosu ani kodów QR. Zachowania zmienia rytm krótkich bodźców połączonych z bezpieczną praktyką – czyli symulacjami.
Co mówi praktyka programów, które działają:
- Krótko i często wygrywa z długo i rzadko – moduły 5-10 minut co kilka tygodni utrzymują temat w polu uwagi; roczne 2 godziny e-learningu buduje wyłącznie zapis w systemie.
- Praktyka bez konsekwencji – symulacja jest siłownią: miejscem, gdzie można „kliknąć” bez szkody i zobaczyć, jak wyglądał atak; bez symulacji pierwszy kontakt z realistycznym atakiem następuje w warunkach bojowych.
- Kontekst realnych kampanii – najskuteczniejszy materiał szkoleniowy to zanonimizowany, prawdziwy atak na Waszą organizację z zeszłego tygodnia, omówiony w 3-minutowej wiadomości „co przyszło i po czym można było poznać”.
- Role zamiast masówki – księgowość ćwiczy zmianę rachunku i BEC, help desk – pretexting na reset MFA, zarząd – vishing i deepfake, administratorzy – konsekwencje kliknięcia na koncie uprzywilejowanym. Ten sam wymóg proporcjonalności do funkcji stawia art. 13 ust. 6 DORA.
Celem programu awareness nie jest wiedza, lecz trzy nawyki odporne na jakość fałszerstwa: zatrzymanie się przy presji czasu i poufności, weryfikacja innym kanałem oraz natychmiastowe zgłoszenie – także własnego kliknięcia.
To przesunięcie celu ma konsekwencję dla treści: mniej „jak rozpoznać fałszywy mail” (coraz częściej się nie da – pokazaliśmy to w analizie phishingu AI), więcej „co robić z każdą prośbą o pieniądze, dane i dostęp, niezależnie od tego, jak wiarygodnie wygląda”.
Jak zaprojektować symulacje phishingowe, żeby uczyły, a nie polowały na pracowników?
Symulacja uczy, gdy spełnia pięć warunków: cel zapisany jako wzrost raportowania (nie „wykrycie słabych ogniw”), moment kliknięcia zamieniony w mikroszkolenie (strona edukacyjna zamiast ekranu wstydu), brak sankcji personalnych i brak imiennych list dla przełożonych, poziomy trudności rosnące wraz z dojrzałością oraz uzgodnienie zasad z HR i – tam gdzie działa – stroną pracowniczą przed startem. Symulacja zaprojektowana jako pułapka daje odwrotny skutek: uczy ukrywania incydentów.
Zasady projektowe w praktyce:
- Karta programu przed pierwszą kampanią – dokument uzgodniony z zarządem, HR i IOD: cel (raportowanie), zasada braku sankcji, kto widzi jakie dane (wyniki zespołowe – tak; imienne listy dla przełożonych – nie; dane imienne wyłącznie dla zespołu programu, do celów wsparcia, np. dodatkowego modułu po serii kliknięć), retencja wyników, kanał komunikacji o programie. Przetwarzanie wyników imiennych to przetwarzanie danych pracowników – RODO wymaga celu, minimalizacji i informacji; karta programu jest miejscem, gdzie to porządkujesz.
- Ogłoszenie programu, nie kampanii – pracownicy wiedzą, że symulacje trwają cały rok; nie wiedzą kiedy i jakie. Jawność programu buduje zaufanie i legalność, niejawność pojedynczej kampanii zachowuje wartość testu.
- Kliknięcie = 60 sekund nauki – strona po kliknięciu pokazuje, co było przynętą, jakie sygnały dało się zauważyć i jeden przycisk „zgłoś na przyszłość”; bez zawstydzania, z podziękowaniem za każdą minutę uwagi.
- Zgłoszenie = widoczne docenienie – potwierdzenie z podziękowaniem, okresowe wyróżnienie zespołów o najwyższym raportowaniu; to zgłaszający są bohaterami komunikacji programu.
- Poziomy trudności i kanały – start od scenariuszy oczywistych (kalibracja bazowa), stopniowe przejście do pretextów budowanych jak u przeciwnika: personalizacja z danych publicznych, ciągłość wątku, presja autorytetu; po ustabilizowaniu maili – warianty QR i głosowe (vishing testowy wymaga osobnych uzgodnień: scenariusze, zakres ról, zapis w karcie programu).
- Granice etyczne – bez pretextów żerujących na zdrowiu, zwolnieniach, śmierci bliskich i wynagrodzeniach „od HR” w okresach ocen; skuteczność takich przynęt jest wysoka, koszt zaufania – wyższy. Granice spisane w karcie programu.
Symulacja phishingowa mierzy skuteczność programu i procedur, a nie uczciwość pracowników – dlatego jej wyniki analizuje się na poziomie zespołów i scenariuszy, a jedyną dopuszczalną konsekwencją indywidualnego kliknięcia jest dodatkowa, wspierająca porcja szkolenia.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że o sukcesie programu w pierwszym roku decyduje jedna decyzja komunikacyjna: kto podpisuje się pod ogłoszeniem programu. Jeśli robi to dział IT – program jest „kolejnym testem od informatyków”; jeśli zarząd, z jasną deklaracją „sami też jesteśmy testowani i szkoleni” – staje się normą organizacyjną. Dlatego w programach, które prowadzimy w ramach szkoleń i testów phishingowych, pierwszym elementem jest sesja dla zarządu (przy okazji zamykająca obowiązek z art. 20 ust. 2 NIS2), a zarząd jest w puli adresatów symulacji od pierwszej kampanii.
Jakie metryki mierzyć – i dlaczego click-rate jest najmniej ważny?
Mierz pięć metryk w tej kolejności ważności: odsetek zgłoszeń (report rate), czas do pierwszego zgłoszenia, stosunek zgłoszeń do kliknięć, odsetek powtarzających się kliknięć obsłużonych wsparciem oraz – dopiero na końcu – click-rate jako tło. Click-rate jest najsłabszą metryką, bo zależy głównie od trudności scenariusza (łatwo nim „zarządzać”, wysyłając łatwe kampanie) i nie mówi nic o tym, co decyduje o szkodach: czy organizacja się dowiedziała.
| Metryka | Definicja | Dlaczego ważna | Cel kierunkowy |
|---|---|---|---|
| Report rate | % adresatów symulacji, którzy zgłosili ją przez oficjalny kanał | jedyna metryka skorelowana z tym, co ratuje przy prawdziwym ataku | rosnący trend; dojrzałe programy osiągają wartości wyższe niż click-rate |
| Czas do pierwszego zgłoszenia | minuty od startu kampanii do pierwszego zgłoszenia | wyznacza, jak szybko SOC może wycofać prawdziwą kampanię ze skrzynek | malejący; docelowo minuty, nie godziny |
| Stosunek zgłoszeń do kliknięć | zgłoszenia / kliknięcia w tej samej kampanii | pokazuje kulturę: czy ludzie zgłaszają także po kliknięciu | > 1, rosnący |
| Zgłoszenia po kliknięciu | % klikających, którzy sami zgłosili swój błąd | najczystszy wskaźnik zaufania do programu (nikt nie zgłasza się do karzącego) | rosnący |
| Powtarzające się kliknięcia | osoby klikające w ≥3 kolejnych kampaniach | sygnał do wsparcia (dodatkowy moduł, rozmowa o obciążeniu pracą), nie do sankcji | malejący, obsłużony wsparciem |
| Click-rate (tło) | % kliknięć w kampanii | kontekst trudności scenariusza; porównywalny tylko w ramach tego samego poziomu trudności | bez celu bezwzględnego |
| Pokrycie i terminowość szkoleń | % populacji z ukończonym modułem w terminie, w tym zarząd | twardy dowód dla NIS2 art. 20, DORA art. 13 ust. 6, PCI DSS 12.6.3 | 100 % dla wymogów regulacyjnych |
Odsetek zgłoszeń i czas do pierwszego zgłoszenia mierzą dokładnie to, co przesądza o skutkach prawdziwego ataku – jak szybko organizacja się dowiaduje – podczas gdy odsetek kliknięć mierzy głównie trudność scenariusza, którą autor kampanii kontroluje.
Raport kwartalny dla zarządu z tych metryk zamyka jednocześnie wymóg oceny skuteczności z ISO 27001 i buduje dowód nadzoru z NIS2 art. 20 – pod warunkiem, że jest prezentowany i protokołowany, a nie wysyłany mailem. Trend z czterech kwartałów mówi więcej niż każda pojedyncza kampania.
Chcesz zobaczyć, jak te metryki wyglądałyby u Ciebie, zanim kupisz cokolwiek?
Patronusec przeprowadza bezpłatną kampanię kalibracyjną: jedna kontrolowana symulacja mailowa na uzgodnionej próbie, z kartą programu, stroną edukacyjną i raportem bazowym (report rate, czas do zgłoszenia, stosunek zgłoszeń do kliknięć) w 10 dni roboczych – jako punkt wyjścia do decyzji o programie rocznym, u nas lub gdziekolwiek.
Jak wygląda roczny harmonogram programu, który spina szkolenia, symulacje i wymogi?
Roczny harmonogram układa się w rytm kwartalny: każdy kwartał zawiera jeden krótki moduł szkoleniowy dla wszystkich, 2-3 kampanie symulacyjne o rosnącej trudności, jedną sesję dla roli podwyższonego ryzyka i raport metryk dla zarządu; raz w roku dochodzą sesja zarządu (NIS2/DORA), przegląd programu (PCI DSS 12.6.2) i aktualizacja treści o nowe techniki.
| Kwartał | Szkolenia | Symulacje | Role podwyższonego ryzyka | Dowody i przeglądy |
|---|---|---|---|---|
| Q1 | sesja zarządu (art. 20 NIS2, art. 5 i 13 DORA); moduł bazowy dla wszystkich: trzy nawyki | kampania kalibracyjna (łatwa) + kampania standardowa | finanse: zmiana rachunku, BEC | karta programu zatwierdzona; raport bazowy dla zarządu |
| Q2 | mikromoduł: vishing i klonowanie głosu | kampania z ciągłością wątku; pierwszy wariant QR | help desk: pretexting na reset MFA/hasła | raport Q2; przegląd granic etycznych po pierwszych kampaniach |
| Q3 | mikromoduł: deepfake i weryfikacja zwrotna | kampania trudna (personalizacja jak u przeciwnika); pilotaż symulacji głosowej dla uzgodnionych ról | zarząd i asystencja: vishing „od prezesa” | raport Q3; test procedury zgłaszania end-to-end (zgłoszenie → reakcja SOC) |
| Q4 | moduł przypominający + omówienie prawdziwych kampanii roku | kampania wielokanałowa (mail + SMS zapowiadający) | administratorzy: konsekwencje na kontach uprzywilejowanych | roczny przegląd programu (PCI DSS 12.6.2); aktualizacja treści; raport roczny i plan na kolejny rok |
| Ciągle | 3-minutowe alerty po realnych kampaniach na organizację | – | onboarding: moduł w pierwszym tygodniu (PCI DSS 12.6.3) | rejestr ukończeń; metryki miesięczne |
Dobrze zaprojektowany harmonogram sprawia, że dowody regulacyjne – sesja zarządu, roczny przegląd programu, zapisy ukończeń, treść o phishingu i socjotechnice – powstają jako produkt uboczny programu zmieniającego zachowania, a nie jako osobne przedsięwzięcie „pod audyt”.
Harmonogram warto zsynchronizować z resztą programu bezpieczeństwa: kampania trudna przed testami socjotechnicznymi w pentestach daje porównanie „ćwiczenie vs przeciwnik”, a wyniki obu zasilają te same rekomendacje proceduralne (weryfikacja zwrotna, help desk, płatności). Miejsce programu w szerszych priorytetach pokazuje 12-miesięczny plan cyberbezpieczeństwa.
Kiedy prowadzić program siłami wewnętrznymi, a kiedy kupić usługę?
Siłami wewnętrznymi warto prowadzić program, gdy istnieje osoba z czasem i warsztatem (treści, platforma, analiza), a organizacja potrzebuje głównie rytmu. Usługa zewnętrzna wygrywa, gdy potrzebne są scenariusze nadążające za technikami AI (w tym głosowe), obce oko wolne od wewnętrznych założeń, gotowe pakiety dowodów pod NIS2/DORA/PCI oraz przewidywalny koszt – i gdy nikt wewnątrz nie chce być „tym od łapania kolegów”.
| Kryterium | Program wewnętrzny | Usługa zewnętrzna |
|---|---|---|
| Koszt startu | licencja platformy + czas osoby prowadzącej | stała cena za uzgodniony program roczny |
| Aktualność scenariuszy | zależna od czasu zespołu na research | aktualizowana z technikami ataków (mail, QR, głos) |
| Scenariusze głosowe i wielokanałowe | rzadko wykonalne własnymi siłami | w zakresie usługi, z uzgodnieniami w karcie programu |
| Neutralność | prowadzący zna kulturę, ale i „wie, kto kliknie” | obce oko; łatwiejsza pozycja przy zarządzie i HR |
| Dowody regulacyjne | do zbudowania samodzielnie | pakiet raportów pod art. 20 NIS2, art. 13 DORA, 12.6 PCI w standardzie usługi |
| Ryzyko ciągłości | program umiera z odejściem osoby prowadzącej | ciągłość po stronie dostawcy |
| Model rozliczenia | koszt wewnętrzny, trudny do policzenia | za rezultaty: kampanie, moduły, raporty w stałej cenie |
Decyzja „wewnętrznie czy usługa” sprowadza się do dwóch pytań: czy ktoś w organizacji ma czas i warsztat, by co 4-6 tygodni dostarczać kampanię na poziomie dzisiejszego przeciwnika, oraz kto ma być twarzą programu wobec pracowników – bo ta rola źle znosi łączenie z codziennym nadzorem IT.
Model hybrydowy – wewnętrzny właściciel programu plus zewnętrzne kampanie i treści – łączy kontekst organizacyjny z aktualnością scenariuszy; to odpowiednik hybrydy opisanej przy wyborze między usługą a etatem IT Compliance Officera, z tą samą zasadą: artefakty (karta programu, raporty, rejestr ukończeń) są własnością klienta w jego narzędziach.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że programy kupowane „per kampania” rozpadają się po dwóch kwartałach – każda kampania wymaga osobnych uzgodnień, a między nimi program nie istnieje. Dlatego sprzedajemy wyłącznie program roczny w stałej cenie: harmonogram jak w tabeli wyżej, kampanie, moduły, sesja zarządu i raporty kwartalne jako uzgodniony katalog rezultatów. Rozliczamy rezultaty, nie godziny – liczba pytań od pracowników po kampanii czy dodatkowa iteracja treści nie zmienia ceny.
Jakie błędy najczęściej niszczą programy awareness i symulacje?
❌ Imienne listy klikających dla przełożonych – zamienia program w narzędzie oceny; raportowanie incydentów spada do zera. Wyniki analizuje się per zespół i scenariusz.
❌ Sankcje lub „obowiązkowe rozmowy dyscyplinujące” po kliknięciu – pracownik, który wie, że kliknięcie kosztuje, nie zgłosi prawdziwego kliknięcia; jedyną reakcją indywidualną jest wsparcie.
❌ Kampanie żerujące na tematach wrażliwych – „premia roczna”, „redukcja etatów”, „wyniki badań” dają wysokie kliknięcia i długotrwałą utratę zaufania; granice etyczne spisane w karcie programu chronią program przed samym sobą.
❌ Pomijanie zarządu w symulacjach i szkoleniach – łamie art. 20 NIS2 i art. 13 ust. 6 DORA, a organizacyjnie komunikuje, że zasady są dla szeregowych; vishing „na prezesa” celuje właśnie w górę struktury.
❌ Optymalizacja pod click-rate – łatwe kampanie robią ładne wykresy i zerową odporność; poziom trudności musi rosnąć, a metryką sukcesu jest raportowanie.
❌ Brak kanału zgłoszeń działającego w minucie – jeśli zgłoszenie wymaga szukania adresu w intranecie, nie będzie zgłoszeń; przycisk w kliencie poczty plus prosty kanał dla vishingu/SMS to warunek wstępny, nie usprawnienie.
❌ Program bez karty i bez uzgodnień z HR/IOD – pierwszy spór o wyniki imienne lub pretext zawstydzający potrafi zatrzymać program na kwartały; godzina uzgodnień przed startem oszczędza miesiące.
FAQ – najczęstsze pytania o program awareness i symulacje phishingowe
Jak często prowadzić symulacje phishingowe?
Co 4-6 tygodni na rotujących próbach populacji – wystarczająco często, by temat nie wygasał, i wystarczająco rzadko, by nie spowszedniał. Ważniejsza od częstotliwości jest zmienność scenariuszy i kanałów oraz stały rytm mikromodułów między kampaniami.
Czy pracownicy powinni wiedzieć o symulacjach?
O programie – tak, o pojedynczej kampanii – nie. Jawny program (cel, zasady, brak sankcji, kto widzi wyniki) buduje zaufanie i porządkuje kwestie RODO; niejawność konkretnej kampanii zachowuje wartość pomiaru. Ten podział zapisuje się w karcie programu uzgodnionej z HR i IOD.
Czy wyniki symulacji można wykorzystać wobec pracownika?
Nie powinno się – i warto to zapisać wprost w karcie programu. Wyniki służą ocenie programu i procedur, dane imienne widzi wyłącznie zespół programu w celu wsparcia (np. dodatkowy moduł), a przetwarzanie podlega zasadom RODO: cel, minimalizacja, retencja, informacja dla pracowników.
Czy symulacje wystarczą jako szkolenie wymagane przez NIS2 i PCI DSS?
Nie. NIS2 art. 20 wymaga szkoleń zarządu, DORA art. 13 ust. 6 – modułów świadomości w systemie szkoleń, PCI DSS 12.6.3 – szkolenia przy zatrudnieniu i co roku z określoną treścią. Symulacje są praktyką i pomiarem; obok nich muszą istnieć moduły szkoleniowe z zapisami ukończenia.
Czy testowy vishing (symulowane telefony) jest legalny i etyczny?
Tak, przy właściwych uzgodnieniach: zapis w karcie programu, zdefiniowane role objęte testem, scenariusze bez tematów wrażliwych, brak nagrywania ponad potrzebę, natychmiastowe ujawnienie po zakończeniu rozmowy testowej. Prowadzony bez uzgodnień potrafi naruszyć zaufanie i przepisy – dlatego wchodzi do programu po ustabilizowaniu kampanii mailowych.
Ile kosztuje program awareness w Patronusec i co obejmuje?
Cena jest stała za program roczny i zależy od wielkości populacji, liczby kampanii i kanałów (mail, QR, głos) oraz liczby sesji dedykowanych (zarząd, finanse, help desk). W standardzie: karta programu, harmonogram kwartalny, moduły i kampanie, raporty metryk dla zarządu i pakiet dowodów pod NIS2, DORA i PCI DSS. Rozliczamy rezultaty, nie godziny.
Od czego zacząć, jeśli nie mamy dziś nic?
Od trzech kroków w tej kolejności: kanał zgłoszeń działający w minutę (przycisk w poczcie), karta programu uzgodniona z zarządem, HR i IOD oraz kampania kalibracyjna dająca metryki bazowe. Dopiero na tych fundamentach ma sens harmonogram roczny – inaczej mierzy się szum.
Co czytać dalej – ścieżka lektury
- Phishing w erze AI – deepfake, klonowanie głosu i spear phishing z LLM – hub klastra: co potrafi dziś atakujący i które warstwy obrony technicznej działają.
- IT Compliance Officer – kim jest i za co odpowiada – jak wymogi szkoleniowe z czterech reżimów trafiają do jednego kalendarza obowiązków z dowodami.
- NIS2 – podmiot kluczowy czy ważny – pełna mapa obowiązków, w której szkolenia z art. 20-21 są jednym z elementów.
- Ransomware – pierwsze 72 godziny – procedura, którą program awareness zasila zgłoszeniami: co się dzieje po pierwszym „zgłoś”.
- 12-miesięczny plan cyberbezpieczeństwa – gdzie program awareness mieści się wśród rocznych priorytetów obok kontroli technicznych.
Program security awareness i symulacje phishingowe – bezpłatna konsultacja
Patronusec prowadzi roczne programy awareness w modelu rozliczenia za rezultaty: karta programu, sesja zarządu zamykająca obowiązek z art. 20 NIS2, kampanie mailowe, QR i głosowe o rosnącej trudności, mikromoduły oraz kwartalne raporty metryk raportowania – w stałej cenie, z pakietem dowodów pod NIS2, DORA, ISO 27001 i PCI DSS.
W bezpłatnej 30-minutowej konsultacji pomożemy Ci:
- przygotować kartę programu z zasadami, które zaakceptują zarząd, HR i IOD,
- zaplanować kampanię kalibracyjną i metryki bazowe (report rate, czas do zgłoszenia),
- ułożyć harmonogram roczny domykający wymogi NIS2, DORA i PCI DSS 12.6 jako produkt uboczny programu,
- zdecydować między modelem wewnętrznym, usługą a hybrydą – z katalogiem rezultatów do rozliczenia dowolnego dostawcy.
Umów bezpłatną konsultację | Szkolenia i testy phishingowe | Testy penetracyjne | IT Compliance Officer | vCISO
