Recommendation Engine Development, security and the DPDP Act: a compliance checklist
Is recommendation engine development compliant with the DPDP Act?
Recommendation engine development can be fully DPDP-compliant, but not by default. It needs consent captured for personalisation as a named purpose, a retention window on behavioural events, erasure that reaches the feature store and training set, and an audit record of what was shown and why.
Recommendation engine development can be fully compliant with India's DPDP Act 2023, but not by default. Compliance rests on four design decisions: consent captured for personalisation as a named purpose, a documented retention window on behavioural events, erasure that reaches the feature store and the training set, and an auditable record of what was shown to whom.
This checklist walks the obligations one at a time, maps each to the control that satisfies it inside a ranking system, names the four places personal data actually sits in such a system, and is candid about where a compliance-first approach starts costing more than it protects.
Why a recommendation engine is a privacy problem, not just a model
A recommendation engine is the most detailed behavioural record most companies hold. It stores what a named person looked at, in what order, for how long, on which device, and what they did not buy. A transactional database knows what someone purchased; an event store knows what they considered. Under the Digital Personal Data Protection Act 2023, both are personal data when they are tied to an identifiable individual.
That matters because the Act is consent-led and purpose-bound. It requires notice in clear language, consent for a stated purpose, limits on retention, and rights of access, correction and erasure. The Ministry of Electronics and Information Technology publishes the Act and the rules made under it at meity.gov.in, and it is the authority whose notifications set the compliance clock. The general obligations for AI systems are covered in DPDP Act 2023 and AI, and the definitions sit in the DPDP Act glossary entry.
The common failure is not malice, it is inheritance. Teams build the engine on an analytics event stream that was collected years earlier under a vague notice, for a purpose nobody documented, with no retention policy. The model is compliant in intent and the data feeding it is not.
Obligation by obligation: what each one means for ranking
Read this table as a build specification. Each row is an obligation, its practical consequence for a recommendation engine, and the control we implement to satisfy it.
| DPDP obligation | What it means for a recommendation engine | Control that satisfies it |
|---|---|---|
| Notice and consent for a stated purpose | Personalisation must be named, not folded into general service improvement | A consent service that stamps every event with a purpose flag at capture |
| Purpose limitation | Events gathered for personalisation cannot quietly train a pricing or credit model | Purpose tags enforced at the feature store boundary, not by convention |
| Data minimisation | Rank on behaviour and catalogue attributes, not on identity documents or sensitive categories | A field-level allow list in the versioned event schema |
| Correction and erasure | A deletion request must clear the user from events, features and future training sets | An erasure job with a tracked completion time across every store |
| Withdrawal of consent | The engine must fall back to non-personalised ranking for that person immediately | A runtime consent check inside the serving path, not a nightly batch |
| Reasonable security safeguards | Behavioural logs need the controls you give your primary database | Encryption at rest and in transit, RBAC, network isolation, access logging |
| Breach reporting | You must be able to say what the event store held and who could read it | A data inventory, a retention policy and an immutable access audit trail |
| Children's data | No behavioural tracking or targeted advertising to children, with verifiable parental consent | An age signal on the consent record and a hard bypass in the serving path |
The four places personal data sits in a ranking system
Most erasure requests fail because teams delete from one store and assume the rest followed. A recommendation engine holds personal data in four distinct places, each with its own deletion mechanics.
The raw event log
Clickstream, views, searches, cart actions and impressions, usually in object storage or a warehouse, partitioned by date. This is the largest store and the easiest to forget. Set a retention window per event type, keep aggregates longer than raw rows, and make deletion a partition rewrite rather than a row-by-row scan you never run.
The feature store
Derived signals keyed by user: affinity vectors, recency and frequency counters, segment memberships. Erasure must clear these too, and because features are recomputed on a schedule, a deletion that does not also block regeneration will silently restore the user next cycle.
Model artefacts
Embeddings and factorised matrices can encode an individual's behaviour. You cannot surgically remove a person from a trained model, so the practical control is a retraining cadence short enough that erased users disappear within a stated period, and a written statement of that period in your privacy notice.
Serving and impression logs
What the engine showed, to whom, at what time, with which model version. These logs are how you answer a grievance or an audit, so they need audit log discipline: append-only, access-controlled and retained deliberately rather than by accident. Apply PII redaction to anything that leaves this boundary for debugging.
Security controls beyond the letter of the law
The DPDP Act requires reasonable security safeguards without enumerating them, which means you are judged against recognised practice. The OWASP Top Ten remains the baseline a security reviewer will expect a web-facing recommendation service to have addressed. These are the controls we put into every personalisation build.
- Tenant and user isolation in the serving path. A recommendation API that accepts a user identifier from the client will eventually be asked for someone else's profile. Derive identity from the session token, never from a request parameter.
- Row-level access on the warehouse. Analysts need aggregates, not individual behavioural histories. Row-level security keeps the event store usable without making it browsable.
- Separate environments with synthetic data. Production behavioural data does not belong in staging. Generate synthetic sessions for load and integration tests.
- Encrypted export paths. Feeds to email platforms, ad networks and messaging providers are where personalisation data usually leaks. Inventory every outbound feed and name its purpose.
- Access logging with retention. You cannot report a breach you cannot reconstruct. Log reads of the event store, not only writes.
- Vendor review before integration. A managed recommender is a processor holding your behavioural data, so its region, sub-processors and deletion guarantees belong in the contract.
Where should behavioural data live?
The Act permits transfer outside India except to territories the government restricts, so residency is usually a commercial commitment rather than a statutory one. In practice, Indian banks, insurers, hospitals and large enterprises ask for it anyway, and they ask late in procurement when changing it is expensive. Decide the region before the first event is written; retrofitting data residency means rebuilding the pipeline. Our approach to hosting, isolation and evidence is set out on the security page, and the commercial side is covered in recommendation engine development in India.
What compliance adds to cost and timeline
Consent plumbing, purpose tags, erasure jobs and audit logging add roughly two to three weeks to a personalisation programme when they are designed in from the start, and considerably more when they are retrofitted. Eazyware builds personalisation engines from $21,000 or ₹13,60,000, ranging to $70,000 or ₹46,40,000 for multi-surface systems, with these controls in scope rather than priced as an extra. Starting figures are published on the pricing page.
Compliance is not a launch event. Retention windows have to run, erasure jobs have to complete, and access reviews have to happen. A care plan from $1,000 or ₹68,000 a month covers the recurring work, including retraining cadence, which is the control that governs how long an erased user persists in model artefacts.
When compliance-first design is the wrong emphasis
If you are ranking anonymous sessions with no login, no identifier that persists across devices and no profile, you are largely outside the Act's personal data definition, and building consent infrastructure before you have a product is premature. Ship the session-based ranker, and add the consent layer when you add accounts.
If you are running a four-week proof of concept on historical, aggregated data in a controlled environment, full production controls will consume the sprint. Use a limited data set, a short retention window and a written scope note instead, then build properly if the proof succeeds.
And be honest about where the risk actually is. A recommendation engine ranking product tiles is a lower-risk system than a scoring model that decides credit or eligibility. Spend the governance effort proportionately; treating every model as a high-risk one usually means the genuinely risky one gets no more scrutiny than the rest.
What this looks like on a real build
On a D2C personalisation and WhatsApp engagement, the messaging surface drove the compliance design more than the ranking did. Messaging consent, opt-out handling and the record of what was sent to whom needed to hold up months later, and the behavioural store had to honour deletion across both web and messaging identities. The programme is described in the D2C personalisation case study.
The checklist
- Name personalisation as a purpose in your consent notice, in plain language
- Stamp every captured event with a purpose flag and a consent version
- Publish a retention window per event type and enforce it with a scheduled job
- Build erasure as one job covering events, features, training sets and exports
- Check consent at serving time, with a non-personalised fallback ranking
- Fix the data region before the first event is written
- Apply RBAC and row-level security to the behavioural warehouse
- Inventory every outbound feed to ad, email and messaging platforms
- Set a retraining cadence short enough to honour your stated erasure period
- Review access logs and vendor sub-processors on a named quarterly date
Related reading
Build or buy in recommendation engine development covers how compliance changes when a vendor holds the behavioural data, event pipelines explains the capture layer these controls attach to, and how to measure recommendation engine development shows why impression logs earn their retention cost twice over.
The DPDP Act does not ask you to stop personalising; it asks you to be able to say what you collected, why, for how long, and how someone gets out, which is a specification, not an obstacle.
Frequently asked questions
Is a recommendation engine compliant with India's DPDP Act?
▾
It can be. The Act requires notice and consent for a named purpose, retention limits, and rights of correction and erasure. A recommendation engine satisfies these when personalisation is named in the notice, events carry purpose tags, deletion reaches the feature store and training data, and consent is checked at serving time.
Does behavioural data for personalisation have to stay in India?
▾
Not as a general rule. The DPDP Act permits transfer outside India except to territories the government restricts. Many Indian enterprises and regulated buyers still require in-country regions contractually, so decide residency before the event pipeline is built rather than during procurement.
How do you delete a user from a trained recommendation model?
▾
You cannot remove an individual from a trained model surgically. The practical control is deleting the person from the event log, the feature store and future training sets, then relying on a retraining cadence short enough that their influence disappears within the period stated in your privacy notice.