The engineering work inside the DPDP Act

Since the Digital Personal Data Protection Act, 2023 received assent in August 2023, most of what has been written about it has come from lawyers. That legal reading is necessary. It is also incomplete, because the duties the law creates are carried out by systems, and the people who run those systems are often not in the room when the explanations are given. They are the engineers who own the customer tables, the product manager who designed the signup screen, and the person who set the backup schedule five years ago and has not looked at it since.

Consent is recorded, checked and withdrawn inside software. A retention period is enforced by a deletion job, or it is not enforced at all. A breach report draws on logs that exist, or it has nothing to draw on. A company can hold a complete, well drafted set of policies and still fail the Act, because its systems cannot do what those policies say.

Six duties make up the working core of the Act: consent, notice, the rights of Data Principals, retention, erasure and breach reporting. Each can be followed from the text of the law down to the system behaviour it needs, and the same pattern shows up in every one of them. A clause that reads like a statement of principle becomes, once you apply it to a real product with real users, a requirement with a data structure, a workflow, a time limit or an audit trail attached. Doing that translation across a whole organisation is most of what preparing for the Act involves.

The timetable gives the work its shape. The DPDP Rules, 2025 were notified on 13 November 2025 (G.S.R. 846(E)) and come into force in phases. The definitions and the provisions setting up the Data Protection Board applied straight away. Consent Manager registration follows around 13 November 2026. Most of the duties examined here, including notice, security safeguards, breach intimation, erasure and the rules on children's data, apply from around 13 May 2027 as notified, unless amended. The penalties in the Schedule go up to 250 crore rupees for failing to take reasonable security safeguards and up to 200 crore rupees for failing to notify a breach. For any organisation of moderate size, the engineering takes months. Organisations that start soon have enough time, and those that wait will be short of it.

Compliance engineering is the name for this work: turning regulatory duties into system design, then checking that the design holds up in operation. Founders, technology heads and product owners deciding how their organisations respond to the Act need an accurate picture of what the law asks of their systems, so that decisions about budget, order of work and outside help rest on the real scope of the job. This is a practitioner's reading of the Act and the Rules. It is not legal advice.

Where the Act actually lives

A law written for systems

The definitions show what kind of law this is. The Act applies to digital personal data: data about an identifiable individual that is collected in digital form, or collected on paper and digitised later. It places duties on the Data Fiduciary, the organisation that decides the purpose and means of processing, and gives rights to the Data Principal, the person the data is about.

Digital personal data lives in database tables, documents, object storage, application logs, analytics events and message queues. It sits in the CRM, the helpdesk, the WhatsApp Business account the sales team uses, and the spreadsheet someone exported for last quarter's GST reconciliation. The decisions a fiduciary makes about purpose and means show up first in product features, integrations and data flows, and only later, if at all, in a policy.

That is why documents alone cannot satisfy the Act. When the law says personal data must be erased once its purpose is served, the duty falls on whoever owns the customer tables, the backup schedule and the analytics warehouse, because that is where the data sits. When the law says withdrawing consent must be as easy as giving it, the duty falls on the team that built the signup flow, which now has to build a withdrawal flow just as simple.

A legal reading of the Act tells an organisation what it owes. An engineering reading tells it what it has to build. A compliance programme succeeds or fails on whether the second reading is done as carefully as the first.

The phased timeline and what it means for engineering teams

The Rules did not switch the whole regime on at once. The provisions that started on notification set up the Data Protection Board, its digital procedures and the basic definitions, so the enforcement structure exists in law today. The Consent Manager provisions follow twelve months after notification. The duties that reach into company systems, covering notice, security safeguards, breach intimation, retention and erasure, children's data and the additional duties of Significant Data Fiduciaries, follow around eighteen months after notification, which puts the working date at around May 2027.

The order carries a practical lesson for anyone planning the work. The duties arriving last are the ones that take longest to build, because they all depend on knowing where personal data sits across every system the company runs, and few organisations have that knowledge written down today. A readiness programme that moves from assessment through remediation to audit-ready operation typically takes nine to twelve months in an organisation of moderate complexity. A team that starts in the second half of 2026 can finish within the window, with little room for delay. A team that waits for the first enforcement actions to show how the Board will behave will be making architectural changes under regulatory scrutiny, which is the most expensive time to make them.

Consent as a system requirement

What the Act asks consent to be

The Act asks for consent that is free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, for a specified purpose. Each of those words becomes a design decision once a product team tries to honour it.

Take an NBFC's personal loan app, as an illustration. It uses applicant data to assess credit, to send repayment reminders, to study where applicants drop off in the funnel, and to market other products. "Specific" means those purposes cannot sit behind one "I agree" box, so the app has to ask for each purpose separately where consent is the basis. "Informed" means each request comes with, or after, the notice required by Rule 3, which ties every consent to a particular disclosure. "Unconditional" means the loan cannot depend on agreeing to marketing the loan does not need. "Unambiguous" and "affirmative" together rule out silence, inactivity and every kind of pre-ticked box.

Put together, these requirements make consent a maintained record. For every Data Principal, the company should be able to say which purposes were agreed to, when, on which screen, against which version of the notice, and in which language the notice was shown. The Act gives people the option to read the notice in English or in any of the twenty-two languages listed in the Eighth Schedule to the Constitution, so the language is part of the record too. When the Board asks the company to show that a particular piece of processing rested on valid consent, the answer should come from a query against a record a system keeps. Building that record properly is the first substantial piece of engineering the Act asks for.

The consent record and its lifecycle

A consent record changes over its life, and the changes are where the engineering gets demanding. Consent is captured at a moment, against a purpose and a notice version. Later it may be renewed, extended to a new purpose or narrowed to fewer purposes. It may be withdrawn in part or in full. It may lapse because the purpose was fulfilled or because the person stopped using the service.

Every one of those changes needs a timestamp, and every one must change what the processing systems are allowed to do. A record that is updated while the connected systems carry on as before protects nobody. Updating a flag in the consent table while the campaign tool keeps sending offers is bookkeeping, and the Act judges the processing.

So consent becomes an integration question that spans many teams. The purposes held in the record have to map to the systems that process data for those purposes. That brings the CRM, the analytics pipeline, advertising integrations and internal reporting jobs into scope, since each must either check consent before it acts or work only on data sets that already respect consent.

The Consent Manager framework adds a further requirement. Registered Consent Managers are companies, with a net worth of at least two crore rupees under Rule 4, that let a person give, manage, review and withdraw consent across many fiduciaries from one place. Organisations that receive consent through them have to be technically ready to accept those signals and act on them. That assumes an interface and a reconciliation process that very few Indian companies ran before this law, and getting it right takes real design work.

Withdrawal and the propagation problem

The Act says withdrawing consent must be as easy as giving it, and that one sentence holds more engineering than any other line in the law. Giving consent is easy because product teams made it easy, with the request placed right in the path of registration or purchase. Matching that means a withdrawal option just as visible and simple, and behind it, machinery that makes the withdrawal take effect.

When a person withdraws consent for a purpose, processing for that purpose has to stop within a reasonable time. Data held only for that purpose then falls under the erasure duties of the Act. The withdrawal must reach every system, and every processor acting on the fiduciary's instructions. Afterwards, the organisation has to be able to show that all of this happened.

Reaching every system is the hard part, because personal data in an established company has been copied widely. Picture a customer's details in a mid-sized consumer business: they sit in the analytics warehouse, the helpdesk, the payment gateway's records, the search index, and the WhatsApp messaging vendor that sends order updates. A withdrawal that changes the main database and leaves those copies untouched has not been honoured in any sense the law recognises.

Solving this needs three things. A map of where data flows, organised by purpose. Contractual and technical arrangements with processors that carry the withdrawal downstream. Monitoring that confirms each step completed. None of these can be declared into existence by a policy. They have to be designed, built and tested, and whether they exist is one of the clearest signs of whether an organisation has done engineering work or stopped at paperwork.

Notice as something you build

The standalone, itemised notice

Rule 3 requires that every request for consent comes with, or after, a notice that can be understood on its own, without reference to any other document. It has to be in clear and plain language, and it has to be itemised. The notice must describe the specific personal data being collected, the specific purpose of processing, the goods or services that processing makes possible, and how the person can withdraw consent, exercise their rights and complain to the Board.

The word "itemised" carries the weight. A general privacy policy that describes broad categories of data and broad business purposes does not meet the standard, because the notice has to be built from the actual data items and the actual purposes involved in the specific consent being sought.

For a product organisation, that changes what a notice is. A notice written to this standard is generated content, and its inputs are the data inventory and the purpose register. It has to stay true as the product changes. When a new field appears on a form, or a new vendor starts receiving customer data, the notice for the affected purpose becomes incomplete, and any consent gathered against it is weaker.

The lasting answer is to produce the notice from the same source of truth the engineering team works from. Then a change in data collection forces a review of the disclosure, and the two cannot quietly drift apart.

Versioning notices and binding them to consent

Because notices will change as products change, they need versions, and each version has to connect to the consent record. Every consent should point to the exact notice version the person saw, in the language they saw it, at the moment they acted.

With that link in place, a question from the Board about what a particular customer agreed to in March, and on the strength of what disclosure, is a lookup. Without it, the organisation is reconstructing history it never recorded. Reconstruction carries little weight in a penalty proceeding, where the burden of showing that notice was given and consent obtained sits with the fiduciary.

Versioned notices also add a checkpoint to the release process, and it is better to plan for it than to discover it. A material change in processing needs a new notice version. A new purpose needs fresh consent from affected users before the processing begins. Organisations that build this checkpoint into their development workflow pay for it early, as a routine review step next to testing and release approval. Organisations that meet it after a feature has shipped pay much more, because unwinding a feature that has already processed data without a valid basis means remediation, possibly notification, and exposure the checkpoint would have prevented.

Data Principal rights and the machinery behind them

Access requests and the inventory problem

Section 11 gives every Data Principal the right to a summary of the personal data being processed about them and the processing activities involved, along with the identities of the other fiduciaries and processors the data has been shared with and a description of what was shared.

Answering one request of this kind needs three capabilities. The organisation has to know every system that holds personal data. It has to be able to search each of those systems for one individual. And it has to turn the results into an accurate, readable response within the period it has published. Rule 14 requires fiduciaries to publish how people can exercise their rights and the time within which grievances will be answered, which must be no more than ninety days. All three capabilities have to exist before the first request arrives, because none of them can be improvised inside a response window.

Many organisations cannot do this yet. Personal data has built up over years across production databases, spreadsheets on shared drives, marketing platforms, support systems and analytics tools, and no single person or document records all of it. That is why a credible programme starts with data discovery and mapping, and leaves the drafting until later. The map is what access, correction, erasure and breach response all stand on, since each one needs to know where the data is before anything can be done with it. A programme that starts with documents and puts off the map has built the visible part of compliance and left out the part that carries the load. The first serious rights request will show the gap.

Correction and erasure across systems and processors

Section 12, the right to correction, completion, updating and erasure, turns the access problem into a harder one, because these rights change data. Correcting a record means carrying the corrected value to every copy downstream. A corrected address in the core system sitting next to the old address in the warehouse leaves the company holding two versions of the truth about one person.

Erasure goes further. The fiduciary must erase personal data on a valid request, or once the purpose is served, and must make its processors erase it too. The duty crosses company boundaries, and the fiduciary stays answerable for data it passed to vendors. That brings processor contracts, deletion instructions and deletion confirmations into the engineering scope of the programme.

Erasure also meets real technical limits, and a serious programme deals with them openly. Backups, disaster recovery archives and append-only logs cannot always remove one individual on demand. A defensible pattern combines prompt erasure from live systems, deletion through expiry as backup cycles rotate, and documented restore procedures that reapply erasures whenever a backup is restored.

What the organisation needs is a written, engineered and tested definition of what deletion means in its own environment, consistent with what its notice tells people will happen to their data. Difficulty here is expected and acceptable. The exposure comes from staying silent about the difficulty while promising things the systems cannot do.

Grievance redressal and nomination as workflows

Two more rights complete the set, and both are workflows more than data operations.

Every Data Fiduciary must run a grievance redressal mechanism, and under section 13 a Data Principal has to use it before approaching the Board. That makes the mechanism the organisation's first contact with any complaint. A working mechanism has a published channel, an accountable owner, tracked cases, response timelines that are kept, and records that show all of this afterwards.

Under section 14, a Data Principal may nominate another person to exercise their rights if they die or become incapable. That asks the systems handling identity and rights requests to represent a relationship, one person authorised to act for another under defined conditions, that most consumer platforms have never modelled.

These two rights say something about the law as a whole. It expects an ongoing working relationship between the organisation and the individual, one that lasts well beyond the disclosures exchanged at signup. Requests arrive continuously, in volumes the organisation does not control, from people whose complaints are specific and personal. They need processes that keep working after their designers have moved on, designed, staffed and measured like any other part of the business.

Retention and erasure as lifecycle design

Purpose limitation turned 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 it to be kept.

The Rules make this concrete for the largest consumer platforms. Rule 8 and the Third Schedule cover e-commerce, online gaming and social media platforms above set user thresholds. For them, the purpose is treated as no longer served three years after the person last engaged with the platform, and the platform must tell the person at least forty-eight hours before erasing, which gives them a chance to log in and keep the account. Organisations below those thresholds are free of the three year figure. The principle still applies to them in full. Keeping everything forever by default is no longer a position the law accepts.

Turning the principle into systems means every category of personal data gets a retention rule, drawn from its purpose and from any other law that requires records to be kept, such as tax, GST and financial regulation. Then the rules have to be carried out by the systems that hold the data: scheduled deletion jobs, archive tiers that expire, and reports that show the schedules ran as designed.

This is the step many organisations have never taken. A retention schedule in a PDF, while every production table keeps growing, does not meet the duty. The duty attaches to the data, and only running systems act on data.

What deletion means in production

Deletion sounds like one operation. In practice it is a family of techniques, and a careful programme decides which one applies in each case.

• Hard deletion removes the record entirely.
• Anonymisation removes everything that could identify the person. It takes the record outside the definition of personal data only if it cannot be reversed, which is a much higher bar than dropping a name column.
• Suppression keeps the bare minimum needed to honour the deletion itself, such as a note that a particular mobile number must not be contacted again.

Each has legitimate uses. The choice in each case should be deliberate, written down, and consistent with what the notice told the person would happen to their data.

For platforms under the three year rule, the forty-eight hour notice adds one more workflow. The retention engine, the messaging system and the audit trail have to work in sequence: notify the person, wait out the window, cancel the erasure if they come back, then erase and keep proof of each step. As duties go this is a small one, and it shows the general character of the Rules well. Again and again, systems are asked to act on time, in a set order, with evidence kept. Requirements of that shape are met through engineering, or they are not met.

Breach reporting against the clock

Two notifications in parallel

When a personal data breach happens, Rule 7 sets two duties that run side by side.

The fiduciary must inform the Data Protection Board without delay on becoming aware of the breach, with a description of it and its likely impact. Within seventy-two hours of becoming aware, or a longer period if the Board allows it on request, the fiduciary must follow up with a detailed report covering the facts, the events that led to the breach, the steps taken to limit it, what was found about the cause and the person responsible where known, the measures taken to stop it happening again, and a report on the intimations sent to affected people.

At the same time, the fiduciary must inform every affected Data Principal without delay, in clear and plain language, through their user account or the contact details it holds. The message has to say what happened, what it may mean for them, what the company is doing about it, what they can do to protect themselves, and how to reach someone who can answer their questions.

There is no size threshold. A breach that touches one customer carries the same duties as one that touches a million.

The clock starts at awareness. It does not wait for the internal investigation to finish, and it does not stop for weekends or Diwali. Many organisations also carry an older duty under the CERT-In directions of April 2022 to report specified cyber security incidents within six hours. A single event can therefore need two reports, to different recipients, in different formats, on different clocks, all prepared while the incident itself is still being contained.

The Schedule attaches serious consequences to failure at either point: up to 250 crore rupees for failing to take reasonable security safeguards, and up to 200 crore rupees for failing to notify a breach. The Board decides the actual amount after looking at the nature, gravity and duration of the breach and the other factors in section 33. Even so, breach readiness sits among the highest-stakes duties in the regime.

Detection, logging and evidence

A seventy-two hour reporting duty can only be met by an organisation that detects breaches quickly, and detection is an engineering capability. It rests on access logging across the systems that hold personal data, alerts on unusual access, and an escalation path that turns a suspicious signal into a declared incident with a named owner within hours.

Rule 6 turns much of this into a baseline. It lists reasonable security safeguards that include encryption, masking, obfuscation or virtual tokens; access control; logs and monitoring so that unauthorised access can be detected and investigated; backups to keep data available; and terms in processor contracts. It also requires logs and personal data to be kept for at least one year for detection, investigation and remediation, unless another law says otherwise. What used to be an operational preference now has a regulatory floor.

Evidence is the other half of readiness. After a breach, the organisation has to show when it became aware, what it did and how quickly it acted, and timestamps carry that story. A tamper-evident record of detection, escalation, containment and notification lets the organisation state its timeline with confidence. An organisation without such records is putting its account together from memory.

Response roles are assigned in advance. Report formats for the Board and for affected people are drafted and reviewed by counsel before any incident. The routes for reaching affected users, by SMS, email or in-app message, are tested. The whole sequence is rehearsed in periodic drills. A weakness found in a drill gets fixed on a normal schedule. A weakness found during a live incident has to be fixed inside the reporting window, at far greater cost and risk.

What this means for how compliance is built

The team a real programme needs

A programme that can meet this law draws on three kinds of work.

Legal judgement interprets the duties, classifies the data and settles the questions the text leaves open, such as when a legitimate use under section 7 applies or how long a business record must be kept. Engineering maps the data estate, builds the consent and notice handling, puts retention and erasure into running systems, and sets up detection and response. Operations runs grievance redressal, rights requests and vendor management as continuing processes with owners and measures.

Each covers ground the other two cannot reach, and a programme missing any one of them develops predictable gaps. Without engineering, you get documents the systems cannot honour. Without legal judgement, you get controls with no defensible reading behind them. Without operations, you get effort with no structure to hold it together once the project team leaves.

The market forming around the Act offers help at both depths, and buyers do well to recognise the difference. Some providers supply policy packs, template libraries and training certificates. These are priced accessibly because they leave the buyer's data processing as it was. Others carry out assessment, design, implementation and verification across the buyer's systems, and are priced 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 shows the first time a rights request, a withdrawal or a breach tests what was bought.

Where documentation fits once engineering leads

None of this makes documentation less important. Policies matter a great deal, and their value goes up 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 drill actually rehearsed are strong documents for one reason: every statement in them can be checked against a system. Documentation like that serves the organisation in front of a regulator, because it describes controls that exist and records decisions that were really made.

The order of work matters as much as the work itself.

1. Data discovery and mapping come first, because every other duty depends on knowing where personal data sits.
2. Consent, notice, retention and rights handling come next, because they have the longest build times and need the most integration.
3. Breach readiness runs in parallel from the start, because incidents arrive on their own schedule.
4. Documentation is finalised as the systems reach their working shape, so that every page describes something real.

An organisation that follows this order reaches May 2027 with a programme that holds up under inspection. One that reverses it produces its documents early and squeezes the system work into whatever time is left.

Conclusion

The Digital Personal Data Protection Act, 2023 asks Indian organisations to change how their systems handle personal data, and six duties show the shape of that change.

Consent becomes a maintained record with a lifecycle that governs processing. Notice becomes a versioned, itemised output bound to that record. The rights of Data Principals become searches and workflows that run against a data map, which has to exist before anything else can work. Retention and erasure become lifecycle rules that systems carry out and prove. Breach reporting becomes a rehearsed capability that works within seventy-two hours, supported by logs kept over the previous year. Each of these is engineering work, and each takes a long time to build compared with the timetable the law has set.

Enforcement will concentrate on the distance between compliance as it appears in documents and compliance as it performs inside systems. Closing that distance is the work of a properly run compliance programme, moving from assessment through design and implementation to keeping it true over time. The Act has given everyone a firm date, announced well ahead, and the value of that notice depends on how the remaining months are used.

TrustOS turns each of these duties into assigned work with an owner, a completion and evidence, and holds the inventory, purposes, notices and requests in one place. The engineering inside your own systems still has to be done by people who know them. Where that work needs hands, Code Colonies consulting runs DPDP readiness assessments, and implementation and integrations can be delivered on 2good terms, where you pay after you accept the work. Write to consulting@codecolonies.com. Every date and phase is set out in the DPDP Act timeline.