How do you build a security awareness programme that works? A working programme combines four elements: content matched to current attacks (vishing, deepfakes, multi-channel scripts – not just email), phishing simulations run without punishment or “hunting employees”, metrics that measure reporting and response time rather than click rates alone, and a continuous rhythm instead of a single annual course.
The regulations – NIS2 (Articles 20-21), DORA (Article 13(6)), ISO 27001 (A.6.3) and PCI DSS (12.6) – require a programme but do not say how to make it change behaviour; this article fills that gap. The threat context – what an AI-equipped attacker can do today and why old training stopped working – is covered in the cluster’s first asset: Phishing in the AI era.
Canonical definition: A security awareness programme is a continuous, measured process of building security behaviours in staff and management, comprising role-appropriate training, controlled social engineering simulations and reporting metrics, required in varying forms by NIS2, DORA, ISO 27001 and PCI DSS.
A security awareness programme – key takeaways:
- The regulations require a programme, not a course: NIS2 obliges management bodies to undergo training (Art. 20(2)) with personal liability attached, DORA makes ICT awareness a compulsory module of staff training for everyone including senior management (Art. 13(6)), and PCI DSS mandates phishing and social engineering content (12.6.3.1) plus a programme review every 12 months (12.6.2).
- A single annual course does not change behaviour – it builds formal evidence, not resilience; what works is rhythm: short modules, simulations every 4-6 weeks, and communication after real campaigns.
- The most important metric is the report rate and time to first report, not the click rate: clicks will always happen, and the scale of damage depends on how quickly the SOC finds out.
- A simulation designed as a trap for employees (punishment, shaming, “clicker lists” for managers) destroys the programme: it kills the reporting of real incidents and trust in security.
- Scenarios must keep pace with attackers: voice and QR simulations alongside email, difficulty tiers, and pretexts built the way adversaries build them today – with AI.
- Patronusec delivers awareness sessions and phishing tests on an outcomes pricing model: an agreed annual programme at a fixed price, board reports built on reporting metrics, and content updated as attack techniques evolve.
Table of Contents
What exactly do NIS2, DORA, ISO 27001 and PCI DSS require for training and awareness?
The four regimes require four different things: NIS2 – management body training and the offer of equivalent training to staff, plus cyber hygiene as a risk management measure; DORA – compulsory ICT awareness modules for all staff and senior management; ISO 27001 – role-appropriate awareness, education and training with effectiveness evaluation; PCI DSS – a formal programme with specific content (phishing, social engineering, acceptable use) reviewed every 12 months.
| Regime | Provision / control | Requirement | Who | Evidence for the auditor |
|---|---|---|---|---|
| NIS2 | Art. 20(2) | members of management bodies are required to follow cybersecurity training; the entity should offer similar training to employees | board (obligation), staff (offer) | board attendance records, training programme, cadence |
| NIS2 | Art. 21(2)(g) | basic cyber hygiene practices and cybersecurity training as a risk management measure | everyone | policy, materials, population coverage |
| DORA | Art. 13(6) | ICT security awareness programmes and digital operational resilience training as compulsory modules in staff training schemes; applies to senior management too; complexity proportionate to the function | all staff + senior management | training scheme with ICT modules, completion records, role proportionality |
| DORA | Art. 5(4) | management body members keep ICT risk knowledge up to date, including through regular training | board | board training records |
| ISO/IEC 27001:2022 | A.6.3 | awareness, education and training appropriate to the function, with policy updates; clauses 7.2-7.3 – competence and awareness, with evidence | everyone, per role | training plan, materials, effectiveness evaluation, competence records |
| PCI DSS v4.0.1 | 12.6.1-12.6.2 | a formal security awareness programme, reviewed at least every 12 months and updated for new threats | in-scope personnel | programme document, review dates |
| PCI DSS v4.0.1 | 12.6.3, 12.6.3.1, 12.6.3.2 | training upon hire and at least annually; content must include phishing and social engineering (from 31 Mar 2025) and acceptable use of technologies | in-scope personnel | completion records, policy acknowledgements, module content |
| PCI DSS v4.0.1 | 5.4.1 | mechanisms to detect and protect personnel against phishing attacks (a technical control supporting the programme) | organisation | mail protection configuration, DMARC |
The common denominator of the four regimes is a continuous programme with evidence – not a one-off course: NIS2 and DORA extend the obligation to the board, PCI DSS prescribes content and an annual rhythm, and ISO 27001 adds an effectiveness evaluation requirement – in other words, metrics.
Two practical consequences. First, the board is a participant, not a sponsoring observer: Article 20 of NIS2 ties management body training to personal accountability for overseeing the measures, and Article 5 of DORA to accountability for the ICT risk framework. Second, ISO 27001’s effectiveness requirement (clause 9.1 with 7.2) means an attendance list is not enough – behavioural metrics are needed, covered below. The deadlines and evidence from this table belong in an obligations calendar – if you run one in the model described for the IT Compliance Officer service, the awareness programme is a natural line in it.
Why does the classic annual course fail to change behaviour?
The annual course fails for three reasons: declarative knowledge does not translate into behaviour under pressure (the employee “knows” to verify but clicks at 4:50 pm on a Friday), a single stimulus fades within weeks, and content ages faster than the training cycle – a module recorded a year ago contains neither voice cloning nor QR codes. Behaviour changes through a rhythm of short stimuli combined with safe practice – which is what simulations are.
What working programmes have in common:
- Short and often beats long and rare – 5-10 minute modules every few weeks keep the topic in view; two hours of annual e-learning builds only a system record.
- Practice without consequences – a simulation is a gym: a place to “click” without harm and see what the attack looked like; without simulations, the first contact with a realistic attack happens under live fire.
- The context of real campaigns – the most effective training material is last week’s anonymised, genuine attack on your organisation, discussed in a 3-minute note: “what arrived and what could have given it away”.
- Roles instead of mass mailing – finance rehearses account changes and BEC, the help desk rehearses MFA-reset pretexting, the board rehearses vishing and deepfakes, administrators rehearse the consequences of a click on a privileged account. DORA Article 13(6) makes the same proportionality-to-function demand.
The goal of an awareness programme is not knowledge but three habits resistant to forgery quality: pausing at urgency combined with secrecy, verifying via a different channel, and reporting immediately – including your own click.
That shift of goal has a content consequence: less “how to spot a fake email” (increasingly impossible – shown in the AI phishing analysis), more “what to do with every request for money, data and access, however credible it looks”.
How do you design phishing simulations that teach rather than hunt employees?
A simulation teaches when it meets five conditions: the goal written down as increased reporting (not “finding weak links”), the click moment turned into micro-training (an education page instead of a wall of shame), no personal sanctions and no named lists for managers, difficulty tiers that grow with maturity, and rules agreed with HR – and, where present, employee representatives – before launch. A simulation designed as a trap produces the opposite effect: it teaches people to hide incidents.
Design rules in practice:
- A programme charter before the first campaign – a document agreed with the board, HR and the DPO: the goal (reporting), the no-sanctions rule, who sees which data (team-level results – yes; named lists for managers – no; named data only for the programme team, for support purposes such as an extra module after repeated clicks), retention of results, and the programme’s communication channel. Named results are employee personal data – GDPR requires purpose, minimisation and information; the charter is where you settle this.
- Announce the programme, not the campaign – staff know simulations run all year; they do not know when or what. An open programme builds trust and lawfulness; keeping individual campaigns unannounced preserves the measurement’s value.
- A click = 60 seconds of learning – the post-click page shows what the lure was, which signals were available, and one “report next time” button; no shaming, with thanks for every minute of attention.
- A report = visible appreciation – a thank-you confirmation, periodic recognition of the teams with the highest reporting; the reporters are the heroes of the programme’s communication.
- Difficulty tiers and channels – start with obvious scenarios (baseline calibration), progress to pretexts built like the adversary’s: personalisation from public data, thread continuity, authority pressure; once email is stable, add QR and voice variants (test vishing needs separate agreements: scenarios, roles in scope, a charter entry).
- Ethical boundaries – no pretexts exploiting health, redundancies, bereavement or “HR bonus” themes during appraisal periods; such lures score high and cost trust for years. Boundaries written into the charter.
A phishing simulation measures the effectiveness of the programme and the procedures, not the honesty of employees – which is why results are analysed at team and scenario level, and the only acceptable individual consequence of a click is an additional, supportive portion of training.
Patronusec Insight: In our project experience, one communication decision determines a programme’s first year: who signs the programme announcement. If IT signs it, the programme is “another test from the IT department”; if the board signs it, with a clear “we are being tested and trained too”, it becomes an organisational norm. That is why in the programmes we run within awareness sessions and phishing tests, the first element is a board session (which also closes the Article 20(2) NIS2 obligation), and the board is in the simulation audience from the first campaign.
Which metrics should you measure – and why is click rate the least important?
Measure five metrics in this order of importance: the report rate, the time to first report, the report-to-click ratio, the share of repeat clickers handled with support, and – last – the click rate as background. Click rate is the weakest metric because it mostly reflects scenario difficulty (easy to “manage” by sending easy campaigns) and says nothing about what determines damage: whether the organisation found out.
| Metric | Definition | Why it matters | Directional target |
|---|---|---|---|
| Report rate | % of simulation recipients who reported it via the official channel | the only metric correlated with what saves you in a real attack | rising trend; mature programmes see it exceed the click rate |
| Time to first report | minutes from campaign start to the first report | sets how fast the SOC can pull a real campaign from mailboxes | falling; ultimately minutes, not hours |
| Report-to-click ratio | reports / clicks in the same campaign | shows culture: do people report even after clicking | > 1 and rising |
| Reports after clicking | % of clickers who reported their own mistake | the purest indicator of trust in the programme (nobody confesses to a punisher) | rising |
| Repeat clickers | people clicking in ≥3 consecutive campaigns | a signal for support (an extra module, a workload conversation), not sanctions | falling, handled with support |
| Click rate (background) | % of clicks in a campaign | context for scenario difficulty; comparable only within the same tier | no absolute target |
| Training coverage and timeliness | % of the population with modules completed on time, including the board | hard evidence for NIS2 Art. 20, DORA Art. 13(6), PCI DSS 12.6.3 | 100 % for regulatory items |
The report rate and the time to first report measure exactly what decides the outcome of a real attack – how quickly the organisation finds out – whereas the click rate mostly measures scenario difficulty, which the campaign’s author controls.
A quarterly board report built on these metrics simultaneously satisfies ISO 27001’s effectiveness evaluation and builds the NIS2 Article 20 oversight evidence – provided it is presented and minuted, not emailed. The four-quarter trend says more than any single campaign.
Want to see what these metrics would look like in your organisation before you buy anything?
Patronusec runs a free calibration campaign: one controlled email simulation on an agreed sample, with a programme charter, an education page and a baseline report (report rate, time to report, report-to-click ratio) within 10 working days – as the starting point for an annual programme decision, with us or with anyone.
Request a calibration campaign
What does an annual schedule look like that ties together training, simulations and the regulatory requirements?
The annual schedule runs on a quarterly rhythm: each quarter contains one short module for everyone, 2-3 simulation campaigns of rising difficulty, one session for a high-risk role and a metrics report for the board; once a year come the board session (NIS2/DORA), the programme review (PCI DSS 12.6.2) and a content refresh for new techniques.
| Quarter | Training | Simulations | High-risk roles | Evidence and reviews |
|---|---|---|---|---|
| Q1 | board session (NIS2 Art. 20, DORA Art. 5 and 13); baseline module for everyone: the three habits | calibration campaign (easy) + one standard campaign | finance: account change, BEC | programme charter approved; baseline report to the board |
| Q2 | micro-module: vishing and voice cloning | thread-continuity campaign; first QR variant | help desk: MFA/password-reset pretexting | Q2 report; ethical-boundary review after the first campaigns |
| Q3 | micro-module: deepfakes and call-back verification | hard campaign (adversary-grade personalisation); voice simulation pilot for agreed roles | board and assistants: “from the CEO” vishing | Q3 report; end-to-end test of the reporting path (report → SOC response) |
| Q4 | refresher module + review of the year’s real campaigns | multi-channel campaign (email + a priming SMS) | administrators: consequences on privileged accounts | annual programme review (PCI DSS 12.6.2); content refresh; annual report and next-year plan |
| Continuous | 3-minute alerts after real campaigns against the organisation | – | onboarding: a module in week one (PCI DSS 12.6.3) | completion register; monthly metrics |
A well-designed schedule makes the regulatory evidence – the board session, the annual programme review, completion records, phishing and social engineering content – a by-product of a behaviour-changing programme rather than a separate “for the audit” exercise.
Synchronise the schedule with the wider security programme: a hard campaign before the social engineering exercises in penetration tests gives you a “drill vs adversary” comparison, and both feed the same procedural recommendations (call-back verification, help desk, payments). The programme’s place among annual priorities is shown in the 12-month cybersecurity roadmap.
When should you run the programme in-house, and when should you buy the service?
Run it in-house when someone has the time and the craft (content, platform, analysis) and the organisation mainly needs rhythm. The external service wins when you need scenarios that keep pace with AI techniques (including voice), an outside eye free of internal assumptions, ready evidence packs for NIS2/DORA/PCI, a predictable cost – and when nobody inside wants to be “the one who catches colleagues”.
| Criterion | In-house programme | External service |
|---|---|---|
| Start-up cost | platform licence + the running person’s time | fixed price for an agreed annual programme |
| Scenario currency | depends on the team’s research time | updated with attack techniques (email, QR, voice) |
| Voice and multi-channel scenarios | rarely feasible in-house | within the service, governed by the charter |
| Neutrality | the runner knows the culture, but also “knows who will click” | an outside eye; an easier position with the board and HR |
| Regulatory evidence | built by yourself | a report pack for NIS2 Art. 20, DORA Art. 13, PCI DSS 12.6 as standard |
| Continuity risk | the programme dies with the person’s departure | continuity on the provider’s side |
| Pricing model | internal cost, hard to count | outcomes: campaigns, modules and reports at a fixed price |
The in-house-or-service decision reduces to two questions: does anyone in the organisation have the time and craft to deliver an adversary-grade campaign every 4-6 weeks, and who should be the programme’s face to employees – because that role combines badly with day-to-day IT oversight.
A hybrid – an internal programme owner plus external campaigns and content – combines organisational context with scenario currency; it is the counterpart of the hybrid described in external IT Compliance Officer or a hire, with the same rule: the artefacts (charter, reports, completion register) belong to the client in the client’s tools.
Patronusec Insight: In our project experience, programmes bought “per campaign” fall apart within two quarters – each campaign needs fresh arrangements, and between campaigns the programme does not exist. That is why we sell only an annual programme at a fixed price: the schedule as in the table above, campaigns, modules, the board session and quarterly reports as an agreed outcomes catalogue. We charge for outcomes, not hours – the number of employee questions after a campaign or an extra content iteration does not change the price.
Which mistakes most often destroy awareness programmes and simulations?
❌ Named clicker lists for managers – turns the programme into an appraisal tool; the reporting of real incidents drops to zero. Results are analysed per team and scenario.
❌ Sanctions or “mandatory disciplinary chats” after a click – an employee who knows a click has a price will never report a real one; the only individual response is support.
❌ Campaigns exploiting sensitive themes – “annual bonus”, “redundancies”, “test results” score high clicks and years of lost trust; ethical boundaries written in the charter protect the programme from itself.
❌ Excluding the board from simulations and training – breaches NIS2 Art. 20 and DORA Art. 13(6), and organisationally signals the rules are for the rank and file; “CEO” vishing targets precisely the top of the structure.
❌ Optimising for click rate – easy campaigns make pretty charts and zero resilience; difficulty must rise, and the success metric is reporting.
❌ No one-minute reporting channel – if reporting requires hunting for an address on the intranet, there will be no reports; a button in the mail client plus a simple channel for vishing/SMS is a precondition, not an enhancement.
❌ A programme without a charter and without HR/DPO agreement – the first dispute over named results or a shaming pretext can freeze the programme for quarters; an hour of alignment before launch saves months.
FAQ – common questions about awareness programmes and phishing simulations
How often should phishing simulations run?
Every 4-6 weeks on rotating population samples – often enough that the topic never fades, and rarely enough that it never becomes routine. More important than frequency are scenario and channel variety, and a steady rhythm of micro-modules between campaigns.
Should employees know about the simulations?
About the programme – yes; about an individual campaign – no. An open programme (goal, rules, no sanctions, who sees results) builds trust and settles the GDPR questions; keeping a specific campaign unannounced preserves the measurement’s value. That split is written into the charter agreed with HR and the DPO.
Can simulation results be used against an employee?
They should not be – and it is worth stating explicitly in the charter. Results serve to evaluate the programme and the procedures; named data is visible only to the programme team for support purposes (e.g. an extra module), and processing follows GDPR: purpose, minimisation, retention, employee information.
Are simulations enough to satisfy the NIS2 and PCI DSS training requirements?
No. NIS2 Art. 20 requires board training, DORA Art. 13(6) requires awareness modules in the training scheme, and PCI DSS 12.6.3 requires training upon hire and annually with defined content. Simulations are the practice and the measurement; training modules with completion records must exist alongside them.
Is test vishing (simulated calls) lawful and ethical?
Yes, with the right arrangements: a charter entry, defined roles in scope, scenarios avoiding sensitive themes, no recording beyond necessity, and immediate disclosure at the end of the test call. Run without those arrangements it can breach trust and law – which is why it enters the programme after the email campaigns are stable.
How much does a Patronusec awareness programme cost, and what does it include?
The price is fixed for the annual programme and depends on population size, the number of campaigns and channels (email, QR, voice) and dedicated sessions (board, finance, help desk). As standard: the programme charter, the quarterly schedule, modules and campaigns, board metric reports and the evidence pack for NIS2, DORA and PCI DSS. We charge for outcomes, not hours.
Where do we start if we have nothing today?
With three steps in this order: a reporting channel that works in a minute (a button in the mail client), a programme charter agreed with the board, HR and the DPO, and a calibration campaign that gives you baseline metrics. Only on those foundations does an annual schedule make sense – otherwise you measure noise.
Recommended reading
- Phishing in the AI era – deepfakes, voice cloning and LLM spear phishing – the cluster hub: what attackers can do today and which technical defence layers work.
- IT Compliance Officer – what the role is – how the training requirements of four regimes land in one obligations calendar with evidence.
- NIS2 essential or important entity – the full obligations map in which Articles 20-21 training is one element.
- Ransomware response playbook – the first 72 hours – the procedure the awareness programme feeds with reports: what happens after the first “report”.
- 12-month cybersecurity roadmap – where the awareness programme sits among annual priorities alongside technical controls.
A security awareness programme and phishing simulations – free consultation
Patronusec runs annual awareness programmes on an outcomes model: the programme charter, a board session closing the NIS2 Article 20 obligation, email, QR and voice campaigns of rising difficulty, micro-modules and quarterly reporting-metric reports – at a fixed price, with an evidence pack for NIS2, DORA, ISO 27001 and PCI DSS.
In a free 30-minute consultation we will help you:
- prepare a programme charter with rules the board, HR and the DPO will accept,
- plan the calibration campaign and baseline metrics (report rate, time to report),
- build an annual schedule that closes the NIS2, DORA and PCI DSS 12.6 requirements as a by-product,
- decide between in-house, service and hybrid – with an outcomes catalogue you can hold any provider to.
Book a free consultation | Awareness sessions and phishing tests | Penetration testing | IT Compliance Officer | vCISO
