CIS Control 14 Security Awareness Training Guide

Most organisations can prove that staff clicked through an annual module, but few can prove that the training covers what CIS Control 14 actually asks for or that it reaches the people attackers target. This guide is the implementation page for Control 14 (Security Awareness and Skills Training) of the CIS Critical Security Controls v8.1. It covers the nine Safeguards with their Implementation Groups, the timing rules CIS writes into them, how the Control applies to the people who create and look after service accounts, API keys and AI agents, and the evidence an assessor will ask for. It is for awareness leads, IT managers and GRC teams. For programme design, human risk scoring and culture, read the Security Awareness and Human Risk Management Guide; for the view across all 18 Controls, read the CIS Controls Guide.

Key takeaways

Eight of nine Safeguards are IG1. Every organisation, however small, is expected to run a programme (14.1) and cover seven named topics (14.2 to 14.8). Role-specific training (14.9) starts at IG2.
The timing is fixed. Train at hire and at least annually, and review the content at least annually or after significant change. The CIS Assessment Specification fails 14.1 if the content review is more than twelve months old.
Each topic is assessed separately. The Assessment Specification expects a module per Safeguard and measures initial and up-to-date completion for each, so one generic course is hard to evidence.
Reporting is the behaviour that pays. Safeguards 14.6 and 14.7 ask staff to report incidents and broken security tooling; the NCSC advises measuring how many people report a phish, not only who clicked.
Machine credentials need trained humans. Developers, platform engineers and administrators create most API keys, tokens and service accounts, so 14.3 and 14.9 should cover secrets handling, not only passwords and MFA.

What it is and who it applies to

CIS defines Control 14 as establishing and maintaining a security awareness program to influence behaviour among the workforce to be security conscious and properly skilled to reduce cybersecurity risks to the enterprise. The CIS rationale is blunt: it is easier for an attacker to entice a user to click a link or open an attachment than to find a network exploit, and users also cause incidents by sending sensitive data to the wrong recipient, losing devices or reusing passwords. CIS also notes that risk differs by role: executives handle more sensitive data, administrators control access to systems, and finance, HR and contracts staff are targeted for the data they hold.

"Workforce" in the Assessment Specification means everyone on the workforce list, so contractors and temporary staff with enterprise accounts are in scope as well as employees. The Control has no technical asset type: it is about people, which is why all nine Safeguards carry the Protect security function.

Small organisations (IG1): an induction module and an annual refresher covering the seven IG1 topics, a simple way to report suspicious messages, and a completion list kept by the IT lead or an off-the-shelf platform will meet 14.1 to 14.8.
Mid-sized organisations (IG2): add role-specific training under 14.9 for administrators, developers, help desk, finance and executives, and link completion data to the HR or identity system so leavers drop off and joiners are enrolled automatically.
Large or regulated organisations (IG3): Control 14 has no IG3-only Safeguards. Maturity shows in measurement: behaviour metrics, targeted interventions and evidence that training changes outcomes, as NIST SP 800-50 Rev. 1 expects.

CIS states that v8.1 did not change Implementation Group assignments, so the levels below hold for v8 and v8.1. Note one discrepancy: the published Assessment Specification page for 14.9 lists Implementation Groups 1, 2 and 3, while CIS's own Implementation Group assignment places 14.9 in IG2. This guide follows CIS's assignment; IG1 organisations lose nothing by doing basic role training anyway.

Structure and key requirements

Titles are as CIS publishes them; the requirement column summarises the Safeguard text in the CIS Controls Assessment Specification.

Safeguard	Title	IG	What it requires
14.1	Establish and Maintain a Security Awareness Program	IG1	A programme to educate the workforce to interact with enterprise assets and data securely; training at hire and at a minimum annually; content reviewed annually or after significant enterprise change
14.2	Train Workforce Members to Recognize Social Engineering Attacks	IG1	Recognising social engineering such as phishing, pretexting and tailgating
14.3	Train Workforce Members on Authentication Best Practices	IG1	Example topics: MFA, password composition and credential management
14.4	Train Workforce on Data Handling Best Practices	IG1	Identifying, storing, transferring, archiving and destroying sensitive data; clear screen and desk, such as locking screens and erasing physical and virtual whiteboards
14.5	Train Workforce Members on Causes of Unintentional Data Exposure	IG1	Example topics: mis-delivery of sensitive data, losing a portable device, publishing data to unintended audiences
14.6	Train Workforce Members on Recognizing and Reporting Security Incidents	IG1	Recognising a potential incident and being able to report it
14.7	Train Workforce on How to Identify and Report if Their Enterprise Assets are Missing Security Updates	IG1	Verifying and reporting out-of-date patches or failures in automated processes and tools, including notifying IT
14.8	Train Workforce on the Dangers of Connecting to and Transmitting Enterprise Data Over Insecure Networks	IG1	Risks of insecure networks; where there are remote workers, guidance to securely configure home network infrastructure
14.9	Conduct Role-Specific Security Awareness and Skills Training	IG2	Examples: secure system administration for IT professionals, OWASP Top 10 awareness for web developers, advanced social engineering awareness for high-profile roles

Turning the topics into content

Safeguard	Content that makes it concrete	Technical control that should back it
14.2	Phishing, smishing, voice and video impersonation, QR codes, MFA push fatigue, OAuth consent prompts, physical tailgating	Email filtering, phishing-resistant MFA, consent policies (Control 9 and Control 6)
14.3	Password managers, length over complexity, never approving unexpected MFA prompts, never sharing codes, where API keys and tokens may and may not be stored	Password blocklists and length rules (Safeguard 5.2), secrets scanning
14.4	Classification labels, approved transfer and storage locations, disposal, screen locking, AI tool data rules	Data classification and DLP (Control 3)
14.5	Autocomplete mis-sends, public sharing links, lost devices, pasting data into public AI tools	Link-sharing defaults, device encryption, recall and DLP policies
14.6	What counts as an incident, the report button, the phone number for urgent cases, reporting after a mistake without blame	Report message add-in, triage mailbox, incident process (Control 17)
14.7	Recognising stale update prompts, a disabled antivirus icon or a failing backup agent, and who to tell	Patch and endpoint compliance reporting (Controls 7 and 10)
14.8	Public Wi-Fi risks, VPN use, changing default router passwords and updating router firmware at home	Always-on VPN or zero trust access, device firewall

The principle from the NCSC is that training "can't teach everyone to spot all phishing emails", so every topic above should pair training with a technical control. Training covers what technology cannot block, and it tells people what to do when technology fails.

Identity and NHI requirements

Control 14 is written about people, but people create and handle most machine credentials. A developer pasting an API key into a chat channel, a platform engineer committing a cloud access key, or an administrator approving an OAuth app for a whole tenant are all failures that awareness can reduce. Fold these points into the existing Safeguards rather than inventing a separate track.

14.3 Authentication best practices: extend "credential management" to secrets. Staff should know that API keys, personal access tokens and service account passwords belong in the approved vault, never in code, tickets, wikis, chat or AI prompts, and that a leaked key must be reported and rotated, not just deleted. See the Secrets Management Guide.
14.2 Social engineering: include consent phishing, where an attacker asks a user to grant an app access instead of entering a password, and device code phishing. Microsoft Defender for Office 365 attack simulation training includes an OAuth Consent Grant technique for this purpose. See the Consent Phishing and Illicit OAuth Grants Guide.
14.9 Role-specific training: help desk staff need identity verification procedures that a caller cannot pass with information from LinkedIn; in the MGM Resorts breach the attackers found an employee on LinkedIn and then called the help desk. Developers and DevOps engineers need secrets hygiene, least privilege for CI/CD tokens and how to request a managed identity instead of a static key. Administrators need training on separate admin accounts and on not using service accounts interactively. See the Account Recovery and Help Desk Security Guide.
AI agents and assistants: staff who build or approve AI agents grant those agents credentials and permissions. Cover what data and access an agent may be given, and who must approve it, in the role training for those builders. See the Insider Risk from AI Tools Guide.

Training non-human identity owners also makes Control 5 work: the quarterly service account review in Safeguard 5.5 depends on owners who understand why an unused key matters. See the CIS Control 5 Account Management Guide.

Implementation steps

Define the workforce list. Take the population from HR plus contractors with enterprise accounts. This is the denominator for every metric the Assessment Specification uses, so agree it with HR and identity teams first.
Write the programme document (14.1). State scope, owner, audiences, topics mapped to 14.2 to 14.9, delivery cadence (at hire, annual, ad hoc), the annual content review date and how completion is recorded. NIST SP 800-50 Rev. 1 gives a four-phase life cycle (Plan and Strategy, Analysis and Design, Development and Implementation, Assessment and Improvement) that fits this document.
Build or buy modules per Safeguard. Make each of the seven IG1 topics an identifiable module or a tagged section, so completion can be shown per Safeguard. Keep modules short; NIST SP 800-50 Rev. 1 supports ongoing awareness throughout the year rather than one long annual course.
Automate enrolment. Connect the learning platform to the identity provider or HR system so new joiners are enrolled on day one (the "at hire" requirement) and leavers drop out of the denominator.
Make reporting easy (14.6). Deploy a single report button in the mail client, publish one phone number for urgent cases, and give reporters feedback. The NCSC recommends a process that is "clear, simple and quick to use".
Pilot simulations carefully. If you run phishing simulations, agree the approach with HR first, as the NCSC advises, start with a small group, and measure reports as well as clicks. See the Phishing Simulation Programme Guide.
Add role tracks (14.9). Start with the roles with the most power or exposure: administrators, help desk, developers, finance and executives. Use existing frameworks for content: OWASP Top 10 for web developers, as CIS suggests, and the Security Awareness Plan Template for scheduling.
Review annually and after change. Record the review date and what changed. Trigger an out-of-cycle review after a significant incident, a merger, a new remote working model or a new attack pattern such as deepfake calls.

Rollback and pacing: if a simulation campaign causes complaints or floods the service desk, pause it, communicate openly and narrow the audience. A programme that staff resent loses the reporting behaviour it exists to build; the NCSC warns that employees who are afraid for their jobs will not report mistakes.

Decision guidance

Choice	Option A	Option B	When to pick which
Content source	Commercial platform library	In-house modules	Platforms cover 14.2 to 14.8 quickly; in-house content is better for 14.9 role tracks and your own reporting process. Most organisations blend both.
Delivery	One annual course	Short modules through the year	Annual meets the minimum; frequent short modules sustain behaviour and give more data points.
Simulations	Regular organisation-wide campaigns	Targeted or no simulations	Not required by Control 14. Use where HR agrees and you measure reporting; skip in favour of reporting drills where culture is fragile.
Follow-up on a click	Automatic remedial training	Coaching and technical guardrails	Use short just-in-time feedback; repeated failures point to a control gap, not a training gap.

For product selection criteria, see the Security Awareness Training Buyer's Guide.

Evidence and assessment

The CIS Controls Assessment Specification uses the same pattern for every Safeguard in Control 14: it first checks that the programme or module exists (a missing one is an automatic fail), then measures the percentage of the workforce that has completed initial training and the percentage whose most recent completion is within twelve months. For 14.1 it also fails the Safeguard if the last content review is more than twelve months old.

Safeguard	Evidence an assessor expects	KPI
14.1	Approved programme document; workforce list; completion export with dates; record of the last content review	Workforce with initial training; training within 12 months; months since content review (under 12)
14.2 to 14.8	Module or section per topic with a syllabus; per-module completion dates for each workforce member	Per-module initial and up-to-date completion rates
14.6	Reporting procedure; report button deployment; volume of user reports and outcomes	Reporting rate in simulations or real campaigns; median time from delivery to first report
14.7	Module content; service desk tickets raised by users about failed updates or disabled tools	User-raised tickets about security tooling failures
14.9	List of roles with required tracks; enrolment rules; completion by role	Role-holders current on their track (for example administrators, developers, help desk)

Measuring whether it works

Coverage: per-Safeguard completion is what the Assessment Specification scores, so track it monthly and chase gaps by department.
Behaviour: phishing report rate, time to first report, and credential submission rate in simulations. Microsoft Defender for Office 365 attack simulation reports, for example, show who reported, who entered credentials and who completed assigned training.
Outcomes: count incidents with a human entry point (phishing, help desk impersonation, mis-sent data) and secrets leaked by staff, and watch the trend after each campaign.
Detection link: user reports should flow into the SOC queue. Map reported lures to ATT&CK T1566 Phishing (T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link), T1598 Phishing for Information and T1621 Multi-Factor Authentication Request Generation so that awareness data enriches detection.

Mapping to other frameworks

Control 14 area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Programme and general awareness (14.1, 14.3 to 14.5, 14.8)	AT-2 Literacy Training and Awareness	PR.AT-01	A.6.3 Information security awareness, education and training
Social engineering (14.2)	AT-2(3) Social Engineering and Mining	PR.AT-01	A.6.3
Clear desk and screen (14.4)	AT-2	PR.AT-01	A.7.7 Clear desk and clear screen
Incident reporting (14.6, 14.7)	AT-2, IR-6 Incident Reporting	PR.AT-01	A.6.8 Information security event reporting
Role-specific training (14.9)	AT-3 Role-based Training, PM-13 Security and Privacy Workforce	PR.AT-02	A.6.3
Training records (all)	AT-4 Training Records	PR.AT-01, PR.AT-02	A.6.3

The CIS Controls Navigator holds the authoritative mappings; check them there before an audit. See the Control Mapping Guide.

Common pitfalls

One generic course for everything: it may touch phishing and passwords but skip 14.7 (reporting missing updates) and 14.8 (home networks), and it cannot show per-Safeguard completion.
A stale programme: content last reviewed two years ago fails 14.1 outright, however high completion is. Put the review date in the programme document and the GRC calendar.
Contractors left out: third-party staff with enterprise accounts are often outside the learning platform. In the Uber 2022 breach an attacker used a contractor's password and MFA fatigue to get in.
Click rate as the headline: click rates move with the difficulty of the lure. Report rates and time to report show whether staff are acting as an early warning system.
Punishing mistakes: named shaming or disciplinary threats reduce reporting, which is the behaviour 14.6 exists to build.
No developer track: without 14.9 content on secrets, engineers keep committing keys and tokens. See the Top 10 Secrets Management Mistakes.

Practitioner checklist

Agree the workforce list, including contractors, as the denominator for all metrics.
Publish a programme document that maps content to Safeguards 14.2 to 14.9 and records an annual review date.
Enrol joiners automatically at hire and require refresher completion at least every twelve months.
Keep an identifiable module or section, with completion dates, for each IG1 topic.
Deploy one report button and one urgent phone route, and give reporters feedback.
Cover secrets, tokens and OAuth consent in authentication training, not only passwords.
Run role tracks for administrators, help desk, developers, finance and executives.
Report reporting rate, time to report and per-Safeguard completion to leadership.
Pair each training topic with a technical control so training is never the only defence.

CIS Control 14 Security Awareness and Skills Training Guide: Safeguards, Implementation Groups and Evidence