How to build vendor security review

What matters here

• Tier on what the vendor can reach, not on what it costs. A cheap tool holding customer records outranks an expensive one holding nothing.
• Size the questionnaire to the tier. A hundred questions for a low-risk tool guarantees the process gets bypassed.
• Track conditional approvals to closure. A condition nobody follows up is an approval with extra words.
• Re-review when the evidence expires, not annually. A SOC 2 report from two years ago is not evidence.
• Measure time to decision by tier. A slow low-tier path is what pushes spend onto personal cards.

Who this is for

You run security, procurement or compliance. Every tool needs review, the process is the same regardless of risk, and teams route around it when they are in a hurry.

How it works in practice

From somebody wanting a tool to being allowed to use it, in order.

1. 1

   The request captures what the vendor will reach

   Data types, systems, whether it processes personal data, and where.

2. 2

   The tier is derived from that, not from cost

   Data classification and integration depth decide it, and the tier decides everything after.

3. 3

   The questionnaire matches the tier

   A handful of questions for low risk, a full assessment with evidence for high.

4. 4

   Evidence is collected once and reused

   A SOC 2 report already on file for another review is not requested again.

5. 5

   Conditions are tracked as work with owners

   Not written into an approval and forgotten.

6. 6

   Re-review fires when evidence expires

   Rather than on an annual date that has nothing to do with the risk.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up, then tier on data access

   Cost correlates poorly with risk and is the wrong input.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Vanta and Coupa, or
   whatever we run in those seats.
   
   Build tiering from what the vendor will actually reach:
   
     What data types: none, business data, personal data, customer records,
     regulated data
     How it connects: standalone, SSO only, read access to a system, write
     access, or a full OAuth grant over our workspace
     Where it processes and stores, for residency
     Whether it is in a critical path, so an outage matters
     Whether it trains on our input
   
   Derive the tier from those. Never from contract value. A free tool with
   an OAuth grant over the company Drive outranks a six figure tool that
   holds nothing, and tiering on cost gets that exactly backwards.

   Integration depth is the input people most often omit and the one that most often changes the tier.

2. 2

   Size the questionnaire to the tier

   A hundred questions for a low-risk tool is a process people bypass.

   Headless skills build-workflow

   Copy

   Use build-workflow. Build a question set per tier:
   
     Low: a handful of questions, answered internally from public
     information, no vendor contact needed
     Medium: a short questionnaire plus a current certification
     High: full assessment, penetration test summary, subprocessor list,
     data processing agreement, architecture review
   
   A low-tier review should complete in hours without the vendor being
   contacted at all.
   
   If every request goes through the same process, the low-risk ones queue
   behind the high-risk ones and somebody buys the note-taking app on a
   card. The tiering exists to protect the high-tier reviews from the volume
   of trivial ones.

3. 3

   Collect evidence once and reuse it

   Asking a vendor for a report you already hold wastes both sides.

   Copy

   Hold an evidence library: certifications, penetration test summaries,
   subprocessor lists and data processing agreements, each with an expiry.
   
   Before requesting anything from a vendor, check whether we already hold
   current evidence from another review. Large vendors are reviewed
   repeatedly by different teams and asked for the same report every time.
   
   Where a vendor publishes a trust centre, take the evidence from there
   instead of emailing.
   
   Store the expiry on every artefact. That date, not an annual review
   cycle, is what triggers the next look.

4. 4

   Track conditions as work, not as words

   A condition in an approval document is a sentence, not a control.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then handle conditional approvals properly.
   
   An approval with conditions creates tracked items, each with an owner and
   a due date: enable SSO before rollout, restrict the OAuth scopes, sign
   the data processing agreement, disable training on our data, complete a
   penetration test before renewal.
   
   Chase them and report the open ones. A condition written into an approval
   and never followed up is an unconditional approval with extra words, and
   that is the most common failure in this whole process.
   
   Where a condition is not met by its date, escalate to the business owner
   and the security owner, not to a queue.

5. 5

   Re-review on expiry, and measure the decision time

   A slow low-tier path is what pushes spend onto cards.

   Copy

   Trigger re-review from events instead of a calendar:
   
     A certification expiring within 60 days
     The vendor changing scope, such as requesting broader OAuth access
     A publicly disclosed breach at that vendor
     A renewal approaching
     A material change in the data we send them
   
   Report: time to decision by tier, reviews in flight and their age,
   conditions open and overdue, evidence expiring in the next quarter, and
   tools discovered in use with no review at all.
   
   Time to decision on low-tier requests is the number that determines
   whether people use this process or route around it. If it is measured in
   weeks, they will route around it.

6. 6

   Test it, then hand the tiering to security

   Because the risk criteria change as the estate does.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production.
   
   Then open the same workflow in Tray Build so security and procurement can
   adjust the tiering criteria, the question sets and the re-review triggers
   in the visual canvas.

What it connects to

Review touches procurement, the evidence library and the people waiting on a decision.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides