A SOC 2 Type 1 can be planned as a ten week sequence: scope and owners, policies, control implementation, evidence capture, a readiness review, then auditor fieldwork. The ten weeks below are our planning template, not an official duration. Real timing depends on your starting point and your auditor's schedule.
A note on honesty about time
Neither the AICPA criteria nor the audit standards set a duration for a Type 1. What the AICPA text does define is what the report is: a description of the design of controls as of a date, with no opinion on operating effectiveness. Because it is a point in time, you can schedule backward from the date you want the controls described. Treat the weeks below as a sequence to adapt.
Weeks 1 and 2: scope and ownership
Choose your service commitments and categories: Security is required, and you decide on Availability, Confidentiality and others. List the systems that make up the service: cloud accounts, code hosting, identity provider, ticketing, HR and payroll tools. Name an executive sponsor, a programme lead and an owner per area. Shortlist auditors and agree a report date range.
Output: scope statement, system list, owner matrix, auditor engagement letter in draft.
Weeks 3 and 4: risk assessment and policies
Run a risk assessment (CC3.2) and record it. Draft the core policies: security, access, change, incident, vendor, continuity, data handling and people. Get management approval and start employee acknowledgments (CC5.3).
Output: risk register, approved policies, acknowledgment tracker.
Weeks 5 and 6: implement the controls
Turn policy statements into settings. Enforce MFA and single sign-on, set up role-based access and start an access review (CC6.1 to CC6.3). Require pull request review and protected branches for change management (CC8.1). Turn on logging and alerting (CC7.2). Set up vulnerability scanning (CC7.1). Begin vendor inventory and tiering (CC9.2). Prepare onboarding and offboarding checklists.
Output: configured systems with exports or dated captures, vendor list.
Week 7: evidence and exceptions
Collect evidence for each control as of your Type 1 date: configuration exports, tickets, approval records, training records. Note gaps and decide which to fix now and which to disclose. Do not backdate anything; evidence must be real.
Output: evidence index by criterion, gap list.
Week 8: readiness review
Run an internal walk through as if you were the auditor. For each control, ask: is it written down, is it implemented, can I show it? Fix what is cheap. Confirm the system description draft, which covers services, infrastructure, software, people, procedures and data, is accurate.
Output: readiness checklist signed by the programme lead.
Weeks 9 and 10: auditor fieldwork and report
The auditor reviews your description and tests the design of controls on the report date. Expect evidence requests, walkthrough calls and questions about gaps. Respond quickly and keep a single owner for requests. Review the draft report for factual errors before it is issued.
Output: final Type 1 report.
Who does what
The sponsor clears blockers and approves policies. The programme lead runs the weekly meeting and owns the evidence index. Engineering owns access, change, logging and scanning settings. HR owns onboarding, offboarding, background checks and training. Finance or operations owns the vendor list. Keeping these roles named from week 1 avoids the common stall where everyone assumes someone else is collecting a screenshot.
What to do
- Set a target report date and work backward.
- Fill in each week's outputs and assign them to named owners.
- Book your auditor early, since their calendar may be the longest lead item.
- Review progress in a weekly 30 minute meeting.
- Decide now whether you will go on to Type 2, so controls you build can be operated and evidenced for a period.
Quick check
Is ten weeks realistic?
It can be for a small company with few systems and decisive owners. It is a template, not a promise, so scale it to your situation.
Does a Type 1 prove my controls work over time?
No. It addresses design at a point in time and has no opinion on operating effectiveness. Type 2 adds tests over a period.
How Safeguard helps automate this
Weeks 5 to 7 usually eat the schedule because evidence is gathered by hand. 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 keeps running after the report so the same evidence supports a Type 2. That saves your team time for other work. Technical evidence 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 what runs automatically. Safeguard does not replace the auditor or guarantee a report. Book a call.
Sources
- AICPA, Trust Services Criteria (2017, with 2022 points of focus): definitions of Type 1 and Type 2 engagements and the criteria IDs cited. Paraphrased.
Last reviewed: 18 October 2026.
