Análisis de vulnerabilidades
Un análisis de vulnerabilidades recorre toda tu superficie de exposición —servidores, puestos de trabajo, aplicaciones web, API y cuentas cloud— y saca a la luz las vulnerabilidades ya publicadas y los fallos de configuración. Combinamos un barrido automatizado, que cubre el alcance completo, con la validación manual de cada resultado: en el informe solo queda lo que de verdad es alcanzable en tu entorno, y no el volcado en bruto de una herramienta.
Te llevas una fotografía fechada de tu exposición y un plan de remediación ordenado: qué hay que corregir esta semana y qué puede esperar al trimestre. El retest, cuando hayas corregido, va incluido.
Confían en nosotros
¿Qué es un análisis de vulnerabilidades?
Un análisis de vulnerabilidades es un examen sistemático de tus sistemas, tus aplicaciones y tu infraestructura de red. Identifica las vulnerabilidades ya conocidas y los defectos de configuración, los clasifica por gravedad y deduce un orden de corrección. Su objetivo no es entrar: es levantar el mapa completo de tus debilidades en una fecha concreta y sobre la totalidad del alcance, en lugar de profundizar en un único objetivo.
No lo confundas con la gestión de vulnerabilidades, que en el mercado español nombra otra cosa: un proceso continuo que pilotas tú, con responsable y plazo por cada vulnerabilidad. Lo que hacemos aquí es un proyecto acotado, con principio, final e informe validado a una fecha. Muchas organizaciones lo usan justamente como medición de referencia para montar después ese proceso interno.
Tampoco es un pentest, y la confusión sale cara en las dos direcciones. La diferencia, con ejemplos, está desarrollada en análisis de vulnerabilidades o pentest.
Objetivos: qué te aporta el análisis
El análisis responde a una pregunta muy concreta: ¿qué tienes hoy expuesto y en qué orden conviene arreglarlo? La norma que lo pide de la forma más directa no es la que más se repite en los anuncios; es el art. 32.1.d) del RGPD, que exige «un proceso de verificación, evaluación y valoración regulares» de la eficacia de las medidas de seguridad. Un análisis periódico es exactamente un proceso de ese tipo. Más abajo detallamos qué obliga de verdad en España.
En la práctica, obtienes cuatro cosas.
Corregir antes de que se explote
Cierras el agujero antes que quien lo habría usado. Las vulnerabilidades conocidas se explotan sobre todo mucho después de que exista la actualización: lo que marca la diferencia es tu plazo de corrección, no la sofisticación del atacante.
Una evidencia que puedes enseñar
El informe acredita que tus medidas se han comprobado de verdad: ante la entidad que audita tu ISO 27001, al documentar el art. 32 del RGPD o frente al cuestionario de seguridad de un cliente grande.
Un orden de trabajo realista
Empiezas por lo que amenaza tu actividad y no por lo que salió primero en la herramienta. Cada vulnerabilidad lleva su puntuación CVSS y, después, una ponderación según su exposición real dentro de tu alcance.
Una visión de conjunto fechada
Sabes dónde estás a partir de una medición y no de suposiciones, incluidos los subdominios olvidados, los paneles de administración abiertos y los entornos de preproducción que nadie recordaba.
Comparativa
¿Análisis de vulnerabilidades o pentest?
Los dos servicios sirven, pero no responden a la misma pregunta. En una frase: el análisis de vulnerabilidades encuentra todas las puertas; el test de intrusión (pentesting) abre unas cuantas y mira hasta dónde puede llegar después.
El análisis es ancho, rápido y comparativamente barato. Detecta vulnerabilidades conocidas —CVE publicadas, versiones obsoletas, servicios expuestos, configuraciones por defecto— sobre la totalidad del alcance. El test de intrusión es profundo y mayoritariamente manual: explota, encadena y demuestra el impacto real de una ruta de ataque, incluidos los fallos de control de acceso y los errores de lógica de negocio que ninguna herramienta detecta.
¿Cuál elegir? Si todavía no has medido nada, empieza por el análisis: te da una base completa por poco dinero. Si tienes que demostrar que una aplicación crítica o un dominio de Active Directory aguantan, lo que necesitas es un test de intrusión. Y si un cliente pide expresamente un informe de test de intrusión en su cuestionario de proveedor, un análisis no basta.
| Criterio | Análisis de vulnerabilidades | Test de intrusión |
|---|---|---|
| Objetivo | Inventariar y clasificar el mayor número posible de vulnerabilidades conocidas (anchura). | Explotar y encadenar fallos para demostrar un impacto real de negocio (profundidad). |
| Método | Barrido automatizado de todo el alcance y validación manual de cada resultado. | Trabajo manual mayoritario: el consultor avanza como lo haría un atacante. |
| Qué saca a la luz | CVE publicadas, versiones obsoletas, configuraciones por defecto, servicios y paneles expuestos. | Todo lo anterior, más fallos de control de acceso, errores de lógica de negocio y cadenas de ataque. |
| Frecuencia | Recurrente: trimestral, y después de cada cambio relevante. | Anual, y antes de cada puesta en producción importante. |
| Entregable | Listado completo de vulnerabilidades, puntuación CVSS y orden de remediación. | Escenarios de ataque, evidencias de explotación y valoración del impacto. |
| Esfuerzo habitual | 2 a 5 jornadas según el alcance. | 5 a 15 jornadas según el objetivo. |
¿Tienes dudas? Descríbenos el alcance y te decimos con franqueza cuál responde a tu necesidad, también cuando es el más barato de los dos. La comparación completa está en análisis de vulnerabilidades o pentest.
Cobertura
¿Qué cubre el análisis?
Un atacante no elige: coge lo que encuentra. Por eso un análisis de vulnerabilidades de infraestructura abarca todo tu entorno digital y no solo los sistemas de los que se habla en comité. El alcance se cierra por escrito antes de empezar —rangos de direcciones IP, nombres de dominio, aplicaciones, cuentas cloud— y fuera de él no se toca nada.
Red externa e interna
Servidores, puestos de trabajo, equipamiento de red y todo lo que sigue siendo visible desde internet. Para bajar en profundidad sobre ese mismo perímetro, la continuación lógica es una auditoría de infraestructura.
Aplicaciones web y móviles
Inyecciones SQL, XSS, fallos de autenticación y de control de acceso, componentes de terceros sin actualizar. Si te preocupa una aplicación concreta, llegan más lejos el pentesting de aplicaciones web y el pentesting de aplicaciones móviles.
Entornos cloud
Revisamos la configuración de AWS, Azure y Google Cloud. En las empresas de España el cloud empieza casi siempre por Microsoft 365 y Entra ID: van en el alcance por defecto. Para un examen a fondo, la auditoría de entornos cloud.
Bases de datos
Permisos, cifrado de los datos en reposo y configuración de Microsoft SQL Server, PostgreSQL y MongoDB. Una fuga por aquí acaba casi siempre en una notificación a la AEPD dentro de las 72 horas del art. 33 del RGPD.
API e integraciones
Por las API circulan tus datos más estructurados. Comprobamos quién accede, si un permiso se puede saltar y si han quedado accesibles interfaces de preproducción o versiones antiguas que nadie retiró.
Dispositivos IoT y entornos OT
Equipos de producción, autómatas y dispositivos conectados. Sobre un entorno OT en marcha nos quedamos en escucha pasiva y validamos contigo cada acción activa antes de lanzarla. Para ir más allá: auditoría de OT, ICS e IoT.
Enfoques: caja negra, caja gris y caja blanca
El enfoque decide cuánta información recibimos antes de empezar y, por tanto, cuánta cobertura compras con el mismo presupuesto. Partir con datos no hace el análisis menos realista: evita gastar jornadas en redescubrir lo que ya sabes. En un análisis de vulnerabilidades pesa además un factor que en un pentest es secundario, el acceso autenticado: un sistema examinado con credenciales revela versiones exactas, actualizaciones ausentes y parámetros de configuración que desde fuera son sencillamente invisibles.
Caja negra
Empezamos sin información, solo con lo observable públicamente: nombres de dominio, rangos de direcciones IP, servicios expuestos y datos de fuentes abiertas. Es la vista de un atacante externo el primer día y sirve para medir tu superficie de exposición real. Su límite es mecánico: lo que no se descubre, no se analiza.
Caja gris
Recibimos el inventario de activos, una cuenta por perfil de usuario y documentación general. Es el enfoque de la gran mayoría de los análisis: rinde más cobertura por jornada invertida y reproduce el escenario más frecuente en la realidad, el de una cuenta legítima comprometida.
Caja blanca
Contamos con credenciales de solo lectura, esquemas de arquitectura, configuraciones y, cuando procede, el inventario de dependencias. La cobertura es completa: versión exacta de cada componente, bibliotecas vulnerables, parámetros de bastionado. Es el enfoque indicado en los sistemas más críticos y antes de una puesta en producción.
Nuestra recomendación por defecto es la caja gris con credenciales de solo lectura. Un análisis sin autenticar sobre un parque Windows deja fuera casi todo lo que importa —actualizaciones pendientes, software de terceros desfasado, configuraciones locales— y produce un informe corto que parece una buena noticia y no lo es. El enfoque elegido y las jornadas que lleva quedan escritos en el presupuesto.
Alcance y planificación
La planificación determina el valor del análisis mucho más que el número de jornadas contratadas. Ocupa una hora escasa y deja cerrado lo siguiente.
- Los objetivos: rangos de direcciones IP, nombres de dominio y subdominios, direcciones URL de las aplicaciones, suscripciones y cuentas cloud, y las credenciales de solo lectura cuando el análisis es autenticado.
- Las exclusiones: sistemas de terceros, entornos fuera de alcance, denegación de servicio y cualquier acción destructiva. Si una aplicación está alojada en un proveedor, pedimos también su conformidad durante la planificación.
- La ventana de ejecución: fechas, franja horaria y una persona localizable por cada parte mientras dure el proyecto. Si tienes un SOC o un servicio gestionado, decidimos si se le avisa; en este servicio lo normal es avisar, porque el objetivo no es medir tu capacidad de detección.
- Las reglas del ejercicio: intensidad de las comprobaciones, tratamiento de los datos reales que aparezcan y qué hacemos ante un hallazgo crítico. Te avisamos en el momento, sin esperar al informe.
- El entorno: preproducción equivalente cuando existe y, si no existe, producción con las precauciones acordadas por escrito.
Nada empieza antes de tu autorización firmada. No es un trámite administrativo: el art. 197 bis del Código Penal castiga a quien accede a un sistema de información «sin estar debidamente autorizado», y esa firma es lo único que separa un análisis de un acceso ilícito. Te comunicamos además las direcciones de origen desde las que trabajamos, para que las incorpores a tus listas de permitidos y no pierdas media jornada bloqueándonos.
Del alcance sale el presupuesto: jornadas, persona asignada, fecha de entrega y plazo de retest. Y si lo que nos describes no justifica un análisis de vulnerabilidades —porque lo que necesitas es un test de intrusión, o al revés—, te lo decimos antes de cifrarlo.
Nuestra metodología
Cómo se desarrolla el análisis
Nos apoyamos en marcos públicos que tu equipo y quien te audite pueden verificar: OWASP y su guía WSTG para la parte web, MASTG para móvil, PTES para la conducción del proyecto y la puntuación CVSS para la gravedad. Cada vulnerabilidad publicada se vincula a su identificador CVE y se comprueba si consta explotación conocida: el catálogo KEV de CISA y la probabilidad EPSS ayudan a separar lo urgente de lo meramente grave. El detalle está en OWASP y OWASP WSTG.
Una herramienta cubre rápido todo el alcance, pero no todo lo que devuelve es real. Por eso un consultor repasa cada resultado, y en un análisis normal esa fase elimina entre un tercio y la mitad de las líneas en bruto: en el informe solo queda lo que es alcanzable en tu entorno.
Planificación y autorización por escrito
Cerramos contigo objetivo, alcance e inventario: rangos de direcciones IP, dominios, aplicaciones y cuentas cloud. La nota de planificación fija las ventanas de ejecución y a quién avisar si algo se tuerce. No empezamos hasta recibir tu autorización firmada.
Reconocimiento e inventario real
Levantamos lo que de verdad está en línea: subdominios olvidados, servicios expuestos, paneles de administración accesibles, certificados caducados, entornos de preproducción abiertos. Esta fase saca con frecuencia activos que no figuraban en el inventario que nos pasaste, y estadísticamente son los más vulnerables, porque nadie los actualiza.
Barrido automatizado del alcance
Recorremos la infraestructura con Nessus, OpenVAS y Nuclei, más comprobaciones específicas de las tecnologías que aparecen. Aquí afloran las vulnerabilidades conocidas (CVE), los puertos abiertos, las versiones obsoletas y los errores de configuración, con pruebas calibradas para no degradar un servicio en producción.
Validación manual y análisis
Nuestros consultores revisan cada resultado, descartan los falsos positivos y buscan lo que ninguna herramienta ve: permisos demasiado amplios, secretos en claro en un fichero de configuración, dependencias vulnerables encadenadas. Cada vulnerabilidad que se queda se repondera por su exposición real: una crítica en un servidor aislado no manda sobre una media publicada en internet.
Informe, sesión de resultados y retest
Recibes el informe en español, con resumen ejecutivo y detalle técnico, y lo presentamos a tu equipo por videoconferencia. Cuando hayas desplegado las correcciones, el retest va incluido en el precio, dentro de los 90 días siguientes a la entrega.
Entregables: informe, plan de remediación, sesión de resultados y retest
Un análisis vale por lo que queda cuando el equipo se va. Cuatro entregables, ninguno opcional, ninguno facturado aparte y todos en español.
El informe
Un resumen ejecutivo de dos páginas para dirección —nivel de riesgo, hallazgos principales y decisiones que tomar, sin jerga— y después una ficha por vulnerabilidad: descripción, activo afectado, evidencia, puntuación CVSS, criticidad ajustada a tu contexto y corrección concreta. Los anexos recogen el alcance, la metodología y la lista de comprobaciones realizadas, incluidas las que no dieron resultado: delante de quien audita suele ser la parte más útil del documento. Se entrega en PDF y con una tabla de seguimiento importable a tu gestor de incidencias. Si lo necesitas también en inglés, para la matriz o para un cliente internacional, va sin coste.
El plan de remediación
Las vulnerabilidades se ordenan en un plan de trabajo realista: lo que hay que corregir esta semana, lo que aguanta el trimestre y lo que en realidad es una evolución de arquitectura. Tu equipo sabe por dónde empezar el lunes. Donde la corrección no consiste en aplicar una actualización, proponemos la mitigación provisional y decimos qué riesgo deja abierto.
La sesión de presentación de resultados
Una hora por videoconferencia con tu equipo técnico y, si quieres, con dirección. Repasamos los hallazgos, respondemos a las preguntas y priorizamos contigo. La dirige la persona que ha hecho el análisis, no un comercial.
El retest
Cuando hayas desplegado las correcciones volvemos a comprobar las vulnerabilidades identificadas y te entregamos un anexo al informe que dice, línea a línea, qué queda cerrado y qué sigue abierto. Va incluido en el precio, sin coste adicional, dentro de los 90 días siguientes a la entrega del informe. Es la partida que el mercado suele facturar como una jornada más.
Qué encontramos habitualmente
Después de unos cuantos análisis los hallazgos se repiten, y no son exóticos. Ese es justamente el problema: casi todo lo que entra en una organización tenía actualización publicada desde hacía meses.
- Software de borde sin actualizar: concentradores VPN, cortafuegos y pasarelas de acceso remoto con vulnerabilidades publicadas que se explotan de forma masiva mucho después de existir el parche. Es, con diferencia, la vía de entrada más frecuente.
- Escritorio remoto y paneles de administración publicados en internet: RDP, interfaces de gestión de hipervisores, NAS y consolas de copia de seguridad accesibles desde cualquier sitio, a veces con las credenciales por defecto que nunca se cambiaron.
- Microsoft 365 e híbrido con Entra ID mal atados: protocolos de autenticación heredados todavía activos, doble factor incompleto, permisos de aplicación concedidos una vez y nunca revisados, y cuentas de servicio con más privilegios de los que necesitan.
- Preproducción expuesta: copias de la aplicación con datos reales, entornos de pruebas indexados por buscadores, repositorios accesibles. Casi nunca figuran en el inventario que nos pasan.
- Componentes de terceros desfasados: extensiones del gestor de contenidos, bibliotecas de la aplicación, versiones de Java o PHP fuera de soporte. El código es tuyo, pero la vulnerabilidad la heredas.
- Certificados y configuración TLS: certificados caducados, protocolos antiguos habilitados, cabeceras de seguridad ausentes. Poco espectacular y muy visible en cuanto un cliente te pasa su cuestionario de seguridad.
- Secretos en claro: claves de API y contraseñas dentro de ficheros de configuración, de imágenes de contenedor o del historial del repositorio.
Nada de esto exige un atacante sofisticado. Exige que nadie haya mirado, y mirar es exactamente lo que compras aquí.
¿Por qué Haxoris?
Proveedores capaces de lanzar una herramienta hay muchos. La diferencia está en lo que te queda al final: un informe que tu equipo de desarrollo puede usar, un interlocutor único que ha hecho el trabajo de verdad y una verificación de las correcciones que no se te vuelve a facturar.
Certificaciones del equipo
Retest incluido, sin coste añadido:
Cuando despliegues las correcciones volvemos a comprobar las vulnerabilidades identificadas, dentro de los 90 días siguientes a la entrega del informe. Está en el precio inicial y no aparece como una jornada extra.
Sabes qué vas a pagar:
El precio se calcula en jornadas: lo habitual son 2 a 5 para el alcance de una pyme o una mediana empresa. Damos la horquilla y la tarifa de jornada en el primer contacto, y el presupuesto detalla las jornadas partida por partida.
Sabes quién analiza:
El nombre, la trayectoria y las certificaciones (OSCP, OSWE, CISSP) de la persona asignada se te comunican antes de firmar. Hablas con ella durante el análisis y en la sesión de resultados, sin intermediario comercial.
Proveedor europeo, datos en la UE:
Haxoris es una empresa establecida en la Unión Europea. Las evidencias y el informe se quedan en la UE: no hay transferencia internacional del capítulo V del RGPD que justificar ni cláusulas contractuales tipo que negociar, sino un contrato de encargo del tratamiento del art. 28.
Testimonios
Lo que dicen nuestros clientes
Qué obliga realmente en España
El mercado repite dos errores: dar por hecho que NIS2 ya es ley aquí y anunciar sanciones que hoy no existen. Esto es lo que está en vigor, lo que dice literalmente sobre pruebas y con qué frecuencia las pide.
RGPD: el texto más directo
El art. 32.1.d) del Reglamento (UE) 2016/679 incluye entre las medidas de seguridad apropiadas «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento». No fija intervalo, y por eso lo que se sostiene ante la AEPD no es un análisis suelto sino un calendario documentado que se cumple. Un análisis de vulnerabilidades trimestral resuelve esa exigencia por muy poco dinero. Y si algún día una brecha acaba en notificación, el art. 33 te da 72 horas: llegar con un inventario y una medición reciente cambia por completo la conversación.
El ENS: Real Decreto 311/2022
El Esquema Nacional de Seguridad es la norma que más pesa sobre el comprador español —el sector público y, por arrastre contractual, sus proveedores—. Su art. 31 somete los sistemas de categoría MEDIA y ALTA a una auditoría regular ordinaria al menos cada dos años, y el art. 38 separa los dos caminos de conformidad: autoevaluación en categoría BÁSICA, certificación en MEDIA y ALTA. Esa auditoría necesita evidencia técnica, y un análisis recurrente es la manera más barata de tenerla ya escrita cuando la entidad auditora se presenta.
Conviene ser preciso en un punto en el que el mercado es deliberadamente ambiguo: donde el ENS pide pruebas ofensivas, las nombra con otro nombre. En el Anexo II, el refuerzo R6 del control [op.mon.3] desarrolla la supervisión continua y su subrequisito [op.mon.3.r6.3] se titula literalmente «Pruebas de penetración», para categoría ALTA. Existe además una segunda puerta menos conocida: op.nub.1.2 a) exige, ya desde categoría BÁSICA, una «Auditoría de pruebas de penetración (pentesting)» cuando el servicio en la nube lo presta un tercero que no acredita conformidad con el ENS. Un análisis de vulnerabilidades no cubre ninguno de los dos supuestos: ahí hace falta un test de intrusión, y te lo diremos antes de venderte lo que no toca.
Lo que aportamos es la prueba técnica que alimenta esa auditoría. La conformidad la declara o la certifica quien corresponde: Haxoris no está acreditada por ENAC, no es entidad de certificación y no expide el certificado de conformidad con el ENS ni el Distintivo de Conformidad. Lo desarrollamos en qué exige realmente el ENS sobre pentesting y en quién puede auditar el ENS.
NIS2 todavía no es derecho español
La Directiva (UE) 2022/2555 debía estar transpuesta el 17 de octubre de 2024. En España, el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad tuvo una primera lectura en el Consejo de Ministros el 14 de enero de 2025 y no ha llegado a las Cortes; el 9 de julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE por esa falta de transposición (procedimiento INFR(2024)0270). Quien hoy te venda «obligaciones NIS2 en España» te está vendiendo un texto que aún no existe.
Lo que sí obliga ahora mismo es lo anterior: el Real Decreto-ley 12/2018 y su reglamento de desarrollo, el Real Decreto 43/2021, para operadores de servicios esenciales y proveedores de servicios digitales.
Y hay una pieza que no depende de ninguna ley española, porque es un reglamento y se aplica de forma directa: el Reglamento de Ejecución (UE) 2024/2690, que fija las medidas técnicas para proveedores de servicios en la nube, centros de datos, redes de distribución de contenidos, proveedores de servicios gestionados y de servicios de seguridad gestionados, mercados en línea, motores de búsqueda, plataformas de redes sociales y prestadores de servicios de confianza. Su Anexo, punto 6.5 «Pruebas de seguridad», exige una política de pruebas documentada, un alcance y una frecuencia fijados en función del riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. Si tu entidad aparece en esa lista, ya tienes obligación de probar aunque la ley de transposición siga sin publicarse, y un análisis de vulnerabilidades con calendario fijo es la forma más económica de cubrir las cuatro piezas a la vez. Más detalle en pentesting para NIS2 y en NIS2 en España: qué obliga hoy y qué no.
ISO/IEC 27001
El control A.8.8 del Anexo A, «Gestión de las vulnerabilidades técnicas», es de los primeros que mira la entidad auditora cuando abre tu sistema de gestión: quiere ver que obtienes información sobre las vulnerabilidades de tus sistemas, que evalúas la exposición y que actúas en consecuencia. Nuestro informe y el anexo de retest son exactamente esa evidencia. El certificado lo expide siempre un organismo de certificación acreditado —AENOR, Bureau Veritas, EQA— y nunca quien realiza las pruebas. Ver pentesting para ISO 27001.
DORA y el sector financiero
El Reglamento (UE) 2022/2554 se aplica desde el 17 de enero de 2025. Sus arts. 24 y 25 obligan a mantener un programa de pruebas de resiliencia digital en el que el análisis de vulnerabilidades figura entre las pruebas previstas, también antes de desplegar aplicaciones o componentes de infraestructura que den soporte a funciones críticas o importantes. El art. 26 añade, para las entidades que designe la autoridad competente, ejercicios TLPT al menos cada tres años: los ejecutan proveedores que cumplen el art. 27 y no son un servicio que prestemos.
PCI DSS
Si tratas datos de tarjeta, PCI DSS 4.0.1 es el estándar más exigente en frecuencia. El requisito 11.3.1 pide análisis internos de vulnerabilidades al menos cada tres meses y tras cualquier cambio significativo; el 11.3.2 pide análisis externos con la misma cadencia, pero firmados por un Approved Scanning Vendor aprobado por el PCI Security Standards Council. Haxoris no es ASV, así que los externos del 11.3.2 tienes que encargarlos a un proveedor aprobado. Los internos del 11.3.1 y la validación manual sí los hacemos, con el nivel de detalle que espera tu QSA.
Marco normativo
Normas que piden pruebas, y qué papel juega el informe
Ninguna norma española certifica un análisis de vulnerabilidades ni acredita a quien lo hace. Lo que hacen es exigir pruebas documentadas y periódicas: nuestro informe es la evidencia técnica que pones encima de la mesa.
RGPD
El art. 32.1.d) exige un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas. Un calendario fijo de análisis, documentado y cumplido, es la forma más simple de demostrarlo.
NIS2 y el Reglamento (UE) 2024/2690
NIS2 sigue sin transponerse en España, pero el reglamento de ejecución ya exige pruebas de seguridad documentadas a las entidades digitales que enumera. Nuestra página NIS2.
ENS e ISO/IEC 27001
Auditoría al menos cada dos años (art. 31 del RD 311/2022) y control A.8.8 del Anexo A de la ISO. Aportamos la evidencia técnica; la certificación la expide siempre una entidad acreditada, nunca quien realiza las pruebas. Pentesting para ISO 27001.
Última revisión: 12 de septiembre de 2026. Esta sección cita normas en evolución; si una cambia, la corregimos aquí.
Lo que no hacemos
Decirlo en voz alta es lo que hace creíble el resto de la página. Hay cinco cosas que no vas a encontrar aquí, y ninguna se arregla con una frase ambigua.
- No certificamos. No somos entidad de certificación acreditada por ENAC y no expedimos certificados de conformidad con el ENS, el Distintivo de Conformidad ni certificados ISO 27001. Emitimos un informe técnico de resultados que te sirve de evidencia ante el organismo que sí certifica, y trabajamos junto a la entidad auditora que elijas.
- No somos Approved Scanning Vendor de PCI DSS. Los análisis externos trimestrales del requisito 11.3.2 los tiene que firmar un ASV aprobado por el PCI Security Standards Council. Te decimos qué parte del requisito 11.3 cubrimos y cuál no antes de presupuestar, no después.
- No vendemos gestión de vulnerabilidades continua. No operamos tu plataforma, no revendemos licencias de herramienta y no montamos un servicio gestionado. Entregamos mediciones acotadas y fechadas; a partir de la primera, te ayudamos a montar tu propio proceso interno.
- No realizamos TLPT. Los ejercicios guiados por amenazas del marco TIBER-ES, coordinado por el Banco de España, exigen proveedores que cumplan el art. 27 de DORA. Un ejercicio de Red Team puede servirte de preparación previa, pero no lo sustituye.
- No trabajamos con información clasificada. El acceso a esa información requiere habilitación de seguridad de la Oficina Nacional de Seguridad; no la tenemos y no nos presentamos a esos pliegos.
Y una última, menos jurídica: un análisis de vulnerabilidades no deja tus sistemas sin vulnerabilidades. Deja una lista priorizada, unas evidencias y una fecha. Lo demás depende de que las correcciones se desplieguen, que es justo lo que el retest comprueba.
Tratamiento de datos y soberanía
Haxoris es una empresa establecida en la Unión Europea, con oficinas en Bratislava y Praga. El equipo interviene desde la Unión Europea y todo lo que genera un análisis —inventario de activos, salidas de herramienta, capturas, notas de trabajo e informe— se almacena y se respalda en la Unión Europea.
Aquí importa más que en otros servicios, y conviene decirlo sin rodeos: el entregable de un análisis de vulnerabilidades es, literalmente, el mapa de por dónde se entra en tu organización. Por eso viaja y se guarda cifrado, solo acceden a él las personas asignadas a tu proyecto y se borra en el plazo pactado en el contrato, por defecto al vencer el plazo de retest.
La consecuencia práctica se nota en cuanto tu departamento jurídico abre el contrato: el RGPD se nos aplica de forma directa, así que no hay transferencia internacional del capítulo V que justificar, ni cláusulas contractuales tipo que negociar, ni evaluación de impacto de transferencias que redactar. Actuamos como encargado del tratamiento en el sentido del art. 28 y el contrato lo recoge; la relación de subencargados y sus países se te comunica antes de firmar y cualquier cambio se te notifica. Al no estar sujetos a la jurisdicción de Estados Unidos, no nos alcanza la CLOUD Act.
El informe es tuyo: no lo reutilizamos y no mencionamos tu nombre sin tu autorización por escrito. Si la duda de fondo es si tiene sentido contratar este servicio fuera de España, la respondemos con números y con derecho aplicable en contratar una empresa de pentesting no española.
Preguntas frecuentes
01 ¿Cuánto cuesta un análisis de vulnerabilidades?
El precio se calcula en jornadas: lo habitual son 2 a 5 para el alcance de una pyme o una mediana empresa, bastante por debajo de lo que cuesta un test de intrusión. El número de direcciones IP, de aplicaciones y de cuentas cloud mueve la cifra, igual que la presencia de un entorno industrial.
Damos la horquilla y la tarifa de jornada desde el primer contacto, y el presupuesto detalla las jornadas partida por partida. El retest no aparece como línea adicional porque va incluido. Para el servicio más profundo, el cálculo está desglosado en cuánto cuesta un pentest en España.
02 ¿Cuánto tarda?
Dos o tres jornadas bastan para un perímetro externo clásico: unas decenas de direcciones IP, uno o dos sitios web y un inquilino de Microsoft 365. Cuenta cuatro o cinco en cuanto entran la red interna, varios dominios de Active Directory o un entorno industrial. Entre el arranque y la entrega del informe suelen pasar una o dos semanas.
Las fechas van en el presupuesto y las cumplimos: si el alcance resulta ser más ancho de lo descrito, te lo decimos antes de consumir jornadas, no después.
03 ¿Cada cuánto hay que repetirlo?
Un ritmo trimestral es practicable y es el que piden por escrito estándares como PCI DSS. Añade un análisis después de cada cambio relevante: sistema nuevo, actualización mayor, migración a cloud, apertura de una filial.
El art. 32.1.d) del RGPD habla de un proceso de verificación y evaluación «regulares» sin fijar intervalo, y un calendario fijo y documentado es la manera más simple de hacerlo demostrable. El punto 6.5 del Anexo del Reglamento de Ejecución (UE) 2024/2690 va en la misma dirección: alcance y frecuencia establecidos en función del riesgo. Última revisión: 12 de septiembre de 2026.
04 ¿Puede afectar a nuestros sistemas en producción?
El riesgo se controla. No empleamos técnicas capaces de interrumpir un servicio ni de alterar datos, las comprobaciones más intrusivas se validan de antemano y el análisis se detiene en cualquier momento con un mensaje. Sobre un entorno industrial en marcha nos quedamos en escucha pasiva mientras tu equipo no valide la acción propuesta.
Todo se hace en remoto: la parte externa arranca sin acceso a tu red y la interna pide una cuenta de solo lectura o un punto de conexión.
05 ¿Caja negra o caja gris?
Caja gris en la gran mayoría de los casos, y sobre todo con credenciales de solo lectura. Un análisis sin autenticar sobre un parque Windows deja fuera actualizaciones pendientes, software de terceros desfasado y configuraciones locales, y devuelve un informe corto que parece una buena noticia y no lo es.
La caja negra conserva todo su sentido cuando la pregunta es precisamente «¿qué ve quien no sabe nada de nosotros?»: entonces es una medida de superficie de exposición, no un inventario exhaustivo. La caja blanca se justifica en los sistemas más críticos. Te recomendamos el enfoque durante la planificación, con las jornadas que lleva.
06 ¿Es lo mismo que la gestión de vulnerabilidades?
No. La gestión de vulnerabilidades es un proceso continuo que pilotas tú: medir sin parar, corregir y vigilar los plazos, con un responsable y una fecha por vulnerabilidad. El análisis de vulnerabilidades es un proyecto acotado que muy a menudo sirve de medición de referencia para montar ese proceso.
Si lo que necesitas cubre un perímetro más amplio —arquitectura, configuración, procedimientos, organización—, mira la auditoría de ciberseguridad.
07 ¿Hace falta un proveedor acreditado para encargarlo en España?
No para un análisis que contrata una empresa privada. En España no existe una acreditación obligatoria para prestar estos servicios: las acreditaciones pesan en caminos concretos —la certificación del ENS, que expide una entidad acreditada por ENAC; los análisis externos de PCI DSS, que firma un Approved Scanning Vendor; o los ejercicios TLPT del sector financiero— y no en un contrato ordinario de seguridad ofensiva.
No estamos acreditados por ENAC y no lo insinuamos. Lo que sí puedes comprobar antes de firmar: el nombre y las certificaciones de quien va a analizar, un informe de ejemplo anonimizado y el retest incluido. Lo ampliamos en cómo elegir una empresa de pentesting.
08 ¿Sirve el informe para el ENS o para una auditoría de ciberseguridad?
Sirve como evidencia técnica. Documenta alcance, metodología, hallazgos, criticidad y verificación posterior, que es lo que se examina al auditar según el art. 31 del RD 311/2022 y lo que el control A.8.8 del Anexo A de la ISO/IEC 27001 espera encontrar.
Ahora bien, donde el ENS usa literalmente ese otro nombre —el subrequisito [op.mon.3.r6.3] del Anexo II, en categoría ALTA, y op.nub.1.2 a) para el cloud de terceros— hace falta un test de intrusión, no un análisis. Para preparar la revisión completa: cómo prepararse para una auditoría de ciberseguridad.
09 ¿Qué pasa con los datos que recogéis durante el análisis?
Intervenimos como encargado del tratamiento en el sentido del art. 28 del RGPD. Todo lo que se produce durante el proyecto viaja y se guarda cifrado, se almacena en la Unión Europea, solo es accesible para las personas asignadas y se borra en el plazo acordado, por defecto al vencer el plazo de retest. No estamos sujetos a la jurisdicción de Estados Unidos, así que la CLOUD Act no nos alcanza.
