Start by mapping the personal data flow, then identify privacy threats at each step using the LINDDUN categories. Prioritise likely misuse, weak access controls, over-collection, linkability and disclosure risks, then assign mitigations to design, engineering and control owners. Revisit the model when the data flow, processors or purposes change.
How to frame the first LINDDUN workshop
Start with a concrete data-flow view rather than a list of abstract risks. A simple diagram of sources, collection points, storage, sharing, retention, and deletion gives the team a shared object to analyse, and it keeps the discussion anchored in where personal data actually moves, changes hands, or is exposed.
That first pass should also define scope tightly enough to be useful. If you cannot say which personal data, which purposes, and which processors are in scope, the model will drift into generic privacy concerns instead of producing threats that can be assigned and acted on.
Use the workshop to establish a repeatable privacy review rhythm, not a one-time brainstorm. A Threat Modelling Guide is useful here because LINDDUN works best when the team follows a disciplined process with trust boundaries, assumptions, and recorded decisions.
Which LINDDUN threats matter most at the start
Once the flow is mapped, begin with the threats that are most likely to create immediate privacy harm or implementation confusion. Linkability, identifiability, disclosure, and over-collection usually surface quickly because they can be observed directly in the design, data schema, access path, or logging behaviour.
Do not treat every LINDDUN category as equally urgent in the first round. The practical starting point is to prioritise the threats that are easiest to trigger through ordinary engineering choices, such as collecting too much data, retaining it too long, exposing it through broad access, or allowing different datasets to be correlated across systems.
That is why privacy threat modelling should sit inside the wider privacy engineering workflow, not beside it. NHIMG’s Privacy by Design Guide for Engineering Teams connects LINDDUN to design decisions, data minimisation, pseudonymisation, and deletion practices that make the model operational.
How to turn threats into ownership and change control
The model is only useful if every identified threat ends with an owner and a next action. Design owners, engineering teams, and control owners should each receive the mitigations that sit in their lane, whether that means changing collection logic, narrowing access, adding deletion controls, or revising processor arrangements.
That ownership step matters because privacy failures often appear in the gaps between teams. One team may own the product feature, another the infrastructure, and a third the legal basis or retention policy, so the threat model should make the dependency chain explicit rather than assuming someone else will notice the issue.
For teams building privacy into an SDLC, it helps to pair LINDDUN with broader application security practice. The Application Security Guide is a useful companion because it shows how threat modelling findings can be folded into secure design reviews, backlog prioritisation, and verification work.
Risk and Threat Considerations
Privacy threat modelling fails when teams focus on the diagram but ignore the trust relationships behind it. The main risks are missed data paths, under-scoped processors, and controls that look adequate on paper but do not actually prevent reuse, disclosure, or excessive collection once the system is built.
Failure mechanism: The team models the initial architecture once, then fails to revisit changes in purpose, processor, storage location, or integration pattern, so the privacy threat picture becomes stale while the system evolves.
Impact: Old assumptions keep driving new releases, which can leave organisations with unreviewed disclosure paths, weaker minimisation, and controls that no longer match how personal data is really used.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | Privacy flows often hinge on service interfaces that expose personal data. |
| V14 — Data Protection | LINDDUN priorities include over-collection, disclosure, and minimisation controls. | |
| Recommendation — Review API exposure points and enforce access checks on data-returning endpoints. Validate minimisation, retention, masking, and deletion controls for personal data. | ||
| NIST SP 800-53 Rev 5 | AR-4 — Privacy Monitoring and Auditing | LINDDUN requires recurring review as purposes, processors, and flows change. |
| PT-2 — Authority and Purpose | Privacy threat modelling starts with defined purposes and allowable processing. | |
| PT-3 — Personally Identifiable Information Processing and Transparency | LINDDUN depends on understanding where personal data is collected and shared. | |
| Recommendation — Monitor privacy controls and reassess them when data processing changes. Define and enforce the authorised purpose for each personal-data flow. Document PII processing paths and make collection and sharing visible. | ||
Practitioner Guidance
Where to start: Build the first pass around one high-value data journey, not the whole organisation. A narrow but complete flow will expose the most important privacy decisions faster than a broad inventory that never reaches threat analysis.
What to verify: Confirm that the identified threats are tied to observable design elements, such as a collector, processor, retention point, export path, or access control. If a threat cannot be linked to a concrete system behaviour, it is probably too vague to prioritise.
What practitioners underestimate: The model must change when business purpose changes, not just when code changes. A new processor, a new analytics use case, or a new sharing relationship can invalidate an otherwise sound LINDDUN assessment.
Practitioner takeaway: The most effective LINDDUN start is a small, real data flow with explicit ownership, because privacy threats only become actionable when they are tied to a specific system change and a named decision-maker.