.svg){kind=small}
.png)
If you're a DPO, CISO, or privacy lead at an Indian enterprise, you have roughly 12 months to get your house in order under the DPDP Act.
You can’t do this without a Record of Processing Activities (ROPA).
This article is a quick primer on ROPAs under DPDP – what they are, why you need one, what they should contain and how to get started.
For a deeper dive (step-by-step creation, ROPA formats etc.), download our full playbook here.
What is a ROPA?
A Record of Processing Activities is a structured log of how personal data moves through your organization. It captures what data you collect, why you collect it, where it flows, and how it's protected.
The term comes from GDPR's Article 30, but the concept isn't actually tied to any single regulation.
The ROPA is basically a single source of truth for your data processing – regardless of whether you maintain it in a spreadsheet, a visual diagram, or a dedicated platform.
A ROPA, regardless of format, helps you answer 3 questions – what personal data you hold, where it sits, and what you're doing with it.
Is a ROPA mandatory under DPDP?
On paper: no. The DPDP Act and DPDP Rules never use or mention the term “ROPA”.
In practice: yes.
Data Fiduciary obligations/duties under the DPDP Act are impossible to comply without a ROPA
The 3 DPDP Duties You Can't Meet Without a ROPA
1. Duty of Accuracy (Section 8(3))
Under the DPDP, Data Fiduciaries must keep personal data complete, accurate, and consistent.
When a customer updates their phone number, that change must reflect across all downstream systems – your CRM, LOS, billing system, marketing tools, vendor systems.
Without a ROPA, you have zero visibility over where data lives - and therefore, cannot make accurate, consistent updates across all downstream systems.
2. Duty of Erasure (Section 12(3))
When a Data Principal withdraws consent, or when the purpose of processing ends, you must erase their data from all your systems.
So if you delete a user's data from your LOS but forget about the same data stored in a spreadsheet titled "Weekly_Report_Final_v2.xlsx" somewhere in your org Google drive, you haven't actually erased the data in compliance with the DPDP Act.
A ROPA acts as a checklist for full deletion – it tells you exactly which systems to hit when you receive a deletion request.
3. Breach Notification (Section 8(7))
If there's a personal data breach, you must notify the Data Protection Board and affected users within urgent timelines.
In the middle of a data breach incident, you don't have time to interrogate your IT team about what was on that server and which customer categories it affected.
With a ROPA, you get that answer fast. In case of a software based ROPA, you can get it near immediately.
What should your ROPA contain?
At minimum, capture these 10 fields for each processing activity:
- Processing activity / business process (e.g., customer onboarding, payroll)
- Data categories (e.g., name, PAN, Aadhaar, device data)
- Data principals involved (e.g., customers, employees, vendors)
- Purpose of processing (e.g., KYC, underwriting, marketing)
- Source of data (e.g., directly from Data Principal, from partner)
- Systems / storage locations (e.g., LOS, CRM, HRMS, S3 bucket)
- Vendors / processors (e.g., cloud providers, SaaS tools)
- Retention period or rule (e.g., 7 years from closure, 90 days from inactivity)
- Key safeguards / controls (e.g., encryption at rest, role-based access)
- Cross-border transfers (yes/no, which country)
You can add more later if you want - but this is a good baseline to start with.
Choosing the right ROPA format
Which team owns the ROPA?
Under the DPDP Act, the business as a whole is liable. So everyone has a stake in keeping the ROPA accurate.
DPO / Legal / Compliance:
- Define what the ROPA should contain and how it should be structured.
- Set the rules and thresholds (e.g., what counts as a processing activity).
- Ensure the ROPA meets DPDP expectations.
Product & IT:
- Identify where personal data flows and is stored.
- Confirm which data is collected, transformed, and shared in each system.
- Expose systems to any discovery or mapping tools.
Business teams:
- Decide what data is collected at which touchpoints. J
- Justify the purpose of collection.
- Make ROPAs and data flows simpler by stopping collection of unnecessary data.
In most organizations, the practical first step is to form a small privacy working group – one person from each of these areas.
Building your first ROPA: A 30/90-day approach
Here's a realistic starting plan for the next 90 days:
Next 30 days:
- Appoint a privacy working group
- List all major systems and vendors that touch personal data
- Define your ROPA fields (start with the 10-field baseline)
- Fill a manual ROPA for 3 – 5 critical processes (e.g., customer onboarding, HR/payroll, core lending operations)
Next 90 days:
- Extend coverage to remaining key processes
- Evaluate automated ROPA/data mapping tools if you process high data volumes or are classified as a Significant Data Fiduciary
Note: Expect a lot of friction. Business teams often collect more data than they need – and get defensive about it.
“We’ve always collected this and have to continue” they’ll say. Unfortunately a lot of these will not stand up to DPDP scrutiny.
It’s the job of the DPO/privacy/legal teams to be the persistent “villain” here.
Keeping the ROPA alive
A ROPA is only useful if it stays current. Your data collection processes will keep changing and your ROPA should change along with it.
You will need to set up “triggers” to ensure your organization keeps updating the ROPA.
Time-based triggers:
- Quarterly or half-yearly review: DPO + IT + business scan for changes in systems, purposes, vendors
- Annual deeper review: align with internal audits, revisit retention rules and minimization
Event-based triggers (via Privacy Impact Assessment):
- New system or major module that processes personal data
- New vendor or processor onboarded
- New product or business line launched
- Major change to an existing journey (e.g., new onboarding flow)
- Significant incident or breach (use the post-mortem to fix ROPA gaps)
Don’t aim for a perfect ROPA. Aim for a useful ROPA.
Even in the EU, after years of GDPR, most ROPAs are far from perfect. Yours doesn't need to be either.
What matters is that you have a defendable, reasonably complete view of your processing – and a realistic way to keep it updated.
If you can't rely on your ROPA in an audit or in the middle of a breach, it's not a complete ROPA yet.
You can get a more detailed version of this blog in our full ROPA Playbook
.avif)
.png)
