Cyber Risk Quantification in INR: A FAIR Model for India

Cyber risk quantification in India means stating exposure in rupees, not red-amber-green tiles. The defensible method today is FAIR (Factor Analysis of Information Risk), localised with DPDPA penalty bands, RBI Cyber Security Framework fine precedents, SEBI CSCRF downtime obligations and India-specific incident response costs. This post is a worked example: two scenarios, the actual LEF and LM math in INR, and a three-slide board narrative you can lift directly.

Indian boards have stopped accepting heatmaps. CFOs at NBFCs, AMCs and fintechs now ask the CISO a single question — "What is our annualised loss exposure in rupees, and what does the next ₹1 crore of security spend buy us?" If your risk register cannot answer that, you are presenting opinions, not risk. FAIR is the only ISO-recognised standard (ISO/IEC 27005:2022 references it) that produces a number a CFO can reconcile against the insurance schedule and the audit committee minutes.

The 5x5 likelihood-impact matrix has three structural failures that Indian regulators and audit committees now expose. First, the categorical labels ("High", "Medium") have no defensible aggregation — you cannot sum a red and an amber to tell the board the enterprise number. Second, post-DPDPA notification, the Data Protection Board can levy up to ₹250 crore per instance of significant non-compliance under Section 33 of the Digital Personal Data Protection Act, 2023, and that single fact alone breaks the upper-bound assumption baked into most heatmaps. Third, RBI's SPARC and SEBI's CSCRF require quantitative incident reporting and "potential financial impact" disclosure — categorical risk is no longer audit-grade.

We have run risk reviews at 11 NBFCs and 3 SEBI-registered AMCs in the last 18 months where the heatmap rated a critical exposure as "Medium" because the previous CISO had no rupee anchor. After re-running the same scenarios through FAIR with localised loss tables, the same risk landed at ₹14-38 crore of annualised loss exposure — enough to fund a full SOC overhaul and still show ROI to the audit committee. The board didn't approve the budget because the colour changed; they approved it because the number could be reconciled against the cyber insurance retention.

The other forcing function is CERT-In's 6-hour reporting directive (CERT-In Directive No. 20(3)/2022, in force since 2022). When a P1 incident hits, the board wants three numbers within the same six hours: notification penalty exposure, downtime cost, and forensic-plus-legal burn rate. Heatmaps give none of these. FAIR gives all three because every loss form is already decomposed and dollar-tagged (rupee-tagged, in our case) before the incident happens.

FAIR decomposes risk into two top-level factors: Loss Event Frequency (LEF) — how many times per year a specific loss event materialises — and Loss Magnitude (LM) — how many rupees that event costs you when it happens. Multiply the two and you get Annualised Loss Exposure (ALE) in INR. The discipline is in the decomposition.

LEF is further split into Threat Event Frequency (TEF) and Vulnerability (Vuln). TEF is "how often does a threat actor attempt this attack against us specifically" — for a tier-2 NBFC, credential stuffing attempts run in the millions per month, but targeted ransomware attempts against the core lending app might be 4-12 per year. Vulnerability is the probability that an attempt succeeds given current controls — for an org with MFA, EDR and a 24x7 SOC, you might assess Vuln at 0.5-2%.

LM decomposes into six loss forms that the FAIR Institute formalised: Productivity, Response, Replacement, Fines & Judgements, Competitive Advantage, and Reputation. For India, we additionally split Fines into three buckets — DPDPA, sectoral regulator (RBI/SEBI/IRDAI), and CERT-In directive non-compliance — because the maximum exposure and the triggering event differ.

The Monte Carlo layer is what turns FAIR from a spreadsheet into a board-defensible model. Instead of point estimates, every factor is expressed as a PERT distribution (Min, Most Likely, Max). A tool like the open-source OpenFAIR reference model or Jack Jones' FAIR-U platform runs 10,000+ iterations and produces a loss exceedance curve. The board sees not a single number but a 90th-percentile loss — "there is a 10% chance we lose more than ₹47 crore this year from this scenario" — which is the same statistical grammar used in Value-at-Risk reporting they already trust from the treasury desk.

This is where most off-the-shelf FAIR templates fail Indian users — they assume GDPR fines, US class-action settlements and SEC 8-K disclosure costs. Replace the loss table with the following India-calibrated figures, refreshed against published enforcement actions through Q1 2026:

Loss Input	India-Specific Range	Source / Anchor
DPDPA significant non-compliance fine	₹50 cr – ₹250 cr per instance	DPDP Act 2023, Schedule
DPDPA failure to notify breach	Up to ₹200 cr per instance	DPDP Act 2023, Section 8(6)
RBI monetary penalty (typical, last 24 mo)	₹25 lakh – ₹3 cr per violation	RBI press releases 2024-2026
SEBI CSCRF non-compliance	₹1 lakh per day, up to ₹1 cr	SEBI Act Section 15HB
CERT-In 6-hour notification breach	Up to 1 yr imprisonment / fine	IT Act Section 70B(7)
Forensic + DFIR cost (P1)	₹40 lakh – ₹2.5 cr	Certbar engagement data, 2024-26
Per-record customer notification	₹180 – ₹450 per record	India breach response cost benchmarks
Core banking / lending downtime	₹8 lakh – ₹35 lakh per hour	NBFC client telemetry, top quartile

The IBM Cost of a Data Breach Report 2025 puts the average India breach cost at around ₹19.5 crore, but that average hides a 12x spread between a SaaS startup and a tier-1 NBFC. Always anchor to your sector, not the national average. For BFSI, also factor in the RBI Cyber Security Framework obligation to maintain a 24x7 SOC — failure here is a separate, stackable violation independent of the underlying breach.

Setting: a Series C lending fintech, 4.2 million KYC records, AWS-Mumbai, hybrid SOC. Scenario: API authorisation flaw (BOLA / OWASP API1:2023) exfiltrates 600,000 KYC bundles including Aadhaar masked numbers, PAN and bank statements.

LEF decomposition:

• TEF (targeted API attacks/year): Min 3, ML 8, Max 20 — based on observed attack telemetry from comparable lenders
• Vuln (success probability): Min 4%, ML 12%, Max 28% — pre-WAF tuning, no API-specific runtime protection
• LEF Most Likely ≈ 8 × 0.12 = 0.96 events/year

LM decomposition (per event, INR):

• DPDPA fine (significant non-compliance + notification failure risk): ₹40 cr – ₹180 cr, ML ₹85 cr
• Forensic + DFIR + legal: ₹1.2 cr – ₹3.5 cr, ML ₹2.1 cr
• Customer notification (600k × ₹250): ₹15 cr
• Credit monitoring offering (60% uptake × ₹400/yr × 2 yr): ₹28.8 cr
• Reputation / churn (8-14% of high-value book, capitalised): ₹22 cr – ₹60 cr, ML ₹35 cr
• Total LM Most Likely ≈ ₹165.9 cr per event

ALE Most Likely = 0.96 × ₹165.9 cr ≈ ₹159 crore/year. Run 10,000 Monte Carlo iterations and the 90th percentile lands near ₹240 cr, the 10th near ₹62 cr. The board now has a defensible "we are carrying ₹159 cr of annualised exposure on this one API surface" — and the proposal to spend ₹3.5 cr on API runtime protection, BOLA-aware DAST and a dedicated red team retainer becomes a 45x return calculation, not a feature request. This is exactly the framing we package in a Certbar AI risk assessment deliverable.

Setting: a deposit-taking NBFC, ₹14,000 cr AUM, outsourced SOC with 8x5 escalation. Scenario: a ransomware operator (assume the 2024 Akira / BlackSuit playbook against Indian financial services) lands a payload at 02:40 IST on a Saturday. Detection is delayed 6.5 hours because the SOC is not staffed.

LEF decomposition:

• TEF (targeted ransomware attempts/year): Min 4, ML 9, Max 18
• Vuln (success given 8x5 SOC + legacy AD): Min 6%, ML 15%, Max 32%
• LEF Most Likely ≈ 9 × 0.15 = 1.35 events/year

LM decomposition (per event, INR):

• RBI monetary penalty for SOC framework breach: ₹0.5 cr – ₹3 cr, ML ₹1.5 cr
• RBI follow-on supervisory action (capital add-on, indirect): ₹5 cr – ₹25 cr, ML ₹12 cr
• Core lending downtime (52 hrs × ₹22 lakh/hr): ₹11.4 cr
• Forensic + IR retainer + rebuild: ₹2.8 cr – ₹6 cr, ML ₹4.1 cr
• Ransom (organisational policy permitting; modelled, not advised): ₹3 cr – ₹14 cr, ML ₹6 cr — see our ransom payment decision framework
• DPDPA exposure if customer data exfiltrated (60% probability × ₹80 cr): ₹48 cr expected
• Reputation / collection-book impact: ₹9 cr – ₹22 cr, ML ₹14 cr
• Total LM Most Likely ≈ ₹97 cr per event

ALE Most Likely = 1.35 × ₹97 cr ≈ ₹131 crore/year. The single highest-leverage control is upgrading from 8x5 to 24x7 SOC, which compresses Vuln from 15% to ~5% — dropping ALE to ~₹44 cr/year. The ₹87 cr/year delta justifies an ₹8-12 cr 24x7 SOC programme inside one budget cycle. This is the exact narrative we hand NBFC audit committees in our RBI compliance engagements.

Boards do not read Monte Carlo histograms. They read three slides, in this order, and you should build every quarterly report this way.

Slide 1 — The Number. One line: "Annualised cyber loss exposure: ₹X crore (P50), ₹Y crore (P90)." One bar chart: top five scenarios ranked by ALE. One sentence on YoY change. That is the entire slide. The CFO and audit committee chair will spend 40 seconds here and move on if the number is plausible and trending right.

Slide 2 — The Drivers. A tornado chart showing which factors move ALE most — typically DPDPA fine band, downtime hourly rate, and SOC detection time. This is where you make the case that "if we cut MTTD from 6 hours to 30 minutes, ALE drops by ₹54 cr." Every driver should map to a control on your roadmap. If a driver has no roadmap item, the board will ask why, which is the question you want.

Slide 3 — The Ask. One column: proposed investment in ₹ cr. Second column: ALE reduction in ₹ cr. Third column: ratio. Nothing else. Anything below 3x is a hard sell, anything above 10x usually approves itself. We have closed eight-figure security budgets at NBFCs and AMCs in 90-second board readouts using exactly this template — the model is doing the persuading, not the deck.

Attach the full FAIR model (the spreadsheet or Archer/RiskLens export) as an appendix. The board will never open it. The auditor and the cyber insurance underwriter will, and they are the two stakeholders who validate whether your number is defensible.

Five failure modes we see repeatedly when teams self-implement FAIR in Indian contexts.

1. Treating DPDPA fines as point estimates. The Data Protection Board has not yet published a graduated fine schedule, so model the fine as a PERT distribution with wide max (₹250 cr) and weighted ML based on case severity and culpability. Anchor at ₹50 cr for a single significant non-compliance, scale up for repeat or wilful breaches.

2. Forgetting that RBI penalties stack with DPDPA. A bank that breaches both the RBI Cyber Security Framework and DPDPA pays both — they are not alternative regimes. Your LM must aggregate, not pick the maximum. Same logic for SEBI CSCRF on AMCs and brokers.

3. Underweighting downtime cost in non-BFSI. SaaS firms routinely undercount because they don't have a "transaction per second × revenue" number. Use SLA credit exposure plus churn probability — for B2B SaaS, 4+ hours of downtime in a quarter typically triggers customer-initiated contract reviews on 6-12% of ARR.

4. Confusing inherent and residual risk. FAIR models residual risk by default — i.e., with current controls in place. If you want to argue for new spend, model the residual ALE today vs the residual ALE after the proposed control. Inherent (no-controls) numbers are useful only for stress-testing insurance limits.

5. Running FAIR once and never updating it. Threat event frequency moves quarterly. After every CERT-In advisory, every published RBI penalty, and every major Indian breach (Polycab 2024, Star Health 2024, BSNL 2024), refresh your TEF inputs. We re-baseline client FAIR models at least twice a year and after any P1 incident in their sector. See our VAPT and threat-intel feeds for the underlying data.

If you are building this in-house and want a peer review of your loss tables and Monte Carlo setup, the NIST Cybersecurity Framework 2.0 "Govern" function (GV.RM) explicitly references quantitative risk methods and is a useful audit-side reference when you defend the model to your statutory auditors.

If your CISO cannot tell the board the rupee figure for the top three cyber scenarios, you are not running a risk programme — you are running a controls programme and hoping the controls are the right ones. FAIR, localised properly, fixes that in one quarter.

Certbar's AI risk assessment and quantification practice runs full FAIR models with India-calibrated loss tables for BFSI, fintech and SaaS clients, including a board-deck handoff and a 12-month re-baseline cycle. If your next audit committee meeting needs a rupee number you can defend, talk to us — we typically deliver a first-draft model and three-slide narrative in 4-6 weeks.