Safeguard 16.9 Secure coding training for developers

What Safeguard 16.9 secure coding training for developers requires

Safeguard 16.9 requires that every person who writes software for the enterprise receives training in secure coding for the environment they work in and the responsibilities they hold, and that this training happens at least once a year. It sits in Implementation Group 2, so an IG2 or IG3 organization that builds or customizes software needs it, while an IG1 organization does not. If your teams ship code, a regulator, customer or assessor will expect you to show who was trained, on what, and when. The CIS Controls Assessment Specification scores the safeguard with a compliance measure: the share of software development personnel who have completed all the appropriate training courses in scope. That makes the population and the course list the two decisions that determine whether you pass.

The phrase "their environment and responsibilities" is what separates this safeguard from generic awareness training. A backend engineer working in a Java service, a frontend developer handling browser code, and a platform engineer writing infrastructure templates each face different classes of flaws, so the content should reflect the languages, frameworks and deployment paths they actually use. Safeguard 16.9 is the developer-specific counterpart to 14.9, which covers role-based training for the wider workforce. Where 14.9 teaches people to recognize risks in their roles, 16.9 teaches the people who create the code to prevent those flaws in the first place. Both are needed, and an assessor will look at whether developers are not simply covered by the general program.

Three things usually make this hard. First, defining the population: contractors, offshore teams, DevOps staff, data engineers and anyone who commits code must be identified, and a roster from the HR system rarely matches the list of people with repository access. Second, tracking completion across teams that use different learning tools or none at all, so start with one system of record that ties course completion to identity. Third, proving the content is current. Ask your training provider or internal team to show the version, date and the languages and frameworks each course covers, and check that they match your current stack. Confirm these details with your assessor before you build the evidence pack, since the expected granularity of records varies by organization and by the framework that also applies to you.

Which developers and environments fall under Safeguard 16.9

Safeguard 16.9 applies to all software development personnel, but who counts as a developer and where they work changes the training population and the evidence you must keep. The cards below cover the scoping decisions that most often change the work, starting with the implementation group that makes the Safeguard applicable.

Implementation group applicability

Safeguard 16.9 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and not to IG1. An IG1 organization that builds its own software can still use the training as good practice, but it is not the Safeguard's measured scope. Confirm your IG against the Safeguards you have adopted in your own documented scope, because an enterprise that writes code often has more than IG1 operational complexity. The Safeguard is assigned to the Users asset class and the Protect security function, which tells the assessor it is a people control tied to protecting software.

Employees and contractors who write code

Scope follows the work, not the employment contract. Full-time employees, fixed-term staff, contractors and temporary engineers who write, review or deploy code all belong in the population of software development personnel. Contract terms should require them to complete the same secure coding training, and your records should show the course completions for each person regardless of how they are engaged. Ask HR and procurement to flag contractor onboarding so that no one who commits code is missed.

Offshore and outsourced development teams

Work done by an outsourced or offshore team is still development work under your control, so the training requirement reaches those people through the contract. Specify in the statement of work that each team member must complete training for your languages and environment, and ask the supplier for completion records that you can sample. Your Safeguard 16.9 evidence must cover the vendor's developers, even though the vendor delivers the course. Confirm this with your contract and service provider management process before the work starts.

DevOps and platform engineers who write code

Infrastructure-as-code, pipeline scripts, operators and automation written by DevOps or platform engineers are code, and the people who write them are software development personnel for this Safeguard. An engineer who only runs a managed pipeline without writing code may fall outside scope, so decide the boundary by what each role commits to repositories. Record the decision in writing, because assessors will ask how you chose the population and whether anyone who commits code was left out.

Development environments and languages in use

Training must address secure coding for each development environment and responsibility in your organization. A team building a Java web service, a team writing Terraform and a team maintaining mobile clients each face different weaknesses, so a single generic course may not satisfy the requirement for all of them. Inventory the languages, frameworks, repositories and pipelines in use, then map each developer group to the content it needs. This list also determines which tools, such as Semgrep Community Edition, you will reference in training.

Measuring the population with the Compliance metric

The assessment specification scores Safeguard 16.9 by the share of software development personnel who have all appropriate training courses in scope. That means the denominator is your defined developer population, so an incomplete list inflates the score. Keep a current roster that links each person to their roles and environments, and reconcile it against repository access and pipeline permissions at least each year. Auditors will sample the roster against the code history, so the roster must be accurate for the period they test.

How an assessor tests Safeguard 16.9

This table walks through the points an assessor checks when measuring Safeguard 16.9 against the CIS Controls Assessment Specification, from the population list to completion records and timing. Read each row as a question the assessor will ask and the evidence the organization should have ready before the review starts.

Assessment point	What the assessor checks	Evidence that passes	Where it usually fails
Prerequisites	The assessment specification lists no prerequisite safeguards, so the assessor tests the training measure directly	A current training record set and the list of personnel it covers	Teams assume a secure development process must be proven first and delay the measurement
Population list	Every person who writes, reviews, tests or deploys code, including contractors and offshore teams	A roster reconciled against repository access, CI/CD permissions and HR or vendor records	The list covers employees only and omits contractors, interns and outsourced developers
Course mapping to environment	Each course addresses the languages, frameworks and tooling the person actually uses	A course-to-role matrix naming the languages and frameworks in each development environment	Generic awareness content is counted as secure coding training for specialized stacks
Compliance metric	The share of software development personnel who hold all appropriate courses in scope	A simple count of in-scope personnel and those with every required course completed, with the scope rules written down	The scope definition changes between reporting periods without a record of why
Completion records	Each completion is traceable to a named person, a course version and a date	Learning management system reports with user, course, version and completion timestamp	Completion is recorded by attendance sheets or verbal confirmation that cannot be linked to a course version
Timing against the annual cadence	Training is delivered at least once in each annual period, including for new joiners	Dated records covering the review window, plus onboarding completion for recent hires	Records show a single training event years earlier, or new developers have no completion date
Stale content	Course material reflects current languages, frameworks and secure coding practices in use	Content review dates, version history and a note of what changed since the last cycle	Courses still reference retired frameworks or older platform versions with no review on file
Training tied to role	Responsibilities such as reviewers, release engineers and API owners receive the topics relevant to them	A role-to-course mapping that shows additional content for higher-risk responsibilities	Every developer receives the same generic module regardless of the code they own

How to implement secure coding training for developers in six steps

This sequence turns Safeguard 16.9 into a roster, a training matrix and a completion record that show every developer in scope has been trained on secure coding for their own environment within the required annual cycle.

Define the developer population in scope
Build the list of software development personnel from source control activity, such as committers and reviewers on in-scope repositories, cross-checked against HR and contractor records so that employees, contractors and temporary staff are all captured. Your engineering manager and HR lead own the roster, and the security function signs off on it. The step is done when the roster has one owner, a refresh rule for joiners, movers and leavers, and a written record of who was excluded and why.
Map languages and frameworks to training tracks
Inventory the languages, frameworks, build tooling and cloud platforms each team uses, then group people into tracks by what they actually write and deploy. A backend Java team, a frontend TypeScript team and an infrastructure-as-code team face different risks, so Safeguard 16.9's requirement to train for the specific development environment depends on this mapping. The output is a course-to-environment matrix that lists each track, its languages and its required modules, and that the application security lead approves.
Select or build the courses
Choose vendor, open-source or in-house courses that cover secure coding for each track, then confirm each one teaches the tracks' languages and frameworks and includes practical exercises on the flaws that matter for that stack. Ask providers which languages and versions their content covers and how completion is recorded. Your team reviews the material before rollout. The step closes when each track has an approved course set and a written note on any gaps that still need custom content.
Set completion rules in the learning platform
Configure the learning management system so that each course records a completion event that auditors can trust. 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 you set, so choose the condition that proves understanding (typically a graded assessment) and document it. Set up the matrix so each person's required courses are visible. The step is done when a test learner's record shows the expected completion state for every required course.
Schedule the annual training cycle
Set a recurring training calendar for each track, assign due dates from the annual requirement, and define the escalation path for people who miss them, such as manager notification and access restrictions if your policy allows. Link the cycle to onboarding so new developers complete the required training before they are granted write access to in-scope repositories. Confirm the calendar with the security and engineering leads. The step is done when the schedule, reminders and escalation rules are written down and the first cycle is assigned.
Report the compliance metric
Calculate the share of software development personnel who have completed all appropriate training courses in scope, which is the metric the CIS assessment specification uses for this Safeguard. Reconcile the numerator and denominator against the roster from step one, and retain a dated report with the course list, the roster version and any exceptions with approved reasons. The owner is the security function, reviewed with engineering leadership. The step is done when the report can be reproduced from the source records and an independent reviewer can trace each figure to a learner record.

How the compliance metric turns training into a measurable share

The CAS scores Safeguard 16.9 with a Compliance metric: the share of software development personnel with all appropriate training courses in scope. The numerator is the set of developers who have completed every course that applies to their environment and responsibilities. The denominator is every person who writes, reviews, tests or deploys software for the enterprise, including contractors and staff in platform or DevOps roles who change code or pipeline configuration. A fraction is only as credible as its denominator, so the population list is the input an assessor scrutinizes most. Ask for the source of that list and compare it against your identity provider groups, repository membership and CI/CD permissions. A developer missing from the list makes the share look better than it is.

Training records must show that the courses match the environment. A generic awareness module does not establish that a Java team learned to avoid injection flaws in its own frameworks, or that a team deploying infrastructure as code understands its misconfiguration risks. Map each course to a language, framework or role, and keep records showing the content, completion date and the people who took it. In Moodle, activity completion can be configured to mark an activity complete when a learner views it, receives a grade or ticks it manually, so decide which condition counts as completion for secure coding material and document that choice. A tick-box that a learner can set without engaging with the content is weak evidence.

New joiners and role changes need explicit rules, because the numerator and denominator both move. Define when a new developer must complete the in-scope courses, such as before receiving repository write access, and record the date the access was granted alongside the date training was completed. When a person changes role, for example from a backend developer to a platform engineer, reassess which courses apply and add any that are new. Confirm with your assessor how the annual cycle treats people who joined partway through the period, since the measurement window determines whether they count. Set these rules in writing before the first measurement so the metric does not drift.

Which training records pass as evidence

An assessor measuring Safeguard 16.9 wants to see that every software development person was trained, on courses that fit their language and role, within the last year. The cards below cover the records that show this, and how to keep them accurate between assessments so the compliance figure stays true.

Current developer roster

The denominator for the Compliance metric is the list of software development personnel in scope, so the roster is the first artifact an assessor asks for. Include employees, contractors and anyone who commits code or reviews pull requests, and record each person's team, language stack and role. Check that the roster matches who actually has write access to repositories, because a developer missing from the list inflates the apparent training rate. Illustrative example: a contractor with merge rights who never appears on the roster will not be counted, and the gap will surface during testing.

Course catalog mapped to roles

Each developer needs courses for their environment and responsibilities, so keep a catalog that ties every course to a language, framework or role. A Java backend team, a frontend team and a platform team will need different content, and the catalog should show which courses each group must complete. Record the mapping in version control so changes are dated and reviewable. An assessor will check that the courses named in the plan genuinely match the stack in use, not a generic list.

Dated completion records

Completion records are the core proof that training happened, and each one needs a learner, course, date and outcome. If you use Moodle, activity completion can mark an activity complete when a learner views it, receives a grade, or ticks it manually, depending on the conditions set. Confirm which trigger each course uses, because a course marked complete on page view proves less than one tied to a graded assessment. Export these records with timestamps so the annual window can be checked.

Grades and quiz results

Where a course uses a quiz or assessment, keep the grade and attempt history alongside the completion record. A grade shows that the content was understood, which is stronger evidence than attendance or page views alone. Decide and document a passing threshold and what happens when a developer fails, such as a retake deadline or restriction on merge rights. Confirm with your assessor whether they expect grades for every course or accept completion for lower-risk topics.

Annual training plan and dates

A written training plan shows the annual schedule, the courses due in each period and who owns the program. Record the due date for each developer's cycle and the date each plan was reviewed, so an assessor can see that training recurs at least once a year rather than as a one-off launch. Tie the plan to the secure development process in Safeguard 16.1 so the training content reflects the design standards and coding practices the organization has adopted. Ask your assessor how far back they will review plan revisions.

Contractor and vendor training records

Contractors who write code for the organization fall under Safeguard 16.9 even when another firm employs them, so their training records must be collected or attested. Put the requirement in the contract, and request completion evidence from the vendor on the same cycle as employees. Where a vendor cannot provide course-level records, document the attestation, the course they completed and the date. Inconsistent treatment of contractors is a common reason a compliance figure fails to reconcile with the roster.

Quarterly roster reconciliation

Between assessments, reconcile the training roster against your identity provider and source control at least quarterly. Compare active accounts and repository write access with the developer list, then add new joiners, remove leavers and flag anyone without a current completion record. This keeps the Compliance metric accurate without a last-minute scramble. Automate the comparison where possible, and retain each reconciliation snapshot, since the snapshot shows the list was maintained over time.

What meeting Safeguard 16.9 costs in money and effort

This table breaks down the money and staff time behind annual secure coding training for developers, separating one-time setup from recurring work. Read each row for who is paid, whether the cost is one-time or recurring, and what pushes it up or down. The main takeaway is that open-source learning platforms reduce license spend, but the largest share of cost is developer time and content tailoring, which no platform removes.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Course content	Internal security engineers, a training vendor or a consultant who builds or licenses developer courses	One-time build, then recurring refresh	Number of languages and frameworks, and whether courses use your own code examples
Learning platform	Vendor license or hosting staff if self-hosted (for example, Moodle, which is GPL-3.0-or-later)	Setup is one-time, hosting and upkeep recur	Whether you already run an LMS, and whether you self-host inside your own infrastructure
Developer time	Each software development employee, paid as salaried or contracted engineering time	Recurring, at least annually, plus onboarding for new hires	Headcount, team turnover, and length of each course or assessment
Environment-specific tailoring	Trainer or consultant who maps courses to your stacks, secure coding standards and internal policies	Mostly one-time, with updates when stacks change	Number of development environments and how much your code and processes differ from generic material
Tracking and reporting	Training coordinator or compliance lead who pulls completion data for the assessment metric	Recurring, usually tied to each review cycle	Whether completion is tracked automatically in the platform or compiled by hand from spreadsheets
Assessor sampling	Your staff preparing evidence, and the independent auditor who samples developers and checks records	Recurring, at each audit or assessment	Size of the developer population, and how cleanly records map to individual developers and roles
Platform license spend	Vendor license fees for a commercial learning system	Recurring license fees	Open-source platforms can remove this line, but staff time for setup and support stays
Ongoing support and upgrades	Internal platform team, or an implementation partner under a retainer if you choose one	Recurring	Scope of support agreed in writing, and how often the platform is patched and upgraded

Open-source tools that support the training evidence

Moodle is a learning management system licensed under GPL-3.0-or-later, and it can host secure coding courses in your own infrastructure. Its activity completion feature records whether each learner has met the completion conditions for an activity, which gives you a per-person record that an assessor can sample. Completion is not automatic in every case. Depending on how each activity is configured, it can be marked complete when the learner views it, when they receive a grade, or when they tick it manually, so the configuration is itself part of your evidence.

Per-learner records: Completion status is stored for each user and activity, which lets you show who finished the course and when.
Condition choice: Use graded assessments or quizzes where you need proof of understanding, rather than relying on page views alone.
Role-based enrollment: Enroll only software development personnel in the course so the population matches the safeguard's scope.
Annual cycle: Reset or reissue the course each year so the record shows training at least annually.
Export for sampling: Keep completion reports and course configuration exports with your training policy.

Before you rely on this tab, confirm with your team how each activity's completion conditions are set and document them, since an assessor will ask what "complete" means for each course.

Where organizations fall short on developer training

Most gaps against Safeguard 16.9 come from who is counted, what is taught, and whether anyone can prove it happened. The cards below cover the failure points an assessor is likely to test, with a closure action for each so the program can show completion for every developer, every year.

Incomplete developer population

The safeguard covers all software development personnel, but many rosters list only employees on the engineering payroll. Contractors, offshore teams, platform engineers who write infrastructure code, and staff who script pipelines are often left out. Build the population from source control commit access, CI/CD permissions and repository ownership rather than from an HR list, then reconcile it each quarter. Ask who owns that reconciliation and how new joiners are added before their first commit.

Generic awareness instead of coding training

A general security awareness module about phishing does not teach a developer how to prevent injection in the language and framework the team actually ships. Safeguard 16.9 asks for secure coding for the developer's specific environment and responsibilities, so the content should name the languages, frameworks, cloud services and pipelines in use. Check whether each course maps to the weaknesses found in the organization's own code reviews and scan results, and document that mapping.

Training without completion records

Teams often run a workshop or share a video link but keep no record of who finished it or what they were tested on. The assessment measures the share of personnel with all appropriate courses completed, so the number must come from a system that stores per-learner status. A learning management platform such as Moodle can record activity completion per learner, but the rule for what counts as complete (viewed, graded or manually ticked) must be set and written down before the course opens.

Annual deadlines missed without tracking

The safeguard requires training at least annually, yet many programs run once at onboarding and never repeat it. Without a due date per developer, lapses go unnoticed until an audit. Assign each person a training date, generate reminders before it expires, and block or flag access to protected repositories when a course is overdue, if the organization chooses that enforcement. Confirm with the tooling owner which of these controls the platform supports before promising them.

Content that lags current standards

Secure coding material written for an older framework version or an unsupported language release can teach patterns that no longer apply. The CIS Controls Navigator maps Safeguard 16.9 to NIST SP 800-53 Rev. 5 controls SA-8 and SA-16, to ISO/IEC 27001:2022 Annex A control 8.28, and to PCI DSS v4.0 requirement 6.2.2. Review each course against the mapping that applies to the organization's frameworks at least once a year, record the review date, and retire material that no longer reflects the code base.

Questions buyers ask about Safeguard 16.9 training

Does Safeguard 16.9 apply to every organization using CIS Controls?

No. Safeguard 16.9 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1 organizations. IG2 adds Safeguards for enterprises with more operational complexity that often hold sensitive information, and IG3 targets enterprises with security specialists and regulated, sensitive assets. Confirm your Implementation Group before scoping training work, because a smaller organization that only targets IG1 will not be measured against this Safeguard. The requirement itself is that all software development personnel receive secure coding training for their own environment and responsibilities, at least annually.

Can we run secure coding training in-house without an outside partner?

Often yes, if you have someone who can design role-specific content and keep records. The work has three parts: choosing or writing the course material for your languages and frameworks, delivering it and tracking completion, and producing the annual cycle records an assessor will ask for. Teams with a training lead, a senior engineer willing to own technical content, and an LMS-style tracking tool usually find the in-house route workable. Outside help tends to make sense when no one internally can judge whether the content matches your code, or when you need the program built and handed over with documentation.

How long does it take to set up the first training cycle?

The setup duration depends on how many development teams you have, how many languages and frameworks they use, and whether training material already exists. Plan for separate phases: defining the audience and roles, selecting or building courses for each environment, configuring the tracking system, and running the first full cycle with records. No timeline figure is supplied for this Safeguard, so ask any partner or internal lead to give a duration tied to a written scope, and confirm how many cohorts and courses that scope includes.

How much effort does the training cost in developer and manager time?

The largest recurring cost is developer time away from delivery work, multiplied by headcount and the number of required courses. Managers spend time confirming which roles are in scope, approving schedules and following up on overdue completions. Costs rise with more languages, more distinct development environments, higher staff turnover (which adds new joiners who need training) and course material that must be rewritten for each team. Ask any quote to break out one-time content development from annual delivery and tracking, and to state the number of learners and courses assumed.

Can a partner build the course content and run the training for us?

Yes, a partner can prepare and deliver the program as part of a fixed-scope engagement, provided the scope, deliverables and timeline are agreed in writing before work starts. DeployOpen implements and documents self-hosted open-source platforms inside your own infrastructure, so a training platform such as Moodle would be deployed and configured in your environment, with your records staying under your control. Confirm with any provider who writes the technical content, who maintains it after handover, and whether ongoing content updates are included or offered as a retainer.

What evidence will an auditor ask for to test Safeguard 16.9?

The assessment specification measures this Safeguard with a compliance metric: the share of software development personnel who have completed all appropriate training courses in scope. An assessor will therefore want the list of in-scope developers, the course or curriculum that applies to each role and environment, and completion records dated within the annual window. Keep the training policy or plan, the role-to-course mapping, and records that show who completed what and when. Confirm with your auditor how they want population lists sourced and how they treat contractors and new joiners.

How do open-source learning and tracking tools help produce that evidence?

A learning management system can produce completion evidence automatically. Moodle, which is licensed under GPL-3.0-or-later, has activity completion that marks an activity complete for each learner when they view it, receive a grade from it, or tick it manually, depending on the conditions set for the activity. Configure completion conditions so that a course counts only when the required modules are passed, and export records regularly. Confirm with your assessor whether a view or manual tick is sufficient evidence of training, or whether graded assessments are expected.

How DeployOpen prepares Safeguard 16.9 evidence

DeployOpen works on Safeguard 16.9 as an implementation partner inside your own environment. We set up the training records, the developer learning platform and the evidence your organization needs to show that every software development person completed role-specific secure coding training at least annually. Your organization owns the control and the program; only an independent auditor or assessor issues any report.

How we scope

We agree a written scope that lists the development teams, roles and repositories in Safeguard 16.9 before any work starts.
We confirm which secure coding topics apply to each language, framework and environment your developers use.
We define the annual training cycle, the completion threshold and the compliance measure the CIS assessment specification uses.

How we build

We configure a self-hosted learning platform, such as Moodle, with course structures per development role and environment.
We set activity completion conditions so a course is marked complete only when the learner meets the criteria you approve.
We connect repository access controls, such as GitLab protected branches, to the training status your policy requires, where your setup supports it.

How we hand over

We deliver the training records, completion reports and the compliance calculation method, documented for your assessor to review.
We document how the annual cycle runs, who owns each course and how new developers are enrolled before their first commit.
We hand over runbooks so your team can run the platform, update courses and produce the evidence without us.

How we support

Ongoing support, upgrades and course maintenance are available as a retainer, aligned to your annual training cycle.
We can keep the completion records current as teams, languages and tooling change during the year.
Confirm with your auditor or assessor which evidence format and retention period they require before we finalize the handover.