ROPA Under DPDP: Map Every Data Flow Before Someone Else Does

ConsentifyAI Team18 May 20264 min read

TL;DR

Unlike the GDPR, the DPDP Act does not explicitly require a Record of Processing Activities. But without one, you cannot write itemised notices, tell individuals who received their data, erase it on time, scope a breach within 72 hours, or prove compliance. A DPDP ROPA records each processing activity's purpose, data, individuals, lawful basis, systems, recipients, transfers, retention and safeguards. It is the foundation every other DPDP control is built on.

Who this is for: DPOs, privacy and compliance leads, and engineering managers who need a reliable picture of what personal data their organisation holds, and why.

Ask most organisations what personal data they hold and you will get a confident answer. Ask them to list every system it sits in, every vendor that receives it, the legal basis for each use and when each category is deleted, and the confidence usually disappears.

That gap matters under the DPDP Act. When a customer asks who you shared their data with, when a breach forces you to identify affected individuals within hours, or when the Data Protection Board asks you to prove a consent, the answer has to come from somewhere. That somewhere is a Record of Processing Activities (ROPA). This guide explains why it matters under DPDP, what to record, and how to build one that stays accurate.

Does the DPDP Act require a ROPA?

Not explicitly. Unlike Article 30 of the GDPR, the DPDP Act contains no standalone obligation to maintain records of processing. But look at what the Act and Rules do require, and a ROPA becomes the only practical way to comply:

Obligation	What it requires	Why you need a ROPA
Itemised notice (Section 5, Rule 3)	An itemised description of the data and each specified purpose	You cannot itemise what you have not inventoried
Access right (Section 11)	The identities of all fiduciaries and processors you shared data with	Requires a maintained map of recipients
Erasure and retention (Section 8(7), Rule 8)	Erasure when purpose ends; one-year minimum for logs; Third Schedule limits	Requires a retention period and trigger for each purpose
Breach reporting (Section 8(6), Rule 7)	Notify affected individuals without delay; detailed report in 72 hours	You must know quickly whose data was in the affected system
Burden of proof (Section 6(10))	Prove notice and consent were given for each purpose	Purposes must be defined consistently before consent can be tied to them
Security safeguards (Section 8(5), Rule 6)	Safeguards appropriate to the data processed	You cannot protect data you do not know you have
SDF obligations (Section 10, Rule 13)	Annual DPIA and audit	Both start from an accurate processing inventory

In short, the ROPA is not an extra compliance task. It is the foundation the other tasks are built on.

What a DPDP ROPA should record

Record each processing activity, meaning a distinct purpose for which personal data is processed, such as "payroll", "order fulfilment" or "WhatsApp marketing". For each one, capture:

Field	What to record	DPDP relevance
Activity and purpose	A specific, plain-language purpose	Section 5 and 6: purpose must be specified
Business owner	The function and person accountable	Ownership of controls and requests
Data Principals	Customers, employees, applicants, children, and so on	Children's data triggers Section 9
Personal data items	Itemised fields, not "customer data"	Rule 3 itemised notice; data minimisation
Source	Collected directly, from a partner, from a public source	Notice and lawful-basis checks
Lawful basis	Consent (Section 6) or a specific legitimate use (Section 7)	Determines rights and withdrawal handling
Notice and language	The notice version and languages used	Section 5, Section 6(3), Section 6(10)
Systems	Applications, databases and storage locations	Breach scoping, erasure, security
Processors and recipients	Vendors, partners, group companies, authorities	Section 8(2) contracts; Section 11 access disclosure
Cross-border transfers	Destination countries and the reason for transfer	Section 16 restrictions; sector localisation rules
Retention	Period, trigger and erasure method, plus any legal hold	Section 8(7), Rule 8 and other laws
Security safeguards	Encryption, access control, logging, backups	Section 8(5), Rule 6
Role	Fiduciary or processor for this activity	Determines who carries the obligations

Here is what a single entry looks like:

Field	Example
Activity and purpose	Sending order updates and delivery notifications by SMS and WhatsApp
Business owner	Head of Customer Experience
Data Principals	Customers (adults)
Personal data items	Name, mobile number, order ID, delivery address
Lawful basis	Section 7(a): data voluntarily provided to receive the order
Systems	Order management system, messaging platform
Processors	WhatsApp Business solution provider; SMS gateway
Cross-border transfers	None
Retention	3 years after last order, then automated erasure; logs 1 year
Safeguards	Encryption at rest, role-based access, API logs retained 1 year

How to build a ROPA in six steps

Start from the business, not the systems. Interview each function, such as sales, marketing, HR, finance, support and product, about what they do with personal data and why. Purposes come from people, not databases.
Validate against systems. Cross-check interview answers against your application inventory, data warehouse, cloud storage and SaaS tools. Shadow IT and forgotten spreadsheets are where most surprises are found.
Add vendors and data flows. List every processor and recipient for each activity, using procurement and finance records to find tools that were bought without review.
Assign a lawful basis. For each activity, decide whether it relies on consent or a specific legitimate use. Activities that fit neither must be redesigned or stopped.
Set retention. Give each activity a retention period, a trigger and an erasure method. Where another law requires retention, record that law.
Assign owners and review dates. Every activity needs an accountable business owner and a next review date.

Keeping it alive

A ROPA that is accurate on the day it is finished and wrong six months later is worse than useless, because people will rely on it. Build updates into existing processes:

New product or feature: privacy review updates the ROPA before launch.
New vendor: procurement cannot approve a tool that processes personal data without a ROPA entry.
New purpose: a change of purpose triggers a new entry and, where needed, new consent.
Annual review: each owner confirms or updates their activities. For Significant Data Fiduciaries, align this with the annual DPIA and audit under Rule 13.

Common ROPA mistakes

Recording systems instead of purposes. "Salesforce" is a system. "Lead nurturing emails" is a purpose. The Act regulates purposes.
Vague data categories. "Customer data" cannot support an itemised notice.
A one-off spreadsheet. If updating the ROPA is not part of change management, it will drift out of date.
Ignoring employees and vendors. HR and vendor-contact data are personal data too.
No retention trigger. "5 years" without a start date cannot be automated.

How ConsentifyAI helps

ConsentifyAI's ROPA module gives you a structured, maintained Record of Processing Activities, not a spreadsheet. Each activity captures purpose, data items, Data Principals, lawful basis, systems, processors, transfers and retention in a DPDP-specific format. Because the same records power ConsentifyAI's notices, consent capture and rights requests, your ROPA stays connected to what your systems actually do, and becomes the evidence base for audits and breach response.

Sources & references

DPDP Act, 2023 — Section 5
DPDP Act, 2023 — Section 6(10)
DPDP Act, 2023 — Section 8(5), 8(6), 8(7)
DPDP Act, 2023 — Section 10
DPDP Act, 2023 — Section 11
DPDP Rules, 2025 — Rules 3, 6, 7, 8, 13

Frequently asked questions

Is a ROPA mandatory under the DPDP Act?

The Act does not explicitly require one, unlike Article 30 of the GDPR. But several obligations, including itemised notices, the access right, retention limits, breach reporting and the burden of proving consent, are very difficult to meet without one.

What should a DPDP ROPA include?

For each processing activity: purpose, categories of personal data and individuals, lawful basis, source, systems, internal owner, processors and recipients, cross-border transfers, retention period and trigger, and security safeguards.

Can we reuse our GDPR ROPA?

As a starting point, yes. You will need to add DPDP-specific fields, such as consent versus legitimate use under Section 7, children's data, Eighth Schedule notice languages and retention rules from the Rules.

How often should a ROPA be updated?

Continuously, triggered by new products, vendors and purposes, with a full review at least annually. Significant Data Fiduciaries should align it with their annual DPIA and audit cycle.

Who should own the ROPA?

The DPO or privacy lead should own it overall, with each processing activity owned by the business function that runs it.