The Report Is the Product

I love pentesting. 10-year-old me would be super stoked if he knew that he would eventually get paid to hack into things for a living.

As cool as pentesting is, hands-on-keys techniques like kerberoasting, password spraying, and buffer overflows are only part of the story, and probably a smaller part than most people think. The reality is that none of our clients hire us just so we can hack things and prove how 1337 we are.

The technical skills required to be a great pentester aren't easy to learn, but I'd bet there are far more people in the world who have the technical chops than there are people who can translate technical findings into business goals, metrics, and risk. Effective penetration testing has to serve a larger purpose for the client and the testing itself can almost never accomplish that in isolation. A great technical pentest without a compelling report to match leaves most of the value untapped.

A Great Pentest Begins Before the Actual Testing

We're not talking about regurgitated vulnerability assessment reports sold as "pentests". Don't buy those. Don't offer those. Those need to go away.

A great pentest begins before testing starts by understanding what matters to the client and shaping the engagement accordingly. Each client has unique needs, goals, challenges, levels of sophistication, and priorities that can (and should) affect the engagement on multiple levels. One of my favorite things to ask here is:

You get a call about a security incident in the middle of the night. What's the last thing you want to hear on the other end?

Less dramatically, you have to understand things like:

• Why is the client considering a pentest?
• What systems, data, apps, or business processes matter the most?
• What is the client's level of sophistication from a security/technical perspective?
• What does the client want to improve or achieve as a result of the pentest?

There are many, many more questions that could be asked here, but rarely will any of them boil down to "grab a screenshot of DA and move on". Cookie-cutter pentests that approach every engagement as a blind hunt for domain admin are low-value at best. More bluntly, they are likely a waste of time and money. Rinse-and-repeat shops that offer little-to-no customization have been the norm in pentesting historically. We must do better as an industry. 

The Report Drives Change

I think it was Abraham Lincoln who said, "A great pentester who produces a meh report is less valuable than a meh pentester who produces a great report". Or maybe that was me? Either way, I think Abe would agree that producing a great pentest report is a valuable skill. But what actually makes for a great report?

The report can be so much more than a place to document "here's what we did" and "here are the issues we found". It should be a tool the client can use to drive improvement. I've worked with many security champions who are the driving force behind improving their organization's security posture. A great pentest report should give them ammunition to support that security evangelism throughout the organization. The report is the pentester's primary (and often only) means of influencing what happens after the engagement has finished. "We should fix this or implement this policy or hire for this function because the pentest team said so" is not effective ammunition. This is why beginning with an understanding of the client organization from a business perspective is such a critical step in effective pentesting and persuasive reporting. 

The Executive Summary Is for Executives

My favorite piece of writing advice is to write with an actual reader in mind. Not a kind of reader, but an actual person. To do this effectively, you have to think about what you're writing, consider the intended audience, and imagine a person (ideally someone you actually know) who fits the profile.

With this in mind, the Executive Summary of a pentest report should be written as a summary... for an executive. A novel idea, I know, but it is so easy to assume that the report is written by security people, for security people. Not only is this not true of even technical sections of the report (more on that later), but it is most especially not true of the Executive Summary.

The Executive Summary should be written for a smart, capable leader who is probably not hands-on-keys technical, but needs to make high-level decisions for and based on the client's technical assets, functions, and teams. This is not a place for jargon or deep tech and security terminology. If the word "krbtgt" appears here, most readers of this section will assume you have a proofreading problem.

This audience derives the most value from an Executive Summary that:

• Summarizes the organization's overall findings and security posture within the scope of the test
• Offers a plain-language description of the most critical or representative findings
• Identifies the most common root-cause conditions contributing to the most critical findings
• Makes the case for what to prioritize first and recommends people, process, and technology improvements

The Executive Summary is a place where a client's security champions can manage up to affect lasting, root-cause change within the organization. In most engagements, this can be the most valuable section of the overall report.

Findings That Can Be Fixed

The findings section will often be the longest section of the report. It is meant to be consumed by technical people who understand the associated assets, but are not necessarily security gurus. They weren't on the kickoff call, didn't watch you exploit the issue, and may never communicate with the pentesting team at all. Can they understand what happened and fix it from the report alone?

A great finding should clearly explain what was discovered, demonstrate how it was exploited, describe why it matters in the context of the client's environment, and provide enough information for someone else to reproduce and remediate it. It should represent an easy-to-follow walkthrough with step-by-step instructions, explanations of key points, and clear recommendations for how to remediate or mitigate findings. Offering multiple options and tradeoffs is a major win here. Bonus points for not only recommending fixes, but including guidance for confirming that a fix has been effective.

This sounds obvious, but technical findings are frequently where otherwise good reports fall apart. Screenshots contain unreadable walls of terminal output. Reproduction steps skip important detail that testers mistakenly believe are obvious. Descriptions are copied from vulnerability scanners. Remediation guidance amounts to "apply security best practices." None of that helps the person who actually has to fix the problem.

If several findings share a common root cause, say so. If fixing one underlying condition can eliminate an entire class of attacks, make that obvious. And findings shouldn't exist in isolation if the associated attacks don't. A low-severity vulnerability that enabled credential access, which enabled lateral movement, which eventually resulted in access to a critical system is part of a story. The report should preserve that context rather than reducing the engagement to a collection of unrelated rows in a findings table.

The objective isn't to prove that the pentester found something. It's to make fixing what we found as straightforward as possible and tell a story that best illustrates how the client can become more secure.

A Pentest Should Make You Better

The coolest part of pentesting will probably always be the hacking. That's certainly the part that ten-year-old me would have cared about.

But getting domain admin, dumping hashes from LSASS, or chaining XSS to steal a token from local storage aren't what make an engagement successful. The engagement is successful when the client understands how those things happened, why they matter, and what to do differently as a result.

The testing gives us evidence. The report gives that evidence context, makes it useful to different audiences, and gives security champions something they can use to drive change.

A pentest shouldn't just leave you with proof that the testers had the skills to compromise your organization. It should leave you with a clearer understanding of how you can be compromised, what matters most, and what to do next.

The goal isn't to prove we can break in. It's to help make sure the next attacker can't.