What Is a SOC 1 Report? ICFR, Examples, and Who Asks

A prospect's external auditor emails your controller asking for "your SOC 1." Your head of sales forwards it to you with a question mark. You have a SOC 2 on file, and you are not sure why that is not enough.

It is not enough because the two reports answer different questions. This post is the pillar primer on SOC 1: what it is, why it exists, who asks for it, and what a finished report actually looks like.

What a SOC 1 report is

A SOC 1 report is an independent CPA's attestation on the controls at a service organization that are relevant to its user entities' internal control over financial reporting. It is issued under SSAE 18, AT-C Section 320, the AICPA attestation standard that replaced SAS 70 in 2011 and was updated again in 2017. The AICPA's own SOC 1 examination guide is the authoritative reference service auditors use to plan and report on the engagement, and the current AT-C codification sits in the AICPA SSAEs currently effective listing.

In plain English: if your systems touch numbers that end up on somebody else's income statement, balance sheet, or cash-flow statement, a SOC 1 is how their auditor gets comfortable relying on your controls without sending a team to inspect you directly.

What "ICFR relevance" means in practice

ICFR stands for Internal Control over Financial Reporting. It is the set of processes and controls that give reasonable assurance a company's financial statements are reliable and prepared in conformity with GAAP.

SOC 1 is scoped exclusively to ICFR. Everything in a SOC 1 report exists because it affects a user entity's ability to produce accurate financial statements. Vendor security hygiene, uptime, privacy commitments, those are SOC 2 territory. SOC 1 only cares about the controls that keep the numbers right.

The mechanics work like this. A user entity's financial-statement auditor identifies the accounts and assertions that are material to the audit. Some of those accounts are produced, calculated, or held at a service organization. The user auditor cannot issue an opinion on the financials without comfort that those service-organization controls operate. They get that comfort from the SOC 1.

For public filers, this chain connects directly to SOX. A filer subject to auditor attestation produces a management assertion under 404(a) and receives a separate auditor opinion under 404(b). Both lean on SOC 1 reports from service organizations inside the reporting perimeter. The mapping between the two regimes is the subject of SOX 404(a) vs 404(b).

Who asks for a SOC 1

The request almost always comes from a user entity's finance team or their external auditor, not their security team. The service organizations that most often need one are the ones sitting inside a financial reporting chain:

• Payroll processors and PEOs. They calculate wages, withhold taxes, and remit to agencies. Wages and payroll tax liability are material accounts on the user entity's books.
• Claims adjudicators and TPAs. They determine amounts that flow into reserves and expense lines.
• Managed accounting, outsourced bookkeeping, and fund administrators. They maintain the general ledger or sub-ledgers that feed it.
• Custodians and transfer agents. They hold assets or track ownership that has to tie to the user entity's records.
• Loan servicers and billing platforms. They cut invoices and record cash receipts that become revenue and receivables.
• Revenue-relevant SaaS. Usage-metering platforms, subscription-billing engines, and ERP hosts where the system of record lives with the vendor.

The auditor on the other side is often a PCAOB-registered firm if the user entity is a public filer. PCAOB firms operate under AS 2201, the PCAOB's ICFR audit standard, which requires them to evaluate service-organization controls as part of an integrated audit. They care about scope overlap with their client's fiscal year and the quality of the complementary user entity controls. They will ask pointed questions when either is wrong.

SOC 1 Type 1 vs Type 2

A SOC 1 Type 1 reports on whether controls were suitably designed as of a point in time. A SOC 1 Type 2 reports on whether those same controls operated effectively over a period, typically 3 to 12 months. Most user auditors want Type 2, with an observation window that covers their client's fiscal year.

The decision framework, observation-window mechanics, and when Type 1 makes sense as a first-year deliverable live in SOC 1 Type 1 vs Type 2.

What's in a SOC 1 report

A finished SOC 1 report has the same five-section shape as a SOC 2. The labeling is familiar if you have read one before (see what a SOC 2 report actually tells your buyer for the SOC 2 walkthrough):

• Section 1: Independent service auditor's opinion. One page. The word the user auditor is looking for is unqualified.
• Section 2: Management's assertion. The service organization's own written statement that the system description is fair and the controls were suitably designed (Type 1) or designed and operating (Type 2).
• Section 3: System description. How the service actually works: in-scope systems, subservice organizations, boundaries, commitments, and the control objectives management has defined.
• Section 4: Controls, tests, and results. For every control, the auditor's test procedure and its result. A table with an Exceptions column that user auditors scan first.
• Section 5: Other information provided by management. Optional. Unaudited. Context the user auditor can use or ignore.

The control objectives in Section 3 are the tell between SOC 1 and SOC 2. In a SOC 1 they read like "Controls provide reasonable assurance that payroll disbursements are calculated in accordance with authorized pay rates and approved hours." In a SOC 2 they read like "Controls provide reasonable assurance that logical access to production systems is restricted to authorized personnel." Same document shape, different questions.

Complementary User Entity Controls

The thing founders do not expect on their first SOC 1 is the CUEC section. Complementary User Entity Controls are the controls the service organization assumes its customers are operating on their own side for the combined system to achieve the stated objectives.

A payroll processor's CUECs might include: the user entity reviews the payroll register each pay period before funding; the user entity maintains current authorized-signer lists; the user entity reconciles payroll tax filings to its general ledger quarterly.

CUECs matter for two reasons. First, the user auditor tests them on their side. If they are written vaguely, the user auditor cannot design a test, and the CUEC becomes a friction point that bounces back to you. Second, CUECs are the boundary between your responsibility and the customer's. A well-drafted set of CUECs is the reason a Section 4 exception does not automatically become a material weakness at the user entity.

A SOC 2 sells your security posture. A SOC 1 lets your customer's auditor sleep.

SecurancePro performs SOC 1 engagements as the service organization's auditor. We issue the report in Section 1. We are not the user entity's financial-statement auditor and we do not sign their 404(b) opinion. That separation is structural, required by independence rules, and the reason our report carries weight when their auditor reads it.

SOC 1 vs SOC 2

Short version: SOC 1 is about ICFR. SOC 2 is about vendor trust, security, availability, processing integrity, confidentiality, privacy. A buyer's finance team and their auditor ask for SOC 1. A buyer's security team asks for SOC 2. The control libraries overlap on the infrastructure layer (access management, change management, backups) and diverge on everything else.

If you are orienting to SOC 2 itself, what is SOC 2 is the pillar. If you want the side-by-side decision post, SOC 1 vs SOC 2 walks through which report your buyers are actually asking for. Some service organizations also publish a SOC 3, a short public-facing version generated from a SOC 2 Type 2, covered in SOC 3 reports.

When you need both

Plenty of our clients need both. A payroll SaaS sold into public-company finance teams is the canonical example: the CFO's auditor wants SOC 1, the CISO's vendor-risk team wants SOC 2, and neither will accept the other as a substitute.

When you run both, the control inventory is shared on the infrastructure side and diverges on the business-process side. Done once, it is roughly one and a third audits, not two. Done as two separate projects by two separate firms with two separate readiness passes, it is close to two audits and a lot of duplicative evidence requests. Scope them together.

---

If your prospect's auditor has asked for "the SOC 1" and you have not scoped the engagement yet, get in touch or see the services we offer. We will help you size Type 1 versus Type 2 and draft CUECs your customers' auditors can actually test.