TL;DR: Supply chain breaches -- SolarWinds, MOVEit, Kaseya -- have proven that your vendors' security is your security. Yet most organizations still rely on security questionnaires and point-in-time certifications to evaluate vendor risk. Penetration testing provides actual evidence of vendor security posture. Automated testing makes it economically viable to test every critical vendor, not just the top three. Building pentesting into vendor onboarding and renewal transforms third-party risk management from a checkbox exercise into a genuine risk reduction program.
The supply chain has become the preferred attack vector for sophisticated threat actors. The logic is straightforward: why attack a hardened enterprise directly when you can compromise a trusted vendor and inherit their access? This is not a theoretical risk. The past several years have produced a drumbeat of supply chain breaches that have reshaped how organizations think about third-party risk.
The Supply Chain Attack Surface
The SolarWinds compromise in 2020 was the watershed moment. A nation-state actor inserted malicious code into the SolarWinds Orion software build process, distributing a backdoor to approximately 18,000 organizations -- including multiple U.S. federal agencies and Fortune 500 companies -- through a routine software update. The attack was sophisticated, patient, and devastating. It demonstrated that a single compromised vendor could provide access to thousands of downstream organizations simultaneously.
The lesson was clear, but the pattern continued. In 2021, the Kaseya VSA ransomware attack exploited vulnerabilities in a managed service provider platform to deploy REvil ransomware across approximately 1,500 downstream businesses in a single weekend. The MOVEit Transfer exploitation in 2023 compromised a widely used file transfer platform, exposing sensitive data from hundreds of organizations including government agencies, healthcare providers, and financial institutions. The Cl0p ransomware group exploited a single zero-day vulnerability in MOVEit and harvested data from organizations that had no direct relationship with the attackers -- their only mistake was trusting a vendor whose software had a critical flaw.
These are not outliers. Research from the Identity Theft Resource Center found that supply chain attacks increased by 78% from 2022 to 2024. Gartner estimates that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains. The attack surface is expanding because organizations are increasingly dependent on third-party software, cloud services, and integrated vendor ecosystems.
Why Questionnaires and Certifications Fall Short
Most third-party risk management programs rely on three primary tools: security questionnaires, compliance certifications (SOC 2, ISO 27001), and occasionally, vendor-provided pentest reports. Each of these has significant limitations that create a false sense of assurance.
Security questionnaires are self-reported. A vendor answers questions about their security practices, and the answers are taken at face value. There is rarely any verification that the stated controls actually exist or function as described. A vendor can claim they perform regular patching, enforce multi-factor authentication, and encrypt data at rest -- and these claims may be entirely accurate, partially true, or aspirational. Without validation, the questionnaire is a statement of intent, not evidence of security.
The questionnaire process also suffers from standardization problems. Different organizations use different questionnaires -- SIG, CAIQ, custom templates -- requiring vendors to answer hundreds of overlapping but slightly different questions across their customer base. Vendors develop standardized responses that are optimized for completeness and compliance language rather than accuracy. The result is a document that satisfies the process requirement but provides limited insight into actual security posture.
Compliance certifications are point-in-time. A SOC 2 Type II report covers a specific observation period, typically 6 to 12 months. It attests that the audited controls were operating effectively during that period. It says nothing about what happened after the observation period ended. An organization can pass a SOC 2 audit in June and suffer a breach in September because of a control that degraded or a new system that was not covered by the audit scope.
ISO 27001 certifications similarly reflect compliance at the time of the audit. Between audits, organizations may introduce new systems, change configurations, or experience staff turnover that affects security operations. The certificate on the wall does not update in real time.
Vendor-provided pentest reports are curated. When a vendor provides a penetration test report as part of a security review, they control what you see. The report may cover a limited scope that does not include the specific systems or integrations relevant to your relationship. Findings may be redacted or summarized in ways that minimize apparent risk. And the report represents the vendor's security posture at the time of the test -- which may have been months ago.
None of these tools answer the fundamental question a third-party risk manager needs to answer: is this vendor's security posture adequate to protect the data and access we are entrusting to them, right now?
Pentesting as Vendor Validation
Penetration testing provides what questionnaires and certifications cannot: empirical evidence of security posture based on actual testing of the vendor's systems.
There are several models for incorporating pentesting into vendor risk management, depending on the relationship structure and the level of access involved.
Testing vendor-provided applications and integrations. For vendors who provide software that runs in your environment -- SaaS applications, APIs, embedded components -- you can test the vendor's product as it operates within your infrastructure. This includes testing authentication and authorization controls, API security, data handling practices, and the security of the integration points between the vendor's system and your own. This testing does not require the vendor's permission to test their infrastructure; you are testing your own environment, which happens to include the vendor's product.
Contractual penetration testing rights. For critical vendors, the most effective approach is to negotiate penetration testing rights into the contract. This gives you the ability to conduct or commission testing of the vendor's systems -- or specific components relevant to your data -- on a regular basis. Many enterprise contracts now include language specifying annual or semi-annual penetration testing rights, with findings shared between both parties and remediation timelines agreed upon in advance.
Collaborative testing programs. Some mature vendor relationships support a collaborative approach where both parties agree on testing scope, share findings, and jointly prioritize remediation. This model works well when the vendor relationship is strategic and long-term, and when both parties have a vested interest in demonstrating security to mutual customers or regulators.
Third-party risk testing services. For organizations with large vendor portfolios, specialized third-party risk testing services can conduct standardized penetration testing across multiple vendors on your behalf. This provides consistent methodology and comparable results across the vendor portfolio, making it easier to identify which vendors represent the greatest risk.
"A SOC 2 report tells you a vendor had adequate controls during the audit period. A pentest tells you whether those controls actually stop an attacker today."
The Economics of Per-Vendor Testing
The traditional objection to pentesting as a vendor validation tool is cost. A manual penetration test costs $10,000 to $30,000 or more depending on scope. An organization with 50 critical vendors cannot afford to commission $500,000 to $1.5 million in annual pentesting for vendor validation alone. The math simply does not work.
Automated penetration testing changes this equation fundamentally.
An automated platform can conduct a comprehensive assessment of a vendor's external attack surface -- or of a vendor application running in your environment -- at a fraction of the manual cost. Where a manual test might cost $15,000 per vendor, an automated assessment might cost $500 to $2,000. At that price point, testing 50 vendors annually costs $25,000 to $100,000 -- a realistic budget line item for any enterprise third-party risk management program.
The cost reduction also enables frequency improvements. Instead of testing each critical vendor once a year, automated platforms make quarterly or even monthly testing feasible. This addresses the point-in-time limitation that plagues both certifications and manual pentests. A vendor's security posture is validated not just annually, but continuously.
For MSSPs managing vendor risk programs on behalf of their clients, automated pentesting creates a scalable service offering. The MSSP can test dozens of vendors across multiple client engagements using the same platform, amortizing costs and delivering per-vendor validation that would be impossible with manual testing alone.
Building Pentesting Into the Vendor Lifecycle
The most effective approach integrates penetration testing into every phase of the vendor relationship, not just the initial evaluation.
Vendor selection and onboarding. During the procurement process, include a penetration test of the vendor's application or external attack surface as part of the security evaluation. This provides objective, empirical data to supplement the questionnaire and certification review. If the pentest reveals significant vulnerabilities, you have leverage to require remediation before contract execution -- or to select a more secure alternative.
Ongoing monitoring. After onboarding, conduct regular penetration testing on a cadence aligned with the vendor's risk tier. Critical vendors (those with access to sensitive data or integration with core systems) should be tested quarterly. Important vendors should be tested semi-annually. Standard vendors should be tested annually at minimum. This ongoing testing catches security degradation that occurs between certification audits.
Contract renewal. At renewal time, the cumulative pentesting data provides an objective record of the vendor's security trajectory. Is the vendor improving, stable, or degrading? Are findings being remediated promptly, or do the same issues recur? This data transforms the renewal conversation from a subjective relationship assessment into an evidence-based risk decision.
Incident response. When a vendor suffers a breach or a new vulnerability is disclosed in a vendor's product, the ability to immediately run a penetration test against the vendor's integration with your environment provides rapid, actionable intelligence. Instead of waiting for the vendor to disclose the impact and provide remediation guidance, you can assess your own exposure within hours.
Regulatory and Insurance Drivers
Third-party risk management is no longer just a best practice -- it is a regulatory requirement across multiple frameworks.
NYDFS 23 NYCRR 500 (Section 500.11) requires covered entities to implement policies governing the security of third-party service providers, including risk assessments and minimum cybersecurity practices. OCC Bulletin 2013-29 requires national banks and federal savings associations to manage risks associated with third-party relationships, including conducting due diligence that evaluates the third party's security controls.
GDPR Articles 28 and 32 require data controllers to ensure that their processors implement appropriate technical measures -- and to verify compliance. The European Data Protection Board has clarified that verification should include objective testing, not just contractual assurances.
Cyber insurance providers are increasingly scrutinizing third-party risk management practices during underwriting. Insurers recognize that supply chain attacks represent a systemic risk that can affect multiple policyholders simultaneously. Organizations that can demonstrate active vendor security validation through penetration testing are viewed more favorably than those relying solely on questionnaire-based programs.
From Checkbox to Risk Reduction
The third-party risk management program that most organizations operate today is fundamentally a compliance exercise. Questionnaires are collected, certifications are filed, and a risk rating is assigned. The process satisfies audit requirements but provides limited assurance about actual vendor security.
Adding penetration testing transforms this program from a checkbox exercise into a genuine risk management function. It provides empirical evidence. It identifies specific, exploitable vulnerabilities. It creates accountability by documenting findings and tracking remediation. And it scales through automation to cover the full vendor portfolio, not just the handful of vendors whose risk is obvious enough to justify the cost of manual testing.
The vendors that fail a pentest are not necessarily bad vendors. They are vendors with specific, identifiable security weaknesses that can be remediated. The pentest creates a constructive conversation: here is what we found, here is the risk it presents, and here is the timeline for fixing it. This is a far more productive vendor relationship than one built on unverified questionnaire answers and annual certification renewals.
The organizations that have already experienced a supply chain breach understand this intuitively. For everyone else, the question is whether to learn from others' experience or wait for their own.