Third party risk management: knowing who you depend on

Third party risk management is the practice of knowing which outside organisations your business depends on, what each of them can do to you if something goes wrong, and what you have agreed with them about it. It gets treated as a compliance exercise because that is usually when it starts — a customer sends a questionnaire, or an auditor asks for a supplier list — but the underlying question is operational and would be worth answering even if nobody ever asked.

The question is this: if any one of your suppliers disappeared tomorrow, or leaked your data, or raised their price by half, would you know within a day, and would you know what to do? For most small companies the honest answer is no, because nobody has ever written the list down.

Start with the list, not the framework

Third party risk management fails most often at the first step, because people go looking for a methodology before they have an inventory. The inventory is the hard part and the useful part. Every organisation you pay, that holds your data, or that sits inside something you sell, goes on one list.

• Software you run the business on — accounting, email, storage, payroll, the tools your team logs into daily.
• Anyone who processes personal data on your behalf, including analytics and support tools.
• Suppliers of physical goods or components, including single-source ones.
• Subcontractors and freelancers who deliver work in your name.
• Infrastructure you resell or build on, including hosting and payment processing.
• Professional services with access to sensitive material — accountants, lawyers, IT support.
• Anything a customer contract names you as responsible for.

Most companies find between two and five times more third parties than they expected, and the surprises are rarely the big contracts. They are the small monthly subscriptions somebody expensed, which quietly hold customer data and were never reviewed by anyone.

Rate them by what they could break

Once the list exists, sort it. Not by spend — by consequence. A NOK 200-a-month tool that holds your entire customer list is a bigger risk than a NOK 50,000 supplier you could replace in a week. Three tiers is enough for most companies.

1. Ask what each third party holds or does: personal data, money movement, a step in delivery, nothing much.
2. Ask what happens the day they stop: business halts, business degrades, mild inconvenience.
3. Ask how quickly you could replace them: hours, weeks, months.
4. Put them into critical, important and routine on the basis of those three answers, and write the reason in one sentence.
5. For critical ones only, collect the evidence — contract, data processing terms, security documentation, uptime commitments, exit terms.
6. Name an owner inside your company for each critical one, so somebody is responsible for noticing when things change.
7. Set a review date. Annual for critical, longer for the rest.

What supplier risk management actually asks for

Supplier risk management questionnaires vary enormously, but the substance behind them is narrow. Does the supplier know where your data is. Do they have someone accountable for security. Do they tell you when something goes wrong, and how fast. Can you get your data out. Who do they in turn depend on — because their suppliers become yours whether you agreed to that or not.

That last point is where most of the unpleasant surprises live. A supplier who is entirely reliable can still take you down because the platform they run on failed. Ask critical suppliers who their critical suppliers are, and you often find three of yours concentrate on one provider.

The concentration problem

Diversification sounds like advice for investors, but it is the single most practical output of third party risk management. When you have the list, group it by underlying provider rather than by vendor name. If your email, your file storage, your backups and your authentication all sit with one company, you do not have four suppliers. You have one, with four invoices.

That may still be the right choice — running everything in one place is cheaper and simpler, and simplicity has real value. The point is to make it a decision rather than an accident, and to know what the fallback is if that decision goes wrong.

Keeping it alive

A register reviewed once and forgotten is worse than none, because it creates confidence that is out of date. The maintenance is small if it is attached to something that already happens: a new supplier gets added when the first invoice is approved, and a departing one gets removed when access is revoked. Both of those are events somebody already handles.

Ettex Records is built for exactly this shape of thing — a structured list where each row is a supplier, with fields for tier, owner, data held, review date and links to the contract, so the register is one table rather than a spreadsheet somebody keeps a private copy of. Reviews and evidence live against the record instead of in an inbox.

What it does not do is assess anybody for you. There is no supplier scoring service behind it, no automatic feed of breach notifications, no questionnaire library that fills itself in. It holds the register and the review schedule; the judgement about whether a supplier is acceptable stays with you, and where a regulator or a customer contract sets specific requirements, those requirements govern rather than any template.

Common mistakes

• Building the framework before the inventory, so the methodology is elegant and the list is incomplete.
• Rating by contract value rather than by consequence of failure.
• Treating the questionnaire as the goal, so it is filed and never acted on.
• Ignoring fourth parties, and discovering the concentration only during an outage.
• No named owner, so nobody notices a supplier being acquired or changing terms.
• No exit plan for critical suppliers — no export, no idea what the data format is, no alternative identified.
• Reviews scheduled but not attached to a real trigger, so they slide indefinitely.

Third party risk management is not a framework problem. Write the list, sort it by what failure would cost, name an owner for the ones that matter, and check where they all quietly overlap.