Data Protection Impact Assessment (DPIA): A Practical Guide for Organizations

A lending team is three weeks from launch. The platform scores applicants using identity data, bank statement analysis, bureau pulls, device fingerprints and in-app behaviour. Security has signed off a penetration test. Legal has approved the privacy notice. Nobody has yet answered the question a Data Protection Impact Assessment exists to answer: what happens to a real person if this system is wrong, breached, or simply over-collects?

That question is not rhetorical, and it is not answered by a clean VAPT report. A DPIA asks a different set of things, and asks them before the architecture hardens:

• What personal data is actually processed — not what the design document claims?
• Why is each field necessary, and what breaks if it is removed?
• Where does it flow, through which APIs, into which cloud services and vendors?
• Who can read it, export it in bulk, or query it without an audit trail?
• How long is it kept, and does deletion actually delete?
• What is the consequence to the individual — not the company — of breach, error or misuse?

This article is a practitioner's guide to running that assessment properly: what Indian law actually requires, where international practice goes further, and how to operationalise a DPIA so it changes design decisions rather than decorating a compliance folder.

What a DPIA Is

Plainly: a DPIA is a structured assessment of how a specific processing activity could harm the people whose data it uses, and what you will change to reduce that harm to an acceptable level.

Technically: it is a documented analysis that establishes the purpose and lawful basis of processing, inventories the personal data involved, maps its flow across systems and third parties, tests necessity and proportionality, identifies privacy and security risks to individuals, evaluates existing controls, scores inherent and residual risk, and records an accountable decision to proceed, modify or abandon.

Three things a DPIA is not:

• Not a vulnerability assessment. A DPIA can conclude that a system with zero exploitable vulnerabilities is still unacceptable — because it collects data it does not need, retains it indefinitely, or subjects people to automated decisions they cannot contest.
• Not a consent review. Lawful basis is one input. Security, retention, rights fulfilment and vendor governance are separate dimensions. We covered that gap in consent management is not DPDP compliance.
• Not a template. A DPIA whose findings could apply to any organisation has assessed nothing.

DPIA Under India's DPDP Framework — What the Law Actually Says

This section is deliberately precise, because a great deal of published commentary imports GDPR obligations into Indian law where none exist.

The Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023, enacted 11 August 2023) is operational law, with the DPDP Rules, 2025 notified on 13 November 2025 and full compliance expected by 13 May 2027.

First, the vocabulary the Act uses:

The DPIA obligation sits in Section 10 — and applies to SDFs

Section 10(1) empowers the Central Government to notify a Data Fiduciary, or a class of them, as a Significant Data Fiduciary based on factors it determines, expressly including the volume and sensitivity of personal data processed and the risk to the rights of Data Principals.

Section 10(2) then imposes additional duties on an SDF: appoint a Data Protection Officer based in India who is answerable to the board or similar governing body and acts as the contact point for grievance redressal; appoint an independent data auditor to evaluate compliance; and undertake further measures, the first of which the Act states as:

Read that definition carefully, because three things follow from it.

It is periodic, not one-off. The statutory word is "periodic". The Act does not itself fix a frequency; further matters may be prescribed. Waiting for a prescribed cadence before setting your own is a poor risk decision — tie reassessment to material change in processing, and review on a defined interval besides.

The subject of the risk is the Data Principal. The Act frames the exercise as assessment and management of risk to the rights of Data Principals — not to the business. A DPIA that scores only regulatory and reputational exposure to the organisation has not performed the assessment the statute describes.

It is scoped to SDFs. Nothing in the Act imposes a DPIA on every Data Fiduciary. That is a genuine difference from the GDPR model and should be stated plainly rather than blurred.

Where the penalties actually fall

The Act's Schedule (referenced by Section 33(1)) sets penalty ceilings per category. The four that matter for this discussion:

So for an SDF, failing to run the periodic DPIA is not a paperwork lapse — it sits in a ₹150 crore category of its own, independent of whether a breach ever occurs.

How This Differs From GDPR Article 35

International practice is worth borrowing from. It is not worth misquoting as Indian law. The differences are material.

Two supporting standards are useful regardless of jurisdiction. ISO/IEC 29134 gives guidelines for privacy impact assessment — process, structure and reporting. ISO/IEC 27701 extends an ISO/IEC 27001 information security management system into a privacy information management system, which is where DPIA outputs become auditable controls rather than one-off documents. The NIST Privacy Framework is a voluntary risk-management structure that pairs well with organisations already using NIST security material. Where you already run ISO 27001, treating the DPIA as a documented control input is far cheaper than building a parallel process.

When to Run One

Regardless of SDF status, these characteristics should trigger an assessment before deployment:

A workable decision path, cheap enough to apply to every change request:

New or changed processing activity
  |
  +-- Personal data involved?                          no  -> record decision, stop
  |     yes
  +-- New purpose, new data, new recipient, new tech?  no  -> light-touch review
  |     yes
  +-- Any high-impact characteristic present?
  |     (scale | inference | biometrics | monitoring |
  |      children | financial or health data |
  |      automated decisions | cross-border)
  |     yes
  +-- FULL DPIA before production deployment
        -> residual risk accepted by a named owner

The Methodology, Step by Step

Fourteen steps, in order. The sequence matters more than the template.

The Technical Assessment

This is where DPIAs most often go thin, and where a security team earns its place at the table. Each area below should produce evidence, not an assertion.

Findings here should be produced by testing — application and API testing, cloud configuration review, access review — not by questionnaire. A control asserted in a document and a control observed in a test are different evidentiary objects.

A Usable Risk Model

Keep the scoring simple enough that engineers will actually use it. Risk = Likelihood × Impact, both on a 1–5 scale, where impact is measured as consequence to the Data Principal.

Likelihood: 1 Rare, 2 Unlikely, 3 Possible, 4 Likely, 5 Almost certain. Impact: 1 Minimal, 2 Minor, 3 Moderate, 4 Major, 5 Severe. Score 1–6 low, 8–12 medium, 15–25 high. Inherent risk is scored before mitigation; residual risk after the agreed controls are actually implemented — not after they are merely planned.

Note what the residual column is really for: it is the record of what a named person accepted on behalf of the organisation, and of the people whose data it is.

Worked Example: AI-Powered Digital Lending

Activity. Underwriting and servicing for an app-based personal loan, using an ML model for risk scoring.

Data. Name, mobile, email, PAN, bank account and statement data, declared and derived income, bureau credit data, device attributes, IP address, coarse location, in-app behaviour.

Flow. Mobile app to API gateway; identity to KYC vendor; account data to an aggregator; bureau pull to credit bureau; features to the model service; decisions and documents to core lending; events to analytics; notifications via SMS and email gateways; everything replicated into a warehouse for reporting.

Third parties. KYC provider, statement aggregator, credit bureau, cloud provider, analytics platform, communication gateways, collections agency — each a processor or recipient with its own sub-processors.

Principal privacy risks. Over-collection of transaction-level data far beyond the underwriting need; opaque automated decisions with no reason codes; behavioural data reused for marketing without a matching basis; broad internal access to identity documents; retention with no defined expiry; deletion that stops at the primary record; sub-processors outside the transfer map.

Principal security risks. Object-level authorisation flaws in the loan-status API; over-permissive cloud storage on the document bucket; shared decryption authority; absent alerting on bulk export; long-lived static credentials in the model service; warehouse copies outside the production control baseline.

Outcome. Three findings changed the design before launch, which is the point of doing this early: precise GPS was removed as unjustifiable for underwriting; raw statement data moved to a 90-day expiry with only derived features persisted; and decline reason codes plus a documented human-review path were added. Two risks were accepted with residual medium ratings and dated review commitments. One — bulk-export alerting — was a launch blocker until implemented, because without it a breach could not have been scoped within the Section 8(6) intimation duty, which we discuss alongside CERT-In's six-hour reporting expectation.

DPIA vs VAPT vs Security Risk Assessment

These are complements. A DPIA without technical validation is an opinion; a penetration test without a DPIA tells you the door is locked but not whether you should be holding the contents.

Who Needs to Be in the Room

A DPIA fails when a single function owns it. Privacy alone cannot see the data flows; engineering alone cannot judge proportionality; legal alone cannot verify a control.

• DPO or privacy lead — owns the assessment and the risk framing against Data Principal rights.
• CISO and security — supplies tested control evidence and the threat view.
• Application and product owner — defends necessity, or removes the field.
• Engineering and architecture — describes actual flows, including the ones not in the diagram.
• Cloud and infrastructure — storage, IAM, logging, backups, retention mechanics.
• Legal — basis, notices, contracts, sectoral overlays such as RBI or SEBI requirements.
• Compliance and risk — scoring consistency and the acceptance threshold.
• Vendor management — processor terms, sub-processor control, transfer mapping.
• Internal audit — periodically, to test that the process is real.

Where DPIAs Usually Go Wrong

Operationalising It

A DPIA becomes real when it is a gate in a process someone already has to pass through. The lifecycle is Discover → Map → Assess → Mitigate → Approve → Monitor → Reassess, and it should be wired into existing controls rather than run beside them:

This is Privacy by Design and Secure by Design expressed as workflow rather than principle: the assessment happens where decisions are still cheap to change.

Pre-Production DPIA Checklist

The Point of the Exercise

A DPIA is not a regulatory document that happens to involve engineers. It is the one artefact that forces privacy, security, architecture, legal, compliance and the business to agree — in writing, before deployment — on what a system does to people and what the organisation is prepared to accept.

Under the DPDP Act the periodic DPIA is a Section 10 duty for Significant Data Fiduciaries, sitting in a penalty category of its own. For everyone else it remains the most efficient way to produce the evidence that Sections 8(5) to 8(7) assume you already have. Treated as a gate, it changes designs. Treated as a form, it changes nothing — and the risk it was meant to catch simply becomes a production risk instead.

How Adayptus Helps

Most organisations do not need a DPIA template; they need the technical work that makes one credible. We run DPDP readiness and DPIA engagements that start with data discovery and a Record of Processing Activities, then substantiate the control claims through actual testing — penetration testing, cloud security assessment, database review — and finish with a scored register and a remediation plan phased to your deadline.

Related capability: GRC advisory, ISO 27001 implementation, third-party risk management, AI governance and virtual CISO support. Related reading: why consent management is not DPDP compliance and the DPDP Rules 2025 roadmap to May 2027.

Frequently Asked Questions

Click any question to expand the answer.

References & Further Reading

1. Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) — full text, MeitY
2. Ministry of Electronics and Information Technology (MeitY)
3. Regulation (EU) 2016/679 (GDPR) — consolidated text, EUR-Lex
4. GDPR Article 35 — Data protection impact assessment
5. Article 29 Working Party — Guidelines on DPIA and determining whether processing is "likely to result in a high risk" (WP248 rev.01, endorsed by the EDPB)
6. European Data Protection Board — guidelines and recommendations
7. ICO — Data protection impact assessments
8. ISO/IEC 29134 — Guidelines for privacy impact assessment
9. ISO/IEC 27701 — Privacy information management system
10. ISO/IEC 27001 — Information security management systems
11. NIST Privacy Framework
12. NIST SP 800-53 Rev. 5 — Security and Privacy Controls
13. CERT-In — directions and advisories
14. Reserve Bank of India — regulatory framework

Statutory references in this article were taken from the text of the Digital Personal Data Protection Act, 2023 as published by MeitY. This article is provided for general information and does not constitute legal advice; obtain qualified counsel on the application of the Act, the Rules and any sectoral regulation to your specific processing.