Why Penetration Testing Costs Vary So Widely
Penetration testing cost is one of the most searched security questions among crypto founders, security directors, and CFOs, for good reason. Budget planning for security is difficult when price signals in the market are so inconsistent. Quotes for ostensibly similar engagements can vary by an order of magnitude, and the terminology used across proposals is often inconsistent, making direct comparison difficult.
The honest answer is that costs genuinely do vary from approximately £2,000 for a narrow, automated-assisted API test through to £200,000 or more for a full DORA-compliant Threat-Led Penetration Test (TLPT). The variation is not arbitrary; it reflects real differences in scope, methodology, duration, and provider quality. Understanding what drives those differences is the prerequisite for evaluating proposals intelligently.
For crypto firms specifically, the stakes attached to security testing are higher than in most sectors. The assets at risk are liquid and immediately transferable. The adversaries are sophisticated and well-resourced. A penetration test that misses a critical attack path does not just represent poor value; it creates a false sense of assurance that may delay investment in the controls that would actually prevent a breach.
"The cost of a penetration test that misses a critical vulnerability is not the fee you paid. It is everything that vulnerability ultimately costs you."
Factors That Drive Price
Five variables account for most of the cost variation you will observe across penetration testing proposals:
1. Scope
Scope is the single largest driver of cost. A test of a single web application with a defined number of endpoints is a fundamentally different undertaking from a test of a full infrastructure including cloud environments, internal networks, key management systems, and personnel. Proposals that do not precisely define scope should be treated with caution; vague scope definitions are often how low-cost providers limit their time on an engagement without explicitly saying so.
In a crypto context, scope questions that must be answered before any proposal is meaningful include: Does this cover the smart contract layer, or only the web application? Are key management systems and hardware signing devices in scope? Does it include social engineering of personnel? Are cloud infrastructure and CI/CD pipelines included?
2. Duration
Point-in-time penetration tests run for days. Extended red team engagements run for weeks or months. The difference is not merely administrative; longer engagements allow the tester to conduct the reconnaissance, persistence, and lateral movement phases that a real attacker would carry out and that a short-duration test cannot replicate. A one-day automated scan and a three-week adversarial red team exercise are not variants of the same product; they answer different questions.
3. Methodology
Automated scanning is cheap and fast but limited to known vulnerability signatures. Manual testing requires skilled human time and finds logic errors, business process flaws, and contextual vulnerabilities that scanners miss. Adversarial simulation combines manual testing with custom threat intelligence, realistic attacker personas, and full kill-chain execution. Each methodology step up represents a material increase in cost and a corresponding increase in the value of findings.
4. Provider Credentials and Crypto Expertise
CREST-accredited providers and CHECK-approved providers operate under quality standards that carry accountability. Individual testers holding OSCP, CREST CRT, or equivalent qualifications have demonstrated practical offensive security competence. These credentials add to cost; they also materially reduce the risk of receiving a test that missed the vulnerabilities that matter.
Crypto domain expertise is a separate dimension from general pen testing quality. A tester without experience in key management systems, multisig workflows, DeFi protocol interactions, and blockchain-specific infrastructure will not know where to look for the vulnerabilities most relevant to your threat model. Expect to pay a premium for genuine crypto expertise, and verify it through specific questions and reference checks.
5. Regulatory Requirements
DORA-compliant TLPT engagements carry specific requirements: threat intelligence-led scoping, production system testing, competence verification of testers, and regulatory reporting. Each requirement adds cost. Firms seeking to satisfy DORA obligations cannot substitute a cheaper conventional pen test and expect it to meet the evidential standard required by their National Competent Authority.
Typical Cost Ranges by Test Type
The following ranges represent realistic market pricing for quality engagements from credentialed providers with relevant expertise. Engagements outside these ranges do exist; at the low end, they typically involve significant scope limitations or methodological shortcuts. At the high end, they may reflect particularly complex environments, regulatory requirements, or extended duration.
Web Application Penetration Test
Typical range: £3,000 to £15,000
Covers authentication mechanisms, authorisation logic, session management, injection vulnerabilities, business logic flaws, and API endpoints. Duration typically two to five days of manual testing. At the lower end of this range, scope will be limited to a defined number of pages or endpoints. A crypto exchange web application with complex trading workflows, wallet management interfaces, and administrative panels will sit toward the upper end.
Infrastructure and Network Penetration Test
Typical range: £5,000 to £20,000
Covers external perimeter, internal network segmentation, cloud infrastructure configuration, and server-level vulnerabilities. In a crypto context, this should include the infrastructure hosting node software, key management systems, and monitoring tooling. Larger and more complex environments with multiple cloud accounts and on-premise components will exceed the upper bound of this range.
API Security Test
Typical range: £2,000 to £10,000
Focused testing of API endpoints including authentication, rate limiting, data exposure, and business logic. Standalone API tests are appropriate for protocols and exchanges that expose significant API surface to third parties or institutional clients. The OWASP API Security Top 10 provides the baseline framework, but a quality engagement will go beyond that to test crypto-specific API patterns.
Smart Contract Audit
Typical range: £5,000 to £50,000 or more
A smart contract audit is technically distinct from a penetration test; it is a code review discipline that examines contract logic, access controls, economic attack vectors, and integration risks. Cost scales with contract complexity, number of contracts in scope, and the protocol category (a simple token contract costs far less to audit than a complex AMM or lending protocol). Flagship DeFi protocols with multiple interdependent contracts and significant TVL should expect costs toward and beyond the upper end of this range.
For a full breakdown of what a smart contract audit entails and where it sits in the broader security lifecycle, see our guide to blockchain security audits.
Full Red Team Engagement
Typical range: £20,000 to £150,000 or more
A multi-week objective-led adversarial simulation covering technical infrastructure, personnel (social engineering, phishing), physical security, and full kill-chain execution. The wide range reflects the significant variation in scope and duration. A two-week engagement focused on external attack paths will sit toward the lower end; a six-week engagement covering internal lateral movement, social engineering campaigns, and physical security will sit toward the upper end or beyond it.
DORA Threat-Led Penetration Test (TLPT)
Typical range: £50,000 to £200,000 or more
The cost premium over a standard red team engagement reflects the regulatory documentation requirements, the threat intelligence scoping phase (typically a separate workstream), the requirement to test production systems with appropriate safeguards, and the competence verification requirements for testers. Firms exploring DORA obligations should consult our detailed analysis of DORA compliance requirements before scoping a TLPT engagement.
Why Cheap Tests Fail to Deliver
The penetration testing market contains a substantial volume of low-quality engagements packaged as comprehensive assessments. Understanding how they fall short is important for procurement decisions.
The most common pattern is the automated scan dressed as a manual test. A provider runs Nessus, Burp Suite in automated mode, or similar tooling against the target, collates the output, applies superficial editorial formatting, and delivers the result as a penetration test report. The report may contain dozens or hundreds of findings, most of them low or informational severity, most of them generated by the scanner with minimal analyst interpretation. The actual time a human spent testing may be measured in hours rather than days.
These reports create a specific kind of risk: the organisation believes it has been tested. Leadership is satisfied that a security review has been completed. The finding remediation effort is directed at publicly documented, low-severity issues. The business logic flaws, key management weaknesses, and social engineering vulnerabilities that represent the actual attack surface for a crypto firm remain unidentified.
The markers of a low-quality engagement are consistently predictable: no crypto domain knowledge demonstrated in scoping discussions, unusually short proposed engagement duration, inability to provide references from comparable crypto firms, no clear methodology documentation, and no retesting commitment for critical findings.
What a Quality Report Looks Like
A quality penetration test report serves two audiences: technical teams who need to understand and remediate findings, and executive leadership who need to understand organisational risk. Both needs should be met in a single document with clearly delineated sections.
The essential components of a quality report include:
- Executive Summary: A non-technical narrative of the overall findings, the most significant risks identified, and the assessor's view of the organisation's security posture relative to its threat model. This section should be readable by a board member with no technical background.
- Scope and Methodology: A precise description of what was tested, what was excluded, what techniques were used, and over what timeframe. This section establishes the validity of the assessment and its limitations.
- Risk-Rated Findings: Each finding individually rated by severity, typically using a combination of CVSS (Common Vulnerability Scoring System) scores and business impact context. In a crypto environment, business impact context is critical: a finding that allows read access to a configuration file containing a private key is a critical finding regardless of its base CVSS score.
- Proof-of-Concept Evidence: Screenshots, request/response captures, or code snippets demonstrating that findings are genuine and exploitable. Findings without evidence should be treated as unverified and deprioritised for remediation until evidence is provided.
- Remediation Guidance: Specific, actionable guidance for each finding, not generic references to OWASP or CVE advisories. The guidance should address the specific implementation context of the organisation.
- Retesting Commitment: A clear commitment to retest critical and high findings after remediation to confirm that the fix is effective and has not introduced new issues.
How Often to Test
Penetration testing frequency should be calibrated to the rate of change in the environment and the regulatory obligations of the organisation.
For infrastructure and network environments, annual testing represents the minimum acceptable frequency for a crypto firm. Any significant infrastructure change (new cloud account, new hosting arrangement, new network segment) should trigger a targeted test of the changed components.
For web applications, testing should occur after every significant release that introduces new functionality, changes authentication flows, or modifies integration with external services. A release-based testing cadence will typically mean two to four tests per year for an actively developed exchange or dApp.
For smart contracts, every deployment to mainnet should be preceded by an audit of any changed code. The principle is that any unaudited code in production represents an unacceptable risk given the irreversibility of on-chain transactions.
For DORA-regulated firms, the minimum TLPT cycle is every three years, but the operational resilience testing requirements under DORA extend beyond TLPT to continuous testing of digital operational resilience more broadly. Our analysis of DORA compliance obligations covers the full testing and reporting framework.
Beyond scheduled testing, a continuous vulnerability management programme should be operating between point-in-time tests. This is covered in detail in our guide to vulnerability management for Web3 organisations.
How to Evaluate Proposals
Evaluating penetration testing proposals requires going beyond price comparison to assess methodology, credentials, and crypto-specific competence.
Questions to Ask Every Provider
- Can you describe your methodology for testing key management systems and multisig workflows?
- What proportion of the engagement is manual testing versus automated scanning?
- Can you provide references from comparable crypto or blockchain firms?
- Which qualifications do the testers assigned to this engagement hold?
- Is retesting of critical and high findings included in the quoted price?
- What is your process if you discover a critical vulnerability mid-engagement that requires immediate remediation?
Certifications and Credentials to Look For
- CREST: The Council of Registered Ethical Security Testers accredits organisations and certifies individual testers at multiple levels. CREST accreditation is the most widely recognised quality standard for penetration testing in the UK and EU.
- CHECK: The NCSC CHECK scheme approves providers to test government and critical national infrastructure. CHECK approval is a strong quality indicator even for private sector engagements.
- OSCP (Offensive Security Certified Professional): An individual certification that requires demonstrated practical ability to compromise systems in a controlled environment. The OSCP is a credible floor-level indicator of individual tester competence.
- CREST CRT and CCT: Higher-level CREST individual certifications that indicate advanced manual testing competence.
Red Flags in Proposals
- Duration that is implausibly short for the stated scope.
- No methodology documentation or refusal to provide one.
- Inability to name individual testers or confirm their qualifications.
- No retesting included and no clear process for how retesting would be priced.
- Report samples that are clearly automated scanner output with minimal analyst commentary.
- No demonstrated knowledge of crypto-specific attack surfaces in scoping conversations.
For context on the broader attack surface management discipline that penetration testing sits within, see our guide to attack surface management for Web3 organisations.
The decision about which provider to select should not be made on price alone. The appropriate question is not "how much does this penetration test cost?" but "which provider will find the vulnerabilities that represent the most significant risk to this organisation?" In a sector where a single missed vulnerability can result in losses that dwarf the entire annual security budget, quality of testing is the only metric that ultimately matters.
Frequently Asked Questions
How much does a penetration test cost for a crypto firm?
Penetration testing cost for crypto firms varies widely depending on scope and methodology. A web application pen test typically costs £3,000 to £15,000. A full red team engagement runs £20,000 to £150,000 or more. A DORA-compliant TLPT engagement often exceeds £50,000 due to regulatory requirements. The final cost depends on scope, duration, provider credentials, and whether crypto-specific expertise is required.
What is the difference between a smart contract audit and a penetration test?
A smart contract audit reviews the code of a blockchain application for logic errors, vulnerabilities, and security issues, typically through manual code review and automated analysis. A penetration test assesses the broader technical environment: web applications, APIs, infrastructure, and network configuration. Both are necessary; they address different parts of the attack surface.
How often should a crypto firm run penetration tests?
Infrastructure should be tested at least annually. Web applications should be tested after every significant release or architecture change. Smart contracts should be audited before every deployment and after any material upgrade. Firms regulated under DORA must undertake TLPT at least every three years, with the possibility of more frequent requirements from supervisory authorities.
What certifications should a pen test provider hold?
For UK engagements, CREST accreditation and CHECK status are the primary quality indicators. Individual testers should hold recognised qualifications such as OSCP (Offensive Security Certified Professional), CREST CRT, or equivalent. For crypto-specific work, ask providers to demonstrate prior engagements with crypto exchanges, DeFi protocols, or blockchain infrastructure operators.
Why are cheap penetration tests often not worth purchasing?
Low-cost pen tests are frequently automated vulnerability scans repackaged as manual assessments. They generate reports full of low-severity, publicly documented findings that your own team could have identified with a free scanner. They lack crypto domain expertise, do not simulate realistic attacker behaviour, and rarely include retesting to confirm that remediations are effective. In a regulated context, they may also fail to meet the evidential requirements of DORA or MiCA compliance frameworks.