SOC 1 Compliance Checklist: What Auditors Test

Last updated August 2026. There is no standard SOC 1 checklist, and that is not a technicality. SOC 2 hands you the AICPA Trust Services Criteria and you map to a fixed list. SOC 1 hands you nothing: your own management writes the control objectives, and the CPA firm tests what you wrote. Every article promising the definitive SOC 1 checklist is really giving you an inventory of IT general controls, which is genuinely useful and is not the report.

So the useful question is not what is on the list. It is what auditors actually test, which parts generalize across every service organization, and which parts you have to write yourself. This walks through both, plus the cost drivers, the Type 1 versus Type 2 decision, and the bridge letter problem that shows up every January.

Is there a standard SOC 1 checklist?

No. The AICPA publishes control criteria for SOC 2 and SOC 3 through the Trust Services Criteria, but it publishes no equivalent for SOC 1. A SOC 1 is performed under AT-C section 320, which tells the service auditor how to conduct the examination, not what your controls should be. Your management states the control objectives, asserts the controls were suitably designed and, for a Type 2, operating effectively, and the auditor opines on that assertion.

The consequence catches people out. Two payroll processors of similar size can produce SOC 1 reports with materially different objectives, and both can be correct. It also means a clean opinion is not automatically a useful one. If you write objectives too narrowly, you can pass the examination, pay the full fee, and still have a report your customer external auditor cannot rely on.

What does a SOC 1 audit actually test?

Four layers, in roughly this order. The first three generalize. The fourth is yours alone.

A Type 2 tests all of this across the period, not at the end of it. That distinction shapes everything about how you prepare, because the auditor draws samples from months you cannot go back and fix.

Who needs a SOC 1 report?

Service organizations whose processing lands in someone else financial statements. Payroll processors, claims administrators, billing and receivables services, loan and mortgage servicers, fund administrators, transfer agents and benefit plan recordkeepers are the classic examples. The list has widened considerably: any SaaS platform that calculates revenue, holds client funds, or produces figures a customer books directly is now a plausible candidate.

The request itself almost never comes from procurement. It comes from your customer external auditor, because AU-C section 402 requires that auditor to understand controls at any service organization relevant to the customer internal control over financial reporting. A SOC 1 is how they get that understanding without auditing you directly. If nobody is relying on you for a number in a financial statement, what you are being asked for is probably a SOC 2 instead, and building the wrong one costs a year.

What are SOC 1 control objectives?

A control objective is a statement of what your controls are meant to achieve for the user entities. A typical one reads like: controls provide reasonable assurance that transactions are recorded completely and accurately in the period in which they occur. Under each objective sit the specific controls that support it, and under each control sits the evidence the auditor will sample.

Writing them is the part that rewards care. Work backwards from the risk your processing creates for the customer, not forward from the controls you happen to have. If your service could cause a customer to overstate revenue, understate a liability, or misstate a cut-off, there should be an objective addressing it. Objectives assembled from controls you already run tend to leave exactly the gaps a user auditor is looking for.

What is the difference between SOC 1 Type 1 and Type 2?

A Type 1 covers the suitability of design and implementation of controls at a single point in time. A Type 2 covers design plus operating effectiveness over a stated period, most commonly six to twelve months, and includes the tests performed and their results.

Type 1 is faster and cheaper and makes sense as a first year step when you have just built the program. It is not a substitute. A user auditor placing reliance under AU-C 402 generally cannot use a Type 1, and no bridge letter is available for one. Most organizations do a Type 1 once, then run an annual Type 2 with a period end chosen to overlap their largest customers financial year. That period end is a commercial decision as much as an audit one.

The checklist that actually generalizes

Strip out what is specific to your service and this is what remains, and it is the layer worth building first because IT general controls carry over into SOC 2, ISO 27001 and SOX Section 404 with very little rework.

• Logical access. Provisioning tied to an approval, deprovisioning tied to a termination date, privileged access restricted and reviewed, and periodic user access reviews with evidence they happened in the months they were supposed to.
• Change management. Changes authorized, tested and approved before production, segregation between who writes and who deploys, and emergency changes documented after the fact rather than invisibly.
• IT operations. Job scheduling and failure handling, backup and restoration testing, incident management, and monitoring with evidence of what was done when something fired.
• Vendor and subservice oversight. A current list of subservice organizations, a decision recorded for each on carve-out or inclusive treatment, and a check that carved-out providers own SOC reports are current and cover the right period.
• The description itself. Kept current through the period, including changes to systems, services and personnel, rather than written from memory in the last fortnight.

Where teams lose evidence is in the ordinary running of the business rather than in the controls themselves. Manual steps generate exceptions. A finance team reconciling collections in a spreadsheet hands the auditor a different quality of record than one where the same work runs through a system that follows up on every overdue invoice automatically and logs what it sent and when. The control is the same either way. The evidence is not.

How much does a SOC 1 audit cost?

Published figures vary enough that any single number should be treated with suspicion, and much of what circulates is really SOC 2 pricing relabelled. The most useful attributable data point comes from Linford and Company, an audit firm, which reported in February 2026 that SOC examinations typically run from 20,000 to 150,000 dollars with a median around 30,000, and that engagements with large firms start in the low six figures. They name scope, Type 1 versus Type 2, service complexity, organization size and control maturity, number of locations and subservice relationships as the drivers.

Two practical notes. Readiness work and the examination itself are different purchases and are often quoted together, so compare bundled quotes rather than line items. And the largest cost you control is scope: every additional system, location and objective adds fieldwork every year, not once.

What is a bridge letter and when do you need one?

A bridge letter, sometimes called a gap letter, is a statement from your management that nothing material changed between the end of your report period and a customer financial year end. It typically covers no more than three months.

The thing to understand is that it is unaudited. Your management signs it, not the service auditor, and it is only available for a Type 2. Some user auditors decline bridge letters entirely, and few will accept one covering a long gap. If a large share of your customers close in December and your period ends in June, the answer is usually to move your period end, not to write longer letters.

Is SSAE 18 still the current standard?

Yes, and a surprising amount of published guidance says otherwise. SSAE 21, effective for reports dated on or after June 15, 2022, revised AT-C 205 and introduced direct examinations at AT-C 206. It did not touch AT-C 320, the SOC 1 section that SSAE 18 created. A SOC 1 issued in 2026 is performed under AT-C 320 layered on AT-C 105 and AT-C 205 as revised, with the SSAE 23 quality management amendments applying to engagements beginning on or after December 15, 2025.

What is genuinely obsolete is SSAE 16, superseded in 2017 and still cited in vendor marketing and security questionnaires. And there is no certificate at any point in this. Nobody is SOC 1 certified, SSAE 18 certified or SSAE 16 certified. The deliverable is a licensed CPA firm opinion on management assertion, which is a different kind of object from a certification, and answering a questionnaire as though you hold one is a misstatement a careful buyer will find.

Where to start

Settle the report type first by asking who is requesting it and why. A customer external auditor wants a SOC 1. A customer security team wants a SOC 2. If both are asking, you need both, and the IT general controls layer underneath serves each of them.

Then write the control objectives before you buy anything, working from the risks your service creates for your customers numbers. Once those exist, the rest is an evidence problem: proving each control ran in every month of the period, keeping the description of the system honest as things change, and knowing where your carved-out providers coverage ends. That is what SOC 1 compliance software is for, and it is why treating the examination as an annual scramble rather than a maintained record is what makes audit readiness expensive.