A security kickoff for a new project can take 15 minutes. Cover what you are building, what data it holds, where trust changes, who owns security decisions and which checks run from day one. Write the answers on one page and keep it with the project, so the first sprint starts with shared facts.
Why a kickoff at all
The Threat Modeling Manifesto frames threat modeling around four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. OWASP's cheat sheet says threat modeling should fit into a team's normal lifecycle as a standard step, not an add-on. A short kickoff is the lightest way to start the first two questions while the design is still easy to change.
The agenda
| Minutes | Topic | Output |
|---|---|---|
| 0 to 3 | What are we building and for whom? | One sentence |
| 3 to 6 | What data does it touch? | A list, with sensitive items marked |
| 6 to 9 | Where does trust change? | Boundaries sketched on a whiteboard |
| 9 to 12 | Who owns what? | Names for security decisions and risk acceptance |
| 12 to 15 | Which checks run from day one? | A short list for the pipeline and definition of done |
What are we building
Say it in one sentence a new hire would understand. If the room cannot agree on that sentence, no security analysis will hold.
What data does it touch
List the kinds of data: customer records, credentials, payment details, logs. Mark the sensitive ones. This list drives later decisions about storage, access and retention.
Where does trust change
Draw the main parts and the arrows between them. OWASP's cheat sheet says data flow diagrams are the most common way to model a system. Mark each place where data crosses from a user, a partner or another system. Those crossings are where most threats start.
Who owns what
Name one person for technical security decisions, such as the tech lead, and one for risk acceptance, such as the product owner. Name how to reach security specialists for hard questions. NIST's Secure Software Development Framework asks organizations to define roles and responsibilities across the lifecycle, and this is the project-sized version.
Which checks run from day one
Agree a minimal set: dependency scanning, static analysis, secret detection and code review on every pull request. Decide what blocks a merge. Adding these on day one is far easier than retrofitting them later.
Notes to keep
Use a single page with these headings: purpose, data, boundaries, owners, day-one checks, open questions. Store it in the repository next to the readme, and link it from the first backlog items.
What to do with open questions
Anything the group could not answer becomes a spike story or a design review request, with a date. Do not leave open questions in the notes with no owner.
Common mistakes
- Making the meeting an hour long. Fifteen minutes forces focus.
- Inviting only developers. Include the product owner so risk decisions have a decider.
- Writing nothing down. A kickoff without notes is a chat.
- Skipping the data list. Almost every later security choice depends on it.
Revisit it
Review the page when the project adds a new integration, data type or user group. A five minute check at the start of a quarter keeps it true.
Safeguard offers asset discovery, SBOM and dependency scanning, which can supply the day-one checks for a new codebase. A free scan is at gold.safeguard.sh/scan.
Quick check
Who should attend a security kickoff?
The tech lead, the product owner, and a developer or two. Add a security specialist or champion if available, but do not make their presence a condition.
Is this the same as a threat model?
No. It is a starting point that covers the first questions in a light way. Run a fuller threat model for high-risk designs.
Sources
- Threat Modeling Manifesto
- OWASP Threat Modeling Cheat Sheet
- NIST SP 800-218, Secure Software Development Framework 1.1
Last reviewed: 19 October 2026.
