A good weekly vulnerability review takes 30 minutes and covers five things in order: new urgent items, overdue items, exceptions near expiry, decisions that need someone senior, and one recurring cause to fix. Do triage before the meeting, so the meeting is for decisions only.
What the meeting is for
It is not for reading scanner output aloud. It is for decisions that need more than one person: accepting a delay, assigning an owner, funding a fix. If a finding can be triaged alone, it should be triaged before anyone sits down.
Before the meeting
- Run the weekly summary: new findings, newly known exploited items, and changes since last week.
- Pre triage new items against your signals: exploitation evidence, exposure, reachability, asset importance.
- Update the overdue list with owners and reasons.
- List exceptions expiring within the next cycle.
- Circulate the one page summary a day ahead.
The 30 minute agenda
| Minutes | Item | Output |
|---|---|---|
| 5 | New urgent items | Each has an owner and a date, or a mitigation |
| 8 | Overdue items | Each has a new date, or goes up the escalation ladder |
| 5 | Exceptions near expiry | Renew with reason, or close |
| 7 | Decisions needed | Written decision, with owner |
| 5 | One recurring cause | One action to remove a class of findings |
Keep time ruthlessly. If an item needs more than its slot, schedule a separate session with the right people.
Who attends
Keep it small: the security lead, a representative from each major engineering group, and whoever owns infrastructure. Invite a senior decision maker for the decisions slot only, so the rest does not take their time.
What to cut
- Low severity items with no exploitation evidence and no reachability. Handle them in a monthly batch.
- Findings with a clear owner and date. Do not re discuss them.
- Tool demos and general news. Share links in writing.
NIST's patching guide encourages reviewing exceptions regularly and defining maintenance plans per group, which fit neatly into this rhythm.
After the meeting
Send decisions the same day, in a few lines. Update tickets. Record anything accepted with an end date. A short written record is what makes the next meeting shorter.
Track the meeting itself
Every month, ask whether the meeting changed anything. Count decisions made and items closed. If the meeting is mostly updates, cut it to every second week and move the status to a dashboard.
Try it yourself
Open the demo and look at the overview of findings by severity and status. Imagine pulling the pre meeting summary from a view like this.
Click through it at your own pace, or open it full screen.
Quick check
How long should the weekly review be?
Thirty minutes is enough if triage happens beforehand. If it runs longer, move discussion to separate sessions.
Should developers attend?
A representative from each major group should, since they own the fixes. Not every developer needs to.
Sources
Last reviewed: 19 October 2026.
