In the kick-off meeting with the client, the scope of the project and the in-scope targets will have been defined. In this subsection of the report, all the defined in-scope URLs, IPs, endpoints, and so on should be mentioned. This information helps the technical team quickly manage the vulnerability at hand and communicate with the developer/administrator team that's responsible for the URLs/IPs mentioned in the scope.
There's another reason for adding the scope to the report – it makes for a smooth project flow for the penetration tester. In a scenario where the scope is undefined, the pentester won't be able to gauge the amount of work that needs to be done, or the number of days it will take to finish the project. As we all know, one of the core entities that is responsible for calculating the penetration testing project value is man-days.
When a penetration testing project is in its initial phase, that is, project discussion with the client, the project's value will be calculated based on the scope shared by the client and the number of man-days it will take to perform the tests for that given scope. Please note that these are not the only elements that define the value of the project – the assets, the timeline, the number of resources allocated for the project, the travel expenses (if any), and the initial requirements by the penetration tester are some of the key elements as well.
This defined scope helps the pentester allocate the resources of their team to the project and define the timeline to ensure there's a smooth project flow. If there are many subprojects, such as internal network or external network penetration testing being performed with the same client, defining the scope ensures both sides have the same expectations.