Stock brokers, depository participants, mutual funds, RTAs, portfolio managers and investment advisers all live under the same SEBI circular now: the Cybersecurity and Cyber Resilience Framework (CSCRF), issued on 20 August 2024, with compliance dates that started on 1 January 2025 for entities already covered by earlier SEBI cyber guidelines and ran through 2025 for the rest. It replaced a patchwork of earlier circulars with one framework, graded by the size of the entity.
Email is not named as a chapter of CSCRF. It does not need to be. Phishing, business email compromise and account takeover are how most capital-market incidents begin, so almost every CSCRF function lands on the mailbox. The question your compliance head cannot yet answer cleanly is the same one banks face: can you show, control by control, that your email platform meets what the framework expects?
What CSCRF actually expects, and where email sits in it
CSCRF is organised around five functions, in the NIST style: Governance, Identify, Protect, Detect, Respond and Recover. Obligations scale with your category: Market Infrastructure Institutions and Qualified REs carry the full set, mid-size and small REs a graded subset, and the smallest entities self-certify. For email, the expectations that matter are these.
- Access control and authentication. Multi-factor authentication for users and administrators, least-privilege roles, and a joiner-mover-leaver process that closes mailboxes the day access should end.
- Data protection. Encryption in transit and at rest, classification of what moves through mail, and leak prevention for client data, KYC documents and order information.
- Logging and monitoring. A documented log-retention policy (CSCRF asks for the policy rather than fixing one duration; CERT-In's 2022 directions independently require 180 days, kept in India), clocks synchronised to an approved NTP source, and logs that a Security Operations Centre can actually read.
- Incident reporting. Cyber incidents reported to SEBI and CERT-In within six hours of detection. A compromised mailbox is an incident.
- Vendor and outsourcing oversight. Your email provider is a third party inside your regulated perimeter; CSCRF expects you to govern it, not just buy from it.
One clause deserves a plain statement because it is misquoted constantly. CSCRF did include a data-localisation control (PR.DS.S2) requiring regulatory data to be stored in India. SEBI placed that specific control in abeyance in December 2024, and as of September 2026 it has not been reinstated. So CSCRF, today, does not force your mail server to sit in India. What still does: RBI's payment-data direction if you handle payments, CERT-In's in-India log retention, and your own clients' due diligence. Indian hosting or an on-premise server makes all of that easier to evidence, which is a good reason to choose it. "SEBI mandates it" is not, at the moment, a true one.
The honest part nobody markets
No email product is "CSCRF-certified". The framework describes controls and asks you to evidence them at audit; it does not certify vendors. What a good platform gives a regulated entity is the controls themselves, working and logged: MFA and role-based administration, SPF, DKIM and DMARC enforced, S/MIME with a certificate authority you control, DLP rules for PAN, Aadhaar, account and demat numbers, audit trails you can export for the SOC, and the deployment choice (hosted in India or on your own infrastructure) that lets you answer the residency question however your board decides. That is the framing your IS auditor will accept: aligned controls, evidenced, not a badge.
A checklist your IS auditor can work straight from
- Every mailbox and admin account has MFA enforced, and there is an exception register (ideally empty).
- Administrative rights are role-based and reviewed quarterly; no shared admin logins.
- SPF, DKIM and DMARC are published for every sending domain, with DMARC at quarantine or reject, and the reports are read by someone.
- Mail carrying client or order data is encrypted in transit everywhere and, where policy requires, signed or encrypted with S/MIME.
- DLP rules exist for PAN, Aadhaar, bank account and demat numbers, and their alerts land with a named owner.
- Login, access and admin actions are logged, retained per your written policy and at least 180 days, with clocks on approved NTP.
- A written playbook gets you from "mailbox compromised" to a six-hour report to SEBI and CERT-In, with names, not roles.
- Retention and deletion rules for mail match your record-keeping obligations and your DPDP erasure duties.
- The contract with your email provider covers where data lives, who can access it, breach cooperation and audit rights.
- You can state, with evidence, where your mail is hosted and why that satisfies RBI, CERT-In and your clients even though the CSCRF localisation clause is in abeyance.
If any line is a "we think so", that is worth knowing before the audit rather than during it. Our RBI-aligned checklist for BFSI covers the banking side of the same controls, and the DPDP and business email page covers the duties every regulated entity now carries on top. For entities that want the server inside their own perimeter, the on-premise edition is the same product on your infrastructure.
