How Long Does a Customer Security Review Take?

From the seller's side, a customer security review takes as long as the buyer's process plus your own response latency, and only the second half is yours to move. The buyer is not being difficult. NIST CSF 2.0 expects its supply chain function to ensure that "planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships" (GV.SC-06), and regulated buyers have the same obligation in law: New York's 23 NYCRR 500.11 requires written policies covering "due diligence processes used to evaluate the adequacy of cybersecurity practices" of third-party service providers, and HIPAA at 45 CFR 164.308(b)(1) lets a covered entity hand protected health information to a business associate "only if the covered entity obtains satisfactory assurances." The contrarian point: the reviews that stall are rarely stalled by a missing control. They stall on an unanswered email, a questionnaire cell filled in by someone who did not check the setting, and a report that has to be requested a second time through legal.

Below: why the buyer cannot skip it, the six stages from the seller's seat and who holds the clock in each, what you send and how it changes the number of rounds, where the weeks actually go, the contract terms that are part of the review, what to do when it is blocking a deal, and the review that cannot finish.

Key takeaways

• The buyer's clock is set by how they tier you. NIST CSF 2.0 expects that "suppliers are known and prioritized by criticality" (GV.SC-04), so the depth of the review follows what your product touches, not the size of your company.
• Six stages: intake and tiering, questionnaire, evidence review, follow-up rounds, contract security terms, approval and onboarding. The follow-up rounds are where the weeks go, and each round is your latency plus their queue.
• The artifact you send first decides how many rounds there are. A current SOC 2 Type II report answers most of a questionnaire before it is sent.
• Standard instruments exist so that you answer once. The Cloud Security Alliance's CAIQ v4 carries 261 questions, down from 310 in v3.1, and CAIQ-Lite carries 124.
• The review does not end at signature. NIST CSF 2.0 expects supplier risk to be "monitored over the course of the relationship" (GV.SC-07), and 23 NYCRR 500.11 requires "periodic assessment of such third-party service providers based on the risk they present."

Why the buyer cannot skip it

Every mature buyer runs a vendor risk programme, and our vendor risk management guide describes that programme from their side: inventory, tiering, assessment depth matched to tier, ongoing monitoring. This article is the mirror image, and the first thing to understand from the seller's seat is that the reviewer is executing an obligation, not exercising a preference.

The obligation is written down in several places. NIST CSF 2.0's Govern function carries a supply chain category whose outcomes include GV.SC-04, "suppliers are known and prioritized by criticality"; GV.SC-06, "planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships"; and GV.SC-07, "the risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship." A buyer aligned to the CSF, which is most of them, has to do the review before signing and keep doing it after.

Regulated buyers have it as a rule. 23 NYCRR 500.11 requires a covered financial services entity's third-party policies to address "the identification and risk assessment of third-party service providers," the "minimum cybersecurity practices required to be met by such third-party service providers," the due diligence processes quoted above, and "periodic assessment of such third-party service providers based on the risk they present." A HIPAA covered entity needs the satisfactory assurances that a business associate agreement provides, which is why the BAA question arrives with the questionnaire if you touch health data. An EU financial entity under DORA has contractual requirements it must impose on ICT providers, covered in our DORA contract piece. And any buyer subject to the GDPR needs a data processing agreement if you process personal data on its behalf.

Two consequences for your calendar. The depth of the review is proportional to what you touch, so a vendor with production access or sensitive data will be reviewed at the top tier however small it is. And the review cannot be talked down, because the reviewer's own auditor or regulator will ask to see it.

The six stages, from the seller's seat

Read the middle column. Of the six stages, three are on your clock or shared, and every one of the stalls in those rows is administrative rather than technical. That is the good news and the whole argument of this article: the part of the calendar you control is mostly latency, and latency is cheap to fix.

What you send decides how many rounds there are

The reviewer's job is to reach a defensible conclusion about your controls with the least effort their tier permits. What you send first determines how much effort that takes.

The AICPA describes SOC services as assurance reports that "provide users with valuable information that is needed to assess and address the risks associated with outsourcing services," which is the reviewer's job description. A current SOC 2 Type II report, sent under NDA at the evidence stage, answers most control questions on any questionnaire before the questionnaire is sent, and a reviewer who has it will often accept a short supplement instead of the full instrument. Two caveats the reviewer will apply and you should apply first: the period and the scope are on the cover, and an exception with a weak management response generates a follow-up round on its own. How to read a SOC 2 report is the reviewer's checklist; read your own report with it before you send it. If the report's period has ended, a bridge letter is what closes the gap, and not having one ready is a round you did not need.

Without a report, the questionnaire is the review, and the standard instruments are worth knowing because they are what a tier-appropriate reviewer will accept in place of a bespoke form. The Cloud Security Alliance's CAIQ is "a downloadable spreadsheet of yes or no questions that correspond to the controls of CSA's Cloud Controls Matrix," and the CSA says a provider "can use CAIQ to document what security controls exist in their services." CAIQ v4 carries "261 questions instead of the 310 found in v3.1," and CAIQ-Lite "contains 124 questions compared to the 261 found in CAIQ, while still addressing all of CCM's control domains." The underlying Cloud Controls Matrix v4.1, released 01/27/2026, is "a cybersecurity control framework made up of 207 controls across 17 security domains." A completed CAIQ can also be submitted to the CSA's STAR registry, which gives a reviewer a stable place to find it. The SIG is the other standard instrument our vendor risk guide names; buyers who use it will usually accept a completed one from a previous review. And if your product has AI in it, the three questions that now dominate and the four artifacts that answer them are covered in our AI questionnaire piece, which this article does not repeat.

The last row is the least used and worth a sentence. NIST says a Current Profile "can be used to document and communicate the organization's cybersecurity capabilities and known opportunities for improvement with external stakeholders, such as business partners or prospective customers." For a company that has no attestation report yet, a candid Current Profile mapped to a framework the reviewer recognises is a far better artifact than a questionnaire full of yes, and it shows the reviewer that you know your own gaps, which is most of what they are trying to establish.

Where the weeks actually go: the follow-up rounds

A review with a clean package and one round finishes on the buyer's intake and legal calendar. A review with four rounds takes four times your latency plus four times their queue, and the queue at a large buyer is measured in weeks per turn. Rounds are generated by four things, all avoidable.

Inconsistent answers. Two questionnaires answered by two people three weeks apart, giving different answers about the same product. The reviewer who notices is the one who was going to sign. Answer from one source of truth; the AI questionnaire piece makes the same point and the principle is general.

Answers that do not match the report. A questionnaire that says all administrative access has multifactor authentication, next to a SOC 2 report carrying an exception on exactly that control. The report is the one the reviewer believes.

Evidence that raises a question it does not answer. A penetration test report with no summary, no scope statement and no retest, which tells the reviewer you test and nothing about what was found. A sub-processor list that names the email tool and not the model provider behind the core feature.

Answering a different question. Asked for your incident notification window, you send the incident response policy. The reviewer wants a number of hours and a trigger, and our breach notification deadlines piece is the reference for what those numbers have to reconcile with.

The rule for the round itself: answer in days, and when the honest answer is bad, say so with a date. A reviewer can risk-accept "partially implemented, target date named," escalate it or make it a contract condition. A confident yes that a later audit contradicts is a contract problem, because most security questionnaire answers end up inside a representation. Our cyber insurance questionnaire piece shows what an overstated answer costs in a neighbouring context, and the mechanism is the same.

Contract security terms are part of the review

The stage most sellers do not count is the one that most often moves the signature date. A security addendum, a data processing agreement, a notification clause: each is drafted by the buyer's counsel from the buyer's policy, and 23 NYCRR 500.11 is explicit that a regulated buyer's third-party policy must carry guidelines addressing access controls, encryption, notification of cybersecurity events and representations about the provider's practices. Those guidelines arrive as clauses.

Two failure modes. The addendum contradicts your questionnaire, because the questionnaire was answered by security and the addendum is being read by legal, and the reviewer has to reconcile them. Or the addendum commits you to something your incident plan cannot deliver, most often a notification window shorter than the time it takes you to know anything. Read the addendum against your own answers before it reaches counsel, and treat the notification clause as a control you are agreeing to operate, not a term to be negotiated down and forgotten.

What to do when the review is blocking the deal

Ask for the tier and the acceptance criteria. Most buyers will tell you which tier you are in and what closes it. Our vendor risk guide describes conditional approval with remediation requirements as a normal outcome, and a conditional approval with dated items is a signed deal.

Offer the artifact you have, and a committed date for the one you do not. A Type I report with a committed Type II date is a recognised bridge, and our Type I versus Type II guide covers how to sequence it so the window is already open when the Type I circulates.

Disclose the gap with a date rather than losing a round to it. The reviewer's follow-up on a vague answer costs more time than the precise partial answer would have.

Put one person on it with the authority to answer. The stalls in the table above are almost all somebody waiting for somebody. A named owner with a day of calendar each week for the duration of the review shortens it more than any control you could stand up in the same period.

Do not promise the control you do not run. The deal closes and the review comes back at renewal, with your own answers as the baseline.

The honest caveat: the review that cannot finish

Some reviews will not close whatever you do, and it is better to know in the first week.

If the buyer's policy requires an attestation report for your tier and you do not have one, no answer speed helps. That is a programme decision, not a review tactic, and our SOC 2 timeline makes the case for reading the vendor security requirements attached to your largest open deals before starting the programme at all, because they are the only demand evidence that matters. If the requirement is real and you are starting from nothing, the report is months away, and the honest conversation is about a Type I plus a committed date, or about the buyer's willingness to accept a conditional approval in the meantime.

Against our own interest: if you touch no sensitive data and have no production access, the buyer's own tiering will put you in the tier our vendor risk guide describes as a lightweight review, and buying a compliance programme to pass that review is money spent answering a question nobody asked. Ask the tier first.

Where Top Floor fits

The work we are useful for is the package and the cadence: assembling the evidence set a given tier needs, reading your own report and your own answers the way the reviewer will before they arrive, and keeping the answers current, which is the part that decays fastest as features ship and sub-processors change. For a company answering reviews continuously that sits inside compliance as a service. Where the review keeps ending in "come back with a report," that is SOC 2 readiness work, and where the question is whether a proposed contractual commitment is honest before it becomes a term, that is audit and assurance advisory.

We do not issue the report and we do not sit on the buyer's side of the table. Both are worth knowing when you weigh the advice.

How to decide this week

Pull the last three security reviews you went through and find, for each, where the calendar went: the buyer's queue, your latency, or rounds. If it was latency or rounds, you have a process problem that a named owner and a single source of truth will fix before the next review starts. If it was the buyer's queue, ask your champion for the tier and the criteria at the start of the next deal rather than the end.

Then build the package once: report or Current Profile, bridge letter if the period has ended, pentest summary, indexed policies, sub-processor list, completed CAIQ. Store it where sales can find it and security can update it, and read it against itself for contradictions. That afternoon of work removes more weeks from your next review than anything else on this page.

Frequently asked questions

Why do enterprise security reviews take so long?

Because the buyer is executing an obligation with a queue in front of it, and because most reviews take more than one round. NIST CSF 2.0 expects due diligence before a supplier relationship is formed and monitoring over its course, and regulated buyers have the same duty in rules such as 23 NYCRR 500.11, so the review cannot be skipped and its depth follows your tier. Inside that process, the weeks are usually spent in follow-up rounds generated by inconsistent answers, evidence that raises questions it does not answer, and slow replies. The buyer's queue is not yours to shorten. The rounds are.

What should we send a customer security reviewer first?

The artifact that answers the most questions at once for your tier. For a company with a current SOC 2 Type II report, that is the report under NDA, with a bridge letter if the period has ended, read first with our guide to reading a SOC 2 report so you know what the reviewer will find. For a company without one, a completed standard questionnaire such as the CSA CAIQ and a candid CSF Current Profile do more than a bespoke form full of yes, and NIST explicitly describes a Current Profile as a tool for communicating capabilities and known opportunities for improvement to prospective customers.

Do we need a SOC 2 report to pass a vendor security review?

It depends entirely on the buyer's tier for you, and the honest way to find out is to ask. Our vendor risk guide describes the buyer side: a formal assessment reviewing an independent report for the highest tiers, a streamlined assessment for the middle, and a lightweight review with no formal questionnaire for vendors with no sensitive data and no system integration. If your tier requires an attestation report, no questionnaire substitutes for it and the programme decision comes first. If it does not, buying one to pass the review is spend with no return.

Does the security review end when the contract is signed?

No. NIST CSF 2.0 expects the risks posed by a supplier to be monitored over the course of the relationship, and 23 NYCRR 500.11 requires periodic assessment based on the risk the provider presents. In practice that means the next review starts from the file you built for this one, including any conditions attached to a conditional approval, and a renewal review in which your answers have quietly diverged from last year's is the one that stalls. Keep the package current and the renewal is an update rather than a second review.