Does Your Web App Need a Penetration Test?

A penetration test for your web app is worth paying for when someone outside your company requires one (an enterprise customer, a public tender, an investor or a certification audit) or when the app handles sensitive personal data or card payments. If none of that applies yet, updating your dependencies, tightening access control and getting a code review will usually do more for your security per euro. The test itself should come from an independent security firm, while your developer's job is to get the app ready beforehand and fix the findings afterwards.

I'm a developer, not a penetration tester, so this guide is written from the developer's side of the table: when a test is worth it, how to avoid paying testers to find the obvious, and what to do with the report.

The short answer: does your web app need a pentest?

Find your situation below. If several rows apply, the strictest one decides.

My rule of thumb: if you can name a person or a requirement that will read the report, or a data leak would seriously hurt your users, the test is worth it. Otherwise, start with the basics.

The rest of ongoing security (updates, backups, monitoring) is covered in my complete guide to web application maintenance.

What a penetration test is (and what it isn't)

A penetration test, or pentest, is a controlled attack on your web app, carried out by security specialists with your written permission. The goal is to find the holes before someone with bad intentions does and show how far each one can take an attacker. You get a report with findings, severity and fixes.

Three things often get mixed up:

• Vulnerability scan: an automated tool looks for known issues and outdated components. It's cheap and fast, but it won't catch logic flaws, such as a user seeing another customer's invoices by changing a number in the URL.
• Code review: a developer reads the code and assesses security, structure and quality from the inside. It catches many of the same issues earlier and cheaper, but doesn't prove they can be exploited. I cover when that's the right call in situations where you need an external code review.
• Penetration test: a human attacks the running app with an attacker's tools and mindset, trying to chain small weaknesses into big ones.

Testers work in one of three modes: black box (no information up front), grey box (test accounts and some documentation) or white box (the source code too). For most web apps I recommend grey box, because the testers spend their days finding holes instead of guessing how the app works.

When a pentest is genuinely necessary

Enterprise customers and procurement

Sell to larger companies and a security questionnaire usually arrives before the contract, asking whether the system has been pentested in the past year. US buyers often ask for a SOC 2 report, European buyers for ISO 27001 alignment, and a recent pentest is typically part of the evidence for both. At that point the real question is whether you want the customer.

Ask exactly what they want to see: the full report, an executive summary or a letter of attestation from the testing firm. If your customer falls under the EU's NIS2 directive, expect stricter supplier requirements, which I explain in what NIS2 means for software suppliers.

Personal data and the GDPR

The GDPR never uses the words "penetration test". But Article 32 requires, where appropriate, a process for regularly testing, assessing and evaluating whether your technical and organizational security measures actually work. For a web app with ordinary customer accounts, scanning, regular updates and a review can cover it. If you process health data, financial data or national ID numbers, an external test is the most convincing evidence when a data protection authority or a customer asks. The GDPR also covers companies outside the EU that offer services to people in the EU. I'm not a lawyer, so get advice on what your specific case requires.

Investors, acquirers and payments

If you're raising money or selling the company, the investor or buyer will often review the technology as part of due diligence. A recent pentest with fixed findings shows security has been taken seriously. An old report with open critical findings shows the opposite.

Card data is its own category. If you store or process card numbers yourself, PCI DSS (the card industry's security standard) requires regular penetration testing. If you use a hosted checkout where the card number never reaches your server, most of that burden typically sits with the payment provider.

When a pentest is a waste of money (for now)

A pentest doesn't get more valuable by finding things you could have fixed yourself. In these situations I usually recommend something else first:

• Your framework or packages are several versions behind. The testers will spend paid time on known vulnerabilities that an update would have closed. Start by updating your dependencies, and check whether your Laravel version still gets security fixes.
• The app is an MVP with few users and no sensitive data. Spend the budget on a code review and a scan, and schedule the pentest for when enterprise customers or sensitive data arrive.
• Nobody maintains the code. A report without a developer to act on it is just a list of problems you now officially know about.
• Large parts of the system are about to be rebuilt. Test the system that will be in production, not the one on its way out.
• You want a stamp that lasts forever. A pentest is a snapshot of one version, and the next release can open new holes.

If you're unsure, a code review is often the cheapest first step: it tells you whether the code is ready and what to fix first.

How to prepare your web app: 7 steps before testing starts

Testing days are expensive, so spend them on the hard stuff.

Fix the obvious first

1. Get the requirement in writing. Ask whoever requires the test what should be in scope, what report they expect and when they need it. Then the testing firm can quote precisely.
2. Update your framework and packages. Run composer audit and npm audit (commands that check your dependencies against lists of known vulnerabilities), and fix what they report.
3. Review access control. At the top of the OWASP Top 10:2025, the most widely used list of web application security risks, sits broken access control: users seeing or changing data they shouldn't have access to. Check that every page and every API call verifies that the user is allowed to see that specific record, not just that they're logged in.
4. Clean up your configuration. Debug mode, which shows technical error details to anyone, must be off in production (in Laravel, APP_DEBUG=false). Secrets belong outside the codebase, logins need rate limiting and everything should run over HTTPS. More of the classic holes are covered in my web application security checklist.

Make the testers' job easy

5. Set up a test environment. A staging environment (a copy of the system used for testing) with the same code and configuration as production, but fake data, lets the testers push hard without touching real customers. If production must be tested, take a backup first and agree on the timing.
6. Create test accounts and describe the system. Testers need at least two accounts per role so they can try to reach each other's data. Add a short overview of roles, integrations and the API, and state what's out of scope.
7. Agree on the rules of engagement. Who's the contact person, which days can testing run, and what happens if they find something critical mid-test? You want to hear about that right away, not in a report three weeks later.

What a pentest costs and how to pick a firm

How much does a penetration test cost?

Pentests are almost always priced by testing days, which depend on how much there is to test. A tightly scoped test of a smaller web app with a couple of user roles can often be done in 3-5 days. A platform with many roles, a public API, integrations and perhaps a mobile app can take two weeks or more.

As a rough estimate, expect from around €3,500 excluding VAT for a small, tightly scoped test up to €15,000 or more for a large platform. Day rates vary a lot between firms and countries, so get 2-3 quotes for exactly the same scope.

How to choose a testing firm

• Independence. The firm didn't build the app and doesn't run it.
• Manual testing. A report that's mostly scanner output can be had for far less, so ask how much is done by people.
• A methodology. Ask whether they follow a recognized one, such as the OWASP Web Security Testing Guide.
• A sample report. Check that the findings are explained well enough for both management and developers to act on.
• A retest. Confirm whether retesting fixed findings is included in the price.
• Credentials. CREST accreditation for firms and OSCP certification for individual testers are common signs of competence. Ask for references from similar systems too.

After the report: turning findings into fixes

Reports rank findings by severity (critical, high, medium, low), often with a CVSS score on a standardized 0-10 scale. Here's how I recommend handling them:

1. Fix critical and high findings first, before the next release.
2. Look for the cause behind the finding. If testers find one page without an authorization check, there's rarely only one. Review every place that uses the same pattern.
3. Write an automated test for each finding so the bug can't sneak back in with the next change.
4. Get a retest of the fixed findings and keep the updated report. That's the version customers and investors want to see.
5. Make a decision on medium and low findings. Some are real risks, others are theoretical in your particular system. Write down why you accept a risk so the decision is documented.

Don't share the full report freely: until the findings are fixed, it's a recipe for attacking your system. Many firms can provide a summary or letter of attestation for customers instead.

Next steps: your pre-pentest checklist

Run through this before you book the test.

If you need a developer to get the app ready or work through the findings, see how I handle maintenance and ongoing development for existing web apps. The test itself should still come from an independent security firm.

Frequently asked questions

How long does a penetration test take from start to finish?+

Plan for several weeks, even though the testing itself takes a few days to a couple of weeks. Scoping and a test environment come first, the report comes after, and good firms are often booked weeks ahead. If a customer has set a deadline, book early and leave time for fixes and a retest.

How often should a web app be pentested?+

Once a year is the most common baseline, and it's the interval many enterprise customers ask for. Also test after major changes to login, user roles, payments or the API, since that's where new holes tend to appear. Small changes don't need a new test each time if code reviews and automated tests are part of everyday development.

Does a pentest make my web app GDPR or SOC 2 compliant?+

No, a pentest is evidence for one part of compliance, not compliance itself. Between them, the GDPR and SOC 2 also cover access policies, data processing agreements, backups, logging and incident handling. A clean report shows your app resisted attack at one point in time. Treat it as one document in a larger file, and get specialist advice if a certification is on the line.

What if the test finds a hole that may already have been exploited?+

Treat it as a possible security incident rather than an ordinary bug. Have your developer close the hole and check the logs for signs it was used. If personal data is involved and you can't rule out unauthorized access, the GDPR generally gives you 72 hours from becoming aware of a breach to notify your data protection authority, unless the breach is unlikely to put people at risk. Get legal advice if you're unsure.