Why it matters
Automated tools find known problems. A person finds the problems that only appear when several small weaknesses are chained together, or when the logic of the product is used in a way nobody planned. A pen test tells you what an attacker could actually reach, not only what looks risky on paper. It is not the same thing as a vulnerability scan.
How it works
- Scope and permission. Agree in writing what may be tested, what may not, and when.
- Mapping. The tester learns how the application works: its pages, APIs, roles and data.
- Testing. The tester tries to break authentication, access control, input handling and business logic, by hand and with tools.
- Report. Each finding gets a severity, steps to reproduce it and advice on fixing it.
- Retest. After the fixes, the tester checks that the problems are really gone.
| Approach | What the tester knows | Best for |
|---|---|---|
| Black box | Nothing beyond what the public can see | Seeing the product as an outsider does |
| Grey box | A normal user account and some documentation | Checking what a signed-in user can reach |
| White box | Source code and architecture | The deepest coverage |
Common mistakes
- Testing before the basics are fixed, so the report lists problems you already knew about.
- Reading a clean report as proof of safety. A pen test is a snapshot of one version on one day.
- Skipping the retest.
- Testing a live system without agreeing the rules first. Authorisation protects both sides.
Related terms
Testers often start from the OWASP Top 10, and a secure code review finds many of the same issues earlier, from inside the code. Read about our penetration testing approach.