For supply chain security, a policy states intent and authority, a standard sets measurable rules, a procedure lists steps to follow, and a guideline offers advice that people may adapt. Sorting content this way keeps the policy short and lets the details change without a leadership vote.
Definitions
| Document | Answers | Changes | Approved by |
|---|---|---|---|
| Policy | Why, who, with what authority | Rarely | Executive |
| Standard | What must be true, measurably | When risk or tooling changes | Review group |
| Procedure | How to do a task, step by step | Often | Process owner |
| Guideline | What good looks like, optional | Whenever useful | Anyone responsible |
NIST SP 800-161 Rev. 1 describes a policy as establishing the program's purpose, outlining responsibilities, granting authority to roles and setting enforcement expectations. That is the top row. The detail beneath it belongs elsewhere.
An example for dependencies
Policy statement: third-party software used in our products is reviewed before adoption and monitored while in use, under the authority of the supply chain review group.
Standard: every production service has a current software bill of materials. Components with known exploited vulnerabilities are remediated within the agreed window or covered by an approved, time-limited exception. Licenses outside the allowed list require legal review.
Procedure: how to request an exception. Fill in the form, attach evidence, post to the queue, the review group decides at the next meeting.
Guideline: how to pick a well maintained library. Check release cadence, maintainer count, open advisories.
Why the split helps
- Auditors and customers ask for the policy. It should be readable in five minutes.
- Engineers need the standard and the procedure. They should find them in the repository or developer portal, not in a PDF.
- When a new tool arrives, just the procedure changes.
SSDF practice PO.1.1 mentions defining policies for software development processes, including for open source and other third-party components, and reviewing requirements at least annually. Whatever structure you choose, give each document a review date and an owner.
How to sort what you already have
- Gather every document that mentions third-party software.
- Tag each paragraph as intent, rule, step or advice.
- Move rules into a standard, steps into procedures, advice into guidelines.
- Cut the policy to what is left. Aim for one page.
- Link everything together and assign owners.
Common mistakes
- Putting tool names in the policy, which forces a policy rewrite whenever tooling changes.
- Writing standards that cannot be measured.
- Letting procedures drift from practice. Check them by watching someone follow them.
For a ready example of the rule layer, see dependency policy one page template.
Try it yourself
Click through it at your own pace, or open it full screen. Treat the gate as the standard in action, and ask which procedure a blocked developer would follow next.
Safeguard's policies, gates and guardrails apply the standard layer automatically on code changes, and its compliance and evidence automation keeps records that the rules ran.
Quick check
Should the policy name specific tools?
No. Name outcomes and authority. Tools belong in procedures.
Where do exceptions go?
The policy says exceptions are allowed with expiry. The procedure describes the process.
Sources
Last reviewed: 19 October 2026.
