Data Localisation for Client Social Media Accounts

Two things happened in the last year. A client's procurement team sent me a vendor questionnaire with the line "confirm all personal data is stored within India", and a WhatsApp group of agency owners started forwarding a post claiming Indian agencies must now host everything on Indian servers or face ₹250 crore penalties.

One of those is a real business requirement. The other is a sales pitch with a statute number attached. Here's the actual legal position, where your clients' data really sits, and how to answer the questionnaire without either lying or losing the account.

Does Indian law require client social media data to be stored in India?

Not as a general rule. The Digital Personal Data Protection Rules, 2025 were notified by MeitY on 13 November 2025 — 22 rules, after a ten-month consultation. Rule 15 deals with sending personal data abroad, and its operative text permits the transfer "subject to the restriction that the Data Fiduciary shall meet such requirements as the Central Government may, by general or special order, specify".

Read that carefully, because it's the opposite of what most people assume. It's a negative list: transfers are allowed by default, and the government can restrict specific destinations. As things stand, no country has been notified as restricted under Section 16 of the Act. India debated hard localisation for years — in the 2018 and 2019 drafts — and landed somewhere else.

What does force Indian storage is narrower and older than the DPDP regime:

So the honest answer to "must client data live in India?" is: your content calendar, no; your security logs, yes; your payment rails, already handled by your gateway. The obligations that do land on an agency are about consent, purpose and deletion rather than geography — we covered those in detail in what the DPDP Act means for marketing agencies, including why you're a Data Processor rather than a Fiduciary and what the 13 May 2027 deadline actually covers.

Where does your client's data actually sit right now?

This is the question worth answering, and almost nobody has. Do the map before someone makes you.

Look at row two. Google Workspace's data-region controls let an admin pin covered data to the United States or the European Union — and that's the full list. India is not one of the choices. If your Drive holds a client's downloaded lead list and their questionnaire demands Indian storage, the truthful answer is that Workspace cannot do it, whatever you'd like to write in the box.

And look at rows four and five, because that's where the actual exposure is. Nobody has ever been harmed by a caption sitting on a US server. People are harmed by a spreadsheet of 4,000 phone numbers from a Diwali contest living in a WhatsApp group with eleven members, four of whom no longer work at your agency.

Why are enterprise clients suddenly asking this?

Three reasons, all of them rational.

1. The clock is running. MeitY notified the Rules with a phased runway — obligations switching on across 14 November 2025, 14 November 2026 and May 2027, with full compliance expected by 13 May 2027. Large companies are working backwards from that date, and vendor due diligence is the cheapest box to tick first.
2. You are their processor. A Data Fiduciary can only engage a processor under a valid contract. Their legal team can't sign that contract without knowing what you hold and where. The questionnaire isn't suspicion, it's paperwork they've been told to produce.
3. The six-hour clock needs you. Under the CERT-In Directions, reportable incidents go to CERT-In within six hours of being noticed. If the breach is a leaked login to their Instagram account and you're the one holding it, their six hours depend on how fast you answer a phone call at 11 PM. That's why the contract now asks for a named contact and a notification commitment.

This is also, quietly, an opportunity. Most agencies bidding against you will answer the questionnaire with vibes. If you turn up with an actual data map, a named security contact and a written offboarding commitment, you look like a different tier of vendor — which matters most in exactly the markets where enterprise retainers live, like Gurugram and Bengaluru.

How do you answer a data-residency questionnaire honestly?

Five rules, learned by getting it wrong once.

1. Never guess a region. If you don't know where a vendor stores data, write "confirming with vendor" and go get it in writing — from their documentation or their support desk. A wrong answer in a signed vendor form is a far bigger problem than a blank one. Ask every vendor you use, including ours; any vendor that won't answer in writing has told you something.
2. Distinguish content from personal data. A caption and a creative are not personal data. A DM thread, a lead-ad submission and a contest entry are. Answer at that granularity and the form gets much easier — and much more credible.
3. Say what you cannot do. "Google Workspace does not offer an India data region; covered data is pinned to [US/EU]" is a perfectly acceptable answer. "All data is stored in India" when it isn't will not survive their next audit.
4. Name a person and a clock. Give a security contact, a phone number and a commitment — we'll notify you within X hours of noticing an incident. Given their six-hour obligation, pick a number well inside it.
5. Commit to deletion, then actually build it. The last question is always about offboarding. Write what you'll delete, from where, and in how many days — then make sure that's a process and not a promise.

The three fixes that matter more than server location

If you do nothing else this quarter, do these. They cost nothing and they close the gaps a residency form never asks about.

Stop holding client passwords

The single largest personal-data risk at most Indian agencies isn't a foreign server, it's the shared Google Sheet of client logins — and the ex-employee who still has the link. Token-based access through Meta's official API means you never hold the password at all, which we walked through in Instagram auto-posting without password sharing. When the questionnaire asks how you access their accounts, "we don't hold credentials" is the strongest sentence you can write.

Get the lead exports off laptops

Every lead-gen client generates a CSV of names and phone numbers, and every agency has downloaded one. Decide where lead data lives, keep it in one system with access control, and stop the WhatsApp forwarding habit. If a client's leads must reach their sales team, send them into the client's CRM — don't make your agency a second uncontrolled copy of their customer database.

Make offboarding a checklist, not a feeling

When a retainer ends: remove your team from their Business Manager, revoke tokens, delete the Drive folder after handover, exit the WhatsApp group, and write the date you did it. The same discipline applies when a staff member leaves mid-retainer. We build this into client onboarding in reverse — whatever access you grant on day one should have a documented way to be taken back, and a system with per-client roles makes that a click instead of an archaeology project. That's the practical case for keeping client work inside one agency system rather than spread across a dozen personal accounts.

FAQ

Sources

• DPDP Rules 2025, Rule 15 — text on transfer of personal data outside India.
• PIB: DPDP Rules, 2025 notified — notification date and phased commencement.
• CERT-In Directions, 28 April 2022 — 180-day log retention within India and 6-hour incident reporting.
• RBI circular on storage of payment system data — 6 April 2018, payment data stored only in India.
• Google Workspace data regions — available regions are the US, the EU, or no preference.