SOC 1 reports,
explained plainly

SOC 1 is an attestation report on the controls at a service organization that are relevant to its user entities’ internal control over financial reporting. The AICPA calls it a "report on controls at a service organization relevant to user entities’ internal control over financial reporting", which is a mouthful, so everyone says SOC 1. It is performed under the attestation standard SSAE 18, specifically AT-C section 320, by a licensed CPA firm, and the deliverable is a report carrying that firm’s opinion.

The phrase that matters is "user entities". A user entity is a customer that relies on your service in a way that affects its own financial statements: you run their payroll, administer their fund, process their payments, calculate their claims or host the system their ledger depends on. Their auditors have to form a view on controls they cannot see, because those controls live inside your organization. A SOC 1 report is how they get that view without auditing you themselves.

Like every SOC report, SOC 1 is not a certification. Nobody is "SOC 1 certified" and there is no certificate to frame. What you have, after the examination, is a report: a description of your system, the control objectives you set, the controls behind them, the tests the auditor performed and the opinion they reached. That report is the product, and it is what your customers’ auditors actually read.

Every public company, and plenty of private ones, has to maintain internal control over financial reporting: the set of controls that gives reasonable assurance its financial statements are reliable. Their auditors test those controls each year. When part of the process runs at an outside service provider, the control is still the customer’s responsibility, but the evidence sits with you.

Before SOC 1 existed the options were bad. Either every customer’s auditor sent their own team to test your controls, or they took your word for it, or they treated the whole outsourced process as an untested black box and did more work around it. A SOC 1 report gives every one of those auditors a single, independent examination they can rely on, performed once, by a firm they can hold to a professional standard.

That origin shapes everything about the report. Scope is defined by what affects the customer’s numbers, not by what a security team would prioritize. The people who read it are auditors and controllers, not CISOs. And the report is deliberately restricted in use, because its detail is meant for a reader who already relies on your service and needs to understand exactly how it is controlled.

A Type 1 report describes your system and states whether the controls, as designed on a specified date, are suitable to achieve the control objectives. It is a snapshot. The auditor examines the design and the description, not whether the controls actually ran the day before or the month before.

A Type 2 report covers a period, commonly six to twelve months, and adds an opinion on operating effectiveness: did each control actually operate, consistently, across that window. The auditor samples evidence throughout the period, from reconciliations and access reviews to change tickets and exception reports, and reports the results test by test, including any exceptions found.

A user entity’s auditor gets very little from a Type 1. A control that was well designed on one day says nothing about the eleven months of transactions they are auditing, so Type 2 is what customers ask for and what their auditors need. Type 1 is a sensible first step to establish the description and the control objectives, but it is rarely the destination.

This is where SOC 1 differs most from SOC 2. SOC 2 comes with the Trust Services Criteria, a published list you are measured against. SOC 1 has no such list. You, the service organization, define the control objectives your system is meant to achieve, and the examination tests whether your controls support them. Management asserts that the objectives are appropriate and the controls achieve them, and the auditor opines on that assertion.

The objectives follow the money. For a payroll processor they read like "controls provide reasonable assurance that payroll is calculated completely and accurately and paid only to authorized employees". For a fund administrator they cover valuations, capital calls and investor allocations. Alongside those business objectives every SOC 1 carries IT general control objectives, because the application controls above depend on them: logical access, change management, computer operations and backup, and often physical access.

Writing good objectives is most of the design work. Too vague and the auditor cannot test them; too many and you have signed up to evidence controls no customer cares about. The right set is the smallest that covers what your customers’ auditors will actually ask about, which is usually a short list of business process objectives plus the handful of IT general control objectives that keep those processes honest.

The system description is the backbone of the report. It says which service is covered, which processes and applications run it, which people are involved, how transactions flow from initiation to reporting, and which controls exist at each step. A reader has to be able to follow a transaction through your organization on paper and see where it is controlled.

Scope should track the services that feed customer financial statements, and stop there. A product line that customers use for something unrelated to their books adds pages and evidence without adding assurance. The boundary also decides what your customers’ auditors can rely on: anything outside the description is, for their purposes, untested.

The test is whether your output lands in a customer’s financial statements. Payroll and HR processors, fund administrators and transfer agents, payment and billing processors, claims and benefits administrators, lending platforms and loan servicers, and data centres or SaaS platforms hosting a customer’s accounting, billing or trading system all sit squarely in that group. If a customer’s auditor would need to understand your controls to sign off on their numbers, you will be asked.

The request usually arrives from a customer’s finance team or audit firm rather than from procurement, and it often arrives with a deadline attached to the customer’s own year end. That timing is worth understanding early: a Type 2 has to cover a period that overlaps the customer’s fiscal year, so a first report often has to be planned a year before the auditor needs it.

Plenty of software companies are asked for SOC 1 when what the customer actually needs is SOC 2, and the reverse. A blunt question settles it: does your service affect the amounts in the customer’s ledger, or does it affect the security of their data. If the former, SOC 1. If the latter, SOC 2. If both, you will probably end up with both reports, and the good news is that they share most of their IT general controls.

Only an independent, licensed CPA firm can issue a SOC 1 report, and that independence is what lets a customer’s auditor rely on it. The firm reviews your system description and management’s assertion, tests the controls behind each objective and issues a report with an opinion. For a Type 2 that means sampling evidence across the period and writing up every test performed and every exception found.

The opinion is the first thing a reader turns to. An unqualified opinion says the description is fairly presented, the controls are suitably designed and, for a Type 2, operated effectively across the period. A qualified opinion calls out an objective that was not met or a control that failed its tests. Exceptions do not automatically qualify an opinion, but every one is listed, and your customers’ auditors will read them and decide what extra work they need to do on their side.

Those readers are the audience to keep in mind while you write the description and pick the objectives. They are controllers and financial-statement auditors who will map your report to their own audit programme. A description written for a security reviewer, heavy on architecture and light on transaction flow, sends them back with questions.

A Type 2 report covers a period, and customers need a report that covers each of their fiscal years, so SOC 1 becomes an annual cycle: a new examination every year, the same controls operating and the same evidence kept. The controls that earned the first report, reconciliations performed and reviewed, access recertified, changes approved and tested, backups verified, are exactly the ones the next examination will sample. Teams that operate them as part of running the business find the annual report largely administrative.

The gap between one report period and the customer’s year end is covered by a bridge letter, sometimes called a gap letter: a short statement from your management confirming that the controls described in the last report have continued to operate without material change. It carries no auditor opinion, but it is what lets a customer’s auditor extend their reliance across the months the report does not cover, and most customers will ask for one.

The auditor’s fee scales with the number of control objectives, the complexity of the transaction flows, the number of applications in scope and whether it is a Type 1 or a Type 2. A Type 2 costs more because there is a period of evidence to sample rather than a single date to inspect. Handling a subservice organization inclusively instead of carving it out adds their controls to your examination and moves the cost accordingly.

As with every SOC report, the larger cost is on your side: designing the controls, writing the description, running the controls every month and keeping the evidence in a form an auditor can sample. Reconstructing a year of reconciliations and access reviews from email at examination time is where first-year projects lose weeks. Keeping that evidence next to the control, as it is produced, is what makes the second year cheaper than the first.

The two levers that move the total are scope and continuity. Keep the objectives to what your customers’ auditors need, and keep the controls and their evidence running between examinations rather than rebuilding them before each one. Most of the cost of SOC 1 is the cost of running a well-controlled service, which is a cost you were going to pay anyway.