How much does a penetration test cost? What drives the price, and two questions to ask first
The price of a penetration test depends on scope, approach, manual work, documentation and retesting. How to read a quote, what the rules require and what should be left once the test is over.

The cost of a penetration test depends mainly on the skilled work it requires, usually measured in days. That work depends on five factors. They are the scope to be tested, the approach (black, grey or white box), the share of manual testing, the documentation requirements and the retest after fixes. That is why no single price list fits everyone. A serious price comes only after two other questions have been answered. What do you want to put to the test? And what will you do with the results?
Why can two quotes for “the same” test differ so much?
Because they often do not describe the same work. The name “penetration test” covers offers that range from an automated scan with a software-generated report to weeks of specialist work testing an application’s logic with users in different roles.
An automated scan has its value, but it is not a penetration test. A supplier who offers a fixed price without knowing the scope may well be selling exactly that. You get a report that is fine for ticking a box, but it rarely tells you where an attacker would really get in.
What is the difference between a vulnerability assessment and a penetration test?
A vulnerability assessment looks for known weaknesses in systems and applications, largely with automated tools, and lists them by severity. A penetration test tries to exploit them, as an attacker would, within a scope authorised in writing. It chains weaknesses together, checks how far it can get and separates real risks from false alarms. NIST’s technical guide to security testing treats the two activities as complementary.
| Vulnerability assessment | Penetration test | |
|---|---|---|
| Goal | find known weaknesses | show what can be done by exploiting them |
| How it is done | mostly with automated tools, then the results are checked | manual work by specialists, supported by tools |
| What you get | a broad list, ranked by severity | attack paths, evidence, impact and fixes |
| When you need it | regularly, across the whole scope | on the most important systems, before go-live and after significant changes |
Which factors set the price?
There are only a few, and they need to be clarified before anyone talks about figures.
| Factor | What to clarify | Why it matters |
|---|---|---|
| Scope | how many IP addresses, web applications, application programming interfaces (APIs), mobile apps, cloud environments, internal networks and sites | every item takes time to analyse and test |
| Approach | black, grey or white box | it changes the reconnaissance time and the depth that can be reached |
| Depth | the share of manual testing, the number of user roles to test, the business logic to challenge | manual work is what finds the most serious problems |
| Operational constraints | time windows, production or test environment, fragile systems that must not be disrupted | more constraints mean more coordination |
| Documentation | requirements from a customer, NIS2, DORA or PCI DSS, plus a summary for management | a report meant for third parties takes more care |
| Retest | whether one is planned after the fixes, and what it covers | without it, you do not know whether the fixes work |
A quote that leaves out scope, approach and retest cannot be compared with another.
Black box, grey box or white box: which should you choose?
The choice depends on what you want to find out, not on which approach costs least.
| Approach | What it simulates | What the company provides | When it makes sense |
|---|---|---|---|
| Black box | an outside attacker starting from nothing | only the authorised scope | to see what is exposed on the internet, as an attacker sees it |
| Grey box | a user with credentials, such as a customer, an employee or a supplier | test accounts with different roles | for applications with restricted access, where much of the risk hides |
| White box | someone who knows the code and the architecture | documentation, source code, diagrams | to dig deeper in less time, on critical or custom-built systems |
For the same time spent, black box explores less deeply, because part of the work goes on reconnaissance. White box goes further, but it calls for a robust non-disclosure agreement (NDA). For business applications, grey box is often the most useful compromise.
What should be left after the test?
The value of a test lies in what the company manages to fix. A good report contains the following.
- A summary for management that can be read without technical knowledge. It says what was tested, what was found and what to do first.
- The technical section, with the scope, dates, approach and reference methodology (for example the OWASP guide for web applications).
- For each vulnerability, a description, evidence, severity (often expressed with the CVSS scoring system), business impact, the proposed fix and who can carry it out.
- A prioritised plan of work, not just a list.
- The outcome of the retest, when one is planned.
For essential entities under NIS2, the EU directive on network and information security, the minimum content in Italy is laid down. The baseline specifications of Italy’s National Cybersecurity Agency (Agenzia per la Cybersicurezza Nazionale, ACN) require reports that describe the activities carried out and their results. The reports must also describe the vulnerabilities found and their level of impact.
How often should it be repeated, and what do the rules require?
It depends on the sector and the risk. These are the main reference points.
- NIS2 in Italy. For essential entities, the ACN baseline specifications (Determination 379907/2025, measure ID.RA-01) call for regular vulnerability identification activities, at least on relevant systems. These must include vulnerability assessments and/or penetration tests, and they must in any case take place before a system goes live. For all NIS entities, the directive requires procedures to assess how effective the security measures are.
- Financial sector (DORA). Regulation (EU) 2022/2554 requires tests at least once a year on the systems that support critical or important functions, and these may include penetration tests. It also requires threat-led penetration testing at least every three years for the entities identified.
- Card payments (PCI DSS). Version 4.0.1 of the standard requires internal and external penetration tests at least every twelve months and after any significant change.
- Everyone else. Common practice is to tie testing to risk and to change. Typical triggers are a new application, a migration, an acquisition or a new way into the network from outside.
For San Marino businesses the framework is different and has to be assessed case by case.
What do you need before you start?
A penetration test is an authorised attack. The authorisation must be in writing and signed by someone with authority over the systems. In Italy, unauthorised access to a computer system is a criminal offence (Article 615-ter of the Italian Criminal Code). If some systems are hosted by third parties, such as hosting or cloud providers, their rules must be checked as well.
Clear rules of engagement are also needed.
- Scope and exclusions, dates, times and contacts who can be reached.
- What to do if a critical vulnerability turns up, or signs of an attack that has already happened. The cPanel flaw shows how long a back door can stay hidden.
- How data seen during the work is handled and deleted.
- Verified backups before anyone touches fragile systems, as our article on the missing piece explains.
How do you compare two quotes?
Ask these eight questions to see whether two offers describe the same work.
- Is the scope written down, system by system?
- How many days are planned, and how many people with what experience?
- How much of the work is manual?
- Which approach and which reference methodology will be used?
- Is the retest included, and what does it cover?
- Does the report include a summary for management and the proposed fixes?
- How are the results, and the data encountered during the test, protected?
- Who can be reached if something stops working during the test?
What about artificial intelligence assistants?
If the company uses AI assistants or agents connected to email, documents or the ERP system, they are part of the scope too. OWASP’s list of risks for applications built on large language models puts prompt injection first. Prompt injection means hidden instructions inside the content the assistant reads. Other risks on the list include the disclosure of sensitive information and excessive agency, meaning agents with too much autonomy. Testing these systems is part of our work on AI security and governance.
How much does it cost not to do it?
An incident brings direct costs. These include downtime, recovery, forensic analysis and, for organisations subject to NIS2, any notifications and fines. It also brings less visible costs, such as management time and the effect on relationships with customers and partners. A penetration test does not remove the risk. It shows where the risk lies while there is still time to reduce it. And, as the letter from a reformed attacker explains, closing the easiest doors is often enough to make attackers move on.
In brief
- The cost depends on scope, approach, manual work, documentation and retest. There is no price list.
- An automated scan is not a penetration test. The two tools complement each other.
- Use black box for what attackers see, grey box for applications behind a login and white box for critical systems.
- A report is useful if it has a management summary, evidence, severity and fixes in order of priority.
- NIS2 (for essential entities), DORA and PCI DSS set frequencies and content. For everyone else, risk and change decide.
- Before you start, you need written authorisation, rules of engagement and verified backups.
Frequently asked questions
How much does a penetration test cost?
It depends on the work involved. That means how many systems and applications are tested, with which approach, how much of the work is manual, what documentation is needed and whether a retest is planned. That is why the price is set after the scope is written down, in a proposal that lists activities, timings and exclusions.
Does NIS2 make penetration tests mandatory?
In Italy, the ACN baseline specifications require essential entities to carry out regular activities, at least on relevant systems, that include vulnerability assessments and/or penetration tests, documented in specific reports. For important entities, the baseline specifications require vulnerabilities to be identified and managed through a plan, without naming these tools explicitly.
Can a penetration test be run on production systems?
Yes, with precise rules. These include agreed times, leaving out tests that could interrupt the service, contacts who can be reached and verified backups. When a faithful test environment exists, some checks move there.
A useful penetration test starts with a written scope and ends with verified fixes. Strategic’s Cybersecurity division carries out penetration tests and vulnerability assessments within scopes authorised in writing. You receive a report for IT, a summary for management and the agreed retest.
Sources
Consulted on 16 September 2026.
- Italy’s National Cybersecurity Agency (ACN), NIS – Procedures and baseline specifications (Determination 379907/2025, Annexes 1 and 2, measures ID.RA-01 and ID.RA-08, in Italian)
- Directive (EU) 2022/2555 (NIS2), Article 21, EUR-Lex
- Regulation (EU) 2022/2554 (DORA), Articles 24, 25 and 26, EUR-Lex
- PCI Security Standards Council, PCI DSS v4.0.1, requirements 11.4.2 and 11.4.3
- NIST, SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008
- OWASP, Web Security Testing Guide
- FIRST, Common Vulnerability Scoring System v4.0
- OWASP Gen AI Security Project, Top 10 for LLM Applications 2025
- Italian Criminal Code, Article 615-ter, Normattiva (in Italian)
Find out moreCybersecurityTesting carried out the way an attacker would (penetration tests), incident management, business continuity and support in meeting NIS2 requirements, suppliers included.


