Third-Party Cyber Incident Affecting a Government Service: Vendor, CERT-In and Contract-Evidence Map
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
- When a third-party cyber incident affects a Government service, the customer needs enough evidence to assess service impact and statutory reporting even if the vendor owns the compromised infrastructure. Outsourcing infrastructure does not outsource accountability for the service relationship.
- Contracts should require rapid notice, log retention, forensic cooperation, root-cause analysis, sub-processor visibility, recovery support and regulator / CERT-In assistance. A generic “notify without undue delay” clause can be operationally too vague.
- The evidence map should distinguish vendor facts from customer conclusions. For example, the vendor can provide affected-host logs while the Government service owner determines citizen impact, transaction reconciliation and authority reporting.
Current position
Control and decision map
| # | Control / decision step |
|---|---|
| 1 | Trigger the joint incident bridge and identify vendor / customer decision owners. |
| 2 | Collect vendor timeline, affected assets, data scope, indicators and containment evidence. |
| 3 | Map the vendor incident to the Government service’s citizen / transaction impact. |
| 4 | Assess CERT-In, sector and contractual notification separately. |
| 5 | Reconcile restored transactions / records before normal closure. |
| 6 | Enforce post-incident RCA, remediation and contractual service-credit / risk actions where applicable. |
Evidence pack
- Vendor incident package
- Customer service-impact assessment
- Authority-reporting record
- Recovery / transaction reconciliation
- RCA and contractual remediation tracker
Worked example
A managed-service provider reports ransomware on the database tier supporting a Government portal. The vendor restores from backup, but the customer does not close the incident until it reconciles the citizen transactions processed around the outage, confirms whether personal data was affected and records the CERT-In / regulator assessment.
Common mistakes
- Accepting “service restored” as complete incident closure.
- Allowing a vendor to decide all customer reporting duties.
- Failing to contract for log and forensic access.
- Ignoring sub-processors involved in the affected service.
Frequently asked questions
Can the customer rely entirely on the vendor report?
No. The customer must assess its own service, data and reporting impact.
What is the minimum vendor evidence?
Timeline, affected systems / data, containment, recovery, indicators and RCA support.
Why reconcile transactions after recovery?
Availability restoration does not prove transaction or data integrity.
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)
- Press Information Bureau / MeitY - Government Strengthens Cyber Security Preparedness of Central Government Digital Platforms and Citizen Services (PIB PRID 2299339; 14 Aug 2026)
- Indian Computer Emergency Response Team (CERT-In) - FAQs on Cyber Security Directions of 28.04.2022 (CERT-In FAQ; May 2022; current)
Disclaimer
Educational and professional reference only; confirm the current law, rates and the facts of your case before relying on this page.