Incident Response and Incident Investigation Are Different Jobs on Different Clocks
Incident response is urgent: contain the harm, restore service, notify whoever needs notifying — it runs in hours to days. Incident investigation is slower and analytical: trace the causal chain, attribute the failure to a specific root cause, and produce a record that satisfies regulatory reporting and actually informs remediation — it runs in days to weeks. Treating these as the same activity is how banks end up with an incident report that says what happened but never says why, which is useless for deciding who fixes what.
Root cause attribution is what makes the investigation actionable: model degradation belongs to the model risk function, a deployment configuration error belongs to IT, an adversarial input that got through belongs to security. Get the attribution wrong and remediation lands on the wrong desk.
Six Phases of a Governance-Grade Investigation
Scoping and timeline reconstruction. Establish what the system produced during the incident window, how many customers or transactions were touched, and the earliest confirmed point of incorrect behavior, using system logs and monitoring data. A timeline with gaps in it is itself a finding — it means the system's logging wasn't sufficient to reconstruct what happened, independent of whatever the underlying incident was.
Evidence preservation. Capture the production state before any remediation changes it — model version, feature values, and predictions from inference logs for ML systems; exact prompt context, retrieved documents, and outputs for LLM/RAG systems; raw input data for pipeline-driven incidents. Preservation has to be the first step after containment, not something that happens after the analysis starts, because evidence overwritten before it's captured is evidence gone for good.
Root cause attribution. Determine primary and contributing causes across five categories: model fault (incorrect output within normal operating range), data fault (distribution shift or quality issue), deployment fault (configuration or integration error), adversarial fault (a deliberate attack got through), or governance fault (an approval or monitoring gap let something unsafe run). Most real incidents have more than one contributing cause — stopping at the first proximate cause misses the ones that will cause the next incident.
Customer impact assessment. Quantify who was affected, what kind of harm occurred, and the financial and reputational scale — and for BFSI specifically, flag whether any affected customers sit in a protected or financially excluded segment (PMJDY, priority sector, vulnerable customers), because differential harm in those segments carries its own regulatory attention beyond the aggregate number.
Control gap assessment. Ask which existing control should have caught this earlier, and why it didn't. The answer should point directly at the fix: a threshold set too loosely gets recalibrated; a failure mode nobody was monitoring gets a new control; a bypassed approval gate gets a process fix. Remediation that treats the symptom without closing the actual control gap just buys time until the same incident happens again.
Regulatory reporting and retention. Decide whether notification is required, prepare the package, and retain the full investigation record — timeline, preservation record, attribution, impact assessment, remediation plan, regulatory correspondence — in a durable, tamper-evident form, kept separately from (but cross-referenced to) the incident response record. Examiners and legal proceedings can both come looking for this record years after the fact.
Root Cause Attribution Drives Everything Downstream
| Root Cause | What to Look For | Who Owns Remediation | Reporting Implication |
|---|---|---|---|
| Model fault | PSI/performance degraded before the incident; correct on training-distribution inputs, wrong on incident inputs | Model risk / validation | Model review and revalidation if the function is regulated |
| Data fault | Clean on test data; data quality alerts around the incident start; upstream pipeline or source change | Data engineering / governance | Assess data governance adequacy; DPDP exposure if personal data involved |
| Deployment fault | Incident coincides with a deployment or config change; correct in test environment | IT / DevOps | Governance finding on its own if a deployment gate was bypassed |
| Adversarial fault | Systematic adversarial input pattern; targeted rather than broad-based | Security / CISO | Likely a cyber incident reporting trigger, separate from operational reporting |
| Governance fault | Change occurred without required approval; monitoring coverage gap let it continue undetected | Model risk / compliance | Likely a reportable control failure; drives framework-level remediation |
An investigation that concludes "the model performed incorrectly" and stops there is not governance-grade — it doesn't tell the board what failed, doesn't route remediation to the right function, and doesn't tell an examiner whether the gap is a one-off or structural.
India BFSI Context: RBI Reporting, CERT-In, and the Segment Question
RBI operational risk reporting. AI incidents resulting in customer harm, data breach, AML/sanctions failure, or material disruption in regulated functions are likely reportable under RBI's operational risk reporting expectations, within the timeframes RBI's framework sets for significant operational incidents. A bare notification without an investigation summary attached does not satisfy this reporting obligation on its own.
Board accountability for governance gaps. Where an incident reveals a governance gap — a model deployed without proper validation, a monitoring blind spot, unassigned accountability — the board-accountability direction set by RBI's FREE-AI Committee report creates an expectation that this gap reaches the board, not just the function that caused it. ****
Personal data breach notification. If the incident involved unauthorized access to or incorrect processing of personal data — including one customer's data leaking into another's AI-generated output, a real risk in shared-tenant LLM inference — it may trigger a personal data breach obligation under the DPDP Act 2023. ****
Differential harm across customer segments. If a BFSI AI incident touched multiple customer segments, the investigation should explicitly check whether PMJDY or other financially excluded customers were disproportionately affected — disaggregating by segment is usually the first question RBI asks, not an afterthought to the aggregate impact number.
Action Checklist for Your Incident Investigation Procedure
- Separate your incident response runbook from your incident investigation procedure — different clocks, different outputs, different owners.
- Make evidence preservation the mandatory first step after containment, before any remediation touches production.
- Require every investigation to name a primary root cause and all contributing causes across the five categories — no closing an investigation on "the model was wrong."
- Track CERT-In cyber incident reporting and DPDP Act breach notification as two separate obligations with two separate clocks, not one combined timeline.
- Disaggregate customer impact by segment in every investigation involving customer-facing AI, with PMJDY and priority-sector customers flagged explicitly.
Related Articles
Forensic investigation capability built in.
Zytra's Forensic Replay reconstructs the exact model context state at any point in time from inference logs — enabling root cause attribution and regulator-ready investigation reports without manual evidence reconstruction.
Talk to sales