The Engineering Work Inside the DPDP Act

Abstract

Since the Digital Personal Data Protection Act 2023 received assent, the commentary around it has come mainly from the legal profession. Law firms have explained its provisions, compliance advisors have summarized its penalties, and company boards have asked their counsel what must be done to satisfy it. This reading of the Act is necessary, and it is also incomplete, because the obligations the law creates are performed by systems rather than by documents. Consent is recorded, checked, and withdrawn inside software. Retention periods are enforced by deletion jobs or they are not enforced at all. Breach reports draw on logs that either exist or do not. A company can hold a complete and well written set of policies and still fail the Act if its systems cannot carry out what those policies state.

This article follows six obligations from the legal text down to the system behavior each one requires. The six are consent, notice, the rights of data principals, retention, erasure, and breach reporting, and together they form the operational core of the law. In each case the pattern repeats. A clause that reads as a statement of principle becomes, once applied to a real product with real users, a requirement with a data structure, a workflow, a time limit, or an audit trail attached to it. Understanding this translation is the first step in preparing for the Act, because the preparation itself consists of performing it across an entire organization.

The schedule gives this work its shape. The Digital Personal Data Protection Rules 2025 were notified on 13 November 2025 and follow a phased commencement. The Data Protection Board and the foundational provisions are already in force. The Consent Manager framework commences in November 2026, and the obligations examined in this article become enforceable around May 2027. The penalty schedule reaches 250 crore rupees for failures in security safeguards and 200 crore rupees for failures in breach notification. The engineering described in the following sections is measured in months for an organization of even moderate complexity, which means the remaining time is adequate for those who begin soon and insufficient for those who wait.

We use the term compliance engineering for this work, meaning the discipline of translating regulatory obligations into system architecture and verifying that the translation holds in operation. The article is written for founders, technology leaders, and product owners who will decide how their organizations respond to the Act. Its purpose is to give them an accurate picture of what the law asks of their systems, so that decisions about budget, sequence, and outside help rest on the actual scope of the work rather than on a summary of the legal text.

1. Where the Act Actually Lives

1.1 A law written for systems

The definitions in the Act reveal its character. It applies to digital personal data, meaning data that identifies an individual and exists in digital form or is digitized after collection. It places obligations on the Data Fiduciary, the entity that determines the purpose and means of processing, and it grants rights to the Data Principal, the individual the data relates to. Each of these terms points at a technical reality inside the organizations the law governs. Digital personal data lives in database tables, documents, object stores, application logs, analytics events, and message queues. The decisions a fiduciary makes about purpose and means are expressed in product features, integrations, and data flows long before they are written into any policy.

This is the reason documentation alone cannot satisfy the Act. When the law requires personal data to be erased once its purpose is served, the requirement falls on whoever owns the customer tables, the backup schedule, and the analytics warehouse, because those are the places the data actually sits. When the law requires that withdrawing consent be as easy as giving it, the requirement falls on the team that built the signup flow and now must build a withdrawal flow of equal simplicity. A legal reading of the Act tells an organization what it owes. An engineering reading tells the organization what it must build, and the outcome of a compliance program depends on the second reading being done as carefully as the first.

1.2 The phased timeline and what it means for engineering teams

The Rules did not bring the whole regime into force at once. The provisions that commenced immediately on notification establish the Data Protection Board, its digital procedures, and the foundational definitions, which means the regulator is already constituted and operating. The Consent Manager framework commences twelve months after notification, in November 2026. The obligations that reach into company systems, covering notice, consent, security safeguards, breach reporting, retention, and the rights of data principals, commence around eighteen months from notification, which places the operative date in May 2027. The government chose to establish the enforcement structure first and to give regulated entities a defined preparation period before the core duties activate.

This sequencing carries practical guidance for anyone planning the work. The obligations arriving last are the ones with the longest build times, because they depend on a complete inventory of where personal data sits across every system the company operates, and few organizations hold such an inventory today. Experience across regulated industries indicates that a readiness program moving from assessment through remediation to audit ready operation occupies nine to twelve months in an organization of moderate complexity. A team beginning in mid 2026 can complete the work within the available window, though without much margin for delay. A team that postpones until the first enforcement actions clarify the Board’s approach will be carrying out architectural changes under regulatory scrutiny, and that is the most expensive condition in which to do them.

2. Consent as a System Requirement

2.1 What the Act asks consent to be

The Act requires consent to be free, specific, informed, unconditional, and unambiguous, and to be given through a clear affirmative action for a specified purpose. Each of these words carries a design consequence once a product team tries to honor it. Specific means purposes cannot be bundled together behind a single agreement checkbox, so a product that processes data for service delivery, analytics, and marketing must obtain consent for each purpose separately. Informed means the consent request must be preceded or accompanied by the notice described in the next section, which ties every consent to a particular disclosure. Unconditional means access to a service cannot be made to depend on consent for processing the service does not require. Unambiguous and affirmative together exclude silence, inactivity, and every form of the pre ticked box.

Taken together, these requirements give consent the shape of a maintained record. For every data principal, the organization must be able to state which purposes were consented to, at what time, through which interface, against which version of the notice, and in which language the notice was presented, since the Rules require notices to be available in English and in the languages of the Eighth Schedule to the Constitution. When the Board asks an organization to demonstrate that a particular processing activity rested on valid consent, the answer must come from a queryable record maintained by a system, and building that record correctly is the first substantial piece of engineering the Act demands.

2.2 The consent record and its lifecycle

A consent record changes over its life, and the changes are where the engineering becomes demanding. Consent is captured at a point in time against a purpose and a notice version. It may later be renewed, extended to a new purpose, or narrowed to fewer purposes. It may be withdrawn in whole or in part, and it may lapse because the purpose was fulfilled or the data principal stopped using the service. Every one of these transitions must be recorded with a timestamp, and every one must change what the processing systems are actually permitted to do. A record that is updated while the connected systems continue their previous behavior offers no protection, because the Act judges the processing itself and not the bookkeeping around it.

Consent therefore becomes an integration concern rather than the property of a single team. The purposes held in the record must map to the systems that perform processing for those purposes, which brings the customer relationship platform, the analytics pipeline, the advertising integrations, and the internal reporting jobs into scope, since each must either check consent state or operate on data sets that already respect it. The Consent Manager framework commencing in November 2026 adds a further requirement, because organizations must be technically prepared to receive and honor consent signals arriving through registered third party Consent Managers. That presumes an interface and a reconciliation process which very few Indian companies operated before this law existed, and which takes real design work to get right.

2.3 Withdrawal and the propagation problem

The Act states that withdrawing consent must be as easy as giving it, and this sentence contains more engineering than any other line in the law. Giving consent is easy because products are designed to make it easy, with the request placed directly in the path of registration or purchase. Matching that ease means building a withdrawal interface of comparable prominence and simplicity, and behind the interface, building the machinery that gives the withdrawal effect. When a person withdraws consent for a purpose, processing for that purpose must stop, the data held for it enters the erasure obligations discussed later in this article, and the withdrawal must reach every system and every processor acting on the fiduciary’s instructions. The organization must also be able to show, afterward, that all of this happened.

Reaching every system is the demanding part, because personal data in an established company has been copied widely. It sits in a warehouse for analytics, in a support desk tool, with a payment processor, and in a search index, and a withdrawal that updates the primary database while leaving those copies untouched has not been honored in any sense the law recognizes. Solving this requires a purpose aware map of where data flows, contractual and technical arrangements with processors that carry the withdrawal downstream, and monitoring that confirms completion. This capability cannot be declared into existence through a policy. It has to be designed, built, and tested, and its presence or absence is one of the clearest ways to tell whether an organization has done engineering work or has stopped at paperwork.

3. Notice as a Built Artifact

3.1 The standalone, itemized notice

The Rules require that every request for consent be accompanied or preceded by a notice that can be understood independently of any other document, written in clear and plain language, and itemized. The notice must describe the specific personal data being collected, the specific purpose of processing, the goods or services enabled by that processing, and the manner in which the data principal can exercise rights and lodge complaints. The word itemized carries the weight here. A general privacy policy that describes categories of data and broad business purposes does not meet this standard, because the notice must be assembled from the actual data elements and the actual purposes involved in the specific consent being requested.

For a product organization this changes the nature of the artifact. A notice built to this standard is not a static page written once and left alone. It is generated content whose inputs are the data inventory and the purpose register, and it must remain truthful as the product evolves. When a new field is added to a form, or a new integration begins receiving user data, the notice tied to the affected purpose becomes incomplete, and the consent gathered against it is weakened. The durable approach is to treat the notice as an output of the same source of truth the engineering team works from, so that a change in data collection forces a review of the disclosure instead of quietly separating the two.

3.2 Versioning notices and binding them to consent

Because notices will change as products change, they must be versioned, and the versions must connect to the consent record described in the previous section. Every consent needs to reference the exact notice version the data principal saw, in the language they saw it, at the time they acted. With that binding in place, a question from the Board about what a particular person agreed to, and on the basis of what disclosure, is answered by a lookup. Without it, the organization is reconstructing history it never recorded, and reconstruction carries little weight in a penalty proceeding where the burden of demonstrating valid consent sits with the fiduciary.

Versioned notices also introduce a checkpoint into the product release process, and it deserves to be planned for rather than discovered. A material change in processing requires a new notice version, and where the change involves a new purpose, it requires fresh consent from affected users before the processing begins. Organizations that build this checkpoint into their development workflow absorb its cost early, as a routine review step alongside testing and release approval. Organizations that encounter it after deployment carry a much larger cost, because unwinding a feature that has already processed data without a valid basis involves remediation, notification, and exposure that the checkpoint would have prevented.

4. Data Principal Rights and the Machinery That Serves Them

4.1 Access requests and the data inventory problem

The Act grants every data principal the right to obtain a summary of the personal data being processed about them, the processing activities involved, and the identities of the other fiduciaries and processors with whom the data has been shared. Fulfilling a single request of this kind requires the organization to know every system that holds personal data, to query those systems by the identity of one individual, and to assemble the results into an accurate and readable response within the service periods it has published, with the Rules pressing fiduciaries toward defined response timelines for rights requests. Each of those three capabilities has to exist before the first request arrives, because none of them can be improvised in the time a response allows.

The honest starting position of many organizations is that they cannot yet do this. Personal data has accumulated over years across production databases, spreadsheets, marketing platforms, support systems, and analytics tools, and no single person or document records the full extent of it. This is why a credible compliance program begins with data discovery and mapping rather than with policy drafting. The map is the foundation on which access, correction, erasure, and breach response all stand, since each of those obligations requires knowing where the data is before anything can be done with it. A program that begins with documents and defers the map has built the visible part of compliance while leaving the load bearing part absent, and the first substantive rights request will expose the absence.

4.2 Correction and erasure across systems and processors

The right to correction and erasure extends the access problem into a harder one, because these rights change data rather than read it. Correcting a record means carrying the corrected value to every downstream copy, since a corrected profile in the primary database sitting beside a stale copy in the warehouse leaves the organization holding contradictory records about the same person. Erasure reaches further, because the Act requires the fiduciary to erase personal data on a valid request or once the purpose is served, and to cause its processors to erase it as well. The obligation crosses organizational boundaries, and the fiduciary remains answerable for data it passed to vendors, which brings processor contracts, deletion instructions, and deletion confirmations into the engineering surface of the program.

Erasure also meets genuine technical constraints, and a serious program resolves them explicitly instead of ignoring them. Backups, disaster recovery archives, and immutable logs cannot always remove a single individual on demand. The defensible pattern combines prompt erasure from live systems, expiry driven deletion as backup cycles rotate, and documented restoration procedures that reapply erasures whenever a backup is restored. What the organization needs is a written, engineered, and tested definition of what deletion means in its own environment, consistent with what its notice tells data principals will happen. Difficulty here is acceptable and expected. Silence about the difficulty, combined with promises the systems cannot keep, is what creates exposure.

4.3 Grievance redressal and nomination as workflows

Two further rights complete the set, and both take the form of workflows rather than data operations. Every data fiduciary must operate a grievance redressal mechanism, and a data principal must exhaust it before approaching the Board, which makes the quality of this mechanism the organization’s first line of engagement with any complaint. A working mechanism consists of a published channel, an accountable owner, tracked cases, response timelines that are honored, and records that demonstrate all of this after the fact. The right of nomination, under which a data principal may nominate another individual to exercise their rights in the event of death or incapacity, requires the systems that manage identity and rights requests to represent a relationship that consumer platforms have generally never modeled.

These two rights say something about the law as a whole. It expects a continuing operational relationship between the organization and the individual, extending well past the exchange of disclosures at registration. Rights requests arrive continuously, in volumes the organization does not control, from people whose complaints are specific and personal, and they must be served by processes that keep functioning after the people who designed them have moved on. Capabilities of this kind are designed, staffed, measured, and rehearsed in every other area of business operations, and the Act now requires the same treatment for the handling of personal data.

5. Retention and Erasure as Lifecycle Design

5.1 Purpose limitation translated into retention schedules

The Act ties the life of personal data to the life of its purpose. Data must be erased when consent is withdrawn or when it is reasonable to assume the specified purpose is no longer being served, unless another law requires retention. The Rules make this concrete for the largest consumer platforms in commerce, online gaming, and social media by deeming the purpose exhausted three years after the data principal last engaged with the service, and by requiring a notice to the individual at least forty eight hours before erasure is carried out, which gives the person an opportunity to return and continue the relationship. Organizations below those thresholds are not bound by the three year figure, but the principle applies to them fully, and retaining everything indefinitely by default is no longer a posture the law accommodates.

Translating the principle into systems means every category of personal data acquires a retention rule derived from its purpose and from any statutory retention obligations, such as those in tax and financial regulation, that operate alongside the Act. The rules must then be executed by the systems that hold the data, through scheduled deletion jobs, archival tiers with expiry, and reporting that shows the schedules ran as designed. This execution step is the one many organizations have never taken. A retention policy that exists in a document while every production table grows without limit does not satisfy the obligation, because the obligation attaches to the data itself, and only running systems can act on data.

5.2 What deletion means in a production environment

Deletion sounds like a single operation and is in practice a family of techniques, and a careful program decides which member of the family applies in each situation. Hard deletion removes the record entirely. Anonymization strips the record of everything that could identify the individual, which takes it outside the definition of personal data only if the process is irreversible, a considerably higher standard than removing a name column. Suppression retains the minimum needed to honor the deletion itself, such as a record that a person opted out so they are not contacted again. Each technique has legitimate uses, and the choice in each case must be deliberate, documented, and consistent with what the notice told the data principal would happen to their data.

The forty eight hour notice before erasure introduced by the Rules adds one more workflow to this lifecycle. An organization subject to it needs its retention engine, its messaging infrastructure, and its audit trail to operate in sequence, notifying the individual, waiting out the window, honoring any renewed engagement, and then erasing with proof of each step. As obligations go this is a modest one, and it illustrates the general character of the Rules well. Systems are repeatedly asked to act on time, in a defined order, and with evidence retained, and requirements of that shape are met through engineering or they are not met.

6. Breach Reporting Against the Clock

6.1 The dual notification obligation

When a personal data breach occurs, the Rules create two obligations that run in parallel. The fiduciary must inform the Data Protection Board without delay upon becoming aware of the breach, providing a description and its likely impact, and must follow with a detailed report within seventy two hours covering the facts, the circumstances that led to the breach, the remedial measures taken, findings about the cause, and confirmation of the intimations sent to affected individuals. At the same time, the fiduciary must notify every affected data principal in clear and plain language, describing what happened, what it may mean for them, what protective steps they can take, and how to reach the organization with questions. There is no threshold of scale, and a breach affecting one individual carries the same notification duties as a breach affecting millions.

The seventy two hour period begins at awareness, not at the conclusion of the internal investigation, and it runs through weekends and holidays. Many organizations also carry a separate and older obligation to report cyber security incidents to the national incident response agency within six hours under existing directions, which means a single event can require two reports with different recipients, different formats, and different timelines, all prepared while the incident itself is still being contained. The penalty schedule attaches serious consequences to failure at either point, with security safeguard failures exposed to penalties up to 250 crore rupees and notification failures up to 200 crore rupees, which places breach readiness among the highest stakes obligations in the regime.

6.2 Detection, logging, and evidence

A seventy two hour reporting obligation can only be met by an organization that detects breaches quickly, and detection is an engineering capability. It rests on access logging across the systems that hold personal data, alerting on unusual access patterns, and an escalation path that converts a suspicious signal into a declared incident with a named owner within hours rather than days. The Rules reinforce this by requiring security safeguards that include access control, encryption or comparable protective measures, monitoring, and the retention of logs for at least one year, which establishes a regulatory minimum for logging in place of what was previously an operational preference.

Evidence is the other half of readiness, because after a breach the organization must demonstrate when it became aware, what it did, and how quickly it acted, and timestamps are what carry that demonstration. An unalterable record of detection, escalation, containment, and notification allows the organization to establish its timeline with confidence, while an organization without such records is assembling its account from memory. The preparation itself is well understood in mature security practice and now becomes a general requirement. Response roles are assigned in advance, report formats are drafted and legally reviewed before any incident, the routes for reaching affected users are tested, and the full sequence is exercised in periodic drills. Weaknesses found in a drill are corrected on an ordinary schedule, while weaknesses found during a live incident must be corrected inside the reporting window, at far greater cost and risk.

7. What This Means for How Compliance Is Built

7.1 The team a real program needs

The preceding sections point to a single structural conclusion, which is that a program capable of meeting this law combines three disciplines. Legal judgment interprets the obligations, classifies data, and settles the questions the text leaves open. Engineering maps the data estate, builds the consent and notice machinery, implements retention and erasure, and establishes detection and response. Operations run grievance redressal, rights fulfilment, and vendor management as continuing processes with owners and measures. Each discipline covers ground the other two cannot reach, and a program missing any one of them develops predictable gaps, whether in the form of documents its systems cannot honor, controls without a defensible interpretation behind them, or effort that lacks an architecture to organize it.

The market forming around the Act contains offerings at both depths, and buyers benefit from recognizing the difference. Some providers supply policy packs, template libraries, and training certificates, priced accessibly because they leave the buyer’s data processing unchanged. Others carry out assessment, design, implementation, and verification across the buyer’s systems, priced according to that scope because the work changes the things a regulator will actually examine. Both kinds of purchase will be made between now and May 2027. The difference between them becomes visible the first time a rights request, a withdrawal, or a breach tests what was bought.

7.2 Where documentation fits once engineering leads

None of this argument reduces the importance of documentation, and it would be a misreading of this article to conclude that policies do not matter. They matter greatly, and their role strengthens when engineering leads. A privacy notice generated from the real data inventory, a retention schedule that mirrors the deletion jobs actually running, and an incident response plan that matches the procedure actually rehearsed are strong documents for a specific reason, which is that every statement in them can be verified against a system. Documentation of that kind serves the organization in front of a regulator, because it describes controls that exist and records decisions that were genuinely made.

The order of work matters as much as the work itself. Data discovery and mapping come first, because every other obligation depends on knowing where personal data sits. The consent, notice, retention, and rights machinery comes next, because these carry the longest build times and the most integration effort. Breach readiness proceeds in parallel, because incidents arrive on their own schedule and readiness cannot wait for the rest of the program to finish. Documentation is finalized as the systems reach their compliant shape, so that every page describes something that exists. An organization following this sequence arrives at May 2027 with a program that withstands inspection, while an organization that reverses the sequence produces its documents early and leaves the system work compressed into whatever time remains.

Conclusion

The Digital Personal Data Protection Act 2023 asks Indian organizations to change how their systems handle personal data, and the six obligations examined in this article show the shape of that change. Consent becomes a maintained record with a lifecycle that governs processing. Notice becomes a versioned artifact bound to that record. The rights of data principals become queries and workflows running against a data map that must exist before anything else can function. Retention and erasure become lifecycle rules that systems execute and prove. Breach reporting becomes a rehearsed capability operating within a seventy two hour period, supported by logs retained over the preceding year. Each of these is engineering work, and each carries a build time that is long relative to the schedule the law has set.

This article is the first in a series of three. The second examines operational readiness under the Act, and specifically the distance between compliance as it appears in documents and compliance as it performs inside systems, because that distance is where enforcement will concentrate. The third describes the structure of a properly run compliance engagement, from assessment through design and implementation to sustained adherence, so that organizations evaluating outside help know what the work should look like from the inside. The Act has given regulated entities a firm deadline announced well in advance, and the value of that advance notice depends entirely on how the remaining time is used.