Vendor risk management (third-party risk)

A company can spend heavily on its own defenses, but if a vendor holds its data or touches its systems, that vendor's weakness becomes the company's weakness. Vendor risk management, also called third-party risk management, is the discipline of finding, assessing, and controlling the risk that enters through every external party with access. That includes cloud platforms, software providers, outsourced IT, payment processors, managed service firms, and even an accountant or a marketing tool with a login. Each connection is a door, and you do not control how well the other side locks it.

For a regulated company this is no longer a nice-to-have. A breach at a supplier that processes your customer data is, in legal and practical terms, your breach. You still have to notify regulators, you still have to answer to customers, and you still carry the reputational damage. The supply chain has become a primary attack route precisely because it is the soft underbelly: attackers no longer need to beat your firewall when they can compromise a smaller, less-defended partner and ride the trust relationship straight into your environment. Managing that risk systematically is what this guide covers.

This guide is part of our security program work. We deliver vendor risk management through governance, risk, and compliance, and it sits alongside the broader discipline of risk management.

Why the supply chain is now a primary attack vector

A modern company depends on dozens of external services, and most of them carry some level of access. That access is the prize. Attackers have worked out that breaking into one well-resourced provider can give them a path into hundreds of its customers at once, so a single compromise scales. This is the logic behind the most damaging supply-chain incidents of recent years: poisoned software updates, compromised managed service providers, and credentials stolen from a contractor who had a standing connection into the target.

The European Union Agency for Cybersecurity has tracked supply-chain compromise as one of the most significant and fastest-growing threats to organizations.¹ The reason is structural, not accidental. Trust between a company and its vendors is usually implicit: the vendor was approved once, given access, and then largely forgotten. Attackers exploit exactly that gap between the initial approval and the absence of any ongoing scrutiny. The weakest partner with a live connection sets your real security level, regardless of how much you spent on your own perimeter.

Your security is only as strong as the weakest partner with a live connection to your systems.

The types of third-party risk

Vendor risk is not a single thing. A useful program separates it into categories, because each one needs a different control and a different owner. Lumping them together is how a security review misses the financial exposure and a procurement review misses the cyber exposure.

• Cybersecurity risk: the vendor is breached and your data or systems are exposed through the connection you gave them.
• Operational and concentration risk: the vendor goes down or fails, and a service you depend on stops with it.
• Compliance and legal risk: the vendor mishandles personal data or fails a control, and the regulator holds you accountable under GDPR, NIS2, or DORA.
• Financial and viability risk: the vendor becomes insolvent or is acquired, and continuity of the service is no longer assured.
• Reputational risk: the vendor's conduct or a public incident at the vendor damages your brand by association.
• Fourth-party risk: the vendor's own subcontractors inherit access, so the chain extends beyond the party you actually signed with.

The vendor risk management lifecycle

Vendor risk is best run as a lifecycle, not a one-time gate. Each stage has a clear purpose, and skipping any one of them leaves a predictable hole. The steps below describe the full arc from before you sign to after you part ways.

1. 01
   Pre-contract assessment

   Before any access is granted, classify the vendor by how much damage their failure would cause, then assess their security in proportion to that. A provider touching personal data or critical systems gets deep scrutiny; a low-access tool gets a light review.
2. 02
   Due diligence

   Gather evidence, not promises. Review security questionnaires, certifications, audit reports, and policies, and check that what they claim matches what they can show.
3. 03
   Contractual security clauses

   Write the security expectations into the contract: control obligations, breach-notification timelines, data-handling terms, subcontractor limits, and a right to audit. A clause agreed before a problem is leverage; one negotiated after is too late.
4. 04
   Continuous monitoring

   Track the vendor through the relationship. Reassess on a schedule set by criticality, watch for changes in ownership or certification status, and require notice of material changes.
5. 05
   Exit strategy

   Plan the offboarding before you need it: how data is returned or destroyed, how access is revoked, and how the service is migrated, so a termination does not become an outage or a data-leak event.

How to evaluate a vendor

Evaluation is where most programs are weakest, because it is tempting to accept a vendor's word. A serious assessment asks for evidence and weights it by how much independent assurance it carries. A self-completed questionnaire is the starting point, not the proof. Independent attestations such as ISO/IEC 27001 certification or a SOC 2 report carry far more weight because a third party has examined the controls.²

The table below shows the common evaluation methods, what each one actually proves, and when to use it. Match the method to the vendor's criticality: the higher the access and the more sensitive the data, the more independent assurance you should demand.

Treat certifications as a floor, not a finish line. Confirm the scope of any certificate or report actually covers the service you are buying, and check the dates: a SOC 2 Type II covering a period that ended two years ago tells you little about today. For the highest-criticality vendors, an attestation is not a substitute for your own risk assessment and, where warranted, independent testing of the service.

Concentration risk

Assessing each vendor in isolation misses a risk that only appears at the portfolio level. Concentration risk is the exposure that builds up when many critical functions depend on a single provider, or on a single underlying platform. If most of your stack runs on one cloud region, or several of your suppliers all rely on the same upstream provider, then one outage or one breach can cascade across functions you assumed were independent.

This is why regulators in finance pay close attention to it. A single dominant ICT provider can become a systemic point of failure. Mapping concentration means looking past your direct contracts to the fourth parties beneath them, and asking what happens if one widely shared dependency fails. The mitigation is rarely to avoid the provider; it is to know the exposure, demand stronger continuity terms, and have a tested fallback for the functions that cannot tolerate downtime.

What NIS2 and DORA require

Supply-chain risk management is now an explicit legal obligation, not a best practice. The NIS2 Directive requires essential and important entities to address security in their supply chains, including the security of relationships with each direct supplier and the secure development practices of those suppliers, as part of their risk-management measures.³ In other words, the regulation expects you to assess and manage your vendors, and to be able to show it. We cover the wider obligations in our NIS2 guide and on the NIS2 compliance page.

DORA goes further for the financial sector. The Digital Operational Resilience Act imposes detailed, prescriptive obligations on the management of ICT third-party risk: a register of all ICT third-party arrangements, mandatory contractual terms for critical providers, concentration-risk analysis, and exit strategies for critical functions.⁴ DORA even creates direct oversight of the most critical ICT providers at EU level. If you are in scope, vendor risk management is no longer something you design freely; the regulation tells you what the contracts and monitoring must contain. Our DORA compliance checklist and the DORA compliance page break down the specifics.

The most common mistake

The failure we see most often is the one-time check at onboarding with no monitoring afterward. A vendor is assessed once, ticks the boxes, gets access, and is never reviewed again. Six months later their certificate has lapsed, they have been acquired by a less mature firm, they have added a risky subcontractor, or they have simply drifted. The risk you signed off on is not the risk you are carrying now.

Two practices close most of this gap. Schedule reassessments by criticality so the highest-risk vendors are reviewed most often, and put a notification obligation in the contract so the vendor must tell you about material changes and incidents. A program without ongoing monitoring is not a program; it is a snapshot that goes stale the moment it is filed.

How Raptoric helps

We help you build a vendor risk program that holds up to both attackers and auditors: a clear vendor inventory ranked by criticality, evidence-based assessments, security and notification clauses in your contracts, concentration-risk mapping, and continuous monitoring tied to NIS2 and DORA obligations. We deliver this through governance, risk, and compliance. Book a scoping call.