A field guide to SOC 2 evidence packs

Every SOC 2 auditor we have worked with has, at some point, asked a version of this question: "Do you have evidence that the penetration testing findings were remediated, and that management reviewed the results?" It sounds like a simple ask. If you are the security lead being asked, you already know it isn't.

The pentest report itself is only half of what your auditor wants. They want a paper trail — timestamps, sign-offs, remediation tickets, retest confirmations — that shows the finding was seen, understood, prioritised, fixed, and verified fixed. Most testing firms hand you a PDF and expect you to build that paper trail yourself. We think that is the wrong division of labour, so we started shipping what we call evidence packs.

What actually goes in a SOC 2 evidence pack

The pack is a zip file that lands with your final report. It contains, at minimum, six artifacts, each of which corresponds to something a Type II auditor is going to specifically ask you to produce.

The engagement letter is a signed PDF that shows the scope of testing, the dates of the engagement window, and the testers assigned. Auditors care about this because it demonstrates that the pentest actually covered the systems in scope of your trust services criteria — not, for example, a marketing site that shares no infrastructure with your production stack. This is the piece of evidence that most cheaply-run pentest engagements get wrong; they scope the testing to whatever the customer thought to mention rather than what the SOC 2 boundary actually covers.

The executive summary is a one-page brief that summarises the finding mix, the severity distribution, and the overall posture assessment. Auditors read this before they read anything else. It should not contain any technical detail that is not repeated elsewhere in the pack — the point is a document that a non-technical board member could read in three minutes and understand the state of the world.

The full technical report is the thing your engineers care about. Every finding with severity, CVSS score, evidence (screenshots, requests, responses), reproduction steps, and remediation guidance. Auditors will spot-check this against the finding tickets you filed in your issue tracker, so the finding IDs need to match. We assign every finding a stable ID at the moment we confirm it and never renumber, precisely so that the ID in your Jira ticket forever matches the ID in the report.

The remediation log is a CSV export of every finding with columns for status, assigned engineer, remediation date, and retest verification date. This is the artifact auditors want but almost nobody produces cleanly. If you have to hand-build it from your issue tracker two months later, it will be wrong. If it is generated automatically from the testing platform, it is trivially correct.

The retest attestation is a signed letter from the tester confirming that specific findings were verified as remediated on a specific date, along with a re-issued report showing the updated status. This is the piece your auditor will use to close a finding on their end. Without it, the finding stays open in their file even if it is closed in yours.

The methodology statement documents which standards were followed (OWASP WSTG, PTES, NIST SP 800-115, etc.), which certifications the testers held, and how the engagement was conducted. This exists because some auditors are stricter than others, and having the methodology in writing means you can hand it over without having to schedule a call to explain what a pentest is.

What auditors care about that most firms miss

Beyond the six artifacts above, there are three things auditors quietly care about that most pentest reports do not surface, and which we now do surface because we got tired of the follow-up emails.

Tester independence. SOC 2 wants evidence that the testing was performed by someone independent of your engineering organisation. This is almost always trivially true — you hired an outside firm — but the auditor still wants it stated. Our pack includes a one-line statement to this effect, so you can hand it over instead of having to write your own.

Scope justification. The pack includes a section explaining why the tested scope maps to your SOC 2 boundary. If your production tier is testing but your staging tier is out of scope, we say so and explain why. If we chose to test staging because production is not safely testable, we say so. This preempts the "why wasn't X tested?" email that otherwise arrives a week before your audit.

Change since last engagement. For repeat customers, the pack includes a diff — what has changed in scope, what findings were recurring, what regressions we found. Auditors love this because it demonstrates trend awareness. Customers love it because it makes the case for continued investment in the security programme.

Frameworks other than SOC 2

The same rough structure works for ISO 27001, PCI DSS, and HIPAA, with framework-specific tweaks. ISO auditors specifically want findings mapped to Annex A controls. PCI auditors want to see requirement 11.4 explicitly referenced and segmentation testing evidence. HIPAA wants to see the risk analysis framing.

We generate a framework-specific pack based on the compliance driver you selected at scoping time. If you have multiple driving frameworks — increasingly common for scale-ups — we generate multiple packs from the same underlying engagement so you don't pay twice.

What this actually costs

Producing evidence packs takes us about two hours of tester time per engagement, plus some automated tooling that we built once and now runs on every job. It is included in every report we deliver, at no extra charge. We do not think it should be a premium feature. If you are paying for a pentest, you are paying for a pentest that helps you close your audit. Evidence packs are how it does that.

If you are running a SOC 2 renewal in the next quarter and want to see what our packs look like, we have a redacted sample available on request — just email hello@secureblock.io.