Pentest Reports with Eric Buck

If your pen test report looks like tool output with a cover letter, you didn't really get a pen test.

Real penetration testing starts before there's a signature on the statement of work. It starts with the question of what's actually keeping the client up at night, what makes their environment different from the last one, and how an attacker would adapt to that. In the short video above, Eric Buck walks through the philosophy that separates a tailored engagement from a templated one.

Watch the full conversation

The tool-output problem

There's a category of pen test report that buyers in this industry know on sight. It's a stack of CVE numbers, severity ratings, a few network diagrams pulled straight from a scanner, and an executive summary written to fit the same template the vendor uses for every client. The findings are technically accurate. They're also indistinguishable from what the client could have generated themselves by running the same tools.

That kind of report has a place. It's not a pen test. It's a vulnerability assessment with a different word on the cover. The reason that distinction matters is that buyers paying for the higher-priced engagement aren't getting what they're paying for, and the security team reading the report doesn't get anything they can act on that they didn't already know.

The work happens before the engagement starts

A real pen test starts with conversations, not scans. Before the kickoff call, before the statement of work, the testing team is trying to understand the client. What are they actually worried about? What would genuinely hurt if it got out, and what only looks critical on a network diagram? Where has the environment grown in ways nobody quite documented, and which systems does the business really run on? Those answers don't come out of a scanner. They come out of asking, and listening.

That understanding is what shapes the engagement. It decides where the testers push hardest, which findings get chased all the way down versus noted and set aside, and how the attack paths get built. Two clients running the same software can need two completely different tests, because what an attacker would actually go after looks different in each environment. A templated engagement ignores that and runs the same playbook every time. A tailored one is designed around the specific thing that would cause that client real harm.

None of this shows up as a line item in the report, but it's the reason the report is worth reading. By the time anything gets written down, the work that made the test useful has already happened, in the questions asked before it started and in the attack paths built for this environment instead of pulled off a shelf. That's the difference between a document that proves work was done, and one your team can actually use.