> sort -k2 -n quotes.csv | head -1 && echo 'cheapest is not best — read the methodology'_
A pen test priced at £4,000 for a 1,200-host internal network is not the same product as one priced at £18,000 for the same scope. The cheaper engagement typically delivers three days of automated scanning with a branded report template, minimal manual testing, and generic remediation guidance. The more expensive engagement typically delivers ten days of manual assessment by experienced testers, a bespoke attack narrative, chain analysis, contextualised remediation, and a debrief session.
Both are called "penetration tests." Both produce a report with findings rated by severity. Both satisfy the procurement requirement for "annual pen test — completed." But one provides genuine adversarial assessment that reveals real risk. The other provides a compliance artefact that creates false confidence — the most expensive kind of security failure, because it convinces the organisation that it has been tested when it hasn't.
The cost of a pen test that misses the chain to Domain Admin is not the £14,000 saved on the engagement. It's the cost of the breach that exploits the chain the test didn't find: regulatory fines, operational disruption, customer notification, reputational damage, and the legal exposure of having commissioned a "pen test" that didn't test.
Methodology is what the tester actually does during the engagement. It's the difference between running Nessus and reading the output, and spending days manually exploring the environment, chaining findings together, and demonstrating what an attacker could achieve. Every provider claims to follow a methodology. The question is whether the methodology involves genuine manual testing by skilled practitioners.
| Question to Ask | Strong Answer | Weak Answer |
|---|---|---|
| "What methodology do you follow?" | "We follow OWASP for web applications, OSSTMM or PTES for infrastructure, and TIBER-EU-aligned approaches for red teaming. Our methodology is documented and available for review. We adapt it to the scope and objectives of each engagement." | "We use industry-standard methodology." No further detail. No documentation available. Inability to explain what the methodology involves in practice. |
| "What proportion of the engagement is automated versus manual?" | "Automated scanning is used for initial discovery and patch-level assessment. The majority of the engagement — typically 70–80% — is manual testing: exploitation, chain analysis, privilege escalation, and detection testing. Automated tools identify the starting points. Manual testing demonstrates the real risk." | "We use leading automated tools to ensure comprehensive coverage." This typically means the engagement is predominantly or entirely automated, with manual effort limited to reviewing scanner output. |
| "How do you identify attack chains?" | "We map individual findings into chains by testing whether they can be combined to escalate access or reach high-value targets. The attack narrative describes the chain — from initial access through to the objective — so you can see how findings relate and where the chain can be broken most cheaply." | "We report findings individually by severity." No chain analysis. No attack narrative. Findings are isolated issues rather than connected paths. |
| "What happens if the tester gets stuck?" | "Our testers have the experience to try alternative approaches — different techniques, different vectors, different targets. If the primary path is blocked, they'll pivot. If no path exists, we'll report that honestly, including what we tried and why the controls were effective." | "We'll run the scans and report what we find." This suggests a limited, tool-driven approach where the tester's role is to operate software rather than think creatively. |
The report is the only tangible output of the engagement. It's read by the IT team, the CISO, the board, the auditor, and potentially the insurer and the regulator. A high-quality report enables remediation, informs investment decisions, and provides evidence of due diligence. A low-quality report sits in a shared drive and satisfies a checkbox.
| Report Element | High-Quality Provider | Low-Quality Provider |
|---|---|---|
| Executive summary | Written for a non-technical audience. Explains the key risks in business terms. Describes the attack chain and its business impact. Provides a clear, prioritised recommendation. Readable by a board member in under five minutes. | Technical jargon aimed at security professionals. Lists findings by CVSS score. No business context. No chain narrative. Unreadable by anyone outside the IT team. |
| Attack narrative | A step-by-step description of how the tester progressed through the environment — from initial access through lateral movement and escalation to the final objective. Maps findings into chains. Shows where the chain could be broken. | No narrative. Findings are listed independently, sorted by severity. The reader cannot see how findings connect or where the critical chain exists. |
| Individual findings | Each finding includes: specific evidence (screenshots, command output), reproduction steps, business impact in context, CVSS and contextual severity rating, detailed remediation guidance tailored to the environment, and verification steps the IT team can use to confirm the fix. | Generic finding descriptions copied from a template. Remediation guidance is "apply vendor patches" or "implement best practices." No evidence. No reproduction steps. No environmental context. |
| Scope and limitations | Clearly states what was tested, what wasn't, time constraints, methodology limitations, and residual risk from untested areas. Honest about what the test can and cannot confirm. | No limitations section. The reader assumes the report represents a comprehensive assessment of the entire environment — which it doesn't. |
| Effective controls | Acknowledges controls that worked: the EDR that caught the initial payload, the MFA that prevented credential abuse, the segmentation that contained lateral movement. Provides a balanced view. | Only reports failures. No acknowledgement of effective controls. The reader gets a skewed picture that ignores what's working. |
| Longitudinal comparison | Compares current results to previous engagements: recurring findings, time to objective, detection rate trends. Demonstrates improvement or regression over time. | Standalone report with no connection to previous engagements. No trend data. No way to demonstrate whether the programme is improving. |
Before engaging any provider, request a redacted sample report from a previous engagement. This is the single most informative artefact in the evaluation process. A provider who produces high-quality reports will share one confidently. A provider who can't or won't share a sample report should be treated with caution.
A pen test is only as good as the person conducting it. The provider's brand, certifications, and proposal quality are proxies — the actual quality is determined by the skill and experience of the individual tester assigned to the engagement.
| Question to Ask | What You're Looking For |
|---|---|
| "Who will be conducting the test?" | A named individual — not "a member of our team." The provider should be willing to share the tester's relevant experience and certifications. If the provider can't tell you who will be testing your network, they may be subcontracting to unknown parties. |
| "What certifications do they hold?" | Certifications that demonstrate practical skill: OSCP, OSCE, OSEP, CREST CRT/CCT, or equivalent. These require the candidate to compromise systems in a practical exam — not just answer multiple-choice questions. Vendor certifications and awareness-level certificates (CEH alone, for instance) are less indicative of hands-on testing ability. |
| "How many years of testing experience do they have?" | Experienced testers find more, find it faster, and find it in places that less experienced testers don't look. An engagement staffed with a tester who has five or more years of dedicated pen testing experience will typically produce significantly deeper results than one staffed with a recent graduate running tools. |
| "Will the same tester be available for the debrief and retest?" | The tester who found the vulnerabilities is best placed to explain them, answer questions, and validate the fixes. If the provider can't guarantee continuity between the test, the debrief, and the retest, the value of each subsequent interaction is reduced. |
| "Do they specialise in our environment type?" | Infrastructure, web applications, cloud, mobile, OT, and IoT all require different expertise. A tester who specialises in Active Directory infrastructure testing may not have the depth required for an AWS cloud assessment — and vice versa. Ensure the tester's specialisation matches the scope. |
| Red Flag | What It Typically Means |
|---|---|
| A fixed price with no scoping questions | The provider is quoting a standard package — not an engagement tailored to your environment. If they didn't ask about your network size, technology stack, objectives, or previous testing, the engagement won't be designed to address your specific risk. |
| "Unlimited scope" at a low price | A provider offering to test "everything" for a low fixed fee is either planning to run automated scans and present the output as a pen test, or is underestimating the effort required — leading to an engagement that's too shallow to find real issues. |
| Inability to provide a sample report | If the provider can't show you what their deliverable looks like, you're buying blind. A high-quality provider has sample reports they're proud to share. |
| Reluctance to name the tester | If the provider won't tell you who will be testing your systems, they may be subcontracting to parties you haven't vetted — or staffing the engagement with whoever is available rather than whoever is qualified. |
| No mention of manual testing | If the proposal describes the engagement entirely in terms of tools and automated scans — vulnerability scanning, automated web application scanning, configuration assessment tools — the engagement may not include genuine manual penetration testing. |
| Guaranteed outcomes | "We guarantee we'll find critical vulnerabilities" or "we guarantee a clean report" are both red flags. Legitimate providers can't guarantee what they'll find — because findings depend on the environment, not the tester's marketing. |
The pen test market ranges from automated vulnerability scans repackaged as penetration tests at commodity prices, to genuine adversarial assessments conducted by experienced testers who spend days manually exploring, exploiting, and documenting what an attacker could achieve. Both are called "pen tests." Both produce reports. Both satisfy the checkbox. Only one improves the organisation's security.
The difference is visible in the methodology (manual testing versus automated scanning), the report (attack narratives versus finding lists), the tester (experienced practitioners versus tool operators), and the communication (partnership versus delivery-and-disappear). Evaluating these factors — by requesting sample reports, asking the right questions, and comparing on quality rather than price — is how an organisation selects a provider that produces genuine security improvement rather than comfortable reassurance.
The cheapest pen test is the one that finds the chain to Domain Admin before the attacker does — regardless of what it costs. The most expensive pen test is the one that misses it — regardless of how little it costs.
We provide sample reports before engagement, name the tester who will conduct your assessment, and deliver findings with attack narratives, chain analysis, and remediation guidance tailored to your environment — because a pen test is only valuable if it finds what matters.