How to Conduct a DPIA Under India's DPDP Act: A Practitioner's Guide

How to Conduct a DPIA Under India's DPDP Act: A Practitioner's Guide

Every Significant Data Fiduciary in India will be required to conduct a Data Protection Impact Assessment at least once every 12 months under the DPDP Rules, 2025. That much is settled law. What isn't settled is how. The DPBI hasn't published a DPIA template. MeitY hasn't issued guidance on what a compliant assessment looks like. And the IAPP's theoretical analysis correctly notes that the DPDP Act's DPIA requirement is structurally different from the GDPR's, making European templates an unreliable starting point. Indian enterprises designated as SDFs will need to build their DPIA methodology before they're told exactly what it should contain. This guide provides a practitioner framework for doing so.

Why DPDP DPIAs Are Not GDPR DPIAs

The first mistake enterprises make is assuming they can repurpose their GDPR DPIA template for India. They can't. The two frameworks differ on three fundamental dimensions.

Trigger mechanism. Under GDPR Article 35, DPIAs are triggered by specific high-risk processing activities: large-scale profiling, systematic monitoring of public areas, large-scale processing of special category data. An organization that doesn't engage in high-risk processing may never need to conduct a DPIA at all. Under the DPDP Act, the trigger is entity status, not processing type. If you're designated as a Significant Data Fiduciary, you conduct DPIAs annually on all processing activities, regardless of whether any individual activity would be considered "high risk" by European standards.

This is a much broader mandate. A large Indian bank conducting only routine transaction processing and KYC verification still needs annual DPIAs. A telecom operator running standard subscriber management without any profiling or AI still needs DPIAs. The assessment isn't about identifying high-risk processing; it's about comprehensively evaluating all processing against Data Principal rights.

Scope. GDPR DPIAs focus narrowly on the specific processing activity that triggered the assessment. The DPDP Act's annual DPIA requirement implies a comprehensive review of the SDF's entire processing landscape. This is closer to a privacy audit than a targeted risk assessment. Enterprises that staff DPIAs as one-off project tasks will be overwhelmed. This needs to be an ongoing programme with dedicated resources.

Regulatory expectation. GDPR DPIAs must be shared with the supervisory authority only when the assessment reveals high residual risk that cannot be mitigated. Under the DPDP Rules, SDFs must conduct DPIAs periodically and make them available to the DPBI. The expectation is that the Board can request any DPIA at any time, not just when risks are flagged. Your DPIA documentation needs to be audit-ready from day one.

Where to Start Based on Your Current Maturity

Not every enterprise begins from the same point. The right approach to building a DPIA programme depends on where you are today.

If you already have a GDPR DPIA programme

You have infrastructure, trained assessors, and documented methodology. Your adaptation work focuses on three changes:

First, expand scope from triggered assessments to comprehensive coverage. Your GDPR programme probably has 5 to 15 DPIAs covering specific high-risk activities. Your DPDP programme needs to cover every processing activity across the organization. Start by mapping all processing activities that aren't currently covered by a GDPR DPIA and building them into the annual cycle.

Second, recalibrate the risk framework. GDPR risk assessment evaluates impact on "rights and freedoms" as defined by European jurisprudence. DPDP risk assessment must evaluate impact on Data Principal rights as defined by the Indian Act: access (Section 11), correction and erasure (Section 12), grievance redressal (Section 13), and nomination (Section 14). These overlap with GDPR rights but aren't identical. Your risk scoring matrix needs adjustment.

Third, restructure your documentation for Indian regulatory expectations. GDPR DPIAs are internal documents shared with the DPA only in exceptional circumstances. DPDP DPIAs should be treated as regulatory deliverables that the Board can request at any time. Documentation standards should match what you'd prepare for an auditor, not what you'd file internally.

If you're starting from scratch

You need to build three things simultaneously: a processing inventory (what data you process, why, and where), a risk assessment methodology (how you evaluate impact on Data Principal rights), and a documentation framework (how you record assessments in a format the DPBI will accept).

The processing inventory is the foundation. You cannot assess risks you haven't mapped. For a large enterprise, this inventory typically takes 8 to 12 weeks to build properly, covering every system, application, vendor, and business process that touches personal data. Attempting to conduct DPIAs without a complete inventory produces assessments that miss entire categories of processing, which is worse than having no DPIA at all because it creates a false sense of compliance.

Start with a pilot: select one business unit or one processing activity (customer onboarding, for instance), conduct a full DPIA on that activity, refine the methodology, and then scale across the organization. Attempting to assess everything simultaneously leads to surface-level assessments that satisfy nobody.

The DPIA Methodology: Five Components Every Assessment Must Cover

The DPDP Act describes a DPIA as setting out "a description of the rights of Data Principals, the purpose of processing of their personal data, and assessment and management of the risk to the rights of Data Principals" (Section 10(2)(c)). From this statutory language, five components emerge as mandatory.

Component 1: Processing Description

Document exactly what personal data is processed, from whom, for what purpose, through what systems, and for how long. This isn't a summary; it's a detailed technical and operational description that would allow an auditor to understand the complete data lifecycle.

For each processing activity, record:

The most common failure here is listing purposes too broadly. "Customer service" isn't a purpose; it's a category. "Responding to customer complaints within 72 hours" is a purpose. "Fraud detection" isn't a purpose; "real-time transaction monitoring to identify unauthorized account access" is. Specificity matters because the DPBI will evaluate whether your processing is proportionate to the stated purpose.

Component 2: Data Principal Rights Impact Assessment

The DPDP Act grants Data Principals five specific rights. Your DPIA must evaluate how each processing activity affects each right.

Right of access (Section 11). Can a Data Principal request and receive a summary of all personal data processed and the identities of all Data Processors with whom data has been shared? If your processing involves complex data flows across multiple systems and vendors, access fulfilment becomes technically challenging. Document how you'll compile a complete response across fragmented systems.

Right of correction and erasure (Section 12). Can a Data Principal request correction of inaccurate data or erasure of data no longer needed? For processing activities subject to regulatory retention mandates (banking KYC, tax records, insurance claims), document which data fields can be erased and which must be retained, with the legal basis for each.

Right of grievance redressal (Section 13). Does your processing create a pathway for Data Principals to raise complaints? If automated processing (credit scoring, insurance underwriting) produces adverse outcomes for individuals, is there a mechanism for the individual to challenge the decision and receive human review?

Right of nomination (Section 14). Can Data Principals nominate another individual to exercise rights on their behalf in case of death or incapacity? Processing activities involving long-term data retention (insurance, pension, banking) must accommodate nomination workflows.

Impact on children. If any processing involves personal data of individuals under 18, Section 9's enhanced protections apply: verifiable parental consent, no behavioural tracking, no targeted advertising. Your DPIA must specifically flag processing activities that involve or could involve children's data and document the additional safeguards in place.

Component 3: Risk Identification and Scoring

For each processing activity, identify risks to Data Principal rights and score them by likelihood and severity.

Risk categories to assess:

• Unauthorized access: Could a breach expose this data? What would the impact be on affected individuals?
• Purpose creep: Could this data be used for purposes beyond what the Data Principal consented to?
• Disproportionate processing: Is the data collected proportionate to the stated purpose, or are you collecting more than necessary?
• Algorithmic harm: If automated decision-making is involved, could the algorithm produce discriminatory or unfair outcomes?
• Retention risk: Is data retained longer than necessary? Could stale data create inaccurate profiles?
• Cross-border exposure: Is data transferred to jurisdictions that the government might restrict in the future?
• Vendor chain risk: If processing involves third-party vendors, do vendor security practices match the risk level of the data they process?

Score each risk on a simple matrix: likelihood (low/medium/high) multiplied by severity (low/medium/high). Document the scoring rationale. The DPBI won't expect actuarial precision; they'll expect evidence that you thought systematically about what could go wrong and how badly it could affect individuals.

Component 4: Mitigation Measures

For every medium or high risk identified, document the specific technical and organizational measures that reduce the risk to an acceptable level.

Technical measures include encryption (specify standard: AES-256 at rest, TLS 1.3 in transit), access controls (role-based access with multi-factor authentication), pseudonymization, data masking, automated data deletion after retention periods, and intrusion detection systems.

Organizational measures include staff training (specify frequency and content), data handling policies, vendor management procedures, incident response plans, and internal audit schedules.

The measure must be proportionate to the risk. A high-risk processing activity (large-scale financial data processing) warrants AES-256 encryption, real-time monitoring, and annual penetration testing. A lower-risk activity (employee attendance records) warrants role-based access controls and basic encryption. Over-engineering controls for low-risk processing wastes resources. Under-engineering controls for high-risk processing creates regulatory exposure.

Component 5: Residual Risk Documentation

After mitigation measures are applied, document the residual risk level. Some risk cannot be eliminated entirely. A bank that processes millions of customer accounts will always have some residual breach risk, regardless of how strong its security controls are.

The DPIA must document: what risks remain after mitigation, why they cannot be further reduced, whether the residual risk level is acceptable given the processing purpose, and what monitoring is in place to detect if residual risks materialize.

This is the section that demonstrates maturity. An enterprise that documents "no residual risk" isn't being thorough; it's being unrealistic. An enterprise that documents specific residual risks with monitoring plans and escalation procedures demonstrates that it understands data protection as an ongoing discipline, not a one-time exercise.

Making DPIAs Operational: Building the Annual Cycle

A single DPIA is a document. An annual DPIA programme is an operating model. The difference matters because the DPDP Rules require SDFs to conduct DPIAs "periodically, at least once in twelve months." That means your first DPIA is due within 12 months of SDF designation, and every subsequent year thereafter.

Quarter 1: Update the processing inventory. Identify new processing activities added since the last DPIA cycle (new products, new vendors, new systems). Retire assessments for processing activities that have been decommissioned. This is also when you incorporate lessons from any breaches, complaints, or regulatory interactions from the previous year.

Quarter 2: Conduct the assessments. Work through each processing activity against the five components above. For a large SDF with hundreds of processing activities, this requires dedicated assessors; don't expect the DPO to do this alone.

Quarter 3: Review and remediate. Present DPIA findings to senior management. Prioritize remediation of high-risk items. Track mitigation implementation against deadlines.

Quarter 4: Finalize documentation. Produce the annual DPIA report. File with the DPO's office. Make available for DPBI review on request. Begin preparing for the next cycle.

This annual rhythm should align with the independent data audit cycle that SDFs must also undergo. The DPIA and the data audit cover overlapping ground; conducting them in sequence (DPIA first, audit second) allows the audit to verify DPIA findings rather than duplicating the assessment.

What the DPBI Will Look for in Your DPIA

The DPBI hasn't published DPIA evaluation criteria. But based on the statutory language, international precedent from the ICO's DPIA guidance and CNIL's DPIA framework, and the DPDP Act's emphasis on Data Principal rights, we expect the Board to evaluate DPIAs on four dimensions:

Completeness. Does the DPIA cover all processing activities? Assessments that skip "low risk" processing will be viewed as incomplete. The Board's expectation is comprehensive coverage, not selective coverage.

Specificity. Does the DPIA describe processing in sufficient detail for the Board to understand what is happening with personal data? Generic descriptions ("we process customer data for business purposes") will be flagged. Specific descriptions ("we process customer transaction data through our core banking system, shared with our fraud detection vendor via encrypted API, retained for 7 years per RBI KYC requirements") demonstrate governance maturity.

Proportionality of response. Are mitigation measures proportionate to the identified risks? Both over-engineering (enterprise-grade security for a newsletter mailing list) and under-engineering (basic passwords for financial data systems) suggest that the SDF isn't applying judgment.

Candour about residual risk. Does the DPIA acknowledge what cannot be fully mitigated? The Board will trust an SDF that documents genuine residual risks and monitors them more than an SDF that claims zero risk.

Frequently Asked Questions

Do we need to conduct DPIAs before we're officially designated as an SDF? Legally, no. The DPIA obligation applies only to Significant Data Fiduciaries after designation. Practically, yes. Building a DPIA programme from scratch after designation means your first annual DPIA will be rushed, incomplete, and potentially non-compliant. Enterprises that expect SDF designation, which includes most large banks, insurers, telecom operators, and major digital platforms, should begin building their processing inventory and methodology now. The banks article in this series discusses SDF preparation in the BFSI context specifically.

Can we use our GDPR DPIA as a starting point? As a starting point, yes. As a finished product, no. Your GDPR DPIA covers specific high-risk processing activities. Your DPDP DPIA must cover all processing activities comprehensively. Your GDPR risk framework evaluates impact on EU-defined rights and freedoms. Your DPDP risk framework must evaluate impact on DPDP-defined Data Principal rights (Sections 11-14). Adapt the methodology; don't copy the output.

How much does building a DPIA programme cost? Costs vary significantly based on organizational size, processing complexity, and existing privacy maturity. The primary cost driver isn't the assessment itself; it's building the processing inventory that underlies it. An enterprise with an existing, comprehensive data map can conduct DPIAs relatively efficiently. An enterprise that needs to build the inventory from scratch is looking at a significantly larger investment. We recommend a scoping assessment to determine your starting point before budgeting.

Who should conduct the DPIA, internal team or external advisor? Both have roles. The DPO should own the DPIA programme and coordinate assessments. Business unit owners should provide processing descriptions and context. An external advisor brings objectivity, cross-industry benchmarking, and regulatory interpretation that internal teams may lack. For the first annual cycle, external advisory support is particularly valuable to establish methodology and documentation standards that the internal team can then maintain in subsequent years.

What happens if the DPIA identifies risks we can't mitigate? Document them candidly. The DPDP Act doesn't require zero risk. It requires that you identify risks, implement proportionate mitigation, and document residual risks with monitoring plans. If a residual risk is genuinely unacceptable (severe impact, high likelihood, no viable mitigation), the appropriate response is to reconsider whether the processing activity should continue in its current form. The DPIA's value is precisely in forcing this question before the DPBI forces it for you.