Red Team vs Pentest: cuándo usar cada uno y por qué importa la diferencia
Pentesting y Red Team no son sinónimos. Cuándo elegir cada uno, qué exige la normativa (ENS, DORA/TIBER-EU) y cómo el Purple Team cierra el ciclo.
En esta página
Dos disciplinas, dos objetivos
Pentesting y Red Team se usan como sinónimos con frecuencia en el mercado español, pero son disciplinas distintas con objetivos, metodologías y ciclos temporales muy diferentes. La confusión no es inocua: contratar un Red Team esperando un pentest — o al revés — produce frustración, entregables inadecuados y decisiones de inversión equivocadas. Y en 2026, con el Esquema Nacional de Seguridad exigiendo auditorías periódicas [1] y DORA obligando a ciertas entidades financieras a ejecutar pruebas basadas en amenazas reales [2][3], entender la diferencia ya no es solo una cuestión técnica: es una cuestión de cumplimiento.
Este artículo actualiza y amplía nuestra guía original con el marco regulatorio vigente, pasos prácticos de contratación y las preguntas que más nos hacen los responsables de seguridad y compliance.
Definiciones precisas
Pentesting
Un pentest es un ejercicio técnico acotado cuyo objetivo es identificar y demostrar la explotabilidad del mayor número posible de vulnerabilidades dentro de un alcance definido (una aplicación, una red interna, una API, un segmento de infraestructura). Se ejecuta habitualmente en ventanas de 1 a 4 semanas, con conocimiento previo del alcance por parte del equipo defensor, y produce un entregable cerrado: informe técnico, hallazgos clasificados por severidad, pruebas de concepto y recomendaciones de remediación priorizadas.
El pentest responde a la pregunta: "¿Cuántas puertas están abiertas y cómo de fácil es entrar por cada una?"
Red Team
Un Red Team es una simulación de adversario realista cuyo objetivo es alcanzar un objetivo de negocio definido — exfiltrar la base de clientes, acceder a un sistema de pagos, desplegar ransomware controlado en un entorno crítico — usando las tácticas, técnicas y procedimientos (TTPs) de un actor real, normalmente mapeados contra el marco MITRE ATT&CK [8]. El alcance es la organización completa (personas, procesos, tecnología), la duración típica va de 2 a 6 meses, el equipo defensor no conoce ni el momento ni el vector de entrada, y el entregable evalúa la capacidad defensiva completa siguiendo el ciclo Detect, Respond, Contain.
El Red Team responde a otra pregunta: "Si un atacante real lo intenta sin que lo sepamos, ¿lo detectamos, lo contenemos y en cuánto tiempo?"
| Dimensión | Pentesting | Red Team |
|---|---|---|
| Objetivo | Hallar vulnerabilidades | Alcanzar un objetivo de negocio |
| Alcance | Acotado (app, red, API) | Holístico (personas + procesos + tecnología) |
| Duración típica | 1-4 semanas | 2-6 meses |
| Conocimiento del defensor | Suele conocer el ejercicio | No lo conoce (o casi) |
| Marco de TTPs | Catálogo de vulnerabilidades (OWASP, CVE) | MITRE ATT&CK [8] |
| Entregable | Inventario de hallazgos priorizado | Evaluación de capacidad defensiva end-to-end |
| Criterio de éxito | Encontrar el mayor número de vulnerabilidades explotables | Lograr el objetivo sin ser detectado, o medir cuándo se detecta |
| Métrica clave | Número y severidad de hallazgos | MTTD/MTTR del Blue Team |
| Marco regulatorio típico | ENS op.mon.3 R6 [1], NIS2 art. 21 [6], PCI-DSS | DORA art. 26 + TIBER-EU [2][3][4], TIBER-EU/CBEST [7] |
Marco regulatorio: qué exige realmente la normativa
Aquí es donde más confusión (y más riesgo de incumplimiento) se genera. Repasamos lo que dice cada norma, con enlace a la fuente oficial.
ENS (Esquema Nacional de Seguridad — RD 311/2022)
El Real Decreto 311/2022 [1] regula el ENS para el sector público español y sus proveedores. Establece tres categorías (básica, media, alta); según su artículo 31.1, los sistemas de categoría MEDIA y ALTA son objeto de una auditoría regular al menos cada dos años que verifique el cumplimiento del ENS, mientras que los sistemas de categoría BÁSICA solo requieren una autoevaluación para su declaración de conformidad, conforme al artículo 38.1 [1]. Dentro del Anexo II, la medida de vigilancia op.mon.3 "Vigilancia del sistema" incorpora el Refuerzo R6 (Pruebas de penetración), que la propia norma exige solo en categoría ALTA (op.mon.3 + R1+R2+R3+R4+R5+R6); en categoría MEDIA el mismo control se aplica sin ese refuerzo (op.mon.2 + R1+R2), por lo que el RD 311/2022 no impone pentest periódico obligatorio en categoría media por esta vía. En ningún caso el ENS exige por sí mismo un Red Team en el sentido que describimos arriba: el refuerzo op.mon.3.r6 exige pruebas de penetración periódicas, es decir, pentest, y únicamente en categoría alta. Conviene confirmar con el auditor certificador si guías CCN-STIC posteriores a este real decreto amplían o matizan esta exigencia para categoría media.
NIS2 (Directiva (UE) 2022/2555)
NIS2 [6] exige a las entidades esenciales e importantes gestionar el riesgo de ciberseguridad de forma proporcional, incluyendo pruebas y auditorías periódicas de seguridad, pero no especifica en el texto de la directiva que deba tratarse de un Red Team formal: el tipo de prueba (pentest, auditoría de configuración, Red Team) se define en las medidas nacionales de transposición y en las guías técnicas asociadas.
Dato importante y cambiante: a fecha de esta publicación, España no ha completado la transposición de NIS2 a derecho nacional. El plazo de transposición vencía el 17 de octubre de 2024. A fecha de esta redacción, la Comisión Europea mantiene un procedimiento de infracción abierto contra España por transposición incompleta de la Directiva NIS2; el estado exacto del procedimiento (incluida una eventual remisión al TJUE) puede consultarse directamente en el Infringement Decisions Register de la Comisión Europea (ec.europa.eu/atwork/applying-eu-law) o en ec.europa.eu/commission/presscorner [5]. Esto significa que las obligaciones específicas de NIS2 todavía no son directamente exigibles en España como ley nacional propia, aunque sí lo son ya el ENS, DORA (para entidades financieras) y otras normas sectoriales.
DORA (Reglamento (UE) 2022/2554) y TIBER-EU
DORA, que sí es un reglamento directamente aplicable desde enero de 2025 (no requiere transposición), regula en su artículo 26 las pruebas avanzadas basadas en TLPT (Threat-Led Penetration Testing) [2]. El desarrollo técnico de este artículo llegó con el Reglamento Delegado (UE) 2025/1190, de 13 de febrero de 2025, publicado en el Diario Oficial y de aplicación directa desde julio de 2025 [3]. Esta norma:
- Define los criterios para identificar qué entidades financieras están obligadas a hacer TLPT (no todas las entidades sujetas a DORA, solo las identificadas como significativas por tamaño, interconexión y criticidad sistémica).
- Exige que el TLPT se ejecute siguiendo el marco TIBER-EU del Banco Central Europeo [4], que define cómo deben trabajar juntos el regulador, la entidad, el proveedor de inteligencia de amenazas y el equipo Red.
- Establece una periodicidad mínima de cada tres años para las entidades obligadas.
- Regula el uso de testers internos y el reconocimiento mutuo entre supervisores de distintos Estados miembros.
El TLPT de DORA es, en esencia, un Red Team altamente estructurado y supervisado por el regulador. TIBER-EU está adoptado también por el Banco de España [4], por lo que las entidades financieras españolas identificadas como significativas quedan bajo este marco.
Equivalentes internacionales
Fuera de la UE, el marco de referencia más citado es CBEST del Banco de Inglaterra [7], un programa de pentest basado en inteligencia de amenazas para entidades sistémicas del sector financiero británico, voluntario pero fuertemente recomendado por el regulador. TIBER-EU se inspiró parcialmente en su diseño.
Cuándo usar pentest
- Antes de un despliegue de una nueva aplicación o infraestructura, para detectar vulnerabilidades explotables antes de producción.
- Cumplimiento regulatorio recurrente: ENS categoría alta (refuerzo op.mon.3.R6) [1], PCI-DSS, requisitos contractuales con clientes.
- Due diligence en procesos de adquisición o fusión, para evaluar la superficie de exposición del objetivo.
- Baseline de madurez técnica antes de plantearse ejercicios más avanzados como Red Team.
Cuándo usar Red Team
- Madurez defensiva alta: la organización ya cuenta con SOC (propio o SOCaaS/MDR subcontratado), EDR desplegado y procesos de respuesta a incidentes documentados.
- Validación de capacidades reales: comprobar si el SOC detectaría un actor persistente avanzado (APT) operando con TTPs reales, no simuladas de forma anunciada.
- Test de respuesta a incidentes con escalado real: ejercicio que llega a Dirección y valida el proceso de decisión bajo presión, no solo la parte técnica.
- Obligación regulatoria específica: TLPT bajo DORA/TIBER-EU para entidades financieras significativas [2][3][4], o marcos voluntarios equivalentes como CBEST fuera de la UE [7].
"Un pentest te dice si la cerradura es buena. Un Red Team te dice si, aunque la cerradura sea buena, alguien acabará entrando — y cuánto tarda tu equipo en darse cuenta." — Analogía usada en formaciones de Hodeitek.
Purple Team: el puente entre ambos
El Purple Team no es un tercer tipo de ejercicio independiente ni un término puramente comercial: es una metodología de colaboración en la que el equipo Red y el equipo Blue trabajan en paralelo, con sesiones conjuntas donde el Red ejecuta TTPs concretas (mapeadas a MITRE ATT&CK [8]) y el Blue observa en tiempo real si las detecta, ajustando reglas de detección sobre la marcha. El objetivo es mejorar la cobertura defensiva de forma incremental y medible, no determinar quién "gana".
Cuándo usar Purple Team
- Tras un Red Team con hallazgos importantes de detección: para cerrar brechas concretas de forma dirigida, técnica por técnica.
- Al desplegar tecnología nueva (nuevo EDR, nuevo SIEM, nueva integración SOAR): validar la cobertura real frente a MITRE ATT&CK antes de confiar en la herramienta.
- Como actividad continua — trimestral o semestral — en organizaciones con madurez alta que quieren mantener, no solo demostrar, su capacidad de detección.
Pasos prácticos para elegir y contratar el ejercicio correcto
- Evalúa tu madurez defensiva actual antes de pedir presupuesto. Si no tienes SOC (interno o subcontratado), EDR y al menos un runbook de respuesta a incidentes probado, empieza por pentest + remediación.
- Identifica si tienes una obligación regulatoria específica. El ENS exige auditoría periódica cada dos años para todos los sistemas en su ámbito y, en categoría alta, el refuerzo op.mon.3.R6 de pruebas de penetración [1]; entidades financieras significativas bajo DORA pueden estar obligadas a TLPT cada tres años [2][3]. Confirma con tu asesor de cumplimiento si tu organización entra en esos criterios — no lo asumas.
- Define el objetivo de negocio, no solo el alcance técnico, si vas a contratar un Red Team. "Comprobar si podemos exfiltrar la base de clientes sin ser detectados" es un objetivo válido; "hacer un Red Team a la red" no lo es.
- Decide el nivel de conocimiento previo del defensor. Un Red Team que avisa "solo entre lunes y viernes, solo esta aplicación" deja de ser un Red Team: se convierte en un pentest con más presupuesto y menos valor.
- Exige que el proveedor mapee las TTPs ejecutadas contra MITRE ATT&CK [8] en el informe final, para poder medir cobertura de detección de forma objetiva y comparable en el tiempo.
- Planifica el Purple Team como fase posterior, no como sustituto: úsalo para cerrar las brechas de detección que el Red Team reveló, con sesiones conjuntas y objetivos de mejora concretos por técnica.
- Documenta el resultado como evidencia de cumplimiento, no solo como informe técnico interno: guárdalo con fecha, alcance, metodología y firma del responsable, porque puede ser solicitado por un auditor ENS, un supervisor DORA o un cliente en un proceso de due diligence.
Errores frecuentes al contratar
Error 1: pedir Red Team sin madurez suficiente
Una organización sin SOC formal, sin EDR y sin runbooks de respuesta no aprovecha un Red Team. El ejercicio se convierte en una "demostración" donde el equipo Red entra en pocos días y nadie se entera, porque no hay nadie observando. El valor obtenido es bajo en relación al coste; un pentest interno con remediación dirigida habría generado más retorno.
Error 2: restringir el Red Team como si fuera un pentest
Limitar el Red Team a "solo de lunes a viernes, solo esta aplicación, avisando antes de cada fase" elimina su valor principal: medir la respuesta ante lo inesperado. Un adversario real no respeta esas reglas, y el ejercicio deja de responder a la pregunta que se pretendía responder.
Error 3: usar el informe de pentest como evidencia de resiliencia organizativa
Un pentest limpio (sin hallazgos críticos) demuestra que una aplicación o red concreta resiste ataques conocidos en ese momento. No demuestra que el SOC detecte un intruso, que el equipo escale correctamente un incidente o que la organización contenga un ataque en curso. Son evidencias de cosas distintas y ningún auditor serio debería aceptar una por la otra.
Error 4: ignorar el marco regulatorio aplicable antes de definir el alcance
Contratar un Red Team genérico cuando la obligación real es un TLPT bajo TIBER-EU (con participación de proveedor de inteligencia de amenazas certificado y coordinación con el supervisor) produce un ejercicio que no sirve como evidencia regulatoria, aunque técnicamente sea sólido. Antes de definir alcance y proveedor, confirma qué exige la norma que te aplica.
Callout — criterio de decisión rápido:
- Si tu madurez defensiva es baja (sin SOC, sin EDR, sin runbooks): pentest + remediación.
- Si tienes SOC 24/7 (propio o MDR), EDR desplegado y respuesta ensayada: Red Team.
- Si eres una entidad financiera identificada como significativa bajo DORA: TLPT bajo TIBER-EU, con proveedor y alcance conforme al Reglamento Delegado (UE) 2025/1190 [3].
- Si quieres mejorar cobertura de detección con un equipo concreto tras un Red Team: Purple Team.
Preguntas frecuentes
¿Un pentest sirve para cumplir con el ENS? Depende de la categoría. El RD 311/2022 exige una auditoría regular al menos cada dos años (art. 31.1), y dentro del Anexo II el refuerzo op.mon.3.R6 (pruebas de penetración) es exigible solo en categoría ALTA, no en MEDIA [1]. Un pentest documentado suele aportarse como evidencia de ese refuerzo, pero no sustituye la auditoría de conformidad completa. Conviene confirmar con el auditor certificador si guías CCN-STIC matizan esta exigencia para categoría media.
¿DORA obliga a hacer Red Team a todas las entidades financieras? No. El TLPT de DORA, regulado por el Reglamento Delegado (UE) 2025/1190 [3], aplica solo a las entidades identificadas como significativas según los criterios de esa norma (tamaño, interconexión, criticidad sistémica). El resto de entidades sujetas a DORA tiene obligaciones de test más ligeras conforme a los artículos 24-25 del Reglamento [2].
¿Qué pasa si en España aún no se ha transpuesto NIS2? A fecha de esta publicación, España no ha completado la transposición de NIS2. La Comisión Europea mantiene un procedimiento de infracción abierto contra España por transposición incompleta de la Directiva NIS2; el estado exacto del procedimiento puede consultarse directamente en el Infringement Decisions Register de la Comisión Europea (ec.europa.eu/atwork/applying-eu-law) o en ec.europa.eu/commission/presscorner [5]. Esto no elimina la obligación futura ni exime de otras normas ya vigentes (ENS, DORA, sectoriales); solo retrasa la exigibilidad directa de las obligaciones específicas de NIS2 hasta que exista ley nacional.
¿Cuánto cuesta un Red Team frente a un pentest? No publicamos cifras de precio genéricas: el coste depende del alcance, la duración, el número de vectores autorizados y si el ejercicio debe ejecutarse bajo un marco regulado como TIBER-EU. Cualquier estimación seria requiere una propuesta comercial con el alcance definido.
¿Puedo pedir un Red Team si no tengo SOC propio? Es posible, pero el valor es limitado: sin capacidad de detección y respuesta (propia o subcontratada, por ejemplo SOCaaS/MDR) el ejercicio tenderá a revelar que la organización no detecta al adversario, algo que probablemente ya se sospechaba. En ese estadio de madurez, un pentest con remediación dirigida suele generar más retorno por euro invertido.
¿Purple Team sustituye al Red Team? No. Purple Team es una forma de ejecutar el trabajo ofensivo y defensivo en colaboración explícita (sesiones conjuntas, retroalimentación inmediata), no un tipo de ejercicio independiente. Se usa como complemento de un Red Team, para cerrar brechas de detección detectadas, o como actividad continua; no reemplaza la validación a ciegas de un Red Team cuando ese es precisamente el objetivo del ejercicio.
Conclusión
Pentest, Red Team, TLPT y Purple Team son herramientas distintas del mismo arsenal, cada una con un marco regulatorio y un nivel de madurez objetivo diferentes. Contratarlas en el momento equivocado — o sin comprobar qué exige realmente la norma aplicable, sea el ENS, DORA o (cuando finalmente se transponga) NIS2 — malgasta presupuesto y puede dejar a la organización sin la evidencia que un auditor, un supervisor o un cliente exigirán. Elegir bien, en cambio, multiplica el valor del ejercicio y genera evidencia defendible ante reguladores, clientes y el propio consejo.
Fuentes
[1] Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad — BOE-A-2022-7191. https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191
[2] Reglamento (UE) 2022/2554 (DORA), artículo 26 — pruebas avanzadas basadas en TLPT. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022R2554
[3] Reglamento Delegado (UE) 2025/1190 de la Comisión, de 13 de febrero de 2025, sobre normas técnicas de regulación relativas al TLPT bajo DORA. https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj
[4] Banco Central Europeo — TIBER-EU Framework. https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
[5] Comisión Europea — Nota de prensa: referencia de España, Irlanda, Francia y Países Bajos al Tribunal de Justicia de la UE por no transponer NIS2, 8 de julio de 2026. https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499
[6] Directiva (UE) 2022/2555 (NIS2), artículo 21. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022L2555
[7] Bank of England — CBEST Threat Intelligence-Led Penetration Testing framework. https://www.bankofengland.co.uk/financial-stability/operational-resilience-of-the-financial-sector
[8] MITRE ATT&CK — matriz de tácticas, técnicas y procedimientos. https://attack.mitre.org/
Fuentes
- [1] Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad — BOE-A-2022-7191. https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191
- [2] Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo (DORA), artículo 26 — pruebas avanzadas basadas en TLPT. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022R2554
- [3] Reglamento Delegado (UE) 2025/1190 de la Comisión, de 13 de febrero de 2025, sobre normas técnicas de regulación relativas al TLPT bajo DORA. https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj
- [4] Banco Central Europeo — TIBER-EU Framework (marco europeo de red teaming basado en inteligencia de amenazas). https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
- [5] Comisión Europea — Procedimiento de infracción contra España por transposición incompleta de la Directiva NIS2. https://ec.europa.eu/atwork/applying-eu-law/infringements-proceedings/infringement_decisions o https://ec.europa.eu/commission/presscorner
- [6] Directiva (UE) 2022/2555 (NIS2), artículo 21 y considerandos sobre gestión de riesgos y pruebas de seguridad. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022L2555
- [7] Bank of England — CBEST Threat Intelligence-Led Penetration Testing framework. https://www.bankofengland.co.uk/financial-stability/operational-resilience-of-the-financial-sector
- [8] MITRE ATT&CK — matriz de tácticas, técnicas y procedimientos (TTPs) de referencia para ejercicios de Red Team. https://attack.mitre.org/
¿Te aplica NIS2?
Autoevalúa en 2 minutos tu alcance NIS2 (esencial/importante/fuera) y qué dominios de la directiva ya cubres.
¿Te ha sido útil este artículo?
Jon Velardiez
Lead Pentester
Responsable de las auditorías ofensivas de Hodeitek: red team y pentesting web, móvil e infraestructura en entornos críticos. Certificado OSCP, OSEP, OSWE, OSWP, CRTE y BSCP.
¿Necesitas ayuda con esto?
Agenda una consulta gratuita con nuestro equipo y revisa cómo aplicarlo a tu organización.
Agendar consulta gratuita