A one page vulnerability prioritization policy has six parts: scope, the signals you use, the priority tiers, response times per tier, the exception process, and ownership. Keep it short enough that engineers read it. Put the detail in procedures that link from it, not in the policy itself.
Why one page
Long policies are written for auditors and read by nobody. A short one gets used in triage meetings, which is the point. NIST's patching guide recommends defining maintenance plans for each group of assets and each risk scenario, and a one page policy is the front door to those plans.
The six sections
1. Scope. What it covers: applications, dependencies, container images, infrastructure. Say what is out of scope and who handles it.
2. Signals. The inputs used to rank, in the order you apply them. A common set is evidence of exploitation, exposure, whether the vulnerable code is reachable, asset importance, and severity score. Name your sources, such as CISA's Known Exploited Vulnerabilities catalog and EPSS.
3. Priority tiers. Three or four named levels with plain entry criteria.
4. Response times. One target per tier, plus when the clock starts.
5. Exceptions. Who can approve, what must be recorded, maximum length, and when it is reviewed.
6. Ownership. Who owns triage, who owns fixes, who reports, and who is on call for urgent items.
Fill in outline
| Tier | Entry criteria (example) | Response (set your own) | Approver for delay |
|---|---|---|---|
| Urgent | Known exploited, or high severity and exposed and reachable | Emergency path | Head of engineering |
| High | High severity and reachable, no exploitation evidence | Within the current sprint | Team lead |
| Standard | Reachable but low exposure, or medium severity | Normal planning cycle | Team lead |
| Low | Not reachable, or low severity | Fix when touching the code | Owner |
Do not copy example numbers from someone else's policy. Choose response times your teams can actually meet, then tighten them as the process matures. A deadline you routinely miss teaches everyone to ignore deadlines.
What to leave out
- Tool names and menu steps. They change and belong in procedures.
- Long lists of severity definitions. Link to the standard instead.
- Promises about zero vulnerabilities. See why zero backlog is not zero risk.
Add the rules people forget
Say how unpatchable items are treated: NIST suggests giving them their own maintenance group rather than a pile of exceptions. Say what happens during a change freeze. Say how often the policy itself is reviewed.
Try it yourself
Open the demo and look at how a gate can turn a written rule into a check on a pull request. Think about which line of your policy could be enforced this way.
Click through it at your own pace, or open it full screen.
Quick check
How often should the policy be reviewed?
At least once a year, and after any incident or major change in tooling. Record the review date on the page.
Should the policy name specific scanners?
No. Name the signals and sources of data. Tools change faster than policy.
Safeguard's policies and gates feature lets teams express rules like these as checks that run in the pull request flow, and there is a free scan at gold.safeguard.sh/scan to see current findings first.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities Catalog
- FIRST, EPSS frequently asked questions
Last reviewed: 19 October 2026.
