What Are Third Party Penetration Testing Requirements, and How Do You Set Them?

When a business asks us to test its network, one of the first questions worth asking back is: what about everyone else with access to it? Third party penetration testing requirements are the standards you set for suppliers and vendors. They cover how often suppliers get tested, by whom, and what proof they hand over. Without them, your own security testing only covers part of the picture.

Every business now runs on a chain of suppliers. Think hosting, payroll, IT support with remote access, and the CRM holding your customer records. Each one is effectively an extension of your own attack surface. Test your own systems all you like. If the supplier holding your customer database has never been tested, that gap is still yours to answer for.

Why this keeps getting overlooked

It is not that businesses do not care. Supplier security usually gets handled once, at onboarding, through a questionnaire nobody revisits. The National Cyber Security Centre has pointed out the scale of the problem directly. Its supply chain security guidance states that “very few UK businesses set minimum security standards for their suppliers.” Attackers notice that gap. They often find it easier to compromise a smaller, less scrutinised supplier than to breach a well-defended target directly.

Setting a clear requirement turns a one-off form into an ongoing check. It gives you something concrete to point to when a supplier’s security comes into question. That beats a vague memory of what they said in a sales call two years ago.

What good third party penetration testing requirements ask for

A requirement only works if it is specific enough to verify. Vague wording like “adequate security measures” lets a supplier tick a box without changing anything. Instead, spell out:

• The scope: matched to what the supplier actually does for you, not a generic test that never touches your data.
• How often it repeats. Annually is the usual floor for anything with meaningful access, with a retest after major changes.
• Who does the testing. It should be an independent third party, not an internal team marking its own homework.
• What evidence you get to see, whether that is a full report, a summary, or a signed attestation.
• What happens to findings. A commitment to fix issues within a set window, with confirmation once they are resolved.

Most established suppliers already test regularly and will happily share evidence once you ask properly. The ones who get evasive when you ask a specific question are the ones worth worrying about.

Not every supplier deserves the same scrutiny

Applying one standard to every vendor wastes effort on low-risk relationships. Worse, it can dilute attention away from the ones that matter. Sort suppliers into rough tiers first:

• Critical suppliers hold sensitive data, payment systems or core infrastructure access. These warrant annual independent testing and a detailed report or summary.
• High-risk suppliers have real but narrower access. Annual testing with a summary and remediation confirmation is usually proportionate.
• Standard suppliers have limited or indirect access. A current Cyber Essentials certificate, checked periodically, is often sufficient here.

This mirrors how the NCSC frames supply chain oversight more broadly. It is a cycle: understand the risk a supplier poses, and establish control through contracts. Then check that the control is actually being exercised, and revisit it as the relationship changes. A tiered testing requirement is a concrete way to handle the “establish” and “check” stages, rather than leaving them as good intentions.

Get it into the contract, not just the checklist

A requirement that lives in a spreadsheet nobody reopens is not a requirement, it is a memory. Under UK GDPR, this has legal teeth too. The ICO’s guidance on controller-processor contracts confirms that Article 28 requires a written contract wherever a processor handles personal data. That contract must reflect the security duties in Article 32, which calls for measures appropriate to the risk involved. Before signing, the ICO says controllers should weigh up the processor’s technical expertise, its documented security policy, and any relevant certification it holds.

ISO 27001 backs this up from the other direction. Annex A control 5.21 asks organisations to agree, document and maintain information security expectations with their suppliers. It is explicit that risk does not stop at the first supplier in the chain. A cloud host has its own infrastructure suppliers. A software vendor has its own dependencies. Written testing requirements, checked periodically, are how that expectation becomes something you can actually verify.

Reading the evidence, not just collecting it

A yes answer to “have you been tested” tells you nothing on its own. Push for detail. Ask for the date of the last test, and whether the testing firm holds a recognised accreditation such as CREST, the UK benchmark for technical competence. Ask for a breakdown of findings by severity, and confirmation that anything serious got fixed and retested. A supplier offering only an automated scan relabelled as a penetration test has told you something important about how much they actually invest in security. It is better to learn that before you sign than after an incident. Sometimes it helps to have someone independent check a supplier’s evidence, or test your own environment first. That is exactly the kind of scoped engagement a professional penetration test is built for.

Where sector rules add another layer

General good practice is the floor, not the ceiling. If a supplier touches payment card data, PCI DSS requirement 12.8 sets specific obligations. Merchants must keep a list of service providers and hold written agreements that assign responsibility for cardholder data security. They must also carry out due diligence before engagement and check each provider’s compliance status at least once a year. Financial firms increasingly face operational resilience expectations that extend into their supplier base. Any processor handling personal data on your behalf already carries the GDPR contractual duties described above, regardless of industry. When a supplier sits inside one of these regimes, point your requirement at the specific standard rather than relying on generic wording.

Frequently asked questions

What counts as a meaningful third party penetration testing requirement?

Good third party penetration testing requirements name a frequency, a scope, an expectation of independence, and a form of evidence you actually get to see. Anything vaguer than that is easy for a supplier to satisfy without changing their behaviour.

Is a vulnerability scan good enough for lower-risk suppliers?

For genuinely low-risk, low-access suppliers, a scan or a baseline certification like Cyber Essentials can be proportionate. For anything with real access to your systems or data, a scan alone does not tell you whether a determined attacker could actually get in.

Should we ask to see the full penetration test report?

You can ask, but many suppliers will decline because a full report reveals sensitive detail about their own environment. A summary of scope, severity-rated findings and remediation status is a fair and common middle ground.

What should we do if a critical supplier refuses to share evidence?

Treat it as a risk decision that needs escalating, not paperwork to chase later. Ask for a call with their security team. If a supplier handling sensitive or regulated data keeps refusing, that is a legitimate reason to reconsider the relationship.

Drafting these requirements for the first time, or want a second opinion on a supplier’s evidence? Feel free to get in touch, no obligation attached.