The four questions
Every threat-modelling framework, stripped of its ceremony, asks four questions: What are we building? What can go wrong? What are we going to do about it? Did we do a good job? A small team can answer all four usefully in a single ninety-minute session — if it resists the urge to be exhaustive and aims instead to be honest.
The prerequisite is a picture. Draw the system as boxes and arrows: users, services, data stores, third parties, and every place data crosses a boundary — network, privilege, organisation. Most of the value of threat modelling is in this drawing, because the risks live on the arrows, not in the boxes.
What can go wrong: follow the assets, not the headlines
Small teams over-index on the attacks they read about and under-index on the ones they will actually face. Start from assets instead: what do we hold that someone would want — credentials, customer data, money movement, compute, reputation? For each asset, walk the drawing and ask who touches it and through which boundary.
STRIDE is a serviceable checklist for the walk: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. But the highest-yield question for a small company is blunter: 'What happens when a laptop is stolen, a token leaks, or one teammate is phished?' If the honest answer is 'everything falls', the model has already earned its ninety minutes.
Write threats down as scenarios with an actor and a path — 'a phished contractor account can reach the production database' — not as categories. Scenarios can be tested, priced and fixed; categories can only be nodded at.
What to do about it: the boring hierarchy
Rank what you found by damage times ease, then fix in the order that shortens the list fastest. In practice, the same handful of mitigations tops the list for nearly every small team: hardware-key or app-based MFA everywhere, short-lived credentials instead of long-lived API keys, least-privilege access reviewed on a calendar, offline or otherwise unreachable backups, and dependency updates on automation rather than memory.
Notice what is not on that list: products. Small teams buy tools to feel safer; attackers exploit the gaps between tools. Until identity, credentials and backups are disciplined, a new dashboard mostly adds another login to phish.
Each accepted risk deserves a sentence in writing — 'we accept X until Y because Z'. The sentence is not bureaucracy; it is what lets a future you distinguish a decision from an oversight.
Did we do a good job: make it a loop
A threat model is a snapshot, and systems move. The method only compounds if the session recurs — quarterly is enough for most small teams, or whenever an arrow changes: a new integration, a new data store, a new class of user. Re-walk the drawing, retire scenarios you have closed, add the ones the new arrows create.
The measure of success is not the document. It is that the next architectural decision gets made with the drawing in the room — that someone says 'that arrow crosses a boundary, what's the story there?' before the code is written rather than after the incident. Ninety minutes a quarter is the cheapest security budget a small company will ever approve, and the one with the highest return.