The short answer: to prepare for a SOC 2 Type II audit, scope your system and choose your Trust Services Criteria, run a readiness assessment, fix the gaps, and then operate your controls through an observation window, commonly 3 to 12 months, while capturing evidence the whole time. At the end, a licensed CPA firm samples that evidence and issues the report. Most Type II problems are not missing controls; they are months where a control ran but nobody kept the proof.
This guide covers Type I vs. Type II, choosing your criteria, a step-by-step prep plan, the evidence auditors sample, a realistic timeline, how to choose an auditor, and how to compare doing it yourself with software against a managed readiness service.
SOC 2 Type I vs. Type II
Both reports are attestation reports defined by the AICPA and evaluated against the same Trust Services Criteria. The difference is time.
| Aspect | Type I | Type II |
|---|---|---|
| What the auditor opines on | Whether controls are suitably designed | Whether controls are suitably designed and operated effectively |
| Time covered | A single date (“as of”) | A period of time, the observation window (“throughout”) |
| Evidence tested | Policies, configurations and walkthroughs of how each control works | Samples of each control actually running across the whole window |
| What it tells a customer | You have the right controls in place today | Your controls kept working, month after month |
| Typical use | A first report to unblock early deals while Type II runs | The report most enterprise security reviews ask for |
A Type I can be done shortly after remediation. A Type II cannot be rushed: the observation window has to elapse, and the auditor tests what actually happened inside it.
Choosing your Trust Services Criteria scope
The Trust Services Criteria have five categories. Only one is mandatory:
- Security (required): the Common Criteria, CC1 through CC9, covering governance, risk assessment, access, system operations, change management and vendor risk. Every SOC 2 report includes them.
- Availability (optional): uptime commitments, capacity, backups and disaster recovery. Add it if customers rely on your service level agreements.
- Confidentiality (optional): protecting information designated confidential, such as customer business data, including its disposal.
- Processing Integrity (optional): processing that is complete, accurate and timely. Relevant for payments, payroll or data-processing services.
- Privacy (optional): how personal information is collected, used, retained and disclosed.
For a small team, start with Security and add a category only when a customer contract or security questionnaire asks for it. Each one adds controls you must operate, and sample evidence you must produce, every month of the window.
How to prepare for a SOC 2 Type II audit, step by step
- Define the system boundary. List the product, infrastructure, data stores, people and vendors that deliver the service your customers buy. Anything outside the boundary is out of scope; anything inside needs evidence.
- Choose criteria and an audit firm early. Agree the criteria and the observation window dates with your CPA firm before the window starts, so nobody disputes the period later.
- Run a readiness assessment. Map every control to the criteria, test whether it exists and runs, and produce a control-by-control gap list with owners. Our SOC 2 readiness checklist covers the controls in detail.
- Remediate the gaps. Approve policies, turn on MFA and logging, set up access reviews, formalize change approval, and stand up vulnerability scanning with remediation deadlines. A 30-60-90-day SOC 2 plan breaks this into phases.
- Automate evidence capture before the window opens. Every control that runs during the window needs dated proof. Decide now where each piece of evidence comes from and who owns it.
- Optionally, complete a Type I. If deals are waiting, a Type I shows the design is sound while the Type II window runs.
- Operate the controls through the observation window. Run each recurring control on schedule and review evidence monthly, not at the end, so a missed review is caught while it can still be explained.
- Run a mock audit before fieldwork. Pull samples the way an auditor would and fix gaps in the evidence trail before the real request list arrives.
- Support fieldwork and review the draft report. Answer sample requests quickly, walk the auditor through each control, and respond in writing to any exception in the draft.
What evidence auditors sample during the observation window
In a Type II audit the auditor selects samples from the full population of each control’s activity during the window, for example a selection of changes, a selection of leavers, and every quarterly access review. The table shows the areas that are almost always tested under the Security criteria.
| Control area | Evidence | How often |
|---|---|---|
| Logical access reviews | Signed-off reviews of who has access to in-scope systems, with removals actioned | Usually quarterly; every review in the window can be sampled |
| Onboarding and offboarding | Access requests and approvals for new hires; access removed on or near the termination date | Per event; auditors sample hires and leavers from HR records |
| Change management | Tickets or pull requests showing review, approval and testing before production deploys | Per change; sampled from the full change population |
| Vulnerability management | Scan results, tickets with owners, fixes within your stated timelines, and rescans proving closure | At the frequency your policy states, often monthly or continuous |
| Incident response | Incident tickets, post-incident reviews, and a tabletop exercise if no real incident occurred | Per incident; plan tested at least annually |
| Vendor management | Vendor inventory, risk ratings, and reviews of critical vendors’ own assurance reports | At onboarding and on the review cycle your policy sets |
| Security awareness training | Completion records for every in-scope employee and contractor | At hire and annually |
| Risk assessment and policies | A dated risk assessment, approved policies, and employee policy acknowledgments | At least annually |
Vulnerability management is where policy-only evidence most often falls short: the auditor wants to see that a finding was detected, assigned, fixed within your stated deadline and verified by a rescan. See how to prove vulnerability remediation to SOC 2 auditors.
SOC 2 Type II timeline
Durations below are typical ranges for a small or mid-sized company, not fixed rules. Your starting maturity and the window you agree with your auditor drive the real schedule.
| Phase | Typical duration | Output |
|---|---|---|
| 1. Scoping and readiness assessment | 2–4 weeks | System boundary, chosen criteria, control-by-control gap list |
| 2. Remediation | 4–12 weeks, depending on starting maturity | Missing controls implemented, policies approved, evidence flowing |
| 3. Type I audit (optional) | A few weeks of fieldwork and reporting | Type I report on control design as of one date |
| 4. Type II observation window | Commonly 3–12 months | Controls operating, evidence captured continuously |
| 5. Type II fieldwork | Several weeks after the window closes | Auditor samples evidence, interviews owners, notes any exceptions |
| 6. Report issued | Typically weeks after fieldwork | Type II report with the auditor’s opinion and any exceptions |
The gap between Type I and Type II, where most teams lose evidence
After a Type I, there is a natural sense that the hard work is done. It is the opposite: the Type I tested design on one day, and the Type II tests every month that follows. The common failure pattern looks like this:
- Evidence was gathered by hand for the Type I and nobody owns gathering it again each month.
- Recurring controls slip. A quarterly access review lands during a release crunch and is skipped, and that quarter cannot be re-run after the fact.
- Vulnerability findings age past deadlines because scans run but nobody tracks remediation to closure.
- Staff changes break ownership. The person who ran a control leaves, and their part of the evidence trail leaves with them.
The fix is to treat the window as an operating rhythm: named owners, scheduled tasks, evidence captured at the moment a control runs, and a monthly check that nothing is missing.
Common reasons for exceptions
An exception is a sample where the control did not operate as described. A few exceptions do not always mean a qualified opinion, but they appear in the report your customers read. The usual causes:
- Access reviews missed, late, or approved without evidence of follow-up
- Terminated users whose access was removed days or weeks late
- Production changes deployed without the documented approval
- High-risk vulnerabilities open past the remediation deadline in your own policy
- Training or policy acknowledgments incomplete for some staff
- A control description in the system description that does not match what the team actually does
The last item is worth stressing: write controls you can operate. Promising a weekly review you will realistically run monthly creates an exception you did not need.
How to choose a SOC 2 auditor
Only a licensed CPA firm can perform a SOC 2 examination and issue the report, under AICPA attestation standards. Readiness providers and software platforms, ours included, prepare you for the audit; they cannot sign the opinion. When comparing firms, ask:
- Is the firm licensed, and does it perform SOC 2 examinations regularly for companies of your size and type?
- Will the same team handle a Type I and a later Type II, so context carries over?
- Can it accept evidence exported from your tooling, and how does it want samples delivered?
- What is its independence policy? A firm that helped design your controls generally should not also audit them.
- How long from the end of fieldwork to an issued report?
DIY compliance software vs. a managed readiness service
The best SOC 2 audit preparation option for a small business depends less on features and more on who will do the work every month of the window. Compare options on these criteria:
- Who operates the controls. Software tracks tasks; someone still has to run access reviews, chase approvals and fix findings. If you have no security lead, a managed service supplies that person.
- Technical evidence, not just policy evidence. Check whether the option finds vulnerabilities itself and proves they were fixed, or only imports results from a separate scanner. Our guide to choosing a vulnerability platform for SOC 2 covers this in depth.
- Remediation, not just detection. Does anyone own closing the gaps the tool finds, or does it stop at a dashboard?
- Evidence continuity through the window. Look for continuous collection and alerts when a control drifts, so a missed review is caught in the month it happens.
- Audit support. Mock audits, auditor liaison and help answering sample requests during fieldwork.
- Internal time. Estimate the hours your engineers and managers will spend per month under each option. See the SOC 2 evidence automation comparison for the three common approaches.
DIY software suits teams with an in-house security owner and time to run the program. A managed readiness service suits teams that need the outcome without hiring for it. For side-by-side detail, see our comparisons with automation-first platforms: Vanta alternative and Drata alternative.
How Scan Ninja keeps evidence current between Type I and Type II
Scan Ninja works as an outsourced security and compliance team for companies preparing for SOC 2. Our U.S.-based experts can operate the program for you, or your team can run the platform yourselves. Either way, the work is aimed at an audit-ready evidence trail for the whole observation window:
- Readiness in the first week. The Week-1 Aha Pack delivers, within 7 days of access, a vulnerability assessment of in-scope assets, an evidence gap analysis, a remediation roadmap mapped to the Trust Services Criteria, and an executive risk summary.
- Type I and Type II readiness tracks with stage-gated milestones, plus mock audit preparation and auditor selection guidance.
- Continuous evidence collection mapped to the Trust Services Criteria, with owner workflows for evidence requests and continuous monitoring that alerts on deviations.
- Remediation proof from our own AI-native scanner: each finding is enriched, assigned to an owner, verified closed and exported for your auditor. Our managed vulnerability remediation service can drive the fixes for you.
Scan Ninja is not a CPA firm and does not issue SOC 2 reports. We get you ready, keep the evidence current, and work alongside the audit firm you choose. See the full SOC 2 readiness program.
Frequently asked questions
What is the difference between SOC 2 Type I and Type II?
A Type I report says whether your controls are suitably designed as of a single date. A Type II report says whether they are suitably designed and also operated effectively throughout a period of time, the observation window. Type II requires the auditor to test samples of each control running across that window, which is why most enterprise buyers ask for it.
How long is a SOC 2 Type II observation period?
Commonly between 3 and 12 months. First-time reports often use a shorter window so the company can get a Type II report sooner; renewals usually move to a 12-month period so coverage is continuous. You agree the period with your audit firm before it starts.
Do I need a Type I report before a Type II?
No. A Type I is optional. Some teams use one to unblock deals while the Type II window runs; others skip straight to the Type II window once a readiness assessment shows their controls are in place.
Which Trust Services Criteria do I need for SOC 2?
Security (the Common Criteria) is required in every SOC 2 report. Availability, Confidentiality, Processing Integrity and Privacy are optional. Add one only when customers or contracts call for it, because every criterion you add brings more controls to operate and more evidence to produce.
Who can issue a SOC 2 report?
Only a licensed CPA firm can perform a SOC 2 examination and issue the report, under AICPA attestation standards. Compliance software vendors and readiness providers, including Scan Ninja, can prepare you for the audit and organize your evidence, but they cannot issue the report.
What causes exceptions in a SOC 2 Type II report?
Most exceptions come from a control that worked on paper but was missed in practice during the window: a quarterly access review that was skipped, a leaver whose access stayed active, a change deployed without approval, a critical vulnerability left open past its deadline, or training that some employees never completed.
Sources
- AICPA & CIMA, SOC 2: SOC for Service Organizations, Trust Services Criteria
- AICPA, 2017 Trust Services Criteria (with revised points of focus, 2022)
Checked November 9, 2026. For SOC 2 readiness with remediation proof built in, see our SOC 2 readiness program.