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
After submitting the registration form, CERT-In reviews and approves within 24–48 business hours. You will receive login credentials to the registered email address.
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.
Use IST explicitly — state the timezone in the description field as well. Many filings are followed up because the timezone was ambiguous. Format: DD-MM-YYYY HH:MM IST. If your systems log in UTC, convert to IST and note both in the description.
Leave blank only if occurrence and detection were simultaneous. Do not guess the occurrence time if it is not established — state "Unknown — under investigation" in the description. Providing an incorrect time that conflicts with forensic findings later creates compliance complications.
Count of affected systems (hosts/endpoints/servers). An approximate count is acceptable at T+6 — explicitly state "preliminary assessment" in the description field. You will update this in the 24-hour follow-up report.
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:
- Attack vector if known
- Affected asset category (e.g., core banking servers, internet banking portal, customer database)
- Containment actions already taken
- Current incident status
- Next steps and expected timeline for preliminary findings
Template:
Use the pre-registered SPOC details exactly as they appear in the portal registration. Changing contact details at filing time — using a different name or email than what CERT-In has on record — causes matching failures and delays acknowledgment. If the primary SPOC is unavailable, use the backup SPOC registered on the portal.
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. These three errors account for the majority of CSITe follow-up notices:
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 — and generate an automatic follow-up request.
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 between "No" and the updated finding 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 as the point of contact.
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 |
Related Reading
Continue Your Research
CERT-In 6-Hour Incident Reporting: The BFSI Practitioner's SOP
The hour-by-hour timeline and decision framework for meeting your 6-hour CERT-In obligation under the 2022 Directions.
Read article DPDP vs GDPRDPDP Act vs GDPR: The Side-by-Side Comparison India's DPOs Actually Need
DPDP breach notification runs parallel to your CERT-In filing. Know both clocks simultaneously.
Read article SEBI CSCRFSEBI CSCRF Maturity Assessment: The Practitioner's Survival Guide
SEBI-regulated entities file both SEBI and CERT-In incident reports. CSCRF evidence requirements for incident response.
Read articleIs your organisation CSITe-ready?
Share this guide with your IR team, CISO, and compliance officer before the next incident hits.
Automate CSITe readiness with CreativeCyber
RiskSage — CreativeCyber's AI-native GRC platform — includes a built-in CERT-In incident response engine with pre-mapped CSITe incident types, parallel DPDP and RBI tracking, and auto-populated portal fields from your asset registry. Learn more about RiskSage or explore the BFSI Incident Response Toolkit.