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 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 estándar suele estar entre 1.500 € y 5.000 €. Proyectos más complejos como un Red Team o un pentesting completo de infraestructura pueden superar esa cifra. Siempre hacemos una primera llamada gratuita para darte un presupuesto ajustado a tu realidad.

¿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 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.

¿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 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.

¿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 al derecho nacional antes de octubre de 2024. España está en proceso de transposición. Aunque la ley nacional específica puede estar pendiente, la directiva ya genera obligaciones para las entidades cubiertas. Lo prudente es adecuarse ahora.

¿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.

¿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.

¿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.

¿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.

¿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.

¿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 hacer las auditorías de seguimiento anuales?

Sí. Ofrecemos contratos de mantenimiento para auditorías de seguimiento, actualización del SGSI ante cambios y preparación para la renovación trianual.

¿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.

¿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.

¿Necesitáis acceso físico al dispositivo?

Para un test completo, sí. Algunos análisis (API backend, app móvil, comunicaciones de red) se pueden realizar de forma remota, pero el análisis de firmware y hardware requiere el dispositivo físico.

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

Siempre trabajamos con el equipo de OT para definir ventanas de mantenimiento y realizar las pruebas más invasivas fuera de horas de producción. La seguridad de la operación es nuestra prioridad.

¿Hacéis evaluaciones para cumplir con la directiva RED (Radio Equipment Directive)?

Sí. Ayudamos a fabricantes a preparar la documentación técnica de seguridad requerida por la directiva RED de la UE para dispositivos IoT.

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

Podemos trabajar con solo el IPA (caja negra/gris). Si nos proporcionas el código fuente, el análisis es más profundo y eficiente. Recomendamos el acceso al código para equipos de desarrollo que quieren resultados accionables.

¿El test require un dispositivo físico con jailbreak?

Para el análisis dinámico completo, sí recomendamos un dispositivo con jailbreak. También podemos trabajar con simuladores para parte del análisis estático y de red.

¿Cubris la API backend que usa la app?

Sí, incluimos la evaluación del backend API dentro del alcance del pentesting móvil. Es esencial para una evaluación completa, ya que muchas vulnerabilidades están en la capa de servidor.

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

No es imprescindible. Podemos trabajar con el APK directamente mediante análisis de caja negra/gris. El código fuente permite un análisis más profundo, especialmente para detectar vulnerabilidades en lógica de negocio.

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

Parte del análisis (estático y de red) puede realizarse con emuladores. Para el análisis dinámico completo con Frida y análisis de hardware-backed security, recomendamos un dispositivo físico rooteado.

¿La auditoría sirve para cumplir con GDPR en apps Android?

Sí. Identificamos dónde se almacenan y transmiten datos personales, si están protegidos adecuadamente y qué permisos son excesivos o innecesarios, lo cual es clave para la evaluación de impacto en privacidad (DPIA).

¿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.

¿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.

¿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.

¿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 España cuesta entre 80.000 y 130.000 €/año. 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.

¿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.

¿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 23 de octubre de 2024. La aplicación plena de los requisitos técnicos y de conformidad es el 11 de diciembre de 2027. Hay dos plazos intermedios críticos: los requisitos de notificación de incidentes activos a ENISA son exigibles desde el 11 de agosto de 2026, y los organismos notificados (para evaluación de terceros) deben estar designados desde el 11 de septiembre de 2026.

¿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.

¿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.

¿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.

¿Trabajáis sobre plataformas ya existentes o necesito cambiar?

Trabajamos sobre cualquier plataforma que ya tengas: HackerOne, Bugcrowd, Intigriti, YesWeHack o canales propios. No es necesario cambiar de plataforma. Si todavía no tienes ninguna, te recomendamos la más adecuada para tu caso y te ayudamos con la configuración inicial.

¿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.

¿Cuánto cuesta gestionar un programa de bug bounty externamente?

El coste depende del volumen de reportes mensuales, el nivel de SLA y si el servicio incluye el diseño inicial del programa. Es significativamente inferior a contratar un analista de triage interno, y más flexible porque el coste se adapta al volumen real del programa.

¿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.

¿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.

¿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, trabajamos con el cliente para definir la ventana y el procedimiento seguro de validación.

¿Cuánto tarda la validación de un reporte?

El SLA estándar es de 24 horas laborables para reportes de severidad alta y crítica, y de 48-72 horas para severidades media y baja. Para programas de alto volumen, acordamos ciclos de validación que se adaptan al flujo de reportes.

¿Qué diferencia hay entre CVSS 4.0 y las versiones anteriores?

CVSS 4.0, publicado por FIRST en 2023, introduce una nueva taxonomía de métricas más granular, mejora la valoración del impacto en entornos OT/ICS y añade métricas adicionales de suplemento. Usamos CVSS 4.0 como estándar base porque proporciona una puntuación más precisa y aplicable a entornos modernos. Si tu programa ya usa CVSS 3.1, podemos trabajar con ambas versiones en paralelo.

¿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.

¿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.