What is ROPA? Record of processing activities under India's DPDP Act

A record of processing activities, or ROPA, is a structured register of every way your organisation handles personal data: what you collect, why, where it sits, who touches it, who you share it with, and how long you keep it.

Here is the part that trips most teams up. The DPDP Act and the DPDP Rules 2025 never use the word ROPA. The term comes from Article 30 of the GDPR. India's law borrowed the substance of the obligation without borrowing the label.

So the honest answer to "does the DPDP Act require a ROPA" is: not by that name, and not as a standalone duty written out for every data fiduciary the way GDPR writes it. But you cannot meet your DPDP duties without one. For Significant Data Fiduciaries, the case is stronger still.

Does The DPDP Act Actually Require A ROPA?

No provision in the Act says "maintain a record of processing activities." Several leading legal analyses confirm the DPDP Act does not impose a GDPR style Article 30 record on all fiduciaries.

The obligation is implicit, and it is unavoidable. Consider what a data fiduciary has to do under the Act:

• Process personal data only for a lawful, specified purpose, and not repurpose it without fresh consent.
• Keep personal data accurate, complete, and consistent where it is used to make decisions or is shared.
• Delete personal data once the purpose is served, under the erasure obligation in Section 8.
• Respond to a data principal who asks what personal data you hold and who you have shared it with.
• Notify the Data Protection Board and affected individuals after a breach.

You cannot do any of these reliably if you do not have a current record of what you process and where it lives. A ROPA is how you hold that record.

For Significant Data Fiduciaries, the requirement hardens. Under Section 10, an SDF must run periodic Data Protection Impact Assessments and independent audits. Both depend on a complete processing inventory. In practice, a ROPA is the document that feeds them. If you expect to be designated an SDF, treat the ROPA as part of your Significant Data Fiduciary obligations, not an optional extra.

There is also the enforcement reality. The Data Protection Board can ask you to demonstrate compliance during an investigation. The fiduciary that can produce a clean, current ROPA answer in days. The one that cannot start reconstructing its data estate under pressure, with penalties of up to ₹250 crore for certain violations sitting in the background.

What A DPDP ROPA Must Capture

There is no prescribed ROPA format in the Rules, so you have room to design one that fits your organisation. A workable DPDP ROPA record for each processing activity:

• The processing activity itself is named plainly (customer onboarding, payroll, marketing analytics).
• The categories of personal data involved (name, mobile, email, PAN, financial data, location.
• The categories of data principals (customers, employees, vendors, minors).
• The specific purpose of the processing.
• The lawful basis: consent, or one of the enumerated legitimate uses under Section 7.
• The source of the data, whether collected directly or received from a third party.
• Internal access: Which departments and roles can access the data.
• External recipients: every processor, partner, or vendor with whom the data is shared.
• Any transfers outside India, and the destination.
• The retention period for each purpose and the deletion trigger.
• The security measures protect the data.

Building this register is, at its core, a data mapping for a DPDPA compliance exercise. You cannot record processing if you have not located it first.

Where A DPDP ROPA Differs From A GDPR One

Copying a GDPR template is where most Indian ROPAs go wrong. Four differences matter.

No legitimate interest basis. GDPR lets a controller process on "legitimate interest." The DPDP Act does not. Processing rests on consent or on the specific legitimate uses listed in Section 7. A ROPA entry that records "legitimate interest" as its basis is non-compliant in India. Every consent-based activity needs a real consent basis behind it.

Consent traceability. A DPDP ROPA entry built on consent should link back to the consent record and the notice version shown to the data principal at collection. This is where the ROPA connects directly to what your consent notice must say under Rule 3. If the Board asks you to justify a processing activity, you should be able to produce the consent and the exact notice the person saw.

Language versions. Because the notice can be served in English or any of the 22 Eighth Schedule languages, the consent behind a ROPA entry may exist in several language versions. Your record should show which version was applied.

Erasure and retention. The DPDP storage limitation duty is firmer than many global programmes assume. Each ROPA entry needs a defined retention period and a working deletion path, not a vague "as long as necessary."

There is one more useful difference. The DPDP Act has no special category of sensitive data the way GDPR Article 9 does. Penalties instead scale with the harm caused, which depends on how sensitive the data is in context. Classifying your data by sensitivity inside the ROPA is good practice, even though the law does not name categories.

Why The Spreadsheet Approach Breaks

Most organisations start their ROPA in a spreadsheet. For a small business with 20 processing activities, that holds. For a mid-sized enterprise with 100-plus activities across dozens of systems, it stops holding fast.

Two problems surface. First, the spreadsheet is only as complete as what people remembered to declare. Automated discovery routinely finds a large share of processing activities that teams did not know existed: data on field agent laptops, in legacy databases, in shadow SaaS tools. A ROPA that misses them is confidently wrong.

Second, a ROPA is a living record, not a one-time project. Every new system, vendor, or data type should be updated before processing begins. A static sheet drifts out of date within a quarter, and a stale ROPA is worse than none, because it gives false assurance. This is part of why consent alone is not DPDPA compliance: the underlying record of what you actually hold has to be accurate and current, or everything built on top of it is unreliable.

How to build a DPDP ROPA before May 2027

Substantive DPDP obligations, including the SDF duties that lean on a ROPA, come into force on 13 May 2027. That is the build window. A practical sequence:

First, discover. Map where personal data actually lives across systems, endpoints, and vendors. Run automated discovery alongside stakeholder interviews so you catch what no one declares. Privy's data discovery and governance layer is built for this, and Data Compass by Privy scans Indian enterprise environments, including PII on laptops and field devices, to surface processing activities the business had lost track of. Second, document. Capture the fields above for each activity, with data owners signing off on their areas. Third, flag and connect. Mark activities that need a DPIA, a consent fix, or a processor agreement review, and run those in parallel. ROPA is also the input to a privacy impact assessment under the DPDPA. Fourth, keep it live. Wire ROPA updates into change management so a new system or vendor cannot go live without a corresponding entry.

Conclusion

The DPDP Act may not require a document called a ROPA, but it does require organisations to prove how personal data is collected, used, shared, retained, and protected. When regulators, auditors, customers, or the Board ask those questions, a complete and current Record of Processing Activities becomes the evidence that turns compliance from a claim into something demonstrable.

As organisations prepare for May 2027, the challenge is not creating a spreadsheet but maintaining an accurate view of personal data across systems, vendors, and AI-driven workflows. Privy by IDfy helps enterprises automate data discovery, data mapping, and privacy governance to build and maintain a living ROPA that stays current as the business evolves. If you're evaluating your organisation's DPDP readiness, data governance framework, or approach to building a Record of Processing Activities, we'd be happy to discuss it with you. Reach out at shivani@idfy.com.

FAQ

Does India's DPDP Act require a ROPA?

Not by name. The DPDP Act and DPDP Rules 2025 never use the term ROPA, and there is no standalone Article 30-style record duty for all fiduciaries. In practice, a ROPA is required because you cannot meet duties like purpose limitation, accuracy, erasure, rights fulfilment, and breach notification without one. Significant Data Fiduciaries need it to run their mandatory DPIAs and audits under Section 10.

What is the difference between an ROPA and a privacy notice?

A privacy notice is what you show the data principal at collection, governed by Rule 3. A ROPA is your internal register of all processing activities. The notice is outward-facing, the ROPA is inward-facing, and the two should be linked.

What should a DPDP ROPA contain?

Per processing activity: the activity, categories of personal data, categories of data principals, purpose, lawful basis (consent or Section 7 legitimate use), data source, internal access, external recipients, transfers outside India, retention period, and security measures.

Can I reuse my GDPR ROPA for DPDP?

Partly. The structure carries over, but you must remove "legitimate interest" as a basis, link entries to consent and notice versions, account for the 22 Eighth Schedule languages, and tighten retention and deletion. A direct copy will contain non-compliant entries.

When does this need to be ready?

Substantive DPDP obligations, including SDF duties, take effect on 13 May 2027. The ROPA should be complete and well-maintained well before then.