Privacy Threat Modelling (LINDDUN) is a structured method for finding privacy risks in a system by examining data flows and likely threats. It helps teams identify linkability, identifiability, disclosure, and other privacy harms. The result should drive controls such as minimisation, segmentation, and stronger consent handling.
How LINDDUN Frames Privacy Risk
LINDDUN is a privacy-focused threat modelling method that starts from data flows rather than from attacker intent alone. It helps teams reason about how information can be linked, exposed, inferred, or over-collected as a system moves data between users, services, logs, and third parties.
Because the method is built around privacy harms, it is useful wherever a design processes personal or sensitive data and the team needs to spot risk early. That makes it a practical complement to broader threat modelling, not a replacement for it, and Threat Modelling Guide is a useful companion when the same system also needs conventional security analysis.
Core Privacy Harms LINDDUN Looks For
The LINDDUN categories focus attention on the kinds of harms that are easy to miss in ordinary security reviews. Linkability asks whether activities can be correlated across contexts, identifiability asks whether a person can be singled out, and disclosure covers unwanted exposure of data or relationships.
Other categories capture privacy failure modes that are often design-level, not just breach-level: detectability, information disclosure, unawareness, non-compliance, and policy or consent failures. The value of the method is that it pushes teams to ask not only “can this be attacked?” but also “what privacy harm becomes possible if this flow exists at all?”
That is why the same system may need different mitigations depending on the data path. A log stream, analytics pipeline, support workflow, or partner integration can create privacy exposure even when the application is otherwise well secured.
Where It Fits in Design and Engineering
LINDDUN is most effective when used during architecture and feature design, before privacy debt becomes expensive to unwind. Teams usually model assets, actors, trust boundaries, and data flows, then attach privacy threats to each flow so that controls can be chosen with the actual harm in mind.
The method naturally leads to design changes such as data minimisation, segmentation, shorter retention, pseudonymisation, and stronger consent handling. For engineering teams, Privacy by Design Guide for Engineering Teams gives a broader implementation context for those outcomes, including privacy requirements, deletion pipelines, and code review.
LINDDUN also works well alongside general application security work, because a system can be secure in the classic sense while still being overly revealing. Application Security Guide is helpful where privacy findings need to be turned into broader secure SDLC work, testing, and remediation tracking.
What Good Output Looks Like
A useful LINDDUN result is not just a list of threats, but a design decision record. The output should show which data flows create which privacy harms, what assumptions make those harms possible, and which controls reduce the exposure without breaking the product.
That makes the method especially valuable for teams that must explain privacy choices to product, legal, security, and engineering stakeholders at the same time. It gives each group a shared language for comparing options such as collecting less data, changing a trust boundary, reducing observability, or tightening user consent handling.
Where privacy is governed by formal obligations, LINDDUN findings can support compliance work too. The method is particularly compatible with privacy engineering practices described in EU General Data Protection Regulation (GDPR) and the NIST Privacy Framework, both of which help translate privacy risk into accountable controls and governance.
Risk and Threat Considerations
Privacy threat modelling is valuable because privacy failures often arise from ordinary system behaviour, not obvious compromise. Over-broad collection, cross-context correlation, hidden identifiers, weak deletion, or permissive sharing can create privacy exposure even when access controls and authentication are otherwise sound.
Failure mechanism: The system design makes it easy to connect, infer, or expose data across contexts, so privacy harms emerge through data flow, aggregation, or reuse rather than a single dramatic intrusion.
Impact: Organisations can create disclosure, re-identification, consent failure, and regulatory exposure, while users can lose control over how their data is linked, retained, or repurposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | A.5.1 — Lawfulness, fairness and transparency | Privacy threat modelling supports lawful, fair, transparent data handling decisions. |
| Recommendation — Map identified privacy harms to lawful processing and document the design basis for each data flow. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities are Identified and Documented | LINDDUN is a structured way to identify privacy weaknesses in data flows and design assumptions. |
| PR.DS-01 — Data-at-rest is Protected | Privacy harms often begin with overexposed stored data and weak retention controls. | |
| PR.DS-11 — Backup and Archive Data is Protected | Archived copies can preserve privacy exposure after the live system has been changed. | |
| Recommendation — Document privacy weaknesses in each data flow and track them as actionable risks. Protect stored personal data and remove data that should not persist. Apply the same privacy controls to archives and backups as to production data. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Privacy modelling often recommends tighter access boundaries to reduce disclosure risk. |
| A.8.11 — Data masking | Masking is a practical response to identifiability and disclosure concerns. | |
| Recommendation — Limit access to personal data according to the identified privacy threat model. Mask personal data where the workflow does not require direct identification. | ||
Practitioner Guidance
Why practitioners should care: LINDDUN is most useful when privacy risk has to be found before implementation choices harden into architecture. It helps teams focus on the exact flow, context, and data element that creates the harm, instead of treating privacy as a generic policy problem.
What to watch for: Pay close attention to flows that cross organisational boundaries, enrich profiles, retain identifiers longer than necessary, or combine datasets that were never meant to be correlated. Those are the places where privacy harms often multiply.
Practitioner takeaway: Use LINDDUN to decide what should not be collected, not only how to secure what was collected.
Related resources from NHI Mgmt Group
- How can organisations tell whether their threat modelling is actually improving security?
- Who is accountable when AI components are added without threat modelling?
- How do security teams balance insider threat monitoring with employee privacy and trust?
- How should security teams use API security events to improve governance and threat modelling?