"Penetration test" gets used to mean very different things. Some vendors run an automated scanner, export the results, and call it a pentest. Others put a person in front of your systems for a week and try to break in the way a real attacker would. The gap between those two is the difference between a report that protects you and one that just ticks a box.
A scan finds the door. A pentest opens it.
An automated scanner is useful. It checks your systems against a database of known issues quickly and cheaply. But it cannot reason. It does not chain two small weaknesses into one serious breach, it does not understand your business logic, and it produces false positives someone still has to sort through.
A real penetration test is led by a person. The tooling helps, but the value is in the judgment: taking a low-severity finding here and an exposed endpoint there and turning them into a demonstrated path to your data.
What you should expect to receive
- An executive summary your leadership can read in five minutes.
- Each finding rated by real business risk, not just a generic score.
- Evidence: how it was found, and proof it is exploitable.
- Remediation a developer can act on.
- A retest, to confirm the fixes worked.
Five things to have ready before you book one
- Scope. Which apps, APIs, networks or cloud environments are in, and which are out.
- Environment. Production or staging, and whether the data is real or seeded.
- Access. Test accounts for each user role.
- Timing. A window that will not disrupt customers.
- A point of contact. Someone who can answer questions quickly.
The point is not the report
The report is the deliverable, but it is not the point. The point is that you can tell a client, an auditor, or your board, honestly, that someone skilled tried to break in, you fixed what they found, and it was checked again. That is what earns trust.