Pentest para SaaS: cómo responder ‘¿tienen un pentest reciente?’ y cerrar el contrato enterprise

El cuestionario que frena el contrato

La demo salió bien, el equipo técnico del cliente quedó conforme y llega la planilla del equipo de seguridad: SIG, CAIS o un cuestionario propio de gestión de riesgo de terceros, con 150 preguntas. En algún punto aparece la línea que marca el ritmo de la operación: "¿La empresa realiza pruebas de intrusión independientes? ¿Cuándo fue la última? ¿Puede compartir el resultado?"

Quien responde "sí, las hacemos" sin adjunto suele recibir otra pregunta. Quien responde "sí, en marzo, aquí está el resumen ejecutivo con el reteste" pasa a la siguiente fila. Esta guía muestra cómo preparar esa segunda respuesta antes de que llegue el cuestionario.

Mientras la planilla sigue sin respuesta, el contrato también espera. Ventas insiste, ingeniería dice "tenemos un pentest, solo debo encontrar el PDF", y el analista del cliente marca el ítem como pendiente. La revisión de seguridad suele ser el último paso antes de la firma, y cada ronda de preguntas y respuestas aleja la fecha del primer pago.

Qué quiere saber realmente el equipo de riesgo del cliente

El analista de riesgo de terceros no va a leer tu informe técnico completo. Necesita marcar una casilla defendible ante su auditor interno. En la práctica busca cinco cosas:

• Independencia: la prueba la hizo un tercero, no tu propio equipo de desarrollo.
• Vigencia: normalmente en los últimos 12 meses o tras un cambio relevante del producto.
• Alcance compatible: cubre la aplicación y la API que usará el cliente, no solo el sitio institucional.
• Tratamiento de hallazgos: los críticos y altos fueron corregidos y reevaluados.
• Método: metodología citada (OWASP WSTG, OWASP API Security, PTES, NIST SP 800-115), no solo una lista de ítems.

Si tu material responde esas cinco preguntas en una página, la mayor parte de la fricción desaparece.

Qué compartir: carta de atestación, resumen ejecutivo o informe completo

Casi nunca se envía el informe completo. Contiene detalles de vulnerabilidades, rutas internas y pruebas de explotación. En manos equivocadas es una hoja de ruta de ataque. El patrón habitual tiene tres capas:

Documento	Qué contiene	Cuándo enviarlo
Carta de atestación	Quién probó, cuándo, alcance, metodología, resumen de severidades, estado del reteste. Una página.	Respuesta estándar a cuestionarios y primer contacto de due diligence
Resumen ejecutivo	Panorama de riesgos, conteo por severidad, correcciones confirmadas, limitaciones. 2 a 4 páginas.	Clientes enterprise, solicitudes de seguridad durante la negociación
Carta de reteste	Confirma, hallazgo por hallazgo, qué se corrigió y qué sigue abierto, con fechas.	Cuando el cliente pregunta si los problemas graves quedaron resueltos
Informe completo	Hallazgos detallados, evidencias, reproducción.	Solo bajo NDA y para clientes concretos con solicitud formal; mejor lectura supervisada

Dos reglas prácticas: nunca envíes hallazgos abiertos sin plan de corrección y mantén una versión del resumen sin nombres de endpoints, usuarios de prueba ni credenciales. Habla con legal sobre el NDA antes de que llegue la solicitud, no durante.

Cómo responder la pregunta en el cuestionario

Una respuesta que suele pasar sin repregunta tiene esta estructura:

1. Sí, con frecuencia definida ("anual y ante cambios significativos de arquitectura").
2. Fecha de la última prueba y quién la ejecutó (empresa independiente).
3. Alcance: aplicación web, API, autenticación y aislamiento entre clientes.
4. Metodología: OWASP WSTG y OWASP API Security Top 10.
5. Estado de los hallazgos: críticos y altos corregidos y reevaluados en la fecha X.
6. Adjunto: carta de atestación o resumen ejecutivo.

Evita frases vagas como "realizamos pruebas de seguridad periódicamente". Y no prometas cobertura que la prueba no tuvo: si el alcance fue solo la API, di que fue solo la API.

Ejemplos de respuesta para adaptar

Pregunta: "¿La empresa realiza pruebas de intrusión independientes?"

Sí. Realizamos un pentest independiente anualmente y tras cambios significativos de arquitectura. El último se completó en [mes/año] por [empresa], cubriendo aplicación web, API, autenticación y aislamiento entre clientes, según OWASP WSTG y OWASP API Security Top 10. Los hallazgos críticos y altos se corrigieron y se retestearon el [fecha]. La carta de atestación se adjunta.

Pregunta: "¿Pueden compartir el informe completo?"

El informe técnico completo contiene detalles de explotación y se comparte solo bajo NDA, previa solicitud formal. Ofrecemos carta de atestación y resumen ejecutivo, y podemos presentar los hallazgos en una sesión de lectura supervisada.

Si el primer test aún no se hizo:

Pentest independiente contratado, con ejecución prevista para [mes]. Enviaremos la carta de atestación al concluir el reteste.

Nunca inventes la fecha de una prueba que no existe. El analista puede pedir el adjunto, y una respuesta honesta con plazo suele ser mejor recibida que un "sí" sin prueba.

Alcance de un pentest para SaaS B2B

El SaaS vendido a empresas tiene un riesgo que un sitio institucional no tiene: muchos clientes dentro de la misma aplicación. Un buen alcance cubre:

• Aplicación web (todas las funciones autenticadas, por rol de usuario).
• API usada por el front-end y por integraciones, incluidos endpoints no documentados. Mira la guía de pentest de API.
• Autenticación y sesión: login, MFA, recuperación de contraseña, SSO/SAML/OAuth, expiración de tokens.
• Aislamiento multi-tenant: ¿puede un usuario del cliente A leer o modificar datos del cliente B? Es el hallazgo que más preocupa a compradores enterprise y el más común en APIs (BOLA).
• Autorización y roles: escalada de privilegios entre perfiles (usuario común a administrador).
• Subida de archivos, exportaciones, webhooks e integraciones con sistemas de terceros.
• Componentes de IA, si existen (asistentes, RAG, agentes), tratados como parte de la superficie.

La infraestructura en la nube entra si el cliente pregunta por ella, pero en SaaS el núcleo es aplicación, API y aislamiento entre inquilinos.

En la práctica, los puntos débiles de un SaaS B2B son previsibles: objetos consultados por identificador sin verificar al propietario (BOLA/IDOR), funciones de administrador accesibles para usuarios comunes, SSO con validación débil de aserciones o tokens, cargas de archivos que aceptan contenido ejecutable y exportaciones que filtran datos de otro cliente. Pide al proveedor que pruebe cada perfil de usuario y al menos dos cuentas de clientes distintos, para demostrar el aislamiento en lugar de suponerlo. El panel de administración interno también entra en el alcance: ahí un error expone a todos los inquilinos a la vez.

Cuándo probar para no retrasar el contrato

El peor momento para contratar un pentest es después de recibir el cuestionario. La prueba lleva días, el informe algunos más, y la corrección y el reteste otro tiempo. Una línea de tiempo realista:

1. Antes de empezar a vender a enterprise: haz la primera prueba y deja lista la carta de atestación.
2. Cada 12 meses, o tras un cambio grande (nueva arquitectura de autenticación, nuevo módulo de pagos, migración de nube).
3. Cuando un cliente grande pide un alcance propio: avisa pronto al proveedor, porque ajustar alcance y ventana de prueba lleva tiempo.

Un pentest de 2023 presentado en 2026 tras dos migraciones se convierte en pregunta, no en respuesta.

El costo de postergar la prueba

Compara el precio del pentest con el costo del retraso, no con cero. Cada semana de negociación detenida pospone ingresos recurrentes que solo empiezan tras la firma, mantiene a ventas e ingeniería en retrabajo y da espacio al competidor que ya tiene la respuesta lista. No hay una cifra universal, pero puedes estimarla con tus datos: toma el valor anual de tus tres últimos contratos enterprise frenados por seguridad, multiplícalo por las semanas de retraso y divídelo entre 52. Pon ese valor junto al presupuesto de la prueba.

Reteste: la evidencia que cierra la conversación

El analista de riesgo no necesita un informe sin fallos. Sabe que las pruebas encuentran problemas. Quiere ver que los problemas graves se corrigieron y los verificó quien los encontró. Por eso importa el reteste:

• Fecha del reteste y qué hallazgos se confirmaron corregidos.
• Hallazgos residuales, con aceptación de riesgo justificada o plan de corrección.
• Mención en el resumen ejecutivo, no escondida en un anexo.

Un resumen que dice "3 altos encontrados, 3 corregidos y reevaluados" es más sólido que un informe limpio sin reteste.

Cómo mantener la evidencia vigente entre una prueba y otra

La carta de atestación envejece. Para que siga siendo útil durante el año:

• Registra en el historial de releases los cambios relevantes (nuevo módulo de pagos, nueva forma de login, migración de nube) y decide si cada uno exige una prueba complementaria.
• Prefiere una prueba dirigida a lo que cambió en lugar de rehacerlo todo, si la arquitectura base es la misma.
• Actualiza la carta con la fecha del último reteste cada vez que haya una nueva ronda.
• Mantén los hallazgos residuales con responsable y plazo, y revisa el backlog cada trimestre.
• Usa escaneo continuo y revisión de dependencias como complemento. Ayudan a la higiene, pero no sustituyen la prueba manual.

Cómo acelera el negocio y se vincula con SOC 2 e ISO 27001

Tener carta de atestación y resumen listos saca a tus equipos de seguridad y comercial de la cola de correos. En vez de "lo consultamos con el equipo técnico" y dos semanas de espera, la respuesta sale el mismo día y el analista de riesgo del cliente tiene lo que necesita para aprobar.

El pentest no sustituye una certificación. SOC 2 e ISO 27001 demuestran que tienes procesos de seguridad; el pentest demuestra que el producto resiste ataques. Se complementan, y muchos controles de ambos piden pruebas independientes periódicas. El post sobre pentest para ISO 27001, SOC 2, RGPD y ENS detalla qué exige cada uno. Si aún no tienes certificación, un pentest reciente ya ayuda a pasar la mayoría de los cuestionarios.

Sobre costos, la guía de precios de pentest explica qué cambia el valor. Para un SaaS con app web y API, la inversión suele ser menor que el costo de un ciclo de ventas enterprise que se estanca por falta de respuesta.

Checklist: listo para el próximo cuestionario

• [ ] Pentest independiente en los últimos 12 meses que cubra app web, API, autenticación y aislamiento multi-tenant
• [ ] Carta de atestación de una página, revisada por legal
• [ ] Resumen ejecutivo con conteo por severidad y estado del reteste
• [ ] Reteste de críticos y altos documentado con fecha
• [ ] Texto estándar de respuesta para la pregunta de pentest
• [ ] Política de NDA definida para enviar el informe completo
• [ ] Calendario de la próxima prueba (anual o tras un cambio grande)

Preguntas frecuentes

¿Puedo enviar el informe completo de pentest al cliente?

Puedes, pero no debería ser lo habitual. Prefiere la carta de atestación y el resumen ejecutivo. El informe completo, solo bajo NDA, para un cliente concreto con solicitud formal y, si es posible, en lectura supervisada.

Mi pentest tiene más de 12 meses. ¿Sigue valiendo?

Muchos clientes aceptan hasta 12 meses y preguntan qué cambió desde entonces. Si hubo un cambio grande de arquitectura, autenticación o nube, planifica una prueba nueva o complementaria de lo que cambió.

¿Necesito SOC 2 o ISO 27001 para vender a enterprise?

No necesariamente. Muchos clientes aceptan un pentest reciente, políticas documentadas y respuestas consistentes. La certificación ayuda cuando el cliente la exige por contrato.

¿Un escáner automático sirve como evidencia?

Por lo general no. Quien evalúa distingue un escaneo de una prueba manual. Mira la diferencia en escáner, pentest o bug bounty.

¿Cuánto tarda tener listo el resumen ejecutivo?

Depende del alcance. Acuerda con el proveedor desde el inicio el formato de la carta y el resumen, para que salgan junto con el informe y el reteste.

¿Quién firma la carta de atestación?

La empresa que ejecutó la prueba, indicando fecha, alcance, metodología y estado del reteste. El área legal de tu empresa debería revisar el texto antes del primer envío.

¿La prueba se hace en producción o en un entorno de pruebas?

Lo ideal es un entorno equivalente a producción con datos ficticios, o producción con ventana acordada y salvaguardas. La carta debe indicar qué entorno se probó, porque el analista de riesgo lo preguntará.

¿Puede un cliente exigir probar nuestro producto por su cuenta?

Algunos lo piden. Suele funcionar definir en el contrato la ventana, el alcance, las cuentas de prueba y la prohibición de denegación de servicio, y ofrecer el informe independiente como alternativa.

Prepara tu respuesta antes del próximo cuestionario

Pentest Machine entrega pentest para SaaS con documentación lista para clientes enterprise: carta de atestación, resumen ejecutivo, informe técnico completo y reteste de los hallazgos corregidos. Define el alcance con nosotros antes de que llegue el cuestionario. Solicita un presupuesto.