India’s Digital Personal Data Protection Act and its accompanying rules set out how organisations may collect and process digital personal data. Privacy policies and notices are part of the response. Most of the work, though, sits in systems: how consent is captured, what data is collected, where it flows and when it is deleted.
This piece covers the engineering side in general terms. It is not legal advice. Obligations, timelines and exemptions depend on your sector and circumstances, so confirm specifics with counsel.
Map the data first
You cannot apply consent, minimisation or retention to data you have not found. Build a data map that covers:
- What personal data each system collects and why
- Where it is stored, including backups, logs, analytics and data warehouses
- Which processors and third parties receive it
- Which AI systems use it for retrieval, fine-tuning or evaluation
Logs and analytics are where personal data hides. So are support tickets, spreadsheets exported for a one-off analysis, and prompts sent to AI models.
Consent as a system of record
The framework emphasises consent that is free, specific, informed and tied to a stated purpose, along with the ability to withdraw it. In engineering terms that means consent is data, not a checkbox.
A workable design:
- A consent store recording who consented, to which purpose, when, through which notice version and channel
- Purpose tags on data so processing can be checked against what was consented to
- Withdrawal that propagates — downstream systems are notified and processing stops for that purpose
- Notice versioning so you can show what a person actually saw
- Clear language — notices in plain terms, available in the languages your users use
Where processing relies on grounds other than consent, record that basis per purpose too. Counsel decides the basis; systems should record it.
Minimise by design
Collect what the purpose requires and nothing more. Practical steps:
- Review forms and APIs field by field — why is each one needed?
- Mask or tokenise identifiers where full values are not required
- Keep personal data out of logs by default; log references, not contents
- Redact personal data before sending text to AI models where the task allows
- Restrict access by role and review it regularly
Minimisation also reduces breach exposure. Data you never stored cannot leak.
Retention with real deletion
Data should not be kept longer than its purpose needs, subject to other legal retention requirements. Retention fails when it lives only in a policy document.
Build it in:
- A retention schedule per data category and purpose
- Automated deletion or anonymisation jobs with logs proving they ran
- Deletion that reaches replicas, caches, search indexes and vector stores
- Handling for backups — documented expiry rather than silent persistence
Vector stores deserve attention. Embeddings of personal data are still derived from personal data. Plan how to remove a person’s records from retrieval indexes.
Rights requests as workflows
People can ask to access, correct or erase their data and to raise grievances. Treat these as product workflows with identity verification, tracking, service levels and audit trails. Manual email chains do not scale and leave no evidence.
Breaches and processors
The framework includes breach notification obligations. Make sure detection, triage and escalation runbooks name who decides and who notifies. For processors, contracts and technical controls should match — access scoped, data returned or deleted at the end of the engagement.
Where to start
- Build a data map for one product, including logs and AI pipelines
- Stand up a consent store with purpose tags and withdrawal events
- Remove personal data from logs and analytics where it is not needed
- Implement retention jobs for the highest-volume data categories first
- Review the design with counsel before rollout
Incubics builds controls designed to support data protection obligations into delivery, with data residency in India where required.