If your business runs on cloud infrastructure in India, the DPDP Rules do not ask you to move everything into the country. They ask you to prove three things: you know where personal data sits, you can see who accessed it, and you can tell the regulator what went wrong within 72 hours of a breach. Most of that proof lives in your infrastructure, not in your privacy policy.
Two dates set the pace. On 13 November 2026, the Consent Manager framework comes into force. On 13 May 2027, almost every operational duty in the Rules becomes enforceable, including security safeguards, breach reporting, log retention, rights requests and the cross-border transfer rule. From today, that leaves about seven months.
Key takeaways
- DPDP has no blanket data localisation requirement. Sector rules, such as RBI's rule for payment data, and data the government later notifies for Significant Data Fiduciaries are the exceptions.
- Rule 6 sets minimum security safeguards: encryption or masking, access control, monitored logs, backups, and one year of log retention.
- A breach must be reported to the Data Protection Board of India without delay, followed by a detailed report within 72 hours. CERT-In separately expects listed cyber incidents within 6 hours.
- Your cloud provider is a Data Processor. You need a contract that requires security safeguards, and you stay accountable for what the provider does.
- The highest penalty, up to ₹250 crore, applies to failing to take reasonable security safeguards.
The DPDP timeline: three dates that matter
The Digital Personal Data Protection Rules, 2025 were notified through Gazette notification G.S.R. 846(E), dated 13 November 2025. Rule 1 does not switch everything on at once. It splits commencement into three stages, each counted from the date of publication.
- 13 November 2025 (already in force). Rules 1, 2 and 17 to 21: definitions, and the rules that set up the Data Protection Board of India. The Board works as a digital office, so complaints, hearings and orders happen online.
- 13 November 2026 (one year later). Rule 4: registration and obligations of Consent Managers.
- 13 May 2027 (eighteen months later). Rules 3, 5 to 16, 22 and 23: notices, security safeguards, breach intimation, retention and erasure, children's data, Significant Data Fiduciary duties, rights of individuals, cross-border transfers and appeals.
One detail on dates. The Gazette notification is dated 13 November 2025, while the government's PIB explainer says 14 November. Some advisers therefore count from the 14th. Planning to the earlier date costs you one day and settles the question.
What changes on 13 November 2026
Consent Managers become a regulated category. A Consent Manager is a platform that lets an individual give, review and withdraw consent across many businesses from one place, much like account aggregators do for financial data today.
The bar to register is deliberately high. The applicant must be a company incorporated in India with a net worth of at least ₹2 crore. Its platform must be independently certified against standards the Board publishes. It must keep consent records for at least seven years, and it must be built so that it cannot read the personal data passing through it.
For most businesses, this date is not a direct compliance deadline. It still matters for two reasons:
- Your systems need to listen. If your users start managing consent through a registered Consent Manager, your applications must receive consent and withdrawal signals from it and act on them. That is an integration job, and it usually touches identity, CRM and data pipelines.
- It is the last checkpoint before May 2027. After 13 November, about six months remain before the core obligations apply. If you are planning a cloud migration, a new region, a backup redesign or a change of vendor, this is the window to finish it, not the month before the deadline.
What changes on 13 May 2027, and where it lands in your infrastructure
On 13 May 2027, the rules that carry most of the operational weight come into force. Several of them read less like legal text and more like an infrastructure specification.
Security safeguards (Rule 6)
Rule 6 sets a minimum, not a menu. Every Data Fiduciary must have, at the least:
- Encryption, obfuscation, masking or tokenisation of personal data.
- Access controls on the computer resources used by the business and by its Data Processors.
- Logs, monitoring and review that make it possible to detect unauthorised access, investigate it and stop it happening again.
- Backups or other measures that keep processing going if data is destroyed or access is lost.
- Retention of those logs and personal data for one year, unless another law requires something different.
- A contract with each Data Processor that requires reasonable security safeguards.
In cloud terms, that translates to encryption at rest and in transit with properly managed keys, role-based access and MFA on every console and API, central logging for any system that holds personal data, backups that have actually been restored in a test, and a signed processor agreement with each provider.
Breach intimation (Rule 7)
When you become aware of a personal data breach, you must tell each affected person without delay, in plain language: what happened, what it means for them, what you are doing and what they can do to protect themselves.
You must also inform the Board twice. First, without delay, with a description of the breach, its timing, location and likely impact. Then, within 72 hours, with a detailed report covering causes, mitigation, any findings on who caused it, the steps taken to prevent a repeat and the notices sent to individuals. The Board can allow more time if you ask in writing.
Seventy-two hours is only tight when logs are scattered across teams and tools. If you cannot answer "which systems, which records, since when" from one place, that is the first gap to close.
Retention of data and logs (Rule 8)
Rule 8(3) requires personal data, the associated traffic data and processing logs to be kept for at least one year from the date of processing, then erased unless another law requires longer. The Rules' own illustration names a cloud service provider: a company that hosts customer records with a provider must make sure the provider also keeps that data and its logs for at least a year before erasure.
Large platforms carry an extra duty. E-commerce and social media platforms with at least 2 crore registered users in India, and online gaming platforms with at least 50 lakh, must erase a user's data after three years of inactivity and warn the user 48 hours before.
Rights requests (Rule 14)
Individuals can ask to access, correct, update or erase their data, or nominate someone to act for them. You must publish a response period of no more than 90 days and have systems that meet it. Erasure is where infrastructure gets tested: a deletion that reaches production but not replicas, backups and staging copies is not a deletion.
Cross-border transfers (Rule 15)
Personal data can be transferred outside India, subject to any requirements the central government sets by general or special order about making it available to a foreign state or entities it controls. Rule 15 itself commences on 13 May 2027, and those requirements arrive through separate orders. Check for any such orders before you lock in a transfer decision.
Significant Data Fiduciaries (Rule 13)
Businesses the government notifies as Significant Data Fiduciaries carry heavier duties: a Data Protection Impact Assessment and audit every twelve months, due diligence on algorithmic software, and keeping government-specified personal data and its traffic data inside India.
What non-compliance costs
The DPDP Act sets penalties of up to ₹250 crore for failing to take reasonable security safeguards. Failing to notify the Board or affected individuals of a breach, and breaching obligations on children's data, can each attract up to ₹200 crore. Other violations can attract up to ₹50 crore.
Does DPDP require data localisation?
No, not as a blanket rule. This is the most common misreading of the law. DPDP allows personal data to leave India by default and restricts it only where the government says so. An earlier draft of the Rules caused concern on this point; the final version kept the default open.
That does not mean every dataset can go anywhere. Three things can still keep data in India, and they apply whatever DPDP says:
- Sector regulators. RBI's 2018 directive requires payment system providers to store the entire data relating to payment systems only in India. Securities and insurance regulators have their own cloud and data rules. DPDP does not override any of them.
- CERT-In's 2022 directions. Service providers, data centres and body corporates must keep logs of all their ICT systems for a rolling 180 days within Indian jurisdiction, and report listed cyber incidents within 6 hours of noticing them.
- Significant Data Fiduciary notifications. If you are notified as an SDF, any personal data the government specifies must stay in India, along with the traffic data about its flow.
Where data leaves India without anyone deciding it should
In our experience, the residency problems that surface in an audit are rarely the primary database. They are the copies nobody mapped:
- Backups or snapshots replicated to an overseas region by default.
- Logging, monitoring and APM tools that ship logs, which often contain names, emails and phone numbers, to servers abroad.
- Support tooling and ticket attachments hosted outside India.
- AI features that send customer prompts, documents or call transcripts to an inference API running in another country.
That last one is growing fastest. If a product summarises customer emails or analyses support calls through an overseas model API, personal data is being processed abroad on every request. Running inference on GPU infrastructure inside India keeps that data flow simple to document.
Your infrastructure checklist for the next seven months
This is the order we suggest working in, because each step feeds the next. A breach runbook is only as good as the data map under it.
- October to November 2026: map the data. For every system that holds personal data, record the category of data, any sector rule that applies, and the physical location of the primary copy, replicas, backups, logs and DR site. Include SaaS tools and AI APIs, not just your own servers.
- November to December 2026: list your processors. Name every vendor that touches personal data on your behalf: cloud, backup, email, CRM, monitoring, support, analytics, AI. This list decides which contracts you need.
- December 2026 to January 2027: fix the contracts. Each processor agreement should require reasonable security safeguards, prompt notice to you of any incident (hours, not days, given CERT-In's 6-hour clock), at least one year of data and log retention, and verified deletion at the end of the contract. Bring your own Privacy Policy and Terms of Service in line at the same time.
- January to February 2027: centralise and retain logs. Send access logs from every system holding personal data to one place. Keep them for at least one year for DPDP and 180 days within India for CERT-In. Make sure the logs themselves are access-controlled; they contain personal data too.
- February to March 2027: rehearse a breach. Write the runbook with three clocks on it: CERT-In within 6 hours, the Board without delay, and the detailed Board report within 72 hours. Then run a tabletop exercise and time it.
- March to April 2027: test rights requests end to end. Pick a test user and run access, correction and erasure requests through every system, including backups and staging. Confirm you can respond well inside 90 days.
- Early May 2027: assemble the evidence. Keep the data map, contracts, log retention settings, restore-test results and drill reports in one folder. If the Board asks, this is what you show.
What your cloud provider handles, and what stays with you
Under DPDP, the business that decides why and how personal data is processed is the Data Fiduciary. Your cloud provider is a Data Processor. Accountability stays with you, whatever the contract says. So the useful question is not "is this provider DPDP compliant?" It is "can this provider give me the evidence I need to prove that I am?"
Before you renew or sign, ask your provider five things:
- Where, physically, is every region, backup target and DR site my data can land in?
- Do logs, monitoring data and support access stay in India?
- Does your processor agreement cover security safeguards, incident notice to me within hours, one-year retention and verified deletion at exit?
- Can you show me access logs for my resources when I need them for a 72-hour report?
- How do you handle GPU and AI workloads that process personal data, and where do they run?
Where Host360 fits
Host360 is the cloud business of Comprint, an Indian IT company founded in 1994 that has run private cloud for enterprises since 2012. We operate public cloud, private cloud, bare metal and GPU infrastructure from data centre locations in India, so primary data, backups and logs can stay in the country by design.
What we will not do is tell you that hosting with us makes you DPDP compliant. No provider can. What we can do is make the infrastructure half of the evidence straightforward to produce. Private Cloud & GPU Cloud
Frequently asked questions
- When does the DPDP Act become fully enforceable? The core obligations apply from 13 May 2027, eighteen months after the DPDP Rules were notified on 13 November 2025. Consent Manager rules apply from 13 November 2026. The Data Protection Board of India has been operational since November 2025.
- Does the DPDP Act require me to store data in India? Not by default. DPDP allows transfers abroad unless the government restricts them by order. Data can still be required to stay in India by sector rules, such as RBI's payment data directive, by CERT-In's 180-day log rule, or by a Significant Data Fiduciary notification.
- Is my cloud provider responsible for DPDP compliance? No. Your provider is a Data Processor; your business is the Data Fiduciary and remains accountable. You must have a contract that requires the provider to take reasonable security safeguards, and you should be able to get the logs and evidence you need from it.
- How quickly must a personal data breach be reported under DPDP? Tell affected individuals and the Data Protection Board without delay. Then file a detailed report with the Board within 72 hours of becoming aware of the breach, unless the Board allows more time. For listed cyber incidents, CERT-In separately requires a report within 6 hours.
- How long must logs be kept under the DPDP Rules? At least one year. Rule 6 requires logs and personal data to be kept for a year to detect and investigate unauthorised access, and Rule 8 requires processing logs to be kept for at least a year from the date of processing. CERT-In adds 180 days of ICT logs within India.
- Can I use an overseas AI API with customer data under DPDP? Generally yes, unless a sector rule or a government order restricts that data. But every request sends personal data abroad, so it must appear in your data map, your processor list and your notices. Many teams run inference on India-hosted GPUs to keep the data flow simpler to document.
- Who is a Significant Data Fiduciary? Any business, or class of business, that the central government notifies as one, based on factors such as the volume and sensitivity of the personal data it processes. SDFs must run an annual DPIA and audit, and keep government-specified data inside India.
Get your data residency map done before the deadline
Most of the work above starts with one question: where does your personal data actually live today, including the copies? Our solutions architects can walk through your current setup, mark which workloads need to stay in India, and show what an India-hosted design looks like for them, from databases to GPU inference.
Sources