SOC 2 Type I vs Type II, and where the pentest fits

If you are pursuing SOC 2, one of the first decisions is Type I or Type II, and it is not just a paperwork distinction. It changes the timing of your penetration test and what the test has to prove. Getting it straight early saves you from discovering a scheduling problem at the worst possible moment.

Type I: designed correctly, at a point in time

A SOC 2 Type I report assesses whether your controls are designed appropriately as of a single date. It is a snapshot: do the right controls exist and are they set up correctly today? Type I is faster to obtain and is often a startup's first step, but it says nothing about whether those controls actually held up over time, only that they were in place on the day of the assessment.

Type II: operating effectively, over a window

A SOC 2 Type II report assesses whether your controls operated effectively across a period, typically three to twelve months. This is the report most enterprise customers actually want, because it demonstrates sustained operation, not a one-day pose. The observation window is the part that affects your testing: evidence has to fall inside it.

Where the pentest fits

Penetration testing supports the monitoring criterion (CC4.1), which we cover in does SOC 2 require a penetration test. For Type I, a recent test showing your controls are soundly designed is generally what an auditor wants. For Type II, the bar is higher: the test should fall within the observation window, and you should be able to show that serious findings were remediated and retested before the period closed. A test from before the window, or open criticals at the end of it, weakens the evidence.

Type I asks whether the locks are installed. Type II asks whether they stayed locked for a year. Your pentest has to answer the version of the question your report is making.

Practical implications

• For Type I: schedule a test that demonstrates sound control design before your report date.
• For Type II: schedule the test inside your observation window, and leave time to remediate and retest the serious findings before it closes.
• Either way: scope the test to your SOC 2 system boundary, and make sure the report maps findings to the relevant criteria.

Uvy fits either path: a real test scoped to your boundary, run when your report needs it, with exploitable findings proven and the serious ones retested closed, in a report an auditor can use. See how it works.