RoPA DPDP Act: What Indian Companies Must Build in 2026

RoPA Under the DPDP Act: What Indian Companies Must Actually Build

By Yatin Chaudhary, SEO Specialist at ProtectComply · Last updated 5 August 2026 · 11 min read

Quick answer

Is RoPA mandatory under India's DPDP Act? Not by name — but effectively, yes.

The Act never uses the phrase "Records of Processing Activities." That is why almost every article on this topic answers "no, but it's good practice" and stops there.

That answer misleads people. The DPDP Act requires you to demonstrate compliance to the Data Protection Board on request. Demonstrating it means producing records of what you process, why, on what basis, shared with whom, and retained how long.

That artefact is a RoPA. The Act simply does not call it one.

So the real question is not whether you need one. It is whether the one you build survives contact with a regulator.

Why "not mandatory" is the wrong answer

Six obligations in the Act converge on the same artefact.

You must be able to demonstrate compliance. The Data Fiduciary is accountable under the DPDP Act and Rules, including for processing carried out by processors on its behalf. Accountability you cannot evidence is not accountability.

Your notice must itemise what you collect and why. Section 5 requires notice specifying the personal data and the purpose. You cannot write an accurate notice for data flows you have not documented — and an inaccurate notice is itself a contravention.

You must fulfil Data Principal rights within statutory timelines. When someone requests access, correction or erasure, you must find every instance of their data. Without a register mapping systems to activities, that is a search party rather than a process.

You must delete data when the purpose is served. Retention limits require knowing what you hold, why, and since when — per activity, not per organisation.

Significant Data Fiduciaries face heavier documentation duties. DPIAs and periodic audits both take a processing register as input. You cannot assess risk in activities you have not enumerated.

Consent must be purpose-linked. Consent obtained for a purpose you never documented is consent for nothing in particular.

Build the register once, properly, and it feeds all six.

What the phased timeline means for your deadline

The DPDP Rules were notified on 13 November 2025 via gazette notification G.S.R. 846(E). Commencement is staggered:

• Immediately on notification — Rules 1, 2 and 17–21: definitions, the Data Protection Board, transitional provisions
• After one year, 13 November 2026 — Rule 4, Consent Manager registration
• After 18 months, 13 May 2027 — Rules 3, 5–16 and 22–23, where the substantive operational obligations sit

The obligations that make a RoPA necessary land in that final tranche. Which sounds like plenty of runway until you attempt one.

A RoPA for a mid-sized organisation is not a two-week project. Discovery alone runs weeks. Reconciling what departments say they process against what systems actually contain is where schedules go. Then you have a living register that needs maintaining as systems change.

Start in early 2027 and you are building your foundational compliance artefact while enforcement is already live.

What goes into an Indian RoPA

Most templates online are lifted from GDPR Article 30 with "controller" swapped for "Data Fiduciary." That produces a document that looks correct and answers the wrong questions.

Processing activity name and identifier. One row per activity, not per system. "Customer onboarding KYC verification," not "MySQL cluster 3."

Business owner. A named person, not a department. Unowned rows go stale first.

Categories of personal data. With Indian identifiers called out specifically — Aadhaar number, PAN, ABHA ID, bank account, mobile, biometric.

Categories of Data Principals. Customers, employees, vendor staff, and critically children. The Act's children's-data obligations are among its strictest and cannot be applied to activities you have not flagged.

Purpose of processing. Specific enough to appear in a notice. "Business operations" is not a purpose.

Lawful basis. Consent, or the specific legitimate use relied upon. This is where GDPR templates break — there is no legitimate-interest catch-all in the DPDP Act.

Notice language coverage. Which Eighth Schedule languages the notice for this activity exists in. No GDPR RoPA has this field, and it is a live gap for most Indian organisations.

Consent artefact location. Where the timestamped proof of consent actually lives. If you cannot point at it, you cannot evidence it.

Recipients and processors. Every third party, with contract reference. Processor obligations flow through contract, so a row without one is exposure.

Cross-border transfers. Destination countries. The Rules use a blacklist model — transfers permitted except to restricted territories — but you still must know where data goes.

Retention period and deletion trigger. Not "as long as necessary." A period, and the event that starts the clock.

Security safeguards applied. Encryption, access control, logging — per activity rather than per organisation.

Withdrawal propagation path. When consent is withdrawn, which systems must update. This field does not exist in GDPR templates and it is the one most organisations cannot fill in.

Why spreadsheets fail an inquiry

Nearly every Indian organisation starts in Excel. It works until it doesn't, and it fails on four specific things.

They record what people remembered. A RoPA built from department interviews documents what teams believe they process. The shadow database from 2022, the S3 bucket taking a nightly export, the vendor integration predating the current team — none of it appears, because nobody thought to mention it.

They go stale immediately. Data estates change weekly. A register refreshed annually is wrong within a month of sign-off.

They have no audit trail. Asked when a record was created and by whom, "it's in version history somewhere" is not an answer.

They connect to nothing. Your RoPA claims consent as the basis for an activity. Does a consent artefact exist? Does the retention schedule match? In spreadsheets those live in separate files nobody reconciles.

An inaccurate RoPA is arguably worse than none — it documents, in writing, to a regulator, that you asserted something untrue about your own data.

How to build one that holds up

Discover before you interview. Scan systems first, then take findings to teams for confirmation. Interview-first produces a register of institutional memory. Discovery-first produces a register of reality, with interviews as verification.

Resolve systems into activities. Discovery yields tables and columns; a RoPA needs business activities. That resolution step is the hard part and the part most tooling skips.

Put a human in the loop. Anything auto-accepted into your register is something you are asserting to a regulator without having checked it.

Link rather than duplicate. Each activity should point to its consent basis, processor contract, retention rule and DPIA. A RoPA that links out becomes a control surface. One that restates everything becomes four documents that disagree.

Make it tamper-evident. Append-only or hash-chained logging makes the trail provable rather than asserted.

Assign owners and a review cadence. Quarterly for stable activities, on-change for anything touching new systems or vendors.

This is the sequence ProtectComply is built around — discovery into RoPA into DPIA, with a steward review queue so nothing enters the compliance record unreviewed, and a hash-chained ledger so the evidence holds when someone asks.

Five mistakes worth avoiding

1. One row per system instead of per activity. A single database supports many activities with different purposes, bases and retention rules. Collapse them and every downstream obligation inherits the error.
2. Copying a GDPR template unchanged. No legitimate-interest basis, plus Eighth Schedule language and withdrawal-propagation fields GDPR never needed.
3. Skipping employee data. HR processing is personal data processing, and it is routinely the largest undocumented estate in the company.
4. Treating it as a document rather than a system. Delivered as a PDF, a RoPA is already historical.
5. Building consent architecture first. Consent designed before the RoPA rests on assumptions about data flows that are usually wrong.

Frequently asked questions

Is RoPA mandatory under the DPDP Act?

Not by name — the Act never uses the term. But the obligations to demonstrate compliance, issue accurate notices, fulfil Data Principal rights within timelines and enforce retention limits cannot be evidenced without a processing register. Significant Data Fiduciaries, facing DPIA and audit obligations, need one more directly still.

What is the difference between RoPA and a data inventory?

A data inventory lists what data you hold and where. A RoPA documents processing activities — purpose, lawful basis, recipients, retention, safeguards. The inventory is an input; the RoPA is the compliance artefact.

How long does it take to build a RoPA?

Discovery-led with tooling: weeks. Interview-led in spreadsheets: a quarter or more, and usually incomplete, because it captures what people remembered rather than what systems contain.

Do small companies need a RoPA under DPDP?

Below a few hundred Data Principals you may manage without formal tooling. Beyond that it becomes an evidence problem rather than a policy problem — and evidence is what the Board asks for.

Does a RoPA have to be submitted to the Data Protection Board?

Not proactively. It is an internal record produced on request during an inquiry — which is exactly why it must be accurate and current rather than assembled under pressure.

What happens if our RoPA is inaccurate?

Worse than not having one. It documents that you asserted something untrue about your own processing. Penalties reach ₹250 crore for security safeguard failures, assessed per contravention rather than per organisation.

Is a RoPA the same under GDPR and DPDP?

No. GDPR Article 30 has no field for Eighth Schedule notice language or consent-withdrawal propagation, and it permits a legitimate-interest basis the DPDP Act does not. A GDPR template applied unchanged will be missing India-specific fields and will offer a lawful basis you cannot rely on.

Where to start

Run a gap analysis first — it tells you which obligations you already meet. Then discovery, then the register, then consent designed around what the register shows.

Not the reverse. Every stalled programme built consent first.

See how ProtectComply builds RoPA from real system discovery

About the author

Yatin Chaudhary is an SEO Specialist at ProtectComply, where he writes about India's data protection framework and how organisations operationalise it.

How this article was researched

Written against the text of the DPDP Act, 2023 and the DPDP Rules, 2025 as notified, and against ProtectComply's own implementation experience building processing registers from system discovery. Where the Act is silent — as it is on the term "RoPA" — we say so rather than overstating the obligation.

Corrections: if you believe anything here misstates the law, write to [corrections email] and we will review and update.

Sources

• Digital Personal Data Protection Rules, 2025 — gazette notification G.S.R. 846(E), 13 November 2025
• The Digital Personal Data Protection Act, 2023 — Sections 5, 8, 10, 11, 12, 13
• MeitY notification on staggered commencement, 13 November 2025

General information, not legal advice. Obligations vary by the nature and volume of processing. Consult qualified counsel before finalising your compliance position.