Third-party Risk Management: SOC 2s, Security Questionnaires, and Beyond

Third-party Risk Management: SOC 2s, Security Questionnaires, and Beyond

Speaker: Eleanor Mount

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch on YouTube

Reading time: ~6 minutes

TL;DR

Eleanor Mount, a GRC professional and security risk and compliance manager at Ansa, delivered a frank dissection of why third-party risk management programs consistently fail to deliver on their promise — and offered five concrete ways practitioners can take ownership rather than just checking boxes. The through-line: most TPRM pain is self-inflicted, and the fixes are available today.

Introduction

Third-party risk management is one of those disciplines that everyone agrees matters and almost nobody does well. Supply chain attacks have moved from edge-case to front-page news. Regulators across HIPAA, SOC 2, and regional frameworks now explicitly demand vendor oversight. And yet the industry has produced a cottage industry of workarounds — trust centers, compliance-as-a-service platforms, automated security scorecards — that collectively give the impression of rigorous assessment while often delivering very little signal.

Mount's talk, titled "Third-Party Risk Management: SOC 2s, Security Questionnaires, and Psychosis," used the framing of Sonja Morgan from The Real Housewives of New York City — a character with an unaccountable roster of vendors, interns, and hangers-on who ultimately files Chapter 11 — to illustrate what organizations without proper vendor oversight look like. The analogy landed: without visibility into who you are paying and why, costs accumulate, risks compound, and the eventual reckoning is painful.

The Real Problems in TPRM Today

▶ Watch: The self-inflicted problems in third-party risk management (06:30)

Mount identified four distinct failure modes that plague TPRM programs, each of which she described as self-imposed rather than structural:

The information exchange problem. Requesting documentation from a vendor triggers weeks of back-and-forth, incomplete responses, and version confusion. A vendor sends their SOC 3 instead of their SOC 2. The reviewer is not sure whether the attestation period is long enough to be meaningful. Everyone is frustrated and the end result is often a decision made without adequate information.

The reliability problem. Even when documentation arrives, it may not be trustworthy. SOC 2 audits have become commoditized: some assessors now issue reports covering as little as one month, reducing what is nominally a continuous monitoring attestation to a point-in-time snapshot. The result is a market where audit reports carry less evidentiary weight than they once did, and vendors who want to obscure problems have ample opportunity to do so.

Mount illustrated this with a personal story. When onboarding a vendor, she requested a SOC 2 report and was told that this was "extremely abnormal" — that a SOC 3 had always been sufficient, that nobody else had ever asked for this. After persistent follow-up, the SOC 2 arrived and disclosed a significant security incident on the first page. The vendor had been actively discouraging review of a document they were required to provide.

The misleading trust problem. Vendors demonstrate "trust" in ways designed to satisfy procurement processes rather than answer genuine security questions. Information overload — sending 27 policies without a summary — is a common tactic. Marketing rights clauses allow vendors to list client logos on their websites without active endorsement; in one case Mount described, her company appeared on a vendor's "trusted by" list for tools they did not know they were using, having accumulated the relationship through a click-through agreement signed years earlier.

Contracting tricks. The argument "we've passed security review at Goldman Sachs, so why is your process taking so long?" is a pressure tactic, not an answer. Every organization has a different risk tolerance, and a vendor clearing one company's bar says nothing about whether it clears yours.

What Actually Works

▶ Watch: Five recommendations for effective TPRM (22:00)

Mount's five recommendations move from structural to tactical:

1. Embed TPRM in existing business processes. The biggest reason TPRM programs fail is that they exist as a separate gate that business stakeholders resent crossing. Connecting assessments to budget cycles, Okta provisioning, security design reviews, and data mapping makes TPRM a feature of how work gets done rather than a tollbooth blocking it.

2. Track and share metrics. Reviewers who can demonstrate where the time actually goes — that the six-week delay is waiting for vendor documentation, not sitting in the security team's queue — build credibility with stakeholders and create the conditions for continuous improvement. "You can't manage what you're not measuring" is a cliché, but Mount applied it specifically: track vendor response times, number of high-risk vendors, which vendors have signed your security addendum and which have negotiated it.

3. Determine your risk tolerance and enforce it. Risk tolerance should be established before a vendor conversation begins, not negotiated during it. Start from zero trust and define the minimum set of requirements that must be in place before data is shared. Document those requirements. Create an exception process so that risk acceptance is explicit and auditable rather than implicit and forgotten.

▶ Watch: Risk tolerance, zero trust starting points, and red flags (27:15)

4. Be discerning with information you receive. In 2025, AI can help review vendor documentation against a defined checklist. Mount recommended using LLMs to do an initial assessment of materials against specific criteria rather than reading through voluminous policy documents manually. The corollary: do not send security questionnaires when public documentation already answers your questions. Every questionnaire you don't send is time saved for both parties.

5. Use creative contracting approaches. Three options were discussed. Generic security addenda — drawing on publicly available frameworks like the Minimum Viable Secure Product (MVSP) — establish a consistent baseline across vendors. Situation-specific addenda can differentiate between contractors with laptop access, high-risk data processors, and AI service providers. And for specific use cases, contract-based risk transfer can shift responsibility for enabling risky features to the customer rather than the vendor, reducing organizational exposure.

The Q&A: Notable Practical Points

▶ Watch: Audience Q&A — metrics, AI use, and vendor escalations (36:00)

The Q&A surfaced several points worth noting. On using AI for TPRM: Mount endorsed feeding vendor documentation into LLMs for initial review, while maintaining a human in the loop. Her view on whether this violates vendor NDAs: "It depends." On tools, she mentioned Asana and Wistic as platforms she has used for tracking vendor risk posture, while emphasizing that the best tool is the one that achieves stakeholder engagement — a sophisticated platform nobody logs into is worse than a spreadsheet everyone uses.

On the TPRM team's decision-making authority, Mount drew a clean line: the function should serve as guardrails, not gatekeepers. "You can inform the business — here are the risks you are taking on — but sometimes you have to make trade-offs." The goal is to influence decisions strongly and to be trusted enough that stakeholders bring the team in early, before vendor conversations are already in motion.

Notable Quotes

"Don't let vendors pull your leg. Start with zero trust. Develop your own risk tolerance. Don't fall for distasteful tactics." — Eleanor Mount (▶ 33:40)

"If you have a consistent approach to contracting and vendor management, you treat all of your vendors the same." — Eleanor Mount (▶ 08:15)

"We're all responsible for making this space better. Don't send questionnaires if you don't have to." — Eleanor Mount (▶ 34:50)

Key Takeaways

• Most TPRM pain is self-inflicted. Information exchange delays, unreliable audit reports, and contracting tricks are addressable problems — they persist because organizations accept them as inevitable.
• SOC 2 reports are not all equal. Audit commoditization means a one-month-scope attestation from a low-scrutiny assessor is structurally different from a full-year report. Reviewers need to understand what they are actually receiving.
• Establish risk tolerance before vendor conversations start. Negotiating requirements in the middle of a procurement process gives vendors leverage they should not have.
• AI is useful for initial documentation review. LLMs can assess whether vendor materials meet a defined set of requirements, reducing the time burden without removing the human judgment step.
• Creative contracting reduces the need for validation. If a vendor contractually commits to your security requirements, the bar for independent verification of every control drops significantly.