Record of Processing Activities (RoPA) Template for the DPDP Act
A Record of Processing Activities (RoPA) template for the DPDP Act: what to log for every place your company touches personal data, and why the DPDP Act expects it even without naming it.
A Record of Processing Activities (RoPA) is a structured log of every way your company processes personal data: what you collect, why, where it is stored, who it is shared with, and how long you keep it. The term comes from GDPR, and the DPDP Act does not use it or mandate a specific document by that name. But the Act's accountability expectations, and the practical reality of an audit, add up to needing exactly this artifact.
When the Board asks how a specific piece of data is handled, "let me check with engineering" is not an audit-ready answer. A current RoPA is.
What to log for every processing activity
- •Activity name and owner. A short label ("checkout payment processing", "AI-based recommendations") and the team or person responsible.
- •Data categories collected. Name, phone number, address, payment details, location, health data, and so on, itemised rather than grouped as "user data".
- •Purpose. The specific reason this data is processed, matched to the specific consent that authorises it under §6.
- •Legal basis. Consent, or one of the narrow "legitimate uses" under §7, if applicable.
- •Source. Where the data comes from: direct user input, a third-party integration, or inferred from other data.
- •Storage location and system. Which database, which region, and whether it crosses outside India.
- •Recipients and processors. Every vendor, analytics tool, or partner that receives this data, and under what contractual terms.
- •Retention period. The specific schedule for this data category, tied to Rule 8, and the erasure trigger.
- •Security measures. What protects this specific data flow: encryption, access controls, logging.
- •Cross-border transfer. Whether this data leaves India, and to which countries.
A worked example: two rows from a real RoPA
| Field | Row 1: Order fulfilment | Row 2: Marketing emails |
|---|---|---|
| Owner | Backend team | Growth team |
| Data categories | Name, address, phone, order history | Name, email, engagement history |
| Purpose | Deliver purchased goods | Promotional communication |
| Legal basis | Consent, itemised at checkout | Consent, itemised opt-in |
| Retention | 3 years post last activity | 2 years or until opt-out |
| Recipients | Logistics partner (contractual DPA in place) | Email service provider |
Notice these are two separate rows with two separate consent bases, even though both might originate from the same checkout flow. That separation is exactly what §6's itemised-consent requirement expects, and a RoPA is where you prove you built it that way.
Why a spreadsheet RoPA breaks down fast
The moment you ship a new integration or a new data field, a manually maintained spreadsheet goes stale, and nobody updates it under deadline pressure. This is the same problem every static compliance template has: it documents a moment, not a system. Privacy Labs generates this record automatically from a live discovery scan of your actual data flows, so it reflects what your systems do today, not what they did when someone last found time to update a spreadsheet.
A completed RoPA also tells you exactly which processing activities need a DPIA and which vendors need a tighter Data Processing Agreement. Run a free Compliance Score below to see how many undocumented processing activities your own systems currently have.
Frequently asked questions
Does the DPDP Act require a RoPA by name?
No. The term RoPA and the specific document format come from GDPR practice. The DPDP Act does not mandate a document by this name, but its accountability principle and the practical demands of an audit mean most companies need equivalent documentation to demonstrate compliance.
What is the difference between a RoPA and a DPIA?
A RoPA is an inventory: a record of every processing activity and its key facts (data, purpose, retention, recipients). A DPIA is an assessment: a risk analysis of one specific processing activity, evaluating potential harm and mitigations. A RoPA typically informs which activities need a DPIA.
How often should a RoPA be updated?
Ideally continuously, triggered by any new feature, vendor, or data field that changes what your company processes. In practice, manually maintained RoPAs are usually reviewed quarterly at minimum, which is also why automated, discovery-driven records are more reliable than spreadsheets.