India's Cybersecurity Mandate Stack: CERT-In, RBI, SEBI, and the Engineering Reality

Indian cybersecurity regulation has tightened materially in 2022-2026. The CERT-In 2022 Directions imposed a 6-hour incident reporting window — among the strictest globally. The RBI’s CSITE master direction has been updated three times since 2022, with new prescriptive requirements on cloud, third-party risk, and incident response. SEBI’s Cybersecurity and Cyber Resilience Framework (CSCRF), notified in 2024 and operational from mid-2025, applies to all SEBI-regulated entities — mutual funds, AMCs, depositories, custodians, brokers, market infrastructure institutions.

For engineering teams operating in India, the combined effect is that cybersecurity is no longer something a security team owns in isolation. The mandates touch architecture, logging, on-call processes, and vendor selection in ways that engineering has to internalize.

The CERT-In Directions in plain language#

The 28 April 2022 CERT-In Directions (issued under Section 70B(6) of the IT Act) are the headline framework. They apply to all service providers, intermediaries, data centers, body corporates, and government organizations operating in India. The core obligations:

Reportable incidents must be reported to CERT-In within 6 hours. The list of reportable incident types is broad — unauthorized access, data breach, identity theft, denial of service, ransomware, unauthorized network probing, fake mobile apps, attacks targeting IoT devices, and more. The 6-hour window is from the time of “noticing” the incident, not from detection by automated systems. This is the part most teams initially get wrong.

Logs of all ICT systems must be maintained securely for 180 days within India. This is the log-retention mandate. It applies to firewalls, IDS/IPS, authentication systems, web servers, application logs — essentially anything that could be relevant to incident reconstruction. The 180-day window is from when the log was generated.

KYC details and customer transaction logs must be retained for 5 years. This applies to financial intermediaries and certain other regulated entities.

VPN providers, cloud service providers, and data centers must maintain customer registration data for 5 years. Subscriber name, hire/lease period, IPs allotted, validated address, contact details, ownership pattern, and purpose.

Synchronized time sources. All ICT systems must use NTP servers from NPL (National Physical Laboratory) or NIC. This sounds trivial; it is operationally non-trivial when your existing infrastructure has been using pool.ntp.org.

The Directions have been controversial — the VPN provider obligations particularly. Several VPN providers have withdrawn services from India rather than comply. For most enterprise-operated systems, compliance is achievable but requires deliberate engineering.

The RBI CSITE master direction#

The RBI’s CSITE (Cyber Security in Information Technology Examination) master direction, applicable to commercial banks, payment system operators, NBFCs above certain thresholds, and increasingly to regulated fintechs, layers sectoral obligations on top of CERT-In:

• Cyber Crisis Management Plan with defined response timelines, escalation matrix, and tabletop exercises.
• Continuous vulnerability assessment with red-team exercises at defined intervals.
• Cloud usage controls — the bank or NBFC’s board must approve cloud strategy; certain “critical” workloads must use specifically-evaluated providers; data residency must be maintained.
• Third-party / vendor risk — every IT vendor must be assessed against a defined framework; the vendor’s controls must meet the regulator’s requirements.
• Authentication standards — multi-factor for privileged access, defined password policies, biometric for high-risk transactions.
• Quarterly board-level reporting on cyber posture.

The bank/NBFC has primary obligation; in practice the technology team and the vendor must meet the regulator’s requirements together.

SEBI’s CSCRF#

SEBI’s Cybersecurity and Cyber Resilience Framework, notified in 2024, applies to capital-markets-regulated entities. It is structured similarly to the RBI’s framework but with capital-markets-specific overlays:

• Tiered regulated entity classification (qualified RE, mid-sized RE, small RE) with proportionate obligations.
• MII (market infrastructure institutions) — stock exchanges, clearing corporations, depositories — have the strictest obligations including continuous monitoring, dedicated SOC, and zero-trust architecture mandates.
• Cyber audits annually, with the audit report submitted to SEBI.
• Incident reporting timelines aligned with CERT-In’s 6-hour requirement, with additional sector-specific reporting to SEBI.

A mutual fund or AMC that hosts on AWS must demonstrate that the cloud architecture meets the CSCRF requirements; the cloud provider (or the customer running on it) must produce evidence on request.

The engineering implications#

For engineering teams, the combined effect is six concrete obligations.

1. Centralized logging, with India-resident storage and 180-day retention minimum. This is the most operationally significant. You need every meaningful system to ship logs to a centralized store; the store must be in India; the retention must be 180 days or longer; the storage must be tamper-evident. The standard architecture: Cloudwatch / Stackdriver / Azure Monitor as primary, with Splunk, Elastic, or S3 + Athena as the centralized layer. For BFSI, the SIEM is typically Splunk or Sumologic with Indian-region storage; some banks use IBM QRadar or LogRhythm.

2. Incident detection and notification within 6 hours. Detection has to be automated. Notification — to CERT-In, and to the sectoral regulator if applicable — has to be a defined runbook. The runbook should not assume the security team is fully staffed or instantly available. Most CERT-In submissions happen via the official incident reporting form (linked from cert-in.org.in); some categories accept email.

3. NTP synchronization to NPL or NIC time sources. Concrete change: replace pool.ntp.org with time.nplindia.org or samay1.nic.in and samay2.nic.in in your infrastructure config.

4. Customer registration records retained 5 years. For VPN, cloud, and data center providers serving Indian customers. For SaaS providers, this is often interpreted as customer ownership records (who signed up, when, what plan); be deliberate about what counts.

5. Vendor risk documentation. For BFSI and SEBI-regulated entities, every IT vendor needs a documented assessment. We typically maintain this as a versioned set of YAML files in the platform repo with vendor name, controls assessment, last-review date, residual risk, and mitigation. Auditors prefer this format to PDF reports.

6. Sectoral overlays where applicable. If you are BFSI, layer the RBI CSITE requirements. If you are SEBI-regulated, layer the CSCRF. If you are healthcare, layer the ABDM consent framework and the upcoming DPDPA healthcare sectoral rules.

The interaction with DPDPA#

The DPDPA covers personal data; the cybersecurity directions cover incident reporting and system logging. The intersections matter.

Breach notification under DPDPA (72 hours to the Data Protection Board and to affected principals) is different from CERT-In’s 6 hours (to the regulator only). For a breach involving personal data of Indian principals, you must do both — 6 hours to CERT-In, 72 hours to the DPBI and users.

Log retention under DPDPA must respect the lawful retention period for personal data. If logs contain personal data — many do — the 180-day CERT-In requirement and the DPDPA purpose-limitation requirement must be reconciled. The standard pattern is logs that contain pseudonymized or hashed identifiers, with re-identification keys held only by the SOC and audited.

A practical implementation checklist#

What we implement for a typical enterprise client in India in 2026:

1. Centralized SIEM in an Indian region, 12-month retention default (longer than CERT-In’s 180 days, to be safe), tamper-evident.
2. Time synchronization with NPL/NIC servers, monitored for drift.
3. Incident classification matrix mapping detection signals to CERT-In reportable categories, with the runbook for each.
4. 6-hour notification automation — most clients have an on-call escalation path that compresses the time-to-detect-to-notify to under 4 hours of awake time, leaving slack.
5. Vendor inventory with controls assessment, versioned in the platform repo.
6. Tabletop exercises annually with the security, engineering, and leadership teams.
7. Cyber audit annually for SEBI/RBI regulated entities, with the audit report submitted as required.
8. DPDPA breach notification path integrated with the cybersecurity incident-response runbook.
9. Board reporting cadence quarterly for BFSI, semi-annually for SEBI-regulated, and once-yearly for most other regulated entities.
10. Cyber crisis communication plan including the press, customer, and regulator templates pre-drafted.

Where pdpspectra fits#

We run cybersecurity engineering and compliance programs for clients across India and internationally, particularly in BFSI and healthcare. The work spans SIEM design, incident response runbook authoring, vendor risk frameworks, and the platform engineering work that makes the compliance posture operationally sustainable.

Related reading: the DPDPA compliance engineering post, the AI banking Nepal compliance post, and the cybersecurity tabletop exercises post.

---

The mandate stack is real. Talk to our team about your cybersecurity program.