A one page runbook lists the intake channel, the named roles, the steps from receipt to published advisory, the decisions that need approval, and the timeline targets you have committed to. Keep it in the repository next to your policy, review it quarterly, and test it once with a fake report.
The page, section by section
1. Channels
Where reports arrive: a security email alias, a private reporting feature on your code host, or a form. Name who watches each. State the one place the tracker lives and who can see it.
2. Roles
Intake owner, validator, fixer, communicator, and a named backup for each. See who does what on a team of five.
3. Steps
| Step | Owner | Done when |
|---|---|---|
| Acknowledge | Intake | Reporter has a reply with next date |
| Log | Intake | Case in tracker with owner |
| Validate | Validator | Outcome recorded |
| Score | Validator | Vector recorded |
| Decide scope and versions | Validator, fixer | Version map written |
| Fix privately | Fixer | Patch and test merged to private branch |
| Review | Second person | Diff and test plan approved |
| Release | Fixer | Fixed version shipped |
| Advisory | Communicator | Published, credit confirmed |
| Review | All | Actions with owners |
4. Decisions needing approval
Who can approve an emergency release, delay a release for a fix, extend a disclosure date, or tell customers before the public advisory. Name a person for each.
5. Timelines
Write the targets from your public policy, so they match. For the CERT Guide to CVD phases (discovery, reporting, validation and prioritization, remediation, public awareness, deployment), your page covers the middle four. Targets are yours to set; choose ones you can meet.
6. Templates
Links to the first reply, the extension request, the advisory template and the customer notice. See what to include in a security advisory.
7. Escalation
What to do if exploitation is seen, if details leak, or if the reporter threatens to publish early. Point to the incident process and the post on early public disclosure.
8. Records
What to keep after closure: the timeline, the fix link, the advisory, and the review actions.
Test it
Once a quarter, run a fifteen minute drill: send a fake report to the alias from a personal account, and watch who responds, how long it takes and whether the tracker is updated. Fix what the drill exposes.
Avoid
- A runbook that depends on one person.
- Promises in the runbook that exceed what the policy says publicly.
- Hiding the runbook where nobody can find it.
Try it yourself
The gate pull request demo shows how a rule can stop a risky change before it merges, the sort of control you might add after a case. Click through and see how a gate makes a decision.
Click through it at your own pace, or open it full screen.
Quick check
Is one page really enough?
For a small team, yes. If it grows past a page, nobody reads it during a real case. Link out for templates.
Should the runbook be public?
The policy should be public. The runbook can be internal, because it holds names and escalation details.
Safeguard's policies, gates and guardrails can automate checks on pull requests, and its compliance and evidence automation can help keep records. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
