Buying Guides

How to Buy Penetration Testing

The words "penetration test" cover everything from an automated scan with a cover page to a six-week manual engagement by named specialists. This guide explains how to scope the work, what genuinely drives the price, and how to tell a serious provider from a report generator.

PentestOps by Extranet Systems Updated 28 July 2026

Start with the decision the test has to support

Most buying processes go wrong in the first meeting, because the organisation asks for "a penetration test" before deciding what the result is for. There are only a handful of real reasons to buy one, and each points at a different kind of work.

The common drivers are: a customer, insurer or auditor has asked for evidence; a significant release or migration is about to go live; you have never tested and want a baseline; an incident has raised the question of what else is exposed; or a regulator expects control effectiveness to be tested on a defined cadence.

Write the driver down in one sentence before you speak to a provider. If your largest customer wants a report before renewal, the deliverable and the provider's credibility matter more than raw depth. If you are moving the whole estate into a new cloud tenancy, depth matters more than the paperwork. Providers can serve either goal well, but rarely with the same proposal.

If you are still working out the vocabulary, start with what penetration testing is and come back to this guide.

Scanner, platform or human engagement

Three quite different products are sold under overlapping names, and buyers routinely compare quotes for one against quotes for another. Knowing which one you are reading is the single most useful skill in this process.

Option	What it actually is	Best when	Watch for
Vulnerability scanner	Automated detection of known issues against a target list	You need broad, frequent coverage and a patching worklist	Findings are unvalidated, so false positives land on your engineers
Continuous testing platform	Scheduled discovery, scanning and safe exploitation with evidence	Your estate changes faster than an annual test can track	Ask precisely what "exploitation" means and what is out of reach
Human engagement	Named testers working a defined scope for a fixed window	You need creative testing of business logic, or a signed report	Point in time by definition; drift starts the day after it ends
Bug bounty	A crowd of researchers paid per valid finding	You have mature triage capacity and a public-facing product	Coverage is unpredictable and it is not scoped assurance

Most mature programmes use more than one

A common and defensible shape is continuous automated testing as the always-on layer, with a human engagement each year or before a major release for the creative work automation does not do well. Automation is good at breadth, repeatability and speed. It is weak at multi-step business logic, at judgement calls about materiality, and at the lateral thinking that turns three harmless findings into one serious one.

Buying one layer and calling it a programme is where most coverage gaps come from. Decide deliberately what you are leaving uncovered.

Scoping: the part that decides everything else

Providers quote against what you give them. A vague scope produces a vague quote, an unfocused test and, eventually, an unpleasant conversation about what was included. Scope also drives price and duration more than any other variable, so this is where your effort pays back.

The checklist below is deliberately specific. Work through it once and you will be able to brief four providers identically, which is the only way to compare their responses honestly.

Asset list. Every domain, public IP range, application, API, cloud account, Kubernetes cluster and internal subnet you want in scope, named explicitly rather than described as "our environment".
Ownership and authorisation. Confirm you own or are authorised to test each asset. Anything hosted or operated by a third party needs written permission from that party before testing starts.
Test type per asset. External, internal, web application, API, cloud configuration, identity or mobile. One asset often needs more than one.
Authentication. Unauthenticated, authenticated as a standard user, or authenticated at several privilege levels. This changes the findings more than any other single decision, and it changes the price.
Environment. Production or a like-for-like staging copy, and an honest statement of how closely staging matches production.
Data. Whether real customer or personal data is present, and what a tester may do with anything they can reach.
Windows and constraints. Permitted testing hours, change freezes, rate limits, fragile systems, and anything that must not be touched at all.
Denial of service. Almost always excluded. Say so explicitly rather than leaving it to interpretation.
Social engineering and physical testing. In or out. Both usually need separate authorisation and separate legal review.
Contacts. A technical contact, an escalation contact and an out-of-hours number for a genuine incident during testing.
Success criteria. What a good outcome looks like, and what you will actually do with the findings once you have them.
Retest. Whether verification of fixed findings is included, how long you have to use it, and whether it produces an updated report.

What actually drives the price

Quotes differ for understandable reasons. If you know the drivers, you can read a proposal and work out where the money is going, which is far more useful than comparing headline numbers.

Number and type of assets. The primary driver in nearly every pricing model, whether it is expressed per asset, per day or per credit.
Depth. An automated pass over an application costs a fraction of a manual review of its authorisation logic.
Roles and authentication. Each additional user role multiplies the authorisation test cases a tester has to work through.
Manual effort. Skilled human days are the expensive component. Automation is comparatively cheap and scales differently.
Reporting requirements. A technical findings list is inexpensive. An executive report, compliance mapping and an attestation letter add work.
Retesting. Included, chargeable or time-boxed. All three are legitimate and they are not comparable.
Timing. Out-of-hours testing, tight deadlines and short-notice bookings attract premiums almost everywhere.
Cadence. Continuous programmes are usually priced per asset per period. One-off engagements are priced per day or per fixed scope.

Reading a suspiciously cheap quote

A quote well below the field usually means less manual effort than you assumed, not a better deal. Ask how many tester days are included and what proportion of the work is automated. Both answers can be legitimate; you just need to know which product you are comparing.

Pricing models vary as much as prices. Day rates, per-asset subscriptions, credit pools and fixed-scope packages all exist, and each favours a different buyer. Per-asset pricing is easy to forecast when your estate is stable, day rates suit a defined one-off, and credit models suit spiky demand but can strand unused value at renewal. Ask for the model in writing alongside the number, and compare a full year rather than a single engagement. Ours is set out on pricing.

How to check a provider's methodology

Every provider says they follow a methodology. The useful test is whether they can name the standard, show you where their process differs from it, and explain why. Vague appeals to "industry best practice" are the answer you get when there is no documented process behind the sales deck.

Four reference points are worth knowing by name. The Penetration Testing Execution Standard defines the phases of an engagement end to end. The OWASP Web Security Testing Guide is the de facto test-case catalogue for web applications, and the OWASP Top 10 is the risk taxonomy most reports map to. NIST publishes SP 800-115, the technical guide to information security testing and assessment, which many public sector contracts still cite. CREST publishes testing guidance and accredits firms against it.

Severity is the other half of methodology. CVSS, maintained by FIRST, is the common baseline, and v3.1 remains the version most tooling and most compliance regimes expect. Ask whether the provider adjusts CVSS for your business context, and whether they factor in real-world exploitation signals such as the known-exploited vulnerability catalogue published by CISA. A severity number with no reasoning behind it is not a prioritisation.

Which standards the methodology maps to, and which phases they perform in practice rather than in the brochure.
How findings are validated before they reach you, and what proportion are manually verified.
How severity is assigned, and whether business context changes it.
Whether exploitation is performed, and what controls stop it going outside the authorised scope.
What evidence is captured per finding, and whether you receive it.
Who does the work: named testers, their qualifications, and whether any part of the engagement is subcontracted.

What a good report contains

The report is the product. Ask for a redacted sample before you sign, and read the remediation advice in particular. Generic instructions to "apply vendor patches" or "validate all input" are a reliable sign that the finding was detected rather than investigated.

An executive summary a non-technical reader can act on, stating overall risk and the first three things to fix.
A scope statement that matches what was agreed, including exclusions and the reason for each.
The methodology followed and the dates the work was performed.
Per finding: what it is, where it is, how it was confirmed, the evidence, the severity with its reasoning, and specific remediation steps.
Reproduction steps an engineer can follow without contacting the tester.
Compliance mapping if you need it, framed honestly as a mapping of findings to a framework rather than a statement that you are compliant.
A machine-readable export so findings can reach your tracker without being retyped by hand.
A named author and a route to ask questions after delivery.

The questions procurement will ask

Security teams choose the provider. Procurement and legal decide whether the contract can be signed. Collecting these answers during evaluation rather than after selection routinely saves several weeks.

Insurance: professional indemnity and cyber liability, with current certificates of currency.
The provider's own security posture, including any certification such as ISO/IEC 27001, and how they protect the findings they hold about you.
Data handling: where your data is stored, who can access it, how long it is retained and how it is destroyed.
Sub-processors and any offshore access, named rather than described.
Contract instruments: master services agreement, data processing agreement, non-disclosure, and a signed authorisation to test.
Personnel: background checks, and whether testers are employees or contractors.
References in your sector, and whether you may speak to them.
Exit: what happens to your data and your reports if you leave.

Paperwork worth having ready

Every credible provider will ask for two documents, and having drafts ready shortens onboarding considerably: a signed authorisation to test naming the exact assets in scope, and a data processing agreement if personal data may be reachable. Ours are published at rules of engagement and DPA.

How PentestOps answers these

PentestOps is a continuous testing platform. It runs discovery, scanning and safe exploitation across your external perimeter, internal networks, web applications, APIs, cloud accounts and identity, on a schedule rather than once a year. It does not replace a skilled human tester working through complex business logic, and we will say so in a sales conversation.

On scoping and price: pricing is asset-wise, so you pay for the assets in scope and scans against them are unlimited within fair use. That maps directly onto the asset list from the checklist above. All paid plans start with a 7-day free trial. A card is required to start your trial and is only charged after the trial ends, unless you cancel first. Plan details are on pricing.

On methodology: our seven-phase process aligns to PTES, the OWASP Web Security Testing Guide v4.2, NIST SP 800-115, CREST testing guidance and CIS Benchmarks. Exploitation is gated by per-tenant rules of engagement with scope enforcement that stops activity outside authorised assets, and every finding carries an evidence trail.

On reporting: findings are scored with CVSS v3.1 with CISA KEV prioritisation, and map to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes. That is a mapping of findings to frameworks, not a statement that you are compliant. Reports are available in multiple formats including PDF, CSV and JSON/API.

On the procurement questions: Extranet Systems Pty Ltd is ISO/IEC 27001:2022 certified, independently audited by Atom Assurances. The platform is hosted in Australia on infrastructure operated by Extranet Systems and customer data is stored in Australia. Authorised personnel in our Bahrain and Egypt offices may access customer data where necessary to operate, support and secure the platform. Retention runs from 1 year to 7 years depending on plan, with 365-day audit logs. The detail is in the Trust Centre.

Frequently Asked Questions

How much should a penetration test cost?

There is no defensible single answer, because the same words describe an automated scan and a multi-week manual engagement. Price is driven by the number and type of assets, the depth of manual work, the number of authenticated roles, and the reporting you need. Ask every provider for the pricing model in writing and compare the total cost over a year. Our own asset-wise model is on pricing.

How long does a penetration test take?

A traditional engagement is usually quoted in tester days, and delivery of the report typically follows the testing window by a week or two. Platform-based continuous testing inverts this: the first results arrive quickly and testing then runs on a schedule, so there is no single completion date. Ask when you will see the first finding and when you will see the final report, because they are different questions.

Should we test production or staging?

Production is the only environment that reflects real configuration, real data flows and real integrations, so results from it are the ones that matter. Staging is safer but only useful if it genuinely mirrors production. A common compromise is to run intrusive testing against staging and non-intrusive testing against production, with a clearly documented difference between them.

Is a vulnerability scan the same as a penetration test?

No. A scan detects patterns that indicate a known issue and reports them without confirming they are exploitable. A penetration test attempts to prove impact, whether by a human tester or by safe automated exploitation, and delivers evidence. Buying a scan and calling it a test is the most common mismatch in this market.

How often should we test?

Match the cadence to your rate of change, not to the calendar. An estate that ships weekly is not meaningfully covered by an annual test, and several regulators now phrase their expectations around control effectiveness rather than an interval. Many organisations settle on continuous automated testing with a periodic human engagement layered on top.

Is a retest included in the price?

Sometimes, and the terms vary widely. Ask three things: whether verification of fixed findings is included, how long you have to use it, and whether it produces an updated report you can hand to an auditor. A test with no retest leaves you unable to demonstrate that anything was actually fixed.

Do we need permission from our cloud provider before testing?

Policies differ by provider and change over time, so check the current one. In general, testing your own workloads is permitted while testing the provider's own infrastructure or running denial-of-service activity is not. Any asset operated by a third party needs that party's written permission, and a competent provider will ask you for it.

What should we do first when the report arrives?

Read the executive summary, agree the top three items with the people who own the systems, and put every finding into your normal tracker with an owner and a date. Then book the retest. Reports that live in a shared drive without owners are the most expensive way to buy nothing.

Compare us against your own checklist

Run the scoping checklist above, then see how an asset-wise continuous testing platform answers it. Start with a free demo scan against a domain you own, or talk to us about scoping a programme.

Start Free Trial Book a Demo Free Demo Scan