The CIO’s DPDP To-Do List: Data Governance Systems Your Organisation Needs Before the Next Audit

The DPO asks the CIO to produce a complete inventory of every system holding Aadhaar numbers. The answer takes six weeks. This is the DPDP gap between IT and compliance — and it is the CIO's problem to solve.

Five governance systems DPDP requires

The DPDP Act and Rules do not prescribe specific software. But the obligations they create cannot be met without certain governance capabilities in place. For the CIO, these translate into five systems that must exist — whether built, bought, or assembled from existing tools.

• ROPA system-of-record. Not a spreadsheet. A queryable, version-controlled register of every processing activity — what data is processed, why, under what lawful basis, who the processors are, and what the retention periods are. The ROPA must be updated when processing activities change, and the update history must be auditable. A spreadsheet shared via email fails on every one of these requirements.
• Consent management store. A database-backed, queryable system that records who consented, to what processing purpose, when, via which notice version, and the current status of that consent. When a data principal withdraws consent, the system must be able to identify the withdrawal, propagate it to downstream processing systems, and log the cessation of processing. Paper forms and PDF archives do not meet this standard.
• Evidence vault. A centralised, access-controlled repository for compliance evidence — policies, audit reports, configuration screenshots, penetration test results, vendor certifications. Evidence must be linked to the controls it supports, date-stamped, and tamper-evident. Scattering evidence across email attachments, SharePoint folders, and local drives makes it impossible to produce a coherent evidence package on demand.
• Policy registry. A version-controlled store of all data protection policies — privacy policy, data retention policy, breach notification procedure, consent management procedure, vendor management policy. Each policy must have a version history, an owner, a review date, and an approval trail. The registry must be the single source of truth — not a folder of Word documents with filenames like "Privacy_Policy_v3_FINAL_v2.docx."
• Retention enforcement. Automated jobs that identify personal data past its retention period, execute the defined action (deletion or anonymisation), and log the execution with timestamps, record counts, and exceptions. The execution logs are the evidence that retention obligations are being met. A policy that says "data will be retained for 7 years" without an automated enforcement mechanism is a statement of intent, not a control.

The shadow data problem

BFSI organisations typically have three to five times more systems holding personal data than are documented in any formal inventory. This is the shadow data problem — and it is the single largest obstacle to DPDP compliance for most CIOs.

The documented systems are obvious: core banking, CRM, loan origination, mobile banking app. But personal data also lives in middleware integration layers that cache customer records, business intelligence tools where analysts have downloaded customer segments, developer staging environments seeded with production data, email archives containing customer correspondence, shared drives where relationship managers store KYC documents, and analyst workstations with local Excel exports.

Each of these is a system holding personal data. Each should appear in the ROPA. Each is subject to retention, access control, and security obligations under the Act. And most CIOs do not have a complete inventory of them.

Data discovery is not a one-time project. New systems are deployed, new integrations are built, new data flows are created. The CIO needs a repeatable discovery process — ideally automated — that identifies where personal data resides across the technology estate and flags new data stores as they appear.

The practical approach is to start with the systems you know, document them in the ROPA, and then systematically expand through network scanning, database profiling, and API inventory. Every system discovered adds to the ROPA and brings the organisation closer to a complete picture of its personal data landscape.

Prioritisation for CIOs

The list of governance capabilities required is long. CIOs need to prioritise based on what delivers the most compliance value fastest — and what is most likely to be asked for in a regulatory inquiry.

First: connect the IAM platform. Identity and access management evidence is required for almost every compliance control — who has access to what data, are privileged accounts controlled, is MFA enforced, are access reviews conducted. If your IAM platform (Active Directory, Okta, Azure Entra ID) can export configuration and audit data into your compliance evidence vault, you cover a significant portion of the evidence requirement in a single integration. This is the highest-leverage first step.

Second: document cloud storage against retention policies. Most personal data at rest lives in databases and object storage (S3, Azure Blob, GCS). Mapping these storage locations to ROPA processing activities and tagging them with retention periods creates the foundation for automated retention enforcement. Without this mapping, retention policies are unenforceable.

Third: wire audit logs into the compliance evidence vault. Application audit logs, database access logs, and infrastructure logs are compliance evidence. But only if they are collected, retained, and accessible. Configure log aggregation to feed into the evidence vault with appropriate retention — most compliance frameworks require 12 to 24 months of log retention. This turns an existing operational capability into compliance evidence.

Integration vs. new systems

Most CIOs do not need new systems to achieve DPDP compliance. They need a documentation and governance layer that connects to what already exists.

The IAM platform already exists. The database infrastructure already exists. The audit logging already exists (in most organisations). The cloud infrastructure already exists. What is missing is the compliance context — the layer that connects these systems to ROPA processing activities, maps them to DPDP obligations, and produces evidence that controls are functioning.

This is a governance integration problem, not a greenfield build. The CIO's role is to ensure that existing IT systems can export the data compliance teams need, in formats that are structured and queryable, at intervals that are useful (not annual snapshots, but continuous or at least quarterly).

Where new capabilities are genuinely needed — consent management, for example, if no system exists — the CIO should evaluate platforms that integrate with the existing stack rather than building standalone tools. Every standalone tool creates another data silo, another integration to maintain, and another system that the compliance team must learn. The goal is fewer systems, better connected.