What Is CSITe and Why It Matters
CSITe — Cyber Swachhta Integrated Threat Exchange — is CERT-In's mandatory incident reporting portal. Under the April 2022 Directions (amended 2023), issued under Section 70B of the Information Technology Act 2000, every service provider, intermediary, data centre, government body, and body corporate operating in India must report cybersecurity incidents to CERT-In within 6 hours of detection.
CSITe is the only accepted channel for this reporting obligation. Email to CERT-In is not sufficient. Phone calls are not sufficient. Reporting to your sector regulator (RBI, SEBI, IRDAI) does not satisfy the CERT-In obligation. The portal at https://csite.cert-in.org.in is the exclusive filing mechanism — and you must be registered before an incident occurs.
Portal Registration: Before You Can File
Registration is a one-time process but has mandatory prerequisites. You cannot create a CSITe account during an active incident — the approval takes 24–48 hours. Register now.
Portal URL: https://csite.cert-in.org.in
Required information for registration:
- Organisation identifier: CIN, LLPIN, PAN, or Government Entity ID
- Primary SPOC name and designation
- Primary email address — must be an organisation domain (Gmail/Yahoo rejected)
- Mobile number for OTP verification
Two critical post-registration steps most organisations skip:
- Designate a minimum of 2 SPOCs (primary and backup). A single SPOC is a compliance gap — if your SPOC is on leave or unreachable during an incident, you cannot file without their credentials.
- Create a shared mailbox (e.g., cert-in-reports@yourdomain.com) as the registered email address. This ensures CERT-In notifications are not lost when the designated SPOC is unavailable, on leave, or has left the organisation.
The 6-Hour Clock: Exact Trigger Points
The CERT-In Directions state the 6-hour window begins from the time the organisation becomes aware of the incident — not from when it is confirmed, not from when root cause is established, and not from when management approves the filing. The clock starts at detection.
Events that start the 6-hour window:
- SIEM alert acknowledged by a SOC analyst
- EDR quarantine action triggered on an endpoint
- User reports suspicious activity to the helpdesk and it is escalated to the IR team
- Cloud provider sends a security incident notification email
- Third-party MSSP alert received and logged
- Vendor notifies you of a breach affecting your data
You do NOT need to wait for:
- Root cause analysis to complete
- Full scope assessment (how many systems, how much data)
- Attacker attribution
- Legal or management approval
- Forensic evidence collection
"The CSITe portal has 44 incident type categories. Selecting the wrong one — even if the incident is legitimately reported — is the single most common reason CERT-In follows up with an 'inadequate report' notice."
CSITe Filing: Field-by-Field Walkthrough
Pre-populate these fields in your Incident Response Plan so that when an incident occurs, your team is filling known blanks rather than researching unfamiliar fields under time pressure.
Most common BFSI selections: Targeted Scanning/Probing of Critical Networks; Phishing/Social Engineering; Ransomware Attack; Data Breach; Unauthorised Access; Website Intrusion and Defacement; DDoS Attack.
Tip: Choose the PRIMARY incident type only. Do not select "Other" for complex incidents — classify by the primary impact and note secondary vectors in the description field.
This is the field most organisations get wrong.
If the investigation is still ongoing at T+6 — and it almost certainly will be — select "Unknown" and state "investigation ongoing" in the description.
Do NOT select "No" if you have not confirmed there was no data exposure. Premature "No" that is later contradicted by forensic findings creates a mandatory follow-up notice from CERT-In and can trigger findings of false reporting under the Directions.
Include all of the following: (1) Attack vector if known; (2) Affected asset category; (3) Containment actions already taken; (4) Current incident status; (5) Next steps and expected timeline for preliminary findings.
The 3 Most Common Rejection Triggers
An "inadequate report" notice from CERT-In is not the same as non-compliance — but it triggers mandatory follow-up, consumes IR team time, and appears on your regulatory record.
Selecting "Website Defacement" for a ransomware attack that encrypted a web server, or selecting "Malware" for ransomware. The primary impact category must lead the classification. If ransomware encrypted files — that is "Ransomware Attack," even if the initial vector was a phishing email and the server hosted a website. The phishing vector and website impact go in the description field; the primary type in the drop-down must reflect the dominant harm.
Stating "approximately 10 PM" without a date or timezone. CERT-In requires unambiguous timestamps. Best practice: use DD-MM-YYYY HH:MM IST format consistently. If your SIEM logs in UTC, convert to IST and note both in the description (e.g., "17:30 UTC / 23:00 IST on 28-04-2026"). Ambiguous timestamps prevent CERT-In from correlating your report with national threat intelligence patterns.
Claiming no data was compromised in the initial 6-hour filing when the investigation is still in the first hour. The "No" selection implies confirmation — and CERT-In treats it as such. When a subsequent follow-up report reveals potential data exposure, the discrepancy triggers mandatory clarification letters and can result in a non-compliance finding. The correct answer when evidence is not yet in hand is always "Unknown."
After You Submit: What Happens Next
Filing the initial report is not the end of your CSITe obligation — it is the start of a structured follow-up process that continues for up to 30 days.
CERT-In sends an automated acknowledgment email to the registered SPOC with a case reference number. Save this reference number — all future correspondence and follow-up reports must cite it.
A CERT-In analyst may contact the SPOC via registered email or phone for clarification or additional technical details. Ensure your SPOC is reachable. If the primary SPOC is unavailable, inform CERT-In and designate the backup SPOC.
You must file a follow-up report through CSITe within 24 hours containing preliminary forensic analysis, updated scope, affected system count, initial attack vector assessment, and containment status.
A detailed technical report covering full incident timeline, IoCs identified, affected data categories and volume, remediation actions taken, and updated impact assessment. This is the primary technical document CERT-In uses for national threat intelligence.
CERT-In expects a formal closure report within 30 days of the initial filing. This includes root cause analysis, lessons learned, controls implemented or planned, and confirmation that all affected systems have been remediated.
Regulatory Parallelism: Filing CERT-In While Meeting Other Obligations
A major cybersecurity incident in a BFSI organisation typically triggers multiple simultaneous reporting obligations. These run in parallel — not sequentially. Filing with one regulator does not satisfy another.
Internal escalation to management within 4 hours of detection; report to RBI within 6 hours — separate from CERT-In. These are two separate reports to two separate regulators. Filing with CERT-In does not notify RBI.
SEBI-regulated entities (brokers, AMCs, depositories) must report cyber incidents to SEBI within 6 hours AND to CERT-In within 6 hours — two separate filings with different templates, different contact points, and different follow-up processes.
If the incident involves personal data, trigger DPDP Act breach notification to the Data Protection Board of India and to affected data principals simultaneously. The DPDP notification is separate from the CERT-In filing and uses different content requirements.
If card data is involved, PCI-DSS breach notification obligations to Visa, Mastercard, and other card networks apply independently. In a major breach, all four tracks — CERT-In, RBI, DPDP, and card networks — may run simultaneously.
Pre-Incident CSITe Readiness Checklist
Organisations that file CSITe reports accurately and on time have one thing in common: they prepared the filing before the incident happened. Use this 12-point checklist in your annual IR tabletop exercise.
Common BFSI Scenarios Mapped to CSITe Incident Types
Quick reference for SOC teams at the moment of detection — map your scenario to the correct CSITe incident type before the drop-down causes hesitation.
| BFSI Scenario | CSITe Incident Type | Notes |
|---|---|---|
| Phishing email campaign targeting customers | Phishing/Social Engineering | File even if no credentials were captured |
| Ransomware on core banking server | Ransomware Attack | Not "Malware" — ransomware has its own category |
| Unauthorized access to customer database | Data Breach | Primary category is Data Breach; note Unauthorised Access in description |
| DDoS on internet banking portal | DDoS Attack | File even if mitigated within 6 hours |
| ATM skimming device discovered | Targeted Scanning/Probing | Plus financial fraud category if applicable |
| Insider theft of customer data | Data Breach | File even if perpetrator is internal to organisation |
| Vendor/third-party breach affecting org data | Data Breach | File even if the attack was on the vendor's systems |
| BEC/CEO fraud email received | Phishing/Social Engineering | File even if no financial loss has occurred yet |
Work Through CSITe Readiness with Practitioner Toolkit
Practitioner Toolkit by CreativeCyber includes the CERT-In incident response SOP, pre-mapped CSITe incident categories, parallel DPDP / RBI / IRDAI deadline worksheets, and portal filing templates — operational tools for practitioners.
Open Practitioner Toolkit →