CIS Safeguard 14.2 social engineering training evidence and audit

What social engineering awareness training must show under CIS 14.2

An assessor checking Safeguard 14.2 will ask one question first: can you show that your workforce has been trained to recognize social engineering, and that the training is still current? The Safeguard names phishing, business email compromise, pretexting and tailgating as the attacks people must learn to spot. For a compliance lead or engineer, that means the proof has to cover two things: a training module that addresses these attacks, and records showing which workforce members completed it and when. The CIS Controls Assessment Specification scores the Safeguard on exactly those points, measuring initial training compliance and whether training is up to date across the workforce.

The requirement is harder in practice than it looks, and it usually fails for one of two reasons. The first is training that is delivered but never recorded, such as a lunch session or a slide deck emailed to staff with no completion data kept anywhere. The second is phishing simulations run without a training module behind them. The assessment specification treats a missing training module on recognizing social engineering as a failing score, so a simulation report on its own does not close the gap. Before anything else, confirm that you have a written module covering all four attack types, and that your learning platform can export per-person completion dates for every workforce member, including contractors where they are in scope.

Safeguard 14.2 sits in Implementation Group 1, the essential cyber hygiene baseline, so it applies to every enterprise regardless of size or sector. Small teams sometimes assume it is optional until they grow, but the Safeguard carries no prerequisite safeguards for measurement, which means it can be evidenced on its own from the start. A practical first step is to name an owner for the module, set a recurring cycle for refreshing it, and agree on the report format the assessor will receive. If you plan to build the training on an open-source learning platform, the Moodle activity completion documentation explains how completion is recorded, which you should test against your own completion requirements before relying on it as evidence.

Which people, channels and third parties fall under social engineering training

Safeguard 14.2 is short, but the population and channels you choose determine how much training you build, who must complete it and what evidence an assessor will ask for. The cards below cover the scoping decisions that most often change the work, and they show where the same training records can also support the NIST SP 800-53, ISO/IEC 27001:2022 and PCI DSS mappings.

Workforce members, including contractors

The safeguard reaches the enterprise workforce, not only employees on payroll. Contractors, temporary staff, part-time staff and interns with access to enterprise systems or data are candidates for the same training. Decide the definition in writing, then tie it to the identity system so new accounts trigger enrollment. Check that the population in the training platform matches the population in the directory, because an assessor measuring Initial Training Compliance will compare the two.

Payment and finance roles

Staff who approve payments, change supplier bank details or process invoices are the typical targets of business email compromise. Treat them as a distinct cohort with scenario-based content, such as a fake change of bank details, and consider a shorter refresh cycle for them. Ask finance leads which workflows can move money without a second approval, because those workflows define what the training must teach.

Executive and assistant communications

Executive assistants, board secretaries and anyone who sends messages on behalf of senior leaders face impersonation and pretexting. Include them explicitly, since leadership is often excluded from mandatory modules. Your content should cover urgent requests for gift cards, document sharing and wire transfers. Confirm with the executive office how requests normally arrive so the training uses realistic patterns from your own environment.

Channels in scope

Safeguard 14.2 names social engineering in general, so the training should cover more than email. Decide whether phone calls, text and chat messages, collaboration platforms and in-person approaches such as tailgating are included. Each channel changes the content and the simulations you can run. Phishing simulations test email only, so physical and voice scenarios need their own exercises or documented procedures, and the training record should state which channels were covered.

Third parties with access

Decide whether vendors, managed service staff and offshore support teams with credentials or access to enterprise mail are in scope. If they are, their training must be contractual or evidenced by the provider, and you need to ask for their completion records. Reliance on a provider's training should be recorded in the service provider inventory, so the enterprise can show who was covered and by what means.

Reusing evidence for other frameworks

The same completion records and simulation results can support mappings to NIST SP 800-53 Rev. 5 control AT-2(3), ISO/IEC 27001:2022 Annex A control 8.7 and PCI DSS v4.0 requirement 12.6.3.1, as the CIS Controls Navigator lists them. Confirm each mapping against the current text of the target framework before relying on it, because the mapping shows relationship, not equivalence. Your assessor, not CIS, decides whether the evidence satisfies a given requirement.

How an assessor scores social engineering training under the CIS assessment specification

This table compares the two metrics the CIS Controls Assessment Specification uses for Safeguard 14.2, the failing condition, the evidence an assessor will ask for and the findings that most often cause trouble. Read it as a checklist of what to prepare before an assessor samples your workforce records.

Element	What the specification measures	Evidence an assessor expects	Common finding
Social engineering training module	Whether the enterprise has a training module that covers recognizing social engineering, which is the failing condition if absent	Current module content covering phishing, business email compromise, pretexting and tailgating, with a version or review date	No module exists, or the module covers only malware and passwords
Initial Training Compliance	The share of workforce members that have received initial training on social engineering	Completion records per person, matched against the current workforce roster, with dates	Contractors, temporary staff or new joiners missing from the records
Up to Date Training	The share of compliant workforce members whose training is current under the enterprise's own refresh cycle	Dates of most recent completion per person and the refresh rule the enterprise has documented	Completions older than the enterprise's own refresh rule, with no reminder or escalation
Completion tracking	Whether completions are recorded in a way that can be reproduced and sampled	Exported learning platform reports with timestamps, plus the rule that defines a completion	Completions marked manually, or recorded only in a spreadsheet with no audit trail
Content currency	Whether the training reflects current social engineering techniques used against the enterprise	Dated content reviews and change history for the module	Content unchanged for years, with examples that no longer match current lures
Simulation results	Phishing simulations are commonly offered as supporting evidence of the training, but the specification scores completion and currency	Simulation design, scope, results and the follow-up training assigned to people who clicked	Simulation results presented without linking them to completion records
Scope of the assessor's review	The specification defines what to measure, not how. The assessor chooses the sample and draws the conclusion	Ask the assessor which sample method and population they will use before fieldwork	Preparing evidence for the wrong population or time window

How to build a social engineering training program that passes the 14.2 measures

This sequence turns Safeguard 14.2 from a policy statement into a training module, delivery record and review cycle that an assessor can trace from the Safeguard to the completion data. Each step ends with an artifact you can hand over.

Define scope, owners and the workforce population
Name the executive sponsor, the training owner and the people who maintain the learning platform, and state which workforce members are in scope, including employees, contractors and any other users with enterprise accounts. Confirm the population against the identity directory so the denominator used for the measures matches who actually has access. The output is a short training standard that lists owners, the in-scope population and where completion records are kept.
Build the social engineering training module
Write one module that covers the attack types named in Safeguard 14.2: phishing, business email compromise, pretexting and tailgating. For each, explain how it appears in your organization, what a legitimate request looks like, and the reporting step staff should take. The output is a versioned module with its learning objectives, content and a knowledge check, and a record showing who approved it. Without this module, the assessment specification scores the Safeguard as failing.
Set delivery and completion rules
Decide when each workforce member must complete the module, including initial training for new joiners, and how completion is defined in the learning platform. Moodle's activity completion, for example, can mark an activity complete when a learner views it, receives a grade, or ticks it manually, so choose the condition that proves the learner actually engaged with the content. The output is a written completion rule and the platform configuration that enforces it, with a screenshot or export as evidence.
Run phishing simulations as reinforcement
Schedule simulated phishing campaigns that test what staff learned, and use the results to target follow-up coaching rather than to replace the training module. Simulations support the phishing element of the program but do not, on their own, establish the initial training measure. The output is a campaign calendar, the message templates used, and a record of which groups received which content.
Record completions and failures
Export completion status for every in-scope user and keep a dated record of who has finished initial training and who is current under the recurring cycle. Record simulation failures and the follow-up action taken, and keep them separate from the training completion record so each can be audited. The output is a reconciled completion report that you can compare against the identity directory population from the first step.
Review content on a fixed cycle
Set a review cadence for the module and the simulation templates, and update them when attack patterns, internal processes or tooling change. Record each review with its date, reviewer and changes made, so the assessor can see the program is maintained rather than delivered once. The output is a review log and a current module version that matches the training standard.

Evidence that passes the social engineering training measures

The CIS assessment specification scores Safeguard 14.2 on the share of workforce members who received initial training and the share who remain up to date. The cards below are the records that let an assessor rebuild those percentages from your own data, plus the content evidence showing the training covers social engineering.

Approved social engineering training module

This is the course itself: the slides, scripts, videos or interactive modules that teach staff to recognize phishing, business email compromise, pretexting and tailgating. Assessors look for a module that exists and that names social engineering explicitly, because a missing module is a failing score under Safeguard 14.2. Record the version number and the approver for each release, and confirm that the module still matches how your organization actually receives requests, such as payment changes or password resets. Review it when attack patterns or internal processes change, not only at the annual cycle.

Workforce roster with roles and start dates

The denominator for both metrics is the full population of workforce members, so the roster must be complete. Include employees, contractors and other people who access enterprise systems, each with a role and a start date. The start date determines when initial training was due. Export the roster from the system of record, such as the HR or identity platform, and reconcile it against training records each month. Gaps in the roster are the most common reason percentages fail to reproduce during an assessment.

Completion records with dates

Completion records show who finished the module and when. They are the numerator for Initial Training Compliance and the basis for Up to Date Training. Keep the learning platform's timestamps, the module version completed and the user identifier that links each record to the roster. Moodle, for example, can mark an activity complete when a learner views it, receives a grade or ticks it manually, depending on the conditions set. Confirm which condition your course uses, because a view-based completion proves less than a graded assessment.

Population-level metric calculations

Assessors check the arithmetic, so keep a written calculation for each metric: the count of workforce members, the count who completed initial training, and the count whose training is current on the assessment date. Show the formula, the date range and the source of each count. Store the query or spreadsheet used to produce it, so the same numbers can be regenerated later. Run the calculation from the roster and completion records rather than from a manually maintained tally.

Phishing simulation reports and follow-up

Phishing simulations do not satisfy Safeguard 14.2 on their own, but they show whether the training changes behavior and they surface people who need more instruction. Keep campaign dates, templates covering social engineering themes, click and report rates, and the list of users who received follow-up training. Record what you did with the results, such as targeted refresher modules. Confirm with your assessor which simulation evidence they want to see, since the specification centers on training completion.

Content review record

A content review record shows that the training stays accurate. Record the reviewer, the review date, the threats considered and any changes made, and link each change to a module version. Reviews should reflect current threat reporting and changes in your business processes, such as new payment approval steps. Keep the review record with the module so an assessor can see that the content was not frozen at launch.

How Moodle activity completion can produce the training record

Moodle can produce a usable training record for Safeguard 14.2 because its activity completion feature marks an activity complete for each learner when they view it, when they receive a grade from it, or when they tick it manually, depending on the conditions set for that activity. The defensible choice is which condition you set. For social engineering modules, requiring a graded quiz with a passing threshold is generally stronger than view-only completion, because a viewed page shows only that the learner opened it. Set completion tracking on the course, then set the completion conditions on each activity, and check the completion report for a test learner before any real cohort uses the course. Moodle's developer documentation on the activity completion API describes the underlying conditions, and the settings you choose should match what you tell an assessor you measure.

The platform cannot prove everything the assessment cares about. A completion flag does not verify that the person at the keyboard is the enrolled workforce member, so identity still depends on your directory and login controls. It also does not record which version of the module was delivered. If a phishing scenario or policy text changes, keep dated versions of the course content and tie each completion to the version it covered, for example by archiving an export of the course with its change history. Exceptions such as leave, contractors who joined late or learners who were granted a waiver also need a documented reason outside Moodle, since the platform only shows that a condition was or was not met.

Confirm the completion settings in your own installation before relying on them as evidence. Check the activity completion settings in each course, the grade-to-pass thresholds, whether completion is locked after it is achieved, and whether the completion report can be exported with the learner list and dates that the Initial Training Compliance and Up to Date Training metrics require. Ask your Moodle administrator or implementation partner to document these settings in a configuration record, and retain a sample export for the assessment period. Whether the completion report meets the measurement needs of your assessor is a question to put to that assessor, not something the platform settles.

What social engineering awareness training costs to meet

This table breaks the cost of meeting Safeguard 14.2 into its components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a written scope and to ask each vendor or partner the same questions before comparing quotes. No prices are given because none are supplied for this topic.

Cost component	One-time or recurring, and who is paid	What drives it, and what to request in a quote
Content development or licensing	Mostly one-time for the first module, then recurring for refreshes. Paid to an internal team, a content vendor or a training provider.	Drivers are the number of roles, languages and scenarios covered. Request the module outline, the source of scenarios, ownership of the content and the cost of each refresh.
Learning platform (open source versus commercial)	Open-source software has no license fee, but hosting, upgrades and administration recur. Commercial platforms charge recurring subscriptions. Paid to the platform vendor or to an operator.	Drivers are the number of learners, hosting model and support hours. Request the license terms for each option, the hosting and backup responsibilities, and the upgrade cadence.
Simulation tooling	Recurring, usually per campaign or per licensed user. Paid to a simulation vendor, or to staff who run an open-source tool.	Drivers are campaign frequency, number of mailboxes in scope and the number of pretexting or tailgating exercises. Ask whether phishing, BEC and in-person scenarios are included or priced separately.
Engineering or administrator time to configure reporting	One-time for the initial reporting build, with recurring effort to maintain it. Paid to internal staff or the implementation partner.	Drivers are the integration with the directory, the learning platform and the simulation tool. Request a written definition of the completion and click-rate data each report will produce.
Evidence upkeep	Recurring. Paid to the staff who export, store and review training and simulation records each cycle.	Drivers are the number of workforce members, the frequency of training cycles and whether records must be retained for each assessment period. Request the list of evidence artifacts and the retention rules.
External review of content and process	Optional and periodic. Paid to an independent reviewer or consultant.	Drivers are the complexity of the training program and whether the organization wants outside validation before an assessment. Request the reviewer's scope, deliverables and whether the review is advisory only.
Auditor sampling effort	Recurring with each assessment cycle. Paid to the independent auditor or assessor, not to the implementation partner.	Drivers are the sample size the auditor selects and how easily records can be pulled for each sampled user. Ask the auditor for its sampling method and the evidence format it expects before work begins.

Who owns the controls, who prepares the evidence and who issues the assessment

Your organization owns Safeguard 14.2 in full. The security awareness program is accountable to leadership, and the people who decide what staff learn about phishing, business email compromise, pretexting and tailgating must be employees with the authority to act on the results. Outside help can draft material, but it cannot own the program.

Policy and scope: Approve the awareness policy, define which workforce members are in scope (employees, contractors and temporary staff, where applicable) and set the cadence for training and simulations.
Workforce roster: Maintain the authoritative list of people, their roles and their status, since the Safeguard's metrics depend on the share of workforce members who have been trained.
Training content decisions: Choose which scenarios reflect your real threats, such as payment change requests or vendor impersonation, and approve the wording and any lures before they reach staff.
Response to failing simulations: Decide what happens to people who click or submit credentials, whether that means coaching, targeted retraining or escalation, and keep that response consistent with HR policy.

Confirm that a named owner signs off the program each cycle and that someone outside the security team reviews whether the content still matches current attacks.

Where social engineering training programs usually fall short

Most Safeguard 14.2 programs fail on records, not on content. An assessor looks for proof that every workforce member was trained, that the training covers social engineering, and that someone owns the roster. The cards below name the gaps that break that chain and the evidence that closes each one.

Training without recorded completion

Sessions run in a meeting room or a slide deck are often attended but never recorded. Under the CIS Controls Assessment Specification, Safeguard 14.2 is measured by the share of workforce members who have received initial training and the share who are up to date, so an unrecorded session counts for nothing. Put every module in a learning management system that stores a timestamped completion for each person. Check that you can export the list of who completed what and when. In Moodle, for example, activity completion can be set to mark an item complete when a learner views it, receives a grade, or ticks it manually, and the condition you choose determines what the record proves.

Simulations without a linked module

Phishing simulations generate clicks and reports, but they do not prove that a workforce member was taught to recognize social engineering. Safeguard 14.2 failing conditions include having no training module on the topic at all, so a simulation with nothing behind it leaves the requirement open. Link every simulation campaign to a short module that explains the lure it used, and record who was sent to that module after a failed click. Ask the vendor or tool whether it can export this link for an assessor.

Contractors and new hires left out

Programs often target employees on the payroll and miss contractors, temporary staff and people who joined mid-cycle. The assessment measures the share of workforce members trained, so a missing group lowers the score even when the core staff are complete. Define workforce membership in writing, tie account provisioning to the training assignment, and set a deadline for initial training that starts on the first day of access. Confirm with your assessor how they define workforce members for your environment.

Content that lags new attack patterns

A module written for classic bulk phishing may not cover business email compromise, pretexting over the phone, or tailgating at a badge door. Safeguard 14.2 names all of these, so the content should reflect each one. Assign an owner to review the module on a set cycle and after a notable incident or simulation trend. Keep a dated revision history so the assessor can see the content was current when people took it.

No record of failures and follow-up

Simulation results are often reported as an aggregate click rate, with no record of which individuals failed and what happened next. That gap matters because the training requirement is about people who are not yet competent, not only about averages. Keep a per-person record of failed simulations, the remedial training assigned, and its completion. Decide in advance whether repeated failures trigger a manager conversation or an access review, and document that rule.

No named owner for the roster

When no one is accountable for the training roster, completion data drifts out of date and nobody can answer an assessor's question about a specific person. The Safeguard 14.2 measures depend on a current, complete list of workforce members, so the roster needs a named owner who reconciles it against the HR and identity records. Schedule that reconciliation, keep the dated extracts, and make the owner the person who signs off the evidence pack. Confirm the owner's role with your own governance structure before the assessment begins.

Questions buyers ask before bringing in help for social engineering training

How much effort does social engineering training take to run in-house?

Most of the effort is recurring rather than a one-time build, so the question is whether your team can sustain it. Safeguard 14.2 is measured by whether workforce members have completed initial training and stay current on it, so someone must own the roster, the content, the schedule and the completion records every cycle. A small team can build a module once, but keeping it current, tracking completion across joiners, movers and contractors, and handling exceptions usually takes ongoing attention. Confirm with your own HR and security leads how many people will maintain it and how many hours per month that represents before deciding what to outsource.

Can a self-hosted open-source platform meet the social engineering training requirement?

A self-hosted platform can hold the training content, deliver it and produce the completion records that assessors ask for, provided it runs inside your own infrastructure and your records are kept under your control. Moodle, for example, has activity completion that marks an activity complete when a learner views it, receives a grade or ticks it manually, depending on the conditions you set. Because the Safeguard is about the training itself, the platform only needs to show who was trained, on what, and when. Confirm with your platform team that completion data can be exported and retained for the period your assessor will sample.

How long does preparation usually take, and what drives that time?

The timeline depends on how much content you already have and how many people must be enrolled. Preparation typically covers agreeing the scope of the module, writing or adapting content for your organization, configuring the platform, loading the roster and running a pilot before full rollout. Timelines also grow when HR records are inconsistent, when legal or works councils must review content, or when translations are needed. The most reliable way to size this is a written scope from a partner, followed by your own check of the dependencies listed above.

What does the work need from our organization?

Three things are needed from your organization before work starts: access to an accurate roster of workforce members, named content owners who can approve what the training says, and a sign-off authority who accepts the module and the evidence. Roster access matters because the measures depend on the share of workforce members trained, so contractors and new starters must be included in the source data. Content owners should cover security, HR and any business unit with specific fraud patterns, such as finance for business email compromise. Agree these roles in writing so approvals do not stall the schedule.

Does Safeguard 14.2 require phishing simulations?

No. Safeguard 14.2 asks that workforce members be trained to recognize social engineering attacks, naming phishing, business email compromise, pretexting and tailgating as examples. The Assessment Specification scores it on training completion and currency and fails it if there is no training module on recognizing social engineering. Phishing simulations are a common way to reinforce and evidence that training, and many organizations run them, but they are not the only acceptable method. Confirm with your assessor how they want the training evidenced in your environment before choosing a method.

What should a fixed-scope quote from a partner include?

A fixed-scope quote should name the deliverables, the assumptions behind them and the responsibilities on each side. Ask for the training modules to be built or adapted, the platform configuration, the roster integration, the completion reporting, the evidence pack for your assessor and the handover to your team. The quote should state what is excluded, such as translation, legal review or ongoing retainer support, and how changes to scope are priced. Make clear that the partner prepares systems and evidence while your organization owns the control and any independent auditor issues the assessment outcome. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that written scope.

How DeployOpen scopes and prepares social engineering training evidence

DeployOpen works on Safeguard 14.2 Social engineering awareness training as a fixed-scope engagement inside your own infrastructure and learning platform. We prepare the training system, content and records so your team can show initial training compliance and up to date training, while your organization keeps ownership of the control and the auditor issues any report.

How we scope

Confirm which workforce populations fall under the training requirement, including employees, contractors and any other workforce members.
Agree in writing which social engineering topics the module covers, such as phishing, business email compromise, pretexting and tailgating.
Define the evidence set up front: completion records, module versions, dates and the reporting fields used to calculate both assessment metrics.

How we build

Set up a self-hosted learning platform in your cloud account, data center or air-gapped network, with access limited to your administrators.
Configure course completion rules so an activity is marked complete only under conditions your policy defines, not by default.
Build the social engineering module and, where agreed, a phishing simulation program with recorded results for each workforce member.

How we hand over

Document the configuration, scope decisions, module content and the procedure for producing the initial and up to date training reports.
Deliver a runbook that shows your staff how to export completion data, record exceptions and retire or update modules over time.
Provide the evidence package to your own compliance lead and, if your assessor asks, to the independent auditor who tests the control.

How we support

Ongoing support, content refreshes and platform upgrades are available as a retainer after the fixed-scope work is complete.
Retainers can include periodic review of completion data and updates to the module when your threat picture or policy changes.
Confirm with us in the written scope whether recurring simulations, annual content review and reporting cadence are included.