Skip to main content
SEBICSCRFData LocalisationPR.DS.S2

SEBI CSCRF Data Localisation in Abeyance: What Regulated Entities Should Know

SEBI's Data Localisation mandate (PR.DS.S2) has been in regulatory abeyance since December 2024. What this means for compliance planning, what stays binding, and what to do instead of building a localisation programme that may never activate.

May 6, 2026 5 min read
On this page (7)

On 20 August 2024, when SEBI published the master CSCRF circular (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113), one of its most operationally demanding provisions was Data Localisation. Control PR.DS.S2 required regulated entities to host data relating to the Indian securities market within India — a requirement that would have mandated data-centre repatriation, cloud workload migration, and cross-border data-flow redesign for every regulated entity with offshore infrastructure.

Four months later, SEBI put it in abeyance. It has stayed there ever since.

This piece explains what happened, what the abeyance means, which obligations remain binding, and how to plan your compliance architecture around a non-current mandate that could still be reinstated.

What PR.DS.S2 actually requires

PR.DS.S2 sits in the CSCRF's Protect (PR) domain — the NIST CSF 2.0 Data Security family. The control reads:

"To ensure data security with respect to operations relying on data infrastructure, Regulated Entities shall host the data relating to the Indian securities market within the legal boundaries of India."

The scope is broad: "data relating to the Indian securities market" covers trade data, client KYC records, fund flow data, settlement instructions, margin records, and transaction logs — essentially every byte a regulated entity processes as part of its SEBI-registered activity.

Had the mandate activated, regulated entities with data centres or cloud regions outside India would have needed to repatriate or replicate those workloads to Indian infrastructure — a multi-quarter project with significant cost and architectural implications.

The December 2024 abeyance

On 31 December 2024, SEBI issued circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/184. The circular was primarily a regulatory forbearance letter — it extended the KRAs' and DPs' compliance deadline from 1 January 2025 to 1 April 2025. But buried in it was a single critical sentence:

"Data Localisation (PR.DS.S2) is kept in abeyance till further notification."

That sentence has not been superseded. Neither the April 2025 amendment (CIR/2025/60) nor the August 2025 technical clarifications (CIR/2025/119) nor the May 2026 AI Advisory lifted the abeyance. PR.DS.S2 remains non-current as of 2026-05-06.

What "in abeyance" means — practically

Abeyance is not repeal. The control still exists in the CSCRF catalogue. SEBI can lift the abeyance with a single subsequent circular — no parliamentary process, no public consultation period.

The practical implications:

  1. Do not implement PR.DS.S2 as a current compliance obligation. Your VAPT auditor, cyber audit scope, and IT-committee compliance report should not include Data Localisation as a binding requirement for FY 2026-27.

  2. Do not exclude it from architectural planning. If you are building new data infrastructure, designing a cloud migration, or renegotiating data-centre contracts, the possibility of PR.DS.S2 activation should be a rated risk in your architecture review — but it should not drive procurement decisions until SEBI issues a further notification.

  3. Document the abeyance in your CSCRF compliance records. When your IT committee reviews CSCRF compliance, include a one-line note: "PR.DS.S2 — Data Localisation: in abeyance per CIR/2024/184 dated 31-Dec-2024; no further notification received as of [date]." This is audit evidence.

  4. Watch for the notification. SEBI does not typically give long lead times for abeyance lifts. If the Indian government's broader data-localisation policy posture shifts — via MeitY, the Data Protection Board, or the DPDP Act rules — a CSCRF abeyance lift is likely to follow quickly.

What stays binding — even with abeyance

Data Localisation is the only CSCRF control in abeyance. Everything else in the master circular — VAPT, cyber audit, red teaming, threat hunting, CCI, ISO 27001 (MIIs), M-SOC, IT Committee, CISO, incident reporting, HSM (MII + QRE), and the full NIST CSF 2.0 + EV.ST control catalogue — remains binding.

In particular, the following data-related CSCRF controls are not in abeyance and remain current:

  • Data classification (PR.DS): Public, Internal, Confidential, Restricted — still required.
  • Encryption at rest and in transit (PR.DS.S1): AES-256 / TLS 1.2+ minimum — still required.
  • Data Loss Prevention (DE.CM): DLP monitoring — still required for critical systems.
  • Database Activity Monitoring: DAM for sensitive databases — still required.
  • Secure data disposal: Retention and disposal policy aligned with SEBI record-keeping — still required.
  • SBOM and asset inventory: Per AI Advisory item 9 — still required for critical applications.

The abeyance applies narrowly to the geographic hosting requirement. All other data-security controls remain binding.

Why SEBI put it in abeyance

SEBI has not published a stated rationale for the abeyance, but two contextual factors are relevant:

  1. The DPDP Act timeline. India's Digital Personal Data Protection Act, 2023, is in the process of being operationalised. The DPDP Act's own data-localisation posture — whether it mandates domestic hosting, adequacy-based transfers, or a consent-based model — will influence sectoral regulators' localisation rules. SEBI may be waiting for the DPDP Act rules to settle before finalising CSCRF's data-localisation position.

  2. Industry feedback. The December 2024 circular was explicitly a forbearance measure — providing "regulatory forbearance" to entities that had flagged operational difficulty meeting the original January 2025 deadlines. Data Localisation, as one of the most operationally heavy mandates, was likely among the most widely flagged.

How Security Brigade helps

Our compliance advisory practice helps regulated entities map their CSCRF control posture, separate binding obligations from non-current ones, and build compliance architectures that are resilient to mandate activation. Use our free SEBI Compliance Wizard to see your current tier and obligations — Data Localisation is correctly flagged as in abeyance in the result.

FAQ

When will SEBI lift the abeyance?

No date has been announced. Monitor MeitY and DPDP Act developments for signals. The abeyance lift is likely to come with a compliance window similar to the original CSCRF rollout (90–180 days).

Should I still include Indian data centres in my cloud migration plan?

Include the possibility as a risk scenario, not a binding requirement. Build your architecture so that workload repatriation or replication is feasible if mandated, but do not commit procurement to it until the abeyance is lifted.

Does CERT-In have a separate data-localisation mandate?

CERT-In Directions (April 2022) require log retention within India for certain categories of incidents — notably, CERT-In's 180-day log-retention rule for Indian subscribers. This is separate from CSCRF's PR.DS.S2 and is not in abeyance. If you are a telecom/internet service provider or operate in that capacity, CERT-In log-localisation obligations may apply independently.

What happens if the abeyance is lifted after I complete my FY 2026-27 compliance?

SEBI typically provides a compliance window when bringing a new/abeyance-lifted mandate into force. The original CSCRF had a phased rollout. If PR.DS.S2 is activated, expect a similar window.

Content current as of 2026-05-06. Source: docs/SEBI-CSCRF-FACTCHECK-2026-05-06.md. Verify any specific obligation against the latest SEBI circular before action — this analysis is informational and not legal advice.

About the authors

Founder & Chief Technology Officer

Founded Security Brigade in 2006 with the thesis that security assessment quality should be structural, not dependent on individual testers. 16+ years building platforms, teams, and methodologies that make enterprise security consistent.

Photo of Security Brigade Research Team

Offensive Security Research · Security Brigade

A rotating byline for collaborative analysis pieces from Security Brigade's offensive security and threat-research practice.