Pass your SOC 2 audit
Walk into your SOC 2 audit with the evidence already assembled. Pentest Today runs the penetration test, scans your environment, and generates the policies and diagrams your auditor maps straight to the Common Criteria.
What a SOC 2 review asks for
SOC 2 is an AICPA report on how your controls meet the Trust Services Criteria — security, availability, processing integrity, confidentiality, and privacy.
What closes each requirement
| Control | What they ask | Evidence | Where it comes from |
|---|---|---|---|
| CC4.1 · evaluations | Show me an evaluation of your controls that somebody outside the team carried out, when it ran, and what you did with what it found. | The penetration test report. Severity sits on every finding, tied to the affected asset; where a finding was actually scored it also carries a CVSS v3.1 vector and base score, and where one applies, an OWASP category. Evidence and reproduction steps fill out the picture, with remediation closing it out on the findings that carry one — so a weakness has a date, a location, and, more often than not, a close rather than a mention. | The pentest workflow. An approved-target scan is triaged into findings and exported as a client-ready PDF, with an Executive Summary that counts findings by severity. |
| CC6.1 · logical access | Who can reach production, who approved each of them, and what stops everybody else. | The Access Control Policy — unique attributable accounts, documented approval before provisioning, MFA on administrative and production paths, and a stated review cadence — read against a dated export from your identity provider. | The policy pack. Thirteen documents are generated from one intake, so the access rules and the data-handling rules do not contradict each other in front of an auditor. |
| CC6.6 · boundary protection | What protects the system from outside its boundary, and how you know that protection holds today rather than on the day it was configured. | External test results against the approved targets: transport security, HSTS, Content-Security-Policy, MIME-sniffing and clickjacking protections, and anything reachable without authentication. | The scan behind the report. The free passive check names the same signals — a missing HSTS header, no Content-Security-Policy, no clickjacking protection, a permissive SPF record — before you buy anything. |
| CC7.1 · detecting new weaknesses | How you find out that a configuration drifted or a new vulnerability appeared, instead of hearing it from a customer. | The Vulnerability Management Policy setting the scanning cadence and the remediation SLA per severity, plus the Scan Runs block in the report: scan identifier, type, status, and the start and completion timestamp of every successful run behind the findings. | The policy pack, plus the report's Scope and Methodology section, which lists the approved targets and every scan run by date. |
| CC7.4 · responding to what you find | When something is identified, who owns it, what was done about it, and how you know it is closed. | The Incident Response Policy — severity tiers, escalation, containment, eradication, recovery, post-incident review — and the per-finding status trail, which moves from open to remediated and then carries a retest status of fixed or not fixed. | The policy pack, plus the retest workflow, which re-tests the previously reported findings and issues a retest report restating each one. |
| CC9.2 · vendors and subprocessors | Which third parties touch customer data, how each was assessed before onboarding, and what you review afterwards. | The Vendor Management Policy for the assessment process, the AI Vendor Review Policy for model providers, and the system architecture and data-flow diagram that draws each third party outside your trust boundary instead of describing it in a sentence. | The policy pack and the generated architecture diagram, both built from the same intake, so the vendor list and the drawing agree. |
What the report actually contains
Illustrative example, written in the format the product generates. Not taken from a customer engagement.
How this review actually runs
A SOC 2 engagement starts with scope, not with testing. You and the audit firm agree which systems sit inside the boundary and which of the five Trust Services Categories the report covers; most first reports take Security on its own. Everything after that is judged against the boundary, which is why a test of the wrong hostname is worth nothing however good the test was.
Readiness comes next, run by an audit firm or by a separate consultant. It produces a gap list: a policy that does not exist, an access review nobody ran, a diagram nobody drew. This is where the evidence work actually happens and where the calendar actually slips — not in the audit.
The penetration test sits inside readiness. You authorize targets, testing runs against those targets only, findings are triaged and written up with evidence and reproduction steps, and the export is a PDF whose scope section names what was tested. Fixes then go back through the retest, which restates each previously reported finding as fixed or not fixed.
The auditor samples last. They pick items, ask for the artifact behind each one, and read the artifact against the criterion rather than against your description of it. Two things stall this stage repeatedly: an artifact that exists but carries no date, and an artifact that contradicts one you already handed over. A policy promising quarterly access reviews, beside an export showing one review in fourteen months, is the version everybody meets.
What gets this sent back
Scan
Authenticated and external scans across web, API, and cloud surface the issues before an assessor does — de-duped, triaged, and mapped to CVE/CVSS.
Pentest
Approved-target scans become a client-ready pentest report: validated findings, evidence, reproduction steps, remediation, and the retest letter auditors accept.
Policy Generator
Generate the policies and system architecture diagrams the review expects — access control, cryptography, incident response — pre-mapped to controls.
Start your Pentest
Our agent swarm and human experts test your endpoints and deliver an audit, fast.
SOC 2 Type II
A SOC 2 Type II report tests whether your controls operated effectively across an observation window, not just on paper.
ISO 27001
ISO/IEC 27001 certifies that you run an Information Security Management System (ISMS) with the Annex A controls in place.
HIPAA
The HIPAA Security Rule requires administrative, physical, and technical safeguards for electronic protected health information (ePHI).
GDPR
GDPR Article 32 requires appropriate technical and organizational measures to secure personal data, including regular testing of their effectiveness.
PCI DSS
PCI DSS protects cardholder data and explicitly requires both internal and external penetration testing at least annually.
NIST CSF
The NIST Cybersecurity Framework organizes security around Identify, Protect, Detect, Respond, and Recover.
SOC 2, answered
Does SOC 2 require a penetration test?
No criterion names penetration testing outright, but auditors routinely accept a test as evidence for the risk-assessment and monitoring criteria, and enterprise buyers reading the finished report expect to find one. What satisfies both is a test with a scope statement, dated findings, and a retest that closes them.
What is the difference between a SOC 2 Type I and a Type II report?
A Type I report describes controls as designed on a single date; a Type II report tests whether those same controls operated across an observation window of three to twelve months. The evidence differs accordingly: Type I accepts the document, and Type II wants a population and a sample drawn from inside the window.
Which SOC 2 criteria does a penetration test actually close?
A test is read most often against CC4.1, which wants evaluations of whether controls are working, and CC7.1, which wants a way to detect new weaknesses. Findings that reach remediation and retest also feed CC7.4. It does not close the logical-access criteria on its own; those need the policy and the approvals behind it.
How recent does a penetration test have to be for a SOC 2 audit?
Inside the twelve months before the report date is the common expectation, and inside the observation window for a Type II. A test older than that, or one dated before a significant architecture change, invites the auditor to ask what has been tested since — which is the question a retest exists to answer.
Can findings still be open when the audit starts?
Open findings are normal and rarely fatal on their own. An auditor looks for a severity, an owner, a remediation date, and a decision: fixed, accepted with a written rationale, or scheduled. An unexplained critical left open across the whole period is the version that draws a qualified opinion.
Does Pentest Today issue the SOC 2 report?
Pentest Today does not issue SOC 2 reports; a licensed CPA firm does, after its own examination. Pentest Today is not an audit firm and holds no attestation of its own. What it produces is the evidence that firm asks for: the penetration test, the environment scan, the policy pack, and the architecture diagram.
Is the pentest a real test or just a scanner dump?
Both scanning and AI triage are scoped to your approved targets, and every finding is reviewed and signed off by a human before delivery — so the report reflects verified findings, not raw scanner noise.
How fast can I get a report?
Most reports turn around in hours, not weeks. You connect an approved target, we scan and verify, and you export a client-ready report and policy pack.
Get the evidence for your SOC 2 review this week.
Start a scan on an approved target and walk in with the report, policies, and diagrams already done.