Most regulated organisations run one annual awareness module, yet the laws and standards behind it ask for different things: board training under NIS2 and DORA, training before access under FISMA rules, annual social engineering training under NYDFS, and AI literacy under the EU AI Act. An auditor will test the specific duty, not the existence of a programme. This map sets out the mandated awareness and role-based training duties in the main EU and US regimes and the common frameworks: who must be trained, on what, how often, and what evidence proves it. It is for CISOs, security awareness leads, compliance and HR teams who need one training programme that satisfies several regulators. Status checked 12 November 2026.
Source note: each duty is summarised from the official legal or standards text listed at the end; where a summary relies on a law firm analysis it is labelled as such. Confirm against the official text before relying on it.
Key takeaways
- Boards are now named trainees. NIS2 Article 20(2) requires members of management bodies to follow training, and DORA Article 5(4) requires management body members to keep their ICT risk knowledge current, including through regular specific training.
- Annual is the common floor, not the rule everywhere. NYDFS 500.14(a)(3) and 5 CFR 930.301 set an explicit annual minimum; NIS2, DORA, HIPAA and the GLBA Safeguards Rule require training without a fixed frequency, so you must set and justify one.
- Before access is a hard requirement in US federal rules. 5 CFR 930.301 requires new employees to receive awareness material before system access, and NIST SP 800-53 AT-3 expects role-based training before authorising access.
- Social engineering is explicitly required. NYDFS requires annual training that includes social engineering for all personnel; NIST SP 800-53 AT-2(3) covers social engineering and mining.
- Role-based training is a separate duty. DORA scales training to function, 5 CFR 930.301 requires role-specific training for staff with significant security duties, and the GLBA Safeguards Rule requires security staff to receive training sufficient for the risks; generic awareness does not satisfy these.
Regulations and frameworks at a glance
| Regime | Who must be trained | Content named | Frequency | Status (12 November 2026) |
|---|---|---|---|---|
| EU NIS2 Directive, Art. 20(2) and 21(2)(g) | Members of management bodies (required); employees (entities encouraged to train regularly) | Skills to identify risks and assess cyber risk management practices; basic cyber hygiene and cybersecurity training | Not fixed in the Directive; national laws may set it | Applies through national transposition laws |
| EU DORA, Regulation (EU) 2022/2554, Art. 5(4) and 13(6) | All employees and senior management; management body members; ICT third-party providers where appropriate | ICT security awareness programmes and digital operational resilience training, complexity matched to function | Regular for management body; compulsory modules in staff training schemes | Applies since 17 January 2025 |
| EU AI Act, Art. 4 | Staff and others operating or using AI systems on behalf of providers and deployers | AI literacy suited to their knowledge, experience and the context of use | Not fixed | Applies from 2 February 2025; amended by the Digital Omnibus on AI (in force 27 July 2026) to a duty to take measures supporting AI literacy rather than ensure a sufficient level (law firm summaries) |
| US HIPAA Security Rule, 45 CFR 164.308(a)(5) | All members of the workforce, including management | Security reminders, malicious software, log-in monitoring, password management (addressable) | Not fixed; "periodic security updates" | In force |
| US NYDFS, 23 NYCRR 500.14(a)(3) | All personnel of covered entities | Cybersecurity awareness including social engineering, updated to reflect the risk assessment | Periodic, at minimum annual | In force |
| US GLBA Safeguards Rule, 16 CFR 314.4(e) | Personnel; information security staff | Awareness updated to reflect risk assessment; security updates and training for security staff | Not fixed | In force |
| US federal agencies, 5 CFR 930.301 | All users of federal information systems, including contractors; staff with significant security responsibilities | Awareness; role-specific training for executives, managers, CIOs and security staff, IT operations | At least annually; before access for new employees; on significant system change or new role | In force |
| PCI DSS v4.0.1, Requirement 12.6 and 6.2.2 | All personnel; software development personnel | Formal awareness programme; phishing and social engineering; acceptable use; secure software development | On hire and at least every 12 months | Future-dated v4.0 requirements mandatory since 31 March 2025 |
Many national and sector rules add to these, and contracts often pass training duties down to suppliers. For the design of the programme itself, see the Role-Based Security Training Programme Guide.
Scope: who counts as a trainee
- Management and boards: NIS2 and DORA name management body members directly; HIPAA includes management in the workforce. Board training needs its own records, separate from staff completion rates.
- All users, not only employees: 5 CFR 930.301 covers contractors, students, guest researchers and visitors; DORA extends training to ICT third-party providers where appropriate; HIPAA's workforce includes volunteers and trainees under the entity's direct control.
- Specialised roles: security staff (GLBA 314.4(e)(3) and (4)), staff with significant security responsibilities (5 CFR 930.301) and developers (PCI DSS 6.2.2). These need role-based curricula, not the general module.
- AI system users: the AI Act extends literacy duties to anyone operating or using AI systems on the organisation's behalf, which can include contractors. See the EU AI Act AI Literacy Obligations (Article 4) Guide.
Key obligations
Content each regime names
| Topic | Named in | How to cover it |
|---|---|---|
| Social engineering and phishing | NYDFS 500.14(a)(3); PCI DSS 12.6.3.1; NIST SP 800-53 AT-2(3) | Annual module plus simulations; include voice and help desk pretexts |
| Malicious software | HIPAA 164.308(a)(5)(ii)(B) | Procedures for guarding against, detecting and reporting malware |
| Log-in monitoring and passwords | HIPAA 164.308(a)(5)(ii)(C) and (D) | How to report unusual sign-in prompts; password and MFA practice |
| Basic cyber hygiene | NIS2 Art. 21(2)(g) | Updates, MFA, reporting, data handling, safe remote working |
| Digital operational resilience | DORA Art. 13(6) | Role-scaled modules on ICT incidents, continuity and third-party risk |
| ICT risk oversight for management | NIS2 Art. 20(2); DORA Art. 5(4) | Board briefings and tabletop exercises with records of attendance |
| Acceptable use | PCI DSS 12.6.3.2 | Acknowledgement of acceptable use policies for end-user technologies |
| Secure development | PCI DSS 6.2.2 | Language and tool-specific secure coding for developers |
| AI literacy | EU AI Act Art. 4 | Capabilities, limits and risks of the AI tools staff use; safe data handling |
| Risk-based updates | NYDFS 500.14(a)(3); GLBA 314.4(e)(1) | Refresh content after each risk assessment |
Timing rules
- Before access: 5 CFR 930.301 for new federal employees; NIST SP 800-53 AT-3 for role-based training. PCI DSS requires training on hire.
- Annual: NYDFS (minimum), 5 CFR 930.301 (awareness at least annually), PCI DSS (at least every 12 months for personnel and developers).
- Event-driven: 5 CFR 930.301 on significant system change or a move into a role needing more training; NIST AT-2 and AT-3 when required by system changes; NYDFS and GLBA when the risk assessment changes.
- Not fixed: NIS2, DORA, HIPAA, GLBA and the AI Act. Document your chosen frequency and why it fits the risk.
Evidence auditors ask for
- Individual records: who completed what and when, retained for a defined period (NIST SP 800-53 AT-4).
- Role mapping: a list of roles with their required modules, tied to HR and access data.
- Board records: dates, attendees and content of management body training for NIS2 and DORA.
- Content review: evidence the programme was reviewed and updated against the risk assessment (NYDFS, GLBA, PCI DSS 12.6.2).
- Third-party coverage: contract clauses and attestations for contractors and ICT providers in scope.
Timeline and current status
| Date | Development |
|---|---|
| 14 December 2022 | DORA and NIS2 adopted |
| 17 October 2024 | NIS2 transposition deadline |
| 17 January 2025 | DORA applies |
| 2 February 2025 | EU AI Act Article 4 AI literacy applies |
| 31 March 2025 | PCI DSS v4.0 future-dated requirements, including 12.6.3.1, become mandatory |
| 27 July 2026 | Digital Omnibus on AI enters into force, recalibrating AI Act Article 4 (Lewis Silkin and KI-Campus summaries) |
Watch national NIS2 laws, which can set specific board training content or frequency, and Commission guidance on the amended AI Act Article 4.
Enforcement and penalties
- NIS2: breaches of Article 21 can attract fines with a maximum of at least EUR 10 million or 2% of worldwide turnover for essential entities, and at least EUR 7 million or 1.4% for important entities (Art. 34).
- DORA: penalties set by Member States and applied by competent authorities.
- HIPAA: HHS Office for Civil Rights resolution agreements and civil money penalties; missing training is a common finding.
- NYDFS: consent orders and penalties, and training is part of the annual compliance certification.
- GLBA Safeguards Rule: enforced by the FTC.
- PCI DSS: contractual, through acquirers and card brands, assessed in the Report on Compliance.
Choosing one programme for several regimes
This section and the compliance steps below are NHI Mgmt Group recommendations, not legal requirements.
Most organisations fall under more than one row of the table above. A bank with EU and New York operations is under DORA and NYDFS and probably PCI DSS; a US health insurer under HIPAA and the GLBA Safeguards Rule. Building separate programmes per regime wastes effort and produces conflicting records. The better pattern is a common core with regime-specific overlays.
| Organisation profile | Core programme | Overlays to add |
|---|---|---|
| Small firm under one regime (for example a GLBA-covered lender) | Annual awareness with phishing content, refreshed after the risk assessment | Training plan for the qualified individual and any outsourced security provider |
| EU financial entity | Annual awareness on hire and yearly; role-scaled modules | DORA operational resilience modules, management body training records, ICT provider coverage |
| NIS2 essential or important entity | Cyber hygiene module for all staff | Management body training under the national law, with content on risk management oversight |
| Card-processing merchant or service provider | Training on hire and every 12 months with phishing and acceptable use | Developer secure coding track; annual programme review evidence |
| US federal contractor | Awareness before access and at least annually | Role-based tracks for significant security roles; contract flow-down to subcontractors |
Trade-off: a single annual cycle is easy to evidence but invites box-ticking; shorter, more frequent modules tied to real incidents improve reporting behaviour but need a learning platform that keeps clean records. Large organisations should automate assignment from HR and identity data; small ones can run the same logic from a spreadsheet, provided the evidence is kept.
Where identity fits
Training duties attach to people, but the risks they address are increasingly identity attacks: help desk resets, MFA fatigue, OAuth consent phishing and leaked API keys. Two identity points make the programme auditable. First, drive assignments from the identity governance system, so that a new privileged role triggers its role-based module before the entitlement is granted, as AT-3 expects. Second, cover the people who create and hold machine credentials: developers, platform engineers and AI tool users need training on secrets handling and on what they may paste into AI assistants. See the Vishing and Help Desk Social Engineering Awareness Guide and the Secrets Management Guide.
Compliance steps
- Build the requirements register. List each regime that applies by legal entity, with trainee groups, named content, frequency and evidence.
- Set the floor to the strictest rule. Training on hire or before access, then at least annually, with social engineering content, covers NYDFS, PCI DSS and 5 CFR 930.301 at once.
- Add role-based tracks. Board, security staff, developers, privileged administrators, help desk and AI tool users. See the Role-Based Security Training Programme Guide.
- Link to access. Make role-based completion a condition of privileged access provisioning.
- Refresh after risk assessment. Update content when the risk assessment or threat picture changes, and record the change.
- Extend to third parties. Put training requirements and evidence in contracts for contractors and ICT providers.
- Test it. Run phishing simulations and a board tabletop each year. See the Phishing Simulation Programme Guide.
Metrics that show it is working
- Completion by deadline: percentage of staff trained on time, by regime and legal entity.
- Before-access compliance: percentage of privileged grants where role-based training was completed first.
- Board coverage: percentage of management body members with training recorded in the last 12 months.
- Reporting rate: share of simulated and real phishing reported by staff, and median time to report.
- Content currency: days since the last content update against the last risk assessment.
Common failure patterns
- One module for everyone: it meets awareness duties but not DORA's role scaling, GLBA's security staff training or PCI DSS developer training.
- Board left out: management bodies are exempted by habit, which now fails NIS2 and DORA directly.
- Training after access: privileged access on day one with training months later fails 5 CFR 930.301 and AT-3.
- No records for contractors: outsourced help desks and developers are trained by the supplier with no evidence held.
- Stale content: the module was not updated after the risk assessment, which NYDFS and GLBA both require.
Framework mapping
| Theme | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | NIST SP 800-171 Rev. 3 | ISO/IEC 27001:2022 |
|---|---|---|---|---|
| Awareness for all users | PR.AT-01 | AT-2 | 03.02.01 | Annex A 6.3 |
| Social engineering training | PR.AT-01 | AT-2(3) | 03.02.01 | Annex A 6.3 |
| Role-based training | PR.AT-02 | AT-3, AT-3(3) | 03.02.02 | Clause 7.2 |
| Training records | PR.AT-02 | AT-4 | 03.02.02 | Clause 7.2 |
For the CIS Controls view, see the CIS Control 14 Security Awareness and Skills Training Guide.
Practitioner checklist
- Keep a register of training duties per legal entity, with trainee groups, content, frequency and evidence.
- Train on hire or before access, then at least annually, with social engineering content.
- Record management body training separately for NIS2 and DORA.
- Run role-based tracks for security staff, developers, privileged administrators, help desk and AI tool users.
- Gate privileged access on completion of the relevant role-based module.
- Update content after each risk assessment and keep the change record.
- Include contractors and ICT providers by contract, with attestations.
- Retain individual training records for a defined period.
Standards and references
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- EUR-Lex: Regulation (EU) 2022/2554 (DORA)
- EU AI Act: Article 4 AI literacy
- Lewis Silkin (secondary): The Digital Omnibus on AI enters into force
- 45 CFR 164.308: Administrative safeguards (HIPAA)
- 23 NYCRR 500.14: Monitoring and training
- 16 CFR 314.4: Elements (GLBA Safeguards Rule)
- 5 CFR 930.301: Information systems security awareness training program
This guide summarises mandated security awareness and training requirements as of 12 November 2026 and is not legal advice. Related NHI Mgmt Group resources: Role-Based Security Training Programme Guide · Security Awareness and Human Risk Management Guide · NIS2 Directive Guide · DORA Guide · PCI DSS 4.0 Guide