Skip to content
What is Third-Party Cyber Risk Management?
What is third-party cyber risk?
Third-party cyber risk is the cybersecurity exposure your organisation inherits through the vendors, suppliers, contractors, and service providers it relies on. It is not the risk of your systems being hacked directly. It is the risk of someone else's systems being hacked, and that attack reaching you through the access and trust you have already extended.
Every vendor with a connection to your environment, your data, or your infrastructure is a potential entry point. Cloud providers, managed service providers, payroll platforms, IT outsourcers, analytics tools. The access they need to do their job is the same access an attacker needs to reach you.
According to the Verizon 2025 Data Breach Investigations Report, third-party involvement in breaches doubled year-on-year, now accounting for 30% of all breaches, up from 15% the year before. That is not a niche problem. It is the mainstream of how breaches now happen.
Source: VerizonThird-party cyber risk management is the discipline of identifying, assessing, and reducing that exposure across the full vendor lifecycle. It sits within your broader third-party risk management programme but requires its own methodology, because the controls that govern financial or compliance risk do not automatically address cyber exposure.
Why are vendors a growing attack vector?
There's three factors that explain the shift.
Vendor dependency has expanded faster than oversight.
Every business function now runs on external platforms. Finance, HR, operations, customer service. SaaS adoption is efficient, but each integration is a connection your security team does not fully control. Wiz Research found that 82% of organisations provide third-party vendors with highly privileged roles in their cloud environments, and in most cases, cloud security teams were unaware these permissions had been granted. Vendors accumulate access over time.
Attackers have reoriented toward suppliers.
Targeting one well-defended enterprise is hard work. Targeting an MSP that serves fifty of them is efficient. A single compromised vendor can cascade across an entire customer base simultaneously, which is exactly what sophisticated ransomware groups have been doing. The Verizon 2025 DBIR noted that third-party breaches included credential exposures from partners, misconfigured SaaS environments, and a lack of secure-by-default settings, not just software supply chain vulnerabilities.
The cost of getting it wrong has increased.
IBM's 2024 Cost of a Data Breach Report put the global average breach cost at $4.88 million, a 10% increase from the year before and the largest annual jump since the pandemic. Third-party breaches tend to cost more than direct attacks because detection is slower, forensic access to the vendor environment is limited, and the operational disruption is broader.
What are the most common types of third-party cyber threats?
Software supply chain attacks
An attacker compromises a vendor's software, update mechanism, or code library. The malicious code then reaches every organisation running that software. The attacker breaches one vendor and gets access to thousands of downstream customers simultaneously. This is the highest-volume category.
Credential-based intrusion via vendor access
Vendors hold legitimate credentials into your environment. Attackers target vendor employees through phishing or social engineering, obtain those credentials, and use them to move into your systems. The Verizon 2025 DBIR, via Intelisys found that among breaches with third-party involvement, 81% involved system intrusion, and several notable incidents involved credential reuse in a third-party environment. The attack vector is the trust you have placed in the vendor, not a flaw in your own systems.
Cloud misconfiguration and over-permissioning
Third-party integrations into cloud environments routinely receive more access than they need, frequently as a result of vendor default settings rather than deliberate configuration. Wiz Research found that 76% of organisations have third-party roles that would allow for full account takeover, with most of those permissions serving no operational purpose.
Fourth-party exposure
Your vendor's vendor. A supplier with strong internal controls may rely on a sub-processor that does not meet the same standard. If that sub-processor is breached, the exposure travels upstream to you. Most organisations have limited visibility into this layer of their supply chain.
How do you assess third-party cyber risk?
Assessing third-party cyber risk is not a single activity. It is a set of practices across the vendor relationship.
Risk-based approach.
Not every vendor warrants the same depth of assessment. Tier based on what access a vendor has, what data they can reach, and how critical they are to your operations.
Use questionnaires as a starting point, not an endpoint.
Self-reported questionnaires give you a vendor's account of their own controls. They do not verify those controls are operating, they do not reflect changes since the last submission, and they do not identify live vulnerabilities. For high-tier vendors, combine questionnaires with independent attestations such as SOC 2 Type II or ISO 27001 certification, and evidence-based control reviews.
Review access, not just policy.
Ask vendors to confirm exactly what access they hold in your environment, what data they can reach, and whether those permissions are still required.
Assess contracts.
Your vendor contracts should specify security standards, breach notification timelines, audit rights, and remediation obligations. If those clauses are absent, you have limited leverage when an incident occurs. A contract review is part of a cyber risk assessment.
Monitor between assessments.
Vendor risk does not stay static between annual reviews. Vendors change systems, onboard sub-contractors, and introduce new vulnerabilities. Continuous monitoring is crucial to maintaining vendor threat visibility.
What regulations require third-party cyber risk management?
No single regulation mandates third-party cyber risk management universally. The obligations you face depend on where you operate, your sector, and where your vendors are located. That said, the regulatory direction is consistent: supply chain and third-party cyber risk is now a defined obligation across the frameworks most likely to apply to your organisation.
DORA (EU Digital Operational Resilience Act)
DORA, directly applicable across the EU from 17 January 2025, requires financial entities to maintain a comprehensive ICT risk management framework, with rigorous third-party ICT risk management as a core component. (AIGovHub). DORA also gives regulators direct oversight of critical third-party providers.
NIS2 (EU Network and Information Security Directive)
NIS2 expanded EU cybersecurity obligations to 18 critical sectors including energy, healthcare, finance, and public administration, with Member States required to transpose it into national law by October 2024. (Recast Software) Supply chain security is a defined obligation under NIS2. Organisations in scope must assess and manage the cybersecurity risks introduced by their technology supply chains, with penalties reaching up to 10 million euros or 2% of global annual turnover.
GDPR
A data breach originating at a vendor does not transfer liability away from you as data controller. If a vendor processes personal data on your behalf and suffers a breach, you carry the notification obligation under GDPR. This makes vendor cyber controls a data protection issue, not just a security one.
The practical implication for multinationals is that several of these frameworks apply simultaneously. A financial institution with EU operations and UK headquarters may face DORA, NIS2, FCA, and GDPR obligations at the same time, each with different thresholds, timelines, and documentation requirements.
How do you build a third-party cyber risk programme?
A third-party cyber risk programme is not a procurement checklist. It is a set of embedded controls across the vendor lifecycle. Here is what that looks like in practice.
Build your vendor inventory first.
You cannot manage what you have not mapped. Start with a complete list of all vendors that have system access, data access, or cloud integrations. Include access that was provisioned historically and never reviewed. That inventory is your baseline.
Tier vendors by cyber exposure.
Segment vendors based on access type, data sensitivity, operational criticality, and sub-contractor complexity. Tier determines assessment depth and monitoring frequency.
Define minimum security standards before you assess.
Establish what good looks like for each tier before issuing questionnaires or requesting evidence. Standards should cover access controls, encryption, incident response capability, patching cadence, and certification requirements. Without a fixed standard, findings have no anchor.
Embed cyber requirements into contracts.
Minimum security standards, breach notification timelines, audit rights, and remediation obligations must be contractually defined and enforceable. If they are absent from existing contracts, target the next renewal cycle to introduce them. Without contractual levers, your programme has no teeth.
Go beyond questionnaires.
Vendors with privileged access, combine questionnaires with independent attestations, evidence-based reviews, and external technical assessments. A completed questionnaire is not evidence that controls are working.
Implement continuous monitoring.
Annual assessments miss everything that changes in between. Connect to external threat intelligence and vulnerability feeds that track changes in your vendors' security posture in real time.
Build an incident response protocol for vendor breaches.
When a vendor breach is detected, the questions that matter are: who is notified, within what timeframe, and who has authority to act. Define those answers before an incident happens. Many organisations discover they have no vendor-specific incident response process only when they need one.
Report at the right level.
Third-party cyber risk should be visible to the board and senior risk committees, not just the security team. Aggregate vendor-level findings into portfolio-level reporting that shows risk exposure by tier, domain, and business unit.
Frequently asked questions
What is the difference between third-party cyber risk and general third-party risk?
Third-party risk management covers all risk domains introduced by external parties: operational, financial, compliance, reputational, and cyber. Third-party cyber risk management is a specialist discipline within that, focused on cybersecurity and information security exposure. Organisations that treat cyber as just another column in their risk register typically end up under-assessing it.
Do we need a separate programme for third-party cyber risk?
Not necessarily separate, but it needs to be explicitly embedded in your existing TPRM programme with its own methodology. Generic risk questionnaires and periodic reviews are not sufficient for high-tier vendors with system access. The assessment approach, monitoring cadence, and contractual requirements need to be calibrated to cyber-specific exposure.
How often should we assess vendor cyber risk?
It depends on the tier. Critical vendors typically warrant annual formal assessment with continuous monitoring between cycles. Lower-tier vendors with minimal access may be assessed less frequently. The principle is that assessment frequency should reflect the level of access and operational dependency, not administrative convenience.
Are questionnaires sufficient for assessing vendor cyber risk?
For lower-tier vendors, yes. For vendors with privileged access, sensitive data, or critical operational dependencies, no. Questionnaires capture self-reported information at a point in time. For high-tier vendors, independent attestations such as SOC 2 Type II or ISO 27001, evidence-based control reviews, and external technical assessments provide a more reliable picture.
Who should own third-party cyber risk in our organisation?
No single function. Contracts sit with legal, due diligence with procurement or compliance, technical assessments with security, and monitoring with risk. Effective ownership requires shared accountability with defined roles, a central governance model, and executive sponsorship. Treating it as IT's problem alone is one of the most common reasons organisations are caught off guard when a vendor breach occurs.
What happens if a vendor breach exposes our customer data?
Under GDPR, you remain the data controller. A breach at a vendor that processes personal data on your behalf does not transfer your notification or liability obligations. You are responsible for notifying the relevant supervisory authority within 72 hours and, where required, affected individuals. The vendor's failure is your regulatory event.