Operating in India: three clocks are already running
If your organization operates in India — or processes personal data of people in India — three separate regulatory clocks are running right now, and they measure very different things. Most coverage treats them as paperwork. They're not. Each one is a test of something operational, and knowing what each clock actually measures is the difference between a compliance program and a filing cabinet.
Clock 1: DPDP — full compliance by May 2027
The Digital Personal Data Protection Act got its operational rules in November 2025, with phased deadlines: the Data Protection Board and penalty framework are live now, consent manager provisions arrive November 2026, and full substantive compliance — notices, consent, data principal rights, retention, breach protocols — lands May 13, 2027.
Two things worth saying plainly. First, there's no small-business pass on the basics: if you collect emails and phone numbers, you're in scope. Second, eighteen months only sounds generous. A typical compliance program of this shape takes 9–12 months of honest work — and everyone's deadline is the same date, which means the queue for experienced outside help forms early. The math is the same as any shared bottleneck: when everyone arrives at once, readiness is decided by who started, not who's smartest.
The breach mechanics deserve special attention: prompt notification to the Board and affected individuals, with a detailed report within 72 hours. That's an operational capability, not a policy paragraph.
Clock 2: CERT-In — six hours, and what it really measures
Since 2022, specified cyber incidents must be reported to CERT-In within six hours of being noticed, and ICT system logs must be retained for 180 days, within Indian jurisdiction.
Here's the reframe that I think matters most: the six-hour clock starts at noticing — which means it doesn't measure your paperwork, it measures your detection and reporting pipeline. If an employee who sees something strange doesn't know the one channel to report it through, your effective reporting time isn't six hours; it's never. The fix is unglamorous: one reporting channel everyone knows, a no-blame rule that's actually honored, and the CERT-In contact details printed into your incident response policy before you need them. The log rule has a similarly unglamorous implication — verify where your logs physically live and how long they're kept now, because you can't retroactively retain anything.
Clock 3: Tenders — ISO 27001 as a ticket, not a trophy
Government and PSU procurement in India increasingly lists ISO 27001 certification as a qualifying requirement — not a scoring bonus, a gate. Which changes what certification is: a sales asset with a lead time. Readiness, stage 1, stage 2, certificate — that chain takes months even when it goes smoothly, and it can't be compressed to fit a tender deadline you discovered last week.
If government work is in your plans, the honest move is to treat certification timing as a pipeline decision made by leadership — with costs and lead times on the table — rather than a scramble triggered by the first lost bid. The ISO page covers how to get there without building a paperwork empire.
The common thread
All three clocks reward the same underlying habits: knowing what data you hold and where (DPDP), detecting and reporting fast (CERT-In), and operating a system that produces evidence as a byproduct (ISO). Which is convenient, because those are the same habits the foundations build anyway. Regulation changes the deadline, not the work.
How this connects: seed your register from the India section of the risk library — the six-hour reporting gap and the log-residency gap are the two I'd check first. Put the May 2027 DPDP date in your leadership briefing as a dated decision, not a looming worry.
Dates current as of mid-2026 and this area moves quickly — verify against MeitY, CERT-In, and Gazette notifications before committing budgets. This is practitioner guidance, not legal advice.