Third-Party Onboarding: How Security Approves a New Vendor

Security often hears about a new vendor after the business has already signed a contract. Third-party onboarding is the review a new vendor goes through before it gets access to your data or systems. An employee's answers about the vendor's use set a risk tier, which decides how much review happens before security approves or rejects it.

The process starts with an internal request, and the vendor's own evidence comes later. The requester's answers about data, access, and criticality set the tier, and review depth follows that tier. Every request ends in a recorded outcome the requester sees, and a vendor found already in use goes through the same steps.

Onboarding sits early in the third-party risk management (TPRM) lifecycle, right after discovery and before ongoing monitoring.

Finance onboarding is a separate job that sets up supplier records and payment details. Security-led vendor onboarding decides whether the vendor should get access at all.

What third-party onboarding covers

Third-party onboarding answers two questions before the relationship starts. Should you work with this vendor, and how closely do you need to review it? The first is a go or no-go call, while the second determines how much effort the review deserves.

Both answers depend on inherent risk, meaning the risk a vendor brings before you've reviewed its controls. 

Ponemon Institute and Imprivata found that 47% of surveyed organizations had a breach or cyberattack within 12 months involving third-party access to their network. Access drives exposure, so your onboarding record needs to show exactly what the vendor can reach.

To make both calls, the third-party onboarding process captures three facts about the vendor:

• Business purpose: What the vendor will do for your organization and which team depends on it.
• Data and system access: Which data, such as personally identifiable information (PII), and which systems the vendor will touch.
• Operational criticality: How much disruption you'd face if the vendor went down or the relationship ended.

The requester is the employee who wants to use the vendor, and they're the best first source of risk information. They know what the vendor will do and what data it will see long before the vendor fills out a questionnaire. Security turns those answers into a tier and a review plan, while procurement and legal often handle commercial and contract terms.

Keep onboarding focused on the decision itself. The deeper review of a high-risk vendor's controls belongs to vendor due diligence, which runs inside onboarding when the tier calls for it.

Two ways a vendor arrives: before purchase, or already in use

A vendor reaches security in one of two ways, and both end in the same tiered review. On the ideal path, someone submits a request before purchase. On the reactive path, someone finds the vendor after a team has started using it.

In both cases, you get information from an internal team member, use it to assign a tier, and then evaluate the vendor as needed. You don't need a second process for vendors that arrive late.

The table below compares the two paths stage by stage:

A vendor found in use is a late onboarding request, so treat it as one instead of opening a discovery project. Send the request to the internal owner who brought the vendor in, sometimes called the champion. That person holds the answers about how the vendor is used.

Vendors can land on this path when employees adopt tools on their own. The UpGuard State of Shadow AI report found that eight out of 10 surveyed employees use unsanctioned AI tools. Any of those tools can become a vendor relationship that started without a security review.

Vendors in use can surface through sources such as expense reports, corporate card statements, or browser-based discovery, but finding them is a separate job. Once one surfaces, the third-party vendor onboarding process picks up exactly where the before-purchase path would.

How to run third-party onboarding, step by step

Third-party onboarding runs on a short sequence, and most of the work happens before the first request arrives. 

Once you set your tiers and intake questions, each new vendor moves through the same steps. Write the sequence down as a vendor onboarding policy so requesters and reviewers follow one version of it.

Three setup steps come first, then four steps every request follows:

1. Define tiers first: Decide what puts a vendor in each tier. For example, tier one might cover vendors that are business-critical or have access to PII.
2. Write the intake questions: Ask what the vendor will do and what it can reach. Add one on business dependence, using multiple-choice answers.
3. Publish one place to submit requests: Put the link where people already look, such as the intranet or the employee handbook.
4. Tier the vendor from the answers: Apply your tiering rule to each request, by hand or with rules that map answers to tiers.
5. Scale review to the tier: A low-tier vendor may need only a quick check. A high-tier vendor gets a security questionnaire and supporting evidence.
6. Record the decision and tell the requester: Log the outcome with its reasons. Then let the requester know where the vendor stands.
7. Hand approved vendors into monitoring: Onboarding ends at approval. Ongoing monitoring then takes over, with the vendor's tier setting the review cadence.

Tiers and intake questions carry most of the weight in this sequence, because a tier is only as good as the answers behind it. Nobody can tier a free-text answer such as "it handles some customer information" without a follow-up call. A select list with options like "no personal data" or "customer PII" lets you map each answer to a tier.

A single request channel matters more than its format. Whether it's a form or a ticket queue, publish it in one place and point every procurement conversation there. Requests that arrive by email or chat tend to skip the intake questions, leaving you tiering by guesswork.

Proportional review keeps the process fast enough that people use it. If every vendor gets the full questionnaire, a low-risk content scheduling tool waits behind a payroll processor that can see every employee record. Tiering sends the payroll processor to a deep review, while the scheduling tool may clear in a day or two.

Many programs ask high-tier vendors for a SOC 2 Type II report, issued by an independent auditor against the Trust Services Criteria from the American Institute of Certified Public Accountants. An ISO/IEC 27001 certificate shows the vendor runs a certified information security management system.

The handoff in step seven is where vendors sometimes drop out of view. Pass the tier and any open conditions to whoever runs ongoing monitoring, so the review cadence matches the risk you found. Conditions with a due date also need someone who checks that they are closed.

You'll know third-party onboarding is working when every new vendor has a request on file and a tier. Each one should also have a recorded outcome and a named owner. If any of those pieces are missing, the vendor isn't fully onboarded yet, even if it's already in use.

Approve, approve with conditions, or reject

The decision is the output of onboarding, so make it explicit and record it. A vendor that's "probably fine" after a call has no outcome on record, and the next reviewer has to start over.

Many programs work with three outcomes:

• Approve: The vendor can go live as requested.
• Approve with conditions: The vendor can proceed once it meets the named conditions, by a date someone owns.
• Reject: The risk is too high for the use case, or the vendor can't supply the evidence its tier requires.

Approve with conditions fits when one gap needs closing first, such as a remediation item due before go-live or SSO for every user. You might also limit the vendor to less data than the requester first asked for. Conditions often become contract terms, so share them with legal before signing.

UpGuard data shows 62% of Vendor Risk Onboarding Portal requests that end in rejection reach a decision within a day, so the requester can start looking at alternatives instead of waiting out a review.

Record your reasons for the decision, because auditors and the next reviewer tend to look for them. A record that says "approved, tier two, SOC 2 report reviewed, SSO required before go-live" answers their questions without a meeting.

Close the loop by telling the requester the outcome and the reasons. A quick, clear answer shows the business that the front door works, which makes people more likely to use it next time.

A third-party onboarding checklist

Use this third-party onboarding checklist to confirm your process is in place. Answer yes or no for each item, and treat every "no" as your next fix. The first list covers setup work you do once, and the second covers what happens on each request.

Before the first request arrives, confirm that:

• You’ve defined your tiers, with example criteria for each one.
• Each tier has a set review depth, from a quick check to a full assessment.
• Your intake questions use multiple-choice answers where possible, and your team agrees on them.
• You’ve published the request channel where employees look for it.
• You’ve written the onboarding process down as a policy.

For every request, confirm that you:

• Applied the tiering rule to the requester’s answers.
• Set the review depth to match the vendor’s tier.
• Recorded the outcome and its reasons.
• Informed the requester of the outcome.
• Handed the approved vendor into ongoing monitoring with a named owner.
• Sent any vendor already in use through an onboarding request to its internal owner.

Where third-party onboarding breaks

Third-party onboarding usually breaks through small slips that make it look finished when it isn't. Each one below has a direct fix:

• Security only finds out after signing: The vendor lands on the reactive path by default. A published request channel moves more vendors to the before-purchase path.
• Every vendor gets the full questionnaire: The queue backs up, and teams start buying around the process. Tiered review keeps low-risk requests moving.
• Answers are free text: Nobody can tier "we'll use it for marketing." Multiple-choice intake questions turn answers into tiers.
• Decisions aren't recorded: An approval in a chat thread disappears. Record every outcome and its reasons where the next reviewer can find it.
• Nobody owns the vendor after approval: No one watches for changes once the request closes. Name an owner and an escalation route at approval.

The queue problem tends to feed the first one. When approvals take weeks, requesters are more likely to sign first and ask later, which pushes more vendors onto the reactive path.

That queue doesn’t have to run for weeks. Across Vendor Risk onboarding requests, the median request moves from submission to recorded outcome in five days, a third close in under a day, and 56% finish in under a week.

Free-text answers and unwritten decisions do slower damage. Both force the next reviewer to rebuild context from scratch, which adds days to each request and weakens your audit trail.

Relationship owners see the problems first. Gartner found that 95% of surveyed owners saw a third-party red flag within 12 months, and only around half escalate it to compliance. A named owner with a clear escalation route gives those warnings somewhere to go.

Every fix on the list points back to one design, where the requester's answers set the tier and the tier sets the review. That design is what keeps onboarding fast enough that the business keeps using it.

How UpGuard Vendor Risk helps with third-party onboarding

Vendor Risk includes vendor inventory, discovery, and onboarding features that follow the sequence described above. Here's what you can do with them:

• Onboarding Portal: Collect requests from employees without them needing an UpGuard license. Accept submissions only from your approved email domains, and post the portal link in your company handbook or an intranet procurement page so employees can find it.
• Onboarding request questionnaire: Edit the default questionnaire, which collects what you need to evaluate and tier vendors. Automation rules apply tiers from the answers.
• Request review: Opening a request assigns it to you with a one-week due date and medium priority. You can change these settings anytime.
• Optional assessment: Decide right away, or monitor the vendor and assess it first. Then link the risk assessment to the request.
• Recorded outcomes: Use the three default outcomes, including Approved with conditions, or define your own. UpGuard logs each outcome.
• Requester updates: Keep your requester informed with automatic email updates each time the request's status changes.

Choosing a tool is its own decision, and our comparison of third-party onboarding software covers the options.

Start a free trial to see how UpGuard Vendor Risk handles your next onboarding request.

Frequently asked questions

What is a vendor onboarding form?

A vendor onboarding form is the intake questionnaire a requester completes about how they’ll use the vendor and what it can access. It's different from the supplier form finance uses to set up payment.

How is third-party onboarding different from due diligence?

Onboarding is the full workflow, starting with a request and ending in a recorded decision. Due diligence is the review step inside it, and its depth scales with the vendor's tier.

Can security approve a vendor with conditions?

Yes. Security can approve a vendor on the condition that it closes named gaps, such as fixing a finding before go-live, and should record those conditions with the decision.

Who should own third-party onboarding?

Security or the TPRM lead should own the process and the final decision. The requester owns the business relationship and stays the vendor's internal contact after approval.