Safeguard 16.9: Train Developers in Application Security Concepts and Secure Coding

“Safeguard 16.9: train developers in application security concepts and secure coding requirement” is an execution requirement, not a policy-only checkbox. CIS expects you to build and run a developer security training program that fits how your teams ship software, then demonstrate it runs consistently. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat developer training like any other control with clear control owners, defined scope, required frequency, and repeatable evidence capture. Your objective is simple: reduce preventable vulnerabilities introduced during coding and create a defensible record that secure coding training is part of normal engineering operations.

This page gives requirement-level implementation guidance you can hand to Engineering leadership and still use for audit prep. It focuses on practical decisions: who must take training, what topics must be covered, how to handle contractors and third parties, how to measure effectiveness without inventing metrics, and what evidence to retain so you don’t scramble at assessment time.

Regulatory text

Framework requirement (excerpt): “CIS Controls v8 safeguard 16.9 implementation expectation (Train Developers in Application Security Concepts and Secure Coding).” ¹

What the operator must do:
You must implement a training program for developers that covers application security concepts and secure coding, and operate it as a repeatable control. In practice, that means:

• Identify who counts as a “developer” in your environment (including contractors and third-party developers with commit rights).
• Assign training that matches the languages, frameworks, and delivery model you use.
• Track completion and keep records that show the training happens as designed. ¹

Plain-English interpretation

This safeguard expects more than annual security awareness. It expects job-specific secure coding training for the people who can introduce vulnerabilities into applications, APIs, infrastructure-as-code, and build pipelines.

If a person can:

• write application code,
• change configuration-as-code templates,
• modify CI/CD scripts,
• approve or merge pull requests,
• publish packages/images used in production,

then they are in scope for secure coding training under this safeguard in most operating models.

Who it applies to

Entity scope

Applies broadly to enterprises and technology organizations adopting CIS Controls v8. ¹

Operational scope (what environments trigger this control)

You should treat 16.9 as applicable if you have any of the following:

• In-house software development (product or internal apps)
• DevOps/SRE teams shipping platform code, automation, or IaC
• Use of contractors or third parties to build or maintain applications
• CI/CD pipelines that deploy to production or customer-facing environments

People scope (who must be trained)

Define roles by capability, not title. Common in-scope groups:

• Application developers (front-end, back-end, mobile)
• API developers
• DevOps engineers and build/release engineers (if they write pipeline code)
• QA/SDET staff who write test harnesses that touch auth/crypto/secrets
• Engineering managers and tech leads who review/approve code
• Contractors/third-party developers with repository access or commit/merge rights

What you actually need to do (step-by-step)

Step 1: Name a control owner and define the control statement

Assign an owner who can enforce completion (often Engineering Enablement, AppSec, or Security GRC with Engineering sponsorship). Write a one-paragraph control statement that includes:

• purpose (secure coding competence),
• scope (roles and systems),
• training standard (required topics),
• operating rhythm (assignment, refresh, exceptions),
• evidence produced.

Keep it in your control library so it’s easy to test and re-test.

Step 2: Build a role-to-training matrix (this is your backbone artifact)

Create a simple matrix with roles on one axis and training modules on the other. Example modules to consider:

• Secure coding foundations (input validation, authn/authz, session management)
• OWASP Top-style web risks adapted to your stack (injection, SSRF, XSS, CSRF)
• API security patterns (authz checks, object-level access control)
• Secrets handling (no secrets in code, vault patterns, key rotation expectations)
• Secure use of crypto (approved libraries, no custom crypto)
• Dependency risk (safe package management, lockfiles, SBOM expectations if you have them)
• Cloud/IaC secure patterns (least privilege, secure defaults, misconfig prevention)
• Logging and error handling (no sensitive data leakage)
• Secure code review expectations (what reviewers must check)

Avoid a single monolithic course for everyone. Auditors accept modularity when you can show coverage and assignment logic.

Step 3: Define the training triggers (hire, role change, and refresh)

Document the events that cause training assignment:

• onboarding into an in-scope role,
• access granted to source repos or CI/CD,
• promotion into reviewer/approver,
• stack change (new language/framework),
• periodic refresh.

You do not need to publish a specific refresh interval to meet the spirit of the safeguard, but you do need a defined standard and to follow it consistently.

Step 4: Implement delivery and tracking (LMS + code-host integration where possible)

Minimum viable operation:

• Assign training in your LMS (or equivalent system of record).
• Ensure completion status is reportable by user, role, and date.
• Enforce completion through access gates where feasible (for example, repo access request workflow asks for training status; CI/CD deploy permission requires training completion attestation).

If you can’t technically gate access, use managerial enforcement and quarterly exception review, and retain the enforcement evidence.

Step 5: Add practical reinforcement in the SDLC

Training alone is weak if your SDLC contradicts it. Tie the training program to at least one SDLC mechanism:

• secure coding standards linked in your engineering handbook,
• code review checklists that reference training topics,
• secure design review gates for higher-risk services,
• secure coding “office hours” or AppSec consult workflow.

This linkage helps in audits because it shows the training is embedded in how work gets done, not a one-off learning event.

Step 6: Prove effectiveness without inventing metrics

You can demonstrate effectiveness qualitatively and with existing engineering signals:

• reduction of repeat findings for the same flaw category in PR reviews,
• training quiz completion and score reports (if your platform provides them),
• evidence that high-risk teams received deeper modules,
• before/after examples of “secure patterns” adopted (for example, standard authz middleware introduced).

Don’t claim numeric improvement unless you can back it with your own measured data.

Step 7: Handle contractors and third parties explicitly

Common audit failure: “Employees completed training, but the contractor team writes most of the code.” Fix it with a clear rule:

• If a third party writes or changes code that will run in your environment, require comparable secure coding training completion (your course or an approved equivalent).
• Include this requirement in SOW/MSA language and onboarding workflows.
• Retain the third party’s completion attestations or training records.

Step 8: Operationalize evidence capture (make it routine)

Set a recurring evidence job (monthly or per release train, depending on how you run controls):

• Export LMS completion report for in-scope population.
• Export list of users with repo write/merge permissions.
• Reconcile deltas and open remediation tickets for overdue training.
• Store exports, reconciliation notes, and remediation outcomes in your GRC repository.

Daydream (or any GRC system you already run) becomes valuable here as the “control operation hub”: control description, owners, test steps, evidence requests, and time-stamped artifacts in one place. That eliminates last-minute evidence hunts.

Required evidence and artifacts to retain

Retain artifacts that answer four audit questions: who, what, when, and how enforced.

Minimum evidence set:

• Control statement for Safeguard 16.9 mapped to your SDLC ¹
• Role-to-training matrix and curriculum outline
• Training content (slides, vendor course outline, internal wiki pages, lab descriptions)
• Population definition (source of truth for developers: HR roster + repo access list)
• Assignment evidence (LMS assignment rules, onboarding checklist, access request workflow)
• Completion evidence (LMS reports with user, module, completion date)
• Exceptions and compensating controls (waivers, deadlines, managerial approvals, removal of access)
• Effectiveness signals (quiz results, secure code review checklist adoption, AppSec office hours logs)

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “Who is in scope?” Be ready to show your developer population logic and how you include contractors/third parties with commit rights.
2. “What training did they take, and is it relevant?” Provide curriculum mapping to your stack and application types.
3. “How do you ensure completion?” Show the enforcement mechanism: gating, workflow checks, or documented escalation.
4. “How do you know it works?” Provide reasonable effectiveness evidence tied to real engineering practices.
5. “Is training current?” Show refresh expectations and completion recency for the in-scope population.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Counting only “Software Engineer” titles	Misses DevOps, SRE, QA coders, contractors	Scope by access and capability (repo permissions, pipeline access)
One generic annual security awareness module	Doesn’t meet “application security concepts and secure coding” expectation	Build role-based modules and map to your stack
No evidence beyond “we have a course”	Auditors test operation, not intent	Keep assignment and completion reports plus reconciliation
Ignoring third-party developers	Real code risk sits outside HR roster	Require equivalent training and keep attestations
Training exists but SDLC encourages insecure patterns	Findings repeat; “paper control” perception	Tie training to code review checklists and secure standards

Risk implications (why operators care)

If developers don’t know your secure patterns, the organization absorbs:

• higher defect density in security-sensitive areas (authz, input handling, secrets),
• slower releases due to late-stage remediation,
• avoidable incidents caused by common coding errors,
• audit observations for weak control operation evidence.

CIS frames this safeguard as a practical baseline; failure is often treated as a governance maturity gap rather than a single missed task. ¹

Practical 30/60/90-day execution plan

You asked for speed. Use phases with concrete deliverables.

Days 0–30: Stand up the control and define scope

• Assign control owner and backup owner.
• Publish control statement and scope definition (roles, systems, third parties).
• Draft role-to-training matrix and pick delivery platform (LMS or internal).
• Build the “source of truth” lists: HR roster + repo permission exports.
• Start collecting baseline completion status (even if low).

Deliverable: control record + scoped population + initial training plan + baseline report.

Days 31–60: Launch training and start enforcement

• Assign training to all in-scope users.
• Add onboarding trigger (new hire into in-scope role).
• Add access trigger (repo write/merge requires training or deadline).
• Establish exception workflow and escalation path.
• Store the first evidence bundle (assignment proof + completion report + remediation tickets).

Deliverable: training live, measurable completion, repeatable evidence capture.

Days 61–90: Harden and prove repeatability

• Add stack-specific modules for high-risk teams (payments, identity, admin consoles).
• Implement SDLC reinforcement: secure code review checklist, secure coding standards page, or AppSec consult path.
• Run a second evidence cycle and reconcile deltas.
• Prepare an audit-ready packet: scope logic, training mapping, completion trend (qualitative is fine), exceptions, and enforcement examples.

Deliverable: sustained operation, not a one-time campaign.

Frequently Asked Questions

Who counts as a “developer” for Safeguard 16.9?

Anyone who can introduce code or code-like changes into production is in scope, including contractors and third-party developers with commit/merge rights. Define scope by capability and access, then document your logic. ¹

Is generic security awareness training enough?

No. This safeguard is about application security concepts and secure coding practices, which requires developer-focused content tied to how your teams build software. Keep awareness training separate from this control. ¹

Do we need to train engineering managers and code reviewers?

If they approve or merge code, treat them as in scope for at least reviewer-focused secure coding and code review training. Auditors often ask how reviewers are prepared to catch security issues before merge.

How do we handle third-party development shops?

Put secure coding training requirements into the SOW/MSA and require completion evidence (your training or an approved equivalent) before granting repo access. Retain attestations and access approval records.

What evidence is usually “make or break” in an audit?

A defensible in-scope population list, training assignment rules, completion reports with dates, and a record of how you handled non-completion (remediation tickets, access removal, or documented exceptions). Content alone rarely passes.

We build mostly infrastructure-as-code and pipelines. Does 16.9 still apply?

Yes, if teams write IaC, deployment scripts, or platform code that affects security controls and production behavior. Include modules on secrets handling, least privilege, secure defaults, and change safety for automation.

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8