Most pentest reports gather dust
A penetration test, done right, is one of the highest-leverage security investments a team can make. Done wrong, it's a 60-page PDF that gets emailed around, glanced at, and forgotten while the same vulnerabilities persist.Scope: write it carefully
- List the targets — domains, IP ranges, applications, mobile apps
- Specify in-scope vs out-of-scope (third-party services, payment processors usually out)
- Specify the type of testing — black-box, gray-box, white-box
- Specify the testing posture — external (internet-facing only), internal (post-authentication), or both
- Specify what's NOT to be tested — DoS, social engineering against employees, etc.
- Specify timing windows — when testing can happen
- Identify "do not touch" systems (legacy, fragile)
A well-scoped pentest engagement document is 4-8 pages.
Choosing a tester
- Specialised firms — established pentesting companies (with named consultants)
- Independent consultants — often deeper than firms, less bureaucratic
- Bug bounty programs (HackerOne, Bugcrowd) — continuous, broader coverage but less depth
- Internal red team — only at large organisations
Vetting the tester
Ask for:- Lead consultant CVs and certifications (OSCP, OSCE, CRTP)
- Sample report (redacted) demonstrating the depth they go to
- Methodology document
- References from previous engagements at similar scale
- How they handle data they discover during the test
A firm that won't share a redacted sample report is a firm to skip.
Pre-engagement checklist
- NDA in place
- Rules of engagement signed by both sides
- Communication channel established
- Test account provisioned (for grey-box / white-box)
- Stakeholders notified (don't surprise the on-call team)
- "Get out of jail" letter
- Backup before testing starts
During the engagement
- The tester finds critical issues mid-engagement → expect immediate notification
- Status calls weekly during longer engagements
- The team shouldn't "fix and hide" findings during the test
- Track issues in real time
The report — how to read it
A good report has:- Executive summary (1-2 pages)
- Methodology
- Findings ranked by severity
- Each finding with: description, evidence, severity rationale, recommendation
- Re-test scope
What to do with it:
- Critical / high → fix within sprint, retest
- Medium → fix within quarter, retest
- Low → fix opportunistically
- Each finding gets a ticket, owner, due date, retest evidence
Re-test, scoped
Should specifically verify the original findings are fixed. Schedule after high/critical fixes.Cadence
- Major application changes → pre-launch pentest
- Annual engagement at minimum for production systems
- Continuous (bug bounty) for high-value targets
One pattern we'd warn about
Treating the pentest as compliance theatre. Meets the audit, doesn't improve security.One pattern that always pays off
A wrap-up call with the pentester at the end. The best findings often come up in conversation that didn't make the report.What's the most useful finding from a pentest you've engaged?
