SOC 1 vs SOC 2 Examination Scope Differences for Service Organizations

A customer asks for "your SOC report," no number attached, and the right answer depends entirely on what that customer's auditor or security team is trying to confirm. Each of these reports answers a different question. SOC 1 addresses whether your controls could affect a customer's financial statements. SOC 2 addresses whether your system handles data securely and reliably. Those are two separate risk domains, each governed by its own standard, and treating the choice between them as a matter of preference, budget, or which report sounds more impressive is how service organizations end up with the wrong document in hand. Handing a SOC 2 to the first group or a SOC 1 to the second does not just waste the money spent on the examination. It fails to answer the question the customer actually asked, and in an auditor's reliance chain, a report that answers the wrong question provides no assurance.

The clearest signal is where the request originates inside the customer's organization. A request from the customer's auditors points to SOC 1: those auditors are trying to determine whether the service organization's controls could affect the customer's financial statements, and SOC 1 is the only report built to answer that question under AU-C 402. A request from a security, vendor-risk, or procurement function points to SOC 2: that group is evaluating how the system handles customer data, which SOC 1 says nothing about. Handing a SOC 2 to a financial-statement auditor who needed a SOC 1 provides no assurance inside a SOX 404 reliance chain, because SOC 2 cannot stand in for SOC 1 regardless of how much IT general controls evidence the two reports share; the reverse failure is equally consequential, since a SOC 1 answers none of the questions a security team needs answered before it approves a vendor.

The governing standards that define each report's mandate

Both reports come from the AICPA, so people assume they are close cousins. In fact they answer to different attestation standards, and their scopes cannot bleed into each other the way some service organizations expect. SOC 1 operates under AT-C section 320, under SSAE No. 18 as amended, with an international counterpart in ISAE 3402. SOC 2 operates under AT-C section 205, measured against the AICPA Trust Services Criteria, the 2017 edition with points of focus revised in 2022. One structural consequence follows immediately from this split. SOC 1 has no fixed list of criteria an auditor must test against; management writes the control objectives that fit the services being provided. SOC 2 works from Trust Services Criteria that are the same for every organization examined, even though the specific controls an organization builds to satisfy them will differ from company to company. The standard also dictates who is required to read the report. Under AU-C 402, a user auditor must consider a service organization's controls whenever those services, and the controls over them, affect the user entity's information system and the business processes relevant to financial reporting. No equivalent obligation exists anywhere in the standard governing SOC 2. Firms like Pease Bell, which conduct both SOC 1 and SOC 2 examinations, treat this as more than procedural trivia: the governing standard is the lens that determines what the report can credibly tell its intended reader, and a compliance-first approach that skips past that question tends to produce a report nobody can actually rely on.

What SOC 1 covers

SOC 1 scope comes down to one test: could an error in what you process flow into a customer's general ledger and eventually show up in their audited financial statements? If the answer is yes, SOC 1 applies, regardless of industry or company size. A payroll processor is the cleanest illustration. Because of who relies on it, a SOC 1 is a restricted-use document. Pease Bell's SOC 1 practice leans on that distinction early in an engagement, so the examination tests what the user auditor genuinely needs for a reliance decision.

What SOC 2 covers

SOC 2 scope runs on an entirely different axis: how does the system handle customer data, regardless of whether any of that data ever touches a financial statement? That question reaches into every corner of a service organization's environment. SOC 2 examinations tend to be broader in operational reach even when they are narrower in financial consequence. Five Trust Services Criteria define the territory: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only one that is mandatory in every SOC 2 examination; the other four get added based on the actual commitments an organization has made to its customers, often in the contracts those customers signed. That selection is not an academic exercise, since choosing criteria that don't match what customers were actually promised produces a report that looks complete but doesn't answer the questions those customers will eventually ask. SaaS platforms, cloud infrastructure providers, data centers, managed IT services, and any organization holding sensitive customer data at scale fall inside this scope. SOC 2 examinations are too often treated as a procurement checkbox rather than what they actually are: a report on whether a system keeps data secure, available, and processed with integrity. Auditors and advisors who approach the engagement that way, regional practices such as Pease Bell among them, start from the premise that the Trust Services Criteria exist to give customers real confidence in how an organization operates, not to produce a document that satisfies a vendor questionnaire and nothing more. And because the primary reader of a SOC 2 is a customer's security, vendor-risk, or procurement function rather than a financial-statement auditor, the request for one tends to arrive from a different desk at the customer organization than a SOC 1 request ever would.

Where the two reports overlap on IT general controls

Skeptics of a clean SOC 1 / SOC 2 split point to IT general controls as proof the two reports blur together. Logical access, change management, computer operations, backup procedures, and physical security appear as control objectives in both reports. That overlap is narrower than it looks, and it doesn't make the reports substitutes for one another. In a SOC 1, those controls appear as ITGC objectives supporting the financial-process assertions the report exists to test. In a SOC 2, the same categories of controls sit under the common criteria supporting security and availability commitments. What differs is the question each report is asking of that evidence. A customer's financial-statement auditor holding only a SOC 2 has evidence about the environment and nothing about the financial processing running through it; that gap matters because SOC 2 cannot stand in for SOC 1 inside a SOX 404 reliance chain, even when an auditor is tempted to stretch it that way. The reverse failure matters just as much. A SOC 1 says nothing about whether a system hits its availability targets, how encryption keys are managed across the environment, or how vendor risk gets monitored, and those are exactly the questions a security team needs answered before it signs off on a vendor. The reports themselves remain two separate opinions answering two separate questions, and no amount of shared evidence changes that.

When does a service organization need SOC 1, SOC 2, or both?

Plenty of service organizations sit in both domains at once: they affect a customer's financial reporting and they hold sensitive data at scale, so they need both reports, and in that situation the two are complementary. The clearest signal for which report, or reports, an organization needs is where the request originates inside the customer's organization. "Our auditors need your SOC 1" means the customer is itself audited, your service touches its books, and its auditor needs evidence of operating effectiveness across the financial year, a request that lands on nearly every payroll, benefits, custody, and claims provider sooner or later. "Send us your SOC 2 before we can sign" comes from a security or vendor-risk function evaluating you as a supplier, and it is the request almost every SaaS company hears before a contract closes. "We need a SOC 1 and a SOC 2" shows up when the customer depends on an organization for financial processing and also entrusts it with data, with a hosted general ledger platform or a payroll SaaS product as the textbook case. An internal diagnostic can settle most ambiguity: would an error in the organization's output misstate a customer's financial statements, and does the system store or process customer data that a security or procurement function has to evaluate? A yes to both questions means both reports are warranted.

Mortgage banking and loan servicing make the dual-report case concrete. These organizations process transactions that feed directly into investor financial statements, which puts them squarely in SOC 1 territory, while also running large technology environments that handle borrower data, which puts them in SOC 2 territory at the same time. When both reports are genuinely required, they are frequently scoped together specifically to share evidence and reduce the burden of running two separate examinations, with IT general controls evidence gathered once and mapped across both.

Type I and Type II examinations across both report types

Type I versus Type II is a separate decision from SOC 1 versus SOC 2, and it applies the same way to both report types: a Type I examination looks at whether controls were designed correctly as of a specific date, while a Type II examination tests both design and operating effectiveness over a period of time, with a minimum window of six months. A financial-statement auditor requesting a SOC 1 under AU-C 402 will almost always insist on a Type II, since that auditor needs proof of operating effectiveness across the period under audit, not a snapshot of control design on a single date. Organizations just starting down the SOC reporting path, or responding to an early customer request before their controls have matured, sometimes begin with a Type I to establish a baseline. That starting point works, but only as a first step; the transition to Type II needs to happen before an enterprise customer or a regulated counterparty forces the issue.

SOC 1 scope in mortgage banking and loan servicing

Few industries make SOC 1 scope as consequential as mortgage banking and loan servicing, where the financial data moving through a servicer's systems feeds directly into the financial statements of the investors and entities that own the loans being serviced. RoundPoint Mortgage Servicing LLC's publicly filed SOC 1 Type II covers control objectives for accurate payment recording, disbursement completeness, and escrow management, each one mapped to a specific financial-statement assertion an investor's auditor needs to rely on. Loan boarding accuracy, payment application, disbursement authorization, and escrow reconciliation are the kinds of control objectives that appear in a loan servicing SOC 1, and none of them appear in a SOC 2, since a SOC 2 tests whether a system is secure or available. These engagements also demand an auditor who actually understands loan servicing operations. This is where mortgage banking audit experience becomes a differentiator rather than a nice-to-have, and it is an area where Pease Bell's work in mortgage banking compliance is directly relevant to the kind of scrutiny these examinations require. The obligation also cascades downstream: mortgage banking auditors routinely evaluate the SOC compliance of a servicer's own vendors, requesting reports from any third party handling outsourced data to assess that vendor's security posture before relying on the servicer's own controls.

SOC examination scope and HUD-regulated multifamily and skilled nursing facility audits

HUD-regulated entities, including multifamily housing operators and skilled nursing facilities financed under HUD Section 232, operate outside the SOC framework entirely, but they face financial control obligations that are just as rigorous and defined by the same underlying logic of matching scope to mandate. The conceptual link to SOC 1 is not a claim that HUD audits are SOC examinations; they are not, and treating them as equivalent would misstate what each actually tests. What they share is a governing principle: the scope of a HUD audit is set by what the regulations require to be controlled and reported, not by whatever an auditor happens to find convenient to test. That is the same discipline that separates SOC 1's financial-reporting focus from SOC 2's data-security focus, with scope defined by mandate. Multifamily and skilled nursing facility engagements call for the same kind of specialized knowledge that mortgage banking SOC 1 work demands, and HUD 232, multifamily, and skilled nursing facility expertise, the kind Pease Bell has built in its own audit practice, is what lets an auditor translate regulatory requirements into an examination that actually tests what matters.

Why an emerging AI assurance standard signals where SOC scope boundaries may be tested next

The question that separates SOC 1 from SOC 2, what needs to be assured and for whom, is now being asked about AI agents embedded in financial workflows, and neither existing SOC framework was built to answer it. AIUC-1 has emerged as an independently audited certification covering controls across six domains, positioned alongside SOC 2 rather than in place of it, and informally described by some as a SOC 2 for AI agents. A SOC 2 that passes today says nothing about whether a service organization's AI agents behave safely or produce accurate output, because the Trust Services Criteria were never designed with AI agent behavior in mind, and SOC 1's financial-statement focus doesn't reach that territory either. Procurement and vendor-risk functions evaluating service organizations that deploy AI agents in financial services workflows are starting to ask for SOC compliance and AI-specific assurance side by side. The scope logic carries straight through: SOC 1 is bounded by financial-reporting impact, SOC 2 is bounded by data system security, and AIUC-1's boundary would be set by what a given AI agent actually does and what can go wrong when it does it, a domain that sits outside what either existing report type was built to cover. Pease Bell's engagement with AIUC-1 as an emerging standard places it at the front edge of that question, relevant to service organizations already examined under SOC 1 or SOC 2 that are now putting AI into processes their customers depend on. The discipline required to answer "what is this report actually assuring, and for whom" is the same discipline that has separated SOC 1 from SOC 2 all along, and it is the discipline that will decide how AI assurance gets scoped next.