When do customers ask for SOC 2 and what do they really mean by it

Because SOC 2 is not always what it seems. Sometimes it's a hard requirement, sometimes a guideline, sometimes a proxy for something else. This article explains in which situations SOC 2 comes up, what customers really mean by it, and how your organisation can anticipate this.

SOC 2 and customer questions in brief

Why customers bring up SOC 2

SOC 2 is a framework developed by the American Institute of Certified Public Accountants (AICPA) and specifically designed for service providers that process or store customer data in cloud environments. The framework assesses internal controls against five Trust Service Criteria: Security (mandatory), Availability, Processing Integrity, Confidentiality and Privacy. A SOC 2 report is the result of an independent audit by a certified accountant confirming that an organisation's controls meet those criteria.

SOC 2 is primarily a North American phenomenon. The framework is dominant in the United States and Canada, where it serves as the standard for technology companies selling to enterprise customers. In Europe, ISO 27001 is the more common standard. But because many SaaS companies operate internationally or serve North American customers, SOC 2 is increasingly relevant for European organisations as well.

What customers usually do mean

When a customer asks whether you have SOC 2, they rarely mean exclusively the report. They want to know whether they can trust you with their data. They want to understand whether you take security seriously, whether there are processes that work, and whether someone is responsible if something goes wrong. SOC 2 is a shortcut for them: an independently confirmed way to answer that question without having to ask about every component themselves.

This also means the underlying need can sometimes be fulfilled differently. A customer who asks for SOC 2 but is satisfied with an extensive security questionnaire or an ISO 27001 certification wasn't actually looking for the report itself but for the trust it represents. The distinction matters because it determines how you can conduct the conversation as an organisation.

Situations where customers ask for SOC 2

Enterprise sales processes

The most recognisable situation is the enterprise deal. You've done multiple demos, conversations are going well, and then the procurement process begins. A security questionnaire with dozens of questions about access management, encryption, incident handling and vendor management. And somewhere at the bottom: "Do you have a SOC 2 Type II report?"

In the North American market, this is now standard procedure with mid-market and enterprise customers. Anyone who cannot produce a report must answer all those questions individually, which can mean weeks of delay. The absence of a SOC 2 report doesn't automatically mean losing a deal, but it increases friction. In sectors such as financial services, health technology and legal technology, the requirements are strictest.

Procurement procedures and vendor assessments

Beyond sales processes, SOC 2 questions also surface in formal procurement procedures and periodic vendor assessments. Large organisations systematically assess their vendors on security maturity, especially when those vendors have access to sensitive data or critical systems.

In that case, the report is not only an instrument for closing a new deal, but also for securing an existing relationship. A vendor that cannot produce a report during a periodic assessment when the customer expects one risks being removed from the approved vendor list. That risk is for many organisations a reason to tackle SOC 2 proactively.

International customers

For European SaaS companies taking the step into the North American market, SOC 2 is virtually unavoidable. North American enterprise customers consider a SOC 2 Type II report the standard for security and reliability in technology vendors.

But the reverse also applies: large North American corporations assessing European vendors sometimes use SOC 2 as a reference point even though those vendors primarily operate in Europe. The conversation about ISO 27001 as an equivalent is then relevant, but requires explanation you'd rather not give in the middle of a sales process.

What customers mean when they say "SOC 2"

Need for trust

The core of a SOC 2 question is trust. A customer who asks you for a report wants the assurance that their data is safe with you, that you know what you're doing regarding security, and that an independent party has confirmed this is actually the case.

SOC 2 is a way for customers to objectify that trust. Instead of relying on claims on a website or answers in a questionnaire, they have an independent report that an auditor prepared after assessing the actual controls. That difference, between claiming and demonstrating, is precisely what SOC 2 provides.

Insight into security and processes

Behind the SOC 2 question is also a desire for insight into how your organisation works. How do you manage access to systems? What do you do during a data breach? How do you manage changes in your software? These are questions that security teams at customers want answered, and a SOC 2 report answers them systematically.

This is also why Type II is more valuable than Type I for most customers. A Type I report says controls were well designed at a certain point. A Type II report says they demonstrably worked over a period of six to twelve months.

Demonstrability and evidence

Customers also ask for SOC 2 because they themselves must account for their decisions. A procurement team that approves a vendor without a security assessment takes a risk that's difficult to defend internally if something later goes wrong. A SOC 2 report gives that procurement team documentation: evidence that the vendor was assessed and approved based on objective criteria.

Understanding this explains why presenting a report sometimes significantly accelerates collaboration. It removes a barrier not only for you, but also for the people on the other side of the table who must defend the conversation internally.

SOC 2 as a signal, not an end goal

Risk assessment by customers

Customers use SOC 2 as a risk assessment instrument. They want to know how likely it is that a collaboration with you leads to a security incident, a data breach or a disruption of their own service delivery. An independently confirmed report significantly reduces that uncertainty.

This means the value of SOC 2 for customers is proportional to the risk they take. A customer using you for a low-risk application has less need for a report than a customer placing critical business processes with you.

Expectations around governance

A SOC 2 report also signals governance maturity. Customers who ask for it are not only interested in technical controls but also in whether your organisation takes compliance seriously as part of how you work.

For customers in regulated sectors, this aspect is particularly relevant. They themselves operate under supervision and are assessed on how they select and manage their vendors.

Difference between SOC 2 Type I and Type II for customers

Snapshot versus continuous evidence

SOC 2 Type I is a snapshot. An auditor assesses at a specific moment whether controls are well designed. SOC 2 Type II goes further. The auditor assesses whether controls demonstrably worked over an observation period of at least six months. That difference is substantial for customers, as it makes the transition from intention to evidence.

What customers actually expect

In practice, enterprise customers almost always ask for Type II. Type I is sometimes accepted as a bridge, for example when an organisation is well on its way and the audit still needs to take place. But anyone who wants a structural position in an enterprise customer's vendor portfolio must eventually be able to produce Type II.

This makes planning relevant. Type II requires an observation period before the audit can take place. Anyone who waits until the first customer question comes in has an immediate disadvantage. Anyone who proactively starts setting up controls is already building observation time.

Common misconceptions about SOC 2 customer questions

SOC 2 is always mandatory

A common misconception is that SOC 2 is legally required. It is not. SOC 2 is not a law or regulation, but a voluntary framework that can be contractually required by customers. The pressure comes from the market, not from the government.

This also makes it a conversation. If a customer asks for SOC 2 and you don't have it yet, it's not automatically a dead end. The question is whether you can demonstrate that you fulfil the underlying need in another way. An ISO 27001 certification, a detailed security questionnaire with evidence, or a clear timeline towards SOC 2 can in some cases be sufficient.

Only a report is sufficient

The other extreme is the assumption that having a SOC 2 report answers all questions. In reality, a report is a starting point for a conversation, not an endpoint. Customers may ask additional questions about specific controls, about how you handle incidents, or about the scope of the report.

Moreover, a report is a snapshot of a period that lies behind you. Customers who work with you long-term want to know that measures are still in order now. An annually repeated Type II audit is the way to demonstrate that.

SOC 2 replaces other frameworks

SOC 2 is not a universal passport that replaces all other security requirements. In Europe, ISO 27001 is the dominant standard, and a SOC 2 report provides no guarantee that you meet ISO 27001 requirements, even though there is significant content overlap. Anyone operating internationally and serving both European and North American customers often needs both. An integrated approach via a combined platform makes it possible to reuse controls and documentation without setting everything up twice.

What customers expect when SOC 2 is not yet available

Short-term alternatives

If a customer asks for SOC 2 and you don't have it yet, there are several ways to keep the conversation productive. An ISO 27001 certification is the strongest alternative, especially for European customers and internationally operating corporations.

Beyond certifications, transparency about your security can provide much of the trust a report also offers. A detailed security questionnaire with concrete answers and evidence, an overview of your controls and a clear description of your incident handling process give customers insight without having to produce a formal report.

Transparency and explanation

Anyone who doesn't yet have SOC 2 but is already working on it should communicate that proactively. A clear timeline, a description of the controls already in place, and the expected audit date give customers something to hold on to. That's better than a vague commitment or silence that leaves room for negative assumptions.

Transparency about what you've already set up and what's still missing also works internally at the customer. A procurement team that receives an honest picture from you can defend that internally. In many cases, it's the lack of information, not the lack of the report itself, that delays or blocks deals.

How organisations prepare for SOC 2 questions

Establishing structure

Preparation for SOC 2 questions begins with establishing structure in your security approach. This means recording what controls you have, who is responsible for them, and what evidence exists that they work. That structure is needed not only for an audit; it's also needed to answer customer questions quickly and correctly.

Organisations that have established structure before the first SOC 2 question arrives are better prepared. They can quickly provide an overview of their controls, have documentation available to share, and don't need to start inventorying at the moment of the question.

Basic measures in order

A SOC 2 audit assesses whether controls work. This begins with the basics: access management, multi-factor authentication, encryption, backups, change management, incident handling and employee awareness. Anyone who has set up these basic measures and demonstrably keeps them working builds the foundation for a successful audit.

Documentation and evidence

Documentation is the connection between controls and the auditor or customer assessing them. Controls that work but aren't documented don't exist for an auditor. Building documentation and evidence is a continuous process, not a one-off project. Anyone who starts well before the audit and maintains it as part of daily operations has a significantly easier process during the audit.

The role of tooling in SOC 2 customer questions

Overview and reusable evidence

A platform that centrally maintains controls, documentation and evidence makes it easy to respond quickly to customer questions. When a customer asks how you handle access management, the answer isn't a search through folders and emails, but a reference to current documentation and accompanying evidence.

Evidence continuously collected through integrations with cloud providers and development tools is also reusable. You don't need to rebuild it for every customer or every audit.

Faster answers to questions

Procurement procedures and security assessments go faster when you have a central system that tracks your compliance status. A security questionnaire with seventy questions is less of an obstacle when the answers are already documented and evidence is immediately available.

How Tidal Control helps with SOC 2 expectations

Structure and insight

Tidal Control offers pre-built controls and policy templates specifically tailored to SOC 2, including the Trust Service Criteria. You start with a structure that directly aligns with what an audit expects, without having to build from scratch. Controls have an owner, tasks are automatically created and progress is visible to everyone on the team.

The platform serves as one central source of truth for all compliance information. When a customer asks about the status of your security, that information is immediately available and current, without having to search through spreadsheets.

Audit support

Tidal Control supports both SOC 2 Type I and Type II. The integrations with cloud providers and development tools such as Microsoft and AWS automate evidence collection, so evidence for a Type II observation period is continuously built without manual effort. More than 150 automated tests provide ongoing insight into the state of controls, so you can course-correct in time when something falls behind.

Anyone looking to grow into the North American market and anticipating that SOC 2 will become relevant sooner or later can start with Tidal Control by setting up the controls needed for it.

Frequently asked questions about SOC 2 and customer expectations

Why do customers specifically ask for SOC 2?

SOC 2 is the recognised standard in North America for security at technology vendors and SaaS companies. Enterprise customers, particularly in sectors such as financial services, health technology and legal technology, use it as an instrument to assess vendor risks. The report provides an independently confirmed basis for trust that goes beyond self-declarations or questionnaires.

What do customers usually mean when they say SOC 2 is required?

Customers who call SOC 2 required almost always mean they want evidence of security maturity. That doesn't always have to be a formal report. In some cases, an ISO 27001 certification, a detailed security questionnaire or a clear timeline towards SOC 2 is sufficient. The need behind the question is trust and demonstrability, not the report as such.

Do customers always expect a SOC 2 Type II report?

Enterprise customers expect Type II in most cases, because it provides evidence over a longer observation period and demonstrates that controls work structurally. Type I is sometimes accepted as a bridge in early sales processes. For a sustainable position in enterprise customers' vendor portfolios, however, Type II is the standard.

In which phase of sales or procurement does SOC 2 become relevant?

SOC 2 most often comes up during the security assessment in a procurement procedure, after there is commercial interest but before a contract is signed. In sectors with strict security requirements, the question can also come earlier, sometimes during initial conversations. Anyone who proactively has a report available avoids delay in the phase closest to contract signing.

What can you do when customers ask for SOC 2 but you're not yet certified?

The most effective approach is transparency combined with a concrete timeline. Show which controls you've already set up, share available documentation and state when you expect the report to be ready. An ISO 27001 certification is a strong alternative for European customers. For North American customers, explanation about the content overlap is sometimes needed, but it shows you take security seriously even without the specific report.