Vendor requests

Anyone on your team can ask to use a new vendor, and an admin decides. Nothing reaches your vendor list, your trust center, or your audit evidence until someone approves it.

Asking for a vendor

Employees submit a request from the portal under Vendor requests. A request asks for three things:

• The vendor — its name, and optionally a link.
• What you’d use it for — the business justification your admins read when they review it.
• What data it would handle — enough for a reviewer to judge the risk.

Once submitted, the request shows the requester its own status, and the decision and reason when one is made. The same person can’t ask for the same vendor twice while it’s still in your workspace; one request gets one answer.

Requests are matched to an existing vendor by name, ignoring capitalisation and extra spacing, so two people asking for the same tool are answered by one decision. Picking the vendor from the list instead of typing its name always matches.

Reviewing a request

Admins see pending requests under Vendors > Requests in the app, alongside who asked, why, what data is involved, and the vendor’s risk rating once its assessment is complete.

Reviewing runs the standard vendor risk assessment. From the request you can:

• Approve — available once the risk assessment is complete. The vendor joins your vendor list and behaves like any other vendor from then on.
• Deny — available any time before a decision, with no assessment required, and always needs a reason. The requester sees the reason you give.

Note

Approval requires a complete assessment because approving is what puts a vendor into your public trust center, SOC 2 Section 3, and control evidence. Denying doesn’t, so you can reject a vendor without filling in a questionnaire for something you aren’t going to use.

After a decision

A denial can be lifted later — if a vendor addresses what you rejected it for, complete its assessment and approve it, and it joins your vendor list. Approval is one way: to stop using a vendor you’ve approved, delete it from your vendor list rather than denying it, which keeps its history intact and can be restored.

If several people asked for the same vendor, one decision answers all of them and everyone who asked is told.

Vendors awaiting a decision

A requested vendor exists in your workspace before it’s approved, but only admins working the review queue can see it. It stays out of the vendor directory, the public trust center, SOC 2 Section 3, control evidence, control scope, and the assessment gaps export until someone approves it — so an unapproved vendor is never presented to a customer or auditor as one you use. A denied vendor stays out of all of them too.

Adding a vendor that’s already been requested tells you who asked and when — or why it was denied — and links you to it, rather than quietly creating a second path to the same vendor.

Notifications

Admins are notified when a request is submitted, and requesters are notified when a decision is made. Both are delivered by email or Slack according to each person’s notification preferences, and both can be turned off — see the notification catalog.