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 below, Eric Buck walks through the philosophy that separates a tailored engagement from a templated one.
| 0:00 | What a real pen test report doesn't look like |
| 0:10 | The work starts before the statement of work is signed |
| 0:25 | Why no two proposals are the same |
| 0:45 | Crafting attack paths that fit the environment |
| 1:00 | Recommendations that actually make sense for the client |
Tired of pen test reports that read like a tool printout?
Get in touch to scope an engagement built around what's actually unique about your environment.
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.
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's their tech stack. What's the size of the security team that will receive the report. What's the budget reality that constrains what they can fix. What does the threat model look like for a business in their industry, at their scale, with their customer base.
None of that information lives in a scanner. It comes out of pre-sales calls, scoping conversations, and a willingness on the testing team's side to keep asking until they understand the environment well enough to plan an engagement that matches it.
If every proposal a firm sends looks the same, that tells you something about how they're going to test. The reverse is also true. Two real proposals from the same firm, for two different clients, shouldn't look alike. The personnel, the technology, the regulatory pressures, and the budget all push the engagement in different directions. A proposal that respects those differences will be priced and scoped differently. One that doesn't is a template with the logo swapped.
Once the engagement starts, the same logic carries forward. The attack paths the team builds need to reflect what would actually work against this client. A path that exploits cloud misconfiguration assumptions for a heavily cloud-native shop won't be relevant for a client running mostly on-prem with a small AWS footprint. A path that depends on phishing a large workforce won't apply the same way to a fifty-person company where everyone knows each other.
When the attack path matches the environment, the recommendations that come out of it match too. The client gets a report that tells them what to fix, in what order, with reasoning specific to their business. That's the difference between findings they can act on and findings they file.
If you're evaluating offensive security partners, the easiest signal is the pre-sales conversation itself. A firm that's going to deliver a tailored engagement will spend the early conversations trying to learn about you. They'll ask about systems, people, recent incidents, what previous tests have missed, what board-level conversations are driving the assessment. A firm that's going to deliver tool output with a cover letter will ask about IP ranges and timing.
Both kinds of engagement get sold as pen tests. Only one is.