The DPDP Act and Your Website: What Indian Businesses Must Actually Do

If your website collects any personal data from someone in India — a name in a contact form, an email for a newsletter, a customer account — the Digital Personal Data Protection Act applies to you. The substantive obligations commence on 13 May 2027. This is a practical guide to what changes on your website and with your host, not legal advice.

What the DPDP Act Is, and Whether It Applies to You

India’s first comprehensive data protection law is the Digital Personal Data Protection Act, 2023, passed by Parliament in August 2023. It sat largely dormant for two years because the operational detail was left to subordinate rules. Those arrived on 13 November 2025, when the Ministry of Electronics and Information Technology notified the Digital Personal Data Protection Rules, 2025 via Gazette notification G.S.R. 846(E), issued under Section 40 of the Act.

With that, the framework became real. There are 23 rules and seven schedules, a regulator in the Data Protection Board of India, and a phased timetable running to May 2027.

The scope test is simpler than most coverage suggests. The Act applies to digital personal data of people in India, whether you collected it online or digitised it later. It applies regardless of where your business sits, so a company outside India offering goods or services to Indian users is covered too.

Personal data means anything that identifies a person. A name and phone number in an enquiry form qualifies. So does an email address on a newsletter list, a customer account, a shipping address, or an IP address tied to a login. If your website has a form, you are almost certainly holding personal data.

The three terms the rest of this guide needs

Data Fiduciary — you. Whoever decides why and how personal data gets processed. If you run the business the website belongs to, this is you, and nearly every obligation in the Act lands here.

Data Principal — the person whose data it is. Your customer, your enquirer, your subscriber. The Act gives them rights, and you have to make those rights exercisable.

Data Processor — anyone processing data on your behalf under contract. Your hosting provider is a Data Processor. So is your email marketing tool, your payment gateway, your CRM.

That third definition matters more than it looks. Using a competent host is not compliance, and no hosting company can sell you compliance. The obligations stay with you as the Fiduciary; what a processor gives you is the technical foundation to meet some of them. We come back to exactly which ones later in this guide.

Who is a Significant Data Fiduciary

The Act creates a heavier category for organisations the government designates as Significant Data Fiduciaries, based on data volume, sensitivity and risk. They face extra duties — annual Data Protection Impact Assessments, independent audits, a resident Data Protection Officer, and algorithmic due diligence.

Small and medium businesses are not in this category, and it is unlikely you will be designated one. Ignore the SDF sections of the coverage you read elsewhere unless you are operating at real scale.

The Dates That Matter

Rule 1 of the DPDP Rules sets three commencement dates, and it is worth reading the Gazette rather than a summary, because secondary sources report these inconsistently.

So the honest position today: the law is notified and the regulator exists, but the obligations on your website are not yet enforceable. May 2027 is the date to work back from.

One caveat worth knowing. MeitY has floated shortening the 18-month transition to 12 months, which would move the deadline to November 2026. That proposal has not been notified in the Gazette. Treat May 2027 as the deadline, and treat the possibility of it moving earlier as a reason not to leave this until the final quarter.

For a small business, the work described below is a few days spread across a few months, not a compliance programme. Starting now costs you little and removes the risk of a compressed timeline if the date does shift.

What You Actually Have to Do

Here is the whole thing on one page. Each row cites the rule it comes from, so you can check it against the Gazette rather than taking our word for it.

Most of that is process rather than technology. Three rows — 3, 5 and 9 — touch your hosting directly, and one of them, row 5, is the one almost nobody thinks about until it is a problem.

Consent and notice (Rule 3)

The notice is the part you will write first, because everything else assumes it exists.

It has to be standalone and understandable on its own, itemise the personal data you collect and the purpose for each item, and explain how to withdraw consent, exercise rights, and complain to the Board. “We may use your information to improve our services” fails on every count.

Practically, for a small business site, this means two things. A short, specific notice at the point of collection — beside the contact form, in the checkout flow — and a privacy policy that says the same things at length. Bundling consent for several unrelated purposes into one tick box does not work: if someone consents to a quote request, that is not consent to a marketing list.

Withdrawal has to be as easy as consent was. If they subscribed with one click, they unsubscribe with one click.

Security safeguards (Rule 6)

This is the rule that carries the highest penalty ceiling, and the one your hosting setup actually affects.

Rule 6 requires reasonable security safeguards, and names the categories: encryption or equivalent protection, access control, monitoring and logs to detect unauthorised access, backups sufficient to restore after a breach, and contractual terms binding your processors to the same standard.

For a typical website that translates into:

• HTTPS everywhere, with an auto-renewing certificate so it never lapses. Free SSL is included on every plan we sell, and our SSL certificate guide covers what it does and does not protect.
• Real access control — unique logins per person, no shared admin account, two-factor where it is available, and removing access when someone leaves.
• Logs that exist and are retained. Rule 6 requires logs be kept for a period so unauthorised access can be detected. You cannot investigate what you did not record.
• Backups you have tested. Restoring is the point; having is not. Our website backup strategies guide covers retention and testing.
• Updates applied. An unpatched CMS is the most common route into a small business site, and “we meant to update it” is not a reasonable safeguard.

Breach notification (Rule 7)

A personal data breach means any unauthorised processing, accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access that compromises confidentiality, integrity or availability. That is broader than being hacked — an email sent to the wrong list, or a database restored over, can qualify.

Rule 7 requires you to notify each affected Data Principal without delay, describing the breach, its likely consequences, what you have done about it, and how to contact you. The Board must be told too, with an initial intimation and then a fuller report.

The uncomfortable part is what this demands before a breach. If you cannot tell which records were exposed, you cannot notify the right people. Logs and backups decide whether you can answer that question, which is why row 4 depends on row 3 being done properly.

Write down who gets called, in what order, and who talks to the Board. An incident plan on one page beats an improvised weekend.

Retention and erasure (Rule 8)

Delete personal data once the purpose it was collected for has been served, unless a law requires you to keep it.

This is the obligation that quietly contradicts how most small businesses run. Form submissions accumulate in a database for years. Old customer records sit in a CRM nobody opens. Backups hold copies of everything, indefinitely.

Under Rule 8, data you no longer need stops being an asset and becomes a liability. The practical response:

• Decide a retention period for each type of data and write it down. Enquiries that went nowhere, six months. Customer records, as long as the relationship plus whatever tax law requires.
• Actually delete on that schedule — a quarterly job in the calendar is enough for most businesses.
• Include backups in the thinking. Indefinite retention of full backups sits awkwardly with an erasure obligation, so age them out on a defined cycle rather than keeping everything forever.

Tax and company law override this where they apply. GST records have their own retention requirements, and those win.

Contact point and grievance (Rules 9 and 14)

The cheapest item on the list, and the one most often missing.

Rule 9 requires you to publish the contact details of whoever answers questions about the personal data you hold — an email address or a page is enough for a small business. It goes on your website and in every privacy notice.

Rule 14 gives Data Principals rights you have to honour: access to what you hold, correction of what is wrong, erasure when consent is withdrawn, and a grievance route when they are unhappy with your answer.

For a small business none of this requires software. It requires a monitored inbox, someone who owns it, and a note of what you did and when. What it does require is that the route works — a published address nobody reads is worse than none, because it demonstrates you knew the obligation existed.

Where Your Data Sits, and What DPDP Says About It

This is the question we get asked most, and the one where published advice is least reliable. Some articles claim DPDP forces Indian businesses to keep all data in India. That is not what the law says.

Section 16 of the Act permits transfer of personal data outside India, except to countries the Central Government restricts by notification. Rule 15 adds that a Data Fiduciary transferring data abroad must meet whatever terms the government specifies for that transfer.

The critical detail: the list of restricted countries has not been notified. Until it is, there is no general prohibition on hosting an Indian business’s website outside India, and no blanket localisation mandate for an ordinary company. Anyone telling you otherwise is describing a rule that does not yet exist.

Two qualifications keep that from being the whole story. Organisations designated as Significant Data Fiduciaries can be subject to localisation for categories of data the government specifies — not you, almost certainly, but worth knowing the mechanism exists. And sectoral rules apply independently of DPDP: if you handle payment system data, the Reserve Bank’s 2018 directive requires it to be stored in India regardless of what DPDP says. Our guide to VPS hosting in India covers who that rule actually reaches.

So should you host in India anyway?

On the law as it stands, you are not required to. On practical grounds, there are three reasons it is the easier position.

If the restricted-country list arrives later and names somewhere your data sits, you are migrating under time pressure. Keeping Indian customer data in India removes that exposure entirely.

Cross-border transfer is a thing you must track and document under Rule 15. Not transferring is simpler than documenting a transfer.

And the performance argument stands on its own: Indian visitors reach an Indian server faster. Our Linux VPS offers an Indian node option alongside US locations for exactly this reason.

None of that makes hosting location a compliance requirement today. It makes it a decision with fewer moving parts.

What Your Hosting Provider Can and Cannot Do For You

Since the Rules were notified, “DPDP compliant hosting” has started appearing in Indian hosting marketing. It is worth being precise about what that can honestly mean, including for us.

Your host is a Data Processor. We process data on your instructions, under contract. You remain the Data Fiduciary, and every obligation in the checklist above is yours. Nobody can sell you compliance, and a provider claiming their plan makes you compliant is telling you something that is not true.

What a host genuinely contributes:

Read down the left column: that is roughly rows 3, 5 and 9 of the checklist, and part of row 4. Everything else is work only you can do, because it concerns what data you collect and why — questions a hosting company has no visibility into.

The practical test when a provider markets compliance: ask which rule number they are addressing and what you still have to do yourself. A straight answer names Rule 6 and hands most of the list back to you.

What we would suggest asking any host, including us: is SSL included and auto-renewing, how long are backups retained and have you tested a restore, what server logs exist and for how long, and is an Indian data location available. Our hosting plans answer all four on the page rather than on request.

What Happens If You Get It Wrong

The penalty schedule in the Act is specific, and the numbers are large:

Now the context that most coverage leaves out, and without which those figures are simply frightening.

These are ceilings, not tariffs. They are the maximum the Data Protection Board may impose, set at a level that is meaningful to the largest data processors in the country. The Board determines the actual penalty case by case, weighing the nature and gravity of the breach, the type of data affected, whether it was repeated, what the organisation did to mitigate it, and whether the response was reasonable.

A small business that collected data with a clear notice, held it securely, deleted it when finished and reported a breach promptly is not the subject this schedule was written for. The organisations at risk of headline penalties are those processing data at scale, carelessly, and failing to act when something goes wrong.

The realistic risk for a small business is not a ₹250 crore fine. It is a complaint from a customer, a Board enquiry asking what your safeguards were, and having no answer because nothing was ever written down. Documentation is what separates “we take this seriously” from “we had not thought about it”.

Final Thoughts

DPDP is a real obligation with a real deadline, and for a small business website it is a few days of work rather than a compliance programme.

Work through it in this order. Write down what personal data your website collects and why — most people find fewer categories than they expected. Write the notice and fix the forms. Set retention periods and actually delete on them. Get security right: HTTPS, unique logins, tested backups, updates applied. Publish a contact point and decide who answers it.

Two things are worth starting now rather than in 2027. Retention takes a while to unwind if years of data have accumulated, and security improvements are worth making regardless of what the law requires. Neither depends on the deadline.

This guide is not legal advice. We are a hosting company, and what we can speak to with authority is the infrastructure half — encryption, backups, logs, server location. Your obligations depend on what data you collect, why, and in what sector, and a data protection professional or lawyer should confirm your specific position. Where we have cited a rule number, check it against the Gazette; the DPDP Rules, 2025 are published in full on the MeitY website.

If the infrastructure side is what you need, our hosting plans include SSL, daily backups and an Indian node option, and our Noida team can answer questions about what runs where.

FAQs