Contratar pentest en Chile 2026: guía CMF

Contratar un servicio de pentesting en Chile en 2026 requiere más que buscar el precio más bajo. El mercado local cuenta con decenas de proveedores que ofrecen "pruebas de penetración", pero la brecha entre un escaneo automático disfrazado de pentest y un ejercicio ofensivo real, ejecutado por profesionales certificados y documentado para satisfacer a los reguladores, es enorme.

Chile tiene uno de los marcos regulatorios de ciberseguridad más exigentes de América Latina. La Comisión para el Mercado Financiero (CMF), la Ley 21.719 de protección de datos personales y la Ley Fintec de 2023 crean obligaciones concretas que van mucho más allá de una política de seguridad en papel. Para bancos, aseguradoras, fintechs, administradoras de fondos y cualquier empresa que procese datos personales a escala, el pentesting ya no es opcional: es evidencia técnica de cumplimiento.

El problema es que muchos proveedores genéricos no conocen la Norma General de Carácter Nº 461 de la CMF, no emiten informes en español con el formato que espera un inspector, y no incluyen retests en sus contratos. Esta guía está escrita para gerentes de tecnología, CISOs y responsables de cumplimiento en empresas chilenas que necesitan tomar una decisión informada y defendible ante su Directorio y ante los reguladores.

El contexto regulatorio que impulsa la demanda de pentesting en Chile

Ley 21.719 — Protección de Datos Personales

La Ley 21.719, vigente desde 2024, exige en su Artículo 38 que los responsables del tratamiento de datos personales implementen medidas de seguridad técnicas proporcionales a los riesgos. Para un análisis detallado del alcance de esta y otras normas, las regulaciones de protección de datos en Chile cubren los requisitos aplicables tanto a la AAPDP como a la CMF. El pentesting es el mecanismo estándar para demostrar que esas medidas funcionan: no basta declarar que se tienen controles, hay que probar que resisten intentos de explotación real. Frente a la Agencia de Protección de Datos Personales (AAPDP), un informe de pentest con hallazgos corregidos y retestados es evidencia sólida de diligencia debida.

CMF Norma General de Carácter Nº 461

La Norma 461 establece los estándares de gestión de riesgos tecnológicos para entidades financieras supervisadas por la CMF. Incluye requerimientos explícitos de pruebas de vulnerabilidades sobre sistemas críticos, con énfasis en la periodicidad, la documentación y la trazabilidad de la remediación. Durante inspecciones, la CMF solicita los informes de pentesting más recientes, los planes de remediación y la evidencia de que las vulnerabilidades críticas fueron cerradas. Un informe incompleto, en inglés o sin trazabilidad de hallazgos puede derivar en observaciones formales.

Ley Fintec 2023 — Seguridad en Open Finance

La Ley Fintec establece los requisitos de seguridad para las APIs de Open Finance que conectan instituciones financieras con proveedores de servicios. Las APIs que exponen datos de cuentas, movimientos y pagos son objetivos de alto valor: el pentesting de APIs bajo estándares OWASP API Security Top 10 es un requisito operativo para operar en este ecosistema y para obtener la autorización de la CMF como proveedor de servicios financieros basados en datos.

El punto crítico para la contratación: el regulador no solo quiere saber si se hizo el pentest, sino cómo, quién lo ejecutó y qué pasó con los hallazgos. Eso define el estándar mínimo que debe cumplir cualquier proveedor que contrate.

Paso 1: Defina el alcance alineado con los requisitos de la CMF

Antes de solicitar propuestas, la organización debe tener claro qué activos entran en el alcance. La CMF habla de "sistemas críticos": aquellos cuya interrupción o compromiso afecta la continuidad operacional, la integridad de los datos financieros o la privacidad de los clientes.

Activos típicos en alcance:

Aplicaciones web (portales de clientes, plataformas de gestión, intranets)
APIs (REST, SOAP, GraphQL) — especialmente las expuestas en Open Finance
Aplicaciones móviles (iOS y Android)
Infraestructura de red (segmentación, firewalls, VPNs)
Entornos cloud (AWS, Azure, GCP: configuración, IAM, exposición de buckets)
Sistemas core banking y sus integraciones (SWIFT, pasarelas de pago)

La distinción más importante: pentesting vs escaneo de vulnerabilidades

Un escaneo automático (Nessus, Qualys, OpenVAS) identifica vulnerabilidades conocidas mediante firmas. Un pentest es un ejercicio manual donde un profesional intenta encadenar vulnerabilidades para lograr un objetivo de negocio (acceso a datos de clientes, movimiento lateral, escalada de privilegios). La CMF acepta ambos como parte de un programa de seguridad, pero solo el pentest demuestra riesgo real y explotabilidad. Confundir los dos conceptos es el error más frecuente que cometen las empresas chilenas.

¿Qué modalidad prefiere la CMF?

Black box: el pentester no recibe información previa. Simula un atacante externo. Útil para validar la superficie de exposición externa.
Gray box: el pentester recibe credenciales de usuario y documentación básica. La modalidad más equilibrada y la que recomienda la CMF para sistemas internos críticos, porque permite profundizar en lógica de negocio y control de accesos.
White box: acceso completo al código fuente, arquitectura y configuración. Ideal para revisiones de seguridad de aplicaciones en desarrollo (SAST + DAST integrado).

Para entidades bancarias, la CMF tiende a valorar ejercicios gray box o white box sobre sistemas core, combinados con un black box externo que cubra la superficie pública.

Alcances específicos por tipo de organización:

Bancos y entidades financieras: core banking (T24, Finacle, sistemas propios), mobile banking, integración SWIFT, portales de inversión.
Fintechs reguladas: APIs de Open Finance, flujos de pago, autenticación OAuth2/OpenID Connect, aplicaciones móviles.
Empresas bajo Ley 21.719: sistemas que almacenan o procesan datos personales a escala (CRMs, plataformas de salud, e-commerce con datos sensibles).

Paso 2: Las certificaciones que importan en Chile

Las certificaciones del equipo son el indicador más objetivo de capacidad técnica. No todas valen igual, y la verificabilidad en línea es crítica para la documentación CMF.

Certificación	Emisor	Verificable online	Relevancia para Chile
OSCP (Offensive Security Certified Professional)	Offensive Security	✅ Sí	Estándar de oro en pentesting ofensivo; examen 100% práctico, 24 horas
OSWE (Offensive Security Web Expert)	Offensive Security	✅ Sí	Profundidad en pentesting de aplicaciones web; relevante para CMF
CRTO (Certified Red Team Operator)	Zero-Point Security	✅ Sí	Operaciones de Red Team, Active Directory, movimiento lateral
OSED / OSEP	Offensive Security	✅ Sí	Explotación avanzada y evasión; equipos especializados
CEH (Certified Ethical Hacker)	EC-Council	✅ Sí	Ampliamente conocido pero de menor rigor técnico que OSCP
Certificaciones de vendor (fabricante)	Varía	❌ Generalmente no	Valor limitado para reguladores; no validan habilidad ofensiva
"Certificaciones locales" no acreditadas	Varía	❌ No	Sin credibilidad ante CMF ni auditorías internacionales

¿Por qué importa la verificabilidad online? Durante una inspección de la CMF o una auditoría interna, el área de cumplimiento puede necesitar demostrar que los pentesters que ejecutaron el trabajo tienen las credenciales declaradas. OSCP, OSWE y CRTO permiten verificar el certificado con número de ID en el sitio del emisor en menos de un minuto. Un proveedor que no puede presentar credenciales verificables en línea representa un riesgo de documentación que puede costarle una observación regulatoria.

Señal de alerta: Proveedores que presentan CVs con certificaciones de fabricante (Cisco, Microsoft, AWS) como prueba de capacidad en pentesting. Esas certificaciones validan conocimiento de producto, no habilidad ofensiva.

Paso 3: Cómo evaluar propuestas de pentesting

Una propuesta de calidad para el mercado chileno debe incluir los siguientes elementos de forma explícita. Para comparar proveedores con criterios objetivos, el checklist de evaluación de proveedores es una herramienta útil antes de tomar la decisión final:

Documento de alcance (Statement of Work):

Lista exacta de objetivos: URLs, rangos IP, nombres de aplicaciones, versiones de APIs
Exclusiones explícitas (qué no se testea y por qué)
Entornos: ¿producción, staging, o ambos? (la CMF acepta staging documentado si es representativo)

Metodología documentada:

OWASP Testing Guide (aplicaciones web y APIs)
PTES (Penetration Testing Execution Standard)
NIST SP 800-115 (para marcos de cumplimiento)
Alineación con MITRE ATT&CK para ejercicios de Red Team

Equipo y credenciales:

Nombres de los pentesters asignados (no un "equipo" anónimo)
Certificaciones verificables (OSCP, OSWE, CRTO)
Experiencia demostrable con el tipo de tecnología en alcance

Cronograma realista:

Un pentest serio para alcance mediano (3-5 aplicaciones web + APIs) requiere entre 2 y 4 semanas. Desconfíe de propuestas que prometen resultados en 3-5 días hábiles para ese alcance: es un escaneo automático.

Formato del informe:

Resumen ejecutivo en español para el Directorio
Hallazgos técnicos con puntuación CVSS v3.1
Evidencia (capturas de pantalla, fragmentos de código, solicitudes/respuestas HTTP)
Recomendaciones de remediación en español
Plan de retest estructurado

Reglas de compromiso (Rules of Engagement):

Ventanas horarias autorizadas para testing intrusivo
Contactos de emergencia (técnico y gerencial) en caso de incidente
Procedimiento si se descubre una vulnerabilidad crítica activa

Retests:

¿Están incluidos en el precio o se cobran aparte? Para cumplimiento CMF, los retests son obligatorios, no opcionales. Un contrato que no los incluye incrementa el costo total de forma significativa.

Señales de alerta en propuestas:

Precio inferior a USD $3,000 para un alcance significativo — implica escaneo automatizado, no pentest
Sin pentesters nombrados en la propuesta
Informes solo disponibles en inglés
Sin retest incluido en el contrato
Cronograma inferior a una semana para alcance real
Sin metodología documentada (o referencia genérica sin detalle)
Sin contrato formal con reglas de compromiso firmadas
Sin plataforma de entrega de resultados — solo reporte en PDF sin trazabilidad

Paso 4: Calidad del informe y requisitos de documentación de la CMF

El informe de pentesting es el artefacto que defiende a la organización ante la CMF. Un informe de baja calidad puede convertir un ejercicio técnico costoso en documentación inútil para el regulador.

Lo que la CMF espera ver en un informe:

Resumen ejecutivo en español, sin jerga técnica, que permita al Directorio entender el nivel de riesgo y las decisiones tomadas
Hallazgos clasificados por criticidad (Crítico, Alto, Medio, Bajo, Informativo) con puntuación CVSS 3.1 y justificación
Evidencia reproducible: capturas de pantalla que muestran el acceso logrado, requests/responses HTTP capturados, fragmentos de código explotado, paso a paso del ataque
Impacto de negocio: no solo "SQL Injection encontrado", sino "SQL Injection en módulo de autenticación que permite acceso a todos los datos de clientes sin credenciales"
Recomendaciones de remediación en español, priorizadas, con referencias a estándares (OWASP, CIS, NIST)
Plan de retest: fechas propuestas, hallazgos que se verificarán, criterios de cierre

La diferencia entre un informe que satisface a la CMF y uno que solo parece profesional: la trazabilidad. El inspector quiere ver que cada hallazgo tiene un ID único, una fecha de descubrimiento, el estado de remediación (abierto, en proceso, cerrado) y la evidencia del retest. Un PDF de 80 páginas sin estructura de seguimiento no cumple ese estándar.

Las plataformas SaaS de gestión de pentesting (como la que utiliza WhiteJaguars) resuelven este problema: los hallazgos se registran en una plataforma con historial, comentarios del equipo de desarrollo, evidencia del fix y evidencia del retest. El área de cumplimiento puede exportar el estado actualizado en cualquier momento, sin esperar al informe final.

Paso 5: Remediación, retests y cumplimiento continuo

El pentesting no termina con la entrega del informe. Para la CMF y para la Ley 21.719, lo que cuenta es el cierre de vulnerabilidades, no su descubrimiento.

Por qué los retests son no negociables:

Un hallazgo de inyección SQL o una misconfiguration en un bucket S3 no desaparece porque el equipo de desarrollo diga que lo corrigió. El retest verifica que la remediación es efectiva y no introduce nuevas vulnerabilidades. Sin retest documentado, la CMF puede considerar el ciclo como incompleto.

Manejo de hallazgos críticos durante el engagement:

Un proveedor profesional no espera al informe final para notificar una vulnerabilidad crítica. Si durante el pentest se descubre acceso no autorizado a datos de clientes, credenciales expuestas en repositorios públicos, o una vulnerabilidad de Remote Code Execution explotable, el protocolo debe ser notificación inmediata (dentro de las primeras horas) para que el equipo interno pueda contener el riesgo antes de que finalice el ejercicio.

Integración con el ciclo regulatorio de la CMF:

Las entidades supervisadas por la CMF deben presentar reportes periódicos de gestión de riesgo tecnológico. El pentest anual debe planificarse con suficiente anticipación para que los resultados y el cierre de hallazgos estén disponibles antes del corte de reporte regulatorio. Un calendario típico para una entidad financiera chilena:

Q1: Pentest de sistemas críticos (core banking, portal de clientes)
Q2: Remediación y retest
Q3: Pentest de APIs y aplicaciones secundarias / Red Team si aplica
Q4: Revisión de cumplimiento, actualización del registro de riesgos, preparación de reporte CMF

Pentesting continuo vs puntual:

Para organizaciones con ciclos de desarrollo ágil (sprints quincenales, nuevas features frecuentes, integración con terceros vía APIs), el modelo puntual (un pentest al año) es insuficiente. El modelo PTaaS (Penetration Testing as a Service) provee cobertura continua: un equipo dedicado testea cambios significativos a medida que se despliegan, con acceso permanente a la plataforma de hallazgos. Para fintechs con Open Finance activo, este modelo es la opción más alineada con el riesgo real.

Rangos de precios en el mercado chileno 2026

Los precios en el mercado chileno varían ampliamente, y la confusión entre escaneos automáticos y pentesting real distorsiona las expectativas. A continuación, rangos reales para 2026, expresados en USD:

Servicio	Rango aproximado	Nota
Escaneo de vulnerabilidades (no es pentest)	USD $500 – $2,000	No suficiente para CMF como evidencia de pentesting
Pentest básico de aplicaciones web (1-3 apps)	USD $3,000 – $8,000	Gray box, 2 semanas, retest incluido
Pentest web + APIs (alcance mediano)	USD $6,000 – $15,000	Metodología OWASP + PTES, informe CMF-ready
Pentest completo (web + API + móvil + infraestructura)	USD $12,000 – $30,000+	Alcance amplio, 3-5 semanas, ideal para bancos y entidades financieras
Red Team engagement (simulación de amenaza avanzada)	USD $20,000 – $60,000+	Incluye reconocimiento, OSINT, movimiento lateral, evasión de EDR
PTaaS (suscripción anual, cobertura continua)	Variable según alcance	Modelo recomendado para fintechs y entidades con desarrollo ágil

Advertencia importante: el precio no debe ser el criterio principal. Un pentest de $1,500 que entrega un reporte de escaneo automático en PDF sin evidencia manual no cumple ningún requisito de la CMF. El costo de una observación regulatoria por documentación insuficiente, o de una brecha de seguridad por vulnerabilidades no detectadas, supera ampliamente la diferencia de precio entre un proveedor económico y uno de calidad.

Gobernanza interna y la CMF: cómo estructurar el proceso de pentesting

¿Quién debe ser el dueño interno del pentest?

En entidades supervisadas por la CMF, la responsabilidad suele recaer en el CISO o en el área de Tecnología, con supervisión del área de Cumplimiento. Es un error delegarlo exclusivamente a TI sin involucramiento de Cumplimiento: el regulador evalúa el pentest como parte del sistema de control interno, no solo como una actividad técnica.

Presentación al Directorio:

La Norma 461 establece que la alta administración debe estar informada sobre los riesgos tecnológicos. El resumen ejecutivo del informe de pentesting debe ser presentado al Directorio o al Comité de Riesgos, incluyendo: número de hallazgos por criticidad, hallazgos críticos y su estado de remediación, plan de cierre y cronograma. Una presentación de 5-10 diapositivas basada en el resumen ejecutivo del proveedor es el formato más común.

Preparación para inspecciones CMF:

Mantenga un archivo de evidencia con: el contrato de pentesting firmado (con alcance y reglas de compromiso), el informe completo más reciente, el registro de remediación con evidencia de cierre, y los informes de retest. Organícelo por año fiscal para facilitar la recuperación durante una inspección.

Integración con el SGSI:

Los hallazgos del pentest deben alimentar el Sistema de Gestión de Seguridad de la Información (basado en ISO 27001 o equivalente) y el registro de riesgos empresarial. Una vulnerabilidad crítica no cerrada es un riesgo activo que debe aparecer en el risk register con propietario, plan de tratamiento y fecha límite.

Señales de alerta: proveedores que debe evitar

No tienen metodología documentada. Un proveedor serio puede describir en detalle qué herramientas usa, en qué orden, y cómo complementa el trabajo manual con el automatizado.
Solo realizan escaneos automáticos y los llaman "pentest". Solicite ejemplos de informes; si no hay evidencia de trabajo manual (cadenas de explotación, bypass de controles, escaladas de privilegio), es un escaneo.
No incluyen retests en el contrato. El retest debe estar explícitamente incluido en el precio y en el alcance.
Sus informes están solo en inglés o no tienen formato para reguladores. La CMF espera documentación en español y con un resumen ejecutivo accesible para no técnicos.
No pueden verificar las certificaciones de sus pentesters online. Solicite los números de certificación y verifíquelos en el sitio del emisor antes de firmar.
No tienen experiencia demostrable con la CMF o la Ley 21.719. Solicite referencias de clientes en sectores regulados en Chile; los proveedores serios las tienen.
El precio es anormalmente bajo. Por debajo de USD $3,000 para un alcance significativo, la matemática no da para trabajo manual de calidad.
No tienen contrato formal con reglas de compromiso. Sin un documento firmado que defina el alcance autorizado y los protocolos de emergencia, la organización asume riesgos legales y operacionales innecesarios.

Preguntas frecuentes

¿Cuánto tiempo toma un pentest completo para una empresa chilena regulada por la CMF?

Para una entidad financiera mediana con 3-5 aplicaciones web, APIs de Open Finance y una aplicación móvil, el cronograma realista es de 3 a 5 semanas: 2-3 semanas de ejecución activa, más 1-2 semanas para informe y retest. Alcances más amplios (core banking + infraestructura + Red Team) pueden tomar 6-10 semanas. Desconfíe de propuestas que prometen resultados completos en menos de una semana para ese tipo de alcance: los tiempos cortos son la señal más clara de trabajo automatizado.

¿Puede una empresa hacer pentesting interno o siempre debe ser externo?

La CMF no prohíbe el pentesting interno, pero para que sea aceptable como evidencia regulatoria debe cumplir con independencia funcional: el equipo de seguridad no puede testear sistemas que administra o desarrolla. En la práctica, la mayoría de las entidades financieras chilenas complementan un pentest externo anual (que satisface a la CMF por su independencia) con revisiones internas continuas. Para empresas bajo Ley 21.719, el pentesting externo es la práctica más defensible ante la AAPDP en caso de incidente.

¿Qué pasa si el pentesting encuentra vulnerabilidades críticas durante el proceso?

Un proveedor profesional tiene un protocolo de notificación inmediata: si durante el ejercicio se descubre una vulnerabilidad explotable de impacto crítico (acceso a datos de clientes, RCE, bypass de autenticación), notifica al contacto técnico y gerencial del cliente dentro de las primeras horas. No se espera al informe final. La organización puede activar su proceso de respuesta a incidentes en paralelo con el pentest. Este protocolo debe estar documentado en las reglas de compromiso firmadas antes de iniciar el ejercicio.

¿Con qué frecuencia debo contratar pentesting para cumplir con la CMF y la Ley 21.719?

La CMF Norma 461 establece pruebas periódicas; la práctica aceptada para entidades financieras es un pentest anual como mínimo, con pruebas adicionales ante cambios significativos (nuevas funcionalidades, migraciones de infraestructura, integraciones con terceros). La Ley 21.719 no establece una frecuencia específica, pero el principio de proporcionalidad implica que organizaciones que procesan datos sensibles a escala deben demostrar revisiones regulares. Para fintechs con APIs de Open Finance activas y ciclos de desarrollo continuos, el modelo PTaaS (testing continuo) es la respuesta más alineada tanto al riesgo como al cumplimiento.

Qué considerar al elegir un proveedor de pentesting en Chile

Antes de iniciar el proceso de evaluación, vale la pena revisar qué opciones existen en el mercado: las mejores empresas de pentesting en Chile comparan los proveedores más relevantes por certificaciones, metodología y experiencia con los reguladores locales.

Navegar los requisitos de la CMF Norma 461, la Ley 21.719 y la Ley Fintec requiere un proveedor que entienda tanto la técnica ofensiva como el contexto regulatorio chileno: metodología documentada (PTES, OWASP, MITRE ATT&CK), informes en español estructurados para el Directorio y para inspecciones de la CMF, retests ilimitados incluidos en el contrato, y una plataforma SaaS con trazabilidad completa de hallazgos. WhiteJaguars, una firma centroamericana con especialización en seguridad ofensiva, aplica esa metodología y cuenta con un equipo certificado en OSCP, CISSP, CEH y CISM, entre otras.

Cómo contratar pentesting en Chile: guía práctica 2026