SOC 2 Readiness: What Auditors Actually Ask For

SOC 2 reports have become a standard requirement in enterprise procurement, particularly for software and service providers handling customer data. The terminology causes persistent confusion: there is no such thing as being "SOC 2 certified". SOC 2 is an attestation performed by an independent accounting firm, producing a report that describes controls and the auditor's opinion on them.

Type I versus Type II

A Type I report assesses whether controls are suitably designed at a specific point in time. It is faster to obtain and useful as an interim step, but a knowledgeable buyer recognises it as a snapshot.

A Type II report assesses whether those controls operated effectively across a review period. This is what most enterprise customers actually want, because it demonstrates sustained operation rather than a single well-prepared day. It also means evidence must exist for the whole period — you cannot assemble it retrospectively, which is the single most common cause of a difficult first audit.

The Trust Services Criteria

SOC 2 is built on five Trust Services Criteria, and you choose which apply.

Security — the common criteria, included in every SOC 2 report. For many organisations this alone is sufficient.
Availability — relevant where uptime commitments are part of the service.
Processing integrity — relevant where accurate, complete processing is core to what you do.
Confidentiality — relevant where you handle information subject to confidentiality obligations.
Privacy — relevant where you handle personal information, and the most demanding to add.
Adding criteria increases scope, cost and audit effort, so they should be selected because customers genuinely require them rather than for completeness.

Type II tests operation over time, not design on a date

What auditors actually ask for

Auditors test evidence, not intentions. The requests are consistent and predictable.

Access reviews with dates, reviewers and outcomes — evidence that the review happened, not that a policy says it should.
Onboarding and offboarding records showing access granted and revoked promptly.
Change management records linking changes to approvals and testing.
Vulnerability management evidence, including remediation timelines against your own stated targets.
Incident records and evidence that the response process was followed.
Vendor risk assessments for subservice organisations.
Security awareness training completion records.
Backup and restoration testing evidence where availability is in scope.

Where first-time audits go wrong

Starting evidence collection too late. A Type II period cannot be reconstructed after the fact.
Writing policies that describe an aspiration. If the policy says quarterly access reviews and three happened in a year, that is a finding created by your own document.
Uncontrolled scope. Selecting all five criteria when customers only ever asked for Security.
Manual evidence that nobody sustains. Processes requiring heroic effort tend to lapse mid-period, and the lapse is visible.
Ignoring subservice organisations. Your cloud provider and major SaaS vendors form part of the picture, and auditors will ask how you monitor them.
Treating exceptions as fatal. A qualified report with disclosed, remediated exceptions is normal; concealing issues is far more damaging.

Evidence needs to exist throughout the review period

SOC 2 and ISO 27001 together

These overlap substantially in underlying controls while differing in form: SOC 2 is a report describing controls and testing results, ISO 27001 is a certificate against an international standard. Which one to pursue is usually determined by geography and customer expectation — SOC 2 dominates North American software procurement, while ISO 27001 has broader international recognition.

Organisations selling into both markets frequently end up pursuing both, and the control work overlaps enough that doing them together is more efficient than sequentially.

Related from TechBiz Security

Sources & further reading

Frequently asked questions

Is SOC 2 a certification?

No. SOC 2 is an attestation engagement performed by an independent accounting firm, resulting in a report containing the auditor's opinion. Organisations are not "SOC 2 certified" — they have a SOC 2 report.

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

Type I assesses whether controls are suitably designed at a single point in time. Type II assesses whether they operated effectively across a review period, which requires evidence spanning that entire period and is what most enterprise customers expect.

Which Trust Services Criteria should we include?

Security is always included. The others — availability, processing integrity, confidentiality and privacy — should be added only when genuinely relevant to your service or explicitly required by customers, since each expands scope and cost.

What is the most common reason a first SOC 2 audit is difficult?

Beginning evidence collection too late. A Type II report tests operation throughout the review period, and evidence cannot be created retrospectively, so controls must be running and generating records before the period starts.