Ethical Hacking y Normativas Internacionales: Las Regulaciones que Exigen Pruebas de Intrusión

¿El ethical hacking ayuda a cumplir normativas? Sí. Un pentest ejecutado por un tercero independiente, con autorización por escrito y un informe auditable, es la evidencia técnica que las principales regulaciones esperan ver cuando exigen comprobar que sus controles de seguridad funcionan. Pero hay un matiz crítico: ninguna norma dice que aprobar un pentest equivale a estar en cumplimiento. El pentest demuestra; el cumplimiento se construye con procesos.

En hacking ético, la prueba de intrusión no es el destino: es el instrumento de medición. Lo que sigue es una guía marco por marco para entender qué exige cada regulación, qué papel juega el pentest como evidencia y qué necesita su informe para pasar una auditoría.

El punto que casi todos entienden al revés

La confusión más frecuente en directorios y comités de cumplimiento es creer que contratar un pentest anual "cubre" la seguridad. No funciona así. Las normativas se dividen en dos grupos:

• Regulaciones prescriptivas que exigen pruebas de intrusión por nombre y con frecuencia definida (PCI DSS).
• Regulaciones basadas en principios que exigen medidas de seguridad técnicas apropiadas y la capacidad de demostrar su eficacia (ISO 27001, GDPR, LGPD, CPRA y las leyes latinoamericanas).

En el segundo grupo, el pentest no es obligatorio por ley, pero es la forma más sólida de demostrar que sus medidas "apropiadas" realmente funcionan. Un auditor no se conforma con una política firmada: quiere evidencia de que el control opera. Esa es la diferencia entre declarar seguridad y demostrarla.

PCI DSS: el único marco que exige el pentest por nombre

Si su empresa almacena, procesa o transmite datos de tarjetas, PCI DSS (actualmente en la versión 4.0.1, administrado por el PCI Security Standards Council) es el marco más exigente con las pruebas de intrusión. El requisito 11.4 las manda de forma explícita (pcisecuritystandards.org):

• 11.4.2 — Pentest interno: al menos una vez cada 12 meses y después de cualquier cambio significativo en la infraestructura o las aplicaciones.
• 11.4.3 — Pentest externo: misma frecuencia, desde internet contra el perímetro. Puede ejecutarlo un recurso interno cualificado o un tercero independiente, con independencia organizativa respecto a quien opera los sistemas.
• 11.4.1 — Metodología documentada: basada en enfoques aceptados por la industria, como NIST SP 800-115, la Guía de Pruebas de OWASP o PTES.
• 11.4.4 — Remediación y retest: las vulnerabilidades explotables encontradas deben corregirse y las correcciones deben verificarse repitiendo la prueba. Sin retest, el ciclo queda incompleto.
• 11.4.5 — Pruebas de segmentación: si usa segmentación para reducir el alcance del entorno de datos de titulares (CDE), debe probar esos controles al menos una vez al año (cada 6 meses para proveedores de servicios).

Un detalle que genera no conformidades: el requisito 11.3.2 exige escaneos externos de vulnerabilidades trimestrales por un proveedor aprobado (ASV), pero el estándar distingue explícitamente entre escaneo y pentest. Un escaneo automatizado identifica vulnerabilidades; un pentest las explota de forma controlada para demostrar el impacto. Los escaneos no sustituyen el pentest, ni viceversa.

ISO/IEC 27001: el pentest como evidencia del SGSI

La norma ISO/IEC 27001 no utiliza la palabra "penetration test" como requisito obligatorio, pero dos controles del Anexo A lo convierten en una expectativa práctica de los auditores (iso.org):

• A.8.8 — Gestión de vulnerabilidades técnicas: la organización debe obtener información sobre vulnerabilidades en los sistemas en uso, evaluar su exposición y tomar medidas apropiadas. Un programa de escaneo sin pruebas de explotación deja huecos en esa evaluación.
• A.8.29 — Pruebas de seguridad en el desarrollo y la aceptación: las pruebas de funcionalidad de seguridad deben realizarse durante el desarrollo, antes de liberar sistemas a producción.

La guía de implementación ISO/IEC 27002:2022 del control 8.8 indica que las organizaciones deberían realizar pruebas de intrusión periódicas y documentadas, por personal interno o por un tercero independiente. Además, la cláusula 9.1 (seguimiento, medición, análisis y evaluación) obliga al SGSI a demostrar que sus controles técnicos realmente funcionan, no solo que están documentados.

En la práctica de certificación, el auditor de etapa 2 pedirá los informes de las últimas pruebas: alcance, metodología, hallazgos, plan de remediación con responsables y fechas, y el retest. Un informe de pentest profesional es, literalmente, la evidencia que responde a esas preguntas.

GDPR: la obligación de probar que las medidas funcionan

El Reglamento (UE) 2016/679 no nombra el pentest, pero el artículo 32 sobre seguridad del tratamiento exige al responsable implementar medidas técnicas y organizativas apropiadas, incluyendo "un proceso para verificar, evaluar y valorar regularmente la eficacia de las medidas técnicas y organizativas" (eur-lex.europa.eu). Es exactamente lo que hace un pentest periódico: verificar eficacia, no declarar intenciones.

El artículo 35 añade la Evaluación de Impacto (EIPD) cuando el tratamiento entraña alto riesgo para los derechos de las personas. Si su organización procesa datos de ciudadanos europeos —clientes, empleados o proveedores—, un programa de pruebas documentado es la forma de demostrar diligencia debida ante una autoridad de control después de una brecha.

LGPD (Brasil): medidas de seguridad verificables

La Ley 13.709/2018 de Brasil establece un esquema similar al europeo, con la ANPD (Autoridade Nacional de Proteção de Dados) como órgano de aplicación (anpd.gov.br):

• Artículo 44: el tratamiento de datos personales es irregular cuando no ofrece la seguridad que de él se espera legítimamente.
• Artículo 46: los agentes de tratamiento deben adoptar medidas de seguridad, técnicas y administrativas, aptas para proteger los datos personales.
• Artículo 48: los incidentes de seguridad deben comunicarse a la ANPD y a los titulares.

Brasil no exige pentests por nombre, pero el artículo 44 convierte la "seguridad esperada" en un estándar objetivo: en un litigio o investigación, demostrar que probaba periódicamente sus controles con un tercero independiente es la diferencia entre diligencia y negligencia. Para empresas con operación en Brasil, el pentest es evidencia de cumplimiento ante la ANPD.

CPRA y las leyes latinoamericanas: el principio se repite

California (CPRA/CCPA)

La ley de privacidad de California, reformada por la CPRA, otorga a los consumidores el derecho de acción privada cuando una brecha se produce por no implementar medidas de seguridad razonables, y creó la California Privacy Protection Agency como organismo de aplicación. No prescribe pentests, pero "medidas de seguridad razonables" es precisamente lo que un programa de pruebas documentado ayuda a acreditar.

América Latina

En la región, el panorama es de principios equivalentes sin mandato explícito de pentest: Colombia (Ley 1581 de 2012), México (LFPDPPP), Argentina (Ley 25.326) y Chile —que reformó su ley de datos personales con la Ley 21.719, creando una agencia especializada de protección de datos— exigen medidas técnicas y organizativas apropiadas. En todos los casos, el pentest cumple la misma función: convertir la afirmación "tenemos medidas de seguridad" en evidencia auditable.

Qué debe contener su informe para que sirva como evidencia

No todo informe de pentest sirve ante un auditor. Para que su prueba funcione como evidencia de cumplimiento, exija estos elementos:

• Alcance definido por escrito: sistemas, aplicaciones, rangos de red y período de la prueba. Un alcance ambiguo invalida la evidencia.
• Autorización explícita firmada: todo pentest legítimo opera con permiso documentado del propietario de los sistemas. Sin autorización, no es hacking ético: es un ataque.
• Metodología reconocida: basada en enfoques aceptados por la industria (NIST SP 800-115, Guía de Pruebas de OWASP, PTES). Conozca las metodologías de hacking ético que debe exigir a su proveedor.
• Hallazgos con criticidad y prueba: cada vulnerabilidad con su severidad, evidencia de explotación controlada e impacto de negocio.
• Plan de remediación con responsables y fechas: el informe debe cerrar el ciclo, no solo abrirlo.
• Retest documentado: PCI DSS lo exige explícitamente; para los demás marcos es la prueba de que la remediación funcionó.

Un informe ejecutivo para la dirección y un informe técnico para el equipo son el formato que los auditores esperan encontrar. Aprenda cómo elegir un servicio de ethical hacking que entregue ambos niveles de reporte.

Errores frecuentes que invalidan su evidencia

1. Confundir escaneo con pentest. El escaneo automatizado enumera vulnerabilidades; el pentest las explota de forma controlada. Las normativas los tratan como actividades distintas: necesita ambos.
2. Probar sin autorización escrita. Además de invalidar la evidencia, expone a responsabilidad legal. La autorización es la línea que separa el ethical hacking del delito informático.
3. El pentest anual como único control. Las pruebas son una fotografía en un momento dado. Sin monitoreo continuo y gestión de vulnerabilidades entre pruebas, la evidencia envejece rápido.
4. No remediar ni retestear. Un informe con hallazgos abiertos es, para un auditor, la confesión documentada de que conocía el riesgo y no actuó.
5. Elegir al proveedor por precio. Un informe de baja calidad no sobrevive una auditoría de etapa 2 ni una investigación regulatoria. Exija metodología, independencia y reportes auditables, y solicite una evaluación inicial sin compromiso.

Preguntas frecuentes

¿Basta con un pentest para cumplir PCI DSS?

No. El pentest es obligatorio bajo el requisito 11.4, pero PCI DSS cubre también gestión de vulnerabilidades, control de accesos, cifrado, registro y monitoreo, entre otros. El pentest es una pieza necesaria, no el programa completo.

¿Cada cuánto debo hacer un pentest?

PCI DSS exige al menos uno anual más uno adicional después de cada cambio significativo. Para ISO 27001, GDPR y LGPD no hay una frecuencia fijada por norma: la define su análisis de riesgos. La práctica habitual es un pentest anual como mínimo, más pruebas adicionales ante cambios mayores en infraestructura o aplicaciones.

¿Un escaneo de vulnerabilidades reemplaza al pentest?

No. El escaneo identifica vulnerabilidades de forma automatizada; el pentest las explota de forma controlada para demostrar el impacto real. PCI DSS los exige por separado (requisitos 11.3 y 11.4), y esa distinción es válida para todos los marcos.

¿Quién debe ejecutar el pentest para que el auditor lo acepte?

PCI DSS permite un recurso interno cualificado o un tercero externo, siempre que exista independencia organizativa respecto a quien opera y protege los sistemas. Para los demás marcos, un tercero independiente aporta la objetividad que los auditores y reguladores valoran. Conozca nuestros servicios de ethical hacking.

¿El informe de pentest sirve como evidencia en una certificación ISO 27001?

Sí. Es evidencia directa de los controles A.8.8 (gestión de vulnerabilidades técnicas) y A.8.29 (pruebas de seguridad en desarrollo y aceptación), y de la cláusula 9.1 sobre evaluación de la eficacia de los controles.

¿Las leyes de América Latina exigen pentest?

Ninguna lo nombra explícitamente. Exigen medidas de seguridad técnicas y organizativas apropiadas. El pentest funciona como evidencia de que esas medidas existen y funcionan, lo cual es relevante ante superintendencias de datos, autoridades de protección de datos y en procesos judiciales tras una brecha.

Convierta su próxima auditoría en un trámite, no en un riesgo

Si su empresa maneja datos de tarjetas, datos personales de clientes o sistemas críticos, la pregunta no es si necesita pruebas de intrusión, sino si las que tiene generan evidencia que un auditor acepta. Contáctenos para una evaluación inicial: definimos el alcance, la metodología y los entregables alineados con el marco normativo que usted debe cumplir.

Solicitar una propuesta