Getting an AI vendor through a corporate security review

A corporate security review of an AI vendor takes 4–6 weeks at UC Berkeley and 1–3 months at UW–Madison, on their published estimates. Both clocks start only once the vendor’s evidence is complete or an analyst is assigned. The stage that slips is that evidence chase, so submit a complete document pack on day one.

• Published review clocks: 1–3 months (UW–Madison Office of Cybersecurity); 4–6 weeks (UC Berkeley Vendor Security Assessment).
• What the clocks leave out: UW–Madison’s excludes the queue before an analyst picks your request up. UC Berkeley’s excludes the weeks spent collecting the vendor’s SOC 2, questionnaire, pen test and diagrams.
• The swing stage inside the clock: assessment sessions, 1 to 10 of them, weekly: up to 50 of the 73 business days in UW–Madison’s stage estimates.
• The fix: the Day-Zero Pack. Twelve documents in hand before you file the request, so the clock starts on the day you submit.
• AI-specific evidence: the CSA AI-CAIQ (mapped to the 247-objective AI Controls Matrix), ISO/IEC 42001, NIST AI 600-1, and the vendor’s named model providers.

How long will my AI vendor’s security review take?

An AI vendor security review takes about 2.4 to 14.6 weeks inside the reviewer’s clock, if you add up the stage-by-stage estimates UW–Madison’s Office of Cybersecurity publishes for its own process. The table converts them to business days, assuming one assessment session per week and five business days per week.

That range brackets the university’s own 1–3 month headline. Two points matter more than the total. First, assessment sessions make up 50 of the 73 high-case days, about 68%, so the number of sessions decides how long the review takes. Second, UW–Madison says its estimates “apply once your risk assessment has been assigned to a risk analyst”, and that “high demand for risk assessment work may delay the start of your project.” The queue is not in the number.

Your own review will differ in detail, but every third-party risk function has an intake, an assessment, a write-up and a sign-off. Ask your security team for their version of this table before you commit to a go-live date.

The stage that slips: the evidence chase before the clock starts

The stage that slips in an AI vendor security review is evidence collection, and neither published timeline puts a number on it. UC Berkeley’s service says a typical assessment takes 4–6 weeks “starting from the date the Vendor has provided all the information requested.” UW–Madison lists “response time of the vendor” as a driver of its range, and says documents supplied upfront “can greatly expedite the review.”

Reviewers spend their effort up front, which is why a missing document blocks everything. Gartner’s 2019 third-party risk research found that 73% of the effort devoted to risk identification goes into due diligence and recertification, and only 27% goes into identifying risks over the life of the relationship. The review puts most of its weight on the one moment when your vendor is waiting on a document.

The typical pattern: you file the request and the analyst sends a list. The vendor’s SOC 2 is released only under an NDA, and the NDA goes through your legal team. The pen test summary turns out to be more than a year old. The questionnaire comes back with “see attached policy” in place of answers. Each loop is a round trip between three organisations. None of it counts towards Berkeley’s published clock, and at UW–Madison it is one of the reasons the range stretches. A security review is only as fast as the slowest document you did not ask for before you filed.

The Day-Zero Pack: twelve documents to have before you file

The Day-Zero Pack is the set of documents that lets a reviewer start the clock on the day you submit. It is built from what UW–Madison and UC Berkeley ask for, plus the AI-specific items those lists now include. Get the vendor’s NDA signed first, because items 2 and 3 are usually released only under one. The 12-month freshness thresholds in the last column are our working rule, not a published standard. The ISO 2013 cut-off is the exception: that one is set by the IAF.

Items 10 to 12 are yours, and a sponsor can finish them in an afternoon. They also set the depth of everything else. Items 1, 2, 3, 4 and 6 are what UW–Madison names: “SOC 2, CAIQ, HECVAT, and relevant architectural or data flow diagrams”, plus “AI security documentation, vulnerability assessments, penetration test results”. Berkeley asks for a SOC 2 Type II report, and for PCI DSS documentation where card data is in scope. If the vendor is an AI agent that talks to your customers, which is the category LeadsNow works in, reviewers ask a set of questions about conversation data. We have published those nine questions and what a good answer looks like. This page does not repeat them.

How much review your AI vendor gets depends on the data it touches

The depth of an AI vendor security review is set by the data classification you declare, not by how much AI is involved. Declare it accurately and early. An under-declared classification that gets corrected mid-review re-scopes the assessment.

An AI appointment setter that reads CRM contacts and records calls handles your customers’ personal information. If your company classes that as sensitive, plan for SIG Core depth, not SIG Lite. The single cheapest way to shorten an AI vendor security review is to scope the tool so it never touches the data class that would trigger the deeper questionnaire.

How to read the vendor’s evidence before your security team does

Read the vendor’s evidence before you submit it, because a document your reviewer rejects costs a full round trip. Four checks:

• SOC 2 type and period. A Type 1 report covers control design at a single date. A Type 2 covers how the controls operated over a period. Check the period end date, the trust services criteria in scope, and whether the AI product is in the system description at all.
• ISO 27001 edition. Under IAF MD 26, the transition to ISO/IEC 27001:2022 ended 31 October 2025, and certificates against the 2013 edition expired or were withdrawn at the end of that period.
• CSA STAR level. On the STAR Registry, Level 1 is a self-assessment and Level 2 is a certification or third-party attestation. Neither is wrong, but they are not the same evidence.
• The AI layer. The CSA’s AI Controls Matrix v1.1 (22 June 2026) has 247 control objectives across 18 domains. It ships with the AI-CAIQ and maps to ISO 42001, ISO 27001, the EU AI Act and NIST AI 600-1, the Generative AI profile published 26 July 2024. A vendor that has filled in the AI-CAIQ has already answered most of what your reviewer will ask about models.

Whether a vendor can produce these items at all is itself a signal. Which vendor to shortlist in the first place is covered by our 20-point AI vendor selection score. Its governance-mapping row scores the same evidence earlier.

What running the review costs you as the sponsor

The internal sponsor of an AI vendor security review is not a spectator. UW–Madison’s process expects the requesting team at the kick-off, at every one of the 1–10 assessment sessions, and at two review meetings. It also expects that team to “provide any documentation in advance.” Budget sponsor time weekly for the length of the assessment, and name one person who can answer scope questions without escalating.

Three things run alongside the security review, and none of them is part of it. Legal review of the DPA: send the vendor’s standard terms on day one. UW–Madison asks up front whether the vendor will sign an agreement sharing data-protection responsibilities (a BAA, DUA or SLA). Channel compliance, if the AI contacts people: consent, disclosure and suppression are a separate reviewer’s questions, covered in the AI outbound compliance checklist for enterprise. Integration change control for SSO and CRM write access. On a corporate rollout of AI appointment setting, security review is the clock you control least. Start it in week one, in parallel with the build, not after the pilot.

Neither university puts a number on the evidence chase: Berkeley’s estimate excludes it, and UW–Madison folds it into its range. Measure your own: log the date you filed, the date the pack was complete, and the date the analyst started. The gap between the first two is the part of the review you control.

Frequently asked questions

How long does a security review take for a new AI tool?

Published estimates run from 4–6 weeks (UC Berkeley) to 1–3 months (UW–Madison). Berkeley’s starts when the evidence is complete and UW–Madison’s when an analyst is assigned. Queue time comes on top, and at Berkeley so does the document chase.

Is a SOC 2 Type 1 report enough for an AI vendor?

Usually not for sensitive data, because a Type 1 report covers control design at a single date, not operation over time. Check the auditor, too. The Journal of Accountancy (February 2026) warns that a rushed report “may rely too heavily on inquiry”.

Does an ISO 27001:2013 certificate still count?

No. Under IAF MD 26, the transition to ISO/IEC 27001:2022 ended 31 October 2025, and certificates against the 2013 edition expired or were withdrawn then. Ask for the 2022 certificate and its Statement of Applicability.

Which questionnaire should we send an AI vendor?

Your security team’s standard one, plus the CSA’s AI-CAIQ for the AI layer. The AI-CAIQ maps to the AI Controls Matrix v1.1, which has 247 control objectives across 18 domains. Ask whether the vendor has already completed one before you send a blank copy.

What slows an AI vendor security review down the most?

Missing evidence at the start. UC Berkeley’s clock starts only once the vendor’s information is complete, and UW–Madison names vendor response time as a driver of its range, so every document you request after filing adds time. Collect the SOC 2, pen test, diagrams, sub-processor list and AI documentation first.