CERT-In Incident Response for a Government-Connected Vendor: Notification, Evidence and Coordination Checklist
By Ravi Sisodia · Reviewed by CA Divyanshu Sengar · Updated 5 October 2026
India-first finance, audit and risk workflow with primary-source anchors.
2-minute summary
- A vendor connected to a Government or citizen-facing service needs a pre-agreed incident path because the first six hours can be consumed identifying owners, preserving logs and deciding who reports. Contract language should support - not delay - CERT-In and regulator assessment.
- The vendor should preserve volatile evidence, isolate affected systems where safe, identify impacted services / data and notify the customer with the information available at that time. CERT-In’s framework allows available information to be reported first and supplemented later where necessary.
- Government-connected environments may involve additional coordination with the service owner, sector regulator, law enforcement or NCIIPC where critical information infrastructure is involved. The contract should never assume one notification satisfies every authority.
Current position
Control and decision map
| # | Control / decision step |
|---|---|
| 1 | Maintain an incident contact matrix for vendor, customer CISO, legal, regulator and CERT-In. |
| 2 | Preserve system, firewall, identity and application logs before rebuilding affected assets. |
| 3 | Classify whether the incident falls within CERT-In reportable categories and record the decision time. |
| 4 | Send an initial customer incident notice with known facts, service impact and containment status. |
| 5 | Coordinate authority reporting without waiting for a perfect root-cause report. |
| 6 | Track remediation, evidence return and post-incident contractual actions to closure. |
Evidence pack
- Vendor incident notification
- Time-stamped log preservation record
- CERT-In assessment / report reference
- Service-impact timeline
- Root-cause and remediation closure
Worked example
A cloud vendor detects unauthorised admin access at 10:00 AM affecting a citizen-service API. At 11:00 AM it has containment evidence but not the full forensic cause. The incident team should not wait until the next day for a polished report; it escalates to the Government customer, assesses CERT-In reporting and preserves logs while the investigation continues.
Common mistakes
- Waiting for a final forensic report before escalating.
- Assuming the vendor alone owns all reporting duties.
- Rebuilding servers before preserving volatile evidence.
- Using a contract SLA longer than statutory reporting windows as the only deadline.
Frequently asked questions
Is every vendor incident reportable to CERT-In?
No. Assess the incident against the current directions and categories.
Can incomplete information be reported?
CERT-In guidance permits reporting information available at the time and supplementing details later.
What should the contract require?
Prompt notice, log preservation, cooperation, root-cause evidence and authority-support obligations.
Official sources
- Indian Computer Emergency Response Team (CERT-In) - Directions under section 70B on cyber security practices and incident reporting (No. 20(3)/2022-CERT-In; 28 Apr 2022; current)
- Indian Computer Emergency Response Team (CERT-In) - FAQs on Cyber Security Directions of 28.04.2022 (CERT-In FAQ; May 2022; current)
- Press Information Bureau / MeitY - Government Strengthens Cyber Security Preparedness of Central Government Digital Platforms and Citizen Services (PIB PRID 2299339; 14 Aug 2026)
Disclaimer
Educational and professional reference only; confirm the current law, rates and the facts of your case before relying on this page.