Threat Modelling for Small SaaS

Threat modelling is the process of systematically identifying what you're protecting, who might attack it, and what they'd do if they got in. It sounds sophisticated but takes 2–3 hours and is worth doing before writing a single line of security code. Four questions structure a threat model: (1) What are we protecting? (customer data, credentials, source code, financial data, API keys, healthcare records). (2) Who might attack us? (competitors, opportunistic hackers, disgruntled customers, nation-state actors if relevant). (3) What do they want? (customer data to sell, service disruption, financial gain, competitive intelligence). (4) What would the impact be? (financial loss, regulatory fine, reputational damage, litigation). For BathCheck, what you're protecting: NDIS client health assessment data (highly sensitive — privacy legislation applies), OT practice credentials, API keys for Claude and Stripe, your source code and algorithms. The most realistic threats: opportunistic attackers scanning for misconfigured APIs or default credentials, credential stuffing attacks on user accounts, and a disgruntled customer trying to access other customers' data.

Security is about risk management, not achieving perfect safety (which doesn't exist). Prioritise controls based on: probability of the attack × impact if it succeeds. A sophisticated nation-state attack on a small OT software company has very low probability — spending significant effort defending against it is miscalibrated. A credential stuffing attack on user accounts has moderate probability (very common automated attack) and moderate impact — this is worth defending against specifically. For a small SaaS, the highest-priority security investments in order: (1) Authentication hardening (2FA, rate limiting, breach detection) — most attacks start with compromised credentials. (2) Dependency management — the Log4Shell, Heartbleed, and similar vulnerabilities attacked software components, not custom code. (3) Secrets management — leaked API keys and credentials are the #1 cause of cloud infrastructure breaches. (4) Data access controls — ensuring users can only access their own data, properly implemented at the database layer. (5) Monitoring and alerting — knowing when something is wrong before your customers tell you. Start with these five before anything else. They cover 80% of realistic attack surfaces for a small SaaS.