What Security Do Enterprise Customers Expect From Startups?

Why does security show up in enterprise sales?

When a customer buys from you, part of their risk moves to you. If you hold their data, connect to their systems, or support a process they depend on, your security becomes relevant to theirs. Many larger organisations assess that risk before signing, and some are required to by their own regulators, insurers or customer contracts.

Not every enterprise customer runs a formal vendor risk programme, and the depth of review varies widely. The general pattern is that scrutiny tracks perceived risk. A tool used by one team with no sensitive data usually attracts fewer questions than a system holding customer records or sitting in a production path. Where a review does exist, it often becomes a step in the sales process, with its own owner, its own timeline and its own ability to hold up a signature.

What might an enterprise customer ask for?

Requests usually fall somewhere in a recognisable range, even though no two reviews look the same. The list below shows what can come up, not a set of things every startup is expected to have.

• A security questionnaire covering how you manage security day to day
• Security policies and supporting documentation
• Evidence of how access to systems and data is controlled
• Information about data protection, encryption and where data is held
• Vulnerability management information, including how issues are found and fixed
• Evidence of independent security testing, such as a penetration test
• Incident response planning and how you would notify them
• Backup, continuity and recovery information
• Secure development information, covering how changes reach production
• A SOC 2 report
• ISO/IEC 27001 certification
• Other compliance or assurance evidence relevant to their sector or obligations

Very few customers ask for everything here. Many ask for a small subset, and some ask for nothing beyond a short conversation. Treating the full range as a to-do list is one of the more common and more costly mistakes at this stage.

Security questionnaires

A questionnaire is one of the most common ways a customer gathers this information. It collects structured answers about your controls, and often asks for supporting evidence alongside them. Length and depth vary considerably, from a short form attached to a contract to several hundred rows with evidence requirements.

The process of working through one, including who should contribute, what to prepare in advance and how to handle questions you cannot answer positively, is covered in our guide to how to complete a customer security questionnaire.

Policies and security documentation

Customers often want to see that relevant practices are written down rather than held informally in a founder's head. Depending on the review, that can touch areas such as information security, access control, incident response, business continuity or vulnerability management.

There is no standard policy pack that every startup is expected to maintain, and a folder of generic documents that nobody follows tends to create problems later rather than solve them. Documentation is most useful when it describes what the company actually does. Where the gap is genuinely in writing things up, security policy development is a reasonably contained piece of work.

Penetration testing

Some customers ask for evidence that the product or environment has been examined by someone independent. That is not a universal expectation, and it is not something every startup needs before it can sell to larger organisations.

Whether testing is appropriate, and what form it should take, depends on what is being assessed, what the customer has actually asked for, the scope of the product or environment involved, and any contractual or other requirements that apply. If a test is the right answer, our penetration testing page covers what that work involves.

Incident response and resilience

A recurring theme in enterprise reviews is what happens when something goes wrong. Questions tend to cover how you would detect and respond to an incident, who would be told and how quickly, what backups exist, and how you would recover a service the customer depends on.

These questions are usually about having thought it through, not about having an enterprise-scale capability. Where a startup needs help building or improving that plan, incident response support is available through providers on Heelr.

SOC 2 and ISO 27001

Some customers explicitly require a SOC 2 report or certification to ISO/IEC 27001, and in those cases the requirement is usually specific and worth confirming in writing. Others simply want to know what assurance you can offer, and a named framework in an email can turn out to be shorthand for that broader question. The two are different mechanisms producing different outputs, and neither is a general prerequisite for selling to larger organisations. Our guide on how SOC 2 and ISO 27001 differ covers what each one produces and how to work out which is relevant.

What is actually required, and what depends on the customer?

This is the distinction that decides how much work a deal creates. Requests that look identical in an email can sit in very different categories, and it is worth working out which one you are dealing with before committing budget.

An explicit requirement

The customer or the contract requires something specific, and there is no obvious substitute. This is the category worth identifying first, because it is the one that genuinely constrains the timeline.

A procurement preference

The customer would prefer a particular form of assurance but may consider alternatives. Whether they do is their decision, not yours, and some will hold the line. It is still worth asking, since the answer changes what you need to do.

An evidence request

The customer wants to understand how a control works rather than requiring a certification or a test. A clear explanation with supporting evidence often resolves this, and it is frequently mistaken for a much larger requirement.

A real security gap

Sometimes the request surfaces something that genuinely needs improving, regardless of this customer. That is worth treating on its own merits rather than as a sales obstacle.

A short set of questions usually separates these quickly. What exactly is mandatory? Why is it being requested? Would alternative evidence be considered? Which part of the product or service is in scope? Is there a deadline tied to the deal? And does anything actually need to be remediated before purchase, or can it be committed to on a timeline? Asking these is about understanding the requirement accurately, not about talking a customer out of something. Where a weakness is real, presenting it as anything else tends to surface later and cost more.

What should you prioritise when security enters a deal?

The order matters more than the effort. Working through it roughly like this keeps the work tied to the requirement rather than to a generic idea of what a secure company looks like.

1. Clarify what the customer actually requires. Get the requirement in writing, in their words. A named framework, a questionnaire and a request for evidence are three different things, and they lead to very different amounts of work.
2. Establish what already exists. Most startups have more than they think. Access controls, logging, backups and review processes often exist in some form even when nothing has been written down.
3. Separate missing documentation from missing controls. These need different responses. Writing up a control that already works is a short piece of work. Building a control that does not exist is a project.
4. Identify which gaps are actually tied to the deal. Some findings need to be resolved before a contract is signed. Others can be scheduled. Ask the customer which category each item falls into rather than assuming.
5. Resist starting unrelated work. A generic checklist found online will suggest work that has nothing to do with this customer's requirement. Anything that does not map to a real risk or a real request can wait.
6. Assign clear internal ownership. Name the person accountable for the response and the people who need to contribute. Requirements stall most often because nobody owns them, not because the work is hard.
7. Bring in specialist help where the expertise is missing. If the requirement needs skills the team does not have, or the timeline is tight, external support can be a practical alternative to building that expertise during a live deal.

What if a customer asks for something you don't have?

It depends entirely on what is missing, and the honest answer is often less damaging than founders expect. Saying no to one item does not automatically end a deal, particularly when the response is accurate and comes with a clear position on what happens next.

The control may exist while the evidence or documentation is weak, which is a writing problem rather than a security problem. The question may be ambiguous, in which case clarification is the first step. An alternative control may achieve what the customer cares about, which is worth explaining rather than assuming. The requested assessment or certification may simply not have been completed yet. Or the control may genuinely not exist.

In each case the approach is the same: answer accurately, clarify what is actually being asked, identify the real gap, and decide whether remediation is needed now or can be planned. Inventing evidence or overstating maturity is the one route that reliably causes damage, because these claims tend to be revisited during contracting, later reviews or an incident.

Who should own enterprise security requirements inside a startup?

Ownership varies by company, and there is no single correct arrangement. Depending on the question, input may come from founders, the CTO or engineering leadership, operations, legal or privacy, a security function where one exists, and the commercial team that holds the customer relationship. What matters more than the job title is that someone is clearly accountable for the response.

Where these requirements become recurring or strategically important, some companies find it useful to establish clearer senior security ownership without creating a full-time role. Fractional security leadership is one way of doing that, though plenty of startups handle this well without it.

When specialist cybersecurity help may be useful

External help tends to earn its place when the customer's request is technically complex, when internal ownership is unclear, when something genuinely needs remediating, when specialist testing is required, when compliance work has become commercially important, or when several pieces of work now need coordinating against a deal timeline.

Equally, a startup with relevant internal expertise may handle some or all of this itself. Many do. The useful question is not whether to bring in help as a matter of principle, but whether the specific gap in front of you is one your team can close in the time available. If you are working out where security fits more broadly at your stage, our page on cybersecurity for startups covers how the categories of work usually sequence.

Common questions