When the numbers get worse, say so in the first sentence, give the cause in plain words, show what remains under control, and make one specific request. Leaders trust a program more when it names a bad quarter honestly than when the bad news appears later in an audit.
Find the cause before the meeting
Worse numbers usually have one of four causes. Work out which before you present, because each calls for a different message.
| Cause | What it looks like | What to say |
|---|---|---|
| Scope grew | Open count up, more repositories or assets scanned | "We now see more, so the count rose. Here is the like for like trend." |
| Disclosure surge | Many new advisories against shared components | "One widely used component drove most of the inflow, and here is its status." |
| Capacity gap | Inflow steady, outflow down | "We fixed less than we received. We need X." |
| Process break | Exceptions or aging items growing | "Reviews slipped. Here is the repair." |
If you cannot tell which it is, say that, and name when you will know.
A short script
- Lead. "Priority one items past SLA rose this quarter, from [last quarter's count] to [this quarter's count]."
- Cause. "Most of the rise comes from [cause]."
- Containment. "None of the open items are known to be exploited in our reachable code" only if that is verified. If unsure, say what you checked.
- Plan. "We will close the oldest [number] by [date] by doing [action]."
- Ask. "To hold that date we need [decision or resource]."
What to avoid
- Changing the metric definition mid quarter without telling anyone. If you must, show both old and new definitions side by side
- Switching from counts to percentages only when the percentage looks better
- Blaming a team in the room
- Offering a hopeful forecast with no basis
- Quoting outside benchmark figures you have not sourced
For why changing the chart style can mislead, see Goodhart's law and security metrics.
Show the part that is working
A bad quarter rarely means every measure got worse. Pick one or two that held steady or improved and present them honestly. Median time to fix for the top tier, or the zero count of aged exceptions, shows the machine still runs. Do not use them as a distraction. Put them after the cause.
After the meeting
Send the one page summary within a day. Record the commitments with dates in the same place you track other risk items. Review them at the next meeting at the top of the agenda, so the follow up is visible.
If your reporting depends on several tools, a single source of per finding data makes this easier. Safeguard's SBOM and dependency scanning, reachability analysis and evidence automation can provide that record, and a free scan shows what a baseline looks like.
Quick check
Should I warn leaders before the meeting?
Yes. A short note a day before lets people prepare questions and avoids a surprise that turns the meeting defensive.
What if I do not know the cause yet?
Say what you have ruled out, name when you will know, and commit to a date. That is better than guessing.
Last reviewed: 19 October 2026.
