You cannot protect what you have not mapped. A Record of Processing Activities (ROPA) is that map: an inventory of what personal data an organisation handles, why, on what legal ground, with whom it is shared, where it travels, how long it stays and how it is secured. India’s Digital Personal Data Protection Act, 2023 (“DPDPA” or “Act”) never uses the word. Yet once its substantive duties under the DPDP Rules, 2025 (“Rules”) take effect on May 13, 2027, almost none of them can be met without one.
What the law requires?
There is no named ROPA in the DPDPA, but its obligations presuppose one. A Data Fiduciary must issue a notice itemising the personal data and purposes (section 5), prove that consent was given (section 6(10)), remain responsible for processing done on its behalf (section 8(1)), engage processors only under a valid contract (section 8(2)), apply reasonable security safeguards (section 8(5)), erase data once the purpose is served or consent is withdrawn (section 8(7)) and answer access, correction and erasure requests (sections 11-12). Significant Data Fiduciaries face periodic DPIAs and audits (section 10). Rule 8(3) requires every fiduciary to retain personal data, traffic data and processing logs for at least one year. Each of these duties needs the same underlying facts: what data, for what purpose, held where, shared with whom and for how long.
Three structural features shape an Indian ROPA:
- Only two grounds. There is no “contract” or “legitimate interests” basis. Processing rests on consent (section 6) or one of the legitimate uses in section 7. Every row must name one.
- No special categories. The Act protects all digital personal data alike, so sensitivity must be assessed on context. Children’s data is the exception, with its own regime under section 9.
- Open transfers, unless restricted. Cross-border transfers are permitted unless the destination is notified as restricted (section 16(1)), subject to stricter sectoral rules (section 16(2)).
Building a ROPA – 6 steps
- Own it. Appoint a ROPA owner (usually the DPO or privacy lead) and a contributor in each function.
- Interview by function, not by system. Ask HR, marketing, operations and support what they do with data; the systems follow.
- Record by processing activity. One row, one purpose. For example, “customer data” is not an activity but “order fulfilment” is.
- Tag the legal ground. Consent under section 6, or the specific clause of section 7 relied on.
- Anchor retention to a trigger. Cite the statute or the purpose-end event, never “as long as necessary”.
- Name the system of record. Each row should point to the databases and vendors holding the data, so rights requests and updates can run off it.
A template ROPA: the heads and how to fill them
Below are the heads a DPDPA-compliant ROPA should carry. Part A is completed once for the organisation. Part B is repeated for every processing activity. Under each head, “Record” says what goes in, and “Check” sets out the questions to ask when deciding what to put there.
Part A: Entity-level heads (completed once, at the top of the register)
1. Data Fiduciary details (section 2(i), section 8(9), Rule 9)
Record: Legal name and group entity; the person who answers data principals’ questions (DPO for an SDF); published business contact; grievance officer.
Check:
- Which entity actually determines purpose and means? In a group, each entity that does so is a fiduciary and needs its own register.
- Does the contact on the register match the one published on the website, app and in responses (Rule 9)?
2. Regulatory classification (section 10, section 17, Third and Fourth Schedules)
Record: Whether notified as a Significant Data Fiduciary; whether a Third Schedule class (e-commerce, online gaming, social media above the user thresholds); any exemption relied on; any sectoral regulator (RBI, SEBI, IRDAI).
Check:
- Check notifications, not assumptions. SDF status brings DPIAs, audits and an India-based DPO.
- Count registered users in India against the Third Schedule thresholds. If crossed, the three-year inactivity erasure rule applies.
- Record the specific clause for any section 17 exemption. A general “exempt” entry will not survive scrutiny.
3. Register governance (sections 8(1) and 8(4))
Record: ROPA owner, function contributors, version number, date of last review, approval.
Check:
- Can every row be traced to a named owner who attested to it?
- Is the review date within the last twelve months and after the last material change?
Part B: Activity-level heads (one row per processing activity)
4. Processing activity and specified purpose (sections 5(1) and 6(1))
Record: A verb-led activity (“payroll processing”, “order delivery”) and the specific purpose it serves.
Check:
- One purpose per row. “Customer data” is a dataset, not an activity.
- Does the purpose match, word for word, the purpose stated in the section 5 notice? If not, either the notice or the processing is wrong.
- Is any data reused for a second purpose? That is a new row and may need fresh consent.
5. Business owner and function (section 8(1))
Record: The team that runs the activity and its accountable lead.
Check:
- Interview the function, not IT. Ask what they do with the data, then trace the systems.
6. Categories of data principals (sections 2(j) and 9)
Record: Customers, employees, applicants, vendors’ staff, visitors, non-users (gift recipients, nominees, references). Flag children and persons with disability acting through a lawful guardian.
Check:
- Whose data enters without their own sign-up? They are still data principals with rights.
- Can a child reach this activity? If yes, flag it and complete head 10 below.
7. Categories of personal data and source (sections 3(a) and 8(3))
Record: Data fields grouped by type; source (directly from the principal, from a third party, generated, inferred); whether digital or digitised.
Check:
- Minimisation test: is each field necessary for the stated purpose? Strike out what is “nice to have”.
- Contextual sensitivity: the Act has no special categories, so mark financial, health, biometric, location or children’s data as high-risk on context.
- Is the data used to make a decision about the principal, or shared with another fiduciary? If so, the accuracy and completeness duties under section 8(3) attach.
8. Legal ground (sections 4, 6 and 7)
Record: Consent, or the precise section 7 legitimate use (e.g., section 7(a) voluntarily provided; section 7(d) legal obligation; section 7(i) employment).
Check:
- There is no “contract” or “legitimate interests” ground. If neither consent nor a named section 7 clause fits, the activity has no lawful basis.
- For section 7(a): did the principal provide the data voluntarily for this purpose without indicating non-consent?
- For section 7(i): is the processing genuinely for employment, or is it monitoring that needs consent?
9. Notice, consent and withdrawal record (sections 5, 6(4) and 6(10); Rules 3 and 4)
Record: Notice version; where and how consent was captured; consent manager (if any); withdrawal channel.
Check:
- Can you produce the consent artefact for any given principal? The burden of proof sits with the fiduciary (section 6(10)).
- Is withdrawal as easy as giving consent, and does it flow through to processors?
10. Children and guardianship (section 9; Rules 10 and 11; Fourth Schedule)
Record: Method of verifiable parental or guardian consent; whether tracking, behavioural monitoring or targeted advertising occurs; any Fourth Schedule exemption claimed.
Check:
- Is age verified or merely declared? Record the Rule 10 method relied on.
- Any analytics or ad SDK on a child-facing flow is a section 9(3) red flag.
11. Recipients (sections 8(1), 8(2) and 11(1)(b))
Record: Processors, other fiduciaries, group companies and authorities, with the data shared and the contract reference.
Check:
- Check vendor invoices and integrations against the list. Every paid tool that touches data is a candidate.
- Is each recipient a processor (contract required under section 8(2)) or a fiduciary in its own right? Record the role; do not assume it.
12. Systems of record and location (sections 8(7), 11 and 12)
Record: Applications, databases, shared drives and spreadsheets holding the data; hosting location.
Check:
- Could you find every copy of one person’s data from this head alone? If not, the row is incomplete.
- Include backups, exports and “shadow” spreadsheets.
13. Cross-border transfers (section 16, Rule 15)
Record: Destination country, recipient, data transferred, and any sectoral localisation rule.
Check:
- Is the country restricted by notification under section 16(1)?
- Does a stricter sectoral rule apply (e.g., RBI payment data localisation)? Under section 16(2), it prevails.
- Check vendor sub-processors and support access from abroad, not just hosting.
14. Retention and erasure trigger (sections 8(7) and 8(8), Rule 8)
Record: Retention period, the event that starts it, the legal basis for any longer hold, and the erasure method.
Check:
- Is the trigger an event (purpose served, consent withdrawn, account closed, statutory period ends) rather than “as long as necessary”?
- Third Schedule entities: three years from the principal’s last approach, with 48 hours’ notice before erasure.
- Rule 8(3) floor: personal data, traffic data and processing logs kept for at least one year.
- Does erasure reach processors?
15. Security safeguards (section 8(5), Rule 6)
Record: Measures protecting this activity: encryption, masking, tokenisation, access control, logging, backups.
Check:
- Does the measure answer the main risk of this row (e.g., masked phone numbers for couriers, tokens instead of card numbers)?
- Are logs retained for one year and reviewed? Rule 6 expects visibility over access.
16. Rights handling (sections 11-14, Rule 14)
Record: How access, correction, erasure, nomination and grievance requests are executed in the systems for this row; response timeline.
Check:
- Can the team for this row pull, fix and erase one person’s data within the published timeline (capped at 90 days for grievances)?
- Which rows must stop on consent withdrawal, and which may continue under a section 7 ground?
17. Risk, DPIA and breach history (sections 8(6) and 10; Rules 7 and 13)
Record: Risk rating; DPIA reference (mandatory for SDFs); past breaches and remediation.
Check:
- Is the activity high-risk on context (children, financial, health, large scale, profiling)? If so, prioritise its review.
- Did a past breach or rights request surface data this row missed? Update the row and note the cause.
No ROPA, no DSR
Under the DPDPA, a data principal’s request can be answered reliably only from a current ROPA. The rights are framed as outputs that a register produces:
- Access (section 11): The fiduciary must give a summary of the personal data processed and the processing activities, and the identity of every other fiduciary and processor it was shared with, along with what was shared. That is a ROPA extract for one person. Without the Recipients head, the answer is incomplete by definition.
- Correction and erasure (section 12): Erasure must reach processors too (section 8(7)). If a vendor is missing from the register, its copy survives and the fiduciary is in breach while believing it complied.
- Withdrawal of consent (sections 6(4)-(6)): Processing on that consent must stop, including at processors. Only a ROPA that tags each row with its legal ground shows which activities stop and which may lawfully continue under section 7.
- Nomination and grievances (sections 13-14): Rule 14 requires fiduciaries to publish response timelines, capped at 90 days for grievances. Nobody will be able to locate data system by system after a request arrives and meet this timeline.
- Keeping it current: when and how to update?
A ROPA should change whenever the processing changes, with a full review at least once a year.
When to update:
- Before launch: a new product, feature, SDK or purpose for existing data.
- At vendor onboarding or exit: any new processor, integration or service provider.
- On a change of data location: a new cloud region, or a country restricted under section 16.
- On legal change: new Rules, sectoral directions (RBI, CERT-In) or an order of the Data Protection Board.
- After an incident: a breach or rights request that surfaced data the register missed.
- On corporate events: mergers, acquisitions, restructuring or notification as a Significant Data Fiduciary.
- Annually: a full attestation by each function owner.
How to update:
- Build it into existing gates. Product launch checklists, procurement approvals and change tickets should not close until the ROPA row is added or amended.
- Version every change. Record the date, author, change and reason. A dated history is the best evidence of accountability.
- Reconcile against reality. Compare the register with vendor invoices, data-flow scans and the system inventory; gaps are unrecorded processing.
- Cascade the change. A new row or ground means updating the section 5 notice, consent flows, processor contracts and the rights-request runbook together.
- Test it. Run a dummy access request each quarter and check that the ROPA located every copy.
Conclusion
A ROPA is not paperwork. It is the organisation’s memory of its own data. Under the DPDPA, it is what lets a fiduciary answer a data principal in days rather than months, and the Data Protection Board with facts rather than hope. May 2027 is closer than it looks. Draw the map now, redraw it every time the ground shifts, and when the questions come you will not be searching for answers. You will be reading them off the page.
Author