While not a pen(etration) tester myself I’ve worked with countless pen testers and teams over the years for my clients, and that means I’ve read a lot of pen test reports. In this post, I’m going to reveal what the best reports do to effectively communicate their findings. 

Naturally, these reports are usually technical, but not all your readers will be technical. As such, the presentation is crucial so that your findings make the right impact and the reader has a clear understanding of the risks you’ve identified, and how to fix them if you provide that information.

There are two founding principles I use in my communications: first, it must be crystal clear what you’re trying to say. Second, it must be as easy as possible for the reader to read. With that said, here are my top report-writing tips.

1. Acknowledge limitations

The scope of pen tests and audits are limited. Your customer will have put constraints on your test, whether it’s time, or IP ranges you can scan. You’ll also in most cases have some upfront information from your customer about the systems under test.

If a pen test concludes and finds no serious faults in an application, it is really a statement that in the limited time, scope and budget set, the team couldn't find anything. This needs to be made clear in your audit report - particularly in the executive summary. Even if you do find significant vulnerabilities, you should spell out the limited scope you’re engaged under.

2. Understand how important the test is

There could be many reasons a client has approached you for a pen test. It could be conducted to assure investors of a startup's ability to deliver secure software, or it could be to meet an internal quality gate or due diligence requirements for one of their customers. As such, pen tests range in importance - your report and its presentation might be absolutely critical.

It’s your job to understand this context. It will guide how to present your report. The executive summary in particular is absolutely crucial - and unlike other sections of the report, shouldn’t be too technical, so a senior person in the business can read it in minutes and get the summary of what you’ve discovered. 

3. Define the severity of vulnerabilities clearly

How you define severity is also key. Many times I’ve been told of a “critical” vulnerability, only to find it’s not that big a deal in the context. I’ve also seen “Medium” or even “Low” risk vulnerabilities reported which actually pose a much higher risk. So make sure you’re consistent in how you label the severity of your findings.  A critical vulnerability on a marketing site may be disastrous for one organisation and trivial for another. You must define precisely what you mean by a ‘high’ risk vulnerability, to avoid doubt for whoever is reading your report.

4. Link risks, remediations and findings

You should show the links between risks, remediations and findings. This could be done with distinct sections in your report, or you could accompany it with a spreadsheet which the customer can filter and analyse at their own leisure (or both, which is how I present findings to customers).

5. Mitigations

Include suggested mitigations or prevention steps for every finding, where you possibly can. A good audit report doesn't just say what's wrong; it details the steps to fix a vulnerability and provide a path to stronger security. This helps the customer feel confident that what you’ve found can be rectified, and how it can be done. The remediation steps don’t have to be comprehensive, but they do need to be accurate.

6. Key details

This sounds like repetition, and it is. You need to be clear on what was tested (i.e. the bounds of the test) and when it took place. This is to anticipate questions about the findings that may crop up, issues can be recreated and that fixes can be confirmed in new builds. On several tests, I’ve also seen issues found by the pen testers that have since been fixed (“oh, that was a dev machine we switched off last week”) or issues the pen testers didn’t find because they were introduced after the test was completed.

7. Run through the report with your customer prior to final publication

A run-through of a draft gives the customer a chance to correct any misunderstandings or fixed findings prior to the report's publication. They’ll appreciate having an early view of what’s about to land, as in some contexts it could have very significant consequences (as we said above).

8. Flag serious findings early

Any serious findings should be communicated to the customer straight away. The best pen test engagements are where the customer is able to react to and fix findings as they are found so that by the end of the testing the customer has already rectified most things. You can still include these in your report, of course, but now can mark them fixed or mitigated, thanks to your proactivity!

9. Present it well - and think about who’s reading it!

It's critical that your report is of value to a customer - and value is not just about volumes of data, but also their ability to navigate and understand that data. This means being aware of your target audience, particularly their technical awareness and what information they're really after - be it risks, technical findings or something else. 

Follow these steps and you have a killer opportunity to help burnish your reputation as a top assessor and penetration tester.

But what if you’re not sure where to begin? Click to access my AWS security scorecard to take the pulse on your cloud services.