What Safeguard 14.9 role-specific security training asks for
Safeguard 14.9 asks the enterprise to conduct role-specific security awareness and skills training, which means the people who hold particular jobs learn the threats and skills those jobs actually expose them to. It is the only Safeguard in Control 14 that applies from Implementation Group 2, so an IG1 enterprise does not need to meet it, while an IG2 or IG3 enterprise preparing for a CIS Controls review should expect an assessor to ask for it. CIS gives three examples, which are illustrative only and not a required curriculum: secure system administration courses for IT professionals, OWASP Top 10 vulnerability awareness and prevention training for web developers, and advanced social engineering awareness training for high-profile roles.
The risk addressed here is that generic awareness content does not teach the people with the most privilege the threats they face. A system administrator needs to recognize abuse of privileged access and insecure administrative practices, a developer needs to avoid the common flaws that end up in production code, and executives and finance staff are targeted by more personalized impersonation attempts. A single annual module for everyone leaves those groups without the skills their roles require, and the gap is usually largest where the damage from a successful attack would be greatest.
Safeguard 14.9 is hard to evidence because the assessment specification measures training completion rather than skill. The Controls Assessment Specification scores it with Initial Training Compliance and Up to Date Training, and it fails an enterprise that has no role-specific training content at all. Confirm with your assessor which role definitions, course catalog and completion records they will accept, and map each role to its training content before the review, so that the records show who was trained on what, when they were last refreshed, and which roles the content was designed for.
Which roles and enterprises Safeguard 14.9 applies to
Safeguard 14.9 is the only IG2 Safeguard in Control 14, so it applies to IG2 and IG3 enterprises and not to IG1 organizations. The cards below cover where that line falls, which roles usually need tailored content, and the scoping choices that decide who must be trained.
IG2 and IG3 applicability
CIS assigns Safeguard 14.9 to Implementation Group 2, so it applies to IG2 enterprises and to IG3 enterprises, which also include all IG2 Safeguards. An IG1 organization is not required to meet it, although a general awareness program under Safeguard 14.1 still applies to every enterprise. Confirm your Implementation Group before scoping the training budget, since IG2 adds operational complexity and sensitive information as the trigger.
IT administrators and privileged staff
Administrators who manage servers, directories, cloud tenants and network devices carry risks that general awareness courses do not address. Safeguard 14.9 examples point to secure system administration courses for IT professionals. Check that the curriculum covers the platforms you run, such as hardening, privileged access and secure remote management, and that it is recorded per person so the assessor can see who completed it.
Developers and web application teams
Developers who build or maintain web applications need training that matches their code, such as OWASP Top 10 vulnerability awareness and prevention. Scope this group by role, not job title, so that engineers who touch production code, pipelines or APIs are included. Pair the course with evidence from code scanning or review so the training can be linked to the defects it targets.
High-profile and privileged roles
Executives, board members, and staff with payment or approval authority are frequent targets of targeted social engineering. The Safeguard 14.9 examples call for advanced social engineering awareness for these roles. Decide which positions qualify, document the list, and review it when responsibilities change, since a stale list is a common gap found at assessment.
Finance and HR workflows
Finance and HR staff handle payment changes, payroll data and employee records, which makes them common targets of business email compromise and data exposure. Role-specific content here usually covers verifying payment instructions and handling personal data. Confirm with the business owners which workflows create exposure, because the training should reflect those processes rather than generic examples.
Contractors and third-party staff
Scoping must state whether contractors, temporary staff and outsourced administrators count as workforce members for Safeguard 14.9. If they hold access to your systems or data, the safer position is to include them, or to require their providers to show equivalent training under your service provider contracts. Record that decision in writing, because the assessment measures the share of workforce members trained.
Users asset class and Protect function
In v8.1, Safeguard 14.9 belongs to the Users asset class and the Protect security function. That classification places it with the people who use enterprise assets, and it sits alongside the other awareness Safeguards in Control 14. Map your evidence to the Protect function when reporting to governance bodies, and note that the NIST CSF 2.0 mappings include the Govern function for role responsibilities.
How an assessor tests Safeguard 14.9
This table compares what the CIS Controls Assessment Specification measures for Safeguard 14.9, the evidence an assessor will ask for, and the findings that most often fail. Use it to check your own training records before an assessment, and to ask a reviewer which evidence they expect to see.
| Test element | What the assessor checks | Evidence to prepare | Common finding |
|---|---|---|---|
| Initial Training Compliance | Share of workforce members who have received initial role-specific training | Role matrix mapping each role to its course, plus completion records with dates for each person | Records cover general awareness only, with no role-specific course logged |
| Up to Date Training | Share of compliant workforce members whose role-specific training is current | Training dates against role changes, refresh schedule and completion history for the period tested | Courses were completed once and never refreshed after tooling or role changes |
| Role-specific content exists | Whether the enterprise has any role-specific training content at all | Course outlines for IT administration, developer secure coding and high-profile role social engineering, as applicable | No role-specific content exists, which produces a failing score |
| Prerequisite safeguards | The CAS lists no prerequisite safeguards for measuring 14.9 | Confirm the scope and population with the assessor before testing begins | Teams assume Safeguard 14.1 evidence alone satisfies the test |
| Population and roles | Whether the roles targeted match the enterprise's actual high-risk functions | Documented list of roles, system access and the rationale for each role's training | Roles such as administrators or developers are missing from the matrix |
| Course content and currency | Whether content reflects the duties of each role and current threats | Course version history, review dates and the owner who approved updates | Course material for web developers still uses an outdated OWASP Top 10 edition |
How to build role-specific training step by step
This sequence turns Safeguard 14.9 from a list of course ideas into a documented program: each role has a defined risk, matching content, recorded completions and a review cycle that the assessment specification can check.
Map roles to risks and training needs
Start by listing the job roles in scope, such as system administrators, web developers, finance approvers and executives, then note the systems, data and decisions each role touches. Security or compliance staff, with input from line managers, record the risks each role creates or faces, for example privileged access for administrators or secure coding for developers. The output is a role-to-risk register that names each role, its top risks and the training topic that addresses each risk. The step is complete when every role in scope has at least one documented risk and an owner has approved the register.
Build the role-to-course matrix
Convert the register into a role-to-course matrix that maps each role to specific courses, the training topics they cover (for example secure system administration, OWASP Top 10 awareness for developers, or advanced social engineering awareness for high-profile roles) and the audience for each. Mark which courses are general awareness and which are role-specific, so the program can show that Safeguard 14.9 is addressed separately from the umbrella program in 14.1. Ask the training lead to confirm which courses already exist internally, which come from a vendor and which must be written. The matrix is finished when each course has a named owner and a target audience.
Select or develop content for each role
For each course in the matrix, decide whether to buy, adopt open content or write it in-house. Content for technical roles should use the organization's own standards, approved tools and real secure configuration examples, while content for developers should reference the code scanning and review practices used in the delivery pipeline. Have a technical reviewer and a security lead approve each course before release. The output is a version-controlled course file for each role with a recorded approval date and author. Confirm licensing terms for any third-party material before it is loaded into the learning platform.
Configure the learning platform to record completion
Load the approved courses into the learning management system and set the completion conditions for each activity. In Moodle, for example, activity completion can be triggered when a learner views the activity, receives a grade or ticks it manually, so choose the condition that proves the learner actually engaged with the role content, and test it with a pilot user. Assign each course to the roles in the matrix through enrollment groups, not individual accounts, so that role changes move learners to the right content. The output is a configured course set and a test report showing that completion is recorded for each role.
Schedule initial and refresher delivery
Set a delivery schedule for initial training for each role and for refresher training that keeps it current. The CIS assessment specification measures two things: whether workforce members have received initial training and whether training is up to date, so the schedule must produce both records. Ask the program owner to define the intervals in the written policy, since no fixed timeline is supplied for this safeguard. Notify learners through the platform and track overdue completions. The output is a published calendar and an automated list of learners who are overdue for each role.
Generate completion reports as evidence
Export completion reports by role, course and date from the learning platform to show who completed initial training and who is current. Compare these reports with the directory of workforce members and the role register to catch gaps, such as new administrators who have not started their course. Keep the reports, the matrix and the approval records together in an evidence folder that the assessor can sample. The output is a dated completion report with an exception list and a named owner who signs off each review. Confirm with the assessor which sample period and format they expect.
Review content on a set cycle
Review every role-specific course on a defined cycle and whenever a role, system, tool or threat changes significantly. Reviewers compare the content against current configurations, incident lessons and the risk register, then record which courses were updated, retired or confirmed. Without current content, the assessment specification treats the program as failing, so this review is not optional. The output is a review log with the reviewer, date, changes made and a link to the updated course version. Feed the findings back into the role-to-risk register to start the next cycle.
Using Moodle, GitLab and Semgrep as training evidence sources
A self-hosted Moodle instance can serve as the record of who completed role-specific courses. Each activity can carry completion conditions, so Moodle marks it complete when a learner views it, when they receive a grade from it, or when they tick it manually, depending on how the course author configured the activity. For Safeguard 14.9 the courses would be tailored to roles, such as secure administration for IT staff or OWASP Top 10 material for developers, and completion records show which people in each role finished which course.
- Condition choice: Set view-based completion for reading material and grade-based completion for assessments, so a click alone does not count as learning.
- Role enrollment: Use cohorts or role-based enrollment so the population for each course matches the workforce roles in your inventory.
- Completion reports: Export course completion reports to CSV or PDF with timestamps, which becomes the record for the Initial Training Compliance and Up to Date Training measures.
- Activity logs: Keep the underlying logs for the retention period your policy sets, since they show access and grading history behind each completion.
- Lifecycle records: Track annual refresher enrollments separately so the Up to Date Training metric can be calculated per person.
Before relying on Moodle output, confirm with your assessor which exports and retention periods they will accept, and confirm the GPL-3.0-or-later license terms with your legal team if you plan to modify the platform.
GitLab Community Edition (MIT licensed) supports protected branches, which restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. These controls do not prove that a developer finished training. They show that the code path is governed, which can support a follow-up process: when a team has completed secure coding training, the organization can require reviewed merges into protected branches, and the platform records who approved each change.
- Merge gating: Require approvals on protected branches so changes from developers who have not completed the course can be routed to a reviewer you choose.
- Push restrictions: Set push access to no one on production branches so training outcomes are applied through review rather than direct commits.
- Force push control: Keep force pushes disabled to preserve the commit history that a review or investigation may need.
- Audit trail: Use merge request approvals and commit history as records of who changed what and who approved it.
- Follow-up list: Export group membership and role data so the platform list matches the training roster from Moodle.
Confirm the exact approval and push settings your GitLab version supports with its documentation, and state in your evidence pack that these records show access control, not learning.
Semgrep Community Edition (LGPL-2.1-only licensed) scans code in many languages, including Java, JavaScript, TypeScript, Python, Go, Ruby, PHP and C/C++, using community or custom rules. It can run in CI/CD pipelines to scan repositories continuously. For developer training, its value is indirect: if a course teaches a specific weakness class, such as injection or insecure deserialization, a scanner rule for that class shows whether the weakness recurs in new code. A rising or falling trend can help a training owner decide where follow-up is needed.
- Rule alignment: Map the course topics to specific Semgrep rules or custom rules, so each finding can be traced back to a lesson.
- Pipeline runs: Run scans on every merge request and keep the job logs and findings as dated records.
- Trend reporting: Track findings per team over time, which is an input to targeted refreshers rather than proof of training.
- Custom rules: Write rules for patterns your own developers repeat, and retire rules that no longer match your code.
- Language coverage: Confirm that the languages your teams use appear in the supported list before counting on the scanner for those teams.
Check with your assessor whether trend data from scanners is acceptable as supporting context, and do not present scan results as evidence that a training measure is met.
Evidence that passes a Safeguard 14.9 review
Safeguard 14.9 is measured through training records, not course content alone. The cards below cover the documents that tie each role to its required training, the proof that people completed it, and the records that keep both current as staff change.
Role-to-training matrix
This is the core document. It lists each job role in the enterprise, such as system administrator, web developer or executive assistant to a high-profile leader, and the role-specific courses each one must complete. Check that every role with elevated access or a higher exposure to targeted attacks has a row, and that each row names a course with an owner and a review date. A matrix that lists roles without courses fails the reviewer's question of whether role-specific content exists at all.
Role-specific course outlines
Each course needs an outline showing its objectives, the learner role it targets and the practical content it covers. Examples include secure system administration for IT staff, OWASP Top 10 vulnerability awareness and prevention for web developers, and advanced social engineering awareness for high-profile roles. Keep the outlines version-controlled with a date. Reviewers check that the content matches the role in the matrix, not a generic course relabeled.
Completion records per workforce member
Assessors measure Initial Training Compliance, the share of workforce members who have received initial training. That requires a record per person, per role course, with a completion date. An LMS such as Moodle can record activity completion when a learner views an activity, receives a grade or ticks it manually, depending on how the activity is configured. Confirm which condition your course uses, because a course marked complete on page view is weaker evidence than one that requires a graded check.
Content review and currency records
The Up to Date Training metric asks whether compliant workforce members remain current. Keep a dated record of each review of the role course content, who approved it and what changed, such as a new OWASP Top 10 edition or a revised administrative procedure. Pair this with records showing that staff who moved into a role or whose course was revised were retrained. Without review records, you cannot show the content is still correct for the role.
Register of hires and role changes
Initial training only covers people who were onboarded into a role. Maintain a register that lists every new hire and every internal role change, with the date each person entered the role and the date their role-specific course was assigned and completed. Reconcile this register against the HR system and the identity directory each month, so that a developer moved to an administrator position appears in the register with the training gap visible.
Access-based training triggers
Link training to privileges, not only job titles. Where repository or infrastructure access is granted, such as protected branch permissions in GitLab that restrict who can push or merge, the access grant can trigger a check that the role's course is complete before access is approved. Document this trigger in your access procedure. It gives the assessor a traceable reason why an individual with elevated access has or has not completed training.
What meeting Safeguard 14.9 costs in money and effort
This table breaks down the money and effort behind a role-specific training program for Safeguard 14.9, showing who is paid for each component, whether it is one-time or recurring, and what drives it up. Use it to structure a quote request, since no supplied figures set prices, and to check that each cost line is covered before work starts.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| Role inventory and content design per role | Internal training lead, security team, or implementation partner | One-time, then recurring when roles change | Number of distinct roles (for example, sysadmins, web developers, executives). Ask for the content outline per role and who approves it. |
| Learning platform and license spend | Software vendor, or none for self-hosted Moodle (GPL-3.0-or-later) | Recurring if commercial, otherwise none | Self-hosted Moodle carries no license fee, so ask for hosting, backup and admin time instead. Confirm any add-ons or plugins you plan to use. |
| Hosting and platform administration | Your infrastructure team or an implementation partner under a fixed scope | One-time setup, then recurring operations | Hosting location, user count and availability needs. Ask what is included in the quote for upgrades and backups. |
| Engineering time for CI/CD evidence integration | Internal engineers or implementation partner | One-time build, then small recurring upkeep | Number of systems that feed completion records into evidence. Ask how completion data will be exported and retained for assessors. |
| Content upkeep and refresh | Internal content owner, trainers or partner | Recurring | Rate of change in tools, OWASP guidance and admin practices. Ask how often each role's content is reviewed and who signs off. |
| External course or trainer fees | Third-party training provider or specialist trainer | Recurring per cohort or course | Number of learners per course, course depth and whether training is vendor-specific. Ask for per-seat pricing and what certificates are included. |
| Assessor sampling effort | Internal evidence owner, plus the independent assessor | Recurring per assessment cycle | Number of roles and workforce members sampled. Ask the assessor which training records and role mappings they will request. |
Which parts of Safeguard 14.9 are worth outsourcing
The organization owns Safeguard 14.9 in full: the training program, the role definitions, the content it approves, and the training records an assessor will ask to see. Nothing in the CIS Controls Assessment Specification lets an outside party take that ownership over. An implementation partner can help the organization prepare the work that is slow and error-prone: a role matrix that maps each job family (system administrators, web developers, executives and assistants to high-profile staff) to the training it needs, a configured self-hosted learning platform such as Moodle, course content for developers and administrators, and an evidence folder that shows who was trained, when, and on which version of the material. Those deliverables are prepared work products. They do not turn the partner into the party that decides whether the Safeguard is met.
Only an independent assessor or auditor issues conclusions about whether the Safeguard is implemented. The assessment specification scores Safeguard 14.9 on initial training compliance and on up-to-date training, and it fails the Safeguard when no role-specific content exists. Before engaging anyone, ask the partner which records each score is calculated from, and confirm with your assessor which population they will sample, such as the list of users in each role on a given date. A partner who offers to certify or attest to the result is outside the role this work supports.
Licensing is the part most often missed. Course material on OWASP Top 10 topics or secure administration may be written by the organization, adapted from an openly licensed source, or taken from a commercial provider. Each source carries its own license terms, and some restrict redistribution, modification or use inside a learning platform hosted for third parties. Ask for a list of every third-party module with its license, and check that the license covers your use before the content is loaded into Moodle. Keep the license file with the training records so the assessor can see that the content was used lawfully.
Who does what for Safeguard 14.9
Your organization owns Safeguard 14.9. Accountability for deciding which roles need specialized training, what each role must learn and whether the workforce has completed it stays with your leadership, security function and HR or learning owners. No partner or assessor can make those decisions for you, and an assessor will look for evidence that the decisions were made, approved and reviewed by your staff.
- Role matrix: Maintain a documented list of roles that need role-specific content, such as system administrators, web developers and staff in high-profile positions, and state the training expected for each.
- Content approval: Review and approve the courses, scenarios and materials used for each role, and record who signed off and when.
- Completion records: Track which workforce members received initial training and which completed refreshers on schedule, since these are the figures the assessment measures.
- Gap follow-up: Decide what happens when someone in a targeted role has not finished training, including access restrictions or escalation to management.
- Program review: Schedule and document periodic reviews of the role matrix as roles, systems and threats change.
Check that each of these items has a named owner and a dated record before any outside party begins work.
An implementation partner such as DeployOpen can prepare the systems, course content and evidence that support your training program, under a written scope agreed before work starts. The partner works inside your environment and at your direction. It does not decide which roles are targeted, does not certify that staff are competent and does not issue any report or attestation about Safeguard 14.9.
- Learning platform setup: Install, configure and harden a self-hosted learning platform, for example Moodle, inside your infrastructure, with user accounts linked to your directory where that is in scope.
- Course build: Build role-specific modules and assessments to the content your team approved, such as secure administration tasks, OWASP Top 10 exercises in a test application, or targeted social engineering scenarios.
- Completion reporting: Configure activity completion so the platform records when each learner completes each module, and produce exports that match the metrics your assessor will request.
- Evidence packaging: Organize course versions, approval records, completion exports and configuration screenshots into a folder your team can hand to the assessor.
- Written scope: Define deliverables, responsibilities and handover dates in writing, so your team knows exactly what the partner produced and what remains with you.
Confirm in the statement of work which artifacts the partner will hand over, who holds the administrator credentials after go-live and how the platform will be maintained.
An independent auditor, assessor or certification body tests Safeguard 14.9 and issues any formal result. Independence means the assessor is not designing the training, configuring the platform or preparing the evidence it reviews. If the same party does both, the assessment loses its value, and many buyers will not accept it as evidence.
- Testing approach: The assessor follows the Safeguard 14.9 measures in the CIS Controls Assessment Specification, checking initial training compliance and whether training is up to date across the in-scope workforce.
- Sampling and source checks: Expect the assessor to select roles and individuals, then compare platform exports against HR records and approved role matrices.
- Content review: The assessor reviews whether role-specific content exists and matches the roles it claims to cover, which is the basis for the failing condition if no such content exists.
- Reporting: Only the assessor issues the findings, report or certificate. Your partner and internal team supply evidence but never sign the conclusion.
- Boundary: Do not ask the implementation partner to write the assessor's conclusions or to validate its own work as the independent review.
Before engaging an assessor, confirm its independence from the team that built your training and ask which evidence it will sample.
Common gaps in role-specific training and how to close them
Most enterprises already run general awareness training, so the gaps under Safeguard 14.9 sit in the role-specific layer. Each gap below looks like compliance on paper but fails when an assessor asks who received which content, when, and whether it still matches the job.
Generic training labeled as role-specific
The most common gap is a single annual course renamed as role-specific content. Administrators, developers and finance staff sit through the same slides, so none of them learns the threats tied to their own systems. Check whether each role has its own course outline that names the tasks, tools and attacks that role faces. Close the gap by writing one short curriculum per role family, starting with the roles that hold privileged access or write production code.
No content for privileged staff
Administrators with access to directories, hypervisors, backup consoles and security tooling often receive no training beyond the general program. Their mistakes carry the largest blast radius, so the assessor looks for secure administration content aimed at them. Ask for the list of privileged accounts, map each holder to a secure administration course, and record completion against that list. Keep the content tied to the platforms your team actually runs.
No content for high-profile roles
Executives, board members, and staff who approve payments or handle sensitive client records are frequent targets of targeted social engineering. Safeguard 14.9 expects advanced social engineering awareness for these roles, not the standard phishing module. Define which roles count as high profile using a documented rule, such as access to payment approval or executive communications. Then deliver scenario-based sessions covering voice, video and executive impersonation requests.
Completion not recorded
Training that happens but leaves no record fails both metrics in the assessment specification, which measure initial training and up-to-date training across the workforce. Learning platforms can record completion when a learner views an activity, receives a grade, or ticks it manually, depending on how the activity is configured. Confirm which trigger matches each course, export completion data by role, and keep the export as dated evidence.
Content not reviewed
Role-specific content goes stale when tools, cloud consoles or application frameworks change. A course that teaches an old admin workflow or an outdated coding pattern will not help and will not satisfy an assessor checking up-to-date training. Assign each course an owner, set a review date, and log every change with the reason. Tie reviews to major platform upgrades so the content reflects what staff now run.
New hires, role changes and contractors missed
Training tied only to an annual campaign misses people who joined last month, moved into a privileged role, or work through a contractor agency. Their access may be broader than their training. Connect role-specific enrollment to the joiner, mover and leaver process so that a change in access triggers the matching course. Include contractors with system access in the same enrollment and completion records.
Safeguard 14.9 questions buyers ask before hiring help
Does Safeguard 14.9 apply to IG1 organizations?
No. Safeguard 14.9 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and not to IG1 organizations. IG1 covers essential cyber hygiene and is the minimum standard for every enterprise, so an IG1 organization still needs the general security awareness program under Safeguard 14.1, but it does not have to build role-specific courses to meet this safeguard. Confirm your Implementation Group against the CIS Implementation Groups pages before scoping work, because an enterprise that handles sensitive information or runs more complex operations may fall into IG2 even if it is small.
What drives the cost of role-specific security training?
The cost depends on how many roles need tailored content, how many people fill each role, and whether the content is built from scratch or adapted from existing material. The CIS Controls Assessment Specification scores this safeguard on the share of workforce members who received initial training and on whether training stays up to date, so the work is partly one-time content design and partly recurring delivery and refresh. Ask any provider to break a quote into content design, learning platform setup, delivery, tracking and annual updates, and to state which items they perform and which your team must provide.
How long does it take to build role-specific training?
Timing depends on the number of roles, the depth of each course and how quickly your subject matter experts can review drafts. The CIS Controls Assessment Specification does not set a duration, so no fixed timeline applies. A practical approach is to start with the roles that have the highest privileges or exposure, such as system administrators and web developers, and publish those courses first. Ask for a written schedule with review checkpoints, and confirm when the first completion records will exist, because the assessment looks for evidence of completed training.
What does the client team need to provide for this work?
The client team owns the role definitions, the list of workforce members in each role, and the threat scenarios that the training must reflect. It also needs to provide access to the learning platform, approval for content, and time from managers and subject matter experts. A partner can draft course outlines and exercises for administrators, developers or executives, but your security and HR leads must confirm that the content matches your environment, policies and tooling. Agree these responsibilities in the written scope before work begins.
Can our own team build this training in-house?
Yes, if you have people who understand both the security risks for each role and how to design learning. Many organizations split the work: internal staff own the policy links and role lists, while an outside specialist supplies technical course content such as secure administration or OWASP Top 10 material for developers. The CIS assessment specification measures whether role-specific content exists and whether people completed it, so the decision comes down to whether your team can produce, maintain and track that content every year. Be honest about the annual refresh effort, since that recurring work is where in-house programs often stall.
How do we show training completion as evidence?
Completion evidence is a dated record, per person, showing the role-specific course they took and when they finished it. Open-source learning platforms can produce this. For example, Moodle's activity completion can mark an activity complete when a learner views it, receives a grade, or ticks it manually, depending on the conditions set for the activity. Keep the course versions, the role mapping, the completion export and the update history together. An assessor will test whether the share of workforce members trained is accurate, so make sure your role list and your learning records match your HR directory.
Can a partner issue a certificate confirming we meet Safeguard 14.9?
No. An implementation partner can prepare the training, the tracking and the evidence, but only an independent auditor, assessor or certification body can issue a report or certificate. CIS Controls do not replace any regulatory or compliance scheme, and CIS does not issue certificates for individual safeguards. Ask any provider who will perform the independent assessment, and make sure your own auditor reviews the evidence package before you rely on it in a customer or regulator conversation.
What should a written scope for this safeguard include?
A written scope should name the roles covered, the training topics for each role, the delivery platform, the completion records to be produced and the annual refresh process. It should also state who approves content, who maintains the role list, and how completion is measured against the workforce. Ask for deliverables such as course outlines, role mapping, platform configuration, completion reports and a runbook for updates. Confirm that the scope references the CIS Controls Assessment Specification for Safeguard 14.9 so both parties agree on what the metrics measure.
How DeployOpen prepares role-specific training evidence
DeployOpen helps organizations build the records behind Safeguard 14.9 inside their own environment. The organization still owns its training program, decides which roles need role-specific content, and approves what is taught. DeployOpen plans, implements and hardens the self-hosted open-source learning and tracking platform that holds that content, configures course completion so each role's training is recorded, and sets up exports that show initial training compliance and up-to-date training for each role group. Where the organization already runs a learning management system, the work is to confirm which role-specific courses exist, how they map to the roles named in the program, and whether the records can be exported in a form an assessor can read.
Because the Safeguard is scored on whether the enterprise has role-specific content and whether training is current, the practical deliverables are a role matrix, course outlines for each role, completion settings, and a dated record of who completed what. For example, an illustrative engagement might cover secure administration for IT operations, a secure coding course for web developers, and an advanced social engineering module for executives, each with its own completion rule and review date. DeployOpen can prepare that structure and the evidence trail, but the content must reflect the organization's own systems, threats and policies.
Engagements are fixed-scope. The scope, deliverables, responsibilities and timeline are agreed in writing before work starts, and the quote follows from that written scope. DeployOpen does not publish a price list. Ongoing work such as updating role courses when systems change, upgrading the platform and refreshing completion records is available as a retainer. DeployOpen does not issue assessments, attestations or certificates. Any evaluation of Safeguard 14.9 is performed by the organization's own assessors or an independent assessor, and the organization should confirm with that assessor which records and formats they will accept before the work begins.
