Controles Common Criteria (CC) de SOC 2 explicados

Los Common Criteria (CC) son la columna vertebral de todo informe SOC 2. Corresponden al Criterio de Servicio de Confianza de Seguridad — el único criterio obligatorio en todo examen SOC 2 — y definen los objetivos de control específicos que evalúa su auditor. Comprender las nueve categorías de CC es esencial para diseñar un marco de controles que apruebe la auditoría y realmente proteja sus sistemas.

Las categorías de CC se derivan del marco de control interno COSO (Committee of Sponsoring Organizations of the Treadway Commission), adaptado por el AICPA específicamente para la seguridad de la información. Cubren desde la cultura y gobernanza organizacional hasta los controles técnicos de acceso y la gestión de riesgo de proveedores. Para las empresas SaaS, esto significa que SOC 2 no se trata solo de firewalls y cifrado — se trata de cómo opera toda su organización.

Esta guía desglosa cada categoría de CC con lo que prueban los auditores, qué evidencia esperan y cómo las empresas SaaS deben implementar controles para satisfacer cada una. Si aún se está orientando con SOC 2, comience con nuestra guía ¿Qué es SOC 2? antes de profundizar en los detalles de los criterios.

CC1: Entorno de control

Criterios cubiertos: CC1.1 a CC1.5

El entorno de control establece la base para todo lo demás en su programa SOC 2. Se trata del compromiso organizacional — ¿su empresa toma la seguridad en serio en todos los niveles, desde el consejo hasta los colaboradores individuales?

Lo que buscan los auditores:

• Un código de conducta o política de ética firmado por todos los empleados
• Estructura organizativa definida con roles y responsabilidades de seguridad claros
• Supervisión a nivel de consejo o ejecutivo del programa de seguridad (actas de reuniones, cadencia de informes)
• Responsabilidad de la dirección sobre los objetivos de seguridad
• Políticas de RRHH que refuerzan la seguridad (verificaciones de antecedentes, capacitación de seguridad en la incorporación, procedimientos de terminación)

Implementación SaaS:

• Organigrama con responsabilidades de seguridad. Mapee quién es dueño de qué: CISO o líder de seguridad, gerentes de ingeniería responsables del desarrollo seguro, el propietario de cumplimiento y cualquier persona con acceso privilegiado al sistema. Esto no requiere una organización masiva — una startup de 30 personas puede documentar responsabilidades de seguridad a través de los roles existentes.
• Código de conducta. Cada empleado firma una política de uso aceptable y ética durante la incorporación. Se revisa y reconoce anualmente.
• Informes al consejo o liderazgo. Documente informes regulares de seguridad a su consejo o equipo ejecutivo. Incluso si es una startup sin un consejo formal, los informes de estado de seguridad trimestrales a su equipo de liderazgo satisfacen este requisito.
• Integración de RRHH con seguridad. Verificaciones de antecedentes para nuevas contrataciones, capacitación de seguridad obligatoria durante la incorporación y un proceso de desvinculación documentado que incluye la revocación de acceso dentro de las 24 horas de la terminación.

En la práctica: CC1 es donde los auditores evalúan si la seguridad es parte del ADN de su empresa o una ocurrencia tardía. Los controles aquí son menos técnicos y más organizacionales, pero son fundamentales. Si su entorno de control es débil — si no hay propiedad ejecutiva, ni estructura documentada, ni responsabilidad — los auditores cuestionarán si los controles técnicos en CC3-CC9 son sostenibles. Para orientación completa sobre políticas, consulte nuestra guía de políticas y procedimientos.

CC2: Comunicación e información

Criterios cubiertos: CC2.1 a CC2.3

CC2 aborda cómo su organización comunica la información de seguridad interna y externamente. Los auditores quieren ver que las responsabilidades, expectativas y compromisos de seguridad se comunican claramente — no enterrados en un wiki que nadie lee.

Lo que buscan los auditores:

• Registros de capacitación en concienciación de seguridad con seguimiento de finalización
• Canales de comunicación interna para información de seguridad (alertas de incidentes, cambios de políticas, actualizaciones de seguridad)
• Compromisos de seguridad externos documentados y comunicados (páginas de confianza, SLAs, documentos técnicos de seguridad)
• Procedimientos para comunicarse con partes externas sobre asuntos de seguridad (consultas de clientes, cuestionarios de proveedores)

Implementación SaaS:

• Programa de capacitación en concienciación de seguridad. Capacitación anual para todos los empleados, con capacitación adicional específica por rol para ingenieros (codificación segura) y administradores (gestión de acceso privilegiado). Rastree las tasas de finalización y haga seguimiento de la capacitación vencida.
• Procesos de comunicación interna. Un canal definido (canal de Slack, lista de correo o intranet) para anuncios de seguridad. Procedimientos documentados para notificar a los equipos sobre incidentes de seguridad, cambios de políticas y cambios del sistema que afectan los controles de seguridad.
• Página de seguridad externa. Una página de prácticas de seguridad pública (página de confianza) que describa sus compromisos de seguridad a un nivel apropiado para clientes y prospectos. Esto es tanto un control CC2 como una herramienta de habilitación de ventas.
• Procedimientos de comunicación con proveedores y clientes. Procesos documentados para responder a cuestionarios de seguridad de clientes, manejar consultas de seguridad de proveedores y gestionar obligaciones contractuales relacionadas con la seguridad.

Ejemplo SaaS: Cuando despliega un cambio significativo de infraestructura — migrar a una nueva base de datos, habilitar un nuevo método de autenticación, cambiar su configuración de cifrado — CC2 requiere que las partes interesadas afectadas sean informadas. Internamente, eso es una notificación de cambio a los equipos de ingeniería y seguridad. Externamente, si el cambio afecta a los clientes, es una comunicación vía su página de estado o registro de cambios.

Para detalles sobre la construcción de artefactos de evidencia para estas comunicaciones, consulte nuestra guía de recopilación de evidencias.

CC3: Evaluación de riesgos

Criterios cubiertos: CC3.1 a CC3.4

CC3 requiere que su organización tenga un proceso formal y documentado para identificar, analizar y gestionar el riesgo. No es un ejercicio de una sola vez — es un programa continuo que alimenta todas las demás categorías de control.

Lo que buscan los auditores:

• Un documento formal de evaluación de riesgos producido al menos anualmente
• Un registro de riesgos que catalogue los riesgos identificados con calificaciones de severidad, evaluaciones de probabilidad y planes de tratamiento
• Consideraciones de riesgo de fraude (sí, incluso para empresas SaaS)
• Un proceso para identificar y evaluar cambios significativos que podrían introducir nuevos riesgos

Implementación SaaS:

• Evaluación anual de riesgos. Realice una evaluación de riesgos estructurada al menos una vez al año. Identifique amenazas a su sistema (brecha de datos, acceso no autorizado, interrupción del servicio, amenaza interna, compromiso de proveedor), evalúe la probabilidad e impacto de cada una, y documente su respuesta — aceptar, mitigar, transferir o evitar.
• Registro de riesgos. Mantenga un documento vivo que rastree cada riesgo identificado, su calificación actual, los controles que lo mitigan, el propietario del riesgo y el estado de cualquier actividad de remediación. Revise y actualice trimestralmente.
• Evaluación de riesgo de fraude. Los auditores buscan específicamente consideraciones de riesgo de fraude — acceso no autorizado a datos, manipulación financiera, anulación de controles por la dirección. Las empresas SaaS deben documentar cómo la segregación de funciones, los controles de acceso y el monitoreo mitigan el riesgo de fraude.
• Evaluación de impacto de cambios. Cuando realiza cambios significativos — nuevas funcionalidades de producto que manejan datos sensibles, migraciones de infraestructura, nuevas relaciones con proveedores, cambios organizacionales importantes — necesita un proceso documentado para evaluar el impacto en la seguridad.

En la práctica: Muchos equipos SaaS tratan la evaluación de riesgos como una casilla de cumplimiento — llenan una plantilla una vez al año y la olvidan. Los programas sólidos integran la evaluación de riesgos en las decisiones operativas. Cuando su equipo de ingeniería evalúa un nuevo SDK de terceros, esa evaluación debe incluir una entrada en la evaluación de riesgos. Cuando se expande a un nuevo mercado con diferentes requisitos regulatorios, se actualiza el registro de riesgos.

Para un recorrido completo de la construcción de una evaluación de riesgos lista para SOC 2, consulte nuestra guía de evaluación de riesgos.

CC4: Actividades de monitoreo

Criterios cubiertos: CC4.1 a CC4.2

CC4 requiere que su organización monitoree activamente la efectividad de sus controles y aborde las deficiencias cuando se identifiquen. Esta es la categoría de “confiar pero verificar” — no puede solo implementar controles y asumir que funcionan para siempre.

Lo que buscan los auditores:

• Procedimientos de monitoreo continuo que evalúen la efectividad de los controles a lo largo del tiempo
• Procesos de evaluación interna (autoevaluaciones, auditorías internas, pruebas de controles)
• Un proceso de gestión de deficiencias — ¿cómo se identifican, rastrean y remedian las fallas de control?
• Evidencia de que los resultados del monitoreo se reportan a la dirección

Implementación SaaS:

• Paneles de monitoreo automatizado. Configure paneles que rastreen métricas clave de seguridad: tasa de adopción de MFA, finalización de revisiones de acceso, estado de gestión de parches, resultados de escaneo de vulnerabilidades, tiempos de respuesta a incidentes. Señale desviaciones de las líneas base esperadas automáticamente.
• Revisiones regulares de efectividad de controles. Al menos trimestralmente, revise si sus controles están operando según lo diseñado. ¿Se realizan las revisiones de acceso según el calendario? ¿Se completan las revisiones de código antes de los merges? ¿Está la finalización de capacitación de seguridad al 100%?
• Proceso de gestión de deficiencias. Cuando un control falla o se identifica una brecha, necesita un proceso documentado para registrar la deficiencia, asignar un propietario, definir un plan de remediación y rastrear la resolución. Los auditores prueban específicamente si las deficiencias identificadas en períodos anteriores fueron resueltas.

Ejemplo SaaS: Su política de revisión de acceso requiere revisiones trimestrales, pero el monitoreo revela que la revisión del Q2 se completó con tres semanas de retraso. Bajo CC4, necesita registrar esto como una deficiencia, investigar la causa raíz (¿el propietario estaba de vacaciones? ¿el proceso no era claro?), implementar una acción correctiva y documentar toda la secuencia. Pretender que no sucedió es peor que la revisión tardía en sí.

Para profundizar en la construcción de un programa de monitoreo, consulte nuestra guía de monitoreo continuo.

CC5: Actividades de control

Criterios cubiertos: CC5.1 a CC5.3

CC5 conecta la identificación de riesgos (CC3) con la implementación de controles. Requiere que seleccione y despliegue controles que realmente aborden los riesgos que ha identificado, y que estos controles se apliquen tanto a través de tecnología como de políticas.

Lo que buscan los auditores:

• Controles mapeados a riesgos específicos (una matriz de controles o documento similar)
• Controles tecnológicos desplegados y configurados adecuadamente
• Políticas y procedimientos establecidos y comunicados para cada área de control
• Evidencia de que los controles están diseñados con un nivel de precisión suficiente para mitigar los riesgos identificados

Implementación SaaS:

• Matriz de controles. Cree un documento de mapeo que vincule cada riesgo identificado con los controles específicos que lo mitigan. Este es uno de los artefactos de auditoría más importantes — demuestra que sus controles son deliberados, no ad hoc. Una matriz de controles bien diseñada mapea cada punto de Common Criteria a uno o más controles, con requisitos de evidencia documentados para cada uno.
• Despliegue de controles tecnológicos. Implemente los controles técnicos que su evaluación de riesgos identificó como necesarios: cifrado en reposo y en tránsito, detección de intrusos, segmentación de red, protección de endpoints, escaneo automatizado de vulnerabilidades.
• Aplicación de políticas. Cada control debe estar respaldado por una política que defina el requisito y un procedimiento que describa cómo se ejecuta. Despliegue políticas a través de su plataforma GRC o sistema de gestión de políticas, rastree los reconocimientos y aplique a través de controles técnicos donde sea posible (ej., aplicar MFA a través de su proveedor de identidad en lugar de depender de la adopción voluntaria).

En la práctica: El hallazgo más común de CC5 es una desconexión entre la matriz de controles y la realidad. La matriz dice “escaneos trimestrales de vulnerabilidades” pero los escaneos se ejecutan de manera ad hoc. La matriz dice “todos los cambios de código requieren revisión por pares” pero el historial de Git muestra pushes directos a main. Los auditores comparan sus controles documentados contra la evidencia operativa — asegúrese de que coincidan. Para orientación sobre desarrollo de políticas, consulte nuestra guía de políticas y procedimientos.

CC6: Controles de acceso lógico y físico

Criterios cubiertos: CC6.1 a CC6.8

CC6 es la categoría con más densidad de controles en los Common Criteria y produce el mayor volumen de evidencia durante una auditoría. Cubre cada aspecto de la gestión de acceso — cómo se aprovisionan las identidades, cómo funciona la autenticación, cómo se restringe el acceso y cómo se protegen los límites del sistema.

Lo que buscan los auditores:

• Configuración del proveedor de identidad con gestión centralizada de usuarios
• Aplicación de MFA en todos los sistemas críticos
• Implementación de control de acceso basado en roles (RBAC) siguiendo el mínimo privilegio
• Controles de seguridad de red (firewalls, WAF, segmentación de red)
• Protección de endpoints en todos los dispositivos de la empresa
• Cifrado de datos en reposo y en tránsito
• Controles de acceso físico para cualquier centro de datos o sala de servidores (los proveedores de nube manejan esto vía sus propios informes SOC)
• Procedimientos de aprovisionamiento y desaprovisionamiento de acceso de usuario
• Revisiones periódicas de acceso con evidencia documentada

Implementación SaaS:

• Inicio de sesión único (SSO) con MFA. Centralice la autenticación a través de un proveedor de identidad (Okta, Azure AD, Google Workspace) con MFA obligatorio para todos los usuarios. Esto es innegociable — los auditores prueban la aplicación de MFA en cada sistema crítico.
• Acceso basado en roles con mínimo privilegio. Defina roles para cada sistema y asigne los permisos mínimos necesarios para cada rol. Los ingenieros no necesitan acceso de administrador a los sistemas de facturación. Ventas no necesita acceso a las bases de datos de producción.
• Revisiones trimestrales de acceso. Cada trimestre, los propietarios del sistema revisan quién tiene acceso a sus sistemas, verifican que los niveles de acceso sean apropiados y revocan el acceso que ya no se necesita. Documente la revisión, los hallazgos y cualquier cambio de acceso realizado.
• Seguridad de red. Implemente WAF (Web Application Firewall) en servicios públicos, segmente su red para aislar producción de desarrollo, restrinja el acceso SSH/RDP a redes autorizadas solamente, y mantenga reglas de firewall que denieguen por defecto el tráfico entrante.
• Protección de endpoints. Despliegue MDM (Gestión de Dispositivos Móviles) y EDR (Detección y Respuesta de Endpoints) en todos los dispositivos de la empresa. Aplique cifrado de disco, políticas de bloqueo de pantalla y actualizaciones automáticas.
• Cifrado en todas partes. TLS 1.2+ para todos los datos en tránsito. AES-256 o equivalente para datos en reposo. Conexiones cifradas a base de datos. Respaldos cifrados. Los auditores verifican la configuración de cifrado en sus entornos de nube.
• Aprovisionamiento y desaprovisionamiento. Procedimientos documentados para otorgar acceso durante la incorporación y revocar todo acceso durante la desvinculación. Los auditores prueban específicamente si el acceso de los empleados terminados fue revocado con prontitud.

En la práctica: CC6 es donde ocurre la mayoría de los hallazgos de auditoría SOC 2. Los problemas más comunes: MFA no aplicado en todos los sistemas (esa consola de administración heredada sin MFA), revisiones de acceso no completadas según el calendario, empleados terminados con acceso persistente y roles IAM excesivamente permisivos. Invierta atención desproporcionada aquí — la exhaustividad de sus controles de acceso determina directamente los resultados de la auditoría.

CC7: Operaciones del sistema

Criterios cubiertos: CC7.1 a CC7.5

CC7 cubre cómo su organización detecta, evalúa y responde a los eventos e incidentes de seguridad. Es el latido operativo de su programa de seguridad — los controles que se ejecutan continuamente en lugar de periódicamente.

Lo que buscan los auditores:

• Herramientas de monitoreo y detección de eventos de seguridad (SIEM, agregación de logs, alertas)
• Procedimientos de clasificación y escalamiento de alertas
• Plan de respuesta a incidentes con roles definidos, clasificaciones de severidad y procedimientos de respuesta
• Evidencia de detección, respuesta y resolución de incidentes
• Documentación de revisión post-incidente

Implementación SaaS:

• SIEM o agregación de logs. Centralice los logs relevantes de seguridad — eventos de autenticación, fallas de autorización, cambios del sistema, actividad de red, errores de aplicación — en una sola plataforma. Configure reglas de alerta para patrones sospechosos: intentos de fuerza bruta, escalación de privilegios, patrones inusuales de acceso a datos, cambios de configuración fuera de ventanas de mantenimiento.
• Proceso de clasificación de alertas. Defina cómo se clasifican las alertas (informativa, advertencia, crítica), quién recibe cada clasificación, tiempos de respuesta esperados por severidad y rutas de escalamiento cuando el respondedor primario no está disponible.
• Manual de respuesta a incidentes. Documente sus procedimientos de respuesta para cada categoría de incidente: brecha de datos, acceso no autorizado, interrupción del servicio, detección de malware, amenaza interna. Incluya listas de contactos, plantillas de comunicación, procedimientos de contención y pasos de recuperación. Consulte nuestra guía de respuesta a incidentes para un marco completo.
• Revisiones post-incidente. Después de cada incidente significativo, realice un post-mortem sin culpas. Documente la cronología, la causa raíz, el impacto, la efectividad de la respuesta y las acciones correctivas. Estas revisiones se convierten en evidencia de auditoría y demuestran una cultura de seguridad madura.

Ejemplo SaaS: Su SIEM detecta múltiples intentos fallidos de autenticación contra una cuenta de administrador a las 3 AM. Sus reglas de alerta activan una notificación al ingeniero de guardia. El ingeniero sigue el manual de respuesta a incidentes: bloquea la cuenta, investiga el origen, determina que fue un ataque de relleno de credenciales, verifica que no hubo acceso exitoso, documenta el evento e implementa limitación de tasa adicional. Toda la secuencia — detección, clasificación, respuesta, resolución, documentación — es la cadena de evidencia que revisa su auditor.

CC8: Gestión de cambios

Criterios cubiertos: CC8.1

CC8 tiene un solo criterio pero es una de las áreas más intensamente probadas en la auditoría SOC 2 de una empresa SaaS. Cubre cómo se gestionan, aprueban, prueban y despliegan los cambios a su infraestructura, aplicaciones, datos y procedimientos.

Lo que buscan los auditores:

• Una política documentada de gestión de cambios
• Requisitos de revisión de código (revisión por pares antes del merge)
• Pipeline de CI/CD con pruebas automatizadas
• Procedimientos de despliegue con flujos de trabajo de aprobación
• Entornos de staging o pre-producción para probar cambios antes de producción
• Procedimientos de cambio de emergencia con revisión retroactiva
• Capacidades de reversión y documentación

Implementación SaaS:

• Revisión de código basada en PR. Todos los cambios de código requieren un pull request revisado y aprobado por al menos un par antes del merge. Aplique esto a través de reglas de protección de ramas en GitHub, GitLab o Bitbucket. Los auditores muestrean PRs y verifican que las revisiones se completaron.
• Controles del pipeline de CI/CD. Las pruebas automatizadas (pruebas unitarias, pruebas de integración, escaneos de seguridad) deben pasar antes del despliegue. Las configuraciones del pipeline deben tener control de versiones y los cambios al pipeline mismo deben requerir revisión.
• Entornos de staging. Los cambios se despliegan a un entorno de staging o pre-producción antes de llegar a producción. Los auditores verifican que tiene un entorno de no-producción y que se usa de manera consistente.
• Flujo de trabajo de aprobación de despliegue. Para despliegues a producción, defina quién puede aprobar y quién puede ejecutar. La segregación de funciones — la persona que escribió el código no debería ser la única persona que lo aprueba — es un control clave.
• Proceso de cambio de emergencia. A veces los problemas de producción requieren correcciones inmediatas que eluden la revisión normal. Documente un procedimiento de cambio de emergencia que permita despliegue expedito con revisión y documentación retroactiva obligatoria dentro de 24-48 horas.
• Procedimientos de reversión. Documente cómo revertir un despliegue fallido. Los auditores quieren ver que ha considerado las fallas de despliegue y tiene una ruta de recuperación documentada.

En la práctica: A los auditores les encanta examinar la gestión de cambios porque la evidencia es rica y fácilmente verificable. Extraerán su historial de Git, observarán los patrones de aprobación de PR, verificarán las configuraciones del pipeline de CI/CD y compararán los logs de despliegue contra sus procedimientos declarados. El hallazgo más común: desarrolladores con la capacidad de hacer push directamente a la rama principal, eludiendo la revisión de código. Bloquee esto antes de su auditoría.

CC9: Mitigación de riesgos

Criterios cubiertos: CC9.1 a CC9.2

CC9 se enfoca en las actividades de mitigación de riesgos, con un énfasis particular en la gestión de riesgos de proveedores y socios comerciales. Para empresas SaaS que dependen de docenas de servicios de terceros, esta categoría es cada vez más significativa.

Lo que buscan los auditores:

• Un programa de gestión de proveedores con procesos documentados
• Inventario de proveedores con clasificaciones de riesgo
• Evidencia de debida diligencia para proveedores críticos (informes SOC 2, cuestionarios de seguridad, certificaciones)
• Contratos con requisitos de seguridad y cláusulas de protección de datos
• Procedimientos de reevaluación periódica de proveedores

Implementación SaaS:

• Inventario de proveedores. Mantenga una lista completa de todos los proveedores que acceden, procesan o almacenan sus datos o los datos de sus clientes. Clasifique cada uno por nivel de riesgo según la sensibilidad de los datos y la criticidad del negocio.
• Evaluaciones de riesgo de proveedores. Para proveedores de alto riesgo (aquellos con acceso a datos de clientes o infraestructura crítica), realice evaluaciones de riesgo formales. Revise sus informes SOC 2, certificaciones de seguridad y respuestas a sus cuestionarios de seguridad. Documente la evaluación y cualquier riesgo residual aceptado.
• Requisitos de seguridad contractuales. Asegúrese de que los contratos con proveedores incluyan obligaciones de protección de datos, requisitos de notificación de brechas, derechos de auditoría y cláusulas de terminación. Para proveedores que procesan datos personales, incluya acuerdos de tratamiento de datos.
• Reevaluación anual. Revise las clasificaciones de riesgo y la postura de seguridad de los proveedores anualmente. Solicite informes SOC 2 actualizados, revise cualquier incidente de seguridad que el proveedor haya divulgado y reevalúe si el proveedor aún cumple con su tolerancia al riesgo.

Ejemplo SaaS: Su aplicación usa Stripe para pagos, AWS para alojamiento, SendGrid para correo electrónico y una herramienta de analítica startup para métricas de producto. AWS y Stripe están bien establecidos con informes SOC 2 que puede revisar. SendGrid también tiene un informe SOC 2. La herramienta de analítica startup no tiene SOC 2 ni documentación de seguridad limitada. Su evaluación de riesgo de proveedores documenta esta brecha, y su decisión de aceptación de riesgo (o su decisión de encontrar un proveedor alternativo) es la evidencia que revisa su auditor.

Para un marco completo de gestión de proveedores, consulte nuestra guía de gestión de proveedores.

Mapeo de controles a Common Criteria

Crear una matriz de controles — un documento que mapea cada punto de CC a los controles específicos que lo satisfacen — es uno de los ejercicios más valiosos de su programa SOC 2.

Cómo construir una matriz de controles:

1. Enumere cada criterio de CC (CC1.1 a CC9.2) en una hoja de cálculo o plataforma GRC.
2. Para cada criterio, identifique los controles en su entorno que lo satisfacen. Un control puede (y debe) mapearse a múltiples criterios.
3. Para cada control, documente la evidencia que demuestra que el control está operando. Vincule a fuentes de evidencia específicas.
4. Identifique las brechas — criterios sin controles mapeados. Estas son sus prioridades de remediación.

Un control, múltiples criterios. Su revisión trimestral de acceso satisface CC6.3 (restricción de acceso), CC4.1 (actividades de monitoreo) y CC1.4 (responsabilidad). Su proceso de respuesta a incidentes satisface CC7.3 (evaluación de eventos), CC7.4 (respuesta a incidentes) y CC2.2 (comunicación de información). Mapear estas superposiciones reduce el número total de controles que necesita implementar.

Comience con los controles de mayor impacto. Si está construyendo su marco de controles desde cero, priorice la gestión de acceso (CC6), la gestión de cambios (CC8) y el monitoreo (CC7). Estas tres categorías cubren la mayoría de los criterios, producen la mayor cantidad de evidencia y abordan los riesgos que los auditores ponderan más.

Ejemplo de mapeo para una empresa SaaS típica:

Control	Criterios CC satisfechos	Evidencia
SSO con aplicación de MFA	CC6.1, CC6.2, CC6.6	Captura de configuración de IdP, política de MFA, logs de inicio de sesión
Revisiones trimestrales de acceso	CC6.1, CC6.3, CC4.1, CC1.4	Registros de revisión de acceso, tickets de remediación
Revisión de código basada en PR	CC8.1, CC5.2	Configuración de protección de ramas, PRs de muestra con aprobaciones
Evaluación anual de riesgos	CC3.1, CC3.2, CC3.3	Documento de evaluación de riesgos, registro de riesgos
Capacitación en concienciación de seguridad	CC1.1, CC2.1	Registros de finalización de capacitación, contenido de capacitación
Plan de respuesta a incidentes	CC7.3, CC7.4, CC7.5	Manual de RI, tickets de incidentes, post-mortems
Evaluaciones de riesgo de proveedores	CC9.1, CC9.2	Inventario de proveedores, registros de evaluación, informes SOC

Criterios adicionales más allá de los Common Criteria

Los Common Criteria cubren el TSC de Seguridad, pero si su informe SOC 2 incluye Criterios de Servicio de Confianza adicionales, necesitará abordar puntos de control suplementarios. Consulte nuestra guía de Criterios de Servicio de Confianza para orientación detallada sobre la selección.

Disponibilidad (A1.1-A1.3). Cubre objetivos de recuperación, procedimientos de respaldo y pruebas de recuperación ante desastres. Necesitará RTOs y RPOs documentados, respaldos automatizados con procedimientos de restauración probados y un plan de DR que haya sido validado a través de al menos pruebas anuales.

Integridad del procesamiento (PI1.1-PI1.5). Cubre la completitud, precisión, oportunidad y autorización del procesamiento. Relevante para productos SaaS que realizan cálculos financieros, transformaciones de datos o procesamiento de transacciones. Necesitará validación de entrada, controles de conciliación y monitoreo de procesamiento.

Confidencialidad (C1.1-C1.2). Cubre la identificación y protección de información confidencial. Necesitará un esquema de clasificación de datos, controles específicos para cada nivel de clasificación y evidencia de que los datos confidenciales reciben protección mejorada (cifrado, restricciones de acceso, límites de retención).

Privacidad (P1-P8). Cubre el ciclo de vida completo de la información personal — aviso, elección, recopilación, uso, divulgación, acceso, calidad y monitoreo. Este es el criterio adicional más extenso y se superpone significativamente con los requisitos del RGPD. Solo inclúyalo si sus clientes lo requieren específicamente o si la privacidad es central a su propuesta de valor.

En la práctica: La mayoría de las empresas SaaS que buscan su primer informe SOC 2 deben comenzar solo con Seguridad (Common Criteria). Cada criterio adicional añade un 15-25% más de controles, evidencias y alcance de auditoría. Añada criterios en el año 2+ basándose en requisitos reales de clientes, no en especulación sobre lo que podría necesitarse.

Cómo ayuda GRCTrail

GRCTrail proporciona un marco estructurado para implementar y gestionar controles en todas las categorías de Common Criteria.

• Marco de controles pre-construido mapeado a todos los Common Criteria para que comience con un conjunto completo de controles CC1-CC9 diseñado para empresas SaaS, no una hoja de cálculo en blanco
• Orientación de implementación de controles para cada categoría CC con instrucciones paso a paso, ejemplos específicos para SaaS y herramientas recomendadas para cada control
• Requisitos de evidencia vinculados a controles para que su equipo sepa exactamente qué artefactos recopilar, dónde encontrarlos y con qué frecuencia necesitan actualizarse
• Análisis de brechas mostrando qué puntos CC tienen controles y cuáles no — dándole una vista en tiempo real de su preparación y una hoja de ruta de remediación priorizada
• Integración de pruebas automatizadas de controles que valida continuamente si sus controles están operando según lo diseñado, señalando la deriva antes del próximo muestreo de su auditor

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
• Lista de verificación de cumplimiento SOC 2 para empresas SaaS
• Guía de políticas y procedimientos SOC 2