DPDP Act and your website: the hosting obligations nobody explains
TL;DR: India's Digital Personal Data Protection Act 2023 became operational when the DPDP Rules were notified on 13 November 2025. Full compliance is required by 13 May 2027. If your website collects a name, an email, or a phone number, it applies to you, and the penalties run to ₹250 crore for the most serious violations.
Most DPDP coverage is written for legal teams and stops at consent notices. The part nobody explains is that your hosting provider is a Data Processor under this law, the accountability for what it does stays with you, and a handful of hosting-side decisions, where your backups live, how fast you can detect a breach, whether you have a signed processor agreement, are the ones that will actually be examined if something goes wrong.
What the DPDP Act actually is
The Digital Personal Data Protection Act, 2023 is India's first dedicated data privacy law. It received presidential assent in August 2023 and then sat largely dormant for two years, because a law without rules is a law without operational detail.
That changed on 13 November 2025, when the Ministry of Electronics and Information Technology notified the DPDP Rules 2025. The Rules supply the machinery: what a consent notice must contain, how breaches get reported, what security safeguards look like, how processor contracts must be structured.
The same notification established the Data Protection Board of India, the body that investigates complaints and imposes penalties.
The scope is broader than most site owners assume. The Act covers digital personal data, which means any data about an identifiable individual, held in digital form. A name in a contact form is personal data. An email address on a newsletter list is personal data. An IP address tied to a session, a phone number in a WhatsApp enquiry, a shipping address in a WooCommerce order, all personal data.
It does not cover non-personal data, and it does not cover paper records. Almost nothing on a modern website falls outside it.
Territorial reach extends past Indian borders. The Act applies to any organisation processing the personal data of individuals in India in connection with offering goods or services to them. A Dubai-registered company selling to Indian customers is in scope. So is a US SaaS product with Indian users.
The penalties are the part that got everyone's attention. Failure to implement reasonable security safeguards carries a penalty up to ₹50 crore. The most serious violations reach ₹250 crore. Fines apply per contravention, and the Board can publish the details of a violation, which adds a reputational cost on top of the financial one.
For a business running on a ₹599 hosting plan, those numbers sound theoretical. They are not aimed at you specifically. But the obligations underneath them apply to you at exactly the same standard as they apply to a bank.
The four roles, and which one you are
Every obligation in the Act attaches to a role. Getting the roles right is the first step, because people routinely assume they are the processor when they are the fiduciary, and that assumption is expensive.
Data Principal is the individual whose data you hold. Your customers, your website visitors, your newsletter subscribers, your job applicants, your employees. They hold enforceable rights over their own data: access, correction, erasure, and grievance redressal.
Data Fiduciary is the organisation that decides why personal data is collected and how it is processed. If you run the website, you are the Data Fiduciary. This is the accountable role. Every notice, consent, security and breach obligation lands here.
Data Processor is a third party that processes personal data on your behalf. Your hosting provider. Your email service. Your CRM. Your analytics tool. Your payment gateway. Your backup vendor.
Significant Data Fiduciary is a Data Fiduciary designated by the Central Government under Section 10, based on data volume, sensitivity, or systemic risk. SDFs carry extra obligations including appointing a Data Protection Officer based in India and running periodic audits. Most small businesses will never be designated.
Here is the sentence that matters most in this entire article.
Compliance responsibility rests with the Data Fiduciary even where the processing is carried out by a Data Processor. Your host having a certification does not transfer accountability to your host. If your hosting provider suffers a breach that exposes your customers' data, the Data Protection Board's first question is directed at you.
You cannot outsource the obligation. You can only manage the vendor.
The deadlines that matter
The Rules set an eighteen-month runway, phased across three dates.
13 November 2025. The Rules were notified and the Data Protection Board of India was established, with its head office in the National Capital Region. Some provisions took effect immediately.
13 November 2026. The Consent Manager framework becomes operational. Organisations can register with the Board as third-party intermediaries that manage user consent and permissions on behalf of Data Principals. This is a registration regime for a new category of service provider, not an obligation on ordinary businesses.
13 May 2027. Full compliance. All substantive obligations, notice and consent mechanics, security safeguards, breach notification, Data Principal rights workflows, processor contracting, are enforceable from this date.
The temptation is to read May 2027 as permission to do nothing until early 2027. That reading is wrong for two reasons.
The first is that consent is not retroactive. Every email address you collect between now and May 2027 without a compliant notice is a record you may not be able to lawfully process afterwards. A list built over eighteen months on a non-compliant form is a list you may have to re-permission from scratch.
The second is that the technical work has lead time. Migrating a database to encrypted storage, building an erasure workflow, or changing hosting providers to get a signed processor agreement takes weeks, not days. 2026 is the build year. 2027 is the deadline.
Does DPDP force you to host in India?
This is the single most common misconception, and it is worth answering flatly.
No. The DPDP Act does not impose blanket data localisation.
Cross-border transfer of personal data is permitted to all jurisdictions except those the Central Government specifically restricts by notification. As of now, no such restriction list has been published. You can lawfully host Indian customer data on a server in Singapore, Frankfurt, or Virginia.
That answer comes with three qualifications.
The government retains the power to restrict specific jurisdictions at any time, with no requirement to give a long runway. A business with all its data in a single overseas region is exposed to a policy change it cannot control. Sector regulators impose their own rules independently. RBI's payment data localisation directive already requires payment system data to be stored in India, and that obligation is separate from and unaffected by DPDP.
And the practical case for Indian hosting has never rested on the law anyway. It rests on latency. A user in Pune hitting a Mumbai server sees a round trip of roughly 15 to 30 milliseconds. The same user hitting a Singapore server sees 60 to 90 milliseconds, and a US East Coast server pushes past 250 milliseconds. Across the dozens of round trips a modern page load requires, that difference is the gap between a site that feels instant and one that feels sluggish.
Host in India because it makes your site faster for the people who use it. Not because a law you have not read told you to.
Your host is a Data Processor. That changes things.
If your hosting provider is a Data Processor, and it is, then the Act expects a valid contract between you and it. The Rules expressly require appropriate security provisions in the Data Fiduciary to Data Processor agreement.
Most small businesses in India have no such contract. They have a checkout page, an invoice, and a terms-of-service link they never opened.
That is the gap. Here is what to look for, and what to ask if you cannot find it.
Is there a Data Processing Agreement at all? A DPA is a specific document, distinct from the general terms of service. Serious providers publish one. If your host has nothing, that is a finding, not a technicality.
Where does the data physically sit, including backups? Primary server location is the easy question. The one people forget is backup location. A host with servers in Mumbai and backups replicated to an unnamed overseas region has an answer you need in writing.
How quickly will they notify you of a breach? Your 72-hour clock to the Board starts when you become aware. If your host takes a week to tell you, your clock has already run out. The DPA should commit to a notification window measured in hours.
What are the sub-processors? Your host may use a third-party CDN, a monitoring service, or an offsite backup vendor. Each is a further processor of your data. You are entitled to know who they are.
What happens to your data on termination? Deletion timelines, format of data export, and confirmation of destruction. Vague language here means data of yours sitting on a decommissioned disk somewhere with no accountability.
Encryption at rest and in transit. Free TLS is table stakes now and there is no excuse for a site collecting personal data over plain HTTP. Encryption at rest for databases and backups is the part that is inconsistently implemented. Our guide to free SSL vs paid SSL certificates covers the transport side in detail, and SSL certificates are included on every HostCloud plan.
Access logging. If you cannot reconstruct who accessed what and when, you cannot investigate a breach, and you cannot demonstrate to the Board that you tried.
Obligations by role and where hosting touches each one
The obligations spread across your whole operation, but a surprising number of them have a hosting dependency that only becomes visible when you map them out.
| Obligation | Who owns it | Hosting dependency | What to do |
|---|---|---|---|
| Consent notice on forms | Data Fiduciary | Low | Rewrite forms with itemised, unbundled consent |
| Purpose limitation | Data Fiduciary | Low | Document why each field is collected |
| Reasonable security safeguards | Data Fiduciary | High | Encryption at rest, TLS, access control, patching |
| Breach detection | Shared | High | Monitoring, log retention, host alerting SLA |
| 72-hour breach report to Board | Data Fiduciary | High | Depends on host telling you fast |
| Data Principal access requests | Data Fiduciary | Medium | Ability to export a single user's data |
| Erasure requests | Data Fiduciary | Medium | Deletion must reach backups, not just the live DB |
| Retention limits | Data Fiduciary | Medium | Backup retention policy must have an end date |
| Processor contract | Data Fiduciary | Direct | Signed DPA with your host and every vendor |
| Grievance officer | Data Fiduciary | Low | Named contact published on the website |
| Cross-border transfer control | Data Fiduciary | High | Know where primary and backup data sits |
The row that catches people is erasure. A Data Principal asks you to delete their account. You delete the row from the live database, and you are satisfied.
Meanwhile the record persists in every nightly backup you hold, potentially for the next twelve months. Whether that constitutes continued processing is a question your retention policy needs an answer to, and it means your website backup strategy is now a compliance artifact rather than just an ops one.
The 72-hour breach clock is a hosting problem
When a personal data breach occurs, the Rules require you to notify affected Data Principals without delay, give the Data Protection Board an intimation without delay, and follow that with a detailed report within 72 hours.
Seventy-two hours sounds generous until you decompose it.
The clock starts when you become aware of the breach. It does not start when the breach happens. That distinction is where most small businesses will fail, because the gap between compromise and awareness on a typical Indian SMB website is not hours. It is weeks.
An attacker gets in through an outdated plugin on a Tuesday. Nothing visible changes. The site keeps serving pages. Card-skimming JavaScript sits quietly in the checkout, or the customer table gets dumped once and the connection closes. Six weeks later a customer reports fraud, or Google flags the site, and only then does anyone look.
At that point you have 72 hours to produce a detailed report describing the nature of the breach, the categories and approximate number of Data Principals affected, the likely consequences, and the remedial measures taken. If your logs rotate every seven days, you cannot answer any of those questions. You are reporting an incident you cannot describe.
The hosting-side capabilities that make this survivable are unglamorous and cheap.
Log retention long enough to investigate, ninety days minimum, because a seven-day window tells you nothing about a compromise that started in March. File integrity monitoring, so an unexpected change to a core file raises an alert instead of sitting unnoticed. Malware scanning at the server level rather than relying on a plugin that the attacker can disable. A host that will tell you within hours, not days, when they detect something on their infrastructure. And clean, tested, restorable backups, because your first remediation step is almost always to roll back to a known-good state.
None of that is exotic. All of it needs to be in place before the incident, because you cannot retrofit log history after the fact. Our hacked WordPress cleanup guide walks through the incident response side once you are already in one.
What to check on your own website this week
Concrete audit, in rough order of how quickly you can close each gap.
Every form. List them all: contact, newsletter, quote request, checkout, job application, chatbot, WhatsApp click-through. For each, note what fields it collects and whether the person is told, at the point of collection, what the data will be used for. Bundled consent is out. A single "I agree to everything" checkbox does not satisfy the notice requirement, and consent must be as easy to withdraw as it was to give.
Your privacy policy. Under DPDP the privacy notice is a living document, not a page you generated in 2019. It needs the specific purposes for processing, the rights available to Data Principals, the grievance officer's contact details, and the mechanism for raising a complaint with the Board.
Your grievance officer. A named contact with published contact details. This is a low-effort requirement that a large number of Indian sites simply do not have.
Your vendor list. Every third party that touches personal data. Host, email, CRM, analytics, payment gateway, chat widget, form plugin, backup service, ad pixels. For each: is there a DPA, and where does the data go?
Your data map. Where does a customer record physically live? Primary database, backups, email archives, exported spreadsheets on someone's laptop, a Google Sheet the sales team maintains. The exports are where compliance quietly dies.
Your logs. How far back do they go? Can you answer, right now, who logged into your admin panel three weeks ago?
Your rights workflow. If a customer emails asking for a copy of all data you hold on them, what happens? If nobody knows, that is the workflow gap.
Your children's data exposure. Processing data of anyone under eighteen requires verifiable parental consent. If your product has any plausible under-eighteen audience, this is a design problem, not a checkbox.
Your cross-border picture. Not because transfers are banned, they are not, but because you need to know the answer before someone asks.
The mistakes small Indian businesses are making right now
Some of these are already visible across Indian SMB websites.
Treating a GDPR policy as sufficient. GDPR compliance covers a lot of ground, but DPDP has India-specific notice and consent requirements, its own breach timelines, and its own grievance mechanism. A copy-pasted GDPR policy misses all three.
Bundling every consent into one checkbox. The most common form pattern on the Indian web, and one of the clearest failures under the Act.
Ignoring vendor contracts entirely. Processor agreements must reflect the statutory obligations. Most businesses have never asked a single vendor for one.
Assuming the host handles it. Your host handles infrastructure security. It does not handle your consent flows, your retention policy, your grievance officer, or your erasure workflow. The accountability is yours.
Waiting for enforcement. The Board is operational. The runway is not a grace period for ignoring the law, it is time allocated for building the systems.
Confusing localisation with compliance. Moving your servers to Mumbai does not make you DPDP compliant. It is a good latency decision and a mild risk-reduction decision. It addresses none of the notice, consent, rights or breach obligations.
The pattern across all six is the same: treating DPDP as a legal document review rather than a programme that cuts across product, engineering, marketing and operations. The legal review is the smallest part of the work.
FAQs
Does the DPDP Act apply to a small business website?
Yes. The Act applies to any organisation that collects digital personal data of individuals in India, with no minimum revenue or headcount threshold. If your website has a contact form, a newsletter signup, or a checkout that captures a name, email, or phone number, you are a Data Fiduciary with obligations under the Act. The obligations scale in effort with your data volume, but they do not switch off below a certain size.
Do I have to host my website in India under DPDP?
No. The DPDP Act does not impose blanket data localisation, and cross-border transfer is permitted to all jurisdictions except those the Central Government specifically restricts through notification. No restriction list has been published so far. Separate sector rules may still apply, notably RBI's requirement that payment system data be stored in India, which operates independently of DPDP.
What is the DPDP compliance deadline?
Full compliance is required by 13 May 2027, eighteen months after the DPDP Rules were notified on 13 November 2025. An intermediate milestone falls on 13 November 2026, when the Consent Manager framework becomes operational. The eighteen-month window is an implementation runway rather than a grace period, and consent collected non-compliantly during it may not be usable afterwards.
What are the penalties under the DPDP Act?
Failure to implement reasonable security safeguards carries a penalty up to ₹50 crore, and the most serious violations reach ₹250 crore. Penalties apply per contravention rather than per company, so multiple failures can compound. The Data Protection Board can also publish details of a violation, which creates reputational exposure alongside the financial penalty.
Is my hosting provider responsible for DPDP compliance?
No. Your hosting provider is a Data Processor, and compliance responsibility rests with the Data Fiduciary even where processing is carried out by a processor. Your host is responsible for the security of the infrastructure and for meeting the terms of the processing agreement you sign with it. Everything else, consent, notices, retention, rights handling, breach reporting, remains yours.
What is a Data Processing Agreement and do I need one with my host?
A Data Processing Agreement is a contract between a Data Fiduciary and a Data Processor setting out how personal data may be handled. The DPDP Rules expressly require appropriate security provisions in Data Fiduciary to Data Processor agreements, so yes, you need one with your hosting provider and with every other vendor that touches personal data. It should specify data location, breach notification timelines, sub-processors, security measures, and deletion on termination.
How fast do I have to report a data breach in India?
You must notify affected Data Principals without delay and give the Data Protection Board an intimation without delay, followed by a detailed report within 72 hours. The clock starts when you become aware of the breach, not when it occurred. This makes detection capability, specifically log retention, integrity monitoring and host alerting, the practical constraint rather than the reporting itself.
Does DPDP require a cookie consent banner?
The Act requires informed, specific and unbundled consent for processing personal data, and most analytics and advertising cookies process personal data. In practice that means a banner that lets a visitor accept and reject categories separately, rather than a single accept button or a notice-only bar. Consent must also be as easy to withdraw as it was to give, which means a persistent way to change the choice.
What is a Consent Manager under the DPDP Rules?
A Consent Manager is a registered intermediary that manages consent and permissions on behalf of Data Principals, giving individuals a single place to grant, review and withdraw consent across services. The framework becomes operational on 13 November 2026, with the Data Protection Board handling registration. It is a registration regime for that category of service provider and does not create a direct obligation on ordinary businesses to use one.
Do I need to appoint a Data Protection Officer?
Only Significant Data Fiduciaries are required to appoint a DPO, and SDF status is designated by the Central Government based on data volume, sensitivity and systemic risk. Most small and mid-sized businesses will not be designated. Every Data Fiduciary, however, must publish the contact details of a grievance officer or another person able to answer questions about data processing.
Does deleting a user from my database satisfy an erasure request?
Not on its own, if the record persists in backups you continue to hold. An erasure workflow needs a documented position on backup retention, typically a defined retention window after which backups expire, and a process for handling restores so a deleted record is not silently reintroduced. This is why retention policy and backup configuration are compliance decisions rather than purely operational ones.
Does DPDP apply to companies outside India?
Yes. The Act applies to organisations outside India that process personal data in connection with offering goods or services to Data Principals in India. A foreign SaaS company with Indian users, or an overseas e-commerce store shipping to India, falls within scope. Being registered elsewhere does not remove the obligation.
Conclusion
The DPDP Act is not a legal document you read once and file. It is a set of operational commitments that cut across your forms, your database, your vendor list, your backups and your incident response, and most of them have a hosting dependency that only becomes obvious when you map the obligations out.
The deadline is 13 May 2027. The work is a 2026 problem.
The parts that will take longest are the ones nobody starts early. Getting a signed processing agreement out of a vendor who has never been asked for one. Building an erasure workflow that reaches backups. Extending log retention far enough that you could actually describe a breach within 72 hours of finding it. Migrating away from a host that cannot tell you where your backups physically sit.
None of that is a legal exercise. All of it is infrastructure.
The businesses that will be fine in May 2027 are not the ones with the longest privacy policy. They are the ones that spent 2026 fixing the boring things: unbundling their consent checkboxes, writing down where every copy of a customer record lives, and choosing vendors that could answer a hard question in writing.
HostCloud runs on Indian infrastructure with server-level security, ninety-day log retention, automated daily backups with defined retention windows, and a written processing agreement covering data location, sub-processors and breach notification timelines. Start from ₹99 a month at https://hostcloud.in, or send our team your current setup and we will tell you honestly which parts of it would survive a question from the Board.