Health Data Localisation Rules for Indian Hospitals Explained

Section 16 of the Act takes a negative-list approach. It empowers the Central Government to restrict, by notification, the transfer of personal data by a data fiduciary to a country or territory outside India. That is the opposite structure to a localisation mandate: transfer is permissible unless the destination has been restricted. It also expressly preserves any other law that provides a higher degree of protection or a stricter restriction on transfer, which is how sectoral rules continue to operate above the Act rather than being displaced by it.

That structure surprises people who expected the Act to be a localisation law, and it means the transfer question for a hospital usually turns on other things: the contractual position with the data principal, the security obligation under the Act, and the sectoral rules described later. The Act's substantive weight for a hospital lies in consent, purpose limitation, security safeguards, breach notification and the rights of the data principal, rather than in geography.

It does not follow that location is unimportant. Wherever the data sits, the hospital remains the data fiduciary and remains accountable for the safeguards applied to it, including those applied by a processor abroad. The Schedule to the Act attaches substantial financial penalties to a failure to take reasonable security safeguards. Practically, demonstrating control over a processor operating under a different legal system is harder and more expensive than demonstrating it over one operating here, and that difficulty is the real argument for keeping data local.

The CERT-In directions of April 2022 require that logs of all information and communication technology systems be enabled and maintained securely for a rolling 180 days, and that they be maintained within Indian jurisdiction. This is unambiguous and it applies regardless of where the application itself is hosted. A hospital can therefore have a defensible position on patient records and a non-compliant position on logs, which is a common and easily missed combination.

The requirement bites in places hospitals do not look. Security monitoring platforms, endpoint protection consoles, identity providers, application performance monitoring, error tracking, ticketing systems and communication tools all generate and retain logs, and several of them default to a region chosen by the vendor. Ask each supplier where their log data physically resides, whether an Indian region is available for your tenancy, and whether switching later is possible without losing history. The answers vary more than you expect.

The same directions require synchronisation to the network time protocol servers of the National Informatics Centre or the National Physical Laboratory, or to servers traceable to them, which is a related design decision when infrastructure sits in a cloud region. Cloud providers offer time services, so the practical step is confirming the traceability position and recording it, rather than assuming that a managed service satisfies the requirement by default.

The Ayushman Bharat Digital Mission is built on a federated model rather than a central health record repository. Records stay with the health information provider that generated them, and are exchanged with the patient's consent through the consent manager and gateway when a health information user requests them. The consequence is that participating in ABDM does not transfer custody of your records to a national database, and hospitals sometimes decline participation on a misunderstanding of exactly this point.

Because the records remain yours, the storage and security obligations remain yours too. The Health Data Management Policy published under the mission sets expectations on data handling, consent, minimisation and security for participants, and the Ministry of Health's EHR Standards for India point to established information security standards for health informatics. Neither replaces your obligations under the Act; they layer on top of them and apply specifically to the ecosystem you are joining.

For localisation purposes the working rule is straightforward. If you are a health information provider, the records exchanged through ABDM originate in your system, so their residency is determined by where you host, not by the mission. If you use a third-party integrator or a gateway intermediary, ask where their components sit and what they retain, because a service that caches records in transit is storing patient data even if it describes itself as a pipe.

The Act preserves stricter rules elsewhere, and hospitals touch several. Payment data is the clearest: the Reserve Bank of India has directed that payment system data be stored in India, which is relevant wherever your billing counter, patient portal or payment gateway handles card and transaction data. Insurance record-keeping regulation places requirements on where insurers hold records, which flows into your dealings with insurers and third-party administrators through their own contract terms rather than directly.

Government and scheme contracts are the second source. Empanelment conditions, state health authority agreements and public tenders frequently specify hosting within India, sometimes specify empanelled or audited service providers, and sometimes specify audit and inspection rights over the hosting arrangement. These are contractual rather than statutory, which makes them no less binding and considerably easier to overlook because they sit in a schedule nobody reads after signature.

The third source is your own consent notices and privacy policy. If you have told patients that their data is stored in India, that statement binds you regardless of what the law permits, and changing it later requires a fresh notice rather than a quiet edit to a web page. Hospitals routinely publish privacy policies copied from a template that makes commitments the hospital has never verified. Reading your own policy against your actual data map is a short exercise with a high hit rate.

Region selection is a decision made once and expensive to revisit, so make it deliberately. Choose an Indian region for the primary workload, choose a second Indian region or availability zone for recovery, and confirm that every managed service you intend to use is actually available in both. Then check the services that sit outside the region concept entirely, such as global identity, content delivery, or certain administrative planes, and record what they hold. This is a half-day of reading documentation that saves a year of ambiguity.

Then get it into the contract rather than the sales deck. The agreement should name the region and commit that customer data will not be stored or processed outside it without written consent, list sub-processors with a notification obligation before any change, address support access explicitly by stating from which countries support personnel may access production data, and give you the right to be informed of and object to changes. Support access is the term most often missing and it is the flow most likely to breach an assumed residency position.

Finally require evidence rather than assurance. Ask for the region configuration in writing at go-live, ask for the sub-processor list at each renewal, and include a right to audit or to receive independent audit reports. A hospital contracting with a platform such as HealUDoc, or with any hosted clinical system, should be able to point to the clause rather than to a conversation when the question is asked in an assessment.

The question arrives from several directions: an NABH assessor, a corporate client's vendor assessment, an insurer, a government tender, occasionally a patient. Having the answer already written is worth more than having a defensible position you have to reconstruct each time. A two-page residency note listing each system, its hosting region, its processors and sub-processors, where logs are held, and the contractual basis for each is sufficient for almost every request, and it takes a day to produce once the data map exists.

Keep it current through a change gate rather than an annual review. Any new system, integration or software-as-a-service subscription answers three questions before approval: where does it store data, where are its logs, and who can access it from outside India. Departments buy tools without IT involvement in every hospital, so the gate needs to sit at procurement and finance as well, since the purchase order is the one point every tool passes through.

Be candid about residual gaps in the note itself. A hospital using an overseas communications tool for internal coordination, or a foreign analytics service on de-identified data, is in a defensible position if it has assessed the flow, documented the basis and applied controls. It is in a poor position if the note claims everything is in India and an assessor finds otherwise. The document that admits three known exceptions with owners and dates reads as competence; the one that claims perfection reads as an unexamined assumption.