# Protecting Data: Threat Modeling for Small Teams

Privacy threats aren’t abstract. They look like a shared device, a curious coworker, a browser
extension with too much access, or an export sent to the wrong place.

Threat modeling doesn’t require a security team. It requires honesty.

For small teams, the goal isn’t “perfect security.” It’s to:

- identify the most likely risks
- implement controls that reduce harm
- avoid false reassurance

If you’re building for people in pain, “false reassurance” isn’t just a marketing problem. It changes
how people use the app.

## Step 1: define the assets (what you are protecting)

Start by naming the assets:

- Class A data (entries, notes, attachments, exports)
- export artifacts (PDF/CSV/JSON) once generated
- any secrets or keys used for at-rest protection (if applicable)

Your architecture decisions should flow from the assets, not from trends.

## Step 2: define the adversaries (be realistic)

For a privacy-first health PWA, realistic adversaries include:

- someone with access to the unlocked device
- a malicious browser extension
- accidental oversharing via exports
- XSS within your origin (a bug becomes a data leak)

Be careful with adversaries you can’t solve:

- compromised OS / spyware
- physical coercion beyond app controls

You can mitigate, but you can’t guarantee.

## Step 3: map entry points

List how data enters and leaves:

- UI input fields
- local persistence layer
- export boundary
- (optional) any network calls you might add later

Threat modeling becomes simpler when the map is explicit.

## Step 4: choose controls that match your constraints

Controls that usually pay off for small teams:

- strict content security posture (reduce XSS risk)
- aggressive redaction in logs (never include Class A)
- minimal on-screen exposure (privacy in public spaces)
- explicit export UX with preview and opt-in details
- secure-by-default feature flags (no hidden telemetry)

## Step 5: define your “truthful claims”

Write the claims you can defend:

- “Works offline.”
- “Data stays on this device unless you export.”
- “No default telemetry.”

Avoid claims you can’t:

- “Unhackable.”
- “Protects against spyware.”
- “Guaranteed privacy.”

## Threat model quick check

1) Assets, adversaries, and entry points are written down
2) Top 5 risks have concrete mitigations
3) Logs and analytics do not contain Class A content
4) Export is treated as a boundary crossing
5) Claims are honest and scoped

## Next: Part 9 — Testing Accessibility with Free Tools and Real Users

Next, Part 9 builds a repeatable accessibility testing workflow that doesn’t require a lab:
automated checks, keyboard tests, screen readers, and targeted observation.

---