Three Bodies Have Published What a Penetration Test Report Must Contain. Nobody Sends You the Checklist.

01 What SOC 2 penetration testing actually requires

A customer asks for SOC 2, someone opens a compliance platform, and penetration testing appears on a list. The platform is not forcing the purchase. Vanta's help centre says many frameworks, including SOC 2, ISO 27001, HIPAA and PCI DSS, require periodic penetration testing [ Vanta Help Centre ] . Its FAQ then says the test itself is not a hard requirement, provided you show good technical vulnerability management. Vanta recommends an annual external test as a reasonably easy control to implement [ Vanta FAQ ] . Drata warns that an auditor will "scrutinize your decision-making process" if you skip it [ Drata ] .

AICPA criterion CC4.1 covers ongoing and separate evaluations of internal control [ AICPA TSC, CC4.1 ] . Drata quotes the point of focus beneath it. Management "uses a variety of ongoing and separate risk and control evaluations", and those "may include first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, resilience assessments, vulnerability scans, security assessment, penetration testing, and third-party assessments" [ Drata, on CC4.1 ] . Penetration testing is one item on that list, and a point of focus rather than a criterion. Drata draws the consequence: penetration tests are "not technically a requirement to meet trust services criterion CC4.1", and "the onus is on you to demonstrate how your selected controls are sufficient to mitigate risks based on this criterion".

Vanta's published line on report contents is one clause: "Findings are documented, including severity, steps to reproduce, and recommendations for remediation" [ Vanta Help Centre ] . Three items. Nothing on scope, tester identity, limitations, retests, or how severity was derived. The specification you need was written elsewhere, by people writing for the reader.

02 The 22 questions written for the reader

Section 5.4 of the PCI SSC Penetration Testing Guidance carries a heading most people in security have never read: "Penetration Test Report Evaluation Tool". It is "intended for entities that receive a penetration test report and need to interpret and evaluate the completeness of the report" [ PCI SSC v1.1, §5.4 ] .

Table 1 holds 22 questions under seven headings.

Section 5 opens with the sentence worth printing out. "Merely reporting lists of vulnerabilities is not helpful in this endeavor and does not meet the intent of the penetration test" [ PCI SSC v1.1, §5 ] . Section 5.2.1 turns that into nine named sections, offered as a suggested outline rather than a PCI DSS reporting requirement: executive summary, statement of scope, statement of methodology, statement of limitations, testing narrative, segmentation test results, findings, tools used, and cleaning up the environment afterwards. The limitations section covers testing hours, bandwidth caps and legacy systems needing special handling.

One line settles most arguments about severity. "The report should clearly document how the severity/risk ranking is derived", with "a traceable set of reasoning" wherever custom scoring is part of the risk ranking [ PCI SSC v1.1, §5.1.1 ] . Rate a finding High and explain nothing, and your reviewer cannot map it to your own risk register.

03 CREST's 12-element minimum

CREST wrote the UK counterpart. The Defensible Penetration Test specification, v5.2 of June 2023, sets "a minimum set of expectations that must exist for the test to comply" [ CREST CDPT v5.2, §10 ] . It is still the only CDPT version on CREST's procurement guides page [ CREST guides page ] .

Twelve elements: the CDPT symbol on the cover; goals and objectives; scope, with location, exclusions, restrictions and coverage gained; full results; a timeline of key activities; enough detail to replicate each issue; a risk assessment against an agreed methodology with a CVSS severity; remediation advice per vulnerability; a statement of totality against the defined scope; the CREST IDs of those who scoped and delivered; evidence that everyone involved was suitably qualified; and CREST's contact details, with the Code of Conduct and complaints process.

Three are worth checking your last report for.

• A statement of totality against the defined scope. One sentence saying the agreed scope was tested in full. Where constraints stopped that, CREST wants them "formally documented and included as part of the report write up and sign-off processes" [ CREST CDPT v5.2, §9.1.2 ] . Without it, a clean result might mean secure or might mean unreached.
• A timeline of key activities, "with logs being available upon request". CREST names the content: "user accounts that have been modified, binaries that have been executed, access attempts (successful or failed)". A provider who cannot produce those logs cannot tell your incident team which alerts last month were the test.
• "Sufficient information should be provided to allow the client to understand and replicate the issue themselves." If your engineer cannot reproduce the finding from the report alone, the fix gets guessed at and the retest proves nothing.

Sign-off is a formal act, "undertaken by a suitably skilled or qualified individual, or by a company officer", attesting that the test followed the provider's approved methodology and "addressed all elements identified during the scoping phase" [ CREST CDPT v5.2, §9.1 ] . CREST also recommends a unique reference per engagement. That reference lets an auditor connect next year's retest to the test it came from.

CREST's buyer guide of December 2022 answers most procurement questions in two sentences. "A good report will include the names, roles and qualifications of the testers, date of the report, type of test undertaken and test scope. It should highlight any issues affecting the validity of the results and any other unknowns or anomalies encountered during testing" [ CREST buyer guide 2022 ] . Format and content "should be defined in both the scope and in a formal contract", and delivery comes "not later than a few days after completion of the test".

04 The two items the NCSC asks for

The NCSC calls a penetration test "a method for gaining assurance in the security of an IT system by attempting to breach some or all of that system's security, using the same tools and techniques as an adversary might" [ NCSC ] . Then it reframes the purpose. A test "should be viewed as a method for gaining assurance in your organisation's vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities", and it "can only validate that your organisation's IT systems are not vulnerable to known issues on the day of the test".

Two items on the NCSC's list of report contents will be hard to find in anything you have ever been sent.

1. Any security issues uncovered.
2. An assessment by the test team of the level of risk each vulnerability exposes the organisation or system to.
3. A method of resolving each issue found.
4. An opinion on the accuracy of your organisation's vulnerability assessment.
5. Advice on how to improve your internal vulnerability assessment process.

Items four and five are a verdict on you, not on your systems. They separate a supplier handing over findings from one telling you why your own process missed them. The NCSC has asked for both on a page last reviewed in January 2022, and they are what an auditor assessing your vulnerability management wants. Responsibility still lands with you: "risk assessment and decisions on the application of fixes are your responsibility". We cover the scan-versus-test question in penetration testing vs vulnerability scanning.

05 The three lists, side by side

Where all three agree you have a floor no reviewer will argue with. Where one asks alone, you have a question your provider has never been asked.

Under all three sits the evidentiary floor. NIST SP 800-115 sets the minimum fields for an assessor activity log: "date and time, assessor's name, assessment system identifier (i.e., IP or MAC), target system identifier (i.e., IP or MAC), tool used, command executed, and comments", because it "allows the organization to distinguish between the actions of assessors and true adversaries" [ NIST SP 800-115, §7.4.1 ] . That is the log CREST expects on request. The same document names the step most reports skip: "Mitigation recommendations, including the outcome of the root cause analysis, should be developed for each finding" [ NIST SP 800-115, §8.1 ] . Root cause, which CREST's buyer guide asks for too.

06 The retest section, with dates

A report is a photograph, valid for known issues on the day of the test [ NCSC ] . Your auditor is assessing whether you manage vulnerabilities, a process with dates in it.

PCI SSC published the format for the second document: executive summary, date of original test, date of retest, original findings, results of retest. And "all remediation efforts should be completed and retested within a reasonable period of time" [ PCI SSC v1.1, §5.2.2 ] . Two dates and a result. Most organisations do not have one. PCI DSS sets no evidence retention rule for testers, though the guidance calls retention "a recommended best practice" [ PCI SSC v1.1, §5.3.2 ] . Ask your provider what they keep, and for how long.

DSIT's Cyber Security Breaches Survey 2025/2026, a random probability survey of 2,112 businesses and 1,085 registered charities, found 13% of businesses carried out penetration testing while 43% reported a breach or attack in the previous 12 months. Only 15% reviewed the risks posed by immediate suppliers, and 6% the wider supply chain [ DSIT CSBS 2025/26 ] . The customer asking you for a report is asking for something 87 in 100 businesses cannot produce.

07 The question none of the checklists contain

Check the dates. PCI's checklist is September 2017, CREST's CDPT June 2023, the NCSC page last reviewed January 2022. None of them asks who, or what, wrote the finding. That question went live this summer. On 28 July 2026 CREST opened an AI accreditation with two relevant parts. Domain 7, Responsible AI Use, covers "governance, oversight, transparency and responsible organisational use of AI by the service provider". Annex B sets "requirements for service providers using AI within penetration testing" [ CREST AI accreditation ] . CREST's own research, published without a sample size or fieldwork date, puts 69% of providers already using AI and 85% expecting clients to demand greater transparency about it.

So add a 23rd question to the 2017 checklist, and put it to every supplier including us. Was AI used in producing this finding, at which step, and who reviewed the output before it reached me? A provider who answers precisely is describing its quality control. We word that for an RFP in CREST's AI accreditation and the three questions for your RFP.

Pull the last report you paid for and run the 22 questions, the 12 elements and the five NCSC items across it. Count what is missing. Your auditor will reach the same count, reading more slowly than you did.

Then ask us the same questions before you ask us for anything else. Every finding proven by a CREST-certified operator and checked by a human, written so your engineer can reproduce it. A fix per finding, a severity your board can read, a re-test from the ticket whenever you ship a change, and a dated export of what was open and what closed on any day someone asks. Start with a free audit, or see how Robin holds the evidence. Our penetration testing pages set out the scope of each engagement, and continuous penetration testing keeps the report current.