Judge security docs by whether people find correct answers quickly and follow them: fewer repeat questions in chat, fewer failed searches, fewer pages past their review date, and runbooks that pass a cold read. Page views alone mislead, because a confusing page can be popular.
Why page views are a weak signal
A page with many visits might be essential, or it might be a confusing page everyone has to open three times. A page with few visits might be unneeded, or it might be buried. Views need context from other signals.
Five measures that tell you something
| Measure | How to collect it | What a bad result means |
|---|---|---|
| Repeat questions | Tag questions in chat, count duplicates per month | A page is missing, hidden or unclear |
| Failed searches | Read the search log for zero result and no click queries | Vocabulary gap or missing page |
| Stale share | Pages past review date divided by total pages | Ownership is not working |
| Runbook test results | Cold read findings per runbook | The runbook would fail in an incident |
| Time to answer | Ask five engineers to find three answers, time them | Structure or titles need work |
None of these need analytics software. A spreadsheet and thirty minutes a month are enough to start.
A simple monthly review
- Pull the counts above.
- Pick the worst two. Ignore the rest this month.
- Choose one fix for each, such as renaming five pages or testing two runbooks.
- Note the result next month.
Small, repeated improvements beat a yearly cleanup.
Ask people, too
Numbers will not catch everything. Once a quarter, ask a few engineers three questions: what did you look for and not find, what did you find but not trust, and what did you stop using? Short answers are often more useful than a dashboard.
Also watch behavior after launch events. After a new policy or tool rollout, count questions about it. A spike followed by a decline shows the docs are working. A spike that stays high means the explanation is missing.
Avoid vanity targets
Do not set a goal like "100 new pages this quarter". It rewards volume over accuracy and makes the stale share worse. For more on this trap in security reporting, see vanity versus decision metrics.
Tie docs to outcomes you already track
Compare docs signals with operational ones. Do incidents involving a documented topic fall after a page improves? Does the time to request an exception drop once the process is written down? You cannot prove cause, but patterns are worth noting.
Where Safeguard fits
If your docs describe a vulnerability process, Safeguard's vulnerability management views give measurable process outcomes, such as open findings, to compare against what the docs promise. Try it in the vulnerability management demo.
Quick check
What is a reasonable stale share?
There is no standard number. Pick a target, such as no critical runbook past its review date, and track whether the trend improves.
How often should I review these measures?
Monthly is enough for most teams. Quarterly works for small knowledge bases.
Last reviewed: 19 October 2026.
