How to Scope a Penetration Test: A UK Buyer's Guide to Getting Results You Can Use

Many penetration tests disappoint for a reason that has nothing to do with the testers' skill: the scope was wrong. The test covered the marketing website but not the customer portal. It ran against a staging environment that differed from production. It excluded the cloud control plane because nobody thought to include it. Or it was scoped as "a pentest" with no stated objective, so the report was a long list of findings with no answer to the question the organisation actually had.

This guide explains how to scope a penetration test so the result is useful, whether you need it for a customer assurance request, a certification, a regulatory expectation or genuine risk reduction.

Start with the question you need answered

The NCSC describes penetration testing as a method for gaining assurance in your vulnerability management, not a replacement for it. Before talking to providers, write down the question. Examples:

• Can an unauthenticated attacker on the internet reach customer data in our SaaS platform?
• Can one customer tenant access another tenant's data?
• If a staff laptop is compromised by phishing, how far can an attacker get?
• Are our AWS and Azure environments configured so a stolen developer credential cannot reach production?
• Can our AI assistant be manipulated into leaking data or taking unauthorised actions?

The question determines the test type, the starting position and what counts as success.

Choose the right type of test

• External infrastructure: internet-facing IP addresses and services, such as VPNs, mail, remote access and exposed management interfaces.
• Web application and API: authentication, authorisation, session management, injection and business logic flaws. The OWASP Web Security Testing Guide is the common reference.
• Internal network or assumed breach: testing from the position of a compromised device or user, focusing on lateral movement and privilege escalation, often through Active Directory.
• Cloud configuration and control plane: IAM, storage exposure, network rules, secrets and the paths between identities and data in AWS, Azure or Google Cloud.
• Mobile applications: the app, its local storage and its back-end APIs.
• AI systems and agents: prompt injection, data leakage and tool misuse. These need specialist methods; see what LLM red teaming tests.

Define the scope precisely

A good scoping document lists:

• Exact targets: domains, IP ranges, application URLs, API specifications, cloud account and subscription IDs.
• Explicit exclusions and why, for example third-party systems you do not own.
• The environment: production or a representative pre-production copy. Testing a staging environment that differs from production gives false confidence.
• User roles to be provided, including at least two accounts per role for multi-tenant applications so cross-tenant access can be tested.
• Testing approach: black box, grey box with credentials and documentation, or white box with source code access. Grey box usually gives the best value for time.

Authorisation and the law

Unauthorised access to computer systems is an offence under the Computer Misuse Act 1990. Written authorisation is therefore essential, and it must come from someone entitled to give it. That matters for cloud and hosted services: you can authorise testing of your own resources, but not the provider's underlying platform. AWS and Microsoft both publish policies that set out which services customers may test without prior approval and which activities, such as denial-of-service testing, are prohibited or need special arrangements. Third-party SaaS applications usually require the vendor's permission.

Choosing a provider

In the UK, two schemes are commonly referenced. NCSC CHECK applies to penetration testing of government and critical national infrastructure systems, and some public sector buyers require it. CREST accredits penetration testing companies and certifies individual testers, and is widely requested in the private sector. Whether you need either depends on your customer or regulator, so check the requirement before going to market. Beyond accreditations, ask for a sample report, the named testers' experience, the methodology and how retesting works.

What a useful report contains

• An executive summary that answers the original question in plain language.
• Findings rated by realistic risk to your organisation, not just generic severity scores.
• Clear reproduction steps and evidence so engineers can verify and fix.
• Specific remediation advice, and where relevant, attack chains showing how lower-severity issues combine.
• A statement of what was in scope, what was not tested and any limitations.

Plan remediation time and a retest. A report with unaddressed findings is a liability in customer due diligence, as we discuss in our article on security reviews in enterprise sales.

Between tests

A penetration test is a point in time. Cloud environments change daily. Regular configuration scans with PyraLink Prove show drift between tests, and good identity architecture based on zero trust principles limits what an attacker can reach when something is missed.

Preparing your organisation for the test

A little preparation makes testing time far more productive. Provide accounts, API documentation and architecture diagrams before the test starts, so testers are not spending paid days waiting for access. Tell the teams who monitor your environment, or your managed security provider, that a test is happening and from which IP addresses, unless the purpose is specifically to test detection. If it is, agree a trusted contact who can confirm the activity is authorised if an alert is escalated.

Take backups of systems and data that could be affected, particularly for tests that involve writing data or exercising destructive functions in an application. Agree how the testers will handle any personal data they encounter, and make sure your data protection officer is aware. Plan for findings, too: allocate engineering time in the weeks after the report, and decide in advance who will triage findings and accept or reject residual risk.

Finally, consider whether to combine the test with an exercise of your incident response process. Treating a critical finding as a simulated incident, including escalation and communications, gives you two sets of insights for the price of one.

How Pyralink helps

Pyralink is a product company and does not carry out penetration tests. PyraLink™ Prove complements testing by keeping read-only evidence of your cloud configuration between tests, so drift after remediation is visible. If your buyer requires a specific accreditation such as CHECK or CREST, confirm it with your chosen testing provider at the scoping stage.

Frequently asked questions

How long does a penetration test take?

It depends on scope. A small web application may need a few days of testing, while a complex multi-tenant platform with APIs and cloud infrastructure may need several weeks. Reporting and retesting add further time.

Should we test production or staging?

Production gives the most accurate results, with suitable safeguards. A pre-production environment is acceptable only if it truly mirrors production, including configuration and integrations.

Do we need permission from AWS or Microsoft to pentest?

Both publish policies allowing customers to test many of their own resources without prior approval, subject to rules. Some activities, such as denial-of-service testing, are prohibited or require separate arrangements.

What is the difference between CHECK and CREST?

CHECK is an NCSC scheme for testing government and critical national infrastructure systems. CREST is an industry body that accredits penetration testing companies and certifies individual testers.

How often should we have a penetration test?

At least annually and after significant changes, such as a major release, a new cloud environment or an acquisition. Many customer contracts specify annual testing.

Sources: NCSC: Penetration testing guidance; NCSC: CHECK penetration testing; OWASP: Web Security Testing Guide; Computer Misuse Act 1990; AWS: Penetration testing policy; Microsoft: Penetration testing rules of engagement.