7 Things I Wish I Knew Before Starting VAPT

A few weeks back, I was on a call with TrinetLayer, going through the onboarding process. I heard terms like "attack surface" and "responsible disclosure" being thrown around, but to be honest, I didn't really understand what they meant. I just nodded along, pretending like I knew what was going on, but inside, I was clueless about what I was getting myself into.

I'm Kanishk Malik, a soon-to-be graduate in Computer Science and IT from MIET. Up until now, my experience in cybersecurity has been focused on the defensive side of things. I've worked on Identity and Access Management, as well as Privileged Access Management, during my time atHustleGrad. I've also had the chance to work with Security Information and Event Management, and analyze network packets, at Teachnook. On top of that, I've gained some insight into Security Operations Center and Open-Source Intelligence through an internship with a police cyber cell. I knew how to lock things down. I had no real idea how people actually break in.

I was tasked by my team lead to write about my time as an intern. Rather than writing another generic article about what VAPT is, I wanted to share the things that really caught me off guard during my first few weeks on the job.

1. Recon Eats More Time Than Anyone Tells You It Will I really thought I'd be spending most of my day searching for weaknesses, but things didn't quite turn out that way.

At first, I didn't jump right in — instead, I used my initial sessions to read and learn as much as I could. I went through endpoints, subdomains, and all the documentation I could find, as well as scope notes, to get a better understanding of what I was dealing with.

At the beginning, everything seemed to be moving at a slow pace, like I was just going through the motions without really accomplishing anything meaningful.

Then I learned why recon matters.

I learned a valuable lesson one time when I rushed through something just to get to the good part. It turned out I ended up looking into something that had already been figured out and fixed a long time ago — months earlier, to be exact. I basically wasted a whole afternoon because I didn't do my due diligence beforehand. If I had just taken the time to do the groundwork, I would have known that it was already taken care of.

That was a pretty effective lesson.

2. A Scan Result Is a Suggestion, Not a Finding I still remember the first time I did a security check and got a ton of warnings — it was like striking gold. Then I started validating them.

Many of the problems we found weren't really problems at all. Some were just mistakes in the report. Others had already been fixed. And then there were the ones that looked bad on paper, but didn't actually pose a real risk. I was really taken aback by just how much time and effort gets put into triage, it's a lot more than I expected.

A huge part of the job isn't finding vulnerabilities. It's figuring out which findings deserve more investigation and which ones are just noise. Nobody really tells you that half the work is learning when to stop chasing something.

3. Scope Is a Line You Check Twice, Not Once I used to hear the word "scope" in meetings and briefings, but to be honest, it didn't really stick with me until I started this internship. Before that, it was just one of those terms that would come up and then I'd forget about it soon after.

Not anymore.

It's surprisingly easy to start from an in-scope asset, follow an interesting lead, and a few clicks later realize you're not completely sure whether you're still operating inside the agreed boundaries.

I've gotten into the habit of keeping the scope document open in another tab when I'm testing, it's just easier that way. It sounds obvious written down. It wasn't obvious to me in week one.

4. My Defensive Background Helped More Than I Expected At first, I thought my background in Identity and Access Management, Privileged Access Management, and Security Information and Event Management wouldn't be that helpful when it came to offensive security. Turns out, I was wrong.

Knowing how authentication is supposed to work, what normal access patterns look like, and how controls are usually implemented makes it easier to spot when something feels off.

I spent some time earlier this year setting up a lab in VirtualBox to test out Active Directory, and I also got to play around with Group Policy Objects and Entra ID. It felt like I was working on the behind-the-scenes stuff, you know, the defensive infrastructure that keeps everything running smoothly.

When I look at how users are verified or given access to something, I already have a pretty good idea of what it should look like. So, if something is not right, it really stands out to me.

5. Writing the Report Is Harder Than Finding the Bug This one annoyed me for a while.

I'd verify an issue, feel good about it, and then spend the next twenty minutes trying to explain it properly.

Too vague, and the finding gets ignored. Too dramatic, and you lose credibility.

The challenge isn't just describing what happened. It's explaining why it matters to someone who wasn't there when you found it. There's no shortcut for that. You just get better with practice.

What's helped me most is writing reports as if I'm explaining the issue to another security professional who understands the technical side but wasn't involved in the testing itself. Enough detail to build trust. Not so much detail that it turns into a novel.

6. Documenting as You Go Saves a Lot of Pain Later At the beginning, I would try something out, then move forward, and afterwards return about an hour later, trying to recall exactly what I had asked for or what the response was that I received. That reconstruction process is miserable. And completely avoidable.

I've started keeping a running log of what I test, when I test it, and what happened. Even if something turns out to be a dead end, I write it down. A lot of the information that's gathered doesn't actually end up in the final version of the report.

They've really helped me avoid doing the same work over and over, which is something I've had to do way too many times in the past.

7. Reading Real Reports Taught Me More Than Any Course One habit that's helped me a lot is reading public bug bounty write-ups and disclosed reports.

What stood out wasn't the exploit itself. It was the thought process.

So, what makes a good story? It's when the writer tells you why they started looking into something in the first place. What caught their attention? What made them curious? They share how they followed tiny leads, one by one, until they stumbled upon something big. It's like solving a puzzle, and the best writers take you along for the ride, showing you how they put the pieces together.

I've been studying about different types of vulnerabilities and I think I've got a good grasp on the theory. But when I read about a real-life vulnerability that was discovered, I'm always surprised by how differently it was approached. It makes me realize that there's a big difference between just understanding the concepts and actually being able to apply them in a real-world scenario.

That gap between understanding a concept and developing the instinct to apply it is probably something that only comes with repetition.

Final Thoughts I'm still dragging my feet on sending in that bug bounty report, and to be honest, I'm not as quick as I want to be when I'm doing recon — it's like I'm stuck in slow motion.

If you're making the switch to VAPT from a defensive role, like I did, you might think you're starting from scratch, but that's not entirely true. You're looking at the same systems you've always worked with. You're just learning to view them from the opposite direction.

And honestly, that shift in perspective has taught me more than I expected.