Hay un momento en el ciclo comercial de cualquier producto SaaS que los founders y los equipos de ventas aprenden a temer: cuando el prospecto corporativo envía una hoja de cálculo de due diligence de seguridad. El documento tiene decenas de líneas. Pregunta sobre arquitectura, políticas de acceso, historial de incidentes y cumplimiento normativo. Y casi siempre incluye una pregunta directa sobre pentest para SaaS: cuándo se realizó la última prueba, quién la llevó a cabo y si hay un informe disponible. En este artículo entenderás por qué los grandes clientes e inversores han empezado a exigir un pentest como criterio de cualificación, qué verifican durante este proceso y qué necesita tener un producto SaaS antes de entrar en cualquier proceso de due diligence de seguridad. Buena lectura.
El pentest ha dejado de ser un elemento diferenciador
Durante años, el pentest se consideró algo que las empresas tecnológicas hacían cuando “ya eran lo suficientemente grandes”. La percepción era que las startups y los productos en crecimiento tenían otras prioridades y que la seguridad podía esperar hasta que la operación madurara.
Este razonamiento funcionaba cuando los contratos corporativos se cerraban en función de la funcionalidad y el precio. Hoy ya no funciona.
La madurez de las áreas de seguridad dentro de las grandes empresas ha cambiado el proceso de evaluación de proveedores de software. Los equipos de infosec han empezado a tener poder de veto en contratos con SaaS que no pueden demostrar que el producto ha sido probado por profesionales externos. El pentest ha dejado de ser un proyecto para realizar “eventualmente” y se ha convertido en un requisito de entrada para negociaciones relevantes.
Por qué los clientes corporativos exigen un pentest
Cuando una empresa contrata un SaaS, está introduciendo ese producto dentro de su perímetro de seguridad. Los datos de sus clientes, empleados u operaciones van a circular por el entorno del proveedor.
Esto significa que una vulnerabilidad en el SaaS es, en la práctica, una vulnerabilidad en el entorno de la empresa contratante. Esta empresa responde ante cualquier incidente que afecte a sus datos, independientemente de dónde se haya producido el fallo técnico. La responsabilidad que no se transfiere al externalizar la tecnología es el mismo principio que lleva al cliente corporativo a exigir evidencias antes de firmar cualquier contrato con un proveedor de software.
Ante esta realidad, el proceso de evaluación de un proveedor SaaS ha empezado a incluir preguntas que no se planteaban hace cinco años.
Qué verifica el equipo de seguridad del cliente
La verificación suele abarcar puntos específicos que van más allá de una conversación sobre funcionalidades. El equipo de infosec del cliente quiere saber si el producto ha pasado por una prueba realizada por profesionales con certificaciones reconocidas internacionalmente, qué vectores de ataque se han probado, qué vulnerabilidades se han encontrado y qué se ha hecho para corregirlas.
El informe del pentest es el documento que responde a estas preguntas. Sin él, el SaaS no tiene evidencias concretas que presentar, solo afirmaciones. Y una afirmación, en un proceso de due diligence, no hace avanzar la negociación.
El peso del sector y del volumen de datos
Cuanto más sensibles sean los datos que procesa el SaaS, más riguroso será el proceso de evaluación. Un producto que gestiona datos de salud, datos financieros o información de menores se enfrenta a requisitos aún más específicos, incluido el cumplimiento de normativas sectoriales que pueden exigir ciclos de pruebas más frecuentes.
Incluso los productos que procesan datos aparentemente sencillos, como información de empleados o registros de acceso, se evalúan cada vez con mayor atención porque representan posibles puntos de entrada para movimientos laterales dentro del entorno del cliente.
Por qué los inversores también han empezado a exigirlo
La exigencia de un pentest no procede únicamente del ámbito comercial. En rondas de inversión, especialmente a partir de Series A, la due diligence técnica ha empezado a incluir una evaluación de seguridad con una profundidad que hasta hace poco no era habitual.
El motivo es directo: un inversor que entra en un producto SaaS está asumiendo exposición al riesgo de un incidente de seguridad. Una vulnerabilidad explotada después de la inversión puede generar sanciones regulatorias, pérdida de contratos y daños reputacionales con un impacto directo en la valoración.
Qué evalúa la due diligence técnica de un inversor
El proceso varía según el inversor, pero hay puntos que aparecen de forma consistente. Historial de incidentes y cómo se gestionaron. Políticas de acceso y control interno. Cumplimiento de la LGPD y de las normativas aplicables al sector. Y la existencia de pruebas de seguridad realizadas por terceros independientes.
Un producto que nunca ha sido probado externamente es un producto cuyo riesgo de seguridad es, por definición, desconocido. Los inversores con experiencia en tecnología saben que los entornos que nunca se han puesto a prueba bajo presión real revelan sus vulnerabilidades en el momento menos conveniente posible.
El pentest como señal de madurez
Además de ser una evidencia técnica, el pentest es una señal de actitud. Un producto que realiza pruebas anuales con una empresa especializada, trata las vulnerabilidades encontradas y mantiene el historial documentado está demostrando que la seguridad se aborda como un proceso, no como una reacción.
Esta distinción es importante para los inversores porque indica cómo responderá el equipo cuando aparezca un problema real. Los founders con un historial de pruebas tienen una perspectiva más ajustada sobre el riesgo que aquellos que nunca han puesto el producto a prueba de forma independiente.
Qué necesita tener el SaaS antes de la due diligence
Llegar a una negociación corporativa o a una ronda de inversión sin documentación de seguridad coloca al producto en una posición defensiva desde el principio. Construir esta base previamente es lo que permite entrar en estas conversaciones con solvencia.
El mínimo esperado por clientes e inversores maduros incluye un informe de pentest reciente realizado por una empresa especializada, la documentación de lo que se corrigió después de la prueba, una política de seguridad de la información formalizada y un proceso de respuesta ante incidentes definido.
La frecuencia recomendada para productos en crecimiento activo es un pentest anual, complementado con análisis de vulnerabilidades en ciclos mensuales. Los productos de sectores regulados o con contratos en negociación pueden necesitar ciclos más cortos, dependiendo de los requisitos específicos del cliente o del inversor.
Qué ocurre cuando el SaaS no tiene este historial
El escenario más habitual es que el negocio se detenga durante la fase de evaluación técnica. El producto supera todas las etapas comerciales, genera un interés real por parte del cliente y acaba encontrándose con un formulario de seguridad que no puede responder con evidencias.
En algunos casos, el cliente ofrece un plazo para que el proveedor presente la documentación. Realizar un pentest con prisas para cumplir un plazo comercial es posible, pero el informe generado en esas condiciones rara vez tiene la profundidad que un equipo de infosec experimentado considera suficiente.
El coste de construir esta base antes de entrar en negociaciones relevantes es significativamente menor que el coste de perder contratos que ya habían llegado a una fase avanzada de evaluación.
STWBrasil realiza pentests anuales para productos SaaS con profesionales certificados internacionalmente, informes estructurados para equipos técnicos y dirección, y documentación trazable para procesos de due diligence. Si tu empresa se está preparando para contratos corporativos o para una ronda de inversión, habla con nuestro equipo.
