Jump to a page

32 pages.

All servicesAssessments, testing, and advisory work for security and compliance programs.
PCI DSS readinessScoping, readiness, and remediation for card-payment environments
Penetration testingAuthorized testing of apps, APIs, and networks
Compliance readinessSOC 2, ISO/IEC 27001, HIPAA, and CMMC readiness
Cloud & application securityArchitecture, configuration, and identity reviews
vCISO advisorySecurity leadership without a full-time hire
Incident readinessResponse plans and tabletop exercises
Risk assessmentsWhere you stand against NIST CSF 2.0 and CIS Controls
Policies, controls & evidenceA security program you can repeat and prove
Vendor riskThird-party reviews with clear priorities
Find the right service
SOC 2 readiness
ISO/IEC 27001 readiness
HIPAA Security Rule readiness
CMMC readiness
Assurance and trust centerHow to check credentials, how engagements run, how we stay independent, and how this website handles your data.
Credentials & authorizationsHow credentials and authorizations work, and how to check them
MethodologyHow engagements are scoped, run, and reported
IndependenceHow advisory work stays separate from formal assessment
Responsible disclosureHow to report a security issue in our website or systems
About
Team
Industries
Pricing
Contact
InsightsPlain-language articles on security and compliance topics
GlossarySecurity and compliance terms, defined in plain language
Search the siteServices, readiness guides, glossary terms, and articles
Privacy notice
Terms of use
Accessibility
Privacy choices

Guide

SOC 2 Type 1 vs Type 2: which report do you need?

SOC 2 Type 1 vs Type 2 comes down to time and depth. A Type 1 report covers your system description and whether your controls are suitably designed as of one date. A Type 2 report adds whether those controls operated effectively throughout a period, so it takes longer to earn and tells customers more. Ask your customers which one they need before you plan the work.

Compliance10 min read

By Security Inspect · Sources checked

Key takeaways

  • Both report types come from a SOC 2 examination performed by a CPA, called the service auditor, under the AICPA attestation standards. Neither one is a certification.
  • A SOC 2 Type 1 report covers the system description and the suitability of control design as of a specified date.
  • A SOC 2 Type 2 report adds the operating effectiveness of controls throughout a specified period, along with the service auditor's tests of controls and their results.
  • The AICPA description criteria set no minimum Type 2 period and no expiry date. The period is agreed with the CPA firm, and customers decide how recent a report must be.
  • Describe the result precisely: the report type, the date or period it covers, and the CPA firm that issued it.

The short answer: SOC 2 Type 1 vs Type 2

The AICPA's SOC 2 description criteria define two types of SOC 2 examination. In a Type 1 examination, the subject matters are the description of your system and the suitability of the design of your controls to meet your service commitments and system requirements, based on the applicable Trust Services Criteria. A Type 2 examination covers both of those and adds a third: whether the controls operated effectively.

Time is the practical difference. A Type 1 speaks to a single date. A Type 2 speaks to a period, so the CPA firm has to test how your controls actually ran across that period, not only how they were designed. You'll also see them written as Type I and Type II; they're the same two reports.

In both cases the report comes from a CPA, known as the service auditor, performing an examination under the AICPA attestation standards (AT-C sections 105 and 205). A readiness advisor can help you prepare, but the examination and the report belong to a licensed CPA firm.

Type 1 and Type 2 side by side

The table below compares the two report types using the AICPA's own definitions. Everything not listed is shared: the same Trust Services Criteria, the same description criteria and the same kind of CPA firm.

SOC 2 Type 1 and Type 2 reports compared
QuestionType 1 reportType 2 report
What the service auditor gives an opinion onThe system description and the suitability of control designThe system description, the suitability of control design, and the operating effectiveness of controls
Time frameAs of a specified dateThroughout a specified period
Tests of operating effectivenessNot part of the examinationIncluded, with the tests performed and their results
Significant changes disclosedNot applicable to a single dateRelevant changes to the system and controls during the period
What a customer learnsWhether controls were designed to meet your commitments on that dateWhether controls were designed and operated as described over time, and what the tests found

How the SOC 2 review period is set for a Type 2

The AICPA description criteria describe a Type 2 description as one that covers a period of time, but they don't prescribe how long that period must be. You agree the period with the CPA firm when you engage it, and your customers' expectations should drive the choice.

Ask your largest customers, or read their security questionnaires and contract language, before you pick a period. Some state a period they accept. If they don't, the CPA firm can explain the trade-off: a longer period gives customers more evidence of consistent operation, while a shorter first period gets a report into their hands sooner.

Controls have to operate across the whole period to be tested, so the period should start only once they're actually running. Starting the clock before a control exists leaves a gap the service auditor may report.

Significant changes during the period

Because a Type 2 description covers a period, the description criteria (DC9) call for the relevant details of significant changes to the system and controls during that period. The AICPA's implementation guidance gives examples: changes to the services provided, significant changes to IT and security personnel, changes to system processes, IT architecture and applications (including those used by subservice organizations), changes to legal and regulatory requirements that could affect system requirements, and organizational changes such as a change to the legal entity.

Plan large migrations with this in mind. A change in the middle of the period isn't a problem in itself, but it has to be described, and the controls on both sides of the change may need evidence.

Which one your customers need

Start with the request, not the report. A customer who asks for a SOC 2 report may accept either type, may accept only a Type 2, or may accept a Type 1 now with a Type 2 to follow. Their security questionnaire, master services agreement or vendor policy often says which.

Check scope at the same time: which Trust Services Criteria categories they expect to see, and which of your services and systems they rely on. A report that covers the wrong system won't answer their question, whatever its type.

Going straight to Type 2

Going straight to a Type 2 makes sense when your controls already run consistently, you can produce evidence for each one, and your customers can wait for the period to end and the report to be written. Signs you're ready:

  • Controls have named owners and run on a schedule, not only when someone asks.
  • Evidence such as tickets, logs, access reviews and approvals is kept where it can be retrieved.
  • Customers have said a Type 1 won't satisfy them.
  • The system in scope is stable enough that no major redesign is planned during the period.

Starting with Type 1

A Type 1 can help when a customer needs a report soon, when controls are newly designed, or when you want an independent view of design before committing to a period. It shows design as of one date, so it doesn't tell customers how controls ran over time.

If your customers expect a Type 2 eventually, treat the Type 1 as a step toward it and plan for both engagements from the start.

Readiness for each type

Readiness work is similar for both types, with a difference in emphasis. For a Type 1, the focus is a complete, accurate system description and controls that are suitably designed as of the date. For a Type 2, the focus shifts to running those controls consistently and keeping evidence throughout the period.

A practical sequence that works for either type:

  • Define the system boundary: the infrastructure, software, people, procedures and data used to provide the service.
  • Choose the Trust Services Criteria categories that match your service commitments.
  • Write the system description, which management owns and presents in the report.
  • Close design gaps against the applicable criteria before the date or period begins.
  • For a Type 2, set up evidence routines so each control leaves a record every time it runs.
  • Identify subservice organizations and any controls your customers need to operate for the system to work as described.

What both reports contain

A SOC 2 report packages several parts. The AICPA description criteria note that management's assertion, the system description and the service auditor's opinion are all included. The Trust Services Criteria add that a Type 2 report also includes a detailed description of the service auditor's tests of controls and the results of those tests, which a Type 1 report doesn't contain.

  • The service auditor's report, which contains the CPA firm's opinion.
  • Management's assertion about the description and the controls.
  • The system description, prepared by management using the AICPA description criteria.
  • In a Type 2, a description of the tests of controls the service auditor performed and the results.

Complementary user entity controls and subservice organizations

Two parts of the description deserve a careful read. Complementary user entity controls are controls that management assumed, in designing the system, would be implemented by user entities, and that are needed alongside the service organization's own controls. If your controls only work when customers do their part, the description has to say what that part is.

If you rely on a subservice organization, such as a hosting provider, and its controls are needed to meet your commitments, the description uses one of two methods. The inclusive method brings the relevant parts of that organization into the description and the examination. The carve-out method excludes them but still identifies the nature of its services, the types of controls expected of it, and the controls you use to monitor it.

SOC 2 reports are also restricted-use. The service auditor's report ordinarily includes an alert that limits use to specified parties who understand the system well enough to read it, such as customers and prospective customers.

How to describe your SOC 2 report accurately

Name the report type, the date or period it covers, the Trust Services Criteria categories in scope, and the CPA firm that issued it. For example: a SOC 2 Type 2 report on the security category, issued by a named CPA firm, for a stated period.

Avoid calling it a certification. SOC 2 is an attestation report issued by a licensed CPA firm. There's no SOC 2 certificate, and the report is about a system and its controls, not a badge for the company or its people.

Be precise about scope. A report covers the system and categories named in it, for the date or period it states. If a customer asks about a product, location or service outside that boundary, say so plainly rather than stretching the report to fit.

Where our work fits

  • SOC 2 readiness — preparation for an examination performed by an independent licensed CPA firm.
  • Security Inspect is not a law firm, a CPA firm, or an ISO/IEC 27001 certification body. We don't give legal opinions, issue SOC 2 reports or ISO/IEC 27001 certificates, or guarantee that a client will pass an assessment.
  • When a program requires a formal assessment, audit, or certification, it's performed by an independent, authorized assessor. We keep advisory work and formal assessment apart: a practitioner never assesses controls they designed, developed, or implemented.

Questions

Is a SOC 2 Type 2 report better than a Type 1?

Neither is better in the abstract; they answer different questions. A Type 2 tells customers more because it adds tested operating effectiveness over a period, which is why customers who need evidence of consistent operation ask for it. A Type 1 answers a narrower question sooner. The right report is the one your customers will accept.

Can we share a Type 1 report while our Type 2 period runs?

Yes, as long as the recipient is among the specified parties the report allows. A Type 1 shows design as of its date, so tell customers when the Type 2 period started and when to expect the report, and don't describe the Type 1 as evidence of how controls operated over time.

How long is a SOC 2 report valid?

The AICPA description criteria don't set an expiry date for a SOC 2 report. Each customer decides how recent a report must be, and the date or period end the report covers is what shows how current it is. Check your contracts and questionnaires for the recency they expect, and plan recurring Type 2 periods to match.

Does a Type 1 examination need evidence?

Yes. A Type 1 is still an examination under the AICPA attestation standards, so the service auditor needs evidence that the description is accurate and that the controls are suitably designed as of the date. Expect requests for documents and explanations of how each control works, even though operation over a period isn't tested.

Primary sources

Related guides

Terms in this guide

More on this site

Information on this website is general and educational. It isn't legal advice, and it doesn't create a client relationship.

Talk through your situation with a practitioner

Every engagement begins with a written scope and proposal.

Security Inspect is not a law firm or a CPA firm and does not provide legal opinions or issue SOC 2 reports. ISO/IEC 27001 certification is performed independently by an accredited certification body. CMMC organization-level assessment authority depends on an active C3PAO listing. Specific PCI services depend on the company’s active PCI SSC program listing and scope.