Auditoría de ciberseguridad antes de vender tu empresa

Por Kike Gandia · Co-Fundador y CEO, OSCP

En cualquier proceso de venta o fusión (M&A), el comprador va a hacer su propio due diligence técnico, y si es el primero en encontrar un problema de seguridad, esa vulnerabilidad se convierte en su palanca de negociación. Una auditoría de ciberseguridad hecha por tu lado antes de sacar la empresa al mercado te permite llegar al proceso con los deberes hechos: sin sorpresas para el comprador y sin margen para que use un hallazgo técnico como excusa para rebajar el precio.

Qué revisa el comprador y por qué te interesa adelantarte

El due diligence técnico de una adquisición cubre vulnerabilidades activas en tu infraestructura y aplicaciones, higiene de gestión de accesos (cuentas huérfanas, privilegios excesivos, credenciales compartidas), historial de incidentes de seguridad no resueltos, y cumplimiento normativo si operas en un sector regulado. Cualquier hallazgo que descubra el equipo del comprador se convierte automáticamente en un argumento de negociación a su favor. Si lo encuentras y corriges tú antes, esa munición desaparece.

El momento correcto para hacerla

Idealmente entre 3 y 6 meses antes de iniciar el proceso de venta formal. Da margen suficiente para remediar hallazgos importantes sin la presión de una operación en marcha, y el informe sigue siendo lo bastante reciente como para presentarlo como evidencia durante el due diligence del comprador.

Qué transmite tener un informe propio y limpio

Más allá de evitar sorpresas, un informe de auditoría reciente con hallazgos ya remediados es una señal de madurez operativa que el comprador valora positivamente: indica que la empresa se gestiona con criterio de seguridad, no solo de producto. En procesos competitivos con varios compradores interesados, esta documentación puede acelerar el cierre porque reduce las preguntas abiertas en la fase de diligence.

Qué debe incluir el informe para servir en el proceso de venta

No basta con un escaneo automático. El informe debe incluir metodología, alcance cubierto, hallazgos clasificados por severidad con evidencia (PoC), estado de remediación de cada uno, y una carta de validación (re-test) para los críticos ya corregidos. Es este nivel de detalle el que un asesor de M&A o un comprador técnico exige para darlo por válido.

Lo que un comprador ve en media hora dentro de tu consola de administración

Buena parte de los hallazgos que aparecen en un due diligence no vienen de un pentest sofisticado, sino de media hora con permisos de lectura sobre la consola de Google Workspace o Microsoft 365. Conviene mirarlo tú antes:

Qué mira	Dónde se ve	Qué concluye si está mal
Número de superadministradores	Listado de roles de administración de la consola	Diez superadmins en una empresa de treinta personas indica que nadie gestiona privilegios
Cobertura real del doble factor	Informe de verificación en dos pasos / autenticación multifactor	Excepciones concentradas en dirección o en cuentas antiguas
Cuentas activas de personas que ya no están	Listado de usuarios frente al organigrama	Falta de proceso de baja: el hallazgo más repetido en M&A
Aplicaciones de terceros con acceso vía OAuth	Controles de API y acceso de aplicaciones	Integraciones olvidadas con permisos amplios sobre correo o ficheros
Retención del registro de auditoría	Configuración de registros y cumplimiento	Sin histórico no se puede demostrar que no hubo un incidente previo
Ficheros compartidos con enlace público	Informes de uso compartido externo	Documentación interna o de clientes accesible sin autenticación

Y conviene saber qué no se ve desde la consola sin ir a buscarlo expresamente: las reglas de reenvío automático configuradas por cada usuario en su propio buzón son el ejemplo clásico. No aparecen en el panel general y son, a la vez, el mecanismo de persistencia más común tras un compromiso de correo. Revisarlas requiere consultar los registros o la configuración usuario a usuario, y es exactamente el tipo de cosa que un comprador técnico pregunta.

FAQ

¿Esto sustituye al due diligence que hará el comprador?

No, lo complementa. El comprador hará su propia revisión (o exigirá acceso a la tuya), pero llegar con un informe propio reciente reduce drásticamente lo que encuentran por su cuenta y acelera el proceso.

¿Qué pasa si la auditoría encuentra algo grave?

Mejor encontrarlo tú con meses de margen que el comprador durante la negociación. Un hallazgo remediado antes de sacar la empresa al mercado no afecta a la valoración; uno descubierto por el comprador, sí.

¿Sirve el mismo informe para varios compradores potenciales?

Sí, siempre que se mantenga razonablemente actualizado (no más de 6-12 meses) y se acompañe de evidencia de que los hallazgos siguen remediados en el momento del proceso.

¿Y si el comprador pide la auditoría la semana que viene, no con meses de margen?

Se puede acotar el análisis a los sistemas que sostienen el valor real del negocio y priorizar arranque y equipo dedicado para comprimir el plazo. Lo que no conviene saltarse es la verificación manual y el re-test de lo remediado: en nuestra guía sobre pentesting y auditoría exprés explicamos exactamente qué se puede acelerar y qué no.

¿Hay que contarle al equipo que se está haciendo esta auditoría?

Al equipo técnico, sí: necesitas su colaboración para el alcance, los accesos y la remediación, y una auditoría a espaldas de IT genera ruido justo cuando menos conviene. Al resto de la organización no hace falta darle contexto de la operación: basta presentarlo como una revisión de seguridad, que además es cierto. Si la venta es confidencial, conviene que el contrato con el proveedor lo recoja y que el informe no mencione el proceso de M&A.

¿Qué permisos necesita el auditor y durante cuánto tiempo?

Para la parte de revisión, acceso de solo lectura a las consolas de administración del entorno de correo y colaboración y del cloud, más el inventario de activos y proveedores; para la parte técnica, las credenciales de prueba de los distintos roles de la aplicación. No necesita acceso administrativo con permisos de escritura ni a datos reales de clientes: si los necesitase para probar algo, se trabaja con datos anonimizados. Los accesos se conceden acotados al periodo del trabajo y se revocan al entregar el informe, y ese propio ciclo de alta y baja es una evidencia útil de que existe control de accesos.

¿Hace falta el re-test o basta con decir que se ha corregido?

Hace falta, y es la parte que más valor aporta en el proceso. Un hallazgo marcado como "corregido" por el propio equipo no es evidencia; una carta de validación del auditor que confirme que el crítico ya no es explotable, con fecha, sí lo es. Es también lo que permite presentar un informe con hallazgos sin que eso juegue en contra: lo que se lee entonces no es "tenían vulnerabilidades", sino "las encontraron y las cerraron".

¿Qué hacemos con los hallazgos que no da tiempo a corregir?

Se documentan con una decisión explícita: se acepta el riesgo, se mitiga parcialmente o se planifica con fecha y responsable. Un hallazgo abierto con una decisión razonada detrás resiste bien la conversación con el comprador; el mismo hallazgo sin mención alguna aparece después como algo que se ocultó, aunque no fuera la intención.