Enterprise security programs have spent two decades hardening the perimeter, and the perimeter has spent those same two decades dissolving. The modern organization runs on a supply chain of software vendors, cloud platforms, managed service providers, payroll processors, marketing tools, and contractors with standing access to production systems.
Each of those relationships is a path into the environment. Most of them are governed by a questionnaire completed once, filed, and never revisited.
The mathematics of this are unforgiving. An organization with a mature internal security posture and 400 third-party relationships has 400 opportunities for someone else’s weaker posture to become its incident. Attackers understand this arithmetic considerably better than most procurement functions do.
Why the Supply Chain Became the Preferred Route
The logic from an attacker’s perspective is efficiency, not sophistication.
Compromising a hardened enterprise directly requires effort, patience, and often a novel exploit. Compromising a smaller software vendor that serves that enterprise, and hundreds of others, delivers access to many targets from a single operation. The economics favor the indirect route so heavily that it has become the default rather than the exception.
Three structural factors reinforce this:
Trust is architecturally embedded. Third-party software frequently runs with elevated privileges, integrates via API keys that never expire, or maintains persistent VPN access into internal networks. That access was granted deliberately and is rarely reviewed after the initial approval.
Security maturity is uneven by design. A 40-person SaaS vendor cannot maintain the security program of a global bank, and the bank knows this, and buys from them anyway because the product solves a real problem. That gap is a business reality, not a procurement failure. It just needs to be managed rather than ignored.
Fourth parties are invisible. Your vendor has vendors. Their subprocessors, hosting providers, and dependencies form an exposure surface most organizations have never enumerated and could not enumerate if asked.
What a Security Questionnaire Actually Catches
The standard control for third-party risk is a questionnaire sent during procurement. It is worth being honest about what that instrument does and does not do.
What It Genuinely Catches
Questionnaires are effective at establishing baseline hygiene and at separating vendors who have a security program from vendors who do not. A supplier who cannot describe their patching cadence, name a security owner, or produce evidence of any independent assessment has told you something useful.
They also create a documented record. When something goes wrong, the questions asked and the answers given matter for contractual and legal purposes, and having asked nothing is a meaningfully worse position than having asked and been misled.
What It Systematically Misses
The questionnaire is a snapshot of self-reported intent at a single moment. That produces four predictable gaps:
- It captures policy, not practice. A vendor can accurately state that they require MFA while a meaningful percentage of their accounts have it disabled. The document describes the policy. Nobody verified enforcement.
- It expires immediately. The answers are true on the day they are given. The vendor’s security posture six months later, after a layoff round eliminated their security engineer, is entirely undocumented.
- It stops at the first tier. The questionnaire asks about the vendor. It rarely asks meaningfully about the vendor’s own supply chain, which is where an increasing share of incidents originate.
- It is graded by whoever has capacity. In many organizations, completed questionnaires are reviewed by procurement staff without the security background to distinguish a strong answer from a plausible-sounding one.
None of this means questionnaires should be abandoned. It means they should be understood as a filter rather than an assurance mechanism, and paired with controls that operate continuously.
Contractual Controls That Actually Matter
Contract language is the leverage point most organizations underuse. A handful of clauses do more practical work than the rest of the agreement combined.
- Breach notification with a defined window. “Prompt” and “without undue delay” are unenforceable. A specific number of hours, with a defined trigger and a named contact, is enforceable. Many organizations discover their vendor’s breach through a news article because the contract permitted that outcome.
- Right to audit or right to evidence. A full audit right is often unrealistic for a small vendor and unnecessary for a low-criticality one. A right to receive current attestation reports, penetration test summaries, and remediation status on request accomplishes most of the same objective at a fraction of the friction.
- Subprocessor disclosure and change notification. If the vendor moves your data to a new hosting provider or adds an AI subprocessor, you need to know before it happens rather than during an incident review.
- Security requirements tied to data classification. A vendor handling anonymized marketing data and a vendor handling customer financial records should not sign identical security schedules. Tiering the requirements makes the strict ones defensible and the negotiations shorter.
- Termination rights on material security failure. The ability to exit without penalty when a vendor’s posture degrades materially changes the negotiation dynamic on everything else.
Evaluating What a Vendor Brings to the Table
The evaluation itself deserves more structure than most organizations give it.
Start by tiering. Not every vendor warrants the same scrutiny, and treating them identically guarantees that the critical ones receive inadequate attention while the trivial ones consume the budget. Tier on two axes: the sensitivity of data the vendor touches, and the operational impact if the vendor becomes unavailable. A vendor scoring high on either belongs in the deep-assessment population, which in most organizations is a small fraction of the total.
For that population, the assessment should reach past the questionnaire. Request the underlying evidence rather than the summary: the actual SOC 2 Type II report including the exceptions section, the penetration test with findings and remediation dates, the incident history and what changed afterward. Vendors who resist producing exceptions and findings are telling you something without meaning to.
External validation adds a dimension self-reporting cannot. Attack surface monitoring, certificate hygiene, exposed services, and breach corpus checks give an outside-in view that does not depend on the vendor’s candor. It is imperfect and occasionally noisy, but it is observed rather than claimed.
This is also where the evaluation should run in both directions. A vendor’s security capability is part of what you are purchasing, particularly when that vendor is an infrastructure, managed service, or integration partner whose own posture becomes an extension of yours. Partners who can articulate their approach to cybersecurity solutions as a discipline they practice internally rather than a checkbox they satisfy for procurement tend to be materially better partners, because the same rigor that governs their environment governs the work they do inside yours. Ask what their own detection and response capability looks like. Ask how they segment customer environments from each other and from their corporate network. Ask what happened the last time they had an incident.
The answers separate vendors who have thought about this from vendors who have not, faster than any questionnaire.
Moving From Annual Attestation to Continuous Monitoring
The structural weakness of third-party risk management is cadence. Assessing annually while threats operate continuously produces up to twelve months of undetected exposure per vendor.
Continuous monitoring closes that gap in three practical ways.
External posture monitoring watches for observable changes: newly exposed services, expiring certificates, credentials appearing in breach dumps, domain infrastructure changes. These signals are imperfect proxies for internal security health, but they surface degradation between assessment cycles and cost far less than a reassessment.
Event-triggered reassessment replaces the calendar with reality. A vendor acquisition, a public breach disclosure, a significant change in the services provided, or a leadership change in their security function should each trigger a review regardless of when the last one occurred. Calendar-driven assessment is convenient for the assessing team and irrelevant to the actual risk timeline.
Access review closes the loop internally. Third-party accounts, API keys, and integration credentials accumulate and rarely get removed when a relationship ends. A quarterly reconciliation of active third-party access against active third-party contracts routinely finds credentials belonging to vendors nobody has worked with in two years. Those are among the easiest wins available in the entire program.
Final Perspective
Third-party risk management fails in most organizations for a structural reason rather than a competence one. It sits between procurement, legal, and security, is owned fully by none of them, and gets measured on questionnaire completion rates rather than on exposure reduction.
The organizations that handle it well make three changes. They tier ruthlessly, so scrutiny concentrates where consequence lives. They write contracts that create leverage before it is needed rather than negotiating during an incident. And they replace the annual snapshot with signals that arrive when something changes.
None of that requires new technology. It requires accepting that a vendor’s security posture is not the vendor’s problem to manage alone. It is your exposure, sitting inside someone else’s environment, governed by someone else’s priorities.
