SOC 2 Type I vs. Type II: Which Do You Need?

If a customer has asked for your SOC 2 report, the first decision is which type to pursue. A Type I report tells readers whether your controls were suitably designed as of a single date. A Type II report tells them whether those controls actually operated effectively over a period of time, commonly somewhere between three and twelve months.

Most enterprise customers ultimately want a Type II. A Type I is useful as a first step when you need something in hand quickly or your controls are too new to have a track record.

What is a SOC 2 report?

A SOC 2 report is an attestation report issued by an independent CPA firm under AICPA standards. It describes a service organization's system and gives the auditor's opinion on the controls that protect it. Readers are customers, prospects and their auditors who need to understand how you handle systems and data on their behalf.

SOC 2 is not a certification, and there is no pass mark. The auditor issues an opinion, and each reader decides whether the report gives them enough comfort. It is also a restricted-use report, so most organizations share it under a nondisclosure agreement rather than posting it publicly.

A typical report contains:

• The independent auditor's opinion
• Management's written assertion
• A description of the system in scope
• The controls, mapped to the applicable criteria
• For a Type II only, the tests the auditor performed and the results, including any exceptions

What are the Trust Services Criteria?

SOC 2 examinations are performed against the AICPA's 2017 Trust Services Criteria (TSC). The criteria are grouped into five categories:

1. Security (required in every SOC 2)
2. Availability
3. Processing Integrity
4. Confidentiality
5. Privacy

The security criteria are known as the common criteria, numbered CC1 through CC9. They are "common" because they apply to every SOC 2 and support the other categories. They cover the control environment, communication and information, risk assessment, monitoring, control activities, logical and physical access, system operations, change management and risk mitigation, which includes managing vendors and business partners.

The other four categories are optional. Add one when it matches a commitment you actually make to customers:

• Availability if you offer uptime commitments or service level agreements
• Confidentiality if contracts require you to protect customer confidential information
• Processing Integrity if customers rely on your processing being complete, accurate and timely, as with billing or payroll calculations
• Privacy if you collect, use and retain personal information directly from individuals

Each added category brings more controls, more evidence and more audit work. Start with Security and add others only where customers need them.

The criteria also include points of focus, which describe characteristics a criterion typically addresses. They are guidance to help you design and assess controls, not a list of items that must each be satisfied.

What is the difference between SOC 2 Type I and Type II?

Both reports use the same criteria and the same system description. The difference is what the auditor tests and over what timeframe.

A Type I report is "as of" a specific date. The auditor evaluates whether the system description is fairly presented and whether the controls are suitably designed to meet the criteria. They confirm each control has been put in place, usually through walkthroughs, inspection and inquiry, but they do not test whether it kept working over time.

A Type II report covers a period. It includes everything in a Type I, plus testing of whether the controls operated effectively throughout that period. The auditor samples activity from across the window. For example, they might pick a sample of new hires and confirm access was approved, pick a sample of production changes and confirm each was reviewed and tested, and check that a quarterly access review happened every quarter.

When does a Type I make sense?

A Type I is a reasonable choice in a few situations:

• You have a deal waiting. A prospect needs something now, and your controls have only recently been implemented.
• Your controls have no operating history. You can't show a period of evidence for controls that started last month.
• You want an early signal. A Type I tells you whether the auditor agrees your control design meets the criteria before you commit to a full observation period.

Be realistic about how readers will treat it. Many vendor risk teams accept a Type I as an interim step and will ask when your Type II is coming. The practical move is to start your Type II period on or right after the Type I date, so you have a clear answer.

When should you go straight to a Type II?

Skip the Type I when customers have told you they require a Type II, or when your controls have already been running long enough to produce evidence. Doing two engagements back to back adds preparation and audit effort that you may not need.

If time pressure is the concern, consider a shorter first Type II period, such as three months. That gets a Type II into customers' hands sooner. In following years you can move to a twelve-month period that begins where the previous one ended, so your coverage has no gaps.

How long is a Type II audit period?

There is no single required length. Periods commonly run from three to twelve months. First-year reports often use a shorter window, while established programs usually settle on twelve months. The period dates appear in the report, and readers will judge for themselves whether the coverage is enough.

What is a SOC 2 readiness assessment?

A readiness assessment is a gap analysis performed before the audit. It compares your current controls against the criteria you've selected and identifies what is missing, poorly documented or not operating as described.

It is not an attestation. There is no opinion, and it won't satisfy a customer asking for a SOC 2 report. Its value is in reducing surprises during the real examination. If your audit firm performs the readiness work, independence rules limit how far it can go in designing or running your controls.

A good readiness effort covers:

1. Define the system boundary: services, infrastructure, software, people, data and procedures.
2. Select the TSC categories that match your customer commitments.
3. Identify subservice organizations, such as your cloud hosting provider, and collect their SOC reports.
4. Map existing controls to the criteria and list the gaps.
5. Check that practice matches policy. A written access review procedure means little if reviews aren't happening.
6. Assign control owners and decide how evidence will be captured.
7. Close the gaps and let controls run before your Type II period begins.

What is a bridge letter?

A SOC 2 report covers a period that ends on a specific date. Customers who review your report months later want to know nothing significant has changed since then. A bridge letter, sometimes called a gap letter, fills that window.

The letter is written by your management, not by the auditor. It typically states that there have been no material changes to the system or controls since the end of the last report period, and it covers the time until your next report is issued. Bridge letters usually span no more than a few months.

Because it is management's own statement, a bridge letter carries less weight than an audited report. It works best as a short-term supplement to a regular annual cycle, not a substitute for one.

How do SOC 1, SOC 2 and SOC 3 differ?

The AICPA's SOC suite includes three reports that are easy to mix up.

A payroll processor often needs a SOC 1 because its work feeds directly into customers' financial statements. A SaaS provider hosting customer data usually needs a SOC 2. Some organizations need both.

A SOC 3 is commonly produced alongside a SOC 2 Type II and posted publicly. It helps early in a sales conversation, but security reviewers will still ask for the SOC 2.

Frequently asked questions

Can we fail a SOC 2 audit?

Not in a pass-or-fail sense. The auditor issues an opinion, which may be unmodified or, where problems are significant, qualified or adverse. In a Type II, individual test exceptions are listed in the report. Exceptions don't automatically lead to a modified opinion, but readers will see them and may ask how you addressed them.

How often do we need a new SOC 2 report?

Most organizations renew annually with consecutive Type II periods. Customers generally expect a recent report, and many treat one as stale once its period ended more than a year ago. Bridge letters cover the short gaps between reports.

Does our SOC 2 cover our cloud provider's controls?

Usually not. Most organizations use the carve-out method, which excludes the provider's controls from your report and lists the controls you expect the provider to operate. Your customers then review the provider's own SOC report. Your report will usually also list complementary user entity controls, which are the controls your customers must run on their side, such as managing their own user accounts.

Next steps

• Ask what customers actually require. Confirm whether they will accept a Type I or need a Type II, and which TSC categories matter to them.
• Scope carefully. Choose categories that match your commitments, not every category available.
• Run a readiness assessment and close gaps before the auditor arrives.
• Set your Type II start date and make sure evidence is captured from day one.
• Plan the annual cycle. Consecutive report periods and short bridge letters keep customers covered without last-minute requests.