What penetration testing is: scope, phases, deliverable and retest

What a pentest is, and what it is not

A pentest is an engagement defined by three things: written permission, a closed scope and an objective. Without all three, it is not a pentest.

The work consists of doing what an attacker would do: finding what you have exposed, finding flaws, chaining them and proving how far that gets. The important word is proving. A pentest does not say "this might be exploitable": it exploits it, in a controlled way, and shows you the evidence.

What it is not:

• It is not a scanner pass. A scanner finds old versions and default configurations. It does not find that customer A’s invoice identifier works inside customer B’s session, because that requires understanding what your business does.
• It is not a compliance audit. An audit checks that you have a control; a pentest checks whether that control holds.
• It is not a guarantee. It says what was found in that scope and on that date. A clean pentest means whoever ran it did not get in with that time and that scope, not that nobody can get in.
• It is not a red team. A pentest goes for coverage, finding everything it can inside the scope. A red team goes for a specific objective without warning the defenders, and what it measures is whether anyone notices.

Pentest or vulnerability scan: the confusion that costs most

It is the question every first-time buyer asks, and the reason people pay for a pentest and receive something else.

A vulnerability scan is automated, broad and recurring. A tool is run across many assets, compares versions and configurations against a database of known flaws, and returns a list. It is cheap, it can be run every month and it is good for what it is good for: knowing what you have left unpatched.

A pentest is manual, narrow and one-off. A person tries to get in. It costs more, it covers less surface and it finds what no tool sees: business logic flaws, permissions that do not separate one customer from another, chains of three harmless things that together grant access.

They do not compete, they are sequenced. The recurring scan is hygiene and goes first, because using a pentest to find something a scanner would have shouted about for free is throwing money away. The pentest comes afterwards and answers a different question.

How to tell what you are being sold, with a single question: ask for the sample report. If it has hundreds of findings, all in the same format and none with a reproducible request, it is a scanner export with a cover page.

What is decided before it starts

This phase is not billed and it decides the whole result. All of it is closed in writing and taken together it is called the rules of engagement.

• The scope, itemised. Domains, IPs, applications, APIs, cloud accounts, networks, mobile apps. And what stays out, with the same clarity. Before closing it, it helps to know what you really have exposed, which almost never matches the inventory: that is your attack surface.
• The starting point. With no information and no credentials, with documentation, or with a username and password for every profile. The more that is given, the more is covered in the same time, because no days are spent working out what you already know. Starting blind tests the reconnaissance; starting with credentials tests the application.
• The environment. Production or a copy, and if it is a copy, how it differs. A pre-production with different data and a different configuration does not prove the same thing.
• Window and notifications. When traffic can be sent, who knows and who does not, and who gets called if something falls over.
• The limits. Denial of service, social engineering against named individuals, real exfiltration of customer data.
• The fast lane. What happens if something critical appears on day one. The right answer is that you are told immediately and it does not wait for the report.

The phases, in the order they actually happen

1. Reconnaissance. What exists, what answers, which versions, which forgotten subdomains, which credentials from your domain are already circulating out there. There is almost always a surprise here that was not in the inventory.
2. Analysis and mapping. How the application works, what roles there are, where the points are at which it is decided whether somebody may do something. This is the phase that separates manual work from automated work.
3. Exploitation. Confirming that a flaw is real by exploiting it, carefully and without breaking anything.
4. Post-exploitation and chaining. What can be reached from there. This is where a "medium" flaw turns into a serious problem, because three small things in a row go further than one big one on its own.
5. Reporting. Writing it properly takes real time and is part of the project, not an extra.
6. Retest. After your team fixes.

The detail of how we do it is in our methodology, and there are two full worked examples written phase by phase: a web application pentest and an internal network one.

Which type of pentest you need

They are named after what is tested, and it is normal to need two or three, not all nine. Start where your business is and with whatever faces the internet.

• Web application. If your product or your operation lives on a website, this is the one.
• API. Increasingly the serious flaw is here and not in the interface.
• External network. Everything visible from the internet.
• Internal network. From a normal workstation: how far somebody gets. It is the path ransomware takes.
• Cloud. Permissions, configuration and trust between accounts, which is where the problem is rather than in the machines.
• Mobile application and wifi.
• IoT, when hardware and firmware are involved.
• AI. For assistants and agents wired to your own data and tools.

If what you want to measure is not the vulnerabilities but the ability to detect and respond, the format is a red team, or an assumed breach exercise that starts from the assumption that the attacker is already inside. And if you do not know which to start with, the usual way in is ethical hacking.

The deliverable, which is all you are left with

When the project ends, what you are left with is a document. What it has to carry:

• A reproducible finding. The exact request, the steps, screenshots or a trace. If your team cannot repeat it, they cannot fix it or check it.
• Business impact, not only technical severity. CVSS is a useful scale and it is not a priority: a medium flaw in the payments system comes before a high one on an internal intranet. The report has to say that, with your own systems in front of it.
• A specific recommendation. "Sanitise the input" is a category, not a recommendation.
• An executive summary that stands on its own, because whoever approves the remediation budget is going to read that page and not the other forty.
• What was tested and came back clean. Without it you cannot tell what is fine from what was never looked at.
• Methodology and coverage, so that a year from now it is clear what that report actually covered.

A PDF is a document; findings inside your team’s workflow are work already started. In our case they live on the platform from the moment they are found, with their status, instead of all appearing together at the end.

The retest, which is where the report turns into an improvement

A pentest without a retest is a photograph: somebody says what is wrong, your team fixes it and nobody checks that it is fixed. It happens a lot that the fix closes the path that was tested and leaves the one next to it open.

What has to be closed off in the contract, beforehand and not afterwards: whether the retest is included or billed separately, how long you have to request it, whether it covers only what was fixed or also whatever changed around it, and what document it produces. The usual output is a version of the report with each finding marked as fixed, mitigated or open, which is what you later show a customer or an auditor.

And something that costs nothing and avoids almost every deadlock: agreeing beforehand who fixes, within what deadline by severity, and who can decide that a risk is accepted instead of corrected.

How long it takes, how it is priced and what the rules ask for

You will not find a price here, and that is on purpose: a number without your scope in front of it is not information, it is bait. What can be explained is what moves it, which is what you need in order to ask for a quote without being handed a template figure.

A pentest is priced in days of work, and the days come from:

• The real size of the scope. Not how many applications, but how many distinct functions and how many roles there are. One application with five user profiles is far more work than five applications with a single profile.
• The starting point. Starting blind burns days working out what you already know.
• The type. An IoT pentest involves hardware and timings that a web one does not.
• Whether a retest is included and how many rounds.
• Formal requirements. A report for an auditor, or for a customer who demands it by contract, carries more writing work.

On duration, what can be said without inventing anything: the testing part is usually a good deal shorter than the whole project, because the scope, coordinating access, the report and the retest also take up calendar. If somebody offers you "the whole infrastructure" in two days, what fits into two days is one pass of a tool.

And the compliance side, which is the real reason behind many projects. ENS is Spain’s national security framework for public sector information systems: it requires periodic audit and it reaches whoever sells to Spanish public administration through their contracts. ISO 27001 is not certified with a pentest, but the pentest is the evidence that several of its controls rest on. NIS2, the European directive, reaches the supply chain, so it can arrive as a clause from your customer. And DORA, the European regulation for the financial sector, requires certain entities to run threat-intelligence-led testing, TLPT, which is not a normal pentest. For personal data protection the framework is the GDPR, the European regulation Spanish texts call the RGPD.

The full catalogue is at services, how to choose a provider is in this guide, and for a specific scope, contact.