What auditors actually look for in a pentest report

An MSP partner sent us a pentest report last quarter that another vendor had delivered to one of their clients. The report was 47 pages, the cover looked sharp, the findings were ranked by CVSS, and the client’s SOC 2 auditor rejected it as evidence. The MSP’s client had to commission a second pentest to keep their audit on track. The vendor’s account manager was surprised. The auditor was not.

This happens often enough that it is worth writing down what auditors are actually checking when a pentest report shows up in evidence. The technical findings matter less than most security engineers think. The procedural and documentation pieces matter more.

Auditors are checking the methodology, not the findings

The first thing a SOC 2, HIPAA, or PCI DSS auditor does with a pentest report is flip past the executive summary and look at the methodology section. They are checking three things:

Was the testing scope what the client says was tested? If the client’s system description says the production application is in scope, the methodology needs to confirm the production application was actually tested. A report that vaguely says “tested the customer’s web environment” without naming the application or environment will get flagged.

Was the methodology recognized? Auditors want to see references to PTES, OSSTMM, NIST SP 800-115, OWASP Testing Guide, or similar standards. A report that just says “our team used industry-standard testing techniques” reads as a generated fluff filler. Name the methodology and version.

Were the testers qualified? Names and certifications of the operators on the engagement, not just the firm’s certifications. PCI DSS specifically requires that the tester be an independent third party with relevant qualifications. Auditors look for OSCP, OSCE, GPEN, GWAPT, or equivalent on the report.

If any of these three are missing, the audit can stall regardless of how thorough the actual testing was. We have seen technically excellent pentests rejected as evidence because the report did not name the operators.

The executive summary is where most reports fail

The executive summary is the part of the report a non-technical CFO or audit committee will read. It is also the part most pentest vendors do worst on. Common failure modes:

The summary lists CVSS counts (“3 critical, 7 high, 12 medium”) but never names the actual systems tested or the business risk. An auditor reading this cannot tell whether the testing covered what their client’s system description claims it did.

The summary is identical across every report from the vendor — the same paragraph about “maintaining strong cybersecurity posture” with the client name dropped in. Auditors notice template summaries because they review reports across many engagements.

The summary leads with vulnerabilities found instead of overall security posture. A good summary tells the audit committee whether the system is reasonably secured or whether it has fundamental gaps. Then it gets into specifics. Vendors who lead with “14 vulnerabilities identified” without contextualizing the severity skew the perception of risk.

What a good executive summary actually does:

1. Names what was tested in plain language matching the client’s system description
2. States the overall security posture in a sentence (e.g., “The application demonstrates strong defensive controls with two findings requiring remediation before production deployment”)
3. Lists the highest-impact findings with one-line business risk descriptions
4. Confirms the client has remediation guidance and a path to retest

Findings have to map to compliance controls

SOC 2 reports have specific Trust Service Criteria. PCI DSS reports have specific requirement numbers. HIPAA reports have specific Security Rule technical safeguards. ISO 27001 reports have specific Annex A controls. NIST 800-53 reports have specific control numbers.

An auditor reviewing a pentest report needs to map findings back to the framework controls they are evaluating. If the report does not do this mapping, the auditor either has to do it themselves or push back to the client to have the report rewritten. Both outcomes cost the client time and audit fees.

What good control mapping looks like in practice:

For SOC 2: each finding tagged with the relevant Trust Service Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) and the specific common criteria number where applicable. A finding about weak session management maps to CC6.1 (logical access controls). A finding about missing audit logging maps to CC7.1 (system monitoring).

For PCI DSS: each finding tagged with the specific requirement number it relates to. An external pentest finding about an exposed admin interface maps to Requirement 1.3. An application finding about input validation maps to Requirement 6.5.

For HIPAA: findings mapped to Security Rule technical safeguards under 164.312 — access control, audit controls, integrity, person or entity authentication, transmission security.

If you are working with a pentest vendor whose report does not include this mapping, ask them to add it. If they cannot, that is a meaningful signal about how often they support audited environments.

Remediation guidance has to be specific

“Apply the latest security patches and follow defense in depth principles” is not remediation guidance. Auditors discount findings with vague remediation because they cannot evaluate whether the client has actually fixed the issue.

Specific remediation guidance for an application finding looks like: the affected endpoint, the specific code or configuration change required, an example of the corrected behavior, and a way to verify the fix is in place. For an infrastructure finding: the affected system, the specific configuration setting, the documentation reference, and the verification method.

This level of specificity is also what makes the remediation retest meaningful. If the original finding said “authentication bypass on /admin endpoint via missing session validation,” the retest verifies that the session validation is now in place and the bypass no longer works. If the original finding said “authentication issues identified,” the retest is going to be a fishing expedition.

The retest is part of the audit evidence

For SOC 2 Type II in particular, the auditor wants to see that findings were remediated and that remediation was verified. A pentest report without a corresponding retest report is incomplete evidence for findings rated medium or higher.

Practical implications: schedule the retest 60 to 90 days after the initial pentest, leaving time for the client to remediate. Make sure the retest is documented in a follow-up report or appendix that names exactly which findings were remediated and how the remediation was verified. Save both reports as audit evidence; do not just save the original pentest.

If your pentest vendor charges separately for retesting or makes it logistically difficult, that vendor is creating an evidence gap for your client’s audit. Build retesting into the original engagement scope.

The cover, the formatting, and the brand discipline

This part is mostly aesthetic but it matters. Auditors review hundreds of pentest reports a year. They notice patterns:

Reports with the security firm’s logo prominent and the client’s logo absent or small read as commodity work product. White-labeled reports under the MSP’s brand with a small “testing performed by [independent assessor]” footer read as integrated security operations.

Reports with consistent formatting, page numbers, and a table of contents read as professional. Reports that look like exported Markdown or screenshots stitched together read as cheap.

Reports with confidentiality markings and version control read as part of an evidence package. Reports without read as one-off deliverables.

None of this changes the technical quality of the testing, but it changes the auditor’s impression of the client’s security program maturity. For SOC 2 readiness in particular, that impression matters.

What an MSP can do about all of this

If you are an MSP whose clients are going through audits, you are the one positioned to set quality standards on the pentest reports they receive. A few practical moves:

Pre-screen the vendor’s sample report. Before referring a client, ask the vendor for a sanitized sample of a recent SOC 2 or PCI report. Check it against the items above. If the executive summary is generic, the methodology is missing, or the control mapping is absent, find a different vendor.

Standardize the engagement scope. If you regularly send clients to a single vendor, build a standard scope template that includes everything an auditor will need: methodology, qualified operators named, control mapping required, retest included.

Hold the vendor to your brand standard. If you are reselling pentests, the report should match your firm’s presentation standards. White-labeling is not just about logos; it is about consistency of voice, formatting, and depth across everything your clients receive from you.

The pentest is the deliverable that goes in the audit folder. The audit is the moment of truth for whether your client passes their compliance review. Spend the time getting the report right.