When systems cannot do what the policy promises

Most companies preparing for the Digital Personal Data Protection Act, 2023 are in two states of compliance at the same time.

In the first state, the documents are in order. The privacy notice has been drafted, the consent wording reviewed by counsel, the retention policy approved and the incident response plan filed. In the second state, someone looks at the systems, and a different picture appears. Customer data sits in places the documents never mention. Consent is recorded, and nothing reads the record. Retention periods exist in a PDF while every table keeps growing. The logs a breach report would depend on were never switched on.

The Act's duties turn into system requirements. The common failure is to assume those requirements are met and never check. The assumption breaks at four layers: databases, applications, infrastructure and vendor relationships. Each layer has its own typical gaps, and each gap has its own way of turning a documented duty into one that is never actually performed. These gaps show up often, and they form even in well run organisations.

Enforcement will concentrate on exactly this distance. A rights request, a consent withdrawal or a breach does not test what an organisation wrote. It tests what the organisation can do, within set time limits, with evidence kept at each step. The largest penalties in the Schedule, up to 250 crore rupees for failing to take reasonable security safeguards and up to 200 crore rupees for failing to notify a breach, attach to failures that happen in systems. Most of the Data Fiduciary duties apply from around 13 May 2027, as notified under the DPDP Rules, 2025, unless amended. An organisation that knows the size and location of its gap can close it in an orderly way before then. One that has never measured the gap will learn its size from the first real test.

The measurement has a working method. A readiness assessment traces each duty through the organisation's actual systems, exercises the paths a Data Principal or a regulator would exercise, and records where each path completes, where it stalls and where it does not exist at all. The result is a mapped and prioritised account of the distance between the compliance an organisation believes it has and the compliance it can show. Every sound remediation programme begins with that account. This is a practitioner's view of the Act and the Rules. It is not legal advice.

Two states of compliance

The document state and the system state

The document state is easy to reach and easy to see. It consists of the things a compliance programme is expected to produce: the privacy notice, the consent wording, the retention policy, the data processing agreements, the incident response plan and the training records. These can be produced quickly, reviewed by counsel and presented to a board. Finishing them feels like progress because it is visible and countable.

These documents are necessary. The question is what their existence proves. A complete document set shows intent, and the Act regulates conduct.

The system state is reached and seen in a different way. It is established by observation, and the observations are specific:

• Can the organisation produce, for one named individual, every item of personal data it holds about them, within its published response period?
• When a person withdraws consent for marketing, does the marketing platform stop within a set time, and is the stop recorded?
• When the retention period for a data category ends, does anything delete the data, and does anything prove the deletion ran?
• If a breach happened last night, could the organisation tell from its logs which records were accessed and by whom?

Each question has a checkable answer, and the answers define where the organisation really stands under the law. The two states line up only when someone has done the work of connecting them. That connecting work is the substance of a compliance programme.

How the gap forms in well run organisations

The gap between documents and systems is rarely a sign of negligence. It forms through the ordinary running of a growing company.

Take an illustrative D2C skincare brand that started on Instagram and WhatsApp five years ago. Orders came in on WhatsApp and were copied into a Google Sheet, then moved to an online store. A courier aggregator received delivery addresses. A marketing tool received phone numbers. Customer service ran on a helpdesk, and agents pasted order details into team chat groups to sort out returns. Someone exported a customer list for a Diwali sale and never deleted it. Every step was reasonable.

The same thing happens in larger companies at greater scale. Products are built under deadline pressure, and data collection grows feature by feature without a register recording it. Teams adopt tools on their own, and each tool receives a copy of customer data as part of doing its job. Engineers create extracts to answer real business questions, and the extracts stay long after the questions are answered. Marketing platforms collect lists, support systems collect conversations and analytics pipelines collect events. All of it is useful, and none of it is mapped. A few years of this produces an estate nobody in the organisation can describe completely, which is the normal state of a company that never had a legal reason to keep that description.

The DPDP Act supplies the legal reason, and it changes the standard the accumulated estate is judged against. Before the Act, a forgotten copy of customer data in an analytics bucket was untidy. Once the main duties apply, the same copy is personal data the organisation processes and cannot account for. Rights requests miss it, retention schedules leave it out, and a breach investigation never looks at it. Nothing about the data changed. The duties around it changed. The gap is the set of places where old habits have not yet been brought up to the new standard. Accepting that the gap is normal is the first step. Measuring it is the second, and the four layers show where to look.

The gap in the data layer

Personal data the organisation cannot see

The first and largest gap sits in the data layer. It is personal data that exists outside anyone's awareness.

The known locations are the production databases behind the main product. Even a modest company holds personal data in many places beyond them:

• Application logs capture email addresses, mobile numbers and identifiers in request records.
• Analytics events carry user properties into third party platforms.
• Support tickets hold whatever customers chose to write, which often includes addresses, phone numbers and account details.
• Marketing tools keep lists uploaded for a single campaign and never removed.
• Spreadsheets on shared drives hold extracts made for reporting, reconciliation or a one-off analysis.
• Chat groups and email threads hold customer details pasted between colleagues to fix one complaint.

Every one of these is within the scope of the Act, because the law attaches to the data, wherever it sits. An access request has to cover the spreadsheet as fully as the production database. An erasure has to reach the analytics platform as fully as the customer table. A breach of the shared drive carries the same notification duties as a breach of the core system.

That is why discovery, the systematic work of finding where personal data actually lives, is the first act of any real readiness programme. It is also the step most often skipped, because it is slower than drafting and its findings are uncomfortable. A programme that skips it is documenting an estate it has never seen.

One person, many records

The second gap in the data layer is about identity. The Act's duties are owed to individuals, and most organisations' systems are not organised around individuals.

The same customer is a customer ID in the order database, a mobile number in the marketing tool, a requester in the helpdesk, a device ID in the analytics pipeline and a name on a GST invoice in the accounting software. Nothing connects them. When that person sends a rights request, the organisation has to find all of these records. The linking that was never done in advance has to be done during the response period, by hand, with no way to know whether everything was found.

Closing this gap means building a data map organised by purpose and extended with identity matching, so the organisation can go from one individual to every record held about them in every system. In practice this is a maintained inventory. For each system, it records what personal data the system holds, for which purposes, keyed by which identifiers, and how those identifiers match the ones used elsewhere.

The inventory is unglamorous, and everything else rests on it. Access, correction, erasure, withdrawal and working out the scope of a breach all come down to walking through it. An organisation that can say quickly and completely where one named person's data sits has closed the data layer gap. One that cannot holds duties it is not yet able to perform.

The gap in the application layer

Consent that is recorded and never enforced

The application layer has a subtler gap, and it shows up in organisations that have already done visible consent work. The consent screens exist, choices are captured and a record is written. Any review that stops at the screen will pass.

The gap sits behind the screen, in the question of what reads the record. In many implementations, nothing does. The campaign tool sends to the full list whatever the recorded preferences say. The analytics pipeline processes every event whatever the recorded purposes are. The recommendation model trains on all available data, whoever agreed to what. The consent record has become an archive of intentions that the processing systems never consult.

Enforcing consent is integration work, and its shape follows from the purposes involved. Each processing system either checks consent before it acts, or only receives data sets that were filtered against consent further upstream. Both patterns need the consent record to be authoritative, current and reachable from the systems that depend on it.

Withdrawal sharpens the requirement. A withdrawal is a change of state that has to alter the behaviour of every connected system within a set time, and that change has to be visible afterwards. An organisation can test its own position in an afternoon: withdraw marketing consent on a test account and watch what actually changes. If the next WhatsApp broadcast or promotional SMS still arrives, the application layer gap has been found.

Rights features that were never built

The rights of Data Principals need application features, and in most products those features do not yet exist, because nothing before the Act asked for them.

• Access needs the ability to gather one person's data and deliver it in a readable form.
• Correction needs a screen or a process through which corrections enter the systems and reach every copy.
• Erasure needs a deletion capability that works for one individual across every place their data is held, which is a very different problem from dropping a table or expiring a partition.
• Grievance redressal needs a case workflow with owners, timelines and records, and published response periods, with grievances answered within no more than ninety days under Rule 14.
• Nomination needs the identity model to represent a person authorised to act for another under defined conditions.

Each feature takes real building effort, and the effort is regularly underestimated because the features sound administrative. Erasure for one individual is the clearest case. It reaches into schema design, foreign key relationships, event streams and derived tables, and retrofitting it into a system that was never designed for deletion is often one of the largest single pieces of work in a readiness programme.

The realistic approach is to treat rights features as a product roadmap in their own right, with the same scoping, estimation and sequencing any roadmap gets. Programmes that do this finish. Programmes that treat rights as a paragraph in a policy discover the roadmap later, with less time to deliver it.

The gap in the infrastructure layer

Copies that outlive the erasure

Below the applications, the infrastructure holds personal data in forms application teams rarely think about. These forms open a gap between what erasure means in a policy and what it achieves in practice.

Database backups hold every record as it stood on the backup date, including records erased since. Read replicas and caches hold copies with lifecycles of their own. Warehouse snapshots keep historical states by design. Storage buckets hold exports, dumps and archives built up over years. Log retention keeps request histories that carry identifiers. An erasure that removes someone from the live systems while all of this stays put has changed the surface and left the depths as they were.

The defensible pattern is well established: erase from live systems promptly, let backups expire on their normal rotation, and make restore procedures reapply any erasures made since the backup. The readiness question here is whether that pattern actually exists in the organisation's infrastructure, and the checks are concrete:

• What is the backup retention period, and is it written down and enforced?
• Do restore procedures include a step that replays erasures made since the backup date, and has anyone ever run that step?
• Which caches and replicas hold personal data, and what limits how long they keep it?
• Which buckets hold historical exports, and when were their contents last checked against retention rules?

Organisations that can answer these have engineered their erasure. Those that cannot are promising something their infrastructure does not deliver.

Logging below the standard breach reporting assumes

The breach duties assume infrastructure most organisations have not yet built. Under Rule 7, a fiduciary must inform affected people and the Board without delay on becoming aware of a breach, and send the Board a detailed report within seventy-two hours. That assumes awareness arrives quickly. Quick awareness rests on access logs across the systems holding personal data, alerts that surface unusual patterns, and an escalation path that produces a declared incident with an owner. Rule 6 adds a specific floor: logs and personal data kept for at least one year for detection, investigation and remediation.

Against that standard, mid-sized organisations commonly fall short in recognisable ways. Logging is on for some systems and off for others. Retention is whatever the default happened to be. Logs exist and nobody watches them. Alerts exist and go to a channel nobody owns.

This gap has one property worth stating plainly: it cannot be closed after it is needed. Every other gap can, in principle, be fixed late, at higher cost and risk. Logs are different. A breach investigation can only use records written before the breach, and nothing done afterwards can recover observation that never happened.

That gives logging and monitoring a natural priority in any remediation plan, ahead of work that looks more visible. An organisation that switches on complete access logging, kept for a year, early in its programme has secured the evidence base for every incident that follows, whatever else is still unfinished at the time.

The gap in third party processing

Vendors holding data without a deletion path

The fourth layer sits outside the organisation, with the vendors and platforms that process personal data on its behalf. The Act holds the Data Fiduciary answerable for that processing and expects erasure to reach processors too. Every vendor relationship involving personal data becomes a compliance dependency. For the D2C brand, that means the courier aggregator, the payment gateway, the WhatsApp Business provider, the helpdesk, the email platform and the agency running its ads.

The readiness questions follow directly:

• Which vendors hold personal data, and does that answer come from a complete list or from memory?
• Does each relationship rest on a contract with data protection terms, deletion duties and breach notification duties running back to the fiduciary?
• When the organisation erases a customer, does an instruction reach each vendor holding that customer's data, and does a confirmation come back?
• When a vendor has a breach, will the organisation hear about it soon enough to meet its own duties to the Board and to affected people?

In most organisations the answers are patchy, because the vendor estate grew the same way the data estate did: tool by tool, under deadline pressure, without a register.

The fix is a vendor register joined to the data inventory, so that every third party system in the map carries its contract status, its deletion path and its notification terms alongside it. Renegotiating agreements takes calendar time that engineering cannot shorten, because it depends on the other side. That argues for starting the vendor work early in a programme and treating it as a main workstream from the first month. A fiduciary whose own systems are in order while its processors are ungoverned has closed three layers of the gap and left the fourth open, and the Act does not grade the layers separately.

Integrations the policy has never heard of

A narrower version of the vendor gap keeps recurring: integrations that move personal data without appearing in any document.

A developer connects the product to an error tracking service, and stack traces start carrying user IDs to an outside platform. A growth team installs an attribution SDK, and device-level data starts flowing to it. A plugin added to the website starts setting identifiers and sending events. None of these went through procurement, none appears in the description of processing, and each is processing personal data on the organisation's behalf within the meaning of the law. The privacy notice describes a data flow diagram that stopped being accurate the day after it was drawn.

The remedy is partly technical and partly procedural. On the technical side, an organisation can list every outbound data flow from its applications and websites, and the list regularly surprises the teams who asked for it. On the procedural side, the lesson from versioned notices applies in full: any change to data flows passes through a checkpoint that updates the inventory, the vendor register and the notices together. The checkpoint costs little as part of the normal release process. Without it, an organisation that finished a careful readiness programme one year drifts quietly out of compliance over the next two.

Measuring the gap: a working method

Tracing duties from start to finish

A readiness assessment that measures the real gap starts with the concrete paths the law will exercise and walks them through the actual systems.

• Submit an access request for a test individual and follow it from intake to the delivered response, recording every system touched, every manual step and every point where the trail goes cold.
• Withdraw consent on a test account and watch which downstream systems change their behaviour, how quickly, and what record is left.
• Run a tabletop breach exercise against a plausible scenario and measure the time from first signal to a draft report for the Board, noting which facts could not be established because the logs to establish them do not exist.
• Pick a data category whose retention period has passed and check whether anything deleted it.

Each trace produces the same kind of output: a specific, located, checkable finding. The access trace shows that the helpdesk and two marketing tools were never searched, because nobody handling the response knew they held personal data. The withdrawal trace shows the consent record updating while the email platform keeps sending. The breach exercise shows that awareness would have taken days, because the relevant alerts do not exist, and that the seventy-two hour report could not have named the affected people, because access logs cover only one system.

Findings like these are hard to argue with, and they turn the readiness question from an opinion into an inventory.

If the Central Government notifies an organisation as a Significant Data Fiduciary, the same tracing extends to the additional duties that come with that status: a Data Protection Officer based in India, an independent data auditor, a Data Protection Impact Assessment and an audit at least once every twelve months, and due diligence on algorithmic software. Each is either demonstrably in place or it is a finding.

Reading the results into a plan

The raw findings become a programme when they are read against three questions.

The first is severity: which findings leave the organisation exposed to duties it cannot perform. Anything touching breach detection, breach notification and security safeguards weighs most, because the penalty Schedule goes up to 250 crore rupees for safeguards.

The second is effort: which findings are configuration changes, which are integration projects and which need schema-level engineering. These differ by an order of magnitude in cost and duration.

The third is dependency: which findings block others. The data inventory blocks nearly everything, and logging blocks every future investigation.

Read this way, the findings produce a remediation sequence, and the sequence is the real deliverable of an assessment. It states what will be fixed, in what order, by whom, at what cost and by what date. It gives leadership a measured position to manage.

The assessment also produces a second deliverable that is easy to overlook: the baseline. Every claim the organisation later makes about its progress, to its own board or to the Data Protection Board, is more credible when it can be set against a measured starting point. That starting point can only be captured once, before remediation begins.

Closing the gap before May 2027

What remediation consists of

Once the assessment has located the gap, the work sorts into five streams.

1. The data stream builds and maintains the inventory and the identity matching across systems. It runs first, because every other stream uses its output.
2. The application stream builds consent enforcement, withdrawal propagation and the rights features, treated as a product roadmap with real engineering estimates.
3. The infrastructure stream brings logging, monitoring, retention jobs and backup handling up to the standard the duties assume, with logging switched on as early as possible, because logs cannot be recovered after the event.
4. The vendor stream completes the register, closes the contract gaps and sets up deletion and notification paths. It starts early, because part of its timetable belongs to other companies.
5. The documentation stream runs alongside all of them, writing up each control as it starts working, so that the final document set describes a system that exists.

The split of effort across these streams corrects a common budgeting mistake. In a typical mid-sized organisation, the engineering streams carry most of the cost and most of the calendar time, and the documentation stream carries the least. That is close to the reverse of how compliance budgets are usually drawn up. An organisation that spends most of its programme budget on producing documents has funded the fifth stream and starved the four that decide the outcome. The right split follows the assessment findings, which is one more reason the assessment comes first. A programme budgeted before the gap was measured is budgeted against a guess.

Time, sequence and a realistic calendar

The calendar arithmetic is simple. An assessment of this kind typically takes two to four weeks in an organisation of moderate complexity. The remediation streams that follow take three to five months when they have committed owners, and longer when they compete with feature work for the same engineers. Vendor renegotiations run on their own clock within that period.

With the main duties applying from around May 2027, an organisation that starts in the second half of 2026 can complete the sequence with a modest margin. Each quarter of delay turns straight into compression of the engineering streams, and those are the streams that compress worst.

The other half of the calendar argument is what the finished state gives you. An organisation that closes its gap in order reaches May 2027 able to answer rights requests within its published periods, able to show that consent is enforced, able to carry out and prove erasure, and able to write a breach report from logs that were running all along. Its documents hold up too, because every statement in them can be checked against a working control. From that position, regulatory questions get short, confident answers. Any organisation that measures its gap while there is still time to close it can reach that position, and the measuring is a defined piece of work with a defined method.

Conclusion

The gap between documented and implemented compliance can be measured, and it has a known shape across four layers.

In the data layer, it appears as personal data the organisation cannot see and identities it cannot connect. In the application layer, it appears as consent that nothing enforces and rights features that were never built. In the infrastructure layer, it appears as copies that outlive erasure and logging below the standard breach reporting assumes. In the vendor layer, it appears as processors with no deletion path and integrations no document describes. Each form of the gap turns a duty the organisation has accepted on paper into one it cannot perform, and from around May 2027 the Act will test performance.

Closing the distance is the work of a well structured compliance programme. It moves from assessment through design and implementation to keeping it true over time, each phase produces defined deliverables, and an organisation weighing outside help can judge a provider by how concretely it describes that work. Every real programme begins with the decision to measure before the deadline does the measuring for you.

TrustOS holds the inventory, the purposes, the vendor register and the evidence in one place, so the findings and the remediation sequence have somewhere to live. The measuring itself has to happen in your own systems first. If you want help with it, Code Colonies consulting runs DPDP readiness assessments that trace each duty through your systems, and you can reach the team at consulting@codecolonies.com. To see which duties apply when, read the DPDP Act timeline.