Penetration Test Plan vs Penetration Test Report

These get searched for interchangeably and they are two different documents, produced at two different points in an engagement. A penetration test plan is agreed before any testing happens and authorises the work. A penetration test report is delivered after testing finishes and records what was found. If someone has asked you for one, the split below is what they expect to receive.

NIST SP 800-115 keeps them structurally apart: assessment planning is Section 6, reporting sits in Section 8 under post-testing activities, and Appendix B of the same guide is a rules of engagement template. Section 6.5 states that an assessment plan should answer five questions. They make a usable checklist to hold any proposed engagement against, including ours.

The five questions a test plan has to answer

What belongs in each document

In the sample above, the plan is visible inside the report. Section 2, Scope and Methodology, restates every element that was agreed before testing began: the two in-scope targets, the environments, the 5 business days per scope, the grey-box approach with two credential sets, the standards, the tools, and the out-of-scope list. That is deliberate. A report with a vague scope section cannot be checked against the engagement it claims to document, which is the first thing a reviewer tries to do.

A worked plan is easier to judge than a description of one. The plan for the engagement above is written out in full below, section by section, so you can hold a proposal you have been sent against it.

If your procurement or audit process needs the plan as a separate signed document before work can start, raise it when you get in touch and we will tell you what we can put in writing before kickoff.

Penetration Test Plan Example

The section above says what belongs in a test plan. This is one, written out. It is the plan for the same Acme SaaS engagement the report above documents, so the two can be read against each other: what was agreed before anyone tested anything, and what came back after.

A note on wording. If a procurement template, a security questionnaire or a vendor onboarding form asks you for an attack and penetration test plan, it is asking for this document. The phrasing differs between organisations. The contents do not.

The document that comes back attracts the same variation. A penetration test report, a penetration testing report and a VAPT report all name the artefact published on this page. What decides whether it is any good is not the label on the cover, it is whether the eight parts listed at the top of this page are actually in it and whether each finding can be reproduced from what is written down.

This is the plan for the sample engagement, reproduced so the shape of the document is visible and so you have something concrete to hold a proposal against. It is not a standing set of terms. On a real engagement the scope, the window, the rules of engagement and the escalation path are agreed with you and written down before testing starts.

1. Engagement and authorisation

2. Objectives

1. Find what is exploitable. Identify vulnerabilities in the web application and the REST API that can actually be reached and used, before the next enterprise customer onboarding.
2. Test what tools cannot. Authorisation, session handling and business logic, where a scanner has no view of who is supposed to be allowed to do what.
3. Produce filable evidence. Findings recorded in a form that can go into SOC 2 and ISO 27001 audit preparation rather than being translated by hand afterwards.
4. Close the loop. Confirm by retest that the fixes hold, before the audit window opens.

3. Authorised targets

Explicitly out of scope. The exclusions matter as much as the inclusions, because they are what a reviewer checks the report against later.

• Denial of service, volumetric load and resource exhaustion testing.
• Social engineering of Acme SaaS staff, including phishing and pretext calls.
• Physical security assessment of any Acme SaaS location.
• Third-party providers, named here as Stripe and AWS Cognito. Acme SaaS does not own them and therefore cannot authorise testing against them.
• Any host, subdomain or API version not named in the table above, including systems that turn out to be reachable from an in-scope host.

4. Access model and credentials

• Grey-box, authenticated. Testing runs from a standard Member account and an Admin account, both supplied by Acme SaaS at kickoff, so both external attacker and insider scenarios are covered.
• Accounts created for the engagement. Test accounts are identifiable in application logs and removed at close. No production customer account is used.
• No source code access. Source review is not part of this engagement, and the report will not claim coverage that reading the code would have given.
• Source addresses declared. The addresses testing traffic originates from are given to Acme SaaS before kickoff, so the monitoring team does not open an incident on the test.

5. Window and logistics

6. Rules of engagement

• No denial of service, volumetric load or resource exhaustion testing.
• No modification or deletion of data outside the accounts created for this engagement.
• Exploitation stops at proof. Access is demonstrated and recorded, and is not used to reach further than the finding requires.
• Automated scanning is rate-limited so it does not degrade the staging environment for the Acme SaaS team working in it.
• Critical findings are communicated to the escalation contact as soon as they are confirmed, rather than held back until the report is written.
• If an assessor finds evidence that the environment was already compromised by someone else, testing stops and Acme SaaS is notified immediately.

7. Sensitive data and evidence handling

• Testing is performed against staging data. Where a finding can only be demonstrated against production, the evidence is captured read-only.
• Credentials, tokens and personal data appearing in evidence are redacted before the report is issued.
• Evidence is held on assessor-controlled systems for the engagement and the retest window, then destroyed.
• The report is classified Confidential and goes only to the distribution list agreed in this plan. Anyone outside that list needs written approval from Acme SaaS. The distribution list in the report above includes a row giving an external auditor the compliance package and nothing else.

8. Incident and escalation procedure

• If testing disrupts a service, the assessor stops that activity, notifies the Acme SaaS contact, and does not resume on that target until Acme SaaS confirms.
• If Acme SaaS needs testing paused for a release or an incident of their own, the window extends by the days lost rather than the scope being quietly reduced.
• Both sides record what was paused and why, so the report can state accurately what the time-box did and did not cover.

9. Deliverables and sign-off

• A v1.0 report at the close of active testing, with the status of every finding recorded as open.
• One free retest within one month of the v1.0 report.
• A v2.0 report at retest close, superseding v1.0, with the status of every original finding updated.
• Founder-led consulting hours for remediation questions, as set out in the pentest plan purchased.
• Signed by the system owner and the lead assessor before any testing traffic is sent. A penetration test without written authorisation from someone who owns the system is not a penetration test.

Every element above reappears in Section 2 of the report. That is the check worth running on any report you are handed: can you reconstruct the plan from the report, and does it match the one that was signed? If the scope section is vague, the answer is no, and there is no way to tell what the test actually covered.