Third-party risk is the exposure a company inherits from the organizations it opens its doors to: technology providers, cloud services, integrators, contractors, partners, and the software you install without fully reading the terms. It is not the risk that they have a problem. It is the risk that their problem becomes yours, with your data and your operations inside it.
Almost half of attacks now come in that way. The Verizon 2026 DBIR found a third party involved in 48% of the breaches analyzed, 60% more than the previous year. And according to the SecurityScorecard supply chain report from March 2026, 78% of organizations monitor less than half of their vendor ecosystem.
Together, the two figures explain why the attacker chose that door: it is the busiest and the least watched.
What counts as a third party?
More things than usually appear in the inventory. A third party is any external organization that touches your systems, your data, or your operations:
- The IT provider or the MSSP that manages your infrastructure and usually has privileged accounts.
- The cloud applications where payroll, the CRM, billing, or your customers’ records live.
- Consulting firms and integrators that come in for a project and sometimes keep the access long afterward.
- Contractors, freelancers, and temporary staff with their own equipment.
- Business partners connected to your network or your ERP to exchange information.
- The software itself: updates, libraries, plugins, and dependencies that arrive signed and trusted.
And there is one more level, the one that is almost never on any list: your vendors’ vendors. It is called fourth-party risk, or fourth-level risk. Your payroll provider subcontracts email delivery, that service is compromised, and the email with your people’s pay stubs comes from a company that does not appear in any of your contracts.
Why does the attack come in through the vendor?
For four reasons that have little to do with technology and a lot to do with business logic.
The first is that the third party comes in with permission. It has valid credentials, an approved VPN, sometimes an administrator account. The attacker who takes over that access does not have to break anything, just use it. To your controls, it looks like a normal workday.
The second is implicit trust. On the day the contract was signed, someone reviewed the vendor. After that, no one asked again. That “it is already approved” is the longest-lasting permission that exists in any company, and it is exactly what the model Zero Trust challenges.
The third is economics. Compromising one company gives access to one company. Compromising the provider that serves it gives access to dozens or hundreds, all configured in a similar way, all with the same remote administration tool. Seen from the other side of the keyboard, it is the best ratio of effort to result on the market.
The fourth is the most uncomfortable: the key no one revoked. The project ended, the contract expired, the person changed jobs, and the account is still active. There is no sophisticated attack behind it. There is an administrative task that no one was assigned.
How many types of third-party risk are there?
It is worth separating them, because each one is controlled differently, and mixing them up is the reason many vendor programs reduce nothing.
| Type | What it is about | Typical example |
|---|---|---|
| Access risk | The third party accesses your systems | A support provider with an administrator account and no two-factor authentication |
| Software supply chain | The code you install brings the problem | A legitimate, signed update with a backdoor inside |
| Data in custody | The third party stores your information or your customers’ information | The breach occurs at the payroll SaaS, and the exposed data belongs to your people |
| Operational dependency | They do not steal anything from you; they bring you to a halt | A cloud or logistics provider out of service for two days |
| Inherited compliance | The error belongs to the third party, and the responsibility is still yours | A subcontractor processes personal data without the measures the law requires |
The last two are the ones that surprise executives the most. In the eyes of your customers and the regulator, delegating operations does not delegate responsibility.
How is third-party risk managed?
The discipline that deals with this is called TPRM, short for third-party risk management, third-party risk management. And it is not a questionnaire answered once: it is a cycle with four stages. The most widely used reference framework, the NIST SP 800-161, frames it the same way.
Before signing. A complete inventory and classification by criticality. Not all vendors deserve the same effort: first those with remote access, those that store personal data, and those that, if they stop, stop you. If a vendor meets all three, that is where the program starts.
In the contract. It is the only moment when you have real negotiating power. Four clauses that should always be there: which systems and data the vendor can touch, how quickly it must notify you of an incident (72 hours is the reasonable standard), the right to request evidence or an audit, and the obligation to notify you if it subcontracts anyone else.
During the relationship. Minimal, temporary access instead of permanent access, two-factor authentication managed by you and not by the vendor, named accounts instead of shared ones, and activity monitored by your SOC just like an employee’s. A vendor access that no one watches is a blind spot with a contract.
At offboarding. The step almost everyone skips. Revoke credentials, close accounts, remove network access, confirm in writing the return or deletion of data. No tool solves this: it is solved by someone who has the task assigned and a deadline.
And why does the vendor list grow faster than the capacity to review it?
Because buying technology is no longer a decision for the IT department. Today any team solves a problem in an afternoon with a corporate card and an email sign-up. It is almost always good news for the business, and it is always a new third party that no one assessed. It is the same phenomenon we already saw with AI that employees use without approval, and it is governed the same way: not by prohibiting, but by making the approved path the easiest one to take.
Six questions before giving a vendor access
- Exactly which systems and which data will it access, and who authorized that scope?
- Is the access permanent, or is it opened when needed and closed when the work is done?
- How quickly do you commit to notifying us of an incident, and is it in writing?
- Do you subcontract any part of the service? To whom, and will you notify us if that changes?
- What security evidence can you show today, without preparing anything?
- When the contract ends, who on our side is responsible for closing the door?
The sixth is the one that almost never has an owner, and it is the one that shows up in forensic reports.
Frequently asked questions
Is third-party risk the same as supply chain risk?
What is fourth-level or fourth-party risk?
How many vendors need to be reviewed?
Is it enough for the vendor to fill out a security questionnaire?
If the vendor loses my customers’ data, who is accountable?
A signature is also a door
Every new vendor solves something and opens something. The useful question is not how many vendors you have; it is how many of them could shut you down tomorrow or get into your systems tonight, and which of those two groups someone is watching.
Our managed 24/7 SOC monitors the activity of third-party access just like that of any internal user, because to an attacker that difference does not exist. If you do not yet have the inventory of who has access to what, the free security assessment is the fastest way to build it. The other terms that appear in this article are explained in our cybersecurity glossary.
A vendor is not assessed on the day it signs. It is monitored every day it still has access.
