A one page policy for a small team states scope, an owner, rules for adding and updating dependencies, build pipeline rules, how exceptions work and when it is reviewed. Keep it short enough that engineers read it, and write only rules you can actually follow and show evidence for.
Why one page
Long policies get signed and ignored. A buyer or auditor who asks for your policy mostly wants to see that rules exist, are specific, and match what you do. A short page is easier to keep true. Never write a rule you do not follow, since a false policy is worse than a missing one.
The sections
Purpose and scope
One sentence on why it exists, and which repositories and pipelines it covers. Name them or the group, such as all production repositories.
Ownership
Name the owner role and the backup role. Link to the escalation rule.
Dependencies
- Lockfiles are committed and CI installs from them.
- New dependencies are checked in the pull request, using dependency review or an equivalent.
- Known exploited vulnerabilities in shipped code are fixed or formally excepted within a stated number of days that you choose.
- Updates are applied on a stated cadence.
For the update cadence, see how often to update dependencies.
Build pipeline
- The main branch requires review and passing checks.
- Workflow tokens default to read only.
- Third party actions are pinned to a commit.
- Two factor authentication is required for the code host and registry accounts.
Exceptions
An exception needs a reason, an owner, a review date and written approval from the engineering lead. Exceptions expire. A rule with no expiry is not an exception, it is a policy change.
Review
The policy is reviewed once a year and after any incident.
Template layout
| Heading | Length |
|---|---|
| Purpose and scope | Two sentences |
| Ownership | Two lines |
| Dependencies | Four to five bullets |
| Build pipeline | Four bullets |
| Exceptions | Three sentences |
| Review | One sentence |
Matching the policy to evidence
Each line should map to something you can show: a screenshot of branch rules, an exported dependency list, a record of exceptions. The NIST Secure Software Development Framework describes practices at a high level and is a handy checklist if you want to see what a larger framework expects. Use it for ideas, not as a claim of conformance.
Do not state that you follow a framework or hold a certification unless you do and can prove it. Describe the practice instead.
Common mistakes
- Copying a large company policy and promising everything in it.
- Setting deadlines you cannot meet.
- Forgetting to link rules to evidence.
- Never revisiting after the first draft.
Safeguard policies, gates and guardrails can enforce several of these rules automatically and keep an audit trail. A free scan at https://gold.safeguard.sh/scan shows where you stand today.
Quick check
Do we need board approval for this policy?
Usually the engineering lead or founder approves it. Check your own governance and any customer or insurer terms.
Can we adopt a framework instead of writing our own page?
You can borrow from one, but a short policy that matches your practice is more honest and easier to evidence than a long one you do not follow.
Sources
- NIST SP 800-218, SSDF Version 1.1
- GitHub Docs, Secure use reference for Actions
- GitHub Docs, About protected branches
Last reviewed: 19 October 2026.
