On 13 November 2026, one rule of India data protection regime switches on. Two months out. Most of the coverage around it reads the date as the day Indian companies have to start routing consent through a Consent Manager. That is not what the date does.
What comes into force is Rule 4 of the Digital Personal Data Protection Rules, 2025, which is the registration route for an entity that wants to be a Consent Manager (Rule 4 text). It opens a door for a small set of applicants. It places no new obligation on an ordinary Data Fiduciary on that date. If you run a 20-person SaaS company in Bengaluru, nothing you own breaks on 13 November 2026.
This is written for the founding engineer or CTO of a 10 to 60 person Indian company who has seen the date in a newsletter and wants to know what to actually do. The honest answer is that the date that binds you is 13 May 2027, that the work between here and there is engineering rather than paperwork, and that the eight months in between are the cheapest window you will get. Below is what switches on when, what the Rules require you to produce, and what it costs.
Where this stands in September 2026
The Rules were notified on 13 November 2025 and carry a phased commencement rather than a single switch (Digital Personal Data Protection Rules, 2025). Phase one landed on notification day and covered definitions and the provisions establishing the Data Protection Board. Phase two is Rule 4, at twelve months, which is 13 November 2026. Phase three is the substantive body of the Rules at eighteen months, which is 13 May 2027 (Sansa Legal timeline).
Phase three is the one with your name on it. Notice under Rule 3, security safeguards under Rule 6, breach notification under Rule 7, retention and erasure under Rule 8, and the Data Principal rights machinery all begin on the same day, with no staggering inside that date. Most regimes give you a soft start. This one hands you eighteen months and turns everything on at once, so the only sequencing that exists is the sequencing you build yourself.
1. What 13 November 2026 actually switches on
Rule 4 sets out how a person registers with the Board as a Consent Manager and what that registration binds them to. The eligibility floor sits in Part A of the First Schedule and includes incorporation in India and a minimum net worth of two crore rupees, alongside demonstrated technical and operational capacity (Tsaaro on Consent Manager obligations). Part B carries the operating obligations: run an interoperable platform, do not sub-contract the obligations, avoid conflicts of interest with Data Fiduciaries, and keep records of consents, notices and sharing for seven years.
Read the net worth line and the seven-year record line together and the shape becomes clear. This is a licensed-intermediary regime, deliberately narrow. It is built for a handful of registered operators, not for every company that collects an email address. The twelve-month gap before Rule 4 exists so the Board can be seated and process a first tranche of applications.
Takeaway: unless you intend to apply to be a registered Consent Manager, 13 November 2026 is a date to know, not a date to build for.
2. The registrar is still being staffed, and that is your window
There is a gap worth naming plainly. The counterparty that registers Consent Managers is the Data Protection Board of India. MeitY issued a notification dated 6 May 2026 inviting applications for the Chairperson and Members of the Board (nasscom, MeitY notification). Reporting through mid-2026 described the Board as existing in statute while still being constituted in practice (LiveLaw).
The useful way to read that is not as a reprieve. Enforcement capacity arrives late and then arrives fully, and the obligations it enforces are dated in the Rules already. What the gap gives you is a build window at the cheapest price this work will ever carry, while your data volume is small and your integrations are few.
Takeaway: treat the staffing lag as eight months of engineering runway, and spend it on the data model rather than on watching the news.
3. The sentence in Section 6 that makes this engineering
Section 6 of the Act is where consent stops being a legal topic and becomes a schema question. Section 6(7) says a Data Principal may give, manage, review or withdraw consent through a Consent Manager. The load-bearing part sits just above it: where consent is the basis of processing and a question arises in a proceeding, the Data Fiduciary is obliged to prove that a notice was given and that consent was given in accordance with the Act (Section 6).
That is a burden of proof, placed on you, discharged with evidence. A boolean column named marketing_opt_in cannot discharge it. It cannot tell you which notice text the person saw, in which language, at which version, at which timestamp, for which purpose, or what happened when they later withdrew. Most consent implementations I look at store the answer and throw away the question.
Takeaway: the requirement is not that you collect consent. It is that you can reconstruct, years later, exactly what was shown and exactly what was agreed.
4. The consent record is a data model, not a checkbox
Build the record as an append-only event log, not a mutable flag. In practice that means a consent artefact carrying: a principal identifier, a purpose identifier scoped to one purpose and not bundled, the notice version and language shown at the moment of collection, the timestamp, the collection channel, the resulting state, and, where relevant, the Consent Manager identifier through which it arrived. Withdrawal is a new row, never an update in place, because the history is the evidence.
Two design choices pay for themselves. First, version your notice text and store the version identifier on the artefact rather than the prose, so a notice change does not rewrite history. Second, make the purpose identifier the join key your downstream jobs read, so a revoked purpose stops a pipeline instead of relying on a human to remember. The Rules point at machine-readable, auditable consent records for the registered intermediaries (AZB on Consent Managers), and the same shape is what makes your own record provable.
Takeaway: if withdrawing consent in your product does not mechanically change what a batch job is allowed to read, you have a UI, not a consent system.
5. Rule 6 turns your logging into a legal artefact
Rule 6 sets the reasonable security safeguards a Data Fiduciary owes, and it is specific enough to check yourself against. It covers securing personal data through measures such as encryption, obfuscation or masking, access control, monitoring and logging of access to personal data, and documented incident response, with a one year floor on retaining the relevant logs (Rule 6 text, K and K on Rule 6).
The log line is the one most teams get wrong. A default CloudWatch or Cloud Logging retention of 30 or 90 days is a cost decision someone made in year one. Under Rule 6 the same setting becomes the reason you cannot answer a question about access to personal data eleven months later. Fixing it is a retention policy change plus a lifecycle rule to cheap storage, an afternoon of work. Leaving it is an evidence gap that shows up on the day it costs most.
Takeaway: set the retention on every log that records access to personal data to at least thirteen months today, and archive rather than delete.
6. Rule 7 is an evidence problem wearing a deadline
Rule 7 splits breach notification in two. Affected Data Principals are told without delay, in their own terms. The Board is told without delay with the initial particulars, covering the nature, extent, timing and location of the breach and its likely impact, followed by a detailed report within seventy-two hours, extendable on request (Rule 7 text).
Seventy-two hours is generous on paper and brutal in practice, because the clock runs on the hardest question in incident response: which records, belonging to which people, were actually reached. Teams that can answer in three days have usually done one thing in advance: tagged personal data at the storage layer and kept access logs joinable to a principal identifier. Teams that cannot end up guessing, and a guess submitted to a regulator is worse than the breach. This is the same discipline the RBI directions already push onto Indian vendors, covered in what the 2026 RBI Cybersecurity Directions flow down to vendors.
Takeaway: rehearse the question once before May 2027: pick a table, and see how long it takes you to list the affected people from logs alone.
7. Rule 8: erasure on a clock, and the 48 hour warning
Rule 8 requires erasure once the purpose is no longer served, and the Third Schedule attaches fixed periods to named classes. Reporting on the Schedule puts the period at three years from last interaction for classes such as large e-commerce and online gaming entities above the stated user thresholds, unless the person re-engages (Rule 8 text, K and K on retention and erasure).
The part almost nobody has built is the notice. At least forty-eight hours before that period completes, you have to tell the person their data will be erased unless they log in, contact you for the specified purpose, or exercise a right. That is a scheduled job reading a last-interaction timestamp, a templated message, and an audit record proving it was sent. Small, invisible until the date arrives, and not retrofittable in a week, because it depends on having a trustworthy last-interaction timestamp.
Takeaway: even if the Third Schedule classes do not cover you, build the last-interaction timestamp now, because every retention rule you will ever face reads from it.
8. India already runs a consent network, and it is the closest template you have
The Consent Manager idea is not theoretical here. The RBI Account Aggregator framework has run a live consent-brokerage network for years, in which an intermediary carries consent artefacts and moves encrypted financial data it cannot itself read. Sahamati has argued that the two regimes can be read together by registering Account Aggregators as Consent Managers for the financial sector, and that the Board should adopt the existing ReBIT standards for financial data rather than write new ones (Sahamati). The overlap and its unresolved edges have been picked apart in legal commentary through 2026 (SCC Online).
For a builder the value is that a working reference implementation of consent-as-artefact already exists and is documented: the consent object, its lifecycle states, and the blind-pipe property are things you can study rather than invent. The architecture side of that network, and where it breaks, is in the Account Aggregator cloud architecture post.
Takeaway: model your consent artefact on the AA artefact even if you never touch financial data, because it is the only Indian design already tested at scale.
9. The penalty table, read the way a Board will read it
The Schedule to the Act sets ceilings, not fixed fines. The highest, up to 250 crore rupees, attaches to a failure to take reasonable security safeguards to prevent a breach. Failure to notify a breach and failure on children data obligations each carry up to 200 crore rupees. Additional Significant Data Fiduciary obligations carry up to 150 crore rupees, and a residual band of up to 50 crore rupees covers any other breach of the Act or Rules (the Schedule).
Practitioner opinion: the number that matters for a small Indian company is not 250 crore. It is that the two largest bands point at the same engineering surface, safeguards and breach handling, which is Rules 6 and 7. A Board setting a figure case by case looks at what you had in place and what you could produce. Documented controls and retrievable logs are the difference between an incident and an aggravating factor, and both are built, not bought.
Takeaway: spend on Rules 6 and 7 first, because that is where both the largest ceilings and the cheapest mitigations sit.
10. What this costs, and where the money actually goes
Published estimates vary widely and come from consultancies and vendors selling into the deadline, so read them as ranges, not quotes. One roadmap puts indicative consulting budgets at 3 to 4 lakh rupees for small companies and 5 to 7 lakh for mid-market (TCSA). Another breakdown puts a typical 50-person Indian SME at roughly 5 to 15 lakh in first-year cost with 3 to 8 lakh recurring (Consently). KPMG has published implementation guidance on the Rules that is worth reading before any of the vendor material (KPMG guidance).
Practitioner opinion on where the money goes: for a team under about 30 engineers, the large line items are not legal fees and not a consent platform licence. They are the data mapping exercise that tells you where personal data actually sits, and the engineering time to make erasure and access logging real across services that were never built for either. Buying a consent banner before doing the mapping is the most common way to spend money and still fail the burden of proof in Section 6.
Takeaway: do the data map first. Every other cost in the programme gets smaller or larger depending on what it finds.
The summary, in one table
| Date or rule | What it does | Does it bind a normal startup | What you build |
|---|
| 13 Nov 2025 | Rules notified, Board provisions live | Already passed | Nothing directly |
| 13 Nov 2026, Rule 4 | Consent Manager registration opens | No, unless you are applying to be one | Nothing directly |
| Section 6 | You must prove notice and consent were given | Yes, from 13 May 2027 | Append-only consent artefact, versioned notice |
| Rule 3 | Notice standards, itemised and plain language | Yes, from 13 May 2027 | Versioned notice text per purpose and language |
| Rule 6 | Security safeguards, logs kept one year | Yes, from 13 May 2027 | Encryption, access control, 13 month log retention |
| Rule 7 | Breach notice to person, 72 hour report to Board | Yes, from 13 May 2027 | Personal data tagging, joinable access logs |
| Rule 8 and Third Schedule | Erasure on a clock, 48 hour advance notice | Yes, from 13 May 2027 | Last-interaction timestamp, scheduled erasure job |
| The Schedule to the Act | Ceilings up to 250 crore rupees | Yes, from 13 May 2027 | Documented controls and retrievable evidence |
Where to start, by stage
Pre-product or a few thousand users. Do the data map and nothing else this quarter. One spreadsheet listing every store that holds personal data, what is in it, why, and who can read it. Then set log retention to thirteen months. Both are free and both are prerequisites for everything below.
Growing, with real users and several integrations. Build the consent artefact as an append-only table with a purpose identifier, and make one downstream job actually read it. One job proves the wiring works. Add the last-interaction timestamp while you are in the schema. Write the incident runbook that answers who was affected, and test it once against a real table.
Scaling, with volume that could put you near Significant Data Fiduciary territory. Add the scheduled erasure job and its 48 hour notice, get access logging joinable to a principal identifier across services, and commission an independent review of the consent flow before May 2027 rather than after. If you process children data or operate at the user thresholds in the Third Schedule, read the SDF obligations closely now, because the additional duties carry their own 150 crore band.
The eight months are the whole opportunity
The date in the headline is real but it is not yours. Yours is 13 May 2027, and between now and then you have the rarest thing in compliance work: a known deadline, a published rule text, and no enforcement pressure while you build. Teams that use it will land on a consent model that fits their schema. Teams that wait will buy one that does not.
If you want a second pair of eyes on where personal data actually sits in your stack and what the Rules will ask you to produce, the free cloud and security checklist is the fastest starting point: open the checklist. It is the same first pass I run before any DPDP readiness work.
About the author
Avinash S is the founder of MatrixGard, a fractional DevSecOps practice for early-stage startups, funded or bootstrapped. He works as the cloud, infrastructure and security function for teams that do not yet have one in-house, across India, Singapore, the UAE, the UK and the US.
Methodology note
Every date, rule number and penalty band in this post is drawn from the Digital Personal Data Protection Rules, 2025 and the Schedule to the Digital Personal Data Protection Act, 2023, with each claim linked to its source at the point it is made. The Board staffing position is drawn from the MeitY notification of 6 May 2026 and reporting through mid-2026, described as reported rather than confirmed current state. Cost figures are published estimates from named consultancies and vendors, quoted as attributed ranges, not quotes for any engagement. Where a view is mine rather than a sourced fact it is labelled Practitioner opinion. No client outcome, audit count or engagement figure appears anywhere in this post. Rule numbering follows the Rules as notified on 13 November 2025; confirm against the official text before acting.
