Organisations increasingly rely on personal data to operate digital products, analyse customers, personalise services and develop new technologies. As data use becomes more complex, businesses need a structured method to identify privacy risks before they become legal, financial or operational problems. A data protection impact assessment provides this framework. It helps an organisation understand what personal data a project will process, why the processing is necessary, what risks individuals may face and which safeguards can reduce those risks. In India, DPIAs have particular importance under the Digital Personal Data Protection Act, 2023 because Significant Data Fiduciaries are required to undertake periodic DPIAs and audits.

What Is a Data Protection Impact Assessment?

A Data Protection Impact Assessment is a structured process for examining the privacy and data protection implications of a proposed or existing processing activity. It is designed to identify risks to individuals and establish practical measures for reducing those risks. A DPIA should not be treated as a document prepared only for the legal department. It is a business governance exercise involving technology, information security, product, compliance, procurement and operational teams. The assessment should explain how personal data moves through a project and whether the proposed processing is justified, proportionate and adequately protected. A good DPIA also creates evidence of responsible decision making. It demonstrates how an organisation considered privacy risks before introducing a new system, technology or processing activity.

Why Is a DPIA Important for Businesses?

Privacy risks can arise long before a product reaches customers. A company may introduce artificial intelligence, combine customer datasets, deploy behavioural analytics or outsource processing without fully understanding the consequences for individuals. A DPIA brings these issues into the project lifecycle. It can identify excessive data collection, unnecessary retention, unclear purposes, weak access controls, inappropriate sharing and risks created by third party vendors. The assessment also encourages privacy by design. Instead of attempting to correct privacy problems after a product launches, teams can consider safeguards while the project is still being designed. For businesses operating across several jurisdictions, a DPIA can also provide a common risk assessment framework. However, the organisation must still identify the specific requirements of each applicable law. A GDPR based DPIA should not simply be copied and presented as an Indian DPDP assessment without considering the differences between the two frameworks.

What Is the Position Under India's DPDP Act?

The Digital Personal Data Protection Act, 2023 creates additional obligations for organisations classified as Significant Data Fiduciaries. Section 10 allows the Central Government to notify a Data Fiduciary or class of Data Fiduciaries as a Significant Data Fiduciary based on factors such as the volume and sensitivity of personal data, risks to Data Principals and potential impacts on sovereignty, security, electoral democracy and public order. Once an organisation is a Significant Data Fiduciary, Section 10 requires it to appoint a Data Protection Officer, appoint an independent data auditor and undertake periodic Data Protection Impact Assessments and audits. The Act describes a DPIA as a process involving a description of the rights of Data Principals and the purpose of processing, along with assessment and management of risks to those rights. The DPDP Rules, 2025 provide further detail. Rule 13 requires a Significant Data Fiduciary to undertake a DPIA and audit once every twelve months from the date it is notified as an SDF or included within a notified class. The person conducting the assessment and audit must provide a report containing significant observations to the Data Protection Board. This means DPIA obligations under the Indian framework should not be described as a universal requirement for every business processing personal data. The statutory periodic obligation is specifically connected with Significant Data Fiduciary status. Organisations not designated as SDFs may still find DPIAs highly valuable as part of privacy governance, risk management, vendor due diligence and preparation for future regulatory expectations.

When Should a Business Conduct a DPIA?

A DPIA should ideally begin before a high impact processing activity is implemented. Starting early gives the organisation enough time to modify the project before technical architecture, contracts and commercial commitments make changes difficult. Under the Indian framework, an organisation should consider conducting a DPIA when a project involves substantial personal data risks, new technologies, large scale processing, profiling, artificial intelligence, extensive monitoring, sensitive business environments or significant changes to an existing processing operation. A DPIA can also be useful when several datasets are being combined. Data that appears relatively low risk when considered separately may create greater privacy concerns when combined with customer profiles, financial information, behavioural records or location information. The assessment should also be reconsidered when the processing changes materially. A DPIA completed during product development may no longer accurately describe the system after a new vendor, new data source, new AI model or new purpose is introduced.

Step 1: Define the Project and Scope

The first step is to establish exactly what the DPIA covers. The project should have a clear name, business owner, technical owner and purpose. The assessment should explain why the project exists and what outcome the organisation expects to achieve. It should identify the systems involved, the categories of individuals affected and the stages of processing being assessed. A broad project description can make risk assessment difficult. A more useful approach is to define the actual processing operation. For example, instead of assessing “customer analytics”, the organisation could assess a specific system used to combine purchase history, website activity and customer preferences for personalised recommendations. The scope should also identify whether the processing is new or an alteration to an existing activity. This helps determine which existing controls, policies and contracts need to be reviewed.

Step 2: Map the Personal Data Flow

A DPIA cannot be reliable unless the organisation understands how personal data moves through the system. The assessment should identify where data originates, how it is collected, where it is stored, which systems receive it, who can access it, whether processors are involved and when the information is deleted. A data flow diagram can be particularly useful. It can show movement between websites, mobile applications, internal databases, cloud platforms, analytics systems, payment providers and external vendors. The organisation should also identify the categories of personal data involved. This may include identity information, contact details, financial information, employment records, location information, behavioural information or other personal data. The purpose is not simply to create a technical map. The data flow should help legal and compliance teams understand whether the actual processing matches the stated purpose and privacy documentation.

Step 3: Identify the Purpose and Legal Basis

Every processing activity should have a clearly defined purpose. A DPIA should explain why the organisation needs the information and whether the processing is connected with that purpose. Under the DPDP Act, processing must have a lawful basis. Consent is one basis, but it is not the only one. The Act recognises specified legitimate uses in Section 7. A DPIA should therefore record the legal basis being relied upon rather than assuming consent is required for every processing activity. Where consent is used, the assessment should examine how consent is obtained, how it is recorded and how withdrawal is managed. Where another lawful basis applies, the organisation should document why the relevant statutory condition is applicable. Purpose clarity is especially important for AI projects and analytics systems. A company may initially collect data for customer support and later want to use the same information for product development, advertising or model training. The DPIA should examine whether the proposed secondary use is legally and operationally appropriate.

Step 4: Assess Necessity and Proportionality

A DPIA should ask a fundamental question: does the organisation need to process all the proposed data to achieve its objective? If a product can work effectively with less information, collecting additional personal data may increase privacy risk without providing sufficient business value. The organisation should consider data minimisation, retention periods, access requirements and alternative methods. It should also assess whether the processing is proportionate to the expected outcome. For example, a business developing a fraud detection system may need certain transaction information. It does not automatically follow that every employee should have access to the full dataset or that the information should be retained indefinitely. Necessity and proportionality should therefore be assessed from both legal and operational perspectives.

Step 5: Identify Privacy Risks

Risk identification is the core of a DPIA. The organisation should consider how processing could negatively affect Data Principals. Risks may include unauthorised disclosure, identity fraud, financial harm, discrimination, loss of confidentiality, excessive monitoring, inaccurate decisions, misuse of information or inability to exercise privacy rights. AI systems can create additional risks. An algorithm may produce inaccurate outputs, rely on poor quality information or make decisions using data in ways individuals did not reasonably expect. Automated profiling may also create risks where personal information is used to categorise or evaluate individuals. Children and other vulnerable groups may require particular attention because the consequences of inappropriate processing can be more serious. The assessment should distinguish between risks to the organisation and risks to individuals. A DPIA is primarily concerned with the effect of processing on people, although regulatory, financial and reputational consequences for the organisation may also be documented.

Step 6: Evaluate Likelihood and Severity

Not every identified risk has the same level of significance. The organisation should evaluate both the likelihood of the risk occurring and the potential severity of its consequences. A useful assessment considers the type of harm, the number of individuals affected, the sensitivity of the information, the duration of the impact and the organisation's existing safeguards. For example, unauthorised disclosure of a basic preference may present a different level of risk from exposure of financial or authentication information. Risk scoring should be consistent with the organisation's wider risk management framework. A simple methodology can be effective if teams understand how likelihood and impact are determined. The important point is to avoid arbitrary scores. Each conclusion should have a documented rationale supported by facts about the actual processing activity.

Step 7: Identify Mitigation Measures

Once risks have been identified, the organisation should determine how they can be reduced. Technical safeguards may include encryption, access controls, authentication, logging, monitoring, tokenisation, pseudonymisation and secure deletion. Organisational measures may include policies, training, approval processes, contractual controls and periodic reviews. Data minimisation can often be more effective than adding security controls after excessive data has already been collected. If certain information is not necessary, the best mitigation may be to avoid collecting it. Vendor controls are also important. A processor handling personal data should be assessed for security, confidentiality, breach response, retention and deletion arrangements. The DPIA should identify who is responsible for implementing each mitigation measure and when the measure must be completed. A recommendation without an owner or deadline can easily remain an unresolved risk.

Step 8: Consider Algorithmic and AI Related Risks

The Indian DPDP Rules introduce an important consideration for Significant Data Fiduciaries. Rule 13 requires SDFs to exercise due diligence to verify that technical measures, including algorithmic software used for various operations involving personal data, are not likely to pose a risk to the rights of Data Principals. This makes algorithmic assessment particularly relevant for organisations using artificial intelligence, automated profiling, recommendation engines or other systems affecting personal data. A DPIA involving AI should examine the source of training and input data, data quality, purpose, access controls, model outputs, human oversight and potential discriminatory or harmful effects. It should also consider whether personal data can be removed when required, how prompts and logs are retained, whether vendors reuse submitted information and how model changes are controlled. A DPIA should not become a technical model validation exercise alone. The assessment needs to connect technical behaviour with the rights and interests of individuals.

Step 9: Assess Third Party and Cross Border Processing

Modern projects rarely operate entirely within one organisation. Cloud providers, software vendors, analytics companies, consultants and other processors may have access to personal data. The DPIA should therefore identify every important external party involved in processing. The organisation should determine what information each vendor receives, why it receives it and whether the vendor can use the information for its own purposes. International transfers require additional assessment. The organisation should identify where data is stored, where it can be accessed and whether another jurisdiction's law may apply. The DPIA should also be aligned with contracts. If the assessment states a vendor will delete information after a defined period but the contract contains no corresponding obligation, the governance framework has a gap.

Step 10: Consult Relevant Stakeholders

A DPIA should not be completed in isolation. Legal and compliance teams may understand statutory requirements, but technology teams understand system architecture. Information security teams understand technical threats, while product teams understand the actual business use case. Procurement teams can provide information about vendors and contractual terms. Customer service teams may identify practical consequences for individuals. Senior management may need to approve significant residual risks. Where appropriate, organisations may also consider input from affected individuals or representative groups, especially for projects involving substantial impacts on people. Consultation creates a stronger assessment because it combines different perspectives before a project is approved.

Step 11: Document the Outcome and Obtain Approval

The completed DPIA should provide a clear record of the processing, identified risks, mitigation measures and final decision. The conclusion should state whether the project can proceed, whether it can proceed subject to specified safeguards or whether further changes are required. Any residual risk should be clearly documented. The organisation should avoid simply marking every risk as “low” after mitigation without explaining why. Senior management or an appropriate governance committee should approve material residual risks. The assessment should also record disagreements where relevant and explain how the final decision was reached. For an SDF, the DPIA process should be capable of supporting the reporting requirements under Rule 13 and the organisation's wider audit framework.

Step 12: Monitor and Review the DPIA

A DPIA should not become a static document stored in a compliance folder. The organisation should revisit it when the purpose changes, new data is introduced, a new vendor is appointed, technology changes, the volume of processing increases or a significant incident occurs. Significant Data Fiduciaries have a specific periodic assessment requirement under Rule 13. The Rule requires the DPIA and audit to be undertaken once every twelve months from the relevant notification or inclusion date. Even where an organisation is not subject to the statutory SDF requirement, periodic reviews can provide valuable evidence of responsible privacy governance.

What Should a DPIA Report Contain?

A practical DPIA report should begin with the project description, business purpose and scope. It should then explain the personal data involved, categories of Data Principals, processing activities, systems, vendors and data flows. The report should document the applicable legal basis, necessity and proportionality analysis, individual risks and risk ratings. It should then record safeguards, responsible owners, implementation deadlines and residual risks. The final section should contain the decision, approval information and review date. Supporting documents such as architecture diagrams, vendor assessments, security reports and contract summaries can be retained as evidence. The exact format can vary according to the organisation and project. What matters is whether the assessment provides a clear and defensible record of how privacy risks were identified and managed.

DPIA vs Privacy Audit: What Is the Difference?

A DPIA and a privacy audit serve related but different purposes. A DPIA generally focuses on the privacy risks associated with a specific processing activity, project, system or change. It is most useful during planning and implementation. A privacy audit examines whether an organisation is complying with applicable requirements and internal controls. It may cover multiple systems and business functions. For Significant Data Fiduciaries, the DPDP framework connects DPIAs and audits through Section 10 and Rule 13. The two exercises should therefore be coordinated without treating them as identical processes.

DPIA Under the DPDP Act and GDPR

The concept of a DPIA is strongly associated with Article 35 of the GDPR. Under the GDPR, a DPIA is required before processing likely to result in a high risk to individuals' rights and freedoms. European guidance also focuses on processing description, necessity, proportionality, risk assessment and mitigation. India's framework is structured differently. The DPDP Act specifically places periodic DPIA obligations on Significant Data Fiduciaries, rather than establishing a universal high risk DPIA requirement identical to Article 35 of the GDPR. Businesses subject to both regimes should therefore maintain a methodology capable of satisfying each applicable law. A European DPIA template can provide useful structure, but it should be adapted to Indian terminology, statutory requirements and the organisation's actual obligations.

Common DPIA Mistakes Businesses Should Avoid

One frequent mistake is starting the assessment after the technology has already been implemented. At this stage, changing architecture can be expensive and difficult. Another mistake is treating the DPIA as a legal document rather than a multidisciplinary assessment. A lawyer cannot accurately assess a system without understanding how the technology works. Some organisations also focus heavily on security while overlooking other privacy risks. Encryption and access controls are important, but they do not solve problems created by excessive collection, unclear purposes, inappropriate profiling or indefinite retention. Another problem is using generic risk statements. A strong DPIA should describe realistic risks associated with the specific processing activity. Finally, organisations sometimes complete a DPIA but fail to implement the measures it recommends. The assessment only creates value when its findings become part of the project plan.

How Legal and Compliance Teams Can Support DPIAs

Legal and compliance teams can help establish the methodology, identify applicable laws and review the project's purpose and legal basis. They can also assess contracts, vendor arrangements, notices, consent mechanisms and cross border processing. For organisations preparing for DPDP compliance, specialist DPIA legal advice can help ensure the assessment reflects Indian statutory requirements rather than simply replicating a GDPR template. The legal review should work alongside technology and security assessments. A DPIA is strongest when legal conclusions, technical architecture and business objectives are considered together.

How Businesses Can Prepare for the DPDP DPIA Requirements

Businesses should begin by identifying projects involving significant personal data processing. They should then establish an internal DPIA methodology, define approval responsibilities and create a consistent evidence framework. Organisations should maintain an inventory of processing activities and identify projects involving artificial intelligence, profiling, large datasets, children, sensitive business processes or extensive third party processing. For organisations likely to fall within the Significant Data Fiduciary framework, preparation should also include governance arrangements for the Data Protection Officer, independent data auditor, periodic assessment and reporting. The DPDP Rules were notified on 13 November 2025 and provide for phased commencement. Rule 13 is within the provisions scheduled to commence 18 months after publication. This means organisations have an important preparation period before the substantive DPIA requirements become operational. Businesses should use this period to establish processes rather than waiting until the statutory deadline approaches.

Conclusion

A Data Protection Impact Assessment is more than a compliance form. It is a structured method for understanding how personal data will be used, identifying risks to individuals and building safeguards into a project before problems arise. For Indian organisations, the DPDP framework gives DPIAs particular importance for Significant Data Fiduciaries. Section 10 creates the statutory requirement, while Rule 13 establishes a twelve month assessment and audit cycle and introduces additional expectations around algorithmic technology. Businesses should therefore approach DPIAs as part of project governance rather than a final legal check. The strongest assessment combines accurate data mapping, clear purposes, legal analysis, necessity and proportionality testing, meaningful risk assessment, technical safeguards, vendor review, documented decisions and ongoing monitoring. Corporate compliance lawyers can also assist businesses in integrating privacy requirements into broader governance and compliance processes. A well designed DPIA can help an organisation make better decisions about new technologies while creating evidence of responsible data governance. As India's DPDP framework moves through its phased implementation, establishing this capability early can help businesses manage privacy risks in a structured and sustainable manner.

Frequently Asked Questions (FAQs)

Q1. Is a DPIA mandatory under India's DPDP Act?

The DPDP Act specifically requires periodic Data Protection Impact Assessments for Significant Data Fiduciaries under Section 10. It does not create the same universal DPIA requirement for every Data Fiduciary as the GDPR high risk model. Organisations outside the SDF category may still conduct DPIAs as part of privacy governance and risk management.

Q2. Who needs to conduct a DPIA in India?

A Data Fiduciary notified as a Significant Data Fiduciary must undertake periodic DPIAs under Section 10. Rule 13 of the DPDP Rules requires an SDF to conduct a DPIA and audit once every twelve months from the relevant notification or inclusion date.

Q3. How often should an SDF conduct a DPIA?

Under Rule 13 of the DPDP Rules, a Significant Data Fiduciary must undertake a DPIA and audit once every twelve months from the date it is notified as an SDF or included in the relevant notified class.

Q4. Is a DPIA required for artificial intelligence projects?

AI does not automatically create a universal DPIA obligation under Indian law. However, AI projects involving significant personal data risks should be assessed carefully. For Significant Data Fiduciaries, Rule 13 also requires due diligence concerning algorithmic software and risks to Data Principals.

Q5. What is the difference between a DPIA and a PIA?

The terms are sometimes used interchangeably. A DPIA generally refers to a structured assessment of data protection risks associated with processing. A Privacy Impact Assessment can be broader and may cover wider privacy considerations. The terminology used should be aligned with the applicable law and the organisation's internal governance framework.

Q6. Can one DPIA cover multiple processing activities?

Potentially. Similar processing operations can sometimes be assessed through a common framework where their purposes, technologies, risks and safeguards are sufficiently similar. The organisation should avoid combining activities merely to reduce documentation if the risks are materially different.

Q7. Should a DPIA be conducted before launching a new product?

Yes, conducting the assessment early is generally more effective. Early assessment allows the organisation to modify data flows, technology, contracts and safeguards before the product becomes difficult to change.

Q8. Who should approve a DPIA?

Approval should depend on the organisation's governance structure and the level of residual risk. Legal, privacy, security, technology and business stakeholders should participate where relevant. Significant risks may require approval by senior management or an appropriate board level committee.

Q9. Does a DPIA replace a security assessment?

No. A DPIA and security assessment address different questions. Security testing focuses heavily on technical and organisational safeguards, while a DPIA examines the broader impact of personal data processing on individuals and the measures used to manage those risks.

Q10. Should a DPIA be reviewed after a data breach?

Yes. A serious data breach may indicate that assumptions or safeguards documented in the original assessment are no longer adequate. The incident should be considered when determining whether the DPIA needs to be updated.

This update was released on 08 Oct 2026.

The views expressed in this update are personal and should not be construed as any legal advice. Please contact us directly on +91 22 40565252 or contact@mhcolaw.com for any assistance.

Legal Update Team
MANSUKHLAL HIRALAL & COMPANY
Advocates, Solicitors and Notaries
T: +91 22 40565252
Mumbai Office: Surya Mahal, 2nd Floor, 5, Burjorji Bharucha Marg, Fort, Mumbai-400 023, India
Delhi Office: Block C-9, Lower Ground Floor, Jangpura Extension, New Delhi - 110 014, India
www.mhcolaw.com

"Noted lawyer in the Real Estate practitioner from India" - Chambers & Partners

Please consider the environment before printing this email

The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. This communication may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or action taken relying on the contents is prohibited and may be unlawful. If you have received this communication in error, or if you or your employer does not consent to email messages of this kind, please notify the sender immediately by responding to this email and then delete it from your system. No liability is accepted for any harm that may be caused to your systems or data by this message.