What Is SOC 2 Type II? How Cloud Vendors Should Prepare

What SOC 2 Type II Actually Means and Why It Is Not a Certification

SOC 2 Type II is an auditor’s report, not a certification, not a badge and not a standard an organisation passes or fails in the conventional sense.

It is an opinion issued by a licensed CPA firm on whether a service organisation’s controls were suitably designed and operated effectively over an observation period, typically six to twelve months.

The framework is maintained by the American Institute of Certified Public Accountants and evaluated against the Trust Services Criteria.

The distinction between Type I and Type II matters in practice. A SOC 2 Type I report covers a single point in time. It assesses whether controls are designed appropriately as of the report date.

A SOC 2 Type II report covers how those controls operated throughout the observation period. Enterprise procurement teams and security-conscious customers often request Type II because it provides stronger evidence of control operation over time. A Type I report tells them little about whether a vendor’s controls actually work day to day.

Cloud vendors entering enterprise sales cycles for the first time often discover the SOC 2 requirement when they lose a deal to it.

The preparation timeline makes a reactive approach costly. A Type II audit cannot begin until controls are in place and the observation period starts, which means the earliest a vendor can have a report in hand is typically nine to fifteen months after beginning the process. For a broader comparison of how HIPAA, PCI DSS and SOC 2 differ in cloud environments, read HIPAA, PCI DSS and SOC 2: Key Differences for Cloud Teams.

What Are the Trust Services Criteria and Which Should You Include?

The Trust Services Criteria are the framework against which a SOC 2 audit is conducted. There are five criteria: Security, Availability, Processing Integrity, Confidentiality and Privacy.

Security, also called the Common Criteria, is mandatory in every SOC 2 audit. The remaining four are selected based on what is relevant to the service the organisation provides and the commitments it makes to customers.

Security covers the controls that protect the system against unauthorised access, both logical and physical.

Availability covers whether the system is available for operation as committed.

Processing Integrity covers whether system processing is complete, accurate and authorised.

Confidentiality covers whether information designated as confidential is protected accordingly.

Privacy covers whether personal information is collected, used, retained and disclosed in accordance with stated commitments.

For most cloud infrastructure and SaaS vendors, Security and Availability are the baseline. Confidentiality is typically added when the vendor processes sensitive client data.

Privacy is added when the service involves the collection and handling of personal information in ways that create direct obligations to data subjects.

Adding criteria beyond what is genuinely relevant to the service does not strengthen a report. It expands audit scope and increases the likelihood of exceptions in areas the organisation has not prioritised.

What Does an Auditor Actually Evaluate?

The auditor’s job is to evaluate whether the controls an organisation has placed in operation address the relevant Trust Services Criteria, and whether those controls operated effectively throughout the observation period.

That evaluation involves document review, interviews with personnel and testing of controls.

The auditor checks whether access reviews happened on schedule, whether change management tickets were raised and approved for system changes, and whether vulnerability scans were conducted and results acted upon.

The auditor issues one of two opinions.

An unqualified opinion, sometimes called a clean report, means the auditor found no material weaknesses and is satisfied that controls were suitably designed and operated effectively.

A qualified opinion means exceptions were identified. These may include controls that did not operate as described, gaps in evidence, or periods during the observation window where a control was not functioning.

Those exceptions are documented in the report and are visible to anyone who reads it.

This is the detail that matters most when evaluating a vendor’s SOC 2 report. The overall opinion is relevant. The exceptions section is often more informative.

A report with an unqualified opinion but a long exceptions section tells a different story from a clean report with no material findings.

What Controls Must Be in Place Before the Observation Period Starts?

The observation period is the window of time the auditor reviews. It cannot begin until controls are actually operating.

This is the point most organisations underestimate when planning their first SOC 2 audit.

Controls must be defined in policy, implemented in practice and generating evidence before the clock starts.

Access reviews need to be scheduled and completed. Change management processes need to be in use for every system change. Vulnerability scanning needs to be running on schedule.

Incident response procedures need to be documented and tested. Security awareness training needs to have been completed by relevant staff.

If any of these controls are put in place after the observation period has already begun, the auditor’s review will identify the gap. This may appear through missing evidence or through a period where the control was not yet operating.

The practical implication is that organisations should plan for three to six months of control operation before engaging an auditor to begin the formal observation period.

Turning SOC 2 Preparation Into Practical Action

Understanding SOC 2 Type II requirements is one step, but preparing controls, evidence and audit-ready processes before the observation period starts requires structured planning.

The Cloud Compliance Basics HIPAA PCI SOC2 In The Cloud course helps cloud and security teams understand SOC 2 audit preparation, evidence collection and control operation in practical terms.

How Cloud Vendors Should Structure SOC 2 Preparation

The most common mistake cloud vendors make when approaching their first SOC 2 audit is treating it as a documentation exercise, writing policies to satisfy a checklist without building the operational habits that produce evidence over time.

An auditor reviewing a twelve-month observation period will see through a programme assembled in the final weeks before fieldwork begins.

Preparation falls into three phases.

The first is a readiness assessment, a gap analysis of current controls against the selected Trust Services Criteria.

This identifies which controls exist and are generating evidence, which exist in policy but are not consistently followed, and which are absent entirely.

The readiness assessment output should be a prioritised remediation list, not a confidence score.

The second phase is remediation and control operation. Every gap identified in the readiness assessment needs to be addressed before the observation period begins.

This is not just implementing a tool or writing a policy. It means operating the control consistently, logging the activity and confirming that evidence is being captured in a format the auditor can review.

For access reviews, that means reviewing access lists on schedule and documenting who conducted the review, what was found and what action was taken.

For change management, that means raising and approving tickets for every system change, not retrospectively and not selectively.

The third phase is the audit itself. This involves engaging an accredited CPA firm, agreeing the scope and observation period, completing auditor fieldwork and receiving the report.

The auditor will request a sample of evidence from throughout the observation period, not just the most recent examples. Evidence from month one of a twelve-month period needs to be as complete as evidence from month twelve.

What Common Exceptions Appear in SOC 2 Type II Reports?

Exceptions in SOC 2 reports tend to cluster around the same control areas regardless of the organisation’s size or the sophistication of its security programme.

Understanding where exceptions are most likely helps teams prioritise during preparation.

Reducing SOC 2 Audit Exceptions

Many cloud vendors have security controls in place but still struggle to prove that those controls operated consistently throughout the observation period.

The Cloud Compliance Basics HIPAA PCI SOC2 In The Cloud course helps teams understand how evidence, ownership and control operation affect SOC 2 audit outcomes.

Access Review Exceptions

Access review exceptions are the most frequent.

These occur when an organisation’s policy requires quarterly access reviews but evidence shows they were conducted once, or when reviews were completed but the documentation does not demonstrate that inappropriate access was actually removed.

Auditors look for the full cycle: review conducted, findings documented, remediation completed and access confirmed as updated.

Vendor Management Exceptions

Vendor management exceptions appear when organisations have a policy requiring annual security reviews of critical vendors but cannot produce evidence of those reviews having taken place.

In cloud environments, where third-party integrations are common and the vendor list changes frequently, this gap is particularly easy to accumulate.

Change Management Exceptions

Change management exceptions occur when system changes, including configuration changes to cloud infrastructure, were implemented without going through the documented change management process.

In cloud environments using infrastructure-as-code and CI/CD pipelines, the change management controls need to be integrated into the deployment process, not added separately afterwards.

Security Training Exceptions

Security training exceptions occur when training completion records are incomplete.

This may include staff who should have completed training within the observation period but have no record of doing so, or training content that does not align with what the policy describes.

What to Look For When Reviewing a Vendor’s SOC 2 Report

Receiving a SOC 2 Type II report from a vendor is only useful if the recipient knows how to evaluate it.

The AICPA’s guidance on SOC report evaluation provides a framework for this, but in practice, the review comes down to four things.

First, check the observation period. A report issued in the current year covering an observation period that ended eighteen months ago is significantly less informative than a current report.

The observation period should be recent enough to be relevant to the vendor relationship you are assessing.

Second, read the scope section. The report will describe exactly which systems, services and locations were included in the audit scope.

If the vendor’s service you are evaluating is not explicitly within scope, the report does not apply to it.

Third, read the exceptions section before the overall opinion. The auditor’s opinion is a summary. The exceptions section contains the substance.

A report with no exceptions and a clean opinion represents a genuinely strong control operation.

A report with multiple exceptions in access management and change control, even with an overall unqualified opinion, tells a more complicated story.

Fourth, check the complementary user entity controls.

SOC 2 reports frequently include a section describing controls that the user organisation, meaning your team, must implement for the vendor’s controls to be effective.

These obligations are your responsibility, not the vendor’s, and they need to be implemented and documented on your side.

If your team is responsible for achieving or maintaining SOC 2 compliance, structured training can reduce the time spent working through audit requirements by trial and error.

The Cloud Compliance Basics HIPAA PCI SOC2 In The Cloud course covers SOC 2 audit preparation for cloud vendors, including Trust Services Criteria selection, evidence collection and how to read and respond to audit findings.

Explore the Course → Cloud Compliance Basics HIPAA PCI SOC2 In The Cloud

Frequently Asked Questions

Is SOC 2 Type II a Certification?

No. SOC 2 Type II is an independent auditor’s report on whether a service organisation’s controls were suitably designed and operated effectively over an observation period.

What Is the Difference Between SOC 2 Type I and Type II?

SOC 2 Type I reviews whether controls are suitably designed at a single point in time. SOC 2 Type II reviews whether those controls operated effectively over a period, usually several months.

What Are the SOC 2 Trust Services Criteria?

The Trust Services Criteria are Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is included in every SOC 2 audit, while the others depend on the service and customer commitments.

Why Do Cloud Vendors Need SOC 2 Type II?

Cloud vendors often need SOC 2 Type II because enterprise customers want evidence that security controls are not only documented, but also operating consistently over time.

Who Should Learn SOC 2 Audit Preparation?

Cloud security teams, SaaS founders, compliance managers, risk teams, DevOps leads and vendor management teams can benefit from understanding SOC 2 audit preparation and evidence collection.