At a glanceA 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 | Involves children’s/PwD data? | Purpose | Lawful basis | Source | Shared with (processors / third parties) | Outside India? | Retention period / trigger | Security measures |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | [activity] | [data] | [yes/no] | [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.”
[Your Business Name]
- What it means: Your business’s name, as it should appear at the top of your official processing record.
- Examples: “Acme Consulting Pvt Ltd.”
[role]
- What it means: Whoever owns and maintains this record, named by role so it survives staff changes.
- Examples: “Data Protection Officer”; “Head of Operations.”
[date]
- What it means: When this record was last reviewed and updated, so anyone reading it knows how current it is.
- Examples: “12 Aug 2026.”
[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.
[data]
- What it means: The specific personal data fields this activity touches, listed rather than summarised as “customer data.”
- Examples: “Name, phone number, delivery address”; “PAN, salary details”; “Aadhaar (masked).”
[Involves children’s/PwD data?]
- What it means: Whether this activity processes personal data of a child or a person with disability who has a lawful guardian. A “yes” triggers Section 9’s extra duties: verifiable parental/guardian consent, no tracking or behavioural monitoring, and no targeted advertising directed at them.
- Examples: “Yes, student sign-up flow”; “No.”
[purpose]
- What it means: The specific reason this activity uses that data, in plain language, matching what your notice or consent record says.
- Examples: “To fulfil and deliver the order”; “to run payroll and statutory deductions.”
[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).”
[source]
- What it means: Where this data actually came from, since not all of it comes directly from the person it’s about.
- Examples: “Directly from the customer”; “from a partner referral”; “from a public directory.”
[recipients], [yes/no]
- 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), No”; “analytics tool, Yes (processes abroad)”; “courier partner, No.”
[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.”
[measures]
- What it means: The actual safeguard protecting this activity’s data, specific enough to mean something if you had to explain it after a breach.
- Examples: “Encrypted at rest, access limited to the ops team”; “masked in all but one authorised system.”
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.