What is a Data Protection Impact Assessment under DPDP and when is it needed
DPIAs are mandatory for Significant Data Fiduciaries under DPDP. Here is what a DPIA is, when it is needed, and how to conduct one.
What triggers a DPIA under DPDP?
For Significant Data Fiduciaries: the government may specify categories of processing that require a DPIA before commencement. Internationally recognised triggers that are likely to be adopted: large-scale processing of sensitive personal data; systematic profiling of individuals with significant effects; use of new technologies with unknown privacy implications; processing of children's data at scale; processing that involves matching or combining datasets from different sources; and cross-border transfer of large volumes of sensitive data. Even for non-SDFs, use these triggers as a guide for when a voluntary DPIA is advisable.
What are the key components of a DPDP-aligned DPIA?
A DPIA should cover: (1) Description of the processing activity — what data, what purpose, what systems; (2) Necessity and proportionality assessment — is this processing necessary for the purpose? Could a less privacy-invasive approach achieve the same goal? (3) Risk identification — what privacy risks does this processing create for data principals? (4) Risk assessment — how likely and how severe are each risk? (5) Risk mitigation measures — what controls, safeguards, and design changes can reduce the risks? (6) Residual risk assessment — what risk remains after mitigation? (7) Sign-off — DPO or senior responsible person reviews and approves.
When should a DPIA be conducted?
Conduct the DPIA before launching the processing activity — ideally during the design phase when changes are cheapest. A DPIA conducted after a product is built and the decision to launch is made is a compliance exercise, not a genuine risk assessment — it will identify risks but the organisation may not have the budget or appetite to address them. Privacy by Design means conducting a DPIA (or privacy risk assessment) when the product specification is first created, not when it is ready for release.
How does a DPIA differ from a standard risk assessment?
A general IT risk assessment focuses on operational risks — system downtime, security breaches, data loss — from the organisation's perspective. A DPIA focuses on privacy risks from the data principal's perspective — what harm could this processing cause to individuals? Could it lead to discrimination? Could it enable surveillance? Could it damage their reputation? Could it restrict their access to services? The DPIA's output is a risk register from the individual's viewpoint, and mitigation measures must reduce risks to the individual, not just reduce organisational risk.
What happens if the DPIA identifies a high residual risk?
If the DPIA identifies a high residual risk that cannot be adequately mitigated, the SDF must consult the Data Protection Board before proceeding with the processing. The Board may approve the processing with additional conditions, require further mitigation, or prohibit the processing. For non-SDFs, if a DPIA identifies a high residual risk, the decision of whether to proceed should be escalated to senior management or the board — it is a decision above the DPO's individual authority. In some cases, not proceeding with a high-risk processing activity is the right risk management decision.
How do you document a DPIA?
DPIA documentation: create a structured template covering all components; document findings in writing during the assessment (not retrospectively); include the date, participants, and data sources used in the assessment; record all identified risks and the mitigation measures decided upon; note residual risks that cannot be fully mitigated; include DPO sign-off; and archive the DPIA with the project documentation. For SDFs, DPIA records will be required by the Board in any enforcement inquiry into a processing activity that caused harm. A well-documented DPIA is evidence of good faith compliance.
Frequently asked questions
Is a DPIA required for processing employee data?
For non-SDF employers, a DPIA is not legally required for standard HR data processing (payroll, attendance, performance). However, if introducing a new HR technology that processes data in a novel way — a performance analytics AI, a biometric wellness monitor, a social listening tool for employee sentiment — a DPIA is advisable before rollout. For SDF-level employers, DPIAs may be required for large-scale HR technology deployments. Apply the trigger criteria (large scale, sensitive data, new technology, significant effects on individuals) to each new HR system.
Who conducts the DPIA — internal or external?
A DPIA can be conducted by internal staff (the DPO or privacy team), an internal cross-functional team (privacy, IT, product, legal), or an external privacy consultant. Internal assessments are faster and cheaper; external assessments bring independent perspective and are more credible in enforcement proceedings. For high-stakes processing (large-scale sensitive data, novel AI applications, high-profile consumer products), external DPIA assessment is recommended. For routine product features, internal assessment with DPO oversight is sufficient.
Does a DPIA need to be repeated?
A DPIA should be reviewed: when the processing activity changes significantly (new data categories, new purpose, new technology); when the regulatory environment changes (new DPDP Rules or Board guidance); and on a periodic basis (at least every 3 years for ongoing processing activities). A DPIA conducted at launch is not permanently valid — processing activities evolve and the privacy risks change over time. Build DPIA review into your product development and privacy governance cycles.
Conduct a DPDP-aligned DPIA for your product
Niti Bharat's DPIA Builder provides a structured DPIA template for DPDP — risk identification matrix, mitigation measures library, residual risk assessment, and DPO sign-off workflow.
Build Your DPIA