What Is a SOC 1 Report? SSAE 18, Type 1, and Type 2 Explained
A SOC 1 report is a CPA firm's opinion on the controls at a service organization that are relevant to its customers' internal control over financial reporting. The service auditor performs the examination under SSAE 18, in AT-C section 320 of the AICPA attestation standards, and the report goes to the service organization's management, its customers (user entities), and the customers' financial statement auditors (user auditors), who rely on it in financial statement audits and SOX 404 work. A Type 1 report covers whether controls were suitably designed as of a single date. A Type 2 report adds tests of operating effectiveness over a review period, normally six to twelve months.
BD Emerson performs SOC 1 Type 1 and Type 2 examinations through its CPA attest practice, from scoping through the signed opinion, and the firm that examines you does not also implement your controls.
SOC 1 at a glance
The table summarizes what a service organization or a user auditor needs to know first.
| Element | What it means for a SOC 1 |
|---|---|
| Standard | SSAE 18, AT-C section 320, applied with the AICPA SOC 1 guide (2025 edition) |
| Subject matter | Controls at a service organization relevant to user entities' internal control over financial reporting |
| Criteria | Control objectives that service organization management specifies, plus the description criteria in AT-C section 320 |
| Report types | Type 1 (design as of a date) and Type 2 (design and operating effectiveness over a period) |
| Typical Type 2 period | 6 to 12 months, set to cover most of the customers' fiscal years |
| Intended users | Service organization management, user entities, and user auditors |
| Who can issue it | A licensed CPA firm, independent of the service organization |
| Renewal | Annual, with management-signed bridge letters for gaps |
| BD Emerson planning range | $20,000 to $40,000 for a Type 1 and $30,000 to $60,000 for a Type 2, one service line, as of October 2026 |
SSAE 18 and AT-C section 320
SSAE 18 is the AICPA statement that clarified and recodified the attestation standards into AT-C sections: the AICPA's current listing groups them into common concepts (the 100 series), level of service (the 200 series), and subject matter (the 300 series). AT-C section 320 is the subject-matter section for SOC 1, titled "Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting." People use "SSAE 18 audit" and "SOC 1 audit" for the same engagement, and the distinction is small: SSAE 18 created the standards that also govern SOC 2 and other examinations, and a SOC 1 is the report that AT-C section 320 produces.
The AICPA's SOC 1 guide carries the practical guidance. Its 2025 edition added material on subservice organizations, software-as-a-service providers, and the reasonableness of control objectives, and it explains how a user auditor uses a Type 1 or Type 2 report. The AICPA describes the audience narrowly: entities that use service organizations and "the CPAs that audit the user entities' financial statements" (AICPA SOC 1 overview).
Who needs a SOC 1 report?
A service organization needs a SOC 1 report when its service affects the financial statements of the companies that use it. The practical test is whether a processing error at your company could produce a misstatement at a customer. Payroll processors and professional employer organizations calculate wages, withholding, and payroll tax liabilities. Benefits administrators and claims third-party administrators adjudicate and pay claims that drive claims expense and reserves. Loan servicers post payments and escrow balances. Fund administrators and transfer agents calculate net asset value and record investor activity. Billing, payments, and revenue cycle companies generate invoices and apply cash. SaaS providers whose applications run a customer's revenue recognition, payables, expense management, or close belong on the list too, which is why the 2025 guide added SaaS-specific material.
The request usually arrives from a customer's controller or external auditor, often in an RFP or a renewal contract. A company whose service has no path to a customer's ledger, such as a marketing analytics tool, needs a SOC 2 instead, and our comparison of SOC 1 vs SOC 2 gives the decision rule with examples.
SOC 1 Type 1 vs Type 2
A Type 1 report gives the service auditor's opinion on whether management's description of the system is fairly presented and whether the controls are suitably designed to achieve the control objectives as of a specified date. A Type 2 report adds an opinion on whether the controls operated effectively throughout a specified period, and it includes the auditor's tests and results. User auditors treat the two differently. PCAOB AS 2601 says a report on controls placed in operation "is not intended to provide any evidence of the operating effectiveness of the relevant controls," and it says a report that includes tests of operating effectiveness should ordinarily cover a minimum period of six months.
Most SOC 1 programs follow the same path: a Type 1 in the first year to give customers something while controls mature, then an annual Type 2. A twelve-month period ending September 30 or December 31 serves calendar-year customers best, because it covers most or all of their fiscal year. A first Type 2 can run six months to get a report to customers sooner, then move to twelve months at the next renewal.
What is inside a SOC 1 report
Most SOC 1 reports follow the same five-section order, and a reader who knows it can find what matters in minutes. The figure shows the five sections and what each one tells the reader.
Section 1 is the independent service auditor's report. An unmodified opinion says the description is fairly presented, the controls were suitably designed, and, in a Type 2, the controls operated effectively. A qualified opinion uses "except for" language and names the control objective that was not achieved, and adverse opinions and disclaimers are rare. Section 2 is management's assertion, the service organization's signed claim about the same points. Section 3 is the description of the system: the services, the transaction flows, the IT environment, the control objectives and related controls, the complementary user entity controls, and the subservice organizations with the method used to present them. Section 4 lists each control objective with its controls and, in a Type 2, the auditor's tests and results, including every exception. Section 5, other information, holds material the service organization adds, such as management's responses to exceptions, and the opinion does not cover it.
Control objectives versus controls
A control objective states what must be achieved, and a control is the activity that achieves it. Management writes both. An objective for a payroll service might read: "Controls provide reasonable assurance that changes to employee pay rates are authorized and processed completely and accurately." The controls under it are specific: a supervisor approves each rate change in the system before the pay run, the system blocks changes from users without the approver role, and a payroll analyst reconciles the change report to approved requests each cycle. The auditor tests the controls and concludes on the objective.
| Control objective | Example control | How a Type 2 tests it |
|---|---|---|
| Payroll changes are authorized and processed accurately | A supervisor approves each pay rate change before the pay run | Inspect approvals for a sample of changes across the period |
| Logical access to financial applications is restricted to authorized users | Access requests need manager approval, and access reviews run quarterly | Inspect approvals for a sample of new users and every quarterly review in the period |
| Program changes are authorized, tested, and approved before deployment | Each change needs a ticket, peer review, and approval before release | Inspect a sample of production changes for the ticket, test evidence, and approval |
| Processing is complete and accurate | Operators monitor batch jobs and resolve and document failures | Inspect job logs and failure tickets for a sample of days |
In BD Emerson's planning, a single-service SOC 1 usually carries eight to twenty control objectives, split between business process objectives and IT general control objectives. The count drives cost, and completeness drives usefulness: an objective that skips a risk the user auditor cares about forces the auditor to test around your report.
Complementary user entity controls and subservice organizations
Complementary user entity controls (CUECs) are controls the service organization assumes its customers perform, and without them the control objectives cannot be achieved. A payroll processor assumes the customer restricts who can submit pay changes, reviews the payroll register before approving each run, and tells the processor promptly when an employee leaves. Section 3 lists the CUECs, and the customer's auditor tests whether the customer performs them. A CUEC that nobody at the customer owns becomes a gap in the customer's own SOX program.
Subservice organizations are vendors the service organization uses to deliver its service, such as a cloud infrastructure provider or a print-and-mail vendor. Management presents them by one of two methods. Under the carve-out method, the description names the subservice organization and what it does, excludes its controls from the examination, and identifies the complementary subservice organization controls (CSOCs) management assumes the vendor performs, while the service organization's own monitoring of the vendor, such as an annual review of the vendor's SOC report, stays in scope. Under the inclusive method, the description includes the subservice organization's relevant controls and the auditor tests them, which requires the vendor's cooperation and its own written assertion. Carve-out is the common choice, because cloud providers such as AWS, Microsoft, and Google publish their own SOC 1 reports, and user auditors read those directly.
IT general controls in a SOC 1
IT general controls (ITGCs) are the controls over the systems that process financial transactions, and a SOC 1 usually covers them in three areas: logical access, change management, and computer operations, plus physical access when the service organization runs its own facilities. They matter because automated controls and system-generated reports are only as reliable as the ITGCs around them. If the auditor finds that developers could push code to production without approval, every automated calculation in the application loses its support, and user auditors must test around it. Our ITGC audit team performs this testing for companies preparing for SOX, and the same domains anchor a SOC 1.
How user auditors rely on a SOC 1 for SOX 404
A user auditor relies on a SOC 1 Type 2 as evidence that controls at the service organization operated effectively, which spares the auditor from testing them directly. For public companies, PCAOB AS 2201, Appendix B, paragraphs B17 through B27, sets the procedure. The auditor evaluates whether the report provides sufficient evidence, compares the testing period with the as-of date of management's assessment (B21), and, when time has passed since the period ended, asks management whether it has identified changes at the service organization (B24). The auditor also tests the customer's own controls over the outsourced activity, including the CUECs, and does not refer to the service auditor's report in its own opinion (B27). Auditors of private companies follow AU-C section 402 for the same questions.
For the customer's SOX team, this becomes an annual routine: obtain the report, confirm it covers the right services and period, map each CUEC to an owned control, evaluate exceptions and the carved-out subservice organizations, and document the bridge to year end. Our SOX compliance consulting team builds that routine for public and pre-IPO companies, and our guide to SOX 404 compliance covers the full requirement.
Bridge letters close the gap to year end
A bridge letter is a short statement, signed by the service organization's management, that covers the months between the end of the review period and a customer's fiscal year end. Take a payroll processor with a review period of October 1 to September 30 and a report issued in mid-November. For a calendar-year customer, the report covers nine months of the fiscal year, January through September, and the bridge letter covers October 1 to December 31, three months, by stating whether controls changed and whether any incidents occurred. The letter is the documented answer to the inquiry AS 2201 paragraph B24 requires. The auditor does not sign it, because no CPA can give assurance over a period it did not examine, and our article on the bridge letter covers what it should contain.
What an exception means and how to read one
An exception, also called a deviation, is a test result where a control did not operate as described for one or more sample items. An exception does not automatically mean a qualified opinion. The service auditor evaluates whether the deviations mean the control objective was not achieved, considering other controls that support the same objective, and the opinion carries "except for" language only when the objective fails.
Read an exception in four steps. First, find the rate: "For 3 of 25 terminated users sampled, system access was removed 9 to 14 days after termination" is a 12 percent deviation rate in a control the description says operates within one business day. Second, find the window: an exception confined to October and November of the review period matters less to a calendar-year customer whose fiscal year starts in January. Third, check Section 5 for management's response and the date of the fix. Fourth, ask whether you have a compensating control on your side, such as your own termination notices to the processor or a periodic review of its user list. User auditors run the same analysis, and a documented compensating control often lets them conclude without extra testing.
SOC 1 timeline and engagement steps
A first SOC 1 Type 1 report takes two to six months from kickoff, and each Type 2 report issues four to eight weeks after its review period closes. The table gives BD Emerson planning ranges for each step.
| Step | What happens | BD Emerson planning duration |
|---|---|---|
| Scoping | Define services, systems, locations, subservice organizations, and the review period; settle the control objectives | 2 to 4 weeks |
| Readiness (optional) | The service organization's team or a separate advisor assesses gaps against the objectives and remediates | 4 to 12 weeks |
| Description drafting | Management writes the system description and control matrix | 3 to 6 weeks, overlapping readiness |
| Type 1 fieldwork | Walkthroughs and design evaluation as of the report date | 2 to 4 weeks |
| Type 2 review period | Controls operate while evidence accumulates | 6 to 12 months |
| Type 2 fieldwork | Interim testing during the period, then final testing after it closes | 3 to 6 weeks in total, 2 to 4 of them after period end |
| Reporting | Draft report, management review, signed assertion and opinion | 2 to 4 weeks after final testing |
How much does a SOC 1 audit cost?
BD Emerson's planning ranges for a SOC 1 covering one service line, as of October 2026, are $20,000 to $40,000 for a Type 1 and $30,000 to $60,000 for a Type 2. Four drivers move the number within the range. The count of control objectives sets how much there is to test. Transaction volume sets sample sizes for business process controls. Each additional processing location or platform adds walkthroughs and samples. ITGC centralization matters most: the auditor tests one identity provider and one deployment pipeline once, while separate access and change processes for each application each need their own testing. Choosing the inclusive method for a subservice organization adds cost, and adding a SOC 2 raises the total fee while removing duplicated ITGC testing.
Renewal years usually cost less than the first Type 2, because the system description, control matrix, and walkthrough documentation carry forward and testing focuses on samples and changes. Budget the internal time as well: someone at the service organization owns the description, gathers evidence for each sample request, and responds to exceptions, and that work falls to finance operations and engineering leads.
Frequently asked questions
What is a SOC 1 report used for? A SOC 1 report lets a service organization's customers and their financial statement auditors rely on controls at the service organization that affect the customers' financial reporting. Auditors use a SOC 1 Type 2 as evidence that outsourced processing, such as payroll, claims payment, or billing, was controlled during the period, which reduces the testing they would otherwise perform. Public company auditors use it in SOX 404 work under PCAOB AS 2201.
What is the difference between SOC 1 Type 1 and Type 2? A SOC 1 Type 1 report covers whether controls were suitably designed and in place as of one date. A Type 2 report adds tests of whether the controls operated effectively over a review period, usually six to twelve months, and lists the results, including exceptions. User auditors need a Type 2 to rely on operating effectiveness, because PCAOB AS 2601 says a design-only report provides no evidence that controls operated.
Is SSAE 18 the same as SOC 1? The two terms overlap without being identical. SSAE 18 is the AICPA statement that recodified the attestation standards into AT-C sections, and those standards govern many engagements, including SOC 2. SOC 1 is the report produced by an examination under AT-C section 320, the section for controls relevant to user entities' internal control over financial reporting. In everyday use, an SSAE 18 audit almost always means a SOC 1 examination.
How long is a SOC 1 report valid? A SOC 1 report has no formal expiration date, but it covers only its review period, and user auditors want a period that overlaps their client's fiscal year. In practice, service organizations reissue a SOC 1 Type 2 every twelve months and give customers a management-signed bridge letter for the months between the period end and each customer's year end. A report whose period ended more than a year ago usually fails customer requirements.
What are complementary user entity controls in a SOC 1? Complementary user entity controls are controls the service organization assumes its customers perform, and without them the report's control objectives cannot be achieved. Examples include restricting who can submit payroll changes, reviewing output reports before approving a payment run, and notifying the service organization when users leave. The SOC 1 lists them in the system description, and each customer's auditor tests whether the customer performs them.
Who can perform a SOC 1 audit? Only a licensed CPA firm can perform a SOC 1 examination and sign the opinion, because it is an attestation engagement under AICPA standards. The firm must be independent of the service organization, so it cannot have designed or implemented the controls it examines. BD Emerson performs SOC 1 Type 1 and Type 2 examinations through its CPA attest practice under SSAE 18 and AT-C section 320, and when our consultants have built part of a client's controls, a different firm performs the examination.
If your customers' auditors have started asking for a SOC 1, our SOC 1 audit team can review the request, scope the control objectives with you, and set a review period that matches your customers' fiscal years.
