How to compare penetration testing proposals

First read your own request, not the replies

Send the same request to five firms and five documents come back that look alike and describe different work. That is rarely dishonesty. A request for a penetration test of "our systems" leaves every vendor to guess the boundary, the depth and how much of the work is done by hand, and each one guesses in the direction of the bench it already has.

So the first document to check is the one you sent. If it did not name assets, environments and accounts, the replies cannot be compared, because they are answers to five different questions. Fix that first: decide the scope before you ask for a price, then re-issue to the same list. The delay costs a week and removes most of the spread you were about to try to interpret.

What follows is what to read in the replies that come back, in roughly the order each item moves the price.

Method: the standard, and which parts of it apply

A proposal should name the testing standard it works from. NIST SP 800-115 sets out the planning, discovery, attack and reporting phases most engagements still follow, and the OWASP Web Security Testing Guide enumerates application test cases in far more detail than any quote will restate.

Naming a standard is the low bar and everyone clears it. What separates documents is whether the method is tied to your assets. A web application test that promises the testing guide in full and budgets three days has not read its own plan, and a proposal that lists the same eight phases for a mobile client, an internal network and an API is describing a template rather than an approach.

Ask two questions in writing. Which sections of the standard apply to the systems in scope, and which are deliberately excluded and why. A vendor that can answer the second one has thought about your estate; a vendor that treats the question as an accusation has not.

Who actually performs the test

The name on the cover and the name on the keyboard are not always the same. Ask who will do the work, how many people, how their time is split across the days quoted, and whether any part of it is subcontracted. A firm that will not name the testers before signature is unlikely to name them afterwards, and subcontracting is not disqualifying as long as it is disclosed and the same terms bind everyone who touches your data.

Certifications describe a floor rather than a ceiling. OSCP, CREST and their equivalents show that someone has worked hands-on under exam conditions; they do not show that the tester has seen a stack like yours. The better evidence is two redacted findings written by the person assigned to your test. You are reading for whether the writing explains an attack path, or only restates a tool's description of a vulnerability.

This is the line item worth paying more for. A scoped, manual penetration test is a purchase of attention, and the person spending it is the variable that moves the result furthest.

Where the price comes from, line by line

Price differences usually resolve to three inputs: tester days, seniority, and how much of the engagement is automated. A total quoted without days is asking you to compare on faith. Once days are visible, the comparison stops being about the number at the bottom.

Below is an illustrative example, not a real quote: two proposals for the same fifteen-endpoint API and one external network range, set side by side.

Read the middle rows rather than the last one. Proposal A is cheaper because it is a shorter test whose manual half is unspecified and whose retest is priced later. That may still be the right purchase, if what you need this quarter is coverage rather than depth, which is the difference between a test and a scan wearing different clothes. What you should not do is read the two totals as prices for the same thing.

Deliverables, and the clock running on the retest

Every proposal promises a report, so the deliverables paragraph tells you almost nothing. Ask for a redacted sample and read one finding end to end: reproduction steps someone on your team could follow, evidence that shows the impact rather than a screenshot of a scanner, the affected assets listed individually, and a fix that names the change rather than the goal. What a report has to contain is a settled list, and a sample answers it faster than any amount of correspondence.

Severity should arrive with its method. If findings are rated using CVSS, ask whether the vendor adjusts for your environment or ships base scores unchanged, because a base score knows nothing about which of your systems is internet-facing. A rating you cannot argue with is a rating you cannot act on either.

Then the retest. Is it included, does it cover every finding or only the high ones, does it require the fixes to land inside a window, and does the window start at report delivery or at your acceptance? Remediation in a regulated environment takes longer than most windows allow. A retest quoted separately, six weeks after the fixes ship, is a second engagement with a second procurement cycle behind it.

The terms that decide how the engagement actually runs

Four clauses do most of the work after signature. Where test evidence is stored and for how long, and whether it can be deleted on request. Who inside the vendor can read it. What happens when a tester finds an active compromise rather than a vulnerability, which is a phone call that has to have a number attached to it before the test starts. And the testing window, including whether out-of-hours work is included or billed.

The authorisation letter is the one document that is as much your responsibility as the vendor's. It names the systems, the dates and the source addresses, and it is signed by someone who can grant that permission for every asset listed. Where a third party hosts an asset, their written consent belongs in the same file. Testing a platform you do not control, without the operator's agreement, is not a scoping oversight.

One more distinction hides in the paperwork. An engagement that is really an objective-based red team rather than a scoped test needs different terms, because the defenders are not told and the escalation path has to work when the people who would normally answer the phone are the ones being tested.

The second reader in Dubai and Abu Dhabi

A proposal in this market is written for two readers. The first is you. The second is whoever assesses you, and which one that is depends on where you operate. An entity inside Dubai government, or supplying it, works to the regime set by the Dubai Electronic Security Center, and the report you commission is often read by the entity you serve rather than only by your own board. An Abu Dhabi healthcare provider answers to ADHICS, where the question an assessor asks is whether the systems the standard names are the systems your scope named. Licensed banks answer to the Central Bank, and federally the UAE Information Assurance Standard, published under the national cyber security framework, sits behind the same expectation: testing that was performed, evidenced, and acted on.

That changes the comparison. Ask each vendor which regime it expects the report to be read under and what it changes in the deliverable, because a document written for an internal audience and a document that will be handed to an assessor are not the same product. Free-zone entities in Dubai and mainland companies in Abu Dhabi also arrive at these obligations by different routes, through contract terms in one case and sector regulation in the other, and a vendor that has worked in both emirates will ask which applies before quoting. If you are still deciding which engagement answers the requirement, the full list of assessments is the place to start.

Frequently asked questions