Penetration testing at nFlo costs from €3,000 net for a web application test up to €11,500 and more for an industrial environment, but the figure on the quote says less about the budget than it seems. An IT director who receives two quotes for “the same” test that differ several times over is usually not looking at two margins — they are looking at two different scopes of work. And the board that approves the spend rarely sees the other half of the bill: the in-house team’s time, the fixes and the retest.
This article breaks the price of a penetration test down into elements you can check and compare. We publish our own price list as an open point of reference, show the costs that sit outside the offer, explain how GDPR, NIS2 and DORA affect the annual budget, and propose a business case that does not rest on invented percentages.
What is penetration testing?
A penetration test is a controlled, authorised attempt to break into systems, networks or applications, aimed at confirming which weaknesses can actually be exploited. From a budget point of view one thing matters most: you pay for specialists’ time, not for a licence or a “product”.
In its SP 800-115 publication of September 2008, the US NIST describes a test in four phases: planning, discovery, attack and reporting. The planning phase sets rules and goals, with no testing at all. Discovery means gathering information, scanning and analysing vulnerabilities. Attack is the attempt to exploit them, and reporting runs in parallel throughout the whole test. Each of these phases takes days of work by specific people — and those days are what make up the price.
The same publication points to the difference that determines the value of the purchase: a scanner only checks whether a vulnerability might exist, while the attack phase exploits it to confirm that it does. That is why a vulnerability scan and a penetration test are not a cheaper and a more expensive version of the same thing — they answer different questions, which we develop in the article on the differences between a penetration test and a vulnerability scan. A broader overview of test types and how they run can be found in our guide to penetration testing.
A single name covers several different services, and each has its own unit of scope and its own price. An external infrastructure test checks what is visible from the internet: addresses, services, remote access gateways. An internal infrastructure test assumes the attacker is already inside the network and checks how far they can get — usually all the way to taking over the domain. Web and mobile application tests focus on logic, authentication and the data sent to the API. On top of that come wireless network tests, industrial environment tests and social engineering tests, which examine people and processes rather than systems. The question “how much does a pentest cost” therefore only makes sense once you know which of these tests you mean.
In short: test price = number of working days needed for the four phases × the team’s rate. Anything that changes the number of days changes the price.
How much does penetration testing cost in 2026?
At nFlo a penetration test costs from €3,000 net (web application, basic package) up to €11,500 net and more (OT/ICS environment). We publish entry thresholds because the price is every buyer’s first question, and an answer of “it depends” without a single number explains nothing.
| Type of test | Price from (net, as of 2026) | Typical delivery time |
|---|---|---|
| Web application — BASIC / STANDARD / ADVANCED package | €3,000 / €5,000 / €9,500 | 5–7 / 7–10 / 14–21 business days |
| External infrastructure | €6,000 | 3–7 business days |
| Internal infrastructure | €8,000 | 5–10 business days |
| Mobile application | €9,500 | 7–12 business days |
| Industrial OT/ICS environment | €11,500 | 5–15 business days |
These figures are lower bounds, not catalogue prices. The BASIC web package covers one application with up to 20 endpoints, STANDARD up to 50 endpoints with an API, and ADVANCED an enterprise-class application with a code review. The details of each variant, including scope, are described on the service pages: penetration testing, web application testing and OT/ICS system testing. What a quote includes and what drives the price is explained in the penetration testing pricing section of the service page.
The price covers the whole cycle, not just the days of attack: the kick-off meeting and agreement on the rules, a test run according to OWASP WSTG, PTES and NIST SP 800-115, a report with proof of exploitation (PoC), a CVSS score and remediation recommendations, and a debrief of the results. The testing team holds OSCP, CEH and GPEN certifications. We list this on purpose, because the same elements are worth checking in every other offer — if one of them is missing, a lower price often stems from exactly that gap.
You will find noticeably cheaper offers on the market. We do not treat that as an accusation — a cheaper test may simply be a shorter test with a narrower scope. The problem arises when a short test is sold as a full one and the buyer compares amounts without comparing scopes. How to recognise that situation is covered in the section on the cheapest offers.
What does the cost of a penetration test depend on?
The cost of a penetration test depends on the number of working days the agreed scope requires, and that number is set by four variables: the type of environment tested, its size, the amount of knowledge handed over to the testers and the constraints under which they have to work. The name of the service — “pentest”, “technical audit”, “security test” — says nothing about the price.
Type and size of the environment
Every type of test has a different unit of scope. In an external infrastructure test what counts are public addresses and services; in an internal test — hosts, network segments and the identity directory, usually Active Directory. In a web application the unit is endpoints, user roles and business logic paths. The OWASP Web Security Testing Guide, version 4.2, divides web application testing into 12 categories, from information gathering to API testing, and every additional role or integration in an application increases the work in several of them at once. We break this down in detail below, in the part on web applications.
Knowledge handed over to the testers
In a black box test the tester starts with no information about the system, in a grey box test they have, for example, a user account, and in a white box test — documentation and often the code. Contrary to intuition, black box is not “the most realistic, and therefore the best”: it consumes days discovering what the company could simply have handed over. For the same budget, grey box usually covers more, while white box gives the fullest picture at a higher preparation cost.
Environment constraints
NIST SP 800-115 warns that penetration testing is labour-heavy and demands deep expertise, and that the systems under test can be damaged or left unusable — experienced testers reduce that risk, but can never remove it entirely. In practice this means that testing production systems, and industrial environments in particular, requires additional planning, maintenance windows and a more careful pace. That lengthens the test, and so raises the price, and it explains why an OT pentest starts higher in our price list than a test of office infrastructure.
What does a quote look like in practice?
A quote starts with a conversation about scope and ends with a number of working days, which only then is converted into an amount. Take an example retail company: an online shop with a customer panel and an API for a mobile app, a dozen or so public IP addresses, and an office network with an Active Directory domain. The first question is not “how much will it cost”, but “what happens if this system fails”. The shop and the API carry the revenue, so they go into scope first; the external perimeter is the entry route for most attacks, so it comes right after them.
Only with the order set this way do we count the units: endpoints and roles in the application, addresses and services on the perimeter, hosts and privileged accounts in the internal network. Each unit has its own testing effort, and the sum of the efforts gives the number of days. If the client’s budget is smaller than the sum, we narrow the scope deliberately and write into the offer what the test will not cover — instead of promising a “full test” in less time. That way the final report states exactly what was checked, and the board knows which risk nobody has verified yet.
Web applications — what multiplies the effort
In a web application test, roles and authentication paths multiply the work most. An authorisation test checks whether a resource available to one role stays unavailable to the others, so each new role adds another row to the matrix rather than one more test case. Password login, login through an identity provider, a second factor, user invitation and password reset are five separate mechanisms, each with its own catalogue of bypass attempts — listing them in the request is the cheapest way to get comparable quotes.
APIs and integrations are priced as a separate surface. A tester moving through the user interface touches only the endpoints the interface calls; endpoints used by the mobile app, batch jobs or a partner stay invisible until someone points them out. For systems hosted inside someone else’s network, NIST SP 800-115 (section 6.5) notes that the owner of that network usually has to approve the test plan as well. An up-to-date interface specification shortens reconnaissance and is the only way we know of to lower the price without lowering the value of the test.
“Retest included” can mean two different products: a one-to-one repeat of the original scope, which according to NIST SP 800-115 (section 8.3) is what confirms a fix was implemented correctly, or a re-check of the patched addresses only. Three questions settle it: what the retest scope is relative to the original, in what window it can be used, and how many iterations the price covers. The schedule is also driven by the environment and time windows — work restricted to evenings and weekends (NIST, section 5.2.2) takes longer on the calendar for the same number of hours, excluding intrusive techniques lowers the risk of downtime at the cost of coverage, and a copy of the environment that differs from production yields findings whose verification is extra work.
Which penetration testing costs do not appear in the offer?
The offer covers the testers’ work and the report, and outside it there are usually three items: your own team’s time, fixing the vulnerabilities found and the retest. In many companies it is these, not the pentest invoice, that determine the total cost.
Your own team’s time means preparing test accounts, adding the testers’ addresses to firewall rules, handing over documentation, and taking part in the kick-off meeting and the results debrief. An internal test adds providing network access and coordinating with system owners. That is hours — and for larger scopes days — of administrators’ work, which does not disappear just because nobody priced it.
Remediation is often the most expensive item of the whole cycle. Updating a library costs little, but changing the permission model in an application, rebuilding network segmentation or replacing an outdated system are separate projects with their own budgets. A sensible testing budget sets aside a reserve for fixes before the report arrives, not after it.
A separate, often overlooked item is the test environment. If the company does not want to test production, it has to prepare a copy of the system that behaves like production: with the same software versions, configuration and realistic test data. Maintaining such a copy costs money, and a copy that differs from production produces results that then have to be verified a second time. The “production or copy” decision should be made when planning the budget, because it changes both the cost on the company’s side and the duration of the test.
A retest confirms that the fixes worked. Without it, the report describes the state before remediation and is not evidence for an auditor or the board. Retest terms differ between providers — sometimes included in the price, sometimes paid separately, sometimes limited in time — so it is worth asking about them directly. We write more about what a retest should cover in the article on retesting and remediation validation after pentests.
Total test budget: provider’s offer + IT team’s time + remediation + retest. If you plan only the first item, you are planning half of the spend.
Why is the cheapest pentest offer often the most expensive?
The cheapest offer is often the most expensive because it usually buys fewer working days, and the missing days are cut from manual verification — the very part for which a penetration test is ordered in the first place. The company pays less, but gets a result closer to a vulnerability scan, and with it a false sense that everything has been checked.
NIST SP 800-115 notes that scanners have high false negative rates, meaning they miss some real vulnerabilities. A report built mainly from scanner output therefore has two flaws at once: it contains items nobody has confirmed, and it omits those the scanner cannot see. The most valuable findings — business logic errors, privilege escalation through a chain of minor weaknesses, abuse of trust between systems — come from the manual attack phase.
Warning signs in an offer are easy to spot if you know where to look. No number of working days, or a number disproportionately small for the scope. No sample report. A methodology described in a single sentence with no reference to recognised standards. A report “on the day the test ends”, which is unlikely given manual work on the evidence. We describe what a good report should look like in the article what to expect from a pentest report.
A separate trap is the form of billing. A fixed price for a package protects the budget, but encourages the contractor to stay within the planned days regardless of what they find along the way. Billing for days actually worked hands the risk to the buyer, but allows the tester to follow a lead that turned out to matter during the test. Neither form is better in itself; what matters is that the offer states clearly what happens when the tester hits an attack path beyond the plan — whether they pursue it or only describe it, and who decides.
A cheap test is not bad by definition. It is good when it names its scope honestly — for example, a quick check of a single service after a configuration change. It becomes expensive only when the board treats it as grounds for considering the risk closed.
How do NIS2, DORA and GDPR affect the cost of testing?
Regulations affect the cost of testing primarily through frequency and required scope, and only indirectly through the level of fines. Of the three acts, DORA is the most specific and GDPR the most general.
GDPR, in Article 32(1)(d), requires controllers and processors to implement “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing”. The provision does not name penetration tests or set their frequency, but a test is one of the most direct ways to show that the measures work. Under Article 83(4), infringements of the obligations in Articles 25–39, including Article 32, are subject to fines of up to EUR 10 million or up to 2% of the undertaking’s total worldwide annual turnover.
NIS2 (Directive 2022/2555), in Article 21(2)(f), lists policies and procedures for evaluating how effective the risk-management measures are among the measures themselves. Here too there is no pentest mandate and no calendar, but the supervisory authority will ask how the organisation checks that its safeguards work. Article 34 sets the maximum fines for infringements of Articles 21 and 23: at least EUR 10 million or 2% of turnover for essential entities, and at least EUR 7 million or 1.4% for important entities. In Poland the directive is transposed by the amendment to the Act on the National Cybersecurity System of 23 January 2026 (Journal of Laws 2026, item 252).
DORA (Regulation 2022/2554) addresses testing directly. Article 25(1) lists penetration tests among the tests of the programme, and Article 24(6) requires financial entities other than microenterprises to “ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions”. Identified entities must, under Article 26(1), also carry out advanced TLPT at least every 3 years. Delegated Regulation 2025/1190 specifies in Article 11(5) that the active red team testing phase alone lasts at least 12 weeks — a project on a different scale from a single application pentest, which we describe in the article on DORA and TLPT testing.
Regulations also change what has to be bought beyond the test itself. DORA, in Article 24(5), requires procedures under which every problem uncovered by the tests is prioritised, classified and fixed, and an internal way of confirming that the weaknesses have been fully removed. In practice this means the budget must cover not only the report, but a documented remediation process and its confirmation — that is, the retest. A NIS2 auditor thinks along the same lines: a report without a remediation plan and without a trace that the plan was carried out is weak proof of the measures’ effectiveness.
For the budget: GDPR and NIS2 require you to demonstrate that safeguards are effective, without a calendar; DORA requires tests at least yearly for systems supporting critical functions and TLPT every 3 years for identified entities.
How often should penetration testing be conducted to maximize return on investment?
Penetration tests are worth conducting at least once a year for critical systems and additionally after every significant change, and in the financial sector the yearly frequency for systems supporting critical functions follows directly from Article 24(6) of DORA. More frequent tests do not always increase the return — better-targeted tests do.
The most value comes from a test performed at the moment the risk has actually changed: after deploying a new application, migrating to the cloud, acquiring a company, rebuilding the network or changing the supplier of a key system. A test every year with the same scope, on an unchanged environment, soon starts confirming what is already known. A test after a major change hits the place where errors are most likely.
The practical model we propose to clients has three layers. The first is a full test of the most important systems once a year, planned in the budget like any other fixed cost. The second is targeted tests after significant changes, funded from the budget of the project that introduces the change rather than from the security budget. The third is the retest after remediation, without which neither of the first two tests closes with evidence.
This split has one more advantage: it moves part of the cost to where the risk arises. The team deploying a new application sees the cost of its test in its own project, so it starts thinking about security at the design stage rather than after the report.
More and more often the question arises whether, instead of a yearly test, to buy continuous testing on a subscription basis. The answer depends on the pace of change. An organisation that deploys new application versions every week will benefit from constant access to testers, because every version may open a new vulnerability. An organisation whose systems change a few times a year will pay in a subscription for readiness it will not use. The decision is best based on the number of significant changes over the past year, not on fashion.
How to calculate return on investment (ROI) in penetration testing?
Return on investment in penetration testing is calculated as the difference between the expected annual loss from specific attack scenarios before the test and after remediation, compared with the total cost of the test. A test does not generate revenue, so its “return” is a reduced expected loss, not a profit.
The starting point is scenarios, not averages. IBM and the Ponemon Institute’s “Cost of a Data Breach Report 2026” estimates the average cost of a data breach worldwide at USD 4.99 million, 12% more than a year earlier and the highest in the report’s history. That is a good figure for showing the board the order of magnitude, but a poor basis for one company’s calculation: it is a global average dominated by large organisations, not the cost of your incident.
The calculation for your own company is built like this. Choose two or three realistic scenarios, for example account takeover through a vulnerable customer application, or servers being encrypted after an external intrusion. For each, estimate the cost of the event with the business owner: downtime, incident handling, notification obligations, lost contracts. Estimate how often such a scenario could occur with the current safeguards and how that frequency would change after removing the vulnerabilities identified in the test. The difference in expected losses is the benefit; the cost is the offer plus team time, remediation and retest.
A numerical example shows the mechanics, not the data — all values are assumptions to be replaced. If an account takeover scenario would cost the company EUR 450,000 and you estimate it occurs once every ten years, the expected annual loss is EUR 45,000. If fixing the vulnerabilities found in the test reduces that frequency to once every forty years, the loss falls to about EUR 11,000 a year. With a total cycle cost of EUR 14,000, the first-year benefit is about EUR 20,000 above cost. The weakest element is the frequency estimate — which is why it is worth showing the board a range, not a single number.
It is worth presenting this calculation to the board in a form that will survive questions. One line per scenario: what can happen, how much it would cost according to the process owner, how often it could occur before the test and after remediation, and who is responsible for the estimate. Such a table has one advantage over an impressive percentage: every figure can be challenged and corrected, so the discussion is about risk, not about the credibility of whoever built the calculation. After a year you can also check which assumptions were right.
Honest ROI: scenarios instead of averages, total cost instead of the price on the quote, and a range instead of one impressive number.
Can penetration testing help reduce insurance premiums?
There is no public, verifiable data that would justify promising a specific reduction in cyber insurance premiums thanks to penetration testing, and texts that guarantee such a reduction deserve a critical look. A test can, however, genuinely help with the insurance process itself.
The insurer prices risk on the basis of the information about security controls that you provide when taking out and renewing the policy. A current test report, a list of remediated vulnerabilities and confirmation from a retest let you answer those questions with facts instead of declarations. This reduces the risk that an answer turns out to be untrue and becomes the subject of a dispute when a claim is made.
The second effect is less obvious: a test reveals gaps that could become grounds for refusing or limiting a payout if the policy requires specific safeguards. Finding them in a test is cheaper than discovering them in the claims process. We write more about preparing for a policy in the article on cyber insurance.
In budget terms this means a simple rule: do not book a premium reduction as income from a pentest. If the insurer offers one, treat it as a bonus, not as the justification for the spend.
Is it cheaper to have an in-house pentest team or to outsource testing?
For most mid-sized companies it is cheaper to outsource penetration testing, and an in-house team only starts to pay off with a steady, large volume of tests, for example in an organisation that deploys changes to many applications every week. The outcome is decided not by rates, but by how fully the team is used throughout the year.
An in-house team means the salaries of several specialists, tools and licences, test labs, training and certifications, plus rotating skills, because a good mobile application tester need not be a good Active Directory tester. A team with less work than headcount is expensive; a team with more work than headcount tests superficially. An external provider spreads these costs across many clients and brings the perspective of someone who did not design the systems under test.
Before you count headcount, answer four questions. How many tests a year do you realistically need, and in how many different technologies? Can you give testers a steady stream of work all year round? Who will test the systems designed by the same team? And will the regulator accept an internal tester as an independent party? If the answer to two of these questions is “I don’t know”, an in-house team will be more expensive than the spreadsheet suggests.
Regulations add the argument of independence. DORA, in Article 24(4), requires tests to be performed by independent parties, whether internal or external, and — where an internal tester is used — sufficient resources and the avoidance of conflicts of interest at every stage. For TLPT, Article 26(8) requires that, where internal testers are used, every third test is contracted to external testers, and recital 61 of the regulation settles that the threat intelligence provider must always be external.
A mixed model most often works best: the internal security team runs continuous scanning, configuration reviews and retests of minor fixes, while full penetration tests and tests after major changes are outsourced. That way every euro goes where it delivers the most.
How to compare penetration testing offers without overpaying?
Penetration testing offers are compared by scope, effort, report contents and retest terms, and only at the end by price. Two amounts without these four pieces of information cannot be compared, even if both concern “an application test”.
The simplest tool is a single request for proposal sent to all providers with the same description of scope: the list of systems, the number of addresses or endpoints, user roles, the amount of knowledge handed over, time constraints. The table below is a list of questions worth asking every bidder, together with the answers that should raise a flag.
| Question for the provider | Why it matters | Warning sign |
|---|---|---|
| How many working days and how many testers do you plan? | It is the main price factor and the only measure of test depth | No number of days, or a number disproportionately small for the scope |
| What methodology do you use? | It shows whether the test has a repeatable structure (e.g. NIST SP 800-115, OWASP WSTG) | A “proprietary methodology” with no reference to any standard |
| What share of the work is manual? | The manual attack phase confirms vulnerabilities and finds logic errors | A description limited to the names of scanning tools |
| Can we see a sample report? | The report is the actual product of the test | A refusal, or a report without evidence and recommendations |
| What does the retest cover and until when is it valid? | Without a retest there is no proof that the fixes work | Retest undefined or priced only after the test |
| Who exactly will do the testing? | The team’s skills decide the result | No way to name the people or their experience |
| How do you handle risk to production? | A test can disrupt systems | No rules for stopping the test and no emergency contact channel |
Once the answers are collected, bring the offers to a common denominator. For each, record the number of days, the scope actually covered by the test, the retest terms and what the offer does not cover. Only then divide the amount by the working days: if one offer is half the price but plans half the days, it is not a cheaper test, just a shorter one. If it plans the same number of days at half the price, ask who will do the testing and what the report looks like — that is usually where the difference lies.
When choosing the provider itself, the article on how to choose a penetration testing company will also help.
Where to start when the testing budget is limited?
With a limited budget, start by testing what is reachable from the internet and serves customers — the external infrastructure and the most important application — because that is where an attacker has the shortest path. An internal test, social engineering tests or red team simulations make sense as next steps, once the basic attack surface has been checked.
The order is worth agreeing with the business owners, not just within the IT department. The question is: the failure or leak of which system would stop sales, production or customer service? That system is tested first. Only then do you extend the scope to supporting systems and the internal network, through which an attacker moves after the first intrusion — we describe the difference in perspectives in the article on external and internal infrastructure testing.
A second way to spend a limited amount sensibly is to hand the testers as much knowledge as possible. A grey or white box test within the same budget will cover more than a black box test, which will use some of its days to discover what could have been handed over in the documentation. A third way is to reserve part of the budget for remediation and retest before you start extending the scope — five fixed vulnerabilities are worth more than fifteen described ones.
A sensible first-year plan fits into a few steps. First, a test of the perimeter and the customer-facing application. Then remediation and a retest of the same systems. In the second half of the year, a test of the internal network and the identity directory, because that is where an attacker who got in once looks for a way to the data and the administrator accounts. Finally, a review of which findings recurred, and a decision on whether the problem lies in individual systems or in the change deployment process. That last answer usually says more about the future budget than the report itself.
If you want to turn these principles into a specific scope and quote, penetration testing at nFlo starts with a conversation about systems and risks, and only then about the number of days. For the perimeter, a good starting point is an external IT infrastructure penetration test, and for organisations that already run regular pentests, the next step may be a red team attack simulation.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- IT Infrastructure Penetration Testing — IT infrastructure penetration testing is a controlled and ethical process of…
- Wi-Fi Network Penetration Testing — Wi-Fi network penetration testing is the process of assessing the security of…
- Penetration Testing — Penetration testing, also known as pentesting, is a controlled process of…
- Security Operations Center (SOC) — Security Operations Center (SOC) is a central location where a team of security…
- SOC as a Service — SOC as a Service (Security Operations Center as a Service), also known as…
Learn More
Explore related articles in our knowledge base:
- Benefits of Regular Penetration Testing for Medium Enterprises
- Cloud Penetration Testing: Challenges and Best Practices
- Cyber risk management: How does penetration testing fit into a company’s strategy?
- DORA compliance: the role of penetration testing and advanced TLPT testing
- How does penetration testing strengthen the trust of customers and business partners?
Explore Our Services
Need cybersecurity support? Check out:
- Penetration Testing - identify vulnerabilities in your infrastructure
- Red Team - advanced attack simulations
Related services and products
Frequently asked questions
How much does a penetration test cost in 2026?
In nFlo's price list (as of 2026) a web application penetration test starts from €3,000 net in the BASIC package, an external infrastructure test from €6,000, an internal infrastructure test from €8,000, a mobile application test from €9,500 and an OT/ICS environment test from €11,500. These are entry thresholds — the final price follows from scope, that is from how many days of specialist work it takes to test the agreed systems.
What factors affect the cost of a penetration test?
The price is set by the testers' effort across the four phases described in NIST SP 800-115: planning, discovery, attack and reporting. Effort grows with the number of addresses and hosts, application endpoints and user roles, with the amount of knowledge handed over to the testers and with the constraints of the environment, such as maintenance windows in production and industrial systems.
How often do NIS2 and DORA require penetration testing?
NIS2, in Article 21(2)(f), requires policies and procedures for evaluating whether cybersecurity risk-management measures are effective, but sets no testing frequency. DORA is more specific: Article 24(6) requires every ICT system and application that supports critical or important functions to be tested at least once a year, and Article 26(1) requires TLPT at least every 3 years for identified entities.
Is the cheapest penetration testing offer a good choice?
Rarely. The lowest price usually means fewer working days, and therefore less manual verification. NIST SP 800-115 points out that a scanner only checks for the possible existence of a vulnerability, while the attack phase is what confirms it. Compare offers by scope, number of days, report contents and retest terms — not by the amount.
Does a penetration test lower cyber insurance premiums?
There is no public, verifiable data that would justify promising a specific premium reduction thanks to a pentest. A current test report and documented remediation do, however, help you answer the insurer's questions about your security controls accurately.
