Privacy threat modelling using LINDDUN identifies privacy risks by analysing data flows for linkage, identifiability, non-repudiation, detectability, disclosure, awareness, and non-compliance. It helps teams spot where systems expose people, not just where they are breached. Practitioners should model collection, sharing, storage, and deletion paths, then map mitigations to each privacy threat.
What LINDDUN is doing when you model privacy risk
LINDDUN turns privacy into a structured analysis of data flows, trust boundaries, and the person-level harms those flows can create. Instead of asking only whether an attacker can break in, you ask where data can be linked, identified, observed, disclosed, or used in ways the user would not expect. That makes the method especially useful early in design, before privacy debt hardens into architecture.
The practical value is that it shifts the team from abstract concerns to concrete system behaviour. You are not just naming a privacy principle, you are tracing how collection, sharing, storage, and deletion create exposure points and how those points differ by actor, dataset, purpose, and retention path. For teams that already use classic threat modelling, the method adds a privacy lens without replacing security analysis.
Because the model is flow-based, it works best when the system can be drawn as data in motion and data at rest. The more clearly you can identify data subjects, processing purposes, recipients, and retention events, the easier it is to see which privacy threats are plausible and which mitigations belong at design time rather than in policy paperwork. NHIMG’s Privacy by Design Guide for Engineering Teams is a useful companion for turning those findings into engineering decisions.
How the seven LINDDUN threat classes fit together
LINDDUN groups privacy concerns into seven categories, and the point is not to treat them as a checklist divorced from the system. Linkability asks whether separate records or events can be correlated. Identifiability asks whether a person can be singled out. Non-repudiation asks whether actions can be proven in a way that removes privacy-preserving deniability. Detectability asks whether the presence of a person, event, or attribute can be observed. Disclosure asks whether sensitive data can leak. Awareness asks whether people know what is happening to their data. Non-compliance asks whether the design violates policy, regulation, or declared privacy commitments.
These classes are most useful when you ask them against each data flow, not against the product in general. A login event, analytics pipeline, backup set, support export, or deletion job may create different privacy threats even though they all sit inside the same application. That is why LINDDUN is stronger than a generic “privacy review” template: it forces the team to locate the privacy consequence in the path of data movement.
Good teams use the categories to separate symptoms from causes. For example, “disclosure” may be the visible problem, but the real issue could be overly broad sharing, long retention, weak separation between environments, or a deletion process that leaves copies behind. NHIMG’s Threat Modelling Guide is helpful here because it shows how to work from diagrams and trust boundaries, which is the natural way to apply LINDDUN in practice.
When the system uses automation, event logging, or downstream analytics, one threat often triggers another. A flow that is merely detectable can become linkable, and a linkable flow can become identifiable once correlated with auxiliary data. That is why practitioners should model privacy threats as chains, not isolated labels, and then ask which control breaks the chain earliest.
What good LINDDUN work produces in practice
Useful LINDDUN output is not a report full of labels, it is a design backlog that maps each privacy threat to a control decision. That can mean minimising collection, separating identifiers from content, narrowing retention, constraining sharing, improving transparency, or changing defaults so that the system discloses less by design. Where a threat cannot be removed, the team should decide whether to reduce identifiability, reduce observability, or reduce the duration and spread of the data.
The method also helps distinguish design defects from governance gaps. Some findings are engineering fixes, such as pseudonymisation, deletion enforcement, or access scoping. Others are process controls, such as user notice, purpose limitation, or review of third-party disclosures. A good analysis assigns ownership to the layer that can actually change the exposure, rather than pushing everything into legal review.
LINDDUN is strongest when it is used repeatedly. Early modelling finds obvious privacy failure modes; later passes catch edge cases introduced by telemetry, product analytics, data sharing, or feature flags. If you only run it once at project start, you will miss the privacy effects of implementation choices that appear much later in the delivery cycle. NHIMG’s Threat Modelling Guide and Application Security Guide are both useful references for embedding that repeated review into normal engineering practice.
Risk and Threat Considerations
LINDDUN matters because privacy failures are often caused by ordinary system behaviour, not by a dramatic breach. A product can expose people through correlation, overcollection, persistent identifiers, or overly broad disclosure even when authentication and perimeter controls are working as intended. The risk is that privacy harm accumulates quietly across features, vendors, logs, backups, and analytics pipelines.
Failure mechanism: The system design makes person-level data easier to correlate, observe, retain, or repurpose than the privacy model assumes. That can happen through shared identifiers, verbose telemetry, weak deletion, uncontrolled exports, or insufficient separation between purposes and recipients.
Impact: Individuals can be exposed, tracked, profiled, or placed out of control of their own data, and the organisation can inherit compliance, trust, and remediation costs that are harder to unwind after launch than during design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | A.25 — Data protection by design and by default | LINDDUN operationalises privacy by design for system flows and controls. |
| A.35 — Data protection impact assessment | LINDDUN is a structured way to identify and assess privacy risks in a design. | |
| Recommendation — Design data flows to minimise disclosure, identifiability, and retained exposure from the start. Use privacy threat modelling to document risks, mitigations, and residual exposure before launch. | ||
| NIST SP 800-53 Rev 5 | AR-2 — Privacy Impact and Risk Assessment | LINDDUN supports identifying privacy risks and documenting mitigation decisions. |
| DM-2 — Data Retention and Disposal | Retention and deletion paths are central to privacy threat modelling outcomes. | |
| PT-2 — Authority to Process Personal Data | LINDDUN examines whether processing aligns with expected privacy use and disclosure. | |
| Recommendation — Assess privacy impacts of data flows and record how each risk is reduced or accepted. Define and enforce retention and disposal limits to reduce long-lived exposure. Restrict personal-data processing to approved purposes and disclosures only. | ||
Practitioner Guidance
What to prioritise: Start with the highest-value data flows, usually the ones that collect identifiers, location, communications, financial details, or other sensitive attributes. Those flows tend to create the most privacy threats and usually justify the earliest design changes.
What to verify: Check that the model includes collection, sharing, storage, deletion, and any secondary uses such as analytics or support access. If one of those paths is missing, the privacy assessment is probably incomplete even if the threat list looks thorough.
What good looks like: Each identified privacy threat has a concrete mitigation owner, a design decision, and an evidence trail showing how the team reduced exposure or accepted the remaining risk deliberately. The best outcome is a product that reveals less by default, not merely a better documented risk register.
Practitioner takeaway: Treat LINDDUN as a design discipline, not a documentation exercise, and use it to reduce how much person-level exposure the system creates in the first place.
Related resources from NHI Mgmt Group
- Privacy Threat Modelling (LINDDUN)
- Why do privacy and prompt retention matter when using AI writing tools for creative work?
- How should organisations decide whether to prioritise privacy compliance work or insider threat mitigation first?
- How can security teams reduce privacy risk when using biometrics?