Pentesting vs Red Team: diferencias, cuándo usar cada uno

Pentesting y Red Team se mezclan en pliegos y en conversaciones de pasillo como si fueran lo mismo, y no lo son. Comparten herramientas, perfil profesional y vocabulario, pero responden a preguntas distintas, duran tiempos distintos, cuestan distinto y dejan al cliente con resultados distintos. Confundirlos lleva a comprar pentesting cuando lo que la organización necesita es un Red Team, o al revés (más caro y más frecuente). La diferencia operativa es esta: el pentesting busca fallos en activos concretos; el Red Team mide si tu defensa se entera y reacciona cuando alguien ya está dentro. Esta entrada desarrolla las dos definiciones, las compara dimensión a dimensión y explica cuándo conviene cada una, cómo encajan en NIS2, DORA y TIBER-EU, y cuándo tiene sentido combinarlas.

Definiciones rápidas

Pentesting

Un pentesting (o test de penetración) es un ejercicio autorizado y acotado en el tiempo sobre un conjunto definido de activos (una web, una API, una red interna, un entorno cloud, una app móvil), donde un equipo ofensivo busca vulnerabilidades técnicas explotables, las prueba en la medida en que el alcance lo permita y entrega un informe técnico con cada hallazgo, su impacto y la remediación recomendada. La pregunta operativa que responde es: ¿qué fallos hay en estos activos y cómo de graves son?

Más detalle en qué es el pentesting.

Red Team

Un Red Team es una simulación adversaria continua y sigilosa que emula a un atacante real (incluido el grupo APT específico cuando hay threat intelligence) intentando comprometer objetivos concretos de negocio sin que la defensa se entere, durante semanas o meses, con un alcance amplio que incluye técnica, físico y, a veces, ingeniería social. La pregunta operativa es: ¿podría un adversario comprometer el negocio sin que nuestra defensa se entere a tiempo?

Más detalle en qué es Red Team.

Diferencias dimensión a dimensión

Objetivo

• Pentesting. Encontrar vulnerabilidades en los activos en alcance, evaluarlas (CVSS, contexto), encadenarlas cuando se pueda y entregarlas con prueba de concepto y remediación.
• Red Team. Medir la capacidad de detección y respuesta del defensor frente a un adversario realista. Las vulnerabilidades son medio, no fin: si una sola es suficiente para alcanzar el objetivo de negocio acordado, el resto no se documentan con la misma profundidad.

Alcance

• Pentesting. Acotado y escrito antes de empezar: lista de URLs, rangos de IP, repositorios, identidades cloud, ventanas horarias y técnicas excluidas. Suele cubrir un activo o un conjunto pequeño.
• Red Team. Amplio y orientado a objetivos de negocio ("exfiltrar la base de datos de clientes", "acceder al entorno de pago", "tomar control de la sala de control OT"). Las técnicas se eligen sobre la marcha según las defensas que se encuentran.

Duración

• Pentesting. Entre 1 y 4 semanas de ejecución activa, según tamaño y complejidad.
• Red Team. Entre 4 y 16 semanas, con campañas de meses en ejercicios TIBER-EU. La sigilosidad exige bajo ritmo de actividad para no quemar la huella.

Profundidad técnica

• Pentesting. Profundidad alta dentro de cada activo. Recorre el árbol de superficie sistemáticamente.
• Red Team. Profundidad selectiva: lo justo para llegar al objetivo. Si el camino más corto pasa por phishing, se prioriza eso; si pasa por una vulnerabilidad web pública, se va por ahí. La técnica está al servicio del objetivo, no al revés.

Sigilo

• Pentesting. No es sigiloso. El equipo defensor sabe que hay un ejercicio y cuándo, y el ejercicio se ejecuta sin esconderse de las herramientas de detección.
• Red Team. Sigilo es requisito. El defensor (excepto un grupo pequeño llamado White Team o Control Group) no sabe que se ejecuta el ejercicio. Detectarlo es parte de lo que se mide.

Perfil del equipo

• Pentesting. Perfiles especializados por superficie: web, API, móvil, red, cloud, IoT/OT.
• Red Team. Perfiles polivalentes con foco en operaciones adversarias: emulación de TTP de APTs específicos, evasión de EDR, post-exploitation, lateral movement, persistencia, exfiltración. Mucho énfasis en MITRE ATT&CK como marco operativo.

Documentación de salida

• Pentesting. Informe técnico exhaustivo con cada hallazgo: severidad, prueba de concepto, request/response, impacto, remediación, retest tras correcciones.
• Red Team. Informe narrativo con la cadena de ataque, los puntos donde la defensa detectó (y los puntos donde no), métricas de detección (MTTD), recomendaciones por capa de defensa y, si se contrató, un ejercicio Purple Team posterior para entrenar la defensa.

Coste

Sin entrar en propuesta cerrada, el orden de magnitud cambia. Un pentesting de aplicación web de complejidad media en España ronda los 5.000-15.000 €; un Red Team serio empieza a partir de 30.000-50.000 € y un ejercicio TIBER-EU completo va entre 80.000 y 250.000 €. Las cifras son rangos de mercado, no propuesta cerrada: dependen del alcance, del adversario emulado y del tiempo asignado.

Diferencias prácticas en el día a día del proyecto

Donde mejor se ven las diferencias es en cinco aspectos operativos.

Reglas de enganche (Rules of Engagement)

El pentesting tiene ROE detalladas y restrictivas (qué se puede tocar, en qué ventana, con qué intensidad). El Red Team tiene ROE amplias y orientadas a objetivos: el equipo decide la técnica concreta dentro de los límites legales y éticos acordados, y se reserva al White Team la autoridad para activar "safe words" si algo se descontrola.

Comunicación con la organización auditada

En pentesting, hay canal abierto con responsables técnicos durante el proyecto: dudas de alcance, validación de hallazgos en tiempo real, coordinación de pruebas que podrían afectar producción. En Red Team, el canal está restringido al White Team y solo se activa para decisiones críticas o emergencias.

Detección y reacción del defensor

En pentesting, si el SOC detecta al equipo ofensivo, la respuesta normal es dejarles trabajar (avisados de antemano). En Red Team, si el SOC detecta al equipo ofensivo y reacciona, eso es el resultado del ejercicio: hasta dónde llegó el atacante antes de ser parado.

Evidencias y reproducibilidad

En pentesting, cada hallazgo lleva PoC reproducible, capturas, comandos exactos. En Red Team, las evidencias se concentran en los puntos clave de la cadena: ingreso inicial, escalada, movimiento lateral, exfiltración. La cadena entera importa más que cada fallo por separado.

Riesgo sobre producción

El pentesting busca minimizar el riesgo sobre producción (alcance acotado, ventanas controladas, herramientas calibradas). El Red Team asume que el atacante real no respeta ventanas, así que opera con cuidado pero sin condicionarse: si una técnica realista puede causar disrupción, se evita por sentido común, no por restricción contractual.

Cuándo necesitas pentesting (y no Red Team)

Hay seis escenarios donde el pentesting es lo que toca, sin discusión.

1. Validar un release o cambio significativo. Aplicación web nueva, API que se va a publicar, entorno cloud recién montado. Necesitas un mapa completo de la superficie técnica antes de que entren clientes.
2. Cumplir un requisito normativo de evidencia técnica. NIS2 artículo 21, DORA secciones técnicas, ENS, ISO 27001 (control A.8.8), PCI DSS (requerimiento 11.4) piden pruebas periódicas. Un informe de pentesting es la evidencia.
3. Due diligence de un proveedor. Comprobar la seguridad técnica de un producto antes de adoptarlo.
4. Madurez técnica baja o media. Sin SOC propio o sin detección sólida, contratar Red Team es prematuro: el equipo ofensivo va a alcanzar el objetivo sin esfuerzo y el ejercicio aporta poco más allá de confirmar lo evidente.
5. Auditoría tras un incidente. Para identificar la vulnerabilidad explotada y descartar más en el mismo activo.
6. Presupuesto contenido. La mayoría de PYMEs cubren su necesidad de evidencia técnica con pentesting anual, sin entrar en Red Team.

Cuándo necesitas Red Team (y no pentesting)

Hay cinco escenarios donde Red Team es la respuesta correcta.

1. Madurez defensiva alta y SOC propio o gestionado. Quieres medir si la inversión defensiva detecta a un adversario realista.
2. Sector regulado de servicios financieros bajo DORA. La sección de TLPT (Threat-Led Penetration Testing) en entidades significativas exige ejercicios tipo TIBER-EU, que son Red Team estructurado. Detalle en TIBER-EU TLPT.
3. Operadores de servicios esenciales con superficie crítica. Energía, sanidad, agua, telcos: probar capacidad real de detección y respuesta.
4. Ejercicio interno tras incidentes importantes. Verificar que las correcciones implantadas tras un compromiso real funcionan en condiciones adversariales.
5. Validación de inversión defensiva. Justificar (o cuestionar) presupuesto en EDR, SIEM, SOC, threat intelligence con datos empíricos sobre lo que detectaron o no.

Cómo encajan en NIS2, DORA y TIBER-EU

Las tres normativas piden pruebas técnicas, pero con matices distintos.

NIS2

El artículo 21 exige medidas técnicas y organizativas que se sostengan con pruebas periódicas, sin especificar que sean pentesting o Red Team. En la práctica del mercado español, el pentesting periódico se acepta como evidencia razonable para entidades esenciales e importantes estándar; el Red Team queda como buena práctica para entidades de mayor criticidad y como referencia obligatoria solo cuando la entidad cae bajo el régimen TLPT de DORA.

DORA

El reglamento financiero europeo distingue dos niveles:

• Pruebas técnicas básicas (artículo 25): pentesting, escaneos de vulnerabilidades, pruebas de continuidad. Obligatorias para entidades en alcance.
• TLPT (artículos 26-27): pruebas avanzadas tipo Red Team con threat intelligence, obligatorias para entidades financieras significativas designadas por la autoridad competente, con una cadencia de al menos una cada 3 años.

TIBER-EU

Es el marco metodológico publicado por el BCE para los TLPT bancarios. No es una norma vinculante por sí misma, pero es el marco que DORA reconoce como referencia para los TLPT. Distingue tres fases: Preparación, Pruebas (Threat Intelligence + Red Team) y Cierre (informes, replay con el defensor). Para entidades financieras significativas en España, el flujo TIBER-ES (con el Banco de España como autoridad) implementa el modelo.

Errores frecuentes al elegir entre pentesting y Red Team

Patrones que vemos en pliegos y propuestas mal planteadas.

1. Pedir Red Team y describir pentesting. "Hacer un Red Team a nuestra aplicación web durante una semana." Eso no es Red Team, es pentesting. El término correcto evita malentendidos en presupuesto y entregables.
2. Pedir pentesting cuando la pregunta es detección. "Quiero saber si nuestro SOC funciona". Para eso, un pentesting visible no sirve: el SOC sabe que hay ejercicio, no es prueba comparable a un atacante real.
3. Contratar Red Team sin tener defensa que medir. Si no hay SOC ni EDR, el Red Team alcanzará el objetivo en horas. El informe se reduce a "no hay defensa", que ya se sabía sin gastar el presupuesto.
4. Definir objetivos vagos para el Red Team. "Que veas hasta dónde llegáis" no es un objetivo: es un cheque en blanco. Los objetivos bien definidos son concretos, medibles y vinculados a impactos de negocio.
5. Saltarse el Purple Team post-Red Team. El valor real del Red Team se materializa cuando, después del ejercicio, el equipo ofensivo se sienta con el defensivo y reproducen la cadena de ataque paso a paso para entrenar detecciones. Sin esa sesión, el ejercicio se queda en un informe.
6. Repetir el mismo proveedor año tras año en Red Team. Misma técnica, misma huella, mismos hallazgos. El valor del Red Team está en simular adversarios distintos. Alternar proveedores cada uno o dos ciclos mantiene la utilidad del ejercicio.

¿Se hacen pentesting y Red Team a la vez?

Sí, y en programas maduros conviven con cadencias distintas:

• Pentesting sobre activos críticos: anual o tras cambio significativo. La frecuencia la marca el ritmo de cambios técnicos y los requisitos regulatorios.
• Red Team sobre objetivos de negocio: cada 1-3 años, según madurez y obligaciones normativas.
• Continuous Red Team / Adversary Emulation automatizada: cada vez más empresas combinan los ejercicios humanos con plataformas de breach and attack simulation que prueban detecciones continuamente. No sustituyen al Red Team humano, lo complementan entre campañas.

Preguntas frecuentes

¿Cuál es la diferencia principal entre pentesting y Red Team?

El pentesting busca vulnerabilidades técnicas en activos concretos durante 1-4 semanas con alcance acotado y comunicación abierta con el defensor. El Red Team mide la capacidad de detección y respuesta frente a un adversario realista durante 4-16 semanas con alcance amplio y sigilo total. En una frase: pentesting responde "qué fallos hay"; Red Team responde "si nos atacaran, ¿nos enteraríamos?".

¿Es más caro un Red Team que un pentesting?

Sí, por dos motivos. Primero, dura mucho más: un Red Team típico oscila entre 4 y 16 semanas frente a 1-4 semanas de pentesting. Segundo, exige perfiles más senior (emulación de adversarios, evasión de EDR, infraestructura propia de C2). En rangos orientativos de mercado en España: pentesting de aplicación web de complejidad media en torno a 5.000-15.000 €; Red Team a partir de 30.000-50.000 €; TIBER-EU completo entre 80.000 y 250.000 €.

¿Mi empresa necesita Red Team o le basta pentesting?

Pentesting es lo razonable si: no tienes SOC propio o gestionado, la madurez defensiva es media-baja, el objetivo principal es cumplir requisitos normativos básicos o validar releases. Red Team tiene sentido si: tienes SOC, EDR, indicadores defensivos medidos, o estás obligado por DORA TLPT, o quieres validar empíricamente la inversión defensiva. La mayoría de PYMEs españolas cubren su necesidad con pentesting anual; el Red Team aparece más a partir de mediana empresa con función defensiva propia.

¿Sirve el pentesting para cumplir NIS2 y DORA?

NIS2: sí, el pentesting periódico es interpretado como prueba técnica suficiente para el artículo 21 en entidades esenciales e importantes estándar. DORA: sí para las pruebas técnicas básicas del artículo 25, no para los TLPT del artículo 26-27, que exigen ejercicios tipo Red Team con threat intelligence y son obligatorios para entidades financieras designadas como significativas.

¿Qué es un ejercicio Purple Team?

Un Purple Team es la sesión colaborativa entre el equipo ofensivo (Red) y el defensivo (Blue) que se hace después o durante un Red Team, donde se reproducen las técnicas del adversario paso a paso para que el defensivo aprenda a detectarlas. Es el momento donde se materializa el valor formativo del ejercicio. Sin Purple Team, el Red Team se queda en informe; con Purple Team, mejora la capacidad real de detección.

¿Cada cuánto debería contratar pentesting o Red Team?

Pentesting: anual sobre activos críticos, más prueba tras cambios significativos (lanzamientos, refactor de infraestructura, migración a cloud). Algunos sectores regulados (PCI DSS, financiero) exigen cadencia específica. Red Team: cada 1-3 años según madurez; en entidades DORA TLPT, mínimo cada 3 años; en grandes operadores de servicios esenciales o financieros, anual es habitual.

¿Puede el mismo proveedor hacer pentesting y Red Team?

Sí, y es lo habitual cuando el proveedor tiene capacidad para ambos. Lo que conviene rotar (al menos en Red Team) es el adversario emulado y, cada uno o dos ciclos, el propio equipo, para evitar que el ejercicio repita la misma huella y los mismos hallazgos. La diversidad de aproximación es parte del valor del ejercicio.

Recursos relacionados

• Qué es el pentesting: guía completa
• Qué es Red Team: guía para empresas
• TIBER-EU y TLPT explicados
• DORA: cumplimiento empresas 2026
• NIS2 España: cómo cumplir
• Servicio Red Team
• Servicio auditoría web y móvil

---

¿Vas a contratar un ejercicio ofensivo y no tienes claro si lo tuyo es pentesting o Red Team? En Secra revisamos el contexto (madurez defensiva, obligaciones regulatorias, objetivos del negocio) y proponemos el ejercicio que de verdad responde a la pregunta que tienes. Cuéntanos qué necesitas medir y vemos qué encaja mejor.