The process, not the paperwork: who is actually reading, the six stages and what each one asks for, how long they take, and the five places deals really stall.
- Published
- Updated
- Reading time
- 9 min read
- By
- Zaaf review desk
In this guide
Founders tend to picture the security review as a document. It is a process, run by people with different jobs, and knowing its shape is most of what makes it survivable. This is what happens on the other side of the table, stage by stage, and where the weeks actually go.
Elsewhere on this blog we cover the individual artifacts: the questionnaire, the audit report, the test report, the letter. This piece is the map they sit inside.
Who is actually reading
Three readers, three questions, and they rarely talk to each other as much as you would hope.
- Procurement owns the file. Their question is "is this complete?" They are not evaluating your architecture; they are checking that every box has something in it and that the something is dated and signed.
- The security reviewer owns the risk. Their question is "can I verify this?" They have read a great many confident paragraphs and are looking for the ones backed by something checkable.
- Legal or privacy owns the terms. Their question is "what happens to our data, and who else touches it?" Subprocessors, retention, breach notice windows.
- ProcurementIs the file complete, dated and signed?
- SecurityCan each claim be verified?
- LegalAre the data terms understood?
An answer that satisfies procurement can still stall with the security reviewer, which is the most common way a deal quietly loses a month.
The six stages
| Stage | What happens | Typical time |
|---|---|---|
| 1. Intake and tiering | They classify how risky you are. This decides everything after it. | Days |
| 2. Questionnaire | Anywhere from 40 to 300 questions, sent as a spreadsheet or through a portal. | 1 to 2 weeks |
| 3. Evidence request | They ask for the documents behind your answers. | Days, if you have them |
| 4. Technical review | A security engineer reads your evidence and pushes back on the thin parts. | 1 to 3 weeks |
| 5. Legal and privacy | DPA, subprocessors, retention, breach notice. | 1 to 4 weeks, often in parallel |
| 6. Approval or conditions | Approved, approved with conditions, or deferred pending remediation. | Days |
Two to four weeks end to end is a good outcome with a mid-market buyer. Six to twelve is normal at a large enterprise or in a regulated industry, because more people have to sign and each of them has a queue.
Tiering decides your review before it starts
Stage one is the one nobody tells you about, and it is the one that matters most. Buyers sort suppliers by blast radius: how sensitive the data is, how much system access you get, how many of their users depend on you being up.
A low tier might clear on a short questionnaire and your word. A high tier can make an audit report mandatory and require that a named accredited firm has tested you, in which case no amount of good technical evidence substitutes. Whether you actually need SOC 2 is really a question about which tier you are in.
What each stage asks for
- Questionnaire. Claims about your controls. The trap is answering it like a form rather than like evidence: the playbook for getting through one is a piece in itself.
- Evidence. An audit report, a technical assessment report, and often an attestation letter summarising what was tested and fixed. Reviewers accept what they can check.
- Technical review. This is where the difference between SOC 2, a pentest and continuous scanning stops being academic. Sending the wrong one costs you a round trip.
- Legal. Your DPA, your subprocessor list, retention periods, breach notification window. Have these written down before you are asked: what each document has to contain is a piece in itself, and this is the stage that runs longest.
Where deals actually stall
Not usually on a failed control. On these:
- An unverifiable claim. "We follow best practices" invites a follow-up, and a follow-up is a week.
- Evidence that does not exist yet. You answer in three days, then spend a month scheduling a test because the report was requested at stage three and you started at stage three.
- A stale document. A report from eighteen months ago with no retest reads as "we did this once".
- An answer that contradicts another answer. Reviewers cross-check, and inconsistency costs more trust than a known gap does.
- Silence. A week of no reply moves you to the bottom of a queue you cannot see.
The one lever you control
You do not control the tier, the queue, or how many people have to sign. You control whether the evidence exists when it is asked for.
Strictly, there is a second lever: answering the repeatable questions once, on a trust page, so stages two and three start further along.
Preparing the pack before the first questionnaire arrives compresses stages three and four from weeks into days, because your answers arrive already backed. That is the whole argument for having a current test report, a retest after you fix, and a dated letter on file: not because the document is impressive, but because it removes the round trip.
Continuous scanners are fast but generally will not sign anything, which is a gap worth understanding before you rely on one. We wrote about what to look for in that category separately.
Before you send
A quick final check
Common questions
What is a vendor security review?
The process an enterprise runs before it lets a new supplier touch its data or connect to its systems. It usually combines a questionnaire, a request for evidence such as an audit report or a test report, a technical review of your answers, and a legal pass over data processing terms. It is run by the buyer, not by you, and the buyer decides what is enough.
How long does a vendor security review take?
For a mid-market buyer, two to four weeks is common once you respond promptly. At a large enterprise, or in a regulated industry, six to twelve weeks is normal because more teams have to sign. Most of the elapsed time is waiting on one side or the other, which is why having evidence ready is the single biggest lever you control.
Who actually reviews your answers?
Usually three different readers with three different questions. Procurement checks that the file is complete. A security reviewer checks whether your claims can be verified. Legal or privacy checks the data terms. An answer that satisfies one can still stall with another, so write for all three.
What is vendor tiering and why does it matter?
Buyers sort suppliers into tiers by how much damage a compromise would do, typically based on data sensitivity, system access and how many of their users depend on you. The tier is set early and it decides everything that follows: which questionnaire you get, whether an audit report is mandatory, and whether a named accredited firm has to have tested you. Ask which tier you are in during the first call.
NoteStage names, sequences and timings describe how enterprise vendor security reviews commonly run and will differ by buyer, industry and regulator; this is general guidance, not legal or compliance advice, and your buyer's own policy governs.