Contratar un pentest no empieza cuando alguien ejecuta herramientas. Empieza cuando tu empresa define qué quiere validar, qué sistemas entran en alcance, qué límites operativos existen y cómo se van a corregir los hallazgos.
Un buen pentest ayuda a responder una pregunta concreta: qué tan lejos podría llegar un atacante dentro de un alcance autorizado. Para llegar a esa respuesta sin poner en riesgo la operación, conviene preparar el trabajo antes de cotizarlo.
Esta checklist está pensada para empresas en México que necesitan contratar pruebas de penetración con un alcance claro, entregables útiles y evidencia accionable.
1. Define el objetivo del pentest
Antes de hablar de herramientas, define la decisión que el pentest debe apoyar.
Algunos objetivos comunes son:
- validar la seguridad de una aplicación antes de publicarla;
- revisar exposición de servicios críticos en internet;
- probar controles después de una remediación;
- preparar evidencia para auditoría o clientes;
- medir el impacto real de vulnerabilidades ya conocidas;
- evaluar una arquitectura nueva o un cambio importante.
El objetivo evita que el proyecto se convierta en una revisión genérica. También ayuda a decidir si necesitas un pentest, una evaluación de vulnerabilidades o un servicio recurrente de monitoreo.
2. Separa pentest de escaneo de vulnerabilidades
Un escaneo ayuda a identificar exposición conocida. Un pentest valida si esa exposición puede explotarse y qué impacto tendría bajo un alcance permitido.
Si tu empresa no tiene inventario, versiones, responsables ni una primera lista de riesgos, conviene hacer una evaluación inicial antes. Si ya corregiste hallazgos evidentes y quieres validar impacto, el pentest tiene más valor.
La diferencia importa porque cambia el entregable. Un escaneo entrega listas priorizadas. Un pentest debe entregar contexto, evidencia, rutas de ataque, impacto y recomendaciones verificables.
Puedes revisar más detalle en la comparación entre pentest vs evaluación de vulnerabilidades.
3. Lista los activos dentro de alcance
El alcance debe decir exactamente qué se puede probar. No basta con escribir “infraestructura” o “aplicación web”.
Incluye datos como:
- dominios y subdominios;
- direcciones IP públicas;
- aplicaciones web y APIs;
- ambientes permitidos;
- cuentas de prueba;
- roles disponibles para pruebas autenticadas;
- proveedores involucrados;
- exclusiones explícitas;
- datos o sistemas que no deben tocarse.
Si hay activos de terceros, confirma autorización por escrito. Esto es especialmente importante en nube, servicios administrados, pasarelas de pago, proveedores de hosting y plataformas SaaS.
4. Aclara el tipo de prueba
No todos los pentests tienen el mismo punto de partida.
Una prueba de caja negra simula poca información inicial. Una prueba de caja gris usa información parcial, cuentas de prueba o documentación técnica. Una prueba de caja blanca permite revisar diseño, código, configuración o arquitectura.
Para empresas que buscan reducir riesgo real, la caja gris suele ser más eficiente. Permite invertir menos tiempo descubriendo lo básico y más tiempo validando controles, lógica de negocio y rutas de impacto.
5. Define reglas de operación
Un pentest debe tener límites prácticos. Esto protege la continuidad del negocio y evita malentendidos.
Define desde el inicio:
- horarios permitidos;
- ventanas de mantenimiento;
- contactos de emergencia;
- sistemas críticos que requieren cuidado especial;
- acciones prohibidas;
- límites de volumen para pruebas;
- uso de ingeniería social, si aplica;
- tratamiento de credenciales y datos sensibles;
- proceso para reportar hallazgos críticos en caliente.
Si el proveedor no pide reglas de operación, es una señal de alerta. Las pruebas autorizadas necesitan control, no improvisación.
6. Prepara accesos y datos de prueba
Muchos pentests pierden valor por falta de accesos. Si el equipo pasa la mitad del tiempo esperando cuentas, VPN o permisos, el resultado se vuelve más superficial.
Antes de iniciar, prepara:
- cuentas por rol;
- MFA configurado cuando sea parte del flujo real;
- datos ficticios suficientes para probar procesos;
- documentación mínima de endpoints críticos;
- URL de ambientes;
- restricciones de IP, si existen;
- permisos temporales aprobados por seguridad y TI.
Evita usar datos reales cuando no sea necesario. El objetivo es validar seguridad, no exponer información de clientes o empleados.
7. Pide entregables accionables
Un reporte útil debe permitir que el equipo técnico corrija y que dirección entienda el riesgo. No debe quedarse en capturas sueltas ni en una lista automática de CVEs.
Pide que el entregable incluya:
- resumen ejecutivo;
- alcance probado;
- metodología general;
- hallazgos priorizados;
- evidencia reproducible;
- impacto de negocio;
- pasos de reproducción;
- recomendaciones técnicas;
- severidad justificada;
- responsables sugeridos;
- plan de remediación;
- criterios para validar cierre.
El lenguaje debe ser claro. Un buen hallazgo explica por qué importa, cómo se comprobó y qué cambio reduce el riesgo.
8. Acuerda cómo se manejarán hallazgos críticos
No todos los hallazgos deben esperar al reporte final. Si durante la prueba aparece una exposición crítica, debe existir un canal para avisar rápido.
Define:
- quién recibe alertas críticas;
- en qué horario se puede escalar;
- qué evidencia mínima se comparte;
- cuándo se pausa una prueba;
- cómo se confirma la corrección;
- si habrá revalidación incluida.
Este punto es clave para empresas con servicios publicados, acceso remoto, portales de clientes o integraciones con información sensible.
9. Incluye una sesión de cierre
El reporte no debe ser el último contacto. Una sesión de cierre ayuda a resolver dudas, priorizar acciones y separar lo urgente de lo importante.
En esa sesión conviene revisar:
- hallazgos de mayor impacto;
- rutas de ataque observadas;
- correcciones rápidas;
- controles que requieren proyecto;
- riesgos aceptados temporalmente;
- plan de revalidación;
- próximos pasos de hardening.
La meta es que el pentest termine en decisiones, no en un PDF guardado. Si la sesión detecta exposición recurrente, también puede conectarse con monitoreo y análisis de seguridad o seguridad gestionada MSSP para dar seguimiento después de la prueba.
10. Planea la revalidación
La remediación sin revalidación deja incertidumbre. Después de corregir, pide una revisión enfocada en los hallazgos cerrados.
La revalidación debe confirmar si:
- el hallazgo ya no se reproduce;
- la corrección no abrió otro problema;
- el control funciona para roles relevantes;
- la evidencia de cierre es suficiente;
- queda riesgo residual documentado.
Esto convierte el pentest en un ciclo de mejora y no solo en una fotografía de riesgo.
Señales de alerta al contratar
Ten cuidado si el proveedor:
- promete resultados garantizados antes de revisar alcance;
- no pide autorización formal;
- no pregunta por ventanas ni contactos de emergencia;
- entrega solo escaneos automáticos como si fueran pentest;
- no explica metodología ni límites;
- evita hablar de revalidación;
- no puede adaptar el reporte a audiencias técnica y ejecutiva;
- propone pruebas intrusivas sin reglas claras.
Un pentest serio combina técnica, comunicación y control operativo.
Cómo puede ayudarte Syscore
Syscore ayuda a definir alcance, ejecutar pruebas autorizadas, documentar evidencia, priorizar remediación y validar correcciones. También podemos conectar el resultado con servicios de ciberseguridad, gestión de incidentes y monitoreo para que los hallazgos no se queden aislados.
Si buscas un equipo local para pentest en México o necesitas apoyo para preparar alcance antes de cotizar, el primer paso es ordenar activos, objetivos y restricciones.
Fuente interna de referencia
Para complementar esta checklist, revisa la página de Pentest en México y el servicio de pruebas de penetración. Ambas páginas explican cómo Syscore estructura pruebas autorizadas, alcance, evidencia, remediación y validación de cierre. Si estás comparando propuestas, también conviene revisar qué factores cambian el costo de un pentest en México.
Preguntas frecuentes
¿Cuánto dura un pentest?
Depende del alcance, la complejidad y la disponibilidad de accesos. Una aplicación pequeña puede requerir pocos días. Un entorno con varias aplicaciones, APIs, roles y sistemas publicados necesita más tiempo para probar con profundidad.
¿Necesito dar credenciales?
Para aplicaciones con usuarios, roles o flujos internos, sí conviene entregar cuentas de prueba. Las pruebas autenticadas encuentran problemas que no aparecen desde una vista pública.
¿Un pentest puede afectar producción?
Puede hacerlo si se ejecuta sin reglas. Por eso deben definirse ventanas, contactos de emergencia, límites técnicos y acciones prohibidas. Cuando el riesgo operativo es alto, puede probarse primero en un ambiente controlado.
¿Qué pasa después del reporte?
El siguiente paso es remediar, documentar responsables y revalidar. El valor real aparece cuando los hallazgos se convierten en cambios verificables.