La seguridad como prerrequisito de venta: cómo pasar el security questionnaire y la due diligence enterprise

Por qué el cliente enterprise transforma la seguridad en condición de compra

Cuando una empresa grande contrata a un proveedor de software, está extendiendo su propia superficie de ataque. Si tu startup procesa, almacena o solo accede a datos del cliente, cualquier falla tuya se vuelve un incidente suyo — con obligaciones regulatorias, contractuales y reputacionales que recaen sobre el comprador. Por eso, las áreas de procurement, jurídico y seguridad de la información (frecuentemente un equipo de Third-Party Risk Management) evalúan tu nivel de seguridad antes de firmar. Ese proceso es el vendor security review, y es parte del ciclo de ventas, no un detalle poscontrato.

En la práctica, la evaluación llega de dos formas. La primera es el security questionnaire: una planilla o portal con decenas a cientos de preguntas sobre tus controles, frecuentemente basado en frameworks estandarizados como el SIG (Shared Assessments) o el CAIQ (Cloud Security Alliance). La segunda es la due diligence de seguridad propiamente dicha: solicitud de informes de atestación (SOC 2), certificaciones (ISO 27001), resultados de pentest, políticas formales y, a veces, una call técnica con tu equipo. Para las fintechs, se suma la capa regulatoria — las exigencias alineadas a normas del Banco Central y a la LGPD aparecen en el mismo paquete.

El punto que cambia el juego para el founder es el timing. Las empresas enterprise tienen un estándar mínimo de proveedor, y cuando no logras evidenciar controles, el negocio no es rechazado de forma explícita — simplemente se traba. El contrato queda detenido por el riesgo, el champion interno pierde fuerza, y el ciclo de ventas se extiende por meses. Tratar la seguridad como una capacidad comercial significa preparar las evidencias antes de que llegue el cuestionario, y no improvisar respuestas bajo la presión de un deal en riesgo.

SOC 2, ISO 27001 y los controles mínimos: qué pide realmente cada cliente

Es común confundir los dos principales artefactos. El SOC 2 es un informe de atestación emitido por un auditor independiente (CPA), siguiendo los Trust Services Criteria de la AICPA — Security (obligatorio), y opcionalmente Availability, Processing Integrity, Confidentiality y Privacy. Existe en dos modalidades: el Tipo I evalúa el diseño de los controles en un punto en el tiempo; el Tipo II evalúa la operación efectiva a lo largo de un período (típicamente de 3 a 12 meses). Es un informe, no un sello — el cliente lee el documento. En cambio, la ISO/IEC 27001 es una certificación de un Sistema de Gestión de Seguridad de la Información (SGSI); un organismo certificador audita tu sistema y emite un certificado, con los controles de referencia en el Anexo A (alineados a la ISO/IEC 27002).

La elección no es técnica, es de mercado. Los clientes en Estados Unidos casi siempre piden SOC 2 Tipo II. Los clientes europeos, de Medio Oriente y las grandes corporaciones globales tienden a pedir ISO 27001. Si vendes a ambos mundos, la buena noticia es que los controles subyacentes se superponen mucho — buena parte del trabajo sirve para los dos caminos. La mala noticia es que ambos toman tiempo: un SOC 2 Tipo II exige un período de observación, y la certificación ISO involucra auditoría de etapa 1 y 2. Por eso importa la secuenciación.

Antes de cualquier certificación, existe el conjunto de controles mínimos que prácticamente todo cuestionario exige, independientemente del framework. En línea con el NIST Cybersecurity Framework, los CIS Critical Security Controls y el OWASP ASVS, el piso es: autenticación multifactor (MFA) en todos los accesos administrativos y de producción; cifrado en tránsito (TLS) y en reposo; gestión de identidad y acceso con privilegio mínimo y RBAC; inventario de activos y gestión de vulnerabilidades; logging y monitoreo centralizados; plan documentado de respuesta a incidentes; backups probados; gestión de proveedores y subprocesadores; y un SDLC con revisión de código y pruebas de seguridad. Ese paquete, documentado en políticas y con evidencias de operación, resuelve la mayoría de los primeros deals enterprise — y es la base sobre la cual Decripte ayuda a las startups a construir, con el plan gratuito de Gestión de Amenazas para dar visibilidad inicial y servicios de cumplimiento y pentest para cerrar las brechas que el cliente va a exigir.

Cómo una startup reducida se prepara sin montar un equipo de 10 personas

La trampa más cara es tratar el cumplimiento como un proyecto puntual de TI. El camino sostenible es construir un security baseline que crece con la empresa. Comienza por un inventario honesto: qué datos de clientes tocas, dónde viven (qué servicios de nube, qué subprocesadores), quién tiene acceso y por qué. Ese mapa es la base de cualquier respuesta de cuestionario y de cualquier auditoría. Sin él, respondes por adivinación — y los auditores y equipos de TPRM lo perciben.

En seguida, formaliza el mínimo de políticas. No tiene que ser un mamotreto: una política de seguridad de la información, una de control de acceso, una de respuesta a incidentes, una de gestión de proveedores y una de desarrollo seguro ya sostienen la mayoría de las preguntas. El secreto es que una política sin evidencia no pasa en una auditoría Tipo II: el cliente quiere ver que el control opera. Si la política dice que los accesos se revisan trimestralmente, necesitas el registro de las revisiones. Diseña los controles de modo que generen evidencia automáticamente — logs, tickets, pull requests con aprobación obligatoria.

Sobre la decisión de hacerlo interno versus tercerizar: para una startup pre-Serie B, tiene poco sentido contratar un equipo de seguridad completo solo para el cumplimiento. El modelo eficiente combina un responsable interno (la primera contratación de seguridad, o el CTO acumulando al inicio) con socios externos para lo que exige especialización e independencia — pentest, gap assessment contra SOC 2 o ISO 27001, y soporte en la preparación de la auditoría. Es exactamente ahí donde Decripte actúa: visibilidad continua de amenazas en el plan gratuito, y servicios de cumplimiento y pentest para que llegues a la auditoría con las brechas ya cerradas, sin inflar el headcount.

Respondiendo al security questionnaire sin trabar el deal

El cuestionario es donde la mayoría de las startups pierde tiempo innecesario. La primera regla es nunca tratar cada cuestionario como un esfuerzo nuevo. Arma un repositorio central de respuestas — un security package reutilizable — con las preguntas más comunes ya respondidas y versionadas: arquitectura, cifrado, gestión de acceso, retención de datos, subprocesadores, plan de continuidad, proceso de respuesta a incidentes. Cuando llega un CAIQ o SIG, lo adaptas en lugar de escribir desde cero.

La segunda regla es responder con precisión, no con aspiración. Los equipos de TPRM verifican la consistencia entre lo que dices en el cuestionario, lo que está en las políticas y lo que aparece en el informe SOC 2 o en el pentest. Una respuesta inflada que no coincide con la evidencia destruye la confianza y genera rondas extra de preguntas — exactamente lo que alarga el ciclo. Si un control aún no existe, di que está en el roadmap con fecha; la madurez honesta convence más que la perfección fingida. Un trust center público (página con tus certificaciones, políticas de alto nivel y subprocesadores) reduce la cantidad de cuestionarios, porque el comprador encuentra la mitad de las respuestas antes de pedirlas.

Para las fintechs, anticipa la capa regulatoria dentro del mismo flujo: tratamiento de datos personales conforme a la LGPD, base legal, encargado (DPO), y los requisitos que los clientes regulados trasladan a los proveedores. Cuanto más listas estén esas respuestas y coherentes con tus evidencias técnicas, menos quedará el deal atrapado entre tu equipo comercial y el jurídico del cliente.

Secuenciación: qué hacer primero para destrabar ingresos

La pregunta correcta no es 'SOC 2 o ISO 27001', sino 'qué exige el próximo deal'. Deja que la demanda del pipeline guíe la inversión. Si los deals que se están trabando piden SOC 2 Tipo II, comienza por el gap assessment, implementa los controles, haz un Tipo I para tener algo que mostrar rápido, y entra en el período de observación del Tipo II. Si los clientes piden ISO 27001, estructura el SGSI y planifica las auditorías de etapa 1 y 2. En ambos casos, los controles mínimos vienen antes — ellos destraban los primeros deals mientras la certificación madura.

Trata el pentest como un acelerador transversal: casi todo cuestionario enterprise pregunta sobre pruebas de penetración, y un informe reciente de un tercero independiente vale más que cualquier afirmación en el cuestionario. Un pentest de aplicación alineado a OWASP, con corrección de las vulnerabilidades y retest, es frecuentemente el ítem que falta para liberar un contrato — y es más rápido de obtener que una certificación completa. Por eso suele ser la primera inversión de retorno comercial directo.

El resultado de secuenciar bien es que la seguridad deja de ser un costo defensivo y pasa a ser una palanca de ingresos: cada control implementado abre una franja de clientes que antes estaba fuera de alcance. Decripte ayuda a diseñar esa hoja de ruta — comenzando por la visibilidad gratuita de amenazas, pasando por el gap assessment de cumplimiento y por el pentest, hasta el soporte en la auditoría — para que el cronograma de seguridad acompañe al cronograma de ventas, y no al contrario.

Checklist práctico

1. 1

   1. Mapea datos, accesos y proveedores

   Documenta qué datos de clientes procesas, dónde residen (proveedores de nube y subprocesadores), quién tiene acceso y con qué privilegio. Ese inventario es la fundación de cualquier cuestionario y de cualquier auditoría; sin él, todas las respuestas se vuelven suposición.

2. 2

   2. Implementa los controles mínimos

   Garantiza MFA en todos los accesos de producción y administración, cifrado en tránsito y en reposo, RBAC con privilegio mínimo, logging centralizado, backups probados y gestión de vulnerabilidades. Usa NIST CSF y CIS Controls como referencia para no olvidar ninguna categoría.

3. 3

   3. Formaliza las políticas esenciales

   Escribe políticas concisas y reales de seguridad de la información, control de acceso, respuesta a incidentes, gestión de proveedores y desarrollo seguro. Diseña cada control para generar evidencia automática (logs, tickets, aprobaciones de pull request), porque la auditoría Tipo II evalúa la operación, no la intención.

4. 4

   4. Arma un security package reutilizable

   Crea un repositorio versionado con respuestas para las preguntas más comunes de CAIQ y SIG, diagrama de arquitectura, lista de subprocesadores y resumen de controles. Considera publicar un trust center para reducir el volumen de cuestionarios recibidos.

5. 5

   5. Haz un pentest independiente y corrige

   Contrata una prueba de penetración alineada a OWASP, prioriza la corrección de las vulnerabilidades por severidad y solicita el retest. Un informe reciente de un tercero frecuentemente es el ítem que falta para liberar un contrato enterprise.

6. 6

   6. Elige el framework guiado por el pipeline

   Deja que la demanda de los deals decida entre SOC 2 e ISO 27001. Haz un gap assessment contra el framework objetivo, cierra las brechas y secuencia — Tipo I antes del Tipo II en el caso del SOC 2; etapas 1 y 2 en el caso de la ISO.

7. 7

   7. Mantenlo como operación continua

   El cumplimiento no es un evento único. Establece revisiones periódicas de acceso, monitoreo continuo de amenazas, gestión de vulnerabilidades recurrente y actualización del security package con cada nuevo control. Es esto lo que sostiene una renovación de SOC 2 Tipo II y el mantenimiento de la certificación ISO.

Preguntas frecuentes