Penetration testing cost: what goes into the price and what moves it

The price is the product of two numbers: how many person-days the brief takes and what a day of a tester’s work costs. Everything else affects the first number: the number of user roles in the application, IP addresses and subdomains, the depth of the test, the retest, and the report format. The second number is fixed on our side; it’s the same for a bank and a manufacturing company.

We calculate effort from what can realistically be covered. For a web application, what counts is the number of user roles, the number of functional modules, and the number of API endpoints. An application with three roles offers three different views of the same function, and we test each of them, plus the transitions between them. That’s why roles move the effort more than the number of screens does.

The depth of the test is the second lever. A black-box test without credentials takes fewer days, but the part of the application behind the login stays unexplored and you pay for the tester guessing. A gray-box test with an account for every role costs more in preparation and less per finding: it turns up more findings for the same number of days.

The price includes a two-part report: an executive summary and a technical section with reproduction steps. One retest of fixed findings is included in the price of penetration tests, except the physical penetration test, which we run as red teaming. The retest is an item some vendors bill separately. Ask about it on every proposal you get, because without a retest nothing documents that the findings were fixed.

Typical effort runs from 2 person-days for a security consultation to several months for a red team operation. So the table puts both side by side: how much work you’re buying and how long the engagement will run on the calendar. The last column names the variable that moves the effort most. You get the number for your specific brief after the scoping call.

A person-day is one day of work by one tester, not one day on the calendar. So 8 person-days doesn’t mean 8 days from the start: the work also includes preparing access and writing the report. The calendar column counts from the start of the test to delivery of the report; scoping comes before it and isn’t counted in the interval. For pentests, every calendar figure fits inside the 5 to 15 business days that penetration testing works with.

The pentest rows differ in what gets counted at all. For an application, it’s the number of roles and the size of the API, so the effort of testing one application follows from its functions, not from the number of servers. For a network it’s the other way around: the effort is set by the number of live IP addresses, sites, and exposed services, as described under testing the network and exposed services.

The newest rows follow the same logic. For a Wi-Fi network test, the effort is set by the number of SSIDs, sites, and the type of security; for a mobile app test, by the number of platforms and the complexity of the app, not the size of the installation file; and for a test of industrial control systems (OT/ICS), by the number of sites, zones, and devices in the industrial environment.

The cloud has its own row in the table because it is ordered and billed separately. In the cloud, the weight of the flaws shifts from versions to permissions: the extent of IAM roles and policies, storage configuration, and the applications’ access tokens. So the effort isn’t set by the number of servers but by the number of AWS accounts and the number of services actually running in them, because each account has its own roles and policies to go through. We test AWS, for which our team holds the CCPenX-AWS certification, and we keep the scope inside what AWS allows in testing and what it doesn’t.

For a physical intrusion, effort is calculated differently from everything else in the table: it has two parts. Each site gets its own block of work, in which a red team operator spends at least six days directly on site, and the rest goes to reconnaissance, scenario preparation, and processing the evidence. The report is written once for the whole operation, so it isn’t repeated with every additional site. Two branch offices in the same city therefore come out differently from one building with three entrances and its own security guards, and what all of that involves is covered under the scope of a physical intrusion.

For a phishing simulation and a security consultation it’s more straightforward: the effort is set by the number of scenarios in the first case and by the amount of material to go through in the second.

An engagement with 8 person-days of pure testing stretches to roughly 12 business days on the calendar: a day to prepare the environment and access, 8 days of testing, and 2 to 3 days for a report that someone actually writes instead of generating it from a scanner. That difference is exactly what separates the two numbers in the table.

One service doesn’t belong in this table: data breach monitoring. It isn’t billed in person-days or in calendar weeks, because it’s a continuous service, not a one-time engagement. It’s paid by a monthly or annual subscription, and the amount follows the number of domains and monitored addresses we watch. We give you the specific figure after scoping, once it’s clear how much there is.

The one-time leak check stays free alongside the subscription: we add it to every engagement, and it tells you what is out there as of the day of the check. The subscription pays for the monitoring to keep running and to alert you whenever a new leak appears. What data breach monitoring includes has its own page.

The infrastructure security audit also sits outside the table. It’s a one-time project like a penetration test, but its effort is set by the size of your infrastructure: the number of devices, the size of the network, and everything that is in scope. So we don’t give a fixed range in person-days; we give you the price after scoping, once it’s clear how much is involved. What the security audit includes is covered on its own page.

User roles, third-party integrations, and a vaguely defined brief raise the effort the most. A prepared environment, working access from day one, and an exact list of what is being tested lower it. For the same application, the difference between a well-prepared and a badly prepared brief is usually several days of work.

The most expensive item is usually uncertainty. When the brief doesn’t say how many subdomains the company actually runs, we have to buy time for reconnaissance at the start. You pay for that time even if it turns out there are three subdomains. An hour spent on the asset list before you send the inquiry pays for itself.

Scoping is a half-hour to one-hour call, after which we have enough to write up the scope, the start date, and the price. We need four things for it: what is to be tested, how much of it there is, which roles exist in it, and when it should happen. What to deliver just before the start, that is, accounts and access, is summarized in our checklist of materials before a test. With that, we usually return a proposal within one business day after you send us your brief.

• What is being tested: domains, IP ranges, application addresses, and possibly mobile apps and their platforms.
• Roles and user types in the application: how many there are and how their permissions differ.
• Environment: production or staging. If staging, how much it differs from production.
• Operational restrictions: windows when testing isn’t allowed, systems that can’t take load, and a contact who will stop the test if something goes wrong.
• Purpose of the test: internal verification, a client’s or insurer’s requirement, or documentation under the Czech Cybersecurity Act, Act No. 264/2025 Coll., on Cybersecurity. The purpose changes the form of the deliverable, not the effort.

Two documents are signed: an NDA and a written authorization to test from someone who is entitled to give it. Without the second one, we don’t start. It protects both sides, and it’s a few paragraphs, not a month of legal back-and-forth.

For a physical intrusion we need three more things for the proposal: who will sign the authorization letter for the company, which premises and times are in scope, and who else is in the building, another tenant or an outside security company that guards it. We also settle what may be photographed when people are in the frame. The full set of rules sits under what we don’t start a physical test without; for the proposal, answers to these questions are enough.

If your brief isn’t put together yet, that’s not an obstacle. We then start by going through what the company actually runs, together with you. During that hour it may turn out that the scope is completely different from how it looked in the original email, because subdomains turn up that nobody remembered.

The price includes scoping, the testing itself, the two-part report, and a walkthrough of the findings with your team. For penetration tests it also includes one retest of fixed findings. For red teaming, phishing simulations, and consulting it doesn’t. We run the physical penetration test as red teaming, so it has no retest either. The price doesn’t cover functionality built after the test, a repeat test after a major change in architecture, or the development work on the fixes. We propose the remediation and verify it, but your team or your vendor fixes the code.

We keep the price fixed for the agreed scope. If it turns out during the test that the application has two more roles and one unannounced module, we get in touch before we start working on it. Not on the invoice. A scope extension is always a separate agreement with its own figure.

We won’t compare competitors’ prices here, because we’d be comparing numbers without a scope. When you compare two proposals, ask three things: how much time is set aside for the testing itself, who will actually run the test, and whether the retest is included. On the second question, it helps to know how to read the qualifications of the person who will be testing. After those three questions the difference between proposals is usually clear without us.