4 MIN READ
Picture the standard third party risk program at any large company. The typical organisation runs 500 to 2,000 third party relationships. The CISO owns the program on paper. The procurement lead schedules the assessments. The security org chases the questionnaires. The vendor receives a 500 question security questionnaire, fills it out in a week, ships a SOC 2 the auditor stamped six months ago, and waits for the next review. The buyer files the report in a folder that nobody opens. Then an approved vendor gets popped, the data shows up on a leak site, and someone asks who signed off. That is the state of third party risk management in 2026, a $15B annual market that has not actually solved the problem it exists to solve.
Lineage worth knowing. SolarWinds in 2020 was the breach that moved the topic onto the C suite dashboard for the first time. MOVEit in 2023 was the breach that moved it onto the regulator’s desk. The 2025 Snowflake credential thefts moved it onto the operations floor, with Fortune 500 companies taking multi day outages because service account credentials were never rotated. Each breach shifted the topic up the org chart. None of them shifted the program. The 2026 state of third party risk is a $15B annual spend that produces 100 to 500 page reports per vendor, and almost nobody can tell you which of those reports they have actually read.
What the typical TPRM program looks like
The typical program has three tells. The questionnaire, where the team sends the vendor a 500 question security questionnaire, the vendor fills it out, the security org reviews the answers, and someone approves the vendor. Nobody reads the full document. The certification, where the company requires a SOC 2, an ISO 27001, a PCI DSS, the vendor has them, the company accepts them, and the certifications ran accurate six months ago. The continuous monitoring service, SecurityScorecard, Bitsight, UpGuard, scoring the vendor from the outside while the actual security posture of the vendor has nothing to do with the score. When the score drops, nobody acts on the drop. All three tells together describe a program that has the paperwork of risk management and almost none of the substance.
What the typical buyer has tried
Three patterns repeat, and all three fail in the same way. Centralisation puts a single TPRM team in charge of every vendor, and they become the bottleneck while vendor onboarding slows to a crawl. Tiering sends the critical vendors through the thorough review and routes everyone else through the questionnaire, with the tiering itself set in 2018 and never updated since. The contract clause stuffs the security requirements into the master service agreement, gets them signed, and never enforces them. The signed contract ran strong in 2020. None of these patterns fail because the people running the program are incompetent. They fail because the program runs as a procurement exercise rather than a security one.
How to actually do it
Three moves that work. Prioritise the vendors by what they can touch, not by their name. The vendor with access to the customer data, the production system, the credentials, sits at the top of the list. The vendor with access to the marketing analytics, the office supplies, the travel booking, sits at the bottom. Without that access analysis, the team is left with a long list of vendors they cannot act on. Second, build the continuous monitoring into the contract. A vendor that refuses monitoring is one nobody can assess at all. A vendor that accepts it is one the team can actually see between reviews. Third, treat the vendor breach as their own breach. When the regulator investigates, the customer reads the disclosure, the press writes the story, nobody accepts “it was the third party” as an answer. The program that does those three things is the program that works.
The bottom line
Prioritise by access, build the monitoring into the contract, treat the vendor breach as your own. Third party risk in 2026 is not a procurement problem, and the security org that still treats it like one is the one that ends up named in the breach disclosure.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
