SOC 2 for SaaS Companies: Scope, Costs & Readiness

SOC 2 for SaaS companies is an independent CPA examination of the controls supporting a defined service. The report addresses the selected Trust Services Criteria and, for Type 2, whether controls operated effectively during a stated period. It helps customers evaluate how you protect their data; it does not cover every product or promise simply because your company has a report.

For a SaaS team, connect the product customers buy to the systems, people, and vendors that deliver it. Start with the buyer’s required coverage, write down the service boundary, assign evidence owners, and budget for readiness work alongside the audit fee. At auditor selection, compare SOC 2 audit firms by industry.

Confirm what the buyer needs from your SOC 2 report

An enterprise buyer may request a SOC 2 report before granting your application access to its data. The report gives its security team independent evidence to review instead of relying entirely on your questionnaire answers. The AICPA describes SOC services as assurance that helps users assess the risks of outsourcing services.

SOC 2 is not a universal obligation created by being a SaaS company. A customer contract or procurement process can make it a condition of doing business. Linford’s guidance for SaaS providers distinguishes that contractual demand from a general industry requirement. If the decision is whether to start now, use the separate SOC 2 guide for startups.

A report can support a security review, but it does not guarantee a shorter sales cycle. Buyers still need to check that the audited service matches the product they intend to use, that the period is acceptable, and how any findings affect their use case.

Before setting a report deadline, get these requirements from the buyer:

• Report type: Will it accept Type 1, or does it require Type 2?
• Service coverage: Which product, legal entity, hosting environment, or service commitment matters to its review?
• Timing: Does it need the issued report by a particular date, and what reporting period will it accept?

Share the buyer’s requirements with engineering, legal, and the audit owner before sales promises a report. They need to confirm that the team can demonstrate the requested coverage.

Write a scope brief for the SaaS service

“Our SaaS product” is too vague a boundary. Identify the product customers use, where their data travels, and which people or systems can affect it. The brief below is a planning aid to review with your auditor, rather than a complete system description.

Start with production, then trace dependencies outward. A development environment may matter if it holds customer data or its credentials can reach production. A support console may matter even though customers never log into it. Assess each system by how it supports or can affect the audited service.

For example, a document-processing SaaS product might receive uploads in an application, store them in object storage, process them through a background worker, and expose results through an API. Scope discussions should account for each data path, the deployment process, and the support staff who can retrieve customer files. If a new feature sends those files to a third party, revisit that dependency before rollout. A hosted model provider is one such dependency; SOC 2 for AI companies covers how they fit the scope.

For each component, record the customer data it handles, who can change or retrieve it, the control owner, and the evidence source. If the support console exposes uploaded documents, include its access and activity records in the discussion. If the worker writes copies to a temporary store, include that store’s retention and deletion path. This is an illustrative architecture, not a description of a tested service.

The scope determination guide explains how to turn the brief into a formal boundary and system description.

Cloud hosting does not transfer all responsibility

Your cloud provider’s assurance documents support vendor review; they do not demonstrate that your own application access and configuration controls operated correctly.

AWS’s shared responsibility model explains that AWS protects its underlying infrastructure, while customers retain responsibilities that depend on the services they use. For services such as S3, those include managing data, encryption options, and access permissions.

Review important vendors’ assurance in relation to the services you actually use, and document your oversight. For how their controls appear in your report, see SOC 2 carve-out vs inclusive reporting. If a managed service provider runs part of your environment, SOC 2 for MSPs shows how it scopes its own report.

Prepare evidence from the way your team operates

During readiness, compare your written policies with how the team works and check that you retain evidence of the controls. The examples below connect SaaS risks to records a team can retain. Discuss them with your auditor: they are planning examples, not a mandatory control list or a guarantee that a particular artifact will satisfy testing.

Use existing tooling when writing procedures. If alerts live in your monitoring system and changes live in pull requests, retain those records and link them to the control. Policies should describe the approval and exception paths your team can actually follow, including emergency changes.

For encryption, document which data stores and connections are protected, how access to keys is controlled, and where configuration evidence comes from. Choose technical settings for your risks, customer commitments, and applicable obligations, then discuss them with the auditor. A sentence saying “we encrypt data” cannot show how the control operates.

Worked example: trace an access review through to the change

GitLab’s public access-review procedure, updated September 29, 2026, provides a concrete example of evidence and ownership. It calls for a system-generated access list, linked removal issues, and confirmation that requested changes succeeded. The sequence below summarizes that published procedure; it does not establish how GitLab’s controls operated during an audit.

1. 01ExportKeep the system-generated user list, extraction date, and method.
2. 02ReviewThe system owner or manager validates user entitlements.
3. 03RequestLink each access-removal issue to the review.
4. 04ChangeThe system owner or IT Operations removes or adjusts access.
5. 05VerifyRetain confirmation that the requested change succeeded.

Source: GitLab Access Review Procedure, reviewed September 30, 2026. Summarized workflow; detailed validation and exception rules remain in the source.

For your SaaS team, test the handoff with one completed review: can another person trace a removal decision from the original user list to the ticket and the changed permissions? Record any missing link, its owner, and the action needed. This is a proposed readiness check, not a replacement for the auditor’s testing.

GitLab’s control framework also distinguishes the control owner, who remains accountable for the control, from the process owner, who understands its operation and supplies evidence. The same person may hold both roles. In your evidence plan, name both responsibilities even when one person performs them.

Build an evidence calendar

For each recurring control, record its owner, frequency, evidence location, reviewer, and exception process. Base the calendar on the control you commit to operating. Do not assign every review a monthly or quarterly cadence simply because a template uses one.

If you use compliance automation, check that integrations cover the in-scope accounts and retain the history you need. Automated collection can reduce administrative work; the team still owns reviews, decisions, remediation, and evidence for processes the integrations do not capture. Use the SOC 2 software guide to compare platforms.

For the full preparation sequence, use the SOC 2 compliance checklist. Before fieldwork, confirm that scope is documented, controls have owners, evidence is retrievable, and known issues have been discussed with the auditor.

Before requesting a proposal, send the auditor the scope brief and evidence-owner plan. Include the buyer’s required report, proposed period, delivery deadline, planned product changes, and known gaps. If an item is unresolved, name the person who will resolve it and the expected date. For firms that can assess the whole service boundary, start with the SOC 2 auditor directory.

Choose report coverage that matches the buyer’s request

Choose the report type and Trust Services Criteria that address the buyer’s requirements for the service in scope. Confirm those choices with the auditor before agreeing a reporting period or delivery date. Type 1 and Type 2 answer different questions; additional categories should reflect the commitments the service makes.

Type 1 or Type 2

A Type 1 report addresses control design at a specified date. A Type 2 report adds testing of operating effectiveness across a specified period. That distinction is explained in Linford’s SaaS audit guidance.

If a buyer accepts Type 1 and your controls are ready, you can provide a report on control design before completing a Type 2 period. If the buyer requires Type 2, plan for the operating history that report needs. Type 1 is not a prerequisite for Type 2; confirm why you need both reports before paying for two engagements.

Agree the Type 2 period with your auditor and confirm that the buyer will accept it before promising a delivery date. A software setup date, an audit booking, and an issued report are different milestones. The Type 1 vs Type 2 comparison covers the detailed trade-offs.

Trust Services Criteria

The AICPA’s Trust Services Criteria cover Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the baseline for SOC 2; discuss the other categories in relation to your service commitments and buyer requirements.

For SaaS scoping, start with the promises in your contracts:

• Uptime and recovery commitments prompt a discussion about Availability.
• Restricted use and disposal of designated business information prompt a discussion about Confidentiality.
• Complete, accurate, timely, and authorized processing prompts a discussion about Processing Integrity. SOC 2 for e-commerce platforms works through an order-processing example.
• Collection, use, retention, and disclosure of personal information prompt a discussion about Privacy.

These are scoping questions, not an automatic category assignment by industry. Handling personal information does not by itself tell you which categories the buyer needs in the report. Privacy obligations still need to be addressed even when the Privacy category is outside the SOC 2 engagement. Use the Trust Services Criteria guide for the full category comparison.

Budget for readiness, the audit, and ongoing operation

An auditor proposal covers a particular examination. It is not a complete estimate of what your SaaS team will spend getting ready or maintaining controls.

Keep one-time fixes separate from recurring costs. For example, tightening a production access path may require engineering work now, while reviewing that access continues throughout the program.

Request itemized proposals against the same scope brief so you can compare audit fees and exclusions. Use the SOC 2 audit cost guide for current fee benchmarks and their limits, then check which services each proposal includes.

Separate the project timeline into three parts

1. Readiness: Define scope, resolve gaps, and establish controls and evidence ownership. Workload depends on what already operates reliably.
2. Type 2 observation period: Retain evidence that controls operate across the agreed period. Discuss readiness and any mid-period changes with your auditor before relying on a planned start date.
3. Fieldwork and reporting: Support testing, answer follow-up requests, and review the draft system description and findings before issuance.

Some activities can overlap, but a fieldwork booking does not remove the need for operating history. Put the readiness milestone, period start and end, fieldwork dates, and expected report date on the same schedule. The SOC 2 timeline guide explains the phases in more detail.

Choose an auditor for your SaaS service

Compare firms on their ability to examine the service you described. Ask who issues the report and who will handle fieldwork, as well as the price. The AICPA’s current SOC guidance, reviewed on 30 September 2026, urges service organizations to evaluate SOC services carefully and highlights concerns about engagements that do not meet professional standards.

Bring the scope brief to the discussion and ask:

• Which SaaS environments and architectures has the assigned team examined?
• What evidence will it request from our deployment, access, support, and vendor-review processes?
• Which report type, criteria, entities, period, and deliverables does the fee cover?
• How will it handle planned product changes and any gaps discovered during testing?
• What work is included in audit coordination, and what would require separate readiness support?
• What dates depend on our readiness, and what dates can the firm commit to?

Use the SaaS auditor directory to compare firms and the auditor-selection guide for the full due-diligence process. Software selection and auditor selection are separate decisions, even when one package includes both.

Keep buyer-facing claims aligned with the report

Once the report is issued, give sales a description of the covered service, report type, selected criteria, and reporting date or period. Match public wording and questionnaire answers to that coverage. A report for one product should not imply that a newly acquired business or an unexamined module received the same assurance.

For a buyer review, make the report and relevant supporting answers available through your approved sharing process. Be prepared to explain findings and changes since the covered date or period. An independent examination supports due diligence; a badge alone cannot answer those questions.

Keep controls operating after issuance. Reassign controls when people change roles, review scope when the product changes, and plan the next reporting period early enough to avoid a coverage gap. Retain the records the team will need for the next audit and for questions from buyers.