Ernest Hemingway said, “the way to make people trustworthy, is to trust them”, but in the case of critical vendors our businesses rely on, can we really afford to apply that adage?
Cyber risk no longer stops at the traditional boundary of the corporate network. Granting a vendor excessive trust at onboarding, without proper assessment or scoping, is like boring a hole beneath the waterline of your business and hoping it won’t flood one day.
The catch is that a critical vendor often sits inside what we used to think of as the effective security boundary. If that vendor has privileged access, handles sensitive data, operates a mission-critical service, connects through APIs or OAuth, or can influence customer-facing systems, then its weaknesses can become your weaknesses that in time may impact your Important or Essential Service (emphasis added, remembering the NIS2 Directive is coming).
Critical business services today increasingly depend on cloud providers, software vendors, managed service providers, payroll platforms, CRM systems, consultants, payment providers and hundreds of other third parties. Many of these suppliers may hold company secrets, connect directly to corporate systems, or operate services your organisation depends on.
That dependency creates a simple problem and the only way out of is through it. A company can have strong internal cybersecurity controls and still suffer a major incident because one of its suppliers is compromised.
Lessons from recent supply-chain incidents
The Salesloft Drift incident in August 2025 showed a different type of supplier risk. Attackers obtained OAuth tokens associated with Drift integrations and used them to access customer environments, including Salesforce instances, for what Google Threat Intelligence later described “large-scale data exfiltration”.
This illustrates an increasingly important risk: a supplier does not necessarily need your administrator password to expose your organisation. A trusted integration, API token or OAuth connection may already provide a pathway.
A more recent example from June 2026 involved market-intelligence provider Klue, where an incident resulted in attackers obtaining OAuth tokens and subsequently accessing LastPass customer related information in Salesforce.
These incidents demonstrate three different dimensions of supplier risk:
- A supplier outage can disrupt your operations
- A compromised third-party vendor can turn legitimate OAuth integrations into a pathway for downstream customer data breaches
- One compromised provider can simultaneously affect many customers.
Vendor risk management, therefore, can’t only consist of asking a supplier to complete a security questionnaire before signing a contract. We have to look deeper.
Firstly, sort your vendors by criticality. Not every third party carries equal risk if they are compromised. Concentrate onboarding enquiry on the integrations that touch sensitive data and core operations.
Understand what the supplier can actually affect
The first stage of an effective vendor risk assessment is not asking whether the supplier has ISO 27001 certification. Before assessing the vendor, determine exactly what would happen to your organisation if that vendor were compromised, unavailable or malicious.
What information does the supplier hold?
Determine whether the supplier processes personal data, commercially sensitive information, intellectual property, credentials, security data or regulated information.
What systems can the supplier access?
Identify APIs, VPN connections, administrative accounts, remote-management tools, OAuth permissions, service accounts and other integrations.
What happens if the service disappears?
Consider the operational consequences if the supplier becomes unavailable for a day, a week, or longer.
Can the supplier affect customers?
A supplier supporting a customer-facing product may create substantially greater risk than one providing a standalone internal administrative service.
Who does the supplier rely upon?
Your supplier may themselves depend upon cloud providers, software platforms, hosting companies and subcontractors. This is sometimes known as fourth-party risk. In practice, it means your business may depend on companies it has no direct contractual relationship with.
Once you understand those dependencies, you should rank suppliers by risk. A simple approach is to classify them as critical, high, medium or low based on the data they hold, access they possess, operational dependency, and potential impact of failure.
This stops you from spending the same amount of effort assessing the office stationery supplier as the cloud hosting provider.
What should a vendor security assessment examine?
Governance and security management
Determine whether responsibility for cybersecurity is clearly assigned within the supplier organisation. Look for evidence of an established security management programme, risk assessments, policies, security governance and independent assurance. ISO 27001, SOC 2 or other certifications can be useful evidence and worthy of review time, but you should treat certification as one source of assurance rather than proof that the supplier presents no risk. The scope of the certification is particularly important; specifically, whether the scope covers the service being supplied to your business.
Access and identity management
Understand how the supplier protects privileged accounts and access to customer environments. Look for multi-factor authentication, least privilege, privileged access management, periodic access reviews and controls around service accounts usage. Keep an inventory of third-party connections and periodically review whether each integration still requires the permissions originally granted.
Vulnerability and patch management
Remember that an attacker will ‘walk in the front door’ if possible. Ask the supplier how it discovers, prioritises and remediates vulnerabilities.
- How often does it perform vulnerability scanning?
- Do internet-facing systems receive additional monitoring?
- What are the expected remediation times for critical vulnerabilities?
- What goes into the company’s programme of security assurance testing?
Incident management
The first time you discuss incident communications with a critical supplier should not be during a cyber attack. Establish contact with them long beforehand and know who will pick up the phone or answer an email to you in the event of an incident. If you are covered by NIS2, this is of vital importance. Use this first contact to understand:
- What constitutes a reportable incident?
- When does the supplier’s incident response procedure stipulate that it needs to notify customers?
- Who communicates during an incident?
- What information will it provide?
- How will it keep customers updated?
Resilience and recovery
Cybersecurity vendor assessment should also examine availability. Ask whether the supplier maintains tested backups, and what are its disaster recovery arrangements, redundant infrastructure and documented recovery objectives. Most importantly, understand your own contingency plan.
Supply-chain controls
Ask the supplier how it manages its own critical suppliers. You could carefully assess a SaaS provider only to discover later that critical development, hosting or support functions are outsourced elsewhere.
The NIS2 Directive explicitly includes supply-chain security among the cybersecurity risk-management measures expected of organisations in scope. ENISA has also highlighted limited supplier visibility, concentration risk and complex cloud shared-responsibility models as continuing challenges.
In the next blog, I’ll look at the weakness of the traditional annual questionnaire as a way to assess supplier security, and will outline an alternative approach that takes account of their security posture on an ongoing basis.
Noel Barbour is head of the cybersecurity practice at BH Consulting.
