What Actually Happens During a Penetration Test From Someone Who Does Them

That's not it.

I've done penetration tests on networks, web applications, and internal systems. And the reality is both more methodical and more interesting than anything Hollywood has come up with. Let me walk you through what actually happens — from the moment a client says yes to the moment they get a report in their inbox.

It starts with a conversation, not a keyboard.

Before anyone touches a single system, there's a scoping call. The client and I sit down — usually over a video call — and define exactly what's being tested. Which systems. Which IP ranges. Which applications. Are social engineering attacks in scope? What about physical access testing? Is the goal to simulate an external attacker who knows nothing, or an insider threat who already has credentials?

This matters more than most people realise. A penetration test without a defined scope is just hacking. With a scope, it's a controlled exercise with a specific question being answered: can someone get in here, and how far can they go if they do?

We also agree on a rules of engagement document. What hours can testing happen? Who do I call if I accidentally take down a production server? What's off limits entirely? This document is what separates a pentest from a crime.

Then comes reconnaissance. And this phase takes longer than most clients expect.

Before I try to break into anything, I spend time learning everything I can about the target from the outside. What does the company's public infrastructure look like? What domains do they own? What email addresses are exposed? What software versions are visible on their web servers? What employees are on LinkedIn, and what tools do they mention in their profiles?

You'd be surprised how much information a company leaks without knowing it. Job postings alone can tell an attacker what security tools a company uses, what cloud provider they're on, and what their internal tech stack looks like. I've found exposed credentials in public code repositories. API keys sitting in old GitHub commits. Subdomains pointing to forgotten staging servers running outdated software.

None of this requires touching the client's systems. It's all public. And it's often where the most useful information comes from.

After recon, I start looking for ways in.

This is what most people think the whole job is. It's actually maybe thirty percent of it. I run scans to identify open ports and running services. I look at what software versions are exposed and whether any of them have known vulnerabilities. I test web applications for common weaknesses — things like how the application handles authentication, whether it properly validates user input, whether there are endpoints that shouldn't be publicly accessible but are.

When something looks exploitable, I verify it carefully before attempting anything. The goal is never to cause damage. It's to demonstrate that a path exists and where it leads.

If I get initial access to a system, the work doesn't stop there. I try to understand what that access actually means. Can I move to other systems on the network from here? Can I escalate my privileges? Can I reach sensitive data — customer records, financial information, credentials that would let me go further? The question I'm always asking is: if a real attacker got this far, what's the worst thing they could do next?

The part nobody talks about is the documentation happening the entire time.

Every command I run, every finding I discover, every piece of evidence — screenshots, output logs, timestamps — gets recorded as I go. Not at the end. As it happens. Because when I'm writing the report, I need to be able to show the client exactly what I did, in what order, and what I found at each step.

A pentest report is not a list of vulnerabilities. A good one tells a story. It explains what I was able to do, how I was able to do it, and — critically — what the business impact would be if a real attacker had done the same thing. It's written for two audiences: the technical team who needs to know exactly what to fix, and the management team who needs to understand why it matters.

The findings get rated by severity. Not every vulnerability is critical. Some things are worth fixing immediately. Some are worth noting and monitoring. The report explains the difference and gives clear remediation guidance for each finding.

After the report goes out, there's usually a walkthrough call. I take the client's team through the findings, answer questions, explain anything that wasn't clear in the report. Sometimes the technical team wants to see a live demonstration of a particular finding. Sometimes management wants to understand the risk in plain language. Both are part of the job.

Some engagements include a retest — after the client's team has fixed the issues, I come back and verify the fixes actually work. A vulnerability isn't truly remediated until someone has confirmed the original attack path no longer works.

The thing I want people to understand is that a penetration test is not an attack. It's a service. The entire point is to find problems before someone with bad intentions does — and to give the people responsible for fixing those problems the specific, actionable information they need.

The hoodie is optional. The methodical thinking, the documentation, and the ability to explain technical risk in plain language — those are what actually make the job work.

Tags: Penetration Testing, Cybersecurity, Ethical Hacking, VAPT, InfoSec, Cyber Career, Security Testing