SOC 1 vs SOC 2: Differences and Which Report You Need

In SOC 1 vs SOC 2, the difference is whose risk each report addresses. A SOC 1 report covers a service organization’s controls that are relevant to its customers’ financial reporting, and it is written for those customers’ controllers and external auditors. A SOC 2 report covers controls relevant to security, availability, processing integrity, confidentiality and privacy, and it is written for customers’ security and vendor-risk teams. Both are attestation reports signed by a CPA firm, both come as Type 1 or Type 2, and a company that processes payroll, payments or billing data often needs both.

Invadel is a penetration testing company, not a CPA firm, so we issue neither report. We provide the testing evidence that sits beside them: a SOC 2 penetration test scoped to your system boundary, usually built around a web application penetration test from $5,200 (pricing by size), with a free retest and an attestation letter included. Our starting prices are published on our pricing page.

SOC 1 vs SOC 2 vs SOC 3 at a glance

	SOC 1	SOC 2	SOC 3
Question it answers	Do the vendor’s controls protect our financial statements?	Do the vendor’s controls protect our systems and data?	The SOC 2 question, in summary
Attestation standard	AT-C section 320	AT-C sections 105 and 205	AT-C sections 105 and 205
Measured against	Control objectives the service organization’s management defines	The AICPA’s Trust Services Criteria	The Trust Services Criteria
Main readers	Customers’ controllers and financial statement auditors	Customers’ security and vendor-risk teams, prospects, regulators	Anyone
Distribution	Restricted to customers and their auditors	Restricted to parties with a business need, usually under NDA	General use, can be posted publicly
Type 1 and Type 2	Both	Both	Usually based on a Type 2
Penetration testing	Not expected by the standard	Named in the CC4.1 points of focus; expected by most auditors	Inherited from the SOC 2 behind it

“SOC” stands for System and Organization Controls. Type 1 and Type 2 are also written Type I and Type II; they are the same reports. Neither SOC 1 nor SOC 2 is a certification.

What a SOC 1 report covers

A SOC 1 examination is performed under AT-C section 320 of the AICPA attestation standards, the section that came in with SSAE No. 18 (which is why a SOC 1 is still sometimes called an SSAE 18 report), and its subject is narrow by design: controls at a service organization that are likely to matter to its customers’ internal control over financial reporting. In the language of the AICPA’s SOC 1 guide, your customers are user entities and their auditors are user auditors.

What makes SOC 1 different:

• Your management writes the control objectives. There is no predefined list. Management sets objectives such as “payroll transactions are processed completely, accurately and on time,” and the auditor tests the controls you say achieve them. AWS describes its own SOC 1 as an audit of controls and objectives AWS defines (AWS SOC FAQs).
• Objectives come in two kinds. Business process objectives cover the transactions: input, processing, output and reconciliation. IT general control objectives cover logical access, change management and computer operations such as backups and job scheduling.
• The audience is narrow. AWS lists the intended users of its SOC 1 as customer management and their auditors.

The report also lists complementary user entity controls, the things your customer must do for your controls to work, such as reviewing the payroll register you send back. Microsoft’s reports call these user entity responsibilities (Microsoft Learn). Subservice organizations, such as your cloud provider, are either carved out or included; the AICPA’s 2025 edition of the SOC 1 guide adds further guidance on them and covers reporting under both methods.

Why SOC 1 exists: Sarbanes-Oxley and financial audits

Under Section 404 of the Sarbanes-Oxley Act, a public company’s annual report must include management’s assessment of its internal control over financial reporting, and for accelerated and large accelerated filers that are not emerging growth companies, the outside auditor must attest to that assessment. When that company outsources payroll, billing or transaction processing to you, your controls become part of its controls, and your SOC 1 Type 2 is how its auditor gets evidence about them. Microsoft notes its customers use its SOC 1 Type 2 for Sarbanes-Oxley, FFIEC and GLBA obligations. A SOC 1 does not cover the security testing GLBA expects of a financial institution itself: 16 CFR 314.4(d)(2) calls for continuous monitoring or annual penetration testing, which is GLBA Safeguards Rule testing. SOC 1 replaced the old SAS 70 report; its international counterpart is ISAE 3402.

SOC 1 Type 1 vs SOC 1 Type 2

A SOC 1 Type 1 gives an opinion on whether controls were suitably designed and in place on a single date. A SOC 1 Type 2 adds an opinion on whether they operated effectively over a period. A customer’s auditor relying on your controls needs evidence for the year being audited, so the Type 2 is what most of them request.

Established providers usually report on twelve-month periods: AWS publishes SOC 1 reports quarterly, each covering twelve months, and Microsoft 365 is examined over October 1 through September 30. When your period ends before a customer’s fiscal year does, the gap is covered by a bridge letter (or gap letter) from your management. Microsoft describes its bridge letters as self-attestations, not reports based on an auditor’s examination, and issues them quarterly to cover the prior three months. A bridge letter fills a gap; it never replaces the next report.

What a SOC 2 report covers

A SOC 2 examination is performed under AT-C sections 105 and 205 against TSP section 100, the 2017 Trust Services Criteria, now with points of focus revised in 2022 (Microsoft Learn). The AICPA supplies the criteria in five categories: Security (the common criteria CC1 to CC9, in every report), plus Availability, Confidentiality, Processing Integrity and Privacy when your commitments make them relevant. You design the controls; the CPA firm tests them. Every criterion, with example controls and evidence, is in our SOC 2 controls list.

A SOC 2 is restricted too, but more widely. AWS describes its audience as users with a business need, which in practice includes prospects under NDA. Enterprise buyers generally want a Type 2; our guide to SOC 2 Type 1 vs Type 2 covers the timing and the penetration test evidence each needs.

What is changing. The AICPA’s October 2026 exposure drafts would revise the Trust Services Criteria for engagements beginning on or after December 31, 2027, with early adoption permitted and public comment open through January 15, 2027 (our SOC 2 controls list covers what they add), and SOC 1 is unaffected because it does not use those criteria.

Where SOC 3 fits

SOC 3 reports against the same criteria as SOC 2 but leaves out the detailed system description, the tests and the results, which is why the AICPA treats it as a general use report that can be freely distributed. Vendors post it on trust pages. In practice a SOC 3 is issued from the same examination as a SOC 2, so it is not a cheaper substitute for one. It helps early in a sales cycle, but a security reviewer will still ask for the SOC 2. There is no general use version of a SOC 1. The AICPA’s SOC suite also includes SOC for Cybersecurity and SOC for Supply Chain; neither replaces a SOC 1 or SOC 2 in a vendor review.

Which report do you need?

Start with who sent the request and how it is worded.

Who is asking	What the request usually says	What they need
A customer’s controller or external auditor	“Send your SOC 1 Type 2 and a bridge letter through December 31.”	SOC 1 Type 2
A customer’s security or vendor-risk team	“Send your SOC 2 Type 2 and a summary of your latest penetration test.”	SOC 2 Type 2 plus a pentest attestation letter
A bank or sponsor-bank partner	A due diligence questionnaire asking for SOC reports and security testing results	Often both reports, plus pentest results
A prospect early in a sales cycle	“Do you have a SOC 2?”	SOC 3, or SOC 2 under NDA

The bank row comes from the regulators. The Interagency Guidance on Third-Party Relationships, issued in June 2023 by the Federal Reserve, the FDIC and the OCC, says a bank may consider reviewing a third party’s SOC reports during due diligence, and separately names the results of vulnerability and penetration tests as useful information about its security. Banks are held to testing expectations of their own, which is the subject of our bank and credit union penetration testing page.

Then look at what your service does:

• It affects customers’ financial reporting (payroll, benefits administration, billing, revenue or expense management, payment processing, loan servicing, fund administration): you need a SOC 1, and almost certainly a SOC 2, because the same customers’ security teams will ask.
• It runs infrastructure customers’ financial systems depend on (data centers, hosting, managed IT): auditors often want a SOC 1 covering your IT general controls; security teams want a SOC 2.
• It holds customer data but does not touch their financial statements (most B2B SaaS and developer tools): SOC 2 only.
• You sell to hospitals: SOC 2, often followed by HITRUST; see HITRUST vs SOC 2. You sell internationally: often ISO 27001 too; see ISO 27001 vs SOC 2.

Can a SOC 2 stand in for a SOC 1, or the reverse?

Rarely well. A SOC 2 is not built around financial statement assertions, so a customer’s auditor handed one often performs extra procedures at your customer instead. A SOC 1 handed to a security reviewer may cover logical access and change management, but not vulnerability management or incident response. Give each audience the report built for it.

Having both: how SOC 1 and SOC 2 overlap

The IT general controls in a SOC 1 (logical access, change management, computer operations) cover much of the same ground as the SOC 2 common criteria, so one control, evidenced once, can feed both reports. Many CPA firms run the two examinations together over the same period and test shared controls once; when you compare SOC 2 audit firms, ask whether each issues SOC 1 reports and how it handles a combined engagement. Combined does not mean one report for the price of one: the business process objectives are tested for the SOC 1 only, and each report keeps its own system description, management assertion and opinion, so ask for the added fee as a separate line.

What does not overlap: SOC 1’s business process objectives (complete and accurate processing, reconciliations, the reports customers book from), and SOC 2’s governance and security criteria with no financial reporting link (risk assessment, monitoring, vulnerability management, incident response, vendor management).

If you carry both, keep one control matrix tagged to both reports, align the period ends so one fieldwork season covers both, and date one penetration test inside the period.

Where penetration testing fits in each report

Report	Does the standard mention penetration testing?	What it means for you
SOC 1	No. There are no predefined criteria; your management writes the objectives	Not required. If you list a test as a control, the auditor tests it like any other
SOC 2	As guidance: a CC4.1 point of focus lists penetration testing, with independent certification and internal audit, among the ongoing and separate evaluations management can use, and CC7.1’s points of focus name vulnerability scanning	Plan a test inside each Type 2 period, early enough to fix and retest
SOC 3	Not at the level of detail published	Covered by your SOC 2 testing
Customer due diligence	Banking guidance names penetration test results	Expect to share an attestation letter whichever report you hold

Think before you list a penetration test as a SOC 1 control. If your logical security objective includes “an independent penetration test is performed annually and high-risk findings are remediated,” the auditor tests exactly that. A test that slips past the period end, or a critical finding still open at cutoff, becomes a printed exception. List it only if you will run it on schedule every period, and keep testing either way, because customers’ security teams will ask for the letter.

For SOC 2, the retest matters as much as the test. The engagement is evidence of an evaluation under CC4.1, and of logical access (CC6.1) and protection against external threats (CC6.6) on the systems tested. The remediation tickets and retest show deficiencies corrected (CC4.2) and vulnerabilities acted on (CC7.1). Our SOC 2 pentest requirements guide covers timing, and the SOC 2 evidence checklist lists what to hand the auditor.

If you have not chosen a tester yet, our comparison of SOC 2 penetration testing providers is the next step.

What testing costs for a SOC 1 and SOC 2 vendor

These are Invadel’s published starting prices, each fixed in writing from your scope details with no sales call. Every engagement includes a free retest of remediated findings, executive and technical reports with findings mapped to the controls your auditor examines (the Trust Services Criteria for SOC 2), and an attestation letter you can share with customers and their auditors.

Company	What to test	From (sum of the tests listed)
SaaS startup with a SOC 2 only	Web application penetration test, Small, including the API the app calls	$5,200
Payroll, billing or expense platform with SOC 1 and SOC 2	Web application Medium ($7,800), API penetration test ($4,000), external network test ($4,200)	$16,000
Fintech or processor selling to banks	Web application Medium, API, and a cloud penetration test ($6,800)	$18,600
Data center or managed IT provider	External network plus an internal network penetration test covering Active Directory ($6,000)	$10,200

Each total above is the sum of the tests listed in its row, not a package price. The cost calculator adds up your own mix, and our SOC 2 cost guide covers the auditor’s side of the budget. Testing is done by senior in-house testers, never subcontractors, reports upload into Vanta, Drata and Secureframe, and onboarding starts within 24 hours of a signed proposal. Read a sample report first, or see how we scope penetration testing for fintech companies facing bank partner reviews. Send your scope for a fixed price.

Frequently asked questions

What is the main difference between SOC 1 and SOC 2? SOC 1 covers controls relevant to your customers’ financial reporting, for their auditors. SOC 2 covers security and, optionally, availability, processing integrity, confidentiality and privacy, for their security teams. Both are CPA attestation reports with Type 1 and Type 2 versions.

Is SOC 1 or SOC 2 legally required? No US law requires a service organization to obtain either report. Customers’ auditors ask for a SOC 1 because Sarbanes-Oxley Section 404 requires controls over financial reporting to be assessed, and enterprise and bank customers write SOC 2 reports into contracts and due diligence, so the requirement comes from your customers.

What is a SOC 1 Type 2 report? A SOC 1 in which the CPA firm gives an opinion on whether controls relevant to customers’ financial reporting were suitably designed and operated effectively over a period, often twelve months. It is the version customers’ auditors usually need, because a Type 1 covers a single date.

Do I need a SOC 1 if I already have a SOC 2? Only if your service affects customers’ financial reporting and their auditors ask for one.

Does SOC 1 require a penetration test? No. Its objectives focus on processing and IT general controls. But customer due diligence asks for test results whichever report you hold, so plan on testing anyway.

What is a SOC 2+ report? SOC 2+ is the informal name for a SOC 2 examination in which you also ask the auditor to report on additional subject matter against additional criteria, for example mapping the same controls to a second framework a customer asks about. The AICPA describes the auditor then also examining whether that additional subject matter meets the additional criteria. It extends a SOC 2; it does not turn it into a SOC 1.

How long is a SOC 1 or SOC 2 report valid? Neither report carries an expiry date. A Type 2 covers a past period, and each reader decides how old is too old. In practice customers and their auditors expect a new report for every period, usually twelve months, with a bridge letter covering the gap until the next one arrives. AWS, for example, says its reports are generally released about 9 to 10 weeks after the period ends.

Can Invadel perform our SOC 1 or SOC 2 audit? No. Only a licensed CPA firm can issue SOC reports. Invadel provides the penetration testing evidence, from $5,200 for a web application with the retest included.

The short version

SOC 1 is for your customers’ auditors and covers controls over their financial reporting; SOC 2 is for their security teams and covers your controls against the Trust Services Criteria; SOC 3 is the public summary of a SOC 2. If you process money or financial data you will probably need both, and either way customers will ask for a recent penetration test. See what a SOC 2 penetration test covers, compare our published prices (a web application test starts at $5,200 with a free retest), or scope your test for a fixed price in writing the same day.