What a SOC 2-Ready Pentest Report Contains (With a Sample TOC)

There's a difference between "a pentest report" and "a pentest report your auditor will accept as SOC 2 evidence". The first one is a PDF with the output of a vulnerability scanner, maybe a cover page, and a list of CVEs that may or may not even apply to the application that was tested. The second one is a structured document with an executive summary written for management, an explicit scope statement, a methodology section that maps to recognised standards, prioritised findings with reproducible evidence, and a remediation plan that the engineering team can actually action.

Crucially, the SOC 2-ready report has the right sections in the right order. Auditors and vendor-risk teams have seen thousands of these documents. They know within thirty seconds whether what's on their screen is a real deliverable or a scanner export with a logo on the front cover. The structure is half the credibility. It's what tells the reader the engagement was scoped, authorised, and executed methodically before they even read a single finding.

This post shows the actual table of contents we deliver on every engagement, why each section is there, and what your overseas client's auditor is actually looking at when they review it. If you're a Pakistani company selling SaaS to a US, EU, or UK customer and they've asked for a "pentest letter" or "third-party security assessment" as part of vendor onboarding, this is the document they expect.

Why the structure matters as much as the findings

Here's the uncomfortable truth about how auditors actually consume pentest reports: they don't read every page. A SOC 2 Type II audit covers dozens of controls across security, availability, processing integrity, confidentiality, and privacy. The pentest report is one piece of evidence among many, and the auditor has a finite number of hours to assess it.

In practice, the auditor jumps to four places: the scope statement (is the right system in scope?), the methodology (was the test done against a recognised standard?), the findings summary table (what was found and at what severity?), and the remediation status (was it fixed?). If those four sections are clear, defensible, signed, and dated, the evidence is accepted and the auditor moves on. If any one of them is missing, vague, or sloppy, the auditor pushes back regardless of how thorough the actual testing was, and you end up scrambling to re-document an engagement that's already finished.

The mental model that helps here: treat the report as a legal-evidence document, not a security report. It needs to stand up to a reviewer who wasn't in the room, who doesn't know your application, and whose job is to find reasons to reject it. Every section exists to remove one objection.

The TOC: sample table of contents

Here's the literal structure we hand over on every SOC 2-ready engagement. It's adapted slightly per scope, but the bones are always the same:

Every section in that list is there because an auditor, a procurement team, or an engineering lead specifically asked for it at some point. Nothing is decorative.

Section-by-section: what we actually put in each

1. Executive Summary

One page. Maximum. Named for management and board readers who will not read past it. It states what was tested, when, by whom, and lands on a single verdict: "ready for production", "production with caveats", or "not production-ready". It names the two or three most important findings in plain English (no CVSS jargon) and gives the overall risk posture. If the CFO reads only this page, they should still know whether to ship the product.

2. Scope and Authorization

Explicit URLs, IPs, repository names, mobile package identifiers, cloud account IDs, and exact start/end dates. Named test accounts with their roles. This is the single section auditors challenge most often when it's missing or vague. "We tested the web application" is not a scope statement. "We tested app.example.com, api.example.com, the staging environment at staging.example.com, between 2026-04-12 and 2026-04-26, using test accounts pt-admin@, pt-user@, and pt-readonly@" is a scope statement.

3. Methodology

Standards followed, listed verbatim. This is the section where SOC 2 and ISO 27001 mappings live. Auditors specifically look for OWASP WSTG, the OWASP API Top 10, PTES, or NIST SP 800-115 to be named. Those are the recognised frameworks. If you wrote "we used industry best practices", that's not enough. We list the standard, the version, and which sections of our test plan map to which control family.

4. Risk Rating Methodology

CVSS 3.1 explained in plain English inside the report itself, so a non-technical reader knows what "7.5 / High" means. We also explain how business context modifies the raw score: a CVSS 9.8 against a publicly exposed authentication endpoint is treated very differently from a CVSS 9.8 against an internal admin tool reachable only from the office VPN. The auditor wants to see that judgement applied, not just a copy-pasted vector string.

5. Findings Summary Table

One row per finding. Columns: ID, title, severity, CVSS score, status (open / fixed / accepted-risk), owner, due date, and SOC 2 control mapping. This table is the page auditors photograph and paste into their working papers. They love it because it answers their entire question in a single view. We make it sortable in the PDF where possible, and we keep it on a single landscape page when scope permits.

6. Detailed Findings

Each finding is a self-contained document. The format is consistent across the report: title → severity badge → CVSS vector → affected component → description → reproduction steps (with screenshots or curl commands the engineering team can copy-paste) → business impact → fix recommendation → references (CWE ID, OWASP category, vendor advisories). An engineer should be able to read one finding in isolation, reproduce it on staging, and ship a fix without needing to read the rest of the report.

7. Remediation Plan

A prioritised list (critical and high findings first, then mediums, then lows) mapped to specific fixes and grouped by owning team where we have that information. We include estimated effort bands (small / medium / large) so engineering leadership can plan a sprint. The plan is the bridge between "here's what's broken" and "here's how the next two weeks look".

8. Letter of Attestation

A separate signed letter (usually a single page on company letterhead) that the client can attach to a procurement form. This is the deliverable your overseas client actually asks for, often even more than the full report itself. We cover it in its own section below because it deserves the attention.

The Letter of Attestation explained

If you're a Pakistani company selling SaaS or services to a US, EU, or UK customer, this letter is the document that gets requested by name. Vendor-risk teams at large enterprises have a folder for each supplier and they need a single, signed, dated, one-page artefact to drop into it. They do not want to read your 80-page detailed findings report. They want a letter that says, in plain language:

• "We, VAPT.PK, conducted a penetration test of [client's named system] between dates A and B."
• "We followed [named methodology: OWASP WSTG, PTES, etc.]."
• "We identified [N] findings, with the highest severity being [severity]."
• "As of [re-test date], all critical and high findings have been remediated and re-verified."
• "Signed, dated, on company letterhead, by the lead tester and a director."

That's it. One page, three short paragraphs. The procurement team can attach it to their vendor file, your SOC 2 auditor can attach it to their evidence folder, and your sales cycle unblocks. We issue this letter on every engagement as standard. It's not an upsell, it's part of the deliverable.

Mapping to SOC 2 controls

The findings summary table includes a column for SOC 2 Common Criteria mappings. The relevant control families for pentest evidence are CC6.1 (logical and physical access controls), CC6.6 (external boundary protections), CC6.7 (data-in-transit protections), and CC7.1 (monitoring for vulnerabilities). For ISO 27001 engagements, we add a parallel column mapping each finding to A.12.6.1 (management of technical vulnerabilities) and, depending on the finding class, to relevant Annex A controls like A.9 (access control) or A.14 (system acquisition, development, and maintenance).

The point of these columns isn't to claim that one pentest finding equals one control failure. That's not how the frameworks work. The point is to make the auditor's life easy. They're already mapping the report to controls in their working papers; pre-mapping it cuts their review time in half and removes a back-and-forth round of clarification emails.

What we don't put in the report

The report is a deliverable, not a journal. Three things explicitly do not belong in it:

• Raw Nessus or Burp output as an appendix. It's noise. Hundreds of pages of low-confidence scanner findings dilute the real ones and make the auditor question whether anyone reviewed the test results before delivery. The detailed findings section already contains everything that matters; raw tool output goes in a separate file we share on request.
• Screenshots with customer PII unredacted. Real names, real emails, real account balances, real API keys. Every screenshot is reviewed and redacted before it goes into the PDF. A leaked report should not become a second incident.
• "We tried X and it didn't work" content. The report shows what was found, not the running log of every failed attack chain. Operational notes (the things we tried, the dead ends, the hunches that didn't pan out) live in a separate "Engagement Notes" document we share with the security team if they ask for it. The report itself stays focused on the verified findings.

What this looks like end to end

A typical engagement ships a 7-page executive summary plus a 60 to 90-page detailed findings report depending on scope size, the signed one-page letter of attestation, and a re-test included in the engagement fee, usually within 30 days of the original report so the client has time to remediate. Everything is delivered as a PDF with embedded bookmarks for the auditor's convenience, plus a separate spreadsheet of the findings table for engineering tracking.

If you'd like to see the full deliverable list, the standards we test against, and the engagement flow from kickoff to re-test, our Security Audit & Reporting service page has the complete breakdown. It's the same document structure described in this post, scoped to whichever testing service is feeding into the report: web, API, mobile, cloud, or network.

The short version: a pentest report is only as valuable as the use it gets put to. If your buyer's auditor accepts it without follow-up questions, the report did its job. If they kick it back asking for scope clarification, methodology details, or a signed letter, the report didn't. We build the deliverable for the second reader (the one who wasn't in the room) and the structure above is how we make sure that reader can sign off.