SOC 1 Report Explained: The Complete 2026 Guide

A SOC 1 report is an independent auditor’s report on the controls at a service organisation that matter to its customers’ financial statements. If you run payroll, fund accounting, claims, payments or a hosted finance application for other companies, their auditors will ask for one. If you are the customer, you will be asked by your own auditor whether you have read it. This guide explains what the document is, who writes each part of it, what it does and does not say, and what to do with one when it lands.

What this guide covers

• What a SOC 1 report is for
• The three parts of a SOC 1 report, and who writes each
• Type 1 and type 2: what the SOC 1 report speaks to
• Control objectives: the spine of the SOC 1 report
• Complementary controls and carve-outs
• What a SOC 1 report is not
• Reading a SOC 1 report as a customer
• Preparing a SOC 1 report as a service organisation
• Frequently asked questions

What a SOC 1 report is for

A user entity — the customer — is audited every year. Its auditor has to understand the controls over every transaction that reaches the financial statements, including the ones a service organisation processes on its behalf. Rather than send an auditor to every payroll provider and every fund administrator, the profession created a standard under which the service organisation engages one auditor, called the service auditor, to examine its controls and issue a report that every user auditor can rely on.

In the United States the examination is performed under AT-C section 320 of the AICPA’s attestation standards, issued as SSAE No. 18 and amended since. Internationally the same engagement runs under ISAE 3402 from the IAASB. The AICPA’s brand for the US version is SOC 1, and the name has stuck for both. The scope is deliberately narrow: controls likely to be relevant to user entities’ internal control over financial reporting. Security, availability and privacy for their own sake are a different examination, covered in our SOC 2 guide.

The three parts of a SOC 1 report, and who writes each

This is the point that surprises service organisations at their first engagement. The auditor writes one part of the package. Management writes the other two.

Both standards make management’s acceptance of that responsibility a precondition of the engagement. AT-C 320 lists six acknowledgements a service auditor must obtain before accepting: that management is responsible for the description and the assertion, that it has a reasonable basis for the assertion, that it selected the criteria, that it specified the control objectives, that it identified the risks and designed the controls, and that it will provide the written assertion. A service organisation that turns up with a folder of policies and expects the auditor to write the description has misunderstood the engagement.

Type 1 and type 2: what the SOC 1 report speaks to

A type 1 SOC 1 report addresses the description and the suitability of design of the controls as of a specified date. A type 2 SOC 1 report addresses the description, the design and the operating effectiveness of the controls throughout a specified period, and includes the auditor’s tests and results. User auditors need evidence about operation across their audit period, so type 2 is what they ask for; the AICPA’s own guidance for management describes type 1 as performed infrequently. The differences are set out in our SOC 1 Type 1 vs Type 2 comparison.

Neither standard fixes the length of a type 2 period. The AICPA’s management guidance suggests a report is most useful when it covers a substantial portion of user entities’ financial-statement periods, and describes a first period shorter than a year as a normal consequence of a late start or a new system. Anything between the end of the period and a customer’s year end is covered by a bridge letter from management, not by the auditor — see what a bridge letter covers and what it does not.

Control objectives: the spine of the SOC 1 report

A SOC 2 report is written against criteria the AICPA publishes. A SOC 1 report has no such list. Management specifies its own control objectives, states them in the description, and the auditor evaluates whether they are reasonable in the circumstances. The AICPA’s guidance for management elaborates that test into four attributes: the objectives must relate to the assertions commonly found in user entities’ financial statements, be free of bias, be measurable so two readers reach the same conclusion, and be complete as a set.

In practice a SOC 1 report carries two families of objectives. Business-process objectives cover the transactions themselves: authorised, complete, accurate, timely, correctly reported. IT general control objectives cover logical access, change management, computer operations, data transmission, backup and physical access, because every application control depends on them. A set of business-process objectives without the ITGCs is incomplete, and the auditor will say so.

Complementary controls and carve-outs

A SOC 1 report is honest about what the service organisation does not control. Two mechanisms carry that honesty, and a reader who skips them is relying on more than the report says.

• Complementary user entity controls (CUECs) are controls the service organisation assumes its customers perform — authorising a payroll file before it is submitted, reviewing the rejection report, administering their own portal users. The auditor’s report states that the control objectives can be achieved only if those controls are in place. They are the customer’s problem, and we explain them in Complementary User Entity Controls: the half you must do.
• Subservice organisations are providers the service organisation itself depends on, a hosting company being the usual example. Under the carve-out method the description names the services and excludes the provider’s controls from the examination; under the inclusive method the provider’s controls are included and the provider gives its own assertion. A carve-out for hosting means the customer may need the hosting provider’s own report too.

What a SOC 1 report is not

It is not a certification. Nobody is certified under AT-C 320 or ISAE 3402; the document is an opinion on specified matters for a specified period, and a vendor that calls itself “SOC 1 certified” has told you something about its marketing rather than its controls. It is not a security review; that is SOC 2. It is not a report on the customer’s own controls; the CUECs and the user entity’s reliance decisions remain the customer’s, which is why SOX 404 programmes treat vendor reports as evidence to be evaluated rather than conclusions to be adopted.

It is also restricted. The report is intended for user entities during the period and their auditors, who have enough understanding to read it alongside other information. Distribution to a prospect, where it happens, is under a non-disclosure agreement with a note that the prospect is not an intended user.

Reading a SOC 1 report as a customer

A user entity’s auditor, working under AU-C 402 or ISA 402, will ask the same questions every year, so the customer should answer them first. Is the system and the service in the report the one we use? Does the period cover enough of our financial year, and is there a bridge letter for the rest? Is the opinion unmodified, and if not, do the affected objectives matter to us? Which exceptions were reported, and did the auditor still conclude the objective was met? Which CUECs are we responsible for, and can we show our own control for each? Which subservice organisations are carved out, and do we need their reports?

A written answer to each question is a control in its own right, and it is what the user auditor will test. Our review checklist for user entities is built on that list.

Preparing a SOC 1 report as a service organisation

The work divides into three phases. Planning: decide the scope, the type and the period; identify subservice organisations and choose carve-out or inclusive for each; specify the control objectives; engage the auditor. Evaluation: write the description, map risks to objectives and controls to risks, confirm the controls are actually in operation, test them yourself across the period, and capture every change. Reporting: finalise the description and the assertion, review the draft opinion, sign the representation letter, issue the report, and start the next cycle. The evidence for a type 2 report has to exist from the first day of the period; a period that has already passed cannot be reconstructed.

The SOC 1 Toolkit is built on exactly that division: 87 templates covering the description in every required section, a library of 19 control objectives with their risks and controls, the CUEC and subservice-organisation registers, the type 1 and type 2 assertions, the representation-letter checklist and the bridge letter, plus six documents for user entities reviewing a vendor’s report. If you are about to face your first examination, the SOC 1 Toolkit is where the description starts.

Further reading in this series: SOC 1 vs SOC 2 on which report a customer actually needs, SSAE 18 explained on the standard behind the report, SOC 1 control objectives on the spine of the description, the SOC 1 audit checklist for readiness, and SOC 1 audit cost on what the engagement costs.

Frequently asked questions

Who needs a SOC 1 report?

A service organisation whose services affect its customers’ financial statements — payroll processors, fund administrators and transfer agents, claims administrators, payment processors, loan servicers, hosted financial applications and the data centres behind them. The demand comes from customers’ auditors, not from a regulator, though some regulators and user groups specify the control objectives.

Is a SOC 1 report the same as SSAE 18?

SSAE 18 is the AICPA statement that issued AT-C section 320, the standard the examination is performed under. SOC 1 is the AICPA’s name for the resulting report. People use the terms interchangeably, and an “SSAE 18 report” means a SOC 1 report. The AICPA’s SOC suite page sets out the family.

How is a SOC 1 report different from ISAE 3402?

ISAE 3402 is the IAASB’s international standard for the same engagement, and a report under it looks almost identical. The differences are in detail — the international standard has no term for complementary subservice organisation controls, for instance, and its list of written representations is longer. Many service organisations obtain one examination reported under both.

How long is a SOC 1 report valid?

It speaks to its period, and no longer. A type 2 report for the year to 30 September says nothing about October. That gap is covered by a bridge letter from management, and by the next report.