Data localisation is one of the least understood — and most quietly breached — parts of SEBI's Cyber Security and Cyber Resilience Framework (CSCRF). The principle is simple: a regulated entity's (RE) regulatory data should stay within India's legal jurisdiction — stored in India, accessible to SEBI, and not placed beyond the reach of Indian law. The complication is where that data actually lives once you run on foreign cloud and third-party SaaS. This guide explains what data localisation under CSCRF requires, which data it applies to, and how to prove residency when SEBI asks.
Does SEBI CSCRF require data localisation?
In substance, yes. CSCRF and SEBI's related cloud-adoption expectations require REs to keep control and legal jurisdiction over their regulatory data. In practice that means the data should reside within India, remain subject to Indian law, and be accessible to SEBI and its auditors on demand. The framework is less about a single line that says 'store everything in India' and more about ensuring that no arrangement — including a cloud contract or an overseas SaaS vendor — puts your regulatory data outside SEBI's reach.
Which data must stay in India?
Not every byte is treated the same. What must be localised is driven by data classification — the more sensitive and regulatory the data, the stricter the residency expectation. As a working model:
| Data type | Residency expectation | Notes |
|---|---|---|
| Regulatory & client data | Stored in India, under Indian jurisdiction | Order, trade, KYC, investor and similar records at the core of your regulated activity |
| Sensitive & personal data | In India; also within DPDPA scope | Overlaps with India's data-protection law — a double reason to keep it local |
| Logs & audit evidence | Retained and accessible in India | Must be producible for SEBI inspection within required timelines |
| Non-sensitive operational data | More flexibility, subject to your policy | Still needs documented controls and access |
The safest default is to treat regulatory, client and sensitive data as must-stay-in-India, and to justify — with documentation — anything you choose to store elsewhere.
The cloud and SaaS problem
This is where most REs are quietly exposed. You may have moved to AWS, Azure or Google Cloud, or adopted a foreign SaaS tool, without confirming which region your data physically sits in — and a global service can default to storing or replicating data outside India. Two things matter here. First, moving to the cloud does not move the accountability: the RE remains responsible for residency, not the cloud provider. Second, it is not only your primary database — backups, disaster-recovery copies, logs, analytics pipelines and third-party integrations can all quietly send regulated data across a border. Localisation is only real if every copy of the data respects it.
How to comply — the practical route
Data localisation is not a one-time toggle; it is a process of knowing what you hold, where it lives, and being able to prove it. The workflow that holds up at inspection:
Classify
Tag data by sensitivity & regulatory status
Map
Find where each dataset actually lives
Localise
Bring regulated data into India
Control access
Ensure Indian jurisdiction & SEBI access
Evidence
Prove residency on demand
The step teams skip is the second one — mapping where data actually lives, across primary systems, backups and every vendor. You cannot localise, or prove localisation, for data you cannot see.
The hard part is knowing where your data actually lives
Most localisation failures are not decisions to break the rule — they are blind spots: a backup region left on a default, a SaaS vendor that replicates abroad, an analytics export nobody tracked. The RE that stays compliant is the one that can point to every dataset, say where it resides and who can reach it, and produce that evidence the moment SEBI asks.
Bottom line
Data localisation under CSCRF comes down to one question you must be able to answer at any moment: where is my regulated data, and is it within India's jurisdiction? Classify your data, map every place it lives — primary, backup, cloud region and vendor — bring the regulated categories into India, keep them under Indian access and control, and hold evidence of all of it. Do that, and localisation stops being a hidden liability and becomes something you can demonstrate on demand.
Frequently asked questions
Does SEBI CSCRF require data localisation?+
In substance, yes. CSCRF and SEBI's related cloud-adoption expectations require regulated entities to keep their regulatory data within India's legal jurisdiction — stored in India, subject to Indian law, and accessible to SEBI and its auditors. Confirm the specific categories and conditions in the circular applicable to your entity.
What data must be stored in India under CSCRF?+
The residency expectation is driven by data classification. Regulatory data (order, trade, KYC, investor records), sensitive and personal data, and audit logs/evidence should be kept in India and accessible to SEBI. Non-sensitive operational data has more flexibility, subject to documented controls.
Can I use AWS, Azure or foreign SaaS under SEBI CSCRF?+
You can use cloud and SaaS, but the accountability stays with you: you must ensure regulated data resides in India, remains under Indian jurisdiction, and is accessible to SEBI — including in backups, disaster-recovery copies and vendor integrations, not just your primary system. Configure regions deliberately and document it.
Do backups and disaster-recovery copies also need to be in India?+
Localisation is only meaningful if it covers every copy of the data, so backups, DR replicas, logs and analytics exports are all in scope for regulated data. The specific DR requirements can vary by entity type — confirm them against the current SEBI circular.
Who is responsible if a cloud vendor stores data abroad?+
The regulated entity. Moving to the cloud does not transfer the localisation obligation to the provider — the RE remains accountable for where its regulatory data resides and must be able to prove it stays within Indian jurisdiction.