At a glance
A Record of Processing Activities (RoPA) is the master map of what personal data your business handles: one row per activity, covering the data, its purpose, the lawful basis, where it came from, who it’s shared with, and when it dies. The DPDP Act never uses the word “RoPA” — but it demands things you can’t do without one: answering rights requests, scoping a breach, proving consent, deleting on schedule. This template is that map — and for Significant Data Fiduciaries, record-keeping stops being best practice and becomes obligation.
Educational resource only. This provides a template for a record of processing activities in line with India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice.
The situation
Every DPDP duty starts with the same unstated question: what data do you process, and why? A breach gives you hours to answer it; a rights request gives you days; an audit gives you no warning at all. Businesses that can answer keep the answer written down — that document is the RoPA, and this is a ready-made one.
What a RoPA is (and what DPDP actually requires)
A RoPA is one table with one row per processing activity — and under the DPDP Act it’s the practical backbone of accountability, not a named statutory form. The DPDP Act doesn’t mandate a document called a RoPA for ordinary businesses (the term comes from Europe’s GDPR). What the Act does is put the burden of proof on you — for consent, for purpose-limited use, for erasure once purposes end — and give people rights whose fulfilment requires knowing exactly where their data lives. Significant Data Fiduciaries go further: their notified obligations include audits and impact assessments that presuppose exactly these records. So: legally named for SDFs’ record-keeping in substance, best-practice for everyone else — and in either case, the single most useful compliance document you’ll maintain.
The template — copy and fill in
Copy the table below, add one row per processing activity, and keep it where your team can update it.
Record of Processing Activities
[Your Business Name] — maintained by [role], last reviewed [date].
| # | Processing activity | Personal data involved | Purpose | Lawful basis | Source | Shared with (processors / third parties) | Outside India? | Retention period / trigger | Security measures |
|---|---|---|---|---|---|---|---|---|---|
| 1 | [activity] | [data] | [purpose] | [basis] | [source] | [recipients] | [yes/no] | [period/trigger] | [measures] |
How to fill it in
Rows are activities, not systems — “customer onboarding,” not “the MySQL database.”
- [Processing activity]
- What it means: A business activity that uses personal data, described the way your team talks about it. One activity may span several systems; that’s still one row.
- Examples: Customer onboarding, order fulfilment, marketing emails, payroll, CCTV at premises, recruitment.
- [Lawful basis]
- What it means: Consent, or the specific legitimate use (Section 7) the activity genuinely runs on — per activity, not one blanket answer for the company.
- Examples: “Consent, at signup”; “employment purposes”; “legal obligation (KYC rules).”
- [Shared with] / [Outside India?]
- What it means: Every processor and third party touching the activity’s data, and whether any of it leaves India — the columns that answer a breach’s “who else has it?” and a rights request’s “who was it shared with?”
- Examples: “Cloud hosting (Mumbai region)”; “analytics tool (processes abroad)”; “courier partner.”
- [Retention period / trigger]
- What it means: When this activity’s data dies — kept consistent with your retention policy, which is this column expanded into a policy of its own.
- Examples: “Account closure + 30 days”; “statutory period per tax law.”
What this template doesn’t cover
The RoPA maps your processing — it doesn’t perform your other duties, and it isn’t legal advice. A filled RoPA doesn’t itself give notice, capture consent, or delete anything: it’s the index that makes those duties executable. It also doesn’t replace an SDF’s formal obligations — audits and Data Protection Impact Assessments are their own exercises, though they’ll lean on this record throughout. And a RoPA that isn’t maintained is a snapshot of a business that no longer exists — the review date at the top is part of the template for a reason.
FAQ
Is a RoPA legally required under the DPDP Act?
Not by that name for ordinary businesses — the term is GDPR’s. But the Act’s burden of proof and rights-fulfilment duties are practically unanswerable without processing records, and Significant Data Fiduciaries’ audit and assessment obligations presuppose them. Treat it as the working backbone of accountability.
How detailed should each row be?
Detailed enough that a new team member could answer “what do we do with customer data?” from the table alone. One row per activity, plain language, every column filled — precision beats volume.
Who should own the RoPA?
A named role — whoever owns privacy or compliance, or the founder in a small business. Ownership matters more than title: an unowned RoPA stops matching reality within months.
How does the RoPA relate to our retention policy and consent records?
The RoPA is the index; the others are depth. Its retention column summarises the retention policy’s schedule, and its consent-based rows point at wherever consent records live. Build the RoPA first — the rest hangs off it.