A Customer Asked for a Security Review. What Happens Next?

What does a customer mean by "security review"?

In practice a security review may include one or several of the following. Very few reviews include all of them, and the combination depends on the customer's process and the nature of what you provide.

This is not a checklist to work through in order. It is a description of the range. If the request you have received is a questionnaire, our guide to completing a customer security questionnaire covers that part in more detail.

Why is the customer asking now?

The timing usually reflects something specific about the deal rather than a change of attitude towards you. Common triggers include the product beginning to handle customer or personal data, an integration into the customer's own systems, access to a sensitive environment, the deal passing a value or importance threshold that engages their procurement process, an internal policy that applies to all new suppliers, or a regulatory obligation the customer is subject to and has to pass down to its supply chain.

It helps to read the request as a risk decision rather than paperwork. Once the customer depends on your service, your security becomes part of theirs, and someone inside their organisation has to be able to explain why using you is acceptable. The questions exist to give that person something to point to. Larger customers tend to have more formal versions of this, which is why enterprise security requirements often arrive suddenly for smaller suppliers moving upmarket.

What are they actually trying to find out?

Behind almost every question is a smaller set of underlying concerns. Understanding these makes the paperwork easier to answer, because you can address the concern rather than the wording.

• How access is controlled: who can reach customer data and systems, how that access is granted, reviewed and removed, and what protects administrative accounts
• How data is protected: what you hold, where it lives, how it is separated between customers, and what happens to it at the end of the relationship
• How vulnerabilities are handled: how issues are found, how they are prioritised, and how quickly meaningful ones get fixed
• How incidents would be managed: who would notice, who would decide, who would tell the customer, and how quickly
• Whether third parties are involved: which sub-processors and vendors sit behind your service, and how you assess them
• Who owns security: whether there is a named person accountable for it, or whether it is genuinely nobody's job
• What evidence supports the answers: whether the things you describe can be shown to exist, rather than only asserted

A reviewer who can follow your answers to these questions is generally satisfied, even where some of the answers are modest. A reviewer who cannot tell what is actually true tends to keep asking.

How do you work out what they really need?

Ask before you commit to work, and particularly before you commit budget. The single most useful question is usually some version of: which parts of this are mandatory for us to proceed, and which are informational? It is a reasonable question, and most security and procurement teams will answer it.

A phrase such as "we require SOC 2" can mean quite different things depending on who said it and why. It may be:

• A genuine contractual requirement, written into their supplier terms and not open to discussion
• A preferred form of evidence, where the customer wants independent assurance and a certification is the easiest way to get it
• An internal procurement default, applied to every supplier regardless of what they do
• Something that may be satisfied another way, such as a detailed questionnaire response, evidence of specific controls, or contractual commitments

Establishing which one applies is worth the conversation. Certification programmes take time and money, and starting one in the middle of a deal rarely fits the deal's timeline anyway. If you are weighing it up, our comparison of SOC 2 and ISO 27001 explains what each one produces and who assesses it. If contractual security terms are involved, take your own legal advice rather than relying on a general guide.

Who should be involved in answering?

The people needed depend on what has been asked. A short review of a low-risk integration may involve two people; a detailed enterprise assessment of a product handling personal data may involve several. Typically the contributors come from:

• Founder or company leadership, to own the commercial relationship and decide what the company is willing to commit to
• Engineering or product, for accurate answers about how the system is actually built and operated
• Whoever owns security internally, where that role exists, to keep the answers consistent across areas
• Legal or privacy input, where contracts, data processing terms or personal data are involved
• External security expertise, where the questions go beyond what anyone internally can answer accurately

One person should coordinate, even in a small company. The common failure is not a lack of people but a lack of ownership, where the review sits between sales and engineering and neither is quite responsible for it.

What if you do not have everything they ask for?

Most smaller companies going through their first serious review find at least one thing they cannot evidence. That is normal, and a gap does not automatically mean the deal is over. What it does mean is that the conversation moves from answering questions to discussing how the gap is handled, and the outcome is the customer's decision.

Depending on the requirement, that discussion may involve clarifying whether the item is genuinely mandatory, explaining controls you already have that address the same underlying risk, supplying alternative evidence, documenting improvements you intend to make, or agreeing specific remediation with a timeline that forms part of the contract.

Two things tend to matter more than the gap itself. The first is accuracy: describe the position as it is today rather than as you intend it to be after a planned project, because inaccurate answers usually surface at the worst moment. The second is specificity: a clear gap with a named owner and a credible date is easier for a reviewer to accept than a vague reassurance, though nothing guarantees they will.

When does outside security help make sense?

Plenty of companies handle these reviews perfectly well themselves. External support is worth considering where the request exceeds what the team can answer confidently, rather than simply because a review has arrived. Situations where it commonly helps include:

• The questions become technically detailed enough that an accurate answer needs specialist knowledge
• You believe the controls exist but cannot confidently evidence them
• The review raises architecture or application security questions that warrant a proper look
• A penetration test is genuinely being requested and the scope needs defining
• Security is becoming a recurring part of the sales process and consuming founder time

The type of help depends on what the review surfaced. A one-off architecture or application security review addresses a specific technical question. Where nobody owns security and reviews keep arriving, some companies bring in part-time security leadership instead of treating each request as a separate emergency.

What happens after the first security review?

The same customer may ask again at renewal or when the relationship expands. The questions rarely repeat word for word, but the underlying subject matter does.

The practical response is modest: keep the information and evidence you were asked for somewhere organised, note when each item was last checked, and be clear about who owns each area internally. That alone turns the second review into a much shorter exercise than the first. It does not require a formal compliance programme, and building one before your customers actually need it is usually premature.

Common questions