SOC 2 Type I vs Type II: what changes in your policies
A Type I report says your controls were suitably designed as of a date. A Type II report says they operated effectively over a period. The policy documents are the same for both, but what the auditor does with them is different, and that changes how you should write the frequencies, procedures and review dates inside them.
The two reports in one table
| Type I | Type II | |
|---|---|---|
| Question the auditor answers | Are the controls suitably designed to meet the criteria as of this date? | Did the controls operate effectively throughout this period? |
| Time frame | A single date | An observation period, usually 3 to 12 months |
| What is tested for policies | Existence, approval, ownership, coverage of criteria, communication to staff | All of the Type I tests, plus samples showing each procedure ran at its stated frequency |
| Typical evidence request | The 22 policies, approvals, acknowledgments, one example of each control | The same, plus populations and samples: all access reviews in the period, 25 of the production changes, every incident |
| Time to first report | Weeks after policies are adopted | The observation period plus fieldwork, so months |
What stays the same
The 22 policies, their owners and the criteria they map to do not change between Type I and Type II. The structure Policyseed uses (purpose, scope, roles, policy statements, procedures, exceptions, enforcement, review cadence, revision history) is designed so a policy adopted for a Type I can be carried into a Type II without rewriting. If you have already adopted a set from the free generator or the Audit Kit, keep it.
What changes
1. Every frequency becomes a commitment
In a Type I, a statement such as “access is reviewed quarterly” is assessed for design: is quarterly a reasonable frequency for this criterion? In a Type II, the auditor takes the observation period, counts how many quarterly reviews should have happened, and asks for each one. Write frequencies you will meet. “At least annually” is easier to keep than “quarterly”; “quarterly” is easier than “monthly”. Where a tool does the work continuously (a scanner, an alerting rule), say “continuously, with findings triaged within N business days” and make sure the triage is evidenced.
2. Procedures need a paper trail
Section 5 of each policy describes how the control runs. For a Type II, every step that produces a decision should also produce an artifact: a ticket, an approval, a dated document. The Policyseed templates are written this way (for example, the Access Control Policy makes the ticket the evidence of the grant), but if you edit the procedures, keep the artifact in the sentence.
3. Exceptions need a register
Section 6 of every policy allows exceptions with written approval and an expiry. In a Type I the auditor checks that the mechanism exists. In a Type II they ask for the register and test whether expired exceptions were closed or renewed. An empty register is fine; a missing one is not.
4. Enforcement must be real
Section 7 describes consequences. A Type II auditor may ask whether any violations occurred in the period and what happened. Keep a short record even if the answer is “none”.
5. The revision history has to move
A Type I pack can have one row per policy (version 1.0, effective date, approver). During a Type II observation period the annual review date will arrive. The review must be evidenced by a new row, even if nothing changed (“Annual review; no changes”), and by the approver’s sign-off. This is the single most common policy-related Type II finding at small companies, which is why the Audit Kit ships an ICS review calendar and the CLI has a check command that fails CI when a review is overdue (see docs).
6. Changes during the period need versions
If you tighten a control mid-period, record it as a version with a date. The auditor will test the old design before the date and the new design after it. Re-collect acknowledgments when the change affects what people must do (see the acknowledgment guide).
Review cadence by activity
The intake asks for one policy review cadence (annual, semi-annual or quarterly), which is written into section 8 of every policy. Individual controls have their own frequencies inside sections 4 and 5. The table below shows what is typically expected for each.
| Activity | Policy | Type I expectation | Type II expectation | Evidence |
|---|---|---|---|---|
| Policy review and re-approval | All 22 (section 8) | Approved once, dated | At the stated cadence (annual minimum) and on material change | New revision history row, approver sign-off |
| Access review | P03 Access Control | One completed review, or a scheduled first review | Quarterly for production, source code and identity admin; each review evidenced | Reviewer attestations, list of removals with dates |
| Risk assessment | P17 Risk Assessment | One completed assessment | Annual, plus updates when risks change | Risk register with scores, owners and treatment dates |
| Vulnerability remediation | P11 Vulnerability and Patch | Scanning configured; SLAs defined | SLAs met for samples across the period | Scanner reports, tickets showing time to fix |
| Backup restore test | P15 Backup and Recovery | One test, or a scheduled first test | At least annually; quarterly is common for SaaS | Test record with date, dataset, outcome, time to restore |
| Incident response exercise | P13 Incident Response | Plan exists; contacts named | Annual tabletop; every real incident documented | Tabletop notes, incident tickets with post-incident reviews |
| Business continuity test | P14 BC/DR | Plan exists with RTO/RPO | Annual test or exercise | Exercise report, lessons learned, plan updates |
| Vendor review | P16 Vendor Risk | Inventory of vendors with data access | Annual review of critical vendors; new vendors assessed before onboarding | Vendor register, SOC 2 reports collected, review notes |
| Training and acknowledgment | P18 HR Security | All current staff acknowledged | Onboarding within the first week; annual refresh for everyone | Signed forms or LMS records per person |
| Change management | P09 Change Management | Branch protection and review rules configured | Every sampled production change shows review and approval | Pull requests with approvals, CI results, deployment logs |
Choosing the observation period
A first Type II is commonly done over three months, which is the shortest period most firms will report on. Six or twelve months gives customers more assurance and is what a mature program runs on. The practical advice: start the observation period on the day the policies are adopted and acknowledged, run every procedure at least once in the first month so nothing is untested when fieldwork starts, and do not change the review cadence mid-period.
For the order in which to write and adopt the policies, see SOC 2 policies for startups. For what the auditor will ask in the walkthrough, see what auditors ask about policies. The template index lists all 22 policies, and the pricing page covers the Audit Kit and the Agency licence.
Frequently asked questions
- Do I need different policies for Type I and Type II?
- No. The same policy set serves both. What changes is that in a Type II the procedures in section 5 of each policy must have actually run on the stated cadence during the observation period, with evidence the auditor can sample.
- Should I do a Type I first?
- A Type I is a faster way to a report and a useful forcing function. Many companies now go straight to a Type II with a three-month window, since customers increasingly ask for Type II. Either way the policies are written once; the difference is when the observation period starts.
- What review cadence should I choose in the intake?
- Annual is the norm and is what most auditors expect for policy review. Choose semi-annual or quarterly only if you will actually do it; a missed quarterly review is a finding, a completed annual review is not. Note that access reviews are quarterly regardless of the policy review cadence.
- Can I change a policy during the Type II observation period?
- Yes. Record the change as a new version in the revision history, have it approved, re-collect acknowledgments if the change affects what people must do, and keep the old version. The auditor will test the control as it was designed at each point in the period.
- Does Policyseed guarantee a clean Type II?
- No. Policyseed provides governance policy templates and optional AI tailoring. Whether controls operated effectively is determined by the CPA firm from your evidence. Policyseed is not legal advice and makes no compliance guarantee.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.