Pass your SOC 2 Type II audit
Type II is about evidence over time. Pentest Today gives you the pentest, continuous scans, and control-mapped policies that prove your security program actually ran during the audit period.
What a SOC 2 Type II review asks for
A SOC 2 Type II report tests whether your controls operated effectively across an observation window, not just on paper.
What closes each requirement
| Control | What they ask | Evidence | Where it comes from |
|---|---|---|---|
| CC3.4 · changes inside the period | What changed in the environment while the window was open, and how the risk was re-assessed each time it did. | A dated architecture drawing per significant change, paired with a test that postdates the change rather than only preceding it. The pairing is the point: a change record on its own says nothing about whether anyone looked at it. | The architecture diagram regenerates from the intake, so a change to the stack produces a new dated drawing instead of an edit nobody can place in time. |
| CC4.2 · deficiencies communicated and corrected | Take one weakness you found during the period, show me who it was reported to, the corrective action that followed, and something other than the word of the people who fixed it confirming that it closed. | One finding traced end to end: the finding as written, its severity and evidence, the remediation, and the retest line restating it as fixed. The retest report opens with a progress line counting how many of the original findings are resolved as of that retest. The trail is the evidence; the fix on its own is invisible to an auditor. | The report's Detailed Findings section, plus the retest workflow, which re-runs against the same approved targets and re-evaluates every finding still marked pending. |
| CC7.2 · monitoring between tests | How the environment was watched in the months between assessments, rather than on the day of one. | Scan runs spread across the period. The report prints each successful run's identifier, type, status, and start and completion timestamps, which gives an auditor a population to sample instead of a single date to accept. | The Scope and Methodology section. Every re-run you start against the approved targets adds another dated row to it. |
| CC7.3 · evaluating what was found | For the events you detected, how you decided which ones were incidents and which were not. | The Incident Response Policy's severity definitions and entry conditions, alongside the triage decision recorded against each finding — confirmed, remediated, or dismissed as a false positive. | The policy pack, plus the status recorded on each finding in the engagement, which is what a sample is drawn from. |
| A1.2 / A1.3 · backup and recovery, exercised inside the period | That you can actually restore, and that somebody proved it during the window rather than assuming it would work. | The Business Continuity / Disaster Recovery Policy's backup section — daily automated backups of production data stores, encrypted at rest, held with geographic or account separation, and restores tested at least quarterly with the results documented — paired with your own dated test records from inside the period. The document sets the commitment; your test records are what it gets sampled against. | The policy pack. Those backup clauses are the standing commitments the document is written from, and the Current implementation section beneath them is written from your intake's backup process, hosting setup, and cloud provider. |
| CC8.1 · change management | That changes to production were authorized, tested, and approved — sampled from every change in the period, not from the three you picked out. | The Change Management Policy and the Secure SDLC Policy set the approval path and the pre-release security requirements; your ticket and pull-request history is the population sampled against them. | The policy pack. Both documents come from one intake, so the release gate described in the SDLC policy and the approval step in change management describe the same process. |
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 Type II audit fixes a start and an end date, and every artifact is judged by whether it falls between them. A penetration test is a single dated event inside that period, which creates the problem nobody writes about: one test speaks for one day out of, say, two hundred and seventy.
Auditors resolve it in a specific way, not by treating the test as continuous coverage. The test is one occurrence of a control that is supposed to recur, so what gets sampled is the cadence, not the test. A single dated test supports the criterion only when the policy it evidences sets testing at that frequency, and when the rest of the period shows the control's other half: findings assigned, remediated, and confirmed.
That confirmation fills the remaining months: it is the retest that carries the date, not the finding record itself. The retest re-runs against the same approved targets, restates each previously reported finding as fixed or not fixed, and is dated later in the window than the original. Re-running the scan on the cadence your Vulnerability Management Policy commits to adds further dated rows to the Scan Runs block — the population an auditor samples.
This stalls on a period that opened before any of it existed. Evidence created after the fact is dated after the fact, and an auditor reads a policy approved in month eleven as a control that operated for one month. Nothing later recovers that, which is why the window start date is the decision worth arguing about.
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.
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.
FedRAMP
FedRAMP authorizes cloud services for U.S. federal use, built on NIST 800-53 controls and requiring penetration testing.
SOC 2 Type II, answered
How long is a SOC 2 Type II observation window?
Three to twelve months, chosen by you with the audit firm. First reports usually take a short window — three months is the common choice — to put a report in a buyer's hands sooner, then extend to twelve on the next cycle. The window length is printed on the report, and buyers do read it.
Does one penetration test cover a whole Type II window?
One penetration test does not cover a Type II window on its own. A single dated test evidences that the evaluation happened; what covers the rest of the period is the trail behind it — findings with remediation dates, a retest confirming the fixes, and further dated scan runs at whatever cadence your vulnerability management policy commits to.
When in the observation window should the penetration test run?
Early enough that findings can be remediated and retested before the window closes, which in practice means the first third of the period. A test in the final weeks produces open findings with no period left to close them in, and unresolved criticals at period end are what draw a qualified opinion.
Do I need a retest after fixing findings?
Auditors accept a fix far more readily when something other than the engineering team confirms it. A retest re-runs against the same approved targets and restates every previously reported finding as fixed or not fixed, dated later in the window than the original report — which is exactly the before-and-after pairing being sampled.
What happens if the environment changes mid-window?
A significant architecture change resets the question for everything downstream of it: the diagram, the risk assessment, and the last test all describe a system that no longer exists. Regenerate the diagram, test the new surface, and keep both dated versions, because the auditor wants the before as well as the after.
Can last year's penetration test be reused for this year's Type II?
Last year's penetration test counts only if it falls inside this year's observation window, which by definition it does not. A test from the previous period evidences the previous report. What does carry forward is remediation history: a finding raised last year and confirmed fixed inside this window is legitimate evidence for the corrective-action criterion.
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 Type II review this week.
Start a scan on an approved target and walk in with the report, policies, and diagrams already done.