Penetration Testing in the UK: Buy the Right Test, Not Just the Report
A penetration test is only as good as the brief behind it. Learn what to test, what to pay and what your team should receive at the end.
Natural light, candid moment, premium editorial treatment.
A good penetration test is a focused assurance exercise. Its value comes from realistic scope, skilled human testing, evidence your engineers can reproduce and a retest that confirms the fixes. The badge on the supplier’s website matters less than the people doing the work and the quality of the brief.
What penetration testing actually is
The UK National Cyber Security Centre describes penetration testing as a way to gain assurance by attempting to breach a system’s security using the tools and techniques an adversary might use. The important word is assurance. A pentest is not a promise that your system is secure forever, and it is not a substitute for secure engineering.
A capable tester combines automated discovery with manual investigation. They test whether weaknesses can be exploited, chain modest issues together and explain the business consequence. This is what separates a penetration test from a vulnerability scan.
A pentest does not prove the absence of vulnerabilities. It gives you an informed view of what a competent tester could find in the agreed time, against the agreed scope, with the access provided.
When is a pentest worth commissioning?
The most useful moment is when the target is stable enough to test but there is still time and budget to fix what the tester finds. Testing the night before launch usually creates an expensive list of problems with no safe remediation window.
Commission a test when you are launching an internet-facing product, making a material architectural or authentication change, introducing sensitive data or payments, preparing for enterprise procurement, responding to a contractual requirement, or seeking independent confidence before a high-risk release. Annual testing may support an assurance programme, but frequency should follow change and risk. The calendar alone is not a strategy.
Buy the assessment that answers your question
If basic patching and access control are not in place, a broad test may simply confirm what the team already knows. Source-code review, cloud review, threat modelling and red teaming answer different questions. Decide what you need to learn before choosing the assessment.
What belongs in the scope
A URL is not a scope. The tester needs to understand the assets, architecture, trust boundaries, user roles, critical workflows and limits of the engagement. Under-scoping produces shallow coverage; vague scoping makes quotations impossible to compare.
Web application
- Domains and test environment
- Every meaningful user role
- Authentication and account recovery
- Payments, uploads and admin workflows
API
- Hosts, versions and documentation
- Authentication method and test tokens
- Object- and function-level authorisation
- Rate limits and sensitive data flows
External estate
- IP ranges, domains and cloud services
- Exposed remote-access services
- Third-party exclusions
- Rules for validation and exploitation
SaaS platform
- Tenant boundaries
- Invitations and role changes
- Integrations and webhooks
- Privileged support and admin functions
Count roles and workflows, not just screens.
A five-page SaaS product with owner, administrator, manager and member roles can require more meaningful testing than a 50-page brochure platform. Each role creates a set of questions: what can it see, change, approve, export or impersonate? Those transitions are where high-impact authorisation flaws often live.
White box, grey box or black box?
Black-box testing begins with little or no internal information and resembles an unknown external attacker, but time is spent discovering what the team could have supplied. Grey-box testing provides accounts and useful context, allowing more time for deeper investigation. White-box work may include source code, architecture and configuration. For most application assurance, informed grey-box testing gives the best depth per day; an external unauthenticated phase can still be included.
The process: from brief to verified fix
Scope
Objectives, assets, roles, exclusions and success criteria.
Prepare
Authorisation, contacts, accounts, data and safe-testing rules.
Test
Discovery, manual exploitation, evidence and daily escalation.
Report
Technical findings, business impact, priorities and debrief.
Retest
Verify remediation and record what remains open.
Keep communication simple
Before testing, agree written permission, contacts, stop conditions and data-handling rules. During testing, critical findings should be escalated immediately. Afterwards, assign an owner to each finding and test the fixes again. A patch can remove the visible symptom while leaving the underlying weakness intact.
What does a penetration test cost in the UK?
Public UK pricing gives a useful budgeting range, but not a universal market rate. As of July 2026, published rate cards commonly sit around £800–£1,400 per consultant day, excluding VAT. A focused test may require three to five testing days; a typical multi-role web application may need five to ten or more. Reporting, project management and retesting may be included or priced separately.
| Illustrative engagement | Typical effort | Budget signal |
|---|---|---|
| Focused application or API | 3–5 days | Low thousands |
| Multi-role web application | 5–10+ days | Often £4k–£12k+ |
| Complex platform or broad estate | Scoped individually | Usually five figures |
Indicative planning ranges, not a quotation. Public examples include Pentus at £800/day and UK G-Cloud documents showing rates around £990–£1,400/day. Exact cost depends on depth, roles, APIs, environment, reporting and retest terms.
What drives the quotation?
- Attack surface: applications, hosts, APIs and integrations.
- Authorisation complexity: user types, tenants and privileged functions.
- Technology: unfamiliar protocols or specialist mobile, cloud and thick-client work.
- Assurance needs: specific methodology, accreditation or procurement requirements.
- Deliverables: workshops, executive reporting, remediation advice and retest depth.
A cheap quote can be efficient. It can also mean the supplier has assumed a shallower test. Ask each provider to state the number of testing days separately from reporting and management. You can then compare the work, not just the total.
What a useful report should deliver
The report is not the product; reduced risk is the product. A useful report makes the path from evidence to remediation unambiguous. It should work at two levels: leadership can see exposure and priorities, while engineers can reproduce and fix each issue safely.
Executive section
- Scope, dates, limitations and overall assurance conclusion.
- The material business risks, not a tally of severity labels.
- Patterns and root causes, such as inconsistent server-side authorisation.
- A prioritised remediation plan and clear residual risk.
Technical findings
- A precise title, affected asset and severity with rationale.
- Preconditions and reproducible steps with sanitised evidence.
- Technical and business impact, including realistic attack paths.
- Actionable remediation specific to your implementation.
- Relevant standards such as CWE, OWASP guidance or vendor documentation.
CVSS can help communicate technical severity, but it should not replace context. An “information disclosure” on a public marketing site is not equivalent to the same issue exposing another customer’s financial records. Ask the tester to explain exploitability, data sensitivity, privilege and blast radius.
How to compare penetration-testing providers
Start with the individual tester. Ask who will perform the work, their experience with your technology and whether the proposed lead is guaranteed. A strong salesperson and a wall of logos do not tell you who will test your application on Tuesday morning.
- Give every supplier the same brief. Include objectives, assets, roles, architecture, dates and expected deliverables.
- Ask for the effort breakdown. Separate scoping, testing, reporting, debrief and retest.
- Request a redacted sample report. Look for reproducible evidence and implementation-specific advice.
- Discuss methodology. OWASP’s Web Security Testing Guide is a useful reference, but a list of standards is not a test plan. The provider should tailor it to your product.
- Clarify data handling. Where will evidence be stored, who can access it and when will it be deleted?
- Confirm escalation and retesting. Define urgent communication, retest window, limits and final status reporting.
Do you need a CHECK provider?
The NCSC CHECK scheme supports penetration testing for UK central government, the wider public sector and critical national infrastructure. If you are buying for one of those environments, follow the relevant procurement requirements. The NCSC explicitly notes that organisations outside the public sector do not need to use a CHECK provider. Choose credentials that match your actual obligation and technical risk.
The buyer’s checklist
We have written the decision this test needs to support.
Every domain, host, API, mobile app and third party is identified.
All meaningful user roles and tenant boundaries are included.
Critical workflows and sensitive data are explained.
The test environment is representative and ready.
Written authorisation, contacts and stop conditions are agreed.
We know exactly who will perform the testing.
The quote separates testing from management and reporting.
Critical issues will be escalated during the engagement.
The report format and retest terms are agreed in advance.
Frequently asked questions
How long does a penetration test take?
A tightly scoped application may need three to five testing days. A multi-role platform, several APIs or a broad external estate can require ten days or more, plus time for scoping, reporting and retesting.
Does a penetration test include fixing the vulnerabilities?
Normally, no. The tester identifies, validates and explains findings; your development or infrastructure team remediates them. Remediation support can be a separate service and the retest should verify the actual fixes.
Do UK companies need a CHECK-approved provider?
Not usually. The NCSC CHECK scheme is intended for UK central government, the wider public sector and critical national infrastructure. Commercial organisations can select an appropriate independent provider based on competence, scope and reporting quality.
Is an automated vulnerability scan the same as a pentest?
No. Scanners are valuable for breadth and repeatability, but a penetration test adds human judgement: chaining weaknesses, exploring authorisation and business logic, and determining whether a finding is genuinely exploitable.
Sources and further reading
Methodology and procurement guidance:
- NCSC: Penetration testing guidance ↗
- NCSC: CHECK information for buyers ↗
- OWASP: Web Security Testing Guide ↗
- OWASP: API Security Project ↗
Public pricing references checked July 2026: