Ask a sales team how long it took to get a new tool approved and the answer is usually measured in weeks. Ask the security reviewer how long they spent on it and the answer is a few hours. Both are telling the truth. Very little of the elapsed time in a vendor review is work. Most of it is waiting: for a missing answer, for a questionnaire to come back, for the next reviewer in line, for someone to notice the request is stuck. The rest is reading that could have been done once and was done three times.
This post takes a vendor review apart, stage by stage, to show where the time goes and which design choices give it back. It is written for the people who run the process — procurement, vendor-risk and security leads — and uses the demo organisation in our screenshots, Northwind Labs, whose vendors are fictional. We do not quote industry cycle-time benchmarks here because the published numbers vary too widely to be useful; the best number is your own, and the last section shows how to get it.
In short
- Elapsed time is mostly waiting, not working. Incomplete requests, sequential approvals, full questionnaires and unowned queues add weeks; the reading itself adds hours.
- Seven delays recur. A vague request, no tier, reviews in single file, the questionnaire nobody needed, the ninety-page PDF, the contract redlined from scratch, and nobody chasing.
- Each has a design answer. One-sentence intake that asks the missing questions, tiering, parallel lanes with SLAs, pre-filled assessments, cited document extraction, a contract playbook and an outbox.
- Measure where requests wait. Average days per lane tells you which fix to make first. In InsightVendors it is a chart on the insights page.
Why slow reviews are a business problem
A slow review is not just an irritation for the requester. It has three costs a leadership team should care about. The first is the business value delayed: a sales team without its call recording tool, a support pilot that misses its quarter. The second is shadow purchasing: when the official route takes longer than a trial, people sign up on a card and accept the vendor's standard terms, and the risk review never happens at all. The third is reviewer burnout. A security team with a long queue rushes the reviews it does, which is exactly when the important finding on page sixty is missed.
Speed and rigour are usually presented as a trade-off. In vendor review they mostly are not. The same changes that remove waiting also make the review deeper, because they free reviewers to read what matters instead of chasing what is missing.
Where the time goes
Follow a typical request through a typical process and seven delays appear. None of them is anyone's fault; they are the result of a process designed around a form and an inbox.
| Delay | What happens | Who waits |
|---|---|---|
| 1. The vague request | The request says “we need Gong”. Procurement emails back to ask about seats, data, integration, an owner and a budget. | Requester, procurement |
| 2. No tier | Every vendor gets the full process because nobody decided up front how risky it is. | Everyone, for low-risk vendors |
| 3. Single file | Security reviews, then privacy, then legal, then finance. Each starts when the last one finishes. | Every reviewer after the first |
| 4. The full questionnaire | The vendor gets hundreds of questions, many of which its SOC 2 report already answers. It takes weeks to reply. | Security, the vendor |
| 5. The ninety-page PDF | A reviewer reads a SOC 2 report end to end to find the audit period, the opinion, the exceptions and the controls you must run yourself. | Security |
| 6. Redlining from scratch | Legal reads the vendor's terms against a playbook that lives in someone's head or a document nobody opens. | Legal |
| 7. Nobody chasing | Requests sit in an inbox. Nobody knows which lane is late, so nobody nudges it. | Everyone |
Delays 1, 3 and 7 are pure waiting. Delays 2 and 4 are work that should not exist. Delays 5 and 6 are real work done slowly because it is done by hand. The design answers follow the same grouping.
Start with a complete request
The cheapest delay to remove is the first one. Most requests arrive incomplete because the person asking does not know what the reviewers need. A long intake form does not fix that; people abandon it or fill it with guesses. What works better is to let the requester say what they want in their own words and have the system work out what is missing.
In InsightVendors a request can be one sentence: “We want Gong for sales call recording, about 40 seats, roughly $60k a year.” The Intake agent names the vendor, the category, the data it will touch, the spend and the urgency. It checks whether the organisation already has something similar, and it lists the questions it could not answer, so they are asked once, at the start, rather than one email at a time over a week.
The duplicate check matters as much as the questions. A request that turns out to be a new use of an existing vendor needs a much lighter review than a new vendor, and sometimes no new purchase at all. Catching that before any reviewer starts is the fastest review there is.
Size the review, then run it in parallel
Delays 2 and 3 are structural. The fix for the first is tiering: decide from what the vendor touches — data sensitivity, system access, business criticality, spend and regulatory flags — whether it is Tier 1 Critical, Tier 2 High, Tier 3 Moderate or Tier 4 Low, and let the tier choose the workflow. A low-risk fast track for a design retainer and a critical-and-regulated track for a hosting provider are both legitimate; the same track for both is not.
The fix for the second is lanes. Security, privacy, legal, finance, IT and the business owner each review at the same time, each with an owner and a service level in business days. Routing rules decide which lanes a request needs and record why: personal data adds a privacy lane, an integration adds IT, an AI vendor requires the AI questionnaire.
Illustrative only. With the demo's lane service levels, six reviews in single file add up to 22 days if each takes its full allowance; in parallel the longest lane, five days, sets the pace. Real reviews depend on the vendor too.
Parallel lanes do not make any single review faster. They stop each review from waiting for the one before it. They also make lateness visible, because every lane has a due date and an owner, which removes delay 7 almost as a side effect.
Ask the vendor only what the documents do not answer
Delay 4 is the questionnaire. Long questionnaires exist for good reasons: they make reviews comparable and they force a vendor to commit to answers in writing. But a current SOC 2 Type II report, an ISO/IEC 27001 certificate and a recent penetration test already answer a large share of a standard security questionnaire. Sending those questions again costs the vendor time, and every day the vendor spends answering is a day the request waits.
The Assessment agent picks the questionnaire from the tier — the InsightVendors Core set, aligned to SIG Lite, plus privacy, AI, business continuity or financial health where they apply — and pre-fills each answer that a document on file already proves, marking the source. Only the rest goes to the vendor, through a portal reached by a signed link with no account to create. The invitation itself waits in an outbox until a person releases it, because Northwind runs that agent at L2, “ask first”.
Read the documents and the contract once, with citations
Delays 5 and 6 are the real work. Nobody should skip it, and nobody should do it slowly. A SOC 2 report has perhaps a dozen facts a reviewer must know: the type (Type I is a point in time; Type II covers a period), the audit period, the auditor, the opinion, any exceptions, the complementary user entity controls (CUECs) you must run yourself, the subservice organisations it relies on, and whether a bridge letter covers the gap since the period ended. The Document agent extracts each of those and cites the page and the text.
That citation is what makes speed safe. In the demo, NimbusDesk's SOC 2 report is a Type I with an audit period dated in the future, which becomes a critical finding a reviewer can check in seconds by opening the cited page. PeopleLoop's report carries a CUEC saying user entities are responsible for enabling single sign-on and MFA: a control Northwind must run itself, which no questionnaire would have surfaced.
Contracts follow the same pattern. The Contract agent checks each clause against the organisation's playbook and proposes redlines. For Quill AI's terms of service, it checked ten clauses and found eight that deviate — including limitation of liability, data location, subprocessors, return and deletion of data, audit rights and termination for convenience. Legal still decides every redline. It no longer starts from a blank page.
A reviewer opens the SOC 2 PDF, scrolls for the audit period, searches for “exception”, copies notes into an email. Legal prints the vendor's terms and marks them up against memory.
Each fact is extracted with its page and quote. The reviewer checks the citations that matter, not the whole document. Legal reviews proposed redlines clause by clause and approves, edits or rejects.
Where this still takes time
Some delays are outside your control. A vendor that takes three weeks to answer the questions the documents could not cover will still take three weeks; the portal sends reminders and flags silence as a signal, but it cannot make the vendor reply. Contract negotiation is a conversation with the vendor's lawyers, and a good playbook shortens it rather than ending it. Document extraction is reliable on standard reports and weaker on unusual layouts, which is why every finding carries its page for a person to check.
Measure where requests wait
The single most useful number for fixing a slow process is the average time requests spend in each lane. It shows whether the bottleneck is security, legal, the vendor or the business owner who forgot to approve. In InsightVendors it is on the insights page, alongside spend by tier, the tier-by-risk heat map and requests by month.
For the last twenty requests, record when each arrived, when each lane started and finished, and when the decision was made.
Require the facts reviewers need at the start, and check for existing vendors and approved alternatives before any review begins.
Write down which facts set the tier, which lanes each tier needs, and an SLA for each lane.
Every lane starts when triage ends. Each has an owner and a due date.
Pre-fill from current documents; send the vendor only what remains.
Watch days per lane. Fix the slowest lane next, then the next.
None of these steps depends on buying software, and you can start on the first three with a spreadsheet. What software, and agents in particular, change is the cost of steps 4 and 5: the reading and the chasing that make parallel lanes and lighter questionnaires hard to sustain by hand.
Vendor reviews are slow because they wait, not because they work. Remove the waiting and the work gets better too.
Ask the missing questions once, size the review to the tier, run the lanes together, ask the vendor only what the documents leave open, and read every document once with the page cited.