# A Pragmatic Threat Model for Regulated SMBs

Canonical: https://kaansystems.com/library/pragmatic-threat-model
Topic: Security · Published: 2026-05-12 · Updated: 2026-10-12
Summary: Threat-modeling templates aimed at Google and Microsoft assume APT-level adversaries. Regulated SMBs mostly face commodity threats plus regulator scrutiny. The model below fits that reality.

## Key takeaways

- The canonical threat-modeling guides — STRIDE, OWASP, and the NIST publications — were written for organizations facing the full threat spectrum, including nation-state adversaries; a regulated SMB doesn't face that.
- By volume, roughly 95% of what hits any internet-exposed SMB is commodity criminal traffic: credential stuffing, phishing, and ransomware-as-a-service.
- Use STRIDE as the frame but model only three of its six categories deeply — spoofing, tampering, and information disclosure; repudiation, denial of service, and elevation of privilege are largely covered by those controls.
- Identity hardening is the single highest-ROI security work for an SMB: universal MFA, SSO consolidation, FIDO2 for admins, and regular access reviews.
- Regulators audit your documentation of controls, not the controls themselves — teams that lose HIPAA audits usually have controls but can't show them in writing.
- The one-page template scores three categories on residual risk (1-5) for an aggregate out of 15: above 9, don't launch; 7-9, launch with a documented mitigation plan and a 90-day review; below 7, launch.

**What does a pragmatic threat model for a regulated SMB look like?** One page, not sixty attack vectors. Regulated SMBs mostly face commodity criminal traffic, regulator scrutiny, and negligent insiders — not nation-state APTs. Use STRIDE as the frame, model the three high-priority categories (spoofing, tampering, information disclosure) deeply, and spend on identity, backups, vendors, and documentation.

## Whose threat model are you borrowing?

The canonical threat-modeling guides (STRIDE from Microsoft, the OWASP Threat Modeling Cheat Sheet, the various NIST publications) were written by and for organizations that face the full threat spectrum: nation-state adversaries, sophisticated criminal groups, hacktivist movements, supply-chain attackers with multi-year operational patience.

A regulated small-to-medium business in healthcare, legal services, or fintech doesn't face that spectrum. It faces:

- **Commodity criminal traffic.** Credential stuffing, phishing, ransomware-as-a-service. By volume, 95% of what comes at any internet-exposed business.
- **Regulator scrutiny.** Not strictly an adversary, but the highest-impact "external party reviewing your security posture" event.
- **Negligent insiders.** Well-meaning employees doing the wrong thing. Far more common than malicious insiders.
- **Opportunistic vulnerability scanning.** Automated scans looking for unpatched CVEs and misconfigurations.
- **Vendor security incidents.** Third parties whose compromise becomes your compromise.

The mismatch between the canonical threat-modeling guidance and the actual SMB threat profile produces threat models that are either too theoretical (worried about adversaries that won't show up) or too granular (cataloguing 60 attack vectors that all reduce to "patch your stuff and turn on MFA").

The pragmatic threat model is one page, identifies the four or five threats that actually matter, and maps them to specific controls.

## Which threats show up for a team this size?

STRIDE — the structure used by most threat modeling — has six categories. Three are high-priority for the SMB profile; three are lower-priority. Use STRIDE as the frame, but allocate modeling time according to that profile.

```mermaid
flowchart LR
  subgraph HIGH[High priority — model deeply]
    direction TB
    S[Spoofing<br/>credential theft, phishing, BEC]
    T[Tampering<br/>unauthorized prod changes]
    I[Information disclosure<br/>regulator-relevant breaches]
  end

  subgraph LOW[Lower priority — covered by HIGH controls]
    direction TB
    R[Repudiation<br/>audit logging from I]
    D[Denial of service<br/>cloud-native scaling + CDN]
    E[Elevation of privilege<br/>downstream of S]
  end

  HIGH -.-> LOW

  classDef high fill:#1F4A3E,stroke:#3FA585,stroke-width:2px,color:#E8F5EE;
  classDef low  fill:#0a1612,stroke:#2E8B6F,stroke-width:1px,color:#E8F5EE;
  classDef band fill:#2E8B6F0F,stroke:#2E8B6F,stroke-width:1px;
  class S,T,I high;
  class R,D,E low;
  class HIGH,LOW band;
```

### High-priority categories

**Spoofing.** Credential theft and identity impersonation. The SMB attacker's #1 path. Credential stuffing against your login forms, phishing of employee credentials, business email compromise.

Mitigations that matter:
- MFA universal (no exceptions, no SMS fallback if avoidable)
- SSO across SaaS (one identity to revoke, not 40)
- Adaptive auth on the login form (rate limiting, anomaly detection)
- Phishing-resistant MFA (FIDO2 / passkeys) for privileged users

**Tampering.** Modification of data or configuration without authorization. For SMBs this maps almost entirely to "unauthorized changes to production infrastructure" rather than data tampering, because SMB applications usually have proper data-layer controls.

Mitigations that matter:
- Change control with auditable trail (every prod change tied to a PR or ticket)
- Immutable infrastructure where possible
- Drift detection on the security-relevant subset (see [the drift detection guide](/library/infrastructure-drift-detection))
- Backups that can't be deleted by the same identities that can touch production (immutable backups)

**Information disclosure.** Unauthorized read access. For SMBs in regulated industries, this is the regulator-relevant category. HIPAA breaches, GDPR violations, breach-notification requirements all live here.

Mitigations that matter:
- Encryption at rest with customer-managed keys for the data that's regulator-relevant
- Encryption in transit (TLS 1.2+ everywhere)
- Access logs on every data store touching regulated data
- Quarterly access review (who has access, do they still need it)

### Lower-priority categories

**Repudiation.** Denial that an action took place. Less of an SMB concern; mostly applicable to financial-transaction systems. Standard mitigation is audit logging, which you already need for the higher-priority categories.

**Denial of service.** Resource exhaustion. SMBs are rarely the primary target for DDoS, but they're often collateral damage from infrastructure that wasn't built for elasticity. Cloud-native scaling plus a CDN with DDoS protection (Cloudflare, AWS Shield Standard) handles 95% of the SMB DoS risk surface.

**Elevation of privilege.** Gaining unauthorized higher access. Important, but mostly an output of the other categories. If spoofing is well-controlled, EoP rarely happens via remote attackers. The realistic SMB scenario is "an engineer's laptop gets compromised, attacker pivots to cloud admin." Defense is endpoint security plus workstation-to-cloud access proxies.

## Where to Actually Spend Effort

For the regulated SMB, four areas absorb most of the security investment. In rough order of impact-per-dollar:

1. **Identity hardening.** MFA universal, SSO consolidation, FIDO2 for admins, regular access reviews. The single highest-ROI security work for any SMB, and the same work as [killing long-lived credentials](/library/killing-long-lived-credentials).

2. **Backup and recovery.** Ransomware is the most likely catastrophic event. Immutable backups, restore drills, and a documented recovery posture turn ransomware from a business-ending event into a 48-hour outage.

3. **Vendor trust chain.** Your security floor is your suppliers' security floor. A vendor breach (think: Snowflake credentials in 2024, MOVEit in 2023) becomes your breach if you used the vendor with sensitive data. Vendor security review at procurement; annual reattestation for material vendors.

4. **Documentation hygiene.** Regulators don't audit your controls; they audit your documentation of your controls. Teams that lose HIPAA audits are rarely the ones without controls. They're the ones that have controls but can't show them in writing. Policies, procedures, runbooks, and an [evidence pipeline](/library/evidence-pipelines-101), kept current. The [7-day Assessment](/assessment) scores that list against the estate.

## The Template

The one-page threat model for an SMB system or feature looks like this. Fill it in for any new system before launch, and re-review annually.

**System / feature:** _____________________

**Owner:** _____________________

**Data sensitivity:** ☐ Regulated (PHI / PII / PCI) ☐ Confidential ☐ Internal ☐ Public

**Spoofing threats**
- Primary scenario: ______________________________
- Existing mitigation: ___________________________
- Residual risk (1-5): ____

**Tampering threats**
- Primary scenario: ______________________________
- Existing mitigation: ___________________________
- Residual risk (1-5): ____

**Information disclosure threats**
- Primary scenario: ______________________________
- Existing mitigation: ___________________________
- Residual risk (1-5): ____

**Aggregate risk score:** ____ / 15

**Risk acceptance:** Above 9 → don't launch. 7-9 → launch with documented mitigation plan + 90-day review. Below 7 → launch.

**Notes / open questions:** _____________________

**Sign-off:** _____________________ Date: ___________

Three categories, one page, scored honestly. The model takes 30 minutes to fill in for a new system, surfaces the threats that matter, and gives leadership a defensible record of what was considered before launch.

## What This Buys You

Two things.

**First, the security program becomes legible.** When a customer, an auditor, or a board member asks "how do you think about security?", you have a structured answer that doesn't hand-wave. The answer is "we threat-model every new system, here's the template, here are the last six completed models."

**Second, the team stops doing security theater.** No more two-hour threat-modeling sessions for a feature that ships in a week. No more 200-question threat assessments that nobody reads. One page, three categories, ship.

The first time the model surfaces a real risk, and it will, the model has paid for itself.

## Frequently asked questions

**Q: Do small businesses really need to worry about nation-state hackers?**

Mostly no. A regulated SMB faces commodity criminal traffic, regulator scrutiny, negligent insiders, opportunistic vulnerability scanning, and vendor security incidents — not the nation-state and sophisticated-criminal adversaries the canonical guides are built around. Model for the threats that actually show up.

**Q: Which threats should a regulated SMB model most deeply?**

Three STRIDE categories: spoofing (credential theft, phishing, business email compromise), tampering (unauthorized production changes), and information disclosure (regulator-relevant breaches). The other three — repudiation, denial of service, and elevation of privilege — are lower priority and mostly handled by the controls you build for the top three.

**Q: Where should an SMB actually spend its security budget?**

Four areas, in rough order of impact per dollar: identity hardening, backup and recovery, the vendor trust chain, and documentation hygiene. Identity hardening is the highest-ROI work; immutable backups turn ransomware from a business-ending event into a 48-hour outage.

**Q: How long does the one-page threat model take to complete?**

About 30 minutes for a new system. Fill it in before launch and re-review it annually. The point is to surface the threats that matter and give leadership a defensible record of what was considered before launch.

**Q: What's the risk-acceptance rule in the template?**

Score the three categories on residual risk from 1 to 5 for an aggregate out of 15. Above 9, don't launch. Between 7 and 9, launch with a documented mitigation plan and a 90-day review. Below 7, launch.

**Q: Why do teams with real controls still fail HIPAA audits?**

Because regulators audit your documentation of your controls, not the controls themselves. The teams that lose audits usually have the controls but can't show them in writing — so keep policies, procedures, runbooks, and evidence pipelines current.

Template: "One-page threat model template" — branded PDF at https://kaansystems.com/templates/pragmatic-threat-model.pdf

Source: https://kaansystems.com/library/pragmatic-threat-model · Work with Kaan Systems: https://kaansystems.com/contact