DNIF SIEM India: The Friday a Mumbai NBFC SOC Almost Waved an Amber Alert Through
4:34 PM. The Slack message was one line. “Service account pulling from the customer DB again, ignore?” That line is where most breach stories start. Not with a hooded figure. With a tired analyst on a Friday asking permission to look away. This is a story about why a mid-size Mumbai NBFC stopped looking away, and how moving to DNIF SIEM India changed what their one-person SOC could actually watch.
4:34 PM on a Friday. The amber alert nobody wanted
Rohan was the security team. All of it. 600 staff, two data centres, a lending app, and one analyst who also owned the firewalls and the VPN. The SIEM threw him about 900 alerts a day. He could properly investigate maybe forty.
So he triaged by gut. Red alerts got looked at. Amber alerts got a glance. And amber, on a Friday at half past four, got the benefit of the doubt.
The 4:34 alert was amber. A service account that normally read 200 rows a night was reading tens of thousands. Rohan had seen that account flag three times before. Each time it was a batch job that finished fine. His thumb was already moving to dismiss it.
I had assumed, the first time I heard this story, that the analyst was careless. He was not. He was rational. When the queue is endless, you learn to bet on the boring explanation. Arre, the boring explanation is usually right. The one time it is not, you read about it in the newspaper.
Why the old SIEM had trained them to ignore amber
Here is the part nobody puts in the brochure. Their old SIEM charged by data ingested. More logs in, bigger bill. So over two years, to keep the renewal sane, they had quietly switched log sources off. Endpoint logs, off. DNS logs, off. Half the cloud audit trail, sampled, not full.
The renewal quote had jumped to roughly 38 lakh a year per the vendor’s volume tier, and the only lever the NBFC had to pull was to feed the SIEM less. A detection tool that punishes you for watching more is a tool that slowly goes blind. Rohan was not ignoring amber alerts because he was lazy. He was ignoring them because he had been left with a fraction of the picture and twice the noise.
That matters more now than it did two years ago. The DPDP Rules 2025 put a 72-hour breach-notification clock on every Data Fiduciary, starting the moment you become aware of a breach, per the MeitY-notified rules. CERT-In already requires you to keep security logs for a rolling 180 days and report serious incidents within 6 hours, per CERT-In’s 2022 directions. For an NBFC, the RBI cyber-security expectations sit on top of that, per the RBI master directions on IT governance. You cannot report a breach you never detected because you turned the logs off to save money.
What a DNIF SIEM India setup changes on a Friday night
We brought DNIF into the conversation for a simple reason. It is built by NETMONASTERY, an Indian company, and its whole pitch is that you should not have to choose between watching everything and paying rent on a building. DNIF HYPERCLOUD is a cloud-native platform that does detection, user behaviour analytics and automation in one place, and its cost model does not spike every time you point a new log source at it.
For Rohan, that one change rewrote the Friday. With ingestion no longer the thing that decided his budget, every log source came back on. Endpoint, DNS, the full cloud audit trail, the lending app. The platform’s behaviour analytics learned what that service account normally did, so the 4:34 alert did not arrive as a flat amber line. It arrived with context: this account, this volume, this hour, this is 60 times its weekly norm.
Achha, now the thumb does not move to dismiss. Now it moves to isolate. We have seen this exact shift in three other mid-size SOCs. The analyst stops triaging by gut because the tool finally hands them a reason to care about this specific amber over the other 900.
Automation closed the loop. A playbook disabled the service account’s session and opened a ticket before Rohan had finished reading the alert. The batch job that was genuinely fine could be re-enabled in a minute. The one that was not stayed contained.
Per-GB SIEM versus flat-ingestion SIEM: what an Indian SOC actually feels
The technology debate sounds abstract until you sit in the chair. Here is the same SOC, same analyst, two cost models.
| What the analyst hits | Per-GB SIEM (the old way) | DNIF flat-ingestion model |
|---|---|---|
| Log sources turned on | Half. The rest cut to keep the renewal down. | All of them. Adding a source is a config change, not a budget meeting. |
| Alert quality | Flat severity. Amber means little. | Behaviour-scored. Amber actually carries weight. |
| Renewal conversation | How much can we afford to stop watching? | How much more can we watch at the same cost? |
| DPDP and CERT-In posture | Gaps you cannot explain to the Board. | Full 180-day log trail, ready for the 72-hour clock. |
None of this means DNIF is the only answer, or the right answer for every estate. A large bank already deep in Splunk or QRadar has switching costs that change the math. Gartner Peer Insights is worth a read before any shortlist, per Gartner’s published reviews. The point is narrower. For a mid-size Indian SOC running lean, a platform that does not bill you for looking is the difference between a watchful analyst and a blind one.
The Monday after: the 72-hour clock that did not start
The service account turned out to be a real attempt. A compromised credential, a script reading the customer records in slow, patient chunks so it would look like a batch job. On the old setup, with endpoint logs off and amber alerts waved through, it would have run all weekend. By Monday it would have been a breach. By Tuesday it would have been a 72-hour clock, a Board notification, and a very bad conversation about the 250 crore cap MeitY sets for weak safeguards.
Instead it was a contained incident. Session killed at 4:39, five minutes after the alert. No customer data left the building. Nothing to notify, because nothing was exfiltrated. The difference between those two Mondays was not a smarter analyst. It was a SIEM he could afford to feed.
Rohan messaged me the next week. “First weekend in two years I did not check the dashboard from home.” That is the result nobody writes into the business case, and the only one that ever really lands.
What we usually see in mid-size Indian SOCs
We have shipped this kind of move for lending, broking and SaaS firms across Mumbai, Pune and Bengaluru. The fleet sizes change. The pattern does not. One overworked analyst. A SIEM bill that grew faster than the team. Log sources quietly switched off to keep the renewal payable. And a queue so loud that amber stopped meaning anything.
The fix is rarely a bigger security team first. It is usually a detection layer that the business can actually afford to run at full coverage, so the analyst you already have can trust the alerts they already get. That is the case we make for DNIF SIEM in India, and it is the same logic behind the Aurva data-security pilot another Mumbai NBFC ran and the SonicWall firewall cutover we keep as field reports.
Detection only earns its keep when it feeds the rest of the response. The privileged-access side of this story sits in the ARCON PAM vendor-audit story, and the regulatory side, the part where the Board asks “are we covered”, sits in the DPDP Rules 2025 notification-day walkthrough and our DPDP compliance package. The public references we keep on the desk for the incident-response math are the NIST incident-handling guidance and CERT-In’s advisories. The numbers in this story are anonymised. The shape of them is not.
Get a quote on a 30-minute SIEM coverage review for your SOC
P.S. Priya here. I have sat with the version of Rohan at four different firms. He is never the problem. The problem is the renewal that made him turn the lights off one room at a time, until the room with the breach in it was dark. If your SIEM bill goes up every time you try to watch more, you are paying to be blind. Reach us on WhatsApp at +91 91375 93228 between 10 and 7 IST and we will read your log-source list before your
