Data residency for Indian associations: hosting your delegate list in India

The question arrives from a board member, usually in the last ten minutes of a meeting about something else: where is our delegate list stored?

It is a fair question and an increasingly common one. The Digital Personal Data Protection Act, 2023 has made Indian organisations far more attentive to personal data; institutional partners now ask about it as a matter of procurement; and members have opinions about their phone numbers that they did not have five years ago.

This piece is about the technical shape of the answer, not the legal one. Whether a specific obligation applies to your organisation is a conversation with your own counsel, and nothing here substitutes for it.

Residency covers more than the database

The instinct is to answer with the database, because that sounds like where data lives. It is the smallest part of the answer. Walk through what happens to one delegate's details and count what touches them:

• The database. Names, emails, phone numbers, dietary requirements, whatever else the form asked.
• Backups. Frequently a different service, region and retention schedule, set up by somebody who has since left.
• Application logs. Which hold more personal data than anyone intends, because an error helpfully includes the record that caused it.
• The email provider. Every confirmation and reminder passes through it in full — name, event, often the entry pass. If that provider is abroad, so are the messages.
• The WhatsApp path. Same again, with a phone number attached.
• Analytics and error tracking. Usually foreign, usually added for good reasons, usually seeing more identifiers than whoever pasted in the snippet realised.
• Support tooling. Screenshots of the registration list live for years in ticket systems.

A self-hosted application that emails through an overseas provider still sends the entire membership list overseas, one message at a time. An answer that survives contact with a real audit has to name all seven, not just the first.

Why the platform being self-hostable is the load-bearing fact

Most software-as-a-service is not merely hosted somewhere you did not choose; it is incapable of being hosted anywhere else. The deployment is a proprietary pipeline into one provider's account, and residency is whatever the vendor's region list offers — often two continents, neither of them yours.

The alternative is a platform that is genuinely a set of containers you can run. Conclave is Docker Compose: a Next.js application, Postgres, Redis, and a worker. That composition is the whole product, so it can run on a machine in Mumbai, or in your own university's data centre, and behave identically to a hosted instance.

That distinction matters, because "we can deploy in your region" and "you can run this yourself" are different promises. The first still leaves the vendor in the operating position. The second means the data is under your control in the ordinary, boring sense: on hardware whose contract you hold, which you could unplug this afternoon.

Self-hosting is a commitment, and it should be described as one

The honest version includes the cost: an association that adopts self-hosting without understanding it ends up with the worst of both — data in the right country, on a server nobody has patched since it was installed.

Backups, and restore tests. A backup that has never been restored is a hypothesis. Restore into a scratch database quarterly, and time it.

Certificates. Automated renewal, and an alert when it fails. An expired certificate on registration day is a self-inflicted outage of the most visible kind.

Upgrades. Postgres releases, base image rebuilds, application versions. Batch them into a scheduled window — not the fortnight before your annual conference.

Monitoring, with somebody at the end of it. The platform reports its own health: database, queue, workers. That is useful only if a failure reaches a human. The queue is the part people forget — with no worker running, registrations still save and check-in still works, and not one email is sent. Everything looks fine.

A named owner. One person who knows the deployment, plus one who could take over.

If your organisation has an IT function, none of this is exotic. If it does not, be realistic: hosting in-country with a managed provider under an Indian contract may serve the same goal with a far smaller operational surface, and that is a legitimate choice, not a lesser one.

Questions worth asking any registration vendor

Whoever you pick, five questions separate a considered answer from a reassuring one:

1. Where is the database, and where are the backups? Two answers, not one; they are frequently different.
2. Which third parties see personal data in normal operation? Email, messaging, analytics, error tracking, support. Ask for the list in writing.
3. Can we run it ourselves? And if so, is that the same software you run, or a reduced version?
4. How do we get our data out, in bulk, in a usable format? Exports should be a feature, not a support ticket. Test it in the first month, not the last.
5. What happens at the end of the contract? How long data is retained, what is deleted, how you would know.

A vendor who answers all five plainly is not necessarily the right one. A vendor who cannot answer them has told you something anyway.

The point of the exercise

None of this is distrust of foreign infrastructure, which is mostly excellent. It is about giving a short, true answer to a reasonable question from your own members: their names and numbers sit on a system your organisation controls, in the country they live in, and you can demonstrate it.

That answer is much harder to retrofit than to choose.