Third-Party and Vendor Risk: Assessing the Risk You Inherit

Your risk is your suppliers’ risk

The average organisation depends on dozens or hundreds of third-party services: cloud providers, SaaS applications, contractors, payment processors, marketing platforms. Each one either handles your data, connects to your systems, or both. A security programme that ignores this landscape is protecting the wrong perimeter.

Many of the largest publicised breaches in recent years have arrived through third parties rather than direct attack. The attacker compromises a smaller supplier and reaches the target through the supplier’s legitimate access.

What a working programme covers

• Inventory — who your third parties actually are, including the ones procurement did not process
• Tiering — which ones matter, ranked by the sensitivity of data they touch and the criticality of the service they provide
• Due diligence — evidence-based assessment before onboarding, scaled to the tier
• Contractual controls — security obligations, incident notification requirements, right to audit
• Continuous monitoring — posture changes over time, so the annual questionnaire is not the only signal
• Exit planning — how data is returned or destroyed when the relationship ends

Why questionnaire-driven programmes fail

Most third-party programmes send suppliers a long questionnaire once a year, receive answers, file them, and consider the work done. This produces documentation, not risk reduction. Suppliers answer to pass, not to disclose. The questionnaire is out of date the moment the supplier deploys anything new.

More effective programmes combine periodic evidence-based assessment (SOC 2 reports, ISO 27001 certificates, penetration test summaries) with continuous outside-in monitoring of supplier posture, and act on findings rather than filing them.

The concentration problem

A distinct risk that most programmes underweight is concentration: what happens when many of your critical services depend on the same underlying provider. The failure of a widely used cloud region or authentication service becomes your incident too, regardless of your direct security posture. Documenting these concentrations, and having a plan for the worst of them, is unglamorous work that pays off unpredictably.

Related in the Knowledge Base

• NIST, ISO 27001, and SOC 2: What Each Framework Is Actually For
• Supply Chain and API Security: The Risk You Inherit
• Continuous Threat Exposure Management (CTEM): Beyond Periodic Scans