Consiva assembles your ROPA from things it actually observed: cookie and tracker scans, consent records, database discovery findings and your processor register. Every entry carries the source that produced it and the date it was last confirmed — so the register is auditable rather than merely present.
The standard ROPA is a spreadsheet. Someone builds it over three weeks by interviewing department heads, it is accurate on the day it is finished, and it begins decaying immediately. A new marketing tool is procured. A developer adds a column. A vendor is replaced. None of that reaches the spreadsheet.
The deeper problem is provenance. When an auditor asks how do you know this row is correct, the honest answer for most registers is “someone told us in March.” That is not a record; it is a recollection with formatting.
The DPDP Act does not use the term “Records of Processing Activities” and does not prescribe a ROPA format. GDPR Article 30 does; DPDP does not. Anyone telling you DPDP mandates a ROPA in a particular shape is importing GDPR.
What DPDP does require makes a processing register the practical way to satisfy it:
So: not a prescribed artefact, but the substrate almost every other obligation runs on.
From observed sources to a signable export — shown here as a workflow before the detail below.
This is the ROPA register. The two columns to look at are Source and Last Reviewed. Source records where the entry came from — a cookie scan, a consent purpose, a database discovery run, the processor register, or a manual entry someone made. Rows marked Manual are the ones resting on someone's word rather than an observation, and they are labelled so you can see how much of the register is in that state. The last row here is flagged as a gap — a system holding personal data with no declared purpose — surfaced rather than quietly listed, because an unattributed purpose is a Section 5 notice problem waiting to happen.
Per entry: the processing activity · personal data categories · declared purpose · lawful basis · systems · processors · retention position · source · last confirmed date · change history.
Per export: generation date, per-row attribution, and a coverage statement. Signable by the accountable owner.
Per gap: systems or data categories present in the evidence with no declared purpose, listed as open items with owners rather than omitted.
Every Consiva ROPA export carries a written statement of its own limits. This is deliberate and it is the part we would defend hardest.
Consiva observes what it is connected to. Data Discovery covers SQL Server, PostgreSQL and MySQL or MariaDB. It does not cover Oracle, MongoDB, Elasticsearch, unstructured file stores, SaaS applications without an integration, spreadsheets on laptops, or paper. Processing in those places is in the register only if someone entered it manually, and manual entries are labelled as such.
A manufacturing group with eleven subsidiaries maintains its ROPA as a spreadsheet, last fully refreshed fourteen months ago. During a customer's vendor-risk review the group is asked to evidence which systems hold employee personal data and for what purpose. Three of the systems named in the spreadsheet were decommissioned; two systems in active use are absent.
After connecting discovery to the four databases that matter and importing the processor register, the generated ROPA shows 63 entries, of which 41 are attributed to an observed source and 22 are manual. The manual 22 become the work queue: each gets an owner and a purpose, or gets confirmed as out of scope. The next vendor-risk review is answered from a dated export with attribution rather than from a spreadsheet nobody can vouch for.
Illustrative. Not based on a named Consiva customer.
Building a first ROPA is a project, not a configuration step. Most teams want it done with them once.
ROPA build-out engagement — Consiva connects the sources, runs the initial discovery, works through the gap queue with your business unit owners, and hands over a register your team maintains.
Managed Privacy Officer — ongoing: reviewing each cycle's changes, chasing gap owners, and keeping exports current.
Decision authority on purposes and lawful basis stays with you. Consiva does not make those determinations on your behalf.
Software that builds and maintains a Records of Processing Activities register — the inventory of what personal data an organisation processes, for what purpose, in which systems, shared with whom, and for how long. The distinction that matters is how entries get there: assembled from observed sources such as scans and database discovery, or typed in from interviews. Only the first can be tested.
Not by that name, and not in a prescribed format — that is GDPR Article 30. DPDP does not mandate a ROPA. But Section 8(1) makes you responsible for all processing undertaken by you or on your behalf, Section 5 and Rule 3 require an itemised description of personal data and purposes in your notice, Section 11 entitles a Data Principal to a summary of processing activities and who her data was shared with, and Rule 13(1) requires an annual DPIA and audit for Significant Data Fiduciaries. A processing register is the practical way to satisfy all of those. Treat it as necessary infrastructure rather than a named legal requirement.
It connects to sources that can observe processing — website and tracker scans, consent logs, database discovery, a processor register — correlates the findings into processing activities, and attaches your declared purposes. Each entry records which source produced it and when it was last confirmed. As scans and discovery runs repeat, the register updates and the changes are dated. Your team resolves gaps where a system holds personal data with no declared purpose.
The saving is less in the initial build than in the maintenance, which is where manual registers actually fail. A spreadsheet ROPA needs a periodic re-interview of every department; a generated one updates on the scan cycle and tells you what changed. The second saving is in responding to Section 11 requests and vendor-risk questionnaires, both of which become queries against the register rather than fresh assembly exercises.
Because a spreadsheet cannot answer the provenance question. When an auditor asks how you know a row is correct, "someone told us in March" is not a satisfying answer, and it is the only answer a spreadsheet supports. Generated entries carry a source and a confirmation date. The secondary reason is gaps: a spreadsheet only contains what someone remembered to add, whereas a generated register can surface a system holding personal data that nobody declared a purpose for.
Enterprise. The Pro plan explicitly excludes ROPA generation and Data Discovery. This is a scoping decision rather than an upsell: ROPA depends on database discovery, which requires credentials, a conversation with the systems owners and a classification review, and that is an implementation engagement rather than a self-serve feature.
Enterprise plan — connects to your databases, scans and processor register to generate a register you can defend.