Cómo elegir una empresa de pentesting

Comprar un pentest no se parece a ninguna otra compra de informática. Abres tus sistemas a personas que no conoces, sobre plataformas donde hay datos de clientes, y lo único que te permite juzgar la calidad del trabajo llega después de la factura: el informe. Hasta ese momento compras una promesa.

Y no tienes una muleta institucional. En un encargo privado no hay un registro que ordene el mercado ni una acreditación general que haya que exhibir para ejecutar la prueba técnica. Eso no es un vacío legal, es simplemente la situación: el mercado del pentesting en España está abierto, y el filtro lo pones tú. La otra cara es que existen puertas cerradas muy concretas —la certificación del ENS, el TLPT del marco TIBER-ES, la información clasificada— y conviene reconocerlas antes de pedir presupuesto. Ese reparto lo desarrollamos aparte, en contratar una empresa de pentesting no española; aquí damos por hecho que el criterio es tuyo y nos ocupamos de cómo aplicarlo.

Lo que sigue es la parte del trabajo que te toca a ti: qué preguntar antes de firmar, qué tiene que decir el contrato, cómo se lee un presupuesto línea a línea, cómo se reconoce un informe que vale lo que cuesta y qué señales conviene tratar como motivo de descarte.

Empieza por comprar la cosa correcta

Los títulos varían de una oferta de empleo a otra: «hacker ético», pentester, auditor técnico, «white hat». El trabajo, no. Y se parece poco a la figura encapuchada de los bancos de imágenes: consiste sobre todo en leer, probar y dejarlo escrito.

• Reconocimiento de la superficie de exposición. Qué se ve desde fuera, qué subdominios siguen respondiendo, qué tecnología corre por debajo. De aquí sale con regularidad un entorno de preproducción que el equipo interno creía apagado desde hace dos años.
• Autenticación y autorización. ¿Puede un usuario hacerse pasar por otro? ¿Ve una cuenta corriente datos que no le corresponden? Ahí están los hallazgos más graves, y ninguna herramienta automática los saca sola.
• Lógica de negocio. Un cupón que se aplica dos veces, un paso que se puede saltar en el proceso de compra, una transferencia con importe negativo. Técnicamente no se rompe nada; solo se va el dinero.
• Cadenas de ataque. Dos detalles inocuos por separado que, encadenados, dan acceso de administración. Esa cadena es lo que el informe tiene que enseñar.
• Prueba de explotación. Un hallazgo sin prueba reproducible es una opinión. La prueba es exactamente lo que separa un test del listado que escupe una herramienta.

De ahí sale una consecuencia práctica para la compra. Pide un test de intrusión, no «los servicios de un hacking ético»: solo el primer término lleva asociados un alcance, un calendario y un entregable, y por tanto solo con el primero se pueden comparar dos presupuestos. Si nunca has comprado uno, en qué es el pentesting está el recorrido completo del trabajo.

Y una distinción que ahorra varios miles de euros de malentendido: un análisis de vulnerabilidades y un test de intrusión no son lo mismo ni valen lo mismo. El primero es una revisión, en buena parte automatizada, de una superficie amplia; el segundo es explotación manual sobre una superficie acotada. Los dos son legítimos y los dos se venden; el problema aparece cuando se factura el primero al precio del segundo. Los comparamos en análisis de vulnerabilidades o pentest.

Las nueve preguntas que ordenan la decisión

Todas se responden antes de firmar y todas dejan rastro escrito. Si alguna solo obtiene respuesta de palabra, esa es justamente en la que conviene insistir.

1. ¿Qué metodología, y aplicada a qué parte del alcance?

Un proveedor serio nombra los estándares que aplica y te dice cuál corresponde a cada parte del alcance: OWASP WSTG para aplicaciones web, OWASP MASTG para móvil, OWASP ASVS como estándar de verificación con tres niveles de profundidad, PTES y NIST SP 800-115 para la conducción del proyecto, MITRE ATT&CK para atar las acciones de un ejercicio adversario a técnicas conocidas. «Seguimos las mejores prácticas del sector» no es una respuesta: es la ausencia de una.

La razón por la que esto importa no es estética. Una metodología con nombre es lo único que hace comparables dos ofertas, porque convierte «hemos probado la aplicación» en «hemos verificado estos capítulos de la WSTG y estos requisitos del ASVS en nivel 2». Sin eso no estás comparando profundidad, estás comparando precios de cosas distintas. Las nuestras están publicadas una a una en metodologías de testing, precisamente para que puedas ponerlas al lado de las de otro.

Hay además dos textos que convierten la metodología documentada en una exigencia, y no en una preferencia:

• El Reglamento de Ejecución (UE) 2024/2690, directamente aplicable desde el 18 de octubre de 2024, fija requisitos técnicos y metodológicos para determinadas entidades —proveedores de servicios en la nube, de centros de datos, de redes de distribución de contenidos, proveedores de servicios gestionados y de servicios gestionados de seguridad, mercados en línea, motores de búsqueda, plataformas de redes sociales, prestadores de servicios de confianza, registros de nombres de dominio de primer nivel y proveedores de servicios de DNS—. Su Anexo, en el punto 6.5, exige determinar la necesidad, el alcance, la frecuencia y el tipo de prueba a partir del análisis de riesgos, ejecutarla «de acuerdo con una metodología de prueba documentada» y dejar registrados el tipo, el alcance, la fecha y los resultados, incluidos los hallazgos críticos, que además hay que corregir.
• El PCI DSS v4.0.1, que no es una norma legal sino un estándar contractual del sector de tarjetas, pide en su requisito 11.4.1 una metodología de test de intrusión documentada y basada en enfoques aceptados por la industria, citando expresamente la NIST SP 800-115 como ejemplo.

Si tu organización cae en alguno de esos dos supuestos, la pregunta por la metodología deja de ser una preferencia de comprador y pasa a ser parte de tu expediente.

Termina la pregunta con un número. ¿Cuántas de las jornadas presupuestadas son de trabajo manual? Todo el mundo promete enfoque manual; muy pocos presupuestos lo cuantifican.

2. ¿Quién prueba, y con qué credenciales a título individual?

Dos comprobaciones que ocupan quince minutos.

Primera: una certificación pertenece a una persona, no a una sociedad. Pide los nombres de quienes van a trabajar en tu proyecto, no una fila de logotipos en el pie de página. En España lo honesto se escribe así: «certificaciones de nuestro equipo», nunca «nuestras certificaciones» como si la empresa hubiera aprobado un examen.

Segunda: pide el identificador de la credencial o el enlace de verificación que emite el organismo, no una captura de pantalla. OffSec, ISC2 e ISACA permiten comprobar una credencial a partir de su identificador, y el proveedor que la tiene no tarda nada en dártelo.

Hay una tercera comprobación que casi nadie hace y que separa ofertas muy deprisa: ¿las personas que aparecen en el presupuesto son las que van a ejecutar el trabajo? Ocurre con frecuencia que el equipo del presupuesto y el equipo asignado forman dos conjuntos distintos. Pregúntalo por escrito y pide poder rechazar a un sustituto.

Haznos la misma pregunta. Nuestro equipo está nombrado en el sitio, con los roles, y te enviamos un informe de ejemplo anonimizado antes de la firma.

3. ¿Enseñan un informe de ejemplo antes de firmar?

El informe es el producto. Un proveedor que no lo enseña tiene un motivo para no enseñarlo. Un ejemplar anonimizado se pide antes de firmar, nunca después, y se lee mirando dos cosas por delante de todo lo demás.

La primera es si debajo de cada hallazgo hay una prueba reproducible: la petición, el parámetro, la secuencia exacta. Un hallazgo que solo dice «se ha detectado una configuración insegura» no permite a nadie corregirlo ni verificarlo.

La segunda es la naturaleza de las recomendaciones. «Aplicar el estado del arte» no ayuda a nadie. «Fijar la cabecera X con el valor Y en el balanceador» es media jornada de un ingeniero de tu equipo. La diferencia entre esas dos frases es la diferencia entre un informe que se implanta y uno que se archiva.

4. ¿Qué contiene exactamente el informe?

Esto se pacta antes, no se descubre al recibirlo. Un informe utilizable contiene:

• un resumen ejecutivo en lenguaje de negocio, legible por una dirección que no es técnica;
• el recuento de hallazgos y su reparto por nivel de riesgo;
• por cada hallazgo: identificador y título, valoración argumentada con CVSS, descripción técnica, prueba que permite reproducirlo y recomendación concreta de corrección;
• una matriz de cobertura que diga qué se ha probado y, sobre todo, qué no —lo segundo es lo que una entidad auditora mira primero;
• un plan de corrección priorizado, que separe lo que se arregla esta semana de lo que es un proyecto.

Si el informe va a servir de evidencia ante alguien, pide además que cada hallazgo quede enganchado al control o a la medida que le corresponde. En un programa ISO 27001, los controles 8.8 (gestión de vulnerabilidades técnicas) y 8.29 (pruebas de seguridad en desarrollo y aceptación) del Anexo A de la ISO/IEC 27001:2022 son el lugar natural del expediente donde se deposita el informe y su retest. Bajo el RGPD, el trabajo alimenta el art. 32.1.d), que exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas». Y en un sistema sujeto al Esquema Nacional de Seguridad, el Anexo II del RD 311/2022 recoge en op.mon.3.r6.3 una previsión titulada literalmente «Pruebas de penetración»: esa es la casilla a la que el informe responde. Qué exige de verdad, y a quién, lo desarrollamos en qué exige realmente el ENS sobre pentesting.

Una pregunta más, de las que no se le ocurren a nadie hasta que llega el momento: ¿en qué idioma se entrega el informe, y quién lo escribe? Un informe traducido a última hora desde una plantilla en inglés se nota, y se nota justo en la parte que tiene que leer tu equipo de desarrollo.

5. ¿El retest va incluido, y con qué plazo?

El retest es la comprobación de que las correcciones aplicadas aguantan. No es una segunda prueba completa y por tanto no debería costar lo mismo, pero es una línea que se factura aparte con mucha frecuencia. Tres precisiones que conviene obtener por escrito: si va incluido o se factura, con qué plazo desde la entrega del informe, y quién lo ejecuta.

Que esto importe no es una opinión nuestra. El PCI DSS v4.0.1 lo exige de forma explícita en su requisito 11.4.4: las vulnerabilidades explotables halladas durante el test de intrusión se corrigen y la prueba se repite para verificar las correcciones. El Anexo del Reglamento de Ejecución (UE) 2024/2690, en el punto 6.5, cierra el ciclo del mismo modo, obligando a corregir los hallazgos críticos y a revisar el proceso a intervalos planificados.

Nuestra práctica, para que la puedas comparar: retest incluido en el precio, dentro de los 90 días siguientes a la entrega del informe. Las horquillas de precio correspondientes están publicadas en cuánto cuesta un pentest en España, en jornadas y en euros, no «bajo petición».

6. ¿Quién firma la autorización y sobre qué alcance?

Lo que separa una prueba de seguridad de un delito no es la técnica —es idéntica— sino tres documentos.

• La autorización escrita. Dada por alguien con poder para obligar a la organización, antes de que empiece el trabajo, y procedente de la entidad que realmente explota el sistema. Para una aplicación alojada en un proveedor cloud o para un servicio SaaS, esa entidad no es automáticamente tu empresa: las condiciones del proveedor de alojamiento limitan a veces las pruebas o exigen un aviso previo.
• El alcance. La lista exacta de lo que entra en la prueba y de lo que queda fuera. Lo que queda fuera se queda intacto, aunque el consultor vea un fallo desde la ventana.
• Las reglas de enfrentamiento (rules of engagement). Ventana horaria, técnicas permitidas, contactos de escalado y las acciones que requieren un acuerdo aparte: típicamente los ataques contra la disponibilidad, los envíos masivos de mensajes y cualquier manipulación de datos de producción.

Sin esas tres piezas, los mismos actos encajan en los arts. 197 bis y 197 ter (acceso y facilitación de acceso a sistemas de información) y en los arts. 264, 264 bis y 264 ter (daños informáticos) del Código Penal, cuyos tipos giran sobre las expresiones «sin estar debidamente autorizado» y «sin autorización». Lo que hace lícito el trabajo es el encargo del titular y el alcance pactado: no una etiqueta, no una inscripción en una lista.

Dos comprobaciones la resuelven deprisa: ¿te facilita el proveedor un modelo de autorización de pruebas? y ¿te pregunta él, por iniciativa propia, si en el alcance hay sistemas de terceros? Quien no pregunta por el proveedor de alojamiento es porque no se lo ha encontrado nunca.

Si lo que vas a contratar es una simulación de ingeniería social sobre tu plantilla, hay un trámite previo adicional que no es opcional en España y que casi ningún proveedor menciona: lo tratamos en simulación de phishing y derechos de los trabajadores.

7. ¿Dónde acaban las evidencias?

Una prueba genera material sensible: capturas, volcados parciales de base de datos, tokens, a veces datos personales reales. Pregunta dónde se guardan, quién accede, cuánto tiempo se conservan y en qué fecha se destruyen.

Si entran datos personales en el alcance, los papeles de responsable y encargado del tratamiento se fijan por escrito: es el contrato del art. 28 del RGPD, y no vale darlo por hecho. El art. 5.1.c) añade la parte que más se olvida, la minimización: si para demostrar un hallazgo basta con extraer tres registros, el informe lleva tres registros, no la tabla entera. Un proveedor que te entrega un volcado completo «como prueba» no te está dando más rigor, te está creando un problema nuevo.

Pide también la lista nominativa de subencargados y el lugar donde se alojan las evidencias. Con un proveedor establecido en la Unión Europea no hay transferencia internacional del capítulo V del RGPD que documentar; el detalle de ese punto está en contratar una empresa de pentesting no española.

8. ¿Qué seguro de responsabilidad civil profesional tiene?

Pide el certificado en vigor, el importe de la cobertura y, explícitamente, si cubre un daño ocurrido en un entorno de producción. Una prueba toca sistemas vivos, y esta es una pieza estándar de un expediente de compras que nadie discute cuando se pide.

No es una manía de comprador desconfiado. El texto europeo que más lejos llega fijando requisitos a quien ejecuta una prueba ofensiva lo incluye en su lista: el art. 27 del Reglamento (UE) 2022/2554 (DORA) exige, para los verificadores externos de una prueba TLPT, idoneidad y reputación, capacidades técnicas y organizativas con experiencia específica, certificación por un organismo de acreditación de un Estado miembro o adhesión a códigos de conducta o marcos éticos formales, una garantía independiente o informe de auditoría sobre la gestión de los riesgos del ejercicio, y cobertura de seguros de responsabilidad civil profesional, incluidos los riesgos de conducta indebida y negligencia. Esa lista se aplica a un supuesto muy concreto —y Haxoris no realiza pruebas TLPT— pero sirve como referencia de qué es razonable exigir a cualquier proveedor.

9. ¿Qué referencias puedes comprobar de verdad?

Una referencia útil no es un logotipo en una cuadrícula. Tiene tres propiedades: es de un alcance comparable al tuyo, es reciente y admite una llamada.

Cuatro cosas que la hacen comprobable, y las cuatro se piden:

• Un proyecto de tamaño y tipo comparables al tuyo —número de aplicaciones, roles, integraciones, entorno cloud u OT— con su fecha.
• El contacto de un cliente de ese perfil, y quince minutos de llamada entre ese cliente y tu equipo.
• Si un acuerdo de confidencialidad impide nombrarlo: la descripción del proyecto sin identificarlo, con las cifras de alcance y de duración.
• Lo que ese equipo aporta al oficio fuera de los proyectos de cliente: publicaciones, ponencias, vulnerabilidades reportadas a fabricantes.

El tercer punto tiene trampa buena: un proveedor que respeta el acuerdo de confidencialidad de otro cliente respetará el tuyo. Nuestros proyectos documentados están en casos de éxito, y las opiniones de clientes, con nombre, en testimonios.

Las certificaciones: qué demuestra realmente cada una

La línea divisoria no pasa entre certificaciones «buenas» y «malas». Pasa entre un examen práctico ejecutado sobre sistemas reales y un test de opción múltiple sobre gobierno de la seguridad. Las dos familias son útiles; simplemente no demuestran lo mismo, y en un equipo de pentesting conviene que la primera esté presente.

Tres cautelas antes de usar esta tabla como criterio único.

El móvil es una especialidad aparte. Probar una aplicación Android o iOS no es una extensión de probar una web: tiene su propia metodología (OWASP MASTG) y su propio instrumental. Si tu alcance incluye aplicaciones móviles, pregunta quién de ese equipo las ha probado y cuántas, no qué certificación genérica tiene.

Un certificado ISO 27001 de la empresa proveedora no es una credencial de pentesting. Dice cómo gestiona esa empresa su propia seguridad de la información, que es una pregunta legítima y distinta. Nosotros lo tenemos y lo decimos con precisión: Haxoris está certificada en ISO/IEC 27001 por TÜV SÜD y te facilitamos los datos del certificado si los pides. Es una certificación que tenemos como empresa, no una acreditación para certificar a terceros: no somos organismo de certificación y no está en nuestra mano emitirte un certificado a ti.

Ninguna certificación sustituye al informe de ejemplo. Si tuvieras que quedarte con una sola prueba de competencia, quédate con el informe: es el único documento que enseña a la vez qué buscaron, qué encontraron, cómo lo demostraron y cómo lo explican.

Cuando el criterio no lo pones tú

Hay cuatro situaciones en las que la elección deja de ser libre, y reconocerlas a tiempo te ahorra un ciclo de compra entero.

El pliego lo dice. Si estás licitando o eres proveedor de alguien que licita, el criterio de solvencia técnica del pliego manda. Puede nombrar una certificación concreta, una experiencia mínima o una titulación. No es una regla general del mercado: es una exigencia contractual de ese comprador, y fuera de ese contrato no viaja. Léela literalmente antes de presupuestar.

El sistema está sujeto al ENS. La certificación de la conformidad con el Esquema Nacional de Seguridad está reservada a entidades certificadoras acreditadas por ENAC; la auditoría de la seguridad del art. 31 del RD 311/2022 —la que se hace al menos cada dos años— no exige acreditación, y las pruebas técnicas que la alimentan tampoco. Son tres cosas distintas con tres reglas distintas, y confundirlas es el error de compra más caro del sector público español. Hay un detalle que además puede descartar a un candidato que te gustaba: la Instrucción Técnica de Seguridad de Auditoría (Resolución de 27 de marzo de 2018, BOE-A-2018-4573) establece en su punto IV.2 que el trabajo de auditoría no incluirá en ningún caso actividades que puedan considerarse de consultoría o similares. Dicho en términos de compra: quien te ha implantado el sistema no puede auditarlo. El mapa completo está en quién puede auditar el ENS.

Eres una entidad financiera sujeta a DORA. El Reglamento (UE) 2022/2554 obliga a mantener un programa de pruebas de resiliencia operativa digital y, para las entidades designadas, añade las pruebas de penetración guiadas por amenazas (TLPT), que en España se articulan a través del marco TIBER-ES. Ese ejercicio exige verificadores que cumplan el art. 27, y no es un servicio que prestemos. Un ejercicio de Red Team puede ser preparación previa, pero no lo sustituye.

El alcance toca información clasificada. Ahí hay habilitación de seguridad de por medio y la conversación es otra desde el primer minuto.

Fuera de estos cuatro supuestos —una empresa de producto que prueba su SaaS antes de que se lo pida un cliente, una pyme que revisa su Active Directory y su tenant de Microsoft 365, un programa ISO 27001, una organización que se prepara para la NIS2— el criterio vuelve a ser tuyo por completo. Sobre la NIS2 conviene además evitar el susto que circula: qué obliga hoy en España y qué no, lo repasamos en NIS2 en España.

Lo que debe decir el contrato

Un contrato de pentesting no se resuelve con una línea sobre «la realización de controles de seguridad». La ausencia de estas cláusulas pasa desapercibida en la firma y se nota el día que algo sale mal.

• Alcance. Direcciones, dominios, aplicaciones, roles y cuentas de prueba. Las exclusiones en una lista aparte, con los sistemas de terceros para los que no hay autorización.
• Ventana de pruebas. Días y horas, y si las acciones más intrusivas se ejecutan fuera del horario de oficina. Sin esta cláusula, la primera alerta convoca un comité de crisis innecesario.
• Contactos y escalado. Quién descuelga a cada lado, también de madrugada, si una prueba deja un servicio parado o si el consultor encuentra rastros de una intrusión real. El segundo caso ocurre más de lo que los presupuestos dan a entender.
• Cuentas y accesos de prueba. Quién los crea, cuándo, y qué pasa si llegan tarde: es la causa número uno de que un proyecto se coma su ventana sin haber probado lo importante.
• Tratamiento de las evidencias. Lugar de custodia, accesos, plazo de conservación, fecha de destrucción y el contrato del art. 28 del RGPD si hay datos personales implicados.
• Acuerdo de confidencialidad. Firmado antes de la reunión de alcance, no después: solo con definir el alcance ya has enseñado tu arquitectura.
• Seguro de responsabilidad civil profesional. Existencia, importe y cobertura de un daño en producción.
• Publicidad y referencias. ¿Puede el proveedor citarte como cliente, publicar un caso o reportar al fabricante una vulnerabilidad descubierta en un producto de terceros? Si es que sí: con qué plazo y con qué aprobación.
• Retest. En el contrato, con plazo y precio, o incluido.
• Subcontratación. Quién ejecuta de verdad, y la posibilidad de rechazar a una persona concreta.

Cómo se lee un presupuesto de pentesting

Un presupuesto de pentesting es una cuenta de jornadas. Todo lo demás son etiquetas. Si sabes leer estas ocho líneas, puedes comparar dos ofertas que a primera vista parecen inconmensurables.

Dos referencias de mercado para situar las cifras, con la advertencia de que el precio no es el criterio de decisión sino el resultado del alcance: los proveedores que venden en España publican tarifas de 700 a 1.500 € por jornada, IVA no incluido, y la mayoría de los proyectos de aplicación ocupan entre 5 y 15 jornadas. El desglose completo, con lo que mueve el número arriba y abajo, está en cuánto cuesta un pentest en España.

Y una regla que no falla: un precio dado antes de escribir el alcance no es un precio. Quien te da una cifra sin saber cuántas aplicaciones, cuántos roles y cuántas integraciones hay, o adivina, o te está presupuestando un análisis automático.

Señales de alarma

• Un análisis automático vendido como test de intrusión. Se reconoce en que cada hallazgo lleva una descripción sacada de una base de vulnerabilidades y ninguno lleva prueba de explotación. Un análisis de vulnerabilidades es un servicio legítimo, útil y más barato; simplemente no es un test y no se factura como tal.
• Un precio antes del alcance. Ver arriba.
• Un presupuesto sin retest. Te quedas con una lista de tareas que nadie viene a cerrar.
• «Un equipo de expertos certificados» sin un solo nombre. Quien no nombra a sus consultores ni facilita un identificador verificable te está enseñando publicidad, no una referencia.
• Un informe entregado sin sesión de resultados. El documento a solas permite que tu dirección y tu equipo técnico saquen dos conclusiones distintas del mismo texto.
• Una promesa de cumplimiento. Un proveedor técnico constata y demuestra; no certifica, y no declara a nadie conforme con una norma. Si alguien te ofrece «certificarte el ENS» o «certificarte la ISO 27001» como parte del pentest, esa oferta no la puede cumplir: esos certificados los expiden entidades acreditadas, y un proveedor de servicios técnicos no lo es.
• Resistencia a poner el alcance por escrito. Si cuesta que el alcance entre en el contrato, costará más que entre en el informe.
• Un descuento por firmar hoy. La urgencia comercial en una compra que abre accesos a tus sistemas es, en sí misma, un dato sobre el proveedor.

Cómo nos aplicamos esta lista

La escribimos sabiendo que nos la vas a aplicar. Esa es la idea.

• Sabes quién prueba. Nuestros pentesters tienen OSCP, OSWE y CISSP a título individual. Conoces sus nombres antes de empezar y hablas directamente con quien ha escrito las conclusiones del informe.
• La metodología está publicada. No «mejores prácticas»: OWASP WSTG y ASVS para aplicación, MASTG para móvil, PTES y NIST SP 800-115 para la conducción del proyecto, MITRE ATT&CK para el ejercicio adversario. Página por página, en metodologías de testing.
• El informe de ejemplo se envía antes de firmar, anonimizado, para que lo juzgues con los criterios de esta página y no con los nuestros.
• El retest va incluido en el precio, dentro de los 90 días siguientes a la entrega del informe.
• Los precios son públicos, en jornadas y en euros, no «bajo petición».
• Somos un proveedor europeo. Tus evidencias y tu informe se quedan en la Unión Europea, el RGPD se aplica directamente y los subencargados van nombrados en el contrato.
• Y decimos lo que no hacemos. Haxoris no es entidad de certificación, no está acreditada por ENAC y no expide certificaciones de conformidad con el ENS; no está acreditada por CREST; y no realiza pruebas TLPT. Haxoris presta servicios de seguridad informática: esta actividad no figura entre las reservadas del art. 5.1 de la Ley 5/2014 y no requiere autorización del Ministerio del Interior.

Preguntas frecuentes

¿Quieres aplicarnos esta lista? Es exactamente para lo que está escrita: pídenos los nombres, los identificadores de las credenciales, el informe de ejemplo y la línea de retest del presupuesto. Solicita tu presupuesto y te respondemos por escrito en 24 horas laborables, también cuando la respuesta sea que tienes que dirigirte a otro. Si prefieres empezar por el servicio, la página es test de intrusión.

Nuestros servicios relacionados: pentesting y tests de intrusión de tus aplicaciones e infraestructuras · auditoría de ciberseguridad de tu entorno tecnológico · análisis de vulnerabilidades de tus sistemas y aplicaciones · Red Team: una simulación de ataque realista