India BFSI AI Incident Response Framework 2026: Multi-Regulator Reporting Playbook

General IT incident response — NIST SP 800-61, ISO 27035 — was designed for infrastructure failures and cyber intrusions. When a server goes down, an incident begins and ends at a clearly defined moment. When an AI fraud detection model starts degrading, the incident may have begun weeks before anyone notices a fraud spike. When a credit scoring AI starts producing discriminatory outputs, the harm is distributed across thousands of customers before any single complaint triggers review. The response framework for AI incidents in Indian BFSI must be built from different foundations — and it must satisfy reporting obligations to multiple regulators simultaneously.

Why BFSI AI Incidents Are Different

AI incidents have three properties that require a framework distinct from traditional IT incident response:

Latent onset: an AI fraud detection model can start degrading weeks before a significant fraud event — the "incident" begins at model drift, not at the fraud spike. Traditional incident response starts at detection; AI incident response must begin at anomaly detection in model performance metrics. By the time a fraud spike triggers an alert, the relevant evidence window may be weeks in the past.

Multi-stakeholder impact: a biased credit scoring model may cause discriminatory loan denials across thousands of customers before anyone files a complaint. The impact is distributed across customers, unlike a system outage that has a single restore-point. Remediation includes retroactive review of affected decisions, not just technical restoration. A bank that restores its credit model to normal operation has not remediated the incident — it has only stopped the ongoing harm.

Causal ambiguity: determining whether an AI output failure was caused by model drift, adversarial input, training data bias, or infrastructure failure requires expertise that most incident response teams do not have. Root cause analysis for AI incidents must involve data scientists and model validators, not just security and infrastructure teams. The causal determination affects which regulators must be notified and under what timeline.

India BFSI Multi-Regulator Reporting Matrix

AI Incident Classification: Four Types

Type 1 — AI Security Incident (CERT-In + RBI reportable)

Definition: AI system compromised by external attack — prompt injection attack, model poisoning, adversarial input exploitation, API key compromise.

Examples: LLM customer service bot manipulated to reveal customer data; fraud detection model attacked via adversarial examples to evade detection; model API exfiltrated via unauthorized access.

Reporting: CERT-In 6-hour clock + RBI 2-hour clock (if banking operations affected).

Key evidence to preserve: attack vector, affected model version, input/output logs from attack window, number of affected customers.

Type 2 — AI Performance Failure (RBI MRMF reportable)

Definition: AI model produces significantly degraded or incorrect outputs without external attack — caused by model drift, data quality failure, or distribution shift.

Examples: credit scoring model accuracy drops below threshold; fraud detection false positive rate spikes causing mass transaction blocking; KYC AI rejects legitimate documents at elevated rate.

Reporting: RBI internal escalation per MRMF; not directly CERT-In unless a data breach also occurs.

Key evidence: model performance metrics at time of incident, comparison to baseline, affected decision population, root cause analysis.

Type 3 — AI Fairness/Discrimination Incident (RBI FREE-AI + potential regulatory action)

Definition: AI system produces discriminatory outcomes affecting customer access, credit, or services.

Examples: credit AI denies loans disproportionately to specific demographic groups; fraud AI flags transactions by geographic region disproportionately; KYC AI fails on specific name or script categories.

Reporting: No prescribed incident reporting timeline — but RBI examination can trigger mandatory review; customer complaints to the RBI Banking Ombudsman create a de facto reporting requirement.

Key evidence: statistical analysis of affected population, model feature importance analysis, INDIC-BIAS test results, remediation plan with timeline.

Type 4 — AI Privacy Incident (DPDP + CERT-In reportable)

Definition: AI system causes unauthorized disclosure, processing, or breach of personal data.

Examples: RAG pipeline retrieves customer data and includes it in a response to a different customer; AI training data memorization causes PII leakage; customer behavioral data processed for an unpermitted purpose.

Reporting: DPDP Board 72-hour (when DPBA operational) + CERT-In 6-hour (if security breach) + RBI 2-hour (if banking data).

Key evidence: data categories affected, number of data principals affected, unauthorized processing timeline, technical root cause.

The Incident Triage Decision Tree

When an AI system anomaly is detected, the first 30 minutes determine reporting obligations. Run these steps in sequence:

Step 1 — Security test

Was the anomaly caused by unauthorized external access or attack?

• YES: Type 1 (Security). Start CERT-In 6-hour clock immediately. Notify RBI CISO within 15 minutes for initial assessment. Go to Step 2 in parallel.
• NO: Go to Step 2.

Step 2 — Data breach test

Did the anomaly result in unauthorized disclosure of personal data?

• YES: Type 4 (Privacy). CERT-In 6-hour clock starts (if not already running from Step 1). DPDP 72-hour clock starts when operationally defined. Go to Step 3 in parallel.
• NO: Go to Step 3.

Step 3 — Discrimination test

Did the anomaly produce outputs that disproportionately affect any customer group?

• YES: Type 3 (Fairness). No external reporting obligation under current regulation — but document immediately; regulatory examination risk is high. Go to Step 4 in parallel.
• NO: Go to Step 4.

Step 4 — Performance failure test

Did the AI model produce materially incorrect outputs (below defined performance thresholds)?

• YES: Type 2 (Performance). MRMF internal escalation; DAKSH supervisory reporting if material.
• NO: Document anomaly in the model performance log; escalate if pattern repeats.

Building the AI Incident Response Playbook

Five components every BFSI AI incident response playbook must contain:

1. AI Incident Severity Tiers

Define Critical/High/Medium/Low for AI incidents using BFSI-specific criteria — not generic IT severity levels. Critical: AI system failure causing customer harm or regulatory breach. High: significant model degradation with customer impact potential. Medium: model drift detected before customer impact. Low: anomalous data pattern with no current impact.

2. First-hour checklist

Who is notified within the first hour (CISO, CRO, Compliance Head, model owner, data science lead), what is preserved (model version, input/output logs, feature values at time of incident), what is isolated (affected model endpoint, affected customer population), and which regulatory notification clock has started.

3. Evidence preservation protocol

AI incidents require different evidence than IT incidents: model version hash, training data snapshot reference, feature importance at incident time, model performance metrics timeline (90 days preceding). This evidence must be preserved before any remediation that might alter the model state. Restarting, retraining, or modifying the model before evidence is preserved destroys irreplaceable forensic material.

4. Regulator notification templates

Pre-drafted notification templates for each regulator (RBI, CERT-In, SEBI, IRDAI) with required fields. Completing a template under pressure during an incident produces better output than drafting from scratch. Each template should include fields that are common to all notifications (incident summary, affected systems, preliminary cause) and fields specific to each regulator's prescribed format.

5. Post-incident review with MRMF

AI performance failures require a formal post-incident model review — the MRMF model validation cycle should be triggered, not just the IT incident post-mortem. This review produces the evidence file that satisfies MRMF's ongoing monitoring requirement and the regulator's examination expectation. The post-incident review is also where the root cause is formally established and whether the incident was a Type 1, 2, 3, or 4 event is documented for the regulatory record.

Regulatory Examination vs. Incident Report: Key Difference

A common mistake in BFSI AI incident response is treating regulatory incident reporting and regulatory examination response as the same process. They are not — and confusing them produces failures in both.

Incident report (immediate): filed within the prescribed timeline, covers what happened, what was contained, and what is the preliminary cause. This is time-pressured and necessarily incomplete. A 2-hour RBI incident report cannot contain a full root cause analysis. Attempting to make it comprehensive delays filing and may cause a timeline breach that is a separate violation.

Regulatory examination response (within days/weeks): the comprehensive analysis of root cause, affected population, remediation plan, and control enhancement. This is where the real governance work happens, and where the bank is actually judged on its AI governance maturity.

The incident report buys time; the examination response is where the bank is actually evaluated. Banks that confuse the two either under-report in the incident report (trying to make it comprehensive — impossible in 2 hours) or over-promise in the examination response (repeating the same incomplete narrative from the incident report).

Build separate processes for each: the incident report team (CISO, compliance) files the immediate notification; the model risk and data science team prepares the examination response with full root cause analysis, population analysis, and control enhancement plan.

Frequently Asked Questions