What a pentest includes, what it costs and how to choose a provider

The price of a pentest in Ukraine depends not on the size of the company but on the scope of the test: how many systems and user roles need checking, how deep the specialist goes by hand and how many working days that takes, including the report and the retest. That is why public figures on the market differ by a factor of tens, and an honest fixed price can only be given after a short call about your systems.

Below are three typical scope examples with durations in working days, a table of what drives the price, a preparation checklist and advice on choosing a pentest provider.

The most expensive mistake when ordering a pentest is not overpaying. It is paying for an automated scan and believing that access control, roles and business logic have been checked. A scanner cannot see those, and an attacker tests exactly them. A typical scenario: a customer changes the order number in the page address and sees other people’s addresses and phone numbers. Login works, payment works, and the scanner found nothing.

In short

• A pentest is an agreed, controlled test of specific systems. It is not the same as an automated scan, and it does not mean “test everything”.
• The price depends first of all on a clear scope: which systems and roles are tested, how deep, how many days the specialist works and what the report and the repeat check (retest) include.
• Typical durations: a website with a customer area usually takes 5 to 10 working days, a website plus a mobile app API 8 to 15, and a company of 30 people (perimeter, cloud office, phishing simulation) 8 to 14.
• Published prices in Ukraine count different things, so no average can be derived from them. A fixed price comes after a call about your systems.
• Before signing, agree on written permission, limits and exclusions, safe testing rules, the report contents, remediation and the retest.

What it costs in Ukraine

Without the same scope, the numbers cannot be compared. Public Ukrainian materials mention $300 to $500 for a small web application or API from one provider and $5,000 to $30,000 for a corporate project from another. ^{[7] [8]} These are different volumes of work, so they cannot be compared as one and the same service.

What drives the price

The price is made of the specialist’s working days. Each row below adds or removes days, and the last column shows how to save without hurting the result.

Examples of public offers

Examples of public offers, not a market median.

A lower bound of a few hundred dollars usually means a limited scope, so ask exactly what is included.

Nothing in these publications supports a claim that “a normal pentest costs this much”. They show something else: systems, depth, the number of roles, manual hours, the type of report and the retest all differ. When you ask for a quote, ask the provider to state the currency, taxes, person days, team composition, automated and manual work, exclusions, timeline and the price of an extra retest. Then two proposals can be compared by the same rules.

If your business accepts card payments, find out separately whether and in what role you fall under PCI DSS. PCI SSC describes the standard as applying to organisations that store, process or transmit payment card data or can affect its environment; the requirements for a specific organisation should be confirmed with the acquirer or a qualified assessor. That does not mean every website needs the same set of work. ^[5] For specific PCI procedures, use the current version of the standard rather than the old 2017 supplementary guidance. ^[6]

Three scope examples: a website, a website with an API, a company of 30 people

I deliberately do not give amounts in money here: they depend on your specific systems. Duration in working days gives a more honest picture of the scope. The days below cover the specialist’s work including the report, but not the retest. I give a fixed price and timeline after a short call, once I see your list of systems and roles.

Example 1. A company website with a customer area

What is tested. Login, sign up and password recovery. Whether a customer sees only their own orders, documents and invoices. Staff roles and the admin panel, forms and file uploads, the settings of the server the site runs on. A typical finding: changing an order number opens someone else’s data, as in the example at the start of this article.

Duration. Usually 5 to 10 working days including the report.

What the report includes. A short summary for management; each finding with evidence and reproduction steps; a risk rating; a concrete fix for the developer; a list of what was tested and what was excluded.

What changes the scope. More days: several staff roles, payments, integrations with a CRM or an accounting system, testing only on the live site in night windows. Fewer days: one customer role and one admin role, a test environment, ready test accounts and a note on who should see what.

Example 2. A website and a mobile app API

What is tested. Everything from the first example plus the API (the interface the app uses to exchange data with the server). Whether someone else’s data can be fetched by swapping an identifier; whether permissions are checked on every request; whether the server returns extra fields; whether login attempts are limited. OWASP lists API risks separately, and the first one on its list is access to other users’ objects. ^[9] If the app itself is in scope, the tester also looks at what it stores on the phone: login tokens, keys, saved data.

Duration. Usually 8 to 15 working days. The website and the app often share one API, so the days for the two parts do not simply add up.

What the report includes. The same as in the first example, plus a list of the API methods tested (the addresses the app calls) and separate findings for the Android and iOS apps if they were in scope.

What changes the scope. More days: two platforms, many API methods without documentation, app protection against analysis that has to be bypassed. Fewer days: API documentation (for example a Postman collection or a Swagger description), test accounts, a test build of the app, one platform in the first stage.

Example 3. A company of 30 people: perimeter, cloud office and phishing

What is tested. Three parts. The external perimeter: what of your systems is visible from the internet (website, mail, VPN, remote access, forgotten subdomains) and whether that can be used to get inside. The cloud office, meaning Microsoft 365 or Google Workspace: two factor login, admin rights, mail forwarding to outside addresses, access to shared files, and the SPF, DKIM and DMARC records (they protect your domain from forged emails). For Microsoft 365 its own Secure Score is a useful starting point, but it does not replace a manual review. ^[10] And a phishing simulation: an agreed training email to staff to see who opens the link, who enters data on a fake page and who reports the email.

Duration. Usually 8 to 14 working days: the perimeter 3 to 5, the cloud office 2 to 4, the phishing simulation 2 to 4 including preparing the scenario, plus a combined report. In calendar time that is 3 or 4 weeks, because a phishing campaign needs to run for several days.

What the report includes. One management summary covering all three parts; technical findings for the perimeter; a prioritised list of cloud office settings; anonymised phishing statistics (how many opened, clicked, reported); a plan of what to fix first.

What changes the scope. More days: several domains or offices, your own servers alongside the cloud, several phishing waves or scenarios. Fewer days: one domain, read access to the admin console instead of looking for settings from the outside, one phishing wave. The number of people matters less than it seems: everyone receives the email at the same time. A company like this often needs not a classic pentest but a mix of a perimeter test, a Security Assessment of the cloud office and a phishing simulation. A good provider will tell you where to start in your case.

A retest after fixes usually takes 1 to 3 working days, depending on the number of findings. To get a fixed price, a short call is enough: you name your systems and roles, and in return you get a written scope with the number of days.

What a business is really buying

A pentest answers a narrower question than “is the company secure?”: can a tester, under agreed conditions, exploit weaknesses in specific systems, and what would that mean? OWASP describes separate testing methods for web applications and services, including authentication, authorisation, sessions and APIs. It is a useful map of tests, but not a promise to check every possible system. ^[2]

For an online shop or a SaaS product this can mean testing login, password recovery, the customer account, staff roles, the API, payments and the admin panel. But testing a payment provider, a hosting platform or a third party integration must not be assumed to be allowed. The proposal should name the system owners, the limits and the agreed actions.

In my work the typical flaw does not always look like a spectacular “hack”. More often the system correctly lets a user into their own account but does not check well enough that the data they request belongs to them. Or an employee has more rights than their role needs. For a product owner this can look like an ordinary API request; the specialist checks whether the result changes if another identifier is substituted or another role is used. Such checks must not be run without the owner’s permission and a controlled testing procedure.

This is why a scanner and a pentest are not interchangeable. A scanner automatically finds known technical signs. A pentester checks whether a finding can be turned into real impact, whether several weak points can be combined and where the intended product logic actually breaks. NIST describes different testing methods separately, with their strengths and limits; PCI SSC also distinguishes vulnerability scanning from penetration testing. ^{[4] [6]}

What the work should include

A good process usually starts not with launching tools but with a conversation about goals and systems. The Ukrainian Diia.Business guide (in Ukrainian) describes planning and reconnaissance, vulnerability analysis, attack simulation, a report and a re-check after fixes. ^[1] In practice, for the customer that means these stages:

1. Setting the goal. For example, checking whether an ordinary user can get another customer’s data, or whether the external perimeter is protected well enough.
2. Scope and rules of engagement. A list of domains, IP addresses, applications, APIs, environments and roles; what is allowed and what is excluded; a contact for an emergency stop. NIST recommends planning technical tests, setting rules for how they are run and analysing the results, rather than reducing the work to scanning alone. ^[4]
3. Manual and automated testing. Tools help find typical weaknesses, while manual testing adds context, confirms findings and explores scenarios specific to the product.
4. Controlled proof of impact. The tester shows that the problem is real, but must not change or delete data, stop the service or go beyond the agreed target without separate permission.
5. Report and walkthrough. OWASP advises making the report clear and reproducible: explain what was tested and how, describe the root cause, the risk, the business impact and a concrete fix. ^[3]
6. Retest. After the fixes, the specific findings are checked again. Clarify in advance how many repeat checks are included in the price and when they can be ordered. On the market these are different commercial terms, not an automatic guarantee.

What the customer receives

Ask for the result to be fixed in the contract or the terms of reference: a short summary for management; a technical description of each finding with evidence and reproduction steps; a risk rating and priority; remediation recommendations; a list of tested and excluded systems; the test date and limitations; a question and answer session; the retest terms. That kind of document helps decide what to fix immediately and what to plan. A bare list of scanner alerts does not replace it. ^[3]

Pentest preparation checklist

Save this list and go through it before the kickoff meeting:

• Formulate the business question: which data, money or operations must be protected above all?
• Collect an exact list of domains, IPs, web applications, APIs, mobile components and cloud environments.
• Mark what you own and what is run by a hosting provider, a payment service or another vendor. Obtain the necessary permissions.
• Decide whether to test production or a separate environment. Define work windows and times when risky checks are prohibited.
• Prepare test accounts for different roles and safe test data. Do not hand over employees’ regular passwords.
• Agree in writing the prohibited actions, load limits, stop procedure, escalation contacts and backup recovery.
• Inform the on-call engineers and the response team, but not necessarily every employee, if the scenario does not require it.
• Define the report format, a secure delivery channel, the retention period for materials and the terms for deleting them.
• Establish what “retest completed” means and when it ends.

Download the preparation checklist (PDF)PDF · A4

Written permission and rules of engagement are not a formality. They stop a tester from accidentally checking someone else’s environment or continuing an active check when the team sees a risk to the service. NIST names planning and rules of engagement as part of organised testing; PCI SSC also devotes separate sections of its supplementary guidance to them. ^{[4] [6]}

Red flags when choosing a provider

A certificate can be a useful signal, but it does not replace a conversation about method, limits and results. Check experience with exactly the type of systems you are ordering, and ask them to explain how the team gets from a finding to a clear remediation plan. More on this in the article how to choose a pentest company.

Questions to ask a provider

1. Which systems, roles and business scenarios are in scope? What is excluded?
2. Which part of the testing will be done manually, and what will be automated?
3. Which test accesses and materials do you need from us?
4. Do you test production? Which actions are prohibited without separate approval?
5. Who is our contact during the test, who can stop the work, and how quickly do you escalate a risk?
6. What will the report contain? Can we see an anonymised sample?
7. What timeline, number of specialists and working days are built into the price?
8. Is the retest included in the price? What scope, how many rounds and by what date?
9. How are evidence and access protected, and when are they deleted?
10. How will the price change if the list of systems changes while the scope is being agreed?

What a pentest does NOT guarantee

A pentest does not prove that a system has no vulnerabilities at all. It shows the result of testing a specific scope, with specific methods, over a specific period. An API that was left out, a new release, another role or a vulnerability that could not be tested safely all remain outside the conclusion. OWASP explicitly distinguishes its practical testing guide from a full source code analysis and from a formal compliance standard. ^[2]

A pentest also does not replace regular updates, monitoring, access control, backups and fixing what was found. Even a good report does not reduce risk if the team has not assigned owners and deadlines to the tasks. And a certificate or the name of a methodology does not by itself prove the depth of a particular test.

Over my career, since 2019, I have run more than 170 pentests for over 80 companies, including while working in banks and consulting: I personally tested web applications, APIs and infrastructure and led a team of pentesters. It matters to me that the customer understands what to fix first and why, so I start with scope and rules rather than with tools. If a full audit is too big right now, you can start with one critical area, for example authorisation in the customer account or the external perimeter. Such a check shows how the work goes on an agreed scope and does not promise to find everything.

FAQ: answers to common questions

How much does a pentest cost in Ukraine?

It depends on the scope: the number of systems and roles, the depth of manual testing, the report and the retest. Public benchmarks range from a few hundred to tens of thousands of dollars because they describe different work. Ask for a quote with the number of working days and a list of what is included; an honest fixed price comes after a short call about your systems.

How many days does a pentest take?

For a website with a customer area usually 5 to 10 working days, for a website plus a mobile app API 8 to 15. A retest after fixes usually takes 1 to 3 days.

Does the price depend on the number of employees?

For a website or API pentest, hardly at all: what is priced is systems, roles and time. Headcount has some effect on a phishing simulation and a Microsoft 365 or Google Workspace review, but even there the number of domains and scenarios matters more.

How can I reduce the cost without losing quality?

Narrow the scope to the most critical system, provide test accounts, documentation and a test environment, and fix the findings before one combined retest. Do not cut the manual testing: that is what finds what a scanner cannot see.

Can a cheap automated service replace a manual pentest?

Automation finds known signs but does not check product logic and access rights. Ask who confirms findings manually and what will be in the report.

In closing

After a scoping meeting, a good result often starts with a short list: this account area, these roles, this API, these prohibited actions, and this person to call if something goes wrong. When the team sees the same limits and the same result, a pentest stops being an unknown cost and becomes a manageable work plan. If you want to define that scope calmly for your business, request a free 30 minute call or start with the overview of the Pentest service.

References

1. Diia.Business: What is penetration testing? (in Ukrainian) business.diia.gov.ua
2. OWASP Web Security Testing Guide: Introduction wstg.owasp.org
3. OWASP Web Security Testing Guide: Reporting Structure wstg.owasp.org
4. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
5. PCI Security Standards Council: PCI DSS pcisecuritystandards.org
6. PCI SSC: Penetration Testing Guidance v1.1 (2017) pcisecuritystandards.org
7. ESKA: How penetration testing pricing is formed (in Ukrainian) eska.global
8. ITFB: Pentesting for business and what it costs (in Ukrainian) itfb.com.ua
9. OWASP API Security Top 10 (2023) api-security.owasp.org
10. Microsoft Learn: Microsoft Secure Score learn.microsoft.com