This is a simple table, displaying the current and past versions of the document. (See example) It also displays the current state of the document (Draft, approval, final) and can contain some comments. This is not required but I always include it, it gives an easy overview of the current state of the document and who the author of that state is. Sometimes, the draft will be written by someone different than the final version for example.
Use this section to indicate who the customer’s representatives are. Use direct names and ask your customer to who the report and plan should be sent. Don’t just send it out without checking as that would constitute a security vulnerability in itself.
You always have to give a description of the purpose of this document. Remember that while it might seem obvious to you because you deal with documents like this all day, your client might not be as familiar as you with the standards and documents from our lovely profession.
This is a functional description of the project itself, not of the pentest. Your pentesting description will come later but for now, we have to give a short overview of the functionality of our application under test.
Any terms that you use throughout the document which might be a bit harder to explain such as OWASP or MiTM poxy should go in here.
Here, we describe what we hope to achieve with the pentest. As you might know by now, there are many different types of pentests and we have to ensure we describe the objectives so our client can easily review them and make sure we are both in line.
In here you can give the client an overview of your tactics and your ways of attacking. Usually the level of coverage is also described in here and the phases of your pentest.
Recon >> Scanning >> Gaining access >> Maintaining access >> Covering tracks
is an example, you can describe each item in more detail and make sure your client understands what types of attacks you are going to be performing on their infrastructure.
Describe both on your side what team members are going to be partaking in this pentest and also what people to contact at the client’s end. This makes it easier for pentesters to know who to contact in case they run into issues and also helps the client get an overview of who will be testing on their network.
In here, try to describe as completely as possible what can (in scope) and can not be tested. This is important as it will avoid any discussions later on.