Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›CERT-In Vulnerability Disclosure
India · CERT-In Directions, Sec 70B IT Act

CERT-In vulnerability disclosure & incident reporting

The 6-hour rule, what counts as a reportable incident, and how to run a Responsible Vulnerability Disclosure Program in India

CERT-In — the Indian Computer Emergency Response Team under MeitY — is the national nodal agency for cyber incidents under Section 70B of the IT Act, 2000. Its Directions of 28 April 2022 (in force 27 June 2022) made incident reporting mandatory: any organisation that notices a listed cyber incident must report it to CERT-In within 6 hours of noticing it. Separately, CERT-In runs a Responsible Vulnerability Disclosure Program (RVDP) for reporting flaws in Indian systems, and expects vendors and CISOs to operate their own coordinated-disclosure process.

This page covers both duties: the mandatory incident-reporting obligation (who, what, when, how) and how to stand up a compliant vulnerability-disclosure and remediation workflow — the questions Indian security teams actually ask and that the global disclosure guides do not answer.

Talk to our advisory team Read the Directions on cert-in.org.in
At a glance
6 hoursTo report a noticed incident to CERT-In
28 Apr 2022Directions issued (effective 27 Jun 2022)
180 daysMinimum ICT-system log retention (within India)
Sec 70BStatutory basis; non-compliance is punishable
CERT-In Directions under sub-section (6) of section 70B of the Information Technology Act, 2000
Why this matters

India's mandatory reporting duty — not optional, not the US CERT/CC model

Unlike the voluntary, coordinated-disclosure culture of the US CERT/CC, CERT-In's regime is a legal obligation. The 2022 Directions bind service providers, intermediaries, data centres, body corporates and government organisations operating in India. Miss the window or fail to report and the penalty provisions of Section 70B(7) apply — this is compliance, not courtesy.

The Directions do two related things. First, they mandate incident reporting: a defined list of incidents (from targeted scanning to data breaches, ransomware, and attacks on critical systems) must be reported to CERT-In within 6 hours of the organisation noticing them. Second, CERT-In operates an RVDP so researchers can responsibly report vulnerabilities in Indian systems, and expects regulated entities to run a coordinated-disclosure process of their own so externally-reported flaws are triaged and fixed, not ignored.

How O3 helps

Find it before attackers do. Catch it if they try. Fix it fast.

Across these requirements, O3 runs one continuous loop on your own software so issues surface, get caught, and get fixed before they become an incident.

1 · Find it first

Test like an AI-assisted attacker

An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build before someone outside finds them.

2 · Catch it live

Detect and block exploitation at runtime

A kernel-level eBPF agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot rather than taking down the host.

3 · Fix it fast

Auto-patch what is reachable

Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside tight fix windows instead of sitting in a queue.

Risk-based prioritisation

From alert flood to a short list

KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.

Raw findings in dependency tree~12,400
Vulnerable & version-matched~4,700
Reachable in your code~1,360
KEV / high-EPSS · act now~370

Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.

Remediation expectations

The clock by finding type

Indicative fix windows. Tightest where exposure and active exploitation meet.

Notice a listed incidentT+0
Report to CERT-In (email / phone / portal)within 6h
Preserve logs for the investigation180 days min
Remediate the underlying vulnerabilityrisk-based
Incident reporting

The 6-hour rule: what to report and how

The core obligation. It is triggered by "noticing" — not by confirming impact — so the clock starts early.

Directions 70B, para (ii)–(iv)Annexure I (types of incidents)
Know the reportable list: CERT-In's Annexure I enumerates the incident types — including targeted scanning/probing of critical systems, compromise of critical systems, unauthorised access, website defacement, malicious code / ransomware, data breaches, attacks on servers and network appliances, IoT and application attacks, and fake mobile apps, among others.
Start the clock at "notice": the 6 hours run from when your organisation becomes aware of the incident, not from confirmation or full triage. Build detection-to-report tooling that can raise a report fast.
Report through the accepted channels: email ([email protected]), phone, or the CERT-In portal, using the reporting format CERT-In publishes. Include what you know; you can supplement as the investigation proceeds.
Designate a Point of Contact: the Directions require organisations to nominate a PoC to interface with CERT-In and to respond to its orders and directions.
Where O3 helps

O3 shortens "notice → report" by detecting exploitation at runtime (eBPF process-tree and egress monitoring) and surfacing the affected assets and reachable CVEs, so the reportable facts are assembled in minutes rather than after a manual investigation.

Logging & records

Log retention and time synchronisation

Reporting is only useful if the evidence survives. The Directions impose concrete logging duties.

Directions 70B, para (v)–(vii)
Retain ICT system logs for a rolling period of 180 days, and maintain them within Indian jurisdiction; produce them to CERT-In when ordered.
Synchronise all ICT clocks to NTP from NIC or NPL (or a traceable source), so log timelines across systems line up during an investigation.
For data centres, VPS, cloud and VPN providers: register and retain subscriber/customer records (KYC and specified fields) for the defined period.
Where O3 helps

O3's runtime telemetry and finding fingerprints give you a durable, deduplicated record of what a threat actually did — process lineage, syscalls, and outbound connections — that complements raw log retention with an attack narrative CERT-In can act on.

Responsible disclosure

Running an RVDP / coordinated-disclosure process

Beyond mandatory reporting, you need a front door for researchers and a workflow to fix what they report.

CERT-In RVDPCERT-In SBOM Guidelines v2.0 (VEX/CSAF, §6)
Publish a disclosure policy and a security.txt: state where to report, your scope, expected response times, and safe-harbour language so good-faith researchers engage rather than go public.
Triage on real risk: rank incoming reports by reachability and exploitability, not raw CVSS, so the genuinely exploitable issues are fixed first.
Coordinate the fix and the disclosure: agree a remediation timeline with the reporter, ship the fix, and disclose in a way that protects users — the coordinated-disclosure model CERT-In's RVDP embodies.
Feed vulnerabilities back into SBOM/VEX: track each reported flaw against your Software Bill of Materials and communicate status via VEX/CSAF, aligning with CERT-In's SBOM guidelines.
Where O3 helps

O3 confirms whether a reported CVE is actually reachable in your code before you spend a fix window on it, opens the remediation PR, and blocks exploitation at runtime while the patch ships — turning a disclosure report into a closed loop.

The whole framework

The obligations, mapped to what you actually have to do

All 8 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.

3Reporting
Incident reporting
3Logging
Logs & records
4Disclosure
RVDP / coordinated disclosure
2SBOM
Vulnerability status (VEX/CSAF)
Requirement area
Mandatory incident reportingDirections 70B (ii)Report any listed incident to CERT-In within 6 hours of noticing it.
Reportable incident typesAnnexure IScanning/probing, unauthorised access, defacement, malware/ransomware, data breach, server/appliance/IoT/app attacks, fake apps, etc.
Point of ContactDirections 70B (iii)Nominate a PoC to interface with CERT-In and act on its orders.
Log retentionDirections 70B (v)Retain ICT logs for 180 days within India; produce on order.
Time synchronisationDirections 70B (iv)Sync all clocks to NIC/NPL NTP for consistent forensic timelines.
KYC / subscriber recordsDirections 70B (vi)–(vii)Data centres, VPS, cloud, VPN providers register and retain specified customer records.
Responsible disclosureCERT-In RVDPProvide a reporting channel + coordinated-disclosure workflow for externally-found vulnerabilities.
Vulnerability statusSBOM Guidelines v2.0 §6Track flaws against your SBOM and communicate via VEX/CSAF.
Related frameworks
CERT-In SBOM/CBOM Guidelines v2.0India SBOM compliance (overview)SEBI CSCRFRBI Cyber Security Framework
Vulnerability & threat intelligence
Vulnerability DatabaseMalware AdvisoriesSQL Injection (CWE-89)Deserialization (CWE-502)Cross-Site Scripting (CWE-79)Path Traversal (CWE-22)SSRF (CWE-918)Authentication Bypass (CWE-287)

Turn a CERT-In report into a closed loop

O3 detects exploitation at runtime, assembles the reportable facts fast, confirms which CVEs are actually reachable, and blocks the attack while you remediate — so the 6-hour clock and the fix both stay under control.

Read the Directions on cert-in.org.in
FAQ

Common
questions.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • Under CERT-In's Directions of 28 April 2022 (effective 27 June 2022), any organisation operating in India that notices a listed cyber incident must report it to CERT-In within 6 hours of noticing it. The clock starts at "notice", not at confirmation of impact.
  • The Directions bind service providers, intermediaries, data centres, body corporates and government organisations operating in India. Data centres, VPS, cloud and VPN providers have additional KYC and record-retention duties.
  • CERT-In's Annexure I lists them — including targeted scanning/probing of critical systems, unauthorised access, website defacement, malicious code and ransomware, data breaches, attacks on servers, network appliances, IoT devices and applications, and fake mobile apps, among others.
  • Organisations must retain ICT system logs for a rolling period of 180 days and maintain them within Indian jurisdiction, producing them to CERT-In when ordered. Clocks must be synchronised to NIC or NPL NTP.
  • RVDP is CERT-In's coordinated-disclosure channel for researchers to responsibly report vulnerabilities in Indian systems. Regulated entities are expected to run their own coordinated-disclosure process — a reporting front door, risk-based triage, and a remediation-and-disclosure workflow.
  • The reporting obligation is statutory under Section 70B of the IT Act, 2000. Failure to comply attracts the penalty provisions of Section 70B(7); it is a legal duty, not a voluntary practice.

See O3 Security in Action

See why security and engineering leaders trust O3
to secure their entire software supply chain.