Section 10(2)(c) of the DPDP Act requires Significant Data Fiduciaries to undertake Data Protection Impact Assessments, and Rule 13(1) of the DPDP Rules 2025 makes the DPIA an annual obligation alongside the independent audit. For non-SDF Data Fiduciaries, the DPIA obligation is triggered by the nature and risk of the processing — not by designation. A DPIA is not a one-time form. It documents the activity, justifies its lawful basis under Section 4, tests its necessity and proportionality, rates the risks to data principal rights, maps mitigations one-to-one, accepts residual risk with a named owner, and locks for audit. For a mid-tier Indian bank, the master list of high-risk processing activities typically runs to 40–80 items — KYC, lending, fraud monitoring, marketing, partner data sharing, AI-driven decisioning, regulatory reporting — and each one needs its own DPIA on an annual cycle. The checklist below covers the trigger test, the DPIA's minimum mandatory content, the stakeholder loop, and the lock-and-track that makes the DPIA defensible under audit.
Trigger Test
Processing involves sensitive personal data categories (financial, health, biometric, location, communications metadata, official identifiers)
Processing operates at scale (large numbers of data principals or high frequency per principal)
Processing involves children's personal data — Rule 10 applies; DPIA mandatory
Processing involves cross-border transfer to a jurisdiction within Rule 15 scope
Processing involves automated decisioning with significant individual impact — algorithmic-fairness assessment required under Rule 13(3); DPIA must integrate it
Processing involves profiling, behavioural inference, or aggregated insights about identifiable individuals
The entity is designated as a Significant Data Fiduciary — Rule 13(1) makes DPIA mandatory annually regardless of activity-level trigger
Existing DPIA for this activity is older than 12 months — re-DPIA required to satisfy Rule 13(1) for SDFs, and good practice for non-SDFs
Activity Description and Lawful Basis under Section 4
Activity name, business owner, and process boundary documented; what is in scope and what is out
Categories of personal data processed listed in itemised form (not “customer information”)
Categories of data principals affected listed (customers, employees, prospects, vendor staff, third-party data subjects)
Purpose of processing stated specifically — not “to provide services”
Lawful basis identified under Section 4: consent under Section 6, or one of the specified legitimate uses under Section 7
Where the basis is consent, the consent flow and notice version are cross-referenced
Where the basis is legitimate use, the specific Section 7 sub-clause invoked is cited, and the conditions of that sub-clause are evidenced
Retention period justified by the purpose; deletion trigger documented; aligned to Rule 8
Necessity and Proportionality
Necessity test: documented reasoning that the processing is necessary for the stated purpose; alternatives considered and rejected with reasoning
Proportionality test: documented reasoning that the volume, granularity, and retention of data are proportionate to the purpose; data minimisation applied
Where the activity processes more data than the bare minimum, the additional data is each justified individually
Where the activity retains data longer than the operational minimum, the retention is justified by a specific obligation or purpose
Profiling, inference, and enrichment activities, if any, justified separately from the underlying transaction
Necessity and proportionality reasoning is specific to this activity — not boilerplate carried over from prior DPIAs
Sign-off on necessity and proportionality by the DPO; DPO has authority to find a DPIA insufficient and require revision
Risk Identification and Mitigation Mapping
Risks to data principal rights identified systematically across at least: confidentiality, integrity, availability, transparency, lawfulness, fairness, accuracy, retention, rights exercise
Each risk rated on a consistent scale defined by the institution's risk methodology, applied across all DPIAs uniformly
Likelihood and impact rated separately; combined into an inherent risk rating
Mitigations mapped one-to-one to each risk above the institution's defined tolerance
Mitigations classified by type: technical (encryption, access control, pseudonymisation), organisational (training, policy, segregation of duties), procedural (review cadence, exception handling)
Mitigations evidenced: each mitigation linked to a specific control, policy, or technical implementation that can be examined in audit
Residual risk re-rated after mitigation; residual rating documented
Residual risk above the institution's risk tolerance escalated and accepted by a named owner with sign-off authority
Where residual risk is accepted at a senior level, the rationale is documented
Risks specific to the security safeguards required under Rule 6 examined: access controls, encryption at rest and in transit, log retention, integrity protections, incident detection, restoration capability
Algorithmic and Cross-Border Assessments
Algorithmic-fairness assessment per Rule 13(3) completed for any processing involving automated decisioning with significant individual impact
Fairness assessment documents: the algorithm class, the training data lineage, the bias-testing methodology, the fairness metrics applied (e.g. demographic parity, equal opportunity, calibration), and the findings
Explainability provision documented: how a data principal who challenges a decision will be given an account of the decision
Human oversight provision documented: which decisions require human-in-the-loop, which require post-hoc review, which run autonomously
Cross-border transfer assessment per Rule 15 completed where applicable: receiving jurisdiction, transfer mechanism, contractual safeguards
Transfer impact assessed against the receiving jurisdiction's regulatory regime
Onward-transfer restrictions defined where the processor in the receiving jurisdiction further transfers data
Cross-border assessment refreshed on a defined cadence and on material change to the receiving jurisdiction's regime
Stakeholder Loop and Sign-offs
Business owner reviewed and signed: confirms the activity description and the necessity reasoning
CISO consulted on security mitigations; sign-off on Rule 6 safeguards
Legal reviewed: confirms lawful basis under Section 4 and the specific Section 7 sub-clause if applicable
DPO reviewed: has authority to require revision, classify the activity as non-compliant pending mitigation, or escalate
Board-level awareness for activities with material residual risk in an SDF context
Where the DPIA recommends “do not proceed” or “proceed only with material mitigation,” the recommendation is recorded and the business decision in response is recorded
Sign-off sequence is enforced — not all signatures collected in parallel; DPO sign-off comes after business, CISO, and legal sign-offs
Post-DPIA Lock and Downstream Wiring
DPIA versioned; version locked after DPO approval; locked version is tamper-evident
DPIA traceable to the underlying evidence — interview notes, technical configuration, contract clauses
ROPA updated to reflect this processing activity and to cross-reference this DPIA version
Vendor DPAs updated if the DPIA identifies new processors or sub-processors; processor-specific obligations flowed down
Mitigations entered into the project plan and the operational backlog with owners and target dates; ownership for ongoing mitigation distinct from ownership for the DPIA itself
DPIA review cadence scheduled — minimum annual for SDFs under Rule 13(1); on-trigger for material change to the activity (new data category, new processor, new jurisdiction, new decisioning logic)
Where the activity is determined no longer needed, the closure is documented and Rule 8 erasure is initiated for the underlying data
DPIA inventory dashboard maintained, providing a current view of which DPIAs are current, due, or overdue, with the named DPO owner
DPDP Assurance Platform
Operationalise this checklist on the DPDP Assurance platform — purpose-built for Indian DPOs managing the full DPDP Act lifecycle.
Operationalise this →