A daily standup should mention security only when it affects the sprint goal: a blocked review, a failing scan, an access request waiting, or a risk that changes the plan. Say it in one sentence with an owner and a wait time, then take the detail offline. Do not turn standup into a security meeting.
What the Scrum Guide says standup is for
The Scrum Guide describes the Daily Scrum as a 15 minute event for the developers. Its purpose is to inspect progress toward the sprint goal and adapt the sprint backlog, and the team picks its own structure as long as it produces an actionable plan for the next day. The Guide also says the daily event helps identify impediments.
A blocked security item is an impediment. That is the only security topic standup needs to carry.
A one-sentence format
Use this pattern: "Blocked on [thing], waiting on [person or team], since [day], needs [action]."
| Example | Why it works |
|---|---|
| Blocked on design review for the export story, waiting on the architecture group since Monday, need a slot today | Names who, since when and what is needed |
| The dependency scan fails on a new package, I will check for a safe version after standup | Shows the plan and keeps detail offline |
| Access to the staging vault is pending, waiting on IT, request filed Tuesday | A clear impediment for the Scrum Master |
What to raise
- A story that cannot start until a security review happens.
- A pipeline check that fails and blocks a merge.
- A new advisory affecting something in this sprint.
- An access or key request that is stuck.
- A scope change that adds a new trust boundary.
What to leave out
- Long explanations of a vulnerability.
- Debates about severity or tooling.
- General updates on security news.
- Anything that needs more than a minute. Say "I will follow up with X after standup".
What a Scrum Master or lead does with it
- Note the blocker and the owner.
- Chase it the same day, because the Scrum Master causes impediments to be removed.
- If the same blocker repeats across several days, bring it to the retrospective as a process issue.
- If a blocker threatens the sprint goal, tell the product owner immediately so the order of work can change.
Track waiting time
If you only track one number, track how many days security-related stories wait. A review queue that takes four days will quietly cap how often the team can ship. Putting the wait time in the standup sentence makes it visible without a dashboard.
A note on the parking lot
Keep a short list during standup of items to discuss afterwards. Assign each a name and a time. This keeps the 15 minutes honest and prevents security topics from either taking over or being forgotten.
When the team is distributed
Written standups, such as a thread in the team's channel, work if the same one-sentence format is used. Make sure blockers get a reply the same day, or the format becomes a log nobody reads.
NIST's Secure Software Development Framework asks teams to record findings and triage them in the team's workflow. Standup is where the human side of that triage happens: someone says the item is blocked, and someone owns it.
Safeguard can show failing policy checks and scan results in the pull request, which makes "the scan fails" a visible fact in the standup. A free scan is at gold.safeguard.sh/scan.
Quick check
Should every standup include a security update?
No. Mention security only when it blocks or changes the plan toward the sprint goal.
What if the blocker needs a long discussion?
Name it in one sentence, assign a person and a time, and take it offline after standup.
Sources
Last reviewed: 19 October 2026.
