Preguntas Frecuentes

¿Tenemos que firmar un contrato de larga duración?

No. La mayoría de nuestros servicios son proyectos cerrados con entregable concreto. Si hay una relación continua, se formaliza con un acuerdo de servicio gestionado, pero siempre con plazos definidos y salida flexible.

¿Trabajáis con empresas de todos los tamaños?

Sí. Tenemos clientes desde startups de 5 personas hasta empresas del Ibex35. Adaptamos el alcance y el precio a la realidad de cada organización.

¿Qué distingue a QuantumSec de otras empresas de ciberseguridad?

La especialización ofensiva y la cercanía. No somos un integrador generalista. Somos un equipo técnico que entiende el lenguaje de los atacantes, lo comunicamos en términos de negocio y acompañamos al cliente durante todo el proceso, no solo cuando entregamos el informe.

¿Cómo garantizáis la confidencialidad?

Firmamos un NDA antes de comenzar cualquier trabajo. Todos los accesos y pruebas quedan documentados y se realizan dentro del alcance estrictamente acordado.

¿Cuánto tardáis en empezar?

Entre una y tres semanas desde que se cierra el alcance, según la disponibilidad del equipo y la ventana que acordemos contigo. Trabajamos como equipo boutique con pocos proyectos simultáneos, así que damos fecha real de inicio y de entrega antes de firmar, no una estimación que luego se mueve.

¿Podemos contratar un solo servicio o hay que hacer un paquete?

Un solo servicio. La mayoría de proyectos son trabajos cerrados con alcance y precio definidos, sin mínimos obligatorios ni permanencia. Si más adelante tiene sentido ampliar —añadir un re-test, pasar de una auditoría puntual a un análisis continuo— se plantea con datos del trabajo ya hecho, no por adelantado.

¿Qué recibimos al terminar el proyecto?

Dos informes y una reunión. Un informe técnico con cada hallazgo, su evidencia, los pasos para reproducirlo y la corrección concreta; un informe ejecutivo con el riesgo traducido a impacto de negocio, apto para dirección o para un cliente que te lo exija. La reunión de cierre sirve para que tu equipo pregunte, no para leer el informe en voz alta.

¿Cuándo tiene sentido contratar un pentesting?

Cuando necesitas validar riesgo real con evidencias y no una aproximación teórica o puramente automática: antes de un lanzamiento, tras un cambio de arquitectura relevante, cuando lo exige un cliente o una normativa, o cuando un escáner ha señalado fallos que nadie ha confirmado explotándolos. Si el objetivo es solo marcar una casilla de cumplimiento y no averiguar qué podría hacer un atacante, el pentesting no es la compra adecuada.

¿Qué debo pedir a un proveedor antes de contratar un pentesting?

Cuatro cosas resuelven la mayoría de decisiones: el CV y las certificaciones de quien va a ejecutar la prueba, no solo la marca de la empresa; un informe de muestra real anonimizado, para ver si explican impacto de negocio o solo vuelcan hallazgos técnicos; la metodología que siguen (OWASP WSTG, PTES, OSSTMM); y si incluyen retest de las correcciones. Un proveedor que no puede enseñar un informe de muestra ni nombra metodología suele estar vendiendo un escaneo automático.

¿Cuánto cuesta un pentesting en España?

El precio depende del alcance: número de IPs, URLs, aplicaciones y profundidad del análisis. Un pentesting web de tamaño estándar suele estar entre 2.500 € y 6.000 €; una API, entre 2.000 € y 6.000 €, y una red interna o perimetral, entre 4.000 € y 12.000 €. Un Red Team parte de 12.000 €. Puedes obtener una estimación inmediata en nuestra calculadora de pentesting, y siempre hacemos una primera llamada gratuita para ajustar la propuesta a tu caso.

¿El pentesting puede afectar a la disponibilidad de mis sistemas?

Definimos el alcance con precisión antes de empezar. Por defecto, evitamos acciones que puedan interrumpir el servicio (DoS, borrado de datos). Si algún test tiene riesgo potencial, lo acordamos contigo y lo hacemos en ventana de mantenimiento.

¿Cuál es la diferencia entre un pentesting y un análisis de vulnerabilidades?

Un análisis de vulnerabilidades es un escaneo automatizado que detecta posibles fallos pero no los verifica ni los explota. Un pentesting va más allá: un experto humano confirma que la vulnerabilidad es explotable, demuestra su impacto real y evalúa si permite escalar el ataque. El resultado es mucho más accionable.

¿Qué diferencia hay entre un pentesting y el hacking ético?

Un pentesting es una prueba técnica con alcance acotado a un sistema o superficie concreta: una aplicación web, una API, una red. El hacking ético es una evaluación más amplia que combina varios vectores —OSINT, perímetro externo, red interna, escalada de privilegios— para simular una campaña de ataque completa contra tu organización. Si necesitas evaluar un sistema específico, el pentesting es el servicio adecuado; si quieres saber hasta dónde llegaría un atacante real en toda tu organización, contrata un hacking ético.

¿Qué información necesitáis para empezar?

Depende del tipo de test. Para un pentesting de caja negra, solo necesitamos las URLs o IPs en alcance. Para uno de caja gris o blanca, podemos necesitar credenciales de prueba, acceso al código fuente o documentación de la arquitectura. Lo acordamos todo antes de empezar.

¿Cuánto tiempo tarda un pentesting?

Entre 3 y 10 días hábiles para la fase técnica, según el alcance. El informe suele entregarse 2-3 días después. Para proyectos de Red Team o infraestructuras complejas, el plazo puede extenderse.

¿Cómo contratar un pentesting para mi empresa?

El proceso es sencillo: nos describes tu entorno (URLs, IPs, aplicaciones o red interna en alcance), hacemos una llamada inicial gratuita para entender tus necesidades, y en 24-48 horas recibes una propuesta con alcance, metodología y precio. No hay letra pequeña ni cargos por el análisis inicial.

¿Hacéis pentesting de sistemas de inteligencia artificial?

Sí, y conviene distinguir dos cosas que suelen confundirse. Una es auditar tu IA: probar tus modelos, chatbots y agentes LLM contra prompt injection, jailbreak, envenenamiento de contexto y fuga de datos del modelo, siguiendo el OWASP Top 10 para LLM y MITRE ATLAS — ese es nuestro servicio de pentesting de inteligencia artificial. La otra es usar IA como herramienta para acelerar un pentesting convencional, que es lo que cubre el pentesting potenciado por IA. Si tu empresa ha puesto un asistente conversacional en producción, lo que necesitas es lo primero.

¿Hacéis pentesting en caja negra, gris o blanca?

Los tres. Caja negra simula un atacante externo sin información previa. Caja gris incluye credenciales de usuario estándar para evaluar el control de acceso. Caja blanca incluye acceso al código y la arquitectura, y permite un análisis más exhaustivo. La mayoría de los clientes optan por caja gris como equilibrio entre realismo y cobertura.

¿Evaluáis WordPress y otros CMS?

Sí. WordPress es el CMS más atacado del mundo precisamente por la proliferación de plugins vulnerables. Evaluamos el core, los plugins instalados, los temas, la configuración del servidor y las prácticas de acceso al panel de administración.

¿Podéis firmar un NDA antes de empezar?

Siempre. Antes de que compartas ningún dato sobre tu infraestructura, firmamos un acuerdo de confidencialidad.

¿Qué pasa si encontráis vulnerabilidades críticas?

Te avisamos de inmediato (mismo día) si encontramos algo que suponga un riesgo grave e inmediato para tu negocio, sin esperar a que termine el test completo.

¿Se puede hacer el pentesting sobre producción o necesitáis un entorno de pruebas?

Se puede hacer sobre producción y es lo más habitual, porque un preproducción con datos falsos y configuración distinta oculta justo lo que interesa encontrar. Lo que se acuerda antes es el perfil de intensidad, la ventana de ejecución para las pruebas que puedan generar carga y una vía de contacto directa para parar en caliente si algo se degrada. Las pruebas potencialmente destructivas se consultan antes de lanzarlas, nunca después.

¿Qué necesitáis para empezar: credenciales, código, documentación?

Depende del modelo de caja acordado. En caja negra basta con la URL y la autorización por escrito. En caja gris —el más rentable para una aplicación con usuarios— hacen falta dos cuentas por cada rol distinto, porque sin ellas no se puede probar la autorización entre usuarios, que es donde aparecen los hallazgos de mayor impacto. El código fuente solo es necesario si se contrata además revisión estática.

¿Qué diferencia hay entre esto y pasar un escáner de vulnerabilidades?

El escáner encuentra lo que ya está catalogado: versiones desactualizadas, cabeceras ausentes, patrones conocidos. No encuentra lógica de negocio rota, que es lo específico de tu aplicación: un descuento que se puede aplicar dos veces, un pedido ajeno cuyo estado se puede cambiar, un flujo de pago que se puede completar saltándose un paso. Eso exige entender a qué se dedica la empresa, y por eso no hay herramienta que lo automatice.

¿Cuánto dura un pentesting web?

La fase técnica suele llevar entre 3 y 10 días hábiles, según el número de roles, flujos y funcionalidades, y el informe llega 2-3 días después. El plazo exacto va en la propuesta, con alcance y precio cerrados.

¿Cada cuánto hay que repetirlo?

Como mínimo una vez al año y siempre después de un cambio relevante: una funcionalidad nueva que maneja datos sensibles, un cambio de autenticación o de proveedor, o una migración. Entre pentests, un análisis de vulnerabilidades recurrente vigila lo catalogado.

¿Necesitáis acceso a la documentación de la API (Swagger/OpenAPI)?

Es útil pero no imprescindible. Podemos trabajar en modo caja negra interceptando el tráfico de la aplicación que consume la API. La documentación acelera el proceso y mejora la cobertura.

¿Auditáis APIs internas o solo las expuestas a internet?

Las dos. De hecho, las APIs internas son frecuentemente las más vulnerables porque se asume erróneamente que "solo las usan los empleados". El movimiento lateral en un ataque suele aprovechar exactamente este tipo de API.

¿Qué diferencia hay entre auditar una API REST y una GraphQL?

GraphQL tiene vectores de ataque específicos: la introspección puede revelar el esquema completo de datos, el batching permite DoS a nivel de aplicación y la autorización a nivel de campo es más compleja de implementar correctamente. Cubrimos ambos con metodologías adaptadas.

¿Cuánto tarda una auditoría de API?

Entre 3 y 7 días hábiles para la fase técnica, según el número de endpoints y la complejidad de los flujos de autenticación y negocio.

¿Necesitáis la documentación de la API o podéis trabajar sin ella?

Se puede trabajar sin ella, pero el resultado es peor y más caro. Con una especificación OpenAPI o una colección de Postman el alcance queda cubierto desde el primer día; sin ella hay que dedicar tiempo a descubrir endpoints, y los que no se descubren no se prueban. Si la documentación está desactualizada, dínoslo: un endpoint que existe y no está documentado es de por sí un hallazgo relevante.

¿Cubrís GraphQL y no solo REST?

Sí, y el enfoque cambia bastante. En GraphQL importan la introspección expuesta en producción, los ataques de profundidad y complejidad de consulta que agotan el servidor, y la autorización a nivel de campo: es frecuente proteger el tipo pero no cada campo, de forma que una consulta anidada devuelve datos que el usuario no debería ver. En REST el peso recae más en la autorización por objeto y en la enumeración de identificadores.

¿Cómo evitáis agotar los límites de peticiones durante las pruebas?

Se acuerda antes: o se excluye la IP de origen del rate limiting durante la ventana de pruebas, o se ajusta la intensidad para mantenerse por debajo del umbral. Conviene decidirlo conscientemente, porque desactivar el límite permite probar el resto a fondo pero deja sin evaluar el propio control de abuso, que en una API expuesta es un hallazgo por derecho propio. Lo habitual es probar ambos escenarios en momentos distintos.

¿Necesitáis el código fuente de la app?

No es imprescindible. Podemos trabajar solo con el binario (APK o IPA) para el análisis estático. El código fuente, si está disponible, permite una revisión más profunda y eficiente.

¿Auditáis apps tanto de iOS como de Android?

Sí. Trabajamos con ambas plataformas. iOS requiere dispositivos con jailbreak o el uso del simulador para ciertos análisis dinámicos. Android es más accesible para el análisis con emuladores.

¿Qué impacto tiene en el proceso de publicación en los stores?

Ninguno directo. La auditoría se hace sobre una versión de prueba o la versión de producción que ya está publicada. Las correcciones se implementan antes de la siguiente release.

¿Podéis hacer solo la auditoría de la API sin analizar la app?

Sí. Si ya tienes la app auditada o lo que te preocupa es el backend, podemos limitarnos a la API. Ver nuestro servicio de pentesting de APIs.

¿Necesitáis acceso de administrador para hacer la auditoría?

No necesariamente. Podemos empezar con una cuenta de usuario estándar para simular exactamente lo que haría un atacante que ha comprometido un puesto de trabajo. Dependiendo del alcance acordado, podemos escalar a privilegios superiores de forma controlada.

¿Qué impacto tiene la auditoría sobre el entorno de producción?

Mínimo. Evitamos por defecto cualquier acción destructiva o que pueda causar bloqueos masivos de cuentas o interrupciones de servicio. Todo se acuerda previamente.

¿Hacéis también hardening de AD una vez identificados los problemas?

La auditoría incluye instrucciones de remediación detalladas. Si necesitas que implementemos directamente las correcciones, podemos presupuestarlo como servicio adicional.

¿Con qué frecuencia debería auditarse el Active Directory?

Mínimo una vez al año y tras cambios importantes en la infraestructura (migraciones, incorporación de nuevas unidades de negocio, fusiones). Los entornos más dinámicos deberían hacerlo cada 6 meses.

¿Cuál es la diferencia entre una auditoría y un pentesting?

El pentesting se centra en explotar vulnerabilidades para confirmar su impacto real. La auditoría tiene un alcance más amplio: revisa configuraciones, políticas, cumplimiento normativo y postura general de seguridad, no solo vulnerabilidades técnicas explotables.

¿Podéis hacer solo la auditoría de una parte concreta?

Sí. Podemos limitar el alcance a una aplicación, un segmento de red, el código de un módulo específico o la configuración de un proveedor cloud. No tenemos mínimos de alcance obligatorios.

¿El informe sirve para presentarlo a clientes o a organismos reguladores?

Sí, siempre que el regulador acepte informes de terceros. Lo estructuramos con la formalidad necesaria para ese uso. Si el regulador exige un formato específico, podemos adaptarlo.

¿Cuánto dura una auditoría de ciberseguridad?

Depende del alcance. Una auditoría acotada a una aplicación o a un segmento de red suele cerrarse en 5-10 días laborables, incluida la redacción del informe. Un alcance amplio —infraestructura, aplicaciones, código y procesos— se mueve entre tres y seis semanas. La fecha de entrega se fija antes de empezar, no sobre la marcha.

¿Qué necesitáis por nuestra parte para empezar?

Un interlocutor técnico, el inventario de activos que entran en alcance y las autorizaciones necesarias si hay terceros implicados (hosting, proveedor cloud, desarrollador externo). Para auditorías internas o de código, los accesos correspondientes. Nada más: el trabajo de preparación lo llevamos nosotros.

¿Incluye una segunda revisión tras corregir los hallazgos?

Sí. Incluimos un re-test de los hallazgos corregidos dentro de una ventana acordada tras la entrega. Una auditoría sin verificación posterior deja sin comprobar lo único que importa: que la corrección funciona y no ha abierto un problema nuevo.

¿Cómo tratáis la información a la que accedéis?

Bajo acuerdo de confidencialidad firmado antes de empezar. Los datos del proyecto se tratan en entornos controlados, no se reutilizan en otros trabajos y las evidencias se retienen solo el tiempo acordado en el contrato. Cualquier dato personal al que se acceda durante la auditoría se trata conforme al RGPD y a la LOPDGDD.

¿Los empleados sabrán que es una simulación?

No durante la campaña. El efecto de aprendizaje es mucho mayor cuando el empleado descubre, después de hacer clic, que era una prueba. Se hace con tacto: no se identifican públicamente ni se usan para sancionar, sino para formar.

¿Necesitáis acceso a nuestro servidor de email?

Necesitamos que nuestra infraestructura de envío esté en la lista blanca para que los emails lleguen correctamente a las bandejas de entrada. Es un proceso técnico sencillo que gestionamos contigo.

¿Qué pasa con los datos de quién hizo clic?

Los datos se gestionan con estricta confidencialidad. El informe puede presentarse de forma anonimizada por departamentos si así lo prefieres, sin identificar a empleados individuales.

¿Con qué frecuencia deberían hacerse estas simulaciones?

Lo mínimo recomendable son 2-3 campañas al año. La concienciación se degrada con el tiempo si no se refuerza. Lo ideal es complementarlo con módulos de formación cortos y periódicos.

¿NIS2 ya está en vigor en España?

La directiva debía transponerse antes del 17 de octubre de 2024 y España no lo hizo: el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad se aprobó en enero de 2025, pero a octubre de 2026 no se ha publicado en el BOE, y la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE en julio de 2026. Mientras tanto no hay un régimen sancionador NIS2 aplicable a empresas y sigue vigente el Real Decreto-ley 12/2018. Las obligaciones llegarán con la ley y la adecuación lleva meses, por eso conviene empezar antes de su publicación.

¿Cuáles son las sanciones por incumplimiento de NIS2?

Para entidades esenciales: hasta 10 millones de euros o el 2% de la facturación anual mundial, la cifra que sea mayor. Para entidades importantes: hasta 7 millones de euros o el 1,4% de la facturación global.

¿En qué se diferencia NIS2 de la anterior directiva NIS1?

NIS2 amplía el ámbito sectorial, aumenta las obligaciones de reporting (notificación en 24/72 horas), eleva las sanciones, incluye responsabilidad personal para los órganos de dirección y añade requisitos sobre la cadena de suministro.

¿Tenemos que hacer un pentesting para cumplir con NIS2?

NIS2 exige evaluar los riesgos de seguridad y aplicar medidas técnicas apropiadas. El pentesting es una de las formas más sólidas de cumplir con esa obligación de forma documentada y verificable.

¿Cuánto tiempo lleva adecuarse a NIS2?

Depende de tu punto de partida. Empresas con una base de seguridad sólida pueden completar el proceso en 3-6 meses. Organizaciones que parten desde cero pueden necesitar 12-18 meses para una adecuación completa.

¿Qué plazos maneja la adaptación a NIS2 en España?

Hoy el calendario no lo fija una fecha de la ley española, que aún no se ha publicado, sino dos cosas: tu punto de partida y tus clientes, que si son entidades reguladas ya están trasladando requisitos por contrato. Recomendamos cerrar el análisis de aplicabilidad y el gap analysis en 4-6 semanas, para tener un plan con plazos defendibles el día que la ley entre en vigor, aunque la implementación se extienda después varios meses.

¿Qué diferencia hay entre estar en ámbito como entidad esencial o importante?

Los requisitos de seguridad del artículo 21 son los mismos para ambas. Lo que cambia es la supervisión y el régimen sancionador: las entidades esenciales están sujetas a supervisión proactiva y a multas de hasta 10 M€ o el 2% de la facturación global; las importantes, a supervisión reactiva — tras un incidente o una denuncia — y hasta 7 M€ o el 1,4%. Determinar la categoría correcta es parte del análisis de aplicabilidad.

¿En qué se diferencia DORA de NIS2?

NIS2 es una directiva horizontal que afecta a múltiples sectores. DORA es un reglamento sectorial específico para el sector financiero, con requisitos más detallados y técnicos, especialmente en lo relativo a las pruebas de resiliencia (TLPT) y la gestión de proveedores TIC.

¿Qué son las pruebas TLPT y quién debe realizarlas?

Las pruebas TLPT (Threat-Led Penetration Testing) son pruebas avanzadas de intrusión basadas en inteligencia de amenazas reales, dirigidas a los sistemas más críticos de la entidad. Solo son obligatorias para las entidades significativas designadas por las autoridades competentes. Nosotros podemos ejecutarlas con metodología TIBER-EU.

¿DORA afecta también a los proveedores tecnológicos de entidades financieras?

Sí. DORA establece un régimen de supervisión directa para los proveedores TIC críticos. Y aunque no seas un proveedor TIC crítico, si eres proveedor tecnológico de una entidad financiera, esta te exigirá que incluyas cláusulas contractuales DORA en el acuerdo de servicio.

¿A partir de cuándo es exigible DORA?

Es de aplicación desde enero de 2025, así que no hay periodo de gracia por delante: las obligaciones ya son exigibles para las entidades en ámbito. Lo que sigue en marcha es el despliegue supervisor y la designación de entidades para pruebas avanzadas, que llega por comunicación de la autoridad competente. No haber recibido esa comunicación no te exime del resto del reglamento.

¿Qué pasa con nuestros proveedores TIC?

Entran por vía contractual. DORA exige mantener un registro de información de proveedores TIC, incluir cláusulas mínimas en los contratos —derechos de auditoría, niveles de servicio, notificación de incidentes, cooperación con el supervisor— y tener una estrategia de salida documentada para los que soporten funciones críticas. Los designados como proveedores críticos pasan además a supervisión directa europea, pero eso es decisión de las autoridades, no tuya.

¿Nos aplica el TLPT o basta con el programa general de pruebas?

El programa general de pruebas lo debe tener toda entidad en ámbito. El TLPT —red team dirigido por inteligencia de amenazas, al menos cada tres años— solo lo exige la autoridad competente a las entidades que designa por tamaño, perfil de riesgo y relevancia sistémica. En España la autoridad es el Banco de España, la CNMV o la DGSFP según el tipo de entidad, y el marco de referencia es TIBER-ES.

¿Qué revisa exactamente el auditor en una auditoría ENS?

Para categoría MEDIA o ALTA, la conformidad se acredita con una auditoría formal que recorre las medidas del Anexo II del RD 311/2022 en tres marcos: el organizativo (política de seguridad, normativa y procedimientos), el operacional (planificación, control de acceso, explotación, continuidad) y las medidas de protección (instalaciones, personal, equipos, comunicaciones e información). No se limita a comprobar que el documento existe: pide evidencia de que la medida opera. Por eso nuestra preparación reproduce esa revisión antes de que llegue la entidad certificadora.

¿Qué tipos de auditoría ENS existen y cuál necesita mi sistema?

Depende de la categoría del sistema (anexo III del RD 311/2022). En categoría BÁSICA no hace falta auditoría: basta una autoevaluación documentada, que puede hacer el propio personal que administra el sistema o en quien este delegue, para emitir la declaración de conformidad. En MEDIA y ALTA se necesita una auditoría formal para obtener la certificación de conformidad, que emite una entidad de certificación acreditada. En todos los casos el artículo 31 exige repetir la auditoría al menos cada dos años, y de forma extraordinaria cuando haya cambios sustanciales en el sistema. Nosotros hacemos la autoevaluación delegada de BÁSICA y, en MEDIA y ALTA, la preauditoría que reproduce la revisión del auditor para que la certificación salga a la primera.

¿Qué diferencia hay entre la declaración de conformidad ENS y la certificación?

La declaración de conformidad es un documento interno que la propia entidad emite afirmando que cumple el ENS. La certificación es emitida por una entidad de certificación acreditada por ENAC tras una auditoría formal. Hay contratos públicos que exigen la certificación, otros que aceptan la declaración.

¿Con qué frecuencia hay que renovar la certificación ENS?

La certificación ENS tiene una vigencia de 2 años, con auditorías de seguimiento anuales.

¿Qué pasa si los sistemas son de categoría BÁSICA?

Los sistemas de categoría BÁSICA tienen un conjunto de medidas menos exigente, pero igualmente obligatorio. La conformidad puede acreditarse mediante una auditoría interna correctamente documentada.

¿Puedo contratar la auditoría ENS con QuantumSec o tiene que ser un organismo oficial?

La certificación formal del ENS debe emitirla una entidad de certificación acreditada por ENAC. Nuestro servicio es la consultoría previa: gap analysis, clasificación del sistema, implementación de medidas y preparación de toda la documentación para que la auditoría de certificación se apruebe a la primera.

¿Qué entidades pueden certificar el ENS?

Cualquier entidad de certificación acreditada por ENAC específicamente para el esquema ENS, como AENOR, Bureau Veritas o DNV. Nosotros no emitimos el certificado —lo hace la entidad acreditada tras la auditoría formal—, pero te ayudamos a elegir y preparamos toda la documentación y evidencias que esa auditoría va a exigir.

¿Cuánto tarda una adecuación al ENS?

Para una categoría BÁSICA con la infraestructura ya ordenada, entre 6 y 10 semanas hasta la declaración de conformidad. Para MEDIA o ALTA con certificación por entidad acreditada, el rango realista va de 4 a 8 meses: el grueso no es la documentación, sino implementar las medidas técnicas que falten y acumular las evidencias de operación que el auditor va a pedir.

¿Necesito el ENS si solo soy proveedor de una administración pública?

Sí en la práctica. El RD 311/2022 extiende las obligaciones a los operadores del sector privado que prestan servicios a entidades públicas, y el nivel exigido se hereda de la categoría del sistema al que das servicio. Es habitual descubrirlo al leer los pliegos: la conformidad ENS aparece como requisito de solvencia técnica, no como mérito.

¿Qué relación tiene el ENS con NIS2?

Se solapan en buena parte del control técnico pero no se sustituyen. El ENS es el marco español para el sector público y sus proveedores; NIS2 es la directiva europea para sectores esenciales e importantes. Si ya tienes el ENS implantado, buena parte del trabajo de NIS2 está hecho —gestión de riesgos, registro de incidentes, continuidad—, pero NIS2 añade obligaciones propias, como la responsabilidad directa del órgano de dirección.

¿Hace falta un pentesting para la adecuación al ENS?

Para categoría ALTA sí: el refuerzo R6 de la medida de vigilancia [op.mon.3] exige pruebas de penetración periódicas sobre los sistemas en alcance. Para MEDIA, el análisis de vulnerabilidades recurrente suele bastar, aunque el auditor puede pedir evidencia de pruebas más profundas según el tipo de servicio. Para BÁSICA no es obligatorio, pero es la vía más rápida de detectar qué medidas declaradas no están funcionando de verdad.

¿El pentesting de red puede interrumpir mis servicios?

En condiciones normales, no. Acordamos el alcance y excluimos acciones disruptivas. Las pruebas más agresivas se planifican en ventanas de mantenimiento. Si trabajas 24/7, definimos ventanas fuera de horas pico.

¿Cuál es la diferencia entre auditoría interna y perimetral?

La perimetral analiza lo que un atacante externo ve desde Internet: puertos abiertos, servicios expuestos, configuración de DMZ. La interna simula a un atacante ya dentro —empleado malicioso, credencial robada— y es donde aparecen los hallazgos más críticos.

¿Con qué frecuencia debería auditar la red?

Al menos una vez al año, y siempre que haya cambios significativos en la infraestructura: nuevas sedes, cambio de proveedor, migración cloud o ampliación de red WiFi corporativa.

¿Qué tamaño de red puede auditarse?

Auditamos desde redes de 20 hosts hasta entornos enterprise de miles de dispositivos. El alcance y precio se adaptan al tamaño real de tu infraestructura.

¿Tenemos que dar acceso al repositorio?

Sí, necesitamos acceso de lectura al repositorio. Firmamos un NDA antes y todo el acceso queda documentado. Puedes crear una rama o fork específico para la revisión si tu política lo requiere.

¿Qué lenguajes y frameworks soportáis?

JavaScript/TypeScript (Node.js, React, Angular, Vue), Python (Django, FastAPI, Flask), Java (Spring), PHP (Laravel), Ruby (Rails), Go y .NET (C#). Si trabajas con otro stack, consúltanos.

¿Cuánto tiempo tarda?

Entre 3 y 8 días hábiles según el tamaño del código base. Un proyecto de 30.000 líneas puede revisarse en unos 4 días. Proyectos mayores requieren más tiempo o una revisión focalizada en módulos críticos.

¿También revisáis infraestructura como código (IaC)?

Sí. Revisamos Terraform, CloudFormation, Kubernetes manifests y Dockerfiles para detectar configuraciones inseguras en la infraestructura definida como código.

¿Qué pasa si un empleado cae en el phishing?

Nada negativo. El objetivo es formativo, no punitivo. El empleado verá una página de aviso que explica que acaba de participar en un ejercicio y qué señales debería haber detectado.

¿Con qué frecuencia debería hacerse?

Al menos dos veces al año para mantener el nivel de alerta. Las organizaciones con mayor exposición o que manejan datos sensibles deberían hacerlo trimestralmente.

¿Podemos excluir ciertos departamentos?

Sí. Podemos segmentar el alcance según departamentos, niveles de acceso o cualquier criterio que necesites.

¿Esto puede acabar señalando a empleados concretos?

No, y el diseño del ejercicio lo impide a propósito. Los resultados se entregan agregados por departamento o por perfil, nunca como una lista de quién cayó. El objetivo es medir la resistencia de la organización y la eficacia de sus controles, no construir un expediente. Un ejercicio que se usa para señalar personas destruye la confianza necesaria para que la gente reporte incidentes, que es justo la capacidad que se quiere reforzar.

¿Hay que avisar a la plantilla de que va a haber un ejercicio?

Avisar de que en algún momento del año habrá simulaciones es recomendable y suele ser exigible por la normativa laboral y de protección de datos aplicable. Avisar de la fecha concreta destruye la medición. El equilibrio habitual es informar en la política de seguridad de que se realizan ejercicios periódicos, sin detallar cuándo ni con qué pretexto, y consensuar el alcance con recursos humanos y con la representación de los trabajadores antes de empezar.

¿Qué tasa de clic es aceptable?

La tasa de clic aislada dice poco, porque depende enormemente de lo verosímil que sea el pretexto: un correo genérico y uno construido con información real de la empresa dan resultados incomparables. Las métricas que sí orientan son la tasa de reporte —cuánta gente avisa al equipo de seguridad— y el tiempo hasta el primer reporte. Una organización con clics pero con reporte rápido está en mejor posición que otra sin clics y sin ningún aviso.

¿Podéis ayudarnos con varias normativas a la vez?

Sí, y tiene sentido hacerlo. Muchos controles de ISO 27001, NIS2 y DORA se solapan. Hacerlo de forma integrada evita duplicidades y reduce el esfuerzo total.

¿Hacéis también la auditoría de certificación?

No somos organismo certificador (requiere acreditación ENAC), pero trabajamos con las principales entidades certificadoras y te acompañamos durante todo el proceso.

¿Cuánto tiempo lleva un proyecto de cumplimiento?

Depende de la normativa y el estado de partida. Un gap analysis tarda 2-4 semanas. Un proyecto completo de ISO 27001 desde cero tarda entre 6 y 12 meses en una PYME.

¿El ENS es obligatorio para empresas privadas?

El ENS es obligatorio para administraciones públicas y las empresas privadas que prestan servicios TIC a la Administración o tratan datos de titularidad pública.

¿Por dónde empezamos si no cumplimos todavía ninguna normativa?

Por el diagnóstico, no por la documentación. Primero se determina qué normativas te obligan de verdad y en qué categoría entras, después se mide la distancia real entre lo que haces y lo que se te exige. Empezar redactando políticas antes de saber eso produce carpetas que no resisten una auditoría y no reducen ningún riesgo.

¿Qué pasa si nos auditan antes de terminar la adecuación?

Tener un plan de adecuación documentado, con hitos y responsables, es una posición defendible ante un supervisor; no tener nada no lo es. Por eso el primer entregable es siempre el plan priorizado por riesgo: si la auditoría llega antes de tiempo, puedes demostrar qué has hecho, qué está en curso y con qué criterio lo has ordenado.

¿Cuánto de lo que exige NIS2 sirve también para ISO 27001 o el ENS?

Bastante más de lo que suele asumirse. Gestión de riesgos, control de accesos, gestión de incidentes, continuidad de negocio y seguridad de proveedores aparecen en los tres marcos con distinta redacción y el mismo fondo. Lo rentable es mapear una sola vez los controles comunes y documentar por separado solo lo específico de cada norma. Mantener tres marcos completos en paralelo multiplica el coste sin añadir cumplimiento.

¿ISO 27001:2013 o ISO 27001:2022? ¿Hay que migrar?

La versión vigente es la ISO 27001:2022. Los certificados emitidos bajo la versión 2013 tenían de plazo hasta octubre de 2025 para migrar. Si estás empezando, arranca directamente con la versión 2022.

¿Cuántos recursos internos necesita el proyecto?

Se necesita un responsable interno (normalmente el CISO o responsable de IT) con entre 4 y 8 horas semanales. El equipo técnico participa puntualmente en la implementación de controles.

¿El certificado ISO 27001 tiene fecha de caducidad?

El certificado tiene validez de 3 años, con auditorías de seguimiento anuales (años 1 y 2) y auditoría de renovación en el año 3.

¿Podéis encargaros del SGSI después de la certificación?

Sí, salvo de la auditoría de seguimiento en sí, que la hace la misma entidad certificadora cada año. Lo que hacemos nosotros es lo que esa auditoría va a revisar: la auditoría interna que exige la cláusula 9.2, la revisión por la dirección, la actualización del análisis de riesgos y de la Declaración de Aplicabilidad cuando cambia la empresa, y la preparación de la renovación al tercer año.

¿Cuánto se tarda en implantar ISO 27001 hasta la certificación?

Con un alcance acotado (un producto, un servicio o una sede), entre 3 y 6 meses hasta la auditoría de certificación; con alcances amplios o varias sedes, de 6 a 12 meses. Lo que más alarga el proyecto no es redactar las políticas, sino que los controles lleven el tiempo suficiente funcionando para que haya registros que enseñar al auditor en la Etapa 2.

¿Con qué entidad de certificación trabajáis?

No emitimos el certificado nosotros: por incompatibilidad de roles, quien te ayuda a implantar el SGSI no puede ser quien lo certifique. Te acompañamos en el proceso de selección entre entidades acreditadas por ENAC —AENOR, Bureau Veritas, DNV y otras— y damos soporte técnico durante toda la auditoría externa, sea cual sea la que elijas.

¿El pentesting de IA afecta al rendimiento del modelo en producción?

No. Las pruebas se realizan en un entorno de staging o con tráfico controlado. Nunca interferimos con usuarios reales ni degradamos el servicio.

¿Necesito acceso al modelo o solo a la interfaz?

Depende del alcance. Un test de caja negra solo requiere acceso a la interfaz final. Un test completo de pipeline requiere acceso al código del sistema y configuración del modelo.

¿Cubrís modelos open-source desplegados on-premise?

Sí. Evaluamos tanto modelos en cloud (APIs de OpenAI, Anthropic, Google) como modelos open-source (Llama, Mistral, Qwen) desplegados en infraestructura propia.

¿Evaluáis agentes de IA y servidores MCP?

Sí. Un agente conectado a varios servidores MCP hereda la confianza de la herramienta más débil que tenga enchufada. Evaluamos tool poisoning, escalada de privilegios entre herramientas conectadas y exfiltración a través de un canal de salida legítimo (publicar, enviar un correo, abrir un PR).

¿Necesitáis credenciales de administrador para el pentesting cloud?

Para un test completo, sí necesitamos una cuenta con permisos de lectura sobre todos los servicios. También podemos realizar un test de caja negra desde internet para evaluar la exposición externa. Te recomendamos combinar ambos enfoques.

¿El pentesting puede afectar a mis servicios en producción?

Coordinamos todas las pruebas para minimizar el impacto. La explotación destructiva (borrado, modificación de datos) siempre requiere aprobación explícita y se realiza en entornos de prueba.

¿Cubrís arquitecturas multi-cloud?

Sí. Tenemos experiencia en entornos que combinan AWS, Azure y GCP, así como en configuraciones híbridas cloud + on-premise.

¿Qué permisos necesitáis sobre nuestra cuenta cloud?

Un rol de solo lectura sobre la configuración es suficiente para la parte de revisión: en AWS equivale a SecurityAudit o ViewOnlyAccess, con equivalentes en Azure y GCP. Para la parte ofensiva —comprobar si una identidad concreta puede escalar privilegios— hace falta además una identidad de prueba con permisos deliberadamente limitados, que es justo la que permite demostrar hasta dónde llega alguien que comprometa una cuenta de bajo privilegio.

¿Hay que avisar al proveedor cloud antes de las pruebas?

Los grandes proveedores permiten hoy la mayor parte de las pruebas sobre recursos propios sin autorización previa, pero mantienen excepciones —principalmente pruebas de denegación de servicio y de saturación— que sí requieren permiso o están directamente prohibidas. Revisamos la política vigente del proveedor al definir el alcance y dejamos por escrito qué queda dentro y qué fuera, porque esas políticas cambian.

¿Esto sustituye a las herramientas de postura de seguridad que ya tenemos?

No, las complementa. Una herramienta de postura te dice qué configuraciones se desvían de una línea base, y eso lo hace mejor y de forma continua. Lo que no hace es encadenar: comprobar si esa configuración concreta, combinada con ese rol y esa función sin red privada, permite a un atacante llegar desde un bucket público hasta credenciales de producción. El valor del ejercicio está en la cadena, no en el hallazgo aislado.

¿Necesitáis acceso físico al dispositivo?

Para un test completo, sí. La API cloud, la app móvil y las comunicaciones de red se pueden probar en remoto, pero el análisis de hardware y de firmware necesita el dispositivo en nuestro laboratorio.

¿Cuántas unidades necesitáis?

Lo ideal son dos o tres: algunas pruebas de hardware pueden exigir desoldar componentes o dejar una unidad inservible. Si solo hay una, se planifica empezando por las técnicas no destructivas y se acuerda contigo antes cualquier paso que pueda dañarla.

¿Necesitáis el firmware o el código fuente?

No es imprescindible: extraer el firmware de la propia placa es parte de la prueba, porque es lo que haría un atacante. Si nos lo facilitas, junto con los esquemas o el código, el análisis llega más lejos en el mismo tiempo.

¿Qué exige la directiva RED a un dispositivo conectado?

Desde el 1 de agosto de 2025, el Reglamento Delegado (UE) 2022/30 obliga a los equipos radioeléctricos que se conectan a internet, y a algunos que tratan datos personales o permiten pagos, a cumplir requisitos de ciberseguridad. Las normas EN 18031-1, -2 y -3 son la vía para presumir la conformidad. Un pentest aporta la evidencia técnica de que esos requisitos se cumplen de verdad, más allá de la documentación.

¿Y el Cyber Resilience Act?

El CRA se aplica a casi cualquier producto con elementos digitales que se venda en la UE. Desde el 11 de septiembre de 2026 los fabricantes deben notificar a ENISA las vulnerabilidades activamente explotadas, y el 11 de diciembre de 2027 será plenamente aplicable, con requisitos de seguridad desde el diseño, gestión de vulnerabilidades y actualizaciones durante la vida del producto.

¿Podéis hacer el pentest sin afectar a la producción industrial?

Sí. En entornos OT trabajamos con el equipo de planta para definir ventanas de mantenimiento, priorizamos técnicas pasivas y hacemos las pruebas más invasivas sobre equipos de reserva o en un banco de pruebas, nunca a ciegas sobre un proceso en marcha.

¿El informe sirve para el expediente técnico del producto?

Sí, como evidencia de las pruebas de seguridad: cada hallazgo indica qué se probó, cómo, el resultado y la referencia a la norma correspondiente, y el retest documenta que las correcciones funcionan. La evaluación de conformidad en sí la hace el fabricante o, cuando corresponde, un organismo notificado.

¿Cuánto dura un pentest IoT?

Depende sobre todo de cuántas capas entran en el alcance (hardware, firmware, radio, app, nube) y de cuántas unidades hay. Lo fijamos en la propuesta, con alcance y precio cerrados, después de una primera llamada en la que vemos el dispositivo y su ecosistema.

¿Necesitáis el código fuente o solo la app?

Podemos trabajar solo con la build (caja negra o gris), como lo haría un atacante. Si además nos das el código, el análisis llega más lejos en el mismo tiempo y las recomendaciones apuntan a la línea exacta. Para equipos que quieren corregir rápido, lo recomendamos.

¿Cómo nos pasáis la app para probarla?

Lo más sencillo es una build de pruebas por TestFlight o un IPA firmado para desarrollo, junto con cuentas de prueba para cada rol. Si la app solo está publicada, también se puede trabajar con la versión de la App Store.

¿Hace falta un dispositivo con jailbreak?

Para el análisis dinámico completo, sí: lo ponemos nosotros. Parte del análisis estático y de red se puede hacer sin jailbreak o en simulador, pero muchos fallos de almacenamiento y de autenticación solo se ven en un dispositivo real.

¿Incluye la API que usa la app?

Sí. La mayoría de los hallazgos graves de una app están en su backend: endpoints que devuelven datos de otros usuarios o que aceptan lo que la app ya debería haber validado. La API entra en el mismo alcance.

¿Qué es OWASP MASVS y qué nivel necesitamos?

Es el estándar de verificación de seguridad de apps móviles de OWASP, organizado en ocho categorías: almacenamiento, criptografía, autenticación, red, plataforma, código, resiliencia y privacidad. Desde la versión 2 ya no define niveles L1 y L2 dentro del estándar: el alcance se ajusta con los perfiles de prueba del proyecto OWASP MAS según el riesgo de la app, y lo acordamos contigo en la propuesta.

¿Probáis también la versión Android?

Sí, y conviene hacerlo en el mismo proyecto: comparten API y lógica, pero cada plataforma tiene fallos propios. Probar las dos juntas evita pagar dos veces el análisis del backend.

¿Cuánto dura un pentest de una app iOS?

Depende del número de funcionalidades y roles y de si la API entra en el alcance. La fase técnica de un pentest suele llevar entre 3 y 10 días hábiles y el informe llega 2-3 días después; el plazo exacto va en la propuesta.

¿Necesitáis el código fuente de la app Android?

No es imprescindible: podemos trabajar con el APK o el AAB, como lo haría un atacante. El código fuente permite llegar más lejos en el mismo tiempo, sobre todo en la lógica de negocio, y que las recomendaciones apunten a la línea exacta.

¿Podéis hacer el test sin un dispositivo físico?

Parte del análisis estático y de red se puede hacer en emulador. Para el análisis dinámico completo con Frida, y para lo que depende del hardware como el Keystore o la biometría, usamos dispositivos físicos con root que ponemos nosotros.

¿Probáis la app ofuscada de producción?

Sí. La ofuscación con R8 o con herramientas comerciales dificulta el análisis, pero no lo impide, y precisamente medir cuánto cuesta saltarla es parte de la prueba de resiliencia. Si quieres más profundidad en el mismo tiempo, una build sin ofuscar ayuda.

¿La auditoría ayuda a cumplir el RGPD?

Sí. Identificamos dónde se guardan y por dónde viajan los datos personales, si están bien protegidos y qué permisos sobran. Es información clave para la evaluación de impacto (EIPD) y para que la sección de seguridad de los datos de Google Play diga la verdad.

¿Cuánto dura un pentest de una app Android?

Depende del número de funcionalidades y roles y de si la API entra en el alcance. La fase técnica de un pentest suele llevar entre 3 y 10 días hábiles y el informe llega 2-3 días después; el plazo exacto va en la propuesta.

¿El servicio de CTI es continuo o puntual?

Es un servicio continuo de monitorización. La inteligencia puntual (un informe de exposición o un análisis de un actor de amenaza concreto) también está disponible como servicio ad-hoc.

¿Cómo se integra el CTI con nuestros sistemas de seguridad existentes?

Proporcionamos feeds en formatos estándar (STIX/TAXII, CSV, JSON) integrables con los principales SIEMs (Splunk, Microsoft Sentinel, QRadar) y plataformas SOAR.

¿Qué diferencia hay entre CTI y OSINT?

OSINT es una fuente (información de fuentes abiertas). CTI es un proceso completo: recolección de múltiples fuentes (OSINT, dark web, feeds privados), análisis, contextualización y producción de inteligencia accionable para la toma de decisiones.

¿Necesitáis estar físicamente en nuestras instalaciones?

Para la evaluación completa, sí. El análisis de redes inalámbricas requiere presencia física. Coordinamos visitas en horario que minimice la interrupción de la actividad.

¿La auditoría WiFi incluye redes de invitados?

Sí, incluimos todas las redes inalámbricas en el perímetro: corporativas, de invitados, IoT y cualquier red no autorizada que detectemos.

¿Evaluáis también la seguridad de los dispositivos conectados al WiFi?

El alcance estándar cubre la infraestructura inalámbrica. Si deseas incluir la evaluación de dispositivos conectados (IoT, PCs, impresoras), lo ampliamos como parte de un pentesting de red interno.

¿Hace falta que alguien vaya presencialmente a nuestras oficinas?

Sí. Una auditoría WiFi seria exige presencia física, porque buena parte de lo que se evalúa depende de la propagación real de la señal: hasta dónde llega desde la calle o desde el aparcamiento, qué se ve desde una sala de espera, si un punto de acceso no autorizado pasaría desapercibido. Lo que sí se puede preparar en remoto es la revisión de configuración de controladores y la documentación de red.

¿Se interrumpe la red durante las pruebas?

En condiciones normales no. La mayor parte del trabajo es pasivo: capturar, observar y analizar. Las pruebas que sí pueden afectar al servicio —desautenticación de clientes para capturar un handshake, o levantar un punto de acceso gemelo— se acuerdan antes y se ejecutan en ventana pactada, normalmente fuera del horario de mayor uso. Nunca se lanzan sin avisar.

Tenemos WPA3, ¿seguimos necesitando la auditoría?

WPA3 cierra ataques concretos del protocolo anterior y no cierra los que más se explotan en la práctica. La mayoría de los hallazgos de una auditoría WiFi corporativa no son criptográficos: son de segmentación —la red de invitados que alcanza la red interna—, de puntos de acceso no autorizados conectados por alguien de la propia empresa, de credenciales compartidas que nunca rotan, y de dispositivos antiguos que fuerzan a mantener modos de compatibilidad que anulan la mejora.

¿Qué diferencia hay entre MSSP y un contrato de mantenimiento IT?

Un MSSP se centra exclusivamente en seguridad: detección de amenazas, gestión de vulnerabilidades, respuesta a incidentes y cumplimiento normativo. No gestionamos infraestructura ni soporte de usuario final.

¿Cuál es el SLA de respuesta ante un incidente?

Para incidentes críticos, el tiempo de respuesta inicial es inferior a 4 horas. Para incidentes de alto impacto, garantizamos inicio del análisis forense en el mismo día.

¿El servicio incluye el pentesting anual?

Sí, los planes de nivel medio y superior incluyen un pentesting anual de alcance acordado. Es la combinación ideal: monitorización continua + evaluación ofensiva periódica.

¿El pentesting con IA es tan riguroso como el manual?

Es más riguroso en cobertura (la IA no se cansa, no omite pasos) y menos en creatividad pura. Por eso combinamos ambos: la IA garantiza la cobertura sistemática y el experto humano aporta creatividad, contexto y explotación avanzada.

¿Qué herramientas de IA utilizáis?

Combinamos herramientas propietarias con soluciones reconocidas del sector, adaptadas a cada tipo de evaluación. No dependemos de un único proveedor ni de herramientas de IA genéricas sin validación en seguridad.

¿Es más barato que el pentesting tradicional?

Generalmente sí, porque la automatización reduce las horas de reconocimiento manual. Pero el valor principal no es el coste: es la mayor cobertura en el mismo tiempo.

¿Cómo evitáis los falsos positivos que genera la IA?

Ningún hallazgo llega al informe sin validación manual. La IA amplía la cobertura del reconocimiento y agrupa evidencias, pero la confirmación de que algo es explotable la hace un pentester reproduciendo el ataque. Un informe con falsos positivos hace que el equipo de desarrollo deje de leerlo, y ese es un coste mayor que el de no haber automatizado nada.

¿Se envían nuestros datos a modelos de terceros?

No sin acuerdo previo y por escrito. El alcance, las herramientas y el tratamiento de los datos se fijan antes de empezar. Cuando un ejercicio requiere procesar información sensible del cliente, se acuerda dónde se procesa y bajo qué condiciones, y queda reflejado en el contrato junto al acuerdo de confidencialidad.

¿Qué parte del trabajo sigue siendo humana?

La que decide. La IA acelera el reconocimiento, la correlación de datos y la priorización inicial; el pentester define el alcance, diseña las cadenas de ataque, explota la lógica de negocio y juzga el impacto real sobre tu operativa. La lógica de negocio rota sigue siendo el hallazgo que ninguna herramienta encuentra sola, porque exige entender a qué se dedica la empresa.

¿Un análisis de vulnerabilidades es suficiente para cumplir con NIS2 o ISO 27001?

Depende del nivel de madurez requerido. NIS2 e ISO 27001 requieren gestión continua de vulnerabilidades, que puede cubrirse con un VA recurrente. Para demostraciones de impacto real o evaluaciones de Red Team, se requiere pentesting.

¿Con qué frecuencia debería hacer un análisis de vulnerabilidades?

Recomendamos un ciclo mensual para activos críticos y trimestral para el resto. Tras cambios significativos en la infraestructura (nueva aplicación, migración cloud, etc.) siempre recomendamos un análisis puntual.

¿El VA incluye aplicaciones web?

Sí. El alcance puede incluir infraestructura de red, servidores, aplicaciones web y APIs. También ofrecemos el análisis de vulnerabilidades como primer paso antes de un pentesting web completo.

¿En qué se diferencia de un pentesting?

El análisis de vulnerabilidades identifica y clasifica debilidades conocidas de forma automatizada y recurrente, con validación manual de los hallazgos relevantes. El pentesting va más allá: explota esas debilidades, encadena fallos y demuestra el impacto real sobre el negocio. El VA responde a "qué tengo expuesto"; el pentesting, a "hasta dónde puede llegar un atacante".

¿Cómo priorizáis los hallazgos?

Combinamos tres señales en vez de fiarnos solo de la severidad teórica: CVSS para el impacto técnico, EPSS para la probabilidad de explotación en los próximos 30 días, y el catálogo KEV de CISA para saber qué se está explotando ya. Un CVSS 9.8 sin explotación observada rara vez es más urgente que un 7.5 con exploit público circulando.

¿Qué hacéis con los falsos positivos?

Los descartamos antes de entregarte el informe. Un escáner sin revisión humana genera ruido que acaba desactivando el proceso: el equipo deja de leer los informes. Validamos manualmente los hallazgos de criticidad alta y media, y documentamos por qué se descarta lo que se descarta.

¿El escaneo puede afectar al rendimiento de los sistemas?

Trabajamos con perfiles de intensidad ajustados al entorno y acordamos ventanas de ejecución para los activos sensibles. En producción usamos configuraciones no intrusivas por defecto. Si un test concreto implica riesgo de indisponibilidad, se consulta antes de lanzarlo, nunca después.

¿Qué diferencia hay entre hacking ético externo y un pentesting de red?

El hacking ético externo se centra exclusivamente en lo que es visible desde internet, comenzando desde cero (sin credenciales ni acceso previo), incluyendo OSINT. El pentesting de red cubre tanto el perímetro externo como la red interna.

¿Incluye el OSINT en empleados?

Sí, dentro del alcance acordado. Identificamos datos de empleados expuestos en filtraciones, LinkedIn y otras fuentes que un atacante real utilizaría para ataques dirigidos o credential stuffing.

¿Puede detectar si ya hemos sido comprometidos?

Una evaluación de compromiso activo (Compromise Assessment) es un servicio diferente. Sin embargo, si durante el reconocimiento detectamos indicadores de compromiso previo, te lo comunicamos inmediatamente.

¿Desde qué punto de partida se realiza el hacking ético interno?

Típicamente simulamos un usuario de dominio estándar (el escenario más realista: un empleado comprometido o un atacante con acceso inicial vía phishing). También podemos empezar desde acceso físico a la red (cable de red) o desde una cuenta sin privilegios en el equipo.

¿El test puede afectar a los sistemas en producción?

Coordinamos todas las pruebas con el equipo de IT. Las técnicas más invasivas (como modificar el AD) se realizan solo con autorización explícita y en ventanas acordadas. El objetivo es simular un ataque, no causar daño.

¿Qué es BloodHound y por qué es relevante?

BloodHound es la herramienta estándar del sector para analizar relaciones en Active Directory y encontrar caminos de escalada de privilegios. Los atacantes la usan; nosotros también, para que puedas ver exactamente lo que ellos verían en tu AD.

¿Cuánto cuesta la ciberseguridad para una PYME?

Depende del tamaño y la exposición. Un diagnóstico inicial y un análisis de vulnerabilidades básico puede estar en el rango de unos pocos cientos de euros. Un servicio de seguridad gestionada para una PYME típica oscila entre 300 y 800 €/mes. Siempre empezamos con lo que más impacto tiene por el menor coste.

¿Obligatoriamente tengo que cumplir con NIS2 siendo una PYME?

Depende de tu sector y tamaño. NIS2 obliga directamente a empresas medianas y grandes en sectores esenciales e importantes. Sin embargo, muchas PYMEs están indirectamente obligadas porque son proveedoras de empresas que sí deben cumplir, y estas les exigen garantías de seguridad.

¿Podéis ayudarnos aunque no tengamos ningún responsable de IT?

Sí. Trabajamos directamente con gerencia o con quien sea el responsable habitual de IT/informática en la empresa. No es necesario tener conocimientos técnicos previos para trabajar con nosotros.

¿Cuánto tiempo tarda poner en marcha un plan de ciberseguridad para mi PYME?

Las medidas de mayor impacto inmediato (MFA, contraseñas, copias de seguridad) se configuran en días. Un análisis de vulnerabilidades inicial dura entre 1 y 5 días hábiles según el tamaño. Un plan completo con análisis, remediación acompañada y políticas básicas suele completarse en 4-8 semanas. Siempre empezamos por lo que más impacto tiene al menor coste.

¿Mi empresa ya ha sufrido un ciberataque. ¿Qué hago ahora?

Lo primero es contener: aislar los sistemas afectados, revocar accesos comprometidos y guardar evidencias sin modificarlas. A continuación, un análisis forense básico determina cómo entraron, qué afectaron y si siguen dentro. Si el incidente involucra datos personales, tienes 72 horas para notificar a la AEPD. Contáctanos: hacemos un triaje inicial para ayudarte a entender la situación antes de decidir los pasos siguientes.

¿Necesito un CISO o responsable de seguridad interno?

Para la mayoría de las PYMEs no es necesario ni viable. Un CISO senior en plantilla es un coste fijo elevado y un perfil difícil de atraer y retener. La alternativa es un servicio de CISO virtual o un partner de seguridad externo: tú defines los objetivos, nosotros los ejecutamos y te informamos periódicamente. Es mucho más eficiente para empresas de menos de 100 empleados.

¿Qué es la seguridad gestionada y cuándo tiene sentido para una PYME?

Es un servicio de monitorización y respuesta continua (SOC as a Service) sin necesidad de contratar un equipo propio: nosotros vigilamos tus sistemas, detectamos incidentes y actuamos según protocolos acordados contigo. Tiene sentido cuando ya tienes activos críticos que proteger fuera de horario laboral pero no el volumen para justificar un SOC interno.

¿Necesito un ciberseguro además de contratar servicios de ciberseguridad?

Son complementarios, no sustitutos. La mayoría de las aseguradoras exigen controles mínimos (MFA, backups, análisis de vulnerabilidades periódico) para emitir o renovar una póliza de ciberriesgo, y reducen la prima si puedes demostrarlos. Te ayudamos a identificar qué exige tu aseguradora y a implementarlo antes de la renovación.

¿Cuándo es el mejor momento para hacer un primer pentesting?

El primer pentesting debería hacerse cuando el producto está en versión beta o antes del lanzamiento público. Esperar a tener tracción o usuarios reales aumenta el riesgo y el coste de la remediación.

¿Podéis ayudarnos a preparar el cuestionario de seguridad de un cliente enterprise?

Sí. Es uno de los servicios más demandados por startups. Te ayudamos a responder cuestionarios de seguridad (CAIQ, SIG, cuestionarios propios) y a tener la documentación que respalda esas respuestas.

¿Tenéis experiencia con startups que usan código generado por IA o vibe coding?

Sí. El código generado por LLMs tiende a reproducir patrones de vulnerabilidades conocidos (inyecciones, manejo inseguro de secretos, validación débil). Tenemos un servicio específico de revisión de código generado por IA.

¿El código generado por IA es más inseguro que el escrito por humanos?

No necesariamente, pero introduce riesgos distintos. Los LLMs son muy buenos reproduciendo patrones conocidos, pero pueden reproducir igualmente patrones inseguros. El mayor riesgo es el "vibe coding": el desarrollador no entiende el código y no puede identificar los problemas de seguridad.

¿Necesitáis acceso al repositorio completo?

Sí, para un análisis completo necesitamos acceso de lectura al código fuente. Trabajamos con GitHub, GitLab y Bitbucket, y firmamos NDA antes de cualquier acceso.

¿Podéis auditar código generado con Cursor, Devin u otras herramientas de IA?

Sí. La herramienta específica de generación de IA es menos relevante que el patrón de vulnerabilidades del código resultante. Evaluamos el código independientemente de con qué herramienta fue generado.

No tengo desarrollador ni equipo técnico, ¿podéis auditarla igual?

Sí. Nos basta con la URL de la aplicación y, si existe, acceso de lectura al proyecto del generador o al repositorio. Buena parte de los fallos característicos de estas aplicaciones —base de datos accesible desde el navegador, claves en el código de front, datos de otras cuentas visibles— se detectan desde fuera, sin tocar el código. El informe se entrega en lenguaje claro y, si hace falta, lo explicamos directamente a quien vaya a aplicar las correcciones.

¿Auditáis apps hechas con Lovable, Bolt o v0, o solo código de Copilot?

Las dos cosas, aunque el trabajo es distinto. Con un copiloto como Copilot o Cursor existe un repositorio y la auditoría se parece a una revisión de código clásica. Con un generador de aplicaciones como Lovable, Bolt, v0 o Replit, el fallo rara vez está en una línea concreta: está en la configuración que el generador dejó abierta por defecto, sobre todo en la capa de datos y en los permisos entre usuarios. Ahí revisamos la aplicación desplegada, no solo el código.

¿En qué se diferencia una consultoría de ciberseguridad de un pentesting?

El pentesting es una prueba técnica que busca vulnerabilidades explotables en un sistema concreto. La consultoría de ciberseguridad es un servicio más amplio que evalúa la madurez general de la organización: controles técnicos, procesos, personas y cumplimiento normativo. Muchas veces la consultoría lleva a identificar que un pentesting es el siguiente paso necesario, pero no siempre.

¿Cuánto cuesta una consultoría de ciberseguridad?

Depende del alcance y del tamaño de la organización. Una consultoría de diagnóstico inicial para una PYME puede partir de 2.500 €. Un proyecto más amplio con hoja de ruta completa y acompañamiento en la implantación puede situarse entre 8.000 y 25.000 €. Siempre damos un presupuesto cerrado antes de empezar.

¿Podéis actuar como CISO externo después de la consultoría?

Sí. Ofrecemos un servicio de CISO as a Service (CISOaaS) para empresas que necesitan una figura de dirección de seguridad sin el coste de contratarla a tiempo completo. Incluye supervisión de la hoja de ruta, asistencia a comités directivos y toma de decisiones estratégicas de seguridad.

¿La consultoría incluye el cumplimiento de NIS2?

Sí. Realizamos el gap analysis respecto a NIS2, identificamos si tu empresa está en scope (sectores obligados), evaluamos las medidas existentes frente a los requisitos de la directiva y preparamos un plan de adecuación con los controles técnicos y organizativos necesarios.

¿Necesito tener un equipo técnico propio para trabajar con vosotros?

No. Trabajamos tanto con empresas que tienen equipo IT interno como con empresas sin recursos técnicos propios. Adaptamos el lenguaje, el nivel de detalle y el acompañamiento a la realidad de cada cliente.

¿Hacéis reuniones presenciales en Valencia?

Sí. Tenemos base en Valencia y podemos reunirnos presencialmente para la llamada inicial, presentación de resultados o sesiones de formación. La ejecución técnica se realiza de forma remota o in situ según el alcance del servicio.

¿En qué municipios de la Comunitat Valenciana dais servicio?

En toda la Comunitat Valenciana. Nuestra oficina está en Valencia capital y desde ahí nos desplazamos con normalidad al área metropolitana (Paterna, Torrent, Manises, Burjassot, Mislata), La Ribera (Alzira, Algemesí, Carcaixent), La Safor (Gandia, Oliva), el litoral (Cullera, Sueca, Sagunto, Dénia), La Costera (Xàtiva, Canals) y La Vall d'Albaida (Ontinyent). También atendemos empresas de Castellón y Alicante. No tenemos oficina en cada municipio: tenemos una sede en Valencia y un equipo que se desplaza, que es lo que permite mantener el trato directo sin encarecer el servicio.

¿Trabajáis solo con grandes empresas o también con PYMEs valencianas?

Trabajamos con todo tipo de empresas, desde autónomos con presencia digital hasta empresas del Ibex35. Tenemos propuestas específicamente diseñadas para el tejido PYME valenciano, con alcances y precios adaptados a su realidad.

¿Cuánto cuesta un servicio de ciberseguridad para una empresa en Valencia?

El coste varía según el alcance. Un análisis de vulnerabilidades básico para una PYME empieza desde 1.500 €. Un pentesting completo (web + red interna) está entre 4.000 y 12.000 € según la complejidad. Solicitanos una consulta gratuita y te damos un presupuesto sin compromiso en 24 horas.

¿Podéis ayudarnos a cumplir la directiva NIS2 desde Valencia?

Sí. Asesoramos a empresas valencianas en la adaptación a NIS2, identificando si están en scope, realizando el gap analysis, implementando los controles requeridos y preparando la documentación para la autoridad competente (INCIBE-CERT / CCN-CERT).

¿Trabajáis con empresas del sector industrial y logístico de Valencia?

Sí. Tenemos experiencia con entornos OT/ICS, redes industriales y sistemas SCADA, habituales en el tejido industrial valenciano (Zona Industrial de Paterna, Puerto de Valencia, polígonos de Almussafes). La seguridad de entornos industriales requiere enfoques diferentes a la IT convencional.

¿Qué hace exactamente una empresa de seguridad informática como QuantumSec?

Una empresa de seguridad informática evalúa, protege y monitoriza los sistemas digitales de tu organización. En QuantumSec nos especializamos en el lado ofensivo: pentesting (simular ataques reales), hacking ético (auditar tus defensas desde la perspectiva del atacante), análisis de vulnerabilidades y cumplimiento normativo (NIS2, ENS, ISO 27001). A diferencia de una empresa de seguridad generalista, nuestro enfoque ofensivo identifica los fallos reales antes de que los exploten terceros.

¿Cuándo entra en vigor el Cyber Resilience Act?

El CRA entró en vigor el 10 de diciembre de 2024. La aplicación plena de los requisitos técnicos y de conformidad es el 11 de diciembre de 2027. Hay dos hitos intermedios: desde el 11 de junio de 2026 los Estados miembros pueden designar organismos notificados para la evaluación por terceros, y desde el 11 de septiembre de 2026 es obligatorio notificar a ENISA las vulnerabilidades activamente explotadas y los incidentes graves.

¿El CRA aplica a todo el software o solo al hardware conectado?

El CRA aplica a todos los "productos con elementos digitales": hardware y software con conectividad de red directa o indirecta. Están excluidos el software publicado como open source sin finalidad comercial, los servicios SaaS puros sin componentes instalables en el cliente, los productos médicos regulados por el MDR, los productos de aviación civil y el equipo de defensa. Si tu SaaS incluye un agente de escritorio o un plugin instalable, ese componente sí entra en el ámbito del CRA.

¿Cuáles son las sanciones por incumplimiento del CRA?

El CRA establece tres niveles de sanción: hasta 15 millones de euros o el 2,5% de la facturación anual global por incumplimiento de los requisitos esenciales de ciberseguridad; hasta 10 millones o el 2% por incumplimiento de otras obligaciones; y hasta 5 millones o el 1% por facilitar información incorrecta a las autoridades.

¿Qué diferencia hay entre los productos Clase I, Clase II y los productos Default?

Los productos Default son la mayoría y pueden hacer self-assessment. La Clase I incluye productos de mayor riesgo (sistemas de gestión de identidad, navegadores, gestores de contraseñas, software de seguridad, routers domésticos) y requieren evaluación de terceros salvo que apliquen íntegramente una norma armonizada. La Clase II incluye los más críticos (sistemas operativos de servidores, hipervisores, cortafuegos industriales, sistemas de control industrial, PKI, TPMs) y requieren obligatoriamente auditoría por un organismo notificado.

¿El CRA se solapa con NIS2 o con otras normativas?

Sí. NIS2 regula la ciberseguridad de los operadores de servicios esenciales, mientras que el CRA regula la seguridad de los productos digitales antes de ponerse en el mercado. Si eres fabricante de software y además operas un servicio esencial, te aplican ambas. También hay solapamientos con el MDR para dispositivos médicos conectados (el MDR prevalece) y con el esquema EUCS para productos de cloud crítica.

¿Cuánto tiempo lleva adecuarse al CRA?

Depende del punto de partida y de la categoría de productos. Empresas con un SDLC seguro ya implementado y procesos de gestión de vulnerabilidades maduros pueden completar el proceso en 6-9 meses. Organizaciones que parten de cero necesitarán 12-24 meses para una adecuación completa antes del plazo de 2027.

¿Qué diferencia hay entre hacking ético y pentesting?

El hacking ético es una evaluación integral que combina varios vectores —OSINT, perímetro externo, red interna, escalada de privilegios— para simular una campaña de ataque completa contra tu organización. El pentesting es una prueba técnica con alcance acotado a un sistema o superficie concreta: una aplicación web, una API, una red. Si necesitas evaluar un sistema específico, contrata un pentesting; si quieres saber hasta dónde llegaría un atacante real en toda tu organización, el hacking ético es el servicio adecuado.

¿El hacking ético puede afectar a mis sistemas en producción?

El alcance se define con precisión antes de empezar. Por defecto evitamos acciones que puedan interrumpir el servicio (DoS, borrado de datos). Si algún test tiene riesgo potencial de impacto, lo acordamos contigo y lo ejecutamos en ventana de mantenimiento.

¿Necesito firmar algo antes de que empecéis?

Sí. Antes de cualquier actividad firmamos un acuerdo de alcance y un NDA. Esto protege tanto a tu organización como al equipo auditor y define exactamente qué está autorizado.

¿Cuánto cuesta un servicio de hacking ético?

Depende del alcance: tipo de análisis (externo, interno, o ambos), número de activos y profundidad de la prueba. Ofrecemos una primera llamada gratuita para dimensionar correctamente el proyecto y darte un presupuesto ajustado.

¿Trabajáis con empresas fuera de Valencia?

Sí. Tenemos clientes en toda España. El hacking ético externo se realiza completamente en remoto. Para el análisis interno puede requerirse presencia física o acceso VPN al entorno según el alcance acordado.

¿Qué pasa si encontráis algo crítico a mitad del trabajo?

Se comunica en el momento, no se espera al informe. Ante un hallazgo que permita comprometer datos o detener la operativa, avisamos a tu contacto técnico por el canal acordado el mismo día, con lo mínimo para que podáis contener el riesgo. El resto del ejercicio continúa después. Guardar una vulnerabilidad crítica dos semanas para que luzca mejor en el entregable no es una práctica defendible.

¿Qué diferencia hay entre el hacking ético externo y el interno?

El externo parte de lo que ve un atacante desde internet, sin credenciales: superficie expuesta, servicios accesibles y puntos de entrada. El interno parte de una posición ya dentro de la red —un empleado, un equipo comprometido o un proveedor— y mide hasta dónde se puede escalar desde ahí. Muchas empresas tienen el perímetro razonablemente cerrado y una red interna plana, y eso solo se ve haciendo el segundo.

¿Cuál es la diferencia entre vuestra solución para PYMEs y para startups?

Las PYMEs suelen priorizar la protección del negocio existente (pentesting, análisis de vulnerabilidades, NIS2) mientras que las startups suelen necesitar acreditar su seguridad frente a inversores o clientes enterprise (due diligence, compliance SOC2/ISO 27001, secure SDLC). Aunque los servicios se solapan, el enfoque y la documentación son diferentes.

¿Trabajáis con empresas muy pequeñas, de menos de 10 empleados?

Sí. Tenemos experiencia con microempresas y autónomos con necesidades específicas de seguridad, especialmente en sectores regulados como salud, legal o fintech. El alcance y el coste se adaptan al tamaño y a los activos críticos reales.

¿Podéis acompañarnos durante todo el proceso de certificación ISO 27001?

Sí. Ofrecemos acompañamiento completo: desde el gap analysis inicial hasta la preparación para la auditoría externa de certificación. También hacemos el seguimiento durante la fase de implementación de controles.

¿El pentesting SaaS requiere acceso al código fuente?

No necesariamente. El pentesting de caja negra o caja gris (sin acceso al código) ya detecta la mayoría de vulnerabilidades críticas en SaaS. Si nos das acceso al código fuente (caja blanca), combinamos el test de intrusión con revisión estática (SAST) para mayor cobertura.

¿Podemos hacer el pentesting sobre el entorno de staging?

Sí. Es la opción más habitual en SaaS: preparas un entorno de staging con datos representativos (no datos reales de clientes) y ejecutamos el pentesting ahí. Lo importante es que el entorno sea fiel a producción en configuración, infraestructura y lógica de negocio.

¿El pentesting SaaS cubre también la infraestructura cloud?

Puede incluirse como alcance adicional. El pentesting de aplicación SaaS cubre la capa de aplicación (web, API, lógica). Si necesitas también revisar la configuración de IAM, grupos de seguridad, S3 policies o Kubernetes, lo añadimos como un componente de pentesting cloud.

¿Cuánto tiempo dura un pentesting de una aplicación SaaS?

Entre 5 y 10 días hábiles para aplicaciones de complejidad media. La duración depende del número de endpoints, roles de usuario, integraciones y la profundidad acordada. Para SaaS con arquitectura de microservicios puede extenderse más.

¿El informe vale para presentar a clientes enterprise o inversores?

Sí. El informe ejecutivo está diseñado para ser presentado a dirección, clientes enterprise y en procesos de due diligence de inversión. Incluye resumen del alcance, metodología, hallazgos y estado de remediación.

¿Podéis integrarse con nuestra plataforma de bug bounty actual (HackerOne, Bugcrowd, Intigriti)?

Sí. Trabajamos sobre las plataformas existentes del cliente sin necesidad de cambiar de herramienta. También nos integramos con canales propios: formularios web, email securizado, Jira, GitHub Issues o cualquier sistema de ticketing. El cliente mantiene la visibilidad total de todo el proceso.

¿Cuál es el SLA de respuesta a un reporte crítico?

Para reportes clasificados como críticos, el tiempo máximo de primera respuesta es de 8 horas en días laborables y 24 horas en fin de semana. Para reportes de severidad alta, el SLA es de 24 horas en días laborables. Estos parámetros son configurables según las necesidades del programa.

¿Qué pasa si discrepamos con vuestra valoración de un reporte?

El cliente tiene siempre la última palabra. Si hay discrepancia en la valoración de un reporte, lo revisamos conjuntamente, aportamos la evidencia técnica que justifica nuestra posición y acordamos la clasificación final. Es un servicio colaborativo, no una caja negra.

¿Cómo garantizáis la confidencialidad de los reportes?

Firmamos un NDA específico para el servicio de triage antes de comenzar. Todos los reportes y sus contenidos son estrictamente confidenciales. El acceso a los reportes está restringido al equipo técnico asignado al cliente. Nunca compartimos información sobre vulnerabilidades de un cliente con terceros.

¿Cuánto cuesta el servicio de triage externo?

El coste depende del volumen estimado de reportes mensuales, el nivel de SLA requerido y si el servicio incluye comunicación con investigadores. Trabajamos con modelos de tarifa fija mensual por volumen de reportes. Es significativamente más económico que contratar un analista de triage interno, y mucho más flexible.

¿Podéis validar vulnerabilidades sin acceso a producción?

Depende del tipo de vulnerabilidad. Para muchos hallazgos (XSS, CSRF, lógica de negocio, fallos de autorización) podemos validar con credenciales de prueba en un entorno de staging. Para otros que requieren observar comportamiento en producción, acordamos contigo la ventana y el procedimiento seguro de validación.

¿Por qué CVSS 4.0 y EPSS y no solo la severidad del investigador?

La severidad que propone el investigador es una hipótesis. CVSS 4.0, publicado por FIRST en 2023, mide la gravedad técnica con métricas más granulares que la 3.1 y permite ajustar por entorno; EPSS estima la probabilidad de explotación en los próximos 30 días. Combinados con el impacto que comprobamos al reproducir el ataque, dan una prioridad defendible ante desarrollo y dirección. Si tu programa ya usa CVSS 3.1, trabajamos con ambas versiones en paralelo.

¿En qué se diferencia este servicio de contratar HackerOne o Bugcrowd?

HackerOne y Bugcrowd son plataformas: te dan acceso a una comunidad de investigadores y herramientas de gestión, pero tú sigues necesitando equipo interno para triagar y validar. Nosotros somos el equipo externo que hace ese trabajo. Podemos operar sobre las plataformas que ya tienes, o diseñar un programa independiente de ellas.

¿Podéis gestionar programas que ya están activos en otra plataforma?

Sí. Trabajamos sobre HackerOne, Bugcrowd, Intigriti y cualquier canal propio. No es necesario cambiar de plataforma ni de proceso. Simplemente añadimos la capa de triage y gestión que te falta.

¿Cuánto tiempo tarda en estar operativo el servicio?

El onboarding estándar lleva entre 5 y 10 días laborables: briefing técnico, configuración de accesos e integraciones, y definición de flujos de trabajo. Para programas más complejos o con múltiples integraciones, el plazo puede extenderse.

¿Cuánto presupuesto de recompensas hay que reservar para empezar?

Depende del alcance y de la criticidad que aceptes, pero el error más común no es quedarse corto de presupuesto sino abrir el programa sin una tabla de recompensas publicada. Sin ella, cada reporte se convierte en una negociación, los tiempos de respuesta se alargan y los investigadores buenos dejan de enviar. Se fija la tabla antes de abrir, se publica, y se revisa con datos del propio programa a los seis meses.

¿Qué pasa si recibimos más reportes de los que podemos gestionar?

Es el escenario habitual en las primeras semanas de un programa público, y por eso se recomienda empezar en privado con un grupo acotado de investigadores. El triage externo absorbe el volumen: valida, descarta duplicados y fuera de alcance, y a tu equipo solo le llega lo confirmado con impacto demostrado. Si el cuello de botella está en remediación y no en triage, el programa se amplía por fases en lugar de abrirlo entero.

¿Un bug bounty sustituye al pentesting?

No, cubren cosas distintas. El pentesting es un ejercicio acotado en alcance y tiempo, con cobertura garantizada de lo que se acordó y un informe entregable que sirve ante un cliente o un auditor. El bug bounty es continuo y sin cobertura garantizada: nadie asegura que alguien vaya a mirar tu módulo menos atractivo. Lo razonable es pentesting para la cobertura y la evidencia, y bug bounty para la vigilancia continua entre ejercicios.

¿Qué información necesito dar a los investigadores sobre quién gestiona el programa?

Tú decides el nivel de transparencia. Podemos operar en tu nombre sin que los investigadores sepan que hay un proveedor externo, o podemos mencionar que el triage lo realiza un equipo de seguridad externo especializado. Ambas modalidades son válidas y habituales en el mercado.

¿Podéis gestionar programas privados de bug bounty?

Sí. Gestionamos tanto programas públicos (accesibles a cualquier investigador) como privados (solo investigadores invitados). Los programas privados tienen dinámicas distintas y requieren una gestión de la comunidad de researchers más activa, algo que también cubrimos.

¿Qué pasa con los reportes duplicados o fuera de alcance?

Los cerramos nosotros con una respuesta argumentada al investigador, sin que lleguen a tu equipo. El duplicado se enlaza al reporte original y el fuera de alcance se explica citando las reglas publicadas del programa. Es la parte más ingrata de un bug bounty y la que más relaciones rompe si se gestiona con plantillas secas: un investigador mal respondido deja de reportar y lo cuenta.

¿Quién decide cuánto se paga por cada reporte?

Tú. Nosotros proponemos la recompensa aplicando la tabla acordada al inicio, según criticidad e impacto real demostrado, y tú apruebas. Lo que sí recomendamos es fijar esa tabla antes de abrir el programa y publicarla: negociar cada recompensa caso por caso genera disputas, alarga los tiempos de respuesta y acaba ahuyentando a los investigadores buenos.

¿NIS2 me obliga a tener un VDP?

NIS2 exige que las entidades esenciales e importantes tengan mecanismos para gestionar y reportar vulnerabilidades, lo que incluye disponer de un canal de notificación de vulnerabilidades. Aunque la directiva no usa explícitamente el término VDP, la práctica más extendida para cumplir con este requisito es implementar un Vulnerability Disclosure Program. Te ayudamos a evaluar exactamente qué necesita tu empresa.

¿Cuánto tiempo tarda en estar operativo el VDP?

El diseño e implementación estándar de un VDP lleva entre 2 y 4 semanas: redacción de política, configuración del canal, pruebas y publicación. Si necesitáis aceleración por un proceso de auditoría o cumplimiento normativo, podemos ajustar el timeline.

¿Qué pasa si recibimos una vulnerabilidad crítica?

Los reportes críticos tienen un canal de escalada inmediata. En cuanto identificamos que un reporte podría tener impacto crítico, lo escalamos directamente al responsable de seguridad del cliente —independientemente del horario— y coordinamos la respuesta de emergencia. El SLA para reportes críticos es de 4 horas en días laborables.

¿Podéis ayudarnos a coordinar la divulgación pública de una vulnerabilidad?

Sí. Si un investigador quiere publicar su hallazgo (CVE, blog post, conferencia), gestionamos el proceso de coordinated vulnerability disclosure (CVD) siguiendo el estándar ISO 29147: acordamos el timeline de divulgación, coordinamos con el investigador y preparamos las comunicaciones necesarias.

¿En qué se diferencia una auditoría de seguridad CMS de un mantenimiento web?

El mantenimiento web actualiza versiones y hace copias de seguridad. Una auditoría de seguridad CMS simula ataques reales para encontrar vulnerabilidades que las actualizaciones no corrigen: lógica de aplicación vulnerable, configuraciones incorrectas, extensiones con código inseguro o vectores específicos del CMS que los escáneres automáticos no detectan.

¿El pentesting interrumpe el funcionamiento de la web?

Coordinamos el alcance para minimizar el impacto operativo. En la mayoría de casos trabajamos sobre un entorno de staging o en franjas horarias de bajo tráfico. Si producción es imprescindible, acordamos las pruebas más invasivas fuera del horario comercial.

¿El pentesting CMS cubre también el hosting y el CDN?

Sí, dentro del alcance acordado. Revisamos la configuración del servidor web, headers de seguridad HTTP, acceso a rutas sensibles, permisos de ficheros y, si aplica, la configuración del WAF y CDN (Cloudflare, Fastly). El entorno de hosting forma parte de la superficie de ataque del CMS.

¿Hacéis también la remediación o solo el informe?

Entregamos el análisis, las evidencias y el plan de remediación. La corrección la ejecuta tu equipo o tu agencia web siguiendo nuestras instrucciones. Siempre incluimos soporte durante la fase de corrección y re-test opcional para verificar que los hallazgos han sido resueltos.

¿El informe sirve para auditorías de cumplimiento (ENS, ISO 27001, PCI-DSS)?

Sí. El informe sigue metodologías reconocidas (OWASP, PTES) y es válido como evidencia de pentesting para procesos de certificación ISO 27001, adecuación al ENS o cumplimiento PCI-DSS. Indicamos la cobertura frente a los controles de seguridad aplicables.

¿Necesitáis acceso de administrador a nuestro Workspace?

Para la revisión de configuración basta con un rol de administrador de solo lectura o un rol delegado con permisos de auditoría. Para las pruebas ofensivas acordamos previamente el alcance y, si procede, una cuenta de prueba. Todo se realiza con autorización explícita y bajo acuerdo de confidencialidad (NDA).

¿La auditoría interrumpe el trabajo de los empleados?

No. La mayor parte es análisis de configuración y de la superficie de ataque, que no afecta a los usuarios. Las pocas pruebas activas se acuerdan y se ejecutan de forma controlada para no impactar la operativa.

¿En qué se diferencia de las recomendaciones que ya muestra Google?

El panel de Google señala ajustes recomendados, pero no piensa como un atacante ni encadena vectores. Nosotros buscamos el camino real de compromiso: una app OAuth olvidada, una delegación de dominio peligrosa o una regla de reenvío que mantiene el acceso aunque cambies la contraseña.

¿Auditáis también Microsoft 365?

Sí. Aplicamos la misma metodología ofensiva al entorno de Microsoft 365 (Entra ID, Exchange Online, SharePoint). Si trabajáis con ambos, auditamos los dos entornos y sus puntos de integración.

¿El informe sirve para cumplimiento (ENS, ISO 27001, NIS2)?

Sí. El informe documenta el estado de seguridad del entorno de correo y colaboración frente a marcos reconocidos (CIS Benchmark) y es válido como evidencia para procesos de adecuación al ENS, certificación ISO 27001 o cumplimiento de NIS2.

¿Necesitáis acceso de administrador a nuestro tenant?

Para la revisión de configuración basta con un rol de solo lectura (Global Reader) o un rol delegado con permisos de auditoría. Para las pruebas ofensivas acordamos previamente el alcance y, si procede, una cuenta de prueba. Todo se realiza con autorización explícita y bajo acuerdo de confidencialidad (NDA).

¿En qué se diferencia del Secure Score de Microsoft?

El Secure Score señala ajustes recomendados, pero no piensa como un atacante ni encadena vectores. Nosotros buscamos el camino real de compromiso: una app con consentimiento ilícito, un hueco en el acceso condicional o una regla de reenvío que mantiene el acceso aunque cambies la contraseña.

¿Auditáis también Google Workspace?

Sí. Aplicamos la misma metodología ofensiva a Google Workspace. Si trabajáis con ambos, auditamos los dos entornos y sus puntos de integración.

¿En qué se diferencia exactamente un Red Team de un pentesting de Active Directory?

Un pentesting de Active Directory analiza el entorno AD en profundidad con un alcance técnico conocido, buscando el máximo de vulnerabilidades de configuración y escalada de privilegios. Un Red Team parte de fuera del perímetro, con un objetivo de negocio concreto, sin que el equipo defensivo lo sepa, y solo entra en AD si ese es el camino más realista hacia el objetivo — es una prueba de la organización completa, no del entorno AD en sí.

¿Es lo mismo que el TLPT que exige DORA?

El TLPT es un Red Team ejecutado bajo el marco regulatorio TIBER-EU, con proveedores acreditados específicamente y coordinación con el supervisor, obligatorio para entidades financieras designadas como críticas. Nuestro Red Team estándar sigue la misma lógica metodológica y es la preparación ideal antes de un TLPT formal; para el TLPT regulatorio en sí, te orientamos sobre el proceso de acreditación necesario.

¿Qué pasa si el equipo defensivo nos detecta el primer día?

Es un resultado válido y valioso — significa que vuestras defensas funcionan para ese vector. En ese caso, con vuestro consentimiento, podemos ajustar el ejercicio para seguir probando otros vectores o técnicas de evasión más avanzadas, maximizando el aprendizaje del ejercicio.

¿Incluye ingeniería social presencial y acceso físico?

Solo si se acuerda explícitamente en el alcance. No es un componente por defecto: algunas organizaciones lo incluyen (tailgating, dispositivos USB, suplantación de personal técnico) y otras prefieren limitarlo a vectores digitales. Se define en la fase de reglas de intervención.

¿En qué se diferencia de una simulación de phishing (ingeniería social)?

Una simulación de phishing evalúa un único vector —el humano— de forma aislada y con un alcance conocido de antemano por quien la contrata. Un Red Team puede usar el phishing como uno de varios vectores de entrada, pero solo si sirve para alcanzar el objetivo de negocio definido, combinado con explotación técnica y movimiento lateral; no es un fin en sí mismo ni se mide de forma independiente.

¿Es lo mismo que una revisión de segregación de funciones (SoD) para auditoría interna?

No. Una revisión de SoD para auditoría interna o compliance confirma que existe una matriz documentada y que, sobre el papel, no hay combinaciones prohibidas asignadas. Nuestra auditoría va más allá: confirma qué de eso es explotable de verdad, añade el análisis de la interfaz RFC/Gateway, el código ABAP personalizado y el estado de parcheo, y simula el impacto real de un atacante, no solo el riesgo teórico documentado.

¿Necesitáis acceso al sistema productivo?

Para la revisión de configuración y autorizaciones basta con un usuario de solo consulta o acceso al sistema de pre-producción con la misma configuración. Para las pruebas ofensivas activas acordamos previamente el alcance, el entorno (habitualmente pre-producción) y, si procede, una cuenta de prueba. Todo se realiza con autorización explícita y bajo acuerdo de confidencialidad (NDA).

¿Cubrís tanto SAP on-premise como S/4HANA Cloud?

Sí, adaptando el alcance: en on-premise y S/4HANA Private Cloud el análisis incluye la capa de infraestructura, el Gateway y el sistema operativo subyacente; en S/4HANA Public Cloud el alcance se centra en autorizaciones, integraciones y configuración, ya que SAP gestiona directamente parte de la infraestructura.

¿La auditoría interrumpe la operativa del ERP?

No. La mayor parte del trabajo es análisis de configuración, roles y código, que no afecta a los usuarios. Las pruebas activas se acuerdan previamente, se ejecutan preferentemente en un entorno de pre-producción y, si deben tocar producción, en una ventana pactada con el equipo Basis.

¿El informe sirve para cumplimiento normativo (NIS2, ENS, ISO 27001)?

Sí. El informe documenta el estado de seguridad del entorno SAP con evidencias y es válido como parte de la documentación de adecuación a NIS2, certificación ISO 27001 o adecuación al Esquema Nacional de Seguridad (ENS) para los sistemas dentro de su alcance.

¿A quién aplica el AI Act?

Aplica a proveedores que desarrollan sistemas de IA, a "deployers" que los usan dentro de su organización, y a importadores y distribuidores, dentro y fuera de la UE si el sistema se usa en territorio europeo. Aplica independientemente del tamaño de la empresa.

Soy autónomo y uso herramientas de IA de terceros, ¿tengo obligaciones?

Sí, como "deployer" tienes obligaciones aunque no hayas desarrollado el sistema: informar a las personas afectadas cuando corresponda, supervisión humana en sistemas de alto riesgo, y no usar sistemas de IA prohibidos (como el scoring social).

¿Cuánto tiempo tengo para adaptarme?

El calendario es progresivo: las prácticas de IA prohibidas ya son ilegales desde febrero de 2025; las obligaciones de gobernanza y modelos de propósito general aplican desde agosto de 2025; las obligaciones de los sistemas de alto riesgo del Anexo III aplican desde agosto de 2026.

¿Qué sanciones impone el AI Act?

Hasta 35M€ o el 7% de la facturación global anual por usar prácticas de IA prohibidas; hasta 15M€ o el 3% por incumplir otras obligaciones del reglamento; hasta 7,5M€ o el 1% por proporcionar información incorrecta a las autoridades.

¿El AI Act sustituye al RGPD?

No, son complementarios. El AI Act regula específicamente los sistemas de inteligencia artificial y su nivel de riesgo; el RGPD sigue aplicando a cualquier tratamiento de datos personales que ese sistema realice.

¿Cómo sé en qué nivel de riesgo cae mi sistema de IA?

Por el uso, no por la tecnología. El AI Act clasifica según para qué se emplea el sistema: hay prácticas prohibidas, sistemas de alto riesgo listados en el anexo III —biometría, empleo, crédito, educación, servicios esenciales—, sistemas con obligaciones de transparencia como los chatbots y los generadores de contenido, y el resto con riesgo mínimo. El mismo modelo puede caer en dos niveles distintos según la finalidad, así que la clasificación se hace por caso de uso.

¿Qué relación tiene el AI Act con la seguridad de mis sistemas de IA?

Para los sistemas de alto riesgo, el artículo 15 exige un nivel adecuado de precisión, robustez y ciberseguridad, incluida resistencia frente a intentos de alterar su uso o su comportamiento mediante explotación de vulnerabilidades. Eso se traduce en pruebas concretas: inyección de prompts, envenenamiento de datos, evasión del modelo y extracción de información. Es exactamente el alcance de un pentesting de sistemas de IA, y la evidencia de haberlo hecho forma parte de la documentación técnica que la norma pide.

¿Esto sustituye a la auditoría general de Microsoft 365?

No necesariamente. Si el correo es tu sistema más crítico o ya has tenido un incidente relacionado con email, tiene sentido contratarla como pieza independiente. Si quieres una revisión completa del tenant (Entra ID, SharePoint, Teams, apps OAuth), la auditoría de Microsoft 365 es más adecuada.

¿Necesitáis acceso de administrador global?

No. Con un rol de lectura sobre Exchange Online (por ejemplo, Exchange Recipient Administrator) es suficiente para la mayor parte del análisis.

¿Interrumpe el funcionamiento del correo?

No. El análisis es de configuración y permisos, y no afecta al flujo de correo en producción.

¿Podéis detectar si ya hay un compromiso en curso?

El análisis de reglas de reenvío y permisos delegados puede revelar la persistencia de un atacante que ya comprometió una cuenta, aunque este no es un servicio de respuesta a incidentes.

¿Sirve el informe para cumplimiento normativo?

Sí. El informe es válido como evidencia de control técnico sobre la seguridad del correo corporativo para NIS2, ENS o ISO 27001.

¿En qué se diferencia del Secure Score o de las alertas de Microsoft Defender?

El Secure Score puntúa ajustes recomendados y Defender alerta sobre actividad sospechosa, pero ninguno revisa buzón a buzón quién tiene permisos delegados, qué reglas de reenvío existen ni si un conector permite enviar correo suplantando tu dominio. Nosotros comprobamos qué podría hacer un atacante con un buzón comprometido, no solo qué casillas faltan.

¿Y si todavía tenemos Exchange Server on-premise o un entorno híbrido?

La auditoría se centra en Exchange Online. En un entorno híbrido revisamos también los conectores y la configuración híbrida del lado de Microsoft 365, que es por donde suele colarse el correo sin filtrar. La exposición de un Exchange Server on-premise a Internet (OWA, ECP, nivel de parches) se cubre mejor con un pentesting de red e infraestructura externa.

¿Esto me sirve para cumplir el AI Act?

Es su prerrequisito operativo, no la adecuación legal completa. Sin saber qué sistemas de IA usa tu organización y para qué, no puedes clasificarlos por nivel de riesgo ni demostrar supervisión humana ante nadie. Este servicio te da ese inventario y ese control. La adecuación formal al reglamento —clasificación, rol de proveedor o deployer, documentación técnica— es nuestro servicio de consultoría AI Act, y se apoya en el trabajo que se hace aquí.

¿Cuánto tarda y qué implicación pide a mi equipo?

El diagnóstico y la política están en unas tres semanas para una organización de tamaño medio. La carga para tu equipo se concentra en el descubrimiento: accesos de solo lectura para revisar aplicaciones conectadas, y unos minutos de cada persona para la encuesta anónima. La formación son sesiones de entre 45 y 90 minutos según el perfil.

¿Vais a prohibirnos las herramientas que ya usamos?

No es el objetivo. En la mayoría de casos el resultado es lo contrario: se aprueban formalmente las herramientas que ya se usaban, se corrigen sus ajustes de retención y entrenamiento, y se acota únicamente el tipo de dato que no debe entrar. Prohibir sin ofrecer alternativa desplaza el uso al móvil personal y empeora la visibilidad.

¿Sirve si somos una empresa pequeña sin equipo de IT?

Sí, y suele ser más rápido. En una organización pequeña el inventario se cierra en días y la política cabe en una página. Lo que no cambia con el tamaño es el riesgo: pegar un contrato de cliente en un chatbot público tiene el mismo impacto en una empresa de ocho personas que en una de ochocientas.

¿En qué se diferencia esto de auditar la seguridad de nuestro propio sistema de IA?

Son cosas distintas. Este servicio gobierna el uso de herramientas de IA de terceros por parte de tu equipo. Si lo que tienes es un producto propio con un modelo, un chatbot de cara al cliente o un pipeline RAG, lo que necesitas es un pentesting de inteligencia artificial, que ataca ese sistema para encontrar sus vulnerabilidades. Muchas empresas acaban necesitando ambos, pero resuelven problemas diferentes.

¿Cuánto cuesta formar a un equipo en ciberseguridad?

Depende del programa y del número de sesiones. Una sesión de concienciación para empleados, online y de unos 90 minutos, parte de un precio cerrado por grupo. Un programa técnico con varias sesiones y prácticas sobre vuestro propio código, o una sesión para dirección, se presupuestan por proyecto o por sesión. Damos precio cerrado antes de empezar, y la primera llamada para acotar el alcance no tiene coste.

¿La formación sirve como evidencia para NIS2, DORA o el ENS?

Sí, y es una de las razones habituales para contratarla. NIS2 exige en su artículo 20 formación en ciberseguridad para los órganos de dirección, DORA exige algo equivalente para el sector financiero, y el ENS incluye la concienciación y formación del personal entre sus medidas. Entregamos registro de asistencia, contenidos impartidos y evaluación en el formato que un auditor espera, que es lo que realmente se pide en la revisión.

¿Podéis formar a nuestro equipo sobre el uso de la inteligencia artificial?

Sí, es un programa propio con tres itinerarios —dirección, equipos técnicos y plantilla— y prácticas sobre 0data, nuestra plataforma de IA privada: qué se puede pegar en ChatGPT, Copilot u otros asistentes, cómo se ataca una aplicación con IA y cómo se controla. La formación se contrata sola. Si además necesitáis descubrir qué herramientas de IA usa realmente el equipo y redactar la política de uso, eso es un proyecto más amplio que ofrecemos desde el servicio de uso seguro de IA.

¿La formación es presencial u online?

Depende del programa. Las sesiones de concienciación y las de dirección funcionan bien en remoto y permiten grupos más grandes. Las de equipos técnicos y los talleres normativos rinden más en presencial, porque incluyen práctica y trabajo en grupo. Tenemos base en Valencia y nos desplazamos al resto de España según el proyecto.

¿Sirve este informe si el pliego no exige ENS ni ISO 27001?

Sí, es exactamente el caso que cubre este servicio. Muchos pliegos piden un informe de auditoría de ciberseguridad —pentest y revisión RGPD— sin exigir una certificación formal. Si tu pliego sí exige ENS o ISO 27001, necesitas ese proceso de certificación: consulta nuestro servicio de auditoría y adecuación al ENS.

¿Cuánto tarda el informe?

Entre 5 y 10 días hábiles desde el inicio, según la complejidad del sistema y el número de integraciones a revisar. Si el plazo del expediente es más corto, dínoslo en la llamada de alcance: priorizamos proyectos con fecha límite conocida.

¿Podemos empezar antes de que se resuelva la licitación?

Sí, es lo recomendable. Si acordáis proveedor y alcance con antelación, el informe puede estar listo antes de la adjudicación, y solo queda presentarlo cuando llegue el plazo de subsanación.

¿Qué pasa si el pliego exige ENS, ISO 27001 o un certificado específico de INCIBE?

Este servicio no sustituye una certificación formal. Si el pliego exige ENS o ISO 27001 necesitas ese proceso con una entidad acreditada; podemos ayudarte con la fase de adecuación previa. Consulta cumplimiento ENS o cumplimiento ISO 27001 según lo que pida tu pliego.

¿Cubre sistemas de terceros como pasarelas de pago o dispositivos IoT conectados a la plataforma?

Sí, siempre que formen parte del sistema ofertado. No auditamos la infraestructura del proveedor de pagos o del fabricante del dispositivo directamente, pero sí revisamos cómo se integra con tu plataforma y qué datos se intercambian.

¿Puede presentar este informe una empresa que actúa como socio local de un proveedor extranjero?

Sí. Es un caso habitual: una empresa de software extranjera colabora con un socio español que licita, y el informe se emite sobre el sistema técnico ofertado con independencia de dónde esté domiciliada la empresa que lo desarrolla.

¿Esto sustituye a tener un Delegado de Protección de Datos (DPD/DPO)?

No necesariamente. Si tu empresa está obligada a tener DPD, esta auditoría es complementaria: evalúa el estado real del cumplimiento y el DPD puede apoyarse en el informe para priorizar su trabajo. Si no tienes DPD, la auditoría te da una fotografía independiente sin necesidad de contratar esa figura de forma permanente.

¿Necesito esta auditoría si ya tengo la política de privacidad de mi web hecha por un abogado?

La política de privacidad es el documento de cara al usuario; no acredita que los tratamientos internos, los contratos con proveedores o las medidas técnicas estén realmente en regla. Es habitual encontrar empresas con una política de privacidad impecable y sin un Registro de Actividades de Tratamiento real detrás.

¿Cuánto dura el proceso?

Entre 2 y 4 semanas para una empresa mediana, según el número de tratamientos y proveedores a revisar. Para alcances acotados a un único producto o sistema puede ser más rápido.

¿El informe sirve para presentarlo en una licitación pública?

Sí, si el pliego pide una revisión de cumplimiento RGPD como parte de la documentación acreditativa. Si además exige un test de intrusión sobre el sistema ofertado, consulta nuestro servicio de auditoría para licitaciones públicas, que combina ambos en un único informe con plazos exprés.

¿Auditáis también el cumplimiento de proveedores externos (cloud, SaaS de terceros)?

Revisamos los contratos y DPA firmados con ellos y cómo fluyen los datos hacia esos proveedores, pero no auditamos la infraestructura interna del proveedor, salvo que forme parte de un pentest contratado aparte.

¿Qué pasa si encontráis un incumplimiento grave?

Lo clasificamos por riesgo real, no solo formal, y te damos una hoja de ruta priorizada. La decisión de cómo y cuándo remediarlo es tuya; podemos acompañar la implementación si lo necesitas.

Qué diferencia hay entre un TLPT y un pentesting

Un pentesting busca vulnerabilidades en un alcance acotado y normalmente con el equipo defensivo informado. El TLPT parte de inteligencia de amenazas real sobre tu entidad, se ejecuta en producción sobre funciones críticas y mantiene al equipo defensivo sin previo aviso, porque lo que mide es la capacidad de detección y respuesta, no solo la existencia de fallos.

Todas las entidades financieras tienen que hacer TLPT

No. DORA exige un programa de pruebas de resiliencia a todas las entidades de su ámbito, pero las pruebas avanzadas tipo TLPT se aplican a las que designa su autoridad competente en función de criterios como tamaño, perfil de riesgo y relevancia. Si tu entidad no está designada, sigue obligada al resto del programa de pruebas.

Cada cuánto hay que repetir un TLPT

DORA plantea una periodicidad mínima de tres años para las entidades sujetas, sin perjuicio de lo que determine la autoridad competente. Conviene planificarlo con antelación: el ciclo completo, con inteligencia previa y remediación posterior, se extiende varios meses.

Qué es TIBER-ES y quién lo supervisa en España

TIBER-ES es la implementación española de TIBER-EU, coordinada por el Banco de España junto con la CNMV y la DGSFP según el tipo de entidad. Es el marco bajo el que se articulan en España las pruebas avanzadas dirigidas por inteligencia de amenazas que exige DORA, y documentar el ejercicio conforme a él es lo que facilita su reconocimiento por el supervisor.

Qué relación tiene el TLPT con TIBER-EU

TIBER-EU es el marco del Banco Central Europeo para pruebas dirigidas por inteligencia de amenazas y es la referencia metodológica sobre la que se apoya el TLPT de DORA. Documentar el ejercicio conforme a TIBER-EU facilita su presentación ante el supervisor.

Puede ejecutarlo el mismo equipo que hace nuestras auditorías habituales

DORA exige que los proveedores de pruebas avanzadas acrediten independencia, reputación y capacidad técnica. Conviene revisar posibles conflictos con quien ya presta servicios recurrentes a la entidad antes de adjudicar el ejercicio.

Cuánto dura un ejercicio TLPT completo

Depende del alcance, pero un TLPT con su fase de inteligencia, ejecución, cierre y remediación rara vez baja de tres meses. Las entidades que lo abordan con el plazo encima acaban recortando alcance, que es justo lo que el supervisor examina.

¿Cuánto cuesta la sesión?

Una sesión de 2-3 horas para el consejo o comité de dirección, presencial u online, parte de un precio cerrado por sesión. Se ajusta según el número de asistentes y si se combina con material de resumen ejecutivo adicional. La primera llamada para acotar el alcance no tiene coste.

¿Esto sirve como evidencia para NIS2 o DORA?

Sí. NIS2 exige en su artículo 20 formación en gestión de riesgos de ciberseguridad para los órganos de dirección, y DORA exige algo equivalente para el órgano de gestión de entidades financieras. Entregamos registro de asistencia y contenidos en el formato que un auditor espera encontrar en la revisión.

¿Es lo mismo que el gap analysis de cumplimiento normativo?

No. El gap analysis de NIS2 o DORA evalúa si tus controles cumplen la normativa; esta sesión forma al órgano de dirección para que entienda el riesgo y su responsabilidad. Son servicios complementarios: la formación suele encajar bien al inicio de un proyecto de adecuación normativa o justo antes de una auditoría.

¿Puede asistir también el equipo técnico?

La sesión está pensada para dirección, pero puede abrirse a mandos intermedios si el objetivo es alinear criterios antes de decidir presupuesto. Si lo que necesitas es formar al equipo técnico en profundidad, esa es una sesión distinta — consulta la formación técnica.

¿Cuánto cuesta la formación técnica?

Un programa de desarrollo seguro con varias sesiones y prácticas sobre vuestro propio código se presupuesta por proyecto, según número de sesiones y tamaño del equipo. Damos precio cerrado antes de empezar, y la primera llamada para acotar el alcance no tiene coste.

¿Necesitáis acceso a nuestro código para preparar la formación?

No es obligatorio, pero mejora mucho el resultado. Si venís de un pentesting o auditoría de código con nosotros, ya tenemos los hallazgos; si no, trabajamos con fragmentos anonimizados que nos facilitéis o con ejemplos del mismo lenguaje y framework que usáis.

¿Es lo mismo que una auditoría de código fuente?

No. La auditoría de código busca y reporta vulnerabilidades concretas en vuestro producto; esta formación enseña al equipo a no cometerlas en el futuro, a menudo usando los hallazgos de una auditoría previa como material didáctico. Lo habitual es encadenar ambas: auditar primero, formar después sobre lo encontrado.

¿Formáis también en detección, no solo en desarrollo seguro?

Sí, es un programa distinto dentro de esta misma formación técnica: enseñamos a equipos de defensa qué señales deja un atacante en logs, tráfico de red y comportamiento de endpoints, basándonos en las técnicas que usamos nosotros mismos en pentesting y red team.

¿Cuánto cuesta una sesión de concienciación?

Una sesión online de unos 90 minutos parte de un precio cerrado por grupo, con descuento por volumen si son varias sesiones para distintos departamentos. Damos precio cerrado antes de empezar, y la primera llamada para acotar el alcance no tiene coste.

¿Hacéis simulaciones de phishing dentro de esta formación?

La simulación de phishing es un servicio distinto: es un ejercicio ofensivo que mide comportamiento real, no una clase. Los dos se complementan bien —lo habitual es simular primero para saber dónde está el problema, y formar después sobre los resultados—, pero se contratan por separado. Si lo que buscas es medir, empieza por las simulaciones de phishing.

¿Esto sirve como evidencia para el ENS?

Sí. El ENS incluye la concienciación y formación del personal entre sus medidas (op.per.4), y es una de las razones habituales para contratar esta sesión. Entregamos registro de asistencia, contenidos impartidos y evaluación en el formato que un auditor espera encontrar en la revisión.

¿La sesión es presencial u online?

Ambas funcionan bien para concienciación; online permite grupos más grandes y varias sesiones cortas en vez de una única jornada. Tenemos base en Valencia y nos desplazamos al resto de España si el proyecto lo pide.

¿Tengo que contratar 0data para hacer la formación?

No. La formación se contrata sola y sirve igual si usáis ChatGPT, Copilot o Gemini. 0data es el entorno de prácticas porque permite ver los riesgos y los controles funcionando de verdad. Si después os encaja, la forma de empezar es un piloto de seis semanas a precio cerrado.

¿Las prácticas usan nuestros datos?

No hace falta. Por defecto trabajamos con datos sintéticos en nuestro laboratorio de 0data. Si ya tenéis 0data instalado o queréis probarlo en casa, las prácticas se hacen en vuestra instalación y los datos no salen de vuestra infraestructura.

¿Esto es lo mismo que el servicio de uso seguro de IA?

No. El servicio de uso seguro de IA es el proyecto de gobernanza completo: descubrir qué herramientas usa realmente el equipo (shadow AI), redactar la política de uso y formar sobre ella. Esta página es solo la formación, por itinerarios, y se puede contratar sin el resto.

¿Cuánto cuesta?

Precio cerrado por sesión o por taller, según el itinerario, el número de asistentes y si es presencial u online. Os lo damos después de una primera llamada para acotar el alcance, que no tiene coste.

¿Necesitamos tener ya una política de uso de IA?

No es obligatorio. Si existe, la formación se construye sobre ella; si no, damos las reglas básicas —qué no se pega nunca, qué herramientas están aprobadas— sin esperar a tener el documento redactado.

¿En qué se diferencia de la formación para equipos técnicos o para directivos?

Esas formaciones cubren la ciberseguridad en general: desarrollo seguro y defensa, o riesgo y responsabilidad del consejo. Esta se centra solo en la IA: cómo usarla, cómo atacarla y cómo controlarla, con prácticas sobre una plataforma real.

¿Es lo mismo que el servicio de cumplimiento normativo?

No, son complementarios. El servicio de cumplimiento hace el gap analysis, redacta la documentación y acompaña el proyecto completo de principio a fin. El taller es una sesión de trabajo puntual: parte de ese gap analysis, o de la normativa si no lo tenéis, y deja al equipo con un plan asignado. Muchos clientes contratan el taller como punto de partida antes de decidir si necesitan el proyecto completo.

¿Es lo mismo que la sesión para dirección?

No. La sesión para dirección y comités es una charla de 2-3 horas sobre riesgo y responsabilidad legal, pensada para quien decide presupuesto. El taller normativo es una sesión de trabajo más larga y técnica, pensada para quien tiene que implementar los controles día a día.

¿Cuánto dura y cuánto cuesta?

Lo habitual es medio día o una jornada completa, según cuántos artículos o controles se trabajen. Se presupuesta por sesión, con precio cerrado antes de empezar. La primera llamada para acotar el alcance no tiene coste.

¿Podéis cubrir varias normativas en el mismo taller?

Sí, cuando comparten controles —NIS2, DORA e ISO 27001 se solapan bastante en gestión de riesgos y de incidentes—, trabajarlas juntas en el mismo taller ahorra tiempo frente a repetir la sesión por cada norma.

¿Nos aplica la NIS2 española si el grupo ya cumple NIS2 en otro país de la UE?

Como regla general, sí: la NIS2 se aplica en el Estado miembro donde la entidad está establecida, así que una filial española responde ante la normativa y las autoridades españolas aunque la matriz cumpla en otro país. Hay excepciones: los proveedores de DNS, cloud, centros de datos, redes de distribución de contenidos, servicios gestionados y servicios de seguridad gestionados, y ciertas plataformas digitales, quedan bajo el Estado miembro de su establecimiento principal en la UE. Lo analizamos caso por caso en el mapa de aplicabilidad.

¿En qué punto está la ley española que transpone NIS2?

El Consejo de Ministros aprobó el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad en enero de 2025, pero a octubre de 2026 no se ha publicado en el BOE, y la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE en julio de 2026. Mientras tanto sigue vigente el Real Decreto-ley 12/2018. El detalle de obligaciones y sanciones está en nuestra página de consultoría NIS2.

¿Necesitamos la certificación ENS si solo somos proveedores de una administración española?

Si prestas servicios o soluciones a una entidad del sector público español, el Real Decreto 311/2022 se extiende a tus sistemas y los pliegos suelen exigir la conformidad. En categoría MEDIA o ALTA se acredita con una auditoría de certificación realizada por una entidad de certificación acreditada (en España, por ENAC); en categoría BÁSICA basta una autoevaluación. Una certificación ISO 27001 del grupo ayuda, pero no sustituye al ENS.

¿Nuestra autoridad de protección de datos es la AEPD o la del país de la matriz?

Depende de dónde esté el establecimiento principal del grupo en la UE. Si está en otro Estado miembro, la autoridad de ese país puede actuar como autoridad principal para los tratamientos transfronterizos (ventanilla única del RGPD), pero la AEPD sigue siendo competente en los asuntos locales y la LOPDGDD añade requisitos propios de España. Si el grupo no tiene establecimiento principal en la UE, no hay ventanilla única y la filial española trata directamente con la AEPD.

¿Cómo encaja DORA si los servicios TIC nos los presta la matriz?

DORA se aplica directamente a las entidades financieras de la UE desde el 17 de enero de 2025, sin ley de transposición. Los servicios TIC que presta otra empresa del mismo grupo también entran en la gestión del riesgo de terceros proveedores TIC del reglamento, así que el centro de servicios del grupo debe figurar en el registro de información y en los contratos. En España la supervisión corresponde al Banco de España, la CNMV o la DGSFP según el tipo de entidad.

¿Trabajáis en inglés?

Sí. Las reuniones, los informes técnicos y los resúmenes ejecutivos pueden ser en inglés para el equipo de seguridad del grupo, y la documentación que se presenta en España (pliegos, auditores, autoridades) se entrega en español. Así el mismo trabajo sirve a la matriz y a la filial sin traducciones posteriores.

¿Podemos contratar solo una parte, por ejemplo el pentest o el ENS?

Sí. El servicio está pensado para que un solo proveedor cubra varios marcos, pero cada pieza se puede contratar por separado. Si ya sabéis que solo necesitáis el ENS o la NIS2, es más directo empezar por esas páginas o por la ficha de alcance del ENS.

¿Qué comisión o descuento ofrece el programa?

No hay una tabla única. Las condiciones económicas se acuerdan a medida según el modelo (derivación, marca blanca o venta conjunta), el tipo de proyectos y el volumen previsto, y quedan por escrito en el acuerdo de colaboración antes del primer proyecto.

¿Quién mantiene la relación con el cliente?

Se acuerda por escrito en cada modelo. En marca blanca, la relación es tuya y no contactamos al cliente final por nuestra cuenta. En derivación y venta conjunta, cada uno mantiene la parte que le corresponde. Lo importante es que quede definido antes de empezar, no a mitad de proyecto.

¿Y si vuestro cliente final nos contacta directamente después?

Es una de las cosas que se dejan escritas en el acuerdo de colaboración, precisamente para que no haya que improvisar. En marca blanca, cualquier petición nueva del cliente final se canaliza a través de ti según lo pactado.

¿Los informes pueden ir con nuestra marca?

Sí, en el modelo de marca blanca, cuando el proyecto lo permite. Hay casos en los que el cliente final o un tercero (una aseguradora, un auditor, un pliego) exige que conste quién ha ejecutado las pruebas; si es así, lo indicamos desde la propuesta.

¿Cuánto se tarda en tener una propuesta para un cliente?

Con el alcance claro, la propuesta con alcance, metodología, plazos y precio llega en 24-48 horas tras la llamada de alcance. Para recoger los datos con tu cliente puedes usar nuestras fichas de alcance interactivas.

¿Qué requisitos hay para entrar en el programa?

Lo vemos en la primera conversación: qué clientes tienes, qué te piden y qué modelo encaja. No hay un formulario de alta cerrado; las condiciones, incluido cualquier compromiso por ambas partes, se fijan a medida en el acuerdo de colaboración.

¿Qué pasa si el pentest encuentra fallos en algo que mantenemos nosotros?

Es frecuente cuando el partner es la agencia o el MSP del cliente, y es justo el valor de una revisión independiente. Se acuerda desde el principio cómo se comunica: lo habitual es que tu equipo conozca los hallazgos a tiempo para corregirlos, y el retest documenta que quedaron resueltos.

¿Cómo se protege la información de nuestros clientes?

Firmamos un NDA antes de recibir cualquier información, trabajamos solo sobre el alcance autorizado por escrito por el cliente final y, si el proyecto implica tratar datos personales, se formaliza el correspondiente contrato de encargado del tratamiento conforme al RGPD.

¿Una correduría puede usar el informe en la suscripción de un ciberseguro?

El informe de pentesting documenta qué se probó, qué se encontró y qué se corrigió, que es la evidencia técnica que suelen pedir los cuestionarios de suscripción. Si la aseguradora pide algo concreto, se ajusta el alcance desde la propuesta. La decisión de suscripción es siempre de la aseguradora.

¿Qué pasa si el cliente necesita algo que no hacéis?

Somos especialistas en seguridad ofensiva y cumplimiento; no hacemos desarrollo web, administración de sistemas del día a día ni mediación de seguros. El programa está pensado para complementar lo que ya ofreces, no para sustituirlo: cada uno cubre su parte.

¿Qué es un seguro de ciberriesgo?

Es una póliza que cubre las consecuencias económicas de un ciberataque o de una brecha de datos: los daños propios de la empresa y su responsabilidad frente a terceros. Ciberseguro, seguro de ciberseguridad, seguro cyber y póliza de ciberriesgos son nombres distintos para el mismo tipo de producto. No evita el ataque: complementa a las medidas de seguridad, no las sustituye.

¿Qué cubre un seguro de ciberriesgo?

Depende de cada póliza, pero suele agrupar tres bloques. Daños propios: respuesta al incidente y análisis forense, recuperación de datos y sistemas, pérdida de beneficios por la paralización, gestión de crisis y notificación a los afectados, y en algunas pólizas la extorsión por ransomware. Responsabilidad frente a terceros: reclamaciones de clientes o empleados por sus datos y la defensa jurídica, incluida a veces la defensa en procedimientos sancionadores de protección de datos. Y fraude: el fraude del CEO o la suplantación de proveedores, a menudo con un sublímite propio o como ampliación.

¿Qué no suele cubrir?

Las exclusiones varían, pero las más habituales son los incidentes anteriores a la póliza o ya conocidos al contratarla, los daños causados de forma deliberada, los ataques atribuidos a un Estado o en contexto de guerra según la redacción de cada condicionado, la mejora de los sistemas tras el incidente y los siniestros en los que un control declarado no estaba implantado. Merece la pena leer las exclusiones antes que las coberturas.

¿Cuánto cuesta un seguro de ciberriesgo?

Las tarifas que publican aseguradoras y corredurías en España van desde unos cientos de euros al año para autónomos y microempresas hasta varios miles para una pyme mediana, y suben mucho más en empresas grandes o sectores regulados. La cifra real sale del cuestionario: facturación, sector, volumen de datos personales, capital asegurado, franquicia, historial de incidentes y, sobre todo, los controles de seguridad que puedas acreditar.

¿Qué requisitos piden las aseguradoras para emitir la póliza?

Los cuestionarios se repiten mucho: MFA en el correo, en los accesos remotos y en las cuentas de administración; copias de seguridad aisladas o inmutables con la restauración probada; EDR en los equipos; parcheo de las vulnerabilidades críticas en plazos cortos; ningún escritorio remoto expuesto a Internet; formación contra el phishing y un plan de respuesta a incidentes. Sin MFA, muchas aseguradoras ni siquiera cotizan.

¿Es obligatorio tener un seguro de ciberriesgo en España?

No existe una obligación legal general. Ni NIS2, ni DORA, ni el RGPD obligan a contratarlo. En la práctica sí puede ser obligatorio por contrato: cada vez más clientes grandes, licitaciones y proveedores de servicios críticos lo piden a sus proveedores como condición.

¿Cuál es el mejor seguro de ciberriesgo para mi empresa?

No hay uno mejor en abstracto: depende de tu riesgo. Al comparar ofertas importan menos el precio y el capital total que los sublímites (ransomware, fraude, pérdida de beneficios), la franquicia, el periodo de espera antes de indemnizar la paralización, el servicio de respuesta 24/7 y su panel de proveedores, la retroactividad y las exclusiones. La comparación y la recomendación de la póliza las hace la correduría; nosotros te ayudamos a llegar con tu situación técnica clara para que esa comparación sea real.

¿El seguro paga el rescate de un ransomware?

Algunas pólizas cubren la extorsión, normalmente con sublímite y con la aprobación previa de la aseguradora. No puede pagarse a personas o grupos incluidos en listas de sanciones de la UE, y en la mayoría de los casos la vía preferente es recuperar desde copias limpias. Por eso las aseguradoras dan tanta importancia a que las copias estén aisladas y la restauración esté probada.

¿Qué pasa si declaro en el cuestionario un control que no tengo?

El cuestionario es la base del contrato. Según el artículo 10 de la Ley de Contrato de Seguro, si la declaración era inexacta y el siniestro llega antes de que se corrija, la indemnización se reduce en proporción a la prima que se habría cobrado conociendo el riesgo real, y si hubo dolo o culpa grave la aseguradora queda liberada del pago. Por eso conviene verificar cada respuesta antes de firmar.

¿Vendéis vosotros el seguro?

No. QuantumSec no es aseguradora ni mediador de seguros: no vendemos pólizas, no cobramos la prima ni recomendamos un producto asegurador concreto. Te ponemos en contacto con corredurías y aseguradoras especializadas con las que colaboramos, y la contratación y el asesoramiento sobre la póliza los hacen ellas. Nuestro trabajo es la parte técnica: que lo que declares sea cierto y que tu empresa cumpla lo que el seguro exige.

¿Un pentest o un análisis de vulnerabilidades abarata el seguro?

Puede mejorar las condiciones, porque convierte una declaración en una evidencia y reduce el riesgo que percibe la aseguradora, pero la decisión de prima es siempre suya. Lo que sí garantiza es que lo que declaras se sostiene: es el mejor seguro para el propio seguro.

¿Qué hago si sufro un ciberataque y tengo póliza?

Llama primero al teléfono de asistencia de la póliza, antes de contratar a nadie por tu cuenta: muchas pólizas trabajan con un panel de proveedores y no cubren los gastos de uno externo sin autorización. Aísla los equipos sin borrar ni reinstalar, conserva los registros, da el parte dentro del plazo del condicionado y, si hay datos personales afectados, recuerda que la notificación a la AEPD es en 72 horas.