Checklist de seguridad antes de una ronda de inversión

Por Kike Gandia · Co-Fundador y CEO, OSCP

Preparar el due diligence de seguridad no consiste en improvisar documentos la semana antes del cierre: es una lista corta y concreta de cosas que hacer con 2 meses de antelación. Esta checklist resume, en orden de prioridad, lo que debe estar listo antes de sentarte con el equipo de due diligence del inversor.

Lo que debe estar listo 6-8 semanas antes

1. Pentest de producto reciente (últimos 12 meses), con hallazgos críticos ya remediados y evidencia de re-test. 2. Política de seguridad de la información documentada, aunque sea de 3-4 páginas. 3. Registro de gestión de accesos: quién tiene acceso a qué sistemas y por qué. 4. Plan de respuesta a incidentes básico: quién hace qué en las primeras 24 horas de un incidente.

Lo que ayuda pero no es imprescindible en fases tempranas

Inventario de proveedores y qué datos comparten con cada uno; política de retención y borrado de datos; evidencia de formación anti-phishing al equipo; y un resumen ejecutivo de una página que traduzca todo lo anterior a lenguaje no técnico para el comité de inversión.

Errores frecuentes que retrasan el cierre

Presentar un pentest de hace más de 18 meses (los inversores lo consideran obsoleto), no tener ningún documento de gestión de accesos aunque el sistema técnico esté bien diseñado, o improvisar respuestas ante preguntas sobre incidentes pasados en vez de tener un registro objetivo, aunque sea breve.

Cómo priorizar si el tiempo aprieta

Si solo puedes hacer una cosa, que sea el pentest: es lo que más tarda en programarse y lo que más peso tiene en la evaluación. El resto de documentos (políticas, registros) se pueden redactar internamente en días si ya tienes claro qué prácticas sigues, aunque no estén escritas.

Quién produce cada pieza y qué la deja inservible

La checklist se atasca casi siempre por el mismo motivo: nadie tiene asignada cada pieza. Esta tabla cierra esa parte.

Pieza	Quién la produce	Margen que necesita	Qué la deja inservible
Informe de pentest	Proveedor externo	Semanas: agenda + ejecución + re-test	Que tenga más de 12-18 meses, o que los críticos sigan abiertos sin plan
Política de seguridad	Interna, con revisión externa	Días	Estar sin firmar, sin fecha o sin versión
Registro de gestión de accesos	IT o el responsable técnico	Días	Listar herramientas y no personas; no reflejar bajas recientes
Plan de respuesta a incidentes	Interna	Días	No decir quién decide ni a quién se notifica en las primeras 24 horas
Inventario de proveedores y datos	Operaciones o finanzas	Días	Omitir las herramientas SaaS contratadas fuera de IT

El patrón que detecta un analista con experiencia es la coherencia entre piezas: si el registro de accesos no menciona la herramienta de la que habla la política, la conclusión no es que falte un documento, sino que ninguno describe cómo trabajáis de verdad.

Qué se entrega y en qué formato

Hay una pregunta que casi nadie hace hasta que llega el momento: ¿se entrega el informe de pentest completo? Depende. Los hallazgos técnicos con pasos de reproducción son información sensible, y compartirlos en una data room a la que acceden varias partes no siempre es prudente. La alternativa habitual es una carta de atestación del proveedor —alcance, fechas, metodología, número de hallazgos por severidad y estado de remediación, sin el detalle explotable— y reservar el informe íntegro para revisión bajo NDA si el inversor lo pide expresamente. Conviene acordar con el proveedor que emitirá esa carta antes de contratar el trabajo: no todos la incluyen por defecto y pedirla después alarga el proceso justo cuando no hay margen.

FAQ

¿Necesito contratar a alguien externo para esta checklist?

El pentest sí requiere un proveedor especializado. La documentación de políticas y procesos puede redactarse internamente, aunque contar con apoyo externo suele acelerar el proceso y evita errores de formato que los analistas de due diligence ya conocen.

¿Esta checklist sirve también para una Serie B o C?

Es la base mínima. En fases posteriores, los inversores suelen añadir exigencias como SOC 2 o ISO 27001, que son proyectos de mayor alcance que esta checklist inicial.

¿Qué pasa si mi startup es muy joven y no tiene nada de esto?

Es habitual en fases pre-seed o seed. Empieza por el pentest y la política de seguridad: son las dos piezas que primero preguntan y las que dan mejor señal de madurez con menos esfuerzo.

¿Y si el inversor cierra en dos semanas, no en 6-8?

El pentest sigue siendo la pieza crítica y la que menos margen tiene, pero un proceso acotado al producto principal y con equipo dedicado se puede arrancar en días. En nuestra guía sobre pentesting y auditoría exprés explicamos qué se puede acelerar de verdad y qué no conviene comprimir.

¿Qué preguntan en la llamada técnica de due diligence?

Casi siempre las mismas cuatro cosas, y ninguna requiere preparación si el equipo trabaja con criterio: quién tiene acceso de producción y cómo se concede o se retira; qué pasa cuando alguien deja la empresa; cómo llega un cambio de código a producción y quién lo revisa; y qué haríais en la primera hora de una brecha. Lo que evalúa el analista no es la sofisticación de la respuesta, sino si la persona responde con hechos o con intenciones.

¿Importa quién haga el pentest?

Importa la metodología y la trazabilidad, no la marca. Lo que se mira es que el informe declare el alcance exacto, las fechas, la metodología seguida, evidencias reproducibles por hallazgo y el estado de remediación verificado en un re-test. Un informe generado principalmente por un escáner automático se reconoce enseguida —hallazgos genéricos, sin contexto de negocio, sin prueba de explotación— y resta credibilidad en lugar de sumarla.

¿Hay que arreglar todos los hallazgos antes de la ronda?

No, y pretenderlo suele retrasar el cierre sin aportar nada. Lo esperable es tener cerrados los críticos y altos que afectan a datos de clientes o a la disponibilidad del producto, y los demás recogidos en un plan con responsable y fecha. Un plan de remediación con fechas realistas se lee como gestión; una lista vacía de hallazgos, como una auditoría superficial.

¿Dónde se guarda todo esto durante el proceso?

En la data room, junto al resto de la documentación, pero conviene separar niveles de acceso: las políticas y el resumen ejecutivo pueden estar disponibles para todo el comité, mientras que el detalle técnico de vulnerabilidades se comparte de forma restringida y con registro de quién lo ha descargado. Revisar los permisos de la propia data room es, además, una de esas cosas que un analista de seguridad comprueba de pasada y comenta.