Ask someone outside security what a penetration tester does and you’ll get some version of “hacking, but legal.” Fair enough, as far as elevator pitches go. But the job itself is messier, slower, and a lot more bureaucratic than the movies suggest.
A pentest usually starts with paperwork. Scope documents, rules of engagement — all leading up to a signed authorization that spells out exactly what systems are fair game and which ones are absolutely not to be touched. Skip that step and you’re not a pentester anymore — you’re just someone committing a crime with better vocabulary.
Once the scope is locked in, the actual work splits into phases that don’t always happen in a tidy sequence. Reconnaissance comes first, usually: mapping out IP ranges, subdomains, exposed services, employee names that might end up in a phishing email later. Some of this is automated. A lot of it still isn’t.
Then comes the part people picture when they hear “hacker” — scanning for vulnerabilities, trying exploits, chaining together small misconfigurations until they add up to something that matters. A test might find a dozen low-severity issues that, stacked together, let an attacker walk straight into a database full of customer records. That’s usually the finding that gets a CISO’s attention, not the individual bugs.
Here’s where the job gets less glamorous: writing it all up. A good pentester can spend more hours on the report than on the actual testing — screenshots, reproduction steps, severity ratings, remediation advice written for an audience that might not touch a terminal all day. If the report’s unreadable, the whole engagement was basically wasted. Nobody fixes a vulnerability they can’t understand.
There’s also a quieter conversation happening inside the field about what pentesters actually need to do this work well. Some argue the toolkit has gotten bloated — every vendor pitching a new scanner, a new framework, a new dashboard promising to automate away the judgment calls. Others say the opposite: that for certain niches, like testing a weird legacy industrial system or a custom API, there’s barely anything built for the job and testers end up duct-taping scripts together. HackerNoon dug into whether pentesters have too many tools or not enough, and it’s worth reading if you’ve ever wondered why two testers can approach the same target with completely different setups.
Communication skills matter more than people expect going in. A pentester who can’t explain a SQL injection to a product manager in plain terms isn’t doing the client much good, no matter how clever the exploit was. Some firms pair technical testers with someone who handles client relationships specifically because the gap between “found a critical flaw” and “the business understands why it’s critical” is wider than it looks.
And then there’s the retest — the unglamorous follow-up where someone checks whether the fixes actually held. Half the time they didn’t, not fully. A patched endpoint reappears somewhere else, slightly reshaped, waiting for the next person who comes looking for it.
