GDPR never uses the words "threat model." It doesn't name STRIDE, a diagramming notation, or any other method. What it does is ask, over and over, for "appropriate technical and organisational measures" chosen in light of the risks a piece of processing creates, and for evidence that someone actually thought about those risks before building it. That's the same shape of question a threat model answers, which is why security teams reach for one when GDPR comes up. It covers about half of what the regulation cares about. This post looks at which half, and what privacy engineering adds for the rest.
In short: STRIDE lines up well with GDPR's security obligations (Article 32 and the definition of a personal data breach). It is mostly silent on GDPR's privacy principles, such as purpose limitation, minimisation, retention and data subject rights, because those can be breached by a system working exactly as designed, with no attacker anywhere. A privacy-focused pass such as LINDDUN, run on the same diagram, is how teams usually cover that second half.
A note on framing: this is a description of how the two disciplines overlap, not advice on what any particular organisation is legally required to do. Whether GDPR applies to you, in what role, and which articles bite hardest depends on your processing, and that's a question for your data protection officer or counsel. Article references below are to the EU regulation; the UK GDPR mirrors them closely.
The articles a threat model actually touches
Out of 99 articles, a handful do most of the work for engineering teams:
- Article 5: the principles. Lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability, meaning you must be able to demonstrate compliance with all of the above. Only one of those seven is a security principle.
- Article 25: data protection by design and by default. Controllers must build those principles into processing "at the time of the determination of the means for processing and at the time of the processing itself," and by default process only the personal data each purpose needs. This is the privacy equivalent of secure-by-design, and the clearest legal hook for doing analysis at design time.
- Article 32: security of processing. Risk-appropriate measures, with examples: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, the ability to restore access after an incident, and a process for regularly testing whether the measures work.
- Articles 33 and 34: breach notification. Notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach that poses a risk to people; tell the affected individuals too when the risk is high.
- Article 35: the Data Protection Impact Assessment (DPIA), required for processing "likely to result in a high risk to the rights and freedoms of natural persons." More on how it relates to a threat model below.
The thread running through all of them is a shift in whose risk is being assessed. A typical threat model asks what could go wrong for the organisation: data stolen, service down, money lost. GDPR asks what could go wrong for the people the data is about. Most of the time the answers overlap. Where they don't is exactly where STRIDE stops being enough.
Where STRIDE covers GDPR
Start with how GDPR defines a personal data breach (Article 4(12)): "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data." That's not only about leaks. Destruction and loss are availability failures; alteration is an integrity failure. Read alongside Article 32, it maps onto STRIDE almost category for category:
| STRIDE | GDPR counterpart | What to look for on the diagram |
|---|---|---|
| S Spoofing | Unauthorised access (Art. 4(12)); confidentiality (Art. 5(1)(f)) | Weak authentication on any flow that returns personal data, including support and admin tools |
| T Tampering | Alteration (Art. 4(12)); integrity and the accuracy principle (Art. 5(1)(d)) | Who can write to stores holding personal data, and whether changes are validated and attributable |
| R Repudiation | Accountability (Art. 5(2)); the ability to assess and document a breach (Art. 33) | Whether logs can tell you which records were accessed, by whom, and when |
| I Information disclosure | Unauthorised disclosure (Art. 4(12)); encryption and pseudonymisation (Art. 32(1)(a)) | Personal data crossing a trust boundary unencrypted, over-broad API responses, data in logs and caches |
| D Denial of service | Destruction or loss (Art. 4(12)); availability, resilience and timely restore (Art. 32(1)(b)–(c)) | Single points of failure on stores holding personal data; backups that have never been restored |
| E Elevation of privilege | Unauthorised access; confidentiality and integrity (Art. 5(1)(f)) | Roles and service accounts that can reach more personal data than their function needs |
The Repudiation row deserves a second look, because GDPR gives it a deadline. The 72-hour notification window starts when you become aware of a breach, and the notification is supposed to describe the categories and approximate number of people and records affected. If the threat model's answer to "can we tell what an attacker read?" is "we log that the API was called, not which rows came back," you'll find out during an incident that you can't scope it. That's a design decision, and the threat model is where it gets made.
Where STRIDE goes quiet
Now run the other six Article 5 principles past STRIDE. Imagine a sign-up flow that collects a phone number "for account recovery," then quietly feeds it to a marketing enrichment vendor. It keeps it forever, includes it in every analytics export, and has no path to delete it when the user asks. There's no spoofing, no tampering, no attacker. Every component is authenticated, encrypted and behaving exactly as built. A STRIDE review can pass it clean. Under GDPR, it raises questions about purpose limitation, minimisation, storage limitation, transparency and the right to erasure.
That class of problem, harm caused by the system working as designed, is what privacy threat modeling exists for. LINDDUN's categories (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance) are covered in What Is LINDDUN?, so rather than repeat them, here's how the principles STRIDE misses show up as concrete questions on a diagram:
| GDPR principle or right | Design-time question | Closest LINDDUN category |
|---|---|---|
| Purpose limitation (Art. 5(1)(b)) | Does each flow carrying personal data have a stated purpose, and does any downstream process use it for something else? | Unawareness, Non-compliance |
| Data minimisation (Art. 5(1)(c)) | Does every field on this flow need to be there? Could the receiver work with an ID, an aggregate, or nothing? | Disclosure, Identifiability |
| Storage limitation (Art. 5(1)(e)) | Does each data store have a retention period, and does anything actually enforce it? | Non-compliance |
| Transparency (Arts. 12–14) | Would the person recognise this flow from what you told them when you collected the data? | Unawareness |
| Data subject rights (Arts. 15–22) | Can an access or erasure request reach every store this person's data lands in? | Unawareness, Non-compliance |
| Pseudonymised data (Recital 26) | Can this "anonymous" dataset be joined back to a person using other data you, or a recipient, hold? | Linkability, Identifiability |
There's also a genuine tension between the two halves. STRIDE's Repudiation category pushes you to log more, which is what you need to scope a breach. But logs about people are themselves personal data, subject to minimisation and retention like any other store. LINDDUN's Non-repudiation category is literally the inverse of STRIDE's. Neither framework resolves that trade-off for you; running both on the same system is how you notice it exists.
Putting GDPR on the data flow diagram
You don't need a separate privacy diagram. The data flow diagram you already use for STRIDE carries most of what a privacy pass needs, if you annotate it a bit more:
- Label flows with data categories, not just protocols. "HTTPS / JSON" tells a security reviewer something; "email, IP address, order history" tells a privacy reviewer what's at stake. Mark special category data (health, biometrics and the other Article 9 categories) distinctly, since it raises the stakes on everything it touches.
- Give every data store a retention period and a deletion mechanism. Then look for the stores nobody thinks of as databases: application logs, analytics warehouses, search indexes, caches, message queues with long retention, error trackers, and backups. These are where erasure requests quietly fail.
- Treat some trust boundaries as legal boundaries too. A flow to an external entity that processes data on your behalf is a processor relationship under Article 28. A flow that lands in another jurisdiction may be an international transfer under Chapter V. The vendor integrations post goes deeper on that edge of the diagram.
- Draw the rights paths as flows. A data subject access or erasure request is a process with inputs and outputs like any other. Drawing it, from the request intake to every store it must reach, is the fastest way to find the store it doesn't.
With that in place, the method is the one you already know: walk each element, apply STRIDE everywhere, and add the privacy questions anywhere personal data is present. Elements with no personal data can skip the second pass, which keeps the overhead proportionate.
Threat model vs. DPIA
The question that comes up most is whether a threat model is a DPIA. They overlap heavily but answer different questions, and Article 35(7) is specific about what a DPIA must contain:
| Threat model | DPIA (Art. 35) | |
|---|---|---|
| Trigger | Usually internal policy: new systems and significant changes | Required by law for processing likely to result in high risk to individuals |
| Whose risk | Mostly the organisation's | The rights and freedoms of the people whose data it is |
| Describes the system? | Yes, in detail: components, flows, boundaries | Yes: "a systematic description of the envisaged processing operations and the purposes" |
| Asks if it should exist? | No; it takes the design's purpose as given | Yes: an assessment of necessity and proportionality in relation to the purposes |
| Output | Threats, mitigations, a risk register | Risks to individuals, the measures to address them, and a documented decision, including consultation with the authority if high risk remains (Art. 36) |
| Who's involved | Engineers and security | The controller, seeking the advice of the DPO where one is designated |
In practice the threat model is a strong input to a DPIA rather than a substitute. It supplies the systematic description (your DFD) and most of the security measures. What it doesn't supply is the necessity and proportionality reasoning, or a view of harm from the individual's side, and those parts need people who aren't only engineers. Teams that keep the two linked, with the DPIA referencing the threat model and risk register by version, tend to find the DPIA much easier to keep current when the system changes.
Common mistakes
- Treating GDPR as an encryption checklist. Encryption shows up once in Article 32 as an example. It does nothing for purpose limitation, retention or rights, which is where many of the hard design questions are.
- Assuming pseudonymised means anonymous. Recital 26 is explicit that pseudonymised data which can be attributed to a person using additional information is still personal data. Hashed emails and stable user IDs usually fall on that side.
- Modelling only the production data path. Support tooling, admin consoles, data exports, staging copies of production and analytics pipelines all hold personal data, and they're often the least controlled parts of the system.
- Doing the privacy pass once. Article 25 applies when you design the processing and while it runs. A new field, a new vendor or a new use of existing data is a change worth re-reviewing, the same way you'd re-threat-model for a new trust boundary.
- Letting the tool claim compliance. A threat model, in any tool, is evidence of analysis. Whether processing complies with GDPR is a legal judgement made by the controller, and no diagram makes it for you.
The useful mental model is that GDPR asks two questions about every flow of personal data: is it protected, and should it be happening at all? STRIDE is a mature, well-practised way to answer the first. The second needs a different lens, but not a different diagram, and the teams that do it well usually just run both passes on the same model.
Privacy harm is the primary risk in regulated health data. See threat modeling for healthcare and threat modeling for SaaS, or start from the free data flow diagram template.