SOC 1 Reports: SSAE 18 and ISAE 3402

A SOC 1 report answers a question that auditors of your customers have to ask: if part of a company's financial reporting runs on your platform, can they trust what your platform does? Payroll calculations, invoices, revenue schedules, payments and the systems behind them all feed financial statements. A SOC 1 report is an independent auditor's opinion on the controls you operate over those processes, which your customers and their auditors can rely on instead of auditing you themselves.

For SaaS companies selling finance, HR, billing or payments software to listed or audited companies, SOC 1 often matters as much as SOC 2, and the two are frequently confused. This guide explains what SOC 1 covers, Type 1 and Type 2 reports, SSAE 18 and ISAE 3402, how to define control objectives, how audits work, and how SOC 1 differs from SOC 2.

What is SOC 1?

SOC 1 is one of the AICPA's System and Organization Controls reports. It reports on controls at a service organisation that are likely to be relevant to user entities' internal control over financial reporting (ICFR). It is performed under the AICPA's attestation standard AT-C section 320, part of SSAE No. 18, by a licensed CPA firm. Outside the US, the equivalent engagement is performed under ISAE 3402, issued by the International Auditing and Assurance Standards Board, and many auditors issue reports that satisfy both.

A SOC 1 report includes:

The service auditor's opinion.
Management's written assertion about the description and the controls.
The description of the system: services, processes, IT systems, control objectives and related controls, and complementary controls expected of customers and subservice organisations.
For Type 2, the tests of controls and results, including any exceptions.

SOC 1 reports are restricted to the service organisation, its customers (user entities) and their auditors.

History and why SOC 1 exists

For decades, US service organisations provided SAS 70 reports so that customers' auditors could rely on their controls. In 2011 SAS 70 was replaced by SSAE 16 for these reports, and the AICPA introduced the SOC family, naming the financial reporting report SOC 1. SSAE 18, effective in 2017, recodified the attestation standards and added requirements such as reviewing subservice organisations' controls and complementary user entity controls. Internationally, ISAE 3402 was issued in 2009 for the same purpose.

The need grew with outsourcing and the Sarbanes-Oxley Act. When a listed company relies on a payroll processor or a billing platform, its management and auditors must evaluate the controls at that provider as part of ICFR. PCAOB standards for auditors, such as AS 2601, address how they consider a company's use of a service organisation, and a SOC 1 Type 2 report is the usual evidence.

Who needs a SOC 1 report?

Payroll and HR platforms that calculate pay, taxes and deductions.
Billing, invoicing and revenue recognition software and subscription management platforms.
Payment processors, payment facilitators and expense platforms.
Fund administrators, transfer agents and financial back-office providers.
Data centres, hosting providers and IT outsourcers running customers' ERP or financial systems, where IT general controls are in scope.
Claims processors and insurance administrators.

Demand comes mostly from customers that are public companies subject to SOX, but also from private companies with audited financial statements, regulated financial institutions and companies preparing for an IPO. A company that only processes data with no effect on customers' financial statements usually needs SOC 2 instead.

Type 1 vs Type 2

	Type 1	Type 2
Covers	Fairness of the description and suitability of control design at a specified date	The same, plus operating effectiveness of controls throughout a specified period
Usefulness for customer audits	Limited; shows design only	What customers' auditors usually need to rely on controls
Typical use	First report, or a new service	Annual ongoing report

Customers want Type 2 periods that cover most of their financial year. Service organisations often align a 12-month period to the calendar year, or run periods that end in the third quarter and provide a bridge letter from management covering the gap to the customer's year end.

Control objectives and controls

In SOC 1, the service organisation defines control objectives relevant to customers' financial reporting, and the controls that achieve them. Unlike SOC 2, there is no fixed criteria list; objectives are tailored to the service, though auditors and industry practice shape them. Typical objectives for a SaaS billing platform:

Business process objectives

New customer accounts and pricing are set up completely and accurately, with authorisation.
Usage and billable events are captured completely and accurately.
Invoices are calculated accurately according to pricing and terms.
Payments are recorded accurately and timely.
Reports and data provided to customers are complete and accurate.
Interfaces with payment gateways and accounting systems transfer data completely and accurately.

IT general control objectives

Logical access to programs and data is restricted to authorised individuals.
Changes to application programs and infrastructure are authorised, tested, approved and implemented properly.
Processing is scheduled and monitored, and failures are resolved.
Data is backed up and can be recovered.
Physical access to data centres is restricted (often addressed through subservice organisations).

Complementary controls and subservice organisations

Complementary user entity controls (CUECs) are controls the service organisation assumes customers have, for example that customers review the reports they receive, manage their own users' access, and approve pricing changes they request. Customers and their auditors test these, so they must be clear and realistic. Subservice organisations, such as the cloud infrastructure provider, are handled by the carve-out method (excluded, with their own reports relied on) or the inclusive method (included and tested). Under the carve-out method, the report lists complementary subservice organisation controls expected of them.

How to prepare for a SOC 1 report step by step

Talk to customers about which services and processes their auditors care about.
Choose an audit firm experienced in SOC 1 for your industry.
Define the system: services, processes, applications, data flows, interfaces and subservice organisations.
Draft control objectives and controls for business processes and IT general controls.
Run a readiness assessment to find design gaps.
Fix gaps: reconciliations, approvals, access controls, change controls, monitoring of interfaces and batch jobs.
Write the system description and define CUECs clearly.
Complete a Type 1 if customers need something quickly, then start the Type 2 period once controls are operating.
Operate and evidence controls throughout the period.
Support fieldwork, respond to exceptions and issue the report; provide bridge letters as needed.

Designing controls that auditors can rely on

A SOC 1 report is only useful if its controls address the risks customers' auditors care about and can be tested efficiently. A few design principles help:

Prefer automated controls where possible. An automated calculation or validation that is protected by change controls can be tested once per change rather than sampled many times, and auditors can rely on it if IT general controls are effective.
Make review controls precise. "Finance reviews the report" is weak; "the billing operations lead reviews the daily usage-to-invoice reconciliation, investigates variances above a defined threshold and records resolution in the ticket" is testable.
Cover completeness as well as accuracy. Auditors want to know that every transaction was processed, not only that the processed ones are correct. Record counts and control totals at each interface do this.
Control the reports you give customers. If customers use your reports in their own controls, the reports themselves must be complete and accurate, and auditors will ask how you know.
Keep the number of control objectives proportionate. Too few leaves customers' auditors with gaps; too many raises cost and the chance of exceptions without adding assurance.

Documentation you will need

System description with services, processes, systems and control objectives.
Policies and procedures for access management, change management, operations and backups.
Process documentation for transaction flows and calculations.
Evidence of controls: approvals, reconciliations, review sign-offs, access reviews, change tickets, job monitoring records.
Complete, system-generated populations (all changes, all users, all transactions) for sampling.
Subservice organisation reports and your reviews of them.
CUEC list communicated to customers.

Audit and reporting

The service auditor tests the design (Type 1) and operating effectiveness over the period (Type 2) of each control, using inquiry, observation, inspection and re-performance, often re-performing calculations and reconciliations on samples. Exceptions are reported with management responses. The opinion can be unmodified or modified (qualified, adverse or disclaimer) if the description is not fair or controls did not achieve objectives.

Timeline and cost considerations

Preparation time depends on how many control objectives are needed and how automated your controls are. Type 2 periods commonly run six to twelve months, and fieldwork follows the period end. Cost factors include audit firm fees (scope, number of objectives, locations and period length), internal staff time, tooling for evidence collection, and remediation. Many providers combine SOC 1 and SOC 2 fieldwork with the same firm to share IT general control testing.

Benefits and the risk of not having one

A SOC 1 Type 2 report removes the need for each customer's auditor to audit you, shortens sales cycles with audited customers, and forces discipline in processes that handle money. It is often a prerequisite for selling to public companies and financial institutions.

Without one, expect repeated customer audits, detailed questionnaires, audit firms requesting access to your systems, and lost deals with customers whose auditors cannot rely on you. There is no regulatory penalty on the service organisation for not having one.

Common mistakes and challenges for IT companies

Getting SOC 2 when customers need SOC 1, or the reverse.
Control objectives that miss what customers' auditors rely on, such as calculation accuracy or interface completeness.
Manual reconciliations without evidence of review.
Incomplete populations that make sampling impossible.
Unclear CUECs, leaving customers surprised by what they must do.
A report period that does not cover customers' year ends, without bridge letters.

Best practices, tools and technologies

Build automated reconciliations between source systems, your platform and payment and accounting systems, with alerts and recorded reviews.
Log every change to pricing, payroll rules and financial configuration with who, when and approval.
Version calculation logic and test it automatically with known cases before release.
Monitor interfaces and batch jobs, with tickets for failures and evidence of resolution.
Generate audit-ready populations from systems rather than spreadsheets.

We build these controls into ERP and finance systems and the integrations that move financial data.

SOC 1 vs SOC 2 vs SOC 3

	SOC 1	SOC 2	SOC 3
Focus	Controls relevant to customers' financial reporting	Security, availability, processing integrity, confidentiality, privacy	Same as SOC 2, summary form
Criteria	Control objectives defined by the service organisation	AICPA Trust Services Criteria	AICPA Trust Services Criteria
Audience	Customers and their financial auditors	Customers, prospects and their advisors under NDA	General public
Typical driver	SOX and financial audits	Vendor security reviews	Marketing and trust pages

How SOC 1 relates to other frameworks

Framework	Relationship
SOX	The main reason listed customers need SOC 1 reports from providers.
COSO	The internal control framework underlying ICFR.
COBIT	Common reference for IT general control objectives.
SOC 2	Security-focused report; shares IT general control testing.
PCI DSS	Payment processors often need both PCI DSS and SOC 1.

Real-world implementation examples

Large payroll, payments and cloud providers make SOC 1 reports available to customers through their compliance portals, often alongside SOC 2 reports. Customers' auditors routinely request them during annual audits.

An illustrative case for a subscription billing SaaS: a listed customer's auditor asks for a SOC 1. The company defines control objectives for account setup, usage capture, invoice calculation, payment recording and data feeds to customers' ledgers, plus IT general controls. It automates daily reconciliations between usage data and invoices, logs all pricing changes with approvals, and lists CUECs such as customers reviewing invoice reports. After a Type 1 and a first Type 2 period, auditor requests from customers drop to receiving the report and a bridge letter.

Next steps

Confirm with customers whether their auditors need SOC 1, SOC 2 or both.
Define the system and control objectives with an experienced audit firm.
Automate reconciliations and change logging in financial features.
Do a Type 1, then a Type 2 aligned with customers' year ends.
Communicate CUECs and provide bridge letters.

Frequently asked questions

What is the difference between SOC 1 and SOC 2?

SOC 1 covers controls relevant to customers' financial reporting, for their financial auditors. SOC 2 covers security and related Trust Services Criteria, for broader vendor assurance.

Is SOC 1 a certification?

No. It is an attestation report with an auditor's opinion on the description and controls.

What is SSAE 18?

The AICPA's Statement on Standards for Attestation Engagements No. 18, which includes AT-C section 320, the standard for SOC 1 engagements.

What is ISAE 3402?

The international standard for assurance reports on controls at a service organisation, the international equivalent of a SOC 1 engagement.

Do we need SOC 1 if our customers are not public companies?

Possibly. Any customer with audited financial statements, or a regulated financial institution, may ask for one if your service affects its financial reporting.

How long does a SOC 1 Type 2 period last?

Commonly six to twelve months. Most providers move to a continuous 12-month cycle.

What is a bridge letter?

A letter from the service organisation's management covering the period between the end of the last report and a customer's year end, stating whether there have been significant changes.

Who can issue a SOC 1 report?

A licensed CPA firm under AICPA standards; ISAE 3402 reports are issued by qualified auditors under the IAASB standard.

Can SOC 1 and SOC 2 be done together?

Yes. Many firms perform both in coordinated engagements, sharing testing of IT general controls.

What are complementary user entity controls?

Controls the service organisation expects customers to perform, such as reviewing reports and managing their users, which are needed for the control objectives to be achieved.

Does a cloud provider's SOC 1 cover our SaaS?

No. It covers the provider's infrastructure controls. Your SOC 1 typically carves out the provider and covers your own processes and IT general controls.