At the end of the penetration test, all of the data will need to be turned into information that allows the business and network owners to take action. Although the goals of a penetration test may vary, the need to document the entire process and put the results into an easily digestible format remains the same. Some items that should be included in an executive report include the following:

Cover page:

The cover page should be both professional and eye-catching. If you happen to have any graphics available for your logo, this is an ideal place to display them. Take a look at this sample to get the basic idea of a typical reporting cover sheet:

The next page should provide a table of contents that acts as an index of the material included within the report. Adding an index allows the reader to quickly jump to the location of interest. This is especially important when the person is attending a meeting or needs a quick refresher of what the report covers:

The next page should be the executive summary, which can be used to quickly review the findings. An Executive Summary may vary, based on the target audience. In our example, we assume that we do not know who the report is being presented to and thus try to cover all bases—the technical and nontechnical managers.

This portion of the report should provide someone who was not part of the initial testing process with enough information to understand what the test was, and what the goal of testing was. It should also provide a quick overview of what the findings are and whether anything in particular was discovered that requires immediate attention.

Take a look at following example:

As discussed, we managed to capture several major areas within a single page. The information should be brief and to the point and technical jargon should be avoided whenever possible, as the report may eventually be provided to nontechnical members of the management team.

The primary sections that should be covered in less than one page include the title and a brief description, the scope or introduction, and the timeline that the testing occurred in. Many people do not understand that a person performing a penetration test is limited by resources just like any other part of a team. If it takes 2 days to crack a password, but you only had one to perform testing, it does not necessarily mean that the passwords are secure. It just means that you did not have sufficient time to properly perform your testing.

The FINDINGS section in the executive summary is very important. Most of the management team will probably never read about all of the steps that had to be taken to find these holes; they just want to know what they are and what the priorities are for each type so that they can begin issuing remediation strategies and plans.

Take a look at the next page in our report:

Not only did we clearly define and summarize the findings, but we also provided a nice chart to assist in the visualization of the findings. By breaking down the vulnerabilities for the client, you make their life easier and may avoid having to make another visit in the future just to go over your findings again.

It is important to provide a clearly defined network diagram from your perspective. This allows the client to understand that all appropriate systems were tested, and in some cases exposes issues that the client was not even aware of, such as systems on the network that do not necessarily belong. Ideally, you would have one listing of all services available on the network. In the sample here, we have only listed the port and the description because we know that only one system was involved. Another method would be to list all services such as this:

A listing such as this can become actionable if there are services on systems that should not be there. For example, a development server is still running a web server that was supposedly shut down years ago.

Take a look at the following example page, which includes a basic network diagram and a listing of fictional ports that are open on 192.168.75.15.

Finally, the time has come to provide some detailed reporting. This is your chance to list the findings in detail and also provide information about how these issues were discovered. There is typically no limit to the amount of data that can be placed in the detailed report portion. Be sure to provide at least enough information so that an administrator could attempt to emulate specific portions of the testing to ensure any mitigating controls that have been put in place are actually working.

At some point in the document, the methodology used should be addressed, be it a subset of a standard methodology or even something that you have come up with on your own—it is important to understand what you did. This is where having your notes available comes in very handy.

Here is a small example of what this section could look like:

If you look closely, you will note that there is a section for remediation. All of the information that is needed to remediate the issues is already in the report, but sometimes it is good to make a listing of vulnerable systems that are associated with particular vulnerabilities. This makes it quick and simple for a business to address the vulnerabilities in a logical fashion. For instance, the administrators could be tasked with updating all versions of SAMBA on the network, and with the remediation section in your report they can go directly to work on the list.

Any additional information that is not directly related to providing actionable data should be added to an appendix. This includes any large data dumps such as directory listings, URLs, installed software and versions, and so on.