From bolted-on stack to one graph: a top-10 Indian private bank

This is a composite of two deployments completed in late 2025 and early 2026 at large Indian private banks with very similar stacks, very similar pain, and very similar outcomes. The numbers are the median of both engagements. Names and identifying details are removed.

The reason we picked this customer to write up is not that the technical migration was unusual — it wasn't. It's that the operational and regulatory effect of moving from four independent products to a single graph was much larger than either side expected going in. The SOC team budgeted for a "platform change" and got something closer to a workflow rewrite. The treasury team budgeted for a 30% software-licensing reduction and got 71%. Compliance budgeted for "easier reporting" and ended up retiring four spreadsheets and a Friday-evening reconciliation job.

The interesting bit isn't the headline numbers. It's why the numbers moved that far. We'll spend most of the article on that.

Before Netgraph

The bank's pre-existing SOC was a mature operation by any reasonable definition. A 24x7 tier-1 floor of forty-two analysts, a tier-2 team of fourteen with deep investigations capability, a dedicated incident-response cell, a threat-intel team, and a separate cloud-security squad responsible for the public-cloud footprint. The annual security spend ran into the high tens of crores. None of that was the problem.

The problem was that the stack was a portfolio, not a system. The legacy enterprise SIEM (a Type A platform in our comparison framework — closed-source, ingestion-priced, on-prem-or-private-cloud only) was the system of record for on-prem telemetry. The three cloud security tools each had their own data plane, their own alerts, their own consoles. The standalone SOAR sat across the top and tried to glue everything together with playbooks. The CMDB lived in a fourth product. Identity context came from a fifth. Threat-intel enrichment was a sixth.

The honest summary from the Head of SOC, in the first scoping meeting, was: "The platform isn't broken. The seams between the platforms are broken." That single sentence is the whole pre-state.

Concretely, here is what "the seams are broken" looked like in numbers and operating reality.

• MTTR of six hours, MTTD of fourteen minutes. Detection was fine; the SIEM correlation engine was tuned and the analysts knew it well. Response was the bottleneck. An L2 analyst working a credential-misuse case typically opened six tools in parallel: the SIEM for the original alert, the identity log for the upstream auth, the EDR for the device, two cloud consoles to check whether the same identity was used in the cloud estates, the CMDB for asset criticality. Each pivot lost five to twelve minutes of context.
• SIEM licensing growing 22% year over year. The Type A platform was priced by ingest. Two new business lines and one regulatory-mandated logging expansion had pushed ingest from 280 GB/day to 480 GB/day in 18 months. Renewal quote for the next three-year window came in with a 67% headline increase. The CFO had asked, not unreasonably, why the security budget grew faster than the loan book.
• Two RBI Cyber Resilience Framework audit findings open. The first finding was about data sovereignty: one of the cloud security tools stored alert metadata in a region outside India. The second was about evidence integrity — the existing SOAR's audit log was not write-once, and reconstructing the timeline of a past investigation required stitching across two tools' audit trails. Both findings had been carried over from the previous year's audit.
• CERT-In 6-hour reporting was a manual fire-drill. Every reportable incident kicked off a frantic spreadsheet exercise. The IR cell pulled timelines from the SIEM, identity context from the IAM tool, asset context from the CMDB, and pasted it all into the CERT-In template by hand. Median preparation time to draft a CERT-In submission was 3 hours 40 minutes — comfortable inside the 6-hour clock, but only because the bank had over-staffed the IR cell to make that the case.
• DPDP readiness was a half-finished project. The DPDP 72-hour clock for personal-data breaches was on the compliance roadmap, but the team had no way to even identify which alerts touched personal data. Data classification lived in a fourth tool, alerts lived in the SIEM, and there was no automated join. Compliance had built a manual "PII-touching alert review" workflow that ran every morning and added another headcount of cost.

The replacement decision was triggered by the SIEM renewal, but the deeper driver was the audit findings. The Head of Compliance had quietly concluded that no amount of additional tooling on top of the existing stack would close the data-sovereignty and evidence-integrity findings without yet another product. The question shifted from "which SIEM do we renew with" to "do we keep buying boxes or do we replace the substrate".

Why Netgraph

The bank evaluated four platforms over an eight-week shortlist. Three of them were variations of the same Type A or Type B pattern — a SIEM with a graph view bolted on, sometimes with a SOAR module included. The fourth was Netgraph. The evaluation rubric had thirty-one criteria. The five that ended up being decisive are listed below; the others mostly tied.

1. One platform, one graph. Detection, response, identity context, asset inventory, cloud-posture findings and threat-intel enrichment all live as typed nodes and edges on a single substrate. The SOC was not buying "a SIEM and a SOAR and a CSPM and a UEBA"; it was buying one logical thing. The detection engineering lead's note in the evaluation document, verbatim, was: "This is the first product that doesn't ask me to choose which console is the source of truth."
2. India-resident SOC operations, end to end. Every byte stored, every model invocation, every backup, every audit log resides in Indian data centres under Indian operational control. The data-sovereignty finding could be closed structurally, not by writing a policy document. The DPDP team verified residency by walking the storage layout with the implementation team in week three of the pilot.
3. Regulatory reporting as a first-class workflow. CERT-In 6-hour and DPDP 72-hour reporting are not "exports" on Netgraph. They are workflows. The graph already knows which assets are in scope, which identities touched them, which data classifications are involved and which controls failed. The reporting templates auto-fill from graph traversal. The bank's IR cell saw the demo of a CERT-In draft generated in under ninety seconds and asked, politely, whether the demo data was rigged. It was not.
4. RBI Cyber Resilience Framework control mapping out of the box. Every detection, every control, every evidence artifact ships with explicit RBI-CRF control references. The compliance team's existing manual mapping — a 1,400-row spreadsheet — was replaced by a live view derived from the same graph.
5. Open-stack economics on owned infrastructure. The bank already owned the data-centre capacity. Netgraph's licensing was capacity-based, not ingest-based. The model the procurement team built showed a 71% reduction in three-year TCO against the renewal quote, assuming the bank kept its own iron — which it preferred to do anyway, on sovereignty grounds.

The factor that tipped the decision was not on the rubric. It was the fact that the platform engineering lead could read the Netgraph schema and write a graph-pattern detection in the first half-day of the technical workshop. The Type A and Type B incumbents required either vendor-certified engineers or a six-week training programme to author equivalent content. The bank already had eight detection engineers; it wanted them productive on day one, not retrained for a quarter.

Implementation

Total elapsed time from contract signature to "primary SOC running on Netgraph, legacy SIEM in read-only" was ten weeks. The bank insisted on a parallel-run period of six weeks during which both platforms ingested in full and both produced alerts; this was the right call and we recommend it for any deployment of this size. The phased timeline is below.

Three operational notes worth flagging for anyone planning a similar migration.

The detection audit was the long pole. Of the 1,140 legacy correlation rules, fewer than half were doing useful work. About a quarter were duplicates of newer rules; another quarter were tuned for noise patterns from telemetry sources the bank had since decommissioned. The migration was an excellent forcing function for the cleanup that the detection-engineering team had been wanting to do for two years. We strongly suggest budgeting for this honestly: the rule-by-rule audit took 320 engineer-hours and was the most contested part of the project. It was also the most valuable.

The parallel-run period needs to be longer than feels comfortable. Six weeks of parallel ingest is expensive — you're double-paying for storage and partly for licensing. But it is the only way to credibly tell the audit committee that you have not lost detection coverage. We ran adversary-emulation replays against both stacks weekly during the parallel-run and produced a comparison report; the report was the artifact the audit committee asked for, and it closed the discussion in one meeting.

The CMDB reconciliation surfaced 11% asset drift. When the existing CMDB was imported into the graph and joined against live telemetry, 11% of assets in the CMDB had no corresponding observed traffic, and a similar fraction of observed assets were not in the CMDB. None of this was a Netgraph issue — it was a pre-existing data-quality problem made visible by the substrate change. The IT-ops team treated it as a gift and used the migration to close the gap.

Outcomes

The numbers below are measured against a four-week baseline taken in the month before the cutover and a four-week steady-state taken in the month after phase 4 closed. Both windows excluded major incidents to keep the comparison clean.

Two of these numbers deserve a sentence of unpacking.

The 38-second MTTD is not a story about a faster correlation engine. The legacy SIEM's correlation engine was perfectly capable of firing inside 14 minutes; the gap was between "rule fires" and "alert is visible to the analyst with enough context to act". On Netgraph the firing and the context arrive together because they share the substrate, so the displayed MTTD reflects time-to-actionable, not time-to-rule-match. It is a fairer measurement, and it is dramatically smaller.

The 22 RCA-agent drafted detections came from the closed-loop content pipeline. Whenever the SOC closed a P1 or P2 with a root-cause classification, the platform's RCA agent proposed a graph-pattern detection that would have caught the precursor pattern earlier. A detection engineer reviewed the proposal, refined it, and either promoted it to production or rejected it with a reason that fed back into the agent's training. Twelve of twenty-two promoted in the first quarter is a healthy yield; the rejection reasons were as useful as the acceptances.

We expected a platform change. What we got was a workflow change. Six months in, our analysts will not let us go near anything that requires opening four consoles to investigate a single alert. That sounds obvious. It was not obvious before.

What's next

Three workstreams are active in the second half of 2026.

Payments-rail graph expansion. The bank's payments switches and ATM channels are already on the graph as event sources. The next phase models the transaction-flow graph as a first-class object — accounts, beneficiaries, devices, sessions — and links it to the security graph through identity. The hypothesis is that account-takeover and mule-network detections benefit from being expressed as the same graph patterns as security-side lateral movement. Early prototypes look promising; we'll write this up separately when the data supports it.

Cross-bank detection-pack sharing. The bank is participating in a working group with three peer institutions on consented, anonymised detection-pack publishing. Netgraph's tenant boundaries and detection-content signing model make this practical; the legal work is the bottleneck, not the technology.

Tabletop-to-BAS pipeline. The IR cell wants every tabletop exercise to end with a corresponding adversary-emulation run, so the lessons-learned become testable detection content rather than meeting minutes. The plan is for the next four quarterly tabletops to be co-designed with the BAS team. The output of each will be a measurable change in graph-pattern coverage, audited against the same kill-chain map.

The honest bottom line: the bank did not buy a faster SIEM. It bought one substrate, and the rest of the operating model rearranged around it. That rearrangement is where the value sits, and it is not visible from a product brochure. It only shows up after the parallel-run window closes and the old consoles get switched off.

Sample case study. Composite of representative deployments; customer details anonymised.