Web application penetration testing for UK businesses is a manual, expert-led security assessment that costs between £5,000 and £15,000 for most apps, rising to £8,000 to £12,000 where the app handles payments, customer data, or multiple user roles. A test takes 5 to 10 days of tester effort over a 2 to 3 week elapsed window. Unlike an automated scan, a pentest probes authentication, authorisation, session management, and business logic flaws that scanners cannot see. CREST-certified day rates run £1,000 to £1,500, occasionally £800 to £2,500. The deliverable is a report with an executive summary, CVSS-scored findings, evidence, and prioritised remediation, usually followed by a free retest. Common triggers include PCI DSS, ISO 27001, and client security questionnaires. Be clear on one point: Cyber Essentials Plus is not a penetration test. This guide explains the OWASP-based process, costs, timeline, and report standards.
Last updated: June 2026
Web application penetration testing is a manual security assessment in which a qualified tester deliberately attacks your live or staging application the way a real attacker would, then documents what they could break and how to fix it. The critical word is manual. An automated vulnerability scan runs a tool against your URLs, matches responses to a signature database, and produces a list of suspected issues. A pentest uses a human brain to chain weaknesses together, bypass logic, and reach data they should never see. The two activities are complementary, not interchangeable, and confusing them is the single most expensive mistake we see UK buyers make.
Here is the practical difference. A scanner can flag a missing security header or an outdated library in seconds. It cannot work out that changing the account ID in a URL from 1042 to 1043 lets you read another customer's invoices, because that requires understanding what the application is for. That class of flaw, broken access control, is consistently the most common serious finding in real-world testing, and almost no scanner catches it reliably. Business logic abuse, multi-step authentication bypass, privilege escalation, and insecure direct object references all live in the gap between what a tool sees and what a human reasons about.
Our honest view: an automated scan is a smoke alarm, useful, cheap, and worth running monthly. A penetration test is a structural survey of the building. If your application takes payments, stores personal data under UK GDPR, or lets different users see different things, you need the survey, not just the alarm. Treat any provider who sells you a re-badged Nessus or Burp scan as a full pentest with deep suspicion.
| Dimension | Automated Vulnerability Scan | CREST-Style Penetration Test |
|---|---|---|
| Who performs it | Software, unattended | Certified human tester |
| Finds business logic flaws | No | Yes |
| Finds broken access control (IDOR) | Rarely | Yes |
| False positive rate | High | Low (manually verified) |
| Typical cost | £0 to £300 per month | £5,000 to £15,000 per engagement |
| Satisfies PCI DSS / ISO 27001 testing clause | No, on its own | Yes |
| Frequency | Weekly or monthly | Annually, or after major change |
If you are commissioning a test to satisfy a client questionnaire, an insurer, or a compliance auditor, the document they want to see is the output of a manual, certified test, not a scanner PDF. Knowing this before you ask for quotes saves a lot of wasted procurement time.
For most UK web applications, grey box testing gives the best value, because the tester is given valid user accounts and basic documentation but not full source code, which mirrors a realistic attacker who has registered an account. The three approaches describe how much information you hand the tester before they begin, and that choice directly affects coverage, time, and cost. Choosing the wrong one wastes money: a pure black box test of a complex authenticated app can burn days just getting through the front door.
Black box testing gives the tester nothing but a URL. It simulates an external attacker with no inside knowledge. It is realistic for the perimeter but inefficient, because the tester spends effort discovering what an authenticated user would already know. White box testing is the opposite: full source code, architecture diagrams, and administrative credentials. It gives the deepest coverage and finds the most issues per day, which makes it ideal for high-assurance applications in finance or healthcare, but it costs more in tester time and requires you to share sensitive material.
| Approach | Information given | Coverage | Relative cost | Best for |
|---|---|---|---|---|
| Black box | URL only | Lower | £ | Perimeter check, unknown-attacker simulation |
| Grey box | Accounts per role, basic docs | Strong | ££ | Most SaaS, portals, e-commerce |
| White box | Source code, admin access, diagrams | Highest | £££ | Payments, regulated, high-assurance |
Our stance is firm here. If your app has more than one type of user, for example a customer and an administrator, insist on grey box at minimum and provide one account for every role. Access control flaws between roles are where the genuinely dangerous breaches happen, and you cannot test what you cannot log into. Paying for a black box test of a multi-role application is paying a specialist to spend your budget guessing passwords.
A professional web application penetration test follows five phases: scoping and engagement, reconnaissance, scanning and vulnerability assessment, exploitation, then reporting and retest. This structure is consistent across the industry because it mirrors how a real attacker operates, and a reputable provider will walk you through each phase before you sign anything. Understanding the phases tells you what you are paying for and where your own input is needed.
Phase one, scoping, is where the value of the whole engagement is decided. You and the provider agree exactly which URLs, APIs, user roles, and environments are in scope, what is explicitly out of scope, the testing window, and the rules of engagement. A vague scope produces a vague test. This is also where you confirm whether testing happens against a staging copy or production, and agree emergency contacts in case anything destabilises.
Phase two, reconnaissance, is information gathering: mapping the application's pages, technologies, endpoints, and entry points. Phase three, scanning and vulnerability assessment, combines automated tooling with manual review to build a list of candidate weaknesses. Phase four, exploitation, is the heart of the test, where the tester confirms which candidates are real by safely exploiting them, then attempts post-exploitation to show genuine business impact, for example reaching another customer's data. Phase five, reporting and retest, delivers the documented findings and, after you fix them, verifies the fixes.
| Phase | What the tester does | What you do | Typical share of effort |
|---|---|---|---|
| 1. Scoping and engagement | Agrees scope, rules, environment, contacts | Provide app details, sign authorisation | 10% |
| 2. Reconnaissance | Maps app, technologies, endpoints | Be on call for access issues | 15% |
| 3. Scanning and assessment | Tooling plus manual candidate review | Nothing, stay available | 20% |
| 4. Exploitation | Confirms and safely exploits findings | Watch for any service alerts | 35% |
| 5. Reporting and retest | Writes report, verifies your fixes | Remediate, then book retest | 20% |
The phase that buyers underestimate is reporting. A test that finds twenty issues but explains none of them clearly is almost worthless to a development team. We treat reporting as a deliverable in its own right, not an afterthought, because the report is the only part of the engagement your developers will ever read.
A web application penetration test is structured around the OWASP Top 10, the industry-standard list of the most critical web application security risks, supplemented by business logic testing that no checklist can fully capture. The OWASP methodology gives the test a defensible, repeatable backbone, so when an auditor or client asks what was covered, the answer maps to a recognised framework rather than one tester's preferences. Every credible UK provider works to OWASP as a baseline.
The categories that produce the most serious real-world findings are broken access control, injection, and authentication failures. Broken access control covers insecure direct object references, where changing an identifier exposes another user's data, and privilege escalation, where a standard user reaches administrative functions. Injection includes SQL injection, where crafted input manipulates a database query, and cross-site scripting, where malicious script runs in another user's browser. Authentication and session management failures cover weak password handling, predictable session tokens, and broken multi-factor flows.
Business logic flaws deserve special attention because they are unique to your application and invisible to every automated tool. Consider an e-commerce checkout that validates the price on the first request but trusts a client-supplied value on the second: a tester can buy a £900 item for £9. No scanner finds that, because nothing is technically broken in the code, the rules are simply exploitable. This is precisely why manual testing exists and why we are sceptical of any quote that is suspiciously cheap. Cheap usually means automated, and automated misses the flaws that cost you money.
| Vulnerability class | What an attacker gains | Caught by scanners? |
|---|---|---|
| Broken access control (IDOR) | Other users' data | Rarely |
| SQL injection | Whole database | Sometimes |
| Cross-site scripting | Session hijack, defacement | Sometimes |
| Business logic abuse | Financial loss, fraud | Never |
| Authentication bypass | Account takeover | Rarely |
Most UK web application penetration tests cost between £5,000 and £15,000, with £8,000 to £12,000 being typical for an application that handles payments, customer data, or multiple user roles and needs 5 to 10 days of tester effort. A small, single-function application with a narrow scope can start from around £2,500, while a large platform with many endpoints, APIs, and integrations can exceed £25,000. The figure is driven almost entirely by tester days, and CREST-certified day rates run £1,000 to £1,500, occasionally as low as £800 or as high as £2,500 for niche specialisms.
The single biggest lever on price is scope, so it pays to understand the cost drivers. More endpoints means more to test. More user roles means more access-control combinations to check. APIs, file upload features, and payment gateways each add attack surface and complexity. A site with a handful of static pages and one login is cheap. A multi-tenant SaaS platform with admin, manager, and customer roles, a REST API, document uploads, and a Stripe integration is not, because each of those is a place where serious flaws hide.
| Application profile | Tester effort | Typical UK cost |
|---|---|---|
| Small single-function app, one role | 2 to 3 days | £2,500 to £4,500 |
| Standard business web app, few roles | 4 to 6 days | £5,000 to £9,000 |
| App with payments and customer data | 5 to 10 days | £8,000 to £12,000 |
| Large multi-role SaaS plus API | 10 to 18 days | £15,000 to £25,000+ |
Our honest rule on price: be sceptical of anything dramatically below £2,500 for a real web app, because that figure cannot buy enough certified tester time to do manual work, which means you are buying a scan in a trench coat. Equally, do not assume the most expensive quote is the most thorough. Ask every provider how many tester days the quote represents and what seniority of tester does the work. Two quotes at the same price can hide a threefold difference in actual effort. The cost factors below are worth raising in every scoping call.
A typical web application penetration test takes 5 to 10 days of active tester effort, but the elapsed time from booking to final report is usually 2 to 3 weeks once scheduling, the test window, reporting, and your remediation are accounted for. The active testing and the calendar time are different numbers, and conflating them causes planning headaches, especially when a client deadline or audit date is looming. Plan around the elapsed window, not the effort figure.
The reason the elapsed time stretches beyond the effort is that several stages involve waiting. Reputable providers are often booked two to four weeks ahead, so the lead time to start matters. After testing finishes, the tester needs a few working days to write a quality report rather than dumping raw tool output on you. Then you need time to remediate the findings before the retest, and that depends on your own development capacity. The honest planning advice is to start the conversation at least a month before any hard deadline.
| Stage | Typical duration | Notes |
|---|---|---|
| Quote and scoping | 3 to 5 working days | Faster with clear scope |
| Lead time to booking | 1 to 4 weeks | Good testers are booked ahead |
| Active testing | 5 to 10 days | Depends on scope |
| Report writing | 3 to 5 working days | Quality reports take time |
| Your remediation | 1 to 4 weeks | Depends on dev capacity |
| Retest | 1 to 2 days | Verifies fixes |
If you have an immovable date, for example a procurement gate or an ISO 27001 audit, work backwards from it. A test that delivers a clean retest certificate the day before the audit is cutting it too fine, because remediation always uncovers something that needs a second look. We advise clients to target the final retest a clear week before any external deadline. That buffer is the difference between a calm sign-off and a panicked weekend of hotfixes.
A professional penetration testing report contains an executive summary, a technical findings section with each issue rated using CVSS, supporting evidence, and clear remediation guidance, followed by a retest section once fixes are verified. The report is the entire reason you commissioned the work, because it is the artefact you hand to developers, auditors, clients, and insurers. A test with a weak report is a test you cannot act on, so judge providers on a sample report as much as on price.
The executive summary is written for non-technical readers: your board, your client's procurement team, your auditor. It states the overall risk posture, the number of findings by severity, and whether the application is fit for purpose, in plain English with no jargon. The technical section is for your developers. Each finding includes a title, a CVSS score and severity rating, where it was found, a description of the impact, step-by-step evidence proving it is real, and specific remediation advice. CVSS, the Common Vulnerability Scoring System, gives every finding a standardised 0 to 10 score so you can prioritise objectively.
Here is what a single finding should look like in practice, so you know what good evidence reads like:
Finding: Insecure Direct Object Reference in invoice endpoint. Severity: High (CVSS 8.1). Impact: An authenticated customer can retrieve any other customer's invoice by incrementing the document ID in the request URL, exposing names, addresses, and order values. Evidence: request and response pairs showing account 1042 retrieving account 1043's invoice. Remediation: enforce a server-side ownership check that the requested document belongs to the authenticated user before returning it. Retest status: resolved, ownership check confirmed.
| Report section | Audience | Why it matters |
|---|---|---|
| Executive summary | Board, clients, auditors | Overall risk in plain English |
| Findings with CVSS scores | Developers, security team | Prioritised, objective severity |
| Evidence and reproduction steps | Developers | Proves each issue is real, not a guess |
| Remediation guidance | Developers | Tells the team how to fix it |
| Retest results | Auditors, clients | Proof the fixes worked |
Insist on seeing a sample report before you commit. A vendor who will not share a redacted example is a vendor whose reports you should worry about. The report you receive is the only durable thing you keep from the entire engagement, and a clear, well-evidenced report is what turns a list of problems into a fixed application.
CREST is the UK gold standard for penetration testing accreditation, NCSC CHECK is the scheme used when testing UK government and public sector systems, and Cyber Essentials Plus is a separate, lighter assurance scheme that is emphatically not a penetration test. These three terms get mixed up constantly in procurement, and the confusion costs money and credibility, so it is worth getting them straight before you buy anything. The short version: for commercial web app testing, look for CREST.
CREST, the Council of Registered Ethical Security Testers, accredits both companies and individual testers against defined competence and conduct standards. When a provider is CREST-accredited and uses CREST-registered testers, you have third-party assurance that the people doing the work are genuinely qualified. The NCSC CHECK scheme is run by the National Cyber Security Centre and is the requirement for testing systems that process UK government data. Unless you are working with the public sector, CREST is usually the standard you are looking for; CHECK is a public-sector overlay.
Cyber Essentials Plus is the one that catches people out. It is a government-backed certification that confirms you have basic technical controls in place, and it includes a hands-on verification, but that verification is a limited assessment against a fixed control set, not a creative, manual penetration test of your application's logic. We see businesses tell a client they have been pentested when they have only done Cyber Essentials Plus. That is a misrepresentation that can blow up during a security questionnaire.
| Scheme | What it is | Is it a pentest? | When you need it |
|---|---|---|---|
| CREST | Accreditation for testers and firms | Yes, the testing standard | Most commercial web app testing |
| NCSC CHECK | Government-system testing scheme | Yes, public sector overlay | Testing UK government data |
| Cyber Essentials Plus | Basic controls certification | No | Baseline assurance, some tenders |
| OWASP | Testing methodology | Methodology, not a body | Always, as the test framework |
Our blunt advice: if a compliance requirement or client contract says penetration test, give them a CREST-aligned test report, and do not try to substitute a Cyber Essentials Plus certificate. They are different products solving different problems, and an experienced procurement reviewer will spot the difference immediately.
You prepare for a penetration test by providing a stable test environment, valid accounts for every user role, a clear scope document, and an agreed freeze window where the application is not changing under the tester's feet. Good preparation directly improves the quality of the test, because every hour the tester spends chasing access or working around a broken environment is an hour not spent finding vulnerabilities. The clients who get the most from a test are the ones who arrive ready.
The biggest single decision is whether to test against production or a staging copy. We recommend a staging environment that mirrors production as closely as possible, because it removes the risk of the test affecting real customers, while still reflecting the real code. If you must test production, agree explicit rules of engagement, a low-traffic window, and a rollback plan. Either way, freeze deployments during the test: pushing a release mid-test invalidates findings and confuses everyone about what was actually present.
| Preparation item | Why it matters | Who provides it |
|---|---|---|
| Staging environment | Protects live customers | Your dev team |
| Accounts per role | Enables access-control testing | Your dev team |
| Written scope | Prevents misunderstanding and out-of-scope work | Joint with provider |
| Deployment freeze | Keeps findings valid | Your dev team |
| WAF whitelist | Stops results being skewed | Your infrastructure team |
One stance we hold firmly: there is a UK GDPR angle to preparation. If you test against production or use real personal data in staging, you are processing personal data, and your testing arrangement should reflect that with appropriate access controls and a contract. Using anonymised or synthetic data in staging where possible is the cleaner path, and it is one of the questions a good provider will raise with you up front.
At Softomate Solutions we run web application penetration testing as a fixed-quote, five-stage engagement with no surprise day-rate creep, and crucially we do not just hand you a report and walk away. Because we are a London software and automation agency that builds web applications as well as tests them, our developers can sit alongside yours to fix the findings, which is where most testing-only firms leave a gap. The result is a tested application that is actually fixed, not a PDF of problems you are left to solve alone.
Our engagement runs in five clear stages, each with a defined output, so you always know where you are. We agree the full price up front based on scope, not an open-ended day rate, which means no nasty invoice surprises if the test runs long. A standard web application penetration test with us starts from £4,500, with payment-handling and multi-role applications typically in the £8,000 to £12,000 band, and we tell you which band you are in before you commit a penny.
| Stage | Output | Typical timeline |
|---|---|---|
| 1. Scoping workshop | Fixed written quote and scope | Days 1 to 3 |
| 2. Environment setup | Staging ready, accounts issued | Days 4 to 7 |
| 3. Manual testing | Confirmed, evidenced findings | Week 2 |
| 4. Reporting | Executive and technical report | Early week 3 |
| 5. Remediation and retest | Fixes verified, clean retest | Weeks 3 to 5 |
Because we also offer web application development services in London, we can rebuild insecure components properly rather than patching them, and our software development team understands the code behind the findings. If your application's problems trace back to brittle manual workflows, our business process automation and custom CRM development work can replace the risky parts entirely. Whether you need a one-off test before a client audit or an ongoing security partner, we quote it fixed and explain every figure.
Most UK web app penetration tests cost £5,000 to £15,000, with £8,000 to £12,000 typical for apps handling payments or customer data over 5 to 10 days of effort. Small, narrow-scope apps can start from around £2,500, while large multi-role platforms with APIs can exceed £25,000. Price is driven by tester days.
Active testing usually takes 5 to 10 days of tester effort, but the elapsed time from booking to final report is typically 2 to 3 weeks once scheduling, reporting, and your remediation are included. Good testers are often booked a few weeks ahead, so start the conversation at least a month before any hard deadline.
A vulnerability scan is automated software matching responses to known signatures. A penetration test is a manual, expert-led assessment that chains weaknesses together and finds business logic and access-control flaws that scanners miss. For compliance, client questionnaires, or insurers, only a manual test counts; a scanner PDF on its own does not.
CREST is the UK gold standard, accrediting both firms and individual testers against defined competence and conduct standards. A CREST-aligned test gives third-party assurance that the work was done by qualified people, which matters to auditors and clients. Non-CREST testers can be excellent, but CREST gives you objective, verifiable credentials to point to.
For most business applications, grey box testing is best: the tester gets one account per user role but not full source code, mirroring a realistic registered attacker. Use white box for payments or regulated systems where you want maximum assurance, and black box only for a pure external-perimeter view of an unknown attacker.
A professional test is designed to avoid disruption, and we strongly recommend testing against a staging copy that mirrors production to remove all risk to real customers. If production must be tested, we agree a low-traffic window, explicit rules of engagement, and a rollback plan, with an emergency contact reachable throughout.
No. Cyber Essentials Plus is a government-backed certification confirming basic technical controls, with a limited hands-on verification against a fixed control set. It is not a creative, manual penetration test of your application's logic. If a contract or auditor asks for a pentest, provide a CREST-aligned test report, not a Cyber Essentials certificate.
The common UK standard is at least annually, and after any significant change such as a major feature release, an authentication overhaul, or a new payment integration. Compliance frameworks like PCI DSS effectively require this cadence. Between tests, run automated scans monthly to catch obvious regressions early.
A stable staging environment matching production, one working account per user role, a written scope listing every in-scope URL and API, an agreed deployment freeze during the test, WAF whitelisting for the tester, and named technical and emergency contacts. Arriving prepared directly improves how much the tester can find.
It varies by provider, so always confirm. A good engagement includes one free retest after you remediate the findings, which verifies your fixes actually closed the issues and produces an updated report you can show auditors or clients. We include a retest as standard so you finish with proof the application is fixed.
Web application penetration testing is the manual, expert-led check that finds the access-control, authentication, and business logic flaws automated scanners cannot see. For most UK businesses, budget £5,000 to £15,000, rising to £8,000 to £12,000 where payments or customer data are involved, and plan for 5 to 10 days of testing across a 2 to 3 week window. Choose grey box testing if your app has multiple roles, insist on a CREST-aligned report with CVSS-scored findings and a retest, and remember that Cyber Essentials Plus is not a penetration test. Prepare well: a staging environment, accounts per role, a written scope, and a deployment freeze will materially improve what the test uncovers. Above all, treat the report as the product, because it is the only durable thing you keep. Get those decisions right and a pentest stops being a compliance tax and becomes genuine, demonstrable assurance for your customers.
Ready to scope a test with a fixed quote and a team that can fix the findings, not just list them? Talk to our London web application security and development team or get in touch to book a scoping workshop.
Written by Deen Dayal Yadav, Founder of Softomate Solutions, a London-based software development and AI automation agency in Stanmore (HA7). With over 12 years building software and automation systems for UK businesses, he has delivered secure web applications, CRMs, and integrations for clients across finance, healthcare, and e-commerce. Softomate Solutions is a registered company at Companies House and combines hands-on penetration testing with the development capability to remediate findings properly. Learn more about Softomate Solutions.
We protect the real names of all clients featured in examples and case studies. Every testimonial is from a real client.
More from the blog
Work with us
Book a free 30-minute discovery call with DD and get a personalised automation roadmap.
Softomate Solutions Limited
Deen Dayal Yadav
Online
We use essential cookies to keep the site running. With your permission, we also use analytics cookies to understand how visitors use our site so we can improve it. No data is sold. Privacy Policy
