From Network Admin to Cybersecurity CEO — Thirty Years on the Wire
How this started
People occasionally ask me to tell “my story”, and I usually resist — the work is more interesting than the person. But thirty years is long enough that some of what I learned the hard way might save someone else a few painful years. So here it is, told plainly: how a network admin in 1993 ended up running a cybersecurity company, and what the wire taught me in between.
If you want the formal version, there is an about page. This is the honest one.

1993: the first router
I configured my first router in 1993, in the dial-up era, when getting voice and data to share a line over the PSTN felt like a small miracle and a large headache. Networks in India then were few, expensive and fragile. Documentation was a stack of printed manuals. If you broke something, there was no forum to ask — you fixed it or you stayed late until you did.
That decade taught me the habit I still rely on: understand the packet before you trust the tool. Every technology since — firewalls, VPNs, SD-WAN, zero trust — is, underneath the marketing, packets making decisions. The engineers who thrive are the ones who never lose sight of that layer.
2002: founding PJ Networks
By the early 2000s I had spent years inside other people’s networks and kept seeing the same gap: enterprises bought security products the way they bought furniture — once, on price, and then forgot about them. Nobody was offering to actually run the thing, patch it, watch it, answer the phone when it screamed at 3 a.m.
I founded PJ Networks in 2002 to close that gap. The early years were firewall deployments, one box at a time, across Delhi NCR — unglamorous work, done properly. I was the sales call, the implementation engineer and the escalation line, sometimes in the same day. I do not say that nostalgically; I say it because it is why I still insist on staying hands-on. A CEO who has racked the box reads a design document differently.
2003: Slammer, and the wake-up call
In January 2003, the SQL Slammer worm crossed the world in about ten minutes. It exploited a vulnerability in Microsoft SQL Server that had had a patch available for six months. I watched networks — including ones I had helped build — buckle under the traffic of a worm small enough to fit in a single packet.
Slammer rearranged my thinking permanently. Until then, security in most Indian enterprises was a perimeter product you bought and installed. Slammer proved that patching discipline, segmentation and speed of response mattered more than any appliance. The organisations that survived it were not the ones with the most expensive firewalls; they were the ones that had patched, and whose networks were divided enough to contain the blast. Every architecture I have designed since carries that lesson in it somewhere.
From firewalls to running a NOC and SOC
Through the late 2000s and 2010s, the company grew in the direction the work demanded. Clients stopped asking “can you install this firewall?” and started asking “can you watch everything, all the time, and tell us when something is wrong?” That is a different business. We built a 24/7 NOC and then a SOC — first for a handful of enterprises, then for organisations across BFSI, manufacturing, hospitality, education, government and healthcare, in India and beyond.
Running a SOC teaches you humility at scale. You learn that most alerts are noise, most incidents are process failures wearing a technical costume, and the difference between a near-miss and a headline is usually whether someone was watching and empowered to act. You also learn that no tool replaces a disciplined analyst who knows the estate. That belief shapes everything we build and every engagement I take on as a consultant.
2016: the Fortinet MSSP partnership
In 2016, PJ Networks became a Fortinet MSSP-level partner. I had worked across many vendors by then, and the decision was pragmatic: the Fortinet fabric — firewall, switching, wireless, authentication, management — let us standardise estates deeply enough to run them well at scale. Standardisation is an unfashionable word, but it is the difference between knowing forty clients’ networks and knowing one architecture forty times. The second one is how you answer at 3 a.m. with confidence.
What three decades taught me about how security actually breaks
Indian enterprises rarely get breached through Hollywood zero-days. The failures I see, over and over, are quieter:
- The unpatched known vulnerability. Slammer’s lesson, twenty-plus years later, still unlearned in too many estates. The patch existed; the process did not.
- The rule nobody dares delete. Firewall estates accrete rules for a decade until the policy base is an archaeology site. Somewhere in layer 600 is the any-any rule from a 2019 migration.
- The flat network. Everything can reach everything, so one compromised endpoint becomes a campus-wide incident. Segmentation is unglamorous and decisive.
- The vendor-shaped gap. Security bought as products from five vendors with no one owning the whole. Attackers live in the seams between consoles.
- The untested assumption. The HA pair that has never failed over. The backup that has never been restored. The incident plan nobody has read since the audit.
None of these need a bigger budget to fix. They need ownership, discipline and someone willing to say uncomfortable things in a meeting. That, more than any technology, is the job.
If you are starting out today
A few things I would tell a young engineer, because nobody told me:
- Learn the fundamentals before the frameworks. TCP/IP, DNS, routing, how a session is born and dies. Frameworks change every few years; the wire does not.
- Break things in a lab, then fix them. Reading about failover is not knowing failover. Build it, pull the cable, watch what actually happens.
- Write things down. The engineer who documents is the engineer who gets trusted with bigger systems — and the one who sleeps during incidents.
- Learn to translate. Half of security leadership is explaining risk in language a board or a plant manager acts on. Technical depth gets you in the room; clarity keeps you there.
- Stay honest about what you do not know. The most dangerous person in a network is the one bluffing. “I will find out” is a senior answer.
What I am building now
Thirty years of watching detections fail — too much noise, too little context, tools that see a log but not the estate — is what shaped the requirements behind PrahiX Ora, the AI-driven detection and response platform we are building at PJ Networks. The ambition is not another dashboard. It is to encode what a disciplined analyst actually does: correlate across the estate, suppress what does not matter, and surface the few things that do, fast enough to act. I will leave the details for another piece; the point here is that the platform exists because of the field work, not instead of it.
I still take on consulting engagements personally — architecture reviews, firewall audits, zero-trust designs, board-level strategy — because the day I stop touching real estates is the day my advice starts to rot.
Work with me
If this way of thinking — fundamentals first, no theatre, honest answers — is what you want in the room, book a working session. Based in Delhi, working with enterprises across India.