A pre-mortem asks the team to assume the feature launched and went badly, then work backward to explain why. It surfaces risks people were reluctant to raise, because everyone is explaining a failure that has already "happened". Thirty minutes with the right people can find abuse and security problems cheaply, before the design is fixed.
Why it works
In planning meetings, optimism has social pressure behind it. Raising a concern can sound like opposition. A pre-mortem flips the incentive: finding a plausible failure is the task, and the person who finds the sharpest one has helped. It also draws on the whole team, not only the security person.
Who to invite
The feature owner, a product representative, two or three engineers who will build it, someone from support, and a security contact if you have one. Support staff are valuable because they know how customers actually misuse things. Keep it under eight people.
The 30 minute format
Minutes 0 to 5: set the scene. The facilitator describes the feature in a few sentences and says: it is three months after launch and this has gone badly. A customer is upset, there is a security issue, or the press is asking questions. Do not explain how yet.
Minutes 5 to 12: silent writing. Everyone writes as many reasons as they can for the failure, one per note. Silence prevents the loudest voice from steering the room.
Minutes 12 to 22: group and discuss. Collect the notes, cluster similar ones, and read them out. Do not debate yet. Ask for clarification only.
Minutes 22 to 28: pick the top risks. Each person votes for the three risks they find most worrying. Take the top three or four.
Minutes 28 to 30: decide actions. For each, choose one: change the design, add a control, add monitoring, or accept it with an owner. Write the decision next to the note.
Prompts that help security thinking
If the room stalls, offer these.
- Which user would abuse this for money?
- What happens if one account is compromised?
- What data would we regret having logged or exposed?
- Which third party are we depending on that could change or fail?
- What would a very angry former employee or customer try?
What to do with the output
Turn each chosen action into a ticket or a design change, linked to the feature's documentation. Keep the sticky notes or a short summary. Revisit them before launch and at the first retrospective, and check which fears came true. That feedback sharpens the next pre-mortem.
For a formal structure on identifying threats, see threat modeling four questions. A pre-mortem is lighter and works well as a warm up or as a substitute when no one has threat modeling experience.
Quick check
How is a pre-mortem different from a threat model?
A threat model is structured around assets and attackers. A pre-mortem is a free form exercise about any failure. They complement each other.
Why write silently first?
It stops senior or loud voices anchoring the group and gives quieter people an equal say.
Last reviewed: 19 October 2026.
