1) Data Inventory (what data, about whom, and where)
Include fields that let you answer: “What personal data do we process in this activity, for which data principals, and in which systems?”
Minimum fields to include: data principal group(s), personal data categories, high-risk tags (for example, financial identifiers/children), source channels (web/app/call center/partner), primary systems of record, secondary systems (exports/data lake), and storage/hosting notes.
Why it matters under DPDP: you can’t reliably provide accurate notice, meet storage limitation, handle rights requests, or scope a breach without knowing what data exists and where it lives.
Under DPDP, a “Data Inventory” isn’t just a list but a dynamic map of digital personal data.
- The “Digital” Filter: Explicitly note that DPDP only applies to data collected digitally or digitized subsequently. Physical paper records that stay physical are out of scope (unlike GDPR).
- Data Categorization: You must track specific identifiers mentioned in the 2025 Rules, such as Device IDs, IP addresses, and User Account handles, as these are now explicitly classified as personal data.
- Source Tracking: Distinguish between data collected directly from the Principal versus data received via a Consent Manager.
2) Purpose & Lawful Basis (why you process and on what grounds)
Include fields that let you answer: “What is the specific purpose of this activity, and what is the permitted ground (consent vs legitimate uses or other applicable ground) supporting it?”
Minimum fields to include: purpose statement (specific and notice-ready), sub-purposes (if needed), permitted ground, consent capture reference (if consent), and withdrawal impact notes (what stops, what continues, what must be deleted).
Why it matters under DPDP: DPDP’s compliance posture is purpose-tied and transparency-led, and the Rules emphasize clear notices and accountable processing. Recording purpose and grounds at the activity level prevents vague, overbroad processing claims.
Purpose & Lawful Basis is the most sensitive area for Indian compliance.
- The “Legitimate Use” Sandbox: Unlike GDPR’s broad “Legitimate Interests,” India’s Section 7 is a closed list (e.g., medical emergencies, employment, state functions). If a use case doesn’t fit Section 7, it must have consent.
- Itemized Mapping: Your RoPA must link every data element to a specific “itemized” purpose. Bundled purposes are a high-risk area for the Data Protection Board (DPB).
3) Third‑Party Transfers (vendor sharing, intra‑group, and cross‑border)
Include fields that let you answer: “Who receives personal data from this activity, what do they do with it, and where is it accessed or stored?”
Minimum fields to include: recipient type (processor/partner/affiliate), vendor name, purpose of sharing, transfer mechanism (API/batch/manual), onward transfers (if known), cross-border storage/access indicator, and contract status (DPA in place, renewal date, risk tier).
Why it matters under DPDP: vendors are where enterprise risk concentrates. RoPA is the most efficient place to maintain “who we share with” per activity so notices, contracts, and breach response stay consistent. The Rules also address cross-border transfer and breach communication expectations.
The DPDP Act places vicarious liability on the Data Fiduciary.
- The Negative List: While the government allows global transfers by default, the RoPA must flag any country on the “Negative List” (to be notified in 2025/26).
- Contractual Enforcement: The RoPA should record the date of the Data Processing Agreement (DPA) and confirm it includes the mandatory “Right to Audit” and “Erasure Instruction” clauses.
4) Retention & Deletion (storage limitation you can execute; The “48-Hour” Rule)
Include fields that let you answer: “How long do we keep the data, what triggers deletion, and where is it enforced?”
Minimum fields to include: retention period, retention trigger (account closure, last transaction, last login), deletion method (automated job/manual SOP), enforcement system (where it is configured), exceptions (legal hold, disputes, statutory requirements), and archival approach.
Why it matters under DPDP: the DPDP Rules introduce mechanisms/schedules linked to when a specified purpose is deemed no longer served, making retention decisions and execution more concrete. Without retention/deletion fields, RoPA cannot drive storage limitation in real systems.
The 2025 Rules introduced specific timelines that are stricter than most global standards.
- Deemed Cessation: If a user is inactive for a specific period (e.g., 3 years for large e-commerce/gaming platforms), the purpose is “deemed” fulfilled.
- Pre-Deletion Intimation: The RoPA must track the workflow for the 48-hour notice required before erasing data due to purpose fulfillment.
- The 1-Year Log Rule: Even if personal data is deleted, Rule 6 requires you to retain processing/traffic logs for at least 1 year for security investigations.
5) Security Measures (reasonable safeguards, proportional to risk)
Include fields that let you answer: “What controls protect this activity’s personal data, and are they proportionate to the data risk?”
Minimum fields to include: access model (RBAC, least privilege), authentication baseline (MFA), encryption at rest/in transit, logging/monitoring, admin access controls, data export controls, and vendor security expectations. For high-risk activities, add step-up controls (tokenization, stricter approvals, enhanced monitoring).
Why it matters under DPDP: the Rules emphasize “reasonable security safeguards” and require clear communication to affected individuals after a breach, which is much easier when safeguards and system ownership are already mapped per activity.
Security is now a “Reasonable Safeguard” mandate with a ₹250 Crore penalty for failure.
- Technical Controls: Your RoPA should map processing activities to specific controls: Encryption (at rest/transit), MFA, and Data Masking.
- Reporting Readiness: Link the RoPA to your Breach Notification Plan. Under the 2025 Rules, you have 72 hours to notify the DPB and the affected individuals.
Comparison of RoPA Requirements: GDPR vs. DPDP 2025
| Feature | GDPR RoPA (Art. 30) | DPDP 2025 RoPA |
| Trigger | Generally 250+ employees | All Fiduciaries (except small MSMEs) |
| Child Data | 13–16 age threshold | Strictly under 18 + Verifiable Consent |
| Lawful Basis | Includes “Legitimate Interest” | Limited “Legitimate Use” only |
| Deletion | “As soon as possible” | Mandatory 48hr notice before erasure |
| Logs | Best practice | Mandatory 1-year retention |
RoPA Implementation Checklist
| Phase | Action Item | Priority |
| Discovery | Use automated tools to find “shadow data” in legacy systems. | High |
| Notice Alignment | Ensure every entry in RoPA has a corresponding “Itemized Notice” version. | Critical |
| Processor Audit | Verify that all Data Processors have an erasure mechanism that follows your instructions. | High |
| Maintenance | Update the RoPA every time a new product feature or API is launched. | Ongoing |
Frequently Asked Questions about RoPA Components under DPDP Act India
What is a data inventory in the context of DPDP RoPA, and how is it different from a system inventory?
A data inventory, within RoPA, records what personal data categories are processed, about which data principal groups, through which channels, and in which systems — all tied to a specific business activity. A system inventory (typically maintained by IT in a CMDB) lists applications and infrastructure but does not capture purpose, data principal context, or retention. Think of it this way: a system inventory tells you “Salesforce exists”; a RoPA data inventory tells you “Salesforce stores prospect names, emails, and phone numbers collected via the website lead form for the purpose of sales outreach, owned by the revenue team, retained for 24 months after last engagement.” Both are useful, but only the RoPA version supports DPDP compliance operations like notice accuracy, breach scoping, and rights fulfilment.
Do we need to list every single data field in our RoPA, or can we use categories?
Categories are sufficient and, for most enterprises, more sustainable. The goal is not to replicate a database schema but to capture meaningful groupings that support compliance decisions. For example, “contact details (name, email, phone)” and “government-issued identifiers (PAN, Aadhaar where applicable)” are useful categories because they carry different risk levels and different retention and security implications. If a specific field carries unusual sensitivity or triggers additional obligations (for example, biometric data or children’s data), call it out explicitly even within a broader category.
How do we handle shadow IT and undocumented data stores in RoPA?
This is one of the most common enterprise challenges. The honest answer is: RoPA will surface shadow IT, and that is a feature, not a bug. During workshops, ask business owners not just “which approved systems do you use” but “where else does this data end up — spreadsheets, shared drives, personal email, WhatsApp groups, local exports?” Then record those as secondary stores in RoPA with a remediation flag. Over time, RoPA becomes the mechanism that brings shadow processing into governance rather than pretending it doesn’t exist.
Should employee and contractor data be included in the data inventory, or is RoPA only for customer data?
Employee and contractor data must be included. This is one of the most frequently missed areas in enterprise RoPA programs. HR processing — recruitment, onboarding, payroll, performance management, background verification, exit — involves large volumes of sensitive personal data including financial identifiers, health information (in some cases), and government IDs. Under DPDP, employees are Data Principals with the same rights framework. Ignoring employee data creates a significant compliance and audit gap.