How to choose a cybersecurity company: 7 criteria that matter

By the QuantumSec team

The cybersecurity market in Spain has grown enormously in recent years, and with it, providers of wildly uneven quality have proliferated. Choosing the wrong team isn't just a waste of money: it can give you a false sense of security that's worse than doing nothing at all. This guide gives you the seven criteria you should evaluate before signing any contract.

1. Certifications of the technical team (not the company)

The most common mistake is judging company certifications (ISO 27001, ENS) as an indicator of the offensive team's technical quality. They matter for processes, but they don't guarantee that the pentester auditing your system knows what they're doing.

The certifications that matter for the team doing the work:

• OSCP (Offensive Security Certified Professional): the de facto standard for pentesters. Requires compromising real machines in a 24-hour exam with no help.
• CRTO (Certified Red Team Operator): specialization in Red Team and Active Directory techniques.
• BSCP / eWPTX: advanced web security specializations.
• CEH: more theoretical, but recognized. Not sufficient on its own.

Ask directly: "What certifications do the pentesters who'll work on my project hold?" If they can't answer with specific names, be wary.

2. Methodology: recognized standards, not opaque proprietary processes

A serious cybersecurity company works following internationally recognized standards. When evaluating a provider, ask which methodologies they follow:

• OWASP Testing Guide / OWASP Top 10: for web applications and APIs.
• PTES (Penetration Testing Execution Standard): a complete pentesting framework.
• OSSTMM: focused on operational security testing.
• MITRE ATT&CK: for adversary simulation and Red Team.
• NIST SP 800-115: technical security assessment guide.

A provider that can't name any standard, or describes its methodology vaguely, should raise doubts.

3. Transparency on scope and budget

A good provider will never give you a price without first understanding what you want protected. If you get a quote in under 24 hours without being asked anything, that's a bad sign.

The correct process is:
1. A qualification meeting to understand the assets, context and goals.
2. A detailed proposal with exact scope, estimated hours, box type (black/grey/white) and deliverables.
3. A contract with confidentiality clauses (NDA) signed before any technical activity.

Scope must be defined precisely: "web application accessible at app.yourcompany.com, including the API endpoints documented in Swagger, excluding the production database environment" is a scope. "Security of your company" is not.

4. Report quality: ask to see a sample

The final report is the tangible output of a pentest. Asking to see an anonymized sample of a real report is a completely reasonable request, and a serious provider will have one ready.

A good technical report includes:
✓ Executive summary with overall risk level and top findings.
✓ Detailed description of each vulnerability with evidence (screenshots, payloads, logs).
✓ CVSS score and risk classification (critical, high, medium, low, informational).
✓ Reproduction steps: enough detail for your team to verify the finding.
✓ Specific, prioritized remediation recommendations.
✓ A roadmap: what to fix first and why.

If the "report" they show you is a PDF of Nessus screenshots with no manual analysis, it's not a pentest.

5. Post-delivery support and re-testing

A pentest doesn't end when you receive the report. The vulnerabilities found need to be fixed, and sometimes the fix introduces new issues or doesn't fully resolve the original finding.

Key questions to ask:
• Do we have access to the technical team to resolve doubts during remediation?
• Does the project include a re-test (verification of fixes)? With what scope?
• Within what timeframe?

Post-delivery support is especially important if your development team doesn't have much security experience: they'll need guidance to implement the fixes correctly.

6. References and verifiable reputation

Most cybersecurity clients don't want it mentioned that they had vulnerabilities. That's why it's normal for providers to present generic case studies without naming the client.

What you can look for:
• Presence at security events (conferences like RootedCON, h-c0n, No cON Name).
• Technical publications, CVEs found or contributions to security communities.
• Reviews on platforms like Google Business or LinkedIn.
• The LinkedIn profiles of the team's pentesters: experience, certifications, CTF participation.

And before starting any work: require an NDA. A provider that refuses to sign confidentiality agreements has a problem.

7. Specialization: not every provider is equally good at everything

A great regulatory compliance consultancy isn't necessarily the best team for a Red Team or a mobile application pentest. Specialization matters.

Aspects to dig into:
• Do they do mobile application pentesting? Do they have iOS and Android experience?
• Do they have cloud experience (AWS, Azure, GCP)? Or only on-premise networks?
• Have they audited industrial environments (ICS/SCADA) or IoT?
• Do they have Red Team and APT simulation capability, or only standard pentesting?

There's nothing wrong with a provider specializing in a specific area. What's wrong is promising to do everything perfectly when their real team only has experience in one part of it.

FAQ

Is a large company better than a small specialized consultancy?

It depends on the project. Large consultancies have more resources, but the work is usually done by a junior team with senior oversight. A mid-sized specialized consultancy usually offers more direct access to senior pentesters and greater customization. For SMBs and mid-sized companies, a specialized consultancy usually offers better value for money.

Does the cybersecurity company need to be in my city?

For most services (web, cloud, API, source code pentesting), physical presence isn't necessary: the work is done remotely. For projects involving physical access to facilities (physical Red Team, wireless network audit in the office), geographic proximity can be relevant.

How long does a pentest take from contract signing?

A standard web pentest usually runs in 1-2 weeks from kickoff. More complex projects (Red Team, large infrastructure pentesting) can extend 3-6 weeks. The report is usually delivered 3-5 business days after the technical phase ends. Good providers have a booked schedule: if your project is urgent, say so from the start.