SOC 2 Type II Readiness: What Auditors Actually Test

Key takeaways

SOC 2 reports are issued by licensed CPA firms against the AICPA Trust Services Criteria.
Security is mandatory; Availability, Processing Integrity, Confidentiality and Privacy are optional.
A Type II report tests whether controls operated effectively across a period — commonly three to twelve months.
Most exceptions come from operational discipline, not missing technology.

What a SOC 2 report is — and is not

A SOC 2 report is an independent attestation, issued by a licensed CPA firm, on the controls a service organisation uses to protect its customers' data. It is written for your customers and their auditors, and it is governed by standards set by the American Institute of Certified Public Accountants (AICPA).

SOC 2 is not a certification and there is no pass mark. The auditor issues an opinion and lists any exceptions found during testing. A report with a handful of well-explained exceptions is normal; a report with exceptions in core areas such as access control or change management will raise difficult questions from customers.

Type I or Type II?

	Type I	Type II
What is assessed	Whether controls are suitably designed at a single point in time	Whether controls are suitably designed and operated effectively over a period
Period	A specific date	Typically 3 to 12 months; 6 and 12 are most common
Evidence	Policies, configurations, walkthroughs	Samples of records across the whole period
Customer value	A useful first step	What most enterprise buyers actually ask for

Many organisations issue a Type I first to unblock sales, then move to Type II. That is sensible — provided the Type II observation period starts as soon as controls are genuinely operating, not after the Type I report lands.

The Trust Services Criteria

The Security criteria — often called the Common Criteria — are mandatory for every SOC 2 report. The other four categories are included when they matter to your customers:

Availability — for services where uptime commitments are part of the contract.
Processing Integrity — where completeness and accuracy of processing is the product, such as payments or payroll.
Confidentiality — where you hold customers' confidential business information.
Privacy — where you process personal information and make privacy commitments to individuals.

Adding categories your customers do not need increases audit cost and exception risk without adding commercial value. Scope to what your contracts actually promise.

What auditors test: the ten areas to get right

During a Type II audit the auditor selects samples from the observation period and asks you to prove each control operated. These are the areas where first-time audits most often produce exceptions:

Onboarding — background checks, signed policies and security training completed before or shortly after access is granted.
Offboarding — access removed promptly when someone leaves. Auditors compare HR leaver dates with account disable dates.
Access reviews — periodic reviews of who has access to production systems, with recorded decisions and follow-up.
Change management — code and infrastructure changes approved, tested and deployed through a controlled process, with separation of duties.
Vulnerability management — scans run on schedule and findings remediated within your defined timelines.
Incident response — a documented plan, tested at least annually, with records of real incidents handled.
Risk assessment — performed at least annually and updated when the business or threat landscape changes.
Vendor management — critical suppliers identified, assessed and reviewed, including their own SOC reports.
Backup and recovery — backups running and, crucially, restores tested.
Monitoring and logging — security events collected, alerts reviewed and responses recorded.

Subservice organisations and complementary controls

Almost every SaaS company relies on a cloud provider. Your report must explain how you treat these subservice organisations — usually the carve-out method, where the provider's controls are excluded from your report and your customers rely on the provider's own SOC report.

Your report will also list complementary user entity controls: things your customers must do for the overall control environment to work, such as managing their own users. Write these carefully; vague or unreasonable expectations become questions in every customer review.

A preparation plan that avoids over-engineering

Run a readiness assessment against the criteria you have chosen and fix design gaps first.
Write policies that describe what you actually do. Auditors test against your own documents.
Automate evidence where possible — identity, cloud configuration and ticketing systems can export most of what auditors need.
Hold a dry run: pick a few random samples per control and check the evidence exists.
Agree the observation period with your auditor and do not change processes mid-period without documenting it.
Plan for continuity: a bridge letter covers the gap between one report's period end and the next report.

Frequently asked questions

How long does it take to get a SOC 2 Type II report?

Allow two to three months of readiness work, an observation period of at least three months, and several weeks for fieldwork and report issue. Six to nine months from a standing start is typical.

Can any auditor issue a SOC 2 report?

No. SOC 2 reports must be issued by a licensed CPA firm. Readiness and advisory support can be provided by others, but the attestation itself cannot.

Do we need SOC 2 if we already have ISO 27001?

Often, yes — particularly if you sell to North American customers who specifically request SOC 2. The control sets overlap substantially, so a unified control library lets you evidence both efficiently.