If someone in your organisation has suggested commissioning a penetration test — or if a client has asked for one as a condition of doing business — this guide is for the person who needs to understand what they are buying, what to ask for, and what to do with the results.
You do not need a security engineering background to run this process well. You do need to know what questions to ask before signing a scope of work, and what a useful deliverable looks like versus one that gives you a false sense of security.
What a penetration test actually is
A penetration test is a controlled, authorised attempt to compromise systems or extract data in the same way an attacker would — in order to find the weaknesses before someone with malicious intent does.
The important word is "controlled." A legitimate pentest operates within a documented scope agreed in advance. The tester only tests what is in scope, follows agreed rules about what actions are permitted (can they exploit a vulnerability or just identify it?), and documents everything they find regardless of severity.
What a penetration test is not: a guarantee of security. A clean pentest report means the tester did not find exploitable vulnerabilities within the defined scope and methodology. It does not mean no vulnerabilities exist — it means none were found within those parameters.
The main types and when each applies
Three types come up most often for scale-ups and SMBs:
Web application penetration testing covers your customer-facing web applications, APIs, and portals. This is the most common starting point for B2B software companies, and the most frequently requested by enterprise clients doing vendor security due diligence.
Network/infrastructure penetration testing covers your internal and external network infrastructure — servers, firewalls, VPNs, cloud configuration. This is relevant if you host your own infrastructure or if your risk profile includes internal threat scenarios.
Social engineering testing includes phishing simulations and pretexting (phone-based impersonation). This is useful but requires careful scoping with clear employee communication protocols — the test design matters as much as the execution.
For a first engagement, most scale-ups benefit most from a web application test scoped to their primary product or customer interface. This addresses the most common attack surface and produces the most directly actionable findings.
What to do before you engage a provider
Three things you should define before any scoping conversation:
First, know what you are protecting. What would cause real damage if it were accessed or disrupted? Customer data, financial records, source code, operational systems? The scope should focus on what actually matters — not everything you have.
Second, know what "done" looks like. Are you running this test because a client asked for it? Because your insurance requires it? Because you want to understand your own exposure? The reason shapes the scope and the deliverable you need.
Third, know who internally owns this process. The pentest provider will have questions, may find critical issues mid-engagement, and will need to hand off findings to someone who can act on them. That person needs to be identified before the test begins.
What a good scope of work contains
Before technical work begins, you should receive a written scope of work. If a provider is willing to start testing without one, that is a signal to stop. A legitimate scope document should define:
- Exact systems in scope (IP ranges, domains, applications)
- Systems explicitly out of scope
- Testing methodology (e.g. OWASP for web apps, PTES for infrastructure)
- Rules of engagement — what actions are permitted if a vulnerability is found (exploit only to prove impact? stop at identification?)
- Emergency contact procedures for critical findings mid-test
- Timeline and testing windows (some clients want testing restricted to off-peak hours)
- What is delivered at the end and to whom
What the report should contain
A useful pentest report has two sections for different readers. The executive summary — which you will read — should explain in plain language what was tested, what was found, and what the business impact is if the findings are not addressed. It should not require a security background to understand.
The technical findings section — which your developers or IT team will work through — should include for each finding: the vulnerability description, how it was found, evidence (screenshots, request/response logs), CVSS risk score, and specific remediation guidance.
What a report should not contain: a list of scanner output with no manual verification, findings without remediation guidance, or a risk score with no explanation of how it was calculated. If you receive a report that looks like it was produced by an automated tool with minimal human review, it probably was.
After the test: what to do with findings
A pentest finding is only useful if it gets fixed. The most common failure mode after a test is that the report sits with the security or IT team while business-critical vulnerabilities remain open for months.
Treat the findings report the same way you would treat any risk register item: assign owners, set remediation timelines that reflect actual risk severity, and track closure. High and critical findings should be addressed within days to weeks, not quarters.
If you ran the test because a client asked for it, confirm with the client what format they need for evidence. Some want the full report; most want an executive summary or a letter of attestation confirming findings were addressed. Know this before you commission the test.
Ready to scope a penetration test?
We start every pentest engagement with a scoping call — not a quote. Tell us what you are protecting and why you need the test, and we will tell you what makes sense.
Book a scoping call