Third-Party Risk Assessment: How Penetration Testing Fits In

Every organisation exists in two simultaneous relationships with third-party risk assessment. As a buyer, you assess the security posture of the vendors, SaaS providers, and technology partners you depend on. As a vendor, your customers assess your security posture before signing contracts and at regular intervals during the relationship.

Penetration testing sits at the intersection of both roles. As a buyer, you need to know whether to accept a vendor's pentest report as evidence, conduct your own assessment of the vendor's systems, or require specific testing as a contractual condition. As a vendor, you need to produce pentest evidence that satisfies your customers' security review requirements and the compliance frameworks that drive those requirements.

This guide covers how penetration testing fits into the third-party risk assessment process from both sides of the relationship, what vendor pentest evidence actually demonstrates, what it does not demonstrate, and how to evaluate a pentest report received from a vendor.

What third-party risk assessment is trying to measure

Third-party risk assessment asks: does this vendor's security posture create risk for our organisation that we need to manage?

The risk channels are specific. A vendor with access to your customer data could expose that data through a breach of their systems. A SaaS platform you depend on could be unavailable due to a cyberattack, disrupting your operations. A software supply chain vendor could distribute malicious code through a legitimate software update. A vendor with privileged access to your internal network could be the initial access vector for a targeted attack on your organisation.

Most TPRM programmes assess these risks through questionnaires (the vendor self-reports their security controls), evidence review (the vendor provides documentation of their controls), and ratings services (continuous external scanning of the vendor's attack surface). Penetration testing is the evidence type that shifts from self-reported controls to independently verified security.

The TPRM evidence hierarchy

Understanding where penetration testing sits in the evidence hierarchy explains when it is necessary and when other evidence types are sufficient.

Questionnaires are the lowest-confidence evidence type. The vendor answers questions about their security programme. The answers are unverified. A questionnaire that asks "do you conduct annual penetration testing?" can be answered yes by a vendor who has conducted one low-quality automated scan. Questionnaires are useful for understanding the vendor's security programme structure and identifying obvious gaps but do not verify that controls actually work.

Compliance certifications (SOC 2, ISO 27001, PCI DSS QSA assessments) are third-party verified but not penetration testing. A SOC 2 Type II report confirms that the vendor had specific security controls in place and operating over the audit period. It does not confirm that those controls would withstand an attacker's attempts to bypass them. SOC 2 penetration testing: what auditors actually require covers the relationship between SOC 2 reports and penetration testing: they address different questions and neither substitutes for the other.

Penetration test reports provide independently verified evidence that specific attack surfaces were tested by skilled testers attempting active exploitation. This is the highest-confidence evidence that the vendor's security controls resist real attack techniques, within the scope that was tested.

Your own security assessment of the vendor's systems is the highest-confidence evidence type available to you: testing you controlled, scoped to the vendor surfaces that matter to your organisation. This is rarely feasible for all vendors but appropriate for the highest-criticality relationships.

When to require vendor pentest evidence vs conduct your own assessment

The appropriate evidence tier depends on two factors: the criticality of the vendor relationship (what access do they have to your systems and data?) and the maturity of the vendor (do they have a security programme that produces credible evidence?).

Require questionnaire plus compliance certification for low-criticality vendors with no access to sensitive data or your internal systems. SaaS tools used for non-sensitive business functions, marketing platforms, scheduling tools.

Require questionnaire, compliance certification, and recent pentest report for vendors with access to sensitive data, vendors with API integrations into your core systems, and vendors with privileged access (administrative accounts, VPN access, access to production environments). This is the appropriate tier for most enterprise software vendors, cloud service providers, and data processors under GDPR or equivalent frameworks.

Require questionnaire, compliance certification, pentest report, and conduct your own assessment for the highest-criticality vendors: vendors with administrative access to production systems, vendors who process your most sensitive data categories, vendors who are part of your software supply chain and whose compromise could affect your customers. For these relationships, accepting the vendor's own pentest report as the only active testing evidence leaves your exposure determination in the vendor's hands.

Conduct a direct technical assessment for critical infrastructure vendors, managed security service providers, and any vendor where a breach would be catastrophic to your organisation. This means you scope and commission the testing, either with an independent firm you select and instruct, or with an agentic continuous testing capability that maintains ongoing coverage of the vendor's relevant attack surfaces.

How to evaluate a vendor's penetration test report

Most security teams receive vendor pentest reports and do not have a structured framework for evaluating them. The result is that a thick PDF gets checked off without meaningful security assurance. What is inside a VAPT report and what's in a penetration testing report: a buyer's breakdown cover what a quality report contains. For TPRM purposes, the evaluation focuses on different questions.

Does the scope match what matters to you?

The most critical TPRM evaluation: does the penetration test scope cover the systems, APIs, and surfaces that your organisation interacts with? A vendor who has conducted a thorough penetration test of their internal HR system and admin portal has produced evidence with limited value if what matters to you is the security of their customer-facing API that processes your data. Ask the vendor to confirm that the scope covers the specific surfaces relevant to your integration.

Is the testing date within an acceptable window?

Penetration test evidence ages. A report from two years ago predates significant infrastructure changes that may have introduced new vulnerabilities. Most TPRM programmes accept penetration testing evidence from within the last twelve months. For high-criticality vendors, six months is a more appropriate threshold. Ask when the most recent test was conducted and what significant infrastructure changes have occurred since.

Who conducted the test?

A vendor who conducts their own penetration testing produces lower-confidence evidence than one tested by an independent third party. Internal teams have insufficient adversarial independence from the systems they test. Ask whether the testing was conducted by an independent third-party firm and request the firm's name and any relevant qualifications (CREST accreditation, OSCP certifications for testers).

What did they find and what did they fix?

The finding distribution tells you something about testing depth. A penetration test with zero findings across a complex application surface is either evidence of excellent security or evidence of insufficient testing depth. For complex vendors, expect some findings. Ask for a summary of critical and high findings and their remediation status. Many vendors will not share the full report due to security sensitivity, but a one-page summary covering finding counts by severity, critical/high finding descriptions, and remediation status is a reasonable request.

Does the test confirm exploitability or only identify potential vulnerabilities?

Some reports list findings from automated scanners as penetration testing output. Ask whether the report contains proof-of-exploitation evidence for significant findings. A report that notes "SQL injection potential identified in login form" is scanner output. A report that documents "SQL injection confirmed in login form, demonstrating ability to extract the user credential table as shown in Appendix B" is penetration testing output. The distinction matters for your confidence that the vendor's controls resist real attacks, not just automated signature matching.

What SOC 2 reports do and do not replace

SOC 2 is the most common third-party security evidence type in enterprise software procurement. Understanding precisely what SOC 2 evidence answers and what it does not changes how you use it in TPRM.

What SOC 2 Type II reports confirm:

That specific controls described in the System Description were operating over the twelve-month audit period. That an independent CPA reviewed the vendor's claims about those controls and attested that the controls were in place and functioning. That the vendor's security programme has a minimum level of structure and maturity that satisfies the auditor's standard.

What SOC 2 Type II reports do not confirm:

Whether those controls would resist an attacker actively attempting to bypass them. Whether the specific controls address the risk channels relevant to your use case. Whether the penetration testing the vendor conducts produces meaningful security assurance or checkbox compliance. The SOC 2 audit verifies that penetration testing was conducted and that findings were remediated; it does not independently evaluate whether the testing was thorough.

For high-criticality vendor relationships, SOC 2 Type II plus a pentest report that you have evaluated for scope, date, independence, and finding quality is the appropriate evidence package. For critical vendors, your own assessment is the gold standard.

The vendor side: producing pentest evidence that satisfies customer requirements

If your organisation sells to enterprise customers, you are on the other side of this relationship. Your customers' TPRM programmes will ask for pentest evidence, and the quality of that evidence affects procurement outcomes.

The key insight: enterprise procurement teams have become more sophisticated about evaluating pentest evidence. A PDF generated from an automated scanner is no longer an acceptable response to "do you conduct annual penetration testing?" Enterprise security reviewers ask the scope questions, the independence questions, and the finding quality questions described above.

Producing pentest evidence that satisfies sophisticated buyers requires: testing by an independent third party (not internal teams), a scope that covers the surfaces your customers care about (typically the API layer and application infrastructure handling customer data), a report with proof-of-exploitation evidence for significant findings, and evidence that critical and high findings were remediated with retest confirmation.

Continuous penetration testing and how it differs from annual pentests covers why deployment-triggered continuous testing produces a more compelling evidence package than annual point-in-time testing. A vendor who can show continuous testing evidence with findings and remediation tracked across every deployment cycle answers the enterprise procurement question with a qualitatively different response than a vendor sharing a single annual report. Agentic pentesting and continuous security validation covers the continuous testing model that produces this evidence as an operational output.

TPRM frameworks and contractual requirements

Several compliance frameworks impose specific penetration testing requirements for vendor relationships.

GDPR/UK GDPR Article 28 requires data controllers to use only processors who can demonstrate sufficient guarantees of appropriate technical security measures. In practice, this creates a procurement obligation to verify vendor security through evidence review, which increasingly means requiring penetration test reports alongside SOC 2 or ISO 27001 certifications.

ISO 27001 Annex A 5.19 (Information security in supplier relationships) and Annex A 5.20 (Addressing information security within supplier agreements) require documented processes for managing supplier information security. ISO 27001 penetration testing: what auditors look for covers the full ISO 27001 testing requirements that inform what evidence to request from ISO 27001-certified vendors.

PCI DSS Requirement 12.8 requires organisations to manage the security of service providers with access to the cardholder data environment, including maintaining a list of providers, written agreements, and monitoring of provider compliance status.

FFIEC and Federal Reserve guidance for financial services organisations require thorough vendor due diligence for technology service providers, including security assessment.

Practical TPRM programme design for penetration testing

A practical approach to integrating penetration testing into TPRM:

Tier your vendors by criticality. Not all vendors require the same evidence depth. A vendor with access to production customer data and an API integration into your core systems warrants different treatment than a vendor providing office supplies. Tiering focuses your TPRM effort where the risk is greatest.

Define minimum evidence standards by tier. For Tier 1 (highest criticality): independent third-party penetration test within the last six months, covering the specific surfaces relevant to your integration, with summary finding and remediation status available on request. For Tier 2: penetration test within the last twelve months plus compliance certification. For Tier 3: compliance certification or questionnaire.

Include penetration testing requirements in contracts. The most reliable way to ensure vendors maintain security testing is to include specific requirements in contracts: annual independent penetration testing of systems handling your data, notification of critical findings within 72 hours, and remediation of critical findings within 30 days. These contractual provisions give you enforcement mechanism beyond vendor goodwill.

Define the evidence review process. Assign specific reviewers with security expertise to evaluate received pentest evidence. Build the evaluation framework from the questions above: scope coverage, testing date, tester independence, finding distribution, and exploitation confirmation. A checklist that security reviewers apply consistently prevents the scenario where pentest evidence is received and filed without meaningful evaluation.

For penetration testing services in the US and VAPT services producing pentest evidence that satisfies enterprise customer TPRM requirements, or PTaaS for continuous testing evidence that enterprise procurement teams find compelling, the 10x Pentest platform covers both the evidence production and evaluation sides. See pricing or get in touch to discuss structuring a testing programme that satisfies your customers' TPRM requirements while also informing your vendor assessment process. For evaluation of vendor security scanning and testing services, 8 questions to ask before buying vulnerability scanning services covers the vendor assessment criteria that apply to security tool procurement specifically.

Frequently asked questions

Q1. What is third-party risk assessment in cybersecurity?

Third-party risk assessment is the process of evaluating the security posture of vendors, suppliers, SaaS providers, and technology partners to determine what risk they introduce to your organisation. The assessment examines whether the third party has adequate security controls for the access and data they handle on your behalf. It typically combines questionnaire self-assessment, review of compliance certifications such as SOC 2 and ISO 27001, and increasingly, review of penetration testing evidence that confirms controls resist active exploitation attempts.

Q2. How does penetration testing fit into third-party risk assessment?

Penetration testing is the highest-confidence evidence type in the TPRM evidence hierarchy because it involves independently verified testing of controls against real attack techniques, rather than self-reported questionnaire answers or auditor attestations that controls exist. In TPRM, penetration testing operates in two ways: as evidence you require from high-criticality vendors to verify their security controls, and as evidence you produce for your own customers' TPRM requirements. The question of when to accept a vendor's pentest report versus conduct your own independent assessment depends on the criticality of the vendor relationship and the maturity of their security programme.

Q3. Does a SOC 2 report replace penetration testing in vendor due diligence?

No. A SOC 2 Type II report confirms that specific controls were operating over the audit period, as verified by an independent CPA. It does not confirm that those controls would withstand an active attacker attempting to bypass them. SOC 2 auditors verify that penetration testing was conducted and that findings were remediated; they do not independently evaluate testing quality. For high-criticality vendor relationships, SOC 2 Type II evidence plus a penetration test report evaluated for scope, tester independence, and finding quality is the appropriate evidence package.

Q4. How do you evaluate a vendor's penetration test report?

Evaluate vendor pentest evidence against five criteria: scope coverage (does the test cover the specific systems and APIs relevant to your integration?), testing date (was it conducted within an acceptable window, typically twelve months for standard relationships and six months for critical ones?), tester independence (was testing conducted by an independent third party, not the vendor's internal team?), finding distribution (is the finding count and severity distribution consistent with thorough testing of a system of this complexity?), and exploitation confirmation (does the report contain proof-of-exploitation evidence for significant findings, or only potential vulnerability identifications from automated scanning?).

Q5. What penetration testing should vendors conduct to satisfy enterprise customer requirements?

Enterprise procurement teams increasingly expect vendors to demonstrate: annual penetration testing by an independent third-party firm (not internal teams), a scope covering the specific application and API surfaces handling customer data, a report with proof-of-exploitation evidence for significant findings rather than scanner output, and evidence that critical and high findings were remediated with retest confirmation. Continuous penetration testing that covers every significant deployment produces a more compelling evidence package than annual point-in-time testing because it demonstrates ongoing security validation rather than a single annual snapshot.