What actually goes in a SOC 2 evidence pack (and what auditors reject)

If you're prepping for a SOC 2 audit or a Series-A security questionnaire, someone has told you that you need a penetration test. That's true, but it's not the whole truth. What the auditor actually wants is evidence, a defensible artifact that maps to specific controls, produced by a repeatable process, that they can staple into the audit file. A raw scanner dump is not that. Neither, honestly, is every consulting pentest.

This post is what actually belongs in a SOC 2 evidence pack, what auditors quietly reject, and how our $7,999 SOC 2 Evidence Pack is built to clear the bar. If you take nothing else away: the deliverable is the product. A finding an auditor can't map to a control is a finding that does nothing for your audit.

What an auditor is actually looking for

SOC 2 is a controls framework. The relevant Trust Services Criteria for a pentest live mostly in the Common Criteria, CC6 (logical and physical access) and CC7 (system operations and monitoring). When an auditor asks for pentest evidence, they are checking a specific claim: you actively test for vulnerabilities and remediate them. The evidence has to demonstrate four things:

1. Scope. What was tested, in-scope systems, domains, and the date. “We scanned some stuff” is not scope.
2. Method. A repeatable, documented process, not a one-time act of heroism nobody can reproduce next year.
3. Findings and severity. What was found, rated honestly, with enough context that a reviewer can see why the rating is what it is.
4. Remediation. What you did about it, or a tracked plan for what you will do, with dates.

Notice what's missing from that list: a count of how many CVEs you found. Auditors do not grade on volume. A clean report that documents thorough testing and a short, tracked remediation list is better evidence than 200 unfiltered findings with no triage.

What goes in the pack

Our SOC 2 Evidence Pack is a Deep authenticated network pentest plus a code scan, wrapped in auditor-ready framing. Concretely:

• An executive summary a non-technical reader (your auditor, your board) can act on: scope, dates, headline posture, and the remediation status.
• A control-mapped evidence section that ties findings and testing coverage to the specific criteria, CC6.1, CC7.1, and so on, so the auditor doesn't have to do the mapping themselves. This is the part a generic pentest PDF almost never includes, and the part that saves you a round-trip.
• Calibrated, honest findings. Severities that reflect exploitability in your context, not the worst-case number the advisory assigned in the abstract. We wrote about that calibration in why most ‘high’ CVEs are noise and what a good report looks like.
• A coverage report. Even when nothing serious turns up, proof of what was tested is itself the evidence of due diligence. “We tested X, Y, Z and found nothing exploitable” is a valid, and common, audit outcome.
• 12-month artifact retention and clean, unwatermarked exports (Markdown, HTML, PDF, CSV), because the free-tier watermarked report is explicitly not valid for compliance, by design.

What auditors reject

Things we've seen bounce, and that we build against:

• A raw scanner export. A database query result with no triage, no context, and no remediation is not a pentest report, it's a to-do list, and auditors know the difference.
• Findings with no severity rationale. A wall of “high” ratings with no explanation reads as uncalibrated, and an auditor who can't tell which findings matter will ask you to do the work again.
• No remediation tracking. Findings with no “fixed / accepted / planned” status and no dates. The audit cares as much about your response as your exposure.
• A stale report. A pentest from 14 months ago against an app that's shipped 300 times since. This is the argument for continuous scanning over an annual event, the evidence stays current.

One-off pack or continuous monitoring?

Two different needs, two different SKUs, and it's worth being clear about which you have:

• You have an audit in a few weeks. The one-off SOC 2 Evidence Pack is the right call, a single deep engagement with the control-mapped deliverable, anchored at roughly a quarter of typical audit-prep pentest spend.
• You need to stay compliant. SOC 2 Type II is about controls operating over a period, not a point in time. A Business or Enterprise subscription gives you scan history, remediation tracking, and the continuous-monitoring artifacts a Type II auditor expects, without you re-buying a pentest every quarter.

A note on our own posture

In the spirit of the honesty we ask of our reports: Pwnkemon itself is currently pre-SOC 2. We follow the controls we expect to attest to, but we don't yet hold an external attestation, and we say so plainly in our security docs. The Evidence Pack is about producing the pentest evidence your audit needs; it doesn't depend on our attestation status, and we'd rather you hear that from us than find it in diligence.

If you've got an audit window coming up, the SOC 2 Evidence Pack is built for exactly that. Questions about scope for your environment are the kind of thing worth a short conversation, reach out before you buy if you're unsure it fits.