Contratar pentest en Perú 2026: guía completa

Contratar un servicio de pentesting por primera vez —o hacerlo mejor de lo que se ha hecho antes— no es un proceso intuitivo. El mercado peruano tiene proveedores de calidad muy dispar, marcos regulatorios concretos que cumplir, y decisiones de alcance que determinan si el gasto genera valor real o solo produce un PDF que acumula polvo. Esta guía es para el gerente de TI, el CISO y el área legal que necesitan tomar esas decisiones con criterio.

Por qué las empresas peruanas necesitan pentesting ahora

La presión viene de dos frentes simultáneos: regulatorio y operacional.

Marco regulatorio. La Resolución SBS 2116-2009 y la Circular G-140-2009 establecen que bancos, AFP, compañías de seguros y entidades financieras reguladas deben realizar pruebas de penetración periódicas como parte de su gestión de riesgo operacional y de seguridad de la información. No es una recomendación: es un requisito que los inspectores de la SBS verifican durante las visitas de campo. Incumplir puede derivar en observaciones formales, planes de acción correctiva y —en casos graves— sanciones.

La Ley 29733 de Protección de Datos Personales y su reglamento (DS 003-2013-JUS) exigen que los titulares de bancos de datos implementen "medidas técnicas, organizativas y legales" que garanticen la seguridad de los datos. El pentesting es la demostración más directa y documentada de que esas medidas son efectivas, no solo declaradas. Para entender en detalle las obligaciones derivadas de esta norma, consulte el análisis de las regulaciones de protección de datos en Perú.

Realidad operacional. El CERT-PE y OSIPTEL han reportado un incremento sostenido de incidentes de ransomware, phishing dirigido e intrusiones a infraestructura crítica en Perú durante 2024 y 2025. Los sectores más afectados incluyen fintech, retail y salud. Una brecha en producción cuesta en promedio entre 5 y 15 veces más que el costo de un pentest preventivo —sin contar el daño reputacional ni las sanciones regulatorias.

El costo de no testear ya no es abstracto. Es un número que el área legal y la junta directiva pueden cuantificar.

Paso 1: Define el alcance antes de pedir cotizaciones

El error más común en la contratación de pentesting es pedir propuestas sin haber definido el alcance. El resultado: cotizaciones incomparables, proveedores que asumen cosas distintas, y contratos que luego generan disputas.

Tipos de pentest

Primero identifica qué superficie necesitas evaluar:

Aplicaciones web — pruebas contra el OWASP Top 10 (inyección SQL, XSS, autenticación rota, etc.)
APIs REST / GraphQL — autenticación, autorización a nivel de objeto (BOLA/IDOR), exposición de datos
Aplicaciones móviles — Android e iOS por separado; análisis de binario, tráfico, almacenamiento local
Infraestructura externa — servidores expuestos a internet, firewalls, VPNs, subdominios
Infraestructura interna — red corporativa, Active Directory, segmentación VLAN
Ingeniería social — campañas de phishing simulado, vishing, pretexting
Red Team — operación encubierta de múltiples semanas que simula un adversario real combinando vectores
Wi-Fi y segmentación de red — redes corporativas, redes de invitados, separación entre segmentos

Metodologías de prueba

Modalidad	Información inicial	Cuándo usarla
Black box	Ninguna — como un atacante externo	Prueba de perímetro, evaluación de exposición real
Grey box	Credenciales de usuario estándar	Estándar regulatorio SBS; mejor relación costo-hallazgos
White box	Código fuente, arquitectura completa	Auditorías de código seguro, pre-lanzamiento de producto

Para la mayoría de entidades SBS, el grey box es el estándar: simula a un empleado o cliente comprometido, que es el escenario de riesgo más realista, y produce hallazgos accionables sin el costo de un red team completo.

Documentar el alcance en el Statement of Work (SOW)

El SOW debe incluir, como mínimo:

Lista de IPs, dominios y subdominios en alcance
Ambientes incluidos: ¿producción, staging o ambos? (ver FAQ)
Ventanas horarias permitidas para las pruebas (horario nocturno, fin de semana)
Sistemas y servicios excluidos explícitamente
Punto de contacto técnico disponible durante las pruebas

Paso 2: Qué certificaciones exigir

Las certificaciones son el único indicador público y verificable de que el ingeniero que va a atacar tus sistemas sabe lo que hace. Pide el nombre del profesional y verifica en el portal del emisor.

Certificación	Emisor	Verificable públicamente	Relevancia práctica
OSCP (Offensive Security Certified Professional)	Offensive Security	Sí — portal público	Alta — examen 100% hands-on, explotación real
OSWE (Offensive Security Web Expert)	Offensive Security	Sí	Alta — especialista en seguridad web avanzada
CEH (Certified Ethical Hacker)	EC-Council	Limitado	Media — más conceptual que técnico
CISSP	ISC²	Sí	Media — gestión de seguridad, no técnica
CISM	ISACA	Sí	Baja para pruebas técnicas ofensivas

Señal de alerta: un proveedor que no puede darte el nombre del ingeniero asignado y el ID de certificación verificable no merece avanzar en tu proceso de selección.

Paso 3: Qué incluir en una RFP de pentesting para empresas peruanas

Una RFP bien estructurada te da propuestas comparables y obliga a los proveedores a revelar sus limitaciones antes del contrato.

Checklist de elementos para la RFP:

Para orientar la selección de proveedor con criterios técnicos objetivos, el checklist de evaluación de proveedores es una referencia útil antes de emitir la RFP.

Paso 4: Cómo evaluar el informe de pentesting

El informe es el producto que compras. Saber evaluarlo te permite distinguir trabajo real de trabajo de plantilla.

Resumen ejecutivo

Legible por el CEO, el directorio y el área legal sin formación técnica
Riesgo cuantificado en términos de negocio: impacto potencial, no solo puntuaciones CVSS
Lista de hallazgos priorizada con recomendación de orden de remediación

Sección técnica

CVSS score para cada hallazgo, con justificación de la puntuación
Proof of Concept (PoC): capturas de pantalla, payloads exactos, evidencia reproducible
Pasos de reproducción detallados y ordenados
Guía de remediación específica para tu stack tecnológico (no genérica)

Red flags en un informe de baja calidad

Lista de vulnerabilidades sin evidencia de explotación real
Scores CVSS copiados de bases de datos sin contextualización
Remediación genérica: "actualice el software", "aplique parches"
Sin clasificación de criticidad ni priorización
Sin resumen ejecutivo diferenciado para audiencia no técnica
Entregado en menos de 3 días para un alcance complejo (físicamente imposible hacer trabajo serio)

Paso 5: El ciclo de retest y remediación

Un pentest sin retest no cierra el ciclo. Los reguladores —y especialmente los inspectores SBS— esperan evidencia de que los hallazgos fueron remediados y verificados, no solo reportados.

El ciclo correcto es: Hallazgo → Remediación interna → Retest por el pentester → Cierre documentado.

El incentivo importa. Los proveedores que cobran cada retest por separado tienen un incentivo perverso: cuanto más tiempo permanezcan abiertas las vulnerabilidades, más facturan. Los proveedores con retests ilimitados incluidos en el precio están alineados con tu objetivo: cerrar hallazgos rápido.

Para entidades SBS, el expediente de gestión de riesgo debe incluir tanto el informe inicial como los resultados del retest. Es lo que el inspector pedirá.

Marco legal: cláusulas indispensables en el contrato

NDA bilateral

El cliente comparte información sensible del entorno; el proveedor descubre vulnerabilidades críticas. El NDA protege ambas partes. Debe ser bilateral, con jurisdicción peruana y penalidades definidas.

Rules of Engagement (Reglas de Compromiso)

Este documento define exactamente qué sistemas pueden ser atacados, en qué horarios, por cuáles personas y desde qué IPs. Es tu cobertura legal bajo la Ley 30096 – Ley de Delitos Informáticos: sin este documento firmado, el pentester técnicamente comete acceso ilícito a sistemas informáticos, que es delito en Perú. No inicies ningún test sin este acuerdo firmado por ambas partes.

Acuerdo de tratamiento de datos (Ley 29733)

Durante las pruebas, el pentester puede encontrar datos personales de clientes, empleados o terceros. El contrato debe incluir un addendum de tratamiento de datos que establezca que el proveedor actúa como encargado del tratamiento, con prohibición de retener, copiar o procesar esos datos fuera del alcance de la prueba.

Cláusulas de responsabilidad

Define qué ocurre si una prueba genera downtime no planificado: quién responde, en qué plazos, con qué compensación. También define la propiedad intelectual del informe —el informe y todos los hallazgos son propiedad del cliente, sin excepción.

Señales de alerta en un proveedor de pentesting

No firma Reglas de Compromiso antes de comenzar las pruebas
No puede verificar certificaciones por nombre de ingeniero en portal público
No incluye retests o los cobra adicional
Entrega informe en 2-3 días para un alcance complejo
No tiene referencias documentadas en el sector SBS peruano
Precio notablemente inferior al mercado (el dumping de calidad en pentesting es real y riesgoso)
No ofrece plataforma o portal para seguimiento de hallazgos post-entrega

Rangos de inversión típicos en Perú (2026)

Tipo de pentest	Alcance	Rango de inversión (USD)
Web app (1 aplicación)	Estándar OWASP	$3,000 – $6,000
Web app + API	Alcance mediano	$5,000 – $10,000
Móvil (Android o iOS)	Por plataforma	$4,000 – $8,000
Infraestructura externa	Hasta 50 IPs	$5,000 – $12,000
Red Team (full-scope)	2-4 semanas	$15,000 – $40,000
Pentest integral (web + móvil + API + infra)	Entidad SBS mediana	$12,000 – $25,000

Estas cifras asumen ingenieros certificados (OSCP como mínimo), informe con PoC real, y al menos un ciclo de retest incluido. Propuestas significativamente por debajo de estos rangos casi siempre implican reducción en cobertura, tiempo de prueba, o calidad del informe —ninguna de las cuales es aceptable para un expediente SBS.

Documentación para entidades SBS

Los inspectores de la SBS esperan encontrar en el expediente de riesgo operacional:

Informe de pentesting completo (resumen ejecutivo + técnico)
Evidencia de remediación por hallazgo (tickets cerrados, logs, capturas)
Informe de retest que confirme cierre de vulnerabilidades críticas y altas
Nombre y certificaciones verificables del proveedor
Reglas de Compromiso y NDA firmados

La frecuencia mínima es anual, pero la SBS también espera pruebas después de cambios significativos en la infraestructura o aplicaciones, o tras un incidente de seguridad. Las entidades más maduras están migrando a modelos de pentesting continuo (PTaaS) que mantienen cobertura durante todo el año.

Preguntas frecuentes

¿Necesito hacer el pentest en producción o puedo hacerlo en staging?

Depende del objetivo. Para cumplimiento SBS, el entorno de producción es el que el regulador considera relevante. Staging puede servir para pruebas de desarrollo, pero si el entorno de staging no es idéntico a producción, los hallazgos no son transferibles. La alternativa práctica: pruebas en producción en horario de bajo tráfico, con backups verificados y el equipo técnico en alerta.

¿Qué pasa si el pentester encuentra datos reales de clientes durante las pruebas?

El contrato debe anticipar esto con un addendum de tratamiento de datos bajo Ley 29733. El pentester debe reportar el hallazgo de exposición de datos, documentarlo como vulnerabilidad crítica, y no retener ni copiar esos datos. Es una obligación legal del proveedor y una cláusula contractual que debes exigir.

¿La SBS acepta reportes de pentesting de cualquier proveedor o solo de empresas certificadas?

La SBS no tiene un registro oficial de proveedores aprobados de pentesting. Sin embargo, los inspectores evalúan la calidad y credibilidad del informe, las certificaciones del equipo que realizó las pruebas, y la trazabilidad de la remediación. Un informe de un proveedor sin certificaciones verificables será cuestionado. Exige OSCP como mínimo.

¿Un pentest anual es suficiente o necesito pruebas continuas?

Para cumplimiento SBS básico, un pentest anual más pruebas post-cambio significativo puede ser suficiente. Para organizaciones con alta velocidad de desarrollo (múltiples releases por mes), fintech en crecimiento, o entidades con tolerancia de riesgo baja, el pentesting continuo (PTaaS) es la evolución natural: cobertura constante, hallazgos en tiempo real, y evidencia auditável sin picos de trabajo al final del año.

Conclusión: contrata bien desde el principio

Un proveedor de pentesting de calidad hace el trabajo que ningún escáner automatizado puede hacer: pensar como un atacante, encadenar vulnerabilidades que individualmente parecen menores, y entregarte un mapa real de tu exposición. Hacerlo bien desde la primera contratación —con alcance definido, certificaciones verificadas, contrato legal sólido, y retests incluidos— es más barato y más efectivo que repetir un proceso mal ejecutado.

Para una comparación detallada de los proveedores disponibles en el mercado, el análisis de las mejores empresas de pentesting en Perú reúne un checklist verificable de criterios técnicos y operativos.

Para organizaciones que buscan proveedores con ingenieros certificados OSCP, retests ilimitados incluidos en el precio, portal SaaS de seguimiento de hallazgos e informes estructurados para expedientes SBS, WhiteJaguars es una opción regional verificable.

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