NIST SSDF version 1.1 asks organizations to provide role-based training for all personnel with responsibilities that contribute to secure development, review proficiency periodically, and update the training as needed. That is task PO.2.2. It does not name a course, a vendor or a number of hours.
Where the training task sits
The SSDF is NIST Special Publication 800-218, published in February 2022. Training lives in practice PO.2, "Implement Roles and Responsibilities", inside the group called Prepare the Organization. Three tasks make up the practice.
| Task | What it asks | Why it matters for training |
|---|---|---|
| PO.2.1 | Create new roles and alter responsibilities as needed, then review them periodically | You cannot train a role you have not defined |
| PO.2.2 | Provide role-based training, review proficiency, update training | The training task itself |
| PO.2.3 | Obtain upper management commitment and convey it | Training time needs a sponsor |
What the examples suggest
SSDF tasks come with examples. They are illustrations, not a checklist you must complete. For PO.2.2 the examples include documenting the desired outcomes of training for each role, defining the curriculum needed to reach those outcomes, creating a training plan per role, acquiring or building training (which may need customizing), and measuring outcome performance to find where training should change.
Notice the order. Outcomes come first, content second, measurement last. Many programs run it backwards: buy a catalogue, assign it to everyone, and count completions.
The PO.2.1 examples also mention security champions by name, among the roles an organization may define alongside software developers, testers, product owners and platform engineers.
A practical reading for an engineering team
- List the roles that touch your software lifecycle: developers, reviewers, release owners, platform engineers, product owners, security staff.
- For each, write one sentence on what they should be able to do after training. "Spot a missing authorization check in a pull request" is testable. "Understand security" is not.
- Pick the format per outcome: a hands-on lab, a review exercise, a short briefing.
- Record who completed what and when, and keep a sample of the work product.
- Set a review date. The text says periodically, so choose one and write it down, for example once a year or after a significant incident.
- Change the content when your findings change.
What the SSDF does not say
It does not set a minimum number of hours. It does not require a particular certification. It does not say training must be annual. Be careful with anyone who tells you it does. If an auditor or a customer asks for a specific cadence, that comes from their own policy or another standard, so ask them to cite it.
The SSDF is also a framework you map to, not an attestation by itself. Whether a customer asks you for a self-attestation form depends on who they are and their own obligations, so check with them rather than assuming.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one piece of evidence can be linked to controls in more than one framework.
Where Safeguard fits
Safeguard provides compliance and evidence automation, plus SBOM and dependency scanning, so scan results and policy records can sit next to your training records. You can try a free scan.
Quick check
Is SSDF training annual?
The SSDF text says to review proficiency and training periodically. It does not set a yearly cadence. Choose an interval you can defend and write it into your plan.
Do contractors count as personnel under PO.2.2?
The task covers all personnel with responsibilities that contribute to secure development. PO.2 also speaks of everyone inside and outside the organization who is involved in the lifecycle, so include contractors who write or review your code.
Sources
- NIST SP 800-218, Secure Software Development Framework version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
