CIS 14.6 incident recognition training: requirements and evidence

What Safeguard 14.6 asks for and why incident reporting depends on it

If you are a compliance lead or engineer who must show that CIS Safeguard 14.6 is met, the short answer is this: workforce members must be trained to recognize a potential security incident and report it, and an assessor checks two things, whether training is completed and kept current, and whether the enterprise has a dedicated training module on recognizing and reporting incidents. Under the CIS Controls Assessment Specification, an enterprise with no such module receives a failing score, so the module itself is the first thing to confirm. The safeguard applies to every Implementation Group, from IG1 upward, and it has no prerequisite safeguards for measurement. The reason this matters is practical. Many incidents first appear to someone outside the security team: a user who clicks a suspicious link, an employee who notices a shared folder open to the wrong audience, or an operator who sees a process behaving oddly. When people do not know what counts as a potential incident, they either stay silent or assume someone else has already raised it, and the response clock starts late. Safeguard 14.6 is the person-facing half of this problem. Safeguard 17.3 in Control 17 is the process half, requiring a documented workforce process for reporting security incidents. Training teaches people what to notice and what to do with it. The reporting process gives them somewhere to send it. An assessor who reviews one without the other will find a gap. Three things usually make this safeguard hard to satisfy. The first is defining a potential incident in terms staff can apply, which means agreeing examples with the incident response owner and aligning them with the reporting channel in 17.3. The second is keeping completion current across joiners, movers and contractors, which requires an owner and a recurring schedule. The third is proving the content covers both recognition and reporting, not only awareness of phishing. Confirm with your assessor which evidence they will accept for each of these points before you build the module.

Who must be trained, and which scoping choices change the work

Safeguard 14.6 applies to every enterprise regardless of Implementation Group, so the scoping work is about who counts as workforce, which assets and data the training must name, and whether the reporting channels in the training match the process in Safeguard 17.3. The cards below cover the decisions that most often change the size and content of the program.

All workforce members, including contractors

Safeguard 14.6 asks that workforce members be trained, and the scope of that term is the first decision to write down. Employees are the obvious group. Contractors, temporary staff and agency workers count when they access enterprise assets or data, so a contractor with a laptop on the corporate network belongs in the audience even if HR does not employ them. Check that your contractor agreements or onboarding gates require completion of the training, and that the training records show who completed it. Decide the definition before you measure coverage, because the assessment depends on the size of the denominator.

Third-party staff with system access

Staff employed by a service provider often hold accounts in your systems, use your ticketing tools or handle your data. Whether they complete your internal training or their employer's equivalent is a scoping choice that should be stated in the service contract. If you accept the provider's training, ask for evidence that it covers recognizing and reporting incidents and that it is kept current. Cross-reference this with Control 15 so the provider's obligations and the training records sit in the same register.

Assets and data named in training

Training that says only "report suspicious activity" is hard to evidence and hard for staff to apply. Name the systems people actually use, such as email, the identity provider, the document store, endpoint devices and any customer-facing portals, and name the categories of data whose exposure must be reported. The asset classes in v8.1 include Users, Devices, Software, Data, Network and Documentation, so the examples in your modules should reflect the classes you have inventoried under Controls 1, 2 and 3.

Role-specific audiences

Safeguard 14.6 is a general requirement, so one module can satisfy it for most staff. Some roles need additional content: IT administrators who receive alerts, finance staff who handle payment changes, and customer support teams who are the first point of contact for suspicious messages. Decide whether these groups take a supplementary incident recognition module or whether their role-specific training under Safeguard 14.9 covers the reporting steps. Record the decision, because an assessor will ask how each audience was addressed.

Reporting channels must match Safeguard 17.3

Safeguard 17.3 requires a documented workforce process for reporting incidents, so the channels named in training must be the same channels that process uses. If training tells staff to email a shared mailbox while the process routes reports to a ticketing queue, the program fails on consistency even when attendance is complete. Before you publish training, walk through the reporting path with the incident response owner, confirm the contact details and hours, and confirm that the process names a fallback channel if the primary one is unavailable.

Implementation Group context

Safeguard 14.6 is in Implementation Group 1, so it applies to IG1, IG2 and IG3 enterprises alike. A small organization and a large regulated one must both train their workforce on recognizing and reporting incidents. What changes with the group is the surrounding maturity: IG2 and IG3 organizations usually have more channels, more sensitive data and more specialist teams, which means more routes that training must describe. Confirm your group against the CIS Implementation Groups pages, then size the audience and channel list to your actual environment instead of the minimum.

How an assessor tests Safeguard 14.6 and what passes

This table compares how an assessor approaches Safeguard 14.6 across its test approach, evidence, pass criteria and common findings. Read it as a checklist of what to prepare before an independent assessor reviews your training program. The main takeaway is that a training module must exist and its completion records must be current, because both metrics depend on them.

Assessment element	What the assessor looks for	Where it usually fails
Test approach	Confirms a training module on recognizing and reporting potential incidents exists, then measures who has completed it and whether completion is current	Assessor finds awareness content that covers phishing only, with no reporting step
Initial Training Compliance	Share of workforce members who have received initial training on incident recognition and reporting	Onboarding records do not show new hires completing the module, or the population list is incomplete
Up to Date Training	Share of compliant workforce members whose training remains current under the enterprise's own refresh cycle	Records show completions from years earlier, with no refresh after content or process changes
Evidence requested	Training module content, enrollment or assignment lists, completion records with dates, and the reporting procedure the module teaches	Content exists only as slides, with no record linking completions to named workforce members
Pass criteria	A module exists that covers recognizing and reporting incidents, and both metrics are measured and reported with supporting records	Module is absent, so the Safeguard receives a failing score regardless of other awareness activity
Common finding: missing module content	Module does not explain what counts as a potential incident or how and to whom to report it	Content covers general security awareness but omits the reporting path described in Safeguard 17.3
Common finding: incomplete completion records	Every workforce member in scope has a traceable completion or a documented exception	Contractors, temporary staff or shared-mailbox users are left out of the population
Common finding: stale training	Refresh occurs when content or the reporting process changes, and the change is reflected in records	Reporting contacts or tooling change, but the module still points staff to retired channels
Scope of the specification	The CIS Controls Assessment Specification defines what to measure, not how; the independent assessor decides the result	Organizations treat the specification as a step-by-step procedure and skip the assessor's judgment

How to implement 14.6 in sequence

This sequence turns Safeguard 14.6 from a training intention into evidence an assessor can test: a defined incident scope, a delivered module, a reporting path tied to Safeguard 17.3, and a completion record that is kept current over time.

Define what counts as a potential incident
Start by agreeing, with the security lead and the incident response owner, a short written definition of a potential security incident for your enterprise. List the signs staff should notice, such as unexpected login prompts, unfamiliar attachments, lost devices, misdirected data, or systems behaving oddly. Keep the list tied to your own assets and business processes so the examples are recognizable to the people who will read them. The output is a signed-off definition and a list of recognition examples that the training module will use.
Write the recognition and reporting module
Build the training module around two parts: how to recognize a potential incident using the agreed examples, and exactly what a person does once they suspect one. Write the reporting path as concrete actions, such as who to contact, through which channel, what information to include, and that staff should not investigate on their own. Assign a named owner for the module content. The output is a module outline with learning objectives, a reporting procedure summary and an owner, reviewed by the people who run incident response.
Link the reporting path to the 17.3 process
Check that the reporting path in the module matches the workforce reporting process documented under Safeguard 17.3 in Control 17. Confirm the reporting channel, the contact details, the escalation route and the ownership of each step are identical in both documents. Ask the incident response lead to confirm that the contact details are current and that the channel is monitored. The output is a cross-reference note showing where each module step is documented in the 17.3 process, which an assessor can use to trace training back to procedure.
Deliver initial training to the workforce
Deliver the module to every workforce member, including contractors and staff who use enterprise systems, and record who received it. If your learning platform is open source, such as Moodle, you can configure the module as a tracked activity so completion is recorded automatically when a learner views it, receives a grade, or ticks it, depending on the conditions you set. Confirm the completion conditions with your platform administrator before launch so the record means what you think it means. The output is a completion list covering the initial audience.
Set the recurring completion cycle
Define how often workforce members must complete the module again, and set reminders for those who have not. The cycle and reminder settings belong in your security awareness program documentation, which Safeguard 14.1 governs. Ask your compliance or security lead to confirm the interval against your policy and any regulatory obligations you carry, since this page does not set one. Record who is responsible for sending reminders and for escalating overdue completions. The output is a documented cycle, a reminder schedule and an escalation owner.
Track completion against the assessment metrics
Produce a completion report that shows the share of workforce members who received initial training and the share who are current on the recurring cycle, matching the two metrics the CIS Controls Assessment Specification uses for this Safeguard. Reconcile the report against your identity directory so departed staff and new joiners are counted correctly. Keep the report with dated exports so you can show its state at the time of an assessment. The output is a dated completion report that an assessor can reproduce from source records.
Record content updates and review cycles
Each time the incident definition, reporting channel, contact details or the 17.3 process changes, update the module and log the change with its date, reason and approver. Schedule a periodic review of the module content with the incident response owner, and note when it was last reviewed. Keep the version history with the module so you can show which content was delivered to which audience at each point in time. The output is a change log and review record that connects each training version to the procedure it described.

Evidence that shows 14.6 is met and how to keep it current

The Assessment Specification scores Safeguard 14.6 on training coverage and currency, so the evidence has to show both that a module exists and that the right people completed it. The cards below cover each artifact an assessor is likely to ask for and the routine that keeps it current between reviews.

Training module content and version history

The module itself is the first artifact. It should explain how to recognize a potential security incident, what signs to look for and exactly how to report it, because the Assessment Specification fails Safeguard 14.6 when no module on recognizing and reporting incidents exists. Keep exported copies of each version with a revision date and the name of the approver, so an assessor can see what was taught on any given day. Confirm with your learning platform whether it keeps prior versions or whether you must archive them yourself.

Learner completion records with dates

The two metrics in the Assessment Specification, Initial Training Compliance and Up to Date Training, are both measured from who finished the module and when. Completion records should show the learner, the module version, the completion date and the method of completion. In Moodle, activity completion can be set to mark an activity complete when a learner views it, receives a grade or ticks it manually, so choose the condition that matches a real check of understanding and document that choice.

Workforce roster of who was trained

Completion is only meaningful against the population it should cover. Keep a roster of workforce members in scope, including employees, contractors and temporary staff who have access to enterprise systems or data, and reconcile it against the learning records each cycle. Gaps between the roster and completions are what an assessor will test first. Ask your HR and identity teams which sources define the workforce so the denominator for both metrics is defensible.

Reporting procedure the module teaches

The training must match the process employees are told to follow. Keep the current reporting procedure, including the channel, the information to include and the time expectations, alongside the module. Safeguard 17.3 separately requires a documented workforce reporting process, so the two documents should use the same contact points, names and steps. A mismatch, such as training that points to an retired mailbox, is an easy finding to reproduce.

Review records after reporting process changes

When the reporting channel, incident thresholds or responsible teams change, the module should be reviewed and reissued. Record each review with the trigger, the reviewer, the decision and any version created, and link it to the incident response change record. This shows the program responds to change rather than only repeating an annual course. Define in writing which changes trigger a review so the decision is not left to memory.

Exporting and dating records on a fixed cadence

Evidence goes stale between audits unless it is captured on a schedule. Set a recurring export of completion reports, roster reconciliations and the current module version, store them in a location with restricted write access, and name each file with its date. Confirm with your auditor or assessor how far back they expect records to go and whether they accept system-generated exports or need signed copies. Assign one owner for the calendar so exports do not depend on an individual's availability.

What meeting 14.6 costs in money and effort

This table breaks down the cost components of training the workforce to recognize and report incidents under Safeguard 14.6, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a written scope and to ask vendors and partners for line-item quotes rather than a single total.

Cost component	One-time or recurring	Who is paid and what drives it
Learning platform or license spend	Recurring	Commercial learning platform subscriptions scale with user count and features. Self-hosted open-source learning software, such as Moodle (GPL-3.0-or-later), removes license fees but moves hosting and patching to your team or partner.
Content development for the incident recognition module	One-time, with periodic revision	In-house staff or an outside content provider write the module on recognizing a potential incident and the reporting steps. Cost rises with the number of roles, languages and scenarios covered, and with how closely the module must match your own reporting process.
Engineering and administrator time to configure the module and completion tracking	One-time setup, then recurring upkeep	Administrators configure course structure, completion conditions and reporting views. Moodle's activity completion marks an activity complete when a learner views it, receives a grade or ticks it manually, so the completion rule you choose determines how much checking staff must do.
Ongoing completion upkeep and reminders	Recurring	Staff track who has received initial training and who is out of date, then send reminders and handle exceptions for new joiners and contractors. Effort grows with headcount turnover and with the frequency of refresher training you set in your awareness program.
Reporting-process alignment with Control 17	One-time, with recurring review	Incident response owners confirm that the reporting route taught in training matches the documented workforce reporting process required by Safeguard 17.3. Cost rises when the reporting process changes, when multiple tools receive reports, or when the incident response team has to rework procedures.
Assessor fees	Recurring per assessment cycle	An independent assessor or auditor charges for testing the evidence. Fees depend on scope, the number of safeguards tested and whether your evidence is organized before fieldwork. Ask the assessor for a written scope and fee basis before they start.
Partner preparation and evidence support	One-time, or recurring under a retainer	If you engage an implementation partner, they are paid to configure systems and organize evidence. The partner does not issue assessment results. Ask for a fixed-scope quote that lists deliverables, training content, tracking setup and evidence packaging separately.

How Moodle and DFIR-IRIS support the 14.6 evidence trail

Safeguard 14.6 asks for proof that staff were trained to recognize and report incidents, and Safeguard 17.3 asks for a working reporting process. Moodle can produce the training records, while DFIR-IRIS can receive and track the reports that follow, but each tool only covers its own half of the trail.

Moodle activity completion as training evidence

Moodle's activity completion marks a learner complete when they view an activity, receive a grade from it, or tick it manually, depending on the conditions the administrator sets. For Safeguard 14.6, the completion condition should match the assessed requirement, such as passing a quiz on recognizing and reporting incidents rather than merely opening a page. Confirm in your own instance that completion settings are enforced and that completion reports can be exported for the assessor.

Tying completions to the workforce roster

The Safeguard 14.6 measures count the share of workforce members who received initial training and who remain up to date. A completion record is only useful if it can be matched to a current, complete list of workforce members, including contractors and new starters. Check that enrollment is driven from the HR or identity source and that leavers and role changes are reflected in the completion denominator.

Training module content on reporting

The assessment specification fails Safeguard 14.6 when no training module covers recognizing and reporting incidents, so the module content itself is evidence. The course should describe what counts as a potential incident, how to report it, to whom, and through which channel, and it should name the same reporting path documented under Safeguard 17.3. Keep versioned copies of the course content so the assessor can see what was taught on a given date.

DFIR-IRIS as the downstream case tool

DFIR-IRIS is an incident case management tool, not a training platform. It keeps each case as one record of assets, indicators of compromise, tasks and evidence with a full audit trail, and it triages alerts from SIEM, EDR and REST sources into cases. Reports raised by staff can be entered as cases, which links the awareness outcome to the Safeguard 17.3 reporting workflow. Confirm how staff reports reach IRIS in your environment, such as a mailbox, form or ticket integration.

Audit trail and timeline for reported events

IRIS records each case with an audit trail and builds a consolidated investigation timeline, so an assessor can see when a report arrived, who triaged it and what action followed. This is the evidence that reporting training is connected to a working process, not just a completed course. Test a sample report end to end in a non-production case to confirm the timestamps and actor records meet your evidence requirements.

Licensing and configuration caveats

Both tools are open source, but the license governs redistribution and modification, not whether your configuration is compliant. Moodle completion and IRIS case handling only produce credible evidence when the administrator sets the conditions, retention and access controls deliberately. Confirm configuration, hosting, backup and access review inside your own infrastructure with your assessor before relying on either tool for a Safeguard 14.6 claim.

Who does what: your team, an implementation partner and the auditor

Your organization owns Safeguard 14.6. Its security function defines what counts as a potential incident for the workforce, decides what staff should do when they suspect one, and approves the training content that teaches it. Human resources or the learning function usually schedules delivery, tracks who has finished, and chases overdue completions. Responsibility for the outcome sits with you, so the training has to reflect your real reporting channels, not a generic template.

Incident criteria: Define in writing the examples staff should report, such as suspicious emails, lost devices, unexpected access prompts and unusual system behavior.
Reporting path: Confirm the channel, contact details and expected speed of reporting that the module teaches, and match it to the process documented under Safeguard 17.3.
Content approval: Sign off on the module, its examples and its review schedule, and record who approved each version.
Delivery and follow-up: Run the training at hire and on a recurring cycle, handle exceptions, and act on staff who do not complete it.
Evidence ownership: Keep the training records, approval history and completion reports that the assessor will request.

Before you engage anyone, confirm that you can name the owner of each item above and show the assessor a current, approved version.

Where organizations fall short on 14.6 and how to close each gap

Most shortfalls on Safeguard 14.6 come from training that stops at recognition and never reaches reporting, or from records and content that drift away from the live process. Each card names one gap, the fix in plain terms and the evidence an assessor will ask to see.

Phishing training with no reporting step

Many programs teach staff to spot phishing and stop there, so a person who suspects a message knows it is bad but not what to do next. Safeguard 14.6 asks for both recognizing and reporting a potential incident. Add a module section that walks through the exact report action, such as the mail client button or the service desk address, and test it in the same phishing simulations. Evidence: the module outline showing a reporting section and simulation results that record reports, not only clicks.

Reporting path that differs from 17.3

If the training tells staff to call one number while the incident response process in Safeguard 17.3 routes reports to a different queue, staff will report to the wrong place or not at all. Check that the training and the documented workforce reporting process name the same channel, owner and hours. Ask the incident response lead to confirm the match during a walkthrough. Evidence: the reporting procedure, the training slide that cites it and a dated sign-off showing both were reviewed together.

No written definition of a potential incident

Staff cannot report what they cannot classify. Without a plain definition, people either over-report routine spam or stay silent about odd account behavior, a lost badge or a suspicious call. Write a short definition with examples that the organization has agreed, and include a few cases where the answer is to report anyway. Keep the examples aligned with the thresholds used in the incident response process. Evidence: the approved definition, the examples used in training and the version history of both.

Completion records not tied to named people

A completion report that shows a percentage but not who finished is weak evidence. The assessment specification measures the share of workforce members who received initial training and whether training stays current, so each count must trace to a person. Confirm that the learning platform keeps user identity, course version and completion date, and that leavers and contractors are handled. For Moodle, activity completion can be set to mark an activity complete on viewing, on receiving a grade or on manual tick, so choose the condition that matches the proof you need. Evidence: exported completion records by user, with the completion condition documented.

Content not updated after process changes

Training often outlives the process it describes. When the reporting channel, contact details or escalation path changes, a module that still shows the old number leaves staff reporting to a dead address. Set a review trigger for each change to the incident process, not only an annual date, and record which module version each person completed. Re-run the affected module after any change and confirm completion. Evidence: a change log linking process revisions to training revisions and the completion count after each re-run.

Questions buyers ask about Safeguard 14.6 cost, effort and outside help

Can a small team meet Safeguard 14.6 on its own?

Yes, in principle. Safeguard 14.6 asks that workforce members be trained to recognize a potential security incident and report it, and CIS lists it in Implementation Group 1, so it is designed as baseline hygiene for every enterprise. A small team with an internal owner for security awareness can write a short module, deliver it, and keep records of who completed it. The work becomes harder when the organization has many sites, contractors, shift workers or no one who can explain the reporting path clearly. Before deciding, confirm who will own the module, who approves its content, and how the assessor will see completion records. Consider whether your learning platform can record completion and whether the reporting channel named in the training matches the one documented under Safeguard 17.3.

What drives the effort of Safeguard 14.6?

The main drivers are the size and spread of the workforce, the number of roles and locations, and how many reporting channels the organization already has. Each additional channel, such as a phone line, a ticketing queue, a service desk form and an email alias, adds content to write and explain. Effort also rises when the module must be reviewed by legal, HR or a works council, or when content must be translated. Ongoing effort depends on how often the module is refreshed and how many new joiners need it. Ask any partner to break the estimate into content design, delivery setup, learning platform configuration, evidence collection and periodic review, so you can see which parts are one-time and which recur.

What does the workforce and management need to contribute?

The workforce must complete the training and understand where to report, which is what the assessment checks through completion metrics. Managers need to release time for training, confirm that new joiners and contractors enroll, and reinforce reporting when staff raise concerns. Security and IT staff must confirm the reporting channels, define what counts as a potential incident in plain language, and make sure reports reach the response team. Legal or HR may need to approve wording about monitoring and disciplinary matters. Agree these roles in writing before the first module goes live, because missing sign-off is one of the more common reasons evidence arrives late.

How long does it take to produce the first evidence set?

The time depends on how quickly content is approved, how many people must complete the training before the assessor's measurement point, and whether a learning platform already tracks completion. CIS scores Safeguard 14.6 with two metrics: initial training compliance, which is the share of workforce members who have received initial training, and up-to-date training, which is the share of compliant members. Reaching a high share takes time for large or distributed workforces, and gaps in identity records or contractor lists slow the count. Confirm with your assessor which date range and population they will sample, and ask any partner to list the dependencies that could delay the evidence, such as legal review, platform access or enrollment of contractors.

Can an implementation partner issue a CIS Controls certificate?

No. An implementation partner prepares the training module, the learning platform configuration, the completion records and the written process, but only an independent assessor or certification body can issue a report or certificate. The organization owns its controls and decides what to claim. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, and CIS Controls Accreditation applies to CIS SecureSuite member organizations offering implementation, auditing or assessment services, which is a separate matter from certifying your organization. Ask any partner to confirm in writing which parts of the evidence they prepare and which parts an independent party must verify.

How does Safeguard 14.6 relate to Safeguard 17.3 and 14.2?

Safeguard 14.6 trains people to recognize and report potential incidents, while Safeguard 17.3 requires a documented workforce process for reporting security incidents. The training should describe that same process, using the same channels, names and timelines, so the workforce is taught what the procedure actually says. Safeguard 14.2 covers social engineering awareness, such as phishing and pretexting, which is one of the most common triggers for a report. Teams often evidence 14.2 with phishing simulations, and those results can show whether staff know how to report a suspicious message. Confirm that your 14.6 module, your 17.3 procedure and your 14.2 material point to one reporting path.

What should a fixed-scope quote for Safeguard 14.6 include?

A fixed-scope quote should state the deliverables, the assumptions and the exclusions in writing before work starts. Ask for the workforce population in scope, the number of training modules and languages, the learning platform and how it will be configured, the reporting channels to be documented, the evidence to be produced, and the review schedule. Ask which items are one-time, such as content design and platform setup, and which recur, such as annual refreshes or onboarding updates. Confirm who approves content, who the assessor is, what happens if scope changes, and how the timeline depends on client reviews. DeployOpen plans and scopes engagements in writing, and a quote follows from that written scope.

How DeployOpen scopes, implements and prepares 14.6 evidence

DeployOpen works on Safeguard 14.6 by setting up the training and reporting systems inside your own infrastructure and preparing the records an assessor would examine. The organization owns the training content, the reporting process and the compliance decision, and an independent auditor or assessor issues any report or certificate.

How we scope

The written scope names the workforce groups, training modules and learning platform covered by Safeguard 14.6 training.
Scope defines how the incident recognition module links to the reporting process documented under Safeguard 17.3.
Scope states which completion and currency measures will be reported, and which parts remain with your HR or security teams.

How we build

We deploy and configure a self-hosted learning platform, such as Moodle, inside your own cloud account or data center.
We configure activity completion so each learner's status records viewing, grading or manual confirmation of the module.
We connect the reporting path to a self-hosted case tool such as DFIR-IRIS so training and incident records line up.

How we hand over

You receive documentation of the module, enrollment rules, completion settings and reporting pathway in writing.
Evidence exports show initial training compliance and up-to-date training status for each workforce group in scope.
Handover includes a walkthrough so your team can run enrollment, refresh cycles and completion reports without us.

How we support

Fixed-scope engagements agree scope, deliverables and timelines in writing before any work starts.
Ongoing support, upgrades and content maintenance are available as a retainer if you want continued help.
Confirm with your auditor or assessor which evidence formats and sampling they will accept before the build begins.