A software company in its first security year needs six short policies: access control, change and code review, vulnerability handling, incident response, vendor management, and acceptable use. Each can fit on one page if it states who does what and how often. Write what you actually do, then improve it.
Policies are promises
A policy is a statement you will be asked to prove. Buyers read them, and auditors, if you pursue an audit, test whether you follow them. That is why a long policy borrowed from a template is a liability. Every sentence you cannot demonstrate is a gap waiting to be found.
Write short, specific, true statements. If you want something to be true next year, put it in the roadmap, not the policy.
The six policies
| Policy | Core content | Evidence it produces |
|---|---|---|
| Access control | Multi-factor sign-in, least privilege, joiner and leaver steps, periodic review | Access review records, removal tickets |
| Change and code review | Pull requests, review before merge, protected branches | Branch settings, merge history |
| Vulnerability handling | How findings are found, ranked, assigned and closed, and how exceptions work | Tracker history, exception log |
| Incident response | Roles, contacts, severity levels, communication, review after | Exercise notes, incident reports |
| Vendor management | Which vendors need review, notice of incidents, ownership | Vendor list, contract clauses |
| Acceptable use | What staff may do with devices, accounts and data | Acknowledgments |
How to write one in a page
- Purpose in one sentence.
- Scope. Who and what it covers.
- Rules. Five to eight plain statements, each testable.
- Roles. Who owns it and who approves exceptions.
- Review date. Policies without a review date become stale.
For example, the vulnerability handling policy might state that findings are assigned to a team owner within a stated working period, that known exploited vulnerabilities in internet facing systems are handled first, and that exceptions carry an expiry date. The CISA performance goals list patching or mitigating known exploited vulnerabilities in internet facing systems within a risk informed span of time as an outcome, which is a reasonable thing to reflect if you can keep it.
What to leave out for now
- Policies for activities you do not do. A data center policy for a company that runs wholly in the cloud invites questions.
- Numeric targets you cannot measure yet.
- Long lists of technology names that will change.
Keep policies and practice in sync
Review each policy against reality at the end of every quarter. If practice has drifted, change one or the other. The honest version of a policy beats an ambitious one every time.
If you are working toward a framework such as ISO 27001 or SOC 2, the same six documents form most of the base. Do not say a framework is complete until an independent party has said so, and describe an attestation as an attestation.
Safeguard's policies, gates and guardrails and its compliance and evidence automation help turn written rules into enforced checks and stored evidence. A free scan can show how your repositories look today against such rules.
Quick check
Can we copy a policy template?
Use it as a starting outline, then delete every line you cannot demonstrate and add the specifics of how you work.
Who approves policies?
Leadership, ideally the person who owns security plus the CTO or CEO. Record the date and version.
Sources
- CISA Cybersecurity Performance Goals (archived page that points to a newer version)
Last reviewed: 19 October 2026.
