In theory, penetration testing helps organisations find and fix security weaknesses. In practice, it often becomes an expensive checkbox that reveals what’s already known, or worse, distracts from what matters most.
Too many pen tests are scoped too narrowly, executed too infrequently, and treated as isolated exercises. They miss the bigger picture: how systems are actually built, how traffic moves, and how users interact with infrastructure over time.
Without context in pen testing methodology, findings are disconnected from business risk. That’s not how you fix security.
In this edition of Penetration Testing Decoded, we’re joined by Siddharth Rajanna, CISO at Bingo Industries and former Black Hat speaker, who brings hard-earned clarity to the conversation. His insights, delivered with an engineer’s logic and frontline experience, expose how security testing often fails not because of attackers, but because of design neglect.
Start with the network, not the tools
“We've built these massive networks,” Siddharth says, “and most of the traffic between endpoints and servers doesn’t even need to happen.”
The basics, like segmentation, are often skipped or poorly implemented. Critical systems sit in flat networks or oversized VLANs where lateral movement is trivial. Firewalls carry thousands of rules, yet only a handful are active.
In one example, Siddharth describes internal laptops across departments sitting in the same subnet, increasing blast radius risk if just one endpoint gets compromised. It’s like putting your crown jewels in the same room and hoping a locked door is enough.
This isn’t just an on-prem issue. Cloud migrations often replicate insecure designs. “We lift and shift everything into a single VPC, slap on a WAF, and assume it’s secure,” he adds. “But we’ve just copied the problem into someone else’s infrastructure.”
Pen testing as a system check, not a spotlight
Most testing today focuses on high-profile systems: applications, public-facing servers, crown-jewel assets. It’s like checking your pulse and calling it a full medical.
But we’re dealing with a whole system. Not just the shiny parts.
Siddharth breaks down his preferred testing model into three layers:
Black box discovery — Testing what an attacker could find without internal knowledge.
Grey box testing — Targeted external testing with limited knowledge and access.
Internal assessment — Drop a tester inside the network and see what they can do.
“Put them on a jump box and ask them to move laterally,” he explains. “That’s where you find the real weaknesses.”
He’s not chasing CVSS scores either. “The CVE might be 9.5, but if it’s on an internal system with strong controls and no business impact, it's not the top priority. A misconfiguration with a score of 4 could be far more damaging.”
Find out more about why scores don’t work in our comprehensive pen testing guide.
Design first, then test
One of the biggest gaps in security testing isn’t technical but architectural. Systems are often deployed without a clear understanding of how they’re built, how components interact, or what the intended flow of traffic should be.
“There are no engineering drawings anymore,” Siddharth points out. “In real engineering, you design, simulate, and test. In security, we deploy and bolt things on later.”
He’s not exaggerating. In many organisations, application diagrams don’t exist. Network diagrams are outdated. The people responsible for security are often working blind.
“You can't protect what you don't understand,” he adds. “And you definitely can’t test it properly.”
Without a clear picture of the infrastructure, pen testing becomes disconnected from the real risks. It might produce a list of vulnerabilities, but it won’t show how those flaws interact with misconfigurations, over-permissive access, or poor segmentation. The result: alerts without context, patches without strategy.
This lack of visibility fuels another problem: over-reliance on detection tools. Monitoring becomes the fallback when prevention feels too complex. But visibility isn’t protection, and noise isn't insight.
Siddharth explains:
“Security isn’t about how many tools you deploy. It’s about whether you understand what you’ve built and whether you’ve built it right.”
Cloud is not safe by default
There's a perception that cloud is safer just because it's managed by a big provider, Siddharth notes. Most organisations treat cloud migration as a technical project, not a security one.
The "lift and shift" mentality preserves existing security problems and amplifies them. "What we have essentially done is, if you look at the on-prem, and let's say the only weakness was putting those servers in the same segment, right? And then you're going to migrate all of those into cloud, into a single VPC or VNet," explains Siddharth. "What we have essentially done there is we have created more risks in the cloud than we had on-prem."
The underlying networking principles haven't changed: your subnets become VPCs or VNets, but the same segmentation rules apply. Yet cloud deployments often lack even basic architectural documentation. Teams deploy complex multi-tier applications without understanding how components communicate.
"If you want to be a good car mechanic or a good aeroplane mechanic, you need to know how it works," Siddharth points out. "Same thing with security. If you don't understand how things are done, how they communicate with each other, you can't secure it."
We regularly find environments where a single compromised endpoint can access everything else because proper network segmentation was never implemented. The blast radius isn't contained because no one drew the blast zones in the first place.
Start fixing what matters
Much of today's security testing focuses on exploitability: can a vulnerability be triggered, and what's its score? But that misses the point. As Siddharth puts it:
"Security testing is about understanding weaknesses. Not just technical exploits. There’s no CVSS score for putting all your critical servers in the same subnet."
He shares a story of a web server exposing its file system path. On paper, the risk was rated low. In practice, it could lead to serious damage. "You can do a lot with a small gap if you understand how things are built."
This is where many organisations get stuck. When security incidents increase, the reflexive response is to hire more SOC analysts and deploy more monitoring tools. Siddharth challenges this thinking: "We need to look at controls that are more preventive and reduce the burden on the SOC team."
The mathematics is simple: "Look at the time difference, right? By the time the SOC team looks into it, recognises it, and translates that into an alert, it sends it to different teams. It's gonna be too late, right?"
Even basic technology choices reflect this backwards thinking. "Why do you wanna deploy this in IDS when you have an option to put it into a prevention system?" The usual objection about false positives misses the point: "Yes, that is why you go through this for like a period of 30 days, remove the false positives, keep fine-tuning it."
Recommended reading: 7 reasons the SOC is in crisis — and 5 steps to fix it
The better approach is designing with prevention in mind. That means tuning systems to block unnecessary traffic, removing false positives, stripping back access, and hardening what matters.
"Principle of least privilege isn't just for users," he adds. "It applies to traffic, to systems, to how everything communicates. It's a security filter for the whole organisation."
Understanding how systems are connected and limiting what doesn't need to connect does more to reduce risk than any reactive tool ever will.
Key takeaways
Start with design. Pen testing without network and application blueprints is just guesswork.
Fix the basics. Segmentation, privilege, and traffic control matter more than tool choice.
Test like attackers move. External, grey box, and internal tests all reveal different truths.
Context beats CVEs. Not all “critical” vulnerabilities matter, and many dangerous misconfigs fly under the radar.
Invest in prevention. The best SOC is the one that’s not constantly in crisis.
At Chaleit, we don’t believe in surface-level security. Pen testing done right isn’t just about spotting bugs. It’s about understanding systems and making them harder to break.
