Cumplimiento SOC 2 para startups: guía paso a paso

A un cliente más grande le gusta tu producto, compras te envía un cuestionario de seguridad y, más o menos en la pregunta cuarenta, te pide tu informe SOC 2. Sin él, el acuerdo se estanca o avanza con condiciones. Esta guía es para ese momento, escrita para una startup europea que vende a empresas más grandes que ella.

SOC 2 o ISO 27001: cuál primero

Los dos producen documentos distintos. Un informe SOC 2 es una atestación: un auditor independiente describe tu sistema, prueba tus controles frente a los Trust Services Criteria y emite una opinión, incluidas las excepciones que encuentre. No hay certificado; los compradores leen el informe. ISO 27001 certifica un sistema de gestión de seguridad de la información (SGSI). Un organismo de certificación acreditado lo audita y emite un certificado válido durante tres años, con auditorías de seguimiento entre medias.

Decide a partir de tus compradores. Reúne los últimos diez cuestionarios, RFPs y borradores de contrato que hayas recibido y anota qué pide cada uno por su nombre:

• SOC 2 pedido explícitamente, a menudo como "SOC 2 Type II": empieza por SOC 2. Es un marco de origen estadounidense, y los compradores norteamericanos suelen pedirlo por su nombre.
• Se pide un certificado ISO 27001, lo habitual en las compras de grandes empresas y del sector público europeos: empieza por ISO 27001.
• Ninguno de los dos: cualquiera sirve, así que elige el que acepte tu mayor acuerdo abierto.
• Clientes sujetos a NIS2 o DORA: deben gestionar la seguridad de sus proveedores, así que espera cláusulas sobre notificación de incidentes y derecho de auditoría además de cualquier informe.

El solapamiento es grande. Ambos esperan control de accesos, gestión de cambios, logging, respuesta a incidentes, gestión de proveedores y evaluación de riesgos, así que un mismo conjunto de controles de ingeniería sirve para los dos. ISO 27001 añade un sistema de gestión (tratamiento de riesgos, Declaración de Aplicabilidad, auditoría interna, revisión por la dirección); un SOC 2 Tipo II añade la prueba de que cada control funcionó durante todo un periodo. Construye los controles una vez y mapéalos a ambos. Para ver cómo encaja esto con el RGPD y NIS2, lee nuestra guía de cumplimiento en ciberseguridad entre jurisdicciones.

Alcance: sistemas, personas y criterios

El alcance es la frontera que prueba el auditor. Trázala alrededor del servicio que compran tus clientes:

• El entorno de producción: cómputo, almacenes de datos, colas y las redes entre ellos.
• El pipeline que lo construye y lo despliega, y los repositorios Git que hay detrás.
• Tu proveedor de identidad y toda herramienta que dé acceso a producción.
• Las personas con acceso a producción o a datos de clientes, y el proceso de RR. HH. que las da de alta y de baja.

Deja fuera lo que no toca el servicio ni sus datos: la web de marketing, la wiki interna, las herramientas de diseño. Tu proveedor cloud es una organización subcontratada (subservice organization): con el método carve-out, el más utilizado, sus controles quedan fuera de tu informe y tú revisas su propio informe SOC 2.

Después elige los Trust Services Criteria. Seguridad (los criterios comunes) se incluye siempre. Los otros cuatro son opcionales, y cada uno añade criterios que el auditor prueba:

• Disponibilidad: añádela si tus contratos incluyen compromisos de uptime.
• Confidencialidad: añádela si los contratos definen información confidencial que debes proteger y eliminar.
• Integridad del procesamiento: añádela si el procesamiento correcto es el producto, como en pagos o nóminas.
• Privacidad: se solapa mucho con lo que el RGPD ya te exige; añádela solo cuando un comprador lo pida.

Tipo I frente a Tipo II

Un informe Tipo I cubre una única fecha: ¿está tu sistema descrito de forma fiel y están los controles adecuadamente diseñados? Un informe Tipo II añade si esos controles funcionaron de forma eficaz durante todo un periodo de observación, algo que se prueba con muestras de evidencias de todo ese periodo.

La duración del periodo se acuerda con tu auditor, y algunos compradores fijan un mínimo, así que pregunta a ambos antes de elegir la fecha de inicio. Un Tipo I ayuda cuando un acuerdo necesita un documento ya; si no, ve directamente al Tipo II. Entre informes, los compradores suelen pedir una bridge letter: tu propia declaración de que nada relevante ha cambiado desde que terminó el último periodo.

Los controles como tareas de ingeniería

Para la mayoría de los controles, un auditor de Tipo II pide una población, por ejemplo cada baja del periodo o cada cambio fusionado en producción, y prueba una muestra. Así que cada control debe dejar un registro por defecto, y tienes que poder presentar la lista completa de todo el periodo.

SSO y MFA en todas partes

Pon cada sistema dentro del alcance detrás de tu proveedor de identidad y exige MFA ahí: consola cloud, plataforma Git, CI, herramientas de base de datos. Mantén una o dos cuentas break-glass documentadas, con una alerta en cada uso.

Evidencias: la lista de aplicaciones dentro del alcance con su método de login, la configuración que obliga a usar MFA, un export de usuarios con su estado de registro en MFA y los logs de uso de las cuentas break-glass.

Altas, cambios y bajas

Lanza los cambios de acceso desde el registro de RR. HH.: un ticket por cada alta, cambio de rol y baja, con los permisos enumerados. Fija un plazo de baja que puedas cumplir siempre, por ejemplo el último día laborable de la persona. Desactiva primero la cuenta en el proveedor de identidad y después revoca las claves y tokens que viven fuera del SSO.

Evidencias: la lista de RR. HH. con las altas y bajas, y para cada persona de la muestra el ticket y cuándo se concedió o retiró el acceso.

Revisiones periódicas de accesos

Con la cadencia que fije tu política, por ejemplo trimestral, el responsable de cada sistema de producción revisa quién tiene acceso y lo firma. Cada retirada se convierte en un ticket.

Evidencias: la lista de accesos exportada, la firma con fecha y los tickets de retirada cerrados.

Gestión de cambios

Protege la rama por defecto de cada repositorio de producción: nada de pushes directos, administradores incluidos; una aprobación de alguien que no sea el autor; checks de CI obligatorios; deploy solo desde el pipeline. Define una vía de emergencia que se revise a posteriori. Es el pipeline que construye nuestra práctica de DevSecOps.

Evidencias: la configuración de protección de ramas y, para cada cambio de la muestra, la pull request con su aprobador y el pipeline en verde.

Logging y alertas

Centraliza los logs de aplicación, de infraestructura y de auditoría del cloud con la retención que indique tu política, y envía las alertas de seguridad (ráfagas de logins fallidos, cambios de privilegios, logging desactivado) al equipo on-call.

Evidencias: las reglas de alerta, la configuración de retención y una muestra de alertas con el ticket que generó cada una.

Backups con restauración probada

Automatiza los backups, guárdalos separados de producción y restaura uno de forma programada:

dropdb --if-exists restore_test
createdb restore_test
pg_restore --exit-on-error -d restore_test /backups/app-latest.dump
psql -d restore_test -c "SELECT count(*), max(created_at) FROM orders;"

Evidencias: el historial de los jobs de backup y un registro de cada restauración: fecha, duración, qué se comprobó y quién la hizo.

Gestión de vulnerabilidades

Analiza dependencias, imágenes de contenedor y hosts, y fija plazos de corrección por severidad, por ejemplo críticas en 7 días, altas en 30 y medias en 90. Elige cifras que vayas a cumplir siempre: el auditor prueba contra tu política, y cada incumplimiento necesita una excepción aprobada.

Evidencias: los resultados de los análisis, los tickets con fecha de apertura y de cierre, y el registro de excepciones.

Cifrado en tránsito y en reposo

TLS en cada endpoint que transporte datos de clientes, incluidos los internos; cifrado en cada almacén de datos y cada backup; claves en un servicio gestionado de claves con acceso restringido. Si tu infraestructura está en Terraform, el código es evidencia.

Evidencias: exports de configuración o código de infraestructura, más un análisis TLS de los endpoints públicos.

Inventario de proveedores

Enumera cada proveedor que toque datos de clientes o producción: qué datos, qué acceso, una calificación de riesgo y cuándo revisaste por última vez su informe o certificado de seguridad. Tu lista de subencargados del RGPD es el punto de partida.

Evidencias: el inventario y las revisiones con fecha.

Plan de respuesta a incidentes y ejercicio de simulación

Escribe un plan corto: niveles de severidad, quién lidera, cómo se notifica a clientes y autoridades, cómo se preservan las evidencias. Después ensáyalo con un escenario realista, como una clave de deploy filtrada, y convierte las carencias en tickets.

Evidencias: el plan, el registro del ejercicio (fecha, asistentes, escenario, conclusiones) y los tickets de seguimiento.

Políticas que la gente lee de verdad

Escribe políticas que describan lo que haces, de pocas páginas cada una, y haz que todo el mundo las acepte al incorporarse y cada año, junto con una formación de concienciación en seguridad.

Evidencias: cada política con su responsable y fecha de revisión, y el registro de aceptación de cada persona.

¿No sabes cuáles de estos controles ya cumples? Solicita una evaluación gratuita de preparación para SOC 2: revisamos contigo tu proveedor de identidad, repositorios, pipeline y backups frente a los criterios y te entregamos una lista de carencias ordenada por riesgo de auditoría.

Recoge evidencias de los sistemas que ya tienes

Las capturas de pantalla hechas la semana antes del trabajo de campo son la evidencia más débil que puedes ofrecer. Expórtala de forma programada, con marca de tiempo, y guárdala donde nadie pueda editarla sin que se note. Un job semanal como este produce las poblaciones que piden los auditores:

#!/usr/bin/env bash
set -euo pipefail
SINCE="2026-01-01"
UNTIL="2026-06-30"
OUT="evidence/$(date +%F)"
mkdir -p "$OUT"

# Every change that reached the default branch in the window
git -C /srv/repos/app log main --first-parent --since="$SINCE" --until="$UNTIL" --format='%H|%an|%cI|%s' > "$OUT/changes-main.txt"

# Who holds which role in the production cluster
kubectl get rolebindings,clusterrolebindings -A -o wide > "$OUT/k8s-bindings.txt"

# Database logins and superusers
psql -d app -At -c "SELECT rolname, rolsuper, rolvaliduntil FROM pg_roles WHERE rolcanlogin;" > "$OUT/db-roles.txt"

# Fingerprint the snapshot
(cd "$OUT" && sha256sum ./*.txt > SHA256SUMS)

El log de Git es la población de cambios. Las plataformas Git alojadas exponen las reglas de protección de ramas, las aprobaciones de pull requests y los resultados de los pipelines a través de sus APIs REST: une cada commit con su pull request y tendrás, por cambio, el autor, el aprobador y el estado del pipeline, que es exactamente lo que se muestrea. Añade el export de usuarios y MFA de tu proveedor de identidad y escríbelo todo en un almacenamiento de objetos con versionado o bloqueo de retención. Las plataformas de automatización del cumplimiento hacen lo mismo mediante integraciones; que compensen frente a unos cuantos scripts depende de cuántos sistemas tengas. Para la parte del cluster, lee cómo automatizar las evidencias de cumplimiento en Kubernetes.

Un plan de preparación de 12 semanas

Semanas 1-2: decidir y delimitar el alcance

• Una nota con la decisión de marco, basada en los cuestionarios que reuniste.
• Un diagrama de la frontera del sistema y un inventario de sistemas, almacenes de datos y personas dentro del alcance.
• La selección de criterios y un registro de carencias, una fila por control.
• Una lista corta de auditores y una primera conversación sobre la duración del periodo y las fechas.

Semanas 3-4: identidad

• SSO y MFA obligatorio en todos los sistemas dentro del alcance, con las cuentas break-glass documentadas.
• Tickets de altas y bajas lanzados desde RR. HH. y un runbook de bajas.
• La primera revisión de accesos, completada y firmada.

Semanas 5-6: cambios y build

• Protección de ramas en todos los repositorios de producción, administradores incluidos.
• Deploys solo desde CI y un procedimiento escrito de cambios de emergencia.

Semanas 7-8: operaciones

• Logging centralizado, con las alertas de seguridad enviadas al equipo on-call.
• Análisis de vulnerabilidades activo, con los plazos por severidad en el gestor de tickets.
• Cifrado verificado, backups en marcha y la primera prueba de restauración registrada.

Semanas 9-10: políticas, proveedores y riesgo

• Un conjunto de políticas que refleje lo que ahora haces, aceptado por todo el mundo.
• El inventario de proveedores, una evaluación de riesgos y el plan de respuesta a incidentes.

Semanas 11-12: ensayar

• El ejercicio de simulación hecho y los jobs de evidencias funcionando según lo programado.
• Una revisión interna de preparación: elige muestras como lo haría un auditor y corrige todo lo que no puedas presentar.
• La fecha de inicio del periodo de observación acordada con el auditor.

Después se abre el periodo de observación: nada nuevo que construir, solo controles que ejecutar a tiempo. Pon cada control recurrente en un calendario compartido con un responsable (revisiones de accesos, pruebas de restauración, revisiones de proveedores) y revisa la carpeta de evidencias cada mes, para que seas tú quien encuentre una revisión olvidada y no el auditor.

Cuánto cuesta y cómo estimarlo

El coste del primer año es la suma de cuatro partidas, y puedes estimar cada una con tus propias cifras:

• Honorarios del auditor: pide presupuestos sobre el mismo alcance por escrito, los mismos criterios, el mismo tipo de informe y el mismo periodo, para comparar lo comparable.
• Herramientas: una plataforma de automatización del cumplimiento o tus propios scripts, más lo que se suele olvidar: el plan superior que algunas herramientas exigen antes de ofrecer SSO, la gestión de dispositivos para los portátiles y los escáneres.
• Trabajo para cerrar carencias: estima en horas cada fila de tu registro de carencias, añade la automatización de evidencias y multiplica por un coste por hora con cargas incluidas.
• Mantenimiento: horas semanales para los controles recurrentes y las entrevistas con el auditor, multiplicadas por las semanas del periodo de observación y por el mismo coste por hora.

Trampas que retrasan una primera auditoría

Políticas escritas para una empresa imaginaria. Las plantillas descargadas describen un equipo de seguridad y un comité de cambios que no tienes. El auditor prueba lo que dice la política, así que cada frase que no puedas respaldar con evidencias se convierte en una excepción. Escribe lo que haces de verdad y luego mejóralo.

Controles que solo existen la semana antes de la auditoría. Un Tipo II prueba todo el periodo. Una revisión de accesos hecha una sola vez, el día antes del trabajo de campo, es una muestra de las varias que el periodo exigía. Pon el reloj en marcha solo cuando los controles funcionen por sí solos.

Meterlo todo en el alcance. Cada sistema dentro del alcance necesita revisiones de accesos, logging y evidencias de cambios. Añadir sistemas que a ningún comprador le importan multiplica el trabajo.

Solicita una evaluación gratuita de preparación para SOC 2

Si un cliente te ha pedido un informe SOC 2 o un certificado ISO 27001, nuestro equipo de ciberseguridad analizará contigo en qué punto estás, sin coste. La evaluación cubre:

• Marco y alcance: qué informe necesitan tus compradores y la frontera más pequeña que los satisface.
• Una lista de carencias control por control en identidad, gestión de cambios, logging, backups y gestión de vulnerabilidades, con las evidencias que cada control produce hoy.
• Un plan de preparación a la medida de tu equipo, que indica qué evidencias se pueden recoger de forma automática.

Solicita tu evaluación gratuita de preparación para SOC 2 y recibe por escrito una lista de carencias y próximos pasos, sin compromiso.