An Indian SaaS company with a strong product and competitive pricing reaches the final stage of a deal with a US mid-market customer. The buyer's security team sends a short message: "Before we sign, please share your SOC 2 report." The company has ISO 27001, policies and good intentions, but no SOC 2. The deal is delayed by months, or lost to a competitor who can send the report the same day.

For software companies selling to North American customers, SOC 2 is often less a nice-to-have than an unwritten entry requirement.

What SOC 2 is

SOC 2 is an attestation framework developed by the American Institute of Certified Public Accountants (AICPA). An independent CPA firm examines a service organisation's controls relevant to the Trust Services Criteria and issues a report. Unlike ISO 27001, which results in a certificate, SOC 2 produces a detailed report describing the system, the controls, the auditor's tests and the results.

The five Trust Services Categories are:

  • Security (mandatory, called the common criteria): protection against unauthorised access.
  • Availability: the system is available for operation and use as committed.
  • Processing integrity: system processing is complete, valid, accurate, timely and authorised.
  • Confidentiality: information designated as confidential is protected.
  • Privacy: personal information is collected, used, retained, disclosed and disposed of according to commitments.

Companies choose which categories to include based on their services and customer expectations. Security is always required; many SaaS firms add Availability and Confidentiality.

Type I versus Type II

  • SOC 2 Type I reports on the design of controls at a point in time. It answers: are the controls suitably designed as of this date?
  • SOC 2 Type II reports on both design and operating effectiveness over a period, commonly six to twelve months. It answers: did the controls actually operate effectively throughout the period?

Most sophisticated buyers ask for Type II, because it provides stronger assurance. Type I is sometimes used as a stepping stone to show progress while the observation period for Type II runs.

Why US buyers ask for it

US enterprises and mid-market firms face vendor risk requirements from their own boards, insurers, regulators and customers. SOC 2 is a familiar, standardised format, and their security teams know how to read it. The report lets them evaluate controls without conducting a full audit of every vendor, which is not practical at scale.

Why Indian SaaS firms are particularly affected

Indian SaaS and IT services firms often serve US customers remotely, with engineering teams in India. Buyers may have extra questions about offshore access to data, subprocessors and incident response across time zones. A SOC 2 report that describes how these arrangements are controlled helps answer those questions credibly.

What the journey looks like

1. Define scope and criteria. Decide which systems, services, locations and categories to include.

2. Perform a readiness assessment. Compare existing controls with the Trust Services Criteria and identify gaps. Many companies with ISO 27001 find significant overlap, though SOC 2 has its own emphasis, such as specific evidence of control operation.

3. Remediate gaps. Implement missing controls and document policies and procedures. Common areas include access reviews, change management evidence, vendor management, vulnerability management, incident response testing, logging and monitoring, and onboarding and offboarding records.

4. Choose an auditor. Select a licensed CPA firm with experience in SaaS and cloud. Auditor reputation matters to buyers.

5. Run the observation period (Type II). Controls must operate consistently and generate evidence throughout the window.

6. Fieldwork and testing. The auditor tests controls by sampling evidence, interviewing staff and observing practices.

7. Receive the report. The report includes the auditor's opinion, management's description of the system, the control matrix and test results, and any exceptions.

8. Maintain annually. Customers expect a current report; most companies repeat the Type II examination each year, with continuous coverage.

Making the report commercially useful

  • Choose the observation period wisely. Start it early enough to have a report when needed. Plan backwards from target deals.
  • Understand exceptions. Control exceptions noted by the auditor are not automatic failures, but they invite questions. Be ready to explain remediation.
  • Share under NDA. SOC 2 reports are restricted-use documents, usually shared with customers and prospects under confidentiality.
  • Prepare a bridge letter if a customer needs assurance for the period between the report's end date and the present.
  • Align with sales. Provide your sales team with a clear summary of scope, categories, period and how to request the report.

Common pitfalls

  • Starting too late and discovering the observation period delays your first report.
  • Underestimating the evidence burden. Controls that exist but leave no records cannot be tested.
  • Scoping too narrowly, leaving key systems or subprocessors out.
  • Relying on automation tools without fixing underlying processes.
  • Neglecting vendor management, since customers care about your subservice organisations.

SOC 2 and ISO 27001 together

Many companies pursue both, and the effort overlaps substantially. A unified control framework allows one set of controls and evidence to serve both audits. ISO 27001 may satisfy buyers in Europe and Asia, while SOC 2 is typically requested in North America. Sequence the two based on your pipeline.

Plan your path

F9 Infotech helps SaaS companies assess readiness, close gaps, prepare evidence and coordinate with audit firms, so that you are ready when the next US buyer asks. Book a SOC 2 readiness consultation.

This article is general information about SOC 2 and does not constitute an audit opinion or legal advice.