"How much does a penetration test cost?" is usually the first question buyers ask, and an honest answer starts with another one: what exactly needs to be tested? Two tests with the same name can differ several times over in effort, because the effort depends on the size and complexity of what is in scope, how deep the testing goes, and what you need at the end.

Below are the factors that drive the effort of a penetration test, so you can compare proposals fairly and avoid paying for the wrong thing. There are no prices here on purpose, because a figure means little until the scope is defined.

Why proposals differ so much #

A low quote and a high quote for "a web application penetration test" are often describing different work. One may be an automated scan with a short report; the other may be days of manual testing by experienced testers, covering business logic, every user role and a retest after fixes. The first is cheaper, but only the second is likely to find the weaknesses attackers actually exploit.

The main factors #

1. Type of target #

Each target type has its own methodology: web applications, APIs, mobile applications, external network perimeter, internal network, cloud environments, wireless networks and social engineering. A combined engagement covers more, and takes longer, than a single target.

2. Size and complexity #

For applications, effort follows the number of pages and functions, user roles, integrations and workflows such as payments or approvals. For APIs, it follows the number of endpoints and authentication methods. For networks, it follows the number of live hosts, sites and network segments. Complexity matters more than raw size: ten unique workflows take longer than a hundred similar pages.

3. Depth of testing #

  • Black box: testers start with no information, like an outside attacker. Realistic but slower to reach deep issues.
  • Grey box: testers receive user accounts and basic documentation. This is usually the best value for business applications.
  • White box: testers also receive source code or architecture details, which allows the deepest review.

4. Environment and constraints #

Testing production systems may require narrow windows, extra care and coordination with your operations team. Testing outside business hours or with strict change controls adds effort. A stable staging environment that mirrors production can make testing faster and safer.

5. Compliance and reporting needs #

If the test supports a requirement, such as the NCA controls, PCI DSS or SAMA, the report must show the methodology, scope and evidence an assessor expects. PCI DSS, for example, also requires segmentation testing where segmentation reduces scope. Reports in both Arabic and English, an executive summary for leadership, and mapping of findings to frameworks add value and some effort.

6. Retesting #

A retest confirms that fixes really work. Agree in advance whether it is included and within what period.

7. Social engineering and red teaming #

Phishing simulations, physical access tests and full red team exercises test people and processes as well as technology. They require careful planning, rules of engagement and leadership approval.

What a good proposal includes #

When you compare proposals, check that each one states:

  • The exact scope: applications, URLs, IP ranges, roles and exclusions.
  • The approach and methodology, such as OWASP guidance for applications and recognized frameworks such as PTES or NIST SP 800-115.
  • How much testing is manual, and who performs it.
  • Testing windows, communication during testing and how critical findings are escalated immediately.
  • The report contents, with a sample if available.
  • Whether a retest is included.
  • Confidentiality terms, starting with a signed non-disclosure agreement.

How to get an accurate proposal quickly #

Prepare a short brief before you ask for proposals:

  1. What you want tested and why: a launch, a client request, an audit or a regulator.
  2. The size of each target: number of applications, roles, API endpoints or IP addresses.
  3. The environment to test and any time constraints.
  4. The standard or requirement the report must support.
  5. Your deadline.

With that brief, a provider can return a fixed, written proposal instead of a vague range, and you can compare like with like.

A note on "cheap" tests #

An automated scan is useful and inexpensive, and it belongs in a vulnerability management programme. It is not a penetration test. Scanners do not understand your business logic, cannot chain small weaknesses into a serious attack, and produce false positives that need human judgment. If a regulator, a client or your board expects a penetration test, make sure that is what you are buying.

Learn more about our penetration testing services or request a proposal.

Frequently asked #

Why do penetration testing quotes vary so much?

Quotes often describe different work: an automated scan with a short report versus manual testing of business logic, every user role and a retest. Scope, depth and reporting needs drive the difference.

Is a vulnerability scan the same as a penetration test?

No. Scans are automated and useful for ongoing hygiene. A penetration test adds manual work that understands business logic, chains weaknesses and removes false positives.

What should I prepare before asking for a proposal?

What you want tested and why, the size of each target, the environment and time constraints, the standard the report must support, and your deadline.

Does Cyber Shields publish penetration testing prices?

No. Every engagement is scoped individually, and we return a written proposal with a clear fee and schedule once the scope is understood, after a signed non-disclosure agreement.

Official Sources and References #

The documents behind this page, linked at the publisher. Where a Saudi regulation is published in both languages, the Arabic text is the binding version.