Once a year, a small team should take a half day to step back and ask seven questions about its security program: what do we protect, what changed, what went wrong, which controls still work, which documents are stale, what do buyers now expect, and what are next year's priorities.
What an annual review adds
Monthly and quarterly routines keep things running. The annual review checks whether the whole program still fits the business. A team that doubled, added a product, or started selling to larger customers needs different controls than a year before.
OWASP SAMM, the Software Assurance Maturity Model, describes itself as an effective and measurable way for any organization to analyze and improve its security posture. You can borrow its idea of assessing, picking improvements and measuring again, without adopting the full model.
The seven questions
| Question | How to answer it |
|---|---|
| What do we protect? | Refresh the asset and data inventory |
| What changed? | New products, vendors, regions, customers |
| What went wrong? | Incidents, near misses, and open actions |
| Do controls still work? | Test: restore a backup, push to main, remove a test account |
| Which documents are stale? | Check review dates on the five core documents |
| What do buyers expect now? | Read the last year of questionnaires for repeat asks |
| What are next year's priorities? | Pick three, with owners |
A half day agenda
Hour one: inventory and changes. Hour two: incidents and actions from the quarterly records. Hour three: control tests. Hour four: documents and buyer expectations. Final half hour: priorities.
Have each owner bring evidence. The review should run on records and tests, not on opinions.
Test the controls, do not assume
A control that existed last year may have drifted. Try the checks: can a former contractor still sign in, does a pull request with a failing check merge, does the backup restore, does the alert reach a person? Record each result. A failed check is a good finding, not a problem with the review.
Use a framework as a lens, lightly
A framework helps you ask what you forgot. The NIST CSF and CIS Controls IG1 are common ones for small teams, and posts like using NIST CSF 2.0 for a first year roadmap show how. Use it for a gap check, and do not claim compliance with a framework unless you have actually met its requirements.
Output
A two page summary: findings, decisions, three priorities, owners, and the date of the next review. Share it with leadership and file it with your other dated records.
Where Safeguard fits
Safeguard offers compliance and evidence automation and framework mapping to help organize the evidence side of a review. Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Click a control and see how evidence maps to it, which is the gap check from the fourth hour.
Quick check
Can we skip it if quarterly reviews happen?
The annual view asks different questions, such as whether the program still fits the business. Keep it, but make it short.
Do we need a framework?
No. A framework is a useful checklist for gaps. Do not claim compliance unless you have met the requirements.
Sources
Last reviewed: 19 October 2026.
