What ISO/IEC 27001, PCI DSS, HIPAA and NIST CSF Actually Ask of Security Awareness Training

Ask an auditor what a security awareness programme needs and you’ll rarely hear “this course” or “that many hours”. The frameworks people work with ask for outcomes: people who know their responsibilities, recognise the threats aimed at them and know what to do. That gives organisations freedom — and makes it easy to buy a course, run it once a year and miss the point.

What the frameworks ask for

ISO/IEC 27001:2022 asks for it twice. Clause 7.3 requires people working under the organisation’s control to be aware of the information security policy, their contribution to the management system and what happens if they don’t conform. Annex A control A.6.3 covers awareness, education and training suited to each person’s role, with regular updates as policies and procedures change. Auditors usually look for a training plan, role-based content and records.

PCI DSS v4.0.1 puts a formal security awareness programme under Requirement 12. Everyone gets it on joining and at least once a year, and since March 2025 it must cover phishing and related social engineering.

HIPAA’s Security Rule requires a security awareness and training programme for the whole workforce, including management (45 CFR 164.308(a)(5)). Its implementation specifications — security reminders, protection from malicious software, log-in monitoring and password management — are “addressable”. That means you decide how to meet each one based on your risk analysis and document the decision; it doesn’t mean optional.

NIST CSF 2.0 has two subcategories under Awareness and Training: PR.AT-01 for everyone, so they can do general tasks with cybersecurity risk in mind, and PR.AT-02 for people in specialised roles, such as administrators, developers, finance staff and senior leaders. NIST’s SP 800-50 Rev. 1 (September 2024) explains how to build a learning programme around them and how to measure it.

The GDPR doesn’t require a course as such, but it lists awareness-raising and training of staff among a data protection officer’s tasks (Article 39(1)(b)), and training is part of the “appropriate technical and organisational measures” controllers must be able to show.

What auditors look for

Across all of them, the evidence that holds up is much the same:

• A plan tied to risk. Topics chosen because of the threats you face and the incidents you’ve had, not a generic catalogue.
• Role-based content. Finance teams need to recognise payment fraud; developers need secure coding; administrators need to protect privileged access.
• Timing. On joining, at intervals, and when something changes, such as a new system, a new policy or a new kind of attack.
• Records. Who completed what and when, and what happens when someone doesn’t.

Measure behaviour, not attendance

A 98% completion rate shows that people clicked through a course. It doesn’t show they will spot the next fake invoice. Better measures include:

• Reporting rate: how many people report a suspicious email or call.
• Time to report: how quickly the first report arrives after a real or simulated attack begins. Early reports let the security team act before others are caught.
• Repeat incidents: whether the same kind of mistake keeps happening in the same team.

The UK National Cyber Security Centre makes the point plainly: blaming people who make mistakes discourages them from reporting, which is the behaviour you most want. A no-blame approach, with quick and visible action on reports, does more for security than a stricter exam.

Where to start

If you have a single annual course and nothing else, three changes make the biggest difference. Add short, role-based modules for the teams attackers target most. Make reporting a one-click action and thank people who use it. And start tracking reporting rates alongside completion, so you can show an auditor — and yourself — whether the programme changes anything.