Privacy Threat Model Template (LINDDUN)
Privacy threat model by LINDDUN category: DFD with trust boundaries, data inventory, elicitation matrix, register, PETs, DPIA link
उपयोग कैसे करें: Use at design time for any feature that handles personal data, alongside the security threat model. Draw the data flow diagram and fill the personal data inventory before eliciting threats per element and category. The main pitfall is rating impact on the company instead of on the data subject.
प्रीव्यू
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.
Document control
| 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
| 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
1. Introduction and scope
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
[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
- Example: User records a run; GPS track and heart rate sync to the workout API.
- Example: User shares a run with friends; friends see route map and pace.
- Example: User requests a coach; matching service uses goal, age band and city.
- [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
The diagram shows external entities (E), processes (P), data stores (DS) and numbered data flows (F). Grouped zones are trust boundaries.
| 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
| 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
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
Severity is the product of likelihood and impact on the data subject, each rated 1 to 4:
| 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
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 (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 -differential privacy when, for any two datasets and that differ in one person and any output set :
Smaller means stronger privacy and noisier results; record the chosen value and the budget per release if it is adopted.
8. Residual risk
| 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
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
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.
संबंधित टेम्पलेट
Threat Model Template (STRIDE)
STRIDE threat model: scope, DFD with trust boundaries, assets, threats per element, L x I rating, mitigations, risk acceptance
सॉफ़्टवेयर और इंजीनियरिंगAttack Tree Analysis Template
Attack tree for one attacker goal: AND/OR tree as list and Mermaid, leaf cost/skill/likelihood, path analysis, countermeasures
सॉफ़्टवेयर और इंजीनियरिंगMigration Plan Template
System or data migration: strategy, phases, data mapping, reconciliation, cutover runbook, rollback, decommissioning