How to Vet a Penetration Testing Firm Before You Buy

Direct answer: Ask who is doing the testing and what they have published, whether a retest is included and for how long, whether findings map to the framework you are audited against, and to see a redacted sample report. A firm that cannot answer those four quickly is selling you scanner output.

Who actually does the work

Sales scoping and delivery are often different people, sometimes different companies. Ask who will run your test, what their background is, and whether the work is subcontracted. Published research, CVEs and recognised certifications are reasonable signals, and any firm proud of theirs will tell you immediately.

Is it a test or a scan

A scan is automated and finds known issues. A test is a person chaining findings and proving what an attacker could reach, including business logic that no scanner understands. Both have value and they cost very different amounts.

The tell is the report. Scanner output lists findings by CVSS with generic remediation. A real report describes attack paths, what the tester achieved, and what it means for your business.

The retest question

Remediation evidence is what an auditor samples. A test without a retest leaves you with a list of findings and no proof you closed them, which is worth much less at audit time. Ask whether retesting is included, how long the window is, and whether the updated report reflects closure.

Scope before price

A good scope names the applications, environments and IP ranges in and out of scope, the testing window, whether it is black, grey or white box, whether social engineering is included, rules of engagement, and escalation contacts if something breaks or they find something critical mid-test.

Beware a fixed price quoted without any of that. It means either the scope is trivially small or it will be revised upward once the work starts.

Does the report satisfy your buyer

If the test exists to unblock a deal or support an audit, check the report will do that job. It should be scoped to the system your buyer cares about, dated within the last year, and issued with an attestation letter you can share without handing over reproduction steps.

Ours is scoped that way deliberately, described on the compliance penetration testing page, with prices on the pricing page and the scoping calculator free if you want to size it before talking to anyone.

How the pricing is built, so you can compare quotes

Almost every honest penetration test is priced the same way underneath: a number of tester-days multiplied by a day rate, plus reporting time. Firms present that differently, but if you ask how many days of testing your quote includes and how many of those are reporting rather than testing, you get a number you can compare across proposals.

The variables that drive the day count are the number of distinct user roles in the application, the number of API endpoints, whether authenticated testing is included, whether the application is multi-tenant, how much custom business logic exists as opposed to standard CRUD screens, and whether infrastructure and cloud configuration are in scope alongside the application.

Two quotes with the same headline price can contain very different amounts of work. A five day engagement with two of those days spent on reporting gives you three days of testing. A seven day engagement with reporting included on top gives you seven. Ask, in plain terms, how many days a human will spend actively testing.

Day rates vary with seniority and geography, and a higher rate is sometimes the cheaper purchase, because a senior tester covers ground in three days that a junior covers in six. What you should never accept is a quote with no day count at all attached to a scope you have not agreed, because there is no way to tell what you bought until the report arrives.

The methodology questions that separate firms

Six questions will tell you more about a firm's competence than any brochure.

Will you test authenticated, and with how many roles? Unauthenticated testing of a SaaS application finds very little, because the interesting surface is behind the login. You want accounts provisioned for every role you ship: administrator, standard user, read-only, and any support or internal role, plus at least two separate tenant accounts.

Will you test for cross-tenant access? For any multi-tenant SaaS product, this is the single most valuable thing in the engagement. Can a user in tenant A reach data belonging to tenant B by manipulating an identifier, a token, a filename or a webhook. It is the class of bug that ends companies, no scanner finds it, and it requires two tenants to test properly. If a firm does not ask you for two tenant accounts, they are not planning to look.

What is your API coverage approach? Modern applications have far more attack surface in the API than in the interface. A firm that only drives the browser will miss endpoints with no corresponding screen, older API versions still routed, and parameters the front end never sends. Hand over your OpenAPI specification or Postman collection. If they do not want it, they are testing the front end and calling it a test.

What standard do you work to, and to what depth? Naming the OWASP Web Security Testing Guide or the Application Security Verification Standard is a reasonable answer, particularly if they can say which verification level they are testing against. Naming nothing is a poor answer, and naming the OWASP Top Ten as a methodology is a bad one, because the Top Ten is an awareness document rather than a test plan.

Will the WAF be in the way? Decide deliberately. Testing through the web application firewall tells you about your production posture. Testing with the tester's addresses allowlisted tells you about the application itself. The second finds more real bugs, and a good firm will recommend running most of the engagement allowlisted with a short unallowlisted pass to check the perimeter does what you think.

Production or staging? Staging is safer and frequently worthless, because staging environments differ in configuration, data, integrations and scale from the thing you actually run. If you test staging, confirm in writing that the deployment configuration matches production, and be aware that findings about production infrastructure will not appear.

Reading a sample report like an assessor

Ask for a redacted report and then read it properly rather than glancing at the layout. Six things tell you what you need to know.

The executive summary should be readable by someone non-technical and should say what the tester achieved and what it means commercially, not restate finding counts by severity. A summary that is a bar chart of highs and mediums indicates a tool exported it.

Findings should carry business context, not just a CVSS score. A stored cross-site scripting flaw in an administrative page used by three internal staff and one in a customer-facing page are the same score and vastly different problems. A tester who understands the application says so.

At least some findings should be things no scanner produces: a broken access control chain, a logic flaw in a workflow, a race condition in a billing or provisioning path, an authorisation gap that only appears when two features are combined. If every finding in the sample is a missing header, an outdated library or a TLS configuration item, you are looking at scanner output with a cover page.

Reproduction steps should be specific enough for your engineer to reproduce the issue without contacting anyone, including the exact request. Vague findings generate weeks of back and forth and often get closed as unreproducible.

Remediation advice should be specific to the technology in question, not a paragraph of generic guidance copied from a knowledge base. Advice that names your framework's actual mechanism is evidence somebody thought about your stack.

There should be a limitations section stating what was not tested and why, including anything out of scope, anything blocked by an environment problem, and anything the tester ran out of time for. A report with no limitations section is a report that has hidden them.

Credentials, and what they are actually worth

Individual certifications such as OSCP, the GIAC web application and exploitation tracks, and CREST registered tester qualifications indicate that a person has demonstrated hands-on skill under exam conditions. They are a floor rather than a ceiling, and they say nothing about whether the individual holding them will be the one on your engagement.

Published research is the stronger signal, because it is public and independently verifiable. A tester with published CVEs has demonstrably found real vulnerabilities in real software and taken them through disclosure, which is a harder test than any certification. For context on what that looks like as a credential rather than a claim, our own testing practice sits on five published CVEs, one of them a CVSS 9.1 in the Mirai botnet, alongside more than twenty penetration tests delivered, and any firm with equivalent work will name it without being asked twice.

Firm-level accreditations matter more when your buyer specifies them. Some regulated buyers and some government procurement processes require a firm holding a particular scheme membership. Establish that before you buy, because switching afterwards means paying twice.

Rules of engagement, and the things that go wrong

The rules of engagement document is where you protect yourself, and most disputes trace back to a clause that was never written.

It should name the testing window with dates and hours, and whether out-of-hours testing is permitted. It should name an escalation contact on both sides who is reachable during the window. It should state what happens if the tester finds a critical issue mid-test, and the right answer is immediate notification rather than waiting for the report, because a live authentication bypass is not something to learn about eleven days later. It should state what happens if the tester finds evidence of a pre-existing compromise, which happens more often than firms advertise. It should state what happens if testing degrades or breaks the environment, including who pays and what the rollback plan is. And it should require an authorisation letter signed by someone at your company who has the authority to authorise testing of those systems, which matters if any of them are hosted or operated by a third party.

Also settle data handling. The tester will hold screenshots, request logs and possibly extracted records containing real personal information. Agree where that data is stored, for how long it is retained, and that it is destroyed on a defined schedule with confirmation. Regulated buyers ask about this, and "we never asked" is an awkward answer.

Getting the most out of the days you paid for

Half the value lost in a penetration test is lost by the client, not the firm. A tester who spends the first day chasing credentials has lost a fifth of a five day engagement, and you are paying for that day either way.

Before the window opens, provision every account in advance and confirm each one logs in. Send the API specification, an architecture summary and a short description of what worries you most about the application, because a tester who knows where the crown jewels are will spend the days there. Warn your on-call team so they do not treat the test as an incident, and freeze deployments during the window, or at least tell the tester when you ship, because chasing a bug that got fixed under them wastes hours.

Take a mid-engagement checkpoint call. Most good firms offer one. It surfaces environment problems while there is still time to fix them, and it lets you redirect effort if the tester has found a rich seam somewhere you did not expect.

What to do when the report is poor

Sometimes you receive scanner output with a logo on it. Before you escalate, be specific about what is wrong: no authenticated testing evidence, no business logic findings, findings you can demonstrate are false positives, or no coverage of parts of the agreed scope.

Take that to the firm in writing, referencing the scope document. A reputable firm will re-test the missed areas at no charge, because the alternative is a public dispute. A firm that argues the scope was ambiguous is telling you what they are, and the lesson is that the scope document should have been specific.

Do not send a weak report to your buyer as a stopgap. Vendor risk reviewers at large customers read a great many of these and recognise scanner output immediately, and a thin report damages your credibility more than not yet having one. It is better to say a test is scheduled for a named date than to hand over something that invites questions.

Disagreements on severity are normal and legitimate. If you believe a finding is over-rated because of a compensating control the tester did not know about, say so and ask them to re-rate it with the context. If they decline and you still disagree, record the disagreement and your risk acceptance in writing with a named signatory. That is a defensible position at audit. Silently ignoring a high finding is not.

After the report, which is where the value is

The report is an input to your vulnerability management process, not an output of the project. Every finding needs a ticket in the same system your engineers already use, with a severity, an owner and a due date consistent with your published remediation timelines. Findings that live only in a PDF do not get fixed, and an auditor sampling remediation will ask to see the tickets and the closure dates.

Schedule the retest deliberately rather than when you remember. Fix the highs and criticals, then retest, then get an updated report or a retest letter confirming closure. That document is what an auditor samples and what a buyer's reviewer actually wants to see, because a list of findings with no evidence of closure reads as a list of things you still have.

The attestation letter is a separate artefact worth asking for explicitly. It should state that a test was performed, the dates, the scope in general terms, the methodology, and that findings were remediated or are being tracked, without the reproduction steps. That letter is what you share with buyers. The full report, with its exploitation detail, should go to very few people, and handing it over unredacted to every prospect who asks is a genuine risk that plenty of companies take without thinking.

When you should not be buying a penetration test at all

Three situations where the money is better spent elsewhere, and we would rather say so than take the engagement.

The first is when the basics are not in place. If you do not enforce multi-factor authentication, if production access is shared credentials, if your dependencies are years out of date, or if your cloud storage permissions have never been reviewed, a penetration test will confirm all of that at considerable expense and you will have learned nothing you could not have determined for free. Fix the known problems first, then test to find the unknown ones. A penetration test is a discovery tool, and paying discovery rates to be told what you already suspect is poor value.

The second is when the requirement is genuinely a checkbox and the risk is low. An early-stage product holding no sensitive data, with a buyer who wants confirmation that some testing has occurred, may be adequately served by an automated scan with a human review of the output. That is a smaller purchase, it is honest about what it is, and it can be upgraded later. What you must not do is present it as a penetration test, because the difference is visible in the report.

The third is when a different assessment would find more per dollar. If your architecture has never been reviewed, a threat modelling session finds design flaws that no black box test reaches. If your cloud configuration has never been assessed, a configuration review covers far more ground per day than an application test. If a specific new feature handles money or credentials, a targeted code review of that feature beats a broad test of the whole product. Firms that only sell one thing will recommend that one thing, which is worth remembering when the recommendation arrives.

Frequency deserves the same scepticism. Annual testing plus testing after material architectural change is the standard expectation and satisfies most auditors and buyers. Quarterly testing of an application that changes slowly is usually a firm selling a subscription rather than a genuine need, and the money is better spent on continuous scanning between annual tests. What we scope and how we price it is on the security page, and if you want a second opinion on a quote you have already received, send us the scope and the number and we will tell you what it should contain.