Un cliente me pide garantías de seguridad de mi aplicación: qué necesito

Por Kike Gandia · Co-Fundador y CEO, OSCP

Es la conversación que aparece en cuanto empiezas a vender a empresas, y suele llegar sin aviso: el equipo de compras o el de seguridad de tu cliente te manda un cuestionario, o te pide directamente "el informe de seguridad". Si construiste el producto con IA y nunca has pasado por esto, la reacción habitual es improvisar. Esta guía explica qué te van a pedir realmente, qué puedes responder hoy sin gastar un euro y qué necesitas conseguir si quieres cerrar el trato.

Qué te van a pedir, en orden de probabilidad

Un cuestionario de seguridad. Un formulario, a veces de cien preguntas, sobre cifrado, control de accesos, copias de seguridad, gestión de incidentes y subencargados. Es lo más frecuente con diferencia.

Un informe de pentest reciente. Normalmente del último año, y cada vez más a menudo piden que sea de un tercero independiente, no una autoevaluación.

Un acuerdo de tratamiento de datos (DPA). Si tu aplicación trata datos personales de los clientes de tu cliente, esto no es opcional: es una obligación del RGPD para ambas partes.

Certificaciones. ISO 27001 o SOC 2. Son las más caras y lentas de conseguir, y normalmente solo las exigen empresas grandes o sectores regulados.

Detalles de arquitectura: dónde se alojan los datos, en qué país, qué subencargados intervienen y cómo se segregan los datos entre clientes.

Qué puedes responder hoy sin gastar nada

Más de lo que parece. Buena parte del cuestionario se responde con información que ya tienes, solo que nunca la has escrito:

Dónde se alojan los datos y en qué región. Lo sabes: es la configuración de tu proveedor.
Qué subencargados usas. Tu proveedor de datos, el de correo, el de pagos, el de analítica. Hazte la lista una vez y reutilízala siempre.
Cómo se autentican los usuarios y si hay segundo factor disponible.
Qué datos guardas de verdad. Este ejercicio suele revelar que almacenas campos que nadie usa, y eliminarlos mejora la respuesta y reduce el riesgo.
Tu política de copias de seguridad, aunque sea la que trae el proveedor por defecto.

Responder "no lo sé" a estas preguntas es lo que hunde una revisión. Responder "usamos las copias automáticas del proveedor, con retención de siete días" es una respuesta perfectamente válida.

Qué no puedes improvisar

Hay dos cosas que no se resuelven redactando.

El informe de pentest. No existe forma de fabricarlo: o alguien ha probado tu aplicación o no. Y afirmar en un cuestionario que has hecho pruebas de seguridad cuando no las has hecho es una declaración contractual falsa, con consecuencias muy distintas a las de admitir que no las has hecho todavía.

Las certificaciones. ISO 27001 o SOC 2 llevan meses y exigen evidencias de operación acumuladas en el tiempo. Si tu cliente las pone como requisito duro y no las tienes, la vía realista es negociar un plan con fechas, no prometerlas para el mes que viene.

En ambos casos, lo que sí funciona es la honestidad acompañada de plan: "no tenemos certificación; sí tenemos una auditoría técnica de junio y este es el plan de remediación" es una posición defendible. "Sí, todo correcto" sin nada detrás se cae en la primera pregunta de seguimiento.

El orden que más trato cierra

Si estás en medio de una venta y tienes semanas, no meses:

1. Pasa las comprobaciones básicas sobre tu propia aplicación para saber si tienes un problema grave antes de que lo encuentre tu cliente.
2. Cierra lo crítico que aparezca. Un fallo de acceso encontrado por el cliente durante la evaluación normalmente termina la conversación.
3. Escribe el inventario: datos que guardas, dónde, subencargados, accesos.
4. Encarga una auditoría técnica externa con informe entregable. Es lo que convierte el cuestionario en un trámite.
5. Deja la certificación para después del contrato, salvo que sea requisito de entrada.

El error caro es el inverso: empezar por la certificación, tardar ocho meses y perder el cliente por el camino.

Por qué esto se parece a una due diligence de inversor

Las preguntas son casi las mismas y el momento es igual de malo para improvisar. Un inversor en una ronda A o B revisa exactamente esto: qué datos tratas, quién tiene acceso, si alguien ha probado el producto y qué encontró.

La diferencia está en la consecuencia. Un cliente que no queda satisfecho no firma; un inversor que encuentra un problema de seguridad no suele retirarse, pero lo usa en la negociación. En los dos casos, el material que necesitas preparar es el mismo, así que conviene hacerlo una vez y mantenerlo vivo en lugar de rehacerlo con cada conversación.

FAQ

¿Vale un informe de pentest de hace dos años?

Casi nunca. La referencia habitual son doce meses, y muchos cuestionarios lo dicen explícitamente. La lógica es razonable: si tu producto ha cambiado desde entonces, el informe describe una aplicación que ya no existe. Un informe antiguo acompañado de un re-test reciente sobre los hallazgos sí suele aceptarse.

Mi cliente pide ISO 27001 y soy una empresa de tres personas, ¿qué hago?

Pregunta primero si es un requisito duro o una preferencia, porque muchas veces es lo segundo y se sustituye por una auditoría técnica externa más un compromiso de certificación con fecha. Si es duro y el contrato lo justifica económicamente, el camino existe, pero cuenta con entre seis y doce meses y con dedicación real de alguien del equipo.

¿Tengo que enseñar el informe de pentest completo?

No necesariamente, y no suele ser buena idea: contiene el detalle de explotación de tus vulnerabilidades. Lo habitual es entregar una carta de atestación o un resumen ejecutivo emitido por quien hizo la auditoría, que confirma alcance, fechas, metodología y estado de remediación sin publicar los detalles técnicos. Pide ese formato al contratar la auditoría.