A good weekly triage meeting runs 30 minutes and follows a fixed order: new high severity findings, items past their due date, suppression requests, rules to tune, then one metric. Prepare the list beforehand, make one decision per item, and end with named owners and dates.
Who attends
Keep it small. One person from security or AppSec who knows the scanners, one engineer from each team with findings that week, and a note taker. Others can read the notes. If nobody from the owning team attends, the meeting produces opinions, not fixes.
The agenda
| Minutes | Item | Output |
|---|---|---|
| 0 to 5 | New high and critical findings since last week | Each confirmed, dismissed or sent for investigation |
| 5 to 12 | Findings past their due date | Fix date, escalate or formally accept the risk |
| 12 to 18 | Suppression and false positive requests | Approve, reject or ask for more evidence |
| 18 to 24 | Noisy rules and tuning requests | A short list of rules to change, with an owner |
| 24 to 28 | One metric | Read it, do not debate it |
| 28 to 30 | Recap | Actions, owners and dates read aloud |
Ground rules
- Prepare. The AppSec lead reads new high findings before the meeting and arrives with a proposed status.
- Decide or assign. Every item ends in a status change or an owner and a date. "Let's discuss offline" is not an outcome.
- Evidence over opinion. A false positive claim comes with a reason, see writing a suppression comment that survives review.
- Time box. Two minutes per item. If it needs more, schedule a separate session.
- Skip when empty. If there are no new high findings and nothing is overdue, cancel and send the numbers by message.
Which metric to read
Pick one and keep it stable for a quarter: the age of the oldest open high severity finding, or the share of findings with an owner. Changing metrics weekly hides trends.
Notes template
Record each decision in one line: finding ID, decision, reason, owner, date. Store the notes where auditors and new team members can find them. This record is also useful evidence for secure development reviews. NIST describes its Secure Software Development Framework as a set of fundamental secure development practices for producers, with a common language for buyers as well, and dated decision notes are a simple way to show a practice is operated, not just written.
Common failure modes
- The meeting becomes a status report on the whole backlog. Stick to new, overdue and requests.
- Security makes all decisions alone. Developers know the code, so let them argue the technical case.
- No follow up. Open the next meeting by reading last week's actions.
One factual note on Safeguard
Safeguard offers compliance and evidence automation that can help keep decision records. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
How often should the meeting run?
Weekly works for teams shipping often. Fortnightly is reasonable for smaller scan volumes, provided high severity items are handled as they arrive.
Can this be asynchronous?
Yes, for low volume. A shared document with decisions and a deadline for comments can replace the call.
Sources
Last reviewed: 19 October 2026.
