Assign each SSDF practice group to a named role, not a team alias: platform owns toolchain and environments, engineering managers own code review and testing, product security owns vulnerability response, and a senior leader owns commitment. SSDF PO.2.1 asks you to define and periodically review these roles.
What PO.2.1 says
PO.2.1 asks you to create new roles and change responsibilities for existing ones so every part of the software life cycle is covered, then review and maintain them. The NIST examples list roles such as security champions, project managers, developers, testers, product owners and operations and platform engineers. They also suggest an annual review and a designated code owner group for each project.
A starter map
| Practice group | Typical owner | Evidence they hold |
|---|---|---|
| PO, prepare the organization | Head of engineering with product security | Policies, role list, training plan |
| PS, protect the software | Platform or release engineering | Repo settings, signing and archive records |
| PW, produce well-secured software | Engineering managers and tech leads | Design reviews, review records, test results |
| RV, respond to vulnerabilities | Product security or the on-call lead | Triage tickets, advisories, disclosure policy |
This is a suggestion, not NIST text. Small teams often have one person in two rows, which is fine if it is written down.
Steps to build yours
- List the SDLC activities you actually perform: design, coding, review, build, release, triage.
- Put one named person or role beside each activity.
- Add a backup for each, so a holiday does not leave a gap.
- Record who approves exceptions to your security requirements.
- Have each owner confirm their row, and save the confirmation.
NIST's PO.2.1 examples suggest educating affected individuals when responsibilities change and confirming they understand and agree. A short acknowledgment in your tracker covers that.
Common gaps
- A role that exists on the org chart but not in anyone's job expectations
- Release approval with no named accountable person
- Vulnerability triage that depends on whoever notices a message first
- Roles written once and never reviewed
PO.2.3 adds a related point: an upper manager or authorizing official should show commitment to secure development and communicate it. The example of appointing a single leader or leadership team accountable for releasing software to production fits naturally into the same document.
Where to keep it
Keep the role map in the same repository or wiki space as your other policies, with a review date at the top. When someone changes jobs, update it that week. An out-of-date map is worse than none, since it points a reviewer at a person who left.
Reviewing the map once a year
Set a yearly review, as the PO.2.1 examples suggest, and add extra reviews after reorganizations or when a key person leaves. In the review, read each row aloud with the owner and ask whether they still do this work, whether the backup knows they are the backup, and whether any activity has appeared that nobody owns. Save the dated result. A map that is reviewed and slightly imperfect is more credible than one that looks flawless but was written two years ago.
Quick check
Can one person hold several roles?
Yes. The point is that responsibilities are defined and reviewed, not that each has a separate person.
Do we need a dedicated security team?
NIST's examples mention integrating security roles into the development team and using security champions, so a dedicated team is not assumed.
Safeguard's policies and compliance evidence features can store who approved what, if you want records to live next to the checks. A free dependency scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
