A SOC 2 Type 1 report gives an auditor's opinion on whether your controls were suitably designed at a single point in time. Unlike Type 2, it carries no opinion on whether they operated effectively over a period. Read it for opinion type, scope, system description, criteria coverage, exceptions and the date.
What do Type 1 and Type 2 mean?
The AICPA's Trust Services Criteria text says a Type 2 engagement includes an opinion on operating effectiveness and the auditor's tests and results. A Type 1 addresses the same subject matter but contains no opinion on operating effectiveness. In plain terms, Type 1 says the controls were designed and in place on the date. Type 2 says they worked across the period. Buyers know this, so be ready to say so.
What sections will you see?
Reports usually have four main parts, though layouts vary.
1. The auditor's report. The opinion. Read the opinion type first. An unmodified opinion says the description is fairly presented and the controls were suitably designed as of the date. A modified one signals a problem, and the reasons follow. Note the date, the audit firm, and which categories are covered.
2. Management's assertion. Your leadership states that the description is fair and the controls suitably designed. Someone senior signs it, so check the right person has read it.
3. The system description. Services, infrastructure, software, people, data and processes in scope, the principal service commitments, and the boundary. It also lists complementary user entity controls that customers must run themselves, and subservice organisations you rely on, such as a cloud host. Check whether those subservice providers are carved out or included.
4. Criteria and controls. A table of Trust Services Criteria, such as the CC series for security, with your control descriptions mapped to each. Type 1 shows control design here without test results of operating effectiveness. Look for criteria marked not applicable and see whether the reason makes sense.
Which red flags matter?
A qualified opinion or exceptions in design. A scope that excludes the product the customer actually uses. Vague control descriptions such as "access is reviewed periodically" with no owner or frequency. A long list of subservice organisations with no mention of their own reports. A report dated many months ago.
How should you use it with customers?
Say plainly that it is a Type 1 and when the Type 2 period is planned. Offer the system description and answer security questions with references to the report. Do not describe it as certification. SOC 2 reports are attestations by an independent CPA firm, not certificates.
How do you read someone else's report?
As a buyer, check that the services you use are in scope, that the date is recent, that the categories you need are covered (security always, plus availability or confidentiality if relevant), and that your own responsibilities in the user control list are things you actually do. Map subservice organisations to the supply chain you care about, in line with CC9.2 on vendor risk.
What should you ask your auditor before you sign off?
Ask how they describe the boundary and whether any in scope system is missing. Ask which control descriptions are likely to draw questions in a Type 2, since a description that is fine for design can fail once tested over time. Ask whether any criteria are marked not applicable and what reasoning the report gives. And ask for a draft of the system description early enough to correct factual errors, because management signs the assertion that it is fair.
Finally, keep a short list of every change you make between the report date and the start of the Type 2 period. Customers and the next auditor will want to know what moved.
What to do
- Read the opinion type and date first.
- Check scope against the services in use.
- Read the system description and the boundary.
- List complementary user entity controls and assign owners.
- Check subservice organisations and whether they are carved out.
- Scan the criteria table for gaps and weak descriptions.
- Write a one paragraph customer summary and a Type 2 timeline.
Quick check
Does a Type 1 prove controls worked?
No. It addresses design at a point in time and contains no opinion on operating effectiveness. A Type 2 covers a period and includes tests of operating effectiveness.
Is SOC 2 a certification?
No. It is an independent auditor's attestation report on controls against the Trust Services Criteria.
How Safeguard helps automate this
A Type 1 shows design, and customers will next ask whether the controls keep working. 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, which helps you start the Type 2 trail. Technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability. Questionnaires can be answered from the same evidence. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically. The report itself comes from your independent auditor.
Try the framework mapping demo full screen.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022), Type 1 and Type 2 engagement description; criterion CC9.2
Last reviewed: 18 October 2026.
