DPDPA Threat Modeling with LINDDUN and STRIDE: A DPIA-Ready Methodology

Key Takeaways

• DPDPA Section 8(5) demands "reasonable security safeguards" — a standard satisfied by evidence of structured threat analysis, not just an ISO 27001 certificate.
• LINDDUN is a privacy-specific threat model covering Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, and Non-compliance; STRIDE is security-focused. Both are needed for complete DPDPA coverage.
• STRIDE alone is insufficient for DPDPA: it misses the entire dimension of how processing itself can harm the Data Principal — linkability, unawareness, and non-compliance threats are invisible to STRIDE.
• DPIA under Section 10(2)(c)(i) is mandatory only for Significant Data Fiduciaries designated under Section 10(1) — not all Data Fiduciaries. Every other Data Fiduciary still benefits from DPDPA threat modeling for Section 8(5) compliance.
• LINDDUN's 7 threat categories map directly to DPDPA obligations: Linkability → S.6(1); Identifiability → S.2(t), S.8(7); Non-repudiation → S.6(10)/S.8(7) tension; Detectability → S.8(5); Disclosure → S.2(u), Rule 6(1)(a); Unawareness → S.5(1), S.5(3); Non-compliance → all DPDPA sections.
• Integrating the threat model into CI/CD (design-gate, build-gate, pre-release DPIA sync) converts a compliance PDF into a living engineering control.
• Every LINDDUN or STRIDE finding must resolve into a testable code-level mitigation with a DPDPA section tag — otherwise it is a wish, not a control.

Key terms: Data Fiduciary — entity determining the purpose and means of processing personal data (DPDPA S.2(i)). Significant Data Fiduciary (SDF) — a Data Fiduciary designated under Section 10(1) for high-risk processing; subject to periodic DPIA under S.10(2)(c)(i), Data Protection Officer appointment, an independent data auditor, and (under Rule 13) an annual DPIA and audit. LINDDUN — a privacy threat modelling methodology covering Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of Information, Unawareness, and Non-compliance (KU Leuven). STRIDE — a security threat model covering Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege (Microsoft). DPIA — Data Protection Impact Assessment; a structured process under DPDPA Section 10(2)(c)(i) describing rights of Data Principals, the purpose of processing, and assessment and management of risk to those rights. Data Principal — the individual to whom the personal data relates (S.2(j)). TOMs — Technical and Organisational Measures; the implementation layer for Rule 6 safeguards.

Table of Contents

• Why Is Threat Modeling Critical for DPDPA Compliance?
• The Legal Requirement: What the DPDPA Actually Says About Risk Assessment
• The Engineering Translation: LINDDUN, STRIDE, and How They Map to the DPDPA
• Practical: DPDPA-Annotated Data Flow Diagrams
• Code-Level Mitigations: Threats Become Tests
• Integrating Threat Modeling into CI/CD
• Section 8(5) "Reasonable" Is Evidential, Not Declarative
• Common Pitfalls
• Key Takeaways
• FAQ
• Downloadable Resources
• Next Steps

Why Is Threat Modeling Critical for DPDPA Compliance?

If you treat the Digital Personal Data Protection Act, 2023 (DPDPA) as a legal checklist, you will build a compliance binder. If you treat it as an engineering problem, you will build a system that actually protects Data Principals. The difference is whether your team does DPDPA threat modeling.

Most Indian enterprises arrive with an ISO 27001 certificate and a vague notion that "privacy is covered." Then Rule 6 of the DPDP Rules 2025 lands on the CISO's desk, the Board asks for a DPIA methodology, and it becomes clear that the existing STRIDE exercise has no answer for linkability, identifiability, or unawareness. Those are privacy threats, and STRIDE was never designed to catch them.

This is the gap LINDDUN closes. Developed at KU Leuven as the privacy counterpart to STRIDE, it gives you a systematic way to enumerate privacy threats against a data flow diagram. Combined with STRIDE and mapped to specific DPDPA obligations, it produces something the Data Protection Board will recognise as a defensible Data Protection Impact Assessment — and something your engineers can act on inside a sprint.

The Legal Requirement: What the DPDPA Actually Says About Risk Assessment

Two obligations in the DPDPA directly create the engineering need for threat modeling.

Section 8(5) — Reasonable Security Safeguards

"A Data Fiduciary shall protect personal data in its possession or under its control, including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards to prevent personal data breach."



— Digital Personal Data Protection Act, 2023, Section 8(5)

Section 8(5) is the hook. It is deliberately outcome-based: the Act does not tell you how to protect personal data, it tells you that you must. The DPDP Rules 2025, Rule 6(1), then specify the minimum floor — encryption, access control, logging and monitoring, backups, one-year log retention, Data Processor contracts, and technical and organisational measures — but "reasonable" is a standard that requires you to demonstrate proportionate thinking. A threat model is the clearest possible artefact of that thinking.

Section 10(2)(c)(i) — DPIA for Significant Data Fiduciaries

For Significant Data Fiduciaries (SDFs), the obligation becomes explicit.

"The Significant Data Fiduciary shall— … (c) undertake the following other measures, namely:— (i) periodic Data Protection Impact Assessment, which shall be a process comprising a description of the rights of Data Principals and the purpose of processing of their personal data, assessment and management of the risk to the rights of the Data Principals, and such other matters regarding such process as may be prescribed;"



— Digital Personal Data Protection Act, 2023, Section 10(2)(c)(i)

The Act uses the phrase "assessment and management of the risk to the rights of the Data Principals." That is not a vulnerability scan. It is not a penetration test. It is a structured analysis of how your system could harm the people whose data you process — which is exactly what LINDDUN was designed to produce.

Other sections that show up inside a threat model

A complete DPDPA threat model will also touch Sections 5(1) and 5(3) (notice and language — LINDDUN Unawareness), 6(1) (consent and purpose limitation — STRIDE Elevation, LINDDUN Linkability), 6(10) (burden of proof — STRIDE Repudiation and Tampering), 8(1)–(2) (accountability for Processors), 8(6) (breach notification), 8(7) (erasure — LINDDUN Non-repudiation), 11 and 12 (access, correction, erasure — STRIDE Spoofing), 16 (cross-border transfer), Rule 6(1)(a)–(g) (the mitigation floor), and Rule 7 (breach intimation — to each affected Data Principal and the Board "without delay", then a detailed report to the Board within 72 hours under Rule 7(2)(b)).

Significant Data Fiduciaries add Rule 13(1)–(2) (an annual DPIA and audit, with a report of significant observations to the Board) and Rule 13(3) (due diligence on algorithmic software). Every finding in your model must cite at least one of these when the Board asks "under what clause is this control mandatory?"

The Engineering Translation: LINDDUN, STRIDE, and How They Map to the DPDPA

LINDDUN has seven threat categories. STRIDE has six. Neither, in isolation, is sufficient for a DPDPA DPIA. STRIDE misses the entire dimension of how processing itself can harm the data subject; LINDDUN underweights classic security threats like DoS on consent infrastructure. Together they form a complete lattice.

LINDDUN categories mapped to DPDPA obligations

LINDDUN's Non-repudiation threat is the category most likely to be misunderstood by engineers familiar with STRIDE. In STRIDE, repudiation (denying an action) is the bad outcome. In LINDDUN, non-repudiation is the bad outcome — because forcing a Data Principal to live with an indelible audit trail of every consent interaction is itself a privacy harm. Section 6(10) creates a burden-of-proof requirement that pulls toward non-repudiation; Section 8(7) creates an erasure right that pulls the opposite way. A mature threat model surfaces this tension and resolves it with scoped retention, purpose-bound access, and the ability to erase activity logs when the underlying purpose is complete.

STRIDE categories mapped to DPDPA obligations

Read the two tables together and you can see the core insight: every DPDPA obligation is already a threat category in one of these two frameworks. Threat modeling is not an additional workstream; it is the existing workstream that you reframe to cover privacy.

Practical: DPDPA-Annotated Data Flow Diagrams

A DFD is the lingua franca of threat modeling. For DPDPA work, you annotate it with four extra pieces of information that a security-only DFD omits: the DPDPA actor type, the lawful basis, the purpose tag, and the retention clock.

Here is a minimal consent-and-processing flow for a hypothetical Indian fintech, expressed as a Mermaid sequence diagram.

sequenceDiagram
    participant DP as Data Principal<br/>(S.2(j))
    participant W as Web App<br/>[Purpose: loan_origination]
    participant CM as Consent Service<br/>(S.6(10) ledger)
    participant KYC as KYC Processor<br/>(S.8(1) DPA-bound)
    participant DB as Customer DB<br/>[Rule 6(1)(a) encrypted]
    participant DPB as Data Protection Board

    DP->>W: Submit loan application (PII)
    W->>CM: Record consent [purpose=loan_origination, lang=ta]
    CM-->>W: consent_id (signed, timestamped)
    W->>KYC: Forward KYC docs (TLS 1.3, mTLS)
    KYC-->>W: KYC verdict
    W->>DB: Store application (field-level encrypted)
    Note over DB: Retention clock: erase when purpose served (S.8(7)), logs kept min 1y (Rule 8(3))
    DP->>W: Section 12 erasure request
    W->>CM: Revoke consent + cascade delete
    CM->>DB: Cryptographic erasure (key destruction)
    W-->>DP: Confirmation (Rule 6(1)(c) logged)
    Note over W,DPB: On breach: Rule 7 — DPs and Board without delay<br/>detailed Board report within 72h (Rule 7(2)(b))

Alt Text: DPDPA threat modeling sequence diagram showing a Data Principal submitting a loan application through a web app, with consent recording, KYC processing, encrypted storage, and erasure cascade, annotated with DPDPA section references.

With that DFD in place, you run LINDDUN and STRIDE per element. A shortened output looks like this:

Every row on that table becomes a ticket in your backlog, a control in your ISMS, and a line item in your DPIA.

Code-Level Mitigations: Threats Become Tests

The artefact that makes this methodology credible to engineering teams is that every threat has a failing test until it is mitigated. Here are three production-grade patterns we deploy at StateCheck.

1. Defeating Detectability on authentication endpoints

Most Indian fintech and healthtech signup APIs leak membership through status codes. The fix is constant-time, constant-shape responses.

# consent_api/auth.py
import hmac
import secrets
from fastapi import APIRouter, Response, status
from pydantic import BaseModel, EmailStr

router = APIRouter()

class SignupRequest(BaseModel):
    email: EmailStr
    phone: str

@router.post("/signup", status_code=status.HTTP_202_ACCEPTED)
def signup(req: SignupRequest, response: Response) -> dict:
    """
    LINDDUN: Detectability mitigation.
    DPDPA: S.8(5) reasonable safeguards.

    Always returns 202 Accepted with an opaque correlation ID.
    The actual account creation and notification happens asynchronously,
    so timing and status code cannot reveal whether the email/phone
    was already registered.
    """
    correlation_id = secrets.token_urlsafe(16)

    # Enqueue work; do not branch on "already exists" in the response path.
    enqueue_signup_task(
        correlation_id=correlation_id,
        email_hmac=_hmac(req.email),
        phone_hmac=_hmac(req.phone),
    )

    # Constant-time dummy work to neutralise timing oracles
    _ = hmac.compare_digest(correlation_id, correlation_id)

    return {"correlation_id": correlation_id, "status": "processing"}


def _hmac(value: str) -> str:
    key = load_secret("SIGNUP_HMAC_KEY")  # from AWS KMS / HashiCorp Vault
    return hmac.new(key.encode(), value.encode(), "sha256").hexdigest()

2. Purpose-scoped access control defeating Elevation of Privilege

DPDPA Section 6(1) requires that processing stay within the consented purpose. That means access control must be purpose-aware, not just role-aware. Here is an Open Policy Agent (OPA) Rego policy we drop into API gateways.

# policy/dpdpa_purpose_scope.rego
package dpdpa.access

# STRIDE: Elevation of Privilege
# LINDDUN: Linkability, Non-compliance
# DPDPA: Section 6(1), Section 8(1)-(2), Rule 6(1)(b)

default allow := false

allow if {
    # The caller has an active consent event for this exact purpose
    some consent in input.consent_events
    consent.data_principal_id == input.resource.data_principal_id
    consent.purpose == input.request.purpose
    consent.status == "active"
    time.now_ns() < consent.expires_at_ns

    # The caller's service identity is contractually bound
    input.caller.service_id in data.dpa_authorised_services[input.request.purpose]

    # The requested fields are within the purpose's minimum-necessary set
    requested := {f | f := input.request.fields[_]}
    allowed := {f | f := data.purpose_field_scope[input.request.purpose][_]}
    count(requested - allowed) == 0
}

violation[msg] if {
    not allow
    msg := sprintf(
        "dpdpa: access denied. caller=%s purpose=%s principal=%s. "
        "Refer DPDPA S.6(1) purpose limitation and S.8(1) accountability.",
        [input.caller.service_id, input.request.purpose, input.resource.data_principal_id],
    )
}

3. Cryptographic erasure defeating Non-repudiation tension

Section 8(7) says data must be erased when the purpose is complete; Section 6(10) says the Fiduciary must be able to prove consent existed. Cryptographic erasure reconciles both: keep the consent event record, but destroy the per-principal data encryption key so the underlying personal data is mathematically irrecoverable.

# erasure/crypto_shred.py
import boto3
from dataclasses import dataclass
from datetime import datetime, timezone

kms = boto3.client("kms")
ddb = boto3.resource("dynamodb").Table("consent_events")


@dataclass
class ErasureResult:
    data_principal_id: str
    deleted_key_arn: str
    erasure_timestamp_utc: str
    consent_record_retained: bool


def erase_data_principal(data_principal_id: str, reason: str) -> ErasureResult:
    """
    Reconciles DPDPA Section 8(7) erasure obligation with
    Section 6(10) consent proof obligation.

    Strategy: per-principal DEK in KMS, destroyed on erasure request.
    The ciphertext in object storage becomes unrecoverable, but the
    consent ledger entry (which contains no plaintext PII) is retained
    for at least the one-year minimum under Rules 6(1)(e) and 8(3).
    """
    dek_arn = _lookup_dek_arn(data_principal_id)

    # Schedule deletion with 7-day window (KMS minimum) — logged for
    # Rule 6(1)(c) detection of unauthorised access requirements.
    kms.schedule_key_deletion(KeyId=dek_arn, PendingWindowInDays=7)

    # Retain the ledger entry but strip any residual quasi-identifiers.
    ddb.update_item(
        Key={"data_principal_id": _pseudonym(data_principal_id)},
        UpdateExpression="SET erasure_reason = :r, erased_at = :t REMOVE email, phone",
        ExpressionAttributeValues={
            ":r": reason,
            ":t": datetime.now(timezone.utc).isoformat(),
        },
    )

    return ErasureResult(
        data_principal_id=_pseudonym(data_principal_id),
        deleted_key_arn=dek_arn,
        erasure_timestamp_utc=datetime.now(timezone.utc).isoformat(),
        consent_record_retained=True,
    )

These three patterns are not illustrative pseudo-code. They are the shape of what we deploy. The point is that every LINDDUN or STRIDE finding must resolve into a change like one of the above — otherwise it is not a mitigation, it is a wish.

Integrating Threat Modeling into CI/CD

A DPIA that lives in a SharePoint folder is a compliance artefact. A DPIA that lives in your pipeline is an engineering control. We integrate LINDDUN/STRIDE into CI/CD in three places, which complements the privacy-by-design pipeline architecture we describe in our DPDPA privacy-by-design CI/CD guide.

1. Design-phase gate. Any pull request that adds a new personal data field, a new external entity, or a new purpose must include a threat-model.yaml update. A CI job parses the YAML, confirms every new element has at least one LINDDUN and one STRIDE entry, and fails the build if a finding is missing a mitigation or a DPDPA section tag.
2. Build-phase gate. OPA policies like the one above are evaluated against Infrastructure-as-Code plans and Kubernetes manifests. This is where "Rule 6(1)(a) encryption at rest" stops being a PDF and starts being a terraform plan exit code.
3. Pre-release DPIA sync. Before any release that changes a DFD element, a scheduled job regenerates the DPIA document from the threat-model.yaml files across the repo. The output is a versioned, git-tracked DPIA that the DPO can sign off on without re-interviewing the engineering team.

If you are moving toward a Zero Trust posture, the same threat model outputs feed directly into segmentation decisions — see our Zero Trust Architecture for DPDPA Compliance guide for how policy-as-code for privacy ties into network and identity controls.

Section 8(5) "Reasonable" Is Evidential, Not Declarative

We see the same pattern repeatedly: a CISO tells the Board they comply with Section 8(5) "because we have ISO 27001." On audit, the ISO scope does not cover the customer data plane, the risk assessment is 14 months old, and no artefact analyses risk to the Data Principal as opposed to the organisation. That is not reasonable within the meaning of Section 8(5) — it is an adjacent framework being asked to do work it was not designed for.

A LINDDUN + STRIDE threat model is directly responsive to the Section 8(5) standard because it enumerates threats in a structured taxonomy, it is specific to the system being deployed, it is refreshed on every material change, and it produces evidence of engineering thought — which is what "reasonable" requires. When the Data Protection Board considers penalties under Section 33(2), it must have regard to "the nature, gravity and duration of the breach" and "whether the person took any action to mitigate the effects and consequences of the breach, and the timeliness and effectiveness of such action." A current threat model is the clearest possible evidence that you were thinking about the right risks before the incident.

Common Pitfalls

Running LINDDUN once and calling it a DPIA. Section 10(2)(c)(i) describes a DPIA as a "process," not an artefact. Refresh with every material change — new purpose, new processor, new data category, new Section 16 transfer.

Skipping the external entity. STRIDE-trained teams draw the Data Principal as a simple actor. LINDDUN forces you to ask: can the Data Principal be identified by their interaction with the system? Account enumeration and timing oracles are identifiability threats.

Treating consent as authentication. Consent under Section 6(1) is a lawful basis, not an identity assertion. Section 11 and 12 requests still need independent Spoofing controls.

Ignoring the Non-repudiation / erasure tension. If your consent ledger cannot be reconciled with erasure rights, you have a compliance bug. Cryptographic erasure is the cleanest answer.

Forgetting Rule 6(1)(f) for Data Processors. Every trust boundary into a Processor must carry a mitigation that traces back to the contractual Rule 6(1)(f) provision.

Key Takeaways

• DPDPA Section 8(5) demands "reasonable security safeguards," which is an evidential standard best satisfied by a living threat model.
• Section 10(2)(c)(i) makes DPIAs mandatory for Significant Data Fiduciaries, and a DPIA is structurally identical to a LINDDUN exercise scoped to DPDPA obligations.
• LINDDUN covers the privacy dimensions (linkability, identifiability, unawareness, non-compliance) that STRIDE was never designed to handle.
• STRIDE covers the security dimensions (spoofing, tampering, repudiation, disclosure, DoS, elevation) that still dominate Section 2(u) breach definitions.
• Every threat model finding must carry a DPDPA section or rule tag, a DFD element, and a code-level mitigation that can be tested in CI.
• Integrate threat modeling into design, build, and pre-release gates so the DPIA is a git artefact, not a SharePoint PDF.

FAQ

Is a DPIA required under DPDPA for all organisations?

No. The DPIA obligation under Section 10(2)(c)(i) applies only to organisations designated as Significant Data Fiduciaries (SDFs) by the Central Government under Section 10(1). The designation is based on factors including the volume and sensitivity of personal data processed, risk to the rights of Data Principals, potential impact on sovereignty, security, and public order. Organisations not yet designated as SDFs are still subject to Section 8(5) reasonable safeguards — for which a LINDDUN + STRIDE threat model provides the strongest available evidence — but the DPIA obligation as explicitly described in the Act is SDF-specific.

What is LINDDUN and how does it differ from STRIDE?

LINDDUN is a privacy threat modelling methodology developed at KU Leuven that focuses on threats to the Data Principal: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of Information, Unawareness, and Non-compliance. STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a security threat model developed by Microsoft that focuses on threats to the system and organisation. The critical distinction for DPDPA work: STRIDE asks "what can an attacker do to the system?" while LINDDUN asks "how can the system itself harm the person whose data it processes?" DPDPA compliance requires both perspectives — Section 2(u) breach definitions are largely STRIDE territory, while the rights-of-Data-Principals framing in Section 10(2)(c)(i) is LINDDUN territory.

Which DPDPA sections does LINDDUN most directly address?

Each LINDDUN category maps to specific DPDPA obligations: Linkability → Section 6(1) purpose limitation and consent, and Section 9(3) (no tracking or behavioural monitoring of children) where users are under 18; Identifiability → Section 2(t) definition of personal data, Section 8(7) erasure; Non-repudiation → the tension between Section 6(10) burden of proof and Section 8(7) erasure rights; Detectability → Section 8(5) reasonable safeguards; Disclosure of Information → Section 2(u) breach definition, Section 8(5), Section 8(6) breach notification, Rule 6(1)(a) encryption; Unawareness → Section 5(1) and 5(3) notice requirements, Rule 3 notice content, Section 11 right to access information; Non-compliance → all DPDPA sections and rules, including the Rule 7 breach intimation obligation ("without delay" to Data Principals and the Board, then a detailed Board report within 72 hours).

How does a DPDPA DPIA differ from a GDPR Article 35 DPIA?

The structures are similar but the DPDPA version is narrower in scope and lighter in procedural prescription. GDPR Article 35 mandates DPIAs for any high-risk processing, includes a mandatory prior consultation with the supervisory authority when residual risk remains high, and prescribes involvement of the Data Protection Officer. DPDPA Section 10(2)(c)(i) limits the DPIA obligation to designated Significant Data Fiduciaries, does not include a prior consultation mechanism in the current text, and prescribes elements (description of rights, purpose, risk assessment and management) without specifying the methodology. The "such other matters regarding such process as may be prescribed" language lets the Rules add requirements; notified Rule 13(1)–(2) already does, requiring an SDF to carry out a DPIA and audit every twelve months and furnish the Board a report of significant observations. Practically, a LINDDUN + STRIDE methodology satisfies both — but a DPDPA DPIA need not be as extensive as a GDPR Article 35 DPIA for organisations that are not SDFs.

What makes an organisation a Significant Data Fiduciary under DPDPA?

The Central Government notifies SDFs under Section 10(1), on the basis of an assessment of such relevant factors as it may determine, including: the volume and sensitivity of personal data processed; risk to the rights of Data Principal; potential impact on the sovereignty and integrity of India; risk to electoral democracy; security of the State; and public order. There is no self-assessment threshold — designation is a governmental act, not a compliance determination. Organisations that process large volumes of sensitive data (financial, health, biometric) across millions of Indian users are most likely candidates, but no official list has been published as of October 2026. Any organisation that may plausibly be designated should implement DPIA processes preemptively, since the obligation activates on designation — not on a future compliance deadline (Section 10 and Rule 13 themselves apply from 13 May 2027).

Does DPDPA have a 72-hour breach notification deadline?

Yes, for the detailed report to the Board. The Act itself (Section 8(6)) sets no hour count, but notified Rule 7 of the DPDP Rules 2025 sets two clocks. First, on becoming aware of a breach, the Data Fiduciary must intimate each affected Data Principal (Rule 7(1)) and the Board (Rule 7(2)(a)) "without delay". Second, Rule 7(2)(b) requires updated and detailed information to the Board "within seventy-two hours of becoming aware of the breach, or within such longer period as the Board may allow on a request made in writing in this behalf". Note the wording: the Rules say "without delay"; the extra word "undue" belongs to GDPR Article 33. Threat models and DPIA documentation should cite Rule 7(1), 7(2)(a) and 7(2)(b), and the breach pipeline should be tested against the 72-hour clock. Rule 7 applies from 13 May 2027.

Is STRIDE alone sufficient for DPDPA Section 8(5) compliance?

STRIDE provides strong coverage for the security-threat dimension of Section 8(5) — preventing personal data breaches caused by attacker actions (spoofing, tampering, information disclosure, denial of service, elevation of privilege). However, Section 8(5) uses the phrase "reasonable security safeguards" in the context of protecting Data Principals' rights, not just organisational assets. Privacy threats like unlawful linkability across purposes (LINDDUN-L), unawareness of processing (LINDDUN-U), and data retention beyond purpose completion (LINDDUN-N) are not visible to STRIDE. The Data Protection Board, in assessing whether safeguards were "reasonable," is entitled to consider whether the organisation analysed privacy risks to Data Principals — not just security risks to the organisation. STRIDE alone does not produce that evidence.

Threat Model Template

DPIA Template

OPA Policy Bundle

DFD Annotation Guide

CI/CD Gate

Quick Reference Card

Implementation Checklist

Next Steps

DPDPA threat modeling is the single artefact that simultaneously satisfies the "reasonable safeguards" standard under Section 8(5), the DPIA obligation under Section 10(2)(c)(i) for Significant Data Fiduciaries, the burden-of-proof standard under Section 6(10), and the breach-notification readiness required by Section 8(6) and Rule 7.

Book a free DPDPA threat modeling assessment — a StateCheck privacy engineer will walk through one of your production data flows, produce a sample LINDDUN + STRIDE analysis, and deliver a gap report tagged to specific DPDPA sections and DPDP Rules.

Related reading:

• Privacy by Design in CI/CD for DPDPA Compliance — how to turn the threat model into automated pipeline gates
• Zero Trust Architecture for DPDPA Compliance — how purpose-scoped access control extends to network and identity planes
• DPDPA to ISO 27001 Mapping — where Annex A controls pick up where the threat model leaves off
• DPDPA Encryption Requirements — Rule 6(1)(a) implementation patterns that mitigate Disclosure and Tampering threats