Scope
Who it applies to.
A SOC 2 report is produced by a service organization — an organization, or a segment of one, that provides services to other entities. Customers, their auditors, and procurement teams ask for one before trusting you with their data. A type 1 examination reports on the description of your system and whether the controls were suitably designed as of the date of that description. A type 2 covers the same ground and adds an opinion on whether those controls operated effectively throughout a stated period.
- The criteria you are measured against
- A SOC 2 examination evaluates controls against the AICPA Trust Services Criteria, organised into five categories: security, availability, processing integrity, confidentiality, and privacy. The common criteria (the CC series) apply to all five and, for security, are the complete set; the other four categories add their own. The common criteria are aligned to the seventeen COSO principles, plus supplemental criteria covering access, system operations, change management, and risk mitigation.
- Vendor & business-partner risk is its own criterion
- The risk-mitigation common criteria (the CC9 series) require you to assess and manage the risks that vendors and business partners present. In practice that means setting requirements for each engagement, periodically re-assessing the risk those parties — and their own vendors — pose, assigning accountability for managing them, reviewing performance, and having a defined exit. Confidentiality engagements add obtaining and checking confidentiality commitments from them.
- Vendors feed your risk assessment
- The risk-assessment criteria (the CC3 series) expect your process to identify threats and vulnerabilities arising from vendors, business partners, and customers, and to treat a change in a vendor relationship as a trigger to re-assess. Every new tool you point at client files is something that process has to catch, evaluate, and document — not once at purchase, but on an ongoing basis.
- Subservice organizations: carve-out or inclusive
- A subservice organization is a vendor whose own controls are necessary, in combination with yours, for your service commitments to be met. Under the carve-out method its system components sit outside your description and outside the examination — but the description must still state the services it performs, the types of controls assumed at it, and your controls that monitor it. Under the inclusive method its components and controls are described and tested by the service auditor.
- Carving out does not mean walking away
- Whichever method you choose, the description discloses how you monitor the carved-out provider — inspecting its own type 2 SOC 2 report, internal-audit testing, reconciling output reports, service-level reviews, site visits. The description also has to say that your commitments can only be met if those assumed controls are themselves suitably designed and operating. Each provider you add is another monitoring routine you must run and evidence.
- What you push back onto your customers
- If your system only works because customers implement certain controls at their end, those complementary user entity controls must be disclosed too. And the service auditor’s report ordinarily carries an alert restricting its use to parties who understand the system, those user-entity controls, and the controls assumed at subservice organizations — so a SOC 2 is not a document you can simply publish.
The vendor & sub-processor obligation
What it puts on you.
Vendor and sub-service-organization risk management is a core part of the criteria: you are expected to identify the third parties that can affect your controls, evaluate their own reports, and manage the residual risk. More vendors in the data path means more to track and evidence.
How self-hosting addresses it
Remove the third party, remove the burden.
Running the workload on your own infrastructure removes outside service organizations from the data path, narrowing the third-party population an auditor and your customers have to consider.
How FileFerret applies
When indexing, search, and AI inference all run on hardware inside your own network, that tooling is not a subservice organization: no outside party operates controls your service commitments depend on, so there is nothing to name, carve out, or list assumed controls for. Your own controls over the appliance remain fully in scope. See how it’s built →
Full, current text is maintained at the official source: AICPA Trust Services Criteria (SOC 2).
Enforcement
Who enforces it, and how.
SOC 2 is not a law. There is no regulator, no statutory penalty, and no filing deadline — it is a voluntary attestation you commission because customers, their auditors, and procurement teams demand one, and because contracts increasingly require it. The examination is performed by a CPA, acting as service auditor under the AICPA attestation standards. The consequence of a qualified opinion is therefore commercial rather than legal: the exception is visible in the report every prospect reads, so deals stall, questionnaires multiply, and renewals get harder until it is remediated.
Common questions
Questions firms ask.
If I carve out a cloud vendor, does that criterion stop applying to me?
No. Carving out excludes that vendor’s components from your description and from the examination, but AICPA description-criteria guidance is explicit that a criterion stays relevant even when the underlying system is entirely outsourced — because your contractual commitment to your customers has not moved. You still have to name the services, state the controls you assume at that provider, and show how you monitor it.
Should we get a type 1 or a type 2?
A type 1 addresses the description and the suitable design of controls as of a single date. A type 2 adds an opinion on operating effectiveness over a period, along with the auditor’s tests and results. Buyers doing genuine diligence generally want a type 2, since design alone shows intent rather than evidence. A common commercial pattern is a type 1 first, followed by a type 2 over a later period.
Can we publish our SOC 2 report on our website?
Ordinarily not. The service auditor’s report normally includes an alert restricting use to specified parties who have enough knowledge of the system, the complementary user entity controls, and the complementary subservice organization controls to read it properly. A SOC 3 report is built on the same trust services criteria but is intended as a general-use report — that is what organizations post publicly instead.