Beyond the DPDP Checklist: Can Management Trust the Personal Data Processing Reality?

A Foundation Layer research note on whether visible DPDP compliance can be relied upon without a reliable view of the personal-data processing reality underneath it.

India’s DPDP implementation discussion is moving from awareness to execution. EY India’s January 2026 readiness research, based on more than 150 professionals across sectors, reported that nearly 48% of organisations had initiated gap assessments, around 44% had documented data-processing activities, and close to 38% had categorised personal data and identified third-party processors. The same research also reported that more than 83% had not yet begun comprehensive implementation of the Act’s requirements.

These numbers do not prove that organisations are unprepared. They show something more useful: different parts of readiness are moving at different speeds.

One organisation may have completed a policy review but still be mapping processing. Another may have identified processors but may not yet have validated retention. A third may have built a rights workflow but may not know whether the workflow reaches email, branch files, backups, archives and processor-held copies.

This creates a management question that is deeper than the checklist:

Can management make a reliable DPDP readiness statement if it does not have a reliable view of the actual personal-data processing reality underneath the policies, systems, processors, locations, backups, retention practices and rights workflows?

This is InfraVeritas360’s question.

Declared compliance and processing reality

DPDP readiness is often visible through the upper layer: notices, consent language, policies, contracts, governance documents, grievance procedures, rights processes, security safeguards and management approvals. These are necessary. They are also the layer most easily presented to management.

But the organisation operates one level below them.

Personal data may be collected through a website, mobile application, branch form, employee process, CCTV system or third-party channel. It may then move into CRM, ERP, email, cloud storage, analytics, backups, archives, SaaS platforms, payment systems, processors and local files. It may be copied, transformed, exported, retained or deleted at different times by different teams.

The policy layer describes what should happen. The Processing Reality Layer asks what is actually happening, where, through whom, under whose ownership and with what evidence.

Consider a simple management statement: “We know where personal data resides.”

That statement may be true at one level. Yet a validation exercise may still need to ask: which applications, which branches, which email systems, which shared drives, which cloud services, which processors, which backups, which archives and which local copies?

Now consider another statement: “Deletion is supported.”

The operating questions become different. Can deletion be executed in the primary application? What happens in email? What happens in backup and DR copies? What happens at a processor? What happens in a branch file? What happens where another legal or operational retention requirement applies?

The purpose of asking these questions is not to prove that a declared statement is wrong. The purpose is to understand how far that statement is substantiated.

The Personal Data Processing Reality Layer

InfraVeritas360’s existing Foundation Layer research uses a simple sequence:

Applied to personal data, this creates a working research construct: the Personal Data Processing Reality Layer.

At the visible compliance layer, an organisation may have notices, policies, consent mechanisms, contracts, rights procedures and governance structures.

Underneath that sits the operating reality: people, purpose, collection points, applications, files, email, branches, cloud, processors, backups, archives, locations, retention, deletion, access, evidence and ownership.

The working hypothesis is:

This is an InfraVeritas360 working research hypothesis. It is not presented as an established industry theorem. It should be challenged.

Four research dimensions

This is an important part of the hypothesis. We are not only asking whether a control exists. We are asking what management can practically rely upon. For easier reading, the four dimensions are shown separately below.

The Processing Reality Gap

This leads to a second working construct: the Processing Reality Gap.

The Processing Reality Gap is the difference between what management believes or declares and what can currently be connected, validated and evidenced across the processing chain.

An explanatory model is:

The important point is that management should distinguish what is substantiated, what is conditional and what still requires validation, rather than force an incomplete operating picture into a binary answer.

A small quantitative example

Assume an organisation identifies ten major processing dependencies for one important personal-data activity.

Six dependencies are supported by current evidence. Two are declared and appear reasonable but have not yet been independently validated. Two remain unclear or unknown.

A percentage model may tempt someone to say “60% compliant”.

That would hide the actual governance issue.

A more useful management view may be:

This shows where confidence exists and where validation is still required, without creating false precision.

An operating example: a State Electricity Distribution Utility

Example only: The wider research hypothesis remains organisation-agnostic. This section uses a State electricity distribution utility only to demonstrate how the same Processing Reality Layer can be applied to one complex operating environment.

A State electricity distribution utility is a useful DPDP example because personal-data processing rarely sits inside one application. A consumer relationship can begin with a new electricity connection and continue through billing, payment, complaints, meter-related services, contact updates, field visits, mobile communication, online portals, rooftop-solar applications, agricultural-energy schemes and other public-service workflows.

The Ministry of Power’s Electricity (Rights of Consumers) Rules create a consumer-service environment that includes connections, metering, billing, payment, grievance redressal and standards of service. In practice, these activities can involve digital portals, customer-service teams, billing systems, field offices, payment channels, communication services and other supporting systems. That makes the privacy question an operating-chain question, not only a form or policy question.

Now add a public-benefit or subsidy-linked process. National renewable-energy programmes show how electricity-distribution organisations can become part of a wider processing chain. Under the Grid Connected Rooftop Solar Programme, residential consumers may apply through a national portal or a State DISCOM portal, empanelled vendors may perform installation, and the relevant DISCOM verifies the installation before Central Financial Assistance is released. The PM-KUSUM programme similarly involves farmers, State implementing agencies, vendors, solar-pump or solarisation workflows and public-benefit administration.

This means that the processing reality can extend beyond a basic electricity account. Depending on the service, it may connect consumer identity, contact details, service address, billing information, complaint history, field verification, scheme application, vendor interaction, payment or benefit status and supporting evidence.

Consider one management statement: “We can correct consumer personal data.”

The visible procedure may be simple. A consumer requests a correction and the organisation updates the main record. But the Processing Reality Layer asks a wider question. Where else is the same information used? Is it also present in billing, CRM, a mobile application, an office-level record, an SMS workflow, a field-service system, a scheme application, an exported report or with a processor?

The issue is not that every copy must always be changed in exactly the same way. Different records may have different legal, operational or evidentiary purposes. The governance question is whether the organisation understands the relationship well enough to explain which records should change, which records should remain, who owns the decision and what evidence supports the final position.

Now consider a grievance or rights-related request.

A consumer may interact through a call centre, online portal, mobile application, office, complaint mechanism or field team. If the matter involves personal data, can the organisation connect that request to the correct consumer account, the relevant systems, the operational owner and any processor involved in the service?

A customer-service process may show that the request was received. A CRM may show a ticket. A field office may complete an action. A communication service may send an SMS. Each record can be correct. The Foundation Layer question is whether these records can be connected into one reliable processing position when management needs to know what actually happened.

Now consider a benefit-linked energy programme.

A subsidy or beneficiary workflow can create additional processing relationships. A consumer or farmer may apply for a scheme, an installation may be performed by an empanelled vendor, a field or technical verification may be required, and a public benefit may be released only after specified steps are completed. The relevant programme may therefore connect an individual, application, service location, vendor, verification status, payment or subsidy status and supporting evidence. National rooftop-solar and PM-KUSUM programme structures demonstrate this type of multi-party operating chain.

The privacy issue is not the existence of the scheme. The research question is whether the organisation can show how personal data moves through the scheme, who is responsible at each important stage, what third-party dependency exists, how long relevant records remain, and what evidence management can rely upon if a correction, grievance, incident or other valid request arises.

This example becomes important because electricity distribution is a large public-service environment. Consumer services may operate through central offices, regional or local offices, digital systems, field operations and external service providers. Management therefore may not need every technical detail, but it does need confidence that an important privacy statement can be traced through the relevant processing chain.

For DPDP readiness, that distinction matters. A policy can describe the intended position. A portal can collect information. A service process can define an action. A contract can define a vendor responsibility. But management reliance depends on whether the organisation can connect these different parts when an actual correction, grievance, retention, deletion, incident or benefit-related question has to be answered.

What current industry research adds

EY India’s 2026 readiness research is relevant here because the reported activities do not move together. Gap assessment, documentation of processing activities, classification, processor identification, policy work and comprehensive implementation were at different stages across respondents. EY also noted challenges associated with fragmented data environments and legacy systems in several sectors.

KPMG India’s 2025 DPDP guidance for Global Capability Centres separately highlights data-flow mapping, role clarity, consent, rights automation, audit trails, breach response, vendor governance and cross-border alignment as connected areas of privacy implementation.

Neither EY nor KPMG validates the InfraVeritas360 hypothesis. Their work is cited only as independent industry reference. What it does show is that modern DPDP readiness involves multiple connected legal, operational, technology and third-party activities.

That is precisely why the question of processing reality deserves examination.

From research question to DPDPiq

InfraVeritas360 is now converting this research question into an experimental, research-built intelligence system called DPDPiq — DPDP Intelligence Quotient.

DPDPiq is being built from InfraVeritas360’s ongoing research into the Personal Data Processing Reality Layer.

Its proposed intelligence flow is:

The objective is not to issue a percentage saying that an organisation is “72% DPDP compliant”.

The objective is to create a structured first management view of what is understood, what is connected, what is supported, what is dependent, what is unknown and what requires validation.

The system intelligence is intended to structure declarations, dependencies, legal triggers, contradictions, evidence and unknowns. It is not intended to replace professional judgement.

Human Intelligence has to challenge the declared position, add business and legal context, validate evidence, reconcile contradictions and determine what management can finally rely upon.

Open research questions

This research is not closed. Several questions remain deliberately open.

Open Research Position

The Personal Data Processing Reality Layer is a working InfraVeritas360 research construct. The Processing Reality Gap is also a working explanatory construct. Neither should be treated as a legal definition, regulatory standard or established industry theorem.

The purpose of this work is not to create another checklist and not to prove that organisations are failing DPDP readiness.

The purpose is to test a management question:

InfraVeritas360 will continue testing this hypothesis through research, practitioner discussions, operating examples and structured assessments. Disagreement, counterexamples, legal challenge and operational experience are particularly valuable at this stage.

We sincerely thank privacy professionals, GRC practitioners, technology teams, legal professionals, CISOs, CIOs and industry professionals who continue to question and challenge this research.

If you believe the Processing Reality Layer is the wrong way to look at DPDP readiness, we would particularly value that challenge.