What a penetration test involves and what you get for it
What happens during a penetration test of a website or application, what you receive, and when a small business needs one.
The short answer
A penetration test is a skilled person, with your written permission and within an agreed scope, trying to break into your website or application the way an attacker would, and documenting what they found and how. It goes where automated scans cannot: into the logic of your specific application, whether one customer can reach another’s data, whether a process can be skipped or repeated, whether several small weaknesses chain into something serious, and how far an attacker could actually get. The deliverable is a report with confirmed findings, evidence, severity and exploitability, specific recommendations, and a retest after fixes, plus a summary you can hand to clients, insurers or an auditor. A small business needs one when the site or application handles sensitive data, when clients or regulators ask for it, or before launching an application. For a content site with a form, a scheduled scan and the practices built into the pipeline cover most of the ground.
What happens, in order
| Phase | What the tester does | What you see |
|---|---|---|
| Scoping | Agrees the targets, the boundaries, the timing, the accounts and the rules | A scope document and an authorisation to sign |
| Reconnaissance | Maps the application: pages, endpoints, roles, technologies, third parties | Nothing, usually; sometimes questions |
| Automated pass | Runs scanners to clear the known issues quickly | Possibly traffic in your logs |
| Manual testing | Probes authentication, access control, input handling, business logic, sessions, file handling, integrations | Test accounts doing odd things |
| Exploitation | Confirms findings by demonstrating impact, within the rules, without damage | Evidence in the report |
| Reporting | Writes up each finding with evidence, severity, exploitability and a fix | The report and a walkthrough call |
| Retest | Re-checks each finding after your fixes | An updated report with statuses |
Getting value from a test
- Test the right thing: the application that handles the sensitive data, at the point where it is stable enough to be worth testing.
- Give real access: test accounts at every role, a representative dataset, the same integrations as production.
- Fix the pipeline first: obvious issues a scan would find waste the tester’s time; run a scan and fix those beforehand.
- Be available: a tester who can ask a question in a minute finds more.
- Read the report properly: by severity and exploitability, not by count.
- Fix and retest: the retest is the proof.
- Keep the summary: it answers client questionnaires for the next year.
When a small business needs one
An application with customer accounts, payments, health, financial or other sensitive data. A client contract or security questionnaire that requires it. A regulator or an insurer that asks. A launch of anything that would be expensive to get wrong. A takeover of software nobody has assessed. Outside those cases, a scheduled scan, dependency monitoring, a strong pipeline and a partner who builds securely are the proportionate answer, with a test added when the situation changes.
What this means for you
A penetration test is a skilled person trying to break your application within a written scope, and it finds the flaws scanners cannot. Commission one when the data, the clients or the launch justify it, give the tester real access, fix what is found and get the retest. Between tests, scans and secure practice carry the load. The report and its summary are assets you will use for a year; the test is only worth buying if it is real.
Frequently asked questions
How is a penetration test different from a security scan?
A scan is software checking for known patterns: outdated versions, missing headers, common misconfigurations. A penetration test is a skilled person using tools and judgement to find flaws in how your specific application works: whether one customer can see another's data, whether a discount can be applied twice, whether a chain of small issues leads to takeover. Scans are cheap and frequent; tests are deeper and occasional.
What do we need to provide?
Written permission and a scope: which addresses and applications, what is out of bounds, when testing may happen. Test accounts at each role level if the application has logins. A contact for the duration. A test environment identical to production is ideal; testing production is possible with care and agreement. And the willingness to fix what is found, because the test is only valuable if followed by fixes and a retest.
How often should we test?
Before launching an application that handles sensitive data, after major changes to it, and then on a yearly rhythm if clients, regulators or risk justify it. Between tests, automated scans on a schedule, dependency monitoring and the security practices built into the pipeline keep the ground covered. A test once a year with nothing in between is a snapshot; the routine is what keeps the site safe.
Sources
- OWASP Web Security Testing Guide (accessed 2026-09-12)