How to Choose the Right Penetration Testing Provider in 2026: A Decision Framework for Security Leaders

• Cyber Risk
• Offensive Security
• Threat Landscape

Choosing the right penetration testing provider in 2026 means matching the engagement model (boutique services or continuous PTaaS), testing methodology, technical depth, and regulatory context to your organization’s risk profile and security maturity. A credible provider should be able to explain how they test, which references they use, such as OWASP WSTG, NIST SP 800-115, PTES, or OSSTMM, and how findings are mapped to real-world attacker techniques using frameworks like MITRE ATT&CK. For advanced engagements, OSCP, CREST CRT/CCT, OSWE, OSEP and OSED are stronger signals than broad certification lists or entry-level credentials. The wrong provider produces long lists of low-value findings; the right one produces validated exploitation evidence, clear business impact, and remediation support through verification.

TL;DR — What every CISO should know in 2026

• The data supports the investment. Verizon’s 2025 DBIR analyzed 22,052 incidents and 12,195 confirmed breaches across 139 countries. The report found that vulnerability exploitation grew 34% year over year and now accounts for 20% of breaches. Ransomware was present in 44% of breaches, reaching 88% among SMBs, while third-party involvement doubled to 30%. Edge devices and VPNs represented 22% of vulnerability-exploitation targets, yet only about 54% of those vulnerabilities were fully remediated during the year. Against IBM’s 2025 global average breach cost of USD 4.4 million, a well-scoped penetration test is a practical way to validate exploitable risk before attackers do.
• Two engagement models serve different needs. Boutique penetration testing is best when you need depth, sector-specific threat modeling, and remediation ownership. Continuous PTaaS is better suited for frequent release cycles, broader asset coverage, and integration with development workflows. Mature security programs often use both.
• Certifications are useful, but not decisive. Treat them as supporting evidence, not the selection criterion. Methodology, scope fit, sector experience, reporting quality, and remediation support matter more than a long list of acronyms.
• Compliance shapes scope. DORA, NIS2, PCI DSS v4.0.1, CMMC 2.0, ISO/IEC 27001, SOC 2, HIPAA, and SEC cyber-disclosure expectations influence how testing should be planned, evidenced, and reported. They do not all require the same type of penetration test, so the obligation should be mapped before scoping.
• Reports without proof of exploitation are noise. Demand chained attack paths, business-impact narratives, and post-fix retest as part of the engagement, not a separate purchase.
• Pricing transparency is a buyer’s right. Most pentests cost $5K–$25K per engagement; complex enterprise tests reach $100K+; DORA threat-led engagements run $150K–$400K+. Anything below $4K for a web app pentest is an automated scan in disguise. Big 4 firms charge 2–3× boutique providers for the same scope.

Why provider selection is harder in 2026 than it was in 2024

Two structural shifts changed the pentest buyer’s landscape in 2025–2026.

Regulatory expansion. DORA has applied since January 2025 and requires financial entities to maintain digital operational resilience testing programs, with selected entities subject to threat-led penetration testing under Articles 26–27. NIS2 does not directly mandate pentesting, but Article 21 raises expectations for risk management, vulnerability handling, secure development, supply-chain security, and control effectiveness assessment. PCI DSS v4.0.1 includes explicit penetration-testing requirements under Requirement 11.4, while the SEC cybersecurity disclosure rule requires public companies to disclose material incidents within four business days after determining materiality. CMMC 2.0 is also being phased into DoD contracting requirements. Provider selection now depends on regulatory fit, not only technical fit.

Threat and exposure acceleration. Verizon’s 2025 DBIR shows that vulnerability exploitation is now close to credential abuse as an initial access vector. The key signal is not that every breach starts with a zero-day, but that exposed systems, edge devices, VPNs, credentials, third parties, and ransomware paths increasingly overlap. Generic “scan plus PDF” engagements cannot validate chained attack paths, identity abuse, business logic flaws, lateral movement, or exposure through vendors and integrations. Buyers need providers who can test realistic attack paths, not just run generic OWASP Top 10 checks.

These two forces mean the cost of choosing the wrong provider has increased. Buyers need disciplined evaluation, not a checklist of logos, tools, and generic certification claims.

What the 2025 Verizon DBIR data says about pentest priorities for 2026

Verizon’s 2025 Data Breach Investigations Report analyzed 22,052 real-world security incidents, including 12,195 confirmed data breaches, with victims spanning 139 countries. The dataset covers incidents from 1 November 2023 through 31 October 2024. For security leaders, the DBIR does not tell you what your exact scope should be, but it does show which attack patterns deserve more attention.

1. Vulnerability exploitation is now a board-level scoping issue
   Vulnerability exploitation as an initial access vector grew 34% year over year and reached 20% of breaches in the 2025 DBIR. Edge devices and VPNs represented 22% of assets targeted in vulnerability-exploitation breaches. Verizon also reported that only about 54% of those edge-device vulnerabilities were fully remediated during the year, with a median remediation time of 32 days.
   
   This does not mean every penetration test should become an infrastructure test. It means that scoping should not ignore internet-facing assets, exposed administrative interfaces, VPNs, firewalls, remote access paths, and externally reachable services. If those assets are business-critical, they should be explicitly considered during scoping.
2. Credentials remain central to initial access
   The 2025 DBIR identifies credential abuse as the most common initial access vector at 22%, followed closely by exploitation of vulnerabilities at 20%. Stolen credentials also play a major role in Basic Web Application Attacks, where the DBIR reports that 88% involved stolen credentials.
   
   For penetration testing, this points to more than password-policy checks. Credible scope should consider authentication flows, authorization boundaries, session management, MFA implementation, password reset logic, privilege escalation, identity-provider integrations, and scenarios where attackers use valid credentials rather than malware.
3. Third-party involvement is no longer peripheral
   Third-party involvement doubled to 30% of breaches in the 2025 DBIR. This does not mean every provider should test every supplier. It does mean that organizations should understand where third parties affect authentication, data access, APIs, CI/CD pipelines, managed services, SaaS integrations, and operational dependencies.
   
   A penetration test that stops at the organization’s own perimeter may miss important paths created by integrations, delegated access, supplier portals, shared cloud environments, and exposed vendor-managed services.
4. Ransomware risk is about attack paths, not just malware
   Ransomware was present in 44% of breaches in the 2025 DBIR, and Verizon reported a disproportionate impact on SMBs, with ransomware present in 88% of SMB breaches. The median ransom payment reported by Verizon was USD 115,000, while 64% of victim organizations did not pay.
   
   A penetration test should not pretend to “test ransomware” by deploying ransomware-like payloads. The safer and more useful approach is to validate the paths ransomware operators rely on: initial access, exposed services, identity compromise, lateral movement, privilege escalation, backup exposure, segmentation weaknesses, and data-exfiltration paths.
5. Human-driven paths still matter
   The DBIR continues to show the importance of the human element, with human involvement hovering around 60% of breaches. This includes social engineering, credential abuse, misuse, and error. Phishing and pretexting may not belong in every penetration test, but they should be considered when the business risk involves payment fraud, helpdesk abuse, privileged access, sensitive data workflows, or executive impersonation.
   
   For mature programs, phishing simulation should be separated from technical penetration testing unless the engagement is explicitly designed as a social engineering or red team exercise. The important point is not to mix everything into one engagement, but to test the attack paths that actually matter.

A defensible priority map for pentest scope

DBIR data should not be copied into scope mechanically. It should be translated into practical testing priorities based on the organization’s assets, business model, regulatory obligations, and threat exposure.

DBIR signal	What it means for scoping	Practical testing focus
Credential abuse: 22%; vulnerability exploitation: 20%	Identity and exposed systems are both primary attack surfaces	Authentication, authorization, session handling, MFA, password reset, exposed applications
Edge devices and VPNs: 22% of vulnerability-exploitation targets	Perimeter and remote-access technologies need explicit attention	VPNs, firewalls, exposed admin interfaces, remote access paths, patch posture
Third-party involvement: 30% of breaches	Supplier, SaaS, API, and managed-service dependencies can create real attack paths	SaaS/API integrations, delegated access, support portals, CI/CD workflows
Ransomware: present in 44% of breaches	Ransomware risk should be validated through attack paths, not malware deployment	Initial access, identity compromise, lateral movement, privilege escalation, segmentation, backup exposure
Basic Web Application Attacks: about 88% involved stolen credentials	Web and API testing should include identity and account-abuse scenarios	Account takeover, credential-based abuse, authorization flaws, session management, MFA edge cases
Human element: around 60% of breaches	User-driven and process-driven attack paths should be considered where business risk justifies it	Helpdesk abuse, payment-process manipulation, privileged access workflows, phishing or pretexting where in scope

These are not mandatory scope items for every engagement. They are evidence-based signals that should be considered during scoping. A credible provider should be able to explain why each item is included, excluded, or handled through a separate engagement.

Pentest ROI in context — the business case

IBM’s 2025 Cost of a Data Breach Report puts the global average cost of a data breach at USD 4.4 million, a 9% decrease from the previous year. That number should not be used as a precise forecast for your organization. Breach cost depends on industry, geography, data type, response maturity, legal exposure, downtime, and regulatory context.

For regulated organizations, breach exposure can extend beyond direct response cost. GDPR administrative fines can reach up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. Under NIS2, essential entities may face administrative fines of at least EUR 10 million or 2% of worldwide annual turnover, while important entities may face fines of at least EUR 7 million or 1.4%.

The better business argument is not “a pentest is cheaper than a breach.” That is too simplistic. The stronger argument is that penetration testing helps validate whether security controls actually reduce exploitable risk. A good engagement can reveal whether a vulnerability is merely theoretical, whether it can be chained into business impact, and whether remediation actually closes the path.

For CFO and board discussions, frame penetration testing as evidence generation:

• It validates exploitable risk before attackers do.
• It gives development and infrastructure teams prioritized remediation work.
• It supports audit and compliance evidence where testing is required or expected.
• It helps leadership understand business impact rather than only technical severity.
• It provides a baseline for retesting and continuous improvement.

Penetration testing is not where organizations should chase the cheapest possible option. The real value is not the number of findings. The value is defensible evidence, prioritization, and verified closure.

Step 1 — The seven questions every CISO should answer before issuing an RFP

Before talking to any provider, answer these internally. Most weak engagements start with unclear scope, not weak tooling.

1. What are we actually protecting? Customer data, financial transactions, intellectual property, operational uptime, regulated workloads, and critical business processes each imply a different test design.

2. Which regulations require this test? DORA, NIS2, PCI DSS v4.0.1, SOC 2, HIPAA, CMMC 2.0, ISO/IEC 27001 — each prescribes specific testing requirements. Document the obligation before scoping.

3. What is the maturity of our security program? An organization at an early stage of security maturity needs a different engagement than a regulated enterprise validating control effectiveness across critical systems.

4. Which attack paths are most relevant to our sector and business model? Financial services, healthcare, energy, manufacturing, public sector, and technology companies face different exposure patterns, data risks, and regulatory expectations. Threat-informed scoping can use well-documented actor examples, such as FIN7, Sandworm, APT29, or APT41, but the scope should be based on realistic attack paths, not actor-name dropping.

5. Will internal teams remediate findings, or do we need fix support? Many providers stop at the report. Some own remediation through fix verification. The right answer depends on internal capacity.

6. Is this a one-time exercise or part of a continuous program? Continuous testing changes the provider model, cadence, reporting structure, and integration with engineering workflows.

7. What’s our reporting consumer? A board needs business-impact narratives. An auditor needs evidence and methodology disclosure. A development team needs reproducible exploitation steps. Different audiences, different deliverable formats.

Until these are answered, no provider — Velstadt included — can scope your engagement responsibly.

Step 2 — Boutique services vs continuous PTaaS: pick the right model first

This is the single most under-discussed decision in the buyer’s journey. Generic “how to choose a pentest provider” articles treat all providers as equivalent. They are not.

Boutique penetration testing services (Velstadt, NetSPI, Bishop Fox, Sentrium)

• What it is: Engagement-based, expert-led testing against a defined scope over a defined period.
• Best fit when: You need deep exploitation evidence, sector-specific threat modeling, regulated-industry reporting, complex business logic testing, or remediation support through verification.
• Strengths: Manual depth, business-context-aware testing, clear accountability, tailored reporting, and stronger ability to investigate non-obvious attack chains.
• Limitations: Lower throughput; testing is point-in-time unless contracted for repeat engagements.
• Pricing: Typically $15,000–$120,000 per engagement, depending on scope.

Continuous PTaaS platforms (Cobalt, Synack, BreachLock, Astra, Horizon3.ai)

• What it is: Subscription-based testing model that usually combines platform workflows, recurring testing, triage, ticketing, retesting, and sometimes crowdsourced or distributed tester capacity.
• Best fit when: You need frequent testing across many releases, faster retesting, broad asset coverage, integration with development workflows, or continuous vulnerability intake.
• Strengths: Throughput, repeatability, developer workflow integration, faster retest cycles, and better fit for high-change environments.
• Limitations:  Depth can vary by tester, scope, and platform model. Sector-specific threat modeling and complex business logic testing may require additional expert-led work.
• Pricing: Typically $20,000–$120,000+ per year, scaling with assets and test frequency.

Decision rule

If your security program prioritizes depth, sector specialization, and regulated-industry rigor — choose a boutique services provider. If your security program prioritizes throughput, developer integration, and continuous coverage — choose a continuous PTaaS platform. Many mature organizations use both. Most under-resourced ones pick one and overuse it.

Step 3 — Velstadt’s 12-Point Provider Evaluation Framework

Use this framework whether you are evaluating Velstadt or any other provider.

#	Criterion	What to demand	Why it matters
1	Named delivery team	The proposal identifies the engagement lead and the testers who will perform the work, including their relevant experience	Reduces ambiguity, rotation risk, and generic “senior team” claims
2	Scope discovery	A discovery process covering business context, assets, constraints, objectives, and reporting needs	Good testing starts before tooling
3	Relevant credentials	OSCP, CREST CRT/CCT, OSWE, OSEP, OSED or other scope-relevant credentials	Credentials should support the scope, not decorate the proposal
4	Methodology	OWASP WSTG, NIST SP 800-115, PTES, OSSTMM, and ATT&CK mapping where relevant	Prevents ad hoc testing hidden behind “industry standard” language
5	Manual and automated balance	Explanation of what is automated, what is manual, and where expert judgment is applied	Automation supports testing; it does not replace it
6	Sector experience	Comparable work in your industry or regulatory environment	Sector context changes test design and reporting
7	Regulatory and audit context	The provider understands which regulatory or audit expectations affect scope, evidence, reporting, and retesting	Prevents technically useful reports that do not support audit, board, or compliance needs
8	Proof of exploitation	Safe, authorized evidence showing exploitability and business impact	Reduces theoretical findings and improves prioritization
9	Remediation guidance	Specific code-level, configuration-level, or process-level recommendations	Generic advice does not close gaps
10	Retest workflow	Included or clearly priced post-fix validation	Findings should not remain unverified
11	Evidence handling	NDA, rules of engagement, secure evidence storage, data minimization, and cleanup process	Pentest evidence can be sensitive or regulated
12	References or proof of work	Relevant case studies, references, or anonymized examples where possible	Helps validate delivery quality beyond sales claims

A provider does not need to be perfect on every item for every engagement. But if several of these areas are vague, the risk of a low-value engagement increases.

Step 4 — Certifications and accreditations decoded

Certification lists are often misleading. The question is not whether a company can display many acronyms. The question is whether the qualifications are relevant to the scope and supported by actual delivery experience.

Strong baseline signals

• OSCP (Offensive Security Certified Professional) — a widely recognized practical baseline for hands-on penetration testing. It is not the highest-level offensive certification, but it remains a credible signal of exploitation capability.
• CREST CRT (Council of Registered Ethical Security Testers, Registered Penetration Tester) — an intermediate-level, practical penetration testing certification that validates competence in core infrastructure and web application penetration testing. It is especially relevant in UK/EU and regulated procurement contexts where buyers value formal assurance around tester capability and delivery standards.
• GIAC GPEN / GWAPT (Global Information Assurance Certification) — useful professional certifications for network and web application penetration testing, especially in enterprise, US federal, and DoD-adjacent environments.

Advanced and specialist signals

• OSWE (OffSec Web Expert) — an advanced web application exploitation certification focused on source-code-assisted vulnerability discovery, exploitation, and advanced web attack techniques.
• OSEP (OffSec Experienced Penetration Tester) — an advanced penetration testing certification focused on evasion, lateral movement, bypassing defenses, and operating in hardened enterprise environments.
• OSED (OffSec Exploit Developer) — an advanced exploit development certification focused on Windows user-mode exploit development, shellcode, and bypassing memory protections.
• OSCE3 (OffSec Certified Expert 3) — an advanced OffSec designation awarded to candidates who hold OSEP, OSWE, and OSED. It signals breadth across advanced penetration testing, web exploitation, and exploit development.
• GXPN (GIAC Exploit Researcher and Advanced Penetration Tester) — an advanced GIAC certification that validates exploit research, advanced penetration testing, and deeper technical exploitation skills.
• CRTL (Certified Red Team Lead) — an advanced red team certification focused on planning, executing, and leading adversary-simulation engagements.
• CRTO (Certified Red Team Operator) — a red team operations certification focused on adversary simulation, offensive tradecraft, and practical operator skills.
• CRTP (Certified Red Team Professional) — an Active Directory-focused certification that validates knowledge of enterprise identity attack paths, privilege escalation, lateral movement, and domain compromise techniques.

Useful but not sufficient on their own:

• CEH (Certified Ethical Hacker) — an entry-level signal. It may show basic familiarity with ethical hacking concepts, but it should not be treated as sufficient evidence for serious regulated or advanced penetration testing.
• CISSP (Certified Information Systems Security Professional) — a security management and governance credential, not a hands-on penetration testing certification. It can be useful for engagement leadership, governance context, and executive communication, but it does not prove technical testing ability.

Scope-specific signals

• AWS Certified Security – Specialty — a cloud security certification relevant when Amazon Web Services environments are in scope. It should be paired with practical AWS security testing experience.
• Azure security certifications — cloud security certifications relevant when Microsoft Azure environments are in scope, especially for identity, cloud configuration, and workload security testing.
• Google Cloud security certifications — cloud security certifications relevant when Google Cloud environments are in scope, especially for IAM, cloud architecture, and workload security testing.
• Scope-specific certifications — examples include CKS (Certified Kubernetes Security Specialist) for Kubernetes security, OSWP (OffSec Wireless Professional) for wireless testing, GMOB (GIAC Mobile Device Security Analyst) for mobile device and application security, and GRID (GIAC Response and Industrial Defense) for ICS/OT environments (it is more of an OT/ICS defense and response signal than a general penetration testing credential). These are useful when those technologies are part of the engagement scope, but they should not be treated as general proof of penetration testing depth.

The practical rule: certifications should support the scope. They do not replace methodology, delivery experience, reporting quality, and proof of exploitation.

Step 5 — Methodology: what to demand

A credible provider can explain its testing process, map it to recognized references, and show how evidence will be collected and reported.

The key references are:

• OWASP Web Security Testing Guide (WSTG) — appropriate for web applications and web services. It provides a structured reference for areas such as authentication, authorization, session management, input validation, and business logic. For dedicated scopes, it should be complemented with specialized OWASP references: OWASP API Security Top 10 for API risks, OWASP MASVS/MASTG for mobile applications, and OWASP AISVS/AI Testing Guide for AI-enabled systems.
• NIST SP 800-115 —  a technical guide for planning and conducting information security testing and assessment, analyzing findings, and developing mitigation strategies.
• OSSTMM (Open Source Security Testing Methodology Manual) — useful for structured, audit-friendly, and controls-oriented security testing.
• PTES (Penetration Testing Execution Standard) —  useful for engagement lifecycle structure, from pre-engagement interaction through intelligence gathering, threat modeling, exploitation, post-exploitation, and reporting.
• MITRE ATT&CK — not a penetration-testing methodology by itself, but a knowledge base of adversary tactics, techniques, and procedures (TTPs) based on real-world observations. It is useful for mapping tested behaviors and findings to attacker techniques.

For mature engagements, the report should include specific references where useful: OWASP WSTG categories, NIST testing phases, and MITRE ATT&CK technique IDs. This helps technical teams reproduce findings and helps auditors understand what was actually tested.

Step 6 — Pricing models and total cost of ownership

Penetration testing pricing varies widely. Any exact market range should be treated as a planning estimate, not a universal benchmark. The price depends on scope, number of assets, authentication complexity, business logic, cloud footprint, testing depth, reporting expectations, retesting, and regulatory requirements.

As a practical market-observed planning view:

Engagement type	Typical planning range	Notes
Small web application pentest	USD 5,000–25,000	Depends heavily on roles, flows, API scope, and business logic
Complex web/API pentest	USD 25,000–75,000+	Common where multiple roles, integrations, APIs, and payment/data flows are in scope
Network penetration testing (external and/or internal)	USD 5,000–80,000+	Covers internet-facing infrastructure and/or internal network paths, including public IPs, exposed services, VPNs, firewalls, remote access, segmentation, credentialed access, Active Directory, lateral movement, and reporting depth
Cloud security assessment / cloud pentest	USD 15,000–80,000+	Depends on provider, accounts/subscriptions/projects, IAM complexity, and architecture
Red team / adversary simulation	USD 50,000–250,000+	Depends on duration, objectives, stealth requirements, and rules of engagement
Continuous PTaaS	USD 20,000–120,000+ per year	Depends on asset count, test frequency, retest workflow, and platform model
DORA TLPT-style engagement	Often significantly higher	Scope, regulatory coordination, threat intelligence, critical functions, and live-system testing can materially increase cost

Very low quotes should be treated with caution, not automatically rejected. A low price may reflect narrow scope, a small application, local market rates, or a limited validation exercise. But if the provider cannot explain manual testing effort, methodology, evidence, reporting, and retest process, the buyer should assume the engagement may be closer to a vulnerability scan than a penetration test.

Hidden cost factors (often quoted separately)

• Retesting: included, limited, or separately priced.
• Out-of-scope findings: how the provider handles issues discovered outside the agreed scope. A credible provider should document the issue as informational or separately reportable, avoid unauthorized testing, and agree on next steps before expanding activity.
• Reporting customization: whether technical, executive, auditor-facing, and board-ready reporting are included by default. Custom formats, board briefings, regulator-facing evidence packs, or additional review cycles may increase cost and should be clarified before signing.
• Business logic: complex workflows require more manual analysis than standard vulnerability checks.
• On-site testing: OT/ICS, restricted networks, or highly regulated environments may add travel and coordination cost.
• Third-party coordination: vendors, managed services, and shared infrastructure require more scoping discipline.
• Threat intelligence add-on: sector-specific TTP modeling (Sandworm, FIN7-adjacent, RaaS profiles). Velstadt’s Phantom platform is included in regulated-industry engagements; standalone TI subscriptions from external providers run $50,000+ per year.

First-year total cost of ownership

The first-year cost may be higher than the initial engagement price if retesting, custom reporting, stakeholder briefings, regulator-facing evidence packs, travel, third-party coordination, or expanded scope are not included. Buyers should compare providers based on included deliverables, retest terms, reporting depth, evidence quality, and remediation support — not only the headline quote.

The lowest headline price is rarely the lowest total cost if the report cannot support remediation, audit, or board-level risk decisions.

Step 7 — Compliance framework mapping

Map the obligation before scoping the test. The point is not to force every framework into a pentest. The point is to understand what evidence the organization needs. The examples below are not exhaustive. Other legal, regulatory, contractual, and internal audit requirements may also influence testing scope and evidence needs.

Framework / regulation	Practical testing implication
DORA	Financial entities must maintain digital operational resilience testing. Selected entities must conduct TLPT under Articles 26 and 27 against critical or important functions.
NIS2	Article 21 requires appropriate and proportionate cybersecurity risk-management measures. Penetration testing may support evidence of vulnerability handling, secure development, supply-chain security, and control effectiveness, but NIS2 should not be oversimplified as a direct pentest mandate.
PCI DSS v4.0.1	Requirement 11.4 includes internal and external penetration-testing expectations, generally at least annually and after significant changes, with segmentation testing where segmentation is used.
SOC 2	SOC 2 does not explicitly require penetration testing or prescribe one universal pentest format. However, penetration testing is commonly used as evidence that relevant security controls, vulnerability management processes, and risk mitigation activities are designed and operating effectively under the Trust Services Criteria.
ISO/IEC 27001	ISO/IEC 27001 does not mandate a universal penetration testing cadence. However, risk-based security testing can support the ISMS by validating vulnerability management, secure development, risk treatment, and continual improvement activities.
HIPAA	The HIPAA Security Rule requires covered entities and business associates to conduct risk analysis and implement administrative, physical, and technical safeguards for ePHI. Penetration testing is not named as a universal requirement, but it can support risk analysis, risk management, and validation of technical safeguards.

Velstadt scopes penetration testing engagements with regulatory, audit, and contractual expectations in mind. The goal is to produce evidence that supports compliance and risk-management needs, not just a generic list of findings.

Step 8 — What good reporting looks like

Reports are where pentest engagements either earn their fee or quietly waste it. Here is the bar.

Executive summary: business-language risk narrative, scope overview, key findings, likely impact, top remediation priorities, and board-ready conclusions.

Technical report: each finding should include affected assets, reproducible steps, supporting evidence such as request/response data or screenshots, severity rationale, CVSS v4.0 where appropriate, business impact, relevant OWASP/NIST references, MITRE ATT&CK mapping where useful, and actionable remediation guidance.

Remediation plan: prioritized fixes, suggested owners where known, recommended timelines, dependencies, and compensating controls where immediate remediation is not possible.

Raw evidence package: captured artifacts, scripts used, log files — auditor-ready.

Optional board briefing: a concise presentation for executives or the board covering security posture, material risks, remediation priorities, and peer or industry context where available.

Retest deliverables: post-fix verification report confirming each finding is closed, partially mitigated, or accepted as residual risk with documentation.

If a provider’s sample report is a generic vulnerability list with no exploitation evidence and no business-impact narrative — they are running a vulnerability scan dressed as a pentest. Walk away.

Step 9 — Red flags that justify additional due diligence

These conditions do not always mean the provider is bad, but they should slow the buyer down.

1. They quote without discovery. A credible provider should understand business context, scope, assets, test objectives, constraints, and reporting needs before issuing a serious proposal.
2. They describe tools but not methodology. “We use Burp Suite, Nessus, and Metasploit” is not a methodology. Tools support testing; they do not define it.
3. They avoid explaining manual testing. Automation is useful, but it cannot reliably replace business logic testing, authorization testing, chained exploitation, or contextual risk analysis.
4. They cannot provide a redacted sample report or report structure. Confidentiality matters, but credible providers should still be able to show report quality without exposing client data.
5. They overpromise compliance. A provider can help produce evidence, but it should not claim that one pentest automatically makes the organization “DORA compliant,” “NIS2 compliant,” or “ISO compliant.”
6. They treat MITRE ATT&CK as a pentest methodology. ATT&CK is valuable for mapping adversary behavior, but it is not a substitute for a testing methodology.
7. They cannot explain retesting. Findings are not truly closed until remediation is verified or risk is formally accepted.
8. The proposal price is dramatically below market. A $1,500–$4,000 “comprehensive web app pentest” is a vulnerability scan or an inexperienced provider. The real cost of a low-quality engagement is the post-incident remediation that follows when an attacker finds the missed exploit.
9. They refuse to define evidence handling. Pentest evidence can include sensitive data, tokens, screenshots, credentials, payloads, and logs. Handling rules must be clear.
10. They cannot identify the delivery team. A credible provider should be able to name the engagement lead and describe the testers’ relevant experience before work begins. Anonymous “senior team” claims increase rotation risk and make credentials harder to verify.
11. They cannot show comparable work. Claims like “we work with Fortune 500 clients” mean little without relevant case studies, anonymized examples, or references from organizations with similar size, scope, or regulatory exposure. If references are not available, the provider should still be able to show credible evidence of comparable delivery experience.

Why Velstadt approaches penetration testing differently

Velstadt’s penetration testing practice combines offensive security expertise, threat intelligence context, and remediation-focused delivery for mid-market and enterprise organizations.

Threat-informed context. Velstadt operates from Ukraine’s high-intensity threat environment, where organizations have faced sustained cyber pressure since 2022, including destructive malware, ransomware activity, espionage-driven operations, and attacks affecting critical infrastructure, financial services, logistics, technology, and public-sector ecosystems. This context helps Velstadt design testing scenarios around realistic attack paths rather than generic checklist execution.

Phantom Threat Intelligence Platform integration. Where relevant, penetration testing engagements draw on Velstadt’s proprietary Phantom Threat Intelligence Platform (backed by Google) for sector-specific threat context, external exposure correlation, dark web signals, credential exposure, and adversary-TTP-aligned testing scenarios. This does not turn every pentest into a red team engagement, but it helps align testing with the threats most relevant to the client’s environment.

Remediation through verification. Engagements focus on validated findings, practical remediation guidance, and post-fix verification. The goal is not to maximize the number of findings, but to help clients close exploitable paths and produce evidence that can be used by technical teams, auditors, executives, and boards.

Market recognition and client feedback. Velstadt’s penetration testing practice was recognized in 2025 by Clutch as a Top Software Testing Company in New York City (#17 of 175). In addition to Clutch recognition, Velstadt was named TechBehemoths Best Cybersecurity Provider 2025 and recognized in five Techreviewer.co 2025 leadership lists, including Top 100+ Cybersecurity Companies and Top Cloud Consulting Companies. All 12 published Clutch client reviews rate Velstadt 5 of 5. These recognitions should not replace technical due diligence, but they provide additional market validation.

Frequently asked questions

What should I look for in a pentest provider?
Named pentesters with verifiable certifications (OSCP, CREST, GIAC etc.), clearly disclosed methodology (OWASP / NIST SP 800-115 etc.), sector experience matching your industry, compliance accountability matching your regulatory obligations, proof of exploitation in sample reports, and retest as a contracted deliverable.

How much does penetration testing cost in 2026?
Pricing varies by scope, complexity, testing depth, reporting requirements, retesting, and regulatory expectations. As market-observed planning ranges, small web application pentests often fall around USD 5,000–25,000, while complex web/API engagements can reach USD 25,000–75,000+. Network penetration testing, external and/or internal, commonly ranges from USD 5,000–80,000+, depending on exposed assets, segmentation, credentialed access, Active Directory complexity, and lateral movement scope. Cloud security assessments or cloud pentests often fall around USD 15,000–80,000+, red team or adversary simulation engagements can reach USD 50,000–250,000+, and continuous PTaaS subscriptions often range from USD 20,000–120,000+ per year. DORA TLPT-style engagements are usually significantly higher because they may include threat intelligence, red team execution, white-team coordination, critical-function scoping, regulatory expectations, and detailed reporting.

What’s the minimum I should pay for a credible web application pentest?
There is no defensible universal minimum. A very small and narrowly scoped test can cost less than a complex enterprise engagement. The better question is whether the provider can explain the manual testing effort, coverage, methodology, evidence, reporting format, and retest process. If those are unclear, the low price is a risk signal.

Why do Big 4 consulting firms charge 2–3× more than boutique providers? Big 4 (Deloitte, PwC, EY, KPMG) prices reflect brand premium, broader scope of practice, and standard global rates rather than specialized depth. Buyers who need brand-mandated reporting (board, regulator, M&A diligence) sometimes choose Big 4 for the badge. Buyers who need exploitation depth, sector specialization, and named pentester accountability typically get better outcomes from boutique providers at one-half to one-third the cost.

What certifications should pentesters have?
Certifications should match the engagement scope. OSCP, CREST CRT, and relevant GIAC certifications are useful baseline signals, while advanced or specialist work may require more specialized credentials. CEH alone is not enough for serious testing, and CISSP does not prove hands-on penetration testing capability.

What is the difference between boutique and continuous penetration testing?
Boutique penetration testing is engagement-based, expert-led, and depth-oriented. It is best for critical systems, regulated contexts, business logic, and remediation ownership. Continuous PTaaS is subscription-based and throughput-oriented. It is best for frequent testing, release-cycle coverage, and developer workflow integration. Mature programs often combine both.

How long does a penetration test take?
A focused web application test may take one to four weeks depending on scope. Larger network, cloud, or multi-application engagements can take several weeks. Red team and adversary simulation engagements often take longer because they require planning, rules of engagement, stealth constraints, execution phases, and detailed debriefing. The timeline should be based on scope, not a generic promise.

How often should we run a penetration test?
Frequency depends on risk, regulatory obligations, change rate, and business criticality. As a concrete example, PCI DSS v4.0.1 requires internal and external penetration testing at least annually and after significant changes. High-change or critical environments may need more frequent testing, continuous PTaaS, or targeted retesting after material changes.

What is proof of exploitation?
Proof of exploitation is concrete evidence that a finding can be exploited in the tested environment, within the agreed rules of engagement. It may include request/response evidence, screenshots, demonstrated privilege escalation, controlled data access, chained attack paths, or safe simulation of impact. It should be collected carefully, minimized, protected, and documented.