Auditors do not read penetration test reports for the findings. They read them for scope, dates, method and closure, because those are the four things that let a report support a control. Reports that bury those details create audit work rather than removing it.
An engineering team reads a penetration test report for the findings. An auditor reads it for something else entirely, and a report optimized for the first reader often fails the second.
Here is what gets checked, in the order it gets checked.
Scope, against the system description
The first question is whether the report covers the system the audit covers. The SOC 2 system description defines the boundary. If the report tested a subset, a superset, or a different environment, the auditor has to work out what the overlap was, and they will ask you.
What makes this pass cleanly: an explicit list of hostnames, applications, environments and account roles that were in scope, and an explicit statement of what was excluded. What makes it fail: a report that names a product rather than an environment, so nobody can tell whether staging or production was tested.
The related trap is the shared responsibility boundary. A report covering only infrastructure your cloud provider already attests to is evidence about their controls, not yours.
Dates, against the observation window
Three dates matter, and reports frequently include only one.
- The testing window, meaning when testing actually ran
- The report date
- The retest date, where there was one
For a Type II, testing has to fall inside the observation window. A report that gives only a publication date forces the auditor to ask when the work happened, and an answer given in an email is weaker evidence than a date printed in the artifact.
Method, in enough detail to be evaluated
CC4.1 asks whether an evaluation was performed. To conclude that one was, the auditor needs to know what was done.
A usable methodology section says what kind of testing was performed, what access the tester had, what standards or references shaped the approach, and what coverage was established. "OWASP Top 10" on its own is not a methodology; it is an awareness list, and citing it describes a starting point rather than the work.
The access point matters more than teams expect. A black box report cannot make a strong coverage claim, because what was reachable in five days is not the same as what exists. A white box or grey box report can state coverage against the actual surface, which is a materially stronger artifact for an audit.
Closure, which is where reports fall down
This is the section auditors care about most and vendors most often omit.
A finding raised and left open is a live issue in your report. A finding raised, fixed and verified with a dated retest is a demonstration that your vulnerability management control works, which is precisely what CC7.1 is asking about. The second one is worth considerably more than the first is worth avoiding.
What a good closure record contains: the finding, the remediation performed, who verified it, the date of verification, and the method of verification. For anything not fixed, a documented risk acceptance with a named owner and a review date. An accepted risk that is written down is defensible. A finding that was quietly ignored reads the same to an auditor as it does to a customer's security reviewer.
Two things that are not evidence
A certificate or attestation letter from the testing vendor. Some firms issue a one-page letter confirming a test occurred. Buyers sometimes accept these. Auditors generally do not, because a letter with no scope, method or findings cannot support a conclusion about whether a control functions.
A summary with the findings removed. Redacting technical detail before sharing with a customer is sensible. Handing the auditor the same redacted version is not, because the auditor is assessing the control and needs the detail the customer does not.
The check before you send it
Read your own report and answer four questions. Does it state what was in scope, precisely enough to compare against the system description. Does it state when testing ran. Does it state what was done and with what access. Does it show what happened to each finding.
If any answer is no, that gap becomes an auditor question, then an email thread, then a delay. Better to notice it before the report is final than during fieldwork.
Questions people ask
What does an auditor look for in a penetration test report?
Scope that can be compared against the SOC 2 system description, the dates testing actually ran, a methodology section describing what was done and with what access, and a record of what happened to each finding including dated verification of fixes.
Is a penetration test attestation letter enough for SOC 2?
Usually not. A letter confirming a test occurred, with no scope, method or findings, cannot support a conclusion about whether a control is present and functioning. Auditors generally ask for the report.
Do I have to give the auditor the unredacted report?
Generally yes. Redacting technical detail is reasonable when sharing with a customer, but the auditor is assessing the control itself and needs the detail that a customer does not.