What Actually Happens During a Pen Test (And Why Your PM Thinks It’s Magic)

To the uninitiated, penetration testing sounds like a mystical dark art.... or a dirty secret. Your PMs and execs imagine a team of hoodie-wearing hackers typing furiously in dimly lit rooms, uncovering secrets no mortal was meant to find.

Which is half true. We do wear hoodies. But let’s demystify what actually happens during a pentest – without the Hollywood nonsense.

Step 1. Scoping – “Tell Us What You Want Broken”

Before we even touch a keyboard, there’s scoping:

  • You tell us what’s in scope, what’s out of scope, and your risk tolerance.
  • We clarify expectations, because “test everything” and “don’t impact production” are usually mutually exclusive.
  • We draft Rules of Engagement, confirming target IPs, allowed attack types, test windows, and emergency contacts for when your SIEM starts screaming.

Step 2. Recon – “The Stalker Phase”

This is where we gather open-source intelligence (OSINT) and public data:

  • Employee emails on LinkedIn
  • Subdomains you forgot existed
  • S3 buckets left open to the world because someone “was just testing something”

Think of it as digital stalking with consent forms.

Step 3. Scanning – “Let’s See What’s Open”

We run network scans to:

  • Identify live hosts
  • Enumerate open ports and services
  • Fingerprint versions for known vulnerabilities

This is usually the first point where your SOC might notice us. Or not. (Spoiler: usually not.)

Step 4. Exploitation – “The Fun Part”

This is what everyone imagines:

  • Launching exploits against vulnerable services
  • Gaining footholds on systems
  • Dumping credentials and pivoting deeper into the network

Realistically, it involves a lot of trial, error, and cursing at exploit scripts that fail for unknown reasons.

Step 5. Post-Exploitation – “We’re In. Now What?”

Here we:

  • Enumerate user permissions, domain trust relationships, and potential lateral movement paths.
  • Dump password hashes, tokens, and juicy configuration files.
  • Assess how far we can go – “Can we become Domain Admin or exfiltrate sensitive data?”

Because getting in is fun, but proving impact is where the business actually pays attention.

Step 6. Reporting – “The Deliverable That Gets Ignored”

We compile:

  • Executive summary (for leadership attention spans)
  • Technical findings with replication steps, screenshots, and recommended remediations
  • Risk ratings to prioritize patching (which may or may not happen)

The report is read in detail by your security team, skimmed by your PM, and summarized in three bullet points for your CIO.

Step 7. Debrief – “The So What Meeting”

Finally, we meet to discuss:

  • What was found
  • How it could be exploited
  • How to fix it

This is also where we field questions like:

  • “But could someone really do that in real life?”
  • “Is this a red or a yellow risk for our dashboard?”

Why Your PM Thinks It’s Magic

Because from their perspective:

  1. We come in.
  2. We break things.
  3. We leave a report saying what’s broken.

But the reality is:

  • It’s methodical, evidence-based testing, not magic.
  • Our job is to validate your assumptions about security controls with real-world attacker behavior.
  • It requires deep technical expertise, creativity, and resilience against tools that fail 60% of the time.

Final Thoughts

Pen testing isn’t about “hackers hacking things for fun.”

It’s about:

  • Validating your security posture
  • Showing the business realistic impacts of weaknesses
  • Enabling prioritization of risk reduction

But hey, we’ll keep letting PMs think it’s magic. It’s good for the brand.

Now excuse me while I put my hoodie back on and go break something else.