Third-party risk intelligence: why vendor questionnaires aren't enough

The standard vendor risk questionnaire was designed for a world that no longer exists. In that world, vendors were stable entities with fixed integrations, audits happened annually, and the biggest third-party risk was a vendor going out of business. Today your SaaS stack turns over faster than your questionnaire cycle. A vendor who passed your assessment six months ago may have acquired a company, re-architected their cloud, or suffered a breach they haven't disclosed yet.

Questionnaires don't tell you what's happening. They tell you what a vendor believed to be true about their environment on the day someone filled out the form.

This isn't an argument against questionnaires. They have a place. But treating them as the primary instrument of third-party risk management is how organizations end up with a false sense of coverage.

What questionnaires actually measure

A questionnaire measures whether a vendor has security policies and whether the person filling out the form believes those policies are followed. That isn't nothing. It is, however, far removed from what you actually need to know: whether a vendor's current security posture creates meaningful exposure for your organization.

The gap between "we have a policy" and "that policy is working" is where most third-party incidents live.

SolarWinds had security policies. The vendor who left a misconfigured S3 bucket exposed with your customer data almost certainly checked "yes" to questions about data security. Questionnaires don't catch configuration drift, unpatched dependencies, or the new engineer who got admin access without MFA because someone was in a hurry.

The three things your TPRM program needs

Continuous signal, not point-in-time assessment

You need to know when something changes, not just that something was true last quarter. The vendors that matter most, the ones with production access, data access, or integration into your critical systems, need monitoring between formal assessment cycles. What you're looking for is drift. A vendor whose ratings were stable for a year and are now declining fast is a different risk than a vendor with a mediocre but stable posture.

Tiered attention based on actual exposure

Not all vendors are the same risk. A vendor with read-only access to non-sensitive reporting data is not your identity provider. Most organizations badly over-invest in assessing low-risk vendors through lengthy questionnaires and under-invest in continuous monitoring of high-risk ones. Tier the program explicitly. Tier 1 vendors (production data access, core system integrations) warrant continuous monitoring and annual deep assessments. Tier 2 vendors (operational access, some data exposure) warrant annual assessments and periodic signal checks. Tier 3 vendors (commodity services, no data access) warrant a lightweight initial review and nothing more.

KRIs extracted from real data, not self-attestation

For your Tier 1 vendors, you want signals from actual sources: security ratings platforms, breach intelligence feeds, publicly available certificate and DNS data, and ideally some visibility into the vendor's own control telemetry if they'll share it. Self-attestation complements these signals. It doesn't replace them.

The vendor risk signals worth watching

Across your Tier 1 and Tier 2 vendors, these are the signals that tend to precede problems.

Security rating decline

Bitsight, SecurityScorecard, and similar platforms provide continuous external ratings based on observable data: open ports, certificate health, patching cadence on internet-facing assets. A steady decline over 60 to 90 days is a meaningful signal. A single-week dip usually isn't.

Credential exposure in breach data

Services that monitor paste sites and dark web data can tell you when employee credentials from a vendor appear in a breach dataset. A vendor with a significant volume of exposed credentials has an elevated probability of an account takeover that could reach downstream systems, including yours.

Certificate and DNS anomalies

Changes to a vendor's certificate infrastructure, unexpected subdomain creation, or DNS record changes outside normal change windows can indicate unauthorized activity or a compromised environment. These signals are cheap to monitor and often appear before a public disclosure.

Unpatched critical CVEs on internet-facing assets

Scanning tools can identify whether a vendor has unpatched critical vulnerabilities on their internet-facing infrastructure. It's one of the most direct indicators of security hygiene at the operational level.

Delayed or incomplete response to your security inquiries

This one is behavioral, not technical, but it matters. A vendor who takes three weeks to answer a direct question about their MFA policy or incident response procedures is telling you something. Whether it's "they're disorganized" or "they have something to hide" is worth finding out before an incident, not after.

A vendor whose rating is declining while their access to your data stays high is exactly the kind of compound signal that deserves a direct conversation rather than a wait for the next review cycle.

Building a practical TPRM program

The goal is a program you can actually run with the resources you have. For a 50 to 500 person organization, that looks like this.

Start with a vendor inventory. Most organizations know less than they think about what's in their SaaS stack, and shadow IT is where unmanaged third-party risk lives. Run a cloud discovery exercise before you build your risk program. You can't tier vendors you don't know exist.

Tier your vendor list ruthlessly. Most organizations have a small number of truly high-risk vendors (probably 5 to 15) and a much larger number of low-risk ones. Your Tier 1 vendors are the ones where a compromise would be material: they hold data, they have production access, or your business depends on their availability.

Build a continuous monitoring baseline for Tier 1. This doesn't require enterprise tooling. A security rating subscription, a credential monitoring service, and a calendar reminder to review changes quarterly cover the core of what you need.

Run questionnaires selectively. For Tier 1 vendors, a focused questionnaire on the specific risks relevant to their access level beats a 200-question document an intern will answer. Ask about MFA enforcement, incident response procedures, third-party audit availability, and subprocessor practices. That's the core.

Define what happens when a vendor fails, before you find one that has. Most programs can identify a risky vendor but never pre-decided what to do about it. Agree on your response tiers in advance: what triggers an urgent conversation, what triggers a remediation plan with a timeline, and what triggers offboarding consideration. Deciding this when you have time to think beats deciding it in the middle of a crisis.

The fourth-party problem

Your vendors have vendors. The organizations processing your data through a SaaS tool may themselves run on infrastructure you've never assessed. Fourth-party risk is real and documented: the 2013 Target breach came through an HVAC vendor's remote access credentials, and major cloud storage breaches have hit organizations whose only connection was a SaaS vendor using that storage.

You can't comprehensively assess every fourth party you depend on. You can require that your Tier 1 vendors disclose their own critical subprocessors and hold them contractually accountable for the security posture of those relationships.