A monthly security update for leadership should answer four questions on one page: what changed this month, what did we fix, what remains exposed, and what do we need from leadership. Use plain words, add no jargon, and leave out numbers that you cannot defend.
Why keep it short
Founders and managers will not read a long report, and they should not have to. The aim is a decision when one is needed and reassurance when it is not. A one page update is quick to write and builds a record month after month.
The four questions
| Question | What to write |
|---|---|
| What changed? | New services, vendors, customers with security needs, incidents or near misses |
| What did we fix? | Real risks closed, in plain words, with the effect |
| What is still exposed? | Known gaps, how bad, and by when we plan to close them |
| What do we need? | A decision, time in the sprint, a purchase, or nothing |
An example layout
Title with the month. Then four short paragraphs, one per question. Under "what do we need", always write something, even "nothing this month", so leaders learn that an empty answer is a real answer.
Keep sentences concrete. Instead of "improved posture", write "removed admin access for four former contractors". Only quote counts you took from your own records, and say where they came from.
What to leave out
Raw alert counts without context. Tool names as achievements. Severity labels leaders cannot interpret. Anything that reads as fear. If you cannot explain why a number matters, drop it.
Tie it to decisions
The most useful job for the page is surfacing trade offs. For example, a cheap fix that needs two days of sprint time, or an old service that needs a decision to retire. Frame each as an option with a consequence. That is what leadership can act on.
Reuse it elsewhere
The same page feeds buyer questionnaires, board updates and audit evidence. Save each month's copy in one folder. After a year you have twelve dated pages showing that someone looks at security regularly. Link them with your quarterly review notes.
Measures worth including
If you track anything, keep it to a few outcomes: how long exploited items stayed open, how many access removals were done on time, whether the last restore test passed. Define each once and keep the definition stable so trends mean something. The posts on first year AppSec metrics go deeper.
Common mistakes
Writing it for other security people. Skipping a month. Hiding bad news in the middle. Presenting a clean month when you simply did not look.
Where Safeguard fits
Safeguard's continuous monitoring and compliance and evidence automation can supply some of the facts for this page. 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. Watch how changes show up over time, which is the raw material for the what changed question.
Quick check
How long should it be?
One page, around 200 to 300 words. Anything longer will not get read.
What if there is nothing to report?
Say so, and still list what was checked. A calm month with evidence is a good month.
Last reviewed: 19 October 2026.
