What a Real Penetration Test Delivers in 2026

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.

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.

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.

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

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 covers how we work, and a 30-minute discovery call is the fastest way to define scope. If you want the pricing bands first, the pricing page has them.