Moving from SOC 2 Type 1 to Type 2 means your controls must operate consistently across an observation period and you must keep dated evidence for every occurrence. The policies can mostly stay; what changes is discipline, sampling readiness, exception handling and a calendar of recurring tasks.
What actually differs
The AICPA text is clear. A Type 1 report addresses the design of controls at a point in time and has no opinion on operating effectiveness. A Type 2 covers a period and includes the auditor's tests of operating effectiveness and the results of those tests. The same criteria apply to both.
So your Type 1 work is not wasted. The system description, scope and most policies carry over. The new risk is that a control that existed on one date might not have run every time during the period.
Where Type 1 shortcuts show up
One time setup becomes recurring work. An access review done once before the audit date becomes reviews at the cadence your policy states, each with a reviewer, date and outcome (CC6.2, CC6.3).
Evidence by sample. The auditor will pick samples from populations: new hires, leavers, code changes, incidents, vendors. You need a complete population for each, such as a list of every change merged in the period, so samples can be drawn.
Exceptions need a story. A missed review or a change without approval is an exception, not necessarily a failure, but only if you noticed, recorded and fixed it. Silent misses are worse than logged ones.
Policy changes need a trail. If you tighten or loosen a rule mid period, record the date and reason. Auditors test against the policy in force at the time.
What to change, area by area
- Access (CC6): schedule reviews, keep leaver tickets with timestamps, and keep a list of all users at review time.
- Change (CC8.1): make sure every production change links to a reviewed, approved change record. Close loopholes such as direct pushes.
- Monitoring and incidents (CC7.2 to CC7.5): keep alert records and a log of events evaluated, even when nothing happened.
- Vendors (CC9.2): refresh vendor assessments at your stated cadence and keep the outputs.
- Risk (CC3.2): update the risk assessment on schedule and after significant change.
- People (CC1.4): keep training completions and acknowledgments for new joiners within your stated window.
- Availability and Confidentiality, if in scope: test restores and recovery plans (A1.3) and keep dispositions (C1.2).
Choosing the observation period
The AICPA text says a Type 2 covers a period but does not fix a length in the material we reviewed. Your auditor will advise on minimum periods. A common planning approach is to start with a shorter period first and move to longer ones, but confirm with your auditor rather than assuming.
A short example
Suppose your access policy promises a quarterly review. In Type 1 you showed the design and perhaps one completed review. In Type 2 the auditor expects each quarter in the period to have a review, with the user list, reviewer, changes made and dates. If a quarter slips, complete it as soon as you notice, record why it was late and fix the calendar so it cannot slip silently again.
What to do
- Ask your auditor to confirm the observation period start date and length.
- Build a control calendar: each recurring control, owner, due date and evidence location.
- Create a population list for each sampled control and update it as events happen.
- Set up an exception log with owner, cause, fix and date.
- Run a monthly review of the calendar and exception log.
- Freeze scope changes without a ticket; scope drift creates sampling surprises.
- Hold an internal mid period check, and fix gaps while the period is still open.
Quick check
Do I need new policies for Type 2?
Usually no. Keep the policies, but make sure the practice matches them for the whole period and record any changes with dates.
What if a control fails during the period?
Record it as an exception, fix it and document the cause. The auditor assesses how it was handled, and the report may note it.
How Safeguard helps automate this
Type 2 is where manual evidence collection breaks down, because the same proof is needed again and again. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously through the whole period, which saves your team time for other work. Technical evidence for change and vulnerability controls comes from your real code and dependencies: scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests; it is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. The opinion comes from an independent auditor, not from Safeguard. Book a call.
Sources
- AICPA, Trust Services Criteria (2017, with 2022 points of focus): Type 1 and Type 2 definitions and criteria IDs. Paraphrased.
Last reviewed: 18 October 2026.
