LINDDUN Walkthrough — Privacy Threat Modelling

Table of contents

Overview

This walkthrough demonstrates how to use the LINDDUN framework within the threat modelling tool to identify and assess privacy threats. We use a Patient Portal as the example system — a web application that allows patients to view medical records, book appointments, and message their care team.

LINDDUN is complementary to STRIDE: where STRIDE focuses on security threats, LINDDUN focuses on privacy threats. Both frameworks can be applied in the same model.

The System

Application: Patient Portal
Owner: Digital Health Team
Data classification: Restricted (personal health information)
Regulations in scope: UK GDPR, NHS Data Security Standards

Components:

• Patient web application (browser)
• API Gateway
• Patient Records Service (backend)
• Appointment Service (backend)
• PostgreSQL database (patient data store)
• NHS Authentication Service (external)
• Email Notification Service (external)

Trust boundaries:

• Public internet → API Gateway
• API Gateway → Internal services
• Internal services → Database

Step 1 — Application Info

Create a new model and complete the Application Info step:

Step 2 — Scope & Decomposition

Trust levels:

1. Unauthenticated public (internet)
2. Authenticated patient
3. Care team staff
4. Internal services
5. Database administrators

Threat agents:

• Curious employee (medium capability) — insider browsing patient records without clinical need
• Malicious third party (high capability) — external attacker targeting health data for sale
• Nation-state actor (nation-state capability) — targeting healthcare infrastructure

Data classification: Restricted — includes NHS numbers, diagnoses, medication history, appointment details.

Step 3 — System & Data Flow Diagram

Map the following components and flows:

Components:

• Patient Browser (external-entity)
• API Gateway (service)
• Auth Service / NHS Login (external-entity)
• Patient Records Service (process)
• Appointment Service (process)
• Email Service (external-entity)
• Patient Database (datastore)

Data flows:

• Patient Browser → API Gateway (HTTPS, authenticated)
• API Gateway → Auth Service (OAuth2, encrypted)
• API Gateway → Patient Records Service (internal, encrypted)
• Patient Records Service → Patient Database (internal, encrypted at rest)
• Appointment Service → Email Service (SMTP, personal data in body)

Trust boundary crossings to flag:

• Patient Browser → API Gateway (public internet crossing)
• API Gateway → Email Service (data leaving internal network)

Step 4 — Identifying LINDDUN Threats

For each component and data flow, apply the seven LINDDUN categories. Below are worked examples.

Threat 1 — Linkability via Appointment Emails

Component / Flow: Appointment Service → Email Service
LINDDUN category: Linkability (L)
Target: Data Flow — appointment confirmation email

Description:
Appointment confirmation emails include the patient’s name, NHS number, clinic location, and appointment type (e.g. “Oncology Department — 14 June 09:30”). An attacker who intercepts the email (or gains access to the email provider) can link the patient’s identity to a specific medical condition.

Likelihood: 3 — Moderate (email is an external service, SMTP may be unencrypted in transit)
Impact: 5 — Critical (disclosure of sensitive health data; regulatory breach)
Risk score: 15 — High

Mitigations:

• Enforce TLS for all SMTP connections (preventive)
• Reduce information in email body — replace appointment type with a reference number only (preventive)
• Implement end-to-end encrypted messaging within the portal instead of email (preventive)
• Audit email content before implementation against UK GDPR Data Minimisation principle (detective)

Threat 2 — Identifiability via Audit Logs

Component / Flow: Patient Records Service → Patient Database
LINDDUN category: Identifiability (I)
Target: Component — Patient Database

Description:
Application audit logs record which patient records were accessed, by which user, at what time — including failed access attempts. If logs are not properly protected, an insider (or attacker with log access) can identify individual patients from query patterns, even without direct database access.

Likelihood: 2 — Low (requires privileged access to log store)
Impact: 4 — High (identifies patients linked to specific conditions or treatments)
Risk score: 8 — Medium

Mitigations:

• Implement role-based access control on log storage (preventive)
• Pseudonymise patient identifiers in log records where operationally possible (preventive)
• Alert on bulk log queries or exports (detective)
• Review log retention policy — retain only what is needed for incident investigation (corrective)

Threat 3 — Non-repudiation for Patients

Component / Flow: Patient Records Service
LINDDUN category: Non-repudiation (N)
Target: Component — Patient Records Service

Description:
The system logs every patient access to their own records with timestamps. While intended for audit purposes, this creates a detailed record that patients cannot dispute — for example, a record of when they viewed information about a specific condition. This data could be requested by insurers, employers, or law enforcement.

Likelihood: 2 — Low (requires authorised disclosure or legal request)
Impact: 3 — Medium (potential chilling effect on patients accessing their own records)
Risk score: 6 — Medium

Mitigations:

• Define and document data retention limits for patient self-access logs (corrective)
• Disclose to patients in the privacy notice that access logs are maintained (preventive)
• Apply data minimisation — log access events without recording which specific record was viewed (preventive)

Threat 4 — Detectability of Sensitive Conditions

Component / Flow: API Gateway → Patient Records Service
LINDDUN category: Detectability (D)
Target: Data Flow — API requests

Description:
API endpoint naming conventions reveal the type of data being requested. For example, GET /api/patients/{id}/hiv-status or GET /api/patients/{id}/mental-health-records makes it possible to infer a patient’s conditions from network traffic monitoring, even without reading the response body.

Likelihood: 3 — Moderate (any network observer on the path can see URL paths)
Impact: 5 — Critical (reveals sensitive condition categories)
Risk score: 15 — High

Mitigations:

• Adopt generic API endpoint naming (e.g. GET /api/patients/{id}/records/{record-id}) (preventive)
• Encrypt all internal API traffic (preventive — already required, verify implementation)
• Apply API gateway request logging controls to prevent log capture of full URLs (preventive)

Threat 5 — Unawareness of Third-Party Sharing

Component / Flow: Appointment Service → Email Service (external)
LINDDUN category: Unawareness (U)
Target: Component — Email Service

Description:
Patients are not informed at registration that their appointment details are processed by an external email provider. The email provider’s data processing activities (including potential storage of email metadata) are not covered in the patient-facing privacy notice.

Likelihood: 4 — High (no disclosure currently exists)
Impact: 3 — Medium (regulatory breach, patient trust impact)
Risk score: 12 — High

Mitigations:

• Update patient privacy notice to list the email service as a data processor (preventive)
• Add a sub-processor record for the email provider to the data processing register (preventive)
• Obtain a Data Processing Agreement with the email provider (preventive)

Step 5 — Risk Assessment Summary

Step 6 — Countermeasures and Residual Risk

After applying the mitigations documented above:

Step 7 — Security Requirements

Auto-suggested requirements generated from the threats above:

1. Data minimisation in notifications — All outbound patient communications MUST contain the minimum personal data necessary. Appointment confirmations MUST NOT include diagnosis or specialty information.
2. Audit log access control — Access to application audit logs MUST be restricted to defined administrator roles and MUST require multi-factor authentication.
3. Sub-processor disclosure — All data processors handling patient data MUST be documented in the patient privacy notice and covered by a signed Data Processing Agreement.
4. API endpoint naming — API endpoint paths MUST NOT encode sensitive data categories. Implementation MUST be reviewed by the privacy team before release.
5. Encryption in transit — All internal and external API communications MUST use TLS 1.2 or above. SMTP connections MUST enforce TLS using STARTTLS or SMTPS.

Key Takeaways

• LINDDUN and STRIDE complement each other. STRIDE would identify the API gateway as a spoofing/tampering/denial-of-service target; LINDDUN reveals the privacy risks in the same flows.
• Privacy threats are often systemic. The unawareness threat (Threat 5) isn’t a code vulnerability — it’s a process gap. LINDDUN surfaces these non-technical risks.
• Data minimisation resolves multiple threats. Reducing what is included in email notifications simultaneously addresses Linkability, Detectability, and Unawareness threats.
• Export this model as JSON to share it with your privacy officer, or generate a PDF for inclusion in your DPIA (Data Protection Impact Assessment) documentation.