Safeguard 14.7 missing security updates training

Safeguard 14.7 asks staff to spot and report missing security updates

Safeguard 14.7 requires workforce training on how to verify and report out-of-date software patches and failures in automated processes and tools, including notifying IT personnel when those failures occur. If an auditor or customer asks for CIS Control 14 evidence and this Safeguard is in scope, the answer is a training module that teaches staff to recognize a missing update and a documented way to tell IT, plus records showing who completed it. Your organization owns this control. An implementation partner can help build the module and collect the evidence, but only an independent assessor or certification body issues reports or certificates.

The risk is simple. Patches are only effective once they are installed, and many gaps are visible to people outside IT long before a scanner or ticket reveals them: a laptop that keeps showing an update prompt, a server that has stopped reporting to the patch tool, or a failed update notice that someone dismisses. When nobody outside IT knows what those signals mean or where to send them, unpatched systems can stay exposed for longer than the platform team realizes. The CIS Controls are free for any organization to use to improve its own security, and CIS states they do not replace regulatory, compliance or authorization schemes, so this training supports other obligations rather than satisfying them alone. Safeguard 14.7 sits in Implementation Group 1, which means it applies to every enterprise, whether it is IG1, IG2 or IG3.

The hard part is keeping the training grounded in what staff actually see. A generic lecture on patching rarely helps a user who is looking at an operating system prompt, a browser warning about an outdated plugin, or a failed notice from an endpoint management console. Confirm which update prompts, failed-job alerts and tool notifications occur in your environment, then write the module around those screens and state exactly who to contact. Plan for upkeep as well: the content has to change when your patch tools, approval workflows or ownership of systems change, and the assessment specification will look for training that reflects current practice.

Who must complete missing security updates training under Safeguard 14.7

Safeguard 14.7 is assigned to the Users asset class and the Protect function, and it applies at IG1, IG2 and IG3. The scope decisions below determine who sits in the training population, where update failures surface, and who receives the reports, so each one should be settled and written down before the training is built.

The workforce population

Start with everyone who holds an enterprise account, not only full-time employees. Decide in writing whether contractors, temporary staff, interns and board members with accounts are included, because the population defines the denominator for the initial training and up to date training measures. Contractors who use enterprise laptops or accounts are the most common gap, since they often sit outside HR onboarding. Confirm how the enterprise will track each group so that completion records can be counted against the full list of account holders.

Endpoints where update failures appear

Update failures show up on managed endpoints, including laptops, desktops and mobile devices enrolled in management tooling, and on servers that staff log into directly. Training should explain what a failed or stalled update looks like on each platform, such as a repeated restart prompt, an error code in a settings screen or a device that has not checked in for a long period. Scope decisions here change the content, because a developer workstation and a shared kiosk fail in different ways.

Patch dashboards and management consoles

Many failures are visible only in patch dashboards and endpoint management consoles, not on the user's screen. Decide which automated processes and tools count as in scope for the training, such as a scheduled patch job, a deployment ring or a compliance report. Define what an automated process is for your enterprise, then tell staff which failure signals they should notice and report. Staff who can view these consoles need different guidance than those who only see a prompt on their own device.

IT and help desk recipients

The training must end in a report that reaches IT personnel, so the IT and help desk teams are part of the scope even when they are not the audience. Confirm the reporting channel, the contact details staff should use, and the response expectation for each report. If the help desk handles reports through a ticket queue, the training should match the queue's intake fields. Without a named recipient, staff learn to report and then have no one to tell.

Third parties using enterprise assets

Third parties whose staff use enterprise assets or accounts create the same update exposure as employees. Decide whether their staff receive the training directly, whether the training is included in the contract, or whether the provider attests to its own equivalent. Confirm this with the contract owner and the service provider management process, since the choice affects how completion is evidenced and who answers for a missed report.

How an assessor tests missing security updates training

This table compares what the CIS Assessment Specification asks an assessor to check for Safeguard 14.7, the evidence that answers each check, and the gaps that most often cause a weak result. Read it alongside the Safeguard 14.7 section of the specification, which is the primary source for the measures and their wording.

Assessment element	What the assessor checks	Evidence usually requested	Common finding
Prerequisite safeguards	The specification lists no prerequisite safeguards for measuring Safeguard 14.7	Confirm scope and the Safeguard 14.7 section directly with the assessor	Teams assume a policy or other safeguard must be in place first
Training module existence	A training module on identifying and reporting missing security updates exists	Module content, outline or course file that names outdated patches and failed automated tools	No module exists, which produces a failing score regardless of completion rates
Reporting route	Content explains how staff notify IT personnel of patch or automation failures	Module section, instructions or ticket and contact steps shown in the course	Module covers the topic but gives no clear way to report to IT
Initial Training Compliance	Share of workforce members who have received initial training on the topic	Completion records by user with dates, matched to the current workforce list	New hires and contractors are missing because onboarding does not assign the module
Up to Date Training	Share of compliant workforce members who remain current on the training	Recent completion records and the refresh cycle set by the enterprise	Completion records lapse, or the module was delivered once and never repeated
Workforce scope	Records cover the people who use enterprise assets, not only IT staff	Roster reconciled against directory or HR records	Records cover a training group while shared or contractor accounts are excluded

How to build a missing security updates training module in six steps

This sequence turns Safeguard 14.7 into a working training module that teaches staff to spot out-of-date patches and failed automated updates, report them to IT, and keep proof that the training happened. Each step ends with a document or record you can show an assessor.

Define the audience and the update tools they see
Start by listing the workforce groups that use enterprise assets, such as office staff, field staff, contractors and remote users, and the devices and tools each group touches. Note which tools show update status or failure messages to users, for example operating system update prompts, endpoint management portal notices, browser update banners and application notifications. Ask IT to confirm which of these tools produce messages users will actually see. The output is an approved audience and tool inventory that the rest of the module is built on.
Write learning objectives for update checks and failures
Write a short set of objectives that state what a learner must be able to do after the module. Cover how to check whether a patch or software version is out of date on their own device, what a failed or stalled update or a blocked automated process looks like in the tools in your inventory, and how to report it. Keep each objective tied to a screen or message a learner can recognize. The output is a signed-off objective list that the IT owner and the security lead have reviewed.
Set the reporting channel and the IT recipient
Decide how a learner reports a missing update or a failed automated process, such as a service desk ticket, a dedicated mailbox or a form, and name the IT role that receives and acts on each report. Confirm the channel is staffed during working hours and document what happens after a report is received. This procedure should match the reporting path used for incidents so staff are not sent to two different places. The output is a written reporting procedure with a named owner for the channel.
Build the module and a short knowledge check
Turn the objectives into lessons with screenshots from your own tools, a checklist for verifying update status, and a clear example of what to report. Add a short knowledge check that asks learners to identify an out-of-date item and choose the correct report step. Build the module in your learning platform, for example an open-source LMS such as Moodle, and set the completion conditions so the record shows that the learner finished the module. The output is a published module outline and a test copy that the security team has reviewed.
Deliver at hire and on a recurring schedule
Assign the module to every new workforce member as part of onboarding and set a recurring assignment for existing staff. Choose the recurring interval as part of your awareness program policy and record it there, since the assessment specification checks that training is current. Include contractors and any group identified in step one. The output is a written assignment rule covering new hires, existing staff and the recurring cycle.
Record completions and review content yearly
Export completion records from the learning platform on a regular basis and reconcile them against the current workforce list so you can report the share of staff who received initial training and the share who are up to date. Track learners who have not completed the module and follow up. Once a year, compare the module against the update tools in use and revise screenshots, objectives and reporting steps that no longer match. The output is a completion report and a dated content review record that show the module is current.

Evidence that shows missing security updates training is in place

An assessor testing Safeguard 14.7 looks for proof that the training exists, that every workforce member has taken it, and that the reporting path works in practice. The cards below cover the artifacts that connect those three points. Each one needs a dated copy and a named owner so the evidence stays current between assessments.

Approved training module and version history

The module itself is the first thing an assessor asks for, because the assessment specification fails Safeguard 14.7 when no training module covers identifying and reporting missing security updates. Keep the approved content, the approver, and a version history showing each revision with its date. Check that the module names the tools and processes staff should watch, such as patch notifications, failed automated updates, and endpoint management alerts, and that it matches how your IT team actually patches.

Learning objectives tied to Safeguard 14.7

Learning objectives show that the training targets the specific behavior the Safeguard describes: verifying whether a patch is out of date and reporting failures in automated processes and tools. Write each objective so a learner can demonstrate it, for example identifying a failed patch status on a workstation and knowing who to notify. Map each objective to Safeguard 14.7 in a traceability table so an assessor can follow the link without interpretation.

Completion records for every workforce member

The assessment specification scores Safeguard 14.7 on initial training compliance and on up-to-date training, so the completion record must show both the first completion for each workforce member and each recurring completion since. Export the learning platform data with dates and user identifiers, and reconcile it against the current workforce list from HR or identity systems. Gaps for leavers, contractors and new starters are the most common reasons this evidence fails review.

Knowledge check results

Knowledge checks show that completion reflects understanding rather than a click-through. Keep the quiz questions, the passing threshold, the attempt history, and the results for each learner. Review the questions against recent missing-update incidents so they do not drift from real conditions. Confirm with your assessor whether they expect knowledge check records or accept completion records alone for this Safeguard.

Reporting procedure and contact channel

Staff need a documented way to report a suspected missing update or a failed automated process, and that channel must reach IT personnel who can act. Keep the procedure, the contact channel (ticket queue, service desk address, or chat channel), and the escalation path with named owners. Test the channel periodically and record the test, so the procedure is shown to work rather than only to exist.

Records of reports received from trained staff

Reports from trained staff are the strongest proof that the training changes behavior. Keep anonymized or access-controlled records of each report about out-of-date software or failed update tools, with the date received, the triage outcome, and the remediation ticket. A period with no reports may also need explaining, so confirm with your assessor how they expect quiet periods to be documented. Keep a dated export of these records each quarter so they are available at audit time.

What missing security updates training costs to meet

This table compares the cost components of building and evidencing Safeguard 14.7 training, showing who is paid, whether each cost is one-time or recurring, what pushes it up and how to keep it down. Use it to structure a written quote, since no price or duration is stated here. The main takeaway is that most of the recurring cost comes from keeping the module current and the evidence pack complete, not from the first build.

Cost component	One-time or recurring	What drives it up	How to keep it down
Content development (internal time or outside developer)	One-time build, then periodic revision	Number of update tools covered, number of modules, branching for different roles	Reuse the module structure for other Control 14 topics such as 14.5 and 14.6
Learning platform or tooling (license or self-hosted)	Setup one-time, hosting and licensing recurring	Number of workforce members, number of locations, reporting needs	Self-hosted open-source platform such as Moodle removes license spend, but hosting and administration remain
Engineering or IT time to map update tools into content	One-time mapping, recurring when tools change	Number of patch and automation tools, frequency of tool changes, unusual failure alerts	Document one standard notification path to IT and reuse it across tools
Workforce time to complete training	Recurring, at hire and on the annual cycle	Number of workforce members, turnover, languages and locations	Keep modules short, deliver them in existing work time and use role-based assignment
Evidence upkeep (exports, change logs, annual review)	Recurring	Number of training cycles, audit sampling requests, number of content revisions	Automate completion exports and keep a dated change log for each module version
External review or auditor sampling	Periodic, depends on assessment or audit cycle	Scope of the assessment, number of samples requested, gaps found in the first review	Ask the reviewer for the sample method in advance and prepare the evidence pack before fieldwork

Who owns the training, who prepares the evidence and who assesses it

Your organization owns Safeguard 14.7. That means someone accountable must decide what staff are taught about spotting out-of-date patches and failed automated updates, approve the content, schedule delivery and act on what staff report. Your team also keeps the records that show who was trained and when. Those records are the raw material for the two metrics the assessment specification uses, Initial Training Compliance and Up to Date Training, so they must be reliable and retained.

Policy ownership: a named owner signs off the training objectives and links them to your patch management and incident reporting processes.
Content approval: staff in security or IT review any outsourced module for accuracy against your real patch tools and escalation path.
Delivery: managers or HR schedule training at hire and on a recurring cycle that you set and can justify.
Reporting decisions: your IT team decides how to respond to staff reports of missed updates or failed tools, and records that response.
Staff relationships: only your managers can explain why the training matters to their teams and follow up with people who skip it.

Check that the owner of these duties can name the completion report they will produce and who reviews it each cycle.

How self-hosted Moodle produces completion evidence for Safeguard 14.7

Moodle can host the training module and record who completed it, which gives an enterprise a self-hosted place to keep the Safeguard 14.7 training and its completion history. Moodle is licensed under GPL-3.0-or-later, so the software itself carries no license fee. The cost sits elsewhere: the organization pays for the servers or cloud accounts it runs on, for patching the platform and its database, for backups, and for the staff or partner who administers it. Those recurring operating costs are the figure to put in a quote, not the software license. Moodle's 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 condition set for that activity. For Safeguard 14.7, pick the condition that matches the assessment. A page view shows that someone opened the material, which is weak evidence that they learned how to spot and report out-of-date patches or failed automated updates. A graded knowledge check with a passing threshold, where staff must identify a missed update and state who to notify in the IT team, is much stronger. Export completion data on a schedule, and confirm with your Moodle administrators how those exports and the underlying logs are retained, since the assessor will ask for records covering the whole review period. Moodle records training completion, but it does not test whether staff verify patch status or report failed update jobs in your real tools. A phishing simulation platform or a patch-reporting tool is a separate system, and the Moodle module does not replace it. Use Moodle to show that the training happened and was passed, and use the other system to show that staff act on what they learned. Confirm with your assessor which combination they accept as evidence for the training metrics in the CIS Controls Assessment Specification before you build the course.

Where organizations fall short on missing security updates training

Safeguard 14.7 is easy to write down and hard to evidence well. The gaps below cluster around three questions: does the content match the risk, can staff act on it, and can the enterprise prove who was trained and when. Each card names one gap and the practical fix an assessor would expect to see.

Phishing content without update failures

Many programs cover phishing and passwords but never explain what a missing patch or a failed update looks like on a workstation. Safeguard 14.7 requires training on verifying and reporting out-of-date software and failures in automated tools, so a module that skips those topics leaves the Safeguard unaddressed. Fix it by adding a short section with examples staff can recognize, such as repeated update prompts that never complete, a patch agent showing an error, or a device reporting an old version. Check that the module names both signs.

No defined reporting channel

Staff who spot a stale patch often do not know whom to tell, so the observation dies in a chat thread or a shared desk. The Safeguard is about notifying IT personnel of failures, which needs a named route. Publish one channel, such as a ticket queue or service desk form, with a named owner and a backup. Confirm that the training shows staff exactly how to use it and that the channel is monitored outside working hours if the enterprise runs around the clock.

Completion records not tied to named people

A training log that shows a course title and a percentage but no individual names cannot support the Safeguard's workforce metrics. The assessment measures the share of workforce members who received initial training and the share kept up to date, so every record must map to a person in the directory. Export completions from the learning platform, match them against the identity system, and remove shared or generic accounts. Ask whether anyone who left the enterprise still appears in the totals.

New hires skip the module

Onboarding often covers laptops and access but not the awareness modules, so new starters can work for months without the content. The assessment measures initial training across the workforce, so new hires count. Add the module to the onboarding checklist as a required task before standard access is granted, and set a deadline the HR and IT teams both track. Confirm the platform can assign courses automatically from a directory group rather than by manual enrollment.

Content that names retired tools

A module that tells staff to open a patch console the enterprise replaced last year teaches the wrong steps and erodes trust in the program. Training must match the tools the workforce uses now, including the update channels for operating systems, browsers and business applications. Assign an owner to review tool names and screenshots whenever the patch or endpoint stack changes, and record the change in the module's revision history so the content can be shown as current.

No annual review record

Assessors look for evidence that training content is reviewed and kept current, not just delivered once. Without a dated review, the enterprise cannot show the update-failure module reflects today's tools and processes. Schedule a yearly review with a named approver, keep the signed or logged outcome, and version the module so each release date is visible. Treat the review record as part of the Safeguard evidence alongside the completion data.

Questions buyers ask about Safeguard 14.7 training

Can our organization build Safeguard 14.7 training itself?

Yes. Safeguard 14.7 asks for workforce training on how to verify and report out-of-date software patches and failures in automated processes and tools, including notifying IT staff. An internal team can write that module if it has three things: a named owner accountable for the content and its evidence, time from IT or security staff to explain how patch status is checked and how failures are reported, and a learning platform that records who completed the training and when. Many teams use an open-source learning management system such as Moodle for this. Its activity completion feature can record that a learner viewed the module, received a grade, or ticked it off, so confirm which completion condition you will use before you rely on it as evidence. An implementation partner can help set up the platform and draft the module, but your organization owns the training and its records.

What drives the cost and effort of Safeguard 14.7 training?

The main drivers are the size of the workforce, the number of update tools and automated processes employees must check or report on, the number of languages the content must cover, and how often the content changes when patch tools or reporting procedures change. Costs fall into one-time work (designing the module, configuring the platform, writing the reporting procedure) and recurring work (refreshing content, enrolling new staff, tracking completion and answering questions). When you request a quote, ask the provider to separate those two groups, to state which tools and reporting channels are in scope, to list which languages are included, and to explain how updates to the content are handled after delivery.

How long does Safeguard 14.7 training take to put in place?

The timing depends on the agreed scope and on your organization's review cycle for security awareness content, so no fixed duration applies to every environment. Schedule drivers include how many update tools must be covered, whether the reporting procedure already exists, how quickly subject matter experts can review draft content, and whether the module must go through HR or works council approval before rollout. Ask any provider for a written scope and milestone plan before work starts, and confirm with your own security awareness owner how often the module will be reviewed once it is live.

What does the work need from our organization?

Four inputs are usually needed. First, access to the update and configuration tools so the module reflects what staff will actually see, such as patch dashboards or endpoint management consoles. Second, a written reporting procedure that tells staff how to report an out-of-date patch or a failed automated process and who receives the report, including IT personnel. Third, a named approver who signs off on the content and the reporting path. Fourth, workforce data, meaning the list of staff and roles that must complete training, plus the records needed to show initial completion and ongoing currency. Confirm early whether your HR or identity system can supply that list, because the two metrics in the assessment specification depend on it.

Does Safeguard 14.7 need a separate module from Safeguard 14.2?

A separate module is the clearer choice. Safeguard 14.2 covers social engineering awareness, such as phishing and pretexting, while Safeguard 14.7 covers verifying and reporting missing security updates and failures in automated tools. The topics have different learning objectives and different people may act on them. The assessment specification also scores Safeguard 14.7 against a specific training module on identifying and reporting missing security updates, so a combined module can make that evidence harder to show. Keep the 14.7 module focused on patch status and failure reporting, and keep its completion records separate so an assessor can trace each Safeguard to its own training.

Does an implementation partner issue a certificate for Safeguard 14.7?

No. An implementation partner prepares the training, the platform configuration and the completion records, but only an independent auditor, assessor or certification body issues reports, attestations or certificates. CIS also states that the CIS Controls do not replace any regulatory, compliance or authorization scheme, so a Safeguard 14.7 training record is one piece of evidence within your wider program. Before engaging anyone, ask which evidence the assessor will expect, confirm that the assessor accepts the completion records you plan to produce, and make sure your organization, not the partner, owns the controls the training supports.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems, training records and evidence behind Safeguard 14.7 Missing security updates training, which your organization owns and an independent assessor reviews. Our work covers the training module, the learning platform configuration and the records that show who completed it and when.

How we scope

Engagements are fixed-scope, with the Safeguard 14.7 deliverables agreed in writing before work starts.
The written scope names the learning platform, the audience groups and the workforce population to be measured.
We confirm which metrics your records must support, Initial Training Compliance and Up to Date Training, and how each is counted.

How we build

We build a training module on identifying and reporting out-of-date patches and failed automated update processes.
We configure completion tracking on the self-hosted learning platform so each learner's status is recorded and retrievable.
We set up reporting that shows which workforce members have completed initial training and which are due for refresher training.

How we hand over

We document the module content, the completion settings and the reporting steps so your staff can rerun them.
We deliver an evidence pack listing the training records, module version and report outputs mapped to each metric.
We confirm with your team how the reporting path to IT staff works, so the training matches the process operators follow.

How we support

Ongoing support, upgrades and content updates are available as a retainer after the initial handover.
Retainer support can keep the training module current as patch processes and tools change in your environment.
Your organization decides whether and how to use the evidence, and an independent auditor or assessor issues any report.