Straight answers about buying a pentest
Most of these come up on scoping calls. If your question is not here, ask it — we would rather answer before you buy than have you discover the answer afterwards.
Before the engagement
What does a penetration test cost?
Price follows scope, and scope follows complexity rather than headline size. The drivers are: how many distinct applications or IP ranges, how many user roles need testing separately, whether testing is authenticated, and whether business logic needs to be understood in depth. A single web application with two roles is a very different engagement from a platform with tenant isolation and an admin surface.
We quote fixed price after a short scoping call, and the quote does not move unless the scope genuinely does — in which case we stop and re-agree in writing before continuing. Be cautious of anyone quoting from a form submission alone; they are either padding for unknowns or planning to raise it later.
How long does a test take?
Typical engagements run three to ten working days of testing, plus reporting. A focused API test may be three days. A multi-tenant platform with several roles can be three weeks. Booking lead time is usually two to four weeks.
If you are working to an audit date, tell us the date first. We plan backwards from it, because you need time after the report to remediate and retest before your assessor arrives. A test that lands the week of the audit leaves you with findings and no runway.
What do you need from us to scope it?
Enough to understand shape and complexity: what the system does, roughly how large it is, how many user roles exist, whether we are testing authenticated, and what is driving the requirement. Architecture diagrams help but are not required, and you should not send credentials or sensitive detail at this stage.
Black box, grey box or white box?
We recommend grey box for most application testing, and it is what we quote by default. You provide credentials for each role and a basic description of the application; we test as an authenticated attacker would.
Pure black box testing is intuitively appealing — it feels like a more realistic simulation — but it spends a meaningful share of your budget on reconnaissance an actual attacker would happily spend weeks on for free. You end up paying tester time to discover things you could have simply told us. Black box makes sense when the question is specifically "what is reachable from the internet with no prior knowledge", which is a perimeter question rather than an application one.
Should we test production or staging?
Production gives the true answer, because staging environments drift — different configuration, different data, sometimes different code. Where production testing carries genuine risk, we test staging on the condition that it is a faithful mirror, and we state that limitation clearly in the report so nobody over-reads the result.
Our testing is non-destructive by default either way. We agree windows, rate limits and escalation contacts before starting.
How often should we test?
Annually as a baseline, and after any significant change to the application, infrastructure or authorisation model. Several frameworks make this explicit — PCI-DSS requires testing after significant change as well as annually. If you ship continuously, an annual point-in-time test is a compliance artefact rather than an accurate picture of risk, and it is worth discussing a different cadence.
How engagements run
Will testing take our systems down?
It should not, and preventing it is a design constraint rather than a hope. We do not run denial of service, we agree rate limits in advance, and we avoid techniques with meaningful availability risk unless you have specifically commissioned them.
The honest caveat: testing exercises code paths that ordinary use does not, and occasionally that surfaces an existing fragility. This is why we agree an escalation contact and a stop procedure before starting. If something degrades, we stop immediately and call you — we do not carry on and mention it in the report.
What happens if you find something critical mid-test?
You hear about it that day, not in the report three weeks later. Critical and High findings are communicated as soon as they are verified, with enough detail to start remediating. If a finding suggests you may already have been compromised, we tell you immediately and stop testing until you decide how to proceed.
Do you need our source code?
Not for a standard penetration test. Source access turns it into a different exercise — valuable, but distinct, and quoted separately. Sometimes we ask for a specific snippet to confirm a root cause so the remediation advice is precise rather than generic.
Who actually does the testing?
The tester who does the work is the person you speak to. Not an account manager relaying questions to someone you never meet. You will know who is on your engagement before it starts, and they are available during remediation.
Reporting, retesting and evidence
What does the report contain?
An executive summary written for people who do not work in security, a technical section with every finding, and an appendix covering scope, methodology and anything that limited coverage. Each finding carries a severity with CVSS vector, reproduction steps, evidence, business impact and specific remediation — not "implement input validation" but what to change, where.
See the sample report for the actual structure.
Is retesting included?
Yes. Retesting the findings we reported is part of the engagement, not a separate purchase. You get updated evidence showing what has been verified as fixed, in a form suitable for handing to an assessor. New functionality built since the original test falls outside that retest — it has never been tested, so it needs scoping as new work.
Will this satisfy our auditor?
For ISO 27001, PCI-DSS, SOC 2, GDPR Article 32 and DORA, our reporting is structured to provide the evidence those frameworks ask for — findings, remediation, and verified closure. The compliance page maps requirements clause by clause.
One caveat worth stating: a report is evidence that testing occurred, not evidence that you are secure or compliant. Assessors look at whether findings were actually remediated. The retest is usually the more important artefact.
Can we share the report with customers?
Yes — it is yours, in full, including raw evidence. Many clients share reports with enterprise customers during vendor due diligence. If you need a version suitable for wider circulation, ask and we will produce a summary that evidences the engagement without publishing exploitation detail for issues you are still fixing.
What if we disagree with a severity rating?
Tell us. Severity combines technical impact with business context, and you know your context better than we do — a finding we rated High may be mitigated by a compensating control we could not see. We will adjust where the argument holds and document the reasoning. What we will not do is downgrade a finding because it is inconvenient, and we will say so plainly if that is what is being asked.
Authorisation and boundaries
What authorisation do you need?
Written confirmation that you own the systems in scope, or documented permission from whoever does, signed by someone able to give it. This is not paperwork for its own sake: unauthorised testing is a criminal offence under the Computer Misuse Act 1990 in the UK, and equivalents elsewhere. No testing starts before it is signed — including for the free finding.
What if our system is hosted by a third party?
You need their permission as well as your own authorisation, and requirements vary by provider. Major cloud providers permit testing of your own resources under their acceptable use policies; SaaS platforms and shared hosting frequently do not. Tell us the hosting arrangement during scoping and we will tell you what consent is needed before anything is booked.
What do you do with our data afterwards?
Where a finding exposes data, we capture the minimum that evidences the issue, record exactly what was accessed, and destroy working copies on report delivery. Reports and evidence are retained encrypted for an agreed period so retesting and audit queries are possible, then deleted. The specifics are in the privacy notice and can be tightened by contract if you have stricter requirements.
Is the free finding genuinely free?
Yes — no card, no obligation, and no sales call required before you receive it. The commercial logic is simply that a real finding in your own system is more persuasive than a case study, and some proportion of organisations we do this for go on to hire us. If you take the finding and fix it yourself, that is a legitimate outcome. Details on the free finding page.
Still have a question?
Scoping conversations are free and carry no obligation. If penetration testing is not what you need, we will tell you that too.