%401x.png)
What is fourth-party risk? Fourth-party risk is the exposure you carry through your vendors' vendors: the subprocessors and service providers that handle your data on a vendor's behalf. Most vendor inventories don't track them, so when one is breached, the first question is often "do we even use these guys?" AI can answer that in minutes if the data exists. If it doesn't, AI can't invent it.
The problem is growing. Verizon's 2026 Data Breach Investigations Report found third-party involvement in 48% of breaches, up from 30% the year before. And one vendor breach rarely stays with one company: the Black Kite 2026 Third-Party Breach Report counted an average of 5.28 downstream victims for every vendor breach, plus an estimated 26,000 victims that were never publicly disclosed.
This was the final scenario in a live experiment Trustero CEO Phillip Liu ran at Onspring GRC Day in Denver. He used Claude, an off-the-shelf AI assistant, on fictional companies and documents. The AI's responses were real.
The scenario: "Do we care about this?"
A breach notice gets forwarded at 9:14 a.m. The CFO wants an answer by 2 p.m.
A print-and-mail company nobody in IT recognizes has disclosed unauthorized access to a file transfer server. The notice is addressed to "Valued Customer" and arrived secondhand through someone's peer Slack group. Security's first take: "I don't think we use these guys?"
They do. The fictional retailer, Redrock Outdoor Co., uses the print vendor directly for marketing catalogs and HR mailings. So does Redrock's payroll vendor, which uses it to print employee W-2s.
This is why fourth-party incidents are so hard:
- Fourth parties are invisible in most vendor inventories.
- Breach notices are vague on purpose, with no named contact and few specifics.
- You need a summary and vendor outreach in the same hour.
What AI did with the breach notice
The prompt gave Claude the forwarded notice and asked: Do we use them? Does any vendor of ours use them as a subprocessor? What data of ours could have been in those files? Then draft a five-sentence CFO summary and vendor outreach emails with a deadline.
Claude's answer: yes, we care. The print vendor was a direct supplier ($67K a year, rated Low, never reviewed). And the payroll vendor prints Redrock's W-2s through it, which appeared as a named carve-out in the payroll vendor's SOC 2.
It mapped each path to the data at risk:
Then it connected a detail no one had asked about. The payroll vendor had answered "no material incidents" on its security questionnaire on August 28, one day before the breach window opened. Claude's recommendation: ask again.
Output: a five-sentence CFO summary, two outreach emails with 11 and 9 specific questions, and a 48-hour response deadline.
That's the connect-the-dots problem in a single morning: the answer was spread across an inventory, a SOC 2 carve-out and a questionnaire, and nobody had put them side by side.
Where AI stops: it only knows what you gave it, as of when you gave it
It can't tell if the notice is real. Secondhand, "Dear Valued Customer," no named contact. Claude flagged all three warning signs. It still drafted the CFO summary as though the notice were real, because it was asked to. Verify before you forward.
No live feed. Did a print job actually run in the breach window? Has the vendor updated its notice since? Unless AI is connected to your systems and the outside world, it's reasoning from a snapshot.
It can't find data you never collected. "Do other vendors use this print company?" was unknowable, because the inventory had no subprocessor column. Claude named six vendors worth asking and called them "unknowns, not findings." That's a common gap: Mitratech's review of 2026 TPRM exam expectations notes that examiners now expect fourth-party visibility, and that most programs stop looking one layer too early.
How to prepare for the next fourth-party incident
- Add a subprocessor field to your vendor inventory. Start with Tier 1 vendors and ask for their subprocessor lists at every review.
- Read SOC 2 carve-outs as a fourth-party list. Carved-out subservice organizations are fourth parties by definition. AI-assisted SOC 2 report evaluation makes it practical to pull them from every vendor report, not just the ones someone had time to read.
- Verify the notice before you escalate. Confirm it with the vendor directly, not through a forwarded email.
- Use AI for the first hour. Mapping data paths, drafting the executive summary and writing outreach questions is exactly where it saves time.
- Set deadlines and track responses in your system of record. An outreach email with no tracked deadline is a hope, not a process. Tools like Trustero Requests replace untracked email chains with assignable, auditable asks, including vendor attestations.
- Define what triggers a reassessment. A vendor's breach, a new subprocessor or a changed service should reopen the file. Our evidence-first, gap-driven TPRM workflow covers how to monitor for material changes.
The principle from the talk applies here more than anywhere: AI reads everything, remembers nothing, and signs off nothing. Verify the notice, call the vendor, and start collecting fourth-party data before the next one.
FAQ
What's the difference between third-party and fourth-party risk? Third parties are vendors you contract with directly. Fourth parties are the vendors your vendors rely on, such as subprocessors, hosting providers or print services, that may handle your data without a contract with you.
How do you identify fourth parties? Ask vendors for subprocessor lists, review carve-outs in their SOC 2 reports, check data processing agreements, and record the results in your vendor inventory.
How should you respond to a vendor breach notification? Verify the notice, confirm whether you or your vendors use the affected company, map what data could be exposed, brief leadership, and send outreach with specific questions and a response deadline.
Trustero builds a multi-agent AI system for GRC teams that works alongside the GRC platforms you already use. See how Trustero helps TPRM teams.