A day five status update should say what has been tested, what the numbers are so far, what is blocked, and whether you are on track for the day ten decision. Keep it to half a page, share counts rather than raw findings, and flag problems early.
Why a mid point update
Stakeholders who hear nothing for ten days either forget the PoC or imagine the worst. A short update on day five keeps them informed and gives you a chance to adjust scope while it is still cheap. It also forces you to check your own progress.
Template
Copy this and fill it in.
Status: on track, at risk or blocked, one word and one sentence.
Done so far: repos connected, scans completed, tests run.
Early numbers:
| Pass mark | Result so far | Status |
|---|---|---|
| Inventory completeness | Measured on N repos | Pass, fail or pending |
| Accuracy on sample | Reviewed N findings | Pass, fail or pending |
| Prioritization | Checked KEV matches | Pass, fail or pending |
| Scan time | Measured on N scans | Pass, fail or pending |
| Developer feedback | N reviews done | Pass, fail or pending |
Surprises: one or two lines. Example: lockfiles missing in one repo, which affects version accuracy.
Blockers: what you need and from whom, with a date.
Next five days: the plan, in a sentence.
Decision date: confirm the day ten readout.
What to leave out
Do not list individual vulnerabilities in a broad email. Share counts and categories. Keep details in the tracker with normal access. Do not make a recommendation yet, because half the evidence is missing. Do not include vendor claims that you have not tested.
How to report an early failure
If a hard floor has already failed, say so plainly, and say what you propose: continue to gather evidence for the memo, or stop early. For a framework on stopping, see when to stop a trial early. A failure at day five saves the other five days of effort.
How to report early success
Be careful. Early positives are often about setup, not fit. Say what has been shown and what remains: accuracy on a small sample is not accuracy overall. Resist the pull to declare a win.
Who should receive it
The decision maker, the repo owners, and the reviewers. Keep the list short. A reply all debate on a status email is a sign you should have talked first.
Use it to adjust
Day five is the point to trim. If review is behind, cut a repo. If a criterion is not measurable, replace it and note why. If the vendor owes you an answer, set a date. Record every change in the charter so the day ten comparison stays fair. See the one page charter.
Quick check
Should the vendor get the status update?
Share only what helps them support you, such as blockers. Keep your scores and opinions internal.
What if there is nothing to report?
Then you are behind. Say so, and decide what to cut.
Safeguard offers SBOM and dependency scanning with reachability analysis, and you can try a free scan at gold.safeguard.sh/scan before you plan a longer test. The CLI, desktop app and IDE extensions are listed on safeguard.sh/download.
Last reviewed: 19 October 2026.
