LINDDUN Privacy Threat Modeling: A Practitioner's Guide for APIs, Queues, and Data Stores

Your STRIDE threat model passes review. Your pen test comes back clean. Then GDPR enforcement lands a seven-figure fine because your telemetry pipeline links pseudonymous event IDs back to real users across sessions without a lawful basis.

STRIDE was designed to model confidentiality, integrity, and availability threats. It does not ask whether you are collecting more data than necessary, whether individuals can be singled out from aggregate records, or whether your data flows are transparent to the people they describe. That is the job of LINDDUN.

LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance) is a systematic privacy threat modeling methodology developed at KU Leuven. It applies the same structured, DFD-driven process that security engineers already use with STRIDE, but targets the privacy properties that GDPR Article 25 and CCPA Section 1798.100 actually require.

This guide walks through how to apply LINDDUN to the components where privacy failures most commonly occur in modern architectures: APIs, message queues, and data stores. A worked telemetry pipeline example covers the full threat enumeration and mitigation cycle.

Both frameworks operate on data flow diagrams and enumerate threats by component type. The difference is what they protect and whose interests they serve.

The STRIDE-to-LINDDUN mapping looks like this:

Non-repudiation deserves special attention here: in security, the inability to deny an action is a goal. In privacy, it is a threat. Audit logs that prove a user performed an action are desirable for security but must be governed carefully for privacy, especially when they enable behavioral profiling.

Run both models. STRIDE findings feed your security risk register. LINDDUN findings feed your DPIA. Neither substitutes for the other.

Before applying LINDDUN to DFD components, you need a working definition of each threat category.

LINDDUN threat elicitation follows the same DFD component types as STRIDE. Each component type has a characteristic threat profile.

Processes (your APIs, microservices, functions):

• Primary risks: Linkability (joining data across calls), Identifiability (aggregating quasi-identifiers), Non-repudiation (logging user actions in recoverable form)
• Ask: Does this process combine data from multiple sources in ways users did not consent to? Does it log more than it needs to fulfill its function?

Data Stores (databases, object stores, caches, data lakes):

• Primary risks: Disclosure of information (access control failures), Linkability (cross-table joins that reconstruct identity), Non-compliance (retention policy violations)
• Ask: Who can query this store? What is the minimum retention required? Can records be linked back to individuals after pseudonymization?

Data Flows (API calls, queue messages, event streams, ETL pipelines):

• Primary risks: Detectability (traffic analysis), Disclosure of information (insufficient encryption or TLS misconfiguration), Linkability (correlation IDs that persist across system boundaries)
• Ask: Does the metadata of this flow (size, timing, destination) reveal sensitive information even if the payload is encrypted?

External Entities (third-party SDKs, SaaS analytics, CDNs, data brokers):

• Primary risks: Unawareness (users do not know data leaves your perimeter), Non-compliance (transfers to jurisdictions without adequacy decisions), Disclosure of information (data shared beyond stated purpose)
• Ask: Is every data transfer to this entity disclosed in your privacy notice? Does it require a Data Processing Agreement (DPA) or Standard Contractual Clauses (SCCs)?

Consider a standard product analytics pipeline: a client SDK sends events to a collection API, which publishes to a Kafka topic, which is consumed by a Flink job that writes enriched records to S3, which is then queried by Spark/BigQuery for dashboards.

The DFD nodes are:

• External Entity: User device (mobile app or browser)
• Process: Event Collector API (REST, authenticates users via session token)
• Data Flow: Kafka topic raw-events (internal)
• Process: Flink enrichment job (joins events with user profile data)
• Data Store: S3 data lake, partitioned by user_id/date/
• Process: BigQuery analytics layer
• External Entity: BI dashboards (data analysts)

We will walk through each LINDDUN category for two components: the Kafka message queue and the S3 data store.

Linkability: Each event message carries a session_id and a device_fingerprint. A consumer with access to two topics can correlate events across sessions without going through the intended enrichment pipeline. Mitigation: strip or hash correlation IDs at ingestion; use separate topics with distinct access controls for data requiring different linkability constraints.

Identifiability: Raw events include IP address, user_agent, and precise timestamps. Even without user_id, the combination is re-identifiable in 87% of cases at the 15-minute granularity (per the 2013 de Montjoye study baseline). Mitigation: truncate IP to /24 at the collector before publishing; drop user_agent minor version; quantize timestamps to the nearest 5-minute bucket.

Non-repudiation: Kafka's immutable, offset-based log means every event a user generated is permanently attributable to their session_id. If session_id maps to user_id in any downstream join, behavioral history is non-repudiable for the full retention window. Mitigation: implement a right-to-erasure workflow that tombstones events by key using Kafka's log compaction; set explicit retention policies (72h for raw topics, not indefinite).

Detectability: An adversary with network access to the Kafka broker can observe the volume and timing of messages on a per-partition basis, even with TLS. If partitions map to tenants or user segments, partition traffic patterns leak behavioral signals. Mitigation: use random partition assignment instead of key-based; add noise to event publishing cadence for high-sensitivity event types.

Disclosure of information: Default Kafka ACLs are permissive. Any consumer group with READ on the topic gets all fields, including PII fields that most consumers do not need. Mitigation: use field-level encryption (encrypt PII fields with consumer-specific keys before publishing); implement schema-enforced field masking at the consumer group level using Confluent's Data Contracts or equivalent.

Unawareness: Users consented to "product improvement analytics." The Kafka topic includes raw API payloads that contain free-text search queries and document titles, which were not disclosed in the privacy notice. Mitigation: audit all fields published to each topic against the privacy notice; add a data classification tag to each schema field; reject schemas that include undisclosed fields.

Non-compliance: The raw-events topic has no retention policy configured, defaulting to indefinite retention. GDPR Article 5(1)(e) requires storage limitation. Mitigation: set retention.ms to the minimum required for each topic; document retention decisions in the Record of Processing Activities (RoPA).

Linkability: The S3 prefix structure s3://analytics-lake/events/user_id=U123/date=2026-07-09/ makes it trivial to retrieve all events for a specific user across any date range. A single S3 ListObjectsV2 call enumerates the full behavioral history. Mitigation: replace user-partitioned prefixes with random shard keys; use a separate index table in a governed metastore (Glue, Iceberg) that requires explicit join authorization.

Identifiability: Parquet files in the data lake include a city, postal_code, and age_group column added during Flink enrichment. When combined with event timestamps, this reaches re-identification risk thresholds for small demographic groups. Mitigation: apply k-anonymity (k >= 5) at write time by generalizing geographic and demographic quasi-identifiers; consider l-diversity for sensitive event types.

Non-repudiation: S3 Object Lock (WORM) was enabled to satisfy audit requirements, but it also prevents deletion of records containing PII. This directly conflicts with GDPR Article 17 (right to erasure). Mitigation: segregate audit records (which may legitimately use WORM) from analytics records (which must support erasure); implement a crypto-shredding pattern where PII is encrypted with a per-user key stored in AWS KMS, and erasure is accomplished by deleting the KMS key.

Detectability: S3 access logs reveal which analysts queried which user partitions. If access patterns are not governed, an analyst querying records for a specific individual (e.g., a public figure or a colleague) is detectable in the access log but may go unreviewed. Mitigation: implement query-level access controls via Athena workgroups or Databricks Unity Catalog; alert on single-user partition queries by non-automated principals.

Disclosure of information: S3 bucket policies are notoriously misconfigured. Even with block-public-access enabled at the account level, cross-account IAM roles with overly broad s3:GetObject permissions create disclosure risk. Mitigation: use S3 Access Analyzer to enumerate all external access paths; apply resource-based policies that deny access to any principal outside the designated data processing accounts.

Unawareness: The data lake schema has expanded over 18 months to include columns not present in the original privacy notice, added by individual teams without a schema governance process. Users are unaware their data now includes inferred attributes (e.g., predicted_churn_score, inferred_income_bracket). Mitigation: implement schema change governance with mandatory privacy review for new columns; treat inferred attributes as sensitive personal data under GDPR Recital 26.

Non-compliance: Data from EU users is co-mingled with US user data in the same S3 bucket in us-east-1 with no data residency controls. This may violate GDPR Chapter V (transfers to third countries) depending on applicable SCCs and the post-Schrems II transfer mechanism in use. Mitigation: implement data residency tagging at collection; route EU user data to eu-west-1 buckets; document transfer mechanisms in the RoPA.

Full LINDDUN with complete threat trees is thorough but time-intensive. LINDDUN GO is the card-based variant designed for 2-hour threat modeling workshops, analogous to the difference between a full STRIDE analysis and a whiteboard session with OWASP Top 10 cards.

LINDDUN GO provides 56 threat cards across the seven categories. Each card describes a specific threat pattern, gives an example, and lists standard mitigations. Teams walk through their DFD, draw threat cards relevant to each component, and vote on severity and applicability.

When to use LINDDUN GO:

• Early design phase when a full threat model would be premature
• Agile sprint planning when the team needs a quick privacy gut-check
• When introducing privacy engineering to teams that have never done structured threat modeling
• For third-party integration reviews where a full DFD is not available

When to use full LINDDUN:

• DPIA preparation under GDPR Article 35
• New product launches processing sensitive categories of data (Article 9)
• Post-incident root cause analysis involving a privacy breach
• Architecture reviews for systems handling health, financial, or biometric data

The LINDDUN GO cards are freely available at linddun.org and can be used in digital whiteboard tools like Miro or Mural with the provided templates.

Each LINDDUN category has a corresponding set of privacy-enhancing technologies (PETs) and architectural patterns.

Against Linkability:

• Pseudonymization with unlinkable pseudonyms (use separate pseudonyms per context, not a single global ID)
• Cryptographic unlinkability via blind signatures or zero-knowledge proofs for high-sensitivity flows
• Data minimization: collect only the fields required for the stated purpose; do not pass correlation IDs across trust boundaries

Against Identifiability:

• k-anonymity: ensure every record shares quasi-identifier combinations with at least k-1 other records
• l-diversity: within each k-anonymous group, ensure sensitive attribute values are diverse (prevents inference attacks)
• t-closeness: the distribution of sensitive attributes within each group must be close to the overall distribution
• Differential privacy: add calibrated noise to aggregate query results (used by Apple, Google, and the US Census Bureau); tools include Google's DP Library and Apple's Learning with Privacy framework

Against Non-repudiation:

• Crypto-shredding: encrypt records with per-subject keys; erasure is accomplished by destroying the key, not modifying the immutable log
• Separate audit records (legally required, minimal scope) from analytics records (erasure-capable)

Against Detectability:

• Traffic shaping and padding to obscure communication patterns
• Onion routing for high-sensitivity internal service calls (rare in enterprise; more common in healthcare and legal contexts)

Against Disclosure of information:

• Attribute-based access control (ABAC) with data classification labels
• Field-level encryption before storage; consumers receive only the fields their key decrypts

Against Unawareness:

• Privacy notice automation: generate privacy notices from your schema catalog and RoPA, not manually
• Consent management platforms (CMPs) that tie data collection to a specific consent record ID

Against Non-compliance:

• Automated retention enforcement via data lifecycle policies (S3 lifecycle rules, BigQuery table expiration, Kafka retention.ms)
• Continuous compliance scanning with tools like BigID, OneTrust Data Discovery, or open-source alternatives like Presidio

LINDDUN was designed with GDPR alignment in mind. Running a LINDDUN analysis directly satisfies the documentation requirements for two of the most scrutinized GDPR obligations.

GDPR Article 25: Data Protection by Design and by Default

Article 25 requires that controllers implement appropriate technical and organizational measures designed to implement data protection principles effectively. The EDPB's guidelines on Article 25 (Guidelines 4/2019) explicitly list pseudonymization, data minimization, and purpose limitation as target controls.

LINDDUN provides the systematic method for identifying where these controls are needed. A documented LINDDUN analysis demonstrates to supervisory authorities that you identified privacy risks at the design stage and selected controls proportionate to the risk. This is precisely the evidence that survives an Article 25 audit.

Map your LINDDUN findings to Article 25 obligations:

• Linkability findings: purpose limitation (Article 5(1)(b)), data minimization (Article 5(1)(c))
• Identifiability findings: pseudonymization requirement (Article 25(1))
• Unawareness findings: transparency obligation (Article 5(1)(a)), privacy notice requirements (Articles 13-14)
• Non-compliance findings: storage limitation (Article 5(1)(e)), lawful basis documentation (Article 6)

GDPR Article 35: Data Protection Impact Assessment (DPIA)

Article 35 requires a DPIA before processing likely to result in high risk. The EDPB's list of processing operations requiring a DPIA includes systematic profiling, large-scale processing of special categories, and systematic monitoring of publicly accessible areas.

A DPIA requires: a description of processing operations, an assessment of necessity and proportionality, an assessment of risks to data subjects, and the measures to address those risks.

LINDDUN provides the risk assessment component directly. Your LINDDUN threat model becomes the risk assessment section of the DPIA. LINDDUN findings that map to residual risk after mitigation become your documented residual risk, which the DPIA requires you to either accept (with DPO sign-off) or mitigate further.

Practical workflow: run LINDDUN during architecture design, document findings in your DPIA template, get DPO review on residual risks before deployment. This satisfies both the procedural requirement (DPIA was conducted) and the substantive requirement (risks were systematically identified and addressed).

Manual LINDDUN analysis does not scale beyond individual system reviews. These tools help automate and operationalize the process.

LINDDUN Online Tool (linddun.org/linddun-pro) The reference implementation from the KU Leuven research team. Supports DFD creation, threat tree traversal, and generates a structured report. Free for non-commercial use. Best for: individual system analyses, DPIA documentation, learning the methodology.

Threagile An open-source, code-based threat modeling tool that supports both STRIDE and privacy threat categories. Models are defined in YAML; Threagile generates reports, DFDs, and risk findings. Privacy threats in Threagile map to LINDDUN categories. Best for: teams that want threat models as code in CI/CD pipelines; the YAML model lives in the same repository as the system it describes.

Example Threagile data asset definition with privacy properties:

data_assets:
  user_events:
    id: user-events
    description: Raw telemetry events from client SDK
    usage: devops
    tags: [pii, behavioral]
    origin: Customer
    owner: Analytics Engineering
    quantity: many
    confidentiality: confidential
    integrity: operational
    availability: operational
    justification_cia_rating: >
      Contains IP, device fingerprint, and session token.
      Linkable to individual users via session join.

Microsoft Threat Modeling Tool Primarily STRIDE-focused, but extensible with custom stencils. The LINDDUN community has published custom stencils that add LINDDUN threat categories to the standard DFD element types. Best for: organizations already standardized on the Microsoft tool that want to add privacy threat elicitation without switching platforms.

OWASP Threat Dragon Open-source, web-based threat modeling tool with a clean DFD editor. Supports custom threat libraries; the LINDDUN threat library can be imported as a JSON configuration. Best for: teams that prefer open-source tooling and want browser-based collaboration without installing a desktop application.

Presidio (Microsoft) An open-source PII detection and anonymization framework. Useful for scanning existing data stores and pipelines to identify undisclosed PII before running LINDDUN, so your threat model reflects the actual data flowing through the system rather than the intended data.

These are the LINDDUN findings that appear most frequently in production architecture reviews, organized by system type.

Authentication and Authorization Services:

• Non-repudiation: auth logs create behavioral profiles (login times, devices, locations) that exceed their stated security purpose
• Linkability: OAuth tokens reused across multiple relying parties allow cross-service identity correlation without user awareness
• Identifiability: failed login attempt logs that include the attempted username reveal whether an email address has an account (account enumeration as an identifiability threat, not just a security one)
• Mitigation pattern: separate security logs (short retention, access-restricted, not queryable by analytics) from auth audit logs; use pairwise pseudonymous identifiers for federated identity (OIDC PPID)

Product Analytics Pipelines:

• Unawareness: session replay tools that capture keystroke-level data, including accidental PII entry in form fields not intended for collection
• Linkability: UTM parameters and click IDs that persist across sessions and allow ad networks to link anonymous browsing to real identities
• Non-compliance: A/B test data retained indefinitely because the experiment infrastructure has no data lifecycle controls
• Mitigation pattern: implement data scrubbing at the collector (strip sensitive form fields before recording); enforce experiment data retention equal to the minimum needed for statistical significance

Third-Party Integrations (SaaS, SDKs, APIs):

• Disclosure of information: sending full user objects to third-party services (Intercom, Salesforce, HubSpot) when only a subset of fields is needed for the integration's purpose
• Non-compliance: third-party data transfers without a current DPA or SCCs for non-adequate-country transfers
• Unawareness: third-party scripts injected via tag managers that collect data not disclosed in the first-party privacy notice
• Mitigation pattern: apply data minimization at the integration boundary; maintain a data transfer registry; audit tag manager configurations quarterly against your privacy notice

Health and Biometric Data Processing (Article 9 Special Categories):

• Identifiability: health event data that is k-anonymous at the aggregate level but re-identifiable when joined with scheduling or billing data in adjacent systems
• Non-repudiation: wearable device data streams that create a continuous, attributable record of physical state
• Mitigation pattern: require explicit consent with granular purpose specification; implement separate data stores with stricter access controls for Article 9 data; apply differential privacy for any aggregate reporting

Running LINDDUN once is a compliance exercise. Running it systematically is a privacy engineering practice.

Integration into the SDLC:

Threat modeling gates work best when they are proportionate. A lightweight LINDDUN GO session should be a required artifact for any new data flow that processes personal data, created during the design phase before the first line of code is written. Full LINDDUN analysis should be required for systems that trigger DPIA criteria under Article 35.

Definition of Ready for new data flows:

• Data flow diagram drafted
• All data fields documented with classification (PII, sensitive, aggregate)
• LINDDUN GO session completed, findings documented
• Privacy review sign-off from DPO or privacy champion

Maintaining the Threat Model: LINDDUN models go stale. A threat model created at launch does not reflect a system that has had 40 schema changes across 18 months of development. Tie LINDDUN review triggers to schema changes and infrastructure changes, not just new system launches. Tooling like Threagile helps here because the threat model lives in the repository and is reviewed in the same pull request as the code change.

Metrics to track:

• LINDDUN findings per system per quarter
• Mean time to mitigate (MTTM) by LINDDUN category
• Percentage of data flows with a current LINDDUN assessment
• DPIA coverage rate for Article 35-qualifying processing operations

Privacy threat modeling is not a checkbox. Regulators have made clear that documented, systematic risk assessment before processing is the difference between a corrective order and a material fine. LINDDUN gives security and privacy engineers a shared language and a repeatable process for getting there.