Building DPDP duties into the release process

You build DPDP duties into a product by turning each one into something a release can be blocked on: a purpose entry, a notice version, a consent event, a withdrawal path, a retention clock, a log, a vendor contract. The Act says nothing on development process. It does require the outcomes, and Sec. 8(4) requires "appropriate technical and organisational measures to ensure effective observance". Most of those measures are engineering work.

This page assumes you have done the audit. If not, start with the compliance checklist and then come back.

A purpose registry that features must reference

Sec. 6(1) requires consent to be specific to a purpose and limited to the personal data necessary for it. The Act's own illustration: a telemedicine app asking for the phone's contact list. Contacts are not necessary for telemedicine, so consent is limited to the data that is.

Make that checkable. A registry holds, per purpose: name, plain-language description, data fields, ground (consent under Sec. 6 or a legitimate use under Sec. 7), retention, processors, and owner. A feature that collects a field must reference an entry, or add one through review. This also gives you the itemised list Sec. 5 and Rule 3 need for the notice. A records-of-processing register can serve as the registry.

Notice as a versioned artifact

Rule 3 requires the notice to stand on its own, use clear and plain language, give an itemised description of the personal data and the specified purposes, and provide the link to the website or app and a description of the means for withdrawal, rights and complaint. Sec. 5 also requires access in English or any Eighth Schedule language. Store each notice version with an identifier, render per language, and ship notice changes through the same pipeline as code. The notice requirements page lists every element.

One consent event per decision

On every grant or withdrawal, write a record: Data Principal identifier, purpose, notice version, language, timestamp, outcome, and the source (web, app, call centre). Append, never overwrite. That record is what you show if a consent is questioned, and what makes downstream propagation possible. Consent receipts describes a tamper-evident form.

Withdrawal in the same sprint as capture

The most common design error is shipping the capture screen and leaving withdrawal for later. Sec. 6(4) requires withdrawal at any time, and Rule 3(c)(i) makes it comparable in ease to the giving. Sec. 6(6) requires you to cease processing, and to cause processors to cease. Wire a withdrawal event to every system that holds the data, including analytics, CRM and messaging tools. The developer docs cover the API and the webhook an app can listen to. If you build your own, test it end to end: withdraw, then check each downstream store.

Retention clocks

For each purpose, define when it is deemed served and what erases the data. Sec. 8(7) requires erasure on withdrawal or when the purpose is no longer served, unless law requires retention, and Rule 8 sets specific periods for the classes in the Third Schedule, with a 48-hour warning to the Data Principal before erasure. Rule 8(3) separately requires personal data, traffic data and logs of processing to be kept for at least one year. Design the schema with an expiry or review date, and an erasure job that also instructs processors.

Breach logging

Rule 6(1)(c) requires visibility on access through logs, monitoring and review, and Rule 6(1)(e) retention of logs for one year. Product teams own most of that: audit trails on reads of personal data, alerts on bulk exports, and a way to answer "who accessed this record". Rule 7 then asks for the nature, extent, timing and location of a breach, so build the queries before you need them. See security safeguards.

The release checklist

Add these to the definition of done for any feature touching personal data.

1. Maps to a purpose registry entry.
2. Notice covers it, and the version is released.
3. Consent events captured.
4. Withdrawal works and reaches downstream systems.
5. Retention and erasure defined and tested.
6. Access logging on, retention one year or per applicable law.
7. New vendor or SDK reviewed, with a contract under Sec. 8(2). See vendor management.

Children's data needs more. Sec. 9(1) requires verifiable parental consent, and Sec. 9(3) bars tracking, behavioural monitoring and targeted advertising directed at children, subject to Sec. 9(4) exemptions. If your product may be used by under-18s, add an age check at the top of this list.

The substantive duties commence on 13 May 2027 under Rule 1(4). Features live before then will still be processing data on that date, so retrofit costs more than building now.