A badly scoped pentest isn't cheap: it's useless

By Kike Gandia · Threats · 14 min read

Illustration of a security testing team marking out on a blueprint which systems fall within the scope of an assessment

Two companies write to us in the same week with the same sentence: "we need a pentest of our application." One ends up with a report of eleven findings, three of them critical, that changes its product plan for the quarter. The other ends up with a forty-page PDF full of HTTP header warnings that nobody is going to read. The team that did the work was just as good in both cases. What changed was the scope: what was put on the table, with what access and against which environment.

This is not an administrative formality before the real work begins. The scope is the work: it decides what can be found and what literally cannot appear in the report. And it is almost always settled in a hurry, over email, before anyone has asked the questions that matter.

What a pentest actually proves

It's worth saying early, because it frames everything else: a penetration test does not certify that a system is secure. It certifies that a team with limited time, specific access and agreed rules found (or did not find) certain things within a window of dates. It is a snapshot, not a clean bill of health.

Far from making it less valuable, that is exactly what makes it useful: it turns an abstract discussion about risk into a list of concrete things someone reproduced on your systems. The difference between "we should review the permissions" and "with a support user's account you can access any customer's records, here is the screenshot" is what moves budgets and priorities.

An automated scan doesn't do that. It finds known patterns and lists them for you; it's cheap, it's fast and it needs doing, but it can't tell the exploitable from the theoretical and it doesn't understand your business logic. Most of the findings that really matter (bypassing an approval flow, seeing another customer's data, chaining two minor flaws all the way to admin) only surface when a person understands what the application is for.

The five decisions that change the outcome

With the same vendor and the same budget, these five decisions determine what you get. None of them is technical: all five are made before anyone opens a terminal.

The five decisions that set the scope of a security test, with what getting each one right or wrong costs: (1) which assets are in scope and which are excluded in writing; (2) the real volume, which is driven by roles and business flows, not the number of screens; (3) how much information the testers work with (black box, gray box or white box), where gray box gives the best return per euro spent; (4) which environment is tested, because production requires an agreed window, a stop criterion and a slow pace; and (5) which deliverable is needed and for whom, since sometimes an attestation letter is enough instead of a full engagement. All five are answered in the pentesting scoping form, at /en/resources/pentesting-scoping-form/.

Black, gray or white box: the most expensive mistake

Many organizations ask for black box testing for a reasonable reason: they want to know what an outside attacker would see, with no help. It's a legitimate question, but it usually gets answered at a price that doesn't show up on the invoice.

In black box testing, a large share of the hours goes into reconstructing from the outside what the organization already knows: which endpoints exist, which roles there are, what things are called. That time is not spent looking for flaws. The result is a shorter report from less productive time, and a considerably higher cost per finding.

Approach	What the team is given	When it makes sense
Black box	Nothing but a target	Validating external exposure or measuring the blue team's detection capability
Gray box	Credentials for each role and basic documentation	The default choice for almost everything: it covers more surface in the same time
White box	Credentials, documentation and source code	Critical products, regulatory evidence, or when you care about the root cause and not just the symptom

For regulatory evidence (NIS2, the ENS, the technical documentation for the Cyber Resilience Act or a customer questionnaire), gray or white box delivers far more: what's being asked for is not a simulation of an attacker but proof that the product has been examined seriously.

Testing in production costs more than it seems

When there is no representative staging environment, testing ends up in production. It can be done, and often is, but it comes at a price: an agreed window, someone reachable throughout the engagement, a written stop criterion, explicit exclusion of denial-of-service testing and a deliberately slow pace. All of that is hours.

There is one case where it is simply not negotiable: industrial environments in operation. No active testing is done on PLCs that are controlling a live process. Without a replica or a shutdown window, honest work is limited to passive and configuration review, and that has to be agreed before signing, not discovered halfway through the project.

If the environment holds real personal data, the data processing agreement has to be formalized before starting and access kept to the minimum. Demonstrating access is enough: there is never any need to extract real data as evidence.

The mistakes we see again and again

Commissioning a test before the incident is closed. If there is an active intrusion, or a suspected one, what's needed is containment and forensics. A pentest on a possibly compromised environment mixes your findings with the attacker's activity and serves neither purpose.
Running another engagement with the previous findings still open. If important issues remain unfixed, the new engagement will find the same things. You will have paid twice for the same report.
Asking for a full engagement when what's required is a letter. Many tenders and customers are satisfied with an attestation stating scope and dates. Read the exact requirement before sizing anything: it is the cheapest deliverable to produce.
Forgetting about third parties. If an asset is hosted or built by someone else, you will also need their authorization, and getting it is your job. It is the single biggest cause of delays in getting these projects started.
Not budgeting for the retest. A report without closure verification leaves the important question unanswered: was it really fixed? The retest is cheap compared with the engagement, and it is what turns the report into a real improvement.
People-focused exercises without formal backing. Simulated phishing is agreed in advance with management and, where applicable, with employee representatives: no names in the report and no disciplinary consequences. Otherwise it stops being a technical exercise and becomes an employment problem.

Why this matters more now than three years ago

For a long time, security testing was a voluntary decision made by security-minded teams. Today it arrives through three channels that don't depend on anyone's goodwill: regulation (NIS2 and its risk management obligations, the ENS in the public sector, the CRA for products with digital elements), the supply chain (your customer audits you because they are being audited) and insurance and due diligence in any corporate transaction.

The practical effect is that the report no longer stays in-house. It will be read by a customer, an auditor, a regulator or someone deciding on an investment. That changes what you should demand of it: an unambiguous written scope, a recognizable methodology, reproducible evidence and an honest statement of what was not tested.

Scope is decided by looking outward, not just inward

Everything so far looks inward: your assets, your access, your environment. The other half of the question is missing, and it is almost never asked: how are attackers getting into companies like yours right now? Without that data point, scope gets decided on gut feeling or on whatever was done last year.

We answer that half with our own data. CyberPanorama is the cybersecurity module of 0data, our autonomous dashboard: several coordinated agents collect and cross-reference more than 600 sources to maintain a live, real-time threat model instead of a quarterly report that is already out of date the day it comes out. Correlate, measure and predict: that is what lets us warn a client before, not after.

CyberPanorama threat network, the cybersecurity module of 0data: 1.1 million correlated signals over a 30-day window from sources such as PhishTank (789,000), Phishing Army (179,000), IOCs (45,000), intelligence aggregators (16,000), reconnaissance (10,445), OpenPhish (15,000), Exploits DB (3,038), Ransomware Live (2,476), vulnerabilities (748) and MITRE techniques (714), with an overall risk level of HIGH (66/100). The 24-hour projection estimates 838,000 signals, split into phishing (90.5%), IOCs and malicious URLs (5.6%), reconnaissance (1.8%), dark web and DeFi (0.9%), OFAC sanctions (0.5%) and vulnerabilities (0.3%). Snapshot of the window closed on September 17, 2026.

That breakdown changes conversations. If nine out of ten signals in the last month are phishing, debating whether the web pentest lasts eight or ten days is optimizing the wrong thing: what needs looking at first is email and people. And the other way around: when the dashboard shows activity in a specific sector, scoping for companies in that sector stops being a template and becomes an informed decision.

MITRE ATT&CK kill chain coverage according to CyberPanorama, with 889 observed techniques: stealth (148), persistence (113), privilege escalation (96), credential access (67), execution (64), impair defenses (56), resource development (50), discovery (49), reconnaissance (46), command and control (45), collection (41), impact (33), lateral movement (23), initial access (22), exfiltration (19) and defense evasion (17). The most populated phases are the post-intrusion ones, not the perimeter. Ransomware victims by sector over 30 days: industry and manufacturing (174), professional services (120), technology (116), healthcare (102), other (93), retail and e-commerce (65), financial services (57), transportation (45) and agri-food (38).

Look at where the techniques pile up: stealth, persistence and privilege escalation. All of that happens after someone has got in. A scope that stops at the perimeter touches none of the three, and it is exactly the scope that gets commissioned by default when nobody has looked at the data.

The difference between reactive and proactive security isn't having more tools: it's having someone watching the landscape continuously who can tell you what changed in your sector this week. Everything else is waiting for your turn.

The report isn't the end: where do our findings live?

Let's go back to the most expensive mistake on the earlier list: not budgeting for the retest. It is really the symptom of something bigger: the report is delivered and that's where the system ends. From then on, it's a PDF by email, a tracking spreadsheet someone maintains by hand, a message thread for every question and, three months later, nobody can say with certainty what was fixed and what wasn't.

That gap is what KOMPLIANCE, the vulnerability management module of 0data, fills. It isn't a report viewer: it's where each finding has an owner, a deadline, a status and a verification step that closes it.

KOMPLIANCE findings board, the 0data vulnerability manager, with sample data: count by severity (3 critical, 11 high, 24 medium, 38 low) and a table in which each finding has an identifier, severity, source (manual pentest, code review, SCA on the SBOM, autonomous agent, SAST, scanner or license check), assigned owner, status (open, in remediation, in retest or closed) and remaining SLA time. The technical report, the executive report and the SBOM are exported from the same board.

Look at the source column. A finding can come from the manual pentest, from an integrated hacking tool, from an autonomous agent that keeps sweeping between engagements, from the code review of the connected repository or from the SBOM license check. These are different sources that in practice find overlapping things, and the value lies in treating the same flaw seen through three channels as one finding, not as three open tasks for the same team.

KOMPLIANCE workflow diagram. Inputs: manual pentest with its evidence, integrated hacking tools with no copy-pasting of output, autonomous agents sweeping continuously between engagements, code review of the connected repository, and SBOM inventory with license checks. Core: deduplication and cross-source correlation, assignment of severity, owner and SLA, a mandatory retest cycle before closure, and full traceability of who saw what and when. Outputs: technical report with evidence and reproduction steps, executive report in business terms, Jira tickets, SIEM feed with what is exploitable, and Slack and Telegram alerts. Benefits: no stray files sent by email, direct access to the technical team that found the flaw, fewer hours spent on management and follow-up meetings, and a traceable retest instead of an "it's fixed now".

What changes day to day is less eye-catching than a critical finding, but it weighs more in the outcome: no more files floating around (the report stops being an attachment that gets forwarded and becomes a status you can look up), the development team has direct access to whoever found the flaw instead of writing to a generic mailbox, and the retest no longer depends on someone remembering. Fewer hours of management, fewer follow-up meetings and a reliable answer to the only question that matters three months later: is this closed or not?

And on the regulatory side, the same place handles what usually lives separately: a complete SBOM, license checks for every component and export of technical and executive reports whenever a customer, an auditor or a regulator asks for them. Which is exactly what Article 14 of the CRA, NIS2 or a customer questionnaire end up demanding, with deadlines, from anyone who doesn't have it in order.

Here we've only covered the part that relates to a pentest. If you want the full picture (the integrations with Nessus, Nuclei, Burp or Black Duck, the triage funnel, matching the SBOM against CISA's KEV catalog, the ISO 27001, CRA and ENS modules, and retesting by surface), it's in KOMPLIANCE: one place for vulnerabilities and compliance.

How to size it without wasting three calls

Almost all of the above comes down to a dozen concrete data points: which assets are in scope, how many of each type there are, what access you can provide, which environment the work happens in, what is explicitly off-limits and what document you need at the end. With that, the work can be sized properly; without it, any quote is a blind estimate that gets revised upward halfway through the project.

So you don't have to work this out on a call, we've published that conversation as a form: the pentesting scoping form walks through those sections and only shows the questions that apply to you based on the assets you select (if all you have is a web application, you answer three sections, not ten). When you finish, it generates a preliminary assessment with any red flags that came up (an open incident, testing in production, earlier findings still open, third-party assets), which you can send to us or keep for yourself.

If all you want is a ballpark figure before talking to anyone, the pentesting calculator gives you a market range in under a minute. And if you'd rather have someone review the scope with you before deciding what's in and what's out, that's what our team is for: half an hour well spent at the start saves weeks later on.

Related service

pentesting service

Topics

#Pentesting #Security-Audit #Red-Team #Compliance #NIS2 #Vulnerability-Management #Threat-Intelligence #0data

Keep reading

Scope your testing with an expert