Ciberseguridad para SaaS startup: ISO 27001 y SOC 2 desde semilla 2026

Una startup SaaS B2B moderna nace con dos relojes corriendo a la vez. El primero es el reloj de producto: encontrar product-market fit, iterar, contratar y crecer. El segundo, casi siempre subestimado, es el reloj de compliance: los primeros clientes enterprise serios llegan con un cuestionario de seguridad de 200 preguntas, una expectativa explícita de SOC 2 Type 2 o ISO 27001 y, en muchos casos, una cláusula contractual que condiciona la firma a presentar el informe en un plazo de 6 a 12 meses. Esta guía explica cuándo y cómo activar ese segundo reloj sin frenar el primero: qué marco elegir entre ISO 27001, SOC 2 Type 1 y SOC 2 Type 2 según mercado, cuándo es el tipping point real, cómo aprovechar plataformas tipo Drata, Vanta o Secureframe sin caer en compliance theatre, qué configuraciones por defecto de AWS, Azure y GCP son inseguras, qué meter en un trust center público y cómo responder cuestionarios sin paralizar al CTO.

Lo esencial

• Una startup SaaS B2B necesita compliance formal cuando un cliente enterprise lo bloquea como condición de firma, normalmente alrededor de Series A o del primer contrato anual por encima de 100.000 dólares.
• SOC 2 Type 2 sigue siendo el estándar de facto para vender a clientes B2B en Estados Unidos; ISO 27001 lo es para Europa y para licitaciones internacionales. Muchas startups acaban haciendo ambas con base documental compartida.
• Plataformas como Drata, Vanta o Secureframe no sustituyen al auditor ni al pentester: automatizan recolección de evidencia y reducen el coste interno, pero la auditoría externa y la prueba técnica siguen siendo obligatorias.
• Las configuraciones por defecto de AWS, Azure y GCP no son seguras para producción. Los CIS Benchmarks y los servicios nativos (AWS Security Hub, Azure Defender for Cloud, GCP Security Command Center) son el punto de partida razonable.
• Un trust center público bien construido reduce la fricción comercial: responde cuestionarios antes de recibirlos y acelera procurement.

Por qué una startup SaaS necesita compliance pronto

El patrón se repite en casi todas las startups B2B que pasan de los primeros clientes self-service o de SMB a clientes enterprise. Llega un deal importante, el equipo comercial lo cierra en tres reuniones, y al firmar el contrato el cliente envía un cuestionario de seguridad con cientos de preguntas, un anexo de cláusulas de procesamiento de datos, una lista de subprocesadores que revisar y, casi siempre, la pregunta clave: "¿tenéis SOC 2 Type 2 o ISO 27001?".

Si la respuesta es no, hay tres caminos. El primero: perder el contrato y aprenderlo. El segundo: comprometer una fecha de certificación a 6 o 9 meses y arrancar el proyecto a la carrera. El tercero: aceptar firmar con compromisos contractuales (informes intermedios, planes de remediación, gap analysis documentado) que reducen riesgo del cliente y compran tiempo. Los tres son legítimos, pero los tres tienen coste.

El cambio de fondo, y la razón por la que esto ya no es un problema de empresa grande, es que las áreas de vendor risk management y third-party risk han madurado mucho en los últimos cinco años. El cliente enterprise ya no se conforma con buena voluntad: pide informe, pide subprocesadores, pide pruebas y pide trust center. La pregunta no es si la startup tendrá que enfrentar esto, sino cuándo.

Hay tres señales que indican que el momento ha llegado:

1. Pipeline enterprise creciente. Si más del 20% del pipeline está en deals que pasan por procurement formal, compliance ya es palanca comercial.
2. Procesamiento de datos sensibles. Si la plataforma maneja datos de salud, datos financieros, datos de menores o datos de empleados de los clientes, la presión normativa llega antes.
3. Inversores con tesis B2B. Los fondos con experiencia en SaaS B2B preguntan por compliance en due diligence desde Series A, a veces desde semilla, y suelen condicionar tramos al avance del programa.

ISO 27001 vs SOC 2 Type 1 vs SOC 2 Type 2

Las tres certificaciones se parecen mucho en el papel y son muy distintas en la práctica. La tabla resume las diferencias que afectan a la decisión de una startup.

La regla práctica que vemos en startups SaaS B2B:

• Si el mercado objetivo es Estados Unidos y los primeros clientes enterprise son americanos, SOC 2 Type 2 es el camino obligado. Empezar por Type 1 para tener algo que enseñar mientras corre el periodo de observación de Type 2 es una táctica habitual.
• Si el mercado es europeo o internacional con énfasis en sector público, ISO 27001 es el sello de entrada y abre licitaciones que SOC 2 no abre.
• Si el cliente lo es todo y aparece en los dos mercados, muchas startups acaban con ambas. La buena noticia es que el solapamiento documental entre ISO 27001 (Anexo A) y SOC 2 (Trust Services Criteria) supera el 80%, lo que hace que la segunda certificación cueste sensiblemente menos que la primera.

Para el contexto general de la norma, está la pieza ISO 27001 explicada y la guía detallada del certificado ISO 27001.

Cuándo empezar: el tipping point real

El error típico es activar compliance demasiado tarde, ya con el contrato sobre la mesa, y arrancar un proyecto de 9 meses con un compromiso comercial a 3. El error opuesto, igual de costoso, es activarlo demasiado pronto, en pre-revenue, y quemar dinero y atención del equipo en certificaciones que no aceleran ninguna venta concreta.

El tipping point razonable que vemos en startups SaaS B2B es uno de estos tres:

1. Series A cerrada y plan comercial que empuja hacia mid-market y enterprise. La conversación de compliance entra en la primera reunión del board post-Series A.
2. Primer contrato anual por encima de 100.000 dólares, sobre todo si ese contrato viene con cuestionario y cláusula contractual de auditoría.
3. Pipeline enterprise donde más del 20% de los deals abiertos pasan por procurement formal.

Antes de ese punto, la inversión razonable es preparar el terreno sin entrar en certificación formal: políticas mínimas, separación de entornos, control de accesos, MFA universal, gestión de secretos, logging básico, un pentest anual ligero y un gap analysis honesto contra ISO 27001 o SOC 2. Esto recorta meses cuando llega el momento.

Path realista 12 meses

La pregunta operativa es cómo organizar el año cuando ya está claro que toca certificarse. La hoja de ruta que mejor encaja en una startup SaaS de 20 a 80 personas es esta:

Mes 1 a 2: decisión, alcance y plataforma. Elección entre ISO 27001, SOC 2 Type 2 o ambos. Definición de alcance (qué producto, qué entornos, qué subsidiarias). Selección de plataforma de compliance automation (Drata, Vanta, Secureframe, Sprinto, Thoropass y similares) y de auditor externo. Las plataformas no son intercambiables, pero el coste de cambio en mes 2 es bajo.

Mes 2 a 4: políticas y controles base. Redacción de cuerpo documental mínimo (política de seguridad, control de accesos, gestión de incidentes, gestión de proveedores, continuidad, BYOD, criptografía). Integración de la plataforma con AWS, GitHub, Google Workspace, JIRA, herramientas de RRHH y endpoint para que la recolección de evidencia sea automática.

Mes 4 a 6: implementación técnica y formación. Cerrar gaps técnicos: MFA universal, SSO en aplicaciones críticas, cifrado en reposo y tránsito, gestión de vulnerabilidades, hardening de cloud, separación de entornos. Plan de formación y concienciación con evidencia (no basta con tener el contenido, hay que registrar quién lo ha completado).

Mes 6 a 8: auditoría interna y pentest. Ejecución de auditoría interna (obligatoria para ISO 27001, recomendable para SOC 2). Pentest externo de la aplicación y de la infraestructura cloud crítica. Este pentest es palanca doble: cierra requisito y produce evidencia para clientes.

Mes 8 a 12: auditoría externa. Para ISO 27001, Etapa 1 y Etapa 2 con la entidad certificadora elegida. Para SOC 2 Type 2, recorrido por el periodo de observación (3 a 12 meses según se haya planificado) y emisión del informe por la firma CPA.

Plataformas como Drata, Vanta y Secureframe encajan en este flujo principalmente en la recolección continua de evidencia (capturas de configuración, listas de usuarios, logs de revisiones de accesos, prueba de backups, prueba de restore). Reducen el trabajo interno de un equipo de seguridad pequeño, pero no sustituyen al auditor (que es independiente y certifica) ni al pentester (que es un servicio técnico distinto).

Cloud defaults inseguros

El segundo gran frente, junto al documental, es el técnico. La realidad incómoda es que las configuraciones por defecto de AWS, Azure y GCP no son seguras para producción. Sin endurecimiento, una startup acumula docenas de hallazgos críticos antes incluso de tener cliente enterprise.

Los patrones que vemos con más frecuencia en gap analysis iniciales:

• Cuenta root de AWS sin MFA, con claves de acceso activas y usadas para tareas operativas. El cumplimiento mínimo es eliminar las claves, activar MFA hardware, y reservar la cuenta root para operaciones excepcionales.
• Buckets S3 con bloqueo de acceso público deshabilitado o con políticas demasiado abiertas. AWS publica por defecto bloqueo, pero proyectos antiguos suelen tenerlo deshabilitado.
• Permisos IAM excesivos, con políticas estilo *:* o roles que se reutilizan sin justificación. La práctica saludable es mínimo privilegio aplicado, revisado y documentado.
• Sin MFA en consola y sin SSO corporativo integrado. Para una startup, integrar Okta, Google Workspace o Microsoft Entra ID con AWS IAM Identity Center es el atajo correcto.
• Logging desactivado o sin retención adecuada. CloudTrail, GuardDuty y Security Hub deben estar habilitados a nivel organización con retención compatible con la política y con los requerimientos contractuales.
• Sin gestión de secretos. Credenciales hardcodeadas en repositorios, variables de entorno sin rotación. La solución es AWS Secrets Manager, HashiCorp Vault o equivalente, con rotación automática.

La base técnica de referencia son los CIS Benchmarks para cada proveedor cloud, complementados por los servicios nativos: AWS Security Hub (que mide cumplimiento frente a CIS, NIST y PCI-DSS), Microsoft Defender for Cloud (en Azure) y Google Security Command Center (en GCP). Profundizamos los errores típicos en errores de configuración cloud en AWS y Azure y en pentesting cloud AWS, Azure y GCP.

Trust center público: qué incluir

El trust center es la página pública donde la startup centraliza todo lo que un comprador enterprise quiere saber antes de empezar el cuestionario. Bien hecho, recorta semanas de ida y vuelta y posiciona compliance como activo comercial. Mal hecho, es un pdf de 2 páginas que nadie lee.

Lo que debe contener un trust center serio:

• Certificaciones y atestaciones: ISO 27001, SOC 2 Type 2, PCI-DSS si aplica, HIPAA mapping, GDPR y otras según mercado. Con fechas, alcance y enlace para solicitar el informe bajo NDA.
• Lista pública de subprocesadores, con país, propósito y datos tratados. Compromiso de notificación previa de cambios (30 a 90 días según contrato tipo).
• Status page pública con histórico de incidentes y tiempo medio de resolución. Páginas tipo Statuspage de Atlassian o Better Stack son el estándar.
• Documentos descargables: política de seguridad, política de privacidad, DPA (Data Processing Agreement), guía de seguridad del producto, política de divulgación responsable.
• Security FAQ: las 30 a 50 preguntas más habituales en cuestionarios, ya respondidas. Esto reduce a la mitad el trabajo de procurement del cliente.
• Información de arquitectura: regiones de despliegue, segregación de datos por cliente o tenant, cifrado en reposo y tránsito, backups y RPO/RTO comprometidos.
• Programa de bug bounty o canal de divulgación responsable con compromiso de respuesta.

El trust center no inventa nada que no se haya hecho, pero estructura lo que sí se ha hecho para que sea consumible por un comprador en 10 minutos.

Security questionnaires comunes

Los cuestionarios de seguridad enterprise son el peaje real de vender SaaS a clientes grandes. Hay tres formatos que cubren la mayor parte de los casos:

VSA y SIG (Standardized Information Gathering), mantenidos por Shared Assessments. El cuestionario SIG tiene una versión Lite (alrededor de 130 preguntas) y una Core (más de 800 preguntas). Es el formato más extendido en banca, seguros y empresas grandes con vendor risk maduro.

CAIQ (Consensus Assessments Initiative Questionnaire) de la Cloud Security Alliance. Específico para proveedores cloud y SaaS, alineado con el CCM (Cloud Controls Matrix). Es el más solicitado para SaaS B2B con componente cloud relevante.

Custom enterprise questionnaires. Los grandes clientes suelen tener su propio cuestionario, a veces de 300 a 600 preguntas, que combina elementos de SIG, CAIQ, NIST CSF y requisitos sectoriales propios. La frecuencia y la longitud crecen con el tamaño del cliente.

La estrategia de respuesta razonable para una startup:

1. Mantener un respositorio interno único de respuestas (en plataformas tipo Vanta, Drata o herramientas dedicadas tipo Loopio, Responsive o SafeBase) que se reutiliza en cada cuestionario.
2. Publicar las respuestas más frecuentes en el trust center para que muchos cuestionarios se respondan solos.
3. Establecer un SLA interno de respuesta (típicamente 5 a 10 días laborables) para no bloquear ventas.
4. Asignar dueño claro del proceso (security o GRC), no dejarlo al comercial ni al CTO.

Pentesting requirements

El pentest es requisito implícito o explícito en los principales marcos.

ISO 27001:2022 control A.8.29 (Security testing in development and acceptance) exige pruebas de seguridad como parte del ciclo de vida del desarrollo y del proceso de aceptación. El control A.8.8 (Management of technical vulnerabilities) refuerza la necesidad de programa estructurado. En la práctica, el auditor espera ver un pentest anual mínimo del producto y de la infraestructura crítica, más pruebas adicionales en cambios significativos.

SOC 2 no lista el pentest como control único, pero los Trust Services Criteria (CC4.1, CC7.1, CC7.2) exigen monitorización y evaluación continua que en la práctica se cubre con pentest anual más escaneo continuo de vulnerabilidades.

PCI-DSS (si la startup procesa pagos directamente) exige pentest anual y tras cambios significativos.

La cadencia razonable para una startup SaaS B2B:

• Pentest anual completo de la aplicación principal (web y API) con metodología OWASP, documentado y con plan de remediación.
• Pentest de infraestructura cloud anual o cada 18 meses sobre los entornos de producción.
• Pentest delta ante cambios arquitectónicos relevantes (nueva integración crítica, nuevo módulo con datos sensibles, cambio de proveedor de identidad).
• Programa continuo de gestión de vulnerabilidades apoyado en herramientas SAST, SCA, DAST y escaneo cloud.

El detalle metodológico está en pentesting de aplicaciones web y en auditoría web guía completa.

Preguntas frecuentes

Una startup pre-revenue, ¿debería invertir en compliance?

Generalmente no en certificación formal. La inversión razonable pre-revenue es construir bien las bases técnicas (MFA, SSO, separación de entornos, gestión de secretos, logging) y mantener un cuerpo documental ligero. Certificarse formalmente sin ingresos significativos quema dinero y atención sin acelerar ventas concretas. La excepción es cuando el primer cliente identificado en el plan exige certificación como condición.

¿ISO 27001 o SOC 2 primero?

Depende del primer mercado relevante. Si los primeros clientes serios son americanos, SOC 2 Type 2 primero (con Type 1 intermedio si se necesita algo que enseñar antes). Si son europeos o de sector público, ISO 27001 primero. Si el plan comercial los pone a ambos, conviene empezar por el que cubra el primer contrato grande y planificar la segunda en el ciclo siguiente, reutilizando entre el 70% y el 80% del trabajo.

¿Drata, Vanta o Secureframe reemplazan al pentester?

No. Estas plataformas automatizan recolección de evidencia, gestión documental y monitorización continua de controles. No realizan pruebas de intrusión, no producen el informe de pentest que clientes y auditores piden, y no descubren vulnerabilidades de aplicación. El pentester sigue siendo un servicio independiente, ejecutado por equipo cualificado, con metodología y entregable propios.

Si mi SaaS está en AWS y AWS tiene SOC 2, ¿no estoy cubierto?

No. AWS gestiona la seguridad de la nube (datacenters, hardware, hipervisor, servicios gestionados). La startup gestiona la seguridad en la nube (configuraciones, identidades, datos, aplicaciones, código). Es el modelo de responsabilidad compartida. El SOC 2 de AWS demuestra el primer bloque; la startup necesita su propio SOC 2 o ISO 27001 para el segundo.

¿Cuál es el coste real de la primera auditoría?

Para una startup SaaS de 20 a 80 personas, el coste total del primer año (plataforma de automatización, consultoría, pentest, auditoría externa, formación) ronda los 40.000 a 90.000 dólares para SOC 2 Type 2 y los 30.000 a 70.000 euros para ISO 27001. Estas cifras varían según alcance, geografía y madurez técnica previa. El mantenimiento anual posterior suele bajar a la mitad o a un tercio del coste inicial.

Algunos clientes piden SOC 2 antes de estar compliance-ready, ¿qué hacer?

Tres opciones. Primero, ofrecer un gap analysis y plan de remediación documentado con fecha comprometida de informe (típicamente 6 a 12 meses). Segundo, firmar un NDA + Security Addendum que detalle medidas actuales con compromiso contractual de mejora. Tercero, ofrecer un SOC 2 Type 1 intermedio mientras corre el periodo de observación de Type 2. Las tres son aceptables para procurement maduro si se acompañan de evidencia técnica seria.

Recursos relacionados

• ISO 27001 explicada: qué es, SGSI y Anexo A
• Certificado ISO 27001: proceso, coste y plazos reales 2026
• Auditoría de ciberseguridad en empresas: guía
• Plantilla de política de seguridad ISO 27001
• Pentesting de aplicaciones web
• Empresa de ciberseguridad en Málaga

Acompañamiento startup compliance con Secra

En Secra acompañamos a startups SaaS desde el primer gap analysis hasta la auditoría externa, combinando consultoría ISO 27001, pentesting técnico ejecutado por equipo OSCP/OSWE y diseño del trust center público. Trabajamos con plataformas tipo Drata, Vanta y Secureframe cuando aportan valor, no como sustituto del criterio humano. Sin actuar como entidad certificadora (la separación obligatoria que exige la norma se respeta siempre). Cuéntanos tu caso y revisamos alcance, plazos y el camino más corto entre tu pipeline enterprise y el informe que tus clientes esperan.