SSDF task PO.2.3 asks for commitment to secure development from upper management or an authorizing official, communicated to everyone with development roles. Proof is concrete: a named accountable leader, a signed policy, resourced work in the roadmap, and a record that the message reached the team.
What the task says
PO.2.3 reads: obtain upper management or authorizing official commitment to secure development, and convey that commitment to all with development related roles and responsibilities. It is the one task in the PO group that is about people at the top rather than tools.
The NIST examples are specific. Appoint a single leader or leadership team responsible for the whole secure development process, including accountability for releasing software to production. Increase authorizing officials' awareness of the risks of building software without security. Help management include secure development in their communications. Educate staff on management's commitment and why it matters.
Evidence that is not a slogan
| What to show | Why it counts |
|---|---|
| Named accountable leader in the role map | Answers who is responsible for release decisions |
| Policy approved and dated by a leader | Shows sign-off, not just authorship |
| Security work in the planning backlog with owners | Shows commitment is resourced |
| All-hands or email message and attendance | Shows it was communicated |
| Review notes from a leadership meeting | Shows ongoing attention |
Each item is a normal business record. You do not need to create special paperwork for a reviewer.
A simple routine
- Pick the accountable leader and write the name in your role map.
- Ask them to approve your secure development policy and record the date.
- Add a standing agenda item to a leadership meeting each quarter: open security exceptions, overdue vulnerabilities, upcoming changes.
- Send a short message after each policy update so staff know what changed.
- Keep the notes in one folder.
What to avoid
- A generic statement that "security is everyone's job" with no owner
- Commitment documents with no date or approver
- Claiming leadership oversight that does not actually happen
If a buyer asks, answer with the facts you can show. "Our VP of Engineering is accountable for release decisions and reviews open security exceptions quarterly" is better than a paragraph of values.
Small company version
In a team of ten, the leader may be the founder or CTO. That is acceptable. What matters is that the accountability is written, the person knows it and the review actually happens.
How to word this for a buyer
When a buyer asks about leadership commitment, resist the urge to describe values. Describe mechanisms: who is accountable for release approval, how often leadership reviews open security items, and where the policy and its approval date can be seen. Offer to share the redacted meeting notes. Because the task is about people at the top, a short call between your leader and the buyer's contact can also help, though that is a business choice and not something the SSDF text asks for.
Quick check
Does PO.2.3 need a board resolution?
No. The task says upper management or an authorizing official. What counts as upper management depends on your organization.
Is a signed policy enough by itself?
It is a start, but pair it with evidence that the policy is used, such as meeting notes and backlog items.
If you want compliance records collected in one place, Safeguard offers compliance and evidence automation. You can also try the free scan 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.
