Who should be running Netgraph in their SOC — and who shouldn't (yet)

I spend a fair amount of my week on buyer calls, and the most useful thing I can do in the first ten minutes is disqualify people. Not because the platform can't ingest their logs — it can — but because a security platform is a five-year relationship, and a mismatch discovered in month eight is expensive for everyone. So this post is the sorting conversation I'd rather have in public: who should be running Netgraph in their SOC, and who genuinely shouldn't yet.

The context that frames every one of these profiles is staffing. Every credible workforce study of the last two years — ISC2's annual studies among them — puts India's cybersecurity talent shortfall in the hundreds of thousands of unfilled roles, and the SOC analyst bench is where the gap bites first. A 24×7 monitoring rota needs a minimum of eight to ten people before anyone takes leave. Most Indian mid-market security teams have three. That arithmetic, not any feature list, is what decides which platform architecture a team can actually operate.

The mid-market enterprise that got priced out of its own telemetry

The first profile is the one Netgraph was originally shaped around: the Indian enterprise with 2,000 to 20,000 employees, a security team of three to eight, and a SIEM bill that has been quietly teaching them to drop log sources. If you have ever excluded your DNS logs or your proxy logs from ingestion because the per-GB metering made them unaffordable, you are in this profile. Detection coverage decided by a billing model is not a strategy; it's a slow-motion incident.

Netgraph's whole platform — all 23 modules on one security knowledge graph — runs in a 32 vCPU footprint, and the operating cost lands at or under 15% of an equivalent Splunk or QRadar ingest bill. The point of that number is not the savings line in the business case. The point is that when telemetry stops being metered, teams turn their dropped sources back on, and the detections that needed those sources start firing. The MTTD targets we commit to — detection in 60 seconds or less, response in 15 minutes or less — are only achievable when the evidence is actually being collected.

BFSI, where the regulators already made the decision for you

If you are RBI-, SEBI-, or IRDAI-regulated, the question "should we have a serious SOC?" was answered for you by circular. RBI's cyber security framework has required banks to run security operations since 2016. SEBI's Cybersecurity and Cyber Resilience Framework, issued in August 2024, went further and made a SOC — your own, a group SOC, or a market SOC — an explicit obligation for regulated entities, with compliance dates through 2025. IRDAI's information and cyber security guidelines put insurers on the same road. And sitting above all of it since June 2022 is CERT-In's direction to report covered cyber incidents within six hours of noticing them.

Six hours is the number that matters. It is not a reporting deadline you can meet with a weekly review meeting; it demands that detection, triage, scoping, and evidence assembly happen inside one working shift. This is precisely what a graph substrate is good at — the incident's scope, affected assets, and timeline are a traversal, not a two-day reconstruction — and we've written up the mechanics in CERT-In 6-hour reporting straight from the graph. The same evidence model serves the 72-hour breach notification the DPDP Rules, notified in November 2025, hung over every Data Fiduciary. BFSI teams don't buy Netgraph for the graph. They buy it because two regulators' clocks and one statute's clock all read off the same substrate.

MSSPs, if multi-tenancy is real and not a folder convention

The third profile is the managed provider running ten to a few hundred customer environments. MSSPs have the inverse of the mid-market problem: plenty of operational skill, brutal economics. Every tenant on a metered SIEM is margin leaking out of the contract, and every tenant on a separate SIEM is an operational fork.

What makes an MSSP deployment safe is isolation you can demonstrate, not isolation you assert. Netgraph's RBAC model carries 390 distinct permissions, which sounds like overkill until you have to give a customer's auditor a precise answer to "which of your analysts could read our data, and what exactly could they do to it?" A role model with eight coarse permissions cannot answer that question honestly; it can only answer it optimistically. The failure patterns — and there are several — are catalogued in MSSP multi-tenant pitfalls. If you run other people's security operations for money, per-tenant graphs with a permission model fine enough to audit is the difference between a service and a liability.

OT and manufacturing, where the network has no outside

Plants, utilities, and defence-adjacent manufacturers keep evaluating cloud-first SOC platforms and keep discovering the same disqualifier on page one: the reasoning layer phones home. If your OT network is genuinely air-gapped, a platform that needs a hosted model API for triage is not a candidate, whatever the deployment guide implies.

Netgraph runs fully offline: reasoning agents in-cluster, threat-intel as an offline corpus, licensing via Ed25519-signed offline license files, so even entitlement checks never require egress. We've argued before that "air-gap ready" isn't a checkbox — it's an architectural property you verify by unplugging the uplink and watching what breaks. For this profile, run that test on us and on everyone else you're evaluating. It shortens the shortlist quickly.

PSU and government, where sovereignty is a procurement clause

Public-sector undertakings and government departments carry two constraints commercial buyers don't: procurement has to flow through channels like GeM, and data sovereignty is a condition, not a preference. A platform whose telemetry, models, or licensing checks transit foreign infrastructure fails the second constraint regardless of how it performs on the first.

Netgraph deploys on-premises or in Indian sovereign cloud, speaks open formats — OCSF and ECS — rather than a proprietary event schema, and is procurable through GeM. The open-format point deserves more weight than it usually gets in government evaluations: a PSU that standardises on a proprietary schema has signed a decade-long dependency, because re-normalising years of security telemetry is a migration nobody funds twice. Open formats are how a sovereign deployment stays sovereign at replacement time, not just at purchase time.

The lean team that wants the agentic SOC, with the human still in charge

The last "yes" profile cuts across the others: the three-to-five-person team that has concluded, correctly, that they will never hire their way to a 24×7 rota and wants the machine to hold the pager at 3 am. Netgraph ships eight specialised agents — triage, investigation, root-cause, detection drafting among them — and an L1 autopilot that handles the alert queue end to end, with human-in-the-loop gates on every action that changes the environment. Containment, credential rotation, and detection promotion all wait for a named human approval; the agents assemble the evidence and the recommendation, and they draft detections through the same Detection-as-Code pipeline a human author would use, BAS-validated before promotion.

The honest caveat: an agentic SOC is a multiplier on judgment, not a substitute for it. Someone on your team still reviews the agents' pull requests and owns the rule library. If nobody will ever play that role, read on, because the next section is about you.

Who shouldn't run Netgraph yet

Two profiles come up on calls where the right answer — the answer that saves everyone a wasted quarter — is "not yet."

Teams deeply invested in a single hyperscaler stack. If your estate is 95% one cloud, your identity, endpoints, and productivity suite are all that vendor's, and your analysts live inside its native SOC tooling, the integration gravity is real and the bundled pricing is real. Netgraph would still give you the graph, but the marginal win over what you already have is smallest in exactly this scenario. The moment to revisit is the moment you become multi-cloud, or acquire a company that is — that's when the single-vendor correlation story breaks and the vendor-neutral substrate starts paying. Our comparison framework in AI-SOC overlays vs graph-native platforms is written to be usable even if you conclude against us.

Organisations that want a pure managed service with no operational ownership. Netgraph automates a very large share of the SOC working day, but it is a platform, and a platform assumes someone on your side owns outcomes: approves containment, reviews detection PRs, decides risk tolerance. If your intent is to sign a contract and never look at a console — a legitimate choice for plenty of businesses — then what you want is an MSSP, not a platform. Preferably an MSSP from the profile three sections up, running multi-tenant Netgraph underneath. Buying a platform to avoid operational ownership is how shelfware happens, and shelfware with our logo on it helps nobody.

A two-question test

If you want the whole post compressed: first, is there at least one person in your organisation who will own security outcomes — approve actions, review detections — even if agents do most of the labour? Second, does your telemetry, regulatory clock, or deployment constraint break the assumptions of a single-vendor cloud stack — metered ingest you can't afford, a six-hour or 72-hour reporting duty, tenancy isolation you must prove, an air gap, a sovereignty clause?

Two yeses and you're in one of the six profiles above; we should talk. One yes, and the conversation is worth having but the timing question is real. Two noes and I'd genuinely rather you didn't buy Netgraph this year — keep the evaluation notes, and come back when the second answer changes. It usually does.

Sorting hats are unfashionable in enterprise software because they cost vendors pipeline. We think they build the only pipeline worth having: customers who are still glad about the decision in year three.