Guide
Data Residency Starts With Tracing Every Copy, and We Set Up Controls From the First Day
Choosing an Indian region is often treated as the answer. The rules depend on the kind of data and who holds it, and they follow every copy, so we begin by finding each one.
4-minute read5 November 2026
In Brief
- A region setting describes the primary database. Backups, logs, analytics, support tools and messaging vendors hold copies too, and an auditor will ask about each one.
- We see four actions: list every copy of the data, classify each by the rule that applies, assign a location and an owner to each, and define the settings in code so they can be reviewed.
- Thinqmesh reviews your infrastructure, spending and risks, then puts identity, encryption, logging and policy checks in place from the first day. A first set of workloads runs within four weeks.
Ask an architecture board how it handles data residency and the answer is often a cloud region: everything runs in Mumbai or Hyderabad, so the matter is closed. A cautious security team may add that Indian law requires it. Both statements are less sound than they appear.
An Indian Region Is Where the Work Begins
What is required depends on the kind of data and who holds it, and where a requirement applies it follows the data well beyond the primary database. The Reserve Bank's rule for payment system data is a good example. It requires storage only in India and reaches the gateways and vendors a payment business uses, but it allows processing abroad under timed conditions. The DPDP framework sets no general localisation rule, and cross-border transfers may be restricted by notification.
The useful question is which copies of which data exist, where they are and which rule applies to each. We start with the review of your infrastructure and risks, set identity, encryption and logging in code from the first day, and keep one record of those settings that reviewers can read.
Four Actions to Take Before You Answer a Residency Question
Each one works whatever your cloud provider, and the first three need no new tooling.
List Every Copy of the Data
The primary database is one copy. Backups, logs, analytics, support tools and vendors hold others.
Walk through the life of one record, from the moment it is created to the moment it is deleted, and note each place it is written. Include the tools your support team uses to look at customer data and the services that send messages on your behalf.
Get started
- Choose one customer record and trace where it is stored.
- Ask each vendor in the chain where they keep their copy.
Classify Each Copy by the Rule That Applies
Payment data, personal data and ordinary operational data are treated differently.
The Reserve Bank requires payment system data to be stored only in India, with processing abroad permitted if the data is deleted there and brought back within one business day or 24 hours, whichever is earlier. The DPDP framework sets no general localisation rule, and transfers may be restricted by notification. Match each copy to the rule that actually applies.
Get started
- Mark which copies hold payment system data.
- Mark which hold personal data under the DPDP framework.
Give Each Copy a Location and an Owner
A copy without an owner is the one that ends up in the wrong place.
Record where each copy is, who answers for it and what happens to it at the end of its life. Where a processor works abroad, record how data is deleted and returned, since that is the obligation the rule describes.
Get started
- Add owner and location columns to your list of copies.
- Fill every row, and mark the ones you cannot yet answer.
Define the Settings in Code
A setting that lives in a console can be changed by anyone with access, and the change passes unseen.
When regions, encryption and logging are defined in code, they can be reviewed before a change and rebuilt exactly. Reviewers then see one consistent record across every team and not a different set of choices in each account.
Get started
- List the cloud accounts and who can change their settings.
- Choose one workload to define in code as a first trial.
How Thinqmesh Solves This
We agree the reason for the move before choosing anything. Some workloads should move as they are, some should be rebuilt and a few should stay where they are, and your data rules decide which.
- Weeks 1-2
Review of Infrastructure and Risks
We review your current infrastructure, spending and risks, and where your data sits, and compare options with their costs side by side.
- Weeks 3-4
First Workloads Running
A first set of workloads is migrated, tested and running, with infrastructure defined in code and monitoring and backups in place.
- Weeks 5-6
Controls Defined Consistently
Identity, encryption, logging and policy checks are defined across teams, so settings can be reviewed and rebuilt.
- Weeks 7-8
Cost and Ownership
A monthly view shows cost by service and owner, and the full migration plan is completed across the eight weeks.
You finish with your first workloads running on the new setup, controls in code, and a bill that can be explained. Regulated workloads follow their own plan.
