# Privacy Threat Model: [System or feature name]

> Privacy threat model for a system, service or feature, organised around
> the seven LINDDUN privacy threat categories (Linking, Identifying,
> Non-repudiation, Detecting, Data disclosure, Unawareness and
> unintervenability, Non-compliance) as published on linddun.org by the
> DistriNet research group at KU Leuven (category names checked in October
> 2026). It records the system description, a data flow diagram with
> trust boundaries, a personal data inventory, threat elicitation per
> category and diagram element, a threat register with severity,
> privacy-enhancing mitigations, residual risk and the link to the data
> protection impact assessment (DPIA). This is an engineering format, not
> legal advice. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- Model at design time and again for every change that adds a new kind of
  personal data, a new recipient or a new purpose.
- Draw the data flow diagram (section 3) and fill the data inventory
  (section 4) before eliciting threats; privacy threats attach to
  personal data moving across elements, not to code.
- Walk every diagram element through every LINDDUN category (section 5),
  recording "not applicable" with a reason rather than skipping cells.
- Privacy threats harm the data subject, not only the organisation. Rate
  severity from the person's point of view first (section 6).
- Hand the register and residual risks to the DPIA owner; this model is
  evidence for the DPIA, not a replacement for it.
-->

## Document control

<!-- Guidance: Identify the model, the system version it describes and who owns it. A privacy model is only valid for the processing purposes named here. -->

| Field | Value |
|---|---|
| Document ID | [PTM-FITTRACK-001] |
| System / feature | [FitTrack mobile app: workout sharing and coach matching] |
| System version modelled | [Design doc v2.1, release 4.0] |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Owner | [@privacy-engineer] |
| Contributors | [@tech-lead], [@product-manager], [@data-protection-officer] |
| Related DPIA | [DPIA-2026-014] |
| Related security threat model | [TM-FITTRACK-003 (STRIDE)] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Privacy engineering lead | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Engineering owner | [@name] | [Accepted mitigations] | YYYY-MM-DD |
| Data protection officer | [@name] | [Reviewed for DPIA input] | YYYY-MM-DD |
| Product owner | [@name] | [Accepted residual risk] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record new data, new purposes, new recipients and changed ratings; skip wording edits. -->

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | System description, DFD and data inventory |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Elicitation workshop, 14 threats recorded |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; residual risks handed to DPIA-2026-014 |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Introduction and scope](#1-introduction-and-scope)
2. [System description](#2-system-description)
3. [Data flow diagram](#3-data-flow-diagram)
4. [Personal data inventory](#4-personal-data-inventory)
5. [Threat elicitation](#5-threat-elicitation)
6. [Threat register](#6-threat-register)
7. [Mitigations and privacy-enhancing technologies](#7-mitigations-and-privacy-enhancing-technologies)
8. [Residual risk](#8-residual-risk)
9. [Link to the DPIA](#9-link-to-the-dpia)
10. [Appendices](#10-appendices)

## 1. Introduction and scope

<!-- Guidance: Say what processing is modelled, why now, and what is out of scope. Name the purposes of processing, because a threat is often "data used beyond its purpose". -->

This section states what the model covers and which processing purposes
it assumes.

### 1.1 Purpose of the model

This model identifies privacy threats to the people whose data
[System name] processes, rates them, and agrees mitigations before
[release 4.0 / the change]. It complements the security threat model,
which focuses on attackers against the system; here the concern also
includes the operator, legitimate recipients and the system's own design.

### 1.2 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Mobile app, workout API, coach-matching service, analytics pipeline | *Example:* Payment provider (separate assessment), corporate HR systems |
| *Example:* Data shared with coaches and with the analytics vendor | *Example:* Marketing website cookies (covered by consent review) |
| [Component] | [Component] |

### 1.3 Processing purposes

| ID | Purpose | Lawful basis (as recorded by legal) | Data subjects |
|---|---|---|---|
| P-1 | *Example:* Record and display the user's own workouts | Contract | App users |
| P-2 | *Example:* Match users with coaches by goal and location | Consent | App users, coaches |
| P-3 | *Example:* Product analytics on feature usage | Legitimate interest, with opt-out | App users |
| [P-n] | [Purpose] | [Basis] | [Subjects] |

## 2. System description

<!-- Guidance: Describe actors, components and the main user journeys in plain words. Include the operator and third parties as actors; many privacy threats come from insiders and processors. -->

[System name] lets users log workouts from their phone and wearable,
share selected workouts with friends, and request a personal coach who
sees their training history.

### 2.1 Actors

| Actor | Relationship | Data they can see |
|---|---|---|
| App user | Data subject | Own data; friends' shared workouts |
| Friend | Data subject and recipient | Workouts shared with them |
| Coach | Recipient (independent professional) | Training history of matched users |
| Support agent | Operator staff | Account data on ticket, with justification |
| Analytics vendor | Processor | Pseudonymous usage events |
| [Actor] | [Relationship] | [Data] |

### 2.2 Main user journeys

1. *Example:* User records a run; GPS track and heart rate sync to the workout API.
2. *Example:* User shares a run with friends; friends see route map and pace.
3. *Example:* User requests a coach; matching service uses goal, age band and city.
4. [Journey]

### 2.3 Assumptions

- *Example:* Transport is TLS 1.2+ and storage is encrypted at rest (covered by the security threat model).
- *Example:* Coaches are contractually bound but not employees.
- [Assumption]

## 3. Data flow diagram

<!-- Guidance: Use the four DFD element types (external entity, process, data store, data flow) and mark trust boundaries. Number every element; section 5 refers to these IDs. -->

The diagram shows external entities (E), processes (P), data stores (DS)
and numbered data flows (F). Grouped zones are trust boundaries.

```mermaid
flowchart LR
  subgraph Device["User device (TB-1)"]
    E1["E1 App user"]
    P1["P1 Mobile app"]
  end
  subgraph Cloud["Operator cloud (TB-2)"]
    P2["P2 Workout API"]
    P3["P3 Coach matching"]
    DS1[("DS1 Workout store")]
    DS2[("DS2 Profile store")]
  end
  subgraph Third["Third parties (TB-3)"]
    E2["E2 Coach"]
    E3["E3 Analytics vendor"]
  end
  E1 -->|"F1 workouts, GPS"| P1
  P1 -->|"F2 sync"| P2
  P2 -->|"F3 write"| DS1
  P2 -->|"F4 profile"| DS2
  DS2 -->|"F5 goal, age band, city"| P3
  P3 -->|"F6 match and history"| E2
  P1 -->|"F7 usage events"| E3
```

| Element | Type | Description | Personal data handled |
|---|---|---|---|
| E1 | External entity | App user | All own data |
| P1 | Process | Mobile app | GPS, heart rate, device ID |
| P2 | Process | Workout API | Workouts, account ID |
| P3 | Process | Coach matching | Goal, age band, city |
| DS1 | Data store | Workout store | GPS tracks, heart rate |
| DS2 | Data store | Profile store | Name, email, date of birth, city |
| E2 | External entity | Coach | Training history of matched users |
| E3 | External entity | Analytics vendor | Pseudonymous events, device model |
| F1 to F7 | Data flows | See diagram | As labelled |

## 4. Personal data inventory

<!-- Guidance: One row per data category. Note sensitivity (special category data such as health), source, purposes, recipients and retention. Data that is not needed for a purpose is the first threat. -->

| ID | Data category | Example fields | Sensitivity | Source | Purposes | Stored in | Recipients | Retention |
|---|---|---|---|---|---|---|---|---|
| D-01 | Identity | Name, email | Personal | User | P-1, P-2 | DS2 | Coach (name only) | Account life + 30 days |
| D-02 | Location traces | GPS track points every 2 s | High: reveals home and routine | Device | P-1 | DS1 | Friends (if shared) | *Example:* 24 months |
| D-03 | Health data | Heart rate, resting HR | Special category (health) | Wearable | P-1, P-2 | DS1 | Coach | 24 months |
| D-04 | Device identifiers | Install ID, device model | Personal (pseudonymous) | Device | P-3 | E3 | Analytics vendor | 13 months |
| D-05 | Profile attributes | Date of birth, city, goal | Personal | User | P-2 | DS2 | Matching service | Account life |
| [D-nn] | [Category] | [Fields] | [Level] | [Source] | [P-n] | [Store] | [Recipients] | [Period] |

## 5. Threat elicitation

<!-- Guidance: Walk each DFD element through each LINDDUN category. Use the category list in 5.1 for prompts, fill the matrix in 5.2 with threat IDs or "n/a" with a reason, then describe each threat in the register (section 6). -->

Threats were elicited in [two 90-minute workshops on YYYY-MM-DD] with
[engineering, product, the DPO and a user researcher].

### 5.1 Categories and prompts

The category names follow LINDDUN; the prompts are this template's own
questions.

| Code | Category | Prompt questions for this system |
|---|---|---|
| L | Linking | Can two data items, sessions or datasets be tied to the same person, even without knowing who they are? Do identifiers persist across contexts? |
| I | Identifying | Can someone learn who a person is from the data, through direct identifiers, unique combinations or inference? |
| Nr | Non-repudiation | Is a person unable to deny an action or a claim when deniability matters to them (for example, a confidential report)? |
| D | Detecting | Can an observer infer that a person uses the system, or has a record in it, without seeing the content? |
| DD | Data disclosure | Is more personal data collected, stored, processed or shared than the purpose needs? Is it exposed to the wrong recipient? |
| U | Unawareness and unintervenability | Do people know what happens to their data, and can they access, correct, export, restrict or delete it? |
| Nc | Non-compliance | Does processing depart from law, policy, consent or recognised good practice (retention, minimisation, processor contracts)? |

### 5.2 Elicitation matrix

Each cell holds the threat IDs found, or "n/a" with a reason in the
notes.

| Element | L | I | Nr | D | DD | U | Nc |
|---|---|---|---|---|---|---|---|
| E1 App user | n/a | n/a | n/a | n/a | n/a | PT-07 | n/a |
| P1 Mobile app | PT-01 | n/a | n/a | PT-05 | PT-04 | PT-07 | n/a |
| P2 Workout API | n/a | n/a | n/a | n/a | n/a | PT-08 | n/a |
| P3 Coach matching | n/a | PT-03 | n/a | n/a | PT-06 | n/a | n/a |
| DS1 Workout store | PT-01 | PT-02 | n/a | n/a | n/a | PT-08 | PT-09 |
| DS2 Profile store | n/a | n/a | n/a | n/a | n/a | PT-08 | n/a |
| F6 to coach | n/a | n/a | n/a | n/a | PT-06 | n/a | n/a |
| F7 to analytics | PT-01 | n/a | n/a | PT-05 | PT-04 | n/a | PT-10 |
| [Element] | [IDs] | [IDs] | [IDs] | [IDs] | [IDs] | [IDs] | [IDs] |

Notes on "n/a" cells: *Example:* Non-repudiation is not relevant to the
workout API because no action needs to be deniable by the user; revisit
if anonymous feedback is added.

## 6. Threat register

<!-- Guidance: One row per threat. Describe the threat as a scenario affecting a person, name the category and element, then rate likelihood and impact on the data subject. Severity uses the scale in 10.2. -->

Severity is the product of likelihood and impact on the data subject,
each rated 1 to 4:

$$
S = L \times I, \qquad S \in [1, 16]
$$

| ID | Threat scenario | Category | Element | Data | L | I | S | Severity | Owner | Status |
|---|---|---|---|---|---|---|---|---|---|---|
| PT-01 | *Example:* The persistent install ID in analytics events links a user's workouts across years and to their account if the vendor's data is joined with ours | L | P1, F7, DS1 | D-04 | 3 | 3 | 9 | High | [@name] | [Open] |
| PT-02 | *Example:* Shared GPS tracks start and end at the user's home, identifying where they live | I | DS1 | D-02 | 4 | 4 | 16 | Critical | [@name] | [Open] |
| PT-03 | *Example:* Rare combination of age band, small city and goal makes a user identifiable to a coach before consent to share name | I | P3 | D-05 | 2 | 3 | 6 | Medium | [@name] | [Open] |
| PT-04 | *Example:* App sends precise location and full device model to analytics although only feature usage is needed | DD | P1, F7 | D-02, D-04 | 3 | 3 | 9 | High | [@name] | [Open] |
| PT-05 | *Example:* Network observers and other apps can detect use of a fertility-training feature from a distinctive API hostname | D | P1, F7 | D-03 | 2 | 3 | 6 | Medium | [@name] | [Open] |
| PT-06 | *Example:* Coach receives full heart-rate history instead of the summary needed to plan training | DD | P3, F6 | D-03 | 3 | 3 | 9 | High | [@name] | [Open] |
| PT-07 | *Example:* Users are not told that coaches can keep notes after the match ends | U | E1, P1 | D-03 | 3 | 2 | 6 | Medium | [@name] | [Open] |
| PT-08 | *Example:* No self-service export or deletion of workouts; requests take 30 days by email | U | P2, DS1, DS2 | All | 4 | 2 | 8 | Medium | [@name] | [Open] |
| PT-09 | *Example:* GPS tracks retained indefinitely in backups, beyond the 24-month policy | Nc | DS1 | D-02 | 3 | 3 | 9 | High | [@name] | [Open] |
| PT-10 | *Example:* No data processing agreement covers the analytics vendor's sub-processors | Nc | F7, E3 | D-04 | 2 | 3 | 6 | Medium | [@name] | [Open] |
| [PT-nn] | [Scenario] | [Code] | [Element] | [D-nn] | [1-4] | [1-4] | [S] | [Severity] | [@name] | [Status] |

## 7. Mitigations and privacy-enhancing technologies

<!-- Guidance: Prefer mitigations that remove or reduce data (minimise, separate, aggregate) over those that only protect it (encrypt, restrict). Map every mitigation to threat IDs and say how it will be verified. -->

Mitigation strategies are listed from strongest to weakest: avoid the
data, minimise it, separate or aggregate it, hide it, then inform and
empower the person.

### 7.1 Mitigation plan

| ID | Mitigation | Strategy | Threats | Owner | Target date | Verification |
|---|---|---|---|---|---|---|
| M-01 | *Example:* Rotate analytics ID every 30 days; never send account ID or location to analytics | Minimise, unlink | PT-01, PT-04 | [@name] | YYYY-MM-DD | Inspect event payloads in CI contract test |
| M-02 | *Example:* Privacy zones: trim the first and last 500 m of shared tracks around user-defined places | Hide | PT-02 | [@name] | YYYY-MM-DD | Automated test with fixture tracks |
| M-03 | *Example:* Matching uses k-anonymous buckets (city replaced by region when fewer than 10 users share the combination) | Aggregate | PT-03 | [@name] | YYYY-MM-DD | Query test on production-like data |
| M-04 | *Example:* Coach sees weekly summaries by default; full history only with explicit per-coach consent | Minimise, consent | PT-06, PT-07 | [@name] | YYYY-MM-DD | UX review and consent log check |
| M-05 | *Example:* Self-service export (JSON, GPX) and deletion with backup purge within 35 days | Empower | PT-08, PT-09 | [@name] | YYYY-MM-DD | Deletion audit report |
| M-06 | *Example:* Generic API hostnames and certificate pinning for sensitive features | Hide | PT-05 | [@name] | YYYY-MM-DD | Traffic capture review |
| M-07 | *Example:* Data processing agreement with sub-processor list and audit right | Comply | PT-10 | [@legal] | YYYY-MM-DD | Signed agreement on file |
| [M-nn] | [Mitigation] | [Strategy] | [PT-nn] | [@name] | YYYY-MM-DD | [Evidence] |

### 7.2 Privacy-enhancing technologies considered

| Technology | What it does | Considered for | Decision |
|---|---|---|---|
| Pseudonymisation with rotating identifiers | Replaces stable IDs with short-lived ones | PT-01 | *Example:* Adopted (M-01) |
| k-anonymity or generalisation | Coarsens quasi-identifiers until each record matches at least k people | PT-03 | *Example:* Adopted with $k = 10$ (M-03) |
| Differential privacy | Adds calibrated noise to aggregate statistics | Product analytics dashboards | *Example:* Deferred; volumes too low for useful accuracy |
| On-device processing | Computes summaries on the phone and sends only results | PT-06 | *Example:* Under evaluation for weekly summaries |
| End-to-end encryption | Content readable only by sender and recipient | Coach chat | [Decision] |
| Private set intersection | Finds shared contacts without revealing address books | Friend finding | [Decision] |

For differential privacy, a mechanism satisfies $\varepsilon$-differential
privacy when, for any two datasets $D$ and $D'$ that differ in one
person and any output set $S$:

$$
\Pr[M(D) \in S] \le e^{\varepsilon} \cdot \Pr[M(D') \in S]
$$

Smaller $\varepsilon$ means stronger privacy and noisier results; record
the chosen value and the budget per release if it is adopted.

## 8. Residual risk

<!-- Guidance: Re-rate each threat after its mitigations. Any residual High or Critical needs a named risk owner, a review date and DPIA consideration. -->

| Threat | Mitigations | Residual L | Residual I | Residual S | Decision | Risk owner | Review by |
|---|---|---|---|---|---|---|---|
| PT-02 | M-02 | 2 | 3 | 6 | *Example:* Accept; users can widen privacy zones | [@product-owner] | YYYY-MM-DD |
| PT-06 | M-04 | 1 | 3 | 3 | Accept | [@product-owner] | YYYY-MM-DD |
| PT-05 | M-06 | 2 | 2 | 4 | Accept | [@product-owner] | YYYY-MM-DD |
| [PT-nn] | [M-nn] | [1-4] | [1-4] | [S] | [Accept / Reduce further / Avoid] | [@name] | YYYY-MM-DD |

Overall conclusion: *Example:* After mitigations no residual threat is
rated above Medium. Processing of health data (D-03) remains high risk by
nature and is assessed in the DPIA.

## 9. Link to the DPIA

<!-- Guidance: Show which outputs of this model feed which DPIA sections, so the DPO can reuse them without re-interviewing the team. -->

This model provides engineering evidence for [DPIA-2026-014]. The table
maps its outputs to the DPIA.

| DPIA topic | Input from this model |
|---|---|
| Description of processing | Sections 1.3, 2 and 3 |
| Necessity and proportionality | Data inventory (section 4) and minimisation mitigations (M-01, M-04) |
| Risks to rights and freedoms | Threat register (section 6) |
| Measures to address risks | Mitigation plan (section 7) |
| Residual risk and consultation decision | Section 8 |

Trigger a DPIA review when: [a new data category or purpose is added; a
new recipient receives personal data; a residual risk is rated High].

## 10. Appendices

<!-- Guidance: Definitions and scales so the model stands on its own. -->

The appendices hold the glossary, rating scales and references.

### 10.1 Glossary

| Term | Meaning |
|---|---|
| DFD | Data flow diagram with external entities, processes, data stores and flows |
| DPIA | Data protection impact assessment |
| PET | Privacy-enhancing technology |
| Quasi-identifier | Attribute that is not identifying alone but can be in combination |
| Data subject | The person the data is about |

### 10.2 Rating scales

| Score | Likelihood | Impact on the data subject |
|---|---|---|
| 1 | Unlikely; needs insider plus rare conditions | Minor inconvenience, easily reversed |
| 2 | Possible with effort | Significant inconvenience or embarrassment |
| 3 | Likely for a motivated party | Serious consequences: discrimination, stalking risk, financial loss |
| 4 | Expected in normal operation | Severe or irreversible: physical danger, loss of livelihood |

Severity bands: 1 to 3 Low, 4 to 8 Medium, 9 to 12 High, 13 to 16
Critical.

### 10.3 References

| Reference | Use |
|---|---|
| LINDDUN privacy threat modelling framework, linddun.org (DistriNet, KU Leuven) | Threat category names in section 5 |
| [Organisation's privacy policy and DPIA procedure] | Ratings and hand-over |
| [Security threat model] | Security threats out of scope here |

## Standard and licence note

Based on the LINDDUN privacy threat modelling framework developed by the
DistriNet research group at KU Leuven (https://linddun.org), using only
its seven threat category names (Linking, Identifying, Non-repudiation,
Detecting, Data disclosure, Unawareness and unintervenability,
Non-compliance) as published on linddun.org in October 2026. The
LINDDUN website states copyright of KU Leuven and no open licence could
be verified, so this template reproduces none of its threat trees,
catalogues, descriptions or method text; the prompts, register,
matrices and examples are original. Consult linddun.org for the full
method and its threat knowledge. This is an engineering format, not
legal advice. Template licence: MIT.