SOC 1 vs SOC 2: which report your customers need, and when you need both

SOC 1 vs SOC 2: the short answer

Look at who sent the request and what they will do with the report. If the person asking audits your client's financial statements, or your service processes payroll, claims, loans, fund records or ledgers that end up in those statements, you need SOC 1. If the request comes from a vendor-risk or information security team that wants to know how you keep their data safe and their service running, you need SOC 2.

The two reports share a family name, a format and an examiner, which is why buyers confuse them. Their subjects differ. The AICPA defines SOC 1 as an examination of controls at a service organisation likely to be relevant to user entities' internal control over financial reporting. SOC 2 covers controls relevant to security, availability, processing integrity, confidentiality or privacy. A SOC 2 report will not satisfy a user auditor who needs SOC 1, and the reverse is equally true.

SOC 1 and SOC 2 side by side

How each standard applies in detail sits in the guide SSAE 18 and ISAE 3402: one report, two standards, and the choice of report type in SOC 1 Type 1 or Type 2: choosing the report and the period.

What actually differs in the work

Where the controls come from

A SOC 2 project starts from a fixed framework. Every Security examination addresses the common criteria, from the control environment through logical access, system operations and change management to risk mitigation, and you design controls that meet them. A SOC 1 project starts from your service. Management defines what the controls must achieve for clients' financial reporting, for example that payroll changes are authorised and processed completely, accurately and on time, and the service auditor tests the controls against those objectives. See SOC 1 control objectives: how to write them and how they are tested.

What the evidence follows

SOC 1 evidence follows transactions: every change request, set-up, reconciliation and exception report in the period, traced from input to output, plus proof that the system reports behind those controls are complete and accurate. SOC 2 evidence follows the system: access reviews, vulnerability management, incident handling, vendor oversight, backups and, if chosen, availability or confidentiality controls.

What the report asks of your clients

Both reports can list controls your clients must operate for your controls to work. In SOC 1 these complementary user entity controls carry real weight, because your control objectives depend on them and your clients' auditors will look for them at the client. The complementary user entity controls guide explains how to word them.

What stays the same

The IT general controls overlap heavily. Joiner, mover and leaver processes, periodic access reviews, tested and approved changes, job monitoring and backup restores support SOC 1 objectives over the systems that process client transactions and meet large parts of the SOC 2 common criteria.

Which report your customers need: a decision table

The wording of the request usually settles it. If it is vague, ask whether the report will go to financial auditors or to a security team.

When you need both, and how to run them together

Payroll bureaus, claims processors, fund administrators, finance and accounting outsourcers and providers of hosted financial software often receive both requests within a year. Schellman, a licensed CPA firm, notes that many organisations that complete a SOC 1 examination are then asked for, or choose, a SOC 2 as well.

• One control matrix. Keep each control once, with its owner, frequency and evidence, and map it to the SOC 1 objectives and the Trust Services Criteria it supports.
• Two descriptions. SOC 2 descriptions follow the AICPA's 2018 description criteria; a SOC 1 description is evaluated under AT-C section 320 or ISAE 3402. Write each for its own reader rather than copying one into the other.
• Aligned periods. Choose Type 2 periods that serve your clients' year-ends for SOC 1 and your sales calendar for SOC 2, then ask the service auditor whether fieldwork on the shared controls can be coordinated.
• One evidence base. A single population of access removals or releases can be sampled for both examinations when it is complete and well kept.

Four mistakes that cost a reporting cycle

• Sending a SOC 2 to a user auditor. A client's financial auditor cannot use a security report to rely on your transaction controls.
• Loading SOC 1 with security objectives. Objectives that describe general information security rather than financial reporting risks confuse user auditors and still do not answer a security review.
• Offering SOC 3 instead of SOC 2. A general-use SOC 3 does not give the level of detail that security teams expect to read, so it seldom closes a vendor review on its own.
• Calling either report a certification. Describe what you hold accurately: the report, its type, its period and the CPA firm that issued it.

Where a hosting provider or other supplier performs part of your service, both examinations must deal with it; the choices are explained in Subservice organisations: carve-out or inclusive?

SOC 1 vs SOC 2: questions buyers ask