Skip to main content
For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt. This page is also available in markdown by appending .md to the URL.
This guide is part of the User Guides collection. It is for the person who wants to start using a new tool or vendor, not for the risk team reviewing the request. If you are on the reviewing side, see the Analyst and reviewer guide.
Before anyone signs anything, your organization needs to know who the vendor is, what data they will touch, and whether you already pay for something that does the same job. That is what a vendor intake request is for, and it takes a few minutes. Coverbase does most of the typing. You confirm, correct, and decide.

​
Read this part first

Submitting a request is not approval. It does not authorize you to buy, sign, expense, or deploy anything.
When you finish, your request goes to your security or due diligence team, and they decide it. A vendor record may appear in Coverbase with your request attached, but it sits in Created status. It is not an approved vendor until someone reviews and accepts it. A completed intake form means “asked”, not “allowed”. Wait for the decision before you commit spend or send data.

​
Two ways to file one

The portal

A three-step form: Select Vendor, Additional Information, Review Questionnaires. Use the link your admin gave you.

Chat

Ask an AI assistant connected to Coverbase. Same request, same queue, no form.
They produce the same thing. Pick whichever you are already using. To file in chat, say what you want in ordinary language. You do not need to use the word “intake”:
I want to start using Northwind Analytics for product analytics.
My team needs a load testing tool and we’re looking at Loadspin. Can we buy it?
Is Acme approved for us to use?
That last one checks first and offers to file a request only if there is not already an approved record.

​
What you’ll be asked

1

Which vendor, exactly

Coverbase researches the company and shows you what it found: what they do, their website, their headquarters, their trust center. Check it. Two companies called Acme is common, and a request filed against the wrong one is sent back to you. If it is wrong, say so and correct it.
2

Whether you already have something that does this

You are shown existing vendors in your portfolio that cover the same job, and any prior relationship with this vendor. Depending on how your admin configured things, you may also see alternatives found on the web.If an approved vendor already does what you need, using it means no review, no procurement cycle, and no new contract.
3

What you'll use it for

You get a short list of use cases this vendor is commonly bought for, rather than a blank box. Pick one, or type your own if none fit.
4

Which services are in scope

A list of candidate services. You can add one that is not listed.
5

The inherent risk questionnaire

Coverbase does most of this one for you. It answers what it can from public sources and whatever context you provided, then shows you each answer with the reasoning behind it.Check them. Answers Coverbase was confident about are marked as such; the ones it was not are flagged for you to look at first. Anything about your intended use, the data you will send, or your internal owner is yours to answer, because public research cannot find it.
Behind the scenes, Coverbase also screens the vendor’s financial stability, security posture, and sanctions status, and checks whether the request duplicates something you already have. You do not have to ask for any of that. It runs as part of the flow, and you see the results.
Which of these steps you see depends on how your organization configured its intake portal. Some orgs turn off web alternatives, or pre-qualification, or prior assessment history. If a step described here does not appear for you, your admin turned it off.

​
Getting through it faster

Give context up front

Anything you already know: the use case, the data types involved, a link to their security page, the team that will own it. Coverbase feeds that into the drafting, so more context up front means fewer questions for you later.
Drafted answers come with a confidence signal. The low-confidence ones usually name what was missing, and they are where your knowledge adds the most. The high-confidence ones mostly need a glance.
A partially answered request is not in anyone’s queue. It sits open until you come back to it. If you do have to stop, you can pick it up later, in the portal or by asking the assistant where your request got to.
Questions about what customer data flows to the vendor drive the whole depth of the review. An optimistic answer here means a review scoped too shallow. If you do not know, say so.

​
After you submit

Your request lands in the risk team’s review queue with everything attached: your answers, the enrichment, the screening results, and the duplicate check. From there one of three things happens:
  • Approved. Onboarding starts and an assessment is created against the right control set, sized to the risk your answers indicated.
  • Sent back. A reviewer needs something clarified. You get a specific question rather than a rejection.
  • Rejected. Usually because an approved vendor already covers the need, or the screening surfaced something disqualifying.
You cannot edit your answers after submitting. A reviewer can correct them on the way through, and can send the request back to you if something needs your input.

Vendor intake in chat

The full conversational flow, step by step, including what your assistant will and will not do on its own.

Analyst and reviewer guide

What happens to your request on the other side, and what reviewers are looking for.