Cómo trabajar con QuantumSec: del primer contacto al retest
Por Kike Gandia · Co-Fundador y CEO, OSCP
QuantumSec es una empresa española de ciberseguridad ofensiva: pentesting, red team, auditorías técnicas y apoyo en cumplimiento normativo. Esta guía explica, paso a paso, cómo es trabajar con nosotros: qué pasa en la primera llamada, qué incluye la propuesta, qué se firma antes de empezar, cómo se ejecutan las pruebas, qué recibes al final y cuánto tarda cada fase. También cubre la otra forma de trabajar con QuantumSec: como partner, si eres una agencia, un MSP, una correduría o una consultoría que quiere ofrecer estos servicios a sus clientes.
Tres formas de trabajar con QuantumSec
La mayoría de los proyectos llegan por una de estas tres vías. El trabajo técnico es el mismo en las tres; lo que cambia es quién habla con quién y quién firma qué.
| Forma | Para quién | Quién contrata | Qué cambia |
|---|---|---|---|
| Cliente directo | Empresas y organismos que necesitan un pentest, una auditoría o apoyo en NIS2, DORA, ENS o ISO 27001 | La propia empresa, con QuantumSec | Nada: el proceso de esta guía, de principio a fin |
| A través de tu proveedor | Empresas cuya agencia, MSP, correduría o consultoría ya colabora con QuantumSec | Según el modelo, tu proveedor o QuantumSec | El interlocutor puede ser tu proveedor habitual, y el informe puede ir con su marca |
| Como partner | Agencias, MSP, corredurías, consultorías e integradores | Tú, con tu cliente, o tu cliente con QuantumSec | Se firma antes un acuerdo de colaboración que fija el modelo: derivación, marca blanca o venta conjunta |
Si vienes como cliente, sigue leyendo en orden. Si vienes como partner, el apartado «Trabajar con QuantumSec como partner» resume los modelos, y la [página del programa de partners](/partners/) los detalla.
Paso 1: la primera llamada
Todo empieza con una llamada gratuita de 30 minutos, que se reserva directamente en el calendario de la [página de contacto](/contacto/) o pidiéndola por correo a contacto@quantumsec.es. No es una llamada comercial de manual: al otro lado hay una persona técnica que va a hacerte preguntas para entender qué necesitas probar y por qué.
Para aprovecharla, conviene llegar con estas respuestas, aunque sean aproximadas:
- Qué quieres probar: una aplicación web, una API, una app móvil, la red interna, el Active Directory, un entorno cloud, Microsoft 365 o Google Workspace.
- Por qué ahora: un lanzamiento, un cliente que lo exige, una auditoría, un pliego, la renovación de un ciberseguro, NIS2 o DORA, o un incidente reciente.
- Qué tamaño tiene: número de aplicaciones, roles de usuario, endpoints de API, IPs o sedes, aunque sea por órdenes de magnitud.
- Qué plazo tienes: si hay una fecha límite (una firma, una auditoría, un go-live), es lo primero que hay que saber.
- Qué se ha hecho antes: pentests anteriores, informes de escáneres o auditorías.
Si no tienes claro qué tipo de prueba necesitas, la llamada sirve precisamente para eso. Y si después no encaja con lo que hacemos, te lo diremos.
Paso 2: alcance y propuesta en 24-48 horas
Con el alcance claro, en 24-48 horas recibes una propuesta por escrito. Para proyectos con muchos activos, a veces hace falta una segunda conversación o rellenar una [ficha de alcance](/recursos/ficha-alcance-pentesting/) con los datos exactos; no hay cargos por ese análisis inicial.
La propuesta incluye:
- Alcance: qué activos se prueban y cuáles quedan fuera, con URLs, IPs, aplicaciones o entornos concretos.
- Enfoque: caja negra, gris o blanca, y con qué cuentas o accesos se trabaja.
- Metodología: OWASP, PTES, OSSTMM o MITRE ATT&CK, según el tipo de prueba.
- Plazos: fechas de ejecución, de entrega del informe y del retest.
- Entregables: informe ejecutivo, informe técnico, reunión de cierre y retest.
- Precio cerrado: lo que cuesta el proyecto tal como está definido, sin variables abiertas.
Si quieres una referencia antes de hablar, la [calculadora de coste de pentesting](/calculadora-pentesting/) da rangos orientativos del mercado español por tipo de prueba y tamaño. El precio definitivo es siempre el de la propuesta.
Paso 3: lo que se firma antes de empezar
Un pentest es un ataque autorizado. Lo que lo diferencia de un ataque real es, precisamente, la autorización por escrito, así que antes de lanzar la primera prueba se deja todo firmado:
| Documento o acuerdo | Para qué sirve |
|---|---|
| Aceptación de la propuesta | Fija alcance, plazos, entregables y precio |
| Acuerdo de confidencialidad (NDA) | Protege la información que nos das y la que encontramos; se firma antes de recibir cualquier dato sensible |
| Autorización de las pruebas | La firma quien tiene autoridad sobre los sistemas, con el alcance exacto y las ventanas de ejecución |
| Reglas del ejercicio | Qué está permitido y qué no, horarios, IPs de origen de las pruebas y contactos de emergencia en ambos lados |
| Contrato de encargado del tratamiento | Solo si el proyecto implica tratar datos personales, conforme al RGPD |
Dos detalles que suelen olvidarse. Si los sistemas están en un proveedor (un hosting, un SaaS o una nube con políticas propias de pruebas de seguridad), hay que confirmar que permite el pentest o avisarle. Y si el equipo de sistemas o el SOC no van a estar avisados, alguien con autoridad tiene que saberlo, para que una alerta no acabe en una escalada innecesaria.
Las condiciones generales que se aplican a todos los proyectos —propuesta y aceptación, plazos, autorización de las pruebas y pago— están publicadas en las [condiciones de contratación](/condiciones-de-contratacion/).
Paso 4: la ejecución de las pruebas
La fase técnica de un pentest dura habitualmente entre 3 y 10 días hábiles, según el alcance. Un red team o una infraestructura compleja pueden necesitar más.
Cómo trabajamos durante esa fase:
- Pruebas manuales: usamos herramientas automáticas para cubrir lo repetitivo, pero el valor está en la explotación manual y en validar el impacto real de cada hallazgo. Un listado de alertas de un escáner no es un pentest.
- Sin acciones destructivas por defecto: no se hacen pruebas de denegación de servicio ni de borrado de datos. Si algún test tiene un riesgo potencial para la disponibilidad, se acuerda contigo y se ejecuta en una ventana de mantenimiento.
- Comunicación durante las pruebas: tienes un interlocutor técnico fijo. Si aparece algo grave —una vulnerabilidad crítica explotable desde internet, indicios de un compromiso previo—, se avisa por el canal acordado en las reglas del ejercicio, sin esperar al informe.
- Trazabilidad: se registra qué se ha probado, desde dónde y cuándo, para poder distinguir nuestras pruebas de cualquier otra actividad.
Las pruebas las ejecuta un equipo con certificaciones OSCP, CRTO y Burp Suite Certified Practitioner, en remoto o presencial, para clientes de toda España y de Europa.
Paso 5: el informe y la reunión de cierre
El informe suele entregarse 2-3 días después de terminar la fase técnica. Son dos documentos pensados para dos lectores distintos:
- Informe ejecutivo: para la dirección o para quien tiene que tomar decisiones. Qué se probó, qué riesgo real hay en términos de negocio, qué es urgente y qué puede esperar.
- Informe técnico: para quien tiene que corregir. Cada hallazgo con su severidad, la evidencia de cómo se explotó, los pasos para reproducirlo y la recomendación concreta de corrección.
Después viene la reunión de cierre. No sirve para leer el informe en voz alta, sino para que tu equipo pregunte: qué significa un hallazgo, cómo priorizar, qué alternativa de corrección encaja con vuestra arquitectura. Si el informe va a un tercero —un cliente enterprise, una aseguradora, un auditor de ISO 27001 o ENS—, también se puede preparar lo que ese tercero va a pedir.
Paso 6: el retest
El retest de las correcciones está incluido en todos nuestros proyectos. Cuando tu equipo ha corregido los hallazgos, volvemos a probar cada uno para verificar que la corrección funciona y no ha abierto otro problema.
De ahí sale la evidencia que de verdad sirve a terceros: no solo qué se encontró, sino que se corrigió y que alguien independiente lo ha comprobado. Es lo que suelen pedir los clientes enterprise en sus cuestionarios de proveedores, los auditores de ISO 27001 o ENS y las aseguradoras en la suscripción de un ciberseguro.
Los términos concretos del retest (plazo para pedirlo y qué cubre) se fijan en cada propuesta. Lo habitual es pedirlo cuando estén corregidos al menos los hallazgos críticos y altos, para no tener que repetir la verificación.
Plazos de un proyecto tipo
Para un pentest de alcance medio —una aplicación web con su API, por ejemplo—, el calendario orientativo es este:
| Fase | Plazo orientativo | De qué depende |
|---|---|---|
| Primera llamada | La reservas tú en el calendario | De tu agenda |
| Propuesta | 24-48 horas tras la llamada de alcance | De que el alcance esté claro |
| Firma y preparación | Unos días | De vuestros circuitos internos de aprobación y de preparar accesos y cuentas de prueba |
| Fase técnica | 3-10 días hábiles | Del tamaño y la complejidad del alcance |
| Informe | 2-3 días tras la fase técnica | Del número de hallazgos |
| Reunión de cierre | Tras la entrega del informe | De vuestra agenda |
| Retest | Cuando hayáis corregido | De vuestro ritmo de corrección |
Si tienes una fecha límite, dilo en la primera llamada: el calendario se construye hacia atrás desde ella. Lo que más retrasa un proyecto no suele ser la parte técnica, sino esperar a una firma interna o a que estén listos los accesos.
Qué necesitamos de tu parte
Un pentest sale mejor, y más rápido, cuando el cliente tiene preparado esto:
| Qué | Por qué | Cuándo |
|---|---|---|
| Un responsable del proyecto | Para decidir sobre el alcance y recibir los avisos urgentes | Desde la propuesta |
| Un contacto técnico | Para resolver bloqueos durante las pruebas (una cuenta que no funciona, una IP bloqueada) | Durante la ejecución |
| Cuentas de prueba | En caja gris, una por cada rol que se quiera probar; nunca cuentas reales de empleados o clientes | Antes de empezar |
| Entorno definido | Saber si se prueba producción, preproducción o ambas, y que preproducción sea representativa | En la propuesta |
| Ventanas y avisos | Horarios permitidos y quién debe saber que hay pruebas en curso | En las reglas del ejercicio |
| Documentación disponible | Especificaciones de la API, diagramas o informes previos; acortan la fase de reconocimiento | Antes de empezar, si existe |
Nada de esto es obligatorio para empezar a hablar. Si falta algo, lo vemos juntos en la primera llamada.
Trabajar con QuantumSec como partner
Si eres una agencia web, un MSP o proveedor de IT, una correduría de ciberseguros, una consultoría o un integrador, y tus clientes te piden seguridad ofensiva, puedes ofrecerla sin montar un equipo propio. Hay tres modelos:
| Modelo | Quién mantiene la relación con el cliente | Quién factura al cliente | Marca del informe |
|---|---|---|---|
| Derivación | QuantumSec, en el proyecto; tú sigues siendo su proveedor en lo tuyo | QuantumSec | QuantumSec |
| Marca blanca o subcontratación | Tú | Tú | La tuya, cuando el proyecto lo permite |
| Venta conjunta | Ambos, cada uno en su parte | Según la propuesta común | QuantumSec, en la parte de seguridad |
El proceso técnico es el de esta guía. Lo que se añade es un paso previo: una primera conversación sobre tus clientes y un acuerdo de colaboración por escrito, con NDA, que fija el modelo, las condiciones económicas (a medida, sin tabla única) y qué pasa con la relación con el cliente final. En el [programa de partners](/partners/) tienes el detalle de cada modelo y quién hace qué.
Lo que no hacemos
Saber dónde termina un proveedor ahorra tiempo a los dos. QuantumSec se dedica exclusivamente a la ciberseguridad ofensiva y al cumplimiento normativo que depende de ella. No hacemos:
- Desarrollo web ni de aplicaciones: encontramos y explicamos los fallos, y recomendamos cómo corregirlos, pero la corrección la hace tu equipo o tu proveedor de desarrollo.
- Administración de sistemas del día a día ni mantenimiento informático.
- Mediación de seguros: en el ámbito del ciberseguro hacemos la parte técnica y ponemos en contacto con corredurías, pero no recomendamos pólizas.
- Revender escaneos automáticos como si fueran un pentest: si lo que necesitas es un análisis de vulnerabilidades recurrente, es un servicio distinto y lo llamamos por su nombre.
Si lo que buscas es una revisión automatizada y periódica, tienes el [análisis de vulnerabilidades](/analisis-vulnerabilidades/). Y si el proyecto necesita alguna de las otras piezas, lo normal es trabajar junto a quien la cubre, que es justo para lo que existe el programa de partners.
FAQ
¿Cuánto cuesta trabajar con QuantumSec?
Depende del tipo de prueba y del tamaño del alcance. Cada proyecto tiene una propuesta con precio cerrado antes de empezar, sin cargos por el análisis inicial. Para una referencia previa, la calculadora de coste de pentesting da rangos orientativos del mercado español.
¿Hay que firmar un contrato de larga duración?
No. La mayoría de nuestros servicios son proyectos cerrados con un entregable concreto. Si hay una relación continua, como un análisis de vulnerabilidades recurrente o un servicio gestionado, se formaliza con plazos definidos y salida flexible.
¿Trabajáis solo en Valencia?
No. La sede está en Valencia, pero trabajamos con clientes de toda España y de Europa, en remoto y presencial. La mayoría de las pruebas se ejecutan en remoto; las que necesitan presencia física, como una auditoría wifi o un red team con intrusión física, se hacen in situ.
¿Las pruebas pueden afectar a nuestros sistemas en producción?
Por defecto evitamos cualquier acción que pueda interrumpir el servicio, como pruebas de denegación de servicio o borrado de datos. Si algún test tiene un riesgo potencial, se acuerda con vosotros y se ejecuta en una ventana de mantenimiento o en un entorno de pruebas.
¿Qué pasa si encontráis algo crítico durante las pruebas?
No esperamos al informe. En las reglas del ejercicio se acuerda un canal y un contacto para avisos urgentes, y por ahí se comunica cualquier hallazgo crítico o indicio de compromiso previo en cuanto se confirma.
¿Está incluido el retest?
Sí, el retest de las correcciones está incluido en todos nuestros proyectos. Los términos concretos, como el plazo para pedirlo, se fijan en cada propuesta.
¿Podemos contratar a QuantumSec a través de nuestra agencia o nuestro MSP?
Sí. Si tu proveedor forma parte del programa de partners, el proyecto puede llegar a través de él: en marca blanca, tu proveedor sigue siendo tu interlocutor y el informe puede ir con su marca; en derivación, contratas directamente con QuantumSec. Si no colabora todavía con nosotros, puede informarse en la página del programa de partners.
Servicio relacionado
programa de partners para agencias, MSP, corredurías y consultorías