LINDDUN is a threat-modeling framework built for a question STRIDE was never designed to answer: not "can an attacker break this system," but "does this system handle personal data in a way that harms the people it belongs to" — even when every actor involved, including your own backend, is behaving exactly as intended. Developed at KU Leuven, it takes STRIDE's element-by-element discipline and points it at privacy instead of security.
Quick definition: LINDDUN is a mnemonic for seven categories of privacy threat — Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance — applied to a Data Flow Diagram the same way STRIDE is.
The seven categories
| Threat | Question | Example |
|---|---|---|
| L Linkability | Can two items be linked to learn more than either reveals alone? | A persistent tracking ID correlates a user's purchases across sessions they thought were separate |
| I Identifiability | Can a specific person be picked out of a supposedly anonymous set? | A "de-identified" record is re-identified from the combination of zip code, birth date, and gender |
| N Non-repudiation | Does the system produce evidence a user should be able to deny? | Server logs prove which specific employee viewed a colleague's HR record, when anonymity was expected |
| D Detectability | Can the existence of an item be inferred without reading it? | Encrypted message size and timing reveal that two parties are communicating, even though content is hidden |
| D Disclosure of Information | Can an attacker access the content directly? | A misconfigured API endpoint returns users' home addresses to any authenticated caller |
| U Unawareness | Can users influence how their own data is collected and used? | Location data collected for one feature is silently reused to train an unrelated model |
| N Non-compliance | Does the system violate law, policy, or stated user expectations? | A privacy policy promises 30-day data retention that the database schema never actually enforces |
Why "Non-repudiation" means the opposite of what it means in STRIDE
This trips people up the first time: in STRIDE, Repudiation is a threat because a system doesn't produce enough evidence to hold a user accountable — you want more logging. In LINDDUN, Non-repudiation is a threat because a system produces too much evidence, stripping a user of the plausible deniability privacy sometimes requires. Same word, opposite direction, because the two frameworks are optimizing for different things. It's the clearest illustration of why you generally need both: STRIDE assumes more accountability is always good, and for security it usually is. Privacy is more conditional.
How LINDDUN is actually applied
Like STRIDE, LINDDUN is applied per element of a Data Flow Diagram, not to the system as a whole. For each external entity, process, data store, and data flow, you ask which of the seven categories apply — and specifically, whether personal data is involved at that point. A data store holding payment metadata gets checked against all seven; an internal health-check endpoint that carries no personal data typically doesn't need the same pass.
The practical difference from STRIDE is what counts as "in scope." STRIDE cares whether an attacker can compromise confidentiality, integrity, or availability. LINDDUN cares whether the system itself — functioning correctly, with no attacker involved — still does something a data subject wouldn't consent to if they understood it. That's why LINDDUN threats often surface in design reviews and privacy impact assessments rather than security audits.
LINDDUN vs. STRIDE: do you need both?
If your system touches personal data under GDPR, CCPA, or similar regulation, yes — they answer different questions and neither substitutes for the other. A system can pass a full STRIDE review with zero exploitable vulnerabilities and still fail LINDDUN badly, because privacy harm doesn't require a breach. Run STRIDE first since it's faster to learn and covers more ground for a typical B2B SaaS product, then add a LINDDUN pass specifically on flows that touch personal data — you don't need to re-run it against your entire system, just the parts where a data subject's information is actually moving.
For the framework most teams should learn first, see What Is STRIDE? — and for how both frameworks anchor to the same underlying diagram, see What Is a Data Flow Diagram (DFD)?