August 20, 2026
Updated: August 20, 2026
Vendors are the attack path: how to tier, assess, contract, monitor, and offboard every third party you depend on.
Abdalla Mohamed
Third-party risk management is the process of identifying, assessing, and controlling the risks your organization inherits from vendors, suppliers, and partners, the outside companies that touch your data, systems, or operations. It matters because attackers have learned that the easiest way into a hardened target is often through a weaker supplier, and the numbers bear that out: 48 percent of breaches in Verizon's 2026 DBIR involved a third party, up from 30 percent the year before, and single vendor compromises have cascaded into thousands of victim organizations at once. This guide walks through the TPRM lifecycle, how to assess and monitor vendors, the frameworks and regulations that shape the discipline, and the fourth-party risk most programs miss.
Updated: August 2026. Reflects the Verizon 2026 DBIR finding that third-party involvement reached 48 percent of breaches, the MOVEit supply-chain wave, NIST SP 800-161 (C-SCRM), and the EU DORA regulation now in force.
Third-party risk management (TPRM) is a structured program for handling the risk that comes with relying on outside parties. Any vendor that stores your data, connects to your network, or supports a critical business function introduces risk you do not fully control, and TPRM is how you bring that risk into view and keep it within tolerance.
A few related terms overlap:
The unifying idea is simple: your security is only as strong as the weakest partner with access to your data or systems.
Third-party breaches have moved from edge case to main event. The Verizon Data Breach Investigations Report shows a sharp multi-year rise in third-party involvement: about 15 percent in 2024, 30 percent in 2025, and 48 percent in 2026. That means nearly half of breaches in the latest report involved a third party. On cost, IBM's breach research has repeatedly ranked supply-chain and third-party compromise among the more expensive root causes.
The reason is structural. Modern businesses run on dozens or hundreds of interconnected vendors, and each integration is a potential path in. Two landmark incidents made the stakes obvious:
These are not anomalies; they are the model attackers now follow. The full picture is in our third-party data breach statistics and vendor risk statistics roundups.
TPRM is broader than cybersecurity, though cyber is the sharpest edge. A complete program considers:
The most damaging incidents usually combine several at once: a cyber breach at a critical vendor becomes an operational outage, a compliance failure, and a reputational hit simultaneously. A mature enterprise program may also account for geopolitical, geographic, strategic, ethical, or environmental risk where those factors are material to the relationship.
No single operating model fits every organization. TPRM often spans procurement, security, legal, privacy, compliance, business owners, and enterprise risk, so the important thing is not which team has the label but whether accountability is explicit.
| Activity | Procurement | Security | Legal | Business Owner | Risk / Governance |
|---|---|---|---|---|---|
| Vendor intake | R | C | C | A | I |
| Security assessment | C | R | C | C | A |
| Contract security terms | R | C | A | C | I |
| Risk acceptance | C | C | C | R | A |
| Ongoing monitoring | C | R | I | C | A |
| Offboarding | R | C | C | A | I |
R = Responsible, A = Accountable, C = Consulted, I = Informed.
Effective programs manage each vendor through a repeatable lifecycle rather than a one-time check at signing. The stages below are a common six-phase model; smaller programs compress them, but the logic holds.
Before onboarding, define the relationship and assess inherent risk: what data and access will this vendor have, and how critical are they? Tier vendors by that risk so a payroll processor with access to employee data gets far more scrutiny than a supplier of office snacks. Tiering is what makes the rest of the program scalable, because it focuses effort where the risk actually is.
Assess the vendor's security posture before you commit. This is where questionnaires, attestations, and ratings come in (covered in the next section). The depth of due diligence should match the vendor's tier: a critical vendor with access to sensitive data warrants deep review, including evidence, while a low-risk vendor may need only a light-touch check.
Bake security and accountability into the contract. Strong agreements specify security requirements, data-handling obligations, breach-notification timelines, a right to audit, compliance expectations, and, importantly, an exit strategy. The contract is your main lever for holding a vendor accountable, so what is not written down is hard to enforce later.
For critical vendors, consider making the following explicit:
Bring the vendor into your environment with least-privilege access, documented data flows, and the controls the assessment identified. Onboarding is where the agreed controls actually get implemented, and where a clean inventory of what the vendor can touch is established.
Risk is not static, so assessment cannot be a one-time event. Continuously monitor for changes in the vendor's posture, new vulnerabilities, breaches, security-rating drops, or shifts in the services they provide, and re-assess critical vendors on a defined cadence. Continuous monitoring is the phase most programs underinvest in, and it is where real-world risk actually changes.
When the relationship ends, close it out deliberately: revoke access, disconnect integrations, retrieve or confirm destruction of your data, and formally settle remaining obligations. A forgotten vendor account with lingering access is a classic breach vector, so offboarding is a security control, not just paperwork.
TPRM works best when it separates the risk a vendor creates before controls from the risk that remains after controls.
For example, a cloud payroll provider storing employee identity data may begin as High inherent risk. After strong encryption, MFA, restricted access, current assurance evidence, and contractual controls are validated, the residual risk may fall to Moderate. The final decision should be based on residual risk, not inherent risk alone.
Several methods exist, and mature programs combine them rather than relying on any single one.
| Method | What it provides | Limitation |
|---|---|---|
| Security questionnaires (SIG, CAIQ) | A structured self-assessment of the vendor's controls | Self-reported; only as honest as the respondent |
| Certifications and audit reports (SOC 2, ISO 27001) | Independent, evidenced attestation of controls | Point-in-time; scope may not match your concerns |
| Security ratings | Continuous outside-in scoring of a vendor's posture | Signals, not proof; can miss internal controls |
| Penetration test reports | Evidence a vendor's defenses were actively tested | Depends on scope and recency; ask for both |
| Continuous monitoring | Ongoing alerting on new vendor risk | Needs process to act on the alerts |
The strongest signal is independent evidence. A completed questionnaire is a starting point; a current SOC 2 report or a recent penetration test report shows the vendor's controls were actually examined by an outside party. This cuts both ways: your own customers increasingly demand the same evidence from you, which is why many companies commission a pentest specifically to satisfy their clients' third-party risk reviews.
You do not have to invent a program from scratch. Several standards and regulations define what good looks like.
| Framework / regulation | What it covers |
|---|---|
| NIST SP 800-161 (C-SCRM) | The primary US guidance for cybersecurity supply-chain risk, including fourth-party risk |
| NIST SP 800-53 (SR family) & NIST CSF | Supply-chain risk controls and the govern/identify functions that anchor a program |
| ISO/IEC 27036 | International standard for supplier-relationship information security |
| EU DORA | In force since January 2025; Chapter V, including Article 28 and related provisions, establishes the ICT third-party risk framework, register-of-information obligations, due-diligence considerations, contractual requirements, and exit strategies |
| GDPR, HIPAA, sector rules | Impose direct obligations to manage the security and privacy risk of third parties handling your data |
For regulated organizations, especially EU financial firms under DORA, third-party risk management is now a legal requirement with specific, auditable outcomes, not just good practice.
Automation helps the program scale, but it should remove repetitive work rather than automate final risk judgment.
Good candidates for automation include:
Keep human review for exceptions, final risk acceptance, material contract decisions, and complex evidence interpretation. Automation should accelerate the workflow, not replace accountability.
Measure the program so you can prove it works and find where it does not. The metrics that matter:
Trend these over time. A maturing program shows rising coverage, shrinking assessment backlogs, and better-understood concentration risk.
Penetration testing sits on both sides of the third-party relationship, which is what makes it uniquely useful here.
Looking outward at your vendors, a recent, well-scoped pentest report is some of the strongest evidence a critical vendor can provide that its defenses were actually tested by an independent party, far stronger than a self-completed questionnaire. Asking data-rich vendors for their latest test results, and the scope behind them, is a practical way to move due diligence from self-attestation toward evidence.
Looking inward, your own customers are running the same playbook on you. As third-party risk reviews become standard in enterprise procurement, more organizations commission a penetration test specifically to satisfy their customers' TPRM and vendor-assessment requirements. A recent independent pentest can reduce due-diligence friction by giving customers evidence that key controls were actively tested. In that sense, being a well-tested vendor can support procurement confidence in a market where everyone is assessing everyone else.
A mature TPRM program should connect directly to incident response. When a critical vendor reports a breach:
Your vendors have vendors, and their weaknesses can reach you. Fourth-party (and beyond, "Nth-party") risk is the dependence you inherit through your direct suppliers, and it is largely invisible unless you go looking. The MOVEit incident is the textbook case: many victim organizations had no direct relationship with the file-transfer product at all; they were exposed because a vendor, or a vendor's vendor, used it.
You cannot assess every party in the chain, but you can require your critical vendors to demonstrate their own third-party risk management, ask about their key subcontractors, and factor concentration risk, many of your vendors depending on the same upstream provider, into your planning. NIST SP 800-161 explicitly extends to this deeper supply chain for exactly this reason.
TPRM is conceptually straightforward and operationally hard. The obstacles most programs hit:
Recognizing these limits is what pushes programs toward tiering, continuous monitoring, and independent evidence rather than questionnaire checkboxes.
If you are maturing a program, a workable path looks like this:
Start with an inventory and tiering. You cannot manage third-party risk you cannot see. Build a complete vendor inventory, including the shadow SaaS, then tier each vendor by the data and access it holds. This single step focuses everything that follows.
Standardize assessment by tier. Define what due diligence each tier requires, deep evidence review for critical vendors, lighter checks for low-risk ones, so effort scales with risk instead of treating every vendor the same. Lean on independent evidence like SOC 2 and pentest reports over self-assessment where the stakes are high.
Operationalize monitoring. Move from one-time assessments to continuous oversight of your critical vendors, watching for breaches, posture changes, and new exposures, with a defined cadence for reassessment. This is where a program stops being a procurement gate and becomes real risk management.
Tie it to the business. Connect TPRM to incident response, so a vendor breach triggers your own playbook, and to procurement, so no critical vendor is onboarded without review. The cost of getting this wrong is measured in real dollars; industry breach research has put third-party and supply-chain compromise among the most expensive root causes, and the broader cost of a data breach climbs when a third party is involved.
Maturity is incremental. An inventory with basic tiering already puts you ahead of most organizations; continuous monitoring of critical vendors is what separates a strong program from a compliance exercise.
Third-party risk management has become one of the highest-leverage disciplines in security because the attack path so often runs through a supplier rather than your own perimeter. With nearly half of breaches now involving a third party and single-vendor compromises cascading into thousands of victims, a signing-day questionnaire is not enough. Run every vendor through a real lifecycle, tier by risk, assess with independent evidence, monitor continuously, and account for the fourth parties hiding behind your direct suppliers. The regulations, from DORA to NIST 800-161, are converging on exactly that expectation.
It is how an organization manages the risk created by the outside companies it depends on, vendors, suppliers, and partners that touch its data, systems, or operations. TPRM identifies those parties, assesses how risky each one is, sets controls and contract terms, and monitors them over time so a weakness at a supplier does not become a breach at your company.
The terms are often used interchangeably. Vendor risk management (VRM) focuses on paid vendors, while third-party risk management is slightly broader, covering any third party you rely on, including partners and non-vendor relationships. In practice most programs treat them as the same discipline.
A common model has six phases: planning and vendor tiering, due diligence and risk assessment, contracting, onboarding, ongoing monitoring, and offboarding. The key idea is that risk management continues throughout the relationship, not just at signing, with the depth of effort matched to how critical and data-rich each vendor is.
Fourth-party risk is the risk you inherit from your vendors' vendors, the subcontractors and suppliers your direct third parties depend on. You have no direct relationship with them, which makes the risk hard to see, but it is real: many MOVEit victims were exposed through a vendor's use of the software rather than their own. NIST SP 800-161 specifically addresses this deeper supply chain.
Key frameworks include NIST SP 800-161 (cybersecurity supply-chain risk), NIST SP 800-53 and the NIST CSF, and ISO/IEC 27036. On the regulatory side, the EU's DORA (in force since January 2025) mandates specific third-party risk practices for financial firms, and GDPR, HIPAA, and various sector rules impose obligations to manage third parties that handle your data.
A vendor security questionnaire is a standardized set of questions sent to a third party to evaluate its security controls. The most common are the SIG (Standardized Information Gathering) questionnaire from Shared Assessments and the CAIQ from the Cloud Security Alliance. They give a structured, comparable view of a vendor's posture, but because they are self-reported, mature programs pair them with independent evidence such as SOC 2 reports, ISO 27001 certificates, and recent penetration test results.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us
