Third-party risk management (TPRM): a guide

You can have exemplary MFA, patched systems and a rehearsed response plan — and still make the headlines because your IT provider kept customer passwords in a spreadsheet and their remote-support tool had access to your network. The high-profile incidents of recent years (from MOVEit to attacks on helpdesk providers) share one denominator: the attacker chose the route through a supplier, because it was easier. Third-party risk management (TPRM) has stopped being an enterprise-only discipline; it’s required by NIS2, DORA and — increasingly — by your own customers.

Where supplier risk comes from

Three typical channels through which a supplier’s problem becomes yours:

Access to your systems. A technician with a VPN account, an agency with CMS access, an accounting firm with bank access, an IT provider with domain admin. Their account taken over = entry into you — often outside your monitoring.
Your data at the supplier. A SaaS holding your customer base, a cloud with your backups, a courier with an address list, a payment processor. A leak at their end is your regulatory notification and your customers’ lost trust.
Operational dependency. An outage or ransomware at a key supplier (ERP, logistics, hosting) stops your business even though nobody attacked you. That’s a continuity risk, not just confidentiality.

A separate category is the software supply chain — dependencies and updates you let into your environment automatically.

Step 1: inventory and tiering

You can’t manage a list you don’t have. Collect suppliers from contracts, invoices and… the departments (shadow IT has a supplier dimension too — we’ve written about it). Then tier them — a simple model that works:

Tier 1 (critical): they have administrative access to your systems, process sensitive data or large volumes of personal data, or their failure stops your business within a day.
Tier 2 (significant): limited access or significant data; an outage hurts within weeks.
Tier 3 (the rest): no access to systems or data, easily replaceable.

Apply the full TPRM rigour to Tier 1, a simplified version to Tier 2, and handle Tier 3 with contract clauses and nothing more. Without tiering, the programme dies under its own weight.

Step 2: pre-contract due diligence

For Tiers 1–2, before signing, collect answers to a dozen concrete questions rather than a 300-item questionnaire nobody reads:

Does the supplier enforce MFA (including on access to your environment)? How do they manage staff accounts after departures?
When was their last penetration test or audit? Will they share a report summary?
What does their incident process look like, and within what time will they commit to informing you?
Where is the data physically, who can access it, will they sign a data processing agreement (GDPR)?
Certifications (ISO 27001, SOC 2) — treat as a maturity signal, not a guarantee; check the certification scope.
What does their continuity look like: backups, RTO, and what happens to your data when the contract ends?

For truly critical suppliers go further: an external attack surface assessment (what’s visible from the internet), a review of the access they hold into you, or a joint incident exercise.

Step 3: a contract with teeth

Questionnaires go stale — the contract remains. The minimum set of security clauses:

Incident notification: a definition of an incident, a notification deadline (specific hours, not “promptly”), the information scope, an emergency contact.
Audit rights (or substitute audit via independent reports) — with a workable execution procedure.
Minimum standards: MFA, encryption, patching, access control to your environment (named accounts, least privilege, session logging).
Subcontractors: consent or at least notification about the further chain.
Exit: data return/deletion with confirmation, migration support, export format.
Liability and insurance — the supplier’s liability cap must not be lower than the realistic impact of an incident on you.

Step 4: access control — where you win the most

The most effective supplier risk reduction needs neither questionnaires nor lawyers — just treat their access like your own privileged accounts:

named accounts for the supplier’s people (never a shared “service” login), disabled when the work ends,
mandatory MFA, access only in agreed time windows or activated on request,
minimal scope: access to the specific system, not the network; segmentation instead of a flat network (Zero Trust thinking),
session recording/logging for remote access and alerts on out-of-pattern logins — wired into your monitoring,
a quarterly review of supplier access: who still has an account, and why?

In tests we regularly find supplier accounts from years ago — active, weakly protected, fully privileged. It’s the lowest-hanging fruit in all of TPRM.

Step 5: monitoring instead of an annual questionnaire

Supplier risk changes between reviews. Sensible, cheap monitoring: alerts for incident news about key suppliers, watching their status pages, a periodic external scan of their attack surface (with consent, or via a rating service), and — most importantly — an internal duty to report changes: a new supplier, a new data scope, a new access = a review before it goes live.

Frequently asked questions (FAQ)

Where do we start with 200 suppliers and no process? With tiering: pick the 10–15 Tier 1 suppliers (admin access / data / operational criticality) and spend the first quarter only on them: an access review, clauses at the next contract amendment, incident contacts established. Breadth comes later; depth on the critical ones delivers 80% of the effect.

A supplier won’t fill in our questionnaire or show a test report. What now? Negotiate alternatives: a report summary under NDA, a certificate with its scope, a technical call with their security team. If a critical supplier refuses everything — that is the risk assessment result. You can compensate (restricted access, extra monitoring) or seek an alternative; document the decision.

Do NIS2/DORA make us audit every supplier? No — they require managing supply chain risk proportionately: identify dependencies, assess the critical ones, have contract clauses and oversight. The regulator will ask about your process and evidence it works, not about auditing your paper supplier.

How can we vet a supplier “from outside” before signing? A passive attack-surface assessment says a surprising amount: exposed panels and services, patching hygiene, domain and email hygiene (SPF/DMARC), leaked employee credentials. We run such assessments as part of our audit services — often hours of work that save months of trouble.

We’re a supplier and clients bury us in questionnaires. How do we cope? Build a due diligence pack once and refresh it every six months: a security architecture description, policies, a summary of your latest penetration test, certificates, a DPA template. Answering “from the pack” shortens B2B sales by weeks — and a regular pentest with a client-ready report is often the best commercial investment you can make.

Summary

TPRM is not about collecting questionnaires but about four things done consistently: you know who your critical suppliers are; their access into you is tight and monitored; contracts give you incident notification and an exit path; and changes get reviewed before they become facts. If you’d like to review supplier access in your network, or prepare for your own customers’ security questions — get in touch.