Drafting a Data Residency Clause That Holds

The procurement officer had done what the last circular asked. The RFP said the solution shall be hosted in India. Three bidders said yes. One of them ran inference in Mumbai and stored traces in a European APM because the Indian collector SKU was not on the price sheet. When the issue surfaced, the vendor's counsel pointed at the clause. Hosted, they said, referred to the application. Traces were operational telemetry.

The officer had not been careless. The clause had been copied from a 2019 cloud RFP written before anyone thought a prompt was a record. The words were familiar. They did not cover the objects an agent actually creates.

This is a template you can attach as a schedule. It is not legal advice and it is not a substitute for your counsel or your DFPR file. It is the set of definitions that stop the hosted-in-India fight from being a fight about adjectives.

Define the objects first

Do not start with reside. Start with a list of objects the clause can see. If an object is not listed, a clever reader will exclude it.

Annex A is where the disks live. Annex B is the tiny list of permitted subprocessors, each with a function, a country, and a retention measured in days. If Annex B is empty, write empty. An empty annex is a fact. A URL is an evasion.

Operative clauses that usually hold

1. Residency. The Vendor shall store and process Institutional Data only in Permitted Locations, except for a transfer expressly listed in Annex B.
2. No silent tools. Any model host, guardrail, OCR, speech, analytics or support path is a subprocessor and must appear in Annex B before it receives Institutional Data.
3. Fail closed. If a Permitted Location component is unavailable, the Services shall not send Institutional Data to an unlisted host.
4. Telemetry. Product analytics, crash reporting and licence checks shall not contain content from Institutional Data. Payloads are published in Annex C.
5. Keys. Buyer-controlled keys where the architecture allows; Vendor shall not retain a standing copy of Buyer secrets.
6. Notice. An Egress Event is notified to the Buyer within twenty-four hours of discovery, with the data classes and the destination.
7. Deletion. On request or on exit, deletion of Institutional Data from all stores including backups within the cycle stated in Annex D, followed by a certificate that names those stores.
8. Verification. Buyer or an independent assessor may test egress, not more than twice a year and after any Egress Event, on reasonable notice.
9. Flow-down. The Vendor shall impose these duties on Annex B parties.
10. Remedy. Undeclared Egress is material breach. Buyer may suspend the offending component immediately.

Those ten lines will be marked as onerous. They are onerous compared with a 2019 hosting sentence. They are not onerous compared with a leaked beneficiary file.

If the annexes are missing, the clause is a slogan again.

Annex	What it contains	Who keeps it current
A — Locations	Facility, city, owner, whether DR	Vendor proposes; Buyer accepts in writing
B — Subprocessors	Name, function, country, retention days	Prior written consent for any add
C — Telemetry schema	Field list for licence and health pings	Change = contract change
D — Deletion cycle	Primary, snapshot, tape, laptop extracts	Tested once before go-live

Objections from vendors and from your own legal cell

DPDP allows transfers, so this clause is extra-legal. Yes. It is policy. Extra-legal is the point of a contract. You are allowed to be stricter than the negative list.

We cannot list subprocessors because they change. Then they should not receive Institutional Data. A moving list is exactly the risk the annex exists to stop.

Twenty-four hour notice is impossible. Discovery to notice is the clock. If they cannot detect egress, they cannot claim to control it.

This will fail on GeM because it is a branded product. Buyer-added terms exist. If a product cannot accept them, do not buy that product for this data class.

Common mark-ups that look safe and are not

Including disaster recovery in India without naming the city and the operator. DR is where copies hide. If DR is a vendor’s other region, you just allowed a second geography in a footnote.

Reasonable efforts to delete backups. Reasonable is not a date. Write the cycle. If the cycle is ninety days, say ninety days. A court and a DPO can live with a date. They cannot live with an adjective.

Affiliates may process as needed. Affiliates are legal entities you have not met. Name them or they do not process. Needed is not a purpose.

Anonymised telemetry may leave India. Anonymised is a claim about identifiability. Officer emails, rare scheme names, and case ids in span tags usually fail that claim. Publish the schema or keep the telemetry in Annex A.

A two-week clause workshop, then a 90-day attach

• Week 1: counsel, procurement and the technical owner fill the four annexes for one workflow. Empty is allowed. Vague is not.
• Week 2: run the ten operative lines past a friendly vendor and one unfriendly one. Record the objections. Decide which objections are real operations and which are sales friction.
• Days 15–45: attach the schedule to the next RFP or to a running contract variation.
• Days 46–90: perform the deletion drill and one egress test. File the results next to the signed annexes.

What goes in the file

The schedule, the four annexes, the signed acceptances of any Annex B add, the last egress-test record, and a one-paragraph note that DPDP did not force this clause — you did, for this data class. That last sentence stops a future vendor from claiming the clause is ultra vires the Act.

This is a drafting aid, not a form prescribed by law. Counsel must adapt it. Prcept AI should be willing to sign a schedule that names locations, an empty or short Annex B, and a deletion cycle you can test.

How to defend this in the file

A P2 Procurement will be asked to explain “Drafting a Data Residency Clause That Holds” to a secretary who has ten minutes. Do not start with the model. Start with the store, the hop, the clause, or the residual risk. “data residency clause template” is a search phrase. The file needs a decision.

A one-line India-region clause will lose the first fight over logs. Draft residency as a table of classes, places and subprocessors, then hang remedies on that table. DPDP does not define sovereign AI. Transfers can be lawful and still be a bad idea. Sector circulars can be stricter than DPDP. Write which instrument you are using.

If you cannot name the Data Fiduciary, the processor, the location of traces, and the erasure method, you are not ready for production personal data — whatever the architecture PDF says.

• One sentence on lawful basis or the procurement rule you are invoking.
• One sentence on where prompts, embeddings and logs live.
• One sentence on who can compel the operator.
• One artefact: packet capture, DPA schedule, or deletion certificate template.

Close this loop before the next CAB

Put “Drafting a Data Residency Clause That Holds” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P2 Procurement, not “the vendor.”

Revisit the item when the model, the GeM term, the region, or the SI changes. “data residency clause template” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.