A good weekly review takes thirty minutes and covers five things: new findings on exposed systems, known exploited matches, deployments lagging behind a fix, exceptions nearing review, and assets with no owner. End with named owners and dates, not a general sense of progress.
Who attends
The service owners for the estate you are reviewing, one person from platform or operations, and one from security. Small groups decide faster. Everyone else reads the notes.
Prepare in advance
Someone, ideally automation, prepares a single page with grouped findings, not raw rows. Group by component, then artifact, then deployment, as described in the dedupe guide.
The agenda
| Minutes | Topic | Question to answer |
|---|---|---|
| 0 to 5 | Known exploited matches | Does any component in our inventory match the CISA catalog, and where does it run? |
| 5 to 12 | New findings on exposed systems | Which are reachable and who owns each? |
| 12 to 18 | Drift behind security fixes | Which deployments still run a version before the fix? |
| 18 to 24 | Exceptions | Which reviews fall due before next week, and is the reason still valid? |
| 24 to 28 | Ownership gaps | Which assets have no team, and who will find one? |
| 28 to 30 | Actions | Read back each action, owner and date |
Rules that keep it short
- No debating scores. Priority comes from exposure, reachability and the known exploited list, not from an argument.
- No status updates. If a ticket has an owner and a date, skip it.
- Decide or delegate. Every item ends with a named person.
- Park deep dives. Take them offline with the people involved.
- Keep a log. A running list of decisions saves repeat debates.
What to track over time
Keep three numbers on the front page: the count of exposed deployments with open findings, the oldest open item in days, and the count of assets with no owner. If all three fall over a month, the meeting is working.
Adjusting for a hybrid estate
If on premises sites run on separate change windows, add a line to the agenda for items waiting for the next window, with its date. That avoids repeating the same item every week.
An example of one decision
The group sees that a component on the known exploited list runs in two production accounts and one staging account. Both production deployments are internet reachable. The decision, made in two minutes: fix production first, owners named, due within the week, staging follows in the next release. The action list records it, and the following week's first agenda item checks it.
Quick check
Should the whole engineering team attend?
No. Keep the group small and publish notes. Large meetings turn into status reporting.
What if nothing new appears one week?
Spend the time on drift and ownership gaps, which are always there. Or cancel the meeting and read the page.
Safeguard's vulnerability and dependency scanning, reachability analysis and asset discovery can produce the grouped page this meeting needs. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
