LINDDUN threat modelling starts by mapping data flows, then identifying privacy threats such as linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, and non-compliance. Teams should model each flow, rank likely harms, and choose mitigations such as minimisation, separation, masking, and access controls. They should repeat the exercise when features, vendors, or data uses change.
What LINDDUN Is Best At, and Why the Data Flow Comes First
LINDDUN works best when you treat privacy as a system property of data movement, not as a late-stage checklist. The first pass is to draw the data flow diagram, name the actors, storage points, trust boundaries, and onward disclosures, then ask what privacy loss each hop can create. That makes the exercise concrete enough to find threats before they turn into design debt.
The method is strongest when the team agrees on scope and granularity. If a flow is missing, overly abstract, or merges distinct data uses, the threat model will undercount exposure and produce weak mitigations. Teams also need a repeatable way to distinguish primary flows from downstream uses, because privacy threats often appear only after data is repurposed, linked, or retained longer than intended.
Good practice is to pair the model with a privacy-by-design review so the threat model does not become an isolated workshop artifact. NHIMG’s Privacy by Design Guide for Engineering Teams is a useful companion because it connects LINDDUN to engineering decisions such as pseudonymisation, deletion, and privacy requirements.
How to Work the LINDDUN Threat Categories Without Turning Them Into Theory
Once the flows are mapped, the practical task is to test each one against the LINDDUN categories, linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, and non-compliance. The value is not in naming the labels, but in forcing the team to ask what an observer, a recipient, or a future user could infer from the flow. A single flow can trigger more than one threat, especially when logs, identifiers, or metadata are shared widely.
Best practice is to rank the most plausible harms first. Not every privacy issue deserves the same response, so teams should distinguish between high-probability, high-impact exposure and lower-value theoretical findings. That ranking step is what turns the model into a decision tool: it helps determine which flows need minimisation, which need separation, and which need stronger masking or access controls.
For practitioners who want a broader modelling discipline around the exercise, NHIMG’s Threat Modelling Guide is directly relevant because it covers DFDs, trust boundaries, and LINDDUN alongside other threat modelling methods.
When the subject involves regulated personal data, the privacy model should also be read against the organisation’s legal obligations. GDPR Article 25 and Article 35 often make LINDDUN findings operationally important rather than merely advisory, so the model should identify where design choices may increase compliance burden or make a DPIA harder to defend. The NIST Privacy Framework is a strong external reference for translating those findings into governance and data handling decisions.
Choosing Mitigations That Reduce Privacy Risk Instead of Just Shifting It Around
The most useful mitigations in LINDDUN are the ones that reduce linkability, identifiability, and unnecessary disclosure at the source. Minimisation is usually the first lever: collect less, retain less, and expose less metadata. Separation and masking follow when the business still needs the data, but not in a form that can be trivially linked across contexts. Access controls matter, but they are strongest when combined with architectural choices that reduce the amount of sensitive data any one path can reach.
Teams should avoid a common mistake: compensating for a broad privacy design problem with one narrow control. For example, stronger access control does not fix excessive collection, and pseudonymisation does not help if the same identifiers are reused across unrelated systems. The point is to reduce the number of places where re-identification or unwanted inference can happen, not just to harden one endpoint.
If the model shows that identity material or API credentials are part of the flow, the privacy threat can quickly become a security threat as well. In that case, the right mitigation is often to treat the exposed path as a broader trust problem, not only a privacy problem. NHIMG’s API Key Management Guide is useful where machine access, scoped keys, rotation, and revocation are part of the privacy control surface.
Risk and Threat Considerations
LINDDUN is especially valuable because privacy failures often emerge through legitimate features, not obvious attacks. A design that makes data easy to correlate, infer, or reuse can create exposure even when the system is technically secure, and the risk grows when vendors, analytics tools, or new product uses introduce fresh visibility into the same data. That is why privacy threat modelling should be revisited whenever the flow, purpose, or recipient changes.
Failure mechanism: The control fails when teams model only the intended business flow and miss secondary disclosures, identifier reuse, or metadata that allows correlation across systems. The same weakness appears when privacy mitigations are applied to one component but not to the end-to-end path.
Impact: The result can be persistent re-identification risk, unwanted surveillance potential, regulatory non-compliance, and a privacy posture that degrades as the product evolves. Once those paths exist, later features can inherit the exposure even if they were not part of the original 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 is used to operationalise privacy by design for personal data flows. |
| A.35 — Data protection impact assessment | LINDDUN findings often feed DPIA-style privacy risk analysis for personal data processing. | |
| Recommendation — Use privacy threat findings to shape minimisation and default-protective design choices. Translate identified privacy threats into documented DPIA risks and mitigations. | ||
| NIST SP 800-53 Rev 5 | RA-3 — Risk Assessment | Threat modelling is a structured risk assessment method for privacy harms in data flows. |
| AC-6 — Least Privilege | Access restrictions are a common mitigation for privacy disclosure and overexposure. | |
| SC-28 — Protection of Information at Rest | Privacy controls often require reducing exposure of stored personal data and derived data. | |
| Recommendation — Assess privacy risks on each data flow and record the mitigation decision. Limit access to personal data to the minimum set of roles and systems. Encrypt or otherwise protect stored data that would amplify privacy harm if exposed. | ||
Practitioner Guidance
What to prioritise: Start with the flows that combine high sensitivity, broad sharing, and long retention. Those paths usually create the most privacy debt, and they are the hardest to fix later without redesign.
What to verify: Confirm that the model covers storage, logs, exports, third-party integrations, and fallback processes, not just the primary application journey. If the data can leave the system through another route, the privacy threat model is incomplete.
Common mistake: Treating LINDDUN as a one-time documentation exercise. The best teams rerun it when data use, recipients, or vendors change, because privacy risk is highly sensitive to context and reuse.
Practitioner takeaway: LINDDUN is most effective when it drives design choices early, and then gets refreshed whenever data starts serving a new purpose, because privacy harm usually comes from reuse and linkage, not from the first feature that collected the data.