Privacy by Design for Product Teams: Building DPDP Into the Build

Executive summary

The Digital Personal Data Protection Act, 2023 (the DPDP Act) does not tell product teams to build "privacy by design". The phrase is not in it. Yet from 13 May 2027 a business that ships a feature without designing for the Act will struggle to comply at all, because most of its duties can only be met by things that must exist before the first user signs up: tagged data, consent records, deletion paths, default settings for children and logs.

This paper makes four points.

• There is no express clause, but there is a design duty in practice. Section 8(4) requires "appropriate technical and organisational measures to ensure effective observance" of the Act and the Rules. Read with ss.6(1), 8(3), 8(5), 8(7) and 9, and Rules 3, 6 and 8 of the DPDP Rules, 2025, it is in our view met only by controls built into the product.
• The lifecycle is the right unit. We map the Act to seven stages (discovery, product requirements, design, build, test, launch and change) and give each a definition of done that an engineering manager can check.
• Seven patterns do most of the work: purpose-tagged fields, consent and withdrawal as events, tracking off by default for minors, retention timers, deletion that reaches processors, a generated access summary and logs kept for at least a year.
• Standards help but do not decide. ISO 31700-1:2023 is a useful voluntary reference. The DPDP Act does not mention it, and following it is no defence.

A worked example, an AI visit-notes feature on a teleconsultation platform, shows the gates in use. A checklist and a roadmap to 13 May 2027 close the paper.

Background

In this paper a data fiduciary is the business that decides why and how personal data is processed, a data principal is the individual the data is about, and a data processor is a vendor that processes data on the fiduciary's behalf. A Significant Data Fiduciary (SDF) is one the Central Government designates for extra duties; none had been designated as of October 2026.

Privacy programmes start with documents; product teams start with tickets. Compliance fails in the gap. A notice can promise erasure when a purpose ends, but if the database does not know which purpose each column serves, nobody can tell when that is. A settings page can offer withdrawal, but if the system keeps only today's answer, with no history of which notice the person saw, the business cannot later prove what she agreed to, as s.6(10) requires.

Timing makes this urgent. The Act's main duties, and Rules 3 and 5 to 16, commence on 13 May 2027, a date unchanged as of October 2026. Features in this quarter's sprints will be live then, holding data collected under whatever design they shipped with. Retrofitting tags, timers and deletion hooks onto a live system is slower and riskier than building them in.

Trayambic has covered the components separately, from notices and retention to DPIAs and age assurance. This paper is about building them in, sprint by sprint.

Legal framework

What the Act does not say

The DPDP Act contains no clause headed or worded as privacy by design. In the Gazette text, the only use of "by design" is the requirement that the Data Protection Board of India (the Board) work as a digital office, with complaints, hearings and decisions "digital by design" (s.28(1)), and the same requirement for appeals to the Appellate Tribunal (s.29(10)).

Earlier drafts went further. The Personal Data Protection Bill, 2019, which never became law, had a clause 22 headed "Privacy by design policy": every data fiduciary had to prepare one, and could submit it to the proposed regulator for certification. The 2023 Act has nothing equivalent. The European Union's GDPR takes the other path: its recitals expect controllers to adopt measures meeting "the principles of data protection by design and data protection by default" (Recital 78).

The absence means there is no free-standing duty to keep a "privacy by design policy" and no certificate to obtain. It does not make design irrelevant.

The provisions that add up to a design duty

Reading them together

In our view s.8(4) is the hinge. "Effective observance" is a test of outcome: did the controls actually make each duty happen, for each person, each time? A fiduciary that adds a deletion path after launch has not ensured erasure for people whose purpose ended before it existed. One that cannot generate an access summary has not ensured observance of s.11. The duty is general; the specific provisions in the table say what "appropriate" has to cover.

Two consequences follow. The measures are judged when processing happens, which for a new feature means when it is designed. And the evidence has to come from the system, because s.6(10) puts the burden of proof on the fiduciary and the Board will ask for records, not intentions.

Penalties follow the specific duty breached. The Schedule sets maximums of ₹250 crore for failing to take reasonable security safeguards, ₹200 crore for breaching the obligations on children, and ₹50 crore for breaching any other provision, which in our view is where a free-standing s.8(4) failure would sit. Trayambic's article on the Board explains how penalties are fixed.

Analysis

Seven gates across the product lifecycle

A gate is a point at which work cannot move on until a short, checkable condition is met. The table assigns each stage the DPDP requirement it mainly serves and a definition of done (DoD).

Keep each DoD short enough to sit in the ticket or pull-request template; long questionnaires get skipped. Make the privacy lead an approver only at discovery and launch. And treat change as the strictest gate: most problems begin when a live feature quietly gains a new purpose, vendor, country, model or user group.

The discovery screen is not a full Data Protection Impact Assessment (DPIA); Trayambic's blog on DPIAs for non-SDFs gives the triggers and a one-page format. At the design gate, Trayambic's blog on dark patterns and consent design applies.

Seven patterns that carry the duties

1. Purpose-tagged data fields. Every field in the data model carries metadata: the purposes it serves, the ground for each (consent or a named s.7 clause), its retention rule, who may receive it and whether it can relate to a child. Services request data for a purpose; a request for an untagged purpose fails. Serves s.6(1), s.8(7) and Rule 3, because the notice, timers and access summary are generated from the same tags. Done when an untagged field cannot be merged into the schema.

2. Consent and withdrawal as events. Record each grant and withdrawal as an immutable event (person, purposes, notice version and language, channel, time) and derive current state from the stream. Services and processors subscribe to withdrawals and stop. Consents arriving through a consent manager under s.6(7) join the same stream. Serves s.6(4), s.6(6) and s.6(10). Trayambic's article on notices and consent explains why, in our view, a minimal record of consent and withdrawal may outlive the erased data. Done when a withdrawal reaches every subscriber within a target time you can show.

3. Tracking off by default for minors. Capture an age signal early, processing only what confirms whether the user is a child, as Part B of the Fourth Schedule to the Rules permits. For under-18 accounts, analytics and advertising software development kits (SDKs) are never initialised, personalisation is limited to what the service needs, and no behavioural profile is built. The switch sits on the server, not in a client setting. Serves s.9(3) and, with Rule 10's verifiable parental consent, s.9(1). Trayambic's article on age assurance covers identifying children. Done when a test account aged 15 produces no third-party tracking calls in a network trace.

4. Retention timers. Each record gets an expiry derived from its purpose: a trigger (order delivered, account closed, last login), a buffer with a stated reason, and an end date. A legal hold pauses the timer; a new purpose never silently extends it. Platforms in the three Third Schedule classes add the three-year dormancy clock with 48 hours' notice. Serves s.8(7)(a), s.8(8) and Rule 8. Trayambic's whitepaper on retention, deletion and logs sets the periods; this pattern makes them run. Done when every store in the data-flow diagram has a timer and expired test records disappear.

5. Deletion pipelines that reach processors. An erasure, from a timer, a withdrawal or a request, is a job with an identifier. It fans out to every internal store and each processor's deletion interface, waits for confirmation and escalates when none comes. Backups are handled by a deletion ledger re-applied on restore, as the retention whitepaper describes. Serves s.8(7)(b), s.6(6) and s.12(3). Done when a deletion test returns confirmation from every processor in the diagram, and each contract requires one.

6. An access-summary export. Generate the s.11(1) summary from live data: personal data held, by category; processing activities, from the purpose tags; and the fiduciaries and processors it was shared with, with what each received, from a sharing register the code writes to whenever data leaves. Omit sharing excluded by s.11(2) and include the Rule 9 contact. Trayambic's article on data principal rights covers both, and the limit of s.11 to consent and s.7(a) data. Serves s.11 and Rule 14. Done when a test user's export matches what the systems actually hold.

7. Logs kept for at least one year. Rule 6 requires logs and monitoring able to detect unauthorised access, kept with related personal data for at least a year; Rule 8(3) separately requires a year's retention of processing records; CERT-In's Directions of 28 April 2022 require ICT system logs for a rolling 180 days within India. Design the log once: who touched which record, for which purpose, from where and when, using identifiers rather than payloads, readable only by security and legal staff, erased when its period ends. Serves s.8(5) and Rules 6 and 8(3). Done when a sample access can be traced a year later and no log line carries more personal data than the trace needs.

Two artefacts engineers will actually maintain

Data-flow diagrams. One diagram per feature, kept in the repository beside the code, showing each source, store, service, processor and country, the trust boundaries and the purpose tags on each flow. It is drawn at the PRD stage and updated in the same pull request as any change adding a store, vendor or flow. It feeds the DPIA, defines the deletion test and, after an incident, shows whose data sat in the affected system; Trayambic's breach-notification whitepaper explains why that decides how fast notices go out.

Privacy user stories with acceptance criteria. Write the Act's duties in the form the team already uses. Three examples:

Criteria written this way become automated tests, and the test runs become evidence.

Where ISO 31700-1 fits

ISO 31700-1:2023, Consumer protection — Privacy by design for consumer goods and services — Part 1: High-level requirements, was published in January 2023. ISO describes it as establishing "high-level requirements for privacy by design to protect privacy throughout the lifecycle of a consumer product". By its own account it does not specify the methodologies an organisation should adopt or the technology used to operate privacy controls.

It gives a team shared vocabulary and a structure for lifecycle documentation. Two limits apply. The DPDP Act refers to no ISO standard, so conformity is no statutory defence and non-conformity no breach. And it is not mapped to Indian law, so every control must still trace to the provisions above. In our view it works best as a cross-check after the DPDP mapping, not as the starting point.

Worked example: AI visit notes on a teleconsultation platform

All facts and figures are illustrative. A teleconsultation platform in Pune connects about 2,000 doctors with patients, handling roughly one lakh consultations a month. It plans "AI visit notes": with consent, a speech-to-text vendor transcribes the consultation, a language-model vendor drafts a clinical note for the doctor to edit and sign, and the patient gets a plain-language summary once the doctor signs. The platform is the fiduciary for the feature; both vendors are its processors.

Discovery. Four purposes were proposed: the doctor's note, the patient summary, quality review of sampled notes, and "model improvement later". The last had no defined use, so it was cut. Recording rests on consent collected separately from booking, and the consultation proceeds normally if the patient declines, so consent is not a condition of care. Under-18 patients are expected; the Telemedicine Practice Guidelines, 2020 let a minor consult only along with an adult whose identity is ascertained (para 3.2.3).

Requirements. The PRD listed eleven new fields, each tagged. Two failed the tag check, a microphone model and an ambient-noise score that the speech vendor's SDK collected by default, and were switched off. Because the note informs clinical decisions, s.8(3) applies: AI-drafted text stays marked until the doctor edits or accepts it, and the summary is released only after sign-off. That also fits para 5.4 of the Guidelines: AI platforms may not counsel patients, and the final counselling or prescription comes from the doctor.

Design. The data-flow diagram showed the language-model endpoint outside India. Section 16(1) restricts no country as of October 2026, but the diagram records it; Trayambic's article on cross-border transfers covers the contract terms. For under-18 patients the feature is off by default; the accompanying parent can switch it on after verification under Rule 10, and a minor's audio is used for nothing beyond the note. In our view the Fourth Schedule exemption for healthcare professionals covers the doctor's treatment, not the platform's feature, as Trayambic's health-tech study argues.

Build. Timers: raw audio deleted 7 days after the note is signed; transcript 30 days; signed note kept under the platform's medical-records policy. Para 3.7.2 of the Guidelines asks for a log or record of the interaction, kept "as prescribed from time to time"; in our view the signed note and session log meet it, and the team recorded that reasoning. Withdrawing mid-consultation stops recording at once and sends a stop event to both vendors.

Test. Three defects surfaced. Stopping recording took one tap during the call but three in the app afterwards, so the settings route was shortened. The speech vendor kept failed jobs in a retry queue for 30 days, outside its deletion interface; the contract was amended and a confirmation step added. And the access summary said "AI vendor" instead of naming each processor; it now names both.

Launch and change. The notice gained two itemised lines and a new version, and the breach runbook added both vendors' incident contacts. Six months later the team proposed fine-tuning a model on signed notes. That reopened the discovery gate as a new purpose: it needs its own notice and consent, excludes minors' data and has gone to a DPIA.

Compliance framework

Phased roadmap to 13 May 2027

• Now to December 2026: apply the gates to all new work; tag the highest-risk live features first (health, finance, children, AI); start the consent event log.
• January to March 2027: tag the remaining fields; build timers, deletion jobs, child mode and the log design; draw diagrams for live features.
• April to 13 May 2027: amend processor contracts; ship the access-summary export; run the privacy test suite on every feature; regenerate notices from the tags.
• From 13 May 2027: run the gates as routine; revisit the DoD lists after the Board's first decisions and after any change to the Rules.

Recommendations

1. 1.Treat s.8(4) as your privacy-by-design clause, and let the specific provisions decide what "appropriate" covers.
2. 2.Put purpose tags in the schema first; notices, timers and access summaries all depend on them.
3. 3.Keep the history: record every consent and withdrawal as an event tied to the notice version shown, and derive the current state from it.
4. 4.Default child accounts to no tracking on the server side, and prove it with a network trace.
5. 5.Count a deletion as done only when every processor has confirmed it.
6. 6.Make change the strictest gate: new purposes, vendors, countries, models and user groups reopen review.
7. 7.Use ISO 31700-1 to check coverage, not to replace the DPDP mapping.

Key takeaways

• The DPDP Act has no privacy-by-design clause; its only 'by design' is the Board's and the Appellate Tribunal's 'digital by design' working (ss.28(1), 29(10)), and the 2019 Bill's privacy-by-design policy was dropped.
• In our view s.8(4), read with ss.6, 8(3), 8(5), 8(7) and 9 and Rules 3, 6 and 8, creates a design duty in practice, because 'effective observance' cannot be retrofitted.
• Seven lifecycle gates (discovery, PRD, design, build, test, launch, change), each with a definition of done, turn the Act into checks a product team can run.
• Purpose-tagged fields, consent as events, tracking off for minors, retention timers, processor-reaching deletion, an access-summary export and one-year logs carry most of the duties.
• ISO 31700-1:2023 is a useful voluntary cross-check, but the Act does not refer to it and conformity is no defence.