An AICPA SOC 1 report is an independent CPA audit of a service organization’s internal controls over the processes that affect its clients’ financial reporting. It’s governed by the Statement on Standards for Attestation Engagements (SSAE) No. 18, specifically AT-C Section 320, and it gives client companies and their external auditors evidence that outsourced functions handle financial data reliably.1AICPA & CIMA. AICPA SSAEs – Currently Effective If your company outsources payroll, loan servicing, claims administration, or any function that touches the numbers on a financial statement, a SOC 1 is how your auditor gets comfortable with those outsourced controls without testing them directly.
Three parties sit around the report. The service organization performs the outsourced work and undergoes the audit. The service auditor is the independent CPA firm that examines the controls and signs the opinion. The user entity is the client company that relies on the service organization. In practice, the primary reader is the user entity’s external auditor, because a clean SOC 1 lets them narrow the scope of their own financial statement audit work.
Common service organizations that produce SOC 1 reports include payroll processors, insurance claims administrators, loan servicers, accounting service providers, banking service firms, and software providers whose platforms process financial transactions. The thread tying them together is straightforward: their work feeds directly into their clients’ financial statements.
How SOC 1 Differs From SOC 2
SOC 1 and SOC 2 both fall under SSAE 18, and readers often mix them up. A SOC 1 focuses exclusively on controls relevant to user entities’ financial statements, with custom control objectives tied to financial reporting risks.2AICPA & CIMA. U.S. Attestation Standards – AICPA (Clarified) AT-C Sections 100-320
A SOC 2, governed by AT-C Section 205, evaluates controls against the AICPA’s Trust Services Criteria: security (always required), and optionally availability, processing integrity, confidentiality, and privacy. It suits service organizations that hold sensitive data but don’t process financial transactions. A cloud hosting provider that stores customer data without calculating any financial figures typically undergoes a SOC 2 rather than a SOC 1. Some organizations end up needing both.
Type 1 vs. Type 2
SOC 1 reports come in two varieties, and the difference in assurance is significant.
A Type 1 report is a snapshot. The service auditor evaluates whether the system description fairly presents the organization’s system as of a single specified date, and whether the controls are suitably designed to achieve their stated objectives on that date.2AICPA & CIMA. U.S. Attestation Standards – AICPA (Clarified) AT-C Sections 100-320 It says the control environment looks right on paper. It doesn’t say whether the controls actually worked over time.
A Type 2 report covers a defined period. The auditor evaluates everything in a Type 1 and also tests whether the controls operated effectively throughout the period, documenting the tests performed and the results.2AICPA & CIMA. U.S. Attestation Standards – AICPA (Clarified) AT-C Sections 100-320 Most Type 2 reports cover twelve months, though the standard sets no minimum period length. Common industry guidance is that the report should overlap at least six months of the user entity’s fiscal year.
User entity auditors strongly prefer Type 2 reports. Evidence of operating effectiveness lets them reduce substantive testing of the outsourced function; without it, they’ll often need to test the outsourced transactions independently. Type 1 reports are usually reserved for a service organization’s first audit cycle or when a client needs something on short notice while a Type 2 engagement is being organized.
What’s Inside a SOC 1 Report
Every SOC 1 is structured in four sections, each written for a different reader need.
- Section I is the service auditor’s opinion. This is the CPA firm’s formal opinion on whether the system description is fairly presented and whether the controls are suitably designed (Type 1) or suitably designed and operating effectively (Type 2). It’s the first thing a user entity’s auditor reads.
- Section II is management’s assertion. A written statement from the service organization’s management affirming that the system description is accurate and that the controls were designed and, for a Type 2, operated effectively throughout the period.
- Section III is the description of the system. A narrative of the services provided, how transactions are initiated, processed, and reported, the boundaries of the system, and the specific controls in place.
- Section IV, in Type 2 reports only, lists control objectives, the tests performed, and the results. Each control objective appears alongside the controls designed to achieve it, the auditor’s tests, and any exceptions.
AT-C Section 320 spells out what the system description must include: the types of services and classes of transactions processed, the flow of transactions through the system, how the organization captures significant events beyond routine transactions, the process for preparing reports to user entities, any subservice organizations and the method used to address them, the control objectives and related controls, and complementary controls assumed to exist at user entities.2AICPA & CIMA. U.S. Attestation Standards – AICPA (Clarified) AT-C Sections 100-320
Control Objectives, Scope, and Complementary User Entity Controls
Before the examination starts, the service organization defines the boundaries of the audit. The scope covers only controls that could affect user entities’ financial reporting. Operational quality issues or compliance matters unrelated to financial data sit outside a SOC 1.
Within that scope, the service organization identifies its control objectives, statements of what its controls are designed to accomplish. A payroll processor’s objective might read: “payroll transactions are completely and accurately calculated and recorded.” Under each objective sit the actual control activities, the approvals, reconciliations, and system configurations that make the objective achievable.
Then come Complementary User Entity Controls, or CUECs. These are controls the service organization assumes its clients have in place for the service organization’s own controls to function as intended.2AICPA & CIMA. U.S. Attestation Standards – AICPA (Clarified) AT-C Sections 100-320 If a payroll provider calculates gross pay but relies on the client to approve new hire salary rates, that approval is a CUEC. If the user entity never puts that control in place, the service organization’s controls alone won’t prevent a misstatement. This is one of the most overlooked parts of the report, and user entity auditors need to review the CUEC list carefully to confirm their own organization is meeting the assumed responsibilities.
SOC 1 reports also usually include IT general controls, the technical processes that keep the systems processing financial data reliable. These typically cover access management, change management, system operations, and governance. The service auditor tests them alongside the business process controls because a failure in the underlying IT environment can undermine every application-level control the report describes.
Subservice Organizations
Service organizations often rely on other vendors. A payroll processor might use a separate data center; a claims administrator might outsource check printing. Those downstream vendors are subservice organizations, and how the report handles them matters for coverage.3Public Company Accounting Oversight Board. AI 18 – Consideration of an Entity’s Use of a Service Organization
AT-C Section 320 provides two approaches. Under the carve-out method, the service organization acknowledges the subservice organization in its system description but excludes the subservice organization’s control objectives and controls from the examination scope. The service organization still has to monitor the subservice organization, typically by reviewing its SOC report, sending questionnaires, or maintaining internal oversight. Under the inclusive method, the subservice organization’s controls sit within the system description and examination scope, and the service auditor tests them as part of the engagement.
The carve-out method is far more common because it’s simpler. But user entity auditors need to know which method was used. When the carve-out method is applied, the user entity’s auditor may need to obtain the subservice organization’s own SOC report separately to get full coverage of the controls that touch their client’s financial reporting.
Reading the Auditor’s Opinion
The auditor’s opinion is the most consequential part of the report. It tells the user entity’s auditor how much weight to give everything else in it.
- An unqualified (clean) opinion says the controls were suitably designed and, for a Type 2, operating effectively in all material respects. This is what every service organization wants and what user entity auditors expect.
- A qualified opinion says the controls were generally effective except for specific identified issues. The problem is limited in scope and doesn’t pervade the environment.
- An adverse opinion says the auditor found severe deficiencies that materially impact and are pervasive across the control environment. A user entity’s auditor cannot rely on the report and will likely need to perform extensive independent testing.
- A disclaimer of opinion says the auditor couldn’t obtain enough evidence to form any opinion, usually because of access restrictions or scope limitations.
Anything other than an unqualified opinion creates work for the user entity’s auditor. The practical impact depends on whether the affected controls relate to the specific transactions the user entity outsources. A qualification over a control that doesn’t touch your outsourced function may have no bearing on your audit. A qualification squarely inside the controls you rely on means your auditor needs a fallback plan.
Control exceptions found during the audit stay in the report even if the service organization fixes them later. The auditor reports on the control environment as it existed during the period, so both the failure and any remediation show up in the final document.
Bridge Letters When the Report Period Doesn’t Match Your Fiscal Year
A common timing issue: the SOC 1 period doesn’t line up with the user entity’s fiscal year. If a service organization’s Type 2 covers January through September and the user entity’s year ends December 31, there’s a three-month gap with no auditor-tested coverage.
Service organizations bridge that gap with a bridge letter, sometimes called a gap letter. It’s a written representation from the service organization’s management stating that no material changes have occurred to the control environment since the SOC 1 report date. The service auditor does not sign the bridge letter and performs no additional testing for the gap period. The bridge letter is management’s word, not auditor assurance. User entity auditors accept them as supplementary evidence, but they carry less weight than auditor-tested controls. If the gap is long or the risk is high, the user entity’s auditor may still need to run independent procedures for the uncovered period.
Who Can Access a SOC 1 Report
A SOC 1 is a restricted-use document, unlike a SOC 3, which is designed for general distribution. The service auditor’s standard opinion limits distribution to three groups: the service organization itself, user entities that used the system during the period covered by the report, and the auditors of those user entities. Indirect user entities downstream of a subservice organization may also fall within the permitted audience when that subservice organization’s controls are relevant to their financial reporting.
That restriction means a SOC 1 report cannot be posted publicly, used in marketing materials, or handed to prospects without an existing service relationship during the audit period. Service organizations usually require a non-disclosure agreement before releasing the report. If you’re evaluating a potential vendor and ask for their SOC 1, expect a request for an NDA or a summary instead of the full document.