Cyber Risk Quantification in INR: A FAIR Model for India

By mid-2026, Indian audit committees at NBFCs, AMCs and fintechs have stopped reading heatmaps. The Data Protection Board can levy up to Rs 250 crore per instance of significant non-compliance under Section 33 of the DPDP Act 2023, and RBI's SPARC plus SEBI's CSCRF now expect quantitative incident reporting, not categorical labels. That shift creates a specific problem for the CISO. The CFO at your next audit committee meeting will ask one question: "What is our annualised loss exposure in rupees, and what does the next Rs 1 crore of security spend buy us?" If your risk register answers in red, amber and green, you are presenting opinions, not risk, and the budget conversation ends there. This post is the rupee-denominated answer. We walk through FAIR (Factor Analysis of Information Risk), localised with DPDPA penalty bands, RBI fine precedents and SEBI CSCRF downtime obligations, then show two worked scenarios with actual LEF and LM math, plus the three-slide board deck you can lift directly into your next quarterly report.

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 Rs 250 crore per instance of significant non-compliance under Section 33 of the Digital Personal Data Protection Act, 2023, and that single fact 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, so 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 Rs 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 rupee-tagged before the incident happens.

FAIR decomposes risk into two top-level factors. Loss Event Frequency (LEF) is how many times per year a specific loss event materialises. Loss Magnitude (LM) is 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 formalised by the FAIR Institute: Productivity, Response, Replacement, Fines and 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. The maximum exposure and the triggering event differ across all three.

The Monte Carlo layer 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). The open-source OpenFAIR reference workbook 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 Rs 47 crore this year from this scenario." That 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 Rs 50 cr to Rs 250 cr per instance DPDP Act 2023, Schedule DPDPA failure to notify breach Up to Rs 200 cr per instance DPDP Act 2023, Section 8(6) RBI monetary penalty (typical, last 24 months) Rs 25 lakh to Rs 3 cr per violation RBI press releases 2024-2026 SEBI CSCRF non-compliance Rs 1 lakh per day, up to Rs 1 cr SEBI Act Section 15HB CERT-In 6-hour notification breach Up to 1 yr imprisonment or fine IT Act Section 70B(7) Forensic + DFIR cost (P1) Rs 40 lakh to Rs 2.5 cr Certbar engagement data, 2024-26 Per-record customer notification Rs 180 to Rs 450 per record India breach response benchmarks Core banking / lending downtime Rs 8 lakh to Rs 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 Rs 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: an 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 is 8 x 0.12 = 0.96 events/year LM decomposition (per event, INR) DPDPA fine (significant non-compliance + notification failure risk): Rs 40 cr to Rs 180 cr, ML Rs 85 cr Forensic + DFIR + legal: Rs 1.2 cr to Rs 3.5 cr, ML Rs 2.1 cr Customer notification (600k x Rs 250): Rs 15 cr Credit monitoring offering (60% uptake x Rs 400/yr x 2 yr): Rs 28.8 cr Reputation / churn (8-14% of high-value book, capitalised): Rs 22 cr to Rs 60 cr, ML Rs 35 cr Total LM Most Likely is around Rs 165.9 cr per event ALE Most Likely = 0.96 x Rs 165.9 cr, around Rs 159 crore/year.

Run 10,000 Monte Carlo iterations and the 90th percentile lands near Rs 240 cr, the 10th near Rs 62 cr. The board now has a defensible "we are carrying Rs 159 cr of annualised exposure on this one API surface." The proposal to spend Rs 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 the framing we package in a Certbar AI risk assessment deliverable.

Setting: a deposit-taking NBFC, Rs 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 is 9 x 0.15 = 1.35 events/year LM decomposition (per event, INR) RBI monetary penalty for SOC framework breach: Rs 0.5 cr to Rs 3 cr, ML Rs 1.5 cr RBI follow-on supervisory action (capital add-on, indirect): Rs 5 cr to Rs 25 cr, ML Rs 12 cr Core lending downtime (52 hrs x Rs 22 lakh/hr): Rs 11.4 cr Forensic + IR retainer + rebuild: Rs 2.8 cr to Rs 6 cr, ML Rs 4.1 cr Ransom (organisational policy permitting; modelled, not advised): Rs 3 cr to Rs 14 cr, ML Rs 6 cr DPDPA exposure if customer data exfiltrated (60% probability x Rs 80 cr): Rs 48 cr expected Reputation / collection-book impact: Rs 9 cr to Rs 22 cr, ML Rs 14 cr Total LM Most Likely is around Rs 97 cr per event ALE Most Likely = 1.35 x Rs 97 cr, around Rs 131 crore/year.

The single highest-impact control is upgrading from 8x5 to 24x7 SOC, which compresses Vuln from 15% to about 5% and drops ALE to roughly Rs 44 cr/year. The Rs 87 cr/year delta justifies an Rs 8-12 cr 24x7 SOC programme inside one budget cycle. This is the exact narrative we hand NBFC audit committees in our SOC 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: Rs X crore (P50), Rs 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 Rs 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 Rs cr. Second column: ALE reduction in Rs 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.

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 a wide max (Rs 250 cr) and a weighted ML based on case severity and culpability. Anchor at Rs 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 x 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, 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. Our VAPT and threat-intel feeds supply 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. A defensible first-version programme looks like this.

Week 1-2, pick the three scenarios that matter most: DPDPA exfiltration on your largest customer dataset, ransomware on your core revenue system, and one sector-specific scenario (SEBI CSCRF downtime for AMCs, RBI SOC failure for NBFCs, API abuse for fintechs). Week 3-4, build the India-calibrated loss table using the figures above, then run calibrated expert elicitation with your CISO, CFO, head of legal and head of operations on TEF and Vuln. Week 5-6, drop the inputs into OpenFAIR or an Excel + Python Monte Carlo, run 10,000 iterations, and generate the loss exceedance curve. Week 7-8, build the three-slide deck and rehearse it with the CFO before audit committee. Week 9-12, integrate the output into your cyber insurance renewal conversation and your DPDP compliance roadmap.

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.