Operations Practical
Threat modelling for a small platform
Who might actually come after your service, in what order, and which of them a hosting decision affects. Most of them it does not — and knowing which is the point.
13 min read Published 2 May 2026 Checked 1 month ago
Threat modelling has a reputation for being an enterprise ritual with diagrams nobody reads. It does not have to be. For a small platform the useful version takes an hour, produces a ranked list, and its main output is knowing which risks your infrastructure choices affect at all — because for most of them, the honest answer is none.
Order matters more than completeness
The classic failure is a long list of everything that could go wrong, treated as equally urgent. That produces paralysis, and then a decision made on vibes anyway. A ranked list of seven things is worth more than an exhaustive list of forty, because you will act on the first three and never reach the rest either way.
Rank by likelihood × cost to you, not by how alarming the scenario sounds. A state adversary is the most frightening item on any list and, for almost every small platform, the least likely — while a credential leak from a former contractor is dull, extremely common, and usually catastrophic.
Seven adversaries, ranked by likelihood
| Adversary | Likelihood | Hosting helps | What actually mitigates it |
|---|---|---|---|
| You, on a bad day | Certain | No | Backups you have actually restored from, and a change process for anything touching auth or DNS. The most likely cause of your worst outage is you. |
| Automated scanning | Constant | No | Patching, no password auth, no default credentials. This is background radiation; it is not aimed at you and it never stops. |
| Credential compromise | High | No | Hardware second factor, scoped API tokens, and revoking access the day someone leaves rather than the quarter after. |
| A complainant with a form | High | Yes | This is the one hosting jurisdiction genuinely addresses: whether correspondence alone can take your service down. |
| Volumetric attack | Medium | Partly | Upstream filtering, and specifically a provider that filters rather than null-routing you to protect itself. |
| A targeted intruder | Low | No | Segmentation, least privilege, encrypted data at rest, and logs somewhere the intruder cannot edit. |
| A state actor | Very low | Partly | Jurisdiction shapes the legal route, not the technical one. If this is genuinely in your model, get advice rather than a hosting plan. |
Which ones a hosting decision touches
Two of seven, and partially a third. That ratio is the single most useful output of the exercise, and it is why doing it before choosing a provider saves more money than any comparison table.
Hosting genuinely changes: whether a complaint can remove your service without a court, and how many separate parties are able to terminate you for reasons you will never see.
Hosting partially changes: how a volumetric attack is handled — filtered upstream, or null-routed to protect the provider’s other customers. Ask which, in writing, because the two words are used interchangeably and mean opposite things for you.
Hosting changes nothing about: your own mistakes, scanning, credential compromise, or an intruder who is already inside. Four of the seven, including the top three.
The one-hour version
- List what you actually hold (10 min). Not systems — data. User email addresses, payment records, private messages, uploaded files, credentials to other services. Write down which would be worst to lose and which would be worst to leak; they are rarely the same thing.
- List who would want each (10 min). Be specific. “Hackers” is not an adversary; “someone buying credential dumps to resell accounts” is, and it implies different defences.
- Rank by likelihood × cost (10 min). Ignore how dramatic each sounds. The dull ones dominate.
- For the top three, write the first hour (20 min). What you would do in the first sixty minutes of each. If you cannot answer, that is the finding — and it is more valuable than the ranking itself.
- Mark which are affected by infrastructure choices (10 min). Usually two of the top five. Now you know what your hosting decision is actually buying.
Redo it when something structural changes — a new data type, a new integration, a person leaving — rather than on a schedule. Calendar-driven reviews get skipped; event-driven ones get done, because there is a reason in front of you.
Three mistakes that make the whole thing useless
Modelling the adversary you find interesting. Nation-state capability is more fun to think about than a leaked API token in a public repository. One of them has happened to almost everyone you know. Rank honestly and the boring items win, which is the point.
Confusing a control with an outcome. “We use encryption” is not a mitigation until you can say what it stops and what it does not. Full-disk encryption on a running server protects against a disk leaving the building; it does nothing against an intruder with a shell on the live machine, because the volume is already unlocked.
Producing a document instead of a decision. If nothing changed after the exercise — no permission revoked, no backup tested, no provider question asked — it was not a threat model, it was an afternoon. The output should be three actions with names against them.
If the complainant row is the one that dominates your table, the next question is which jurisdiction and how to verify what a provider claims about it — six questions, answerable in an afternoon. If it does not appear in your top five at all, you probably do not need us, and that is a perfectly good outcome for an hour’s work.
Written by the engineers who run the platform, and re-read 1 month ago. If something here is wrong or has gone out of date, say so from the panel — that is where about half of these came from.
