To scope a SOC 2 Type 1, define the system you provide to customers, choose which trust services categories to include (Security is always in), draw the boundary around the people, software, infrastructure, procedures and data that run it, and decide how you describe vendors. Keep scope tight, but match what customers ask for.
A Type 1 report describes the design of your controls at a point in time. Per the AICPA text, it contains no opinion on operating effectiveness and no detailed tests of controls, which are features of Type 2. Scope still matters, because it carries forward into your Type 2.
What is the system?
The AICPA defines a system as the infrastructure, software, procedures and data, designed, implemented and operated by people to achieve business objectives. System boundaries are the specific aspects of those five components needed to provide a service. If two services share parts, the systems overlap but the boundaries differ.
In practice, scope one product or service that your customers rely on, not the whole company. A SaaS product with a production environment, its source repositories, deployment pipeline, support tooling and the staff who operate them is a typical boundary.
Which categories should you include?
The criteria cover five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is the baseline set of common criteria, labeled CC1 through CC9. Others add criteria: A1 for availability, C1 for confidentiality, PI1 for processing integrity and the P series for privacy.
A sensible starting rule:
- Security: always.
- Availability: add it if customers have uptime commitments in contracts or your product is operationally critical to them.
- Confidentiality: add it if you hold customer data under confidentiality terms, which is common in B2B.
- Processing Integrity: add it if accuracy of calculation or transaction processing is the product.
- Privacy: add it if you handle personal information as a main function.
Each added category adds criteria the auditor will test or evaluate, so more categories mean more controls to document. Ask your buyers which categories they actually read for before you add any.
How do you draw the boundary?
Walk the lifecycle of customer data and code:
- Where does customer data enter, live and leave?
- Which cloud accounts, regions and databases hold it?
- Which repositories and pipelines build and deploy the product?
- Which employees and contractors can touch production or customer data?
- Which corporate systems (identity provider, endpoint management, ticketing, HR) support those controls?
Everything on those lists is in the boundary. A staging environment with real customer data is in. A marketing website with no customer data usually is not, but write down why.
How do you treat vendors?
Your cloud host and other service providers sit partly outside your control. Your system description must say which vendors you rely on and which of their controls you expect, and the criteria (CC9.2) require you to assess and manage vendor and business partner risk. Ask your auditor how they want vendor reliance presented, since the AICPA text we read does not prescribe a layout.
What to do
- Name the one service you are scoping and write a one-paragraph description in plain language.
- Choose categories from customer requests, not from a wish for completeness.
- List the components in each of the five parts: infrastructure, software, people, procedures, data.
- Build a vendor list with the data each vendor touches and whether you hold their audit report.
- Write out of scope items and the reason, so nobody discovers them later.
- Share the scope draft with your auditor before you start control work.
Quick check
Is Security the only mandatory category?
Yes. Security (the common criteria) is required in every SOC 2. The other four are optional and chosen based on your commitments and customer needs.
Can I change scope between Type 1 and Type 2?
You can, but expect extra work. Anything you add for Type 2 has not been evaluated before, and removing items may raise questions from customers. Aim to scope Type 1 the way you want Type 2.
How Safeguard helps automate this
Once scope is set, the work is mapping each in-scope system to controls and keeping evidence current. 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 between audits. That frees the team to focus on other work. Technical evidence comes from your real code and dependencies, including scans, SBOMs and reachability. Safeguard helps you prepare and keep evidence ready, while the independent auditor decides whether you pass. Autonomous fix pull requests are off by default and each category starts on Manual. Book a call or try the demo below.
Open the framework mapping demo
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022): scope glossary, report type description, CC9.2 and category criteria, read from a local copy on 18 October 2026
Last reviewed: 18 October 2026.
