How to Choose a Penetration Testing Company: CISO Guide

Choosing a penetration testing company is a decision you make once a year but that shapes the whole technical security posture of an organisation: which bugs get discovered, how reproducible the proof is, how remediation gets prioritised and whether the report holds up later in front of a NIS2, DORA or ISO 27001 auditor. Most RFPs compare price and surface deliverables, but the findings that change a security team's life come from three factors that rarely make it into the comparison spreadsheet: real technical profile of the team, documented methodology and the quality of the report they actually deliver.

This guide summarises what to look for when contracting a pentest provider, the red flags worth spotting before signing, the types of company available (boutique, big four, MDR/MSSP, vendor with professional services) and the concrete questions that separate a serious team from one that just goes through the motions.

What makes a good penetration testing company

Five traits shared by providers worth working with:

1. Identifiable and technically active team. The team names appear in talks, advisories, published CVEs, contributions to open source tools or public write-ups. If the website only shows client logos and nobody on the team has recent technical footprint, the audit tends to be superficial.
2. Methodology traceable to a recognised standard. OWASP WSTG and MASTG for web/mobile, OWASP API Security Top 10 for APIs, PTES and NIST 800-115 for infrastructure, MITRE ATT&CK for red team. The provider should explain which methodology they work with and map every finding to the corresponding control.
3. Anonymised sample report available. What actually gets delivered, not the marketing template. Look at: clarity of the executive summary separated from the technical detail, justified CVSS severity, reproducible proof of concept (HTTP request, screenshot, script), recommendations prioritised by effort and reference to the standard.
4. Retest included in the original scope. After the fixes, the team validates each finding and issues a remediation certificate. If retest gets charged as extra, the provider monetises your finding instead of closing it.
5. Capacity to adapt to the sector. Auditing fintech, healthcare, public sector or industry calls for different profiles. A serious team tells you when it's not their niche instead of accepting and learning with your money.

Red flags before signing

Five patterns that systematically correlate with weak audits:

• Closed proposal before technical scoping. If the salesperson quotes scope without a technical contact asking questions (how many endpoints, what user types, which critical modules, how many roles, is there SSO or API key auth), the team will improvise on arrival and the scope won't match reality.
• Just a disguised automated scanner. The proposal promises "exhaustive audit" but the real deliverable is a PDF generated by Nessus, Acunetix, Burp Pro or MobSF dressed up. Identifiable because the bug list looks suspiciously like the scanner output and the proof of concept is generic.
• Cascading subcontracting. The main company sells, a second company coordinates, freelancers from several countries execute. Each link cuts margin and quality. How to spot it: ask for the names of the people who will do the work and verify their public footprint.
• No own research or public contribution. A pentesting company that in five years has not published an advisory, a technical talk or an open source tool rarely has the technical muscle the proposal claims.
• Incomprehensible report or templated like a financial audit. The technical report should be an operational tool for your development team. If it's a 400-page corporate document with abstract risks and no concrete payloads, it doesn't help fix anything.

Types of pentesting company: when each fits

Four categories with very different profiles. None is "better" in the abstract: it depends on the asset and the moment.

Specialised boutiques

Teams of 10 to 100 people focused exclusively on offensive security. Own research, signed advisories, no aggressive sales. Examples in Spain: Tarlogic, Hispasec, BlackArrow (pentesting), Internet Security Auditors, Securízame and a group of mid-sized boutiques (Secra among them).

Where they fit: critical application, serious programme, organisation that values technical depth of the report and direct contact with whoever does the test. Year-over-year continuity is common because the team learns the context and accelerates each new cycle.

Big Four and large consultancies

PwC, Deloitte, KPMG, EY have a cyber division. They fit when the buying decision sits in the executive committee and the reputational badge matters, or when the audit is contracted as part of a broader compliance project (ENS, NIS2, ISO 27001) the same provider is already leading.

Common limitation: offensive technical profile inside the firm rotates a lot, and report depth often falls below a boutique's. The best version of a Big Four in pentesting is when they subcontract to a boutique and sign on top.

MSSP and MDR with professional services

Telefónica Tech, S2 Grupo, Innotec, Indra, GMV offer pentesting as one piece within a managed services programme (SOC, EDR, MDR, GRC). They make sense when you already consume their SOC or managed service and want to consolidate vendors.

Limitation: pentesting is usually not the core product, so deliverable quality depends a lot on the specific team assigned and on the priority the provider gives to your account.

Vendors with professional services

Some vendors (Microsoft, AWS, Cloudflare, Datadog, CrowdStrike) offer professional services that include pentesting or red team of their own platform. Useful when the asset sits inside their ecosystem and you want the test run by whoever knows the internals.

Limitation: they tend to focus on their own ecosystem. If your surface is heterogeneous (multi-cloud, multiple SaaS, on-prem infra), it doesn't cover everything.

How to compare proposals in a pentest RFP

The way to avoid comparing apples and oranges:

1. Define the scope yourself first. Which assets, which environments, which credentials, which schedule. Without fixed scope, each proposal invents its own and the numbers can't be compared.
2. Ask for proposals with the same explicit methodology. Web against OWASP WSTG, mobile against OWASP MASVS, API against OWASP API Security Top 10. If a provider changes the agreed methodology, depth changes too.
3. Compare specific profiles of the assigned team, not the firm's roster. Technical CV, signed advisories, talks, certifications (OSCP, OSWE, OSEP, CRTO) where they apply.
4. Review the anonymised sample report. If they don't deliver one, drop them. It's the only deliverable that matters.
5. Ask about the retest timeline and whether it's included or costs extra.
6. Clarify ownership of the report and findings. They stay yours, with no clauses limiting sharing with external auditors.
7. Check professional liability insurance and standard NDA.

Questions that separate the serious team from the box-tickers

Eight concrete questions for a first technical meeting with the provider:

1. Who will run the test? Name, profile and public footprint.
2. What methodology do you apply and where is it documented? If the answer is "proprietary methodology" with no detail, bad signal.
3. How do you justify the CVSS severity of each finding? Any vague answer means CVSS gets filled in by default.
4. What exactly do you deliver as proof of concept? Raw HTTP request, script, screenshot, video, payload content.
5. How do you handle critical findings during the test? Notified immediately or held for the final report?
6. Is retest included? On what timeline? What does it produce (new report, certificate, annex)?
7. How many audits in this sector have you done in the last 12 months?
8. Can you show signed advisories, talks or research from members of the assigned team?

Pentesting companies and compliance: NIS2, DORA, ISO 27001, PCI DSS

To meet compliance, not any audit will do. What each framework demands:

• NIS2 (article 21). Effectiveness of technical measures demonstrated for essential services. The audit must document methodology, representative scope and reproducible evidence. The competent authority can request the report. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (articles 24-25). Technical resilience testing with minimum annual frequency and, for significant entities, TLPT under TIBER-EU every three years. The provider must demonstrate specific capabilities for TLPT (intelligence-led, team separated from the SOC, validated threat profile). More in DORA compliance guide for financial entities 2026.
• ISO 27001:2022 (control 8.29). Security testing in the software lifecycle. The documented audit (with methodology, findings, fixes and retest) is direct evidence for the control.
• PCI DSS v4.0 (req. 11.4). Annual internal and external pentest plus after any significant change. The provider must follow an "industry-accepted" methodology (PTES, OWASP, NIST 800-115) and the team must be organisationally independent from the asset owner.

Asking the provider to state in the proposal which specific controls the deliverable maps to simplifies the auditor's job and avoids redoing audits because they don't fit the framework.

Factors that determine price (without entering specific figures)

The audit budget depends on variables worth identifying before requesting a quote:

• Asset type: web, mobile, API, internal or external infrastructure, cloud, IoT/OT, red team. Effort per unit varies significantly.
• Scope size: number of endpoints, modules, roles, devices, cloud instances.
• Methodology depth: black-box, grey-box (with credentials) or white-box (with source code and architecture). Grey-box usually gives the best quality-cost ratio.
• Target compliance: TLPT under DORA or PCI pentest demand specific profiles and evidence that raise the effort.
• Timeline: an audit with an aggressive deadline costs more than one planned two months ahead.
• Retest scope: including 1, 2 or N retests changes the final figure.

What's most useful when comparing offers is not the absolute figure but the cost per person-day of the team and the proposed duration for the same scope. Two proposals with the same final figure can hide a factor of three in real hours dedicated. More in penetration testing pricing in Spain.

Frequently asked questions

How long does it take to contract and execute a pentest?

From first contact to delivery of the final report, the typical cycle is 4-8 weeks: 1-2 weeks of scoping and proposal, 1 week of planning and kick-off, 1-3 weeks of execution depending on scope, and 1 week of report and debrief. If you need the report by a specific date (audit, release), tell the provider in the first email to confirm team availability.

When does it make sense to change pentesting provider?

When the reports bring the same findings year after year without the scope changing, when the assigned team rotates every year and the context gets lost, or when the provider starts selling more adjacent services (training, consulting) than the audit itself. A change every 2-3 years is reasonable to refresh the critical eye, without making it rigid policy.

Is a small boutique better than a large company?

It depends on the asset and the buying organisation. The boutique brings technical depth, direct contact and continuity. The large company brings geographic coverage, integration with other services and reputational badge. What matters is not size but the profile of the specific team that runs the test: ask for it by name.

Is a specific certification mandatory to audit?

OSCP is the historical reference for hands-on pentesting. OSWE for advanced web, OSEP for evasion, CRTO for red team. For mobile apps, specific certifications like OSMR are less common and advisory footprint counts more. For TLPT (DORA), TIBER-EU requires providers accredited by the ECB or the corresponding central bank. Certifications are a signal, not a guarantee.

Should the report be signed by a specific person?

Yes. The technical report is signed by the team that executed the test (not the abstract company) and usually includes the technical project lead. That signature is what an external auditor recognises as evidence that the work was done by an identifiable professional.

What do I do if the pentest findings are too many to fix?

Prioritise by real risk (probability of exploitation plus business impact), not by isolated CVSS severity. Tackle the criticals on internet-exposed surfaces first, then the criticals on internal surfaces, then the highs by category (authentication, authorisation, cryptography) and leave the mediums and lows for the next cycle. A serious provider helps you prioritise; a weak one leaves the flat list and walks away.

Related resources

• What is a penetration test: the cluster pillar, with methodology and comparisons with red team and bug bounty.
• Web application penetration testing: what the audit on the web layer concretely covers.
• API penetration testing: REST and GraphQL: the backend audit and the peculiarities versus traditional web pentesting.
• Mobile application penetration testing iOS and Android: what MASVS/MASTG demand and how iOS and Android audits differ.
• White-box vs black-box vs grey-box testing: which depth to request per scenario.
• Cybersecurity companies in Spain: how to choose: broader market context when the decision goes beyond pentesting.

How we work at Secra

At Secra we run web, mobile, API, internal and external infrastructure, cloud and red team pentesting with OWASP WSTG, MASVS, API Top 10 and PTES, identifiable team with original research (CVE-2025-40652 in CoverManager and CVE-2023-3512 in Setelsa ConacWin CB published on NVD and INCIBE-CERT), and reports with reproducible proof of concept, justified CVSS severity, retest included and mapping to NIS2, DORA, ENS, ISO 27001 or PCI DSS as applicable. If you want a concrete proposal for your scope, get in touch through contact or check the web and mobile audit, infrastructure audit and cloud audit services.