Cybersecurity companies in Spain: how to choose one

What you are actually buying under that name

"Cybersecurity company" is a label covering three businesses that have little in common, and confusing them is the mistake that costs most.

• Offensive security. People who attack your systems with your written permission, to find how somebody without permission would get in. That is pentesting (penetration testing), red team and phishing simulation.
• Defensive security and operations. Whoever watches, detects and responds: SOC, monitoring, incident handling. It is bought by the month, not by the project.
• Compliance. Whoever takes you through certifying a management system or meeting a sector rule. It is documentation consultancy with an audit at the end.

All three are necessary and none replaces the others. A SOC does not tell you whether your application has an authorisation vulnerability, and a certificate does not tell you whether a hacker would get in today. Before asking for a quote it pays to know which of the three you need, because the same brochure sells all three and the price does not tell them apart.

Asperis does the first one: offensive security, with compliance as a consequence rather than as a separate product. If you want a provider on the ground in Spain, the Barcelona page explains how we work from there.

1. The scope, and why it is written before anyone signs

The scope comes first because it decides everything else: the price, the duration, what gets found and what does not. A fixed price on an open scope is not a commercial advantage, it is a postponed argument.

What has to be in writing, at this level of detail:

• What is in, itemised. Domains, IP ranges, applications, APIs, cloud accounts, wifi networks, mobile applications. And what is out, said with the same clarity.
• Where the testing is done from. With no credentials, as a normal user, as an administrator, from inside the network or from the internet. The same application gives different results in each case.
• Environment. Production or pre-production, and if it is pre-production, how it differs from production. A copy without the same data and the same configuration does not prove the same thing.
• Window and notifications. When traffic can be sent, who is told beforehand and who is not, and what happens if something falls over.
• What is forbidden. Denial of service, social engineering against named individuals, real exfiltration of customer data.

All of that together has a name in the industry, the rules of engagement, and it is the document that turns an attack into a lawful service. If a provider does not bring it as standard, that is not a paperwork detail: it means they are going to improvise.

Before discussing the scope it helps to know what you have exposed, which is usually more than what is in the inventory. That is your attack surface, and measuring it is a job in itself.

2. The methodology, and what changes when they name it

Ask which methodology they follow and ask them to name it. This is not a formality: a public methodology is a list of things that have to be tested, so naming it is committing to a verifiable minimum. Without one, coverage depends on the memory and the mood of whoever you get.

For web applications the usual reference is the OWASP testing guide, and the OWASP Top 10 is its best known summary. Be careful with that last point, because it is a frequent and expensive confusion: the Top 10 is a list of risk categories, not a test plan. A provider offering "we cover the OWASP Top 10" is offering less than it sounds.

And there is one question that separates manual work from automated work better than any other: which part of the finding is found by a tool and which part is found by a person. A scanner finds old versions and default configurations. It does not find that customer A’s invoice identifier works inside customer B’s session, because that requires understanding what your business does. If the answer is vague, the answer is that there is no manual work.

When what you want tested is not an application but the ability to detect and respond, the format is different: a red team, which pursues a specific objective without warning the defending team, or an assumed breach exercise, which starts from the assumption that the attacker is already inside and measures how far they get.

3. Who does the work, not who signs the proposal

In this industry the result depends on the person assigned more than on almost anything else. So the useful question is not how many people the company has, but who is going to be on your project.

• Names and profiles of the assigned team, not of the whole roster. And if they change, ask to be told.
• Certifications, with what they mean. The ones earned by sitting a practical exam of several hours against real machines say something different from the ones passed with a multiple choice test. Ask which is which and why they bring it.
• Published work of their own. Reported vulnerabilities, tools, talks, advisories. It is the cheapest way of checking that there is craft behind the sales.
• Subcontracting. If part of the work is subcontracted, to whom and under what confidentiality agreement.
• Professional liability insurance and what it covers. You are about to give somebody permission to attack your systems.
• Contactable references from projects like yours. The published case studies show the kind of work; a phone call covers the rest.

We say who we are on our team page, and that is exactly the level of detail worth demanding from anyone, ourselves included.

4. The deliverable, which is all that is left when they finish

Ask for a sample report before you sign, anonymised. It is the request that yields the most information and the one fewest providers expect. What to look for in it:

• That every finding can be reproduced. The exact request, the steps, screenshots or a trace. If your team cannot repeat it, they cannot fix it or check that they fixed it.
• Impact on your business, not only technical severity. CVSS is a useful scale and it is not a priority: a medium severity flaw in the payments system comes before a high one in the canteen intranet. The report has to say what breaks if that is exploited, with your own systems in front of it.
• How to fix it, specifically. "Sanitise the input" is not a recommendation, it is a category. A recommendation says what to change and where.
• An executive summary that stands on its own. Somebody who is not technical is going to decide the remediation budget from that page.
• What was tested and came back clean. A report that only lists failures does not let you tell what is fine from what was never looked at.

And a practical question that saves weeks: in what format do they deliver. A PDF is a document; findings inside your own issue tracker are work already started. In our case findings live on the platform from the moment they are found, not at the end.

5. The retest, which is where you see whether it was worth anything

A pentest without a retest is a photograph. Somebody tells you what is wrong, your team fixes it, and nobody checks that what was fixed is actually fixed. It is surprisingly common for the fix to close the path that was tested and leave the one next to it open.

What has to be closed off in the contract:

• Whether the retest is included or billed separately. Both answers are legitimate; what is not legitimate is leaving it unanswered until the invoice arrives.
• How long you have to request it after the report is delivered.
• What it covers. Only the fixed findings, or also whatever changed around them.
• What document it produces. The usual output is a version of the report with each finding marked as fixed, mitigated or open, which is what you later show a customer or an auditor.

And a recommendation that costs nothing: agree beforehand who fixes, within what deadline by severity, and who decides whether a risk is accepted instead of corrected. Reports almost always get stuck there, not on the technical side.

6. What the rules will ask of you: ENS, ISO 27001, NIS2 and DORA

Often the search for a cybersecurity company does not come from a scare but from a requirement. It pays to know which one applies to you before asking for a quote, because it changes the deliverable.

• ENS, the Esquema Nacional de Seguridad. This one is Spanish and not European: it is the national security framework that sets the security requirements for the information systems of Spanish public administration. It classifies systems by category and requires periodic audit, and it reaches private companies through their contracts: if you sell to the Spanish public sector, this ends up arriving even though you are a private company. We cover it in the ENS service.
• ISO 27001. It certifies an information security management system, not a product and not an application. It is audited by an accredited certification body, which cannot be the same one that implements the system for you. A pentest certifies nothing on its own, but it is the evidence several of the controls rest on. It goes in the ISO 27001 service.
• NIS2. A European directive that raises the bar for essential and important entities in sectors such as energy, transport, health, water and digital infrastructure. Two things set it apart from the above: it makes management directly accountable, and it requires significant incidents to be notified within short deadlines. And it reaches the supply chain, so it can arrive as a clause from your customer.
• DORA. A European regulation for the financial sector and its technology providers. It is the one that affects what you are buying the most, because for certain entities it requires threat intelligence led penetration testing, TLPT, which is not a normal pentest: it is driven by intelligence on real attackers in your sector and it has its own requirements for how it is run and who may run it.

The question to ask a provider is not whether they "work with" these rules, but what specific evidence their work produces that you can put in front of an auditor. And if what you need is personal data protection, that is a different conversation and it goes through GDPR, the European regulation Spanish texts call the RGPD.

7. The signs you are about to be sold a scanner, and the list to take with you

None of these signs is conclusive on its own. Two or three together are.

• A fixed price without anyone having asked about the scope. If nobody has asked how many applications there are or what they do, the number comes from a template.
• A two day timeline for "the whole infrastructure". What fits into two days is one pass of a tool.
• The sample report looks like an export. Hundreds of findings, all in the same format, none with a reproducible request, and chapters that talk about ports and versions but not about your business.
• There are no rules of engagement.
• There is no retest, or "we will see".
• You do not know who is going to do it.
• Certifications are sold as if they were results. A logo on the proposal is not a finding.

The short list, to take into the meeting: a written and itemised scope; a named methodology; what is manual and what is automated; the names of the assigned team; an anonymised sample report; business impact as well as severity; a retest with closed conditions; insurance; contactable references; and what evidence it produces for the rule that applies to you.

If it helps as a comparison, this is how we answer those ten: the catalogue is at services, ethical hacking is the usual way in, and at contact you can ask for the sample report with no commitment. And if you want the ground under all of it first, what a penetration test actually is and what it produces is set out in this guide, and if you would rather start from the basics and in order, the guide to cybersecurity for companies comes before all of this.