That gap — between documented compliance and engineered privacy — is where privacy incidents actually happen. A checklist tells you a control exists. It doesn't tell you whether your system design creates a way around it. This is the problem privacy threat modeling is built to solve, and it's worth understanding even if you never touch a modeling tool yourself.

7
LINDDUN privacy threat categories
4
gaps found in one composite lending flow
0
of those 4 caught by a standard compliance checklist
Nov 2025
DPDP Rules formally notified by MeitY

Threat Modeling Isn't New. Applying It to Privacy Is What's Changed.

Security teams have used structured threat modeling for two decades — STRIDE being the best-known example — to systematically ask "what could go wrong with this system?" before it ships, rather than after an incident forces the question. LINDDUN does the same thing for privacy specifically. Developed by researchers at KU Leuven and now a widely referenced methodology in privacy engineering circles, it gives teams seven lenses to examine a system through, each named for a category of privacy harm.

LINDDUN — SEVEN LENSES FOR PRIVACY HARM
Linkability Combine data or systems to build a fuller picture than any one holds Identifiability Single a person out from data meant to be anon- ymous or pseudonymous Non-repudiation Tie someone permanently to an action they should have been able to deny Detectability Infer a person is in a dataset at all, without seeing the data itself Disclosure Data exposed to parties, purposes, or durations beyond what was consented Unawareness The person doesn't really understand what's done with their data Non-compliance System behaviour doesn't match what the law and the org's own policy say it should
None of this is proprietary — it's published methodology, freely documented at linddun.org.
What separates organisations that benefit It isn't access to the framework — it's whether they apply it before a system is built, consistently, across every process that touches personal data, and turn the findings into something an auditor or regulator can actually see evidence of.

A Composite Example: Onboarding a Borrower

The following is an illustrative scenario built from patterns common across digital lending platforms — not a specific client engagement — but it shows how the LINDDUN lens changes what a privacy review actually finds.

A fintech NBFC is onboarding a new personal-loan applicant. The flow looks unremarkable: PAN and masked Aadhaar for KYC, a selfie for liveness verification, bank statements for income assessment, and a device fingerprint to support fraud scoring. The data then flows to a credit bureau for a report and to a third-party underwriting vendor for a risk score. Read against a standard compliance checklist, this flow passes: consent is captured, a privacy notice is shown, a DPA is signed with each vendor. Read through LINDDUN, four things surface that a checklist alone would miss.

LINDDUN lens What surfaced Why the checklist missed it Fix
Linkability Fraud-scoring fingerprint and bureau report both land in the same analytics warehouse, re-identifying "pseudonymised" training data Consent and the DPA covered each processing purpose individually — not what happens when the outputs are joined downstream Separate data at the pipeline level; apply purpose-based access controls that persist downstream
Disclosure Underwriting vendor receives the full KYC packet — PAN, address, bank statements — when the risk model only needs derived income bands The DPA said the vendor "may receive KYC data for underwriting"; it never asked how much the model actually needs Push minimisation upstream so the vendor never receives what it doesn't need in the first place
Unawareness Liveness selfie is retained for model retraining long after the loan decision is made Consent language named the KYC purpose, never the retraining purpose Extend the consent record honestly, or set a retention job that expires the image at decision time
Non-compliance Bureau data transits a cloud region the org's own data-processing register doesn't list as approved Infrastructure decisions and privacy documentation were made by different teams on different timelines Make the processing register a living check against actual data flows, not a document filed once and forgotten
WHERE THE FOUR FINDINGS SIT IN THE ACTUAL FLOW
Applicant NBFC onboarding PAN · Aadhaar · selfie bank stmt · fingerprint Credit bureau N — unapproved region Underwriting vendor D — gets full KYC packet Analytics warehouse L — re-identifies training data U — selfie retained past decision
L = Linkability · D = Disclosure · U = Unawareness · N = Non-compliance — matching the table above.

Individually, none of these are dramatic. Together, they're exactly the kind of finding that turns into a Data Protection Board inquiry, a breach notification obligation, or a customer trust problem — and none of them would show up on a control checklist, because the controls, on paper, all exist. What's missing is a structured pass that asks how does this actually behave, not what have we documented.

"Checklists tell you a control exists. They don't tell you whether your system design creates a way around it."

— ON CHECKLIST COMPLIANCE VS. ENGINEERED PRIVACY

Why This Is a 2026 Problem, Not a Someday Problem

The DPDP Rules, 2025 were notified by MeitY on 14 November 2025, and they move India's data protection regime from principle to phased, dated obligation — from breach notification timelines to significant data fiduciary requirements rolling out over the following period. Organisations that treat compliance as a documentation exercise will find the gap between their paperwork and their actual system behaviour increasingly hard to explain when a regulator, or a breach, asks the question directly.

What this means in practice Privacy-by-design isn't a slogan in that environment — it's the difference between a DPIA that takes weeks of manual back-and-forth and one built on evidence a team has already produced as part of how they design systems.

Where This Fits for a Compliance or Engineering Team

Privacy threat modeling isn't a tool you buy — it's a discipline, and it holds together across three habits:

  • 01
    Apply the seven lenses before a system ships
    Every processing activity gets a LINDDUN pass before it goes live, not after an incident forces the question.
  • 02
    Keep findings as living evidence
    A threat-modeling pass that sits in a slide deck once a year isn't evidence — a register that's checked against actual data flows is.
  • 03
    Make minimisation part of design, not review
    Purpose limitation and data minimisation belong in the architecture, not in a clause that gets reviewed once a year.
Practical note That's also, not coincidentally, the discipline DPDP assurance work increasingly demands: a Register of Processing Activities that's actually connected to threat findings, not sitting in a separate spreadsheet from them.

The Practical Takeaway

At CreativeCyber, that connection — ROPA to threat model to audit-ready evidence — is what our DPDP Assurance platform is built to operationalise for BFSI and fintech teams. If your privacy program is still checklist-first, a walkthrough of what threat-model-first looks like in practice is worth the half hour.

Sources: Digital Personal Data Protection Rules, 2025 notification, PIB · LINDDUN framework · Digital Personal Data Protection Rules, 2025 — Wikipedia