The enterprise deal is close. Procurement sends a link to their vendor risk portal, a questionnaire, and a list of documents, with a deadline that assumes you have nothing else to do. The account executive wants to know how long it will take. Nobody on your side has done one of these for this customer before.
An enterprise security review is a sequence of stages, and most delays come from handling them out of order: answering a questionnaire before asking what it covers, or promising a control on a call without checking who would build it. This article walks through one review from intake to approval, with what to send and what to decide at each stage.
The stages of a typical review
The order varies by buyer, and some run stages in parallel, but most reviews include these:
Intake. The buyer's vendor risk team opens the review and tells you what they need.
Document request. They ask for standard evidence: reports, certificates, policies, a penetration test summary.
Questionnaire. Their own format, a standard one, or both.
Follow-up. Written questions about your answers, often a call with their security team.
Findings. The reviewer identifies gaps and asks you to close them, explain them, or accept contract terms that address them.
Decision. The buyer approves, approves with conditions, or escalates for a risk acceptance on their side.
Each stage has its own failure mode. The sections below take them in order.
Start with intake, not answers
The first message from the buyer usually contains less information than you need. Before anyone opens the questionnaire, get answers to these:
- Not done:
Which of your products and services is in scope?
- Not done:
What data will you handle for them, and will it include personal data, health information, or payment data?
- Not done:
Has the buyer assigned a risk tier to this engagement? The tier usually decides how deep the review goes.
- Not done:
What is the deadline, and what event drives it?
- Not done:
Who is the reviewer, and can you contact them directly?
- Not done:
Will privacy, legal, or an AI review run separately?
- Not done:
Will a standard package replace any part of the questionnaire?
On your side, name one coordinator. That person owns the deadline, routes questions to the right people, and reviews everything before it is sent. Without a coordinator, answers come back from several people in different voices, and some contradict each other.
Send the standard package first
Before the questionnaire, send the documents you would send to any enterprise buyer. A typical package:
Your audit report or certificate, and a bridge letter if the report period has ended
A penetration test summary
An index of your security policies, with full text on request
Your subprocessor list and data processing agreement
A completed standard questionnaire, if you maintain one
A short architecture overview showing where customer data lives
An insurance certificate, if the buyer asked for one
Sharing these through a Trust Center under NDA keeps a record of what was sent and when. Gating documents behind an NDA covers how to set that up. Ask the reviewer which questionnaire sections the package already answers. Many will tell you, and some will remove those sections.
Answering the questionnaire
The general method of answering questionnaires does not change for enterprise buyers. What changes is the scale and the scrutiny.
Draft from your library, then route the rest. Answers you already maintain should take minutes. Questions with no existing answer go to the control owner with a specific deadline, earlier than the buyer's. Building a security answer library covers how to keep those answers ready.
Answer for the scoped product only. If the buyer is purchasing one product, answer for that product's systems. Mark questions about things you do not offer as not applicable, with a one-line reason.
Surface the honest "no" answers early. If the true answer to an important question is no, tell the account executive before you submit. They need time to prepare the buyer, and the buyer needs to hear it from you rather than find it in row 214.
Keep your own copy. Portals often make it hard to export what you submitted. Save a copy of every answer as sent, with the date. You will need it next year, and possibly during contract negotiation.
Read the whole thing once before submitting. The coordinator reads every answer in order, looking for contradictions and for qualifiers that went missing. This is the step most often skipped, and it is the one that catches the answers that would generate follow-up questions.
Follow-up calls
Most enterprise reviews include at least one call with the buyer's security team. Prepare for it as you would for an auditor walkthrough.
Bring the right people. Usually that means your security lead and an engineer who knows the architecture. The account executive can attend, but should not answer technical questions.
Read the buyer's follow-up questions before the call and have the relevant diagrams, policy sections, and screenshots ready. When a question comes up that nobody can answer accurately on the spot, say you will confirm in writing, and do it within the agreed time. A guess on a call becomes a representation the buyer writes down.
Take notes on everything you say you will do. Any commitment, however small, belongs in a list with an owner and a date.
When the reviewer raises findings
Findings usually come in three forms: a gap the buyer wants closed before signing, a gap they will accept if you close it by a date, or a requirement they want written into the contract.
For each finding, you have four responses:
Accept and commit. Agree to close it, with a date your team has confirmed it can meet.
Show a compensating control. Explain how the risk is already addressed another way, with evidence.
Clarify scope. Some findings rest on a misunderstanding of what the product does or what data it touches. Correct it in writing.
Decline with reasons. Some requests do not fit your product or would require you to run a separate environment for one customer. Say so plainly.
Do not commit to anything on the spot. Check with the engineering owner, agree the date internally, and only then reply. Contractual requirements go to legal and should be checked against what your controls actually do. If you have mapped your controls across frameworks, as described in control overlap between frameworks, it is usually quick to show whether a requested control already exists under another name.
The decision, and what follows it
The buyer's approval may come with conditions: a remediation date, an annual reassessment, a requirement to deliver your next report on issue. Read the approval notice as carefully as the questionnaire. Each condition is a commitment, even if it never reaches the contract, and the buyer's vendor risk team will check it at the next reassessment.
Keeping the record
When the review closes, file everything together: the documents sent and their versions, the questionnaire as submitted, call notes, findings, your responses, and any commitments with their dates. Next year, the same buyer will reassess you. The record turns that from a fresh review into an update.
If this is your first enterprise review and you do not yet have an audit report, the SOC 2 readiness page sets out what to put in place first.
How TrustLynce helps
TrustLynce questionnaire automation suggests answers from your reviewed answer library, so the questions you have answered before take minutes. Documents can be shared through a gated Trust Center with an access log, so the record of what each buyer received is kept as you go.