Threat modelling when you have eleven employees

Step one: draw where the data goes

On a whiteboard, draw every place data enters your system, every place it is stored, and every place it leaves. Include the unglamorous ones — the CSV export, the admin panel, the Zapier integration somebody set up, the analytics tool receiving form submissions.

This exercise alone routinely surfaces surprises. Most teams discover at least one path they had forgotten, and forgotten paths are unmonitored paths.

Step two: ask four questions per box

For each store and each boundary crossing, ask the same four questions. Write the answers down even when they are embarrassing, particularly when they are embarrassing.

• Who can read this, and how do we know that list is correct today?
• What happens if this credential leaks — what is the blast radius, and how would we notice?
• If this input is hostile, what is the worst it can do?
• If we deleted this data tomorrow because a customer asked, could we actually find all of it?

Step three: rank by what you would actually do

Skip the risk matrix. For each issue found, ask one question: if this happened on Monday morning, would we drop everything? Issues that get a yes go on the sprint. Issues that get a no go on a list with a review date.

This is less rigorous than a scored matrix and considerably more likely to result in someone fixing something, which is the only outcome that matters.

A threat model that produces three fixed issues beats a threat model that produces a forty-page report and zero commits.

The things that keep coming up

Across the startup assessments we have run, the same handful of findings appear again and again. If you do nothing else from this article, check these five.

• Admin panels reachable from the public internet with password-only authentication
• API keys committed to the repository at some point in history and never rotated
• Object storage buckets with permissions broader than anyone intended
• No rate limiting on authentication, password reset or invitation endpoints
• Production database credentials shared in a chat tool and never rotated after staff changes

Do it again in six months

A threat model describes a system at a point in time, and your system changes weekly. Put a recurring half-day in the calendar every six months, or after any significant architectural change.

The second pass is always faster than the first, because the diagram already exists. What changes is the set of boxes, and that difference is usually the most informative part of the exercise.