What Is a RoPA? Records of Processing Activities Under the DPDP Act

A RoPA (Record of Processing Activities) is a structured inventory of every activity in which an organisation processes personal data: what data, from whom, why, for how long, and who else touches it. Unlike the GDPR, the DPDP Act never uses the term RoPA and imposes no rule that names it directly. But four separate obligations in the Act are practically impossible to meet without one.

This is the gap in most DPDP compliance plans. Teams build a breach-notification runbook, schedule a DPIA, and appoint a grievance officer, then discover none of it works without an answer to a more basic question: what personal data do we actually hold, and where? A RoPA is that answer, kept current.

RoPA Meaning and Full Form

RoPA stands for Record of Processing Activities. It originates from Article 30 of the GDPR, which requires most controllers and processors to maintain a written record of their processing operations. The DPDP Act does not import the term or the article, but it converts the same underlying discipline into a practical necessity for four reasons.

Why the DPDP Act Needs a RoPA Even Without Naming One

Section 8(3) and 8(7)–(8): accuracy and erasure. A Data Fiduciary must ensure the personal data it processes is accurate and complete, and must erase it when consent is withdrawn or the specified purpose is fulfilled (or deemed fulfilled under Section 8(8)). You cannot act on either duty for data you cannot locate. A RoPA is the map that tells you where each category of data lives and when its retention clock runs out.

Rule 7: breach notification. When a personal data breach happens, Rule 7 requires you to notify affected Data Principals and the Data Protection Board describing the nature and extent of the breach, without delay, and to file a detailed report to the Board within 72 hours. Answering "what personal data was exposed, and whose" inside that window is a RoPA lookup if you have one, and a scramble through logs and emails if you do not.

Rule 13: the annual DPIA and audit. For Significant Data Fiduciaries, the Data Protection Impact Assessment and independent audit both start from the same first step: scope the processing. A RoPA is the input, not a by-product, of that step — teams that skip it end up rebuilding the inventory from scratch every twelve months instead of refreshing one.

Sections 11–13: Data Principal rights. When a Data Principal exercises the right to access, correction, erasure, or grievance redressal, you have a limited window to respond accurately across every system that holds their data. A RoPA that maps data categories to systems and processors is what makes that response possible instead of aspirational.

RoPA Under DPDP vs GDPR Article 30

Aspect	GDPR (Article 30)	DPDP Act
Legal status	Yes — an explicit written-record obligation	No — the term does not appear
Applicability	Controllers/processors above 250 employees, or where processing is not occasional, involves special categories, or risks rights	Not mandated by headcount or activity type; driven instead by Sections 8, 11–13 and Rule 7
Minimum fields	Purposes, categories of data subjects and data, recipients, transfers, retention, security measures	Not prescribed — organisations must infer the field list from what Sections 8, 11–13, and Rules 7 and 13 require them to answer
Regulator access	Yes, on demand	Not explicit, but its contents feed the Rule 7 breach report and Rule 13 DPIA/audit observations sent to the Board
Transfer log	A required RoPA field	Needed to support your cross-border transfer position under Section 16, even though no register is named

The practical takeaway: if you already run a GDPR-grade RoPA, keep it — the DPDP Act does not ask you to change the format. If you do not, do not wait for a DPDP-specific template to appear. None is coming, because the law was written around outcomes (accurate erasure, timely breach response, answerable rights requests), not around the document that produces those outcomes.

What a RoPA Should Contain

There is no prescribed DPDP schema, so build to the questions the Act actually asks. At minimum, capture one row per processing activity with these fields:

• Activity name and business owner — the team or product that runs it
• Data categories — what personal data is collected (and whether any of it concerns children, per Section 9)
• Source — collected directly, from a partner, or from a public source
• Purpose — the specified purpose stated in your consent or notice
• Lawful basis — consent, or the specific Section 7 legitimate use relied on
• Recipients and Data Processors — every vendor or internal team the data flows to
• Cross-border destinations — countries the data leaves India for, if any
• Retention period and erasure trigger — how long you keep it, and what event ends the purpose
• Security measures — the Rule 6 safeguards applied to this specific activity
• Related DPIA reference — link to the assessment that covers this activity, if one exists

A Worked Example: Three Rows From an Illustrative RoPA

Field lists stay abstract until you see them filled in. Here is what three rows might look like for a GRC SaaS company — call it Vratex — documenting its own processing. This is an illustrative example to show the shape of a real entry, not an actual company's published record.

Activity	Data Categories	Lawful Basis	Retention & Erasure Trigger
Customer account & billing	Name, work email, company, billing address, payment reference	Consent (Section 6) at signup	Active subscription term; erased 90 days after account closure (Section 8(7))
Product usage & support logs	Login activity, in-app actions, support tickets	Consent (Section 6), bundled with signup	12 months rolling — the Rule 6 minimum for detection and investigation logs
Employee payroll & HR records	Name, PAN, bank details, salary, attendance	Section 7(i) legitimate use — employment purposes	Employment term, plus statutory retention under applicable labour law

Three things to notice. First, the lawful basis is not uniform across a single organisation's RoPA — customer data usually rests on consent, while employee data more often sits on the Section 7(i) employment ground. Second, retention is tied to an event (account closure, end of employment), not a flat number of years, which is what makes the erasure obligation under Section 8(7)–(8) actually executable. Third, the log-retention row shows a case where a security requirement (Rule 6's one-year minimum) and a privacy requirement (do not keep data longer than needed) have to be reconciled in the same field rather than treated as separate problems.

How to Build One in Five Steps

1. List your systems, not your policies. Walk through every application, spreadsheet, and vendor tool that touches personal data — HRIS, CRM, support desk, analytics, payment processor, marketing tools. Policy documents describe intent; systems hold the actual data.
2. Interview the owners, not IT alone. IT knows where servers are. Product and HR teams know why the data was collected and whether the stated purpose still matches how it is actually used. Both perspectives are needed to fill the purpose and lawful-basis fields honestly.
3. Map every processor and sub-processor. For each system run by a vendor, confirm the contract reflects Data Processor obligations and note whether that vendor further engages a sub-processor. This is also where you flag anything crossing a border for the cross-border transfer picture.
4. Attach retention and erasure logic per activity, not per system. The same CRM might hold a lead record with a short retention window and a paying customer's record with a much longer one. Retention lives with the activity, not the tool.
5. Review on a cadence, and after every material change. Treat the RoPA as a living record: revisit it whenever a new product feature, vendor, or data flow launches, and at minimum on the same cycle as your DPIA and audit.

Who Should Own the RoPA

For a Significant Data Fiduciary, RoPA upkeep is one of the recurring duties that falls to the Data Protection Officer. For everyone else, ownership should sit with whoever is accountable for Section 8 compliance — often a compliance lead, general counsel, or CISO — with each system owner responsible for keeping their section of the record accurate.

Where Vratex Fits

A RoPA that lives in a spreadsheet goes stale the week someone forgets to update it. Vratex keeps your data inventory, retention triggers, and processor mappings as live records tied to the same risk register and audit trail that back your DPIA and breach response, so the record you show the Board is current by default, not by memory.