A quarterly review with engineering leaders should cover five items per team: open findings by age, inflow versus outflow, known exploited items, ownership gaps, and the top blockers. Keep it to an hour, review each team on the same page layout, and end with dated commitments.
Why engineering needs a different page than the board
A board page summarizes the company. An engineering review is about specific services and the choices of specific managers. It needs per team detail and a conversation about tradeoffs, such as feature work against upgrades.
The one page per team
| Item | Why it is there |
|---|---|
| Open findings by age band | Shows neglect without a single score |
| Inflow and outflow this quarter | Shows whether the backlog is growing |
| Open known exploited items | The urgent list |
| Findings with no owner | A management problem, not a technical one |
| Fix available but not applied | The cheapest risk to remove |
| Top blocker, in one line | The ask |
Use the same layout for every team so leaders can compare without translating.
Agenda for sixty minutes
- Five minutes: what changed in method or tooling since last quarter.
- Thirty five minutes: the team pages, roughly equal time each, ordered by need rather than alphabet.
- Ten minutes: shared blockers, such as a base image or a framework upgrade that affects many teams.
- Ten minutes: commitments, each with an owner and a date.
Rules that keep it productive
- Send the pages in advance. The meeting is for decisions.
- Compare a team with its own history, not with a team of a different size and risk profile. Per team normalization such as per service counts is fairer than raw totals.
- Do not rank teams in public. Rankings invite hiding and gaming.
- Capture commitments in the tracker the same day.
Handling the hard conversation
Some teams carry far more legacy than others. If a team is red because of inherited components, the fix is a planned upgrade, and the right ask is capacity or scope, not blame. Say it that way in the room.
Follow up
At the next quarter, open with the previous commitments and mark each done, moved, or dropped. Dropped needs a reason. This closes the loop and makes the meeting worth attending.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are tracked over time rather than at one point, which is what a quarterly review compares.
Quick check
Should security lead the meeting?
Security prepares the data and facilitates. Engineering leaders own the commitments, since they own the work.
How do we avoid it turning into a blame session?
Use shared definitions, send pages ahead, avoid rankings, and focus the ask on blockers and capacity.
Last reviewed: 19 October 2026.
