For years, "security awareness training" meant an annual module, a quiz at the end, and a completion certificate filed away for the next audit. That approach is getting harder to defend under two of the most consequential compliance frameworks touching financial services today — and the gap between what most institutions are doing and what these frameworks now require is wider than most compliance teams realize.
PCI-DSS v4.0: the annual session becomes the floor, not the program
PCI-DSS v4.0 (now v4.0.1) rebuilt Requirement 12.6, and its future-dated requirements became mandatory on 31 March 2025. Requirement 12.6.1 calls for a formal security awareness program. Requirement 12.6.2 requires that program to be reviewed at least once every 12 months and updated for new threats and vulnerabilities — not a static module reused year after year. Requirement 12.6.3 sets the floor: training upon hire and at least once every 12 months, delivered through multiple methods of communication. And Requirement 12.6.3.1 adds explicit content: personnel must be trained on phishing and related social engineering attacks.
Read together, the annual session is the minimum, not the program. A program that is reviewed against the current threat landscape and delivered through several channels is, in practice, a continuous one.
The standard also specifically targets technical staff: Requirement 6.2.2 requires software development personnel working on bespoke and custom software to be trained at least once every 12 months on software security relevant to their job function and development languages, including secure software design and secure coding techniques. Generic, one-size-fits-all awareness content delivered to a developer does not satisfy this requirement — it has to be role-specific.
DORA: training as a binding legal obligation, not an HR exercise
The EU's Digital Operational Resilience Act treats this even more explicitly. DORA has applied since 17 January 2025, and Article 13(6) is binding regulation, not guidance: financial entities "shall develop ICT security awareness programmes and digital operational resilience training as compulsory modules in their staff training schemes." The article requires that these programs be:
- Compulsory — built into staff training schemes, not optional or self-directed
- Universal — applicable to all employees and to senior management
- Proportionate to role — with "a level of complexity commensurate to the remit of their functions"
- Extended to ICT third-party service providers where appropriate, in line with Article 30(2)(i)
DORA's testing regime points the same way. Financial entities identified by their competent authority must run threat-led penetration testing (TLPT) at least every three years, and frameworks such as TIBER-EU, on which DORA's TLPT is modelled, routinely include social engineering of staff in scope. Training success is drifting away from completion rates and toward demonstrated resilience under realistic attack.
Why generic annual training fails this standard structurally, not just technically
The underlying research on training efficacy explains why regulators moved in this direction. Memory research going back to Ebbinghaus's forgetting curve, and replicated by Murre and Dros in 2015, shows that most newly learned material is lost within days unless it is reinforced. Field evidence on phishing training points the same way: a randomized study of more than 19,500 employees at UC San Diego Health found no significant relationship between how recently someone completed annual training and whether they failed a phishing simulation. That means an organization relying solely on annual compliance training is functionally operating with an under-trained workforce for most of the year. Frameworks that require regular review, multiple delivery channels and role-specific content are responding to this evidence, not expressing a bureaucratic preference.
| Old Model | What PCI-DSS v4.0 / DORA Now Require |
|---|---|
| Annual training event | Program reviewed and updated at least every 12 months, delivered through multiple channels |
| Generic content for all roles | Training commensurate to each role's remit; dedicated secure coding training for developers |
| Completion certificate as evidence | Evidence the program addresses current threats, including phishing and social engineering |
| Internal staff only | All employees and senior management, plus ICT third-party providers where appropriate under DORA |
What compliance and security leaders should be doing now
- Audit your current program against the "continuous" standard, not the "annual" one. If your last full review of training content was more than 12 months ago, you likely have a documentable gap under PCI-DSS 12.6.2.
- Segment training by technical role, particularly for developers under PCI-DSS 6.2.2 — generic phishing awareness content does not satisfy a secure coding training requirement.
- Build evidence of behavioral outcomes, not just completion logs. Neither framework accepts a module that was merely opened as proof of a working program, and assessors increasingly ask what changed as a result.
This is precisely the operational gap our Ethical Hacking & Bug Bounty Bootcamp was designed around — building the kind of hands-on, role-specific, continuously reinforced security capability that satisfies where these regulations are actually heading, not where annual compliance training has historically stopped.
Requirement numbers refer to PCI DSS v4.0.1 and Regulation (EU) 2022/2554 (DORA). This piece is informational, not compliance advice; confirm scope with your QSA or competent authority.