Why SOC 2 for SaaS companies is usually a customer requirement
SOC 2 is not a law for most SaaS companies. It is a report a licensed CPA firm issues on a service organization's controls, and the request usually arrives from a customer's security questionnaire, a bank's vendor review or a contract clause that names the report. That customer review sets the deadline, so the first task is to find out exactly what the customer asked for: a SOC 2 Type 1 or Type 2, a SOC 3, a bridge letter, or simply evidence that controls exist. Many teams discover the requirement only when a deal stalls, so checking the security section of open contracts and pending questionnaires is a practical first step.
The answer depends on who is asking, which system is in scope and which report type they need. A bank reviewing a critical vendor under third-party risk guidance will expect a restricted report it can review during due diligence, while a mid-market customer may accept a public SOC 3 on the website and ask for the full report only under a non-disclosure agreement. Scope matters as well: a customer whose data sits in one product module may need only that system described in the report. Ask each requester which categories beyond security they expect, whether the report must cover a period or only a date, and whether they need the cloud provider's own SOC reports alongside yours.
Plan the next step before the request forces it. Write down the customers and bank partners who require a report, the report type each one accepts, and the date each needs it by. Then confirm with each requester in writing what they will accept if the report is not yet available, since an interim statement or bridge letter may be negotiated rather than assumed. Those decisions shape the scope and timing of the examination, so they should be settled before any CPA firm is engaged.
SOC 2 or SOC 1 when the service affects customers' financial reporting
A SOC 2 report addresses a service organization's controls relevant to security, availability, processing integrity, confidentiality or privacy, as described in the Journal of Accountancy's 2016 explanation of the three SOC reports. Most SaaS companies fall here because customers send their data to the platform and want assurance about how it is protected, kept available, processed correctly, kept confidential or handled as personal information. The common criteria always apply, and the other categories are added only when they are in scope.
- Data hosting and storage: Platforms that hold customer records, files or application data are usually asked for security and confidentiality assurance.
- Uptime-dependent services: If customers rely on the service for continuous operations, availability criteria often come into scope.
- Personal data processing: Services that collect or use personal information may need privacy criteria, which carry more detailed requirements.
- Vendor reviews: Bank and enterprise procurement teams usually request a SOC 2 when assessing a third party's controls.
- Scope decisions: The categories included, the system boundary and any subservice organizations must be written down before fieldwork starts.
Before committing to a SOC 2, ask the customer's auditor or risk team which report they accept and confirm the categories in writing.
A SOC 1 report addresses controls relevant to user entities' internal control over financial reporting, according to the same Journal of Accountancy explanation. It becomes the relevant report when the service touches the numbers a customer reports in its financial statements. Examples include payroll processing, billing and invoicing platforms, or expense systems that feed a customer's general ledger during financial close. The customer's external auditor is usually the reader who needs it.
- Payroll and benefits: Services that calculate pay, withholdings or benefit deductions often feed financial statements directly.
- Billing and revenue: Platforms that generate invoices, recognize revenue or manage receivables may affect the customer's reported figures.
- Financial close dependencies: Tools whose outputs are posted into a customer's ledger during close are common SOC 1 candidates.
- Control objectives: A SOC 1 is built around control objectives for the financial reporting process, not the Trust Services Criteria.
- Reader: The customer's external auditor, rather than a security reviewer, typically asks for this report.
Ask the customer's external auditor whether a SOC 1 is required and which control objectives they expect to see covered.
Many services sit in both groups. A SaaS platform may hold customer data, which points to SOC 2, and also post figures into a customer's ledger, which points to SOC 1. The safest approach is to ask who will rely on the report and for what purpose, then match the report to that reader. Some organizations end up producing both, with separate scopes and separate system descriptions.
- Ask the reader: The customer's risk team and external auditor define the question, not the vendor.
- Map the use case: Note whether the service stores data, processes it, or feeds financial records.
- Check the scope in writing: Record the services, locations, categories and subservice organizations covered.
- Plan for both if needed: A SOC 1 and a SOC 2 can share some controls but have different system descriptions and criteria.
- Watch for drift: New features or integrations can move a service from one category to the other.
Confirm the report type and the scope in writing with the customer before any readiness or examination work begins.
How a SaaS company approaches its first SOC 2
The sequence moves from confirming who needs the report to a CPA firm's issued opinion, with a defined output at every stage so the company knows what it has and what is still missing.
Confirm which customers need which report
Start by listing the customer contracts, security questionnaires and bank or enterprise vendor reviews that ask for SOC 2, and note whether each asks for a restricted SOC 2 report, a SOC 3 summary or a SOC 1. Ask each customer which report type and which period they expect, since a Type 1 and a Type 2 answer different questions. The output is a written requirements list that names the report type, the audience and the deadline each customer has set. The step is done when the list is agreed with sales and legal and nobody is promising a report date that the list does not support.
Define the system and categories in scope
Decide which product, environments, data flows, support processes and locations make up the system the report will describe, and which Trust Services Categories to add to security. Identify the cloud providers and other subservice organizations the system depends on, and decide whether they are included or carved out. Management owns these decisions, and the CPA firm will test them against what customers actually use. The output is a draft scope statement and a system boundary diagram, and the step closes when engineering, product and the CPA firm have reviewed the same document.
Run a readiness assessment against the criteria
Compare the company's current controls with the common criteria CC1 to CC9 and any added categories, using the criteria and their points of focus as the reference. Document, for each criterion, which control exists, who operates it and what evidence it leaves. A readiness assessment can be performed by an internal team, a consultant or a CPA firm, but a firm that will later issue the report must watch its independence limits when it helps prepare. The output is a gap register that lists each missing or weak control with an owner.
Remediate gaps and collect evidence
Close the gaps in the register by writing or revising policies, configuring access controls, logging, change management, vendor reviews and incident procedures, and then running them long enough to produce records. Infrastructure and self-hosted tooling can generate much of the evidence, such as access reviews, configuration baselines and deployment records, when they are set up for that purpose. The output is a control matrix that maps each control to its criterion, owner, frequency and evidence location, and the step is done when every in-scope control has an operating example.
Prepare the system description and management assertion
Management writes the system description under the 2018 description criteria, explaining the services, infrastructure, software, people, procedures and data, along with complementary user entity controls and subservice organization controls. Leadership then signs a written assertion that the description is fairly presented and the controls are suitably designed. The output is a reviewed system description draft and a signed assertion ready for the auditor. Both documents must match the scope and the controls actually in place, because the CPA firm will test them.
Choose a CPA firm
Select a licensed CPA firm to perform the examination after checking its license, its AICPA peer review status and its experience with SaaS and cloud environments. Ask for a written engagement letter that states the report type, scope, period, fees, fieldwork approach and what the company must provide. The firm's independence from any compliance tool vendor and from the consultants who prepared the company should also be confirmed. The output is a signed engagement letter, and the step is complete when the firm has agreed the timeline for fieldwork in writing.
Run the examination and receive the report
The CPA firm assesses the system description and the design of controls, and for a Type 2 report tests operating effectiveness over the agreed period through sampling and inquiry. Management answers evidence requests, documents exceptions and signs the written representation letter the firm requires. The output is the CPA firm's report with its opinion, which only the firm issues. The company then decides which recipients may receive the restricted report under its NDA, and whether a public SOC 3 summary is also useful.
Scope decisions that change what a SaaS company must prove
Before fieldwork starts, a SaaS company settles a handful of scope decisions. Each one changes what the service auditor tests, what the report says, and what a customer's vendor review can rely on. Decide them in writing with the CPA firm before the system description is drafted.
The production system and its boundaries
The system description covers the services, infrastructure, software, people, procedures and data that deliver the product to customers. Decide which production environments, regions, tenants and support tools sit inside the boundary, and which internal systems do not. A customer who reviews the report will check whether the product they bought is the product the report describes. Ask the firm how it will confirm that the boundary matches what customers actually use.
Security alone or added categories
Every SOC 2 covers the common criteria for security. Availability, confidentiality, processing integrity and privacy are added only when they are in scope. Each added category brings its own criteria, so a company that promises uptime commitments, handles confidential customer data or processes personal data usually adds the matching category. Adding a category expands testing and evidence, so choose it on the basis of the commitments in customer contracts.
Cloud providers as inclusive or carve-out
Cloud hosting and other providers are subservice organizations. An inclusive approach brings their controls into the examination, while a carve-out excludes them and relies on the provider's own SOC report plus complementary subservice organization controls. Carve-out is common, but the company must still review the provider's report and document which controls the company itself operates. Confirm with the firm which approach it will accept for each provider and how the provider's report will be read.
Type 1 or Type 2 coverage
A Type 1 report describes the system and the design of controls as of a single date. A Type 2 report adds an opinion on whether those controls operated effectively over a period. Many customer reviews expect Type 2, so a company that issues only a Type 1 may face follow-up questions about the operating period. Ask customers which report type their security teams will accept, and plan the observation window before the first control runs.
Customer-hosted and self-hosted deployments
Some SaaS vendors run the product inside customer environments, such as a private cloud or on-premises installation. Whether those deployments fall in scope depends on whether the vendor operates or can access them. If the customer runs the software, the customer's own controls govern those systems, and the report may list them as complementary user entity controls. Define the deployment models in the system description so the customer knows which environments the report covers and which remain their responsibility.
Who owns each part of a SaaS SOC 2
A SOC 2 for a SaaS company involves four parties with different jobs. The company owns its controls and the claims in its system description, an implementation partner prepares systems and evidence, an independent CPA firm tests and reports, and the customer reviews the result against its own vendor requirements.
The company
The service organization owns its controls, policies, system description and management's assertion. It signs the written representation letter the CPA firm requires, and it is accountable for every statement in the report, including those about subservice organizations such as its cloud provider. Before the examination, check that someone with authority over the system is named as the control owner for each criterion and that the description matches how the platform actually runs.
The implementation partner
An implementation partner such as DeployOpen prepares the self-hosted systems, access controls, logging, backups and documentation that the company's controls depend on, inside the company's own cloud accounts or data centers. It can also help collect and organize evidence and support the examination. It does not write the company's assertion, issue a report or attest to anything. Ask for the written scope, the deliverables and who keeps the evidence after the engagement ends.
The CPA firm
Only an independent CPA firm can perform the SOC 2 examination and issue the report. It assesses the system description, tests control design for a Type 1 or operating effectiveness over a period for a Type 2, and states its opinion. The firm must be independent of the company, which limits how much it can help prepare the same controls it will test. Confirm its license, its AICPA peer review status and whether it is independent of any compliance tool the company uses.
The customer
The customer owns its own vendor review. It decides whether the SOC 2 scope covers the services it buys, reads the exceptions and the complementary user entity controls section, and fills any gaps through its own contract terms or controls. For bank customers, the 2023 interagency guidance says a bank may review a third party's SOC reports during due diligence, so the customer may also ask for audit report types and frequency in the contract.
Questions SaaS companies ask about SOC 2
Is SOC 2 legally required for a SaaS company?
No general law requires a SOC 2 report. Demand comes from contracts and reviews: customers' vendor reviews, banks applying third-party risk guidance, and regulated customers that ask for audit reports. The US banking agencies' 2023 interagency guidance says a bank may consider reviewing a third party's SOC reports during due diligence, and it suggests contracts specify which audit reports the bank is entitled to receive. Your obligation is therefore set by what your customers and their regulators require, which you should confirm in each contract and security questionnaire before committing to a report type and timeline.
Can a SaaS company prepare for SOC 2 without outside help?
Yes, a company can prepare internally, but the examination itself must be performed by an independent CPA firm, and that firm cannot also design the controls it tests. Internal teams usually own the system description, the control matrix, policies, access reviews and change records. Many teams bring in a readiness reviewer to check scope and gaps before the examination starts. Outside help is typically used for scoping, gap analysis, and implementation of tooling, and the company still owns its controls and evidence. Confirm with the CPA firm which preparation work it can accept without affecting its independence.
What does a SOC 2 examination need from engineering and operations?
Engineering and operations supply most of the evidence an auditor samples. The work usually includes documenting how production access is granted and removed, showing change records from ticket to deployment, keeping logs and alerts for security events, running vulnerability scanning and tracking remediation, and tracking backups and restore tests. Operations also maintains asset inventories, configuration baselines and infrastructure as code history where it is used. Plan for recurring time: evidence must be captured continuously across the observation period, not assembled once before the audit. Ask your CPA firm for its evidence request list early so engineers know exactly which records to keep.
How do cost and timeline change with scope and report type?
Cost and time rise with the number of systems, locations and trust services categories in scope, the number of subservice organizations such as cloud providers, and whether you need a Type 1 point-in-time report or a Type 2 report over an observation period. A Type 2 needs a period of operating evidence, so its calendar time is longer than a Type 1. Readiness and remediation work also add effort when controls are immature. Your cost and timeline depend on your own environment, so see the SOC 2 cost and SOC 2 timeline guides for the factors to weigh, and request a quote that states the systems, categories and report type it assumes.
Does a SOC 3 report replace a SOC 2 report?
No. A SOC 3 covers the same trust services categories as a SOC 2 in less detail, and it is a general use report that can be freely distributed, often posted publicly. A SOC 2 is restricted in use and contains the detailed system description, the tests performed and the results, which is what customers' security and vendor-risk teams usually need. Many companies publish a SOC 3 for marketing and still provide the SOC 2 under NDA to customers who ask. Check each request, because a customer that asks for a SOC 2 expects the restricted report, not a summary.
How are self-hosted products handled in a SOC 2?
If your company develops software that customers install and run in their own infrastructure, the customer usually controls the environment, so your SOC 2 may cover only the parts you operate, such as your build pipeline, your secure development practices, your support access and your vendor management. Customers running the software in their own networks will rely on their own controls for those systems. Confirm with your CPA firm and your customers how the boundary is drawn, and document it in the system description so reviewers know which controls apply to the service you actually run.
How DeployOpen helps SaaS teams prepare for a SOC 2 examination
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a SaaS team preparing for SOC 2, that means we can build and configure the systems that run your controls, such as identity, logging, backup and deployment pipelines, and then produce the evidence an examination will sample. We also prepare the control documentation and the records that show each control operating. What we do not do is issue the report. Only an independent CPA firm issues a SOC 2 report, and your organization owns its controls and its system description.
Engagements are fixed-scope. Before work starts, we agree in writing which systems, Trust Services Criteria categories and environments are in scope, which deliverables we will hand over, and the timeline for each. A quote follows from that written scope, so the cost reflects the systems you actually run and the gaps you actually have. Ask for the scope document to name the production environments, the identity provider, the logging stack and the subservice organizations, and to state which items remain your responsibility. Also confirm with your CPA firm, before scoping, which evidence it expects in what format, so the deliverables match what the examination will test.
Before you sign, check three things. First, confirm that the deliverables include the system and control evidence your auditor has requested, not only a policy set. Second, confirm who maintains the evidence after handover, since a SOC 2 Type 2 report covers an observation period that must be recorded continuously, and ongoing support is a separate retainer. Third, confirm that the CPA firm you intend to use has no conflict in preparing the controls it will later test, so that the readiness work does not compromise its independence. We can help you plan these checks, but the decision and the auditor relationship remain yours.
