Lista de verificación de cumplimiento SOC 2 para empresas SaaS

El cumplimiento de SOC 2 es un esfuerzo multifase — y las empresas SaaS que lo tratan como un proyecto estructurado, en lugar de una carrera antes de la temporada de auditoría, son las que aprueban limpiamente y mantienen el cumplimiento año tras año.

Esta lista de verificación cubre el ciclo de vida completo: desde las decisiones iniciales de alcance hasta la finalización de la auditoría y el cumplimiento continuo. Cada sección enlaza a una guía detallada donde puede profundizar en temas específicos. Ya sea que busque su primer informe SOC 2 o esté ajustando los preparativos para su próximo ciclo de auditoría, utilice esto como su hoja de ruta operativa.

Si es completamente nuevo en SOC 2, comience con nuestra guía ¿Qué es SOC 2? para los conceptos fundamentales antes de trabajar con esta lista de verificación.

Fase 1: Alcance y planificación

Las decisiones que tome durante el alcance definen el costo, el cronograma y la complejidad de todo lo que sigue. Haga bien esta fase y el resto del proceso se vuelve dramáticamente más manejable.

Defina qué Criterios de Servicio de Confianza incluir

Todo informe SOC 2 debe incluir el criterio de Seguridad (también llamado Common Criteria). Los cuatro restantes — Disponibilidad, Integridad del Procesamiento, Confidencialidad y Privacidad — son opcionales y deben seleccionarse según los requisitos de sus clientes y la naturaleza de su servicio.

En la práctica: La mayoría de las empresas SaaS B2B comienzan con Seguridad y Disponibilidad. Si su producto maneja datos sensibles con controles de acceso estrictos, añada Confidencialidad. Si procesa datos personales a escala y quiere demostrar alineación con el RGPD, incluya Privacidad.

No incluya criterios “por si acaso.” Cada criterio adicional añade controles, requisitos de evidencia y alcance de auditoría. Incluya lo que sus clientes piden y lo que es genuinamente relevante para su servicio.

Lea nuestro desglose detallado: Criterios de Servicio de Confianza de SOC 2 explicados

Decida Type I o Type II

Type I evalúa el diseño de sus controles en un momento específico. Type II evalúa el diseño y la eficacia operativa durante un período (generalmente 6-12 meses). Los clientes empresariales prefieren fuertemente Type II porque demuestra operación sostenida de los controles, no solo una instantánea.

Ejemplo SaaS: Una startup Serie A cerrando su primer acuerdo empresarial podría buscar un Type I para desbloquear la venta, luego hacer la transición a Type II en los próximos 12 meses. Una empresa Serie B con una base de clientes establecida debería ir directamente a Type II.

Lea nuestra comparación: SOC 2 Type I vs. Type II: ¿cuál necesita?

Establezca presupuesto y cronograma

Los costos de SOC 2 varían significativamente dependiendo del tamaño de su empresa, el alcance de la auditoría y si utiliza una plataforma de cumplimiento o consultores. Los honorarios del auditor por sí solos típicamente oscilan entre $20,000 y $80,000 para un compromiso Type II. Añada herramientas, costos de remediación y tiempo interno de ingeniería, y los costos totales del primer año para una empresa SaaS de etapa media a menudo aterrizan entre $50,000 y $150,000.

Orientación de cronograma: Un informe Type I puede completarse en 2-4 meses si sus controles fundamentales están implementados. Un informe Type II requiere un período de observación de 6-12 meses después de que se implementen los controles, lo que significa que debe comenzar 9-15 meses antes de necesitar el informe en mano.

Lea nuestro análisis detallado: Costo y cronograma de SOC 2 para empresas SaaS

Seleccione un auditor

Solo una firma de CPA autorizada puede emitir un informe SOC 2. Elija una firma con experiencia demostrable en SaaS — auditores que comprendan la infraestructura en la nube, los pipelines de CI/CD y la infraestructura como código harán preguntas relevantes y no perderán el tiempo de su equipo en controles diseñados para entornos on-premise.

Qué evaluar:

• Experiencia auditando empresas SaaS de su tamaño y etapa
• Familiaridad con su pila tecnológica (AWS/GCP/Azure, Kubernetes, etc.)
• Estilo de comunicación y capacidad de respuesta durante el compromiso
• Transparencia de precios — esté atento a honorarios ocultos por repruebas de remediación
• Referencias de otras empresas SaaS que hayan auditado

Defina el límite del sistema

El límite del sistema define qué está en el alcance de su auditoría SOC 2. Esto incluye infraestructura, software, personas, procedimientos y datos relacionados con el servicio que está evaluando.

En la práctica: Para una aplicación SaaS típica, el límite del sistema incluye su entorno de producción, el pipeline de CI/CD que despliega a él, los sistemas de monitoreo y alertas, las personas que lo acceden y las políticas que gobiernan su comportamiento. Los entornos de desarrollo y staging generalmente se excluyen a menos que contengan datos de clientes.

Sea preciso. Un límite del sistema demasiado amplio significa más controles, más evidencia y más costo. Uno demasiado estrecho significa que su informe no cubrirá lo que realmente les importa a los clientes.

Fase 2: Evaluación de riesgos y análisis de brechas

Antes de implementar controles, necesita comprender su estado actual: qué riesgos existen, qué controles ya están implementados y dónde están las brechas.

Realice una evaluación formal de riesgos

Una evaluación de riesgos SOC 2 identifica amenazas a su sistema, evalúa su probabilidad e impacto, y documenta cómo las mitiga. No es un ejercicio teórico — es la base sobre la que se construyen sus controles, y su auditor la revisará.

Qué evaluar:

• Amenazas externas: intentos de acceso no autorizado, ataques DDoS, compromisos de la cadena de suministro, ingeniería social
• Amenazas internas: errores de empleados, amenazas internas, errores de configuración, controles de acceso inadecuados
• Amenazas ambientales: interrupciones del proveedor de nube, desastres naturales que afectan la disponibilidad, fallas de servicios de terceros
• Amenazas de cumplimiento: cambios regulatorios, requisitos contractuales de clientes, obligaciones de residencia de datos

Ejemplo SaaS: Su evaluación de riesgos identifica que los ingenieros tienen acceso permanente a las bases de datos de producción que contienen datos de clientes. El riesgo: las credenciales comprometidas de un ingeniero podrían exponer datos de clientes. La mitigación: implementar acceso justo a tiempo con flujos de trabajo de aprobación y registro de sesiones.

Lea nuestro proceso paso a paso: Guía de evaluación de riesgos SOC 2

Identifique brechas contra los Common Criteria de SOC 2

Mapee sus controles existentes contra los Common Criteria de SOC 2 (los puntos de control de la serie CC). Este análisis de brechas le dice exactamente qué necesita construir, formalizar o documentar antes de la auditoría.

Brechas comunes que descubren las empresas SaaS:

• Las políticas existen informalmente pero no están documentadas
• Las revisiones de acceso ocurren de manera ad hoc pero no están programadas ni registradas
• Los procedimientos de respuesta a incidentes existen en la cabeza de alguien pero no en un manual
• Las evaluaciones de riesgo de proveedores se hacen durante la incorporación pero nunca se revisitan
• La gestión de cambios existe en los flujos de trabajo de pull requests pero no está formalmente documentada como un control

Priorice la remediación según el nivel de riesgo

No todas las brechas tienen el mismo peso. Priorice según el nivel de riesgo (de su evaluación de riesgos) y la criticidad para la auditoría (si la brecha resultaría en una opinión con salvedades).

En la práctica: Una política de seguridad de la información faltante es una brecha crítica — sustenta múltiples áreas de control y su auditor la señalará inmediatamente. Una revisión anual faltante de su política de uso aceptable es importante pero de menor prioridad. Construya un plan de remediación con propietarios, plazos y seguimiento de estado.

Fase 3: Políticas y controles

Aquí es donde el cumplimiento pasa de la planificación a la implementación. Sus políticas definen lo que se compromete a hacer. Sus controles son los mecanismos que aplican esos compromisos.

Redacte las políticas requeridas

SOC 2 requiere políticas documentadas en múltiples dominios. Su auditor revisará estas políticas, probará si su equipo las sigue y evaluará si se revisan y actualizan apropiadamente.

Políticas centrales que necesitará:

• Política de seguridad de la información
• Política de control de acceso
• Política de gestión de cambios
• Política de respuesta a incidentes
• Política de evaluación de riesgos
• Política de gestión de proveedores
• Política de clasificación y manejo de datos
• Política de continuidad del negocio y recuperación ante desastres
• Política de uso aceptable
• Política de seguridad de recursos humanos (cubriendo incorporación, desvinculación, verificaciones de antecedentes)

Qué hace una buena política: Debe ser lo suficientemente específica para ser accionable, lo suficientemente realista para ser seguida y revisada al menos anualmente. Las políticas que dicen “utilizamos las mejores prácticas de la industria” son inútiles — declare lo que realmente hace.

Lea nuestra guía detallada: Guía de políticas y procedimientos SOC 2

Implemente controles de seguridad alineados con los Common Criteria

Los controles son los mecanismos operativos que aplican sus políticas. Para SOC 2, estos controles necesitan mapearse a los Common Criteria y a cualquier Criterio de Servicio de Confianza adicional que haya incluido.

Áreas clave de control para empresas SaaS:

• Controles de acceso lógico: SSO con MFA para todos los sistemas de producción, acceso basado en roles, revisiones trimestrales de acceso, desaprovisionamiento automatizado al momento de la terminación
• Seguridad de red: Reglas de firewall, segmentación de red, detección/prevención de intrusos, protección DDoS, VPN o acceso de confianza cero para herramientas internas
• Gestión de cambios: Revisiones de pull request, pruebas automatizadas en CI/CD, flujos de trabajo de aprobación de despliegue, procedimientos de reversión
• Protección de datos: Cifrado en reposo (AES-256) y en tránsito (TLS 1.2+), gestión de claves, clasificación de datos, eliminación segura
• Monitoreo y alertas: Registro centralizado, SIEM o agregación de logs, alertas sobre eventos de seguridad, retención de logs para el período de auditoría

Establezca un programa de gestión de proveedores

Su alcance SOC 2 no termina en los límites de su empresa. Los servicios de terceros que procesan, almacenan o transmiten datos en el alcance de su informe necesitan ser evaluados y monitoreados.

Qué documentar para cada proveedor:

• Qué datos acceden o procesan
• Su estado de informe SOC 2 (o certificaciones de seguridad equivalentes)
• Términos contractuales de protección de datos
• Resultados de su evaluación de riesgo del proveedor
• Cadencia de revisión y fecha de última revisión

Ejemplo SaaS: Su aplicación usa Stripe para pagos, AWS para infraestructura, Datadog para monitoreo y Slack para comunicaciones internas. Stripe, AWS y Datadog están en el alcance porque procesan o tienen acceso a datos de clientes. Slack probablemente está fuera del alcance a menos que se use para transmitir datos de clientes.

Lea nuestra guía completa: Guía de gestión de proveedores SOC 2

Establezca procedimientos de respuesta a incidentes

Su capacidad de respuesta a incidentes es una de las áreas más escrutadas en una auditoría SOC 2. Los auditores quieren ver un plan documentado, roles definidos, rutas de escalamiento claras y evidencia de que ha probado el plan.

Su plan de respuesta a incidentes debe cubrir:

• Clasificación de incidentes y niveles de severidad
• Mecanismos de detección y alertas
• Roles del equipo de respuesta e información de contacto
• Procedimientos de contención, erradicación y recuperación
• Protocolos de comunicación (internos, orientados al cliente, regulatorios)
• Proceso de revisión post-incidente
• Requisitos de preservación de evidencias

En la práctica: Cuando se dispara una alerta de seguridad a las 2 AM, su ingeniero de guardia debe saber exactamente dónde está el manual de procedimientos, a quién escalar, qué decisiones está autorizado a tomar y cómo documentar sus acciones. Si su plan de respuesta a incidentes solo funciona durante horario laboral, no funciona.

Lea nuestra guía detallada: Guía de respuesta a incidentes SOC 2

Fase 4: Recopilación de evidencias y monitoreo

Los controles sin evidencia son controles que su auditor no puede verificar. Esta fase se trata de demostrar — sistemática y continuamente — que sus controles están operando según lo diseñado.

Establezca procesos de recopilación de evidencias

Los auditores SOC 2 necesitan evidencia de que sus controles operaron eficazmente durante todo el período de auditoría (para Type II). Esto significa que necesita recopilar y retener evidencias continuamente, no recopilarlas retroactivamente.

Tipos de evidencia que su auditor solicitará:

• Evidencia de configuración: Capturas de pantalla o exportaciones mostrando configuraciones del sistema (MFA habilitado, ajustes de cifrado, reglas de firewall, listas de control de acceso)
• Evidencia de procesos: Registros de revisiones de acceso, aprobaciones de cambios, respuestas a incidentes, evaluaciones de proveedores
• Evidencia automatizada: Logs de SIEM, pistas de auditoría del proveedor de nube, registros del pipeline de CI/CD, logs de despliegue
• Evidencia humana: Registros de finalización de capacitación, reconocimientos de políticas, confirmaciones de verificación de antecedentes

Ejemplo SaaS: Su auditor solicita evidencia de que todos los cambios de producción pasan por revisión de código. En lugar de apresurarse a extraer datos de PR de GitHub, su plataforma de cumplimiento captura automáticamente metadatos de pull requests — revisor, marca de tiempo de aprobación, marca de tiempo de merge — y los almacena como evidencia lista para auditoría.

Lea nuestra guía detallada: Guía de recopilación de evidencias SOC 2

Implemente monitoreo continuo

El monitoreo continuo significa que sus controles se validan de forma permanente — no solo durante la preparación de la auditoría. Esto detecta las fallas de control temprano y le da tiempo para remediar antes de que llegue el auditor.

Qué monitorear continuamente:

• Efectividad del control de acceso (¿los empleados terminados están realmente desaprovisionados?)
• Deriva de configuración (¿alguien deshabilitó MFA en una cuenta de servicio?)
• Gestión de vulnerabilidades (¿se están aplicando los parches críticos dentro de su SLA?)
• Métricas de disponibilidad (¿está cumpliendo sus compromisos de tiempo de actividad?)
• Adherencia a la gestión de cambios (¿todos los cambios de producción están pasando por el proceso definido?)

Lea nuestra guía de implementación: Guía de monitoreo continuo SOC 2

Realice una evaluación interna de preparación

Antes de contratar a su auditor, realice una evaluación interna de preparación. Recorra cada control, verifique que existe la evidencia e identifique cualquier brecha restante.

En la práctica: Asigne un propietario de control para cada control SOC 2. Haga que cada propietario verifique que su control está operando, que se está recopilando evidencia y que la documentación está actualizada. Cualquier brecha descubierta ahora es una brecha que puede corregir antes de que comience el reloj de la auditoría.

Fase 5: La auditoría

La auditoría en sí es un compromiso estructurado con su firma de CPA. La preparación determina si es un proceso fluido o una carrera estresante.

Prepárese para el proceso de auditoría

Su auditor comenzará con una fase de planificación — comprendiendo su sistema, revisando la descripción de su sistema e identificando los controles que probará. Llegue preparado con un repositorio de evidencias limpio y organizado y puntos de contacto designados para cada área de control.

Lista de verificación de preparación:

• Documento de descripción del sistema (describiendo su servicio, infraestructura y entorno de control)
• Lista completa de controles mapeados a los criterios SOC 2
• Repositorio de evidencias organizado por control
• Contactos designados para cada dominio de control
• Disponibilidad de calendario para los recorridos del auditor

Lea nuestro recorrido detallado: Proceso de auditoría SOC 2: qué esperar

Apoye los recorridos y pruebas del auditor

Durante la auditoría, el auditor probará sus controles a través de una combinación de indagación (preguntando a su equipo cómo funcionan las cosas), observación (viendo procesos en acción), inspección (revisando evidencias y documentación) y re-ejecución (re-ejecutando un control para verificar que funciona).

Ejemplo SaaS: El auditor prueba su control de acceso seleccionando una muestra de empleados terminados y verificando que su acceso fue revocado dentro del plazo especificado en su política. Verificarán Active Directory, AWS IAM, GitHub y cualquier otro sistema donde esos empleados tenían acceso.

Aborde cualquier hallazgo

Si el auditor identifica deficiencias de control, tendrá la oportunidad de discutirlas. Los problemas menores pueden anotarse como observaciones en el informe sin afectar la opinión. Las deficiencias significativas o debilidades materiales pueden resultar en una opinión con salvedades — lo que anula el propósito del informe.

En la práctica: Si el auditor encuentra que 2 de 25 revisiones de acceso muestreadas se completaron tarde, probablemente sea una observación. Si encuentra que 15 de 25 nunca se completaron, es una deficiencia significativa. La diferencia entre estos resultados es el rigor de su programa de cumplimiento continuo.

Reciba su informe SOC 2

El entregable final es un informe SOC 2 que contiene la opinión del auditor, la descripción de su sistema, una descripción de sus controles, los resultados de las pruebas del auditor y cualquier excepción anotada. Este informe es lo que comparte con clientes y prospectos bajo NDA.

Fase 6: Cumplimiento continuo

Un informe SOC 2 tiene una vida útil. Los clientes empresariales esperan informes vigentes, y sus controles necesitan operar continuamente — no solo durante la ventana de auditoría.

Mantenga el monitoreo continuo

Los controles que implementó para la auditoría necesitan seguir funcionando. Los paneles de monitoreo, la recopilación automatizada de evidencias y las revisiones regulares deben operar como parte de sus operaciones normales, no como actividades de temporada de auditoría.

Recertificación anual

Los informes Type II se emiten típicamente de forma anual. Su período de auditoría debe cubrir los 12 meses desde su último informe, sin brechas. Comience a planificar cada ciclo de auditoría 2-3 meses antes de que termine el período de observación para asegurar transiciones fluidas.

Consejo de cronograma: Si su primer informe Type II cubre de enero a junio, su próximo informe debe cubrir de julio a junio del año siguiente. Las brechas entre los períodos de observación generan preguntas de los clientes que revisan su informe.

Gestione los cambios

Las empresas SaaS cambian constantemente — nuevos proveedores, nueva infraestructura, nuevos miembros del equipo, nuevas funcionalidades. Cada cambio puede afectar su entorno de control SOC 2.

Cambios que requieren reevaluación:

• Añadir un nuevo proveedor externo que procesa datos en el alcance
• Migrar a un nuevo proveedor de nube o región
• Cambios significativos en la arquitectura de su aplicación
• Cambios organizacionales (adquisiciones, reestructuración, salidas de personal clave)
• Nuevos requisitos regulatorios de clientes o mercados
• Expansión a verticales con necesidades de cumplimiento específicas (salud, finanzas)

Construya un proceso liviano de evaluación de cambios: cuando ocurra un cambio material, evalúe su impacto en sus controles SOC 2 y actualice su documentación en consecuencia. Su auditor preguntará sobre los cambios significativos durante la próxima auditoría, y tener evaluaciones documentadas demuestra madurez.

Errores comunes que cometen los equipos SaaS

Comenzar demasiado tarde. El error número uno es comenzar la preparación de SOC 2 tres meses antes de necesitar el informe. Un informe Type II requiere un período de observación de 6-12 meses. Añada 2-4 meses de preparación antes de que comience ese período. Si un cliente necesita su informe SOC 2 el próximo año, comience ahora.

Tratar el cumplimiento como un problema del equipo de seguridad. SOC 2 toca a ingeniería (gestión de cambios, controles de acceso, revisión de código), RRHH (incorporación, desvinculación, verificaciones de antecedentes) y operaciones (gestión de proveedores, continuidad del negocio). Cada equipo que opera un control es responsable de ese control.

Recopilar evidencias manualmente. Dedicar 40 horas a tomar capturas de pantalla y exportar logs antes de cada auditoría es una señal de que su recopilación de evidencias no está automatizada. Invierta en herramientas que capturen evidencias continuamente — se paga sola en el primer ciclo de auditoría.

Redactar políticas que nadie sigue. Los auditores prueban si su equipo realmente sigue las políticas documentadas. Una política de seguridad de la información de 30 páginas que ningún ingeniero ha leído es peor que una política de 3 páginas que refleja lo que su equipo realmente hace. Redacte políticas que describan prácticas reales, luego aplíquelas.

Ignorar el cumplimiento de proveedores. Si un proveedor crítico no tiene su propio informe SOC 2, su auditor querrá ver cómo evaluó y gestiona ese riesgo. “Confiamos en ellos porque son una empresa grande” no es una evaluación de riesgos.

Cómo ayuda GRCTrail

GRCTrail está diseñado para equipos SaaS que gestionan el cumplimiento SOC 2 — desde la primera preparación hasta las auditorías anuales continuas.

• Evaluación de preparación SOC 2 que mapea su estado actual contra cada punto de control de Common Criteria y genera un plan de remediación priorizado
• Biblioteca de plantillas de políticas con políticas específicas de SOC 2 escritas para empresas SaaS, listas para personalizar y publicar a su equipo
• Recopilación automatizada de evidencias integrándose con AWS, GCP, Azure, GitHub, GitLab, Okta, Google Workspace y otras herramientas de su pila
• Paneles de monitoreo continuo que rastrean la efectividad de los controles en tiempo real y le alertan cuando los controles se desvían del cumplimiento
• Marco de evaluación de riesgos con flujos de trabajo estructurados para identificar, calificar y mitigar riesgos contra los criterios SOC 2
• Módulo de gestión de proveedores para rastrear la postura de seguridad de terceros, el estado de informes SOC 2 y los calendarios de revisión
• Seguimiento de respuesta a incidentes con flujos de trabajo incorporados para clasificación, respuesta y documentación de revisión post-incidente
• Paquetes de evidencia listos para auditoría que organizan sus evidencias por control y criterio, exportables en formatos que su auditor espera

Vea cómo GRCTrail simplifica el cumplimiento SOC 2 →

Comience con GRCTrail →

Guías relacionadas

• ¿Qué es SOC 2? Una guía práctica para empresas SaaS
• Criterios de Servicio de Confianza de SOC 2 explicados
• SOC 2 Type I vs. Type II: ¿cuál necesita?
• Common Criteria de SOC 2 explicados
• Proceso de auditoría SOC 2: qué esperar
• Políticas y procedimientos SOC 2: qué necesita documentar
• Guía de gestión de proveedores SOC 2
• Guía de recopilación de evidencias SOC 2
• Guía de evaluación de riesgos SOC 2
• Guía de respuesta a incidentes SOC 2
• Guía de monitoreo continuo SOC 2
• Costo y cronograma de SOC 2 para empresas SaaS
• Lista de verificación de cumplimiento RGPD para empresas SaaS
• Acuerdos de Tratamiento de Datos (DPA) bajo el RGPD