A SOC 1 report example follows a standardized five-section format: an independent auditor’s opinion, a management assertion, a description of the service organization’s system, a matrix of control objectives with test results, and optional additional information from management. The report is a restricted-use audit document performed under AT-C section 320, established by the AICPA’s Statement on Standards for Attestation Engagements No. 18, that evaluates whether a service organization’s internal controls are designed and operating to protect the accuracy of its clients’ financial reporting.{1AICPA & CIMA. SOC 1 – SOC for Service Organizations: ICFR} Payroll processors, claims administrators, loan servicers, and similar organizations whose work feeds directly into a client’s general ledger are the typical subjects. If your concern is broader operational security, availability, or data privacy rather than financial statement impact, you’re looking for a SOC 2 instead.
The Five Sections of a SOC 1 Report
Every SOC 1 report is organized the same way, which is what makes it useful. A user auditor at one client company can pick up a report and find the same information in the same place they’d find it in a report from any other service provider.
Section I — Independent Service Auditor’s Report. The auditor’s formal opinion on whether the controls are fairly presented and, for a Type II, whether they operated effectively over the period. An unmodified opinion means no significant problems were found. A qualified opinion flags specific issues in a defined area.
Section II — Management’s Assertion. A written statement from the service organization’s leadership claiming that the system description is accurate and that controls were suitably designed and, for a Type II, operated effectively during the review period.
Section III — Description of the System. A narrative explaining the services provided, the technology infrastructure, the people involved, and how data flows through the organization.
Section IV — Control Objectives, Controls, and Tests of Controls. The technical core of the report, presenting each control objective mapped to specific control activities, the auditor’s testing methods, and the results.
Section V — Other Information. Optional content provided by the service organization that falls outside the auditor’s opinion, such as planned system changes or context around noted exceptions.
One point of interpretation matters here. The auditor’s opinion in Section I covers only Sections II through IV. Anything in Section V is management’s own commentary and carries no auditor assurance. When you’re weighing a specific disclosure, check which section it sits in.
A Closer Look at the System Description
Section III is where the service organization explains, in plain terms, what it does and how it does it. The description defines the boundaries of the system under review, identifying the software applications, hardware infrastructure, and network components that process client financial data. It covers the people responsible for operating those systems, their reporting lines, and any segregation of duties built into the organizational structure.
The description traces the full lifecycle of data: how it enters the system, what processing steps occur, and where results are stored or transmitted back to clients. Automated processes like scheduled backups and system-generated reconciliations are documented alongside manual procedures like supervisor approvals and physical security checks. Incident management procedures and disaster recovery capabilities round out the section, giving user auditors insight into what happens when something goes wrong.
This is where most of the real diligence lives for a careful reader. A vague system description usually signals that the organization hasn’t clearly defined its own control boundaries, and auditors reading the report will notice.
How Control Objectives and Test Results Are Presented
Section IV lays out the audit findings in a structured table. Each row ties a control objective to one or more control activities, describes the auditor’s testing methodology, and reports the results. This is the part user auditors spend the most time with, so it’s worth understanding how the pieces fit together.
A control objective describes what the organization is trying to achieve. Typical examples include ensuring that new client accounts are set up only with proper authorization and processed accurately, or that access to applications and data is restricted to authorized users performing authorized actions. Each objective is paired with the specific control activities the organization uses to achieve it. That might be a requirement that a manager approve any system access change, or an automated validation check that runs on incoming data files.
In a Type II report, the auditor also describes the testing procedure for each control. That might involve selecting a sample of access-change requests to verify each had documented approval, or inspecting system logs to confirm that backup jobs ran on schedule throughout the testing period. The PCAOB defines audit sampling as applying a procedure to less than 100 percent of the items in a population to evaluate a characteristic of the whole.{2Public Company Accounting Oversight Board. AS 2315 – Audit Sampling} The results column then discloses whether any exceptions were found, meaning instances where the control did not work as intended.
Type I vs. Type II: What Changes in the Report
A SOC 1 report example will look meaningfully different depending on which type you’re holding.
A Type I report evaluates whether the service organization’s controls are properly designed as of a single date. It’s a snapshot: the auditor looks at the control environment on one specific day and determines whether the design would achieve the stated objectives if the controls operated as described. Section IV in a Type I identifies the control activities but does not include tests of operating effectiveness.
A Type II report goes further. It tests not just the design but the actual operating effectiveness of those controls over a period, typically six to twelve months.{1AICPA & CIMA. SOC 1 – SOC for Service Organizations: ICFR} Section IV in a Type II includes the testing procedures the auditor performed and the results of that testing. Most client auditors strongly prefer a Type II because a well-designed control that nobody follows is worthless. Organizations pursuing their first SOC 1 sometimes start with a Type I to confirm their controls are designed correctly before committing to the longer Type II engagement.
Reading the Auditor’s Opinion and Any Exceptions
Exceptions in a SOC 1 report do not automatically mean the sky is falling. A few minor exceptions, such as one access review out of twenty-five completed a week late, are common and unlikely to change the auditor’s overall opinion. What matters is the pattern and the severity.
When exceptions are significant or numerous enough to indicate that a control objective was not met, the auditor issues a qualified opinion. A qualified opinion means that, except for the specific area identified, the controls were suitably designed and operating effectively. The rest of the report remains usable. Client auditors receiving a report with a qualified opinion cannot rely on the controls in the affected area but can still rely on everything else that was clean.
A qualified opinion in a SOC 1 context is more comparable to a significant deficiency or material weakness disclosure than to a going-concern opinion. It signals a problem with a specific control area, not a fundamental question about the organization’s viability. When exceptions appear, the report typically includes management’s response explaining the root cause and any remediation steps taken or planned.
Complementary User Entity Controls
One of the most overlooked parts of a SOC 1 report is the list of complementary user entity controls, or CUECs. These are controls the service organization cannot perform on its own because they require action at the client company’s end. If your vendor’s SOC 1 lists CUECs and you ignore them, the control objectives the report covers may not actually be achieved for your organization.
Common CUECs include:
- Promptly removing a departing employee’s access to the service organization’s systems.
- Formally approving any system changes the service provider implements on your behalf before they go live.
- Using encrypted methods or the provider’s secure upload portal when sending data.
- Keeping your own devices patched and protected, unless the contract specifically covers this.
- Maintaining your own business continuity plan; the service organization’s disaster recovery plan covers their operations, not yours.
Your own auditors will test whether you have implemented the CUECs identified in your service providers’ reports. Failing to implement them can produce findings in your financial statement audit, which is exactly the kind of surprise nobody wants during year-end close.
Subservice Organizations in the Report
Many service organizations rely on their own vendors, called subservice organizations, to deliver parts of their services. A payroll processor might use a third-party cloud provider to host its application. The SOC 1 report has to address these relationships, and how it does so changes what you’ll see.
Under the carve-out method, the report describes the services the subservice organization performs but excludes that vendor’s control objectives and testing from the report. The service organization instead documents the controls it uses to monitor the subservice organization, such as reviewing the vendor’s own SOC report annually. Carve-out is by far the more common approach.
Under the inclusive method, the subservice organization’s controls appear directly in the report and are tested alongside the service organization’s own controls. This gives user auditors a more complete picture but requires the subservice organization to cooperate fully with the audit, which many vendors are reluctant to do.
When you read a carve-out report, the excluded vendor’s controls represent a gap in coverage. You or your auditor may need to obtain the subservice organization’s own SOC report separately to get comfortable with the full control chain.
Who Can Actually Receive the Report
SOC 1 reports are restricted-use documents. The intended audience is the service organization’s own management, the user entities that rely on its controls, and the auditors of those user entities. The auditor’s report in Section I explicitly states the intended audience and warns that the report should not be used by anyone outside that group.
The restriction exists because the report contains detailed information about internal controls, system architecture, and security processes that could be misused if made public. Unlike a SOC 3 report, which produces a general-use seal of compliance, a SOC 1 is not something a service organization posts on its website or hands to prospects as marketing material. Most providers manage distribution through secure portals or require a non-disclosure agreement before releasing the report to authorized recipients. If you’re trying to obtain a vendor’s SOC 1, expect to sign one.