Record of processing activities template for DPDP and GDPR.
One inventory that answers GDPR Article 30 and the questions the DPDP Act assumes you can answer. Copy the columns into a spreadsheet and start with your five biggest processing activities.
What goes in a record of processing activities?
A record of processing activities lists, for each purpose you process personal data for: who is responsible, the purpose, the categories of people and data, recipients, transfers abroad, retention, and security measures. Those are the seven items GDPR Article 30(1) requires of a controller; this template adds the fields the DPDP Act makes necessary.
The DPDP Act has no Article 30. It does, however, require an itemised notice (section 5), put the burden of proving consent on you (section 6(10)), require erasure when a purpose ends (section 8(7)), restrict transfers by notification (section 16), and set security minimums in Rule 6. A record that cannot answer those questions leaves each of them to memory.
The columns, and which law asks for each
| Column | What to write | DPDP Act / Rules | GDPR |
|---|---|---|---|
| Ref | Unique ID for the activity, e.g. HR-01. | None | None |
| Processing activity | What happens, in plain words: “Payroll”, “Newsletter”. | None | None |
| Business owner | The person who can answer for it. | None | None |
| Fiduciary / controller and contact | Legal entity, DPO or contact person. | s.8(9) contact; s.10(2) DPO for SDFs | Art. 30(1)(a) |
| Purpose(s) | Each purpose on its own line, in the words of your notice. | ss.4–5 | Art. 30(1)(b) |
| Ground for processing | DPDP: consent (s.6) or the specific legitimate use (s.7). GDPR: the Art. 6 basis. | ss.4, 6, 7 | Art. 6 (not required by Art. 30, but reviewers ask) |
| Categories of Data Principals / data subjects | Customers, employees, prospects. Flag children. | s.9 (children) | Art. 30(1)(c) |
| Categories of personal data | Itemised. Flag GDPR special categories. | s.5 itemised notice | Art. 30(1)(c), Art. 9 |
| Source | Collected from the person, from a third party, or observed. | None | Art. 14 (transparency) |
| Systems and location | Where the data lives: application, database, region. | Rule 6 | None |
| Recipients and processors | Who receives it, and the contract reference for each processor. | s.8(2) processor contract | Art. 30(1)(d), Art. 28 |
| Transfers outside India / EEA | Country and safeguard. | s.16 | Art. 30(1)(e), Chapter V |
| Retention and erasure trigger | Period, and the event that starts it. | s.8(7); Rule 8 and Third Schedule; Rule 6(1)(e) one-year logs | Art. 30(1)(f) |
| Security measures | Short description, or a link to the control set. | s.8(5); Rule 6 | Art. 30(1)(g), Art. 32 |
| Notice version / consent record | Which notice version the consents point to. | s.6(10) burden of proof | Art. 7(1) |
| DPIA needed? | Yes / no, with the reference. | s.10(2) for SDFs | Art. 35 |
| Last reviewed | Date and reviewer. | None | None |
SDF means Significant Data Fiduciary. A dash means the column is good practice rather than a statutory item.
The template (controller or Data Fiduciary)
Tab-separated, with one worked example row. Paste it into cell A1 of a blank Google Sheet or Excel workbook and it lands in columns. Delete the example once you have written your own.
Ref Processing activity Business owner Fiduciary / controller and contact Purpose(s) Ground for processing Categories of Data Principals / data subjects Categories of personal data Source Systems and location Recipients and processors Transfers outside India / EEA Retention and erasure trigger Security measures Notice version / consent record DPIA needed? Last reviewed MKT-01 Marketing newsletter [Head of Marketing] [Company Pvt Ltd], [privacy@] Sending product news to subscribers DPDP consent s.6 / GDPR Art. 6(1)(a) Subscribers (adults only) Name, email, open and click events Collected from the person [Email platform], [region] [Email platform] (DPA ref [ ]) [Country], [safeguard] Until withdrawal; erased within [7] days of unsubscribing [Link to control set] Newsletter notice v[ ] No [date], [name]
The processor version (GDPR Article 30(2))
If you process personal data on behalf of customers, Article 30(2) asks for a shorter record per customer: who you are, whom you act for, what categories of processing you carry out, transfers, and security measures. Most SaaS companies need both records: one for their own processing, one for what they do for customers.
Processor name and contact Controller / Data Fiduciary on whose behalf Categories of processing Transfers outside India / EEA and safeguard Security measures Sub-processors
How to use this template
- Start from purposes, not systems. Ask each team what they use personal data for. Systems come second.
- Do the five largest activities first. Customer accounts, payments, marketing, HR and support usually cover most of the data.
- Link, do not copy. Point the processor column at the contract, and the security column at the control set, so the record does not go stale when those change. The DPDP data processing agreement template uses the same fields in its Annex 1.
- Make retention an event, not a number. “Two years after account closure” can be scheduled; “two years” cannot.
A spreadsheet records what people remember. Data discovery finds the personal data that is actually in your systems and maps the flows, which is how the gaps in a hand-built record usually surface. For the high-risk rows, continue into a DPIA using our free template, and for the law underneath, the DPDP Act guide.
More free templates: the full template library, including a 5×5 risk register, a record of processing activities, a vendor security questionnaire and a DPDP consent notice.
The things people ask us
What is a record of processing activities?
A record of processing activities (RoPA) is an inventory of every way an organisation uses personal data: the purpose, the people and data involved, who receives it, where it goes, how long it is kept and how it is protected. Article 30 of the GDPR requires one. Under the DPDP Act it is the practical way to meet duties that assume you know all of this.
Does the DPDP Act require a record of processing activities?
Not in those words. The DPDP Act has no equivalent of GDPR Article 30. But section 6(10) puts the burden of proving notice and consent on the Data Fiduciary, section 8(7) requires erasure when a purpose ends, and Rule 6 requires logs and safeguards. Each duty assumes an inventory of what you process and why.
Who is exempt from GDPR Article 30?
Article 30(5) exempts organisations with fewer than 250 employees, unless the processing is likely to result in a risk to people's rights, is not occasional, or includes special category or criminal offence data. Payroll and customer databases are not occasional, so in practice most small companies still need a record for their core processing.
How detailed should each entry be?
Detailed enough that a stranger could find the data and act on it. One row per purpose, not per system: a CRM serving sales and support is two activities with different grounds and retention. Itemise data fields rather than writing categories like 'contact information', because the DPDP notice has to itemise them anyway.
How often should the record be reviewed?
Whenever processing changes, and at least once a year. The events that should trigger an update are a new vendor, a new purpose, a new country of storage, a change to retention, or a new product feature that collects data. A record reviewed only before an audit is the most common reason it is wrong.
Can the RoPA double as the input to a DPIA?
Yes, and it should. The purposes, data categories, recipients, transfers and retention in the record are most of the description section of a data protection impact assessment. Keep the reference to the DPIA in the row so reviewers can move between the two.
Find the data the spreadsheet missed.
We run discovery against one data store live and compare what it finds with the record you brought.