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

Cómo contratar un servicio de pentesting en Panamá: guía práctica (2026)

Contratar un servicio de pentesting en Panamá sigue un proceso de seis pasos: definir el alcance, entender si existe un requerimiento regulatorio, evaluar propuestas con criterios técnicos claros, formalizar la relación contractual, coordinar la ejecución de las pruebas, y hacer seguimiento de la remediación con retest. Si se salta alguno de estos pasos, el dinero invertido en el pentest produce mucho menos valor del que podría.

Esta guía está escrita para directores de tecnología, CISOs y gerentes de operaciones de empresas panameñas — desde fintechs supervisadas por la SBP hasta empresas de logística de la Zona Libre de Colón, pasando por entidades del sector financiero y servicios profesionales — que necesitan contratar su primer pentest o mejorar la manera en que gestionan los siguientes.

Paso 1: Definir el alcance antes de hablar con proveedores

El error más frecuente al iniciar un proceso de contratación de pentesting es pedirle al proveedor que defina el alcance. El proveedor puede orientarlo, pero usted debe llegar a la primera conversación con una lista preliminar de activos a evaluar. Sin un alcance claro, las propuestas que reciba serán incomparables entre sí y no podrá saber si está pagando por la misma cobertura.

Tipos de pentest por superficie de ataque

Aplicaciones web: Sus portales, sistemas de gestión, plataformas de clientes, paneles administrativos accesibles por navegador. El alcance debe especificar la cantidad de aplicaciones, la cantidad de roles de usuario a probar (cliente, operador, administrador, superadmin) y si se incluye el código fuente para revisión estática.

Aplicaciones móviles: Si tiene apps iOS y/o Android para clientes o empleados. El alcance debe especificar si se incluye análisis estático (APK/IPA desensamblado), análisis dinámico (runtime), o ambos.

Infraestructura de red: Servidores en datacenter o nube, dispositivos de red, VPNs, Active Directory / LDAP, sistemas OT/SCADA si aplica. Para redes corporativas, el alcance debe delimitar rangos IP incluidos.

Infraestructura cloud: Configuraciones de AWS, GCP o Azure — IAM, S3 buckets, security groups, funciones Lambda, configuraciones de bases de datos administradas. Este es un alcance separado y especializado del pentest de red tradicional.

Ingeniería social: Phishing simulado a empleados, pretexting telefónico, o pruebas físicas (acceso a instalaciones). Requiere autorización expresa de la dirección y protocolos claros de manejo de resultados.

Social engineering y phishing: Campañas de phishing controladas al personal, con métricas de tasas de clic, entrega de credenciales y descarga de adjuntos. Valioso para organizaciones que manejan información sensible de clientes o fondos.

Definición de ambiente: producción vs. staging

Idealmente, el pentest se realiza en un ambiente de staging que replique producción. Sin embargo, para muchas empresas panameñas el staging no existe o no es representativo. En ese caso, el pentest en producción es válido — pero requiere coordinación más cuidadosa (ver Paso 5) y algunas técnicas de explotación deben moderarse para evitar impacto operacional.

Paso 2: Contexto regulatorio — ¿quién le exige el pentest?

En Panamá, el requerimiento de evaluaciones de seguridad puede provenir de varias fuentes. Identificar cuál aplica a su empresa determina el tipo de entregable que necesita del proveedor.

Superintendencia de Bancos de Panamá (SBP)

Los emisores de dinero electrónico (EDE) bajo el Acuerdo 5-2022 deben demostrar controles activos de ciberseguridad, incluyendo evaluaciones periódicas de vulnerabilidades y pruebas de penetración. La SBP puede solicitar evidencia de estas evaluaciones durante inspecciones de riesgo operativo. El reporte del pentest debe tener formato ejecutivo y técnico, y debe poder presentarse ante el inspector sin necesidad de que el proveedor esté presente para explicarlo.

Bancos, aseguradoras y otras entidades supervisadas por la SBP, SSRP o la Superintendencia de Valores también pueden estar sujetos a requerimientos de evaluación de seguridad dentro de sus marcos de gestión de riesgo operativo.

Autoridad Nacional para la Innovación Gubernamental (AIG)

La AIG emite lineamientos de seguridad para entidades del Estado y proveedores que procesan datos gubernamentales. Si su empresa provee tecnología o servicios al gobierno panameño, es probable que deba demostrar evaluaciones de seguridad periódicas.

Contratos con bancos y procesadores de pago

Si su empresa se integra con bancos panameños para pagos, desembolsos o cobros, el banco puede exigir como condición contractual la presentación de un pentest reciente. Este tipo de requerimiento es cada vez más frecuente en contratos de adquirencia y en acuerdos de open banking.

PCI DSS

Si procesa datos de tarjetas de crédito o débito, PCI DSS es un requerimiento de las redes de pago (Visa, Mastercard) que incluye pruebas de penetración anuales como control explícito (Requisito 11.4 de PCI DSS v4.0). El pentest debe ser realizado por un proveedor con experiencia en PCI y el reporte debe mapear los hallazgos contra los controles del estándar. Más allá de PCI, las regulaciones de protección de datos en Panamá imponen obligaciones específicas de seguridad a quienes tratan datos personales, y el pentest es la evidencia técnica más directa para demostrar que esas medidas son efectivas.

Requerimiento propio (sin mandato externo)

Muchas empresas panameñas contratan pentests sin que un regulador los exija — como parte de un programa propio de gestión de riesgos de seguridad, antes de un lanzamiento de producto, o como due diligence ante una inversión o adquisición. En este caso, usted tiene más libertad para definir el alcance y el formato del reporte según sus necesidades internas.

Paso 3: Evaluar propuestas con criterios técnicos

Una vez que tiene el alcance definido y sabe qué necesita demostrar (si aplica), puede solicitar propuestas formales. Estos son los criterios que determinan si una propuesta es técnicamente sólida:

Metodología explícita

Un proveedor serio describe la metodología que usará: OWASP Testing Guide para aplicaciones web, OWASP MASVS para mobile, PTES o OSSTMM para infraestructura, OWASP API Security Top 10 para APIs. Si la propuesta solo dice "usamos herramientas líderes de la industria" sin especificar metodología, es una señal de alerta. Para orientar la evaluación con criterios objetivos, el checklist de evaluación de proveedores reúne los puntos de verificación más relevantes antes de firmar un contrato.

Credenciales del equipo que ejecutará el trabajo

Las certificaciones de seguridad ofensiva más reconocidas — OSCP (Offensive Security Certified Professional), GPEN (GIAC Penetration Tester), CRTO (Certified Red Team Operator) — son verificables en línea directamente en los registros de los organismos certificadores. Solicite los nombres de los pentesters que realizarán el trabajo y verifique sus certificaciones. No es suficiente que la empresa tenga certificaciones: los individuos que ejecutan el pentest deben tenerlas.

Entregables definidos

La propuesta debe describir con precisión qué recibirá al final: reporte ejecutivo (para dirección y regulador), reporte técnico (para el equipo de desarrollo/infraestructura), y evidencia de cada hallazgo (capturas de pantalla, request/response HTTP, descripción de pasos para reproducir). Sin estos entregables definidos por escrito, el reporte puede entregarse en un formato que no sea utilizable para sus necesidades.

Política de retests

¿El proveedor incluye retests para verificar que los hallazgos críticos fueron corregidos? ¿Cuántos retests están incluidos? ¿En qué plazo? Un pentest sin retest es incompleto — no sabe si su equipo realmente cerró la brecha o solo modificó algo superficialmente.

SLA y tiempos de entrega

¿Cuántas semanas toma la ejecución? ¿Cuántos días hábiles para entregar el reporte final después de terminar las pruebas? Un proyecto que empieza pero no tiene fecha de entrega del reporte puede extenderse indefinidamente.

Paso 4: Aspectos legales y contractuales

Antes de que cualquier prueba comience, deben estar firmados estos documentos:

Acuerdo de No Divulgación (NDA)

El NDA protege la información de su empresa que el proveedor accederá durante el pentest: arquitectura de sistemas, credenciales temporales, datos de clientes de prueba, hallazgos de vulnerabilidades. El NDA debe ser bidireccional y especificar obligaciones de confidencialidad incluso después de terminado el contrato.

Autorización de pruebas (Rules of Engagement)

Este documento es tan importante como el NDA. Define con precisión:

• Qué sistemas están en alcance y cuáles están explícitamente excluidos
• Ventanas de tiempo autorizadas para las pruebas
• Qué técnicas de explotación están permitidas y cuáles están limitadas (por ejemplo, denegación de servicio generalmente está fuera de alcance)
• Qué hacer si se descubre un acceso a sistemas de terceros no relacionados con el alcance
• Contactos de emergencia en caso de impacto no anticipado
• Condiciones bajo las cuales el proveedor debe pausar las pruebas inmediatamente

Sin este documento, el proveedor opera en un vacío legal — y su empresa también. En caso de un incidente no anticipado durante las pruebas, la ausencia de una autorización formal escrita complica enormemente la gestión.

Definición de responsabilidades en caso de impacto

¿Qué ocurre si una prueba genera indisponibilidad de un sistema en producción? ¿Quién asume los costos de recuperación? Esto debe estar regulado en el contrato de servicios, no asumido implícitamente.

Paso 5: Durante la ejecución de las pruebas

Contacto de punto único

Designe un punto de contacto técnico interno (generalmente el CTO, el líder de infraestructura, o el CISO) que esté disponible durante el período de pruebas para responder preguntas del equipo de pentest, validar hallazgos que requieran contexto, y tomar decisiones si surge algo inesperado.

Triggers de incidente

Defina con antelación qué condiciones activan una pausa inmediata de las pruebas y una llamada de emergencia:

• El proveedor accede a datos reales de clientes que no debería haber encontrado en el ambiente de pruebas
• Un sistema crítico muestra comportamiento anómalo durante las pruebas
• El equipo de pentest identifica un acceso externo no autorizado al sistema (es decir, hay un atacante real presente además del equipo de pentest)

Este último escenario — raro pero no imposible — requiere que las pruebas se detengan y que el incidente real sea gestionado antes de continuar.

Comunicación de hallazgos críticos en tiempo real

Un buen proveedor no espera al reporte final para comunicar hallazgos críticos. Si durante las pruebas se identifica una vulnerabilidad de severidad crítica (por ejemplo, ejecución remota de código sin autenticación, o acceso a la base de datos de clientes), debe comunicársela al punto de contacto interno de inmediato — no en dos semanas cuando entregue el reporte.

Paso 6: Después del pentest — remediación y retest

El reporte es el inicio del trabajo, no el final. El valor real del pentest está en la remediación.

Sesión de lectura del reporte

Solicite una sesión de presentación donde el equipo de pentest explique los hallazgos más críticos al equipo técnico y a la dirección. Esto es especialmente importante si hay hallazgos que afectan decisiones de arquitectura o que requieren inversión significativa para corregir.

Priorización por riesgo real

No todos los hallazgos son iguales. La prioridad de remediación debe basarse en el riesgo real para su negocio, no solo en el CVSS score automático. Una vulnerabilidad de severidad media en un endpoint que procesa pagos puede ser más urgente que una crítica en un sistema interno sin datos sensibles.

Retest formal

Una vez que su equipo ha implementado las correcciones, el proveedor debe ejecutar un retest específico sobre los hallazgos cerrados. El retest confirma que la corrección es efectiva — no solo que se cambió algo en el código. El resultado del retest debe documentarse en un addendum al reporte original, porque ese addendum es lo que le muestra al regulador o al auditor que los hallazgos fueron cerrados.

Errores frecuentes de empresas panameñas al contratar pentesting

Confundir vulnerability scanning con pentesting

Un escáner automático (Nessus, OpenVAS, Qualys) identifica vulnerabilidades conocidas basándose en firmas. No simula un ataque real, no prueba la lógica de negocio, no explota vulnerabilidades para verificar su impacto real, y no descubre vulnerabilidades que requieran encadenamiento de técnicas. Un pentest manual realizado por profesionales es fundamentalmente diferente — y necesario para cualquier evaluación que deba presentarse ante un regulador o demostrar un nivel de seguridad real.

Elegir al proveedor más barato sin verificar credenciales

El precio de un pentest varía porque varía la profundidad técnica de lo que se hace. Un proveedor que ofrece un "pentest completo" a precio muy bajo generalmente entrega un informe de escaneo automático con formato de reporte. Sus credenciales — o la falta de ellas — son verificables antes de firmar el contrato.

No incluir activos cloud en el alcance

Muchas empresas panameñas migran sus sistemas a la nube pero contratan pentests pensando en el modelo on-premise: servidores, red interna, aplicaciones web. Los buckets S3 públicos por error, las políticas IAM demasiado permisivas, las bases de datos RDS accesibles desde Internet y los secretos en variables de entorno de funciones Lambda son vulnerabilidades reales que un pentest tradicional no descubre si no incluye el cloud en el alcance.

No hacer retests después de la remediación

El pentest sin retest es como un examen médico sin seguimiento. Saber que tiene una vulnerabilidad pero no verificar que la corrección funcionó deja la misma brecha abierta — con el agravante de que ahora consta en un documento que la empresa la conocía.

Sacar los sistemas críticos del alcance "para no correr riesgos"

La lógica de excluir los sistemas más críticos del pentest "para no afectar la operación" es contraproducente: son precisamente los sistemas críticos los que más necesitan ser evaluados. La coordinación adecuada (ambiente de pruebas, ventanas de tiempo, protocolo de pausa) mitiga el riesgo operacional sin sacrificar cobertura.

Precios de referencia en el mercado panameño (2026)

Los rangos siguientes son orientativos. El precio final depende de la complejidad real del sistema, el número de roles de usuario, la cantidad de endpoints de API, y si se requiere mapeo regulatorio específico.

Tipo de evaluación	Rango orientativo (USD)
Pentest de aplicación web (1 app, 2–3 roles)	$4,000 – $8,000
Pentest de API REST (hasta 30 endpoints)	$3,500 – $7,000
Pentest de app móvil (iOS o Android, análisis estático + dinámico)	$4,000 – $7,000
Pentest de infraestructura de red (hasta 50 hosts)	$5,000 – $10,000
Evaluación de seguridad cloud (AWS/GCP/Azure)	$4,000 – $9,000
Pentest completo (web + API + mobile + cloud)	$12,000 – $25,000
Campaña de phishing simulado (hasta 100 empleados)	$2,500 – $5,000

Nota: estas cifras son referencias de mercado, no cotizaciones vinculantes. Solicite propuesta formal con alcance detallado.

Preguntas que debe hacerle a su proveedor de pentesting

Antes de contratar, haga estas preguntas y evalúe la calidad de las respuestas:

• ¿Cuáles son los nombres y certificaciones de los pentesters que realizarán este trabajo específico?
• ¿Qué metodología utilizarán para la evaluación de APIs / aplicaciones web / mobile (según aplique)?
• ¿Cómo gestionan el acceso a credenciales de prueba que les proporcionemos?
• ¿Qué ocurre si durante las pruebas identifican un hallazgo crítico? ¿Nos notifican de inmediato?
• ¿El reporte incluye evidencia reproducible de cada hallazgo (no solo una descripción)?
• ¿Cuántos retests están incluidos y en qué plazo?
• ¿Pueden entregar el reporte en formato utilizable ante la SBP o un banco adquirente?
• ¿Han trabajado con empresas en sectores similares al nuestro en Panamá o la región?
• ¿Qué pasa si hay un impacto no anticipado en producción durante las pruebas?

Por qué el contexto panameño importa

Panamá no es un mercado genérico de ciberseguridad. Tres características específicas del entorno panameño deben conocerlas tanto usted como su proveedor:

Entidades reguladas por la SBP: Los reportes de pentesting para presentación ante la SBP requieren un nivel de rigor y formato que un proveedor sin experiencia regulatoria puede no conocer. Un reporte técnico detallado pero sin estructura ejecutiva utilizable por el inspector regulatorio es menos valioso de lo que parece.

Empresas de la Zona Libre de Colón: El perfil de amenaza de una empresa ZLC — con flujos de comercio internacional, múltiples divisas, y transacciones de alto volumen — es diferente al de una empresa de servicios domésticos. El alcance del pentest debe adaptarse a esa realidad: sistemas de gestión de comercio internacional, plataformas de pagos cross-border, y conexiones con socios comerciales internacionales.

Sector logístico y portuario: Panamá es un hub logístico global. Las empresas de logística, puertos y operadores de carga manejan sistemas OT (tecnología operacional) además de IT — y la evaluación de seguridad de sistemas OT requiere metodología y experiencia específicas que no todos los proveedores de pentesting tienen.

Para una visión comparativa de los proveedores disponibles en el mercado, el análisis de las mejores empresas de pentesting en Panamá incluye un checklist de criterios verificables que permite evaluar opciones de forma objetiva.

Para empresas panameñas que necesitan un proveedor con metodología documentada en la región, WhiteJaguars opera con marco de trabajo (PTES + OWASP + MITRE ATT&CK), retests ilimitados incluidos y equipo certificado en OSCP, CISSP, CEH y CISM, entre otras —certificaciones que cualquier empresa puede solicitar para verificar antes de firmar el contrato.

Preguntas frecuentes

¿Cuánto tiempo tarda un pentest típico en Panamá?

Un pentest de aplicación web de tamaño mediano (1–2 aplicaciones, 3 roles de usuario) tarda entre 2 y 3 semanas de ejecución, más 1–2 semanas adicionales para la entrega del reporte final. Un pentest completo (web + API + mobile + cloud) puede tomar 4–6 semanas. El retest posterior a la remediación es un proceso separado de 3–5 días.

¿Puedo hacer el pentest en producción o necesito un ambiente separado?

Ambas opciones son válidas si se gestionan correctamente. Un ambiente de staging que replique producción es ideal porque permite mayor libertad en las técnicas de explotación. Si no existe staging, el pentest en producción es posible con coordinación adecuada, ventanas de tiempo definidas, y exclusión de ciertas técnicas agresivas (como denegación de servicio). Discuta esta decisión explícitamente con el proveedor antes de iniciar.

¿El proveedor puede dañar nuestros sistemas durante el pentest?

El riesgo de impacto operacional existe pero es manejable. Un proveedor profesional no usa técnicas destructivas sin coordinación previa. Los protocolos de las rules of engagement, la comunicación en tiempo real y las ventanas de prueba definidas minimizan el riesgo. En más de 15 años de historia de la industria, los incidentes durante pentests profesionales son raros y generalmente están relacionados con sistemas ya en estado degradado antes del inicio de las pruebas.

¿Es suficiente un pentest anual o necesitamos más frecuencia?

Un pentest completo anual es el mínimo recomendado. Para empresas que hacen releases de software frecuentes (fintechs, plataformas de e-commerce, sistemas de gestión), se recomienda evaluaciones de seguridad adicionales ante cada lanzamiento de funcionalidad crítica. Un modelo de pentesting continuo (PTaaS — Pentesting as a Service) puede ser más eficiente que contratos puntuales anuales para organizaciones con desarrollo activo.

---

Proveedores como WhiteJaguars acompañan desde la definición del alcance hasta el retest final, con metodología documentada (PTES + OWASP + MITRE ATT&CK), equipo certificado en OSCP, CISSP, CEH y CISM entre otras, y retests ilimitados incluidos.