When You Need SOC 1 and SOC 2 Together: A Dual-Report Guide

Who actually needs both — the trigger test

The reliable way to decide is not to memorize a list of industries; it is to ask who will read your reports. SOC reports are restricted-use documents written for specific audiences, and each report answers a different question for a different reader.

You need SOC 1 when a control at your organization could affect a customer’s internal control over financial reporting (ICFR) — for example, you calculate payroll, move money, adjudicate claims, or produce the billing records that feed a customer’s revenue. Their financial-statement auditor (the “user auditor”) needs assurance over your controls to complete their audit.

You need SOC 2 when you store or process customer data and their security, procurement, or GRC team demands assurance that you protect it. That request usually arrives as a security questionnaire during enterprise procurement.

When both readers exist for the same platform, you need both reports. A worked example makes it concrete: for a payroll platform, the SOC 1 covers control objectives such as payroll calculation accuracy, completeness, and authorization — read by clients’ financial auditors — while the SOC 2 covers that same platform’s access management, encryption, and change controls, read by clients’ security teams. If you only face one reader, you likely need only one report; our sibling guide on SOC 1 vs SOC 2 for B2B software vendors walks through choosing the single report.

SOC 1 vs SOC 2: what each report actually is

Both are “SOC for Service Organizations” examinations performed by a licensed CPA firm, but they sit on different attestation standards and test fundamentally different things.

What SOC 1 tests: management-defined control objectives

SOC 1 examinations are performed under SSAE No. 18, AT-C section 320, and report on controls at a service organization that are relevant to user entities’ internal control over financial reporting. Crucially, SOC 1 has no fixed control set. The service organization defines its own control objectives — typically a set of IT general controls (access, change, operations) plus business-process objectives such as transaction completeness, accuracy, authorization, and cut-off. The auditor then tests whether the controls achieve those stated objectives. Your SOC 1 audit is therefore as much about your business processes as your systems.

What SOC 2 tests: the fixed Common Criteria (CC1–CC9)

SOC 2 examinations are performed under AT-C section 105 (concepts common to all attestation engagements) plus AT-C section 205, which SSAE No. 21 superseded and retitled “Assertion-Based Examination Engagements” (effective for reports dated on or after June 15, 2022). SSAE 21 brought terminology and clarification changes and also introduced a new AT-C section 206 for direct engagements — but it made no substantive change to how a SOC 2, which is an assertion-based examination, is conducted. SOC 2 reports against the AICPA’s Trust Services Criteria (the 2017 criteria, with revised points of focus published in 2022). Unlike SOC 1, these criteria are pre-defined by the AICPA, not chosen by management.

Security — the Common Criteria — is the only mandatory category. It comprises the Common Criteria series CC1–CC9: control environment (CC1), communication and information (CC2), risk assessment (CC3), monitoring activities (CC4), control activities (CC5), logical and physical access controls (CC6), system operations (CC7), change management (CC8), and risk mitigation (CC9). The four optional categories — Availability, Processing Integrity, Confidentiality, and Privacy — are added only when relevant to what you promise customers. For the full control breakdown, see our SOC 2 controls list by Trust Services Criteria.

Why they cannot be merged. This is the single most important structural point for a dual-report program: because SOC 1 uses management-defined control objectives while SOC 2 uses the AICPA’s fixed criteria, the two examinations reach two different conclusions against two different frameworks. Even in a fully combined engagement, the auditor issues two separate opinions in two separate reports. There is no such thing as a single merged “SOC 1 + SOC 2” report.

Do you need both? A decision matrix

Apply the “follow the report reader” test to your own service. The matrix below shows the common patterns, but each row is derivable: if a control affects the customer’s financials, you need SOC 1; if a customer’s security team demands data assurance, you need SOC 2.

Payroll, benefits & HRIS platforms

These platforms sit squarely inside customers’ financial reporting: payroll expense, tax withholding, and benefit accruals all flow into the general ledger. Their auditors will ask for a SOC 1 covering calculation accuracy and completeness. At the same time, HRIS platforms hold sensitive employee data, so enterprise buyers demand a SOC 2. This is the textbook “need both” case.

Payments, fintech & BPO / transaction processing

If you move, settle, or reconcile money, transaction completeness and accuracy are ICFR-relevant — SOC 1 territory. The same systems require SOC 2 because they handle account data and are scrutinized by security teams. Business-process outsourcers running finance operations for clients are almost always in the both bucket.

Expense, AP automation, billing & revenue platforms

Expense and accounts-payable tools authorize and record spend; billing and revenue platforms produce the records behind recognized revenue. All of these affect customers’ financial statements (SOC 1) and store financial and personal data that security teams vet (SOC 2).

Healthtech handling PHI + claims (and where HIPAA fits)

A healthtech platform that adjudicates or processes claims can affect payers’ and providers’ financial records (SOC 1) and stores protected health information that security teams review (SOC 2). Because it handles PHI, it also has HIPAA obligations as a business associate — a separate legal regime that can be mapped alongside SOC 2. See our guide to multi-framework control mapping across SOC 2, HIPAA, and GDPR to avoid audit fatigue.

When you only need one

If your service never touches a customer’s financial statements — a collaboration tool, an analytics dashboard, a pure hosting layer — you almost certainly need only SOC 2. If your only reader is a customer’s financial auditor and no security team is requesting data assurance, SOC 1 alone may suffice. When the choice is genuinely one-or-the-other, start with SOC 1 vs SOC 2 for B2B software vendors.

Where SOC 1 and SOC 2 controls overlap — the ITGC core

The reason a combined engagement is efficient is that the two reports share a large body of IT general controls (ITGCs). SOC 1 tests these as ITGC control objectives; SOC 2 tests the same underlying controls under its Common Criteria. A single, well-organized evidence set can support both when the examinations run concurrently. This is widely accepted practice rather than a codified AICPA rule — but it is how experienced firms scope a dual-report program.

Shared: logical access, change management, system operations

The densest overlap is access (CC6), system operations (CC7), and change management (CC8). These map almost one-to-one to the ITGC objectives in a typical SOC 1. Evidence such as access recertifications, change tickets, and monitoring alerts is pulled once and referenced by both examinations.

Unique to SOC 1: business-process and transaction controls

What never appears in SOC 2 is the business-process layer: control objectives over transaction completeness, accuracy, authorization, valuation, and cut-off. These are the controls that make SOC 1 meaningful to a financial auditor — and they are defined by your management, not by any fixed criteria.

Unique to SOC 2: the optional Trust Services categories

Conversely, the optional SOC 2 categories — Availability, Processing Integrity, Confidentiality, and Privacy — have no counterpart in a standard SOC 1. If you commit to these to customers, they add criteria (and cost) on the SOC 2 side only.

How to run a combined SOC 1 + SOC 2 engagement

A combined engagement is not one report; it is one coordinated effort producing two reports. The mechanics below are how Auditsuisse structures a dual-report program — and they are the source of the efficiency. For the underlying approach, see our audit methodology.

1. Scope both reports together. Define one system boundary, then map it to SOC 1 control objectives and SOC 2 criteria in a single scoping pass. Use our guide to scoping systems for SOC 2 as the starting point and extend it with your business-process objectives.
2. Align the observation periods. Set both Type II examinations to cover the same window (commonly 6–12 months) so one period of evidence satisfies both. Aligning the periods is what makes shared ITGC evidence possible — see SOC 2 Type I vs Type II for how the observation window works.
3. Map the overlapping ITGCs once. Tag each shared control to both its SOC 1 objective and its SOC 2 criterion so it is walked through and tested a single time.
4. Build one evidence calendar. Feed both reports from a single governed repository and schedule. Our audit evidence management best practices explain how to keep that evidence attributable and reusable.
5. Run a single fieldwork effort. The auditor performs shared walkthroughs and sampling once, then adds the SOC 1-only business-process testing and any SOC 2-only category testing.
6. Issue two opinions. The engagement concludes with two separate reports and opinions — SOC 1 under AT-C 320 and SOC 2 under AT-C 205.

One scope, one evidence calendar, two opinions

The operating principle is “collect once, report twice.” A control owner uploads an access recertification a single time; it is referenced by the SOC 1 access objective and the SOC 2 CC6 criterion. That eliminates the duplicated evidence requests that make sequential engagements painful.

Subservice organizations: carve-out vs inclusive, CUECs, and consistency

Both reports must address subservice organizations (such as your cloud provider) using either the carve-out method (the subservice organization is excluded from your scope, and its complementary subservice organization controls, or CSOCs, are disclosed) or the inclusive method (its controls are tested within your report). Both reports also disclose complementary user entity controls (CUECs) — the controls your customers must operate for yours to be effective. The practitioner point that competitors rarely make: the same subservice organization must be treated consistently (carve-out or inclusive) across both reports, and the CUECs you disclose must reconcile between them, or a customer comparing the two will find a discrepancy.

Sequencing and prioritization when budget is phased

When you cannot fund both at once, sequence deliberately. The options below trade speed, cost, and buyer coverage.

Which first? If enterprise procurement is blocking deals, lead with SOC 2, since security questionnaires demand it. If a customer’s financial auditor has formally requested assurance, lead with SOC 1. Either way, aim to converge on a single aligned Type II period as soon as budget allows — running them separately is the most expensive path because the ITGC core gets tested twice.

Cost and efficiency: why together beats sequential

No reputable firm publishes a hard combined price or a fixed savings percentage, and neither will we — scope drives cost. What is defensible is the direction: because SOC 1 and SOC 2 share the ITGC core, a combined engagement reuses walkthroughs and evidence, so the incremental cost of the second report is materially lower than commissioning it standalone. Auditsuisse quotes a single fixed fee after a short scoping call.

The cost drivers to plan around, framed directionally as the industry does:

• Optional SOC 2 categories add cost only on the SOC 2 side. Availability and Confidentiality are commonly cited as smaller add-ons; Processing Integrity and Privacy as larger ones, because Privacy in particular expands scope substantially.
• Type I credit toward Type II. When you phase through a Type I, firms commonly credit a portion of the Type I effort toward the subsequent Type II completed in the same cycle.
• SOC 1 business-process testing is incremental. The unique SOC 1 work — transaction control objectives — is the part that does not overlap and therefore carries its own cost regardless of the combined structure.
• Evidence maturity lowers both. Going into fieldwork with mature, well-organized evidence reduces the cost of each report.

Keeping both reports current: bridge letters and renewals

SOC reports are not certificates; they are recurring examinations covering stated periods, so both reports must be renewed — usually annually. Running them on an aligned observation period keeps the renewal cadence synchronized, which is far easier to manage than two drifting cycles.

Between a report’s period-end date and the date a buyer reviews it, you cover the gap with a bridge letter (gap letter) — a management-signed statement that no material changes have occurred since the last report. Because it is management’s representation rather than auditor-tested assurance, industry practice limits it to roughly 90 days, and it can never replace a fresh report. In a dual-report program you maintain two bridge letters, and they must be coordinated so that sales and procurement always have current coverage for each report at any moment.

Common mistakes with dual-report programs

Treating it as one merged report. The most common misconception is expecting a single “SOC 1 + SOC 2” document. Because the criteria differ, two opinions are mandatory — plan for two reports from day one.

Misaligned observation periods. If the two Type II windows do not line up, you forfeit most of the shared-evidence efficiency and effectively run two engagements. Align the periods before fieldwork begins.

Inconsistent subservice treatment. Carving out AWS in one report and including it in the other — or disclosing different CUECs — creates a discrepancy that sophisticated buyers will notice. Reconcile subservice treatment and CUECs across both reports.

Forgetting the business-process layer. Teams that scope from a SOC 2 mindset sometimes under-build the transaction control objectives that give SOC 1 its value to a financial auditor. Scope the business-process controls explicitly.

Uncoordinated bridge letters. Letting one report’s bridge letter lapse while the other is current leaves a coverage gap in procurement. Track both period-end dates and both bridge letters together.

Glossary of key terms

ICFR (Internal Control over Financial Reporting)

The controls that give reasonable assurance about the reliability of financial reporting. SOC 1 exists to give a customer’s auditor assurance over your controls that could affect their ICFR.

Control objective vs control criteria

SOC 1 tests management-defined control objectives; SOC 2 tests the AICPA’s fixed Trust Services Criteria. This difference is why the two reports cannot be merged.

Carve-out vs inclusive method

Two ways to treat a subservice organization: carve-out excludes it and discloses its complementary controls (CSOCs); inclusive tests its controls inside your report.

CUEC (complementary user entity control)

A control your customer must operate for your controls to achieve their objective — disclosed in the report and expected to reconcile across both SOC 1 and SOC 2.

Bridge letter (gap letter)

A management-signed statement covering the interval between a report’s period end and the current date; limited to about 90 days and not a substitute for a new report.