DPDP: 70 days to the November 2026 inflection

Mid-November is about ten weeks away, and it is the date India's Digital Personal Data Protection regime stops being a document you read and starts being a system you operate. Around 13 November 2026, the Consent Manager framework comes into force and the initial soft-enforcement phase ends. The Data Protection Board of India shifts from awareness-building to active supervision. If your compliance plan is still a policy PDF and a to-do list, the next ten weeks are the ones that matter.

We have written before on what the DPDP Act asks of a software build and on sharing data with vendors under DPDP. This piece is narrower and more urgent: what the November inflection actually changes, and what to do about it before it lands.

The timeline, without the ambiguity

The Ministry notified three enforcement dates, and they are worth writing down plainly:

• 14 November 2025 brought the first set of provisions and definitions into force.
• Mid-November 2026 operationalises the Consent Manager framework and ends the soft-enforcement window. This is the inflection.
• Mid-May 2027 is when the principal substantive obligations commence and full compliance is expected, closing an 18-month implementation phase.

The mental model most teams got wrong: they treated 2027 as the deadline and 2026 as free time. It is not free time. 2026 is the build-and-test year the regulator handed you, and mid-November is when the "test" part ends and the Board starts watching. May 2027 is when the fines have teeth. The work has to be done before the watching starts, not before the fines do.

What the November inflection actually changes

Three things move at once.

Consent Managers become real infrastructure. The framework that lets a data principal grant, review, and withdraw consent through a registered intermediary is no longer a concept in the rules. If your product collects personal data from Indian users, your consent notice, your consent records, and your withdrawal flow now have to interoperate with that framework, not just exist as a checkbox.

The Board starts supervising. Through the soft phase, the posture was guidance. After the inflection, the Data Protection Board is expected to move toward active regulatory supervision. The difference between "we are drafting our consent flow" and "our consent flow is in production and audited" stops being cosmetic.

The grace period stops being an excuse. A regulator that gave you 18 months to build has a weaker tolerance for "we have not started" in month twelve. The teams that used 2026 to build will be visibly different from the teams that used it to plan.

Why most of this is a build, not a policy

The trap in DPDP readiness is treating it as a legal exercise that ends in a PDF. The legal exercise is necessary and it is the easy 20 percent. The other 80 percent is engineering that has to actually work:

• A consent notice and record system that logs what was consented to, when, and under which version of your notice.
• A withdrawal path that propagates, so a withdrawn consent actually stops the downstream processing and does not just flip a flag.
• Data-principal rights handling: access, correction, and erasure requests served within the timelines, across every system that holds the data.
• Breach notification wired to detection, not to a quarterly review.
• Retention limits enforced in the schema, so data expires because the system deletes it, not because someone remembered to.
• Vendor and API data-sharing brought under agreements and technical controls, which is where most Indian companies have the largest gap.

None of that is a clause in a privacy policy. All of it is a system that either exists in production by mid-November or does not.

The next ten weeks, in order

1. Map the personal data. Where it enters, where it flows, where it rests, and which vendors touch it. You cannot govern what you have not mapped, and this is usually a two-week job that teams keep deferring.
2. Stand up the consent and withdrawal system. Notice, record, and a withdrawal path that actually propagates. This is the load-bearing build.
3. Wire the data-principal rights flows. Access, correction, erasure, on a clock, across systems.
4. Close the vendor gap. Agreements plus technical controls on every API and integration that shares personal data.
5. Instrument it. Breach detection, retention enforcement, and an audit log a regulator could actually read.

Ten weeks is enough for a focused team to do this properly. It is not enough to start in November.

Where build-versus-buy tilts

Regulated workflows change the build-versus-buy math, and DPDP is a clean example. A consent-management SaaS looks cheaper on the sticker, but the regulated version of the total cost includes the vendor's own data-processing agreement, the audit overhead of proving what that vendor does with the data, and the reality that a per-vendor consent record you do not control is a record you cannot fully attest to. Build wins earlier than the sticker suggests, because the compliance overhead the SaaS math hides is real and it lands on you regardless. See designing compliant data products.

How we help before mid-November

A two-week Strategy engagement ships a written memo: your data map, your gap list against the November and May obligations, and a prioritised build plan with a number and a window on each item. If the gaps are a build, we scope the build fixed-price. If they are mostly policy and configuration, we tell you that and hand you the plan. Either way you walk into the inflection with a system in progress rather than a slide about one.

The countdown that was 11 months in the spring is 10 weeks now. Run your own exposure first with the DPDP penalty calculator, then map the data. Everything downstream depends on the map.

Read more: /strategy/ · DPDP 101 · DPDP 2026 field guide · DPDP penalty calculator