Un cliente me pide un pentest: qué alcance e informe debo solicitar

Aclara qué necesita recibir tu cliente

Solicita el texto del requerimiento y una persona que pueda resolver dudas. “Necesitamos un ethical hacking” puede referirse a una aplicación, un conjunto de APIs o una versión que todavía está en desarrollo. Confirma quién revisará el resultado y si existe un formato o criterio de aceptación contractual.

No supongas requisitos que nadie pidió. Una fecha, una metodología o una condición sobre hallazgos debe venir del acuerdo aplicable, no de una plantilla comercial. Si el requerimiento es ambiguo, conviene aclararlo antes de contratar. Así evitas terminar con un informe técnicamente útil que no responde a la entrega que tu cliente esperaba.

Define la plataforma y las condiciones de la prueba

Identifica aplicación, versión, ambiente, tipos de usuario y operaciones relevantes. Incluye las APIs cuando sostienen esas funciones y señala qué servicios pertenecen a terceros. El equipo necesita saber qué puede probar y quién tiene autoridad para permitirlo; contratar la revisión no autoriza por sí solo intervenir sistemas ajenos.

La guía NIST SP 800-115 aborda planificación, ejecución y análisis de evaluaciones técnicas. Para tu contratación, tradúcelo a alcance, permisos, restricciones y coordinación documentados. Si solo habrá acceso parcial, pide explicar qué se puede concluir con esas condiciones y qué puntos necesitarían otra instancia para evaluarse.

Pide un informe que permita entender y corregir

El informe debe conectar cada hallazgo con la plataforma evaluada y sus consecuencias. La gerencia necesita comprender prioridades; desarrollo, la evidencia y las recomendaciones. Antes de comenzar, acuerda qué información se compartirá con el cliente y cómo se tratarán datos técnicos sensibles que no deberían circular sin control.

• Versión, fechas y alcance de la evaluación.
• Pruebas realizadas y restricciones relevantes.
• Hallazgos respaldados por evidencia.
• Impacto y prioridad de corrección.
• Recomendaciones y asuntos que quedaron pendientes.

Un documento comercial de cierre no equivale a una garantía de seguridad. La aceptación corresponde a las condiciones acordadas con quien solicitó la evaluación.

Reserva una etapa para resolver y volver a probar

Pregunta qué sucede si la evaluación detecta un problema relevante. Define quién podrá corregirlo, qué dependencias existen y qué evidencia necesita el cliente para considerar atendido el hallazgo. Una fecha comercial de entrega debe considerar esas decisiones, además del tiempo de evaluación.

Una comprobación posterior se llama retest. Su alcance y sus condiciones deben estar incluidos expresamente. En BlackDoor, la propuesta indica si se contrata esa segunda revisión y qué problemas se comprobarán. Un retest de correcciones específicas no constituye automáticamente un nuevo pentest completo. Si mientras tanto cambió la aplicación, hay que evaluar qué partes adicionales necesitan revisión.

Envía contexto suficiente para una cotización precisa

Para cotizar el pentest, describe qué producto entregas, quién lo usa y qué pide tu cliente. Indica si está publicado, si hay ambiente de prueba y qué funciones son centrales. Puedes mencionar el plazo contractual y la disponibilidad del equipo que hará correcciones, sin adjuntar contratos confidenciales al formulario.

Con esa información definimos el trabajo de ethical hacking y pentesting y coordinamos los antecedentes adicionales. No necesitas compartir contraseñas en la solicitud. Si el requisito incluye revisar la implementación, podemos incorporar una auditoría de código con alcance separado. La propuesta debe permitirte explicar a tu cliente qué se evaluará y qué entregable recibirá.