Resources

Guidance from the field.

A buyer's guide, scoping worksheets, the questions worth asking any vendor, and plain-English definitions — free, ungated, and useful whether you hire us or not.

Buyer’s guide

How to buy a penetration test

Most people buying a penetration test are doing it for the first time, often because a client or auditor asked for one. Here are three of the steps we would take if we were on your side of the table — the full guide covers scoping, pricing and how to compare proposals.

Step 01

Know what you're actually being asked for

“We need a pentest” usually originates somewhere specific — a SOC 2 control, an enterprise client’s vendor questionnaire, a cyber insurance form. Find the original wording. It often specifies scope, frequency or independence requirements that determine which engagement you need, and it will save you paying for the wrong thing.

Step 02

Read the report before you buy it

This is the single highest-signal thing you can do. A report shows whether findings are reproduced with real evidence, whether remediation advice is specific to your stack or copied from a template, and whether anyone considered business impact. Any firm that will not share a redacted sample is telling you something.

Step 03

Plan what happens after

A test that finds problems and never verifies the fixes is half a service. Check whether remediation re-testing is included and for how long, who you can ask questions of during remediation, and what happens if something critical is found mid-engagement.

One thing worth knowing

If a firm quotes you a fixed price before asking what you are running, they are guessing. Scope determines effort, and effort determines price. A quote that arrives without questions is a quote for an engagement nobody has thought about yet.

Read the full buyer's guide

Six sections covering scoping, what drives price, the questions that expose a scan sold as a test, and the warning signs to check a proposal against. Free, and the whole thing is on the page.

Free worksheets

Before you request a quote

Gather these and any firm can scope you accurately on the first pass — which means a faster, cheaper and more honest quote. Take these to whoever you end up hiring, including if that is not us.

Scoping worksheet

What to have written down before the first call
  • The systems in scope, named individually — URLs, IP ranges, API base paths.
  • How many distinct user roles exist, and what each can do that others cannot.
  • Whether testing hits production, staging, or both — and who must approve it.
  • Live host count, not IP range size. A /24 with six live hosts is a small job.
  • Any third-party or shared hosting that needs the provider’s authorisation first.
  • Whether a WAF, rate limiting or IP blocking sits in front of the target.
  • Your technical contact and their availability during the testing window.
  • What is driving the requirement, and the deadline attached to it.

Questions to ask any vendor

Including us — the answers should be specific
  • How many tester-days are allocated, and how are they split between testing and reporting?
  • Who is doing the work, and what is their experience and certification?
  • What proportion of the engagement is manual versus automated?
  • Which methodology do you follow — OWASP, PTES, NIST, something else?
  • Can I see a redacted sample report before committing?
  • Is remediation re-testing included, and for how long after delivery?
  • What is the escalation path if you find something critical mid-engagement?
  • How is our data handled, stored and destroyed after the engagement?
What you actually get

Anatomy of a good report

The report is the deliverable — it is the entire artifact you are paying for. Here is what a useful one contains, so you can judge any report you are handed, from us or from anyone else.

What should be in it

Judge any report against this list
  • An executive summary a non-technical director can act on without a translator.
  • A narrative of how the tester moved from initial access toward something valuable.
  • Every finding reproduced with request and response evidence, not just described.
  • Severity adjusted for your context, not copied from a CVSS base score.
  • Remediation guidance naming your actual stack and versions.
  • Findings no tool could have produced — logic abuse, authorisation bypass, chained escalation.
  • A clear statement of what was tested, what was not, and why.

Warning signs

What a thin engagement looks like on paper
  • Every severity matches the CVSS base score exactly — that is unedited scanner output.
  • No narrative anywhere. A scan has no story to tell because it did not do anything.
  • Findings are entirely CVEs and missing security headers.
  • Remediation advice is generic vendor boilerplate.
  • Page count is padded with tool documentation and methodology filler.
  • No mention of user roles or access boundaries being tested.

Want to see ours?

We will send a redacted sample report on request, before you commit to anything. It is the fastest way to tell whether we are worth hiring — and the fastest way for you to compare us honestly against anyone else you are considering.

Plain English

The terms vendors use

Security firms lean on jargon, sometimes to sound impressive and sometimes to blur what is actually being sold. Here is what the common terms mean.

Vulnerability assessment

Automated scanning that compares your systems against a database of known issues. Broad, cheap, repeatable — and unable to tell you real-world impact.

Penetration test

Manual testing that exploits weaknesses and chains them toward real impact. Narrower, more expensive, and the only thing that answers “what could an attacker actually do?”

Red team

A goal-driven simulation of a real adversary, usually without the defending team knowing. Tests detection and response, not just the presence of vulnerabilities.

Black, grey and white box

How much you tell the tester up front. Black box means nothing, grey box means credentials and basic docs, white box means source access. Grey box almost always gives the best coverage per dollar.

Broken access control

The system checks that you are logged in but not that you are allowed to touch this particular thing. Consistently the most damaging category, and the one automation is worst at finding.

Business logic flaw

A sequence of individually valid requests that produces an outcome nobody intended — skipping a payment step, reusing a one-time discount. Invisible to scanners.

Rules of engagement

The written agreement covering what may be tested, when, by whom, and what is off limits. If a firm does not insist on one, that is a serious warning sign.

Re-test

Verification that your fixes actually worked. Ask whether it is included or billed separately — firms differ enormously, and it changes the real cost.

Prefer to talk it through?

If you've read enough and want a straight answer about your situation, we're one message away.