Vendor onboarding process flowchart

How it works

1. Match the swimlanes to your organisation

   Rename the five lanes to the functions that actually exist in your company. Smaller teams often merge Legal into Procurement, or run Security & compliance as a part-time role held by IT. Delete a lane rather than leaving it empty, and make sure every box sits in the lane that genuinely owns the work rather than the one that gets blamed for it.

2. Write down your risk tiering criteria

   Replace 'High risk tier?' with the test your company actually applies. Most organisations tier on whether the vendor processes personal or regulated data, annual spend, whether they get access to internal systems or premises, and how disruptive it would be to lose them. Record the thresholds next to the node so the decision is repeatable by whoever is on duty.

3. Define what enhanced due diligence requires

   Fill in what the high risk branch demands in practice: a SOC 2 report or penetration test summary, a subprocessor list, beneficial ownership and sanctions screening, references, or a site visit. If the branch does not name specific evidence, it will be skipped under time pressure.

4. Assign the bank verification control to a named role

   Decide who performs the callback and confirm it is not the same person who creates or edits the vendor master data record. Separating those two duties is the whole point of the control. Add the source of the phone number, which should be the signed contract or an independently obtained number, never the invoice or the email requesting the change.

5. Add your systems, owners and service levels

   Put real system names on the steps: where the request form lives, which ERP holds vendor master data, where the approved vendor register sits. Add the role that owns each box and a target turnaround for each lane so the process can be measured rather than only described.

6. Set the review cadence, then circulate for sign-off

   Choose reassessment intervals per risk tier and record the date on the register itself rather than in a personal calendar. Share the chart with procurement, legal, finance and security for comment, and keep it under version control so the approved diagram and the written procedure do not drift apart.

Frequently asked questions

How long should vendor onboarding take?

For a low risk vendor on standard terms, three to five working days is realistic once the due diligence pack is complete. High risk vendors typically take two to six weeks, because enhanced review, negotiated contract terms and security evidence all sit on the critical path and often run into the vendor's own approval cycles. The single biggest delay is usually waiting on documents from the vendor, which is why the request form and the due diligence pack come first in this flowchart, before any review work begins. If your median time is much longer than this, measure how long each lane holds the file rather than the process end to end.

What is vendor risk tiering, and how many tiers do we need?

Risk tiering classifies a vendor so the depth of review matches the exposure. Three tiers, high, medium and low, is enough for most companies; more than that tends to produce arguments about placement rather than better decisions. Common inputs are whether the vendor processes personal or regulated data, annual spend, whether they receive access to internal systems or premises, and how disruptive it would be to lose them at short notice. The tier should drive two separate things: what evidence you require before approval, and how often the vendor is reassessed afterwards.

Why is bank detail verification shown as its own step and decision?

Invoice redirection fraud works by sending a plausible request to change a supplier's bank account, usually from a spoofed lookalike domain or a genuinely compromised mailbox. The defence is procedural rather than technical: verify the account by calling the vendor on a number taken from the signed contract or independently sourced, never one supplied in the email or printed on the invoice, and record who verified it and when. Giving it a decision node with a re-verify loop makes it explicit that payment setup does not proceed on an unverified account, and the same check should apply to any change of bank details after onboarding.

Where should the approved vendor register live?

Wherever it lives, it needs a single owner and a review date against each vendor. A spreadsheet is workable at small scale provided changes are dated and attributable; dedicated procurement or third-party risk tooling handles it better once you pass a few hundred vendors. The failure mode is identical either way: vendors get added and never removed, so the register gradually stops reflecting who you actually buy from. Reassessing on the cadence set by the risk tier, and closing out vendors you no longer use, is what keeps it accurate.