DPDP Act and the 2027 Plan: Budgeting for the May 2027 Obligations

Budgeting for the DPDP Act's May 2027 obligations means funding six specific build items — notice, consent, breach reporting, children's data handling, cross-border transfer controls, and a Data Principal rights-request workflow — as a named line in the 2027 plan, not an assumed absorption into an existing compliance budget. The obligations bind on 13 May 2027 under the commencement notification the government issued in November 2025. For most organizations building a 2027 budget now, that date falls inside the year being planned, not safely beyond it.

Why This Is a 2027 Budget Line, Not a 2026 One or a "Later" One

We have covered the DPDP Act's actual phase-in dates in detail in Most Compliance Content Says India's DPDP Act Already Applies. It Doesn't — Not Yet. — the short version: a government notification dated 13 November 2025 phases the Act into force in three tranches, and the substantive Data Fiduciary obligations most organizations associate with the Act do not bind until the third tranche, 13 May 2027. That date sits inside the 2027 fiscal year for almost every organization's calendar, which means the build work has to be funded, staffed, and largely finished before the year most budgets treat as "this year" is even half over. A budget planning cycle that treats DPDP readiness as a 2028 problem, or as something the existing privacy or legal budget will absorb without a dedicated line, is planning against a date that has already moved inside the window.

Six Obligations, Six Build Items

Each of the six substantive obligations that bind on 13 May 2027 reads like a single compliance checkbox. Each is actually a build item with its own engineering and process cost, and budgeting for "DPDP compliance" as one number instead of six undercounts what the work actually requires.

• Notice — a notice mechanism that actually fires at the point of data collection, in the required form, not a privacy policy page assumed to satisfy the requirement by existing.
• Consent — a consent-capture flow that records a specific, informed, unambiguous affirmative action, with a working withdrawal path, not a pre-ticked checkbox retrofitted to look compliant.
• Breach reporting — a detection-to-notification pipeline with a defined SLA, a tested runbook, and a named owner, not a plan to figure out the process after the first real incident.
• Children's data handling — an age-verification or parental-consent mechanism that holds up to scrutiny, not an assumption that a self-reported birthdate field is sufficient.
• Cross-border transfer controls — a data flow map that actually reflects where personal data of Indian residents travels today, not a diagram last updated for a different regulatory review.
• Data Principal rights — a request-intake and fulfillment workflow that can find, produce, correct, or erase a specific person's data inside a defined turnaround, not a support-ticket queue repurposed at the last minute.

Why This Undercounts Easily

Each of the six items above sounds like a feature a product team could ship in a sprint. None of them is, because each one is a standing operational commitment, not a one-time build. A breach-reporting pipeline that works once, in a tabletop exercise, is not the same as one that holds up at 2 a.m. during a real incident with the SLA clock already running. A consent-withdrawal path that exists in the codebase but was never load-tested against actual user volume is not the same as one that works on 13 May 2027 under real traffic. Budgeting the engineering cost of building each mechanism without budgeting the ongoing cost of operating it — monitoring, periodic testing, staffing the rights-request queue — is the most common way a DPDP budget line comes in short.

Where This Fits in the 2027 Planning Cycle

Picture an organization building its 2027 AI and data budget in Q4 2026, the same planning season this budget line needs to be set in. If the six DPDP build items are not named individually, with an owner and a cost estimate for each, they tend to collapse into a single rounded-up "compliance" number that nobody can defend when a steering committee asks what it actually covers. Naming each of the six separately — even at a rough estimate — produces a number a CFO can interrogate line by line, and surfaces which of the six already has partial infrastructure to build on (a support queue that could become the rights-request workflow) versus which needs to be built from nothing (most organizations' cross-border transfer map).

What to Decide Before the Budget Locks

Three decisions belong in this specific planning cycle, before the 2027 number is finalized. First, name an owner for each of the six build items individually — not one person accountable for "DPDP compliance" as an undifferentiated whole. Second, confirm each item's cost estimate includes both the one-time build and the recurring operational cost, not just the build. Third, set a target completion date for each item that leaves real margin before 13 May 2027, not a date that assumes zero slippage across six parallel workstreams competing for the same engineering capacity.

The AI Regulatory Compliance Risk Register provides the tracking layer this planning cycle runs on: a Compliance Gap Register pre-seeded with 30 requirements, including the India DPDP obligations, each with a status, owner, evidence, and target-date field, plus a Regulatory Timeline tab that auto-calculates days remaining to 13 May 2027 and a Board Summary Dashboard that rolls every gap into a single Regulatory Deadline Alert.

→ Available at www.viksya.com