How to Choose a Penetration Testing Company: CISO Guide

How to choose a penetration testing company is a question a CISO answers once a year, but the answer shapes the whole technical security posture of the organisation: which vulnerabilities get discovered, how reproducible the proof is, how remediation gets prioritised and whether the report holds up later in front of a NIS2, DORA, PCI DSS or ISO 27001 auditor. Most pentest RFPs compare price and surface deliverables, but the findings that change a security team's work depend on three factors that rarely make it into the comparison spreadsheet: the real technical profile of the assigned team, the documented methodology and the quality of the report they actually deliver.

This guide focuses on contracting the offensive audit itself: which technical criteria to demand from the provider, the red flags worth spotting before signing, how to structure the RFP so proposals are comparable, the concrete questions for the first technical meeting and what evidence each compliance framework expects. If the decision is broader (managed SOC, GRC consulting, incident response) and you need the map of providers in the Spanish market, the dedicated guide is cybersecurity companies in Spain: how to choose.

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 OWASP MASTG for web and mobile, OWASP API Security Top 10 for APIs, PTES and NIST SP 800-115 for infrastructure, MITRE ATT&CK for red team. The provider should explain which methodology they work with, which test cases from the guide they covered and which they left out of scope, and map every finding to the corresponding control or technique.
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.

Boutique, Big Four, MSSP or vendor: what changes for pentesting

The Spanish provider market is organised in four profiles (specialised boutique, Big Four cyber division, MSSP with professional services and vendor auditing its own platform). The full map, with examples in each category and where each one fits, is in types of cybersecurity company in Spain and is not repeated here.

For pentesting specifically, the type of company matters less than three questions worth asking any of them:

• Is the offensive audit the core product or a side line? When it is a side line (common in MSSPs and generalist consultancies), the profile of the assigned team and the priority of your account determine the result more than the brand.
• Who actually runs the test? A Big Four that subcontracts to a boutique and signs on top can deliver a good report; the problem is not knowing before signing. Ask for the named team in the proposal.
• Does it cover your whole surface? A vendor's professional services know the internals of their platform, but rarely cover a heterogeneous scope (multi-cloud, several SaaS, on-prem infrastructure) without leaving gaps.

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 and important entities. The audit must document methodology, representative scope and reproducible evidence, because the competent authority can request the report. In Spain, INCIBE-CERT acts as the reference CSIRT for the private sector. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (articles 24 to 27). Digital operational resilience testing with minimum annual frequency and, for the entities designated by the competent authority, threat-led penetration testing (TLPT) at least every three years following the TIBER-EU framework. Article 27 sets requirements for testers: demonstrated technical and organisational capability, independence, professional indemnity insurance and a red team separated from the threat intelligence team. 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 (requirement 11.4). Internal and external pentest at least annually and after any significant change. The provider must follow an industry-accepted methodology (PTES, OWASP, NIST SP 800-115) and the team must be organisationally independent from the asset owner. The requirement text and the PCI SSC penetration testing guidance are in its document library.

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.

What we see in our engagements

Four signs in a proposal that tell us the work will be an automated scan with a report on top: a fixed price without having asked about roles, endpoints or environment; a one or two day timeline; no names or certifications of the team that executes; and a deliverable that is a tool export.

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.

Should I give the provider credentials or source code?

In most cases, yes. A grey-box test with credentials for each role covers more surface per hour than a black-box one, because the team does not spend days gaining access and can focus on authorisation, business logic and internal flows. White-box (code and architecture) pays off in critical modules such as authentication, payments or cryptography. Black-box makes sense when the goal is to measure exactly what an external attacker sees with no prior information. The detail is in white-box vs black-box vs grey-box testing. A serious provider proposes the mode based on the objective, not on what is most convenient for them.

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: provider types, service catalogue and sector specialisation when the decision goes beyond pentesting.
• Penetration testing pricing in Spain: indicative ranges per asset type and how to read a commercial proposal.

How we work at Secra

We apply the criteria in this guide to our own proposals: technical scoping before quoting, named team in the proposal, anonymised sample report under NDA, explicit methodology (OWASP WSTG and MASTG, API Security Top 10, PTES, NIST SP 800-115) and retest included. Our research programme has published advisories on NVD and INCIBE-CERT, including CVE-2025-40652 in CoverManager and CVE-2023-3512 in Setelsa ConacWin CB. If you want a proposal for a concrete scope, get in touch through contact or check the web and mobile audit, infrastructure audit and cloud audit services.