What is third-party penetration testing?

Third-party penetration testing most often means a penetration test of your own systems performed by a qualified firm that is organisationally independent of the teams that build and run them, which is what PCI DSS, FedRAMP, NYDFS and SOC 2 auditors expect. It also refers to testing, or obtaining test evidence for, the vendors and service providers your organisation depends on.

Does PCI DSS require the penetration test to be done by a third party?

Not strictly. PCI DSS v4.0.1 Requirements 11.4.2 and 11.4.3 allow a qualified internal resource or a qualified external third party, but require organisational independence of the tester. In practice most organisations use an external firm because demonstrating the independence of an internal tester to a QSA is harder than commissioning the test.

Can I penetration test my SaaS vendor?

Usually not the platform itself: terms of service prohibit testing shared, multi-tenant infrastructure, and doing so would touch other customers' data. You can test your own tenant configuration, identity integration, the APIs and custom code you built against the platform, and dedicated environments operated for you, with written authorisation. For the platform, request the vendor's independent test attestation and summary report.

What is a penetration testing attestation letter?

An attestation letter is a short document from the testing firm confirming who tested what, when, by which methodology and with what result, summarised by severity without technical detail. Vendors share it with customers in place of the full report, and auditors accept it as evidence that an independent test took place.

Is a bug bounty programme a third-party penetration test?

No. A bug bounty brings external researchers, but it has no scope statement, no guaranteed coverage, no methodology and no attestation, so it does not satisfy PCI DSS, FedRAMP, NYDFS or customer due-diligence requirements on its own. It is a useful supplement after an independent, scoped test has cleared the basics.

How often should vendors provide penetration test evidence?

At least annually and after major changes to the service you consume, which matches the cadence PCI DSS, NYDFS and the GLBA Safeguards Rule set for the vendors' own obligations. Write that cadence into the contract, together with the right to receive the summary report and attestation letter.

Does my vendor's audit report replace a penetration test?

No. A SOC 2 or ISO 27001 report is an auditor's opinion on controls over a period; the penetration test is one piece of evidence behind one or two of those controls. Read the SOC 2 for scope and carve-outs, then ask for the penetration test attestation that covers the system the report describes.

2 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

Third-party penetration testing: why independence matters for your own systems, and how to test the vendors you depend on

Third-party penetration testing is used for two different things. The first is having an independent firm test your systems, which is what auditors, regulators and enterprise customers mean when they ask whether your test was performed by a third party. The second is testing, or obtaining testing evidence for, the vendors and service providers your business depends on. This guide covers both: which frameworks require independence and in what words, how internal, third-party and crowdsourced testing compare, what you can and cannot test on a vendor, what a penetration testing attestation letter should contain, and how to read a vendor's summary report.

Scope an independent penetration test

What third-party penetration testing means

In the first and most common sense, a third-party penetration test is a penetration test of your own systems performed by a qualified firm that is organisationally independent of the people who build and run those systems. The point is not that outsiders are smarter. It is that the party judging the security of a system should not report to the party responsible for it, should not have designed its controls, and should have no incentive to under-report. That principle is written into PCI DSS, FedRAMP, NYDFS Part 500 and the audit practice around SOC 2 and ISO 27001, and it is what a customer's security questionnaire is probing when it asks for your latest third-party penetration test.

In the second sense, the third party is the vendor. Every organisation now runs on software it did not write and infrastructure it does not operate: SaaS platforms, payment processors, managed service providers, cloud hosting, identity providers, outsourced development. A weakness in any of them is a weakness in your environment, and the supply-chain campaigns of recent years against managed file-transfer software, SaaS integrations and service providers have made regulators and boards treat vendor security as a first-order risk. Third-party penetration testing in this sense means establishing, through your own testing where allowed and through evidence where not, that the vendors behind your critical processes are tested to a standard you would accept for yourself.

The two meanings meet in the middle. The attestation letter your vendor sends you is the output of their third-party test in the first sense. The attestation letter you send your customers is the same document from the other side. Organisations that understand both sides buy better tests, write better contracts and answer due-diligence questions faster.

Meaning one: why auditors and customers require an independent tester

Few frameworks use the words third party. Most use independence, qualified external resource or accredited assessor. This is where the requirement actually sits.

PCI DSS v4.0.1, Requirement 11.4

Internal and external penetration testing at least once every 12 months and after significant changes (11.4.2 and 11.4.3), performed by a qualified internal resource or a qualified external third party, with organisational independence of the tester explicitly required. The tester does not need to be a QSA or ASV. 11.4.1 requires a documented methodology; 11.4.4 requires remediation and retest.

AICPA Trust Services Criteria (service organisation reports)

SOC 2 does not mandate a penetration test, but CC4.1 (ongoing and separate evaluations) and CC7.1 (detection of vulnerabilities) are almost always evidenced with one, and the auditor assesses whether the evaluation was objective. An independent test with a named firm, scope and dates is the evidence that passes without discussion; a self-test by the engineering team invites exceptions.

ISO/IEC 27001:2022

Annex A control 8.8 (management of technical vulnerabilities) expects testing evidence; control 5.35 requires independent review of the information security approach; controls 5.19 to 5.22 govern supplier relationships, supplier agreements, the ICT supply chain and monitoring of supplier services. Certification auditors expect the tester to be independent of the ISMS owner.

HIPAA Security Rule

45 CFR 164.308(a)(8) requires periodic technical and non-technical evaluation; 164.308(b) and 164.314(a) require business associate agreements that bind vendors to the same safeguards. The Security Rule update proposed in January 2025 would make annual penetration testing by a qualified person explicit; until finalised, OCR guidance and enforcement already treat independent testing as the expected evaluation method.

FedRAMP and CMMC 2.0

FedRAMP requires penetration testing by an accredited Third Party Assessment Organization (3PAO) under control CA-8 and the FedRAMP Penetration Test Guidance, at authorisation and annually. CMMC 2.0 Level 2 requires assessment by a certified C3PAO for most defence contractors. In both programmes independence is not a preference; it is the structure of the programme.

NYDFS 23 NYCRR 500.5 and the GLBA Safeguards Rule

NYDFS 500.5(a)(1) requires annual penetration testing of information systems by a qualified internal or external party; 500.11 requires a third-party service provider policy. The FTC Safeguards Rule, 16 CFR 314.4(d)(2), requires annual penetration testing and six-monthly vulnerability assessments, and 314.4(f) requires oversight of service providers.

DORA and NIS2 (EU)

DORA Article 24 requires tests to be performed by independent internal or external testers; for threat-led penetration testing (Articles 26 and 27) the threat-intelligence provider must always be external. Articles 28 to 30 govern ICT third-party risk, including contractual rights to access, inspect and audit providers. NIS2 Article 21(2)(d) makes supply-chain security a mandatory measure and 21(2)(f) requires testing and auditing of the measures.

Internal team vs third-party firm vs crowdsourced testing

Each model has a place. Only one of them satisfies an independence requirement on its own.

Aspect	Internal security team	Third-party firm	Crowdsourced / bug bounty
Independence	Low: reports into the same organisation; may have built the controls	High: organisationally separate, contractually bound, named testers	Medium: researchers are external, but coverage and method are not controlled
Accepted as evidence by	Internal audit; rarely by PCI, FedRAMP, NYDFS or enterprise customers on its own	PCI DSS, SOC 2, ISO 27001, HIPAA, NYDFS, GLBA, DORA, customer due diligence	Useful supplement; not a substitute for a scoped test in any framework
Coverage	Deep system knowledge, continuous; blind spots where the team designed the system	Scoped and complete against a stated methodology; fresh eyes	Unpredictable; concentrates on what pays, skips authenticated and internal scope
Confidentiality	Highest	Contractual: NDA, data handling, named individuals	Lowest: many unknown participants
Deliverable	Tickets and internal reports	Report with scope, methodology, evidence, remediation, retest and attestation letter	Individual reports per finding; no scope statement
Cost logic	Fixed headcount; lowest cost per test once staffed, expensive to build	Priced per engagement on scope and depth	Pay per valid finding plus platform fee; unbounded
Best for	Continuous testing between external engagements, regression of fixed findings	Annual and change-driven testing, compliance evidence, customer attestations	Public-facing applications after an independent test has cleared the basics

Meaning two: testing the third parties you depend on

A vendor risk programme sorts suppliers by the data they hold and the processes they support, then decides what evidence each tier owes you. For critical vendors, that evidence should include penetration testing: either your own test of the parts you are allowed to test, or their independent test report and attestation letter, or both. Questionnaires alone do not establish that a control works; a test does. The practical sequence is to classify the vendor, read their SOC 2 or ISO 27001 scope to see what their auditor actually covered, request the penetration test attestation and summary report for the service you consume, and then test your side of the integration yourself.

What you can test is governed by the vendor's terms and by the shared-responsibility model. On a multi-tenant SaaS platform you generally cannot test the platform itself: the terms of service prohibit it, and an unauthorised test against shared infrastructure is unauthorised access to other customers' data. You can test your tenant configuration, your single sign-on and identity integration, the APIs and webhooks you built against the platform, any custom code you deployed into it, and the data flows between the vendor and your own systems. Managed service providers, outsourced developers and hosting partners that operate dedicated environments for you can usually be tested under a written authorisation that names them as a party.

Cloud hosting is the special case, and the phrase third-party penetration test is sometimes used for it. Most major cloud providers publish customer penetration-testing policies that permit testing of your own hosted resources without prior notice for common services, while prohibiting tests against the provider's shared infrastructure and any denial-of-service testing. The provider secures the underlying platform; you remain responsible for identity, configuration, network exposure and workloads, which is the scope of a cloud penetration test (linked below).

Where you cannot test, the contract has to do the work. A right-to-audit clause should say what you may audit (controls, evidence, test reports), how often, at whose cost, and what happens when a critical finding is open. It should distinguish an audit from a test, grant the right to receive the vendor's penetration test summary and attestation at least annually and after major changes, set remediation timelines for findings that affect your service, and allow you to commission a test of dedicated components with notice. DORA Article 30 makes several of these provisions mandatory for financial entities' critical ICT providers; for everyone else they are negotiable, and they are easier to negotiate before signature than after an incident.

What a penetration testing attestation letter should contain

An attestation letter is the one-to-two-page document a vendor shares in place of a full report. Whether you are writing one or reading one, it should cover these points.

Identity of the testing firm, the named lead tester and their certifications, and a statement of the firm's independence from the organisation tested
Dates of testing and the date of the letter, with the validity period the firm is prepared to stand behind
Scope in concrete terms: the applications, URLs, IP ranges, environments (production or staging) and versions tested, and what was explicitly excluded
Test type and depth: external, internal, web application, API, cloud configuration; black, grey or white box; authenticated roles covered
Methodology referenced by name (PTES, OWASP WSTG or MASTG, NIST SP 800-115) with confirmation that manual testing was performed
Findings summarised by severity count, using a stated severity model such as CVSS, without technical detail that would expose the vendor
Remediation status at the time of the letter and the date and result of the retest
Limitations: testing windows, rate limits, components out of scope, anything that reduced coverage
A contact at the testing firm who will confirm the letter's authenticity on request

How to read a vendor's penetration test summary

Most vendor summaries are written to reassure. Read them for what they prove about the service you actually buy.

1. Does the scope match the service you consume?

A test of the marketing website or a single product line says nothing about the API your integration uses. Compare the scope statement to your architecture diagram, and ask for the test that covers your components if it is not there.

2. How recent, and how often?

A test older than twelve months, or one that predates a major release, is history rather than evidence. Ask for the testing cadence and for change-driven tests, and check it against the release notes.

3. Who tested, and were they independent?

Look for a named external firm, named and certified testers, and a statement of independence. An unnamed team or an automated scanning service presented as a penetration test is the most common weakness in vendor evidence.

4. What was the severity distribution and what is still open?

Zero findings in a mature product is a scope or depth problem, not a security achievement. Ask for the counts by severity, the remediation dates and the retest result, and for how long critical findings stayed open.

5. Which environment, and at what depth?

A black-box test of a staging environment is not evidence about production authorisation controls. Grey-box testing with authenticated roles on production or a production-identical environment is the standard a critical vendor should meet.

6. How does it line up with their audit report?

Read the SOC 2 system description, the subservice organisations carved out, and the complementary user entity controls you are expected to operate. The penetration test should cover the system the SOC 2 describes, and a bridge letter should cover the gap since the report period ended.

How HackersHub fits both sides

For organisations that need an independent test of their own systems, HackersHub is the third party: an Amsterdam-based offensive-security firm with 10+ years of experience, testers who all hold at least OSCP with OSWE and CREST-certified testers on the team, a documented methodology aligned with PTES, OWASP WSTG and MASTG and NIST SP 800-115, and reports built for the people who will read them: an executive summary, CVSS-scored findings with evidence, an attack narrative and prioritised remediation. A verification retest of medium-and-higher findings within 90 days is included, and we issue an attestation letter you can hand to auditors and customers. Delivery is remote from Amsterdam, Netherlands, with on-site work where an engagement needs it.

For organisations that need assurance about their vendors, we test the components you are authorised to test (tenant configuration, identity integration, APIs, dedicated environments operated for you), review the penetration test evidence your critical vendors provide and tell you what it does and does not prove, and help you write the testing and right-to-audit language into contracts before they are signed. Choosing the firm for either side is a separate question, covered in our guide to selecting a penetration testing company, which you should read alongside this one.

Frequently asked questions

Need an independent test, or assurance about a vendor?

We test your systems as the independent third party your auditors and customers expect, test the vendor components you are authorised to test, and tell you what a vendor's evidence actually proves. Talk to an expert.

Scope an independent penetration test Talk to an expert