Third-Party Vendor Risk: A Practical Framework

Most organisations have a vendor risk problem. Many do not know how large it is.

Third-party vendor risk sits at the intersection of IT, security, legal, and operations. It gets reviewed during procurement, sometimes assessed annually, and then largely left alone until something breaks. By then, the risk has usually been live for much longer than anyone realised.

I have managed vendor portfolios across several organisations at different stages of IT maturity. The pattern is consistent. Initial procurement includes some form of due diligence. After onboarding, the relationship drops into BAU. Vendor access, integrations, and data sharing evolve over time in ways that nobody quite tracks. When an incident eventually occurs — a supplier breach, a contractual failure, a sudden end-of-life announcement — the response often reveals how little ongoing governance was actually in place.

Third-party vendor risk management is not primarily a procurement activity. It is an ongoing operational discipline.

Where the Risk Actually Sits

There are three categories of third-party vendor risk that matter most in practice.

Data exposure risk is the most commonly discussed. If a vendor processes, stores, or has access to your data — customer records, employee information, financial data, intellectual property — a failure in their security controls creates a failure in yours. Under GDPR, your organisation retains responsibility for personal data even when it is processed by a third party. A supplier breach is not their problem alone.

Operational dependency risk is less visible but often more disruptive when it materialises. If a SaaS platform goes down, a managed service partner loses a key engineer, or a software vendor announces end-of-life on a product you depend on, the business impact can be significant regardless of any security failure. Single points of failure created through deep vendor dependency are a legitimate risk category, not just a procurement concern.

Supply chain risk is the category that has moved up every IT leader's agenda since the SolarWinds incident and similar attacks in subsequent years. Your vendor's software and systems are part of your attack surface. Their developers, their infrastructure, and their upstream suppliers are all potential entry points. If a threat actor compromises a trusted vendor's update mechanism, that compromise propagates into your environment through a channel you have explicitly trusted.

A Practical Risk Register Approach

The most useful structural change most organisations can make is to bring vendor risk into a managed risk register rather than leaving it in procurement records.

A vendor risk register does not need to be complicated. The essentials are:

• a list of all material vendors, including SaaS tools that may have been adopted informally
• classification of each vendor by risk tier based on data access, operational criticality, and integration depth
• the key controls in place for each vendor: contractual protections, security certifications, access review cadence
• the date of the last formal review and when the next is due
• any open issues or flag items from the most recent review

The risk tier classification is worth spending time on. A tier-one vendor — one with access to sensitive personal data, deep system integration, or critical operational role — deserves regular scrutiny. A tier-three vendor with no data access and no critical operational role does not require the same frequency of review. Building a tiered model lets you allocate attention appropriately rather than treating every supplier identically.

Moving From Point-in-Time to Continuous

Traditional vendor risk management is built around point-in-time assessments. You review a vendor's security questionnaire at onboarding, perhaps annually thereafter, and treat that as your assurance.

The limitation is obvious in hindsight. A questionnaire answered honestly at the time of completion may not reflect what is true twelve months later. Vendors get acquired. Their security programmes change. Staff turn over. Certifications lapse.

There are two practical ways to improve this without significantly expanding your programme.

Passive monitoring means subscribing to sources that will alert you when something changes. Threat intelligence feeds, CVE notifications for software your vendors maintain, news monitoring, and breach notification services all contribute. If a vendor has a material security incident, you should know about it before they tell you, or at least at the same time.

Contractual obligations mean building change notification requirements into your vendor agreements. Key changes — ownership, subprocessors, security posture, key personnel in security roles — should trigger a notification to your team. Many vendors will accept this if asked. Most standard contracts do not include it unless you put it there.

The Contractual Controls That Actually Protect You

Vendor contracts often receive intensive scrutiny during commercial negotiation and much less scrutiny on the security and risk terms. This is a mistake.

The terms worth ensuring are present:

Data processing agreements are legally required for any vendor processing personal data under GDPR. They should specify exactly what data is processed, for what purpose, under what legal basis, and with what security obligations. If you are using a vendor that handles personal data without a signed DPA, that is an immediate compliance gap.

Audit rights give you the ability to verify a vendor's security claims. In practice, most organisations do not exercise these rights frequently. What matters is that they exist and are enforceable. A vendor that resists standard audit rights provisions is a vendor worth scrutinising more carefully.

Incident notification timelines should specify how quickly a vendor must notify you of a breach or incident that may affect your data or operations. The GDPR standard for reporting to the ICO is 72 hours. Your vendor notification obligation should be faster than that. Twenty-four hours is a reasonable contractual requirement.

Exit provisions are frequently neglected. When a vendor relationship ends — whether through natural conclusion, poor performance, or a supplier failure — you need to be able to retrieve your data, revoke access, and transition to an alternative without being held hostage by a poor exit clause. Negotiate exit terms at the start of a relationship when your leverage is highest.

What the Review Cadence Should Look Like

For most organisations, a practical review cadence looks something like this.

Tier-one vendors: formal annual review including questionnaire, certificate review, and a conversation with a counterpart in their security team. Review triggered immediately by any material change or incident.

Tier-two vendors: annual questionnaire-based review with passive monitoring in between. Triggered review on any significant incident.

Tier-three vendors: annual confirmation that scope and access have not changed. No formal assessment unless scope escalates to tier two.

The annual review cycle is not the end of the programme. It is the minimum. The passive monitoring layer, the contractual obligations, and the internal change management process that catches when a new team has started using a vendor outside the procurement process — these are what make vendor risk management a live discipline rather than a periodic exercise.

The Dependency Map You Probably Do Not Have

One of the most useful things an IT leader can do is build a current, accurate map of which vendors have which access to which systems and data.

Most organisations have a partial version of this. Procurement has contracts. IT has access credentials. Security has some integrations logged. Finance has payment records. Nobody has a single view.

A dependency map does not need to be a sophisticated tool. A spreadsheet with vendors, the systems they integrate with, the type of access they hold, and the data categories they can reach is more valuable than no map at all. When an incident occurs — a breach notification, a sudden service failure, a vendor acquisition — having that map means you can respond in minutes rather than hours.

Build it once. Keep it current as part of your onboarding and offboarding processes. Review it annually alongside your vendor register.

The Honest Assessment

Third-party vendor risk is uncomfortable to manage well because it requires disciplined attention to relationships that most organisations prefer to treat as solved problems once onboarding is complete.

The risk does not work that way. Vendors change. Integrations deepen. Data sharing expands. The threat landscape around supplier ecosystems has become considerably more hostile than it was five years ago.

The organisations that manage this well are not necessarily the ones with the biggest security teams or the most sophisticated tooling. They are the ones that have built a repeatable discipline: classify your vendors, review them regularly, monitor for change, and maintain the contractual protections that give you recourse when things go wrong.

That is achievable for most IT functions. What it requires is treating third-party vendor risk as an ongoing programme rather than a procurement checklist.