At Bluelupin we are working with multiple organizations on their DPDP goals. Across those engagements, the pattern is consistent: policy text and consent banners move first; the systems that prove notice, consent, purpose, erasure, and breach readiness lag.
DPDP implementation is a build-and-evidence problem for platforms that determine purpose and means of processing digital personal data. This post is the engineering checklist we use with those teams: what to ship before May 2027, and which artefacts show the work is real.
It is not legal advice. Engage counsel for SDF classification, children's products, and cross-border design. Bluelupin is an engineering partner for DPDP implementation, not a Consent Manager or a law firm.
Why this is a build problem now
MeitY notified the Digital Personal Data Protection Rules, 2025, and related Act-commencement instruments around 13 November 2025 (MeitY hub, Enforcement Notification G.S.R. 843(E)). The Board machinery started then. The rest is phased.
Treat two milestones as planning anchors. Exact calendar days of "publication + N months" can read as 13 vs 14 depending on the Gazette stamp, so do not invent a single day without counsel:
| Milestone | Rough date | What it means for platforms |
|---|---|---|
| Consent Manager phase | November 2026 (~12 months from the Nov 2025 notifications) | Consent Manager registration and related machinery under Rule 4 / Act s.6(9) |
| Core fiduciary duties | May 2027 (~18 months from those notifications) | Notice, consent proof, security, breach, rights, children, transfers, retention, and related Rules go live for operational compliance |
As of writing (September 2026), you sit between phases. The Board exists on paper. The Consent Manager window is near. May 2027 is still the hard prove-it line for core duties unless MeitY shortens timelines by a fresh Gazette. Industry press has floated acceleration ideas. Treat those as not-yet-law until they appear in the Official Gazette.
Until Act s.44(2) commencement in that +18-month phase, plan for a dual regime with SPDI Rules / IT Act s.43A as well. Do not drop existing security obligations early.
Map obligations to product surfaces
If your team only debates statute sections, you will ship policy PDFs. Map each duty to something a user touches or an engineer can demo.
| Obligation (Act / Rule) | What to ship | What you must be able to prove |
|---|---|---|
| Lawful ground: consent or enumerated "certain legitimate uses" (ss.4, 6, 7) | Purpose registry with a lawful-basis tag per purpose | No processing without a tagged ground |
| Notice (s.5; Rule 3) | Standalone plain-language notice (itemised data, purposes, withdraw/rights/Board links; Eighth Schedule language option) | Notice shown at the right time, including retroactive notice for pre-commencement consent |
| Consent quality + burden of proof (s.6, especially s.6(10)) | Affirmative, purpose-limited capture; withdrawal as easy as grant; cease cascade to processors | Immutable consent/notice receipts |
| Purpose end / retention / erasure (s.8(7)-(8); Rule 8) | TTL jobs, withdrawal erase cascade, schedule-specific clocks where you qualify | Timed erasure evidence and 1-year processing-log retention where Rule 8(3) applies |
| Data Principal rights + grievance (ss.11-14; Rule 14) | Authenticated DSR portal + ticketed grievance with ≤90-day SLA | Request logs, identity checks, completion evidence |
| Security safeguards (s.8(5); Rule 6) | Encryption/masking/tokens, access control, monitoring, backups, processor contract clauses | Security-relevant logs retained ≥1 year |
| Breach (s.8(6); Rule 7) | Detect → notify affected principals without delay; Board initial intimation without delay; detailed Board pack within 72 hours | Runbook timestamps and packed evidence |
| Processors / vendors (s.8(1)-(2); Rule 6(1)(f)) | Written DPAs, security flow-down, kill switches for pixels/SDKs | Processor register + erase-on-instruction trails |
| Cross-border (s.16; Rule 15; Rule 13(4) if SDF) | Transfer inventory + watch process for Govt orders | Map of where personal data leaves India |
| Children (s.9; Rules 10-12) | Age gate + verifiable parental consent; no tracking/behavioural ads at children unless a mapped Fourth Schedule exemption | Diligence narrative counsel can defend |
India-based product companies serving Indian users are usually Data Fiduciaries for first-party product data. The same entity may be a Processor for B2B customers. Do not blur that in contracts or UI copy.
Data map and purpose registry as the spine
Every later control hangs off one spine: what personal data you hold, for which purpose, on which lawful ground, in which systems, shared with which processors.
Without that registry, consent banners lie. Retention jobs miss lakes. Access summaries invent sharing maps. Erasure tickets become theatre.
Build a living purpose registry, not a one-off spreadsheet. Per purpose, record data categories, collection surfaces, lawful ground (consent vs a specific s.7 use), retention trigger, processors, and product owner. Kill orphan purposes. Tag secondary uses that never got a fresh ground.
When teams skip the purpose registry, they spend the next year bolting compliance features onto an undocumented estate, and that usually fails the first Board-style evidence ask.
Consent UX that produces an audit trail
A banner that returns true is not enough. Under s.6(10), the Fiduciary bears the burden of proving notice and consent in proceedings. Design for receipts.
Ship:
- Purpose-scoped notices, independent of other fine print (Rule 3).
- Affirmative action per purpose where consent is the ground. No pre-ticked packs that bundle unrelated uses.
- Withdrawal that is as easy as grant, with a timed cease cascade to every processor and marketing pixel (s.6(6)).
- Machine-readable consent receipts: principal id (or token), purpose ids, notice version, timestamp, channel, locale.
Consent Managers become an optional channel after the November 2026 registration phase. They are Board-registered intermediaries for give/manage/withdraw flows. Integrate if your product needs that path. Do not wait for a CM to invent your ledger. Own the proof yourself.
Children's flows are a hard gate: child means under 18. "Tick parent" without verifiable adult ID or authorised token diligence will not survive Rule 10. Map Fourth Schedule exemptions with counsel before you ship kids features.
Shipping Data Principal rights without a ticket black hole
Rights under ss.11-14 are not a shared inbox. Principals need published means to request access (including a sharing map), correction, erasure, and nomination. Grievance redressal must respond within 90 days (Rule 14(3)). They must exhaust Fiduciary grievance before going to the Board.
What fails in practice (industry pattern, not a MeitY FAQ): erasure stops at CRM. Data lakes, logs, backups, and vendor copies stay untouched. Access summaries omit subprocessors. Identity verification either blocks honest users or lets account takeover through.
Ship a DSR orchestration path: authenticate, scope systems, fan out to services and vendors, assemble an evidence pack, and close with a published contact (DPO if SDF, otherwise the answering person) on the site/app and in every response (s.8(9); Rule 9).
Measure the 90-day clock. If you cannot graph it, you do not have an SLA.
Vendor and cross-border controls you can operate
You remain liable for processing done by a processor on your behalf (s.8(1)). Contracts are mandatory for that processing (s.8(2)). Security safeguards must flow down (Rule 6(1)(f)).
Operate a processor register: who holds what, under which DPA, with what erase and breach escalation clauses. Inventory pixels and SDKs the same way. Orphaned tags after withdrawal are a classic gap.
Cross-border under DPDP is not a GDPR adequacy/SCC carbon copy. Default posture is transfer allowed unless the Government restricts (s.16) or sets requirements when data is made available to a foreign State or agency (Rule 15). SDF entities may later face India-localisation for Government-specified categories (Rule 13(4)).
Build a transfer inventory and a watch process for Gazette orders. Do not pretend the restriction list is empty forever. Do not invent localisation duties before an SDF notification and category list exist.
Breach readiness that matches Rule 7
GDPR muscle memory ("notify if high risk") will mislead you. Rule 7 expects:
- Notify affected Data Principals without delay (nature, extent, timing, consequences, mitigations, safety tips, contact) via account or registered channel.
- Intimate the Board without delay.
- Send a detailed Board pack within 72 hours (facts, cause, mitigations, who caused it, recurrence fixes, principal-notification report).
Pair that with Rule 6 security controls that actually run: encryption or equivalent, access control, monitoring, backups, and ≥1 year retention of security-relevant logs and related personal data.
If you mention Schedule penalties at all, frame them correctly: they are maxima after Board inquiry into a significant breach, not automatic fines (e.g. security up to ₹250 crore, breach-notice / children up to ₹200 crore, SDF up to ₹150 crore, residual up to ₹50 crore per the Act Schedule). Prefer fixing the runbook over leading with fear.
If SDF might apply: design for auditability
Significant Data Fiduciary status is a Government notification under s.10, not a self-label. As of September 2026, no public SDF class list was located. Do not market yourself as SDF. Do not sell "SDF-ready" as if designation already landed.
Still design for auditability: India-based DPO operating model (if ever designated), DPIA methodology, independent audit scoping, algorithmic diligence checklist, hooks for Rule 13(4) localisation lists. Activate on notification. Keep those artefacts out of marketing claims until then.
Pre-May 2027 build sequence
No fake hour estimates. Sequence by dependency and owner.
Phase A: Spine (now)
Eng + product + legal: Fiduciary vs Processor map per product surface. Data discovery. Purpose registry with lawful grounds. Kill orphan purposes and orphan pixels.
Phase B: Proof surfaces
Eng + product: notice + consent capture with immutable receipts. Withdrawal and erase cascade including vendors. DSR portal and grievance tooling with a measurable ≤90-day clock.
Phase C: Operate under load
Security + eng: Rule 6 controls and 1-year log retention in production, not only in a policy PDF. Breach runbook matching Rule 7 (without delay + 72h Board pack). Transfer register and Gazette watch.
Phase D: Contingent and schedule-specific
Legal + product: children's verification path or mapped exemptions. Third Schedule inactivity clocks if you qualify as a large intermediary class. Consent Manager adapter options after November 2026. SDF kit on shelf, not in the homepage.
Phase E: Dual regime until ~May 2027
Security + legal: keep SPDI / IT Act s.43A ownership until s.44(2) commencement. Monitor MeitY for timeline amendments, SDF notifications, transfer orders, and Board Consent Manager standards.
How to prove compliance
When someone says "we're ready," ask for artefacts:
- Purpose registry export with lawful-basis tags and owners
- Notice version history and sample renders (including Eighth Schedule locales you support)
- Consent ledger query for a test principal (grant, withdraw, cease-to-processor timestamps)
- Processor / pixel register with DPA pointers and kill-switch evidence
- DSR and grievance tickets with SLA clocks and completion packs
- Retention/erasure job logs for purpose-end and withdrawal
- Security log retention proof (≥1 year) and access-control attestations
- Breach tabletop report with timed Board-pack draft
- Transfer inventory and last Gazette-watch note
- Counsel memo on kids / SDF / cross-border open questions (not a blog post)
If those files do not exist, the banner does not either.
Closing
May 2027 is a ship date for notice, consent proof, security, breach, rights, children, retention, and transfers. November 2026 is when the Consent Manager ecosystem becomes real. Neither date is a reason to wait on the data map.
Bluelupin helps organizations implement DPDP controls in product and platform: purpose registry, consent receipts, DSR fan-out, vendor kill switches, and Rule 7 runbooks. If you want a working session against your stack, we can sit with your eng and product leads and walk the artefact list. We will not certify you "compliant." We will help you see what is still missing.
Again: this is not legal advice. Engage counsel before you claim SDF status, penalty exposure, or "fully compliant" marketing. Watch the MeitY DPDP Rules page for Gazettes that change timelines or designate SDFs.