A monthly report should fit on one page and answer four questions: what changed, what is still open, what decisions are needed, and what happens next. Include counts, dates and owners. Clients read short reports and file long ones, and a steady format shows trends better than any single month.
Why send one
Security work on a retainer is invisible when it goes well. A short report makes the work visible, gives the client a record for their own questionnaires, and creates a natural place to raise a decision, such as a framework upgrade that needs budget.
The layout
1. Summary line. One sentence. For example: "Two dependency updates deployed, one advisory open with a plan."
2. What changed.
| Item | Detail |
|---|---|
| Updates deployed | Count and notable packages |
| Advisories fixed | Count, severity |
| Access changes | Accounts added or removed |
| Incidents | None, or a short note |
3. What is open.
| Finding | Severity | Status | Owner | Target date |
|---|---|---|---|---|
| Example advisory in a transitive package | High | Fix needs a major upgrade | Agency | Date |
4. Accepted risks. Each with a reason and a review date. Do not let these accumulate silently.
5. Decisions needed from the client. Phrase them as questions with a recommended answer.
6. Next month. Planned updates, upgrades and reviews.
7. Trend. A small chart or three numbers over time: outdated packages, open advisories, average days to fix. Pick measures you can compute the same way each month.
Where the data comes from
- The dependency inventory, regenerated at each release.
- The scanner's findings list.
- The update tool's pull request history.
- The access list from the repository and hosting accounts.
- GitHub's Dependabot alerts and security updates, if the client uses them, which flag dependencies with known vulnerabilities and open pull requests to move them to a fixed version.
Automating the collection means you spend your time on the commentary.
Tone
Be plain. Say "open" for open. If something slipped, say so, say why, and say when it will be done. Clients forgive delays. They do not forgive surprises.
What to leave out
Raw scanner output (attach it separately), jargon, and vanity numbers such as "scanned 4,000 packages". A count of what you checked is not a measure of safety.
Review it once a year
Ask the client what they actually use. Trim sections no one reads. Add what they ask for.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the monitoring view and notice which numbers change over time. Those are good candidates for the trend line.
Quick check
Should the report go to the client's executives?
Send it to the technical owner, and offer a two line version for executives.
What if nothing happened this month?
Send it anyway. A report that says nothing is open, and shows the checks you ran, is still useful evidence.
Sources
Safeguard
Safeguard's dependency scanning and compliance evidence automation can supply the counts and history behind a report like this. A free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
