---
title: "What a real penetration test delivers — and how to spot a cheap one"
description: "A 2026 buyer's guide to penetration testing — what's actually in scope, the deliverable you should receive, how a pentest differs from a vulnerability scan, the red flags of a cheap test, and why fix-PRs beat an 80-page PDF."
date: 2026-05-14
updated: 2026-05-14
author: "Dezső Mező"
tags: "Cybersecurity, Penetration testing, Security audit, Buyer guide, EU"
slug: what-a-penetration-test-delivers-2026
canonical: https://dfieldsolutions.com/blog/what-a-penetration-test-delivers-2026
---

# What a real penetration test delivers — and how to spot a cheap one

Most teams buy a penetration test without knowing what a good one produces. Here's what should be in scope, what the deliverable looks like, and the red flags that mean you bought an automated scan with a nicer cover page.
Most teams buy a penetration test the way they'd buy insurance — because a customer's security questionnaire, an investor, or a NIS2 obligation said they need one. That's a fine reason to start, but it means the buyer often can't tell a real test from an automated scan with a nicer cover page. The two cost wildly different amounts and deliver wildly different value. This guide is the buyer's-side breakdown: what a real penetration test actually covers, what the deliverable should look like, and the red flags that tell you the quote in front of you is the cheap kind.

**TL;DR**
- A real pentest is manual · a human attacking your system the way a real adversary would. An automated scan is one input, not the test.
- Scope it explicitly · what's tested (web app, API, network, cloud, the LLM layer), what isn't, and the rules of engagement — in writing, before it starts.
- The deliverable that matters · reproducible findings, severity-rated, plus fix proposals against your actual repo, plus a retest that verifies the fixes held.
- Red flags · a price under a few thousand euros, an 80-page auto-generated PDF, no named tester, no retest, no exploitation (just "this looks vulnerable").
- Know what you're buying · a pentest, a vulnerability scan and a compliance audit are three different things. Buying the wrong one is the expensive mistake.

## What a penetration test is — and isn't

A penetration test is a controlled, authorised attack on your system, performed by a human, to find the weaknesses a real attacker would exploit and to prove how far they'd get. The word that does the work is performed by a human. Automated tooling is part of any modern pentest — it covers ground fast — but the tooling finds candidates, not conclusions. A scanner flags a thousand "potential" issues; a tester works out which three actually chain into a breach, and proves it.

What a pentest is not: it is not a vulnerability scan (that's automated, continuous, and cheap), and it is not a compliance audit (that's a paperwork exercise against a control framework). All three are useful. They are not interchangeable, and a studio that blurs them in the quote is either confused or hoping you are.

## What's actually in scope

A real engagement is scoped before it starts, in writing. "Test our security" is not a scope. A proper scope names the targets, the boundaries, and the rules of engagement.

- Targets · which systems are in — the web app, the public API, the cloud configuration, the internal network, the mobile app, and increasingly the LLM / AI layer if you ship one.
- Out of scope · what the tester must not touch — third-party services you don't own, production data deletion, denial-of-service. Stated explicitly so nothing is ambiguous.
- Rules of engagement · test windows, who to contact if something breaks, whether it's black-box (no internal knowledge), grey-box (some), or white-box (full source access).
- Standards · what the test is measured against — the OWASP Top 10 for web, the OWASP API and LLM lists where relevant, and a recognised methodology so coverage isn't ad hoc.

> **TIP:** Grey-box or white-box testing usually finds more for the same money — handing over source access lets the tester spend hours on real exploitation instead of on reconnaissance. Black-box only makes sense when the goal is specifically to simulate an outside attacker with zero knowledge.

## The methodology, in plain terms

A structured pentest moves through recognisable phases. You don't need to run them — but you should recognise them in a proposal, because a quote that can't describe its own method is a quote for something else.

1. Reconnaissance · mapping the attack surface — what's exposed, what technologies are in use, where the entry points are.
2. Scanning · automated and manual probing to enumerate candidate weaknesses across the scoped surface.
3. Exploitation · the actual test — proving which candidates are real by exploiting them in a controlled way, and showing the impact.
4. Post-exploitation · how far a foothold goes — privilege escalation, lateral movement, what data becomes reachable. This is what separates "a bug" from "a breach".
5. Reporting · every confirmed finding written up so you can reproduce it, severity-rated (typically with CVSS), with a concrete remediation.
6. Retest · after you fix, the tester re-runs the findings and verifies the fixes actually held. A test without a retest is half a test.

## The deliverable: what you should receive

The report is where cheap and real diverge most visibly. A real deliverable is built to be acted on, not filed.

- Reproducible findings · each one with the exact steps to trigger it. If your engineer can't reproduce it from the report, it can't be fixed with confidence.
- Severity that means something · rated consistently (CVSS or an equivalent), so you fix the critical path first and don't drown in low-risk noise.
- Remediation you can act on · not "improve input validation" but a specific fix — ideally a pull request opened against your actual repository.
- An executive summary · one page a non-technical stakeholder can read: what was tested, what was found, what the real risk is.
- A verified retest · documented confirmation that the fixes closed the findings. This is the artefact a customer's security team or an auditor actually wants.

> **WARN:** An 80-page report is not a sign of thoroughness — it's usually a sign of an automated scanner's raw output pasted in. A real report is shorter, because every finding in it is confirmed. Length is a vanity metric; reproducibility is the real one.

## Red flags: how to spot a cheap test

If a quote shows several of these, you are buying an automated scan dressed up as a penetration test.

- A price well under a few thousand euros · real manual testing is senior engineering time; a serious web-app test is dozens of hours.
- No named tester · you should know who is doing the work and see their background. "Our team" with no names means a tool ran it.
- No exploitation · findings phrased as "this appears vulnerable" rather than "we exploited this, here's the proof". Appears is scanner language.
- No retest included · if verifying your fixes costs extra, the engagement was scoped to end before the value does.
- An 80-page PDF as the headline selling point · volume substituting for confirmation.
- No scoping conversation · a real test starts with a discussion about what's in scope and why; a flat order form does not.

## Pentest, scan, audit — which do you actually need

**By the numbers**
- Vulnerability scan: Automated, continuous, cheap · catches known issues fast
- Penetration test: Manual, scoped, periodic · proves real exploitable risk
- Compliance audit: Paperwork against a framework (NIS2, SOC 2, ISO 27001)
- Most common mistake: Buying one when the obligation needed another

You likely need more than one. A vulnerability scan should run continuously in your pipeline. A penetration test belongs before a major launch, after a significant architecture change, and on a regular cadence — annually is a common floor. A compliance audit happens when a framework or a customer demands it. If a customer questionnaire says "penetration test" and you hand them a scan report, you fail the question — and vice versa.

## How DField Solutions runs a test

We run penetration testing the way the rest of our work runs: scoped up front with a fixed price, manual testing against the OWASP web, API and LLM lists, and a deliverable built to be acted on. Findings come as fix-PRs opened against your repository — not an 80-page PDF — each one reproducible, severity-rated, and with the impact proven. A retest after you merge the fixes is part of the engagement, not an upsell. The standard audit runs about two weeks; the report and the fix-PRs land by the end of week two.

If you're scoping a test — for a launch, a customer's security review, or a NIS2 obligation — the [cybersecurity service page](/services/cybersecurity) covers how we work, and a [30-minute discovery call](/contact) is the fastest way to define scope. If you want the pricing bands first, the [pricing page](/pricing) has them.

**Key takeaways**
- A penetration test is manual exploitation by a human — an automated scan is one input, not the test.
- Scope it in writing first: targets, exclusions, rules of engagement, the standard it's measured against.
- The deliverable that matters is a reproducible, severity-rated finding plus a fix-PR plus a verified retest.
- Red flags: a price under a few thousand euros, no named tester, no exploitation, no retest, an 80-page auto-generated PDF.
- A scan, a pentest and a compliance audit are three different things — match what you buy to what the obligation actually requires.

---

Source: https://dfieldsolutions.com/blog/what-a-penetration-test-delivers-2026
Author: Dezső Mező · Founder, DField Solutions
Site: https://dfieldsolutions.com