Verdict
Yes
Yes, penetration testing is worth it for an application that holds customer accounts or personal data: book an outside tester once a year and after changes to login, roles or file handling, and fix and retest every finding.
Why
- Blast radiussafety-or-legal
- Change frequencyregularly
- Detectabilitynever
- Reversibilityimpossible
- Test costheavy
Yes, penetration testing is worth it for an application that holds customer accounts or personal data. The typical case is a web application with customer logins and no contract demanding a test. Blast radius is safety-or-legal, because a flaw exposes personal data, and Change frequency is regularly, because endpoints change monthly. Detectability is never, because an attacker's requests look like ordinary traffic, and Reversibility is impossible, because leaked data cannot be recalled. Test cost is heavy, because an outside tester needs five days and a staging copy, and rule R2 still gives Test mandatory.
| When | Decision | Why |
|---|---|---|
| The site has no customer data, accounts or forms, such as documentation deployed from the repository | Do not book a penetration test; keep dependencies patched, for example with Dependabot | Blast radius falls to users, Detectability to same-day and Reversibility to trivial, because a redeploy restores a defaced page |
| A staff tool holds no customer data or secrets, such as a meeting room booking app | Test it differently: alert on sign-ins from new countries and review access every quarter | Blast radius falls to internal, Detectability to eventually and Reversibility to with-effort, because a backup restores the bookings |
| The product has no customers yet and holds invented records on a staging server the team shares | Test it differently: scan staging with OWASP ZAP on each deploy until real customer data arrives | Blast radius falls to internal and Reversibility to trivial, because no real data exists to leak |
| All customer data lives in a hosted platform whose terms forbid penetration tests | Test it differently: check the vendor's audit report, require multi-factor login and alert on bulk exports | Test cost rises to prohibitive, because you may not attack the vendor's platform |
| A penetration test finds a known kind of flaw, such as an image import that fetches internal addresses | Test mandatory: a CI test sends an internal address to the import and asserts a refusal | Test cost falls to moderate, because the tester's request reproduces the flaw, and Blast radius stays safety-or-legal |
What breaks if you don't test
Your own tests check the attacks your team thought of. An import that fetches any URL a user enters passes every unit test and dependency scan, until an attacker points it at the cloud metadata address, reads the server's credentials and copies the customer database. No alert fires, and the first sign may be a researcher's email.
What you lose if you over-test
A penetration test after every weekly release costs days of tester time and reports on code already replaced. Bruce Schneier named in 2007 one reason to test: "You want to know whether a certain vulnerability is present because you're going to fix it if it is." A report whose findings stay open changes nothing. A scan sold as a penetration test gives false confidence, because a scanner does not know which user may read which record.
How to test
- Cover known flaws in CI first, with a test per endpoint and role as in the OWASP Authorization Testing Automation Cheat Sheet, so the tester's days go to new flaws.
- Book an outside tester once a year and after changes to login, roles, or code that fetches URLs or parses uploads. Scope the test with the OWASP Web Security Testing Guide, and give the tester an account per role on a staging copy with invented data.
- Fix each finding, get a retest, and turn the tester's request into a CI test.
When the answer changes
- The system holds no customer data, accounts or forms.
- Every system that holds customer data is a hosted product you may not test.
- A contract or PCI DSS requires a penetration test report, and that evidence comes first.
Cost estimate + Real incident
Six thousand euros against one leak
On a SaaS product I worked on, the first penetration test cost 6,000 euros: five tester days at 1,200 euros a day, the rate in our 2025 quotes. Staging, fixes and retest took three developer days, 1,500 euros at an assumed 500 euros a day, so a yearly test costs 7,500 euros. The tester found that our avatar import fetched any URL, and our servers still answered IMDSv1, the older metadata version that hands role credentials to a plain GET request. We blocked internal addresses as the OWASP SSRF Prevention Cheat Sheet describes, and required IMDSv2.
The Polish data protection authority fined Virgin Mobile Polska PLN 1.6 million, about 370,000 euros at 4.3 zloty per euro, after a leak of 114,963 customers' data, and the fine leaves out notification and lost customers. The yearly test pays off if it cuts the chance of such a leak by 2 percentage points a year: 7,500 divided by 370,000 is 0.02.
Related questions
- Does GDPR require penetration testing?Code under test: Yes
- Does SOC 2 require penetration testing?Code under test: Yes
- Is fuzz testing worth it?Yes
- Does ISO 27001 require penetration testing?Code under test: Yes
- Should I test two-factor authentication?Yes
FAQ
- Do I need a penetration test?
You need a penetration test when your application holds customer accounts or personal data, or when a contract or standard demands a report. A static site with no accounts or forms needs only patched dependencies.
- How often should you run a penetration test?
Run a penetration test once a year and after changes to login, roles, or code that fetches URLs or parses uploads. Between tests, CI tests replay past findings on every change.
- Is a vulnerability scan enough instead of a penetration test?
No, a vulnerability scan is not enough for an application with customer accounts, because it misses flaws in your own logic, such as a missing access check. Run the scan weekly and the penetration test yearly.