ProcureWave Book a demo
VENDOR MANAGEMENT

Vendor vs Third Party: The Complete Guide

Untangling two terms that get used interchangeably, and why the distinction decides whether your third-party inventory is complete.

Vendor vs Third Party: The Complete Guide
Photo by Tobias Dziuba on Pexels

"Vendor" and "third party" get used as if they were the same word, and in casual conversation nobody minds. In risk, audit and procurement work the difference is material. One describes a commercial buying relationship; the other describes every external organisation your business is entangled with, paid or not. This guide untangles the two terms, maps the relationship types that sit between them, and shows why a supplier list is rarely a complete third-party inventory.

Key takeaways

  • Every vendor is a third party, but not every third party is a vendor.
  • Risk follows access to data, premises, customers and money, not the direction of payment.
  • A supplier list built from your finance system will systematically miss unpaid relationships.
  • Tier the whole third-party population by inherent risk, then size diligence to the tier.

What a vendor actually is

A vendor is an organisation that sells you something. There is an offer, an acceptance, a price and usually a purchase order or contract behind it. The relationship is commercial and directional: value flows to you, money flows to them. That is the whole of it, and it is why vendor records live comfortably alongside procurement data such as spend, catalogues, invoices and payment terms.

The word carries some regional flavour. In North American usage vendor covers services and software as readily as goods; in parts of Europe and the Commonwealth "supplier" does more of that work, and vendor sometimes implies a smaller or transactional seller. Our guide to the meaning of vendor unpacks those shades, and the vendor versus supplier comparison covers where the two labels genuinely diverge. For this article, treat vendor as shorthand for "an external organisation we buy from".

The important property of a vendor, for our purposes, is that it is always discoverable. If you pay someone, they exist in your accounts payable ledger. That makes vendors the easiest third parties to inventory and, not coincidentally, the ones most organisations assess first.

What a third party actually is

A third party is any external organisation that acts with you, for you, or on your behalf. The framing comes from contract language, where the first party and second party are the two signatories and everyone else is a third party. In practice the term has come to mean the whole population of external relationships that can affect your operations, your data, your customers or your reputation.

That population is far wider than your buying activity. It includes organisations you sell through, organisations that introduce customers to you, organisations you share infrastructure or data with, organisations you have invested in jointly, and organisations that receive nothing from you at all but still hold something of yours. A charity partner running an event under your logo is a third party. So is a research body you have shared an anonymised dataset with, a landlord's facilities contractor with a swipe card to your floor, and a broker who quotes on your behalf.

The practical test is not "do we pay them?" It is closer to: does this organisation have access to our data, our premises, our systems, our customers or our money, or can it act in a way that a customer or regulator would attribute to us? If the answer to any of those is yes, it belongs in the inventory whatever the commercial arrangement looks like.

The relationship types, compared

Most confusion clears once you lay the common relationship types side by side. The table below shows whether each type is normally a vendor, whether money typically flows, and what makes it risky.

Relationship type Vendor? Money flow Typical risk exposure
Supplier or vendor Yes You pay them Delivery failure, quality, data access, solvency
Outsourced service provider Yes You pay them Operates a whole process; deep data and system access
Agent acting in your name Sometimes Commission, or none Conduct, mis-selling, bribery, statements attributed to you
Reseller or distributor No They pay you Customer data, brand conduct, pricing and channel behaviour
Franchisee No They pay you Brand, service quality, employment and safety practices
Introducer or broker Sometimes Commission Customer data, disclosure quality, incentive conflicts
Joint venture or alliance No Shared Shared liability, governance, co-mingled data and staff
Data-sharing partner Often not Often none Data protection, onward transfer, purpose creep
Fourth party or sub-processor No direct contract Paid by your vendor Concentration, hidden dependency, breach reaching you indirectly

Read down the "vendor?" column and the point makes itself. Four of the nine rows are not vendors at all, and two of them, franchisees and resellers, actually pay you. If your assurance programme starts from spend, those rows are invisible.

Why the distinction matters for risk

Third-party risk management exists because outsourcing an activity never outsources accountability for it. That principle, familiar from risk management generally, applies to every external relationship rather than only the purchased ones. Supervisors and auditors have converged on broadly the same expectation: know who you rely on, understand what could go wrong, and be able to evidence proportionate oversight. Nothing in that expectation limits itself to entities you send money to.

The gap shows up in predictable places. An organisation with a mature vendor programme is often surprised to find that its most sensitive customer data sits with a partner it never paid, or that a franchised outlet handles complaints under its brand with no service standard behind it, or that an unpaid pilot integration has held API credentials for eighteen months. None of those are vendor failures. All of them would be reported as yours.

The payment-flow blind spot. Programmes built from the accounts payable ledger inherit its logic: no payment, no record. That quietly excludes resellers, franchisees, joint ventures, data-sharing partners, unpaid pilots and anyone your vendors subcontract to. Before assuming coverage is complete, ask which relationships would never appear in finance data at all, then go and find them.

Building a complete third-party inventory

A supplier list answers "who do we pay?" An inventory answers "who are we exposed to?" Building the second from the first takes a deliberate sweep, because the missing entries live in departments rather than in systems.

  • Start with the ledger, then treat it as incomplete. Accounts payable gives you the paid population quickly. Mark it as your baseline, not your answer.
  • Sweep the contract repository. Signed agreements with no associated spend are the clearest signal of a non-vendor third party: partnership terms, data-sharing agreements, referral arrangements, memoranda of understanding.
  • Ask the access questions. Pull lists of active system accounts held by external email domains, building passes issued to non-employees, and integrations with live API credentials. Reconcile each one to a named organisation and owner.
  • Interview the revenue side. Sales, channel and partnerships teams hold the relationships that pay you rather than the reverse. They rarely think of these as third parties until asked directly.
  • Capture the unpaid and the informal. Pilots, trials, secondments, community partners, industry bodies and shared-service arrangements all belong in scope if they touch data, premises or customers.
  • Record ownership at entry. Every entry needs a named internal owner from day one, otherwise the inventory becomes a list nobody maintains.

Hold the result in one place rather than in a spreadsheet per department. Platforms such as ProcureWave keep organisation records, documents, owners and approval history together, so a non-paying partner can be governed with the same rigour as a paid supplier without inventing a parallel process for it.

Tiering by inherent risk, not by spend

Once the inventory is honest, it will be larger than expected, and you cannot assess everything to the same depth. Tiering solves that, but only if the criteria are about consequence rather than commerce. Spend is a poor proxy in a mixed population and a meaningless one for third parties you do not pay at all.

Data sensitivity
What categories of data does the relationship touch, in what volume, and can it be transferred onward?
Process criticality
Would a core process stop, degrade or become manual if this organisation disappeared tomorrow?
Access footprint
Systems, credentials, premises, cash handling and the ability to make commitments on your behalf.
Attribution
Would a customer or regulator see this organisation's conduct as your conduct? Agents, franchisees and resellers score high here.
Substitutability
How long, and at what cost, would a realistic replacement take? Long answers indicate concentration risk.

Score inherent risk first, before controls, so the tier reflects what the relationship could cause rather than what you hope is already mitigating it. Then size diligence to the tier: deep evidence-backed assessment and continuous monitoring at the top, a short screening set at the bottom, and a documented reason recorded either way. A tier decision you can explain is worth more than a questionnaire nobody read.

Fourth parties and sub-processors

Your third parties have third parties. The software vendor runs on someone else's cloud, the logistics provider subcontracts the final leg, the analytics tool passes data to a sub-processor in another jurisdiction. You have no contract with any of them, yet their outage or breach lands on your customers exactly as if it were yours. This is where third-party risk merges into supply chain risk management more broadly.

You cannot assess a fourth party directly, so the controls are contractual and informational. Require disclosure of material subcontractors and sub-processors. Require notice, or approval, before they change. Require the same obligations to flow down. Then use the disclosures to look for concentration: it is common to discover that six independent-looking vendors all rest on the same hosting region or the same payment processor, which turns a diversified-looking portfolio into a single point of failure.

For the top tier, ask the resilience question directly. What is your vendor's plan if their critical subcontractor fails, and have they tested it? A vendor who cannot answer has not thought about their own dependencies, which tells you something useful about how they will handle yours.

Who owns third-party governance

This is where the vendor and third-party distinction becomes an organisational problem rather than a semantic one. Vendors have an obvious home in procurement. Partners sit with the commercial team, franchisees with operations, data-sharing arrangements with legal or privacy, joint ventures with the executive. Left alone, each group governs to a different standard and the aggregate picture belongs to nobody.

The workable pattern separates three things. The business owner who introduced the relationship owns the risk, because they own the outcome it supports. A single function, usually procurement or a third-party risk team, owns the process, the inventory and the tiering framework, and applies them consistently whichever department the relationship came from. Specialist functions assess their own domains, and an accountable executive owns the portfolio view, including concentration and fourth-party overlap that no individual owner can see. The deeper mechanics of assessment cadence, evidence and monitoring are covered in our vendor risk management guide.

A pragmatic starting point: take your existing supplier list, run the access sweep for a fortnight, and see how many organisations you find that were never in it. That number is usually persuasive enough to fund the rest of the work. If you would like to see how one record can hold paid and unpaid third parties, their owners, documents and review dates in the same place, talk to the ProcureWave team and we will walk through it against your own relationship types.

Frequently asked questions

What is the difference between a vendor and a third party?

A vendor is an organisation you buy goods or services from under a commercial agreement. A third party is any external organisation your business deals with, whether money changes hands or not. Every vendor is a third party, but many third parties, such as agents, resellers, franchisees, regulators and community partners, are not vendors.

Is every third party a vendor?

No. Third parties include partners you share revenue with, intermediaries who introduce customers, joint ventures, franchisees, outsourced agents acting in your name, and unpaid relationships such as data-sharing partners or volunteer bodies. None of these appear on a purchase order, yet several may have deeper access to your data or customers than an ordinary supplier does.

Why does the vendor versus third party distinction matter for risk?

Because risk follows access, not payment. If your inventory is only a supplier list, you will assess the people you pay and miss the people who hold your data, enter your premises or speak to your customers. Auditors and regulators look at the whole third-party population, so a payment-derived list leaves visible gaps.

What is a fourth party?

A fourth party is your third party's third party: the cloud host behind your software vendor, the courier behind your distributor, the sub-processor behind your analytics tool. You have no contract with them, but their failure reaches you all the same, which is why subcontracting disclosure and flow-down obligations matter.

Who should own third-party governance?

The business owner who introduced the relationship owns the risk. Procurement usually owns the process, the record and the tiering framework, which is covered in more depth in our vendor risk management guide. Specialist functions assess their own domains and an executive owner holds the aggregate picture.

Want to see this in your own numbers?

Book a tailored demo and we will show ProcureWave running on scenarios that match your business.

Get in touch